AI駆動開発を安全に始める｜GitHub Copilot × Azure で作る開発基盤
AIがコードを書くことが当たり前になりつつある今、問われているのは「AIをどう使うか」よりも、「AIが書いたコードを、どう安全に本番へ届けるか」です。
実装はAIエージェントに任せ、人はレビューと承認に集中する。できたコードは、シークレットを保存しない仕組みで Azure へデプロイする。AI駆動開発は、ツールを入れることではなく、開発の進め方と基盤を設計することです。
本記事では、GitHub Copilot（AIエージェントとコードレビュー）、GitHub Actions、Azure を組み合わせた開発基盤について、仕組み・組み込みの安全策・構成・情報システム部門が確認したい統制のポイントを、弊社がお客様へのご提案で使用している資料をもとに、GitHub と Microsoft の公式情報で裏付けながら解説します。
目次
- AI駆動開発とは｜「AIに補完させる」から「AIに任せてレビューする」へ
- Copilot cloud agent の仕組み｜Issue を任せ、人はレビューと承認に集中する
- 推奨アーキテクチャ｜計画から本番運用まで、AIとセキュリティを組み込む
- GitHub Actions から Azure へ｜OIDCで「保存するシークレット」をなくす
- ランナーの選び方｜まず標準構成で試し、本番の要件に応じて閉域化する
- 情報システム部門が確認したい統制のポイント｜ID・学習への利用・データの保存場所
- GitHub と Azure DevOps の使い分け｜AIエージェントを中心に据えるなら、コードは GitHub に
- 導入の進め方｜小さく試して、測ってから広げる
- 弊社の支援｜ID・ネットワーク・デプロイの経路まで、一貫して設計する
- よくあるご質問
株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ Microsoft 365・Azure の導入支援と、AIの業務活用（AIプライベート）の支援を提供しているIT企業です。
本記事の全体像を1枚にまとめると、次のとおりです。
AI駆動開発とは｜「AIに補完させる」から「AIに任せてレビューする」へ
AI駆動開発とは、AIを開発の工程そのものに組み込み、実装・テスト・レビューの一部をAIが担う開発の進め方です。ソフトウェア開発は、人がすべてのコードを書く時代から、AIがコードの補完やチャットで支援する時代を経て、AIエージェントが実装からテスト、プルリクエスト（PR）の作成までを担い、人は要件の定義とレビューに集中する時代へと移りつつあります。
Gartner は、2028年までに企業のソフトウェアエンジニアの75%がAIコードアシスタントを使うようになると予測しています（2023年初頭は10%未満）。GitHub の Octoverse 2025 では、新しく GitHub に登録した開発者の約80%が最初の1週間で Copilot を使っていること、Copilot のコーディングエージェントが2025年5月から9月までに100万件を超えるPRを作成したことが報告されています。国内では、経済産業省の2019年の調査で、2030年のIT人材の需給ギャップが最大で約79万人に広がると試算されています。
開発組織が抱える課題と、従来の開発フロー
AI駆動開発が求められる背景には、開発組織に共通する課題があります。開発速度・属人化・品質・人材不足の4つは互いに連鎖し、その根本には「開発のプロセスの多くが、人の手作業と個人の経験に依存している」ことがあります。
従来の開発フローでは、定型的な実装に工数が取られ、テストが後回しになり、レビューが有識者に集中して滞留しがちです。レビューでの指摘や仕様の認識違いによる手戻りが、リリースまでの期間を押し延ばします。
GitHub Copilot とは
GitHub Copilot は、GitHub が提供するAIの開発支援サービスです。現在はコードの補完にとどまらず、エディターから Pull Request まで、開発の流れ全体に関わる機能をそろえています。
| 機能 | できること | 主な使いどころ |
|---|---|---|
| Copilot Chat | エディターや GitHub 上で、コードの説明、設計の相談、不具合の調査を対話で行う | 既存コードの理解、新しいメンバーの立ち上がり |
| エージェントモード | 開発者の手元のエディターで、複数のファイルにまたがる変更を、AIと対話しながら進める | 手元での改修や機能追加 |
| Copilot cloud agent | Issue などで依頼すると、GitHub Actions 上の一時的な開発環境で実装・テストを行い、PRを作成する | 定型的な実装・改修、テストの追加 |
| Copilot コードレビュー | PRをレビューし、指摘と修正案をコメントする。承認の件数には数えられない | レビュー待ちの短縮、レビュー観点のばらつきの抑制 |
このうち、AI駆動開発の中心になるのが Copilot cloud agent です。以前は「Copilot coding agent」と呼ばれていた機能で、2026年4月時点の GitHub の公式ドキュメントでは Copilot cloud agent の名称で案内されています。有償の Copilot プランで利用でき、Copilot Business／Enterprise では管理者が有効にして使います。
公開されている調査結果の読み方
GitHub が2022年に公開した対照実験（95人）では、Copilot を使った開発者は同じ課題を平均1時間11分で終え、使わなかった開発者（2時間41分）より55%速かったと報告されています。また、GitHub と Accenture による2024年の調査では、成功したビルドの数が84%、PRのマージ率が15%増えたと報告されています。いずれも条件を定めた調査の結果で、どの組織でも同じ効果が出ることを示すものではありません。自社のコードと体制で、小さく試して測るのが確実です。
Copilot cloud agent の仕組み｜Issue を任せ、人はレビューと承認に集中する
Copilot cloud agent では、人が Issue にやりたいことを書いて Copilot に割り当てると、AIエージェントが GitHub Actions 上の隔離された一時的な環境でリポジトリを調べ、実装計画を立て、ブランチを作ってコードを書き、テストやリンターを実行して、変更内容を説明したPRを作成します。人が関わるのは、最初の「依頼」と最後の「レビュー・承認」です。
依頼は Issue への割り当てのほか、GitHub.com のエージェント用の画面、Visual Studio Code、既存のPRへのコメント（@copilot）、Azure Boards の作業項目などから行えます。Microsoft Teams や Slack からの依頼は、2026年4月時点ではプレビューとして提供されています。
組み込みの安全策
AIエージェントに実装を任せるうえで気になるのが、「AIが書いたコードが、確認されないまま本番に入らないか」という点です。GitHub の公式ドキュメントでは、次のような安全策が説明されています。
| 観点 | 内容（2026年4月時点の公式ドキュメント） |
|---|---|
| 依頼できる人 | リポジトリへの書き込み権限を持つユーザーだけが、Copilot に作業を依頼できる |
| 書き込めるブランチ | push できるのは1つのブランチだけ。新しい作業では copilot/ で始まる専用ブランチが作られ、そのブランチにしか書き込めない |
| 承認とマージ | Copilot は自分のPRを承認・マージできない。作業を依頼した本人もそのPRを承認できないため、別の人によるレビューが必要になる |
| CIの実行 | 既定では、書き込み権限を持つユーザーが内容を確認して「Approve and run workflows」を押すまで、ワークフローは実行されない |
| 外部への通信 | インターネットへのアクセスは、組み込みのファイアウォールで制限される |
| 生成したコードの検査 | CodeQL による検査、依存関係の検査、シークレットの検出を行う |
| 追跡性 | コミットは Copilot が作成し、依頼した開発者が共同作成者として記録される。コミットには署名が付く |
このほか、1回の作業は最大59分、対象は依頼したリポジトリの1ブランチ・1つのPRに限られます。リポジトリに設定したルールによっては Copilot が作業できない場合もあるため、ブランチ保護やルールセットとの組み合わせは事前に確認しておきます。
活用イメージ｜「顧客一覧のCSV出力」を任せる
Java（Spring Boot）の業務システムに「顧客一覧をCSVでダウンロードしたい」という機能を追加する場面を例にすると、流れは次のようになります。人は受け入れ条件を書いた Issue を作り、Copilot が既存コードを調べて実装計画を立て、実装とテストを行い、PRを出します。PRではビルド、単体テスト、CodeQL による検査、Copilot のレビューが自動で走り、最後に人が承認してマージします。
図中の所要時間は弊社が想定した目安で、機能の規模、コードベース、レビューの方針によって変わります。実際の効果は、PoCで実測して評価します。
弊社の見立て
AIエージェントの成果を左右するのは、依頼の書き方です。Issue には「何を作るか」だけでなく、受け入れ条件（出力形式、件数の上限、追加すべきテストなど）を具体的に書きます。チームのコーディング規約やレビューの観点は、リポジトリの指示ファイル（.github/copilot-instructions.md）にまとめておくと、AIの出力とレビューの基準をそろえやすくなります。
推奨アーキテクチャ｜計画から本番運用まで、AIとセキュリティを組み込む
AIエージェントを開発に組み込む基盤の全体像です。Microsoft Entra ID で開発者のIDを統合し、GitHub Enterprise Cloud 上で計画から Issue、Copilot による実装、PRでのレビュー、GitHub Actions による自動化までを進めます。PRのたびに、AIレビュー、CodeQL、シークレットの検出、Dependabot、ルールセットといった品質とセキュリティのゲートを通し、OIDC で認証して Azure の開発・検証・本番の各環境へデプロイします。運用で得た監視やアラートは Issue に戻し、継続的な改善につなげます。
図の「データレジデンシー：日本」は、コードやリポジトリのデータを日本に保存する GitHub Enterprise Cloud の形態（GHE.com）を指します。Copilot の処理がどこで行われるかは別の論点のため、後述の「統制のポイント」で補足します。
Azure 側で、開発者が必要な環境を申請から払い出し・変更管理まで統制された形で使えるようにする考え方は「Azureのインフラ払い出しをセルフサービス化する」で解説しています。
GitHub Actions から Azure へ｜OIDCで「保存するシークレット」をなくす
AIがコードを書く量が増えるほど、デプロイの経路の安全性が重要になります。従来は、Azure にデプロイするためのクライアントシークレットを GitHub の Secrets に保存する方式が一般的でした。この方式では、長期間有効なシークレットを管理し、期限切れの前に定期的に更新し続ける必要があります。
Microsoft が案内しているのが、OpenID Connect（OIDC）によるワークロード ID フェデレーションです。GitHub Actions のワークフローが GitHub から受け取ったトークンを Microsoft Entra ID が検証し、Azure にアクセスするためのトークンを発行します。デプロイのために保存しておくシークレットは不要になります。
設定する項目は次のとおりです。
| 設定する場所 | 内容 |
|---|---|
| Microsoft Entra ID | Entra ID のアプリ、またはユーザー割り当てマネージド ID に、フェデレーション資格情報を追加する。発行者は https://token.actions.githubusercontent.com、audience は既定値の api://AzureADTokenExchange |
| Azure のアクセス権 | 上記のアプリ（またはマネージド ID）に、デプロイ先に必要な範囲だけの Azure RBAC ロールを割り当てる |
| GitHub Actions のワークフロー | ジョブに id-token: write の権限を与え、azure/login アクションにクライアント ID・テナント ID・サブスクリプション ID を渡す（いずれも秘密の値ではない） |
信頼する範囲は、フェデレーション資格情報の subject で決まります。GitHub Actions では、次のような形式になります。
| ジョブの種類 | subject の例 |
|---|---|
| 環境（environment）に紐づくジョブ | repo:org/repo:environment:production |
| ブランチで起動するジョブ | repo:org/repo:ref:refs/heads/main |
| PRのイベントで起動するジョブ | repo:org/repo:pull-request |
設定でつまずきやすい点
subject は完全一致で、ワイルドカードは使えない
ワークフローの設定と1文字でも違うと、トークンの交換に失敗します。- 間違っていても、作成時にはエラーにならない
フェデレーション資格情報は誤った値のまま作成でき、実際にデプロイを動かしたときに初めて失敗が分かります。 - 登録できる数に上限がある
1つのアプリ（またはマネージド ID）に登録できるフェデレーション資格情報は、最大20件です。
本番環境へのデプロイは、環境（environment）単位で信頼する設定にし、GitHub の環境に承認者を設定しておくと、「本番の環境で、承認を経たジョブだけがデプロイできる」構成にできます。
ランナーの選び方｜まず標準構成で試し、本番の要件に応じて閉域化する
GitHub Actions のジョブや Copilot cloud agent の作業を実際に動かすのが「ランナー」です。どのランナーを使うかで、運用の手間と、到達できるネットワークが変わります。
標準構成｜GitHub-hosted ランナー
GitHub が管理するランナーを使う構成です。ジョブごとに新しい仮想マシンで実行されるため、ランナーの構築や更新は不要です。デプロイはインターネット経由になるため、Azure 側のサービスは公開エンドポイントのまま、Entra ID の認証、RBAC、アクセス制限で保護します。
閉域構成｜仮想ネットワーク内のランナーから、プライベートエンドポイント経由で
機密データを扱うシステムなどでは、Azure 側のサービスの公開アクセスを無効にし、仮想ネットワーク内のランナーからプライベートエンドポイント経由でデプロイします。ランナーは GitHub への送信通信（HTTPS）だけでジョブを受け取るため、受信ポートを開ける必要はありません。
図は、日本のデータレジデンシー（GHE.com）と Azure の東日本リージョンを組み合わせた構成の例です。ランナーの方式ごとの違いは、次のとおりです。
| 観点 | GitHub-hosted ランナー（標準） | GitHub-hosted ＋ Azure private networking | Self-hosted ランナー（自社管理） |
|---|---|---|---|
| 運用 | GitHub が管理。ジョブごとに新しい仮想マシンで実行される | GitHub が管理 | 自社で構築し、OSの更新や台数の管理も行う |
| ネットワーク | インターネット経由でデプロイ先に接続する | ランナーのネットワークインターフェースが、お客様の Azure 仮想ネットワークに配置される | お客様の仮想ネットワーク内で動かせる |
| 閉域のリソースへの到達 | できない（デプロイ先は公開エンドポイントとアクセス制限で守る） | プライベートエンドポイントや、仮想ネットワークから届く社内のリソースに接続できる | 同左 |
| 主な条件 | — | larger runner（2〜64 vCPU の Ubuntu・Windows）に限られる。対応リージョンに注意 | 構成の自由度は高いが、運用の負担も大きい |
| Copilot cloud agent | 標準の実行環境 | 利用できる（必要な宛先への送信を許可する） | 利用できる。ただし組み込みのファイアウォールは非対応のため、無効にする必要がある |
- 標準のランナーのIPアドレスで許可リストを作らない
GitHub は、標準のランナーのIPアドレスを社内リソースの許可リストに使うことを推奨していません。IPアドレスで制限したい場合は、固定IPを持つ larger runner か、Self-hosted ランナーを使います。 Azure private networking の対応リージョンは、GitHub の利用形態で異なる
2026年4月時点で、GitHub.com で使う場合の対応リージョンには西日本（Japan West）が含まれ、東日本（Japan East）は含まれていません。日本のデータレジデンシー（GHE.com）で使う場合は、東日本・西日本の両方が対応しています。Self-hosted ランナーで Copilot cloud agent を動かす場合は、送信先の制御を自前で用意する
組み込みのファイアウォールを無効にする必要があるため、図のように Azure Firewall などで送信先を制限する設計が必要です。GitHub は、ジョブごとに使い捨てるランナーでの利用を推奨しています。
弊社の見立て
最初から閉域の構成を作り込むと、効果を確かめる前に準備の期間が延びがちです。まずは標準構成で効果を検証し、機密データを扱う本番システムなど、要件に応じて閉域構成へ段階的に移す進め方が現実的です。
情報システム部門が確認したい統制のポイント｜ID・学習への利用・データの保存場所
開発基盤は、ID、認証、権限、パイプライン、ネットワークの各層で守ります。あわせて、AIを業務で使ううえでのデータ保護も確認が必要です。
GitHub のアカウントを、会社のIDで管理する
GitHub Enterprise Cloud の Enterprise Managed Users（EMU）を使うと、GitHub のユーザーアカウントを会社側で作成・管理できます。Microsoft Entra ID と OIDC でシングルサインオンを構成した場合は、Entra ID の条件付きアクセスの設定を GitHub 側でも評価できます。
ただし、GitHub 側で継続的に適用されるのは、条件付きアクセスのうちIPアドレスの条件です。デバイスの準拠状態の条件は GitHub 側では適用されず、多要素認証は Entra ID にサインインする時点で求められます。アプリがユーザーの代理ではなくアプリ自身として行うリクエストは、条件付きアクセスの評価の対象になりません。端末の管理や多要素認証は Entra ID のサインインの段階で確実にかけ、GitHub 側のIP条件と組み合わせて設計します。
業務のコードが、AIの学習に使われないか
GitHub は、Copilot Business／Enterprise の利用者のやり取りのデータを、契約に基づいてモデルの学習に使わないとしています。一方、個人向けの Copilot Free／Pro／Pro+ では、2026年4月24日から、やり取りのデータがモデルの学習に使われるようになりました（設定で拒否できます）。業務で使う場合は、組織で契約したプランに利用を集め、個人のアカウントでの業務利用を統制することが大切です。社内で許可していないAIの利用を見える化し、承認済みのサービスに集める考え方は「増える社内『シャドーAI』を統制する」で解説しています。
コードとデータの保存場所
GitHub Enterprise Cloud には、コードやリポジトリのデータを保存する地域を選べるデータレジデンシーの形態（GHE.com）があり、日本は2025年12月に一般提供となりました。この形態では EMU の利用が前提で、パブリックリポジトリは作れません。
なお、リポジトリのデータを日本に保存することと、Copilot の処理がどこで行われるかは別の話です。Copilot の処理を特定の地域のモデルに限定する機能は、2026年4月に米国とEUで提供が始まり、日本は同年後半に予定されていると案内されています（2026年4月時点）。国内での処理が要件になる場合は、最新の提供状況を確認したうえで設計します。
GitHub と Azure DevOps の使い分け｜AIエージェントを中心に据えるなら、コードは GitHub に
Microsoft の開発基盤には、GitHub と Azure DevOps があります。すでに Azure DevOps を使っている組織では、どちらを軸にするかが論点になります。要件管理やテスト管理は Azure DevOps に強みがある一方、AIの機能は GitHub が先行しています。
図の◎〇△は、弊社の評価です。AIエージェントに実装を任せる開発を中心に据えるなら、コードは GitHub のリポジトリに置くのが前提になります。Azure Boards の作業項目から Copilot にPRの作成を依頼する連携もありますが、対象は GitHub のリポジトリで、Azure Repos には対応していません。一方で、作業管理は Azure Boards のまま使えるため、計画・作業管理の仕組みまで一度に移す必要はありません。既存の資産と運用を踏まえて、段階的に構成を決めるのが現実的です。
導入の進め方｜小さく試して、測ってから広げる
導入は、1つのチームでのPoCから始め、効果を測ってから開発チーム全体、全社へと段階的に広げます。
PoC｜対象のチームと、測る指標を決めて試す
1つのチームと実際の案件を選び、リリースまでの期間、レビュー待ちの時間、後工程での手戻りなど、効果を測る指標と現状の値を決めます。組織で契約した Copilot のプラン、Entra ID と連携したアカウント管理、OIDC によるデプロイ、標準のランナーで環境を用意し、Issue の書き方や指示ファイル、AIが作ったPRのレビューの進め方を試します。- 開発チームへの導入｜標準化と定着
PoCの結果で広げるかを判断し、開発標準やテンプレート、指示ファイルを整え、要件に応じた閉域構成とセキュリティのゲートを本番化します。ハンズオンの教育と、社内で活用をリードする人の育成も進めます。 - 全社展開｜全社標準の開発基盤へ
AIエージェントの活用を本格化し、推進組織とガバナンスを整えて、指標にもとづく継続的な改善を回します。
弊社の支援｜ID・ネットワーク・デプロイの経路まで、一貫して設計する
AI駆動開発の基盤づくりは、開発ツールの設定だけでは完結しません。ID、ネットワーク、デプロイの経路を、情報システム部門の要件に沿って設計する必要があります。
弊社は、Azure と Microsoft 365 の導入支援で取り組んできた Entra ID・ネットワーク・セキュリティの設計の経験を生かし、計画・構築から教育・運用まで、次のメニューで支援しています。単体でも、組み合わせてもご利用いただけます。
Azure の設計・構築の支援内容は「クラウド導入支援（Azure）」、ID とアクセス制御の強化は「セキュリティ強化支援（ゼロトラスト）」をご覧ください。
よくあるご質問
こちらをクリックして「よくある質問」を表示
AI駆動開発とは何ですか？
AIを開発の工程に組み込み、実装・テスト・レビューの一部をAIが担う開発の進め方です。GitHub Copilot の場合、AIエージェント（Copilot cloud agent）が依頼に応じて実装とテストを行ってPRを作成し、人はレビューと承認に集中します。
Copilot coding agent と Copilot cloud agent は違うものですか？
同じ機能を指しています。2026年4月時点の GitHub の公式ドキュメントでは、Copilot cloud agent の名称で案内されています。有償の Copilot プランで利用でき、Copilot Business／Enterprise では管理者が有効にして使います。
AIが書いたコードが、確認されないまま本番に入ることはありませんか？
Copilot cloud agent は専用のブランチにしか書き込めず、自分のPRを承認・マージできません。作業を依頼した本人もそのPRを承認できず、既定ではワークフローも人が承認するまで実行されません。これにブランチ保護や本番環境の承認ルールを組み合わせることで、人のレビューを経たコードだけが本番に届く構成にできます。
業務のコードが、AIの学習に使われることはありませんか？
GitHub は、Copilot Business／Enterprise の利用者のやり取りのデータを、契約に基づいて学習に使わないとしています。個人向けの Free／Pro／Pro+ では、2026年4月24日からやり取りのデータが学習に使われるようになった（設定で拒否可能）ため、業務では組織で契約したプランを使うことをおすすめします。
閉域の環境でも使えますか？
Azure の仮想ネットワークに接続したランナー（Azure private networking を使う larger runner、または Self-hosted ランナー）を使えば、プライベートエンドポイント経由でデプロイ先に接続できます。Azure private networking は GitHub の利用形態によって対応リージョンが異なり、Self-hosted ランナーで Copilot cloud agent を動かす場合は組み込みのファイアウォールを無効にする必要があるため、送信先の制御を含めて設計します。
Azure DevOps を使っています。GitHub へ全面的に移る必要がありますか？
一度にすべてを移す必要はありません。Azure Boards の作業項目から Copilot にPRの作成を依頼する連携があり、作業管理は Azure Boards のまま使えます。ただし、この連携の対象は GitHub のリポジトリで、Azure Repos には対応していないため、AIエージェントに任せるコードは GitHub に置くことになります。
どの程度の効果が見込めますか？
GitHub の対照実験では課題の完了が55%速くなった、Accenture との調査では成功したビルドの数が84%増えた、といった結果が公開されています。ただし、効果はコードの規模や体制、依頼の仕方によって変わります。対象のチームと指標を決めて小さく試し、自社の数値で判断することをおすすめします。
GitHub Copilot と Azure を組み合わせた開発基盤の設計や、PoCの進め方についてのご相談は、お問い合わせよりお気軽にご連絡ください。現在の開発の流れと、情報システム部門の要件を伺い、どこから始めるべきかをご提案します。
関連サービス・関連コラム
- 関連コラム：Azureのインフラ払い出しをセルフサービス化する
- 関連コラム：増える社内『シャドーAI』を統制する
- 関連コラム：AIエージェントに「権限」をどう与え、統制するか
- 関連コラム：企業におけるAIエージェント活用の始め方
- 関連コラム：ゼロトラストとは
- 関連サービス：クラウド導入支援（Azure）
- 関連サービス：セキュリティ強化支援（ゼロトラスト）
まずは無料トライアルで、効果をご確認ください
「AIプライベート」は短期・低コストで試せます。帳票入力（AI-OCR）や電話受注（AI-Voice）の自動化、Azure/Microsoft 365・DXのご相談まで、お気軽にどうぞ。
