GitHub Actionsのシステム開発の発注/外注/依頼/委託方法について

GitHub Actionsのシステム発注・外注は、YAMLファイルの作成だけを依頼するのではなく、リポジトリ、Runner、クラウド認証、デプロイ、監査、運用保守までを一つの開発業務基盤として設計することが重要です。

「社内にGitHub Actionsを設計できる人がいない」「Jenkinsなどの既存CIから移行したい」「GitHub Enterpriseやself-hosted Runnerまで含めて、どこに何を頼めばよいのか分からない」と悩む企業担当者は少なくありません。本記事では、発注形態の選び方、RFPと要件整理、請負・準委任の使い分け、初期費用とランニングコストの相場、委託先の選定、見積比較、契約後の引き継ぎまでを順番に解説します。

▼全体ガイドの記事
・GitHub Actionsのシステム開発の完全ガイド

GitHub Actionsのシステム発注・外注は何を依頼しますか？

GitHub Actionsの外注では、ワークフローの実装に加えて、何を自動化し、どの環境へ、誰の承認でリリースするかを決めます。GitHub ActionsはpushやPull Requestなどを起点にビルド、テスト、リリース、運用作業を実行する基盤です。そのため、ソースコード管理だけでなく、認証情報、実行環境、成果物の保管、通知、障害対応を含めて発注範囲を考えます。

発注時は、GitHubのプランやEnterprise契約の支援と、GitHub ActionsのWorkflow実装を分けて確認します。GitHub Enterpriseを契約しても、自社のブランチ戦略に合うPull Requestチェック、テスト、イメージ作成、staging・productionへのデプロイ、失敗時のロールバックが自動で完成するわけではありません。ライセンス販売を得意とする会社と、CI/CD設計やクラウド連携まで担当できる会社では、提案の範囲が異なります。

委託先へ依頼する成果物は、WorkflowのYAMLだけに限定しないことが大切です。リポジトリごとの設定一覧、Reusable Workflowや社内Actionのソース、Runner構成、OIDCによるクラウド認証設定、Environmentの承認ルール、権限一覧、監査・通知の設計書、テスト結果、運用Runbook、担当者向けの教育資料まで含めると、納品後に自社で改善しやすくなります。

外注範囲は、現状調査、基本設計、PoC、Workflow構築、既存CIからの移行、クラウドやレジストリとの連携、テスト、教育、運用保守に分解します。たとえば最初の発注では、1〜3リポジトリを対象にPull Request時の静的解析・単体テストとstagingデプロイを作り、使い勝手と失敗時の復旧を確認する方法があります。最初から全社の本番環境を切り替えるより、課題と追加費用を把握しやすくなります。

既存のJenkins、GitLab CI、CircleCIなどから移行する場合は、YAMLを機械的に置き換えるだけでは不十分です。認証方式、Secretsの保管、キャッシュ、並列実行、成果物の保持期間、手動承認、通知先、再実行の方法を比較し、移行後に業務が止まらないようにします。委託先には、移行対象と対象外、並行稼働の期間、切り戻し条件を見積書と計画書に明記してもらいます。

発注形態は一括請負・準委任・内製併用から選びます

発注形態は、要件がどの程度固まっているか、自社にどれだけ運用人材がいるか、成果物の完成条件を定義できるかで選びます。一社へまとめて依頼する方法は管理しやすい一方、ライセンス、アプリ開発、クラウド、セキュリティの専門領域を一社でカバーできるかを確認する必要があります。調査や改善を含む場合は、複数の契約を段階的に組み合わせる方が実態に合うこともあります。

対象リポジトリ、使用言語、実行環境、デプロイ先、成功条件が決まっている場合は、設計・実装・テスト・納品を一括請負で依頼しやすくなります。完成すべきWorkflow、設定ファイル、テストケース、ドキュメント、受入条件を契約書や個別仕様書に記載できるため、予算と納期を管理しやすい方式です。

ただし、請負契約でもGitHubやAWSなど第三者サービスの仕様変更まで受託会社が無期限に保証するわけではありません。GitHub Enterpriseの契約費、クラウド利用料、MarketplaceのAction、Runnerのマシン費用を含むか、仕様変更に伴う追加対応を誰が負担するかを分けて記載します。受入後に何をもって完成とするかが曖昧だと、追加改修の判断が難しくなります。

現行CIの調査、移行可否の検証、セキュリティ診断、PoC、開発者とのワークショップ、運用改善は、実施しながら課題が明らかになるため、準委任で依頼する方法が適しています。稼働時間や担当者の役割、会議体、成果物、報告方法を決めておけば、要件を固める前の専門家支援を受けられます。

