🌟
GitHub Copilot カスタムエージェントでつくる「なんちゃって Deep Research」エージェント

2025/12/04に公開
2025/12/08
GitHub Copilot
Deep research
tech
「Azure Container Apps の最新機能について調べてまとめて」
そんな一言から、こんなレポートが出来上がったら便利だと思いませんか？
Azure Container Apps 調査レポート（サンプル）
この記事では、GitHub Copilot のカスタムエージェントと MS Learn MCP Server を組み合わせて、こうした「なんちゃって Deep Research」エージェントを作る方法を紹介します。

 1. Deep Research とは？LangChain のブログによると、Deep Research エージェントには「詳細なシステムプロンプト」「計画ツール」「サブエージェント」「ファイルシステム」という 4 つの主要な構成要素があります。通常の AI チャットとの違いは次のとおりです。

計画を立てる: 何を調べるべきかを最初に整理する

反復的に検索する: 1 回の検索で終わらず、不足があれば追加で調べる

構造化された出力: 単なる回答ではなく、レポート形式でまとめる
本記事では、これらの要素を GitHub Copilot のカスタムエージェントで「なんちゃって」再現してみます。本格的な実装ではありませんが、日常の調査業務には十分使えるレベルのものができあがります（例: 1 回のプロンプトで 30 分自走して調査 ⇒ 2,792 行、9,212 ワード、89.224 文字の Markdown レポートを生成）。

 2. 使用する技術スタック今回使うのは以下の 2 つです。

 GitHub Copilot カスタムエージェントGitHub Copilot 拡張機能に搭載されているエージェントモードを使います。通常のチャットモードと異なり、ファイル編集や外部ツール呼び出しが可能です。また、GitHub Copilot では、.github/agents/ 配下に Markdown ファイルを置くことで、独自のエージェントを定義できます。プロンプト、使用ツール、振る舞いをカスタマイズ可能です。
https://code.visualstudio.com/docs/copilot/customization/custom-agents

 MS Learn MCP ServerMicrosoft が公式に提供している MCP（Model Context Protocol）サーバーです。認証不要・無料で利用でき、以下の 3 つのツールが提供されています。


ツール名
説明


microsoft_docs_search
Microsoft 公式ドキュメントを意味検索

microsoft_docs_fetch
指定した URL のドキュメントを Markdown で取得

microsoft_code_sample_search
公式コードサンプルを検索

Azure、.NET、Power Platform など Microsoft 技術の調査にはうってつけです。
https://learn.microsoft.com/ja-jp/training/support/mcp

 3. 環境構築
 3.1. VS Code と GitHub Copilot のセットアップVS Code に GitHub Copilot 拡張機能がインストールされていることを確認してください。エージェントモードを使うには、Copilot Chat 拡張機能も必要です。

 3.2. MS Learn MCP Server の設定VS Code の設定から MCP Server を追加します。コマンドパレット（Ctrl+Shift+P）を開き、「MCP: Add Server」を選択して、以下の情報を入力します。

Type: HTTP

URL: https://learn.microsoft.com/api/mcp

Server ID: microsoft-learn（任意の名前）
または、.vscode/mcp.json を作成して以下のように記述します。
{
  "servers": {
    "microsoft.docs.mcp": {
      "type": "http",
      "url": "https://learn.microsoft.com/api/mcp"
    }
  }
}

 4. リサーチエージェントを作るそれでは本題のカスタムエージェントを作っていきましょう。

 エージェント定義ファイル.github/agents/research.agent.md を作成します。
---
name: DeepResearchAgent
description: Assist users in researching a given topic.
tools:
  ["edit", "search", "microsoft.docs.mcp/*", "fetch", "todos", "runSubagent"]
---

指定されたトピックについての調査を行ってください。情報（事実）の収集が目的で、網羅性が重要です。

## 手順 (#tool:todos)

1. `research/` を確認し、過去の調査と重複しないことを確認する。重複があれば、ユーザーの指示を仰ぐ。
2. 必要な調査の観点（例: 定義確認、学術文献調査、最新動向把握など）をリストアップする。
3. 観点ごとに、 #tool:runSubagent で調査サブエージェントを複数実行する。
4. #tool:runSubagent で評価サブエージェントを実行する。
5. 改善ポイントがあれば、ステップ 2 に戻る。なければステップ 6 に進む。
6. 調査が完了したら、ユーザーに報告する。

## 注意

