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

GitHub Actionsの発注は、現状調査、要件整理、PoC、見積比較の順に進めると、自社で運用できる基盤につながります。

依頼範囲から委託先の選び方まで、順に見ていきます。全体像は、GitHub Actionsのシステム開発の完全ガイドもご覧ください。

・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。

GitHub Actionsのシステム発注・外注の依頼範囲

GitHub Actionsは、pushやPull Requestを起点に、ビルド、テスト、リリース、運用作業を実行する基盤です。そのため、外注では何を自動化し、どの環境へ、誰の承認でリリースするかを先に決めておく必要があります。また、認証情報、実行環境、成果物の保管、通知、障害対応も、発注範囲に含めます。

ライセンス導入とWorkflow実装の切り分け

発注時は、GitHubの契約支援とWorkflow実装を分けて確認します。Enterprise契約を結んでも、ブランチ戦略に沿ったテストやデプロイが自動的にできあがるわけではありません。

失敗時のロールバックも、Workflowの設計対象に含まれます。ライセンス販売に強い会社と、CI/CD設計やクラウド連携を担える会社では、提案の範囲が異なります。

Workflow：YAML、設定一覧、Reusable Workflow、社内Actionのソース
環境・権限：Runner構成、OIDC、Environment承認ルール、権限一覧
運用：監査・通知設計書、テスト結果、Runbook、教育資料

これらをYAMLと一緒に納品物へ含めておけば、稼働後も自社で手を入れられます。

外注範囲の区切り方（設計・構築・移行・運用）

外注範囲は、調査から運用保守まで工程ごとに分けます。初回は1〜3リポジトリでテストとstagingデプロイを作り、使い勝手や復旧を確かめる方法もあります。

全社の本番環境を一度に切り替えるより、PoCから始めたほうが、課題と追加費用を事前に把握しやすくなります。また、移行では既存CIの仕様を機械的に置き換えないことが大切です。

認証・Secrets：保管方法と認証方式
実行・成果物：キャッシュ、並列実行、保持期間の比較
運用・移行：承認、通知、再実行、切り戻し条件

Jenkins、GitLab CI、CircleCIなどから移行する場合は、移行対象と対象外、並行稼働期間、切り戻し条件を、見積書と計画書の両方に明記します。

ポイント

依頼範囲は、ライセンス導入とWorkflow実装、運用を分けて決めるのが目安です。工程ごとの外注範囲も、調査から運用保守まで区切っておくと、発注後の認識違いを減らせます。

発注形態の選び方（一括請負・準委任・内製併用）

発注形態は、要件がどこまで確定しているか、社内に運用の人材がいるか、成果物の完成条件を定められるかで選びます。

一社にまとめると管理は楽になります。一方で、必要な専門領域をその一社が担えるかは、事前に確かめておく必要があります。

ライセンス、アプリ開発、クラウドを一社で担えない場合には、複数の契約を段階的に組み合わせる方法もあります。セキュリティを一社で担えない場合や、調査・改善を含む場合も、同じ考え方で組み合わせられます。

要件が固まった部分の一括請負

対象リポジトリや言語、実行環境が決まっていれば、一括請負で依頼できます。デプロイ先と成功条件も決まっていることが前提です。

仕様書：Workflow、設定ファイル、テストケース、ドキュメント、受入条件
費用・変更：契約費、クラウド、Marketplace Action、Runner費用と、追加対応の負担
完成条件：受入後の完成基準、追加改修の判断方法

完成条件を先に決めておけば、予算と納期を見通しやすくなります。

第三者サービスの仕様変更まで、無期限に保証されるわけではありません。そのため、契約費や利用料の扱いと、仕様変更への追加対応を誰が負担するかを決めておきます。

調査・PoC・改善の準委任

現行CIの調査や移行検証、セキュリティ診断では、作業の途中で課題が見つかります。PoCやワークショップ、運用改善でも、作業の途中で課題が見つかります。そのため、準委任が適しています。

体制：稼働時間、役割、会議体、報告方法
作業の記録：設計書、調査報告、検証結果、変更履歴
移行計画：月ごとの目標、PoCから請負へ移る際の引き継ぎ

準委任なら、要件が確定する前から専門家の支援を受けられます。ただし、作業時間に対する契約になりやすく、機能の完成を自動的に保証するものではありません。

