AI駆動開発を安全に始める｜GitHub Copilot × Azure で作る開発基盤

AIがコードを書くことが当たり前になりつつある今、問われているのは「AIをどう使うか」よりも、「AIが書いたコードを、どう安全に本番へ届けるか」です。

実装はAIエージェントに任せ、人はレビューと承認に集中する。できたコードは、シークレットを保存しない仕組みで Azure へデプロイする。AI駆動開発は、ツールを入れることではなく、開発の進め方と基盤を設計することです。

本記事では、GitHub Copilot（AIエージェントとコードレビュー）、GitHub Actions、Azure を組み合わせた開発基盤について、仕組み・組み込みの安全策・構成・情報システム部門が確認したい統制のポイントを、GitHub と Microsoft の公式情報で裏付けながら解説します。

株式会社ロクシアシステムズは、福岡と東京を拠点に、全国のお客様へ 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 では管理者が有効にして使います。

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 が作業できない場合もあるため、ブランチ保護やルールセットとの組み合わせは事前に確認しておきます。

GitHub Copilot for Azure とは｜エディターから Azure を操作する拡張機能

GitHub Copilot for Azure は、ここまで説明してきた Copilot cloud agent とは別の機能で、開発者の手元のエディターから Azure を自然言語で扱うための GitHub Copilot の拡張機能です。Azure のサービスについて調べる、リソースを作成してアプリをデプロイする、リソースの情報を取得する、問題を診断して切り分ける、といった操作を対話で行えます。

内部では Azure MCP サーバーを通じてツールを呼び出し、Azure のサービスや Azure Resource Graph とやり取りします。あわせて Azure スキル（azure-prepare、azure-validate、azure-deploy）が自動で追加され、よくある作業を複数の手順に分けて進められます。

利用には、Azure サブスクリプションへのアクセスと、GitHub Copilot のサブスクリプションが必要です。対応している開発環境は次のとおりです。

開発環境	提供状況	補足
Visual Studio Code	一般提供	拡張機能として追加する。Azure MCP サーバーのツールもあわせて使える
Visual Studio 2026	一般提供	Azure と AI の開発ワークロードを入れると使える
Visual Studio 2022	パブリックプレビュー	v17.14.30 以降。既定では無効のため、一度だけ有効にする
JetBrains の IDE	一般提供	GitHub Copilot プラグインから使う
Claude Code	一般提供	プラグインとして追加する

使い分けの目安としては、複数の手順にまたがる作業はエージェントモード、Azure のサービスについての簡単な質問は Ask モード（@azure）が向いています。プロンプトに「Azure」という語を入れておくと、Azure MCP サーバーのツールが呼ばれやすくなります。

本記事で扱う Copilot cloud agent が「Issue を受け取って実装し、PRを出す」役割であるのに対し、GitHub Copilot for Azure は「開発者の手元で Azure を調べ、操作する」役割です。どちらも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 にアクセスするためのトークンを発行します。デプロイのために保存しておくシークレットは不要になります。

ランナーの選び方｜まず標準構成で試し、本番の要件に応じて閉域化する

GitHub Actions のジョブや Copilot cloud agent の作業を実際に動かすのが「ランナー」です。どのランナーを使うかで、運用の手間と、到達できるネットワークが変わります。

標準構成｜GitHub-hosted ランナー

GitHub が管理するランナーを使う構成です。ジョブごとに新しい仮想マシンで実行されるため、ランナーの構築や更新は不要です。デプロイはインターネット経由になるため、Azure 側のサービスは公開エンドポイントのまま、Entra ID の認証、RBAC、アクセス制限で保護します。

閉域構成｜仮想ネットワーク内のランナーから、プライベートエンドポイント経由で

機密データを扱うシステムなどでは、Azure 側のサービスの公開アクセスを無効にし、仮想ネットワーク内のランナーからプライベートエンドポイント経由でデプロイします。ランナーは GitHub への送信通信（HTTPS）だけでジョブを受け取るため、受信ポートを開ける必要はありません。

情報システム部門が確認したい統制のポイント｜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から始め、効果を測ってから開発チーム全体、全社へと段階的に広げます。

1. PoC｜対象のチームと、測る指標を決めて試す
   1つのチームと実際の案件を選び、効果を測る指標と現状の値を決めたうえで、実際の開発で試します。
2. 開発チームへの導入｜標準化と定着
   PoCの結果で広げるかを判断し、開発標準やテンプレート、指示ファイルを整え、要件に応じた閉域構成とセキュリティのゲートを本番化します。ハンズオンの教育と、社内で活用をリードする人の育成も進めます。
3. 全社展開｜全社標準の開発基盤へ
   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）・計画づくり（AI-Enhance）の自動化から、クラウド（Azure・Microsoft 365）・DXのご相談まで、お気軽にどうぞ。