- 調査レポートにはに調査日を記録してください。
- 信ぴょう性が重要なので、一般的でない事実について脚注を使用してください。

  ```md
  調査結果の本文。[^1]

  [^1]: 参考文献の詳細情報。
  ```

- 調査内容に推論や意見を含めないでください。事実のみの提供です。
- 調査結果は人間が読むものではなく、データとしての利用を目的としています。過剰な装飾や冗長な説明は避けてください。

## サブエージェント定義

### 調査サブエージェント

- 目的: 指定されたトピックと観点で情報を検索し、調査レポートを作成/更新する。
- 入力:
  - トピック: <調査対象のトピック>
  - 観点: <調査の観点や焦点>
- 出力: NULL
- 手順:
  - 指定されたトピックと観点に基づき、関連情報を検索する。
  - 検索結果を分析し、重要な情報を抽出する。
  - 抽出した情報を整理し、レポートを `research/YYYY-MM-DD-<slug>.md` に記録する。
- ツール:
  - `edit`
  - `search`
  - `microsoft.docs.mcp/*`
  - `fetch`
  - `todos`

### 評価サブエージェント

- 目的: レポートファイルの内容を分析し、情報の抜け漏れや追加調査が必要な箇所を特定する。
- 入力:
  - パス: <レポートファイルへのパス>
  - トピック: <ユーザーが指定したトピック>
- 出力: 見つかった問題のリスト
- 手順:
  - レポートファイルを読み込み、内容を理解する。
  - 各セクションを批判的かつ中立的に評価し、問題（例: 情報の抜け、説明不足、引用不足、根拠のない断定）を特定する。
  - 見つかった問題を構造化して出力する。
- ツール:
  - `edit`
  - `search`
  - `fetch`
  - `todos`

 ポイント解説このエージェント定義にはいくつかの工夫があります。
