.NETでAIエージェントを作るなら、2026年5月5日時点で確認すべき中心テーマは Microsoft Agent Framework です。Microsoft公式ブログの「Microsoft Agent Framework – Building Blocks for AI Part 3」では、単なるチャットボットではなく、ツール実行・複数ターン会話・記憶・ワークフロー・人間承認を組み合わせたエージェント開発の考え方が整理されています。(Microsoft for Developers)
結論から言うと、既存の.NETアプリにAI機能を追加している開発者、Semantic Kernelのエージェント機能を使っているチーム、RAGやツール呼び出しを本番運用に近づけたいチームは、早めに設計方針を見直すべきです。特に AIAgent、AgentSession、AIContextProvider、グラフベースのワークフローは、今後の.NET向けAIエージェント開発で重要な確認ポイントになります。
Microsoft Agent Framework – Building Blocks for AI Part 3の位置づけ
「Microsoft Agent Framework – Building Blocks for AI Part 3」は、.NETにおけるAI構築要素を整理する連載の第3回です。第1回では Microsoft.Extensions.AI、第2回では Microsoft.Extensions.VectorData によるRAGやセマンティック検索が扱われ、今回の第3回では、それらを使って「行動できるAI」を作るための Microsoft Agent Framework が中心に取り上げられています。(Microsoft for Developers)
ここで重要なのは、Microsoft Agent Frameworkが「チャット応答の便利ライブラリ」ではなく、AIエージェントを構成するためのSDKとして説明されている点です。ブログでは、エージェントを「入力を受けて回答するだけのチャットボット」と区別し、タスクを理解し、必要なツールを選び、結果を評価し、次の行動を判断する存在として整理しています。(Microsoft for Developers)
つまり、今回の情報を読むべきなのは「AIチャットを表示したい人」だけではありません。次のような開発に関わる人ほど影響が大きくなります。
| 対象者 | 確認すべき理由 |
|---|---|
| .NETでAIアプリを開発している人 | IChatClient から AIAgent へ拡張する設計が示されている |
| C#でツール呼び出しを実装している人 | AIFunctionFactory と Description 属性の使い方が重要になる |
| Semantic KernelのAgent機能を使っている人 | 名前空間、作成方法、セッション、ツール登録、実行APIの差分確認が必要 |
| RAGを業務システムに組み込んでいる人 | AIContextProvider と VectorData を組み合わせる設計が見えてくる |
| 本番環境でAIエージェントを運用したい人 | セッション永続化、承認フロー、ワークフロー制御を設計に入れる必要がある |
何が変わったのか：ポイントは「チャット」から「行動するエージェント」への拡張
今回の更新で最も大きな見方の変化は、AI機能を「モデルに質問して回答を返す処理」ではなく、「モデルが判断し、ツールを使い、複数ステップで目的を達成する処理」として設計する流れが明確になったことです。
従来のチャット実装では、開発者が次のような分岐を書きがちでした。
if (userInput.Contains("天気"))
{
// 天気APIを呼び出す
}
else if (userInput.Contains("予約"))
{
// 予約処理を呼び出す
}Microsoft Agent Frameworkでは、エージェントにツールを渡し、モデル側が「どのツールを使うべきか」を判断する構成になります。ブログでは、AsAIAgent() によるエージェント作成、RunAsync() による実行、RunStreamingAsync() によるストリーミング応答が紹介されています。(Microsoft for Developers)
実務上の意味は大きく、AIアプリの設計が次のように変わります。
| 従来の実装 | Microsoft Agent Frameworkでの考え方 |
|---|---|
| 入力文を条件分岐で判定する | エージェントにツールを渡し、モデルが呼び出しを判断する |
| 1回のプロンプトで完結させる | セッションで会話履歴を維持する |
| RAG検索を都度アプリ側で差し込む | AIContextProvider で文脈注入を仕組み化する |
| 複数処理を手続き的に並べる | ワークフローでエージェントや処理単位を接続する |
| 危険な処理をプロンプトで抑止する | 人間承認フローを組み込む |
まず確認すべき変更点
AsAIAgent() によるエージェント化
ブログでは、Azure OpenAIなどのチャットクライアントから .AsAIAgent() を呼び出して AIAgent を作成する例が示されています。これは、IChatClient を中心にしていた実装を、セッション、ツール、メモリを扱えるエージェントへ拡張する入口です。(Microsoft for Developers)
確認すべき点は、既存コードが「チャットクライアントを直接呼ぶだけ」になっているかどうかです。単純なFAQや要約であれば従来の構成でも十分な場合がありますが、業務処理、検索、外部API、複数ステップの判断が必要なら、AIAgent への移行を検討する価値があります。
ツール呼び出しは AIFunctionFactory と説明文が鍵になる
Microsoft Agent Frameworkでは、関数をツールとしてエージェントに渡せます。公式ブログでは AIFunctionFactory.Create() を使い、天気取得関数をツールとして登録する例が紹介されています。(Microsoft for Developers)
ここで見落としやすいのが Description 属性です。ツール名だけでは、モデルが「いつ、どの引数で使うべきか」を正しく判断できない場合があります。説明文は、AIにとっての操作マニュアルに近い役割を持ちます。
悪い例は、次のような曖昧な説明です。
[Description("Get data.")]
static string GetCustomerData(string id) => ...実務では、次のように用途と制約を明確に書く方が安全です。
[Description("指定された顧客IDに対応する顧客の契約状況を取得します。請求情報や個人情報の更新は行いません。")]
static string GetCustomerContractStatus(
[Description("社内CRMで使用する顧客ID。メールアドレスではありません。")] string customerId)
=> ...ツール説明が曖昧だと、不要なタイミングでツールが呼ばれる、引数の解釈を誤る、回答に必要な処理が実行されない、といった問題が起きやすくなります。
複数ターン会話は AgentSession で管理する
AIエージェントを本番で使う場合、1問1答だけでは足りません。ユーザーは「さっきの件を修正して」「別の条件で再計算して」のように、前の会話を前提にした指示を出します。
Microsoft Agent Frameworkでは AgentSession を使って会話の文脈を維持できます。ブログでは CreateSessionAsync() でセッションを作成し、同じセッションを RunAsync() に渡す例が示されています。また、セッションのシリアライズとデシリアライズにも触れられており、ステートレスなサービスでの運用を意識した内容になっています。(Microsoft for Developers)
実務で確認すべきポイントは次の通りです。
| 確認項目 | 判断基準 |
|---|---|
| セッション保存先 | WebアプリならDB、分散キャッシュ、ユーザー単位のストレージを検討する |
| 保存期間 | 問い合わせ対応なら短期、パーソナライズなら長期保存の要否を検討する |
| 個人情報 | 名前、メール、顧客ID、契約情報などを保存する場合は社内ルールに合わせる |
| 削除方法 | ユーザー退会、問い合わせ終了、保存期限切れ時の削除手段を決める |
| 復元テスト | サーバー再起動後に会話文脈が正しく戻るか確認する |
特に注意したいのは、セッションを「便利だから全部保存する」と考えないことです。AIエージェントの文脈保存は便利ですが、個人情報や機密情報を含む可能性があります。保存する情報、保存しない情報、保存期間を開発初期に決めておくべきです。
長期的な記憶は AIContextProvider で扱う
セッションは会話中の文脈を維持する仕組みですが、ユーザーの名前、好み、過去のやり取り、関連ドキュメントなどを継続的に使いたい場合は、より明確な「記憶」の設計が必要です。
公式ブログでは AIContextProvider が紹介されています。StoreAIContextAsync で会話後に情報を保存し、ProvideAIContextAsync で次の実行前に必要な文脈を提供する考え方です。(Microsoft for Developers)
この仕組みは、RAGとの相性が高いのが特徴です。たとえば社内ヘルプデスク用エージェントなら、次のような構成が考えられます。
| 用途 | AIContextProvider で注入する情報の例 |
|---|---|
| 社内FAQ回答 | VectorDataで検索した関連FAQ、手順書、規程 |
| 営業支援 | 顧客の契約プラン、過去の商談要約、禁止提案事項 |
| 開発支援 | 対象リポジトリ、使用フレームワーク、コーディング規約 |
| カスタマーサポート | 問い合わせ履歴、製品プラン、サポート範囲 |
ただし、記憶を増やすほど回答品質が上がるとは限りません。古い情報、矛盾した情報、権限外の情報が混ざると、AIの判断を誤らせます。AIContextProvider を使う場合は、取得条件、情報の鮮度、ユーザー権限、監査ログをセットで設計する必要があります。
ワークフロー対応で何ができるようになるのか
Microsoft Agent Frameworkの注目点は、単体エージェントだけでなく、グラフベースのワークフローを扱えることです。公式ブログでは、ExecutorとEdgeを接続し、順次処理、並列処理、条件分岐、フィードバックループ、サブワークフローといったパターンが紹介されています。(Microsoft for Developers)
これは、AIエージェントを「1つの巨大な万能AI」として作るのではなく、役割ごとの処理単位に分けて設計する考え方です。
たとえば、記事作成支援エージェントなら次のような流れが考えられます。
| ステップ | 役割 |
|---|---|
| 要件整理エージェント | キーワード、読者、制約条件を整理する |
| 調査エージェント | 指定ソースや社内資料から根拠を集める |
| 執筆エージェント | 初稿を作成する |
| レビューエージェント | 事実誤認、過剰表現、SEO不足を確認する |
| 修正エージェント | レビュー結果を反映する |
| 人間レビュー | 公開可否を判断する |
公式ブログでは、writer-critic型のワークフローも例示されています。作成役のエージェントがドラフトを出し、批評役のエージェントが評価し、承認されるまで戻す構成です。(Microsoft for Developers)
実装時の注意点は、ループに上限を設けることです。AI同士のレビューを自動化すると、品質向上に役立つ一方で、条件が曖昧だと同じ修正を繰り返したり、トークン消費が増え続けたりします。承認条件、最大試行回数、失敗時の終了処理を必ず決めてください。
Human-in-the-loopは本番運用で必須の設計要素
AIエージェントがツールを呼び出せるようになると、便利さと同時にリスクも増えます。検索や計算なら影響は小さくても、メール送信、DB更新、決済、権限変更、チケット削除のような操作では、人間の承認が必要です。
公式ブログでは、Microsoft Agent Frameworkがツール承認ワークフローをサポートし、エージェントがツール呼び出しを提案して人間の承認を待つ仕組みが説明されています。特にデータベース書き込み、金融取引、コミュニケーション送信のような機密性の高い操作で重要とされています。(Microsoft for Developers)
実務では、ツールを次の3段階に分けると設計しやすくなります。
| ツール種別 | 例 | 承認の要否 |
|---|---|---|
| 読み取りのみ | FAQ検索、天気取得、在庫確認 | 原則として自動実行しやすい |
| 影響が限定的な書き込み | 下書き作成、チケットのメモ追加 | 条件付きで自動化を検討 |
| 重大な操作 | メール送信、顧客情報更新、決済、削除 | 人間承認を必須にする |
「プロンプトで禁止しているから大丈夫」と考えるのは危険です。実際のシステムでは、コード側で承認、権限、監査ログ、ロールバック手段を用意する必要があります。
Semantic Kernel利用者が確認すべき移行ポイント
Semantic Kernelのエージェント機能を使っている場合、Microsoft Agent Frameworkへの移行可否を早めに確認する価値があります。Microsoft Learnの移行ガイドでは、名前空間、エージェント作成、セッション、ツール登録、実行API、DI、エージェント型の統合など、多くの差分が整理されています。(Microsoft Learn)
特に影響が出やすいのは次の項目です。
| 項目 | Semantic Kernel側 | Agent Framework側 | 確認ポイント |
|---|---|---|---|
| 名前空間 | Microsoft.SemanticKernel など | Microsoft.Agents.AI、Microsoft.Extensions.AI | usingの変更だけでなく型の役割も確認する |
| エージェント作成 | Kernel 依存が大きい | AsAIAgent() などで作成 | 既存のKernel中心設計を見直す |
| セッション | 呼び出し側がThread種別を意識 | AgentSession を作成 | セッション保存・削除の設計を確認する |
| ツール登録 | PluginやKernel経由 | AIFunctionFactory.Create() で直接登録 | 既存Pluginをどう移すか確認する |
| 非ストリーミング実行 | InvokeAsync() | RunAsync() | 戻り値とメッセージ構造の違いを確認する |
| ストリーミング実行 | InvokeStreamingAsync() | RunStreamingAsync() | UI表示やログ出力の処理を修正する |
| DI | Kernel 登録が中心 | AIAgent 登録 | サービス登録とライフサイクルを見直す |
移行で失敗しやすいのは、「API名を置き換えるだけ」で済ませようとするケースです。Microsoft Agent Frameworkでは、セッション、ツール、ワークフロー、人間承認を含めたエージェント設計に寄せて考える必要があります。移行時は、既存機能を単純変換するよりも、業務フロー単位で再設計した方が安全です。
設定確認で見落としやすいポイント
Microsoft Agent Frameworkを試すだけなら、公式ブログのサンプルのように環境変数を使ってAzure OpenAIのエンドポイントやデプロイ名を読み込む構成で始められます。ただし、本番環境に近づける場合は設定の扱いを慎重に確認してください。
特に DefaultAzureCredential は開発時には便利ですが、本番利用では意図しない資格情報探索やレイテンシ、セキュリティ上の懸念があるため、Microsoft Learnでは ManagedIdentityCredential など具体的な資格情報の利用を検討するよう注意されています。(Microsoft Learn)
確認すべき設定は次の通りです。
| 確認項目 | 具体的に見ること |
|---|---|
| モデル接続 | Azure OpenAI、OpenAI、GitHub Models、Foundry Local、Ollamaなど、利用先に応じたSDKと認証方式 |
| 環境変数 | エンドポイント、デプロイ名、APIキーをコードに直書きしていないか |
| 認証 | 開発用認証と本番用認証を分けているか |
| ツール権限 | エージェントが呼び出せるAPIを最小限にしているか |
| セッション保存 | 会話履歴の保存先、保存期間、削除方法を決めているか |
| ログ | プロンプト、ツール呼び出し、承認結果、エラーを追跡できるか |
| コスト | ワークフローやループでトークン消費が増えすぎないか |
| 失敗時処理 | ツール失敗、モデル応答失敗、承認拒否時の動作を定義しているか |
すぐ試す場合の最小ステップ
Microsoft Agent Frameworkをまだ触っていない場合は、いきなり複雑なマルチエージェント構成を作るより、次の順番で試すのがおすすめです。
| ステップ | 目的 | 成功条件 |
|---|---|---|
| 1 | 単体エージェントを作る | RunAsync() で応答を取得できる |
| 2 | ストリーミングを試す | UIやコンソールに逐次表示できる |
| 3 | 1つのツールを追加する | ユーザー入力に応じて関数が呼ばれる |
| 4 | セッションを使う | 直前の会話を参照した回答ができる |
| 5 | セッションを保存・復元する | アプリ再起動後も文脈を戻せる |
| 6 | AIContextProvider を追加する | ユーザー情報や検索結果を文脈として注入できる |
| 7 | ワークフロー化する | 複数処理を順番・条件分岐・ループで制御できる |
| 8 | 承認フローを入れる | 重要操作の前に人間が許可・拒否できる |
最初の検証では、読み取り専用のツールを使うのが安全です。たとえば「社内FAQを検索する」「商品情報を取得する」「チケット一覧を取得する」といった処理から始めると、エージェントの判断ミスが起きても影響を抑えられます。
対応すべきチームと優先度
すべての.NET開発者がすぐに移行する必要はありません。優先度は、AI機能の使い方によって変わります。
| 優先度 | 対象 | 対応方針 |
|---|---|---|
| 高 | Semantic Kernel Agent機能を使っているチーム | 移行ガイドを読み、API差分とセッション設計を確認する |
| 高 | ツール呼び出しで業務処理を実行しているチーム | 承認フロー、権限、ログ、失敗時処理を見直す |
| 中 | RAGや社内検索をAIに組み込んでいるチーム | AIContextProvider と VectorData連携を検討する |
| 中 | 複数エージェントやレビュー自動化を考えているチーム | ワークフロー設計とループ上限を検討する |
| 低 | 単純なFAQチャットのみのチーム | すぐ移行せず、将来の拡張候補として把握する |
重要なのは、Microsoft Agent Frameworkを「流行の新SDK」として導入するのではなく、自社アプリのAI機能がどの段階にあるかで判断することです。単純なチャット応答なら過剰設計になる可能性があります。一方で、AIに外部ツールを使わせる、会話をまたいで文脈を保持する、複数工程を自動化するなら、早めに設計を寄せるメリットがあります。
導入時の注意点と失敗しやすいポイント
ツールを増やしすぎない
エージェントに多くのツールを渡すほど便利に見えますが、モデルがどれを使うべきか迷いやすくなります。最初は、用途が明確でリスクの低いツールから始めてください。
悪い設計は、「顧客検索」「顧客更新」「メール送信」「請求処理」「契約解除」などを一気に渡すことです。まずは検索系だけを許可し、更新系は承認付きに分ける方が安全です。
セッションと長期記憶を混同しない
セッションは会話の流れを保つ仕組みです。一方、長期記憶はユーザー属性や過去の行動を再利用する仕組みです。両者を混同すると、不要な個人情報を保存したり、古い文脈で誤った回答をしたりします。
「この会話中だけ必要な情報」と「次回以降も使う情報」を明確に分けてください。
人間承認を後回しにしない
AIエージェントが外部APIを呼ぶ構成では、承認フローを後から追加するのが難しくなる場合があります。特にメール送信、データ更新、課金、削除を扱うなら、最初の設計段階でHuman-in-the-loopを入れるべきです。
ワークフローの成功条件を曖昧にしない
writer-critic型のようなフィードバックループは便利ですが、「何を満たせば承認か」が曖昧だと終わりません。品質基準、最大ループ回数、失敗時の通知先を決めておきましょう。
まず取るべき次の行動
2026年5月5日時点で「Microsoft Agent Framework – Building Blocks for AI Part 3」を読む際は、単なる新機能紹介としてではなく、.NETにおけるAIエージェント設計の確認リストとして見るのが実用的です。
まずは、自社のAI機能を次の3つに分類してください。
| 分類 | 次にやること |
|---|---|
| チャット応答のみ | 既存構成で十分か確認し、将来の拡張候補として把握する |
| ツール呼び出しあり | AIFunctionFactory、説明文、権限、承認フローを確認する |
| 複数工程・記憶・RAGあり | AgentSession、AIContextProvider、ワークフロー設計を検討する |
Microsoft Agent Frameworkは、.NETでAIエージェントを本格的に作るための構成要素を整理するものです。今すぐ全面移行するかどうかよりも、既存のAI実装が「単発のチャット」なのか、「行動するエージェント」へ進む段階なのかを見極めることが重要です。まずは小さな検証環境で単体エージェント、ツール呼び出し、セッション管理までを試し、その後にメモリ、ワークフロー、人間承認へ広げていくのが安全な進め方です。
コメント