GitHubのシステム開発は、対象範囲を切り分け、要件と契約を整理してから発注するのが基本の流れです。
小規模なPoCから段階的に展開すると、発注後の手戻りを抑えやすくなります。
▼全体ガイドの記事
・GitHubのシステム開発の完全ガイド
・業務システム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「業務システム開発の完全ガイドブック」で詳しく解説しています。
・スクラッチシステム開発を依頼する会社の選び方やRFPの作り方については、無料ホワイトペーパー「スクラッチシステム開発の完全ガイドブック」で詳しく解説しています。
GitHubのシステム発注・外注の全体像
「GitHubのシステム」には、GitHubを開発基盤として使うケースと、GitHubと連携する業務システムを作るケースがあります。対象を切り分けると、どこまでを依頼するかや、見積もりを比べる軸がはっきりします。
GitHubの位置づけと開発基盤としての役割
GitHubで管理するのは、Gitリポジトリ、ブランチ、Pull Request、Issues、Projectsです。さらに、Actionsのワークフロー、パッケージ、脆弱性情報も管理対象に含まれます。
顧客向け画面や業務データベース、独自の承認画面は、別途アプリとして設計・開発します。帳票や外部サービスとの業務連携も、同じ扱いになります。そのため、RFPでは「GitHubの設定・移行」と「業務システムの開発」を分けて記載します。
発注前に決める目的と成果指標
目的は、開発リードタイム、レビュー実施率、リリース頻度などの指標に置き換えて決めます。脆弱性の修正時間や障害からの復旧時間も、指標の候補になります。
同じGitHubの導入でも、目的によって必要な設計と費用は変わります。たとえば、レビュー漏れの削減、SVNや社内Gitサーバーからの移行、手動リリースのActions自動化では、作業の中身が違います。
目的を決めないまま機能の一覧だけで発注すると、使われない設定や過剰な権限設計に予算を使うおそれがあります。
GitHubの発注形態の選び方
発注形態は、開発会社にどこまで責任を持ってもらうかで選びます。初期設定だけなら導入支援、業務アプリまで作るなら受託開発、継続的にチームを補うなら準委任やラボ型が候補です。
1社にすべてを任せる方法にも利点はあります。ただし、ライセンス販売、基盤構築、アプリ開発、運用保守を同じ会社が担当するとは限りません。そのため、どの会社が何を受け持つかを見積書で確認しておきます。
導入支援として発注するケース
10〜20人程度のチームで、GitHubの基本設定と開発プロセスの標準化を依頼する場合に適しています。なお、既存の業務アプリは作り替えません。
- 権限と保護：組織・リポジトリ・チーム権限、ブランチ保護の設定
- 開発ルール：Pull Requestのテンプレート、CODEOWNERSの設定
- 自動化と定着：Actionsの標準ワークフロー、試行、管理者研修
現状調査から研修までを一つのパッケージにし、運用開始後の質問対応は別契約にする方法もあります。
受託開発として発注するケース
顧客ポータル、申請システム、開発状況ダッシュボードなど、独自画面やデータ処理を作る場合は受託開発が合っています。
成果物と納期を固定しやすい一方、要件追加や仕様変更が多いと金額とスケジュールが膨らみます。
基本設計には、GitHub API、Webhook、GitHub Appsの選択が含まれます。さらに、APIのレート制限や障害時の再送も対象にします。
準委任・ラボ型で発注するケース
移行対象や改善テーマが多く、優先順位を毎月見直す場合は、準委任やラボ型で開発チームを確保できます。
優先順位は発注側が決め、受託側がGitHub管理者、DevOpsエンジニア、アプリ開発者などを配置します。
費用は稼働時間に応じて発生します。完成機能を一括で納品する契約とは責任の置き方が異なるため、契約には成果物と品質基準を書き、報告方法と交代時の引き継ぎも記載しておきます。
RFPと要件整理の準備範囲
RFPは、開発会社に同じ条件で提案と見積もりを依頼するための文書です。完成した仕様書でなくても構いません。
まずは課題、対象ユーザー、現行環境を示します。そのうえで、希望時期や予算の考え方、発注範囲、提案事項も揃えます。
GitHubの選定だけでなく、業務アプリと開発基盤の境界も明記しておきます。境界をそろえて示すと、各社の提案を同じ前提で比べられます。
RFPに書く基本情報
背景と目的、対象部門、利用者数を記載します。加えて、対象業務、現行Git環境、移行元を示します。さらに、リポジトリ数と容量、履歴の必要性、連携先も書いておきます。
CloudかServerか決め切れていなくても、受託側から比較案を得られます。その際、データ所在地、閉域接続、社内認証を示し、バックアップと運用体制も伝えます。
GitHub固有の要件
要件に含めるGitHubの設定は、分野ごとに整理します。
- 組織と権限：組織・リポジトリ、チーム権限の定義
- 認証：SAML SSO・SCIM、管理者の多要素の設定
- レビュー：ブランチ保護、必須の承認、CODEOWNERSの決定
- 自動化と安全性：Actionsの実行環境、シークレット、Dependabot、CodeQL、監査ログの定義
GitHub ActionsはPull RequestやIssueなどをきっかけに、ビルド・テスト・デプロイを自動化します。
GitHub公式資料には、ホストランナーとセルフホストランナーの選択肢があります。処理を実行するネットワークもRFPに書いておくと、追加費用を抑えやすくなります。
受け入れ条件と非機能要件
受け入れ条件は、設定が終わったかではなく、安全に使える状態かを基準に定めます。たとえば、代表チームによる作成、レビュー担当者の自動指定、テスト失敗時の本番デプロイ防止などを確認します。
退職者のアカウント停止時間や、監査ログの確認可能期間も合格条件にします。非機能要件では、可用性、復旧目標、ログ保存期間も明記します。障害時の連絡時間と脆弱性対応期限も、書いておきます。
GitHubの外注における契約形態と役割分担
契約形態によって、受託側の責任と発注側の関与が変わります。そのため、契約書の名称だけでなく中身を確認します。
見るのは、成果物、検収、仕様変更、知的財産の扱いです。さらに、再委託、秘密情報、脆弱性対応、保守範囲も確認します。
GitHubのアカウントやリポジトリの所有者と、契約終了後の管理者は、あらかじめ決めておきます。
請負契約で固定の成果物を委託する場合
請負契約は、合意した成果物を完成させ、検収を受ける契約です。成果物には、初期設定、移行スクリプト、Actionsなどがあります。設計書や運用手順書を納品する案件にも適しています。
要件が固まっていないと、変更のたびに追加見積もりや納期変更が生じます。そのため、検収環境とテストデータは先に合意しておきます。検収期間と軽微な不具合の扱いも、あわせて決めておきます。
準委任契約で継続的に改善する場合
準委任契約は、専門業務を一定期間遂行してもらう形態です。移行対象を調査しながら優先順位を変える場合や、管理者とアプリ開発者を継続配置する場合に適しています。
請負と同じ完成責任は期待せず、業務遂行の定義を文書にします。文書には、月次稼働時間、担当者、定例会を記載し、さらに成果報告と品質指標を定めます。未消化タスクと終了時の引き継ぎも決めておきます。
ソースコードと権利の引き渡し
委託費を支払っても、ソースコードや著作権が自動で移るとは限りません。IaCやActions設定、設計書は、どこまで渡るかを確かめます。テストコード、監視設定、手順についても、渡す範囲を確認します。
契約には、発注側Organizationへの配置と管理者を書きます。納品形式と第三者ライブラリのライセンスも記載します。さらに、著作権法第27条・第28条の権利と共通部品の扱いも明記します。
GitHubのライセンス契約と開発委託契約は別々の契約なので、両方を確認します。
GitHubのシステム開発にかかる費用相場と内訳
費用は、ライセンス、初期設定・移行、業務アプリ開発を分けて考えます。さらに、CI/CD・セキュリティ、教育・運用保守も別の項目として見ます。公式料金と導入支援の相場は別物なので、ライセンス価格だけで予算を決めないようにします。
以下の支援額は、NotebookLMのリサーチノートにある業務システム一般の相場と、GitHub移行・認証・Actions構築の類似案件からの推定です。GitHub公式の一律導入価格ではありません。
ライセンス費用の試算
GitHubのライセンスとCopilotは、席数に応じた料金と利用量課金を確認して試算します。
- GitHub Team：1ユーザー月額4米ドル（出典：GitHub公式料金ページ、2026年8月確認）
- GitHub Enterprise：1ユーザー月額21米ドル（出典：GitHub公式料金ページ、2026年8月確認）
- Enterpriseの試算：10人で月3.15万円、50人で月15.75万円、100人で月31.5万円
- Copilot：Businessは1ユーザー月額19米ドル、Enterpriseは1ユーザー月額39米ドル
- AIクレジット：組織・Enterprise向けの使用量課金
GitHub公式資料では、含まれるクレジットを超えた利用は追加料金の対象です（出典：GitHub公式「About billing for GitHub Copilot in organizations and enterprises」、2026年8月確認）。
円換算は1米ドル150円とし、税・割引・為替変動を含めない単純試算です。
Enterpriseの金額は席数分の基本料金です。実際の請求額は、代理店契約や最低購入数で変わります。サポートや追加製品も、請求額に影響します。
発注時には、席数と対象者を決めておきます。利用モデルとAIクレジットの上限も押さえます。予算アラートと利用ログの確認方法も、あわせて決めます。
導入・移行・構築支援の相場
導入支援の費用と期間は、規模や移行範囲によって異なります。
- 小規模：PoC・運用ルール策定・10〜20人の初期設定は推定50万〜150万円、2〜4週間
- 中規模：移行・認証連携を含む支援は推定150万〜500万円、1〜3か月
- 全社展開：50〜200人で複数組織等を整える場合、推定300万〜1,000万円、3〜6か月
- 大規模・複雑構成：推定1,000万〜3,000万円以上、6〜12か月となる場合がある
中規模支援には、GitHub.comや他のGitサーバーからの移行、SAML・SCIM、リポジトリ設計が含まれます。さらに、ブランチ保護やGitHub Actionsの標準テンプレート、管理者研修も対象です。
大規模支援は、Enterprise Serverやハイブリッド、数百人規模の移行を含む場合の目安です。ネットワーク分離や冗長化も、この範囲に入ります。監査やバックアップも含まれます。
いずれも公開定価ではありません。金額は、リポジトリ数や履歴容量で変わります。対象チーム数や移行リハーサルの回数でも変わります。
50〜200人規模の全社展開では、複数組織に加えて、既存のCI/CD、クラウド、チケット管理を整えます。そこにはセキュリティ基準への対応も含まれます。
これらを予算の上限と決めつけず、複数社に同じ前提条件で内訳を依頼します。
見落としやすいランニングコスト
Codespacesは計算リソースが0.18米ドル／時間から、ストレージが0.07米ドル／GB／月からです（出典：GitHub公式料金ページ、2026年8月確認）。
追加費用は、利用量に応じるもの、基盤に関するもの、運用と安全対策に関するものに分けて考えます。
- 利用量に応じる費用：Actions、ログ・成果物、Codespaces
- 基盤の費用：セルフホストランナー、コンテナレジストリ、外部クラウド
- 運用・安全対策：監視、バックアップ、Advanced Security
これらは別費用になり得るため、月次の利用量を誰が監視するかも見積書に記載します。
保守運用では、障害対応に加えて、アカウント管理と権限の見直しが続きます。さらに、ルール変更、依存アクションの更新、脆弱性対応も必要です。ログ確認、教育、問い合わせ対応も、保守の作業に含まれます。
業務システム一般では初期費用の年15〜25％程度を保守運用費の目安とする考え方があります。GitHubの管理範囲やSLAで大きく異なるため、相場とは決めつけず、対応時間と作業項目に分けて見積もります。
GitHubの委託先選定と見積比較のポイント
委託先は、ライセンス販売だけでなく、依頼範囲を実装し、運用まで任せられるかで選びます。導入専門会社や国内代理店、DevOpsに強いSIerのように、委託先の種類によって得意な領域は異なります。業務アプリの受託会社も、得意とする範囲はそれぞれ異なります。
公開情報のある窓口として、マクニカやJTPがあります。システムサポートやCTCも候補です。社名だけで優劣は決めず、担当者の経験と提案範囲を確かめます。
実績の確認：会社名ではなく担当範囲
CloudとServerの別や、移行元を質問します。移行したリポジトリ数とユーザー数も確かめます。SSO・SCIMと、Actions・セキュリティの対応範囲も聞きます。
旧環境、採用構成、移行期間を、匿名化した事例で示してもらいます。加えて、利用部門、課題、運用支援の内容も提示を求めます。最後に、公開事例と今回の担当エンジニアの経験を照合します。
同じ作業単位での見積書比較
見積書は一式表示を避け、作業の内訳を揃えます。そうすると、金額差の理由を確認できます。
- 調査・設計：現状調査、要件定義、設計、アカウント設計
- 構築・移行：リポジトリと履歴の移行、Actions実装、テスト、リハーサル
- 定着・運用：教育、文書、リリース支援、保守
ライセンスと作業は、別の行に分けます。クラウドと従量費は、独立した行で示してもらいます。交通費、税、オプションも、分けて書いてもらいます。
たとえ安く見えても、移行テストや引き継ぎが抜けていると、後から別費用がかかることがあります。
提案デモでの異常系と引き継ぎの確認
デモでは、まず正常動作を見ます。そのうえで、権限不足やレビュー未完了、テスト失敗を確かめます。さらに、秘密情報検出、外部API障害、デプロイのロールバックも見ておきます。
GitHubを発注側と受託会社のどちらのOrganizationに置くかも、確認しておきます。発注側が所有して必要な権限だけを渡しておけば、契約終了時の移管やロックインのリスクを抑えられます。
GitHubの発注から運用開始までの進め方
まずは目的とKPIを決めた小規模なPoCから始め、標準ルールを作ったうえで段階的に展開します。導入・移行と業務アプリ開発を並行する場合は、意思決定者を明確にしておきます。
受託範囲が広いほど、発注側でプロダクト責任者と技術責任者を置くことが、成功の条件になります。
代表チームでのPoC
最初の4〜8週間は、代表チームのリポジトリで試します。権限、ブランチ戦略、Pull Requestを確かめます。さらに、Actionsと脆弱性検出を試し、通知と監査ログも見ます。
合格条件は、設定が終わったことではなく、開発者が迷わず使え、レビューとテストが定着し、失敗時に復旧できることです。
GitHubチャンピオンを置き、FAQと操作手順を整えておくと、全社展開時の問い合わせを減らせます。
移行リハーサルと本番切り替えの分離
移行前には、リポジトリ、ブランチ、タグ、コミット履歴を洗い出します。Pull Request、Issue、Wikiも対象です。さらに、Actionsの秘密情報、Webhook、パッケージ、権限も確認します。
サンプルでリハーサルを行い、所要時間と欠落データを確認します。停止時間やロールバック方法も確かめてから、本番へ進みます。
旧環境は、すぐに削除せず、一定期間は読み取り専用で残します。そうすると、利用者が必要な履歴を確認できます。
運用設計と定着の発注範囲
運用では、アカウントのライフサイクルと権限の見直しを定期的に行います。リポジトリの申請やActionsの変更審査も、同じ運用の中で管理します。さらに、秘密情報、脆弱性、監査ログ、バックアップと復旧訓練も定期管理の対象です。
保守委託では、一次受付と調査、修正の時間をSLAに定めます。緊急対応と報告の時間も、SLAに含めます。
社内で引き取る場合は、研修と設定一覧、手順を納品物に含めます。トラブル対応と設計判断の記録も、納品物として求めます。
GitHubのシステム発注・外注でよくある質問
発注の前によく出る質問には、料金、開発基盤の所有権、業務アプリとの境界があります。移行と運用の責任範囲も、よく質問されます。
GitHubのライセンス購入だけを外注できますか？
外注できます。販売代理店や導入支援会社には、プランの選定や契約窓口を相談できます。ユーザー数の設計、請求、初期設定も、相談の対象になります。
ライセンスを購入しただけでは、作業は完了しません。権限設計や移行、Actionsの構築が残り、セキュリティ、教育、運用も必要です。そのため、必要な作業は別項目として見積もります。
GitHub Enterprise CloudとServerはどちらを選ぶべきですか？
CloudとServerは、運用負担、統制範囲、データの保存地域を比べて選びます。
- Cloud：インフラ運用を軽くして早く展開したい場合に候補
- Server：ネットワークやデータ配置を自社基準で細かく統制したい場合に候補
- Cloudの国内提供：2025年12月にデータレジデンシーを一般提供（出典：GitHub公式Changelog、2025年12月18日）
- 保存地域：コードやリポジトリを置く地域を選べます
関連データのすべてが国内に限定されるとは限りません。請求、サポート、テレメトリは、法務・情報システム部門と確認します。Copilotや連携サービスについても、同じ部門と確かめます。
GitHubのシステム開発費用はどのくらいですか？
ライセンスはユーザー数に応じた月額です。10〜20人の小規模PoCは、推定50万〜150万円程度です。この金額には、初期設定、移行、Actionsに加え、セキュリティと教育も含まれます。
移行や認証連携を含む中規模導入は推定150万〜500万円程度、50〜200人の全社展開は推定300万〜1,000万円程度になることがあります。
これらは公式の定価ではありません。金額を比べるには、対象人数とリポジトリ数、移行元を揃えます。要件と保守範囲も同じ条件にして、相見積もりを取ります。
ソースコードは発注先のGitHubに置いても問題ありませんか？
発注先のGitHubに置く場合も、保管先を誰が管理するかを先に決めておくことが大切です。契約と情報管理の面で確認する点は、次の4つです。
- 配置先と権限：発注側のGitHub Organizationに置き、委託先へは必要なアクセス範囲だけを渡す形
- 委託先Organization：使う場合の移管、バックアップ、管理者、再委託先、データ削除、インシデント通知の取り決め
- 秘密情報：顧客情報やAPIキーをコードに保存せず、管理機能や外部の管理の利用
- 個人情報：取り扱いと海外移転の該当性、法務担当との確認
まとめ
GitHubのシステム開発では、開発基盤と別途作る業務アプリを切り分けます。そのうえで、目的に合う発注形態を選びます。RFPには現行環境、ユーザー数、移行範囲を記載し、認証、CI/CD、セキュリティ、受け入れ条件も書き添えます。
ライセンス・作業費・運用費を分けた予算化
費用は、ライセンスの月額だけでは判断しません。移行や設計、Actionsの作業費を分けて、内訳で比べます。さらに、セキュリティと教育、監視とバックアップ、保守の費用も確認します。
相場は案件の条件によって変わります。推定額をそのまま発注額とはせず、同じ条件での見積もりと、追加費用が発生する条件を確認します。
Copilot、Actions、Codespacesなどの従量費は、利用量に応じて変わります。そのため、利用量と予算上限を先に決めておきます。
所有権と運用の引き継ぎの確認
引き継ぎを見据えて、委託先の技術範囲、成果物の所有、PoC後の展開方針を合わせて確認します。
- 担当範囲：移行、認証、CI/CD、セキュリティ、業務アプリ連携の経験の有無
- 所有と納品：Organization、コード、IaC、設定、設計書、テスト、手順書、教育を、自社で引き継げる形にすること
- 段階展開：小規模PoCでKPIと合格条件を検証し、標準化後に展開
▼全体ガイドの記事
・GitHubのシステム開発の完全ガイド
▼RFP作成前に読みたい無料ホワイトペーパー
・業務システム開発の完全ガイドブック
・スクラッチシステム開発の完全ガイドブック
・【2026年最新版】AI駆動開発の完全ガイドブック
会社紹介
株式会社riplaでは、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを、構想策定・要件定義から開発・改善まで一気通貫で支援。事業会社でIT・DXを経験したプロフェッショナルによる高い要件定義力・システム設計力を活かし、事業成果の最大化に伴走します。
また、当社独自の開発テンプレート「Boxシリーズ」による標準機能の高速開発と、AI駆動開発の独自フレームワーク「GoDD」による独自機能のAI実装を組み合わせることで、低コスト・短期間で開発を実現いたします。
もし、システム開発やプロダクト開発に関するご要望がございましたら、お気軽にお問い合わせください。
・サービス概要資料のURLはこちら >>>
・お問合せページのURLはこちら >>>
・お役立ち資料のURLはこちら >>>
株式会社ripla 代表取締役CEOとして、システムパッケージ活用、システム開発、データ分析、生成AI活用、SaaS開発、アプリ開発、EC構築など、幅広い領域で企業のDX推進と事業成長を支援している。事業会社でIT・DXを経験したプロフェッショナルが集う株式会社riplaにおいて、お客様の事業・ユーザー・業務に最適化したオーダーメイド型システムを構想策定・要件定義から開発・改善まで一気通貫で支援し、単なるシステム納品にとどまらず、クライアントと同じ目線で事業成果の最大化に向けた伴走支援を行う。早稲田大学卒業後、ラクスル株式会社、LINEヤフー株式会社にて事業開発やDX推進などに従事した後、株式会社riplaを創業。