ツールの指定方法
microsoft.docs.mcp/* のようにワイルドカードを使うと、MCP サーバーが提供するすべてのツール（microsoft_docs_search、microsoft_docs_fetch、microsoft_code_sample_search）を一括で指定できます。
runSubagent の活用
runSubagent は GitHub Copilot のエージェントモードで使える機能で、メインエージェントから別のエージェント（サブエージェント）を起動できます。これにより、コンテキスト汚染を防いだり、過去のコンテキストに影響されない中立的な状態でタスクを遂行できたりします。詳しくは GitHub Copilot の runSubagent を検証してみた：コンテキスト分離の効果と限界 を参照してください。
今回のエージェントでは、調査の観点ごとにサブエージェントを起動し、最後に評価用のサブエージェントで品質チェックを行う構成にしています。これは Deep Research における「反復的な調査」を模したものです。
todos ツール
進捗管理のために todos ツールを指定しています。エージェントが TODO リストを使って作業を追跡することで、複雑なタスクでも抜け漏れが減ります。

 5. リサーチエージェントを使う使い方は簡単です。
VS Code で Copilot Chat を開く
エージェントモードに切り替える
エージェント選択で「DeepResearchAgent」を選ぶ
調べたいトピックを入力する
Azure Container Apps の最新機能について調べてまとめて
実行すると、まずは調査の観点をリストアップしてくれます。
次に、各観点ごとに調査サブエージェントを呼び出してくれます。デバッグログを見ると、確かにいろいろとサブエージェントが呼び出されていることがわかります。
これらの調査サブエージェントは独立したコンテキスト ウィンドウを持つので、調べた MS Learn ドキュメントは通常メインエージェントやほかのサブエージェントと共有されません。しかし、レポートという中間生成物（ファイル）にオフロードされるので、コンテキスト汚染を抑えたまま情報共有をすることが実現できます。
また、実際にどの程度モデルが調査を実施してくれるかはモデルにかなり依存するところはあるのですが、Claude Opus 4.5 の場合だと以下のような呼び出しが行われていました。

調査が必要な観点: 7 個
サービス概要と最新更新
新機能・プレビュー機能
ネットワーキング機能
スケーリング機能
セキュリティ機能
開発者エクスペリエンス
料金・プラン


総ツール呼び出し回数:
Microsoft Docs Search: 14 回
Microsoft Docs Fetch: 24 回


使用トークン:
調査サブエージェント: 30,000 ~ 50,000 トークン
評価サブエージェント: 約 80,000 トークン

そして、評価エージェントでは以下のような問題点を指摘してくれました。


問題番号
セクション
重要度
説明


1
ネットワーキング
高
Resiliency Policies（リトライ、タイムアウト、サーキットブレーカー）はサービス間通信の信頼性向上に重要だが説明なし

2
信頼性・可用性
高
Availability Zones の設定方法、ゾーン障害時の動作、復旧プロセス等の詳細が不足

3
スケーリング
中
コールドスタート軽減策（ストレージマウントによる大容量ダウンロード管理、カスタム liveness プローブ等）の具体策が不足

4
AI 統合
中
Azure AI Foundry モデルデプロイの設定方法や制限事項の詳細が欠如

5
ヘルスプローブ
高
各プローブのデフォルト値（Startup: failureThreshold=240等）、推奨設定値が未記載

6
Java Components
中
Gateway for Spring は API ゲートウェイ機能を提供する重要コンポーネントだが未記載

7
最新更新
低
2025年の月次更新のタイトルのみで具体的な機能説明なし

8
Jobs
高
Jobs は Azure Container Apps の主要機能の一つだが、詳細セクションがない

9
Landing Zone
中
エンタープライズ導入に必要な Landing Zone Accelerator ガイダンスが欠落

10
Service Connector
低
Azure サービスとの接続を簡素化する機能の説明なし

評価サブエージェントの出力（フル）レポートファイル `2025-12-04-azure-container-apps-latest.md` を批判的に評価した結果、以下の問題を特定しました。

```
問題1: [ネットワーキング機能] - Resiliency Policies（サービスディスカバリ耐障害性ポリシー）の説明が欠落
問題2: [信頼性・可用性] - 独立した「信頼性・可用性」セクションが欠落（Availability Zones、災害復旧、計画メンテナンスの詳細説明不足）
問題3: [スケーリング機能] - 「Scale to Zero」時のコールドスタート軽減策の詳細が不十分（ストレージマウント活用等の具体策の説明不足）
問題4: [AI 統合機能] - Azure AI Foundry モデルデプロイ（プレビュー）の詳細説明が不足（サポートされるモデルタイプや設定方法の詳細が欠如）
問題5: [ヘルスプローブ] - 独立した「ヘルスプローブ」セクションが欠落（liveness/readiness/startup probes の詳細説明、デフォルト設定、推奨設定値の記載不足）
問題6: [Managed Java Components] - Gateway for Spring の説明が欠落（Eureka Server、Config Server、Admin for Spring は記載あるが Gateway for Spring が未記載）
問題7: [最新更新] - GitHub での 2025年のアナウンスメント詳細が欠落（リストアップされているが、各更新の具体的内容が記載されていない）
問題8: [Jobs機能] - Azure Container Apps Jobs の独立セクションが欠落（Manual/Scheduled/Event-driven の各ジョブタイプの詳細説明不足）
問題9: [Landing Zone Accelerator] - エンタープライズ向け Landing Zone Accelerator の説明が欠落（設計ガイドライン、参照アーキテクチャの記載なし）
問題10: [Service Connector] - Service Connector 機能の説明が欠落（Azure サービスとの接続簡素化機能の記載なし）
```

### 問題の詳細説明

| 問題番号 | セクション | 重要度 | 説明 |
|---------|-----------|--------|------|
| 1 | ネットワーキング | 高 | Resiliency Policies（リトライ、タイムアウト、サーキットブレーカー）はサービス間通信の信頼性向上に重要だが説明なし[^WAF] |
| 2 | 信頼性・可用性 | 高 | Availability Zones の設定方法、ゾーン障害時の動作、復旧プロセス等の詳細が不足[^Reliability] |
| 3 | スケーリング | 中 | コールドスタート軽減策（ストレージマウントによる大容量ダウンロード管理、カスタム liveness プローブ等）の具体策が不足[^ColdStart] |
| 4 | AI 統合 | 中 | Azure AI Foundry モデルデプロイの設定方法や制限事項の詳細が欠如[^GPU] |
| 5 | ヘルスプローブ | 高 | 各プローブのデフォルト値（Startup: failureThreshold=240等）、推奨設定値が未記載[^HealthProbes] |
| 6 | Java Components | 中 | Gateway for Spring は API ゲートウェイ機能を提供する重要コンポーネントだが未記載[^JavaOverview] |
| 7 | 最新更新 | 低 | 2025年の月次更新のタイトルのみで具体的な機能説明なし |
| 8 | Jobs | 高 | Jobs は Azure Container Apps の主要機能の一つだが、詳細セクションがない[^Jobs] |
| 9 | Landing Zone | 中 | エンタープライズ導入に必要な Landing Zone Accelerator ガイダンスが欠落[^LZA] |
| 10 | Service Connector | 低 | Azure サービスとの接続を簡素化する機能の説明なし |

### 出典URL

[^WAF]: https://learn.microsoft.com/en-us/azure/well-architected/service-guides/azure-container-apps#reliability
[^Reliability]: https://learn.microsoft.com/en-us/azure/reliability/reliability-container-apps
[^ColdStart]: https://learn.microsoft.com/en-us/azure/container-apps/cold-start
[^GPU]: https://learn.microsoft.com/en-us/azure/container-apps/gpu-serverless-overview
[^HealthProbes]: https://learn.microsoft.com/en-us/azure/container-apps/health-probes
[^JavaOverview]: https://learn.microsoft.com/en-us/azure/container-apps/java-overview
[^Jobs]: https://learn.microsoft.com/en-us/azure/container-apps/jobs
[^LZA]: https://learn.microsoft.com/en-us/azure/cloud-adoption-framework/scenarios/app-platform/container-apps/landing-zone-accelerator
主に項目が不足しているという点での評価でしたね。この辺りは評価サブエージェントの定義をいろいろチューニングしてみると、指摘結果も変わります。自分の感性に合わせて調整してみてください。
そして評価の後は、再調査が実施され冒頭に示したレポートが最終的に完成します。
ちなみに、すべての実行時間を合わせるとおおよそ 30 分程度時間がかかりました。30 分自走させて Premium リクエスト 1 回の消費で済むのはお財布にも優しいですし、何より手間がかからないのが嬉しいですね。
https://github.com/openjny/github-copilot-custom-deep-research/blob/main/research/2025-12-04-azure-container-apps-latest.md

 6. なぜサブエージェントを使うのかこの調査エージェントでは runSubagent を多用していますが、理由がいくつかあります。

 コンテキスト汚染の防止調査系のタスクでは、エージェントのコンテキストがすぐに汚染されます。検索結果、取得したドキュメント、中間的なメモ……これらがコンテキストに蓄積されると、エージェントの判断が鈍ってきます。「さっき読んだ情報」に引きずられて、本来調べるべきことを見落としたり、偏った結論を出したりしがちです。
Manus AI のブログで紹介されてる通り、このコンテキスト管理を「コンテキストエンジニアリング」と呼び、エージェント設計における本質的な課題として位置づけています。サブエージェントは独立したコンテキストで動作するため、この問題を回避できます。各サブエージェントは「自分の観点」だけに集中し、クリーンな状態で調査を行います。調査結果はファイルに書き出され、メインエージェントはそのファイルだけを見ればよいのです。

 評価の客観性確保評価サブエージェントを別プロセスにしているのにも理由があります。もしメインエージェントが自分で書いたレポートを自分で評価したら、どうなるでしょうか。「自分が調べた情報は十分だ」というバイアスがかかり、問題を見逃しやすくなります。
評価サブエージェントは、調査プロセスを一切知らない「第三者の目」として機能します。レポートファイルだけを見て、純粋に情報の抜け漏れや論理の飛躍を指摘できるのです。Anthropic のマルチエージェント研究でも、このようなオーケストレーター・ワーカーパターンが採用されており、品質担保の重要な要素となっています。
これらのような話は以前の記事『GitHub Copilot サブエージェントによるオーケストレーター パターンの実践』でも紹介しているので、興味があれば参照してください。

 7. 工夫ポイント
 サブエージェントの定義をプロンプトに含める今回のエージェントでは、サブエージェントの定義をメインエージェントのプロンプト内に記述しています。GitHub Copilot の runSubagent はプロンプトで指示した内容を解釈して動作するためです（外部エージェントを呼び出せない）。
今回のものはこれでよいですが、プロンプトがが大きくなってきてメンテナンスが難しい場合は、サブエージェント定義を外部化することを検討してください。サブエージェント用の .agent.md ファイルを別途作成し、そのパスをメインエージェントのプロンプトで指定します（参考)。

 過去の調査との重複チェックプロンプトの最初で research/ ディレクトリを確認するよう指示しています。同じトピックを何度も調査してしまうのを防ぐためです。過去のレポートが見つかった場合は、ユーザーに確認を求めるようにしています。

 ファイルシステムの有効活用ファイルシステムは最高のコンテキストエンジニアリング基盤です。コンテキストが膨らんできそうなタイミングでファイルにオフロードするという意識を持てば、自然とどの単位で（責任分解で）サブエージェント化すればよいか見えてきます。
また、ファイルシステムの素晴らしい点は階層化（グルーピング）にあるので、これを適切に活用することも意識します。特定の階層化において一意に意味が定まる名前をファイル名につけることも忘れないようにしてください。

 8. 注意すること何回も Microsoft Learn MCP を呼び出すことになるので、レート制限には注意してください。外部サービスに依存する場合は、障害時のフォールバック戦略も考慮しておくとよいでしょう。
また、実際の活用を考えると、個人的には「要件定義」エージェントを導入して、調査の前に使うことをお勧めします。この記事で紹介した「ACA の最新機能を調べてくれ」というのはあまりに乱暴なトピック指定で、本来であれば目的（何のための調査か）、受け入れ条件（どういう情報が含まれるべきか）のような情報があるべきだからです。ChatGPT の Deep Research などでも同じような機能がありますよね。

 9. まとめGitHub Copilot のカスタムエージェントと MS Learn MCP Server を組み合わせることで、Microsoft 技術に特化した「なんちゃって Deep Research」が実現できました。
todos を使うとか、フローを示すみたいなことは色んな所で見るテクニックになってきたかなと思いますが、今回紹介したエージェントの特徴をまとめると以下の2点です:

サブエージェントの活用: コンテキスト汚染を防ぎ、評価エージェントの中立性を高める

ファイルシステムによるサブエージェント間通信: ファイルを活用して必要な情報だけをやりとりさせる
本格的な Deep Research と比べると、複雑な推論や長時間の調査には向きませんが、日常的な技術調査には十分なレベルです。何より、VS Code と GitHub Copilot だけで完結するので、追加のセットアップがほとんど不要なのがポイントです。
ぜひ自分の業務に合わせてエージェントをカスタマイズしてみてください。

 10. 参考リンクMicrosoft Learn MCP Server 概要
GitHub Copilot カスタムエージェント
MCP Server GitHub リポジトリ
MCP 公式サイト

LangChain: Deep Agents - Deep Research エージェントの構成要素を解説

Anthropic: Multi-Agent Research System - マルチエージェント設計の実践例

Manus: Context Engineering for AI Agents - コンテキストエンジニアリングの知見

How Deep Research Works - Deep Research の動作原理
ツール名	説明
`microsoft_docs_search`	Microsoft 公式ドキュメントを意味検索
`microsoft_docs_fetch`	指定した URL のドキュメントを Markdown で取得
`microsoft_code_sample_search`	公式コードサンプルを検索
問題番号	セクション	重要度	説明
1	ネットワーキング	高	Resiliency Policies（リトライ、タイムアウト、サーキットブレーカー）はサービス間通信の信頼性向上に重要だが説明なし
2	信頼性・可用性	高	Availability Zones の設定方法、ゾーン障害時の動作、復旧プロセス等の詳細が不足
3	スケーリング	中	コールドスタート軽減策（ストレージマウントによる大容量ダウンロード管理、カスタム liveness プローブ等）の具体策が不足
4	AI 統合	中	Azure AI Foundry モデルデプロイの設定方法や制限事項の詳細が欠如
5	ヘルスプローブ	高	各プローブのデフォルト値（Startup: failureThreshold=240等）、推奨設定値が未記載
6	Java Components	中	Gateway for Spring は API ゲートウェイ機能を提供する重要コンポーネントだが未記載
7	最新更新	低	2025年の月次更新のタイトルのみで具体的な機能説明なし
8	Jobs	高	Jobs は Azure Container Apps の主要機能の一つだが、詳細セクションがない
9	Landing Zone	中	エンタープライズ導入に必要な Landing Zone Accelerator ガイダンスが欠落
10	Service Connector	低	Azure サービスとの接続を簡素化する機能の説明なし
1. Deep Research とは？

2. 使用する技術スタック

GitHub Copilot カスタムエージェント

MS Learn MCP Server

3. 環境構築

3.1. VS Code と GitHub Copilot のセットアップ

3.2. MS Learn MCP Server の設定

4. リサーチエージェントを作る

エージェント定義ファイル

ポイント解説

5. リサーチエージェントを使う

6. なぜサブエージェントを使うのか

コンテキスト汚染の防止

評価の客観性確保

7. 工夫ポイント

サブエージェントの定義をプロンプトに含める

過去の調査との重複チェック

ファイルシステムの有効活用

8. 注意すること

9. まとめ

10. 参考リンク

Discussion
