🦦
GitHub Copilot SDK/CLI - A2A Kubernetes マルチエージェントシステム実行ガイド

2026/05/06に公開
テーマ「GitHub Copilot 活用選手権」
 はじめにこのガイドでは、GitHub Copilot SDKとKubernetes、A2A（Agent2Agent）プロトコルを使ったマルチエージェントシステムの構築方法について説明します。

GitHub Copilot SDKはGitHub Copilotの機能を自身のアプリケーションに組み込むためのSDKです。また、SDKを利用するにあたってはGitHub Copilot CLIをインストールする必要があります。
なお、このガイドで取り扱うA2A構成およびマルチエージェントに関する内容はGitHub Copilot Dev Days Tokyo- .NETラボ 勉強会 2026年4月の勉強会で扱ったものです。より詳細な内容やアーキテクチャについては、勉強会資料も併せてご参照ください。
参考資料
GitHub Copilot SDKによるマルチコーディングエージェントシステムの開発

 前提条件このガイドを進める前に、以下の環境が整っていることを確認してください。
GitHub Copilot CLI
GitHub Copilot SDK
0.2.2 以降

Kubernetes
Rancher DesktopからKubernetesをインストール、kubectlが使用可能な状態にしておくこと


 アーキテクチャ概要複数のCopilotサーバーが相互に接続するAgent2Agent (A2A) アーキテクチャを実装します。

各エージェントは独自の能力を持ち、Dispatcherがクライアントからのリクエストを受け取り、能力に基づいて適切なエージェントにルーティングします。
具体的には以下のような構成です。
┌─────────────────┐
│   Dispatcher    │  ← クライアントからのリクエストを受信
│   (Port 8000)   │     能力ベースでエージェントにルーティング
└────────┬────────┘
         │
         ├─────────────┬─────────────┐
         ▼             ▼             │
    ┌─────────┐  ┌──────────┐        │
    │ Weather │  │Calculator│        │
    │  Agent  │  │  Agent   │        │
    │(Port8001)│  │(Port8002)│       │
    └─────────┘  └──────────┘        │
    get_weather   calculate +        │
                 convert_currency    ▼
                                拡張可能
                                (File Ops, Translation等)
各エージェントは独自の能力を持ち、クライアントからのリクエストに応じて適切なエージェントが処理を担当します。dispatcherはリクエストの内容を解析し、必要な能力に基づいてエージェントにルーティングします。
Weather
天気情報を提供するエージェント

Calculator
計算や通貨変換を行うエージェント

新しいエージェントを追加する際はService単位でエージェントを構築することで拡張できます。
このアーキテクチャの特徴は以下の通りです。
自動エージェント検出
Kubernetes上の各Podがapp=a2a-agentラベルで自動検出される

能力ベースルーティング
各エージェントが公開するagent-card.jsonに基づいてリクエストをルーティング

独立したツールセット
各エージェントは独自のカスタムツールを持つ

スケーラブル
新しいエージェントを追加するには、ラベルを付けてデプロイするだけ


 なぜ、Agent2Agent プロトコル（A2A）構成なのかA2A構成は複数のエージェントが相互に接続し、協力してタスクを処理するアーキテクチャパターンです。これにより、以下のようなメリットがあります。
専門性の分離
各エージェントが特定の能力やドメインに特化できるため、より高度な機能を提供できる。

柔軟な拡張性
新しいエージェントを追加する際に、既存のエージェントやシステム全体に影響を与えることなく、独立して開発・デプロイが可能。

障害の分離
あるエージェントが障害を起こしても、他のエージェントが正常に動作し続けることができるため、システム全体の信頼性が向上する。

協調動作
エージェント同士が協力してタスクを処理することができるため、複雑なタスクやマルチステップの処理を効率的に行うことができる。


 デプロイ手順おおまかな手順は以下の通りです。GitHub側の準備は認証のみです。
