チュートリアル - エージェントモード + MCP

GitHub Copilotのエージェントモードに、Model Context Protocol（MCP）を組み合わせることで、開発ワークフローが大きく変わります。本記事では、この組み合わせが実際の開発現場でどのように機能するのか、具体的な実装例とともに解説します。

注意事項
企業や組織でCopilotを利用している場合、MCPサーバーの使用を制御するポリシーがデフォルトで無効化されています。MCPサーバーを使用するには、管理者による有効化が必要です。

1. エージェントモードとMCPの組み合わせがもたらすもの

1.1 エージェント機能の本質

Copilotのエージェント機能は、以下の3つの能力を持ちます：

1. 自律実行 - 複数ステップのワークフローを、継続的な指示なしで実行
2. 意思決定 - コンテキストに基づいて適切なツールとアプローチを選択
3. 反復適応 - フィードバックと結果に応じてアプローチを調整

MCPサーバーと組み合わせることで、これらの能力が外部リソースへのアクセスと統合され、Copilotは「エージェントループ」を完結できるようになります。つまり、関連情報の自律的な検索、フィードバックの分析、情報に基づいた意思決定を動的に行えるということです。

1.2 具体的なメリット

コンテキストの拡張
MCPサーバーを通じて、Copilotは外部のデータソース、API、ツールにアクセスできます。これにより、コードベース内の情報だけでなく、設計ドキュメント、issue管理システム、テストツールなど、開発に必要なあらゆる情報を統合的に扱えるようになります。

手作業の削減
issueの作成、ワークフローの実行といったタスクをCopilotが実行している間、開発者はより高度な意思決定や設計に集中できます。

シームレスな統合
複数のツールやプラットフォームにまたがるタスクを、コンテキストの切り替えやカスタム統合なしで処理できます。

2. 実践的な使い方：ベストプラクティス

2.1 プロンプト戦略

効果的にエージェントモードを活用するには、プロンプトの設計が重要です：

目標の明確化
何を達成したいのか、どのような出力が欲しいのかを具体的に定義します。

良い例：
「顧客ポータルをWCAG 2.1 AA準拠にする。Figma MCPでデザイン仕様を分析し、
GitHub MCPでアクセシビリティ関連のissueを検索して、カテゴリ別に整理してください」

避けるべき例：
「アクセシビリティを改善して」

コンテキストの提供
プロジェクトの背景情報や要件を含め、Copilotがアクセスできる外部リソースへのリンクも提供します。

境界の設定
タスクの制約や制限を明示します。例えば、計画のみを作成し、まだ変更を加えないでほしい場合は、そう明記します。また、有効にするMCPツールを制限することもできます。

確認の要求
重要な変更を進める前に、Copilotに理解の確認を求めます。

プロンプトファイルやカスタム指示の活用
異なるMCPサーバーに対するCopilotの動作をガイドするために、プロンプトファイルやカスタム指示ファイルを作成できます。詳細はGitHub Docsの「About customizing GitHub Copilot responses」を参照してください。

2.2 MCPサーバーの選択と管理

適切なサーバーの選択
ワークフローのニーズに合致するMCPサーバーを選択して有効化します。

シンプルから始める
複雑な統合を追加する前に、いくつかの確立されたMCPサーバーから始めます。

接続のテスト
エージェントモードのタスクを開始する前に、すべてのMCPサーバーが適切に設定され、アクセス可能であることを確認します。

2.3 セキュリティの考慮事項

開発環境でMCPを使用する際は、セキュリティに十分注意を払う必要があります：

OAuth認証の優先
GitHub MCPのようなMCPサーバーでは、個人アクセストークンよりもOAuth認証を優先します。詳細はGitHub Docsの「Using the GitHub MCP Server」を参照してください。

権限の制限
MCPサーバーには、タスクに必要な最小限の権限のみを付与します。

接続の定期的な監査
開発環境へのアクセス権を持つMCPサーバーを定期的に確認します。

アクティビティの監視
CopilotがMCPサーバーを通じて実行するアクションを追跡します。

シークレットの漏洩防止
プッシュ保護機能により、AI生成レスポンスにシークレットが含まれることを防ぎ、GitHub MCPサーバーを使用して実行するアクションを通じてシークレットを露出することを防ぎます（現在はパブリックリポジトリのみ利用可能）。詳細はGitHub Docsの「About push protection」を参照してください。

3. 実例：アクセシビリティ対応の実装ワークフロー

実際の開発シナリオで、エージェントモードとMCPがどのように連携するかを見ていきます。

3.1 シナリオ設定

顧客ポータルが最新のアクセシビリティ基準に準拠する必要があり、以下のガイダンスが与えられています：

• デザインチームが定義した仕様のリスト
• アクセシビリティ監査後にプロジェクトリポジトリに作成されたissue

このシナリオでは、異なるフェーズ（調査、計画、実装、検証）に対して個別のプロンプトを使用します。これにより、ソフトウェア開発ライフサイクルのフェーズに緩やかに対応した複数の「エージェントループ」が生まれます。