準委任は作業時間に対する契約になりやすく、想定した機能の完成を自動的に保証する契約ではありません。担当者のスキル、月の稼働時間、レビュー責任、成果物の著作権、作業ログ、未消化時間、途中解約の条件を確認します。PoC後に請負で本構築へ移る場合は、PoCの設定や検証結果を本番契約へ引き継げるかも確認します。

社内にアプリ開発者がいる場合は、委託先へ基盤設計、セキュリティ、難しいクラウド連携を依頼し、各チームが自分のリポジトリのWorkflowを更新する分担も可能です。外部会社がすべてを作って納品するより、標準テンプレートとレビューの仕組みを残せるため、リポジトリを増やしたときの追加費用を抑えやすくなります。

内製併用では、誰が共通Workflowを承認するか、第三者Actionの採用基準を誰が更新するか、productionのリリース権限を誰が持つかを明確にします。外注先のノウハウが担当者個人に閉じないよう、ペアレビュー、設計書、録画した操作説明、引き継ぎ期間を契約に含めます。

RFP・要件整理では何を決めておきますか？

RFPは、開発会社から同じ前提で提案と見積を出してもらうための文書です。GitHub Actionsを導入する目的、現行環境、対象リポジトリ、開発言語、ブランチ戦略、既存CI、デプロイ先、利用者、希望時期、予算の考え方、納品物、提案期限、評価方法を記載します。機能要件だけでなく、セキュリティ、性能、可用性、監査、保守、教育まで含めると、会社ごとの見積範囲をそろえやすくなります。

現状調査では、リポジトリ数、公開・非公開の区分、主要言語、テスト時間、ブランチ保護、Pull Requestのレビュー人数、既存CIの処理、成果物の保存先、デプロイ先を一覧化します。開発環境、staging、本番の違い、手動承認の有無、リリース頻度、失敗時の戻し方も確認します。複数部署や複数アカウントが関係する場合は、組織・リポジトリ・Environmentごとの管理者も整理します。

既存のSecretsやクラウド資格情報がどこに保管されているかも確認します。長期的なアクセスキーをWorkflowへ埋め込む構成をそのまま移行せず、AWS、Azure、Google Cloudなどとの接続はOIDCによる短期認証を候補にします。GitHub公式ドキュメントでも、クラウドへ長期保管の秘密情報を渡す代わりに、Workflowの実行ごとに短期トークンを発行するOIDC連携が案内されています（出典：GitHub公式「OIDC in cloud providers」、2026年）。

要件は「GitHub Actionsを導入する」ではなく、「Pull Request作成時に静的解析と単体テストを実行し、失敗時はマージを禁止する」「mainへのマージ後にstagingへデプロイし、承認者がproductionを実行する」のように業務シナリオで書きます。Workflow、Job、Stepの単位、並列実行、matrixテスト、キャッシュ、成果物の保持期間、再実行、手動実行、通知先まで決めると、提案内容を比較できます。

受入条件は、YAMLファイルが納品されたことではなく、実際のリポジトリで期待した処理が成功することにします。たとえば、Pull Requestのテストが失敗したときにマージできないこと、stagingへのデプロイが指定の承認を経ること、失敗時に担当者へ通知されること、同じ入力で再実行できること、ロールバック手順を実行できることを確認します。テスト用のサンプルコードと判定基準を発注者側で用意すると、納品後の認識違いを減らせます。

非機能要件には、実行時間、同時実行数、必要なOSやCPU、成果物の容量、ログの保存期間、バックアップ、通知、障害時の復旧目標を含めます。self-hosted Runnerを使う場合は、ネットワーク接続、プロキシ、社内レジストリ、Runner Group、ラベル、マシンの調達、OSパッチ、監視、交換、廃棄まで発注範囲に入ります。GitHub-hosted Runnerなら運用負担を減らせますが、社内ネットワーク内の資産へ接続する設計には別の制約があります。

GitHubの設定を委託先のアカウントで管理したままにしないことも重要です。リポジトリ、Organization、クラウド、コンテナレジストリ、監視サービスの所有者を自社に置き、外注先には必要な範囲の権限だけを付与します。契約終了時のアカウント削除、Secretsの再発行、Runnerの登録解除、成果物とログの返却・削除、再委託先の扱いをRFPと契約書の両方で確認します。

契約形態と責任分界はどこを確認しますか？