GitHubの認証
イメージのビルド
Kubernetes namespaceの作成
Kubernetes Secretを作成
環境変数 COPILOT_MODELの設定
GitHub Copilot SDKベースのエージェントをデプロイ
マルチエージェントの動作確認
Aspireで可視化してみよう
AgentCard Viewerを起動してAgentCardをチェック
(Option) Prometheus と Grafanaを利用してメトリクスを可視化
おわり：Resourceの片付け
項番10は必須ではありませんが、Kubernetes上でエージェントを動作させる際の可観測性の担保方法の一例として紹介します。
1番〜10番も含めてデプロイを行うと以下のような構成が構築できます。
※11番はリソースの削除です。

 セットアップ手順ハンズオンに必要なリソースはリポジトリに含まれています。次の手順でセットアップを行ってください。

 リポジトリのクローンまずは今回利用するリポジトリをクローンします。
git clone https://github.com/ymd65536/GitHubCopilotSDK.git
GitHub CLIでクローンする場合は以下のとおりです。
gh repo clone ymd65536/GitHubCopilotSDK
ディレクトリを移動します。
cd GitHubCopilotSDK
これでセットアップは完了です。次のセクションから実際のデプロイ手順を説明していきます。

 1. GitHub認証GitHub Copilot SDKを使用するには、GitHub認証が必要です。

 GitHub CLIで認証GitHub CLIを使用すると、トークンが自動的に管理されます。

以下のコマンドを実行して認証を行ってください。
※clipboardオプションを使用することで、ブラウザでの認証後にトークンが自動的にクリップボードにコピーされるため、手続きがスムーズになります。
gh auth login --clipboard
対話形式で以下を選択：
What account do you want to log into? → GitHub.com
What is your preferred protocol for Git operations? → HTTPS または SSH
Authenticate Git with your GitHub credentials? → Yes
How would you like to authenticate GitHub CLI? → Login with a web browser

 2. イメージのビルド認証が完了したら、Kubernetes上で動作するエージェントのDockerイメージをビルドします。

ディレクトリに移動して、以下のコマンドを実行してください。
cd k8s_copilot
bash scripts/build-images.sh
実行結果（一部）
=== Built Images ===
a2a-agent                                                latest                 9020fbb758fd   2 seconds ago    1.03GB
a2a-dispatcher                                           latest                 017921f69777   49 seconds ago   221MB

✓ All images built successfully!

Next steps:
  1. Create GitHub token secret: kubectl create secret generic github-token --from-literal=token=YOUR_TOKEN -n a2a-copilot
  2. Deploy to Kubernetes: bash scripts/deploy.sh
ビルドされたイメージを確認するため、以下のコマンドを実行してください。
docker images
実行結果（一部）

※イメージIDや作成時間は環境によって異なります。
k8s_copilot $ docker images
REPOSITORY                                               TAG                    IMAGE ID       CREATED              SIZE
a2a-agent                                                latest                 9020fbb758fd   37 seconds ago       1.03GB
a2a-dispatcher                                           latest                 017921f69777   About a minute ago   221MB

 3. Kubernetes namespaceの作成イメージがビルドできたら、Kubernetes上にnamespaceを作成します。このガイドでは a2a-copilot というnamespaceを使用します。
kubectl apply -f k8s/namespace.yaml
これで、a2a-copilot namespaceが作成されました。以降のリソースはすべてこのnamespaceにデプロイされます。

 4. Kubernetes Secretを作成gh auth tokenで取得したトークンを使用して、Kubernetes Secretを作成します。

これによりKubernetes上のGitHub Copilot CLIがGitHubにアクセスできるようになります。
kubectl create secret generic github-token --from-literal=token=$(gh auth token) -n a2a-copilot

 5. Copilotモデルの指定（任意）Copilot CLI/SDK が使用するモデルは環境変数 COPILOT_MODEL で指定できます。

このA2A構成では、各Deployment（Dispatcher / Weather Agent / Calculator Agent）に以下を設定しています：
COPILOT_MODEL=gpt-5-mini
別のモデルを使いたい場合は、以下のマニフェストの env: を変更して再デプロイしてください。
k8s/dispatcher.yaml
k8s/weather-agent.yaml
k8s/calculator-agent.yaml

 6. GitHub Copilot SDKベースのエージェントをデプロイここまで準備ができたら、いよいよエージェントをKubernetesにデプロイします。マニフェストを適用します。
kubectl apply -f k8s/calculator-agent.yaml
kubectl apply -f k8s/dispatcher.yaml
kubectl apply -f k8s/weather-agent.yaml
これで、Dispatcher、Weather Agent、Calculator Agentの3つのエージェントがKubernetes上にデプロイされます。

 7. マルチエージェントの動作確認では、エージェントが正しく動作しているか確認してみましょう。

 Podの状態を確認以下のコマンドを実行して、a2a-copilot namespaceのPodの状態を確認します。