担当者のスキルや月の稼働時間、レビュー責任を確かめます。著作権、未消化時間、途中解約の条件も、あわせて決めておきます。PoC後に請負へ移るなら、設定と検証結果を引き継げるかも決めておきます。

内製と部分委託の組み合わせ

社内にアプリ開発者がいる場合は、基盤設計、セキュリティ、難しいクラウド連携を外部に委託し、各チームがWorkflowを更新する分担もできます。

標準テンプレートとレビューの仕組みを残しておけば、リポジトリを追加するときの費用を抑えやすくなります。また、共通Workflowの承認者とAction採用基準の更新者も決めておきます。

productionのリリース権限も明確にします。そのうえで、ペアレビューと設計書を契約に含めます。録画した操作説明や引き継ぎ期間も入れ、ノウハウが特定の人だけに残るのを防ぎます。

ポイント

要件が固まった部分は一括請負、調査やPoCは準委任、社内で続けられる部分は内製併用と、役割で分けるのが目安です。一社で担えない範囲は、複数の契約を段階的に組み合わせます。

RFP・要件整理で決めておく事項

前提と責任範囲を共有すると、各社の提案を同じ条件で見比べられます。

RFPは、各社から同じ前提で提案と見積を受けるための文書です。導入目的、現行環境、対象リポジトリを記載します。さらに、言語とブランチ戦略を明記します。既存CIやデプロイ先も書き込みます。

利用者や希望時期、予算の考え方も加えます。納品物、提案期限、評価方法も書きます。セキュリティや性能、可用性の要件も入れます。監査、保守、教育まで含めると、見積の範囲をそろえやすくなります。

現行CI・リポジトリ・デプロイ先の洗い出し

見積の前提をそろえるには、現行CIとリポジトリ、デプロイ環境を次の観点で洗い出します。

リポジトリ：数、公開区分、主要言語、ブランチ保護、レビュー人数
処理と成果物：テスト時間、既存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を納めたかではなく、期待した処理が成功するかを確認します。

発注者側でテスト用のサンプルコードと判定基準を用意しておくと、納品後の認識のずれを減らせます。

RFPに書く非機能要件と責任分界

RFPには、性能とRunner運用を記載します。資産の所有と、契約終了時の責任も書きます。

性能・復旧：実行時間、同時実行数、OS・CPU、容量、ログ、バックアップ、通知、復旧目標
Runner運用：self-hosted Runnerの管理範囲と運用担当
契約終了：アカウント削除、Secrets再発行、Runner解除、成果物・ログ、再委託先

GitHub-hosted Runnerは運用の負担を減らせます。ただし、社内の資産へ接続する設計では、別の制約が出てきます。

self-hosted Runnerでは、ネットワーク接続とプロキシを確かめます。社内レジストリやRunner Group、ラベルの設定も確認します。

マシン調達、OSパッチ、監視は、発注範囲に含めます。さらに、交換と廃棄も入れます。

リポジトリやOrganizationは自社所有にします。さらに、クラウド、レジストリ、監視サービスも、自社所有にします。外注先には、必要な範囲の権限だけを付与します。

成果物やログの返却と削除、再委託先の扱いも、RFPと契約書で確かめます。

契約形態と責任分界の確認点

案件には、要件定義やWorkflow開発、ライセンスが混在します。さらに、クラウドやRunner運用、脆弱性対応も含まれ、問い合わせ対応が加わることもあります。

契約名だけでなく、成果物と作業、判断の責任を分けます。費用と事故対応についても、誰が負うかを決めます。開発会社が設定を作り、発注者が本番承認を行う分担も可能です。

クラウド会社がIAMとネットワークを管理する分担も考えられます。

請負契約の完成条件と変更管理

対象と成功条件が決まっている案件なら、請負で依頼できます。

仕様書：対象リポジトリ、Workflow機能、ブランチ、環境、テスト、文書、納期、受入条件
開発範囲：標準機能、社内Actionの新規作成、外部サービス設定の区別
変更手続き：本番追加、別リポジトリへの展開、Runner変更時の手続き
費用：Enterprise契約、クラウド、Marketplace Action、Runnerマシンの費用
追加対応：見積単位、影響調査費、納期の再計算、承認者、緊急対応料金