GitHub Actionsの案件では、要件定義、Workflow開発、GitHubライセンス、クラウド利用、Runner運用、脆弱性対応、問い合わせ対応が混在します。契約名だけで判断せず、成果物、作業、判断、費用、事故対応の責任を分けて書くことが大切です。開発会社が設定を作り、発注者が本番承認を行い、クラウド会社がIAMとネットワークを管理するような分担も考えられます。

請負契約で依頼する場合は、対象リポジトリ、Workflowの機能、対応するブランチ、環境、テストケース、ドキュメント、納期、受入条件を個別仕様書へ落とし込みます。GitHub Actionsの標準機能で対応する範囲、社内Actionを新規作成する範囲、外部サービスの設定を行う範囲も区別します。

契約後に「本番も追加したい」「別リポジトリにも展開したい」「self-hosted Runnerへ変えたい」となった場合の変更手続きも決めます。追加見積の単位、影響調査の費用、納期の再計算、変更承認者、緊急対応の料金を定めておくと、口頭の依頼が積み上がることを防げます。

準委任契約では、プロジェクトマネージャー、GitHub管理者、クラウド担当、セキュリティ担当などの役割と稼働時間を確認します。月次の作業報告、課題一覧、設計レビュー、コードレビュー、定例会議、緊急時の連絡方法を契約に含めます。成果物の完成保証がない契約でも、設計書、調査報告、検証結果、変更履歴など、作業の結果を残す形にします。

作業時間を消化することが目的にならないよう、月ごとの達成目標と判断基準を置きます。たとえば1か月目は現行調査、2か月目は1リポジトリでのPoC、3か月目は共通Workflowと運用手順の作成というように分けます。自社担当者の参加時間と意思決定の期限も明記すると、発注者側の遅延が全体計画へ与える影響を説明しやすくなります。

GitHub ActionsのWorkflowは、リポジトリのコードやSecretsにアクセスし、場合によっては本番環境へ変更を届けます。委託先へ渡す権限を発注者の管理下に置き、MFA、SSO、最小権限、監査ログ、承認ルール、アクセス可能な時間を決めます。事故が起きたときの一次連絡、Secretsの無効化、Runner隔離、ログ保全、原因調査、再発防止、報告期限も責任分界に含めます。

GitHub公式のSecure use referenceでは、第三者Actionを完全なコミットSHAへ固定することが、変更されない実体を指定する方法として案内されています。また、GITHUB_TOKENを含む権限は最小限にし、Pull Requestから未検証の入力をWorkflowへ渡さないことも重要です（出典：GitHub公式「Secure use reference」、2026年）。この確認を設計レビューと受入テストの項目に入れ、納品後のAction更新ルールまで決めます。

GitHub Actionsのシステム発注費用・相場はいくらですか？

GitHub Actionsの費用は、GitHubのライセンス、Workflowの設計・実装、Runner、クラウドやレジストリ、監視、教育、保守に分けて考えます。以下の初期費用は、一般的な業務システムの小規模・中規模・大規模の開発相場と、GitHub Actionsの導入範囲を照らし合わせた推定レンジです。公開された一律の定価ではないため、対象リポジトリ数や既存環境、セキュリティ要件によって変動します。

1〜3リポジトリを対象に、Pull Request時のテスト、基本的なstagingデプロイ、Secrets設定、操作説明までを依頼する小規模案件では、初期費用は50万〜150万円程度が比較用の目安になります。期間は2〜6週間程度が一つの目安です。既存CIがなく、テストコードやデプロイ手順も整っていない場合は、Workflow以外の準備工数が増えるため、この範囲を超える可能性があります。

10〜50リポジトリへ展開し、Reusable Workflow、OIDC、Environment承認、既存CIからの移行、監視、教育まで含める中規模案件では、150万〜500万円程度、期間は1.5〜4か月程度が推定レンジです。Enterprise Cloudや複数クラウド、社内レジストリとの連携、部門ごとの権限設計がある場合は、対象範囲と体制を分けて見積を取ります。

GitHub Enterprise CloudまたはEnterprise Server、SSO・SCIM、組織ルール、複数部署、self-hosted Runner、専用ネットワーク、監査、段階展開、内製化まで含める場合は、初期費用500万〜1,500万円以上、期間3〜9か月以上の推定レンジになります。これはGitHub Actionsの利用料だけではなく、現状調査、設計、ネットワーク、IAM、移行、テスト、教育、運用設計を含む場合の目安です。

見積を受け取ったら、金額の大小だけでなく、何が含まれているかを確認します。特に、対象リポジトリ数、Workflow本数、テストの作成、クラウド側のIAM、Runnerの構築、監視、障害対応、ドキュメント、教育、移行、受入テストが別料金になっていないかを見ます。要件が曖昧なまま対象リポジトリや環境を増やすと、工数が1.3〜1.5倍程度に膨らむことがあるため、追加の単価と変更条件も確認します。