重要なポイント：チェックポイントの活用

各ループの間には自然なチェックポイントが設けられており、開発者は以下のことができます：

• 進捗状況を確認する
• Copilotの提案内容をレビューする
• 必要に応じてフィードバックを提供する
• 次のフェーズに進む前に要件を調整する

この段階的なアプローチにより、Copilotが一度にすべてを実行するのではなく、開発者が各段階で適切に介入できます。

3.2 前提条件とセットアップ

開始前に以下を準備します：

1. Copilot統合とMCPサポートを備えたIDE
   Visual Studio Codeなど、MCPに対応したエディタを使用します。

2. エージェントモードの有効化
   IDEの設定でエージェントモードを有効にします。通常、Copilot Chatの設定メニューから「Agent mode」や「Agentic mode」のオプションを探して有効化できます。

3. 使用したいMCPサーバーへのアクセス
   必要なMCPサーバーを事前に設定し、接続テストを行います。

今回のシナリオでは、以下のMCPサーバーを設定します：

GitHub MCPサーバー
リポジトリへのアクセス、コードベースの検査、既存issueの調査、ブランチの作成、プルリクエストの管理を可能にします。詳細はGitHub Docsの「Using the GitHub MCP Server」を参照してください。

Figma MCPサーバー
色のコントラスト要件、フォーカス状態、インタラクションパターンなどのアクセシビリティ仕様を含むデザインファイルへのアクセスを許可します。Figma-Context-MCPまたはDev Mode MCPサーバーが利用可能です。

Playwright MCPサーバー
スクリーンリーダーの互換性やキーボードナビゲーションテストを含む、自動アクセシビリティテストの作成と実行を可能にします。mcp-playwrightを参照してください。

3.3 ワークフローの全体像

3.4 ステップ1：調査ループ - アクセシビリティ要件の分析

まず、Copilotにアクセシビリティ要件と既存のアクセシビリティ関連GitHub issueの両方を分析するよう指示します。

プロンプトには、Figmaファイルへのリンクを含めます。Copilotがデザイン仕様を正常に読み取って分析できるように、ファイル内の特定のノードまたはレイヤーを選択し、ノードIDがURLに含まれるようにします。

プロンプト例1

顧客ポータルをWCAG 2.1 AA準拠にする必要があります。
Figma MCPを使用して、https://figma.com/design/DESIGN-FILE-FOR-ACCESSIBILITY-SPECS?node-id=NODE_ID
のデザイン仕様からアクセシビリティ要件を分析してください。
また、GitHub MCPを使用して、customer-portalリポジトリで「accessibility」または「WCAG」
ラベルが付いた未解決のGitHub issueを検索してください。
その後、それらをカテゴリに分類し、各カテゴリに該当するissueをissueタイトルと番号とともに
リストアップしてください。

期待される応答

Copilotはまず、FigmaとGitHub MCPサーバーからツールを実行する許可を求めます。許可すると、CopilotはFigmaのデザイン仕様を分析し、GitHub issueを検索して整理します。

例えば、Copilotは複数のissueを発見したことに基づいて、色のコントラストをカテゴリとして識別する可能性があります：

色のコントラストの問題
- Issue #134: ダッシュボードテキストのコントラスト比が4.5:1未満
- Issue #156: フォームのエラー状態がコントラスト要件を満たしていない

これにより、アクセシビリティ要件の包括的な概要が得られ、Copilotに優先順位付けと計画の作成を依頼できます。

チェックポイント
ここで一度立ち止まり、Copilotが識別したカテゴリと各issueの内容を確認します。必要に応じて、追加の調査や焦点を当てるべき領域について指示を出すことができます。

3.5 ステップ2：計画ループ - アクセシビリティ実装戦略

次に、Copilotに詳細な実装計画を作成するよう依頼します。

プロンプト例2

Figmaデザインとgithub issueのアクセシビリティ分析に基づいて、
最優先のアクセシビリティissueに対処する即座のプルリクエスト用の
集中的な実装計画を作成してください。まだ変更は加えないでください。
また、残りのFigma仕様のために作成すべきフォローアップissueを提案してください。

期待される応答

Copilotは、即座のプルリクエスト用に影響度の高いアクセシビリティissueに焦点を当てた優先順位付けされた実装計画を作成し、残りの作業用のフォローアップissueを提案します。

例えば、Copilotは色のコントラストカテゴリのissueを修正するために必要な作業を識別する可能性があります：

1. 色のコントラスト修正:
- variables.scssのテキストカラー変数を更新し、すべての通常テキストで4.5:1のコントラスト比を確保
- DashboardCard.vueおよびその他の主要コンポーネントのUIコンポーネントカラーを変更し、
  3:1のコントラスト比を満たす
- Issue #134（ダッシュボードテキストのコントラスト）とIssue #156（フォームのエラー状態）
  の修正を優先