kubectl get pods -n a2a-copilot
実行結果
k8s_copilot $ kubectl get pods -n a2a-copilot

NAME                                READY   STATUS    RESTARTS   AGE
calculator-agent-855f846dd9-mkwv4   1/1     Running   0          30s
dispatcher-68d9f45cd9-pmzvf         1/1     Running   0          30s
weather-agent-5574c5544f-ldxst      1/1     Running   0          30s
すべてのPodが Running 状態になりました。

 エージェントの一覧を取得する別のターミナルで以下のコマンドを実行してエージェントをポートフォワードします。
kubectl port-forward svc/dispatcher-svc 8000:8000 -n a2a-copilot
つぎにDispatcherがエージェントを正しく検出しているか確認します。
curl http://localhost:8000/agents
実行結果（整形済）[
    {
        "endpoint": "http://weather-agent-svc:8001",
        "name": "Weather Agent",
        "description": "Provides weather information for cities worldwide",
        "capabilities": [
            "weather"
        ],
        "tools": [
            {
                "name": "get_weather",
                "description": "Get current weather for a city",
                "parameters": {
                    "city": {
                        "type": "string",
                        "description": "City name (e.g., Tokyo, Paris, New York)"
                    }
                }
            }
        ]
    },
    {
        "endpoint": "http://calculator-agent-svc:8002",
        "name": "Calculator Agent",
        "description": "Provides calculation and currency conversion capabilities",
        "capabilities": [
            "calculator"
        ],
        "tools": [
            {
                "name": "calculate",
                "description": "Calculate a mathematical expression",
                "parameters": {
                    "expression": {
                        "type": "string",
                        "description": "Mathematical expression (e.g., '15 * 23 + 100')"
                    }
                }
            },
            {
                "name": "convert_currency",
                "description": "Convert currency from one type to another",
                "parameters": {
                    "amount": {
                        "type": "number",
                        "description": "Amount to convert"
                    },
                    "from_currency": {
                        "type": "string",
                        "description": "Source currency code (USD, EUR, JPY, GBP, AUD)"
                    },
                    "to_currency": {
                        "type": "string",
                        "description": "Target currency code (USD, EUR, JPY, GBP, AUD)"
                    }
                }
            }
        ]
    }
]

 エージェントにリクエストを送るまずはWeather Agentにリクエストを送ってみましょう。以下のコマンドを実行してください。
curl -X POST http://localhost:8000/ask \
  -H "Content-Type: application/json" \
  -d '{
    "capability": "weather",
    "message": "What is the weather in Tokyo?"
  }'
実行結果
{
    "agent": "Weather Agent",
    "endpoint": "http://weather-agent-svc:8001",
    "response": "Fetching current weather for Tokyo using the built-in weather tool to provide fresh conditions.\n\nTokyo: 18°C, cloudy."
}
次にCalculator Agentにリクエストを送ってみましょう。以下のコマンドを実行してください。
curl -X POST http://localhost:8000/ask \
  -H "Content-Type: application/json" \
  -d '{
    "capability": "calculator",
    "message": "Calculate 15 * 23 + 100"
  }'
実行結果
{
    "agent": "Calculator Agent",
    "endpoint": "http://calculator-agent-svc:8002",
    "response": "15 * 23 = 345; 345 + 100 = 445\n\nResult: 445"
}
このような感じで、Dispatcherがリクエストを適切なエージェントにルーティングし、エージェントがリクエストを処理していることが確認できます。

 可観測性を高めるKubernetesでエージェントを動作させた場合、エージェントのログや状態をどのように可観測にするかが課題としてあります。
