GitHub CopilotでAIエージェントに実装を任せる時代に、いちばん重要になるのは「うまいプロンプトを書くこと」だけではありません。今回のポイントは、Issue、受け入れ条件、PR、CI、レビュー、ドキュメント更新まで含めて、エージェントを開発プロセスに組み込むことです。
2026年5月20日に公開・更新情報として扱われたMicrosoft公式ブログ「Agentic-Agile: Why Agent Development Needs Agile (Not Just Prompts)」は、GitHub Copilotの機能廃止や強制移行を告知するものではなく、GitHub Copilot CLIやCopilot cloud agentのようなAIコーディングエージェントを、チーム開発で安全かつ継続的に使うための方法論を示した内容です。なお、公式ページ上の掲載日は「May 19th, 2026」と表示されています。(Microsoft for Developers)
結論から言えば、管理者と開発者が今確認すべきことは3つです。第一に、Copilotに渡す作業を「曖昧な依頼」ではなく「Issue化された仕様」に変えること。第二に、.github/copilot-instructions.mdなどのリポジトリ内ドキュメントで、Copilotが守るべき開発ルールを明文化すること。第三に、Copilot cloud agentを使う組織では、ポリシー、シークレット、Actions実行、MCP、レビューゲートの設定を見直すことです。
GitHub CopilotのAgentic-Agileで何が変わるのか
今回の公式情報で示された「Agentic-Agile」は、GitHub Copilotを単なる補完ツールやチャット相手として扱うのではなく、開発チームの一員としてプロセスに参加させる考え方です。
従来のAI活用では、開発者が「この機能を作って」「このコードを直して」とプロンプトを入力し、出力を見て再依頼する流れが中心でした。しかし、対象が単一関数や小さなリファクタリングを超え、複数ファイル、外部依存、API契約、テスト、CI/CDを含む変更になると、プロンプトだけでは作業範囲や完了条件が曖昧になります。
Microsoft公式ブログでは、プロンプト駆動の開発が大規模化すると、バックログがない、完了条件がない、段階的なデリバリーがない、ガバナンスが後付けになる、といった問題が起きると説明されています。結果として、単体では動くコードが統合時に壊れたり、セッションごとに挙動がぶれたり、レビュー前に欠陥が積み上がったりするリスクが高まります。(Microsoft for Developers)
| 観点 | プロンプト中心の使い方 | Agentic-Agileの使い方 |
|---|---|---|
| 作業の起点 | チャットへの依頼文 | GitHub Issueや仕様書 |
| 完了条件 | 開発者の感覚で「よさそう」 | 受け入れ条件を満たしたか |
| Copilotへの文脈 | その場のプロンプト中心 | リポジトリ内の永続的な指示 |
| レビュー | 出力後に人が確認 | PR、CI、レビューゲートで確認 |
| 並行開発 | 競合が起きやすい | ファイル所有・依存関係・波単位で分割 |
| 改善方法 | プロンプトを直す | Issue、指示、テスト、レビュー基準を改善 |
つまり、変更点は「GitHub Copilotに新しいボタンが増えた」というより、Copilotに仕事を任せる前の設計・管理・レビューの作法が変わることにあります。
Agentic-Agileは「プロンプト改善」ではなく「仕様ファースト」の開発手法
Agentic-Agileの中心は、仕様を先に作ることです。Copilotに「ログイン機能を作って」と依頼するのではなく、まずGitHub Issueとして目的、背景、対象ファイル、変更しない範囲、受け入れ条件、検証方法を定義します。
公式ブログでは、Copilotに対する作業を「Issue first」とし、作業には関連Issueを持たせること、曖昧な機能はIssue化し、すべてのIssueに受け入れ条件を持たせることが推奨されています。さらに、PR、CI、レトロスペクティブを使ってプロセス自体を改善する姿勢も強調されています。(Microsoft for Developers)
悪い依頼と良い依頼の違い
悪い依頼の例は、次のようなものです。
ユーザー登録機能を追加して。いい感じにバリデーションも入れて。この依頼では、対象画面、API、保存先、エラー仕様、既存機能への影響、テスト方法が不明です。Copilotは推測で補完できますが、その推測がチームの設計意図と一致するとは限りません。
Agentic-Agile向けのIssueは、たとえば次のように書きます。
## Summary
メールアドレスとパスワードによるユーザー登録APIを追加する。
## Context
既存のログインAPIはあるが、新規ユーザー登録APIが未実装。
管理画面やOAuth連携は今回の対象外。
## Scope
### Files to Create or Modify
- src/routes/register.ts — 登録APIのルートを追加
- src/services/userService.ts — ユーザー作成処理を追加
- tests/register.test.ts — 正常系と異常系のテストを追加
## Invariants to Preserve
- 既存のログインAPIのレスポンス形式を変更しない
- 既存のUserテーブル定義を変更しない
## Acceptance Criteria
- [ ] 有効なメールアドレスとパスワードでユーザー登録できる
- [ ] 重複メールアドレスの場合は409を返す
- [ ] パスワードが8文字未満の場合は400を返す
- [ ] npm test が成功する
## Negative Constraints
- OAuthログインは実装しない
- 管理者ロールの追加は行わない
- 既存のログインAPIは変更しないこのように書くと、Copilotの仕事は「自由に作る」から「契約を満たす実装を行う」に変わります。人間にとってもレビューしやすく、PRの合否判断が明確になります。
影響範囲：開発者、管理者、リポジトリ運用のどこに関係するか
Agentic-Agileの影響は、GitHub Copilotを使う開発者だけに限られません。特にCopilot cloud agentやGitHub Copilot CLIを組織で使う場合、管理者側の設定とリポジトリ設計も重要になります。
| 対象 | 影響 | 確認すべきこと |
|---|---|---|
| 開発者 | Copilotへの依頼方法が変わる | Issue、受け入れ条件、/plan、PRレビューを使う |
| テックリード | 作業分解とレビュー基準が重要になる | ファイル所有、依存関係、CIゲートを設計する |
| GitHub管理者 | Copilot cloud agentの利用範囲を制御する必要がある | 組織・Enterpriseポリシー、リポジトリ除外設定を確認する |
| セキュリティ担当 | Actions、MCP、シークレット、外部接続の統制が必要になる | Agents secrets、ファイアウォール、レビューゲートを確認する |
| 情シス・開発基盤 | 利用コストと実行環境の管理が必要になる | GitHub Actions分、Premium requests、ランナー設定を確認する |
GitHub Docsによると、Copilot cloud agentはリポジトリ調査、実装計画の作成、バグ修正、機能追加、テストカバレッジ改善、ドキュメント更新などを実行できます。また、IDEのagent modeとは異なり、GitHub Actionsベースの環境で作業し、IssueやGitHub Copilot Chatから割り当てられたタスクを進められます。(GitHub Docs)
そのため、Agentic-Agileは「Copilotを便利に使うコツ」ではなく、AIが作るブランチ、PR、テスト、ログ、権限をどう管理するかという開発運用のテーマです。
開発者が確認すべきGitHub Copilotの使い方
小さな作業はプロンプトでよいが、複数ファイルの変更はIssueから始める
単一ファイルの軽微な修正や、関数の説明、テストケースの追加程度であれば、従来どおりCopilot ChatやIDEのagent modeに直接依頼しても問題ありません。
一方で、次のような作業はIssue化してからCopilotに任せるべきです。
| 作業内容 | 推奨する進め方 |
|---|---|
| 単一関数の修正 | Copilot ChatまたはIDE上で依頼 |
| 複数ファイルにまたがる機能追加 | Issue化し、受け入れ条件を定義 |
| DBスキーマやAPI契約に関わる変更 | 仕様、影響範囲、ロールバック方針を明記 |
| 認証、権限、決済、個人情報に関わる変更 | 人間の設計レビューを先に行う |
| 大規模リファクタリング | ファイル所有とフェーズを分けて波単位で実施 |
| CI/CDやセキュリティ設定の変更 | PRレビューとActions実行承認を必須にする |
判断基準はシンプルです。「失敗したときにレビューだけで直せるか」「既存仕様を壊す可能性があるか」を見てください。既存仕様を壊す可能性がある作業は、プロンプトではなくIssueから始める方が安全です。
GitHub Copilot CLIでは/planを先に使う
GitHub Copilot CLIを使う場合は、実装前に/planを使うのが実務的です。GitHub Docsでは、Plan modeによりCopilotがコードを書く前に構造化された実装計画を作成し、実装前に承認を待つと説明されています。Shift + Tabで通常モードとPlan modeを切り替えるか、通常モードで/planコマンドを使えます。(GitHub Docs)
例として、次のように依頼します。
/plan Issue #123 を読んで、実装前に変更対象ファイル、テスト方針、リスク、確認質問を整理してください。
まだコードは変更しないでください。いきなり実装を始めさせるのではなく、まず計画を出させ、人間がスコープの漏れや誤解を修正します。特に、リファクタリング、認証、API追加、依存パッケージ追加では、この一手間が手戻りを大きく減らします。
.github/copilot-instructions.mdを整備する
Agentic-Agileでは、Copilotへの指示を毎回プロンプトに書くのではなく、リポジトリ内に永続的な指示として残します。
GitHub Docsでは、リポジトリ全体のカスタム指示として.github/copilot-instructions.mdを利用でき、パスごとの指示には.github/instructions配下のNAME.instructions.mdを使えると説明されています。また、AI agents向けにはAGENTS.md、単一のCLAUDE.mdやGEMINI.mdをルートに置く方法も示されています。(GitHub Docs)
.github/copilot-instructions.mdには、最低限次の内容を入れておくと実用的です。
# Copilot Instructions
## Project Overview
このリポジトリは、社内向け在庫管理APIです。
TypeScript、Node.js、PostgreSQLを使用します。
## Coding Rules
- TypeScriptの型を明示する
- 例外を握りつぶさない
- APIレスポンス形式を既存仕様から変更しない
- 外部ライブラリを追加する場合は理由をPRに書く
## Testing
- 新規APIには正常系と異常系のテストを追加する
- 既存テストが失敗する場合は実装を完了扱いにしない
- テストコマンドは npm test
## Pull Request
- 変更概要、影響範囲、テスト結果を書く
- 仕様変更がある場合はREADMEまたはdocsを更新する重要なのは、抽象的な理念ではなく、Copilotが実装中に判断できるルールを書くことです。「高品質に書く」ではなく、「外部ライブラリを追加する場合は理由をPRに書く」のように、検証可能な指示にします。
管理者が確認すべき設定
Copilot cloud agentの有効化ポリシー
GitHub Copilot BusinessまたはGitHub Copilot Enterpriseでは、Copilot cloud agentは管理者による有効化が必要です。GitHub Docsでは、Business/Enterprise加入者の場合、Copilot cloud agentは既定で無効であり、利用するには管理者が有効化する必要があると説明されています。一方、ProまたはPro+では既定で有効とされています。(GitHub Docs)
組織管理者は、まず次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Enterpriseポリシー | 組織側で上書きできるか、Enterprise側で固定されているか |
| Organizationポリシー | Copilot cloud agentをどの組織・メンバーに許可するか |
| リポジトリ除外 | 機密性が高いリポジトリで利用を止める必要があるか |
| 第三者エージェント | Anthropic ClaudeやOpenAI Codexなどを許可するか |
| MCP | 外部ツールやデータソースとの接続を許可するか |
GitHub Docsでは、組織のCopilotポリシーで機能やモデルの可用性を制御でき、Enterprise側の設定がある場合は組織側で上書きできない場合があると説明されています。また、第三者コーディングエージェントとしてAnthropic ClaudeとOpenAI Codexの有効化設定が示されており、これらはCopilot cloud agentが有効なリポジトリと同じ範囲にアクセスするとされています。(GitHub Docs)
Actionsワークフローの自動実行は慎重に扱う
Copilot cloud agentがPRに変更をpushしたとき、GitHub Actionsを自動実行するかどうかは重要な設定です。GitHub Docsでは、Copilotがpushした変更に対してActionsワークフローは既定で自動実行されず、PRのマージボックスにある「Approve and run workflows」から実行できると説明されています。さらに、自動実行を許可すると、レビュー前のCopilot生成コードがリポジトリへの書き込み権限やActions secretsへアクセスできる可能性があると警告されています。(GitHub Docs)
実務では、最初から自動実行を全面許可しない方が安全です。特に.github/workflows/配下をCopilotが変更したPRでは、ワークフロー自体に悪影響がないかを人間が確認してから実行してください。
Agents secretsとvariablesを確認する
Copilot cloud agentには、Actions、Codespaces、Dependabotとは別に、専用のAgents secretsとvariablesがあります。GitHub Docsでは、Agents secrets/variablesは組織レベルまたはリポジトリレベルで設定でき、Copilot cloud agentの開発環境に環境変数として渡されると説明されています。また、以前copilot環境に設定していたシークレットや変数は、新しいリポジトリレベルのAgentsタイプに自動移行されているとされています。(GitHub Docs)
確認すべきポイントは次のとおりです。
| 項目 | 注意点 |
|---|---|
| Actions secrets | Copilot cloud agentには渡らない |
| Agents secrets | Copilot cloud agent用に明示的に設定する |
| 組織レベルのsecret | 対象リポジトリを必要最小限にする |
| MCP用secret | COPILOT_MCP_プレフィックスを使う |
旧copilot環境 | 自動移行後の新しい場所で管理する |
「Actionsで使えているsecretだからCopilot agentも使える」と考えると、ビルドやテストが失敗します。逆に、必要以上のsecretをAgents側に渡すと、権限過多になります。必要なものだけを、対象リポジトリ単位で設定するのが基本です。
Copilot cloud agentの検証ツールとレビュー設定
Copilot cloud agentには、生成コードをセキュリティ観点で確認し、Copilot code reviewで別視点のレビューを受けるための検証ツールがあります。GitHub Docsでは、既定でCopilot cloud agentが生成コードをセキュリティ問題についてチェックし、Copilot code reviewによるセカンドオピニオンを取得すると説明されています。(GitHub Docs)
速度を優先してこれらを無効化する選択肢もありますが、代替のレビュー体制やセキュリティスキャンがないなら避けるべきです。Agentic-Agileの考え方では、ガバナンスは最後に足すものではなく、最初のバックログから組み込むものだからです。
Content exclusionを過信しない
管理者が特に注意すべき点として、Copilot cloud agentはcontent exclusionsを考慮しない制限があります。GitHub Docsでは、content exclusionsはCopilotに特定ファイルを無視させる設定ですが、Copilot cloud agent利用時にはこれらのファイルを見たり更新したりできると説明されています。(GitHub Docs)
そのため、機密情報を含むファイルを「除外設定しているから安全」と判断しないでください。Copilot cloud agentを使わせないリポジトリを分ける、ファイル構成を見直す、secret管理を徹底する、PRレビューで対象ファイルを確認する、といった運用が必要です。
ファイアウォールとMCPの接続範囲を確認する
MCPは、GitHub Copilotを外部ツールやデータソースと接続するための仕組みです。GitHub Docsでは、MCPによりGitHub Copilotの機能を拡張し、IDE、Copilot CLI、Copilot cloud agentなど複数の利用面で使えると説明されています。また、Business/EnterpriseではMCPサーバー利用をポリシーで有効・無効化でき、既定では無効とされています。(GitHub Docs)
MCPは便利ですが、外部データや社内ツールへの接続経路になります。開発者ごとに自由に接続させる前に、次を決めておくべきです。
| 設定 | 判断基準 |
|---|---|
| MCPサーバーの許可 | 業務上必要なサービスだけ許可する |
| 外部接続 | ログ、チケット、監視ツールへのアクセス範囲を限定する |
| secret | MCP用secretはCOPILOT_MCP_で分離する |
| 監査 | どのエージェントが何にアクセスしたかを追跡できるようにする |
| ファイアウォール | 依存関係取得に必要な通信と不要な通信を分ける |
GitHub Docsでは、Copilot cloud agentのインターネットアクセスは既定でファイアウォールにより制限され、データ流出リスクの管理に役立つと説明されています。(GitHub Docs)
移行時の注意点：いきなり全社展開しない
Agentic-Agileへの移行は、GitHub Copilotのライセンスを配るだけでは完了しません。むしろ、最初に全リポジトリへ広げると、Issueの粒度、レビュー基準、Actions実行、secret管理が追いつかず、かえって混乱します。
おすすめは、1〜2個のリポジトリでパイロット運用を行うことです。選ぶリポジトリは、次の条件を満たすものが向いています。
| 条件 | 理由 |
|---|---|
| テストが一定程度整備されている | Copilotの出力を機械的に検証しやすい |
| CIが安定している | 失敗原因をCopilot由来か環境由来か切り分けやすい |
| 仕様が文書化されている | Copilotに渡すコンテキストを作りやすい |
| 影響範囲が限定されている | 失敗時のリスクを抑えやすい |
| レビュー担当者が明確 | PRが滞留しにくい |
逆に、テストがほぼない、CIが壊れている、仕様が属人化している、機密ファイルが混在しているリポジトリは、最初の対象にしない方が安全です。Agentic-Agileは「AIで雑に進める」方法ではなく、AIが動けるように開発プロセスを整える方法です。
展開手順：最初の4週間でやること
1週目：対象リポジトリと利用範囲を決める
最初に、Copilot cloud agentを使うリポジトリ、使わないリポジトリを分けます。Business/Enterpriseでは、管理者がCopilot cloud agentの有効化ポリシーを確認し、必要に応じて対象組織やリポジトリを限定します。
この時点では、開発者に「自由に使ってよい」と広げないことが大切です。先にレビュー担当、Issueテンプレート、secretの扱い、Actions承認ルールを決めます。
2週目：カスタム指示とIssueテンプレートを作る
次に、.github/copilot-instructions.mdとIssueテンプレートを整備します。Microsoftが公開しているagentic-agile-templateには、Copilot向け指示ファイル、Issueテンプレート、スタイルガイド、評価フレームワークなどが含まれています。このテンプレートは、構造化されたhuman-agent collaborationの出発点として設計されています。(GitHub)
Issueテンプレートには、少なくとも次の項目を入れます。
| 項目 | 目的 |
|---|---|
| Summary | 何を実現するかを一文で示す |
| Context | なぜ必要か、背景を示す |
| Scope | 対象ファイルや実装範囲を示す |
| Invariants | 壊してはいけない既存仕様を示す |
| Acceptance Criteria | 完了条件をテスト可能な形で示す |
| Negative Constraints | やらないことを明確にする |
| Dependencies | 先に必要なIssueや作業を示す |
| File Ownership | 並行作業時の競合を防ぐ |
3週目：CI、レビュー、Actions承認を整える
Agentic-Agileでは、CI/CD、lint、テスト、レビューゲートを後回しにしません。Microsoft公式ブログでも、CIゲートや単体テストを受け入れ条件に含めることが、成果物の品質に大きく影響したと説明されています。(Microsoft for Developers)
この週に確認すべきことは次のとおりです。
| 項目 | 推奨設定 |
|---|---|
| 必須チェック | テスト、lint、型チェックをPR必須にする |
| PRレビュー | Copilot生成PRも人間レビューを必須にする |
| Actions承認 | 初期段階では自動実行を避ける |
| ワークフロー変更 | .github/workflows/の変更は特に厳しく見る |
| ドキュメント更新 | 仕様変更時はREADMEやdocs更新を受け入れ条件にする |
4週目：効果を測定し、改善する
展開後は、生成されたコード量だけを見ても意味がありません。Agentic-Agileで見るべき指標は、開発速度だけでなく、手戻り、レビュー指摘、欠陥、マージまでの時間です。
GitHub Docsでは、Enterprise管理者やOrganization ownerがCopilot usage metricsを使い、Copilot cloud agentによるPR作成数、マージ数、マージまでの中央値などを分析できると説明されています。(GitHub Docs)
実務では、次の指標を追うと改善につなげやすくなります。
| 指標 | 見る理由 |
|---|---|
| First-pass acceptance rate | 初回PRでどれだけ受け入れられるか |
| Rework rate | Copilot出力の手戻りが多すぎないか |
| Escaped defects | マージ後に見つかった欠陥が増えていないか |
| Merge conflict | 並行エージェント作業で競合が起きていないか |
| Time to merge | PRがレビュー待ちで滞留していないか |
| CI failure rate | Copilotがテスト前提を理解できているか |
失敗しやすいポイントと対策
| 失敗パターン | 起きること | 対策 |
|---|---|---|
| 「いい感じに作って」と依頼する | Copilotが設計を推測し、意図しない実装をする | Issueに受け入れ条件と除外範囲を書く |
| 指示ファイルを作って放置する | 古いルールをCopilotが参照し続ける | 仕様変更時に.github/copilot-instructions.mdも更新する |
| 複数エージェントに同じ領域を触らせる | マージ競合や設計不整合が起きる | ファイル所有とwave単位の作業分割を行う |
| PRレビューを省略する | セキュリティ不備や仕様逸脱が混入する | Copilot生成PRも通常PRと同じ基準でレビューする |
| Actions自動実行を安易に許可する | 未レビューコードがsecretや書き込み権限に触れる | 初期は手動承認にし、ワークフロー変更を重点確認する |
| Content exclusionを過信する | Copilot cloud agentが除外対象ファイルを見られる可能性がある | リポジトリ単位の利用可否とsecret管理で制御する |
| MCPを無制限に許可する | 外部サービスへの接続範囲が広がりすぎる | 許可サーバー、secret、監査ログを設計する |
Agentic-Agileを導入する時の実務判断基準
GitHub Copilotを使うすべての作業に、重いプロセスをかける必要はありません。重要なのは、作業のリスクに応じて使い分けることです。
| リスク | 例 | 必要な管理レベル |
|---|---|---|
| 低 | コメント追加、README修正、小さなテスト追加 | ChatやIDE agent modeで対応可 |
| 中 | 複数ファイルの機能追加、UI変更、API追加 | Issue、/plan、PRレビューを必須にする |
| 高 | 認証、権限、課金、個人情報、CI/CD変更 | 人間の設計レビュー、CI、セキュリティ確認を必須にする |
| 非常に高 | 本番インフラ、secret、組織横断の権限変更 | Copilot単独実装を避け、補助的に使う |
判断に迷う場合は、「Copilotに任せる範囲」ではなく「人間が責任を持って確認できる範囲」で区切るのが安全です。エージェントは実装速度を上げられますが、最終的な設計責任やリリース責任を肩代わりするわけではありません。
まず今日やるべきこと
GitHub CopilotのAgentic-Agile対応として、最初にやるべきことは大きな移行プロジェクトではありません。まず、対象リポジトリを1つ選び、次の3つを整えることです。
1. .github/copilot-instructions.md を作る
2. Agentic-Agile向けのIssueテンプレートを作る
3. Copilotに任せる小さなIssueを3件選び、/plan → 実装 → PR → CI → レビューの流れを試すこの流れで、Copilotがどこで迷うのか、Issueの粒度が大きすぎないか、レビューやCIで何が足りないかが見えてきます。Agentic-Agileの本質は、完璧なプロンプトを探すことではなく、人間とAIエージェントが同じルール、同じ完了条件、同じレビュー基準で開発できる状態を作ることです。
GitHub Copilotを本格的にチーム開発へ組み込むなら、次の一歩は「プロンプト集を増やすこと」ではありません。バックログ、カスタム指示、受け入れ条件、CI、PRレビューを整え、Copilotが安全に働ける開発システムを作ることです。
コメント