焦点を当てたい内容に基づいて、Copilotに計画の調整を依頼できます。結果として、実装を依頼できる、納得のいく計画が得られます。

チェックポイント
実装に進む前に、提案された計画を慎重にレビューします。優先順位が適切か、スコープが妥当か、リソースの見積もりが現実的かを確認してください。この段階で計画を調整することで、実装フェーズでの手戻りを最小限に抑えられます。

3.6 ステップ3：実装ループ - アクセシビリティ改善の実施

計画を確認した後、Copilotにアクセシビリティ修正の実装を開始するよう指示します。

プロンプト例3

新しいブランチを作成し、提案された実装計画に従って重要なアクセシビリティ修正を実装してください。
最優先と識別した上位3つのカテゴリに焦点を当ててください。
修正されるissueへの適切な参照を含むプルリクエストを作成してください。

期待される応答

Copilotは実装計画を実行し、識別されたアクセシビリティissueに対処するための的を絞ったコード変更を行い、プルリクエストを作成します。

例えば、Copilotはfix/critical-accessibility-issuesという新しいブランチを作成し、色のコントラストissueに対処するための変更を行う可能性があります：

ダッシュボードテキストのコントラストissueを修正（Issue #134）:
- src/styles/variables.scssのテキストカラー変数を#767676から#595959に更新
- DashboardCard.vueのライトグレー背景上の暗いテキストを変更し、4.5:1の比率を確保

これらの変更を含むプルリクエスト#213を作成しました。

チェックポイント
プルリクエストの内容を確認し、コードの変更が計画通りに実装されているか、想定外の変更がないかをレビューします。必要に応じて、Copilotに追加の修正や調整を依頼できます。

3.7 ステップ4：テストループ - Playwrightによるアクセシビリティ検証

Playwright MCPを使用して、アクセシビリティテストを作成して実行するようCopilotに指示できます。

プロンプト例4

プルリクエストで更新したコンポーネント用の集中的なアクセシビリティテストを作成してください。
Playwright MCPを使用してください。

期待される応答

Copilotはアクセシビリティテストを開発し、必要に応じてPlaywright設定ファイルを作成します。

例えば、Copilotはテキストコントラストに関するテストファイルを作成する可能性があります：

テストの実装:

tests/accessibility/に的を絞ったテストファイルを作成しました:
- contrast.spec.ts - テキストのコントラスト比を検証

テストが作成されると、CopilotはPlaywright MCPから様々なツールを使用してテストを実行する許可を求めます。なお、Copilotが必ずしも要求していない追加のテストを行う場合があります。これを防ぐには、プロンプトをより厳密に調整してください。

チェックポイント
テストの実行結果を確認し、すべてのアクセシビリティ要件が満たされているかを検証します。失敗したテストがある場合は、Copilotに修正を依頼するか、テストの妥当性を確認します。

3.8 ステップ5：GitHub issueの更新

最後に、プルリクエストで対処されたGitHub issueを更新し、フォローアップissueを作成するようCopilotに指示します。

プロンプト例5

プルリクエストで修正したGitHub issueを、変更を要約するコメントで更新してください。
残りのアクセシビリティ作業用に提案したフォローアップissueを作成してください。

期待される応答

CopilotはGitHub MCPサーバーから必要なツールを使用する許可を求めます。その後、詳細なコメントでGitHub issueを更新し、残りの作業用の構造化されたフォローアップissueを作成します。

例えば、Copilotは調査ステップで最初に識別された色のコントラストissueにコメントを追加します：

コメント付きで更新されたissue:

Issue #134: "ダッシュボードテキストのコントラスト比が4.5:1未満"
コメント: "PR #213でvariables.scssのテキストカラー変数とDashboardCardコンポーネントを
更新することで修正しました。すべてのダッシュボードテキストが4.5:1のコントラスト比を満たし、
自動テストで検証済みです。"

最終チェックポイント
プルリクエストを確認し、必要な調整を行います。変更が有効であることを確認したら、他のプルリクエストと同様にマージできます。また、作成されたフォローアップissueが適切かどうかも確認してください。

4. 実際に試してみる

GitHub Copilot Skillsの「Integrate MCP with GitHub Copilot」演習を試すことで、MCPとGitHub Copilotの統合を実践的に体験できます。

5. まとめ

GitHub CopilotのエージェントモードとMCPの組み合わせは、開発ワークフローの自動化において実用的な選択肢を提供します。この記事で紹介したアクセシビリティ対応の例は、調査、計画、実装、テスト、ドキュメント更新という一連の流れを、複数のツールをシームレスに連携させながら進められることを示しています。

重要なのは、この仕組みが開発者の判断を置き換えるものではなく、繰り返しの作業を削減し、各フェーズで適切な情報を提供することで、開発者がより高度な意思決定に集中できるようにする点です。

適切なMCPサーバーの選択、明確なプロンプトの設計、セキュリティの考慮を組み合わせることで、実際の開発現場で効果的に活用できるワークフローを構築できます。