また、前述のようにcurlを直接送る方法はあくまで動作確認のためのものであり、実際にはどのような経路でリクエストが処理されているのか、どのエージェントがどのようなリクエストを処理しているのかを把握することが重要です。
さらに、リクエストの処理に失敗した場合、どのエージェントでエラーが発生しているのかを把握することも重要です。
つまり、たくさんのエージェントが動いている場合はどのエージェントがどのリクエストを処理しているのか、エラーが発生した場合はどのエージェントで発生しているのかを把握することが重要です。
そこで今回はMicrosoftがOSSとして提供しているAspireを利用して、エージェントのログや状態を可観測にする方法を紹介します。AspireにはAspire DashboardというWeb UIが提供されており、OpenTelemetryを利用して収集されたログやメトリクスを可視化できます。

 8. Aspireで可視化してみようそれでは実際にAspireを利用してエージェントのログや状態を可視化してみましょう。おおまかな手順は以下の通りです。
Aspireのイメージをpullする
Aspire Dashboardを起動する
Aspire Dashboardにアクセスしてログや状態を確認する
Aspire Dashboardはkubectlでマニフェストを適用するだけで起動できます。

 Aspire Dashboardの起動Aspire Dashboardを起動するにはマニフェストを適用します。以下のコマンドを実行してください。
# k8s_copilotディレクトリにいることを想定
kubectl apply -f k8s/aspire-dashboard.yaml
すると、aspire-dashboardというPodが起動します。以下のコマンドでPodの状態を確認してください。
kubectl get pods -n a2a-copilot
実行結果
NAME                                READY   STATUS    RESTARTS   AGE
aspire-dashboard-dc8ff7d77-cnmdh    1/1     Running   0          11s
Podが起動したら、ローカルホストにアクセスしてください。
localhost
Aspire DashboardのUIが表示されます。ここで、エージェントのログや状態を確認できます。
試しにWeather Agentにリクエストを送ってみましょう。以下のコマンドを実行してください。
curl -X POST http://localhost:8000/ask \
    -H "Content-Type: application/json" \
    -d '{
        "capability": "weather",
        "message": "What is the weather in New York?"
    }'
実行した結果をAspire Dashboardで確認してみましょう。Dispatcherがリクエストを受け取り、Weather Agentにルーティングしていることがわかります。また、Weather Agentがリクエストを処理している様子も確認できます。
Weather Agentは内部でGitHub Copilotを呼び出しているため、Copilotへのリクエストも確認できます。実際に確認してみます。ダッシュボード上でGitHub Copilotへのリクエストを出しているものをチェックします。以下の画像では5a0e084というIDのリクエストがWeather AgentからGitHub Copilotに出されていることがわかりますので、これをクリックしてみましょう。
※リクエストIDは実行タイミングによって異なります。
すると、Weather AgentからGitHub Copilotに出されたリクエストの内容を確認できます。リクエストの内容やCopilotからのレスポンスを確認できます。
少し画像が小さいので拡大してみましょう。リクエストの内容やレスポンスの内容を確認できます。

さらに細かくリクエストの内容を確認する場合はキラキラマークをクリックすることで確認が可能です。
今回はinvoke_agentというものについて見るため、invoke_agentのキラキラマークをクリックします。
すると、Weather AgentがGitHub Copilotに出したリクエストの内容をさらに細かく確認できます。インプットのトークン数やアウトプットのトークン数、Copilotが何ターンでレスポンスを返したのかなど、詳細な情報を確認できます。

 9. AgentCard Viewerを起動してAgentCardをチェック次に、Dispatcherがエージェントをどのように検出しているのかを確認してみましょう。DispatcherはKubernetes上のPodをラベルセレクターで検出し、各エージェントが公開するagent-card.jsonを取得することでエージェントの情報を把握しています。
このagent-card.jsonの内容を確認するためにAgentCard Viewerという.NET Blazorのアプリケーションを開発しました。AgentCard Viewerを使って確認してみましょう。

 AgentCard Viewerのセットアップ手順まずは、AgentCard Viewerのコードをクローンします。以下のコマンドを実行してください。
git clone https://github.com/ymd65536/AgentCardViewer.git
GitHub CLIでクローンする場合は以下のとおりです。
gh repo clone ymd65536/AgentCardViewer

 KubernetesのポートフォワードAgentCard ViewerはDispatcherの公開するエンドポイントから情報を取得するため、Dispatcherのポートをローカルにフォワードします。
まだポートフォワードしていない場合はターミナルを起動して以下のコマンドを実行してください。
kubectl port-forward svc/dispatcher-svc 8000:8000 -n a2a-copilot

 AgentCard Viewerの起動AgentCard Viewerは.NET Blazorのアプリケーションで、Kubernetes上のエージェントが公開するagent-card.jsonを取得して表示するものです。クローンしたら、以下のコマンドでアプリケーションを起動してください。