GitHub-hosted Runnerの料金は、GitHub公式の2026年料金表で、標準Linux 2-coreが1分あたり0.006米ドル、Windows 2-coreが0.010米ドル、macOS 3〜4-coreが0.062米ドルと掲載されています（出典：GitHub公式「Actions runner pricing」、2026年）。ジョブごとに分単位へ切り上げられるため、月間の実行分数、OS、並列数を集計して見積に入れます。GitHubのプラン、Actionsのストレージ、Packages、クラウド、ネットワークの費用は別途発生します。

GitHubは2026年1月1日から、GitHub-hosted Runnerの価格をマシン種別に応じて最大39％引き下げました。一方、self-hosted Runnerについて発表されていた1分あたり0.002米ドルの新たなプラットフォーム課金は再評価のため延期されています（出典：GitHub Changelog「Update to GitHub Actions pricing」、2025年12月）。料金方針は変わる可能性があるため、契約直前に公式料金表を確認し、見積書には「GitHub公式の改定時は実費変更」といった扱いを明記します。

self-hosted RunnerはGitHub側の実行料金だけで判断できません。VMや物理サーバー、OSライセンス、ディスク、ネットワーク、バックアップ、監視、パッチ、障害対応、容量増強、Runnerの交換が必要です。GitHub公式ドキュメントでは、self-hosted RunnerのOSやソフトウェア更新は利用者が担うと説明されています。保守費は類似する業務システム相場をもとに、初期費用の年15〜25％程度、または月額5万〜30万円程度から比較し、対応時間と作業範囲を確認します。

委託先の選定と見積比較では何を見ますか？

委託先は、GitHubの販売実績だけでなく、CI/CDの設計・実装、クラウド、IaC、セキュリティ、教育、運用保守の6軸で比較します。GitHub Enterpriseのライセンスを扱える会社でも、複雑なWorkflowやself-hosted Runnerの設計を経験しているとは限りません。逆にアプリ開発会社でも、Enterpriseの組織設計や監査要件を扱えるとは限らないため、今回の案件で必要な専門性を分解して確認します。

実績を確認するときは、「GitHub Actionsの導入実績があります」という説明で終わらせません。対象リポジトリ数、言語、既存CIからの移行、GitHub-hostedかself-hostedか、クラウド、OIDC、承認フロー、セキュリティ審査、保守体制、内製化まで、担当した範囲を質問します。可能であれば、公開できる範囲で設計書の目次、Workflowの標準化方法、失敗時の復旧手順、導入後の改善事例を確認します。

事例の数字だけを鵜呑みにしないことも大切です。デプロイ時間が短縮されたとしても、テストの品質、失敗率、リードタイム、復旧時間、運用担当者の負担がどう変わったかを見ます。発注者と同じ業界の経験がなくても、個人情報、閉域網、監査、承認、24時間運用などの制約を扱った経験があれば、技術要件を自社へ応用できる場合があります。

相見積もりでは、各社へ同じRFP、対象リポジトリ一覧、サンプルWorkflow、クラウド構成、希望スケジュールを渡します。見積書は、現状調査、要件定義、設計、Workflow実装、Action開発、Runner、クラウド設定、データや設定の移行、テスト、教育、ドキュメント、保守に分けてもらいます。人月、作業時間、対象数量、単価、前提条件、除外項目が記載されていると、安い理由や高い理由を確認しやすくなります。

比較時は、初期費用だけでなく3年間程度の総保有コストを考えます。GitHubの契約費、Runnerの実行分数、ストレージ、クラウド、監視、保守、脆弱性対応、バージョンアップ、追加リポジトリ、担当者教育を足し合わせます。過度に安い見積では、セキュリティレビュー、運用Runbook、テスト自動化、引き継ぎ、障害対応が含まれていないことがあるため、除外項目を先に確認します。

提案面談では、うまくいくケースの説明だけでなく、テスト失敗、Runner停止、クラウド認証の期限切れ、第三者Actionの脆弱性、誤ったデプロイ、GitHubのサービス障害が起きたときの対応を質問します。誰が一次切り分けを行い、どのログを確認し、どの条件で手動リリースやロールバックへ切り替え、何時間以内に報告するのかを確認します。

引き継ぎでは、発注者の担当者がWorkflowの変更、Secretsの更新、Runnerの交換、ActionのSHA更新、利用量の確認、障害時の再実行を実施できるかを見ます。最終納品日に資料を渡すだけではなく、実際の操作を一緒に行い、発注者が自力で変更できたことを確認します。内製化が目的なら、教育費と引き継ぎ期間を初期見積から外さないことが重要です。

GitHub Actionsのシステム発注・外注でよくある質問

GitHub Actionsの外注では、費用や技術だけでなく、自社の運用体制と契約後の責任分界に関する質問が多くなります。ここでは、発注前に確認しておきたい代表的な疑問へ直接回答します。

Workflowの実装だけを外注することは可能ですが、テスト、Secrets、Runner、デプロイ先、通知、ロールバックの前提が決まっていなければ、納品後に動かない可能性があります。最低限、対象リポジトリ、実行環境、認証方式、成功条件、保守担当を整理し、YAML以外に必要な設定とドキュメントも見積へ含めます。

1〜3リポジトリでPull Requestのテストとstagingデプロイを作る小規模案件なら、2〜6週間程度が目安です。10〜50リポジトリへの標準化、既存CIからの移行、OIDC、教育、監視まで含める場合は1.5〜4か月程度、Enterpriseやself-hosted Runner、全社展開を含める場合は3〜9か月以上の計画になります。現行テストの不足、権限調整、ネットワーク申請、受入者の確保によって変動します。

社内ネットワーク、特殊なビルド環境、機密データ、独自ハードウェアが必要なら、self-hosted Runnerの設計・構築を外注する価値があります。ただし、OS更新、Runnerソフトウェア、監視、容量、隔離、障害対応は継続的な運用業務です。GitHub公式では、更新を止めたRunnerは新機能に対応できず、一定期間更新しない場合はジョブがキューに入らなくなると説明されています。2026年はGitHub Enterprise Cloudでself-hosted Runnerのバージョン要件が段階的に強化され、同環境では2026年9月25日から完全適用予定と発表されているため、更新担当と予算を契約前に決めます（出典：GitHub Changelog「Minimum version enforcement timeline for self-hosted runners」、2026年6月）。

RFPを同じ条件で渡せるなら、2〜3社程度へ依頼すると提案内容と費用を比較しやすくなります。GitHubライセンス、CI/CD、クラウド、セキュリティ、保守のどこまでを一社へ任せるかをそろえ、見積の前提と除外項目を確認します。最安値ではなく、要件の理解、実装担当者の経験、障害対応、成果物、引き継ぎ、将来の追加費用まで含めて総合的に選びます。

まとめ

発注前は、対象リポジトリ、現行CI、デプロイ先、Runner方式、認証、受入条件、納品物、保守範囲を一枚の一覧にまとめます。委託先から提案を受けた後も、できることだけでなく、できないこと、追加費用になること、発注者が用意することを確認すると、契約後の手戻りを減らせます。

最初の発注では、1〜3リポジトリを対象に、Pull Requestの品質ゲートとstagingデプロイを検証し、開発者が自分で運用できる状態を目指します。効果、課題、追加費用、内製へ移せる範囲を記録してから対象を広げると、GitHub Actionsを長く使える開発基盤へ育てやすくなります。

GitHub Actionsのシステムを発注・外注するときは、YAMLの作成費だけでなく、GitHubの契約、Workflow、Runner、クラウド認証、デプロイ、監査、通知、保守、教育までを一つの開発業務基盤として整理します。まずは現行CIと対象リポジトリを棚卸しし、1〜3リポジトリのPoCで自動化の効果と運用負担を確認すると、全社展開の判断をしやすくなります。

RFPには、目的、対象範囲、Workflowの受入条件、認証方式、Runner方式、セキュリティ、障害対応、納品物、契約後の責任分界を明記します。要件が固まった開発は請負、調査や改善は準委任、共通基盤は外注して各チームが運用する内製併用というように、工程ごとに発注形態を選びます。相見積もりでは、初期費用だけでなくGitHub利用料、Runner・クラウド、保守、更新、教育を含む総保有コストで比較することが大切です。

委託先を選ぶ際は、ライセンス販売の実績だけでなく、CI/CD実装、クラウド・IaC、セキュリティ、運用保守、内製化支援を確認します。第三者ActionのSHA固定、最小権限、OIDC、Environment承認、self-hosted Runnerの更新、ロールバック、契約終了時のアカウントとSecretsの整理まで確認できる会社を選ぶと、納品後の属人化と予期しない追加費用を抑えやすくなります。

▼全体ガイドの記事
・GitHub Actionsのシステム開発の完全ガイド

会社紹介

株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。

また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。

もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。

株式会社riplaの会社HPはこちら

・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>

執筆者プロフィール

張田谷凌央

株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。