8月5日、Microsoft Agent Frameworkが「Build Production-Ready Agents with the GitHub Copilot Harness and Agent Framework」と題した記事を公開した。エージェントにシェル実行やファイル操作の能力を与えたとき、「何を・いつ・誰の許可で実行するか」を制御できなければ本番投入は難しい。この統合が解決しようとしているのはまさにその問題で、デフォルトでは何も自動実行されない「許可しなければ何もしない」設計を軸に、GitHub CopilotのエージェントループへMicrosoft Agent Frameworkのガバナンス層を重ね合わせる仕組みが提供された。
GitHub Copilot AgentがAgent Frameworkに統合
GitHub Copilotはすでにコーディング向けのエージェントループ(モデル呼び出し、ツール実行、計画、セッション管理)を内部に持っている。今回の発表は、そのCopilot側のループをそのまま活かしつつ、Microsoft Agent Frameworkが持つ観測性・ミドルウェア・承認ワークフロー・エンタープライズガバナンスを重ね合わせられるようになったというものだ。
.NETとPythonの両方で安定版(stable)としてリリースされており、すぐに本番投入できる。なお元記事執筆時点のバージョン番号については、各パッケージのリリースノート(.NET・Python)で確認されたい。
コードはシンプルだ。.NETの場合:
using GitHub.Copilot;
using GitHub.Copilot.Rpc;
using Microsoft.Agents.AI;
await using CopilotClient copilotClient = new();
await copilotClient.StartAsync();
SessionConfig sessionConfig = new()
{
OnPermissionRequest = (request, invocation) =>
Task.FromResult(PermissionDecision.ApproveOnce()),
};
AIAgent agent = copilotClient.AsAIAgent(sessionConfig, ownsClient: true);
AgentResponse response = await agent.RunAsync("Summarize what this project does.");
Console.WriteLine(response);
Pythonも同様に数行で書ける。ストリーミングも.NETはRunStreamingAsync()、Pythonはrun(..., stream=True)で対応している。
「許可しなければ何もしない」設計
エージェントにシェル実行・ファイル操作・URL取得といったシステムレベルの能力を与えると、安全性が問題になる。この統合で重要なのは、すべての操作がパーミッションハンドラーを通じてゲートされる設計だ。
- シェル実行 — コマンド・スクリプトの実行
- ファイル操作 — 既存ファイルの読み取りと新規ファイルの書き込み
- URLフェッチ — Webコンテンツの取得と処理
それぞれの操作はエージェントが要求を投げ、開発者が用意したハンドラーが承認・拒否を返す。デフォルトでは何も自動で実行されない。本番環境で「エージェントが勝手に動く」ことへの不安を制度的に排除している点は実用上の強みだ。
def approve_and_log(request, context):
if request.kind == "shell":
print(f"[Permission: {request.kind}] {getattr(request, 'full_command_text', '')}")
return PermissionHandler.approve_all(request, context)
return PermissionDecisionUserNotAvailable()
承認が必要なカスタムツールは、.NETではApprovalRequiredAIFunctionでラップし、Pythonではapproval_mode="always_require"を宣言することで同じ承認フローに乗る。
MCPサーバーとカスタムツールの追加
Model Context Protocol(MCP)サーバーをローカル(stdio)またはリモート(HTTP)で接続できる。記事ではfilesystemサーバーとMicrosoft LearnのドキュメントAPIの例が示されている。
mcp_servers = {
"filesystem": {
"type": "stdio",
"command": "npx",
"args": ["-y", "@modelcontextprotocol/server-filesystem", "."],
"tools": ["*"],
},
"microsoft-learn": {
"type": "http",
"url": "https://learn.microsoft.com/api/mcp",
"tools": ["*"],
},
}
独自のPython関数をツールとして登録することも可能で、これらもCopilot SDKのpre-tool-useフックを通じて承認フローに統合される。
セッション管理とプロジェクトガイドライン
セッションは自動生成されるが、セッションIDを使って会話を再開することもできる。新しいエージェントインスタンスからでも既存のセッションに復帰できるため、複数ターンにわたるワークフローを構築しやすい。
また、.copilot/instructionsやdocs/agent-guidelinesといったディレクトリを指定して、プロジェクト固有またはチーム共有のガイドラインをエージェントに読み込ませる機能も備わっている。
観測性とOpenTelemetry
GitHub Copilot AgentはAgent FrameworkのOpenTelemetryトレーシングに参加する。他のエージェントプロバイダーと同じトレース・テレメトリが得られるため、マルチエージェント構成でも一元的なモニタリングが可能だ。
特にマルチエージェント構成でのデバッグにおいて、OpenTelemetryトレーシングの恩恵は大きい。複数のエージェントが協調して動作する場合、どのエージェントがいつ・どのツールを呼び出し・どこで承認待ちになったかを単一のトレースとして追跡できる。問題が発生した際に「どのエージェントのどのステップで止まったか」を分散ログの海から探す手間が省け、デバッグサイクルを大幅に短縮できる。Agent Frameworkがサポートする他のエージェントプロバイダー(Azure OpenAI、Anthropicなど)と同じ計装基盤を共有しているため、ハーネスをCopilotに切り替えてもダッシュボードやアラート設定を作り直す必要がない点も実運用上の利点だ。
セットアップ要件とサンプル
動作には認証済みのGitHub Copilot CLIとアクティブなGitHub Copilotサブスクリプションが必要だ。.NETは8以上、Pythonは3.11以上が対象となる。
# .NET
dotnet add package Microsoft.Agents.AI.GitHub.Copilot
# Python
pip install agent-framework-github-copilot
主要な環境変数は以下のとおり:
| 変数名 | 説明 | デフォルト |
|---|---|---|
GITHUB_COPILOT_CLI_PATH |
Copilot CLI実行ファイルのパス | copilot |
GITHUB_COPILOT_MODEL |
使用するモデル識別子(※元記事の例示をそのまま掲載。例: gpt-5, claude-sonnet-4) | サーバーデフォルト |
GITHUB_COPILOT_TIMEOUT |
リクエストタイムアウト(秒) | 60 |
GITHUB_COPILOT_BASE_DIRECTORY |
CLIセッション状態と設定のディレクトリ | ~/.copilot |
実行可能なサンプルは以下で公開されている:
- .NET: samples/02-agents/AgentProviders/github-copilot
- Python: samples/02-agents/providers/github_copilot
なお、よりカスタマイズ可能なハーネスを自前で組み立てたい場合は、Build your own claw and agent harnessシリーズが.NETとPython両方のステップバイステップ解説を提供している。
詳細はBuild Production-Ready Agents with the GitHub Copilot Harness and Agent Frameworkを参照していただきたい。