Microsoft Agent Framework

Microsoft Agent Frameworkが選ばれる理由

Microsoft Agent Frameworkは、単一のプロンプトと応答だけで完結しない、より複雑なアプリケーション向けに設計されています。エージェントが状態（ステート）を保持し、複数のツールを呼び出し、承認を待ち、タスクを委譲し、中断後に復旧し、あるいは確実なコード実行とモデルによる判断を調整する必要がある場合に、その真価を発揮します。

このフレームワークは、MicrosoftのAutoGenおよびSemantic Kernelにおけるエージェント機能の直接的な後継です。実験的なマルチエージェント連携とエンタープライズ向けのアプリケーション統合のために別々の抽象化を維持するのではなく、Pythonと.NETで共通のプログラミングモデルとして統合されました。

既存のMicrosoftユーザーにとって、この位置づけは重要です。.NETチームは、慣れ親しんだ依存関係注入（DI）、Microsoft.Extensions.AIの抽象化、ASP.NET Coreによるホスティング、マネージドID、Azure Functions、OpenTelemetryをそのまま活用できます。Pythonチームも、C#ランタイムを強制されることなく、並行して同じエージェントやワークフローの概念を利用できます。

また、Azure以外の環境でも利用可能です。複数のモデルプロバイダーへの接続、ローカルでのOllamaの使用、独自のデータベース選択、標準プロトコルのエンドポイント公開、セルフホスト環境での実行が可能です。Microsoft Foundryは最も統合されたデプロイパスですが、コアSDKの使用に必須ではありません。

設計指針として重要なのは、「通常の関数で確実に解決できる問題にはエージェントを使わない」という点です。Microsoft Agent Frameworkは、開発者が「どこまでを確率的な推論に任せ、どこを確実なコードで制御するか」を厳密に定義したい場合に、強力なツールとなります。

主な開発フロー

実践的な実装は、通常、完全なマルチエージェントシステムではなく、単一のエージェントから始めます。開発者はモデルクライアントを選択し、限定的な指示セットを定義し、型定義された少数のツールを追加し、会話状態の保存方法を決定します。これにより、挙動、レイテンシ、トークン消費量、失敗パターンを測定できる基準が確立されます。

エージェントのキャラクター設定（ペルソナ）よりも、ツールの定義（コントラクト）に注意を払うべきです。各ツールには、正確な説明、検証済みのパラメータ、制限された権限、明示的なタイムアウト、予測可能なエラー結果を設定する必要があります。目的が限定された操作で十分な場合に、汎用的なデータベースやシェルインターフェースをモデルに与えるべきではありません。

次のステップは、追加の挙動を同じエージェント内に含めるか、明示的なワークフローとして切り出すかの判断です。自由度の高いタスク委譲はモデル駆動のままでも構いませんが、規制のある業務や反復的なビジネスプロセスは、グラフとして表現した方が監視やデバッグが容易になります。確実な実行プログラムをエージェントのステップ間に挟むことで、データの検証、ポリシーの適用、計算結果の算出などを行えます。

人間による介入（Human-in-the-loop）は、デプロイ後に追加するのではなく、設計段階で組み込むべきです。金銭の取引、アカウント変更、外部へのメッセージ送信、破壊的なファイル操作など、影響の大きいアクションの前には承認ゲートを設けるのが適切です。ワークフローは一時停止して状態を保存し、オペレーターの応答後に再開できます。

オブザーバビリティ（観測性）と評価（エバリュエーション）によって開発ループが完結します。トレースには、モデルの呼び出し、ツールの実行、ルーティングの決定、トークン使用量、レイテンシ、エラーを記録すべきです。また、モデルや指示、ツール、ワークフローの構成を変更した際に、単に応答が流暢になっただけでなく、意図した成果が向上したかをテストするための再現可能な評価セットを用意してください。

エージェント vs 明示的なワークフロー

タスクが会話形式であり、利用可能なアクションが限定されており、モデルが次に何をすべきかを妥当に判断できる場合は、個別のエージェントが適しています。例えば、知識ソースに基づいた質問回答、複数の検索ツールからの選択、ユーザーからの不足情報の収集などが挙げられます。

一方、アプリケーションに必須のステージ、固定の承認、分岐するビジネスルール、またはモデルの判断に委ねられない義務がある場合は、ワークフローが推奨されます。請求処理を例に挙げると、非定型な説明の解釈にはエージェントを使い、ポリシーデータの検証には確実なコードを用い、勧告案の作成に別のエージェントを使い、支払実行前には必ず人間の承認を通す、といった構成になります。

マルチエージェントのオーケストレーションは、単一エージェントからの「自動的なアップグレード」と考えるべきではありません。参加者が増えるほど、プロンプト、状態遷移、レイテンシ、モデル呼び出しが増え、エージェント間での不一致が発生する可能性も高まります。個別のエージェントに分けるのは、それぞれに異なる権限、コンテキスト、モデル、評価基準、または管理境界が必要な場合に限るのが賢明です。

グラフモデルは、これらの境界を可視化するのに役立ちます。順次実行はレビューパイプラインに、並列実行は独立した調査タスクに、ハンドオフ（受け渡し）は専門家間のルーティングに、マネージャー型オーケストレーションはサブタスクが事前に分からない問題に適しています。適切なパターンは、ルーティングの制御をどの程度コードに持たせ、どの程度モデルに任せるかによって決まります。

向いている用途

企業プロセスの自動化: 分類、文書分析、ポリシー参照、承認、記録更新などを調整しつつ、確定的なビジネスルールを言語モデルの外側で維持できます。

カスタマーサポートの連携: トリアージエージェントが、返金、請求、技術サポートなどの専門エージェントに会話を振り分けます。機密性の高い操作は、従業員がツール呼び出しを承認するまでブロック状態を維持できます。

調査・レビューパイプライン: 複数のエージェントが独立したソースを並行して調査し、レビュー担当エージェントが結果を比較します。確実な実行コードによって、引用構造の強制、重複の排除、不完全な出力の拒否を行えます。

ソフトウェア運用アシスタント: エージェントが診断データを収集して修復案を提示し、ツールは限定的な運用アクションを実行します。承認と監査コントロールにより、モデルが制限なしにインフラを変更することを防ぎます。

長期実行されるバックオフィス業務: プロセスが外部イベントを待つ必要がある場合や、プロセスの再起動を挟む場合、追加情報を要求する場合、あるいは再開まで数時間から数日間停止させる必要がある場合に、永続的な実行機能が役立ちます。

フレームワークを越えたエージェントネットワーク: A2A（Agent-to-Agent）サポートにより、Agent Frameworkアプリケーションが互換性のあるリモートエージェントを発見し通信できます。異なる部門やベンダーが異なるランタイムでエージェントを実装している場合に有用です。

エージェント型Webアプリケーション: AG-UIとの統合により、エージェントの活動、ワークフローの状態、承認リクエスト、ツールの進捗状況をフロントエンドにストリーミングできます。最終的な回答だけを表示するチャットインターフェースよりも多くの文脈をユーザーに提供できます。

他のツールとの比較

LangGraphは、状態を持つグラフオーケストレーションと実行パスの明示的な制御を求める開発者にとって、有力な代替肢です。PythonおよびJavaScriptのエコシステムで広く普及しています。Microsoft Agent Frameworkは、.NET、Microsoft.Extensions.AI、Microsoft Foundry、およびAutoGen/Semantic Kernelからの移行パスにより直接的に適合しています。

CrewAIは、役割ベースのエージェントチームとタスクベースの連携を重視しています。専門家グループを素早く定義する際には親しみやすいモデルです。Microsoft Agent Frameworkは、エージェントと確実な実行プログラム、型定義されたルーティング、チェックポイント、ミドルウェア、エンタープライズ向けのホスティングパターンを組み合わせることを、より明確に意図しています。

OpenAI Agents SDKは、OpenAIのサービスに特化してエージェント、ツール、ハンドオフ、ガードレール、トレースを構築する手法を提供します。アプリケーションを意図的にOpenAIプラットフォーム中心にする場合は、よりシンプルになる可能性があります。Microsoft Agent Frameworkは、より広範なプロバイダーの抽象化と、Pythonに並ぶ第一級の.NET実装を提供します。

Google Agent Development Kitは、GeminiやGoogle Cloudを中心としたアプリケーションにおける自然な選択肢です。この選択は、どのIDシステム、モデルカタログ、オブザーバビリティスタック、デプロイ環境、マネージドエージェントサービスを組織が既に使用しているかという、より広いプラットフォームの選択に似ています。

PydanticAIは、型定義された出力、依存関係注入、バリデーション、および比較的コンパクトなプログラミングモデルを重視するPythonチームに好まれます。Microsoft Agent Frameworkは、より大きなオーケストレーションとホスティングの領域をカバーしていますが、その分、チームが理解すべき概念も多くなります。

AutoGenとSemantic Kernelは、多くの既存アプリケーションで使用されているため、重要な比較対象です。新しいプロジェクトでは、Agent Frameworkが将来を見据えた選択肢となります。ただし、移行は単なるパッケージの置換ではなく、既存の会話パターンやプラグイン構成を、新しい統一されたエージェント・ワークフローモデルに合わせて再検討する機会となります。

推奨される構成

アプリケーションのコアパスには安定版パッケージを使用し、プレビュー段階の統合機能は内部インターフェースの背後に分離してください。フレームワークの1.0 APIは互換性が保証されていますが、より新しいハーネス、セキュリティ、UI、ホスティング、リサーチ用パッケージはより早く進化する可能性があります。

初期のプロトタイプが完成したら、アプリケーションに必要なプロバイダーパッケージのみをインストールしてください。Pythonのメタパッケージは試作には便利ですが、依存関係を最小限に抑えることで、イメージサイズ、推移的な脆弱性、起動時間、未使用サービスの誤設定を減らすことができます。

プロバイダーの選択は、アプリケーション固有のファクトリ層や設定層の背後に隠蔽してください。共通のエージェントインターフェースによって移行作業は軽減されますが、ツール呼び出し、構造化出力、ホスト型ツール、コンテキスト制限、認証、エラーの仕様はプロバイダーごとに異なります。プロバイダー固有の挙動がビジネスロジック全体に漏れ出さないようにすべきです。

ツールには限定的な権限を与え、状態を変更する操作は「べき等（同じ操作を何度繰り返しても結果が同じ）」にしてください。エージェントはタイムアウトやワークフロー復旧後にリトライする可能性があるため、ツールの再実行によって誤って支払、メッセージ、チケット、インフラリソースが二重に作成されないようにします。

重大なアクションには承認必須のラッパーを使用してください。承認用のデータには、提案された操作、関連パラメータ、予想される影響、要求元のエージェント、ワークフローの文脈を含め、レビュー担当者が不透明な関数名だけでなく、情報を得た上で判断できるようにします。

メモリは目的別に選択してください。一時的な会話履歴、長期的なユーザーの事実、ワークフローの状態、検索ドキュメント、エージェントが生成した作業ノートは、それぞれ異なるデータクラスです。これらすべてを一箇所のベクトルインデックスに保存すると、保持期限、アクセス制御、削除、関連性の調整が困難になります。

OpenTelemetryデータを既存の監視バックエンドにエクスポートしますが、デバッグの必要性が正当化されない限り、機密性の高いプロンプトと応答の取得は無効にしておいてください。ログ記録を有効にする場合は、マスキング、アクセス制御、保持制限、環境分離を適用します。

ローカル開発ではDevUIを使用して、メッセージの流れとワークフローの実行を確認してください。ただし、DevUIは開発用サンプルであり、堅牢なエンドユーザー向けアプリケーションではないため、本番環境には別途認証されたインターフェースを構築してください。

長時間実行されるプロセスの場合、チェックポイントをワーカープロセスの外に保存（永続化）してください。Azure FunctionsとDurable Extensionはマネージドなパスを提供し、独自のコンピューティング環境では外部スケジューラに永続ワーカーを接続できます。いずれの場合も、意図的な再起動や二重配信シナリオを通じて復旧挙動をテストすべきです。

AutoGenからの移行

AutoGenアプリケーションは、複数のエージェント間の会話によって連携をエンコードすることがよくあります。移行時には、どのやり取りが真に自律的な連携を代表し、どれが実際には固定されたプロセスステージ（ワークフローのエッジにするべきもの）であるかを特定してください。

プロバイダー固有のエージェントクラスを新しい共通エージェント抽象化にマッピングし、横断的な挙動は適宜ミドルウェアに移動します。ロギング、検証、レート制限、セキュリティチェック、リトライポリシー、コンテンツフィルタリングを、すべてのプロンプトで繰り返す必要はありません。

既存のグループチャットは、利用可能なオーケストレーションパターンに照らして再評価すべきです。例えば、順次レビュープロセスは、偶然同じ順序になることを期待するオープンなグループ会話よりも、明示的なシーケンスとして定義した方がテストしやすくなります。

実装を変更する前に、挙動テストを保存しておいてください。代表的な入力、期待されるツール呼び出し、ルーティング結果、承認ポイント、失敗ケースをキャプチャします。これらのトレースを比較することは、移行後のアプリケーションが「似たような言い回しのテキスト」を生成するかどうかを確認するよりもはるかに有用です。

Semantic Kernelからの移行

Semantic Kernelのユーザーは、パッケージ名、メッセージ型、エージェントの構築、呼び出しメソッド、オプション、ツールの登録方法に変更があることを考慮する必要があります。Microsoft Agent Frameworkは、共通のMicrosoft.Extensions.AI抽象化に依存し、サポートされているチャットクライアント間で統合されたエージェントモデルを使用します。