変更の条件を決めておけば、口頭での依頼が積み重なるのを防げます。

準委任契約の体制と成果物

準委任では、体制と作業の記録を契約で確かめます。月ごとの目標や、自社側の参加条件も決めます。

体制・報告：各担当の役割と稼働時間、月次報告、課題一覧、レビュー、会議、緊急連絡
成果物：設計書、調査報告、検証結果、変更履歴
月次目標：1か月目に現行調査、2か月目に1リポジトリのPoC、3か月目に共通Workflowと運用手順

完成を保証しない契約でも、作業結果が残る形にしておきます。月ごとに判断基準を置き、作業時間を消化すること自体が目的にならないようにします。

自社の担当者の参加時間と意思決定の期限も明記します。そうすると、発注者側の遅れが計画に与える影響を示せます。

PMとGitHub管理者、クラウド担当の役割と稼働時間も確かめます。セキュリティ担当については、役割と稼働時間を確認します。

作業ログや成果物の著作権も確かめます。さらに、未消化時間と途中解約の条件も確認します。

セキュリティ事故とアカウント管理の責任

Workflowは、コードやSecretsにアクセスし、本番環境を変更することもあります。そのため、契約では、アクセス管理と事故対応、Workflowの安全策を決めておきます。

アクセス管理：発注者管理、MFA、SSO、最小権限、監査ログ、承認、アクセス時間
事故対応：一次連絡、Secrets無効化、Runner隔離、ログ保全、原因調査、再発防止、報告期限
Workflow安全策：ActionのSHA固定、GITHUB_TOKENの最小権限、未検証入力の制限

GitHub公式資料では、Pull Requestから未検証の入力をWorkflowへ渡さない対策も案内されています（出典：GitHub公式「Secure use reference」、2026年）。

これらは、設計レビューと受入テストに含めておきます。納品後の更新ルールも決めます。

ポイント

契約名だけで判断せず、成果物と作業、事故対応の責任を分けて書くのが目安です。特にセキュリティ事故とアカウント管理は、受注側と発注側のどちらが動くかを先に決めておきます。

GitHub Actionsのシステム発注費用の相場

対象範囲が広がるにつれて、見積レンジも大きくなります。

費用は、GitHubライセンス、Workflow設計・実装、Runnerに分けて考えます。さらに、クラウドやレジストリ、監視も費用に含めます。教育と保守も、一覧に加えておきます。

初期費用は、業務システムの規模別の相場と導入範囲から推定した幅です。リポジトリ数や既存環境、セキュリティ要件によって変わるため、一律の金額にはなりません。

初期構築費の目安（小規模は50万〜150万円）

規模別の初期費用と期間は、導入範囲に応じた推定レンジです。

小規模：1〜3リポジトリ、テスト・staging・Secrets・操作説明。50万〜150万円、2〜6週間
中規模：10〜50リポジトリ。150万〜500万円、1.5〜4か月

CI、テストコード、デプロイ手順が未整備だと、準備の工数が増えます。その結果、小規模の費用幅を超える場合もあります。

中規模では、Reusable WorkflowやOIDC、Environment承認が入ることがあります。さらに、既存CIの移行、監視、教育が加わる場合もあります。

Enterprise Cloudや複数クラウドがある場合は、範囲と体制を分けて見積もります。社内レジストリや部門別の権限が絡む場合も、同じ考え方で扱います。

エンタープライズ規模の費用想定（500万〜1,500万円以上）

エンタープライズ規模では、管理基盤と実行環境の範囲を含めて見積もります。

管理基盤：Enterprise CloudまたはEnterprise Server、SSO・SCIM、組織ルール、複数部署
実行環境：self-hosted Runner、専用ネットワーク、監査、段階展開、内製化
見積項目：対象リポジトリ数、Workflow本数、テスト、IAM、Runner、監視、障害対応、文書、教育、移行、受入テスト
追加条件：要件が曖昧なまま範囲を広げると工数が1.3〜1.5倍程度になる場合がある。追加単価と変更条件の確認

初期費用は500万〜1,500万円以上、期間は3〜9か月以上が推定レンジです。利用料だけでなく、現状調査や設計、ネットワーク、IAMを含む目安です。移行とテスト、教育、運用設計も含みます。

別料金になる作業や、追加対応の条件も見積の時点で確かめます。

Runner・クラウド・保守の継続費用

継続費は、Hosted Runnerの料金、料金改定、self-hosted Runnerの運用費に分けて見ます。

Linux：標準2-coreは0.006米ドル/分
Windows：2-coreは0.010米ドル/分
macOS：3〜4-coreは0.062米ドル/分（出典：GitHub公式「Actions runner pricing」、2026年）
料金改定：2026年1月1日に最大39％値下げ。0.002米ドル/分の課金は延期
設備・運用：VM、物理サーバー、OSライセンス、ディスク、通信、監視、保守、Runner交換

料金は、ジョブごとに分単位へ切り上げられます。そのため、月間の実行分数をOSや並列数ごとに集計しておきます。

GitHubのプランやActionsストレージ、Packagesは、別途加算します。クラウドとネットワークの費用も、別に積み上げます。

料金方針は変わる可能性があるため、契約の直前に公式の料金表を確認します。改定時の扱いも、見積書に明記します。

この課金延期はGitHub Changelog「Update to GitHub Actions pricing」（2025年12月）で発表されています。

self-hosted RunnerのOSやソフトウェアの更新は、利用者が担います。保守費は、初期費用の年15〜25％程度、または月額5万〜30万円程度から比べ、対応時間と作業範囲を確かめます。

ポイント

初期費用は規模と導入範囲で変わるため、リポジトリ数や既存環境をそろえてから比べます。Runnerやクラウドの継続費は、初期費用と分けて試算します。

委託先の選定と見積比較の観点

提案から契約後の運用まで、確認点を一続きで捉えられます。

委託先は、GitHubの販売実績だけでなく、CI/CDやクラウド、IaCの経験で比べます。セキュリティや教育、運用保守の力も、あわせて確かめます。

ライセンス販売会社が、複雑なWorkflowやRunnerを経験しているとは限りません。アプリ開発会社も、Enterprise設計や監査に対応できるとは限らないため、案件に必要な専門性を分けて確かめます。

実績の確認（構成と担当範囲）

導入実績の有無だけで終わらせず、構成と担当範囲を確かめます。

構成・担当：リポジトリ数、言語、CI移行、Runner方式、クラウド、OIDC、承認
導入後：セキュリティ審査、保守、内製化、標準化、復旧、改善事例
成果：テスト品質、失敗率、リードタイム、復旧時間、担当者負担の変化

可能であれば、設計書の目次も確かめます。同じ業界でなくても、個人情報や閉域網を扱った経験は、自社に応用できる場合があります。監査や承認、24時間運用の経験も、参考になることがあります。

見積項目と前提条件の比較

各社へ同じ前提を渡し、費用と対象範囲をそろえて比べます。

共通資料：RFP、リポジトリ一覧、サンプルWorkflow、クラウド構成、希望日程
見積内訳：調査、要件定義、設計、実装、Runner、移行、テスト、教育、保守
総保有コスト：3年間程度の契約、実行、保守、更新、追加リポジトリ、教育

人月や作業時間、数量が分かれば、金額差の理由を確かめやすくなります。単価、前提、除外項目も、あわせて見ます。

総保有コストには、GitHub契約やRunner実行分数、ストレージを含めます。さらに、クラウドや監視、脆弱性対応も入れます。

見積の金額が安くても、セキュリティレビューやRunbook、テスト自動化が含まれない場合があります。引き継ぎや障害対応も入っていないことがあるため、除外項目を必ず確かめます。

提案面談の質問（障害時と引き継ぎ）

提案面談では、障害時の対応と契約後の引き継ぎを確かめます。

障害の想定：テスト失敗、Runner停止、認証切れ、Action脆弱性、誤デプロイ、GitHub障害
初動：一次切り分け、確認ログ、手動リリースやロールバックの条件、報告時間
引き継ぎ：Workflow、Secrets、Runner、SHA、利用量、再実行を自社で扱えるか

引き継ぎは、最終日に資料を渡すだけでは足りません。操作を一緒に行い、自社の担当者が自力で変更できるかを確かめます。

内製化が目的なら、教育費と引き継ぎ期間も見積に含めておきます。

ポイント

委託先は、GitHubの販売実績だけでなく、CI/CDや運用の経験で比べるのが目安です。見積は同じ前提で並べ、除外項目と引き継ぎの範囲の差を見ます。

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

費用や技術のほか、自社の運用体制や契約後の責任分界について、発注前によくある疑問を取り上げます。

GitHub ActionsのWorkflowだけを外注できますか？

Workflowだけを外注することもできます。ただし、テストやSecrets、Runnerが未確定だと、納品後に動かない可能性があります。デプロイ先や通知、ロールバックが未確定の場合も、同じ問題が起きるおそれがあります。

対象リポジトリや実行環境、認証方式を整理します。成功条件と保守担当も決め、YAML以外の設定や文書も見積に含めます。

GitHub Actionsの導入はどのくらいの期間がかかりますか？

1〜3リポジトリでテストとstagingデプロイを作る小規模案件は、2〜6週間程度が目安です。

10〜50リポジトリの標準化や既存CI移行を含む場合は、1.5〜4か月程度です。そこに、OIDCや教育、監視が加わることもあります。

Enterprise、self-hosted Runner、全社展開を含む場合は、3〜9か月以上を計画します。期間は、テスト不足や権限調整によって変わります。ネットワーク申請や受入者の確保によっても変動します。

self-hosted Runnerも外注したほうがよいですか？

社内ネットワークなど固有の実行環境が必要なら、self-hosted Runnerの設計・構築を外注する選択肢があります。

検討条件：社内ネットワーク、特殊なビルド環境、機密データ、独自ハードウェア
継続運用：OS・Runner更新、監視、容量、隔離、障害対応の担当と予算

GitHub公式資料では、更新を止めたRunnerは新機能に対応できず、一定期間更新しないとジョブがキューに入らなくなると説明しています。

GitHub Enterprise Cloudでは、Runnerのバージョン要件が2026年に段階的に強化されます。完全適用は、2026年9月25日からの予定と発表されています。

そのため、更新の担当と予算を先に決めておきます（出典：GitHub Changelog「Minimum version enforcement timeline for self-hosted runners」、2026年6月）。

相見積もりは何社に依頼すると比較しやすいですか？

同じ条件のRFPを渡せるなら、2〜3社程度へ依頼すると比較しやすくなります。ライセンスやCI/CD、クラウドの範囲をそろえます。セキュリティと保守の範囲も、そろえておきます。

見積の前提と除外項目を確かめたうえで、選びます。判断材料は、要件理解や担当者の経験、障害対応です。さらに、成果物、引き継ぎ、将来費用も見ます。

まとめ

発注前に確認するポイントの一覧

対象リポジトリや現行CI、デプロイ先を一覧にします。Runner方式や認証、受入条件を加えます。納品物と保守範囲も書き込みます。

提案を受けたあとは、対応の可否と追加費用、発注者側の準備を確かめます。そうすることで、契約後の手戻りを減らせます。

小さなPoCから始める外注

まず小さなPoCで自社運用できる状態を目指し、結果を踏まえて発注範囲を広げます。

PoC：1〜3リポジトリでPull Requestの品質ゲートとstagingデプロイを試す
評価：効果、課題、追加費用、内製へ移せる範囲、運用負担を記録する
要件・契約：RFPに目的、受入条件、認証、Runner、セキュリティ、責任分界を記す。工程に応じ請負・準委任・内製併用を選ぶ
比較・選定：利用料や保守を含む総保有コストと、CI/CD、クラウド、セキュリティ、内製化支援を比べる

対象を広げる前に、外注範囲を確定しておきます。GitHub契約やWorkflow、Runnerのほか、認証、デプロイ、監査も範囲に入れます。さらに、通知や保守、教育も外注範囲に含めるかを決めます。

第三者ActionのSHA固定や最小権限、OIDCを委託先に確かめます。Environment承認とRunner更新、ロールバックについても、確認しておきます。

契約終了時のアカウントとSecrets整理まで確かめておくと、特定の人への依存や、予期しない追加費用を抑えやすくなります。

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

▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
 ・スクラッチシステム開発の完全ガイドブック
 ・【2026年最新版】AI駆動開発の完全ガイドブック

会社紹介

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

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

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

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

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

執筆者プロフィール

張田谷凌央

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