Agent-Framework | The .NET Blog

Microsoft Foundry 2026年4月: Foundry Local GA、GPT-5.5、HyperlightによるCodeAct

Emiliano Montesdeoca — Tue, 02 Jun 2026 00:00:00 +0000

Microsoft Foundryにとって忙しい月でした。最も重要なアナウンスをご紹介します。

Foundry Localが一般提供開始

Foundry Local — MicrosoftのクロスプラットフォームのローカルAIランタイム — がWindows、macOS（Apple Silicon）、Linux x64でプレビューからGAになりました。開発者向けSDKを備えた、本番環境対応のローカルモデル推論です。バージョン1.1では文字起こし、embeddings、Responses APIのサポートが追加されています。

GPT-5.5

GPT-5ファミリーの最新モデルがFoundryで利用可能になりました。Tier 5およびTier 6サブスクリプションのデフォルトクォータ。以前のGPT-5バリアントで作業していた場合、ユースケースに合わせて評価する価値があります。

FoundryでのAgent Frameworkトレーシング

今月、2つのトレーシング機能がプレビューとして提供されます：

Microsoft Agent Frameworkトレーシング — MAFエージェントがFoundryにOpenTelemetryトレースを送信できるようになりました。エージェントの動作をデバッグし、多段階実行をトレースし、ツール呼び出し全体の遅延とエラーを表面化させます。これは実際のギャップを埋めます：何を返したかだけでなく、エージェントが本番で実際に何をしたかを知ること。

ホステッドエージェントトレーシング — ホステッドエージェントのセッション、ツール呼び出し、実行ステップもFoundryトレースに表示されます。同じオブザーバビリティストーリーがホステッドティアにも拡張されます。

HyperlightによるCodeAct（Alpha）

これは技術的に最も興味深い追加機能です：Agent FrameworkがHyperlightマイクロ仮想マシン内でPythonコードを実行できるようになりました。

CodeActはエージェントがツールとしてPythonコードを生成して実行するパターンです。明らかな懸念はセキュリティ — モデルが生成したコードを実行しています。HyperlightのマイクロVMはネイティブに近い起動時間でプロセスレベルの隔離を提供し、フルコンテナやVMのオーバーヘッドなしでサンドボックスコード実行を実用的にします。

コード実行が必要なエージェントワークフローにとって、これはホストプロセスでコードを実行するよりも大幅なセキュリティ改善です。

エージェント監視ダッシュボード（プレビュー）

トークン使用量、遅延、実行成功率、エバリュエータースコアを1つのビューに組み合わせた統合オペレーションダッシュボード。通常のオブザーバビリティダッシュボードとの違い：オペレーションメトリクスとともに評価結果が含まれているため、「エージェントが遅くなっている」と「エバリュエータースコアが下がった」を相関させたり、関係ないことを確認したりできます。

継続的評価カスタムエバリュエーター（プレビュー）

独自のコードベースまたはプロンプトベースのエバリュエーターを継続的評価パイプラインに持ち込めるようになりました。以前は、継続的評価は組み込みエバリュエーターに限定されていました。カスタムエバリュエーターを使用すると、本番監視ループでチーム固有の品質基準を適用できます。

コントロールプレーンのエージェントインベントリ

FoundryコントロールプレーンのOperate ビューで、サブスクリプション全体のすべてのサポートされているエージェントが表示されるようになりました：Foundryエージェント、Azure SRE Agent、Logic Appsエージェントループ、および登録済みカスタムエージェント。何がどこにデプロイされているかを把握するための1つのビュー。

元の投稿：What’s new in Microsoft Foundry | April 2026

ハンドオフパターン：1つのエージェントでは不十分な時

Emiliano Montesdeoca — Mon, 01 Jun 2026 00:00:00 +0000

どのマルチエージェントシステムも、いつかはシンプルなルーターを超えます。最初のサインは、専門エージェントがフォローアップの質問をする必要があるとき、またはターンの途中で別のエージェントが続けるべきだと気付くときです。固定パイプラインはそこで失敗します。ワンショットルーターもそこで失敗します。

それこそがMicrosoft Agent FrameworkのHandoffオーケストレーションパターンが対処するために設計された問題です。

Handoffの仕組み

開発者がグラフを宣言します：エージェントはこれで、エージェント間のエッジはこれです。フレームワークが残りを行います — 各出力エッジにハンドオフツールを合成して各エージェントに注入します。エージェントが制御を渡すと決めたらツールを呼び出します。フレームワークがトポロジを強制します。

これをエージェントが互いを呼び出すことと異なるものにする3つのこと：

1つの共有トランスクリプト — 受信エージェントは完全な会話履歴を見ます。ゼロから始まることはありません。
トポロジの強制 — エージェントは宣言されたターゲットにのみハンドオフできます。ルーティングのバグは作成時に検出され、プロダクションでは検出されません。
自然な終了 — アクティブエージェントがハンドオフツールを呼び出さずにターンを終えると、ワークフローはユーザーに譲ります。ポーリングなし、明示的な終了条件なし。

最小限の例

.NETでhandoffワークフローを構築するとこのようになります：

using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Workflows;

AIAgent triage = chatClient.AsAIAgent(
 instructions: "Route to the right specialist.",
 name: "Triage");

AIAgent billing = chatClient.AsAIAgent(
 instructions: "Handle billing questions.",
 name: "Billing");

AIAgent tech = chatClient.AsAIAgent(
 instructions: "Handle technical support.",
 name: "Tech");

var workflow = HandoffWorkflow.Create()
 .Add(triage, targets: [billing, tech])
 .Add(billing, targets: [triage])
 .Add(tech, targets: [triage, billing]);

Triageはどちらの専門家にも送れます。両方の専門家がtriageに戻せます。グラフは非巡回対応ですが、必要なとき(“もっと情報が必要” → 調査に戻る)にバックエッジをサポートします。

Handoffを使う時（と使わない時）

Handoffが適している場面：

所有権が会話の途中で変わりうる — エージェントが自分が間違った専門家だと気付く場合
バックエッジが重要 — 再起動なしに前のステップを再訪する必要がある場合
ルーティング決定が曖昧 — ハンドオフするかどうかの決定が文脈的で、型付きの述語よりモデルが判断した方が良い場合

適していない場面：

パイプラインが固定で順次的 — その場合はSequentialワークフローを使用
各ステップが独立 — 1つしか必要としていないのに全員がトランスクリプトを共有するのは雑音
厳格な処理保証が必要 — モデル駆動ルーティングの非決定論は望むものではない

バックエッジとHuman-in-the-Loop

Handoffが可能にする最も興味深い形の一つは、本物のバックエッジです。エージェントは「情報が不十分」と判断して研究ステップに戻るルーティングをすることができます — ハードコードされたループではなく、モデルがそれが正しい判断だと決めるからです。

Human-in-the-loopのインタラクションも自然に構成されます。専門家がユーザー入力を必要とするとき、ワークフローはデフォルトのターンループを通じてユーザーに戻し、応答を収集し、完全なコンテキストで再開します。エージェントは会話を失いません。

まとめ