カーネルプラグインの多くは、そのまま関数ツールに変換できます。これによりフレームワーク固有の属性やボイラープレートを減らすことができますが、広すぎるプラグインを整理し、読み取り操作と外部システムを変更するアクションを分離する良い機会でもあります。

プロバイダーごとに異なるSemantic Kernelエージェントクラスを使用していたアプリケーションは、単一の共通エージェント抽象化へ移行できます。プロバイダー固有の設定はクライアントレイヤーに残りますが、上位のアプリケーションコードは共通インターフェースに依存できます。

ホストされた会話の仕様には注意が必要です。すべてのプロバイダーが同じサーバー側の履歴保持や削除挙動をサポートしているわけではないため、セッションのライフサイクルと保持ポリシーは、以前のバックエンドを前提にせず明示的に設計する必要があります。

移行は1つの垂直的なワークフローずつ進めてください。旧実装と新実装を同じ評価セットで実行することで、プロンプト、プロバイダーのバージョン、履歴の扱い、ツールスキーマ、あるいはフレームワーク自体の違いによる差異を特定しやすくなります。

本番環境のアーキテクチャ

エージェントレイヤーはアプリケーション全体ではなく、コンポーネントの一つとして扱ってください。認証、認可、課金、記録の所有権、ポリシーの決定、および不可逆的な状態変更は、明示的なインターフェースを持つ通常のサービスに留めるべきです。

エージェントへの指示（インストラクション）は認可境界ではありません。「特定のリソースにアクセスしないように」とエージェントに伝えるプロンプトよりも、最初からそのリソースを返さないツールの方が強力です。権限は、データの取得時とアクションの実行時の両方で強制されるべきです。

外部コンテンツと信頼された指示を分離してください。Webページ、取得したドキュメント、メール、MCPの応答、リモートエージェントからのメッセージには、プロンプトインジェクションや誤解を招く指令が含まれている可能性があります。機密性の高いツールを、検証や承認なしに信頼できないコンテンツから直接駆動させないでください。

モデルを切り替える前に、評価スイートを作成してください。代替モデルがルーティングの精度、ツールの選択、構造化出力、安全性、レイテンシ、コストを維持できているかを判断できない限り、プロバイダーの柔軟性は価値を発揮しません。

予算計画は、単一のモデル呼び出しコストではなく、ワークフロー全体のトレースに基づいて立てるべきです。マルチエージェントアプリケーションでは、複数のモデル呼び出し、ツール実行後の再試行、ドキュメント取得、メモリ書き込み、テレメトリ送信などが発生し、多くのターンにわたってアクティブであり続けます。

デプロイには、同時実行制限、タイムアウト、キャンセル処理、サーキットブレーカー、レート制限、デッドレター処理、および放置されたワークフローに対するオペレーターの介入パスも含まれるべきです。エージェント専用の抽象化機能は、従来の分散システムエンジニアリングを代替するものではありません。

運用上のトレードオフ

プロバイダーの中立性はアーキテクチャの結合を減らしますが、モデルを完全に代替可能にするわけではありません。あるプロバイダーでテストされたワークフローは、ツール呼び出しの形式、推論スタイル、コンテキスト処理、安全性フィルタ、あるいはホスト型機能のサポート状況の違いにより、切り替え後に異なる挙動を示す可能性があります。

Pythonと.NETの共有設計は、混合言語を使用する組織にとって価値がありますが、2つの実装が常に同時にすべての統合機能を受け取るとは限りません。チームはインターフェースやデプロイ機能を決定する前に、各言語のドキュメントを確認する必要があります。

永続的実行やマルチエージェント実行はレジリエンスを向上させますが、状態モデルを複雑にします。開発者は、どのメッセージ、ツール結果、チェックポイント、ファイル、承認、メモリが再実行可能で、デプロイ変更後に削除または保持すべきかを決定しなければなりません。

ローカルのOllamaサポートはデータフローの制御や実験コストの改善に役立ちますが、ローカル推論が自動的に企業のプライバシー基準やパフォーマンスを満たすわけではありません。組織は引き続き、ホストの保護、適切なモデルの選択、更新管理、出力品質の監視、および十分な計算リソースの確保を行う必要があります。

フレームワークは有用な制御機能を提供しますが、生成されたエージェントの安全性、正確性、コンプライアンスを保証するものではありません。これらの特性は、選択されたモデル、データ、指示、ツールの権限、評価、インターフェース、デプロイアーキテクチャ、および運用ポリシーに依存します。