cd AgentCardViewer
dotnet run
アプリケーションが起動したら、ブラウザでlocalhost:5162にアクセスしてください。
http://localhost:5162/
Dispatcherが検出しているエージェントの情報をWeb画面で確認できます。

 10. Prometheus と Grafanaを利用してメトリクスを可視化Aspire DashboardとAgentCard Viewerを使って可視化する方法を紹介しましたが、さらにPrometheusとGrafanaを利用してメトリクスを可視化することもできます。これにより、エージェントのパフォーマンスやリクエストの処理状況などをリアルタイムで監視できます。
PrometheusとGrafanaを利用する場合は、以下の手順でセットアップを行ってください。
PrometheusとGrafanaのマニフェストを適用する
Prometheusでエージェントのメトリクスを収集する
Grafanaでダッシュボードを作成してメトリクスを可視化する
では、まずはPrometheusとGrafanaのマニフェストを適用してみましょう。以下のコマンドを実行してください。
# PrometheusとGrafanaのマニフェストを適用
kubectl apply -f k8s/prometheus.yaml
kubectl apply -f k8s/grafana.yaml
Podの状態を確認して、PrometheusとGrafanaが起動していることを確認してください。
kubectl get pods -n a2a-copilot
実行結果（一部）
grafana-85b785d45d-sm9mk            1/1     Running   0          41s
prometheus-7dcb8c8489-f2gj8         1/1     Running   0          41s
以下のエンドポイントにアクセスすることで、PrometheusとGrafanaのダッシュボードにアクセスできます。
Prometheus
Grafana

 Prometheus targetsが正しく設定されているか確認Prometheusのダッシュボードにアクセスして、Targetsのページを開いてください。エージェントのメトリクスが正しく収集されている場合は、以下のように表示されます。
3つのコンテナが表示されていることがわかります。これらはDispatcher、Weather Agent、Calculator Agentのメトリクスを収集しているものです。すべてのステータスがUPになっていることを確認してください。

 Grafanaでダッシュボードを作成してメトリクスを可視化次にGrafanaのダッシュボードを作成して、エージェントのメトリクスを可視化してみましょう。

まずはログイン画面にアクセスします。初期のユーザー名とパスワードは以下の通りです。
ユーザー名: admin
パスワード: admin
パスワードを変更するかどうか聞かれますが、今回はSkipを選択して先に進みます。
ログインができたら、Prometheusをデータソースとして追加します。以下のURLを開きます。
Add data source
一覧からPrometheusを選択します。
Add new data sourceをクリックします。
http://prometheus-svc:9090をURLに入力して、Save & Testをクリックします。
以下のようにSuccessfully queried the Prometheus API.と表示されれば、PrometheusとGrafanaの接続は成功です。
Successfully queried the Prometheus API.

Next, you can start to visualize data by building a dashboard , or by querying data in the Explore view .

 ダッシュボードの作成つぎにbuilding a dashboard from scratchをクリックして、ダッシュボードの作成を開始します。
New dashboardという文字が表示されます。この画面でダッシュボードが作成できます。
大きな+をクリックすると、グラフやテーブルなどのパネルを追加できます。今回はグラフを追加してみましょう。
パネルを追加するとConfigure visualizationというボタンが表示されるので、これをクリックします。
パネルの編集画面に遷移します。ここで、Prometheusにクエリを投げてメトリクスを取得できます。気になるメトリクスをクエリしたいところですが、ぱっと見ではどんなMetricsがあるかわかりません。
そんなときは前述のAspire Dashboardでエージェントにリクエストを送ったときのメトリクスを確認してみましょう。
例：localhostのAspire http.server.active_requestsのMetrics
※Grafanaのクエリ画面にはOpen metrics explorerという機能があるので、これを利用してもどんなMetricsがあるのか確認できます。

 11. おわり：Resourceの片付け最後に、今回作成したリソースを片付けましょう。以下のコマンドを実行して、a2a-copilot namespaceを削除してください。
kubectl delete namespace a2a-copilot
Podの状態を確認して、すべてのリソースが削除されたことを確認してください。
kubectl get pods -n a2a-copilot
実行結果
No resources found in a2a-copilot namespace.

 応用例をいくつか紹介ガイドは以上です。ここからはこれまでの構築を踏まえて、さらに発展させるための応用例をいくつか紹介します。

 BYOKを利用するGitHub Copilot CLIはBYOK（Bring Your Own Key）に対応しているため、独自の暗号化キーを使用して機密情報を保護できます。これにより、エージェントが処理するデータのセキュリティをさらに強化できます。
また、6月からプレミアムリクエストモデルからAIクレジット制度への移行が予定されており、BYOKを利用することでコスト管理の面でもメリットがあります。今回のガイドではBYOKの設定は行っていませんが、BYOKを利用する場合はGitHub Copilot CLIのドキュメントを参照して設定を行ってください。
参考：GitHub Copilot CLI での独自の LLM モデルの使用

 ローカルLLMを利用するGitHub Copilot CLIはローカルLLM（Local Large Language Model）にも対応しているため、ローカルで動作するLLMを利用してエージェントを構築することもできます。

ローカルLLMを利用することで、ネットワークの遅延を減らしたり、データのプライバシーを保護したりすることができます。
今回のガイドではローカルKubernetes上で通常のGitHub Copilotを利用する構成だったため、ローカルLLMの利用は行っていませんが

Copilot CLIをマルチエージェントで活用しつつ、ローカルLLMを利用する構成も十分に考えられます。
ローカルLLMを利用する場合はCOPILOT_OFFLINEをtrueに設定したうえで以下の設定も行う必要があります。
COPILOT_PROVIDER_BASE_URL
COPILOT_MODEL
COPILOT_PROVIDER_MAX_PROMPT_TOKENS
COPILOT_PROVIDER_MAX_OUTPUT_TOKENS
トークン数が多い処理はローカルLLMで処理して、トークン数が少ない処理は通常のCopilotで処理するなど、タスクの内容に応じて使い分けることも可能です。

 Copilot CLIを使った大規模なマルチエージェントパターンについて公式資料では、Copilot SDK/CLIを使った大規模なマルチエージェントパターンについても紹介されています。今回のガイドではKubernetes上でのA2A構成を紹介しましたが、それ以外にもいろいろなアーキテクチャが考えられます。ぜひ、公式資料も参照してみてください。
参考：Copilot SDK デプロイのスケーリング
また、今回のガイドについては登壇資料でもさらに詳細に解説しています。より深く理解したい方はぜひ登壇資料も参照してみてください。
参考：GitHub Copilot SDKによるマルチコーディングエージェントシステムの開発

 まとめ今回はGitHub Copilot SDKとKubernetes、A2Aプロトコルを使ったマルチエージェントシステムの構築方法について説明しました。GitHub Copilot SDKを利用することで、独自のエージェントを簡単に構築できます。
Kubernetes上でエージェントを動作させることで、スケーラブルなマルチエージェントシステムを構築できます。

A2A構成を採用することで、エージェント同士が協力してタスクを処理することができるため、複雑なタスクやマルチステップの処理を効率的に行うことができます。
また、A2AプロトコルによってGitHub Copilot SDK の具体的な実装を抽象化できるため、エージェントの実装を柔軟に差し替えや拡張できます。例えば、エージェントの能力を追加したり、エージェント同士の連携を強化したりすることが容易になります。
今回はCopilot CLIのサーバーモードを実行基盤としましたが、A2Aでサーバであれば、他の実行基盤を利用することも可能です。

例えば、サーバーレス環境やオンプレミスのサーバーなど、さまざまな環境でエージェントを動作させることもできます。Microsoft FoundryのHosted AgentやRunpod、他のサーバーレス環境を利用することで、さらにスケーラブルなマルチエージェントシステムを構築することも可能です。
※Microsoft FoundryのHosted Agentについては登壇資料がありますので、興味のある方はぜひ参照してみてください。
参考: AIエージェントをAzureにホイっとデリバリーできるMicrosoft Foundryの魔法があることを君たちはまだ知らない
さらに、Aspireを利用することで、エージェントのログや状態を可観測にすることもできるため、運用面でも安心です。今回のガイドを参考に、ぜひ独自のマルチエージェントシステムを構築してみてください。