Handoffは内面化すると多くを可能にするシンプルに見えるパターンの一つです：分散ルーティング、共有コンテキスト、強制されたトポロジ、自然な終了。エージェントが「実際は他の誰かがこれを処理すべきだ」と言い始めたときの次のステップです。

元の投稿で完全なウォークスルーを読む: A Tour of the Handoff Orchestration Pattern

Microsoft Agent Frameworkにおける永続的ワークフロー：In-MemoryからAzure Functionsへ

Emiliano Montesdeoca — Sun, 31 May 2026 00:00:00 +0000

初期のAIエージェントワークフローの問題点のひとつ：脆弱性です。単一プロセスに縛られた長時間実行のマルチステップワークフローは、プロセス再起動 = 状態喪失を意味します。シンプルなデモには問題ありませんが、本番ワークロードには向きません。

Microsoft Agent FrameworkのワークフロープログラミングモデルがAzure Functionsホスティングでのdurable task フレームワークによる永続的実行をサポートするようになりました。プログラミングモデルの仕組みと、永続性の重要性について説明します。

基本的な構成要素

Executorは作業の基本単位です。各Executorは型付きで、特定の入力を受け取り、特定の出力を生成します：

using Microsoft.Agents.AI.Workflows;

internal sealed class OrderLookup()
 : Executor<OrderCancelRequest, Order>("OrderLookup")
{
 public override async ValueTask<Order> HandleAsync(
 OrderCancelRequest message,
 IWorkflowContext context,
 CancellationToken cancellationToken = default)
 {
 // 注文を検索して返す
 return new Order(Id: message.OrderId, ...);
 }
}

WorkflowはFluentビルダーを使ってExecutorを有向グラフに接続します。フレームワークが実行、ステップ間のデータフロー、エラー伝播を処理します。

モデル化できるもの：

順次チェーン（ステップA → ステップB → ステップC）
並列Fan-out/Fan-in（エージェントA、B、Cを並列実行して結果を集約）
条件分岐
ヒューマン・イン・ザ・ループ承認（ワークフローを一時停止して外部シグナルを待機）

ローカル開発用In-Memoryランナー

開始は素早くできます：

dotnet add package Microsoft.Agents.AI
dotnet add package Microsoft.Agents.AI.Workflows

コアパッケージには軽量なインプロセスランナーが含まれています。外部依存関係なし、データベースなし、Azureリソースなし。ローカル開発とユニットテストに最適です。

Durable Taskで永続性を追加

ワークフローがプロセス再起動を乗り越える必要がある場合 — 長時間実行だから、ヒューマン・イン・ザ・ループステップがあるから、多くの並列エージェント呼び出しに分散するから — In-Memoryランナーでは不十分です。

MAFのDurable Task統合はワークフロー状態をAzure Storageに保存します。プロセスが再起動しても、ワークフローは中断した場所から再開されます。プログラミングモデルは変わりません。ランナーを入れ替えるだけです。

dotnet add package Microsoft.Agents.AI.Workflows.DurableTask

同じExecutor、同じワークフローグラフ — 永続的な状態に支えられています。

Azure Functionsホスティング

3番目の層はAzure Functionsホスティングです。ワークフローはFunctionアプリになります：HTTPエンドポイントでワークフローをトリガーし、永続的ランタイムがスケーリング、状態、信頼性を管理します。

これにより、並列呼び出し、条件分岐、ヒューマン承認を持つマルチエージェントワークフローが、カスタム状態管理なしでサーバーレスFunctions環境でスケールできます。

なぜこれが重要か

この組み合わせは本番AIシステムにとって重要です：

並列エージェント呼び出し — ブロックなしで複数の専門エージェントに同時に分散し、全員が完了したら結果を集約
長時間実行プロセス — ヒューマン承認や外部イベントを含むワークフローが時間や日をまたいで一時停止・再開できる
スケーリング — Azure Functionsが実行を水平スケール；Durable Taskフレームワークが並列状態の調整を管理

シンプルなローカルデモを超えたMAFワークフローを構築するなら、これが本番品質の実行への道筋です。

元の投稿：Durable Workflows in the Microsoft Agent Framework

あなたのローカル MAF エージェントが本番環境の家を手に入れました

Emiliano Montesdeoca — Sat, 30 May 2026 00:00:00 +0000

エージェントをローカルで動作させることは楽しい部分です。難しい部分はその後のすべてです：正気を保ちながらデプロイし、セッションを管理し、アイデンティティを設定し、可観測性を配線する。通常、これは多くのカスタムインフラの「接着剤」を意味します。

Foundry Hosted Agents は、Microsoft Agent Framework (MAF) ユーザーにとってそのような接着剤の大部分を取り除いてくれました。

Foundry Hosted Agents が実際に何をするか

MAF エージェントを Foundry Hosted Agents にデプロイすると、プラットフォームは驚くほど長いリストのことを処理してくれます。それを自分で構築する必要がなくなります：

ゼロへのスケール — アイドル時にコストがかからず、自動的に起動します
セッションごとの VM 分離サンドボックス — 各ユーザーセッションがスケールダウンイベントを乗り越えるファイルシステム永続性を持つ独自のサンドボックスを取得します
組み込み Entra ID — 各エージェントが Foundry モデル、Toolbox、Azure サービスをシークレットをイメージに焼き付けずに呼び出せる独自のアイデンティティを取得します
バージョン管理されたデプロイメント — 各デプロイメントが不変のスナップショットで、blue/green とカナリアロールアウトサポートがあります
設定不要の可観測性 — APPLICATIONINSIGHTS_CONNECTION_STRING が実行時に注入されるため、MAF の OpenTelemetry トレースが App Insights に自動的に流れます

最後のものは本当に便利です。追加の配線なし、追加の設定なし。トレースがただ表示されます。

コードの違いは最小限

この統合で最も気に入っているのはこれです。エージェントを書き直す必要はありません。ただラップするだけです：

.NET の場合：

using Microsoft.Agents.AI.Foundry.Hosting;

var builder = WebApplication.CreateBuilder(args);
builder.Services.AddFoundryResponses(agent);

var app = builder.Build();
app.MapFoundryResponses();

app.Run();

Python の場合：

server = ResponsesHostServer(agent)
server.run()

それだけです。ローカルでテストしたのと同じロジックが本番環境で実行されます。プラットフォームはセッション管理、アイデンティティ、スケーリングインフラでそれをラップします。

2 つのプロトコル、1 つのエージェント

Hosted Agents は 2 つのエンドポイントスタイルをサポートします：

Responses (/responses) — OpenAI 互換、会話履歴とストリーミングを管理します。チャット形式のエージェントの良いデフォルト。
Invocations (/invocations) — リクエスト/レスポンススキーマを定義します。非会話的なワークフローに適しています。

会話のように見えるものを構築している場合は、Responses から始めてください。構造化された入力を受け取り、構造化された出力を返す API 形式のエージェントを構築している場合は、Invocations が柔軟性を提供します。

`azd` を使ったデプロイフロー

MAF エージェントで azd up を実行すると：

オプションで Foundry プロジェクトを作成してモデルをデプロイ
コードをパッケージ化して Azure Container Registry にイメージをプッシュ
ACR イメージからコンピューティングをプロビジョニング
エージェントに専用の Entra ID を割り当て
安定したエンドポイントを公開 (https://{project_endpoint}/agents/{agent_name})
それ以降はすべてを処理

セッションは最大 30 日間持続します。アイドル状態のコンピューティングは 15 分後にデプロビジョニングされ、次のリクエスト時に透過的に復元されます。エージェントの観点からは、何も変わっていません。

まとめ

「ローカルで動作している」から「本番で実行されている」までの距離は、AI エージェントにとって歴史的に長くて辛いものでした。Foundry Hosted Agents + MAF はそのギャップを大幅に縮めます。Agent Framework で構築されたローカルエージェントがすでにある場合は、今日試す価値があります。

チームは GA が近いと言っています — これは現在プレビュー中です。始めるには MAF Hosted Agent 統合ドキュメントと .NET サンプルを確認してください。

元の記事: From Local to Production: Deploy Your Microsoft Agent Framework Agent with Foundry Hosted Agents

エージェントを作るのは簡単な部分 — 安全に実行するのが難しい部分

Emiliano Montesdeoca — Fri, 29 May 2026 00:00:00 +0000

AI エージェント開発には「デモ後悔」と呼び始めたパターンがあります。エージェントはデモでは完璧に動作します。そして誰かが聞きます: 間違ったツールを呼び出したら何が起こる? アクセスすべきでないデータにアクセスしたら? 誰が監査した?

Microsoft Agent Framework はビルドとオーケストレーションをサポートします。Agent Governance Toolkit（AGT）はその後の部分をカバーします — ガバナンス、ポリシー適用、ランタイムでの監査可能性。

各プロジェクトが実際に行うこと

Microsoft Agent Framework (MAF) はプログラミングモデルを提供します: マルチエージェントワークフロー、A2A プロトコル相互運用性、ミドルウェアフック、メモリ、Foundry Agent Service によるマネージドホスティング。モデル入出力レベルでコンテンツセーフティを処理します。

Agent Governance Toolkit (AGT) は同じミドルウェアパイプラインに接続して アクション を管理します。すべてのツール呼び出し、リソースアクセス、エージェント間メッセージは実行前にポリシーに対して評価されます。サブミリ秒のオーバーヘッド。サイドカーなし、プロキシなし、変更されたプロンプトなし。

エージェントアクション --> ポリシーチェック --> 許可 / 拒否 --> 監査ログ (< 0.1 ms)

異なるレイヤー、完全なカバレッジ、1つのパイプライン。

接続はミドルウェアを追加するだけ

Python では、AGT はログやコンテンツフィルターに使うのと同じ middleware パラメーターに追加されます:

agent = Agent(
 client=OpenAIChatClient(model="gpt-5.3"),
 name="Contoso Loan Officer",
 instructions="You are a governed loan assistant.",
 tools=[check_credit_score, get_loan_rates, approve_small_loan],
 middleware=[
 AuditTrailMiddleware(audit_log=audit_log, agent_did="loan-agent"),
 GovernancePolicyMiddleware(evaluator=evaluator, audit_log=audit_log),
 CapabilityGuardMiddleware(allowed_tools=["check_credit_score", "get_loan_rates"]),
 RogueDetectionMiddleware(detector=detector, agent_id="loan-agent"),
 ],
)

.NET では .Use() を通じて同じパターン:

var agent = builder.BuildAIAgent(model: "gpt-5.3")
 .Use(new GovernancePolicyMiddleware(evaluator))
 .Use(new CapabilityGuardMiddleware(allowedTools))
 .Use(new AuditTrailMiddleware(auditLog));

同じエージェント、同じオーケストレーション、同じツール。AGT はエージェントのロジックを変更せずにガバナンス機能を追加します。

何を得るか

GovernancePolicyMiddleware — 宣言的ポリシールールに対してすべてのアクションを評価
CapabilityGuardMiddleware — エージェントが呼び出しを許可されているツールのホワイトリスト（上記の approve_small_loan ツールは意図的に許可リストに含まれていない）
RogueDetectionMiddleware — ランタイムで異常な動作パターンを検出
AuditTrailMiddleware — すべてのアクションを暗号学的に改ざん耐性にするための Merkle チェーン監査ログ

最後のものはコンプライアンスに重要です。Merkle チェーンは、誰かがログを変更すると、チェーンが壊れることを意味します。監査が証拠です。

5つの業界シナリオ

AGT リポジトリには5つの完全なエンドツーエンドシナリオが含まれています: 金融サービス（ローン担当者）、医療（患者データ）、法律（契約審査）、政府（市民サービス）、製造（品質管理）。それぞれが実際の MAF エージェントと実際の AGT ガバナンスミドルウェアを組み合わせています。

おもちゃのデモではありません。実際に本番でガバナンスが必要なシナリオです。

まとめ

実際のデータに触れる、結果を伴う決定を下す、または本番で監視なしで動作するエージェントを構築している場合 — ガバナンスは任意ではありません。MAF + AGT の組み合わせが完全なスタックを提供します: Agent Framework でビルドし、AGT で管理します。

両プロジェクトはオープンソースです。元の記事には完全なコードサンプルへのリンクがあります。

元の投稿: Governance at the Speed of Agents: Microsoft Agent Framework and Agent Governance Toolkit, Better Together

A2A v1 登場: Microsoft Agent Framework for .NET でのクロスプラットフォームエージェント通信

Emiliano Montesdeoca — Mon, 04 May 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちら。

A2A v1 登場: Microsoft Agent Framework for .NET でのクロスプラットフォームエージェント通信 — A2A プロトコルが v1.0 に到達し、.NET の A2A Agent（クライアント）と A2A Hosting（サーバー）パッケージが更新されました。

A2A v1 の実体

A2A は、AWS、Cisco、Google、IBM Research、Microsoft、Salesforce、SAP、ServiceNow の代表者からなるテクニカルステアリングコミッティが支援するAIエージェント向けオープン相互運用プロトコルです。v1 ラベルは、これが安定した本番対応の標準になったことを意味します。実装する SDK と Agent Framework パッケージはまだプレビュー段階ですが、プロトコル自体は確定しています。

v1 は v0.3 からマルチテナントサポート、暗号化IDのための署名付き Agent Cards、改善されたセキュリティフロー、ウェブ整合アーキテクチャを追加しました。

リモート A2A エージェントへの接続

リモート A2A エージェントはコード内では単なる AIAgent です — 同じ RunAsync、同じストリーミング、同じセッション管理：

// Well-known URI による探索
A2ACardResolver resolver = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = await resolver.GetAIAgentAsync();
Console.WriteLine(await agent.RunAsync("What's the weather in Seattle?"));

// 直接設定
A2AClient a2aClient = new(new Uri("https://a2a-agent.example.com"));
AIAgent agent = a2aClient.AsAIAgent(name: "my-agent", description: "A helpful assistant.");

// ストリーミングも同様
await foreach (var update in agent.RunStreamingAsync("Write a short summary..."))
 Console.Write(update.Text);

エージェントを A2A エンドポイントとして公開

Microsoft Foundry、Azure OpenAI、OpenAI、Anthropic、AWS Bedrock で構築した任意の AIAgent を、ASP.NET Core の 2 行で A2A エンドポイントとして公開できます：

builder.Services.AddKeyedSingleton<AIAgent>("weather-agent", (sp, _) => ...);
builder.AddA2AServer("weather-agent");

エージェントカードは /.well-known/agent-card.json で自動的に提供されます。

実際に何を意味するか

安定した v1 プロトコルにより、breaking changes を心配せずに .NET エージェントを Python、Java、その他の言語で構築されたエージェントと接続できます。署名付き Agent Cards の暗号化 ID は、エージェント間の信頼検証の基盤も提供します。

完全な変更履歴と v0.3 からの移行メモについては、完全な記事をご覧ください。

Agent FrameworkのCodeAct：エージェントのレイテンシを半分にする方法

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

エージェントプロジェクトの開発中、トレースを見て「なぜこんなに時間がかかるんだろう？」と思う瞬間があります。モデルは問題ない。ツールも動いている。でも、1回で計算できる結果を得るのに7回のラウンドトリップが発生している。

これがまさにCodeActが解決する問題です。Agent FrameworkチームはHyperlightパッケージでのアルファサポートをリリースしました。

CodeActとは？

CodeActパターンはエレガントにシンプルです。モデルにツールリストを渡して1つずつ呼び出させる代わりに、単一のexecute_codeツールを与え、計画全体を短いPythonプログラムとして表現させます。エージェントはコードを1回書き、サンドボックスがそれを実行し、1つの統合された結果を得ます。

方式	時間	トークン
従来型	27.81秒	6,890
CodeAct	13.23秒	2,489
改善	52.4%	63.9%

セキュリティ：Hyperlightマイクロ-VM

agent-framework-hyperlightパッケージはHyperlightのマイクロ-VMを使用します。各execute_code呼び出しは独自の新しいマイクロ-VMを取得します。起動はミリ秒単位で計測されます。分離はほぼコストゼロです。

ツールはホストで実行し続けます。モデルが生成したグルーコードはサンドボックスで実行されます。これが正しい分離です。

最小セットアップ

from agent_framework import Agent, tool
from agent_framework_hyperlight import HyperlightCodeActProvider

@tool
def get_weather(city: str) -> dict[str, float | str]:
 """Return the current weather for a city."""
 return {"city": city, "temperature_c": 21.5, "conditions": "partly cloudy"}

codeact = HyperlightCodeActProvider(
 tools=[get_weather],
 approval_mode="never_require",
)

agent = Agent(
 client=client,
 name="CodeActAgent",
 instructions="You are a helpful assistant.",
 context_providers=[codeact],
)

いつCodeActを使うか（使わないか）

CodeActを使う場合：

タスクが多くの小さなツール呼び出しを連鎖させる（ルックアップ、結合、計算）
レイテンシとトークンコストが重要
モデル生成コードに強力な分離が必要

従来のtool-callingを使う場合：

エージェントがターンごとに1〜2回しかツールを呼び出さない
各呼び出しに個別の承認が必要な副作用がある
ツールの説明が乏しいか曖昧

今すぐ試す

pip install agent-framework-hyperlight --pre

Agent Frameworkブログの完全な投稿でより詳しい解説をご覧ください。

GPT-5.5 が Azure Foundry に登場 — .NET 開発者が知っておくべきこと

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

MicrosoftはGPT-5.5がMicrosoft Foundryで一般提供開始したと発表しました。Azureでエージェントを構築してきた方にとって、これが待ち望んでいたアップデートです。

GPT-5 の進化

GPT-5: 推論と速度を1つのシステムに統合
GPT-5.4: より強力なマルチステップ推論、企業向けエージェント機能
GPT-5.5: より深い長コンテキスト推論、信頼性の高いエージェント実行、トークン効率の向上

実際に何が変わったか

エージェントコーディングの向上: GPT-5.5は大規模なコードベース全体でコンテキストを保持し、アーキテクチャ上の障害を診断し、テスト要件を予測します。修正が他に何に影響するかを行動前に推論します。

トークン効率: 少ないトークンと少ない再試行でより高品質な出力。本番デプロイメントでコストとレイテンシが直接削減されます。

長コンテキスト分析: 膨大なドキュメントやマルチセッション履歴をスレッドを失わずに処理。

価格

モデル	入力 ($/M tokens)	キャッシュ入力	出力 ($/M tokens)
GPT-5.5	$5.00	$0.50	$30.00
GPT-5.5 Pro	$30.00	$3.00	$180.00

Foundry が重要な理由

Foundry Agent Serviceでは、YAMLでエージェントを定義するか、Microsoft Agent Framework、GitHub Copilot SDK、LangGraph、またはOpenAI Agents SDKで接続できます。永続的なファイルシステム、独自のMicrosoft Entraアイデンティティ、ゼロスケール価格を持つ孤立したホステッドエージェントとして実行します。

AIAgent agent = aiProjectClient
 .AsAIAgent("gpt-5.5", instructions: "あなたは役立つアシスタントです。", name: "MyAgent");

完全な詳細は完全発表をご覧ください。

あなたのエージェントはどこで物事を覚えているか？チャット履歴ストレージの実践ガイド

Emiliano Montesdeoca — Sat, 25 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元の記事はこちらをご覧ください。

AIエージェントを構築する際、ほとんどのエネルギーをモデル、ツール、プロンプトに費やします。会話履歴がどこに保存されるかという問題は実装の詳細に見えますが、実は最も重要なアーキテクチャ上の決定の一つです。

これにより、ユーザーが会話を分岐させたり、回答を元に戻したり、再起動後にセッションを再開したりできるかどうか、そしてデータがインフラから出るかどうかが決まります。Agent FrameworkチームはLデープな分析を公開しました。

2つの基本パターン

サービス管理型: AIサービスが会話状態を保存します。アプリは参照（スレッドID、レスポンスID）を保持し、サービスは各リクエストに関連する履歴を自動的に含めます。

クライアント管理型: アプリが完全な履歴を管理し、各リクエストに関連メッセージを送信します。サービスはステートレスです。すべてを制御できます。

Agent Frameworkによる抽象化

AgentSession session = await agent.CreateSessionAsync();
var first = await agent.RunAsync("私の名前はAliceです。", session);
var second = await agent.RunAsync("私の名前は何ですか？", session);

session = agent.create_session()
first = await agent.run("私の名前はAliceです。", session=session)
second = await agent.run("私の名前は何ですか？", session=session)

セッションが基礎的な違いを処理します。プロバイダーを切り替えてもアプリケーションコードは変わりません。

プロバイダー早見表

プロバイダー	ストレージ	モデル	圧縮
OpenAI/Azure Chat Completions	クライアント	N/A	開発者
Foundry Agent Service	サービス	線形	サービス
Responses API（デフォルト）	サービス	分岐型	サービス
Anthropic Claude, Ollama	クライアント	N/A	開発者

選び方

会話の分岐や「やり直し」が必要？ → サービス管理型のResponses API
データ主権が必要？ → データベースバックドプロバイダーのクライアント管理型
シンプルなチャットボット？ → サービス管理型の線形で十分

完全な記事で意思決定ツリー全体を確認してください。

.NETのAgent Skillsが本気で柔軟になった

Emiliano Montesdeoca — Tue, 14 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

Microsoft Agent Frameworkでエージェントを構築しているなら、流れは分かっているはずです：スキルを定義し、プロバイダーに接続し、エージェントにどれを呼び出すか判断させる。新しいのはスキルの作り方であり、柔軟性の向上は大きなものです。

最新のアップデートでは、エージェントスキルの3つのオーサリングパターンが導入されました：ファイルベース、クラスベース、インラインコード定義。3つすべてが単一の AgentSkillsProviderBuilder に接続されるため、ルーティングロジックや特別なグルーコードなしで自由に組み合わせることができます。それぞれのパターンと、いつ使うべきかを説明します。

ファイルベースのスキル：出発点

ファイルベースのスキルはそのままの意味です — SKILL.mdファイル、オプションのスクリプト、参照ドキュメントを含むディスク上のディレクトリです。エージェントに新しい能力を与える最もシンプルな方法です：

skills/
└── onboarding-guide/
├── SKILL.md
├── scripts/
│ └── check-provisioning.py
└── references/
└── onboarding-checklist.md

SKILL.mdのフロントマターでスキル名と説明を宣言し、指示セクションでスクリプトと参照の使い方をエージェントに伝えます：

---
name: onboarding-guide
description: >-
 Walk new hires through their first-week setup checklist.
---

## Instructions

1. Ask for the employee's name and start date.
2. Run `scripts/check-provisioning.py` to verify accounts.
3. Walk through `references/onboarding-checklist.md`.
4. Follow up on incomplete items.

そして SubprocessScriptRunner.RunAsync でスクリプト実行を接続します：

var skillsProvider = new AgentSkillsProvider(
 Path.Combine(AppContext.BaseDirectory, "skills"),
 SubprocessScriptRunner.RunAsync);

AIAgent agent = new AzureOpenAIClient(new Uri(endpoint), new DefaultAzureCredential())
 .GetResponsesClient()
 .AsAIAgent(new ChatClientAgentOptions
 {
 Name = "HRAgent",
 ChatOptions = new() { Instructions = "You are a helpful HR assistant." },
 AIContextProviders = [skillsProvider],
 },
 model: deploymentName);

エージェントは自動的にスキルを発見し、アカウントステータスを確認する必要があるときにプロビジョニングスクリプトを呼び出します。クリーンでシンプルです。

クラスベースのスキル：NuGetで配布

ここからがチームにとって面白いところです。クラスベースのスキルは AgentClassSkill<T> から派生し、[AgentSkillResource] や [AgentSkillScript] などの属性を使用して、フレームワークがリフレクションですべてを発見します：

public sealed class BenefitsEnrollmentSkill : AgentClassSkill<BenefitsEnrollmentSkill>
{
 public override AgentSkillFrontmatter Frontmatter { get; } = new(
 "benefits-enrollment",
 "Enroll an employee in health, dental, or vision plans.");

 protected override string Instructions => """
 1. Read the available-plans resource.
 2. Confirm the plan the employee wants.
 3. Use the enroll script to complete enrollment.
 """;

 [AgentSkillResource("available-plans")]
 [Description("Plan options with monthly pricing.")]
 public string AvailablePlans => """
 ## Available Plans (2026)
 - Health: Basic HMO ($0/month), Premium PPO ($45/month)
 - Dental: Standard ($12/month), Enhanced ($25/month)
 - Vision: Basic ($8/month)
 """;

 [AgentSkillScript("enroll")]
 [Description("Enrolls employee in the specified benefit plan.")]
 private static string Enroll(string employeeId, string planCode)
 {
 bool success = HrClient.EnrollInPlan(employeeId, planCode);
 return JsonSerializer.Serialize(new { success, employeeId, planCode });
 }
}

素晴らしいのは、チームがこれをNuGetパッケージとしてパッケージ化できることです。プロジェクトに追加し、ビルダーに入れるだけで、ファイルベースのスキルと一緒に調整なしで動作します：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

両方のスキルがエージェントのシステムプロンプトに表示されます。エージェントは会話に基づいてどちらを使うか判断します — ルーティングコードは不要です。

インラインスキル：素早いブリッジ

別のチームがまさに必要なスキルを構築しているけど、次のスプリントまで完成しない、あの瞬間を知っていますか？AgentInlineSkill があなたのブリッジです：

var timeOffSkill = new AgentInlineSkill(
 name: "time-off-balance",
 description: "Calculate remaining vacation and sick days.",
 instructions: """
 1. Ask for the employee ID if not provided.
 2. Use calculate-balance to get the remaining balance.
 3. Present used and remaining days clearly.
 """)
 .AddScript("calculate-balance", (string employeeId, string leaveType) =>
 {
 int totalDays = HrDatabase.GetAnnualAllowance(employeeId, leaveType);
 int daysUsed = HrDatabase.GetDaysUsed(employeeId, leaveType);
 int remaining = totalDays - daysUsed;
 return JsonSerializer.Serialize(new { employeeId, leaveType, totalDays, daysUsed, remaining });
 });

他のスキルと同じようにビルダーに追加します：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .Build();

NuGetパッケージが最終的にリリースされたら、インラインスキルをクラスベースのバージョンに交換するだけです。エージェントは違いに気づきません。

ただし、インラインスキルはブリッジだけのものではありません。ランタイムで動的にスキルを生成する必要がある場合 — 設定からロードされるビジネスユニットごとのスキルを考えてみてください — やスクリプトがDIコンテナに属さないローカルステートをキャプチャする必要がある場合にも適切な選択です。

スクリプト承認：ヒューマンインザループ

本番エージェントを構築する.NET開発者にとって、これがデプロイメントの議論を本当に前進させる部分です。一部のスクリプトには実際の影響があります — 誰かを福利厚生に登録する、本番インフラを照会する。UseScriptApproval を有効にすると、エージェントはスクリプト実行前に一時停止します：

var skillsProvider = new AgentSkillsProviderBuilder()
 .UseFileSkill(Path.Combine(AppContext.BaseDirectory, "skills"))
 .UseSkill(new BenefitsEnrollmentSkill())
 .UseSkill(timeOffSkill)
 .UseFileScriptRunner(SubprocessScriptRunner.RunAsync)
 .UseScriptApproval(true)
 .Build();

エージェントがスクリプトを実行したいとき、代わりに承認リクエストを返します。アプリが判断を収集し — 承認または拒否 — エージェントはそれに応じて続行します。規制環境では、これが「デプロイできる」と「法務がノーと言っている」の違いです。

なぜこの組み合わせが重要なのか

本当の力は個々のパターンにあるのではなく、構成にあります。以下が可能になります：

ファイルベースのスキルで小さく始めて、指示を反復し、C#を書かずに公開する
他のチームが1行で追加できるNuGetパッケージとして再利用可能なスキルを配布する
何か今すぐ必要なときにインラインスキルでギャップを埋める
エージェントが必要なものだけをロードするようにプレディケートで共有ディレクトリをフィルタリングする
本番システムに触れるスクリプトに人間の監視を追加する

これらすべてが AgentSkillsProviderBuilder を通じて構成されます。特別なルーティングなし、条件ロジックなし、スキルタイプチェックなし。

まとめ

.NETのエージェントスキルは、真に柔軟なオーサリングモデルを手に入れました。ファイルベースのスキルでプロトタイピングするソロ開発者であろうと、NuGet経由でパッケージ化された機能を配布するエンタープライズチームであろうと、パターンは適合します。そしてスクリプト承認メカニズムにより、人間のチェックポイントが必要な環境でも本番対応できます。

オリジナルの発表、Microsoft LearnのAgent Skillsドキュメント、GitHubの.NETサンプルをチェックして始めましょう。

ブラックボックスに感じないリアルタイムマルチエージェントUIを構築する

Emiliano Montesdeoca — Fri, 10 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。原文はこちらをご覧ください。

マルチエージェントシステムの問題点はこうです：デモでは信じられないほど素晴らしく見えます。3つのエージェントが作業を受け渡し、問題を解決し、意思決定を行う。でも実際のユーザーの前に置いてみると…沈黙。回転するインジケーター。どのエージェントが何をしているのか、なぜシステムが停止しているのか分からない。これはプロダクトではありません — 信頼の問題です。

Microsoft Agent Frameworkチームが、MAFワークフローとAG-UIを組み合わせる素晴らしいウォークスルーを公開しました。AG-UIはServer-Sent Eventsを介してエージェント実行イベントをフロントエンドにストリーミングするオープンプロトコルです。正直に言うと、これはまさに私たちに欠けていた架け橋です。

.NET開発者にとって重要な理由

AI搭載アプリを構築しているなら、おそらくこの壁にぶつかったことがあるでしょう。バックエンドのオーケストレーションは完璧に動作します — エージェント同士がタスクを受け渡し、ツールが実行され、意思決定が行われます。しかしフロントエンドは裏で何が起きているか全く分かりません。AG-UIは、エージェントイベント（RUN_STARTED、STEP_STARTED、TOOL_CALL_*、TEXT_MESSAGE_*など）をSSE経由でUIレイヤーに直接ストリーミングする標準プロトコルを定義することでこれを解決します。

デモは3つのエージェントを使ったカスタマーサポートワークフローです：リクエストをルーティングするトリアージエージェント、金銭関連を処理する返金エージェント、そして交換を管理する注文エージェント。各エージェントは独自のツールを持ち、ハンドオフトポロジーは明示的に定義されています — 「プロンプトから推測する」ようなことはありません。

ハンドオフトポロジーが真の主役

私の目を引いたのは、HandoffBuilderでエージェント間の有向ルーティンググラフを宣言できることです：

builder = HandoffBuilder(
 name="ag_ui_handoff_workflow_demo",
 participants=[triage, refund, order],
 termination_condition=termination_condition,
)

(
 builder
 .add_handoff(triage, [refund], description="Refunds, damaged-item claims...")
 .add_handoff(triage, [order], description="Replacement, exchange...")
 .add_handoff(refund, [order], description="Replacement logistics needed after refund.")
 .add_handoff(order, [triage], description="After replacement/shipping tasks complete.")
)

各add_handoffは自然言語の説明付きの有向エッジを作成します。フレームワークはこのトポロジーに基づいて各エージェントのハンドオフツールを生成します。つまり、ルーティングの決定はオーケストレーション構造に基づいており、LLMの気分次第ではありません。これは本番環境の信頼性にとって非常に大きな意味があります。

本当に機能するHuman-in-the-loop

デモでは、実際のエージェントアプリに必要な2つの割り込みパターンを紹介しています：

ツール承認割り込み — エージェントがapproval_mode="always_require"とマークされたツールを呼び出すと、ワークフローが一時停止してイベントを発行します。フロントエンドはツール名と引数を含む承認モーダルをレンダリングします。トークンを消費するリトライループはありません — クリーンな一時停止-承認-再開フローです。

情報リクエスト割り込み — エージェントがユーザーからより多くのコンテキスト（注文IDなど）を必要とする場合、一時停止して質問します。フロントエンドが質問を表示し、ユーザーが回答し、実行は停止した箇所からそのまま再開されます。

両方のパターンは標準のAG-UIイベントとしてストリーミングされるため、フロントエンドはエージェントごとのカスタムロジックを必要としません — SSE接続を通じて届くイベントをそのまま表示するだけです。

接続は驚くほど簡単

MAFとAG-UIの統合は単一の関数呼び出しで完了します：

from agent_framework.ag_ui import (
 AgentFrameworkWorkflow,
 add_agent_framework_fastapi_endpoint,
)

app = FastAPI()

demo_workflow = AgentFrameworkWorkflow(
 workflow_factory=lambda _thread_id: create_handoff_workflow(),
 name="ag_ui_handoff_workflow_demo",
)

add_agent_framework_fastapi_endpoint(
 app=app, agent=demo_workflow, path="/handoff_demo",
)

workflow_factoryはスレッドごとに新しいワークフローを作成し、各会話が分離された状態を持ちます。エンドポイントはすべてのSSE配管を自動的に処理します。すでにFastAPIを使っている（または軽量レイヤーとして追加できる）なら、ほぼゼロフリクションです。

私の見解

私たち.NET開発者にとって、すぐに浮かぶ質問は「C#でできるのか？」です。Agent Frameworkは.NETとPythonの両方で利用可能で、AG-UIプロトコルは言語に依存しません（ただのSSEです）。この特定のデモはPythonとFastAPIを使用していますが、パターンは直接転用できます。同じAG-UIイベントスキーマに従ったSSEエンドポイントを持つASP.NET Core最小APIを構築できるでしょう。

より大きなポイントは、マルチエージェントUIが後付けではなくファーストクラスの関心事になりつつあるということです。エージェントが人間と対話するものを構築しているなら — カスタマーサポート、承認ワークフロー、ドキュメント処理 — MAFオーケストレーションとAG-UIの透明性の組み合わせが、従うべきパターンです。

まとめ

AG-UI + Microsoft Agent Frameworkは、バックエンドでの堅牢なマルチエージェントオーケストレーションとフロントエンドでのリアルタイム可視性という、両方の良いところを提供します。もうブラックボックスのエージェントインタラクションとはお別れです。

完全なウォークスルーとAG-UIプロトコルリポジトリをチェックして、さらに深く掘り下げてください。

Microsoft Agent Frameworkが1.0に到達 — .NET開発者にとって本当に重要なこと

Emiliano Montesdeoca — Fri, 03 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。原文はこちらをご覧ください。

Semantic KernelやAutoGenの初期からAgent Frameworkの歩みを追ってきた方にとって、今回のニュースは大きいです。Microsoft Agent Frameworkがバージョン1.0に到達しました — 本番環境対応、安定したAPI、長期サポートのコミットメント。.NETとPythonの両方で利用可能で、実際のワークロードに本当に対応できる状態です。

発表のノイズを切り抜けて、.NETでAI搭載アプリを構築している方にとって重要なポイントに集中しましょう。

短いまとめ

Agent Framework 1.0は、かつてSemantic KernelとAutoGenだったものを単一のオープンソースSDKに統合します。1つのエージェント抽象化。1つのオーケストレーションエンジン。複数のAIプロバイダー。エンタープライズパターン向けのSemantic Kernelと研究グレードのマルチエージェントワークフロー向けのAutoGenを行き来していた方は、もうその必要はありません。これが唯一のSDKです。

はじめるのはほぼ不公平なほど簡単

.NETで動作するエージェントはこちら：

// dotnet add package Microsoft.Agents.AI.OpenAI --prerelease
using Microsoft.Agents.AI;
using Microsoft.Agents.AI.Foundry;
using Azure.Identity;

var agent = new AIProjectClient(endpoint: "https://your-project.services.ai.azure.com")
 .GetResponsesClient("gpt-5.3")
 .AsAIAgent(
 name: "HaikuBot",
 instructions: "You are an upbeat assistant that writes beautifully."
 );

Console.WriteLine(await agent.RunAsync("Write a haiku about shipping 1.0."));

これだけです。数行でAzure Foundryに対して実行されるAIエージェントが完成します。Pythonの同等コードも同様に簡潔です。関数ツール、マルチターン会話、ストリーミングは必要に応じて追加できます — APIサーフェスは奇妙になることなくスケールアップします。

マルチエージェントオーケストレーション — これが本題

単一エージェントはデモには十分ですが、本番シナリオには通常、調整が必要です。Agent Framework 1.0は、Microsoft ResearchとAutoGenから直接もたらされた実戦テスト済みのオーケストレーションパターンを搭載しています：

シーケンシャル — エージェントが順番に処理（ライター → レビュアー → エディター）
コンカレント — 複数のエージェントに並列で展開し、結果を収束
ハンドオフ — 1つのエージェントがインテントに基づいて別のエージェントに委任
グループチャット — 複数のエージェントが議論し、解決策に収束
Magentic-One — MSRの研究グレードのマルチエージェントパターン

すべてがストリーミング、チェックポイント、ヒューマンインザループの承認、一時停止/再開をサポートしています。チェックポイントの部分は重要です — 長時間実行されるワークフローがプロセスの再起動を生き延びます。Azure Functionsで耐久性のあるワークフローを構築してきた.NET開発者にとって、これは馴染みのある感覚です。

最も重要な機能

知っておく価値があるものの私のリストはこちら：

ミドルウェアフック。 ASP.NET Coreにミドルウェアパイプラインがあるのをご存知ですか？同じコンセプトですが、エージェント実行用です。すべてのステージをインターセプト — コンテンツセーフティ、ロギング、コンプライアンスポリシーを追加 — エージェントのプロンプトに触れることなく。これがエージェントをエンタープライズ対応にする方法です。

プラガブルメモリ。 会話履歴、永続的なキーバリューステート、ベクトルベースの検索。バックエンドを選択：Foundry Agent Service、Mem0、Redis、Neo4j、またはカスタム実装。メモリは、ステートレスなLLM呼び出しを、実際にコンテキストを覚えているエージェントに変えるものです。

宣言的YAMLエージェント。 エージェントの指示、ツール、メモリ、オーケストレーショントポロジーをバージョン管理されたYAMLファイルで定義します。単一のAPI呼び出しでロードして実行。これは、コードを再デプロイせずにエージェントの動作をイテレーションしたいチームにとってゲームチェンジャーです。

A2AとMCPサポート。 MCP（Model Context Protocol）により、エージェントは外部ツールを動的に発見して呼び出すことができます。A2A（Agent-to-Agentプロトコル）はクロスランタイムコラボレーションを実現します — .NETエージェントは他のフレームワークで実行されているエージェントと連携できます。A2A 1.0サポートは近日対応予定です。

注目すべきプレビュー機能

1.0ではいくつかの機能がプレビューとして出荷されました — 機能は動作しますがAPIは変更される可能性があります：

DevUI — エージェントの実行、メッセージフロー、ツール呼び出しをリアルタイムで可視化するブラウザベースのローカルデバッガー。Application Insightsのようなものですが、エージェントの推論用です。
GitHub Copilot SDKとClaude Code SDK — オーケストレーションコードから直接CopilotまたはClaudeをエージェントハーネスとして使用。同じワークフロー内の他のエージェントと一緒にコーディング対応エージェントを構成できます。
Agent Harness — エージェントにシェル、ファイルシステム、メッセージングループへのアクセスを提供するカスタマイズ可能なローカルランタイム。コーディングエージェントや自動化パターンを想像してください。
Skills — エージェントに構造化された機能をすぐに提供する再利用可能なドメイン機能パッケージ。

Semantic KernelまたはAutoGenからの移行

既存のSemantic KernelまたはAutoGenコードがある場合、コードを分析してステップバイステップの移行プランを生成する専用の移行アシスタントがあります。Semantic Kernel移行ガイドとAutoGen移行ガイドがすべてを案内してくれます。

RCパッケージを使用していた場合、1.0へのアップグレードはバージョン番号の変更だけです。

まとめ

Agent Framework 1.0は、エンタープライズチームが待ち望んでいた本番環境のマイルストーンです。安定したAPI、マルチプロバイダーサポート、実際に大規模に機能するオーケストレーションパターン、そしてSemantic KernelとAutoGenの両方からの移行パス。

フレームワークはGitHubで完全にオープンソースで、dotnet add package Microsoft.Agents.AIで今日から始められます。クイックスタートガイドとサンプルをチェックして、実際に触ってみてください。

「本番環境で安全に使える」というシグナルを待っていた方へ — これがそのシグナルです。

Microsoft Agent Frameworkのバックグラウンドレスポンス：タイムアウトの不安から解放

Emiliano Montesdeoca — Thu, 26 Mar 2026 00:00:00 +0000

o3やGPT-5.2のような推論モデルで何かを構築したことがあるなら、その痛みを知っているでしょう。エージェントが複雑なタスクについて考え始め、クライアントは待ち続け、「大丈夫」と「クラッシュした？」の間のどこかで接続がタイムアウトする。あの作業は？全て消えます。

Microsoft Agent Frameworkがバックグラウンドレスポンスをリリースしました — 正直なところ、これは初日から存在すべきだった機能の一つです。

ブロッキング呼び出しの問題

従来のリクエスト-レスポンスパターンでは、エージェントが終了するまでクライアントはブロックされます。簡単なタスクには問題ありません。しかし、推論モデルに深い調査、多段階分析、20ページのレポート生成を依頼する場合は？実時間で数分かかります。その間：

HTTP接続がタイムアウトする可能性がある
ネットワークの途切れが操作全体を壊す
ユーザーはスピナーを見つめて何かが起きているか疑問に思う

バックグラウンドレスポンスはこれを逆転させます。

継続トークンの仕組み

ブロックする代わりに、エージェントタスクを起動して継続トークンを受け取ります。修理工場の引換券のようなものです — カウンターに立って待つ必要はなく、準備ができたら戻ってくればいいのです。

フローは単純です：

AllowBackgroundResponses = trueでリクエストを送信
エージェントがバックグラウンド処理をサポートしていれば、継続トークンを受け取る
トークンがnullを返すまでポーリング — 結果の準備完了を意味します

.NETバージョンはこちら：

AIAgent agent = new AzureOpenAIClient(
 new Uri("https://<myresource>.openai.azure.com"),
 new DefaultAzureCredential())
 .GetResponsesClient("<deployment-name>")
 .AsAIAgent();

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();

AgentResponse response = await agent.RunAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options);

// 完了までポーリング
while (response.ContinuationToken is not null)
{
 await Task.Delay(TimeSpan.FromSeconds(2));
 options.ContinuationToken = response.ContinuationToken;
 response = await agent.RunAsync(session, options);
}

Console.WriteLine(response.Text);

エージェントがすぐに完了する場合（簡単なタスク、バックグラウンド処理を必要としないモデル）、継続トークンは返されません。コードはそのまま動きます — 特別な処理は不要です。

再開付きストリーミング：本当のマジック

ポーリングはfire-and-forgetシナリオには良いですが、リアルタイムの進捗が欲しい場合は？バックグラウンドレスポンスは再開機能付きストリーミングもサポートしています。

各ストリーム更新は独自の継続トークンを持ちます。ストリーム中に接続が切れても、中断した正確な位置から再開できます：

AgentRunOptions options = new()
{
 AllowBackgroundResponses = true
};

AgentSession session = await agent.CreateSessionAsync();
AgentResponseUpdate? latestUpdate = null;

await foreach (var update in agent.RunStreamingAsync(
 "Write a detailed market analysis for the Q4 product launch.", session, options))
{
 Console.Write(update.Text);
 latestUpdate = update;
 break; // ネットワーク中断をシミュレート
}

// 中断した正確な位置から再開
options.ContinuationToken = latestUpdate?.ContinuationToken;
await foreach (var update in agent.RunStreamingAsync(session, options))
{
 Console.Write(update.Text);
}

クライアントに何が起きてもサーバー側でエージェントは処理を続けます。リトライロジックやサーキットブレーカーを書くことなく、組み込みのフォールトトレランスが実現します。

実際にいつ使うべきか

すべてのエージェント呼び出しにバックグラウンドレスポンスが必要なわけではありません。高速な完了には無駄な複雑さを追加するだけです。しかし、ここで威力を発揮します：

複雑な推論タスク — 多段階分析、深い調査、推論モデルを本気で考えさせるもの
長文コンテンツ生成 — 詳細レポート、複数パートのドキュメント、広範な分析
信頼性の低いネットワーク — モバイルクライアント、エッジデプロイメント、不安定な企業VPN
非同期UXパターン — タスクを送信し、他のことをして、結果を取りに戻る

エンタープライズアプリを構築する.NET開発者にとって、最後のポイントは特に興味深いです。ユーザーが複雑なレポートを要求するBlazorアプリを想像してください — エージェントタスクを起動し、プログレスインジケータを表示し、作業を続けてもらう。WebSocketの曲芸なし、カスタムキューインフラなし、トークンとポーリングループだけです。

まとめ

バックグラウンドレスポンスはMicrosoft Agent Frameworkを通じて.NETとPythonの両方で今すぐ利用可能です。単純なQ&A以上のことをするエージェントを構築しているなら、ツールキットに追加する価値があります。継続トークンパターンはシンプルさを保ちながら、非常に現実的な本番環境の問題を解決します。

完全なAPIリファレンスとその他のより例については完全なドキュメントをご覧ください。

Agent-Framework | The .NET Blog

Microsoft Foundry 2026年4月: Foundry Local GA、GPT-5.5、HyperlightによるCodeAct

Foundry Localが一般提供開始

GPT-5.5

FoundryでのAgent Frameworkトレーシング

HyperlightによるCodeAct（Alpha）

エージェント監視ダッシュボード（プレビュー）

継続的評価カスタムエバリュエーター（プレビュー）

コントロールプレーンのエージェントインベントリ

ハンドオフパターン：1つのエージェントでは不十分な時

Handoffの仕組み

最小限の例

Handoffを使う時（と使わない時）

バックエッジとHuman-in-the-Loop

まとめ

Microsoft Agent Frameworkにおける永続的ワークフロー：In-MemoryからAzure Functionsへ

基本的な構成要素

ローカル開発用In-Memoryランナー

Durable Taskで永続性を追加

Azure Functionsホスティング

なぜこれが重要か

あなたのローカル MAF エージェントが本番環境の家を手に入れました

Foundry Hosted Agents が実際に何をするか

コードの違いは最小限

2 つのプロトコル、1 つのエージェント

azd を使ったデプロイフロー

まとめ

エージェントを作るのは簡単な部分 — 安全に実行するのが難しい部分

各プロジェクトが実際に行うこと

接続はミドルウェアを追加するだけ

何を得るか

5つの業界シナリオ

まとめ

A2A v1 登場: Microsoft Agent Framework for .NET でのクロスプラットフォームエージェント通信

A2A v1 の実体

リモート A2A エージェントへの接続

エージェントを A2A エンドポイントとして公開

実際に何を意味するか

Agent FrameworkのCodeAct：エージェントのレイテンシを半分にする方法

CodeActとは？

セキュリティ：Hyperlightマイクロ-VM

最小セットアップ

いつCodeActを使うか（使わないか）

今すぐ試す

GPT-5.5 が Azure Foundry に登場 — .NET 開発者が知っておくべきこと

GPT-5 の進化

実際に何が変わったか

価格

Foundry が重要な理由

あなたのエージェントはどこで物事を覚えているか？チャット履歴ストレージの実践ガイド

2つの基本パターン

Agent Frameworkによる抽象化

プロバイダー早見表

選び方

.NETのAgent Skillsが本気で柔軟になった

ファイルベースのスキル：出発点

クラスベースのスキル：NuGetで配布

インラインスキル：素早いブリッジ

スクリプト承認：ヒューマンインザループ

なぜこの組み合わせが重要なのか

まとめ

ブラックボックスに感じないリアルタイムマルチエージェントUIを構築する

.NET開発者にとって重要な理由

ハンドオフトポロジーが真の主役

本当に機能するHuman-in-the-loop

接続は驚くほど簡単

私の見解

まとめ

Microsoft Agent Frameworkが1.0に到達 — .NET開発者にとって本当に重要なこと

短いまとめ

はじめるのはほぼ不公平なほど簡単

マルチエージェントオーケストレーション — これが本題

最も重要な機能

注目すべきプレビュー機能

Semantic KernelまたはAutoGenからの移行

まとめ

Microsoft Agent Frameworkのバックグラウンドレスポンス：タイムアウトの不安から解放

ブロッキング呼び出しの問題

継続トークンの仕組み

再開付きストリーミング：本当のマジック

`azd` を使ったデプロイフロー