Ai | The .NET Blog

NL2SQLはエージェント時代のSQLインジェクションだ

Emiliano Montesdeoca — Wed, 03 Jun 2026 00:00:00 +0000

NL2SQLのピッチには完璧に聞こえるバージョンがあります：ユーザーが自然言語で質問し、エージェントがSQLを生成し、データが返ってくる。画面が少なく、クエリが少なく、コードが少ない。シンプル。

そして5分後にもっと考えます。

デモで誰も話さない問題

スキーマは物事を説明するように設計されていません。 不可解なテーブル名、一貫性のないカラム名、追加の述語なしでは意味的に無効な技術的に有効な関係 — これらはエンタープライズデータベースでは普通のことです。バグではなく、ビジネス変更の蓄積された歴史です。しかし、意図を伝えるように設計されていないスキーマから意図を推論するようにモデルに求めると、モデルは何があっても試みます。諦めません。最善のクエリを生成し、自信を持って結果を返します。

モデルは決定論的ではありません。 同じデータベースに同じ質問を2回して、異なるSQLを得るかもしれません。モデルは確率を計算しており、コンテキストのわずかな変化が異なる出力を生み出します。エージェントが常に正しいクエリを生成するという保証をテストで達成することはできません。

ユーザーレビューはスケールしません。 「実行前にすべてのクエリを確認するだけ」は安全に聞こえます。しかし、ユーザーがデータモデルとSQLの両方の専門家であることを前提としています — 自然言語インターフェースを必要としなかった人々まさにその人たちです。また、認知的過負荷と確認バイアスの新しいクラスをもたらし、クエリの複雑さに圧倒されたユーザーが無効なクエリを調査するのではなく承認します。

そしてインジェクションがあります。 従来のSQL開発では、パラメータ化がインジェクションを解決しました。ユーザー入力はSQLの構造ではなく、パラメータを埋めていたからです。NL2SQLでは、モデルがSQL自体を生成します。プロンプト、スキーマコンテキスト、会話履歴、取得されたデータすべてが実行されるものに影響します。誰かがモデルが生成するものを変えるプロンプトを作成した場合、それはインジェクションです — パラメータレベルではなく、クエリ生成レベルで。そしてテーブルの削除（明らか、回復可能）とは異なり、NL2SQLインジェクションは目に見えるエラーなしに誤った結果を返すクエリを生成します。ビジネス上の意思決定が間違ったデータに基づいてなされます。

SQL MCP Serverが実際に解決すること

ここで記事は最も実践的に有用な点を述べます。エージェントに任意のスキーマアクセスを与えて最善を望むのではなく、SQL MCP ServerはData API builderの上に構築された厳選されたAPIサーフェスを公開します。

違いは重要です：エージェントはSQLを生成しません。事前定義された結果形式を返す名前付きエンドポイントを呼び出します。SQLは開発者によって一度書かれ、決定論的です。エージェントの非決定論は任意のクエリを構築することではなく、どのエンドポイントを呼び出すかを選択することに制限されます。

これは従来のアプリモデルでのSQLインジェクションに対してパラメータ化が行ったこと — 信頼できない入力から任意のクエリを構築する能力を削除すること — に類似しています。

正しい質問

記事は「NL2SQLを決して使うな」とは言っていません。それは言います：どこで適用し、何を公開するかについて慎重に考えてください。スコープされたスキーマと読み取り専用アクセスを持つ制御された環境での探索的分析には、NL2SQLで問題ないかもしれません。ビジネス上の意思決定が結果に依存する本番システムには、厳選されたAPIレイヤーが大幅に安全です。

正直に言うと：いくつかの問題は、自然言語からSQLよりも名前付きエンドポイントの背後にある構造化されたクエリで解決する方が本当に優れています。SQL MCP Serverはエージェントインターフェースを完全に放棄することなく、そのオプションを提供します。

元の投稿: Considering NL2SQL? Should your database really be the prompt? How can SQL MCP Server help?

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

Foundry Local 1.1: リアルタイム文字起こし、Embeddings、Responses API

Emiliano Montesdeoca — Thu, 28 May 2026 00:00:00 +0000

Foundry Local 1.0 はコンセプトを証明しました：開発者フレンドリーな SDK で Windows、macOS（Apple Silicon）、Linux x64 上で AI モデルをローカルで実行できること。バージョン 1.1 は多くの実際の本番ユースケースをカバーする 3 つの機能を追加しています。

ライブ音声文字起こし

最も重要な新機能：マイクから直接リアルタイムで音声をテキストにストリーミング変換。字幕、音声 UI、会議の文字起こし、アクセシビリティツール — すべてクラウド依存なしでローカル実行されます。

API はセッションベースで、結果が到着するとすぐに送信し、中間テキストと確定テキストを区別するための is_final マーカーを使用します。JavaScript、C#、Python、Rust のすべての言語バインディングで利用可能です。

カタログからストリーミング音声モデルを読み込み、音声設定（サンプルレート、チャンネル、言語）でセッションを作成し、起動し、生の PCM オーディオチャンクをプッシュして、結果の非同期ストリームを消費します。投稿には Python と C# の完全な例があります。

テキスト Embeddings

セマンティック検索、RAG パイプライン、クラスタリング、類似性マッチング — これらすべてに embeddings が必要です。Foundry Local 1.1 は embedding モデルのサポートを追加し、クラウドエンドポイントにデータを送信せず、同じ SDK からローカルでベクターを生成できます。

データの居住性が重要なアプリケーションや機密コンテンツを処理する場合、ローカルでの embedding 生成は重要な機能です。

Responses API

Foundry Local は Responses API — エージェント的インタラクションのために設計された構造化インターフェース — をサポートするようになりました。これにより追加されるのは：

ツール呼び出し — ローカルで実行中のモデルが定義したツールを呼び出すことを可能にします
マルチモーダルビジョン-言語入力 — ビジョン対応モデルに画像 + テキストを渡します
標準 API 形式と互換性があるため、OpenAI の Responses API を対象とした既存のエージェントがローカルモデルに対して動作します

パッケージサイズの改善

2 つの変更により JavaScript パッケージサイズが削減されます：

koffi FFI レイヤーがカスタム Node-API C アドオンに置き換えられました
WebGPU 実行プロバイダーは別のプラグインとして配布されるため、GPU アクセラレーションを必要としないアプリケーションはサイズコストを支払う必要がありません

C# SDK は .NET の幅広い互換性のためにより低いフレームワークバージョンをターゲットとするようになりました。

なぜこれが重要か

3 つの機能 — 文字起こし、embeddings、ツール呼び出し — は多くの AI アプリケーションのコアビルディングブロックをカバーしています。これらをローカルで実行することは以下を意味します：

インターネット不要
トークンコストなし
データがマシンを離れない
ネットワーク状態に関わらず一定の遅延

Foundry Local は、エッジシナリオ、プライバシーに敏感なワークロード、オフラインアプリケーション、または開発中にクラウド依存を避けたいあらゆるものに適しています。

元の投稿：Foundry Local 1.1: Live Transcription, Embeddings, and Responses API

Cosmos DB Shell はパブリックプレビューに — そして MCP サーバーが内蔵されている

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

1 つの Cosmos DB の質問に答えるだけのために、ポータルのタブ、SDK サンプル、そして書きかけのスクリプトを行き来した経験があるなら、このプロジェクトが解消しようとしている摩擦をすでに知っているでしょう。

Azure Cosmos DB Shell がパブリックプレビューに入りました。bash ライクな構文を持つオープンソース CLI であり、そして — これを面白くする部分 — 統合された MCP サーバーを備えています。

他のデータベース CLI との違い

CLI 自体は有用です：使い慣れたコマンド、スクリプトサポート、CI/CD 統合。この部分は開発者向けデータベースツールの最低限のものです。

興味深い部分は MCP サーバーの統合です。CLI が公開するすべてのコマンドが、AI エージェントが呼び出せる MCP ツールとして利用可能になります。カスタム API レイヤーはなく、書くべき統合コードもありません。エージェントは次のことができます：

cd、ls、pwd でデータベース階層を移動
query で SQL クエリを実行し、構造化された結果を取得
create item、update、rm でアイテムを作成・変更
mkdb、mkcon、rmdb、rmcon でデータベースとコンテナを管理
endpoint、pwd で現在のコンテキストを確認

重要な変化：エージェントは Cosmos DB API と話しているのではなく、あなたが使う同じシェルインターフェイスと話しています。コマンドは決定論的で監査可能であり、正確に何が起きているかを確認できるようオープンソースです。

オープンソースの基盤が重要

これはブラックボックスのマネージドサービスではありません。シェルはオープンソースであり、それが意味することは：

セキュリティチームが実装を監査できる
プラットフォームチームが特定の標準に合わせてフォークして拡張できる
開発者が全員のためになる改善を貢献できる

AI ツールを採用する企業チームにとって、「正確にどう動くか見られますか」はオプションの要件でなくなりつつあります。ここでのオープンソースは意味ある差別化要因です。

簡単になる 3 つのシナリオ

インテリジェントなデータ分析 — エージェントをシェルに接続し、自然言語で質問し、構造化されたクエリ結果を得る。クエリの構築はエージェントが担当し、実行はシェルが担当します。

自律的なデータ管理 — Cosmos DB でデータを作成、更新、削除する必要があるワークフローは、カスタム統合を必要とせず MCP ツールを通じて行えます。

リアルタイム監視とアラート — エージェントがコンテナを定期的にクエリし、結果を比較し、意味のある通知チャネルで異常を報告できます。

MCP インターフェイスにより、これらのシナリオは MCP を話す任意の AI プラットフォームと組み合わせ可能になります — Microsoft のツールだけでなく。

始め方

シェルはパブリックプレビュー中です。インストールし、Cosmos DB 接続を設定し、MCP サーバーを有効にします。そこから、MCP 互換の任意のエージェントホストがツールを発見して使用できます。

元の投稿：Announcing the Public Preview of Azure Cosmos DB Shell: Open-Source Power Meets AI-Driven Database Automation

Azure SQL がエンベディングを生成できるようになりました — 純粋な T-SQL で、アプリ層不要

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

RAG パイプラインを構築したことがあれば、パイプライン税を知っているでしょう: データは SQL に存在しますが、エンベディングを生成するにはデータを抽出し、エンベディング API を呼び出し、バッチ処理とレート制限を処理し、ベクトル検索が可能な場所に結果を保存する必要があります。多くの場合、まったく異なるデータベースに。

Azure SQL は、現在一般提供されている 2 つの機能でその大部分を排除しました: CREATE EXTERNAL MODEL と AI_GENERATE_EMBEDDINGS。

何をするか

これら 2 つの T-SQL 機能は統合パイプラインとして機能します:

CREATE EXTERNAL MODEL — 外部 AI モデルエンドポイントを名前付きデータベースオブジェクトとして登録します。場所、API フォーマット、モデルタイプ、資格情報を一度設定します。どこでも再利用できます。

AI_GENERATE_EMBEDDINGS — 登録されたモデルを呼び出し、ベクトル値の JSON 配列を返すスカラー T-SQL 関数です。SELECT、INSERT、UPDATE、MERGE 文で動作します。

合わせて、SQL エンジンを離れることなくエンドツーエンドのエンベディングパイプラインを形成します。

完全なワークフロー

-- ステップ 1: エンベディングプロバイダーを一度登録する
CREATE EXTERNAL MODEL MyEmbeddingModel
WITH (
 LOCATION = 'https://your-aoai-resource.openai.azure.com/',
 API_FORMAT = 'Azure OpenAI',
 MODEL_TYPE = EMBEDDINGS,
 MODEL = 'text-embedding-ada-002'
);

-- ステップ 2: T-SQL でインラインにエンベディングを生成する
UPDATE docs
SET embedding = AI_GENERATE_EMBEDDINGS(content USE MODEL MyEmbeddingModel)
FROM documents AS docs;

-- ステップ 3: ベクトル距離で検索する
SELECT TOP 10 id, content
FROM documents
ORDER BY VECTOR_DISTANCE('cosine', embedding,
 AI_GENERATE_EMBEDDINGS(@query USE MODEL MyEmbeddingModel));

これがパイプライン全体です: SQL のデータ、SQL で生成されたエンベディング、SQL での類似性検索。オーケストレーション層なし、ETL なし、別個のベクトルデータベースなし。

サポートされる API フォーマットとオプション

GA では、API_FORMAT は Azure OpenAI と OpenAI をサポートします。MODEL_TYPE は現在 EMBEDDINGS に固定されています。PARAMETERS JSON では、再試行回数を含むモデルレベルのデフォルトを設定できます:

PARAMETERS = '{"sql_rest_options":{"retry_count":3}}'

認証はデータベース資格情報を使用するため、シークレットはアプリケーションコードの外に保持されます。

.NET アプリケーションで何が可能になるか

既存の SQL データの上に AI 機能を構築する .NET 開発者にとって、これは重要です。以下は不要です:

エンベディング用に中間ストアにデータを抽出する
外部エンベディングパイプラインを管理する
別個のベクトルデータベースを設定する (フル機能のベクトルストアが必要な場合は Azure AI Search を使用できますが)
アプリケーションのデータアクセス層を変更する

既存の SQL アプリケーションに段階的にセマンティック検索を追加できます。すでにお持ちの同じ T-SQL ツールを使用して。

まとめ

SQL データに対する RAG パターンが劇的にシンプルになりました。AI_GENERATE_EMBEDDINGS + CREATE EXTERNAL MODEL は、既存の SQL アプリケーションが新しいインフラを追加することなくベクトル検索機能を獲得できることを意味します。

両機能は本日、Azure SQL Database と Azure SQL Managed Instance で GA です。

元の投稿: Generate Embeddings Function and External Model Object Support Are Now Generally Available in Azure SQL

あなたの AI エージェントにはアイデンティティの問題があります（そしてこれがそれを解決するテンプレートです）

Emiliano Montesdeoca — Wed, 20 May 2026 00:00:00 +0000

すべての AI エージェントプロジェクトには、こんな瞬間があります: デモは完璧に機能し、エージェントは自然言語を解釈し、正しい API を呼び出し、正しいデータを返します。そして実際のユーザーについて考え始めます。

あるユーザーのエージェントセッションが別のユーザーのデータを見るのを何が防ぐのでしょうか？エージェントがプロンプトインジェクションで騙された場合はどうなるでしょうか？予期しない方法でツールを呼び出した場合はどうなるでしょうか？

これらはエッジケースではありません。これらはリリース前に行うべき設計上の決定です。

Curity と Microsoft による新しい azd テンプレートは、まさにこの問題に対して機能するリファレンスを提供します。

核心的な問題: 認証 ≠ 認可

ほとんどのエージェントサンプルはユーザー認証をうまく処理しています。認可の処理は不十分です。ユーザーが誰であるかを知っていても、彼らが見るべきデータが何かはわかりません。

従来のクライアントアプリは予測可能な API 呼び出しを行います。AI エージェントは非決定論的です — 自然言語を解釈し、何を呼び出すかを決定します。創造的になれます。また間違える可能性もあります。プロンプトインジェクションによって操作される場合、AI が適切に動作することに依存しないルールが必要です。

このテンプレートが示す解決策: 各ホップに正確に正しい情報を運ぶ短命のトークン。

トークンチェーンの仕組み

テンプレートは OAuth 2.0 アクセストークンとトークン交換を使用して、各ステップで権限を絞り込みます。ユーザートークンは MCP サーバーに到達する前に 2 回交換されます:

最初の交換 — スコープを絞り込み、不透明なトークンを JWT に変換
2 番目の交換 — エージェント ID と MCP サーバーホップのための新しいオーディエンスを追加

MCP サーバートークンがどのように見えるか:

{
 "scope": "stocks/read",
 "sub": "62c839b8...",
 "aud": "https://mcp.demo.example",
 "customer_id": "178",
 "region": "USA"
}

customer_id は認可サーバーによってトークンに組み込まれており、エージェントが制御するパラメータとして渡されません。API はエージェントの指示ではなく、トークンをチェックします。

これが意味すること: エージェントが別の顧客のデータを取得しようとするよう騙されたとしても、トークンはそれを認可しません。

テンプレートがデプロイするもの

いくつかの azd コマンドで次のものが得られます:

Microsoft Foundry 上のバックエンドエージェント（C#、Microsoft A2A および MCP SDK）
サンプルポートフォリオ API を公開する MCP サーバー
認可サーバーとして Curity Identity Server、認証のために Entra ID と並行して
トークン交換と監査ログを処理する外部および内部 API ゲートウェイ
Azure インフラストラクチャ全体の Bicep: Container Apps、VNet、ACR、Azure AI Foundry、Key Vault、Azure SQL Database、ストレージ

パターン全体は検査可能でカスタマイズ可能です。

借りる価値のある設計原則

Curity を使用しない場合でも、パターンは転用可能です: エージェントは永続的な API アクセスを決して持つべきではありません。すべてのアクションは、その特定の呼び出しに必要な最小スコープを持つ短命のトークンを使用し、特定のエージェント ID に対して発行され、API が認可の決定を行うために必要なクレームを運ぶべきです。

これは創造的なエージェント、ミス、プロンプトインジェクションに対して「エージェントが悪いことをしないようにするだけ」では決して耐えられない方法で耐えます。

まとめ

AI エージェントのセキュリティパターンは、業界全体でまだ整理されています。このテンプレートは私が見た中で最も完全なリファレンス実装の 1 つです — 認証だけでなく、実際の認可フローをカバーしています。

元の投稿: Least privilege AI agents: A new azd template from Curity and Microsoft

Aspire 13.3: Kubernetes サポート、ブラウザログ、Aspireify スキル

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

5週間はリリースとしては短い期間ですが、Aspire 13.3 はそのようには感じません。主要な項目は重要なものです: Helm による Kubernetes および AKS のファーストクラスデプロイ、Aspireify というエージェント支援のオンボーディングスキル、ダッシュボードへのブラウザログキャプチャ直接統合、構造化されたコマンド結果。さらに、45の新機能、134の改善、93のバグ修正も含まれています。

ハイライトを見ていきましょう。

Aspireify: エージェント支援のオンボーディング

Aspire を既存のプロジェクトに追加するのは簡単に聞こえます — AppHost を追加すれば完了。しかし実際には多くの調査が必要です: どのポートが重要か、どの環境変数が実際の依存関係か、どの Docker Compose サービスが Aspire のインテグレーションにマッピングされるべきか。

新しい Aspireify スキル は、コーディングエージェントにまさにそのためのガイド付きワークフローを提供します。aspire init がスケルトン AppHost を作成するとき、Aspireify スキルはエージェントがリポジトリを調査し、どのように動作しているかを理解し、アプリに合わせて AppHost を接続するのを助けます — その逆ではありません。

デフォルトのスタンスは「コードへの変更を最小化する」です。アプリがすでに DATABASE_URL を読み取っている場合、エージェントは設定を書き直すように求めるのではなく、WithEnvironment() でそれをマップします。ポートがハードコードされている場合、スキルはエージェントにそれを保持するタイミングを伝えます。

これは、レビューのための作業を増やすのではなく、実際に時間を節約する AI ツールの一例です。

ファーストクラスの Kubernetes と AKS デプロイ

これはウィッシュリストにしばらくありました。Aspire 13.3 では Helm を使用した Kubernetes と AKS のファーストクラスデプロイサポート が提供されます。Aspire ツールから直接 AKS をデプロイターゲットとして指定できるようになりました。

AKS で本番ワークロードをすでに実行しているチームにとって、これは重要なギャップを埋めます。Aspire のアプリモデルは、手動で Helm チャートを書く必要なく、ローカル開発から Kubernetes へのクリーンなパスを持つようになりました。

ダッシュボードのブラウザログ

これはフロントエンドの問題をデバッグするまでは小さく見える機能の一つです。

新しい WithBrowserLogs() API は、エンドポイント対応のリソースに追跡されたブラウザリソースを添付します。Aspire はプライベート CDP パイプを使用して Chromium を起動し、コンソールログ、ネットワークリクエスト、エラーをリソースのログストリームに直接ストリーミングします:

var frontend = builder.AddViteApp("frontend", "../frontend")
 .WithHttpEndpoint(port: 3000)
 .WithBrowserLogs();

TypeScript AppHost も同様にサポートしています:

const frontend = await builder.addViteApp("frontend", "../frontend")
 .withHttpEndpoint({ port: 3000 })
 .withBrowserLogs();

コンソールエラー、失敗したネットワークリクエスト、クライアントサイドの例外 — すべて、すでにトレースとメトリクスを監視しているのと同じダッシュボードで可視化できます。基本的なことのためにブラウザ DevTools にタブを切り替える必要はもうありません。

構造化されたコマンド結果

リソースコマンドが大幅にアップグレードされました。これまで、コマンドは成功/失敗を返していました。今では構造化された結果を返します: モデル、ダッシュボード UI、CLI、MCP ツールを流れるテキスト、JSON、または Markdown です。

ダッシュボードはこれをヘッダーの新しい通知センターでまとめています。コマンド結果は Markdown レンダリングと「応答を表示」アクションを持つタイムスタンプ付き通知として表示されます。

これにより、リソースコマンドが真に組み合わせ可能になります。インテグレーションは、単にどこかの状態を変更するのではなく、トンネル URL などの意味のある出力を返すコマンドを公開できるようになりました。

まとめ

Aspire 13.3 は Kubernetes サポートだけでもアップデートする価値があります。ブラウザログと構造化されたコマンド結果は、日常の開発ワークフローで素早く積み重なる生活の質向上の改善の一種です。

完全なリリースノート: What’s New in Aspire 13.3

SDD Conference 2026

Mon, 11 May 2026 00:00:00 +0000

SDD 2026 は 2026年5月11日〜15日 に ロンドンの Barbican Centre で開催されます。3日間のメインカンファレンスは火曜日から木曜日で、月曜日と金曜日にはオプションの終日ワークショップがあります。

78セッション と 14ワークショップ を擁し、ヨーロッパで最も充実した開発者カンファレンスの一つです。

トピック

アーキテクチャ的思考
C# 13 における関数型コード
サーバーレスデザイン
セマンティック AI
Azure Kubernetes Services
リーン DevOps 戦略
The Model Context Protocol (MCP)
.NET におけるエージェント AI
モノリスのリファクタリング
LLM でより速くコーディング
ポスト量子世界における暗号技術
ローカルファースト開発

スピーカー

Kevlin Henney、Neal Ford、Sander Hoogendoorn、Andrew Clymer、Jacqui Read、Christian Weyer、Jeff Prosise、Jules May、Oliver Sturm、Raju Gandhi を含むワールドクラスのラインナップ。

チケットと情報

SDD 2025 参加者の98%が全体的な体験を「良い」、「とても良い」、「素晴らしい」と評価しました。

.NETのComposable StackでAI搭載カンファレンスアプリを構築する

Emiliano Montesdeoca — Wed, 06 May 2026 00:00:00 +0000

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

.NETのComposable StackでAI搭載カンファレンスアプリを構築する — Microsoftは、5つの.NET拡張ライブラリを組み合わせることで、ライブカンファレンスセッション向けのBlazor ServerアプリであるConferencePulseを構築しました。MVP Summitで使用されました。

ConferencePulseの機能

ConferencePulseはライブセッション中に動作し、以下を提供します：セッションコンテンツからAIが生成するポール、ライブナレッジベースからRAGパイプラインで引き出す聴衆Q&A、自動生成されたインサイト、複数の同時AIエージェントが生成するセッションサマリー。スタックは.NET 10、Blazor Server、Aspireで、5つのプロジェクトに分割されています：Web、Core、Ingestion、Agents、Mcp、AppHost。

Microsoft.Extensions.AI：すべてのための1つの抽象化

IChatClientは統合抽象化です — 一度セットアップすれば、同じインターフェイスがAzure OpenAI、OpenAI、Anthropic、または他のプロバイダーで動作します。関数呼び出し、OpenTelemetryトレーシング、ロギングミドルウェアを備えた完全設定クライアントを6行で取得できます：

services.AddChatClient(new AzureOpenAIClient(...).GetChatClient("gpt-4o"))
 .UseFunctionInvocation()
 .UseOpenTelemetry()
 .UseLogging();

同じIChatClientは後でデータ取り込みのエンリッチメントステップに再利用されます — そのための別クライアントは不要です。

DataIngestionパイプライン

セッションコンテンツはパイプラインを流れます：MarkdownReader → HeaderChunker（500トークン、50トークンオーバーラップ）→ SummaryEnricher + KeywordEnricher → VectorStoreWriter（Qdrant）。エンリッチャーはインデックス作成前にサマリーを生成してキーワードを抽出するために同じIChatClientを使用します。聴衆の質問、Q&Aペア、ポール結果はセッションが進むにつれてリアルタイムで取り込まれます — ナレッジベースはトーク中に成長します。

VectorData：プロバイダーに依存しない検索

VectorStoreCollection.SearchAsync()は、バッキングストアがQdrantであるかAzure AI Searchであるかに関係なく同じように動作します。ハイブリッド検索（ベクトル + 全文）がサポートされています。聴衆Q&AのRAGパイプラインはこのコレクションをクエリし、チャットクライアントにコンテキストとして渡す関連チャンクを取得します。

MCP：ツールとしてのセッションコンテンツ

セッションコンテンツはMCPを通じて公開されるため、MCPと互換性のあるクライアントからアクセスできます。サーバーとクライアントの両方が実装されています — サーバーはセッションの知識をMCPツールとして公開し、クライアントはエージェントパイプライン内からそれらのツールを呼び出すことを可能にします。

Agent Framework：並列マルチエージェントサマリー

セッションサマリーは3つのエージェントが並行して実行されることで生成されます — PollSummaryAgent、QuestionSummaryAgent、InsightSummaryAgent — その後マージされます。これはMicrosoft Agent Frameworkのグループチャットまたは並列実行パターンを使用します。各エージェントが1つの関心事を担当し、オーケストレーターが出力をマージします。

設計原則

この投稿では覚えておく価値のある点が述べられています：最もシンプルなツールを使用する。シンプルな生成タスクには直接のIChatClient呼び出し。構造化データ抽出にはツール/関数呼び出し。自律的なマルチステップ推論が必要な場合のみフルエージェントを使用。ライブラリのレイヤリングがこれを強制します — フルAgent Frameworkを引き込まずにMicrosoft.Extensions.AIを使用できます。

完全なプロジェクト構造とソースリンクについては、フルポストを参照してください。

Microsoft Agent Framework パート3：ツールからワークフローへ — ビルディングブロックがカチッとはまる

Emiliano Montesdeoca — Tue, 05 May 2026 00:00:00 +0000

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

.NETのBuilding Blocks for AIシリーズを追っているなら、パート1がIChatClient（ユニバーサルモデルインターフェース）を、パート2がMicrosoft.Extensions.VectorData（セマンティック検索とRAG）を提供したことはご存知でしょう。どちらも基礎的で、単体でも有用です。しかし、ここからすべてがつながり始めます。

パート3はMicrosoft Agent Frameworkについてです — 正直に言うと、.NETで実現されるのを待ち望んでいたピースです。1.0は4月にリリースされました。APIは安定しています。本物のエージェントを構築する時が来ました。

エージェントとは何か（チャットボットとの違い）

コードに入る前に、この区別を明確にしておきましょう。チャットボットはインプットを受け取り、モデルを呼び出し、アウトプットを返します。シンプルなループです。

エージェントには自律性があります。タスクについて推論し、どのツールを使うかを決定し、それを呼び出し、結果を評価し、次に何をすべきか決定できます — すべてのシナリオに対してステップバイステップのロジックを書く必要はありません。ツールと指示を与えれば、オーケストレーションを自分で処理します。

こう考えてみてください：IChatClientは会話を持つことのようなものです。エージェントはタスクリストを誰かに委任するようなものです。

10行で書く最初のエージェント

dotnet add package Microsoft.Agents.AI

AIAgent agent = new AzureOpenAIClient(
 new Uri(endpoint),
 new DefaultAzureCredential())
 .GetChatClient(deploymentName)
 .AsAIAgent(
 instructions: "You are good at telling jokes.",
 name: "Joker");

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate."));

.AsAIAgent()拡張メソッドがブリッジです。MEAIの.AsIChatClient()と同じパターン — プロバイダーのSDKを安定した抽象化でラップします。Azure OpenAI、OpenAI、GitHub Models、Microsoft Foundry、またはローカルモデルで動作します。

ストリーミングも機能します：

await foreach (var update in agent.RunStreamingAsync("Tell me a joke about a pirate."))
{
 Console.Write(update);
}

エージェントにツールを与える

ここでエージェントが高度なチャットボットから脱却します。ツールはユーザーの要求に基づいてモデルが呼び出しを決定できる関数です。ルーティングロジックは不要 — モデルが自分で判断します。

[Description("Get the weather for a given location.")]
static string GetWeather(
 [Description("The location to get the weather for.")] string location)
 => $"The weather in {location} is cloudy with a high of 15°C.";

AIAgent agent = chatClient.AsAIAgent(
 instructions: "You are a helpful assistant",
 tools: [AIFunctionFactory.Create(GetWeather)]);

2つのことに注目してください。まず、AIFunctionFactoryはMEAIから来ています — 通常のIChatClientで使うのと同じツールファクトリーです。チャットシナリオ用にすでにツールを定義している場合、ここでも機能します。

次に、Description属性は非常に重要です。これがモデルがツールの機能と使用タイミングを理解する方法です。人間ではなくAIへのドキュメントとして扱ってください。

セッション：本当に記憶する会話

AgentSession session = await agent.CreateSessionAsync();

Console.WriteLine(await agent.RunAsync("Tell me a joke about a pirate.", session));

Console.WriteLine(await agent.RunAsync(
 "Now add some emojis and tell it in the voice of a pirate's parrot.",
 session));

セッションなしでは、各RunAsync呼び出しはステートレスです。セッションありでは、エージェントはどのジョークを指しているかを知っています。AgentSessionはターン間で会話履歴を保持します。

本番ステートレスサービスでは、セッションはクリーンにシリアライズできます：

JsonElement sessionState = await agent.SerializeSessionAsync(session);
// ... どこかに保存する ...
var restoredSession = await agent.DeserializeSessionAsync(sessionState);
Console.WriteLine(await agent.RunAsync("What were we just talking about?", restoredSession));

エージェントがサーバーレスまたは水平スケール環境で動作する場合、これは非常に重要です。

AIContextProvider：セッションをまたいだ永続的メモリ

セッションはセッション内の会話履歴を保持します。しかし、セッション間でユーザーのことを知ることは？AIContextProviderがそれを処理します。

2つのフックがあります：

ProvideAIContextAsync — 各インタラクションの前に実行され、エージェントにコンテキストを注入する
StoreAIContextAsync — 各インタラクションの後に実行され、学習と永続化を可能にする

パターンはエレガントです：複数のプロバイダーを積み重ねることができます — ユーザー設定用、最近のインタラクション用、関連ドキュメントのVectorDataストアを照会するものなど。最後のものは、パート2のRAGパターンそのもので、今やすべてのエージェント呼び出しで自動的に実行されます。

マルチエージェントワークフロー

ここでフレームワークがその名前を証明します。エグゼキューター（エージェント、関数、何でも）がエッジを介して接続するグラフベースのワークフローシステムを含みます。

ネイティブでサポートされているパターン：

シーケンシャル：エージェントAの出力がエージェントBに流れる
コンカレント（ファンアウト/ファンイン）：複数のエージェントに並列ディスパッチ、結果を収集
条件付きルーティング：出力に基づいて異なるエージェントに作業をルーティング
ライター-クリティックループ：一方のエージェントが書き、もう一方が評価し、承認までループ
サブワークフロー：ワークフローを階層的に構成

ライター-クリティックの例：

WorkflowBuilder builder = new(writerAgent);
builder
 .AddEdge(writerAgent, criticAgent)
 .AddEdge(criticAgent, writerAgent, condition: result => !result.IsApproved)
 .WithOutputFrom(criticAgent, condition: result => result.IsApproved);
var workflow = builder.Build();

クリーンで読みやすく、条件ベースのルーティングによりループロジックを自分で書く必要がありません。

ヒューマン・イン・ザ・ループ

すべてが完全に自律的に実行されるべきではありません。センシティブな操作 — データベースへの書き込み、金融トランザクション、通信の送信 — には、エージェントが実行する前に人間の承認が必要です。

フレームワークにはFunctionApprovalRequestContentとFunctionApprovalResponseContentを介したサポートが組み込まれています。エージェントがツール呼び出しを提案し、アプリケーションコードがユーザーに提示し、レスポンスが実行を続けるかどうかを決定します。

これがエンタープライズ環境でエージェントについて考える正しい方法です：完全な自律ではなく、ガードレール付きの自律性。

全体像

少し引いて見ると：

MEAIはどのモデルへの普遍的インターフェースを提供
VectorDataはセマンティック検索を通じて組織の知識へのアクセスをエージェントに提供
Agent Frameworkはすべてをオーケストレート — 内部でIChatClientを使用し、コンテキストプロバイダーと組み合わせ、ワークフローを通じて調整

各ピースは他のものと組み合わせられるように設計されています。Jeremy Likness の元の投稿とAgent Framework GitHubリポジトリで完全なサンプルをご確認ください。

まとめ

Microsoft Agent Framework パート3の投稿は、ビルディングブロックシリーズのループを閉じます。ツールを使い、物事を記憶し、調整する本物のエージェントを構築したい.NET開発者にとって、これが前進への道です。

安定版1.0リリースは、これを本番環境で構築できることを意味します。.NETでのエージェント開発に飛び込むのを待っていたなら、今がその時です。

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ブログの完全な投稿でより詳しい解説をご覧ください。

Azure MCP Server が .mcpb になった — ランタイムなしでインストール

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

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

MCP サーバーのセットアップで面倒だったこと、ご存知ですか？ランタイムが必要でした。npm 版には Node.js、pip/uvx には Python、dotnet 版には .NET SDK。

Azure MCP Server がその問題を解決しました。.mcpb — MCP Bundle — として利用可能になり、セットアップはドラッグ＆ドロップです。

MCP Bundle とは？

VS Code 拡張機能（.vsix）やブラウザ拡張機能（.crx）のようなものですが、MCP サーバー用です。.mcpb ファイルはサーバーバイナリとすべての依存関係を含む自己完結型の ZIP アーカイブです。

インストール方法

1. プラットフォーム用バンドルをダウンロード

GitHub Releases ページで、OS とアーキテクチャに合った .mcpb ファイルをダウンロードします。

2. Claude Desktop にインストール

最も簡単な方法：拡張機能の設定ページ（☰ → ファイル → 設定 → 拡張機能）を開きながら、.mcpb ファイルを Claude Desktop ウィンドウにドラッグ＆ドロップします。サーバーの詳細を確認し、インストールをクリックして確認します。

3. Azure で認証

az login

以上です。Azure MCP Server は既存の Azure 認証情報を使用します。

できること

AI クライアントから直接 100 以上の Azure サービスツールにアクセス：

Cosmos DB、Storage、Key Vault、App Service、Foundry のクエリと管理
任意のタスクの az CLI コマンド生成
Bicep・Terraform テンプレートの作成

はじめるには

ダウンロード: GitHub Releases
リポジトリ: aka.ms/azmcp
ドキュメント: aka.ms/azmcp/docs

完全な記事もご確認ください。

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
データ主権が必要？ → データベースバックドプロバイダーのクライアント管理型
シンプルなチャットボット？ → サービス管理型の線形で十分

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

Foundry Toolboxes: AIエージェントツールのための統一エンドポイント

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

この投稿は自動翻訳されました。元のバージョンはこちらをクリックしてください。

退屈に聞こえるが実際に直面すると深刻な問題がある：組織が複数のAIエージェントを構築し、それぞれがツールを必要とし、各チームがゼロから設定している。同じWeb検索統合、同じAzure AI Searchの設定、同じGitHub MCPサーバーの接続 — でも別のリポジトリに、別のチームが、別の認証情報で、ガバナンスの共有なしに。

Microsoft FoundryがPublic PreviewでToolboxesを公開した。これはその問題への直接的な答えだ。

Toolboxとは

ToolboxはFoundryで一度定義し、単一のMCP互換エンドポイントを通じて公開する、名前付きの再利用可能なツールバンドルだ。MCPを話す任意のエージェントランタイムが消費できる — Foundry Agentsへのロックインはない。

提案はシンプルだ：build once, consume anywhere。ツールを定義し、認証を一元設定（OAuthパススルー、Entraマネージドアイデンティティ）し、エンドポイントを公開する。そのツールが必要な各エージェントはエンドポイントに接続して全てを取得する。

4つの柱（今日は2つが利用可能）

柱	ステータス	何をするか
Discover	近日公開	手動検索なしで承認済みツールを発見
Build	利用可能	ツールを再利用可能なバンドルにまとめる
Consume	利用可能	単一MCPエンドポイントが全ツールを公開
Govern	近日公開	全ツール呼び出しの一元認証+可観測性

実践的な例

from azure.identity import DefaultAzureCredential
from azure.ai.projects import AIProjectClient
import os

client = AIProjectClient(
 endpoint=os.environ["FOUNDRY_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

toolbox_version = client.beta.toolboxes.create_toolbox_version(
 toolbox_name="customer-feedback-triaging-toolbox",
 description="ドキュメントを検索し、GitHubのissueに対応する",
 tools=[
 {"type": "web_search", "description": "公開ドキュメントを検索"},
 {"type": "azure_ai_search", "index_name": "internal-docs"},
 {"type": "mcp_server", "server_url": "https://your-github-mcp-server.com"}
 ]
)

公開後、Foundryは統一エンドポイントを提供する。1回の接続で全ツールが使える。

Foundry Agentsへのロックインはない

ToolboxはFoundryで作成・管理されるが、消費面はオープンなMCPプロトコルだ。Microsoft Agent FrameworkやLangGraphのカスタムエージェント、GitHub Copilotやその他のMCP対応IDE、あらゆるMCPランタイムから使用できる。

今なぜ重要か

マルチエージェントの波が本番環境に到達している。新しいエージェントが増えるたびに、重複した設定、古い認証情報、一貫性のない動作の新たな表面が生まれる。Build + Consumeの基盤は集中化を始めるには十分だ。Governの柱が来た時、エージェント全体に完全に可観測で一元管理されたツール層が得られる。

まとめ

まだ早い段階だ — パブリックプレビュー、Python SDK優先。しかし、モデルは確かで、MCPネイティブな設計は既に構築しているツールで機能することを意味する。公式発表で詳細を確認しよう。

Windows App Dev CLI v0.3: ターミナルからF5デバッグとエージェント向けUIオートメーション

Emiliano Montesdeoca — Thu, 23 Apr 2026 00:00:00 +0000

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

Visual StudioのF5体験は素晴らしいです。しかし、パッケージ化されたWindowsアプリを起動してデバッグするためだけにVSを開くのは、CIパイプライン、自動化ワークフロー、またはAIエージェントがテストを実行しているときには過剰です。

Windows App Development CLI v0.3がリリースされ、2つの主要機能でこれに直接対応します：winapp runとwinapp uiです。

winapp run: どこからでもF5

winapp runはアンパッケージのアプリフォルダーとマニフェストを受け取り、VSがデバッグ起動時に行うすべてを実行します：ルーズパッケージを登録し、アプリを起動し、再デプロイ間でLocalStateを保持します。

# アプリをビルドし、パッケージアプリとして実行
winapp run ./bin/Debug

WinUI、WPF、WinForms、コンソール、Avaloniaなどで動作します。各モードは開発者と自動化ワークフローの両方を想定しています：

--detach: 起動後すぐにターミナルに制御を返します。CI/自動化に最適です。
--unregister-on-exit: アプリ終了時に登録済みパッケージを削除します。
--debug-output: OutputDebugStringメッセージと例外をリアルタイムでキャプチャします。

新しいNuGetパッケージ: パッケージアプリ向けdotnet run

.NET開発者向けに新しいNuGetパッケージが登場しました：Microsoft.Windows.SDK.BuildTools.WinApp。インストール後は、dotnet runがインナーループ全体を処理します：ビルド、ルーズレイアウトパッケージの準備、Windowsへの登録、起動 — すべて1ステップで。

winapp init
# または
dotnet add package Microsoft.Windows.SDK.BuildTools.WinApp

winapp ui: コマンドラインからUIオートメーション

エージェント型シナリオを切り開くのがこの機能です。winapp uiはターミナルから、実行中のあらゆるWindowsアプリ（WPF、WinForms、Win32、Electron、WinUI3）への完全なUIオートメーションアクセスを提供します。

できること：

すべてのトップレベルウィンドウを一覧表示
ウィンドウの完全なUIオートメーションツリーをナビゲート
名前、タイプ、オートメーションIDで要素を検索
クリック、呼び出し、値の設定
スクリーンショットの取得
要素の表示を待機 — テスト同期に最適

winapp uiとwinapp runを組み合わせると、ターミナルから完全なビルド→起動→検証ワークフローが実現します。エージェントがアプリを実行し、UIの状態を検査し、プログラムで操作して結果を検証できます。

その他の新機能

winapp unregister: テスト終了後にサイドロードされたパッケージを削除します。
winapp manifest add-alias: ターミナルからアプリ名で起動できるエイリアスを追加します。
タブ補完: 1つのコマンドでPowerShell補完を設定します。

インストール方法

winget install Microsoft.WinAppCli
# または
npm install -g @microsoft/winappcli

CLIはパブリックプレビュー中です。完全なドキュメントはGitHubリポジトリを、すべての詳細は元のアナウンスをご覧ください。

VS Code 1.117：エージェントが専用のGitブランチを持つようになった、これは最高だ

Emiliano Montesdeoca — Sun, 19 Apr 2026 00:00:00 +0000

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

「AIアシスタント」と「AIチームメイト」の境界線はどんどん薄くなっている。VS Code 1.117がリリースされ、完全なリリースノートは盛りだくさんだが、ストーリーは明確だ：エージェントが開発ワークフローのファーストクラスの市民になりつつある。

本当に重要なことはこれだ。

Autopilotモードがついに設定を記憶するように

以前は、新しいセッションを開始するたびにAutopilotを再度有効にする必要があった。面倒だった。今では権限モードがセッション間で保持され、デフォルトも設定できる。

Agent Hostは3つのセッション設定をサポートしている：

Default — ツールは実行前に確認を求める
Bypass — すべてを自動承認する
Autopilot — 完全自律型、自分の質問に答えて作業を続ける

.NETプロジェクトをマイグレーション、Docker、CIと一緒にスキャフォールディングするなら、Autopilotに一度設定すればあとは忘れていい。その設定はそのまま維持される。

エージェントセッションのworktreeとgit分離

これが本命だ。エージェントセッションが完全なworktreeとgit分離をサポートするようになった。つまり、エージェントがタスクに取り組むとき、専用のブランチと作業ディレクトリが割り当てられる。メインブランチは一切影響を受けない。

さらに良いことに、Copilot CLIがこれらのworktreeセッションに意味のあるブランチ名を生成してくれる。もうagent-session-abc123は終わりだ。エージェントが何をしているかを実際に説明する名前が付けられる。

複数のフィーチャーブランチを管理したり、長いスキャフォールディングタスクの実行中にバグを修正している.NET開発者にとって、これはゲームチェンジャーだ。あるworktreeでエージェントにAPIコントローラーを構築させながら、別のworktreeでサービスレイヤーの問題をデバッグできる。コンフリクトなし。スタッシュなし。混乱なし。

サブエージェントとエージェントチーム

Agent Host Protocolがサブエージェントをサポートするようになった。エージェントがタスクの一部を処理するために他のエージェントを起動できる。委任と考えればいい — メインエージェントが調整し、専門エージェントが各部分を担当する。

まだ初期段階だが、.NETワークフローへの可能性は明らかだ。あるエージェントがEF Coreのマイグレーションを処理し、別のエージェントが統合テストをセットアップする姿を想像してみてほしい。まだ完全には到達していないが、プロトコルサポートが今入ったということは、ツールもすぐに続くということだ。

エージェントが入力を送信するとターミナル出力が自動的に含まれるように

小さいが意味がある。エージェントがターミナルに入力を送信すると、ターミナル出力が自動的にコンテキストに含まれるようになった。以前は、エージェントが何が起きたかを読むために余分なターンが必要だった。

エージェントがdotnet buildを実行し、失敗し、エラーを確認するためだけにもう一回往復するのを見たことがあるなら — そのフリクションはなくなった。出力を即座に確認して反応する。

macOSのAgentsアプリが自動更新に

macOSのスタンドアロンAgentsアプリが自動更新されるようになった。新しいバージョンを手動でダウンロードする必要はもうない。常に最新の状態が保たれる。

知っておく価値のある小さなこと

package.jsonのホバーがインストール済みバージョンと最新の利用可能なバージョンの両方を表示するようになった。.NETプロジェクトと一緒にnpmツールを管理している場合に便利。
JSDocコメント内の画像がホバーや補完で正しくレンダリングされるようになった。
Copilot CLIセッションがVS Codeで作成されたか外部で作成されたかを表示するようになった — ターミナル間を行き来するときに便利。
Copilot CLI、Claude Code、Gemini CLIがシェルタイプとして認識されるようになった。エディタが何を実行しているか把握している。

まとめ

VS Code 1.117は派手な機能のダンプではない。インフラだ。worktree分離、永続的な権限、サブエージェントプロトコル — これらは、エージェントがコードを踏むことなく実際の並列タスクを処理するワークフローのための基盤だ。

.NETで開発していてエージェント型ワークフローにまだ踏み込んでいないなら、正直、今が始めるときだ。

AzureでのAI実験がお金を燃やしている — その解決方法はこちら

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

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

今AzureでAI搭載アプリを構築しているなら、おそらく気づいていることがあるでしょう：クラウドの請求書が以前と違って見えるということです。単に高くなっただけではなく、不思議な感じです。スパイクがあり、予測が難しい。

Microsoftが今でも重要なクラウドコスト最適化の原則に関する素晴らしい記事を公開しました。正直なところ、これ以上ないタイミングです。なぜなら、AIワークロードがコストに関するゲームのルールを変えてしまったからです。

AIワークロードが違う理由

ポイントはこうです。従来の.NETワークロードは比較的予測可能です。App Serviceのティアを把握し、SQLのDTUを把握し、月々の支出をかなり正確に見積もることができます。AIワークロードは？そうはいきません。

どのモデルが合うか、複数のモデルをテストしています。ファインチューニングのためにGPUバックのインフラを立ち上げています。Azure OpenAIへのAPI呼び出しでは、プロンプトの長さやユーザーの行動によってトークン消費量が大きく変動します。すべての実験に実際のコストがかかり、正しいアプローチにたどり着くまでに何十回も実行することになるかもしれません。

この予測不可能性こそが、コスト最適化を重要にする理由です — 後から考えるのではなく、初日から。

管理と最適化 — 違いを知る

記事の中で開発者が見落としがちだと思う区別があります：コスト管理とコスト最適化には違いがあるということです。

管理はトラッキングとレポーティングです。Azure Cost Managementで予算を設定し、アラートを受け取り、ダッシュボードを見ます。これは基本中の基本です。

最適化は実際に意思決定を行うところです。本当にそのS3ティアが必要ですか、それともS1で負荷に対応できますか？常時稼働のコンピューティングインスタンスが週末に何もしていませんか？トレーニングジョブにスポットインスタンスを使えませんか？

.NET開発者として、私たちはコードに集中し、インフラの決定を「運用チーム」に任せがちです。しかし、Azureにデプロイしているなら、それらの決定はあなたの決定でもあるのです。

実際に効果があること

記事と自分自身の経験に基づいて、これが実際に効果を生むことです：

何にいくら使っているか把握する。 リソースにタグを付けてください。本当に。どのプロジェクトや実験が予算を食っているかわからなければ、何も最適化できません。適切なタグ付けを行ったAzure Cost Managementが最強の味方です。

実験する前にガードレールを設置する。 Azure Policyを使って、dev/test環境で高価なSKUを制限しましょう。Azure OpenAIデプロイメントに支出上限を設定しましょう。誰かが週末にGPUクラスターを動かしっぱなしにしていたことに請求書が届いてから気づく、なんてことは避けましょう。

継続的にライトサイジングする。 プロトタイピング中に選んだVM？本番環境にはおそらく合っていません。Azure Advisorが推奨事項を提示してくれます — 実際に確認してください。年に一度ではなく、月に一度レビューしましょう。

ライフサイクルを考える。 開発リソースはシャットダウンすべきです。テスト環境は24時間365日稼働する必要はありません。自動シャットダウンポリシーを使いましょう。AIワークロードについては特に、コンピューティングを常時稼働させる代わりに実行ごとに課金されるサーバーレスオプションを検討しましょう。

コストだけでなく価値を測定する。 これは忘れがちです。コストは高いけれど大幅に優れた結果を出すモデルが正しい選択かもしれません。目標は最小限の支出ではなく、賢い支出です。

まとめ

クラウドコスト最適化は一度きりのクリーンアップではありません。習慣です。AIワークロードによって支出がかつてないほど予測しにくくなっている今、この習慣を早くから身につけることで、後の痛い驚きを避けることができます。

Azureで構築している.NET開発者なら、クラウドの請求書をコードと同じように扱い始めましょう — 定期的にレビューし、散らかってきたらリファクタリングし、コストを理解せずにデプロイしないようにしましょう。

FoundryのRFTがより安く、よりスマートに — 変更点まとめ

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

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

ファインチューニングされたモデルに依存する.NETアプリを開発しているなら、今月のFoundryアップデートは注目に値します。Reinforcement Fine-Tuningがより利用しやすく、大幅に安くなりました。

詳細は公式発表にありますが、ここでは実用的なポイントをまとめます。

o4-miniのグローバルトレーニング

o4-miniは推論重視のワークロードやエージェント型ワークロードに最適なモデルです。大きなニュース：13以上のAzureリージョンからファインチューニングジョブを起動でき、Standardトレーニングと比較してトークンあたりのトレーニングコストが低くなりました。同じインフラ、同じ品質、より広い対応範囲。

チームが複数の地域に分散している場合、これは重要です。トレーニングのために少数のリージョンに縛られることはもうありません。

グローバルトレーニングジョブを開始するREST APIコールはこちらです：

curl -X POST "https://<your-resource>.openai.azure.com/openai/fine_tuning/jobs?api-version=2025-04-01-preview" \
 -H "Content-Type: application/json" \
 -H "api-key: $AZURE_OPENAI_API_KEY" \
 -d '{
 "model": "o4-mini",
 "training_file": "<your-training-file-id>",
 "method": {
 "type": "reinforcement",
 "reinforcement": {
 "grader": {
 "type": "string_check",
 "name": "answer-check",
 "input": "{{sample.output_text}}",
 "reference": "{{item.reference_answer}}",
 "operation": "eq"
 }
 }
 },
 "hyperparameters": {
 "n_epochs": 2,
 "compute_multiplier": 1.0
 },
 "trainingType": "globalstandard"
 }'

このtrainingType: globalstandardフラグが重要な違いです。

新しいモデルグレーダー：GPT-4.1ファミリー

グレーダーはモデルが最適化する報酬シグナルを定義します。これまで、モデルベースのグレーダーは限られたモデルセットに制約されていました。今回、GPT-4.1、GPT-4.1-mini、GPT-4.1-nanoの3つの新しいオプションが追加されました。

決定的グレーダーの代わりにモデルグレーダーを使うべきなのはどんな時でしょうか？タスクの出力がオープンエンドの場合、複数の次元で部分的なスコアリングが必要な場合、またはツール呼び出しの正確さがセマンティックコンテキストに依存するエージェント型ワークフローを構築している場合です。

ポイントは、ティアリング戦略が実用的であること：

GPT-4.1-nano 初期のイテレーション用。低コスト、高速なフィードバックループ。
GPT-4.1-mini 評価ルーブリックが安定し、より高い精度が必要になったら。
GPT-4.1 本番環境の評価や、すべてのスコアリング判断が重要な複雑なルーブリック用。

単一のRFTジョブでグレーダータイプを混在させることもできます。「正解」の次元にはstring-matchを使い、推論品質の評価にはモデルグレーダーを使う。この柔軟性が、実際のワークロードで本当に役立つ理由です。

RFTデータフォーマットの落とし穴

ここでつまずく人が多いです。RFTのデータフォーマットはSFTとは異なります。各行の最後のメッセージはUserまたはDeveloperロールでなければなりません — Assistantではありません。期待される回答は、グレーダーが直接参照するreference_answerのようなトップレベルのキーに入れます。

これまでSupervised Fine-Tuningを行っていてRFTに切り替えたい場合は、トレーニングデータを再構築する必要があります。このステップを飛ばすと、ジョブがサイレントに失敗します。

.NET開発者にとってなぜ重要か

Azure OpenAI SDKを通じて.NETアプリからファインチューニングされたモデルを呼び出している場合、トレーニングコストの低下はより積極的にイテレーションできることを意味します。モデルグレーダーのオプションにより、完全一致シナリオだけでなく、ニュアンスのあるタスクに対してファインチューニングが可能になります。そしてGitHubのベストプラクティスガイドは、実際のデバッグ時間を節約してくれます。

小さく始めましょう。10から100サンプル。シンプルなグレーダー。ループを検証。そしてスケール。

Global Azure Spain 2026

Sat, 18 Apr 2026 00:00:00 +0000

Global Azure Spain 2026 は 2026年4月18日 にマドリード、Alcobendas の Kinépolis Diversia で開催されます。スペイン最大のコミュニティ主導のAzureイベントで、AIエージェント、Azureネットワーク、Cosmos DB、Fabric、IoT、セキュリティなどをカバーする3つの並行トラックに38名のスピーカーが登壇します。

イベントは 08:30 から 18:30 まで開催され、キーノート、コーヒーブレイク、ランチ、クロージングQ&Aセッションを含みます。

アジェンダのハイライト

Domando Agentes de IA: Azure AI FoundryとAzure API Managementによるガバナンス、ツール、API
Construyendo agentes con LibreChat en Azure
How Can I Steal Your Data with Azure Private Endpoints
Stop Building APIs. Forge Agents with Azure
Agentic DevOps Meets IoT: Real-Time Systems with Fabric and GitHub Copilot
El regreso de los tamagotchis!: マルチエージェントシステムの実践
Foundry Control Plane como plataforma de Agentes global
Rompiendo el perímetro: Zero Trust aplicado en Azure

チケット

登録は象徴的な寄付です — チケット代金は全額 Plan International に寄付され、世界中の子どもの権利と平等を支援します。定員に限りがありますので、お早めにお申し込みください。

Azure Tour 2026

マドリード以外にも、Global Azure Tour 2026 は サラゴサ、テネリフェ、セビリア でも開催されます。

Docker Sandboxで、Copilotエージェントがマシンをリスクにさらさずにコードをリファクタリングできるようになった

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

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

Copilotのエージェントモードを小さな編集以上のことに使ったことがあるなら、あの煩わしさは知っているはずです。ファイルへの書き込みのたびに、ターミナルコマンドのたびに、また許可プロンプト。これを50プロジェクトで想像してみてください。楽しくないですよね。

AzureチームがGitHub CopilotエージェントのためのDocker Sandboxに関する記事を公開しました。正直に言って、これはエージェンティックツーリングで見た中で最も実用的な改善の一つです。マイクロVMを使ってCopilotに完全に隔離された環境を提供し、パッケージのインストール、ビルドの実行、テストの実行まで、ホストシステムに一切触れずに自由に作業できます。

Docker Sandboxが実際に提供するもの

コアのアイデアはシンプルです：完全なLinux環境を持つ軽量なマイクロVMを起動し、ワークスペースをその中に同期させ、Copilotエージェントを内部で自由に動かす。完了したら変更が同期されて戻ってくる。

単なる「コンテナ内で実行する」以上のものにしているポイントはこちらです：

双方向ワークスペース同期で絶対パスが保持されます。プロジェクト構造はサンドボックス内でも同一に見えます。パス関連のビルドエラーはありません。
プライベートDockerデーモンがマイクロVM内で稼働。エージェントはホストのDockerソケットをマウントすることなくコンテナのビルドと実行が可能です。セキュリティ面で大きな進歩です。
HTTP/HTTPSフィルタリングプロキシがエージェントのネットワークアクセスを制御。どのレジストリとエンドポイントを許可するかはあなたが決められます。サンドボックス内の悪意あるnpm installによるサプライチェーン攻撃？ブロックされます。
YOLOモード — はい、本当にそう呼ばれています。エージェントは許可プロンプトなしで実行されます。なぜなら、文字通りホストを壊すことができないからです。すべての破壊的アクションが封じ込められています。

.NET開発者が注目すべき理由

今まさに多くのチームが直面しているモダナイゼーション作業を考えてみてください。30プロジェクトを含む.NET Frameworkソリューションがあり、.NET 9に移行する必要がある。数百のファイル変更が必要です — プロジェクトファイル、名前空間の更新、APIの置き換え、NuGetの移行。

Docker Sandboxを使えば、CopilotエージェントをプロジェクトにポイントしてマイクロVM内で自由にリファクタリングさせ、dotnet buildとdotnet testで検証し、実際に動作する変更だけを受け入れることができます。実験中にローカル開発環境を誤って壊してしまうリスクはありません。

記事では並列エージェントのフリートの運用も説明されています — それぞれが独自のサンドボックスで、異なるプロジェクトに同時に取り組みます。大規模な.NETソリューションやマイクロサービスアーキテクチャにとって、これは膨大な時間の節約になります。サービスごとに1エージェント、すべて隔離して実行、すべて独立して検証。

セキュリティの観点が重要

多くの人が見落としているポイントがあります：AIエージェントに任意のコマンドの実行を許可するということは、マシン全体を信頼して預けるということです。Docker Sandboxはそのモデルを逆転させます。エージェントは使い捨て環境内で完全な自律性を得ます。ネットワークプロキシが承認されたソースからのみダウンロードできることを保証します。ホストのファイルシステム、Dockerデーモン、認証情報は手つかずのままです。

コンプライアンス要件を持つチーム — そしてそれはほとんどのエンタープライズ.NET企業に当てはまります — にとって、これは「エージェンティックAIは使えない」と「安全に導入できる」の違いです。

まとめ

Docker Sandboxはエージェンティックコーディングの根本的なジレンマを解決します：エージェントは有用であるために自由が必要ですが、ホストマシンでの自由は危険です。マイクロVMは両方を実現します。大規模な.NETリファクタリングやモダナイゼーションを計画しているなら、今すぐセットアップする価値があります。Copilotのコードインテリジェンスとセキュアな実行環境の組み合わせは、まさにプロダクションチームが待ち望んでいたものです。

AzureでAIエージェントをどこにホストすべき？実践的な判断ガイド

Emiliano Montesdeoca — Wed, 15 Apr 2026 00:00:00 +0000

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

今.NETでAIエージェントを構築しているなら、おそらく気づいていることがあるでしょう：Azureでホストする方法がたくさんあるということです。Container Apps、AKS、Functions、App Service、Foundry Agents、Foundry Hosted Agents — どれも合理的に聞こえますが、実際に選ぶ段階になると困ります。MicrosoftがAzureでのAIエージェントホスティングに関する包括的なガイドを公開しました。これを.NET開発者の実践的な視点から整理します。

6つのオプション早見表

オプション	最適な用途	管理するもの
Container Apps	K8sの複雑さなしにコンテナを完全制御	オブザーバビリティ、状態、ライフサイクル
AKS	エンタープライズコンプライアンス、マルチクラスター、カスタムネットワーキング	すべて（それがポイント）
Azure Functions	イベント駆動の短時間エージェントタスク	ほぼなし — 真のサーバーレス
App Service	シンプルなHTTPエージェント、予測可能なトラフィック	デプロイ、スケーリング設定
Foundry Agents	ポータル/SDKによるコード不要エージェント	ほぼなし
Foundry Hosted Agents	マネージドインフラでカスタムフレームワークエージェント	エージェントコードのみ

最初の4つは汎用コンピュートです — エージェントを動かすことはできますが、そのために設計されたものではありません。最後の2つはエージェントネイティブで、会話、ツール呼び出し、エージェントのライフサイクルをファーストクラスの概念として理解しています。

Foundry Hosted Agents — .NETエージェント開発者にとってのスイートスポット

注目すべきはこれです。Foundry Hosted Agentsはちょうど中間に位置しています：自分のコード（Semantic Kernel、Agent Framework、LangGraph — 何でも）を実行する柔軟性がありながら、プラットフォームがインフラ、オブザーバビリティ、会話管理を処理します。

キーピースはHosting Adapterです — エージェントフレームワークをFoundryプラットフォームに接続する薄い抽象化レイヤーです。Microsoft Agent Frameworkの場合：

from azure.ai.agentserver.agentframework import from_agent_framework

agent = ChatAgent(
 chat_client=AzureAIAgentClient(...),
 instructions="You are a helpful assistant.",
 tools=[get_local_time],
)

if __name__ == "__main__":
 from_agent_framework(agent).run()

これがホスティングの全体像です。アダプターがプロトコル変換、server-sent eventsによるストリーミング、会話履歴、OpenTelemetryトレーシングを自動的に処理します。カスタムミドルウェアも手動の配管作業も不要です。

デプロイは本当にシンプル

以前Container Appsにエージェントをデプロイしたことがありますが、状態管理やオブザーバビリティのためのグルーコードをたくさん書くことになります。Hosted Agentsとazdなら：

# AIエージェント拡張機能をインストール
azd ext install azure.ai.agents

# テンプレートから初期化
azd ai agent init

# ビルド、プッシュ、デプロイ — 完了
azd up

この1つのazd upがコンテナをビルドし、ACRにプッシュし、Foundryプロジェクトをプロビジョニングし、モデルエンドポイントをデプロイし、エージェントを起動します。5つのステップが1つのコマンドに凝縮されています。

組み込みの会話管理

本番で最も時間を節約するのはここです。独自の会話ステートストアを構築する代わりに、Hosted Agentsがネイティブに処理します：

# 永続的な会話を作成
conversation = openai_client.conversations.create()

# 最初のターン
response1 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Remember: my favorite number is 42.",
)

# 2回目のターン — コンテキストが保持される
response2 = openai_client.responses.create(
 conversation=conversation.id,
 extra_body={"agent_reference": {"name": "MyAgent", "type": "agent_reference"}},
 input="Multiply my favorite number by 10.",
)

Redisなし。Cosmos DBセッションストアなし。メッセージシリアライゼーション用のカスタムミドルウェアなし。プラットフォームがすべて処理します。

私の判断フレームワーク

6つすべてのオプションを検討した結果、私のクイックメンタルモデルはこうです：

インフラゼロが必要？ → Foundry Agents（ポータル/SDK、コンテナなし）
カスタムエージェントコードがあるがマネージドホスティングが欲しい？ → Foundry Hosted Agents
イベント駆動の短期エージェントタスクが必要？ → Azure Functions
K8sなしで最大限のコンテナ制御が必要？ → Container Apps
厳格なコンプライアンスとマルチクラスターが必要？ → AKS
予測可能なトラフィックのシンプルなHTTPエージェント？ → App Service

Semantic KernelやMicrosoft Agent Frameworkで構築しているほとんどの.NET開発者にとって、Hosted Agentsが適切なスタート地点でしょう。scale-to-zero、組み込みOpenTelemetry、会話管理、フレームワークの柔軟性が得られます — Kubernetesの管理やオブザーバビリティスタックの構築なしに。

まとめ

AzureのエージェントホスティングランドスケープはFastに成熟しています。今日新しいAIエージェントプロジェクトを始めるなら、習慣でContainer AppsやAKSに手を伸ばす前に、Foundry Hosted Agentsを真剣に検討することをお勧めします。マネージドインフラは実際の時間を節約し、hosting adapterパターンでフレームワークの選択を維持できます。

Microsoftの完全ガイドとFoundry Samplesリポジトリで動作するサンプルを確認してください。

.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サンプルをチェックして始めましょう。

Azure MCP Server 2.0 がリリース — セルフホスト型エージェンティッククラウドオートメーションがここに

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

この記事は自動翻訳されています。オリジナル版はこちらをご覧ください。

最近 MCP と Azure で何かを構築している人なら、ローカル環境での体験がうまく機能していることはご存じでしょう。MCP サーバーを接続して、AI エージェントが Azure リソースと通信できるようにして、先へ進む。しかし、その設定をチーム全体で共有する必要が出た瞬間？そこが複雑になっていました。

もうそんなことはありません。Azure MCP Server が 2.0 安定版をリリースし、見出し機能はまさにエンタープライズチームが要望していたものです：セルフホスト型リモート MCP サーバーサポート。

Azure MCP Server とは？

簡単なおさらいです。Azure MCP Server は Model Context Protocol 仕様を実装し、Azure 機能を構造化された検出可能なツールとして公開します。AI エージェントがこれらを呼び出せます。これをエージェントと Azure 間の標準化された橋と考えてください — プロビジョニング、デプロイメント、監視、診断、すべて 1 つの一貫したインターフェース経由で。

数字を見ればわかります：57 の Azure サービス全体で 276 の MCP ツール。これは本格的なカバレッジです。

大きな変化：セルフホスト型リモート展開

ここが重要な点です。ローカルでマシン上で MCP を実行することは開発と実験には問題ありませんが、実際のチームシナリオでは以下が必要です：

開発者と内部エージェントシステム向けの共有アクセス
集中管理構成（テナントコンテキスト、サブスクリプションデフォルト、テレメトリ）
エンタープライズネットワークとポリシー境界
CI/CD パイプラインへの統合

Azure MCP Server 2.0 はこれらすべてに対応しています。HTTP ベースのトランスポート、適切な認証、一貫した統治を備えた集中管理内部サービスとしてデプロイできます。

認証には 2 つの確実なオプションがあります：

マネージド ID — Microsoft Foundry と並行して実行している場合
On-Behalf-Of（OBO）フロー — サインインしたユーザーのコンテキストを使用して Azure API を呼び出す OpenID Connect 委譲

この OBO フローは .NET 開発者にとって特に興味深いものです。これは、エージェンティックワークフローが過度な特権を持つサービスアカウントではなく、ユーザーの実際のアクセス許可で動作できることを意味します。最小権限の原則が組み込まれています。

セキュリティの強化

これは単なる機能リリースではなく、セキュリティリリースでもあります。2.0 リリースは以下を追加します：

より強いエンドポイント検証
クエリ指向ツールのインジェクションパターンに対する保護
開発環境用のより厳密な分離制御

MCP を共有サービスとして公開する場合、これらのセーフガードは重要です。本当に重要です。

どこで使用できますか？

クライアント互換性の状況は幅広いです。Azure MCP Server 2.0 は以下で動作します：

IDE：VS Code、Visual Studio、IntelliJ、Eclipse、Cursor
CLI エージェント：GitHub Copilot CLI、Claude Code
スタンドアロン：シンプルなセットアップ用のローカルサーバー
セルフホスト型リモート：2.0 の新しいスター

さらに、Azure US Government と 21Vianet が運用する Azure のソブリンクラウドサポートもあります。これは規制対象のデプロイメントに重要です。

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

.NET でエージェンティックアプリケーションを構築している場合 — Semantic Kernel、Microsoft Agent Framework、または独自のオーケストレーションのいずれであっても — Azure MCP Server 2.0 は、エージェントが Azure インフラストラクチャと対話するための本番環境対応の方法を提供します。カスタム REST ラッパーは不要です。サービス固有の統合パターンは不要です。MCP があるだけです。

数日前にドロップされた MCP Apps 向けの Fluent API と組み合わせると、.NET MCP エコシステムは急速に成熟しています。

はじめに

パスを選択してください：

GitHub リポジトリ — ソースコード、ドキュメント、すべて
Docker イメージ — コンテナ化されたデプロイメント
VS Code 拡張機能 — IDE 統合
セルフホスティングガイド — 2.0 の旗艦機能

まとめ

Azure MCP Server 2.0 は、デモでは派手に見えないけれど、実際には万能を変えるようなインフラストラクチャアップグレードです。適切な認証、セキュリティ強化、ソブリンクラウドサポートを備えたセルフホスト型リモート MCP は、Azure でエージェンティックワークフローを構築している実際のチームに MCP が対応していることを示しています。「エンタープライズ対応」シグナルを待っていたなら — これです。

.NET Aspire 13.2はあなたのAIエージェントの親友になりたがっている

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

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

AIコーディングエージェントがしっかりしたコードを書いて興奮した後、実際にそれを実行しようとした途端に全てが崩壊する瞬間、知っていますか？ポート競合、ゴーストプロセス、間違った環境変数 — 突然エージェントが機能を構築する代わりに起動トラブルシューティングにトークンを消費し始めます。

Aspireチームがまさにこの問題について非常によく考えられた記事を公開しました。彼らの答えは説得力があります：Aspire 13.2は人間だけでなく、AIエージェントのためにも設計されています。

問題は現実のもの

AIエージェントはコードを書くのに驚異的です。しかし、動作するフルスタックアプリを出荷するには、ファイルを生成する以上のことが必要です。正しい順序でサービスを起動し、ポートを管理し、環境変数を設定し、データベースを接続し、何かが壊れた時にフィードバックを得る必要があります。現在、ほとんどのエージェントはこれらすべてを試行錯誤で処理しています — コマンドを実行し、エラー出力を読み、再試行します。

Markdownの指示、カスタムスキル、プロンプトを重ねてガイドしようとしますが、それらは予測不可能で、コンパイルできず、パースするだけでトークンがかかります。Aspireチームは本質的な洞察を突きました：エージェントにはコンパイラと構造化されたAPIが必要であり、もっとMarkdownではありません。

エージェントインフラとしてのAspire

Aspire 13.2がエージェンティック開発にもたらすもの：

スタック全体を型付きコードで。 AppHostがアプリの完全なトポロジー — API、フロントエンド、データベース、キャッシュ — をコンパイル可能なTypeScriptまたはC#で定義します：

import { createBuilder } from './.modules/aspire.js';

const builder = await createBuilder();

const postgres = await builder.addPostgres("pg").addDatabase("catalog");
const cache = await builder.addRedis("cache");

const api = await builder
 .addNodeApp("api", "./api", "src/index.ts")
 .withHttpEndpoint({ env: "PORT" })
 .withReference(postgres)
 .withReference(cache);

await builder
 .addViteApp("frontend", "./frontend")
 .withReference(api)
 .waitFor(api);

await builder.build().run();

エージェントはこれを読んでアプリのトポロジーを理解し、リソースを追加し、接続を配線し、検証のためにビルドできます。コンパイラが何か間違っていればすぐに教えてくれます。推測不要、設定ファイルでの試行錯誤不要です。

すべてを支配する一つのコマンド。 エージェントがdocker compose up、npm run dev、データベース起動スクリプトをジャグリングする代わりに、すべてがaspire startだけ。すべてのリソースが正しい順序で、正しいポートで、正しい設定で起動します。長時間実行プロセスもエージェントをハングさせません — Aspireが管理します。

並列エージェント用の分離モード。 --isolatedを使えば、各Aspire実行が独自のランダムポートと分離されたユーザーシークレットを取得します。複数のエージェントがgit worktreeで作業している？衝突しません。これはVS Codeのバックグラウンドエージェントのような並列環境を立ち上げるツールにとって非常に重要です。

テレメトリによるエージェントの目。 ここが本当に強力になるところです。Aspire CLIは開発中に完全なOpenTelemetryデータを公開します — トレース、メトリクス、構造化ログ。エージェントはコンソール出力を読んで最善を祈るだけではありません。サービス間で失敗したリクエストをトレースし、遅いエンドポイントをプロファイリングし、問題の正確な箇所を特定できます。開発ループにプロダクショングレードの可観測性があるのです。

ボウリングのバンパーの例え

Aspireチームは素晴らしい例えを使っています：AspireをAIエージェントのためのボウリングレーンのバンパーだと思ってください。エージェントが完璧でない場合（そして完璧にはなりません）、バンパーがガーターに落ちるのを防ぎます。スタック定義が誤設定を防ぎ、コンパイラがエラーをキャッチし、CLIがプロセス管理を行い、テレメトリがフィードバックループを提供します。

これをPlaywright CLIのようなものと組み合わせれば、エージェントは実際にアプリを使うことができます — フローをクリックし、DOMをチェックし、テレメトリで壊れた箇所を見つけ、コードを修正し、再起動してテストし直す。ビルド、実行、観察、修正。これが私たちが追い求めてきた自律的な開発ループです。

始め方

Aspire初心者？get.aspire.devからCLIをインストールし、入門ガイドに従ってください。

すでにAspireを使っている？aspire update --selfで13.2を取得し、お気に入りのコーディングエージェントをリポジトリに向けてください。Aspireのガードレールがあることで、エージェントがどれだけ先まで進めるか驚くかもしれません。

まとめ

Aspire 13.2はもはや単なる分散アプリフレームワークではありません — 不可欠なエージェントインフラになりつつあります。構造化されたスタック定義、ワンコマンド起動、分離された並列実行、リアルタイムテレメトリが、AIエージェントにコードを書くことからアプリを出荷することへ移行するために必要なものを提供します。

Aspireチームの完全な記事ですべての詳細とデモ動画をご覧ください。

Azure FunctionsのMCPサーバーをFoundryエージェントに接続する方法

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

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

MCPエコシステムで私が大好きなことがあります：サーバーを一度構築すれば、どこでも動作するということです。VS Code、Visual Studio、Cursor、ChatGPT — すべてのMCPクライアントがあなたのツールを発見して使用できます。そして今、Microsoftはそのリストにもう一つの消費者を追加しています：Foundryエージェントです。

Azure SDKチームのLily Maが、Azure FunctionsにデプロイされたMCPサーバーをMicrosoft Foundryエージェントに接続する実践ガイドを公開しました。すでにMCPサーバーをお持ちなら、これは純粋な付加価値です — 再構築は不要です。

この組み合わせが理にかなう理由

Azure Functionsは、MCPサーバーのホスティングにスケーラブルなインフラ、組み込みの認証、サーバーレス課金を提供します。Microsoft Foundryは、推論、計画、行動ができるAIエージェントを提供します。この2つを接続すると、カスタムツール — データベースのクエリ、ビジネスAPIの呼び出し、バリデーションロジックの実行 — がエンタープライズAIエージェントが自律的に発見して使用できる機能になります。

重要なポイント：MCPサーバーはそのままです。Foundryをもう一つの消費者として追加するだけです。VS Codeのセットアップで動作している同じツールが、チームや顧客が対話するAIエージェントを動かすようになります。

認証オプション

ここが記事の真価が発揮されるところです。シナリオに応じた4つの認証方法：

方法	ユースケース
キーベース（デフォルト）	開発またはEntra認証なしのサーバー
Microsoft Entra	マネージドIDによる本番環境
OAuthアイデンティティパススルー	各ユーザーが個別に認証する本番環境
認証なし	開発/テストまたは公開データのみ

本番環境では、エージェントIDを使用したMicrosoft Entraが推奨パスです。OAuthアイデンティティパススルーは、ユーザーコンテキストが重要な場合に使用します — エージェントがユーザーにサインインを求め、各リクエストがユーザー自身のトークンを運びます。

セットアップ

大まかな流れ：

MCPサーバーをAzure Functionsにデプロイ — .NET、Python、TypeScript、Javaのサンプルが利用可能
Function Appで組み込みMCP認証を有効化
エンドポイントURLを取得 — https://<FUNCTION_APP_NAME>.azurewebsites.net/runtime/webhooks/mcp
FoundryにMCPサーバーをツールとして追加 — ポータルでエージェントに移動し、新しいMCPツールを追加、エンドポイントとクレデンシャルを提供

その後、Agent Builderのプレイグラウンドでツールをトリガーするプロンプトを送信してテストします。

私の見解

ここでのコンポーザビリティの話は本当に強力になっています。MCPサーバーを.NET（またはPython、TypeScript、Java）で一度構築し、Azure Functionsにデプロイすれば、すべてのMCP互換クライアントが使用できます — コーディングツール、チャットアプリ、そして今やエンタープライズAIエージェント。実際に機能する「一度書いて、どこでも使う」パターンです。

特に.NET開発者にとって、Azure Functions MCP拡張機能がこれを簡単にしてくれます。ツールをAzure Functionsとして定義し、デプロイすれば、Azure Functionsが提供するすべてのセキュリティとスケーリングを備えた本番グレードのMCPサーバーが手に入ります。

まとめ

Azure FunctionsでMCPツールを実行している場合、Foundryエージェントへの接続はクイックウィンです — カスタムツールが適切な認証付きでエンタープライズAI機能になり、サーバー自体のコード変更は不要です。

各認証方法のステップバイステップの手順は完全ガイドを、本番セットアップについては詳細ドキュメントをご覧ください。

MCP AppsにFluent APIが登場 — .NETでリッチなAIツールUIを3ステップで構築

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

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

MCPツールはAIエージェントに機能を与えるのに最適です。でも、ツールがユーザーに何かを表示する必要がある場合はどうでしょう？ダッシュボード、フォーム、インタラクティブなビジュアライゼーション。そこで登場するのがMCP Appsで、構築がずっと簡単になりました。

Azure SDKチームのLilian Kasemが、.NET Azure Functions上のMCP Apps向け新しいFluent設定APIを発表しました。なぜ最初からこんなにシンプルじゃなかったのかと思うような、開発者体験の改善です。

MCP Appsとは？

MCP AppsはModel Context Protocolを拡張し、ツールが独自のUIビュー、静的アセット、セキュリティコントロールを持てるようにします。テキストを返すだけでなく、MCPツールは完全なHTMLエクスペリエンスをレンダリングできます — インタラクティブなダッシュボード、データビジュアライゼーション、設定フォーム — すべてAIエージェントから呼び出し可能で、MCPクライアントを通じてユーザーに表示されます。

問題は、これらを手動で配線するにはMCP仕様を深く理解する必要があったことです：ui:// URI、特殊なMIMEタイプ、ツールとリソース間のメタデータ調整。難しくはないけど、面倒でした。

Fluent APIの3ステップ

ステップ1：関数を定義する。 標準的なAzure Functions MCPツール：

[Function(nameof(HelloApp))]
public string HelloApp(
 [McpToolTrigger("HelloApp", "A simple MCP App that says hello.")]
 ToolInvocationContext context)
{
 return "Hello from app";
}

ステップ2：MCP Appに昇格させる。 プログラムのスタートアップで：

builder.ConfigureMcpTool("HelloApp")
 .AsMcpApp(app => app
 .WithView("assets/hello-app.html")
 .WithTitle("Hello App")
 .WithPermissions(McpAppPermissions.ClipboardWrite | McpAppPermissions.ClipboardRead)
 .WithCsp(csp =>
 {
 csp.AllowBaseUri("https://www.microsoft.com")
 .ConnectTo("https://www.microsoft.com");
 }));

ステップ3：HTMLビューを追加する。 必要なUIでassets/hello-app.htmlを作成します。

以上です。Fluent APIがMCPプロトコルの配管をすべて処理します — 合成リソース関数の生成、正しいMIMEタイプの設定、ツールとビューを接続するメタデータの注入。

APIの設計が秀逸

特に気に入っている点がいくつかあります：

ビューソースが柔軟。 ディスク上のファイルからHTMLを提供したり、自己完結型デプロイのためにリソースをアセンブリに直接埋め込んだりできます：

app.WithView(McpViewSource.FromFile("assets/my-view.html"))
app.WithView(McpViewSource.FromEmbeddedResource("MyApp.Resources.view.html"))

CSPがコンポーザブル。 最小権限の原則に従い、アプリが必要とするオリジンを明示的に許可します。WithCspを複数回呼び出すとオリジンが蓄積されます：

.WithCsp(csp =>
{
 csp.ConnectTo("https://api.example.com")
 .LoadResourcesFrom("https://cdn.example.com")
 .AllowFrame("https://youtube.com");
})

可視性制御。 ツールをLLMのみ、ホストUIのみ、または両方に表示できます。UIのみをレンダリングし、モデルから呼び出されるべきでないツールが欲しい場合は簡単：

.WithVisibility(McpVisibility.App) // UI-only, hidden from the model

始め方

プレビューパッケージを追加：

dotnet add package Microsoft.Azure.Functions.Worker.Extensions.Mcp --version 1.5.0-preview.1

すでにAzure FunctionsでMCPツールを構築している場合、これはパッケージの更新だけです。コンセプトが初めての方はMCP Appsクイックスタートが最適な出発点です。

まとめ

MCP AppsはAIツーリング分野で最もエキサイティングな開発の一つです — 物事を行うだけでなく、ユーザーに物事を見せることができるツール。Fluent APIはプロトコルの複雑さを取り除き、重要なことに集中させてくれます：ツールのロジックとそのUI。

完全なAPIリファレンスと例については完全な記事をお読みください。

Microsoft Foundry 2026年3月 — GPT-5.4、Agent Service GA、そしてすべてを変えるSDKリフレッシュ

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

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

毎月の「Microsoft Foundryの新着情報」記事は、通常インクリメンタルな改善と時折のヘッドライン機能の組み合わせです。2026年3月版はどうでしょう？基本的にすべてがヘッドライン機能です。Foundry Agent ServiceがGAに、GPT-5.4が本番環境向けにリリース、SDKがメジャーな安定版リリースを受け、Fireworks AIがオープンモデル推論をAzureに提供します。.NET開発者にとって何が重要かを詳しく見ていきましょう。

Foundry Agent Serviceが本番環境対応に

これが最大のニュースです。次世代エージェントランタイムが一般提供開始されました — OpenAI Responses APIの上に構築され、OpenAIエージェントとワイヤー互換性があり、複数のプロバイダーのモデルに対応しています。今日Responses APIで構築している方は、Foundryに移行することでエンタープライズセキュリティ、プライベートネットワーキング、Entra RBAC、完全なトレーシング、そして既存のエージェントロジック上での評価が追加されます。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

project_client = AIProjectClient(
 endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=DefaultAzureCredential()
)

agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
)

主な追加機能：エンドツーエンドのプライベートネットワーキング、MCP認証の拡張（OAuthパススルーを含む）、音声対音声エージェント向けVoice Liveプレビュー、6つの新リージョンでのホスティングエージェント。

GPT-5.4 — 純粋な知性より信頼性

GPT-5.4はより賢くなることが目的ではありません。より信頼性が高くなることが目的です。長い対話での強力な推論、より良い指示への忠実度、ワークフロー中の障害の減少、そして統合されたコンピュータ使用機能。本番環境のエージェントにとって、その信頼性はベンチマークスコアよりもはるかに重要です。

モデル	価格（100万トークンあたり）	最適な用途
GPT-5.4 (≤272K)	$2.50 / $15 出力	本番エージェント、コーディング、ドキュメントワークフロー
GPT-5.4 Pro	$30 / $180 出力	深い分析、科学的推論
GPT-5.4 Mini	コスト効率的	分類、抽出、軽量なツール呼び出し

賢い戦略はルーティングです：GPT-5.4 Miniが高ボリューム・低レイテンシーの作業を処理し、GPT-5.4が推論の重いリクエストを担当します。

SDKがついに安定版に

azure-ai-projects SDKが全言語で安定版をリリースしました — Python 2.0.0、JS/TS 2.0.0、Java 2.0.0、そして.NET 2.0.0（4月1日）。azure-ai-agentsの依存関係はなくなり、すべてがAIProjectClientの下に統合されました。pip install azure-ai-projectsでインストールでき、パッケージはopenaiとazure-identityを直接の依存関係としてバンドルしています。

.NET開発者にとって、これはFoundry全体の機能に対する単一のNuGetパッケージを意味します。別々のエージェントSDKを使い分ける必要はもうありません。

Fireworks AIがオープンモデルをAzureに提供

おそらくアーキテクチャ的に最も興味深い追加：Fireworks AIが毎日13兆以上のトークンを~180Kリクエスト/秒で処理し、Foundryを通じて利用可能になりました。DeepSeek V3.2、gpt-oss-120b、Kimi K2.5、MiniMax M2.5がローンチ時に利用可能です。

本当の注目点はbring-your-own-weights — サービングスタックを変更せずに、どこからでも量子化またはファインチューニングされた重みをアップロードできます。サーバーレスのペイパートークンまたはプロビジョニングされたスループットでデプロイ可能です。

その他のハイライト

Phi-4 Reasoning Vision 15B — チャート、ダイアグラム、ドキュメントレイアウト向けのマルチモーダル推論
Evaluations GA — Azure Monitorに連携した継続的な本番モニタリング付きのすぐに使えるエバリュエーター
Priority Processing（プレビュー）— レイテンシーに敏感なワークロード向けの専用コンピュートレーン
Voice Live — Foundryエージェントに直接接続する音声対音声ランタイム
Tracing GA — ソートとフィルター付きのエンドツーエンドエージェントトレース検査
PromptFlowの非推奨化 — 2027年1月までにMicrosoft Framework Workflowsへの移行

まとめ

2026年3月はFoundryにとって転換点です。Agent Service GA、全言語での安定SDK、信頼性の高い本番エージェント向けGPT-5.4、そしてFireworks AIによるオープンモデル推論 — プラットフォームは本格的なワークロードに対応する準備が整っています。

完全なまとめを読んで、最初のエージェントを構築して始めましょう。

SQL MCP Server — AIエージェントにデータベースアクセスを与える正しい方法

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

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

正直に言いましょう：今日利用可能なほとんどのデータベースMCPサーバーは恐ろしいものです。自然言語のクエリを受け取り、その場でSQLを生成し、本番データに対して実行します。何がうまくいかないでしょうか？（全部です。全部うまくいかない可能性があります。）

Azure SQLチームがSQL MCP Serverを発表しましたが、根本的に異なるアプローチを取っています。Data API builder（DAB）2.0の機能として構築され、AIエージェントに構造化された決定的なデータベース操作アクセスを提供します — NL2SQLなし、スキーマの公開なし、そしてすべてのステップで完全なRBAC付き。

なぜNL2SQLを使わないのか？

これが最も興味深い設計判断です。モデルは決定的ではなく、複雑なクエリは微妙なエラーを生み出す可能性が最も高いです。ユーザーがAIに生成してほしいと思う正にそのクエリが、非決定的に生成された場合に最も精査が必要なものでもあります。

代わりに、SQL MCP ServerはNL2DABアプローチを使用します。エージェントはData API builderのエンティティ抽象化レイヤーと組み込みのクエリビルダーで作業し、正確で整形されたT-SQLを決定的に生成します。ユーザーにとっては同じ結果ですが、幻覚されたJOINや偶発的なデータ漏洩のリスクがありません。

7つのツール、700ではなく

SQL MCP Serverは、データベースのサイズに関係なく、正確に7つのDMLツールを公開します：

describe_entities — 利用可能なエンティティと操作を発見
create_record — 行を挿入
read_records — テーブルとビューをクエリ
update_record — 行を変更
delete_record — 行を削除
execute_entity — ストアドプロシージャを実行
aggregate_records — 集計クエリ

これは賢明です。コンテキストウィンドウはエージェントの思考空間だからです。何百ものツール定義で氾濫させると、推論のための空間が減ります。7つの固定ツールは、エージェントをナビゲーションではなく思考に集中させ続けます。

各ツールは個別に有効化・無効化できます：

"runtime": {
 "mcp": {
 "enabled": true,
 "path": "/mcp",
 "dml-tools": {
 "describe-entities": true,
 "create-record": true,
 "read-records": true,
 "update-record": true,
 "delete-record": true,
 "execute-entity": true,
 "aggregate-records": true
 }
 }
}

3つのコマンドで開始

dab init \
 --database-type mssql \
 --connection-string "@env('sql_connection_string')"

dab add Customers \
 --source dbo.Customers \
 --permissions "anonymous:*"

dab start

これでCustomersテーブルを公開するSQL MCP Serverが稼働します。エンティティ抽象化レイヤーにより、名前やカラムにエイリアスを設定し、ロールごとにフィールドを制限し、エージェントが見るものを正確に制御できます — 内部スキーマの詳細を公開することなく。

セキュリティストーリーは堅実

ここがData API builderの成熟さが活きるところです：

あらゆるレイヤーでRBAC — 各エンティティがどのロールが読み取り、作成、更新、削除できるか、どのフィールドが表示されるかを定義
Azure Key Vault統合 — 接続文字列とシークレットを安全に管理
Microsoft Entra + カスタムOAuth — 本番グレードの認証
Content Security Policy — エージェントは生のSQLではなく、制御されたコントラクトを通じてやり取り

スキーマの抽象化は特に重要です。内部テーブル名やカラム名はエージェントに露出しません。AI対話に意味のあるエンティティ、エイリアス、説明を定義します — データベースのERD図ではなく。

マルチデータベースとマルチプロトコル

SQL MCP ServerはMicrosoft SQL、PostgreSQL、Azure Cosmos DB、MySQLをサポートします。そしてDABの機能であるため、同じ設定からREST、GraphQL、MCPのエンドポイントを同時に取得できます。同じエンティティ定義、同じRBACルール、同じセキュリティ — 3つのプロトコルすべてで。

DAB 2.0の自動設定は、データベースを検査して設定を動的に構築することもできます。迅速なプロトタイピングのために抽象化を減らしても良い場合に便利です。

私の見解

これがAIエージェント向けのエンタープライズデータベースアクセスのあるべき姿です。「ねぇLLM、SQLを書いてプロダクションにYOLO」ではなく。代わりに：明確に定義されたエンティティレイヤー、決定的なクエリ生成、各ステップでのRBAC、キャッシュ、モニタリング、テレメトリ。最高の意味で退屈です。

.NET開発者にとって、統合ストーリーはクリーンです — DABは.NETツールで、MCP Serverはコンテナとして動作し、ほとんどの人がすでに使っているAzure SQLで機能します。データアクセスが必要なAIエージェントを構築しているなら、ここから始めましょう。

まとめ

SQL MCP Serverは無料、オープンソースで、どこでも動作します。AIエージェントに安全なデータベースアクセスを提供するためのMicrosoftの規範的アプローチです。始めるには完全な記事とドキュメントをご覧ください。

ブラックボックスに感じないリアルタイムマルチエージェント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プロトコルリポジトリをチェックして、さらに深く掘り下げてください。

VS Code 1.115 — バックグラウンドターミナル通知、SSHエージェントモードなど

Emiliano Montesdeoca — Mon, 06 Apr 2026 00:00:00 +0000

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

VS Code 1.115がリリースされました。目玉機能という点では軽めのリリースですが、AIコーディングアシスタントを日常的に使っている方にとって、エージェント関連の改善は本当に役立つものです。

実際に知っておく価値のあるポイントを紹介します。

バックグラウンドターミナルがエージェントに通知するように

これが今回の目玉機能です。バックグラウンドターミナルが、コマンド完了時に終了コードとターミナル出力を含めて、エージェントに自動通知するようになりました。バックグラウンドターミナルでの入力プロンプトも検出されてユーザーに表示されます。

なぜこれが重要なのか？Copilotのエージェントモードでビルドコマンドやテストスイートをバックグラウンドで実行したことがあるなら、「あれ、もう終わった？」という苦痛を知っているはずです。バックグラウンドターミナルは基本的に撃ちっぱなしでした。今ではエージェントがdotnet buildやdotnet testの完了時に通知を受け取り、出力を確認して適切に対応できます。小さな変更ですが、エージェント駆動のワークフローの信頼性が大幅に向上します。

また、新しいsend_to_terminalツールにより、エージェントがユーザーの確認付きでバックグラウンドターミナルにコマンドを送信できるようになりました。これにより、run_in_terminalでタイムアウトを設定するとターミナルがバックグラウンドに移動して読み取り専用になってしまう問題が解決されました。

SSHリモートエージェントホスティング

VS Codeが SSH経由でリモートマシンに接続し、CLIを自動インストールしてエージェントホストモードで起動できるようになりました。これにより、AIエージェントセッションがリモート環境を直接ターゲットにできます。LinuxサーバーやクラウドVMでビルド・テストを行う.NET開発者にとって便利です。

エージェントセッションでの編集追跡

エージェントセッション中に行われたファイル編集が、diff、元に戻す/やり直し、状態復元とともに追跡・復元されるようになりました。エージェントがコードを変更して何か問題が起きた場合、何が変わったかを正確に確認してロールバックできます。エージェントにコードベースを変更させる際の安心感が得られます。

ブラウザタブの認識とその他の改善

その他のクオリティ・オブ・ライフの向上：

ブラウザタブの追跡 — チャットがセッション中に開いたブラウザタブを追跡・リンクできるようになり、エージェントが閲覧中のWebページを参照できます
ターミナルへのファイル貼り付け — Ctrl+V、ドラッグ&ドロップ、右クリックでターミナルにファイル（画像含む）を貼り付け可能
ミニマップでのテストカバレッジ — テストカバレッジインジケーターがミニマップに表示され、視覚的な概要を素早く確認できます
Macでのピンチズーム — 統合ブラウザがピンチズームジェスチャーをサポート
セッションでのCopilot使用権限 — ステータスバーのセッションビューに使用状況が表示されます
ファイルに移動でのファビコン — 開いているWebページがクイックピックリストにファビコンを表示

まとめ

VS Code 1.115はインクリメンタルなリリースですが、エージェントの改善 — バックグラウンドターミナル通知、SSHエージェントホスティング、編集追跡 — が合わさって、AI支援開発の体験が目に見えてスムーズになりました。.NETプロジェクトでCopilotのエージェントモードを使っているなら、日々の摩擦を減らすクオリティ・オブ・ライフの改善そのものです。

すべての詳細は完全なリリースノートをご覧ください。

Aspire 13.2にドキュメントCLIが搭載 — AIエージェントも使えます

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

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

Aspire AppHostの奥深くでインテグレーションを接続していて、Redisインテグレーションが正確にどのパラメータを期待しているかを確認する必要がある、あの瞬間を知っていますか？ブラウザにAlt-Tabして、aspire.devを探し回り、APIドキュメントに目を細め、エディタに戻る。コンテキストが失われて、フローが途切れる。

Aspire 13.2がまさにその解決策をリリースしました。aspire docs CLIを使えば、ターミナルから直接Aspireの公式ドキュメントを検索、閲覧、そして読むことができます。そして再利用可能なサービスに支えられているため、AIエージェントやスキルも同じコマンドを使ってドキュメントを参照できます。存在しないAPIを幻覚する代わりに。

これが本当に解決する問題

David Pineがオリジナルの記事で的確に指摘しています：AIエージェントはAspireアプリの構築を支援する点でひどいものでした。aspire runの代わりにdotnet runを推奨し、aspire.devにあるドキュメントに対してlearn.microsoft.comを参照し、古いNuGetパッケージを提案し、そして——個人的に一番のお気に入り——存在しないAPIを幻覚していました。

なぜか？Aspireがポリグロットになるよりもはるかに長い間.NET専用だったからです。そしてLLMは最新機能よりも前のトレーニングデータで動作しています。AIエージェントに現在のドキュメントを実際に検索する能力を与えると、推測をやめて役に立つようになります。

3つのコマンド、ブラウザタブはゼロ

CLIは爽快なほどシンプルです：

すべてのドキュメントを一覧表示

aspire docs list

aspire.devで利用可能なすべてのドキュメントページを返します。マシンリーダブルな出力が必要ですか？--format Jsonを追加してください。

トピックを検索

aspire docs search "redis"

タイトルとコンテンツの両方を重み付けされた関連性スコアリングで検索します。内部的にドキュメントツールを支えているのと同じ検索エンジンです。タイトル、スラグ、関連性スコアを含むランク付けされた結果が得られます。

ページ全体を読む（またはセクションだけ）

aspire docs get redis-integration

ページ全体をマークダウンとしてターミナルにストリーミングします。セクションだけ必要ですか？

aspire docs get redis-integration --section "Add Redis resource"

外科的精度。500行をスクロールする必要はありません。必要な部分だけ。

AIエージェントの視点

ここからがAIツールで開発している私たち開発者にとって面白くなるところです。同じaspire docsコマンドが、スキル、MCPサーバー、またはシンプルなCLIラッパーを通じて、AIエージェントのツールとして機能します。

あなたのAIアシスタントが古いトレーニングデータに基づいてAspire APIを捏造する代わりに、aspire docs search "postgres"を呼び出して、公式のインテグレーションドキュメントを見つけ、正しいページを読み、ドキュメントに記載されたアプローチを提供できます。リアルタイムで最新のドキュメント——モデルが6ヶ月前に記憶したものではありません。

この背後のアーキテクチャは意図的なものです。Aspireチームは一回限りのインテグレーションではなく、再利用可能なサービス（IDocsIndexService、IDocsSearchService、IDocsFetcher、IDocsCache）を構築しました。つまり、同じ検索エンジンがターミナルの人間、エディタのAIエージェント、CIパイプラインの自動化のために機能します。

実世界のシナリオ

ターミナルでの素早い検索： 3ファイルの深さに入っていて、Redisの設定パラメータが必要。2つのコマンド、90秒、仕事に戻る：

aspire docs search "redis" --limit 1
aspire docs get redis-integration --section "Configuration"

AI支援開発： VS CodeスキルがCLIコマンドをラップします。「AppHostにPostgreSQLデータベースを追加して」と聞くと、エージェントが回答する前に実際のドキュメントを参照します。幻覚なし。

CI/CDバリデーション： パイプラインがAppHost設定を公式ドキュメントに対してプログラム的に検証します。--format Jsonの出力はjqやその他のツールにきれいにパイプできます。

カスタムナレッジベース： 独自のAIツールを構築していますか？構造化されたJSON出力をナレッジベースに直接パイプ：

aspire docs search "monitoring" --format Json | jq '[.[] | {slug, title, summary}]'

Webスクレイピングなし。APIキーなし。内部的にドキュメントツールが使用しているのと同じ構造化データ。

ドキュメントは常に最新

これが私が最も評価している部分です。CLIはスナップショットをダウンロードしません——ETagベースのキャッシュでaspire.devにクエリを実行します。ドキュメントが更新された瞬間、あなたのCLIとその上に構築されたすべてのスキルがそれを反映します。古いコピーも、「でもwikiには書いてあった…」という瞬間もありません。

まとめ

aspire docsは、実際の問題をきれいに解決する、そんな小さな機能の一つです。人間はターミナルネイティブなドキュメントアクセスを得ます。AIエージェントは推測をやめて実際のドキュメントを参照する方法を得ます。そしてすべてが同じ信頼の源に支えられています。

.NET Aspireで構築していてまだCLIを試していないなら、aspire docs search "あなたのトピック" を実行して、どう感じるか確かめてください。そして、使っているAIスキルや自動化セットアップにそれらのコマンドをラップすることを検討してください——あなたのエージェントが感謝するでしょう。

ドキュメントツールがどのように構築されたかについてのDavid Pineの詳細記事と、すべての詳細が記載された公式CLIリファレンスをチェックしてください。

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で今日から始められます。クイックスタートガイドとサンプルをチェックして、実際に触ってみてください。

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

Aspire 13.2のダッシュボードにテレメトリAPIが搭載 — これで全てが変わる

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

.NET Aspireで分散アプリケーションを構築しているなら、ダッシュボードが体験全体の中で最高のものだと既に知っているでしょう。すべてのトレース、ログ、メトリクスが一箇所に — 外部のJaegerも不要、Seqのセットアップも不要、「別のターミナルを確認させて」という瞬間もなし。

Aspire 13.2で大幅に改善されました。James Newton-Kingがアップデートを発表しましたが、正直なところ、テレメトリエクスポートとAPI機能だけでアップグレードの価値があります。

テレメトリをまともにエクスポートする

誰もが経験したシナリオ：分散問題をデバッグしていて、20分のセットアップの後にようやく再現でき、チームに何が起きたかを共有する必要がある。以前は？スクリーンショット。トレースIDのコピペ。いつもの混乱。

Aspire 13.2はログとテレメトリの管理ダイアログを追加しました：

すべてのテレメトリをクリア（再現前に便利）
選択したテレメトリを標準OTLP/JSON形式のZIPファイルにエクスポート
そのZIPを後で任意のAspireダッシュボードに再インポート

最後のポイントがキラー機能です。バグを再現し、テレメトリをエクスポートし、ワークアイテムに添付すれば、チームメイトが自分のダッシュボードにインポートして、あなたが見たものと全く同じものを見ることができます。「あなたのマシンで再現できる？」はもう不要です。

個々のトレース、スパン、ログにもコンテキストメニューに「Export JSON」オプションがあります。特定のトレースを共有する必要がある？右クリック、JSONをコピー、PRの説明に貼り付け。完了。

テレメトリAPIが本当のゲームチェンジャー

最もワクワクしているのがこれです。ダッシュボードが/api/telemetry配下でHTTP APIを公開し、テレメトリデータをプログラマティックにクエリできるようになりました。利用可能なエンドポイント：

GET /api/telemetry/resources — テレメトリ付きリソースの一覧
GET /api/telemetry/spans — フィルター付きスパンのクエリ
GET /api/telemetry/logs — フィルター付きログのクエリ
GET /api/telemetry/traces — トレースの一覧
GET /api/telemetry/traces/{traceId} — 特定トレースの全スパン取得

すべてOTLP JSON形式で返されます。これは新しいCLIコマンドaspire agent mcpとaspire otelを駆動しますが、本当の意味はもっと大きい：アプリのテレメトリを直接クエリするツーリング、スクリプト、AIエージェント統合を構築できるようになりました。

デバッグ中に実際の分散トレースを見ることができるAIコーディングエージェントを想像してください。それはもう仮説ではありません — このAPIが可能にするものです。

GenAIテレメトリが実用的に

Semantic KernelやMicrosoft.Extensions.AIでAI搭載アプリを構築しているなら、改善されたGenAIテレメトリビジュアライザーを評価するでしょう。Aspire 13.2の追加機能：

AIツールの説明がMarkdownでレンダリング
トレースページに専用のGenAIボタンで素早いアクセス
切り詰められた、または非標準のGenAI JSONに対するエラー処理の改善
ツール定義間のクリックでハイライトするナビゲーション

ブログ記事では、VS Code Copilot chat、Copilot CLI、OpenCodeのすべてがOTEL_EXPORTER_OTLP_ENDPOINTの設定をサポートしていると言及されています。Aspireダッシュボードに向ければ、テレメトリを通じてAIエージェントがリアルタイムで考えている様子を文字通り見ることができます。他では見つけられないデバッグ体験です。

まとめ

Aspire 13.2はダッシュボードを「便利なデバッグUI」から「プログラマブルなオブザーバビリティプラットフォーム」に変えます。エクスポート/インポートワークフローだけで分散デバッグの実際の時間を節約し、テレメトリAPIはAI支援診断への扉を開きます。

既にAspireを使っているなら、アップグレードしましょう。まだなら — aspire.devを試してみる良い理由です。

azdでAIエージェントをローカル実行・デバッグ可能に — 2026年3月の変更点まとめ

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

1ヶ月で7つのリリース。これがAzure Developer CLI（azd）チームが2026年3月に出荷したもので、メイン機能は私が待っていたもの：AIエージェントのローカル実行＆デバッグループです。

PC Chanが完全なまとめを公開しましたが、内容が多いので、AI搭載アプリを構築する.NET開発者にとって本当に重要なことにフィルタリングしましょう。

デプロイなしでAIエージェントを実行・デバッグ

これが一番大きいです。新しいazure.ai.agents拡張機能がAIエージェントの適切なインナーループ体験を提供するコマンドを追加します：

azd ai agent run — エージェントをローカルで起動
azd ai agent invoke — メッセージを送信（ローカルまたはデプロイ済み）
azd ai agent show — コンテナのステータスとヘルスを表示
azd ai agent monitor — コンテナログをリアルタイムでストリーミング

以前は、AIエージェントのテストは変更するたびにMicrosoft Foundryへのデプロイを意味しました。今ではローカルで反復し、エージェントの動作をテストし、準備ができたときだけデプロイできます。

GitHub Copilotがazdプロジェクトをセットアップ

azd initに「Set up with GitHub Copilot (Preview)」オプションが追加されました。プロジェクト構造についてのプロンプトに手動で回答する代わりに、Copilotエージェントが設定を生成します。コマンドが失敗した場合、azdがAI支援のトラブルシューティングを提供します。

Container App Jobsとデプロイの改善

Container App Jobs：azdが既存のhost: containerapp設定でMicrosoft.App/jobsをデプロイ可能に
設定可能なデプロイタイムアウト：azd deployの新しい--timeoutフラグとazure.yamlのdeployTimeoutフィールド
リモートビルドフォールバック：ACRビルドが失敗するとローカルDocker/Podmanビルドに自動フォールバック
ローカルプリフライト検証：デプロイ前にBicepパラメータをローカルで検証

DXの改善

pnpm/yarn自動検出 — JS/TSプロジェクト向け
pyproject.tomlサポート — Pythonパッケージング向け
ローカルテンプレートディレクトリ — azd init --templateがファイルシステムパスを受け入れ
改善されたエラーメッセージ — --no-promptモード
ビルド環境変数 — すべてのフレームワークビルドサブプロセスに注入（.NET、Node.js、Java、Python）

まとめ

ローカルAIエージェントデバッグループがこのリリースの主役ですが、デプロイ改善とDXポリッシュの積み重ねにより、azdはかつてないほど成熟しています。AzureにDotNetアプリをデプロイしているなら — 特にAIエージェント — このアップデートは価値があります。

完全なリリースノートで全詳細をご確認ください。

Visual Studioの3月アップデートでカスタムCopilotエージェントが作成可能に — find_symbolが大きな進化

Emiliano Montesdeoca — Thu, 02 Apr 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

Visual Studioが最も重要なCopilotアップデートを受けました。Mark Downieが3月リリースを発表し、見出しはカスタムエージェントですが、正直なところfind_symbolツールがワークフローを最も変える機能かもしれません。

リポジトリ内のカスタムCopilotエージェント

Copilotにチームのコーディング標準に従わせたい？カスタムエージェントはリポジトリの.github/agents/に.agent.mdファイルとして定義されます。各エージェントはワークスペース認識、コード理解、ツール、優先モデル、MCP接続へのフルアクセスを持ちます。

エージェントスキル：再利用可能なインストラクションパック

スキルはリポジトリの.github/skills/またはプロファイルの~/.copilot/skills/から自動的にロードされます。

find_symbol：言語対応ナビゲーション

新しいfind_symbolツールはCopilotのエージェントモードに言語サービスベースのシンボルナビゲーションを提供します。テキスト検索の代わりに、シンボルのすべての参照を見つけ、型情報やスコープにアクセスできます。

.NET開発者にとって、これは大きな改善です — 深い型階層を持つC#コードベースが大きく恩恵を受けます。

Copilotでテストをプロファイル

Test ExplorerのコンテキストメニューにProfile with Copilotが追加されました。Profiling Agentがテストを実行し、パフォーマンスを自動分析します。

ライブデバッグ中のPerf Tips

パフォーマンス最適化がデバッグ中に行われるようになりました。Visual Studioがインラインで実行時間を表示します。遅い行を見つけたら、Perf Tipをクリックして最適化の提案をCopilotに依頼できます。

Solution ExplorerからNuGet脆弱性を修正

NuGetパッケージの脆弱性が検出されると、Solution Explorerに直接Fix with GitHub Copilotリンクが表示されます。

まとめ

カスタムエージェントとスキルが見出しですが、find_symbolが隠れた逸品です — .NETコードのリファクタリング時のCopilotの精度を根本的に変えます。Visual Studio 2026 Insidersをダウンロードしてお試しください。

KubeCon Europe 2026：.NET開発者が本当に知るべきこと

Emiliano Montesdeoca — Sun, 29 Mar 2026 00:00:00 +0000

この記事は自動翻訳されました。オリジナル版はこちらをご覧ください。

巨大なアナウンス記事が出て、スクロールしながら「クール、でも実際に自分にとって何が変わるの？」と思うあの感覚、分かりますよね？毎回KubeConシーズンになると私はそうなります。

MicrosoftがKubeCon Europe 2026の完全なまとめを公開しました。Brendan Burns自身が執筆しています。正直に言うと、ここには本物の中身があります。機能のチェックリストだけでなく、本番環境での運用方法を変える運用面の改善です。

.NET開発者として本当に重要なことを整理しましょう。

サービスメッシュ税なしのmTLS

サービスメッシュの問題点：全員がセキュリティの保証を求めるけど、運用オーバーヘッドは誰も望まない。AKSがついにこのギャップを埋めています。

Azure Kubernetes Application Networkは、相互TLS、アプリケーション認識型の認可、トラフィックテレメトリを提供します。サイドカーの重いフルメッシュをデプロイする必要はありません。Advanced Container Networking ServicesのCilium mTLSと組み合わせれば、X.509証明書とSPIREによるID管理を使った暗号化されたpod間通信が実現します。

実際にはどういうことか：ASP.NET Core APIがバックグラウンドワーカーと通信する、gRPCサービスが相互に呼び出す — すべてがネットワークレベルで暗号化・ID検証され、アプリケーションコードの変更はゼロ。これは大きいです。

ingress-nginxから移行しているチームには、Meshless IstioによるApplication Routingもあり、Kubernetes Gateway APIの完全サポート付きです。サイドカーなし。標準ベース。段階的な移行のためのingress2gatewayツールも提供されています。

後付けではないGPUオブザーバビリティ

.NETサービスと並行してAI推論を実行している場合（正直、誰が始めていないでしょうか？）、GPUモニタリングの盲点に遭遇したことがあるでしょう。CPU/メモリのダッシュボードは素晴らしかったのに、GPUについては手動のエクスポーター設定なしでは何もなかった。

AKSはGPUメトリクスをネイティブにマネージドPrometheusとGrafanaに表示するようになりました。同じスタック、同じダッシュボード、同じアラートパイプライン。カスタムエクスポーターもサードパーティエージェントも不要。

ネットワーク側では、HTTP、gRPC、Kafkaトラフィックのフローごとの可視性がワンクリックAzure Monitor体験で追加されました。IP、ポート、ワークロード、フロー方向、ポリシー判定 — すべてが組み込みダッシュボードに。

そして二度見させられたもの：agentic container networkingは、クラスターのネットワーク状態について自然言語で質問できるWeb UIを追加します。「ポッドXがサービスYに到達できないのはなぜ？」→ ライブテレメトリからの読み取り専用診断。午前2時に本当に役立ちます。

博士号不要のクロスクラスターネットワーキング

マルチクラスターKubernetesは歴史的に「自分でネットワークの接着剤を持ってくる」体験でした。Azure Kubernetes Fleet Managerが、マネージドCiliumクラスターメッシュによるクロスクラスターネットワーキングを提供するようになりました：

AKSクラスター間の統一された接続性
クロスクラスター検出のためのグローバルサービスレジストリ
クラスターごとに繰り返すのではなく中央で管理される設定

レジリエンスやコンプライアンスのために複数リージョンで.NETマイクロサービスを実行しているなら、多くの脆弱なカスタムの接着剤が置き換えられます。West EuropeのサービスAがメッシュを通じてEast USのサービスBを発見して呼び出せます。一貫したルーティングとセキュリティポリシーが適用されます。

勇気を必要としないアップグレード

正直に言いましょう — 本番環境のKubernetesアップグレードはストレスフルです。「アップグレードして祈る」があまりにも多くのチームのデファクト戦略であり、クラスターがバージョンに遅れる主な理由です。

2つの新機能がこれを変えます：

Blue-greenエージェントプールアップグレードは新しい設定でパラレルなノードプールを作成します。動作を検証し、トラフィックを段階的に移動し、クリーンなロールバックパスを維持します。本番ノードでのインプレース変更はもう不要。

エージェントプールロールバックにより、アップグレードがうまくいかなかった場合、クラスターを再構築することなく、ノードプールを以前のKubernetesバージョンとノードイメージに戻せます。

組み合わせることで、オペレーターにアップグレードのライフサイクルに対する本当のコントロールを提供します。.NETチームにとっては、プラットフォームの速度が新しいランタイム、セキュリティパッチ、ネットワーク機能をどれだけ早く採用できるかを直接制御するため重要です。

AIワークロードがKubernetesのファーストクラス市民に

アップストリームのオープンソース作業も同様に重要です。Dynamic Resource Allocation (DRA)がKubernetes 1.36でGAになり、GPUスケジューリングがワークアラウンドではなく本物のファーストクラス機能になりました。

注目すべきプロジェクト：

プロジェクト	内容
AI Runway	推論のための共通Kubernetes API — K8sを知らなくてもモデルをデプロイ、HuggingFace検出とコスト見積もり付き
HolmesGPT	クラウドネイティブ向けのエージェント型トラブルシューティング — CNCF Sandboxプロジェクトに
Dalec	SBOM生成付きの宣言的コンテナイメージビルド — ビルド段階でのCVE削減

方向性は明確：あなたの.NET API、Semantic Kernelのオーケストレーション層、推論ワークロードはすべて一貫したプラットフォームモデル上で実行されるべきです。そこに向かっています。

今週から始めるなら

チームでこれらの変更を評価しているなら、私の正直な優先順位リスト：

まずオブザーバビリティ — 非本番クラスターでGPUメトリクスとネットワークフローログを有効にする。見逃していたものを確認する。
Blue-greenアップグレードを試す — 次の本番クラスターアップグレード前にロールバックワークフローをテストする。プロセスへの信頼を構築する。
ID認識型ネットワーキングをパイロット — 内部サービスパスを1つ選んでCiliumでmTLSを有効にする。オーバーヘッドを測定する（ネタバレ：最小限）。
Fleet Managerを評価 — 2つ以上のクラスターを運用しているなら、クロスクラスターネットワーキングはカスタムの接着剤削減だけで元が取れる。

小さな実験、素早いフィードバック。それが常に正しい手。

まとめ

KubeConのアナウンスは圧倒的になりがちですが、今回のバッチはAKS上の.NETチームにとって本当に針を動かします。メッシュオーバーヘッドなしのより良いネットワークセキュリティ、本物のGPUオブザーバビリティ、より安全なアップグレード、そしてより強力なAIインフラストラクチャの基盤。

すでにAKSを使っているなら、運用ベースラインを強化する絶好のタイミングです。.NETワークロードをKubernetesに移行する予定なら — プラットフォームは大幅にプロダクションレディになりました。

SQL MCP Server、SSMS の Copilot、AI エージェント付き Database Hub：SQLCon 2026 で本当に重要なこと

Emiliano Montesdeoca — Sat, 28 Mar 2026 00:00:00 +0000

Microsoft がアトランタの FabCon と併催で SQLCon 2026 をキックオフしました。内容盛りだくさんです。元の発表はコスト削減プランからエンタープライズコンプライアンス機能まで全部カバーしていますが、エンタープライズ価格のスライドは飛ばして、Azure SQL と AI で開発している人にとって本当に重要な部分にフォーカスします。

SQL MCP Server がパブリックプレビューに

これが僕にとってのヘッドラインです。Azure SQL Database Hyperscale に SQL MCP Server のパブリックプレビューが追加され、Model Context Protocol を使って SQL データを AI エージェントや Copilot にセキュアに接続できるようになりました。

MCP の波を追いかけている人なら — 正直、今は見逃すほうが難しいですよね — これは大きなニュースです。データベースからのコンテキストを AI エージェントに渡すためにカスタムデータパイプラインを構築する代わりに、SQL データを直接公開するための標準化されたプロトコルが手に入ります。エージェントがライブのデータベース情報をクエリし、推論し、アクションを起こせるようになります。

Semantic Kernel や Microsoft Agent Framework で AI エージェントを構築している人にとって、これはクリーンな統合パスを開きます。エージェントが在庫を確認する必要がある？顧客レコードを検索する？注文を検証する？MCP がシナリオごとにカスタムのデータ取得コードを書かなくても、構造化されたやり方を提供してくれます。

SSMS 22 の GitHub Copilot が GA に

SQL Server Management Studio を使っている人 — 正直に言うと、ほとんどの人がまだ使っていますよね — GitHub Copilot が SSMS 22 で正式に一般提供になりました。VS Code や Visual Studio で使っているのと同じ Copilot 体験が T-SQL で使えます。

実用的な価値はシンプルです：クエリの作成、ストアドプロシージャのリファクタリング、パフォーマンス問題のトラブルシューティング、管理タスクのためのチャットベースのアシスタンス。コンセプトとしては革命的ではないですが、SSMS の中にあるということは、データベース作業で AI の助けを得るためだけに別のエディタにコンテキストスイッチする必要がないということです。

ベクトルインデックスが本格的にアップグレード

Azure SQL Database のベクトルインデックスが高速化・高機能化し、insert、update、delete の完全サポートが追加されました。つまり、ベクトルデータがリアルタイムで最新の状態を保てます — バッチ再インデックスは不要です。

新機能はこちら：

量子化 でインデックスサイズを縮小（精度の大きな損失なし）
イテレーティブフィルタリング でより精密な結果
クエリオプティマイザーとの緊密な統合 で予測可能なパフォーマンス

Azure SQL をベクトルストアとして Retrieval-Augmented Generation (RAG) を行っている場合、これらの改善は直接的に役立ちます。リレーショナルデータと同じデータベースにベクトルを保持できるので、別のベクトルデータベースを運用するよりもアーキテクチャが大幅にシンプルになります。

同じベクトルの改善は Fabric の SQL Database でも利用可能です。どちらも同じ SQL エンジンで動いているからです。

Fabric の Database Hub：エージェント型管理

これはもう少し将来を見据えた話ですが、面白いです。Microsoft は Microsoft Fabric の Database Hub（早期アクセス）を発表しました。Azure SQL、Cosmos DB、PostgreSQL、MySQL、SQL Server via Arc を一元的に管理できるビューを提供します。

面白いのは統一ビューだけではなく、エージェント型の管理アプローチです。AI エージェントがデータベース環境を継続的に監視し、何が変わったかを示し、なぜそれが重要かを説明し、次に何をすべきかを提案します。エージェントが下調べをして、あなたが判断を下す human-in-the-loop モデルです。

複数のデータベースを管理しているチームにとって、これは運用ノイズを本当に減らせる可能性があります。ポータル間を行き来してメトリクスを手動で確認する代わりに、エージェントがシグナルを届けてくれます。

.NET 開発者にとっての意味

これらの発表をつなぐ共通のテーマは明確です：Microsoft はデータベーススタックのあらゆるレイヤーに AI エージェントを組み込んでいます。ギミックとしてではなく、実用的なツールレイヤーとして。

Azure SQL をバックエンドにした .NET アプリを構築しているなら、僕が実際にやることはこれです：

SQL MCP Server を試す — AI エージェントを構築しているなら。カスタムの配管なしでエージェントにデータベースアクセスを与える最もクリーンな方法です。
SSMS で Copilot を有効にする — まだなら。日常の SQL 作業のための無料の生産性アップです。
ベクトルインデックスを調べる — RAG をやっていて現在別のベクトルストアを運用しているなら。Azure SQL に統合すれば、管理するサービスが一つ減ります。

まとめ

完全な発表にはもっとあります — コスト削減プラン、移行アシスタント、コンプライアンス機能 — でも開発者向けのストーリーは MCP Server、ベクトルの改善、エージェント型管理レイヤーにあります。これらが変えるのは、予算の立て方ではなく、構築の仕方です。

完全な全体像は Shireesh Thota の完全な発表をチェックしてください。新しい管理体験を試したい場合は Database Hub の早期アクセスにサインアップしてください。

Azure DevOps MCPサーバーがMicrosoft Foundryに登場：AIエージェントにとっての意味

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

MCP（Model Context Protocol）が注目を集めています。AIエージェントのエコシステムを追っているなら、MCPサーバーがあちこちで登場しているのに気づいているでしょう — 標準化されたプロトコルを通じて、エージェントが外部ツールやサービスとやり取りする能力を提供しています。

Azure DevOps MCPサーバーがMicrosoft Foundryで利用可能になり、これは実用的な可能性について考えさせられる統合の一つです。

実際に何が起きているのか

MicrosoftはすでにAzure DevOps MCPサーバーをパブリックプレビューとしてリリースしています — これがMCPサーバー本体です。新しいのはFoundryとの統合です。ツールカタログから直接、Azure DevOps MCPサーバーをFoundryエージェントに追加できるようになりました。

Foundryをまだ知らない方へ：これはMicrosoftのAIアプリケーションとエージェントを大規模に構築・管理するための統合プラットフォームです。モデルアクセス、オーケストレーション、評価、デプロイ — すべてが一か所に。

セットアップ

セットアップは驚くほどシンプルです：

Foundryエージェントで Add Tools > Catalog に移動
“Azure DevOps"を検索
Azure DevOps MCP Server（preview）を選択して Create をクリック
組織名を入力して接続

以上です。エージェントがAzure DevOpsツールにアクセスできるようになりました。

エージェントがアクセスできるものを制御する

ここが評価できるポイントです：オール・オア・ナッシングのアプローチに縛られません。エージェントに利用可能なツールを指定できます。ワークアイテムの読み取りだけを許可してパイプラインには触れさせたくない場合、そのように設定できます。最小権限の原則を、AIエージェントに適用するわけです。

これはエンタープライズシナリオで重要です。誰かが「リリースを手伝って」と頼んだだけで、エージェントが誤ってデプロイパイプラインを起動するのは避けたいですよね。

.NETチームにとってなぜ興味深いのか

実践的に何が可能になるか考えてみてください：

スプリント計画アシスタント — ワークアイテムを取得し、ベロシティデータを分析し、スプリントキャパシティを提案できるエージェント
コードレビューボット — リポジトリやリンクされたワークアイテムを実際に読めるため、PRのコンテキストを理解するエージェント
インシデント対応 — ワークアイテムを作成し、最近のデプロイを照会し、バグと最近の変更を相関させるエージェント
開発者オンボーディング — 「何に取り組むべき？」に対して、実際のプロジェクトデータに基づいた本物の回答が得られる

CI/CDパイプラインやプロジェクト管理にすでにAzure DevOpsを使用している.NETチームにとって、これらのシステムと直接やり取りできるAIエージェントは、有用な自動化への大きな一歩です。

MCPの全体像

これはより広いトレンドの一部です：MCPサーバーはAIエージェントが外部世界とやり取りする標準的な方法になりつつあります。GitHub、Azure DevOps、データベース、SaaS APIで見かけるようになり、Foundryはこれらすべての接続が集まるハブになりつつあります。

.NETエコシステムでエージェントを構築しているなら、MCPに注目する価値があります。プロトコルは標準化され、ツールは成熟し、Foundry統合によりサーバー接続を手動で配線することなくアクセスしやすくなっています。

まとめ

FoundryのAzure DevOps MCPサーバーはプレビュー中なので、進化が期待されます。しかし、コアワークフローはしっかりしています：接続し、ツールアクセスを設定し、エージェントにDevOpsデータを操作させる。すでにFoundryエコシステムにいるなら、数クリックで始められます。試してみて、どんなワークフローが構築できるか確認してください。

詳しいセットアップ手順については完全なアナウンスをご覧ください。

Foundry Agent ServiceがGA：.NETエージェント開発者にとって本当に重要なこと

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

正直に言いましょう — AIエージェントのプロトタイプを作るのは簡単な部分です。難しいのはその後のすべて：適切なネットワーク分離で本番に乗せること、実際に意味のある評価を実行すること、コンプライアンス要件に対応すること、そして午前2時にものを壊さないこと。

Foundry Agent ServiceがGAになりました。そしてこのリリースは「その後のすべて」のギャップにレーザーのように集中しています。

Responses APIの上に構築

見出し：次世代のFoundry Agent ServiceはOpenAI Responses APIの上に構築されています。すでにそのワイヤープロトコルで開発しているなら、Foundryへの移行は最小限のコード変更で済みます。得られるもの：エンタープライズセキュリティ、プライベートネットワーキング、Entra RBAC、完全なトレーシング、評価 — 既存のエージェントロジックの上に。

アーキテクチャは意図的にオープンです。一つのモデルプロバイダーや一つのオーケストレーションフレームワークに縛られません。プランニングにDeepSeek、生成にOpenAI、オーケストレーションにLangGraph — ランタイムが一貫性レイヤーを処理します。

from azure.ai.projects import AIProjectClient
from azure.ai.projects.models import PromptAgentDefinition

with (
 DefaultAzureCredential() as credential,
 AIProjectClient(endpoint=os.environ["AZURE_AI_PROJECT_ENDPOINT"],
 credential=credential) as project_client,
 project_client.get_openai_client() as openai_client,
):
 agent = project_client.agents.create_version(
 agent_name="my-enterprise-agent",
 definition=PromptAgentDefinition(
 model=os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"],
 instructions="You are a helpful assistant.",
 ),
 )

 conversation = openai_client.conversations.create()
 response = openai_client.responses.create(
 conversation=conversation.id,
 input="What are best practices for building AI agents?",
 extra_body={
 "agent_reference": {"name": agent.name, "type": "agent_reference"}
 },
 )
 print(response.output_text)

azure-ai-agentsパッケージから来ている場合、エージェントはazure-ai-projectsのAIProjectClientでファーストクラスの操作になりました。スタンドアロンの依存関係を削除し、get_openai_client()でレスポンスを駆動してください。

プライベートネットワーキング：エンタープライズのブロッカー除去

これはエンタープライズ採用のブロックを解除する機能です。FoundryはBYO VNetで完全なエンドツーエンドのプライベートネットワーキングをサポートするようになりました：

パブリックエグレスなし — エージェントのトラフィックはパブリックインターネットに触れない
コンテナ/サブネットインジェクション — ローカル通信のためにネットワークに注入
ツール接続性も含む — MCPサーバー、Azure AI Search、Fabricデータエージェントすべてがプライベートパスで動作

最後のポイントが重要です。プライベートのままなのは推論呼び出しだけではありません — すべてのツール呼び出しと検索コールもネットワーク境界内にとどまります。外部ルーティングを禁止するデータ分類ポリシーの下で運用しているチームにとって、これが欠けていたものです。

MCP認証を正しく

MCPサーバー接続は認証パターンの全スペクトルをサポートするようになりました：

認証方法	使用タイミング
キーベース	組織全体の内部ツール向けシンプルな共有アクセス
Entra Agent Identity	サービス間；エージェントがそれ自体として認証
Entra Managed Identity	プロジェクト単位の分離；クレデンシャル管理不要
OAuth Identity Passthrough	ユーザー委任アクセス；エージェントがユーザーに代わって行動

OAuth Identity Passthroughが興味深い。ユーザーがエージェントに個人データへのアクセスを許可する必要がある場合 — OneDrive、Salesforce org、ユーザースコープのSaaS API — エージェントは標準のOAuthフローでユーザーに代わって行動します。全員のふりをする共有システムIDはありません。

Voice Live：配管なしの音声対音声

エージェントに音声を追加するには、STT、LLM、TTSを組み合わせる必要がありました — 3つのサービス、3つのレイテンシホップ、3つの課金サーフェス、すべて手動で同期。Voice Liveはこれを単一のマネージドAPIに凝縮します：

セマンティック音声アクティビティとターンエンド検出（沈黙だけでなく意味を理解）
サーバーサイドのノイズ抑制とエコーキャンセル
割り込みサポート（ユーザーが応答中に割り込める）

音声インタラクションはテキストと同じエージェントランタイムを通過します。同じ評価者、同じトレース、同じコスト可視性。カスタマーサポート、フィールドサービス、アクセシビリティシナリオで、以前はカスタムオーディオパイプラインが必要だったものを置き換えます。

評価：チェックボックスから継続的モニタリングへ

ここでFoundryが本番品質について本気になります。評価システムには3つのレイヤーがあります：

組み込み評価者 — 一貫性、関連性、根拠性、検索品質、安全性。データセットまたはライブトラフィックに接続してスコアを取得。
カスタム評価者 — 独自のビジネスロジック、トーン標準、ドメイン固有のコンプライアンスルールをエンコード。
継続的評価 — Foundryがライブ本番トラフィックをサンプリングし、評価者スイートを実行し、ダッシュボードに結果を表示。根拠性が低下したりセキュリティ閾値を超えた場合のAzure Monitorアラートを設定。

すべてがAzure Monitor Application Insightsに公開されます。エージェント品質、インフラ健全性、コスト、アプリテレメトリ — すべて一か所に。

eval_object = openai_client.evals.create(
 name="Agent Quality Evaluation",
 data_source_config=DataSourceConfigCustom(
 type="custom",
 item_schema={
 "type": "object",
 "properties": {"query": {"type": "string"}},
 "required": ["query"],
 },
 include_sample_schema=True,
 ),
 testing_criteria=[
 {
 "type": "azure_ai_evaluator",
 "name": "fluency",
 "evaluator_name": "builtin.fluency",
 "initialization_parameters": {
 "deployment_name": os.environ["AZURE_AI_MODEL_DEPLOYMENT_NAME"]
 },
 "data_mapping": {
 "query": "{{item.query}}",
 "response": "{{sample.output_text}}",
 },
 },
 ],
)

ホステッドエージェント向け6つの新リージョン

ホステッドエージェントがEast US、North Central US、Sweden Central、Southeast Asia、Japan Eastなどで利用可能になりました。これはデータレジデンシー要件と、エージェントがデータソースの近くで実行される場合のレイテンシ圧縮に重要です。

.NET開発者にとってなぜ重要か

GAアナウンスのコードサンプルはPythonファーストですが、基盤となるインフラストラクチャは言語に依存しません — そしてazure-ai-projectsの.NET SDKも同じパターンに従います。Responses API、評価フレームワーク、プライベートネットワーキング、MCP認証 — これらすべてが.NETから利用可能です。

AIエージェントが「かっこいいデモ」から「実際に仕事で出荷できる」に変わるのを待っていたなら、このGAリリースがそのシグナルです。プライベートネットワーキング、適切な認証、継続的評価、本番モニタリングが欠けていたピースです。

まとめ

Foundry Agent Serviceは今すぐ利用可能です。SDKをインストールし、ポータルを開いて構築を始めましょう。クイックスタートガイドで数分でゼロから動くエージェントに到達できます。

すべてのコードサンプルを含む完全な技術的ディープダイブはGAアナウンスメントをご覧ください。

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リファレンスとその他のより例については完全なドキュメントをご覧ください。

VS Code 1.112：.NET開発者が本当に注目すべきこと

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

VS Code 1.112がリリースされました。正直に言うと、.NETの世界で日々過ごしているなら、このリリースは一味違います。公式リリースノートには多くの内容がありますが、スクロールの手間を省いて、私たちにとって本当に重要なことに焦点を当てましょう。

Copilot CLIがずっと便利になった

今回のリリースの大きなテーマはエージェントの自律性 — Copilotにもっと自由にやらせて、あなたが一つ一つのステップを見守る必要をなくすことです。

メッセージのステアリングとキューイング

Copilot CLIがタスクの途中で、何か言い忘れたことに気づく瞬間を知っていますか？以前は待つしかありませんでした。今はリクエストがまだ実行中でもメッセージを送れます — 現在のレスポンスを方向付けるか、フォローアップの指示をキューに入れるかのどちらかです。

dotnetのスキャフォールディングの長いタスクで、Copilotがプロジェクトをセットアップしているのを見ながら「あ、待って、MassTransitも必要だった」と思う時に、これは最高です。

パーミッションレベル

これが一番ワクワクするものです。Copilot CLIセッションが3つのパーミッションレベルをサポートするようになりました：

デフォルトパーミッション — ツールが実行前に確認を求める通常のフロー
承認バイパス — すべてを自動承認し、エラー時にリトライ
オートパイロット — 完全に自律：ツールを承認し、自分の質問に答え、タスクが完了するまで続行

ASP.NET Core APIをEntity Framework、マイグレーション、Dockerセットアップで新規作成するなら — オートパイロットモードは欲しいものを説明してコーヒーを取りに行くだけ。なんとかしてくれます。

chat.autopilot.enabled設定でオートパイロットを有効にできます。

デリゲーション前の変更プレビュー

Copilot CLIにタスクをデリゲートすると、ワークツリーが作成されます。以前は、コミットしていない変更がある場合、ソースコントロールを確認して何が影響されるかを見る必要がありました。今はチャットビューで保留中の変更がすぐそこに表示され、コピー、移動、無視を決められます。

小さなことですが、「待って、何をステージしてたっけ？」というモーメントから救ってくれます。

VS Codeを離れずにWebアプリをデバッグ

統合ブラウザがフルデバッグをサポートするようになりました。ブレークポイントの設定、コードのステップスルー、変数の検査 — すべてVS Code内で。Edge DevToolsに切り替える必要はもうありません。

新しいeditor-browserデバッグタイプがあり、既存のmsedgeやchromeのランチ設定がある場合、移行はlaunch.jsonのtypeフィールドを変更するだけです：

{
 "type": "editor-browser",
 "request": "launch",
 "name": "Debug Blazor App",
 "url": "https://localhost:5001"
}

Blazor開発者にとって、これはゲームチェンジャーです。すでにターミナルでdotnet watchを実行しています — デバッグも同じウィンドウに留まります。

ブラウザには独立したズームレベル（やっと）、適切な右クリックコンテキストメニュー、Webサイトごとにズームが記憶される機能も追加されました。

MCPサーバーのサンドボックス

これは思っている以上に重要です。MCPサーバーを使っている場合 — Azureリソースやデータベースクエリ用にカスタムのものを設定しているかもしれません — これまでVS Codeプロセスと同じ権限で実行されていました。つまり、ファイルシステム、ネットワーク、すべてへのフルアクセスです。

今はサンドボックス化できます。mcp.jsonで：

{
 "servers": {
 "my-azure-tools": {
 "command": "node",
 "args": ["./mcp-server.js"],
 "sandboxEnabled": true
 }
 }
}

サンドボックス化されたサーバーが持っていないものへのアクセスが必要な場合、VS Codeが権限の付与を促します。「誰も変なことをしないことを祈る」アプローチよりずっと良いです。

注意： サンドボックスは現在macOSとLinuxで利用可能です。Windowsサポートは準備中 — WSLのようなリモートシナリオは動作します。

モノレポのカスタマイゼーション発見

モノレポで作業している場合（正直に言うと、多くのエンタープライズ.NETソリューションはモノレポになります）、これは本当の痛みのポイントを解決します。

以前は、リポジトリのサブフォルダを開いた場合、リポジトリルートにあるcopilot-instructions.md、AGENTS.md、カスタムスキルをVS Codeが見つけませんでした。chat.useCustomizationsInParentRepositories設定により、.gitルートまで遡ってすべてを発見するようになりました。

これはチームがエージェントの指示、プロンプトファイル、カスタムツールをモノレポ内のすべてのプロジェクト間で共有できることを意味します。全員がルートフォルダを開く必要はありません。

エージェントデバッグ用の/troubleshoot

カスタム指示やスキルを設定して、なぜ検出されないか不思議に思ったことはありますか？新しい/troubleshootスキルはエージェントのデバッグログを読んで何が起きたかを教えてくれます — どのツールが使われたかスキップされたか、なぜ指示がロードされなかったか、何が遅い応答を引き起こしているか。

次の設定で有効にします：

{
 "github.copilot.chat.agentDebugLog.enabled": true,
 "github.copilot.chat.agentDebugLog.fileLogging.enabled": true
}

チャットで/troubleshoot why is my custom skill not loading?と入力するだけです。

これらのデバッグログのエクスポートとインポートもできるようになり、何かが期待通りに動作しない場合にチームと共有するのに最適です。

画像とバイナリファイルのサポート

エージェントがディスクから画像ファイルとバイナリファイルをネイティブに読めるようになりました。バイナリファイルはhexdump形式で表示され、画像出力（統合ブラウザからのスクリーンショットなど）はカルーセルビューに表示されます。

.NET開発者の場合：UIバグのスクリーンショットをチャットに貼り付けてエージェントに何が問題かを理解させたり、Blazorコンポーネントのレンダリング出力を分析させたりできます。

自動シンボル参照

小さなクオリティオブライフの改善：シンボル名（クラス、メソッドなど）をコピーしてチャットに貼り付けると、VS Codeが自動的に#sym:Name参照に変換するようになりました。手動で追加することなく、エージェントにそのシンボルの完全なコンテキストを提供します。

プレーンテキストが欲しい場合はCtrl+Shift+Vを使用してください。

プラグインの有効/無効切り替え

以前はMCPサーバーやプラグインを無効にするには、アンインストールする必要がありました。今はオン/オフを切り替えられます — グローバルにもワークスペースごとにも。拡張機能ビューまたはカスタマイゼーションビューで右クリックするだけです。

npmとpypiのプラグインも自動更新できるようになりましたが、更新はマシン上で新しいコードを実行することを意味するので、まず承認を求めます。

まとめ

VS Code 1.112は明らかにエージェント体験を強力に推進しています — より多くの自律性、より良いデバッグ、より厳密なセキュリティ。.NET開発者にとって、統合ブラウザデバッグとCopilot CLIの改善が際立った機能です。

.NETプロジェクトでCopilot CLIのフルセッションをオートパイロットモードで試したことがないなら、このリリースが始めるのに良いタイミングです。パーミッションを設定して、あとはお任せしましょう。

VS Code 1.112をダウンロードするか、VS Code内からヘルプ > 更新の確認で更新してください。

ラップトップから本番へ：2つのコマンドでAIエージェントをMicrosoft Foundryにデプロイ

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

「自分のマシンでは動く」と「デプロイされてトラフィックを処理している」の間のギャップを知っていますか？AIエージェントにとって、そのギャップは痛いほど広かった。リソースのプロビジョニング、モデルのデプロイ、IDの設定、モニタリングの構築 — これら全ては、誰かが実際にエージェントを呼び出せるようになる前の話です。

Azure Developer CLIがこれを2つのコマンドで済む話にしました。

新しい`azd ai agent`ワークフロー

実際にどんな感じか見せましょう。AIエージェントプロジェクトがあるとします — ホテルのコンシェルジュエージェントとしましょう。ローカルで動いています。Microsoft Foundry上で実行したい。

azd ai agent init
azd up

以上です。2つのコマンド。azd ai agent initがリポジトリにInfrastructure as Codeを生成し、azd upがAzure上で全てをプロビジョニングしてエージェントを公開します。Foundryポータルでエージェントへの直接リンクが得られます。

裏側で何が起きているか

initコマンドはリポジトリに実際の、検査可能なBicepテンプレートを生成します：

Foundry Resource（トップレベルコンテナ）
Foundry Project（エージェントが存在する場所）
モデルデプロイメント設定（GPT-4oなど）
適切なRBACロール割り当てを持つマネージドID
サービスマップ用のazure.yaml
エージェントメタデータと環境変数を持つagent.yaml

重要なポイント：これは全てあなたのものです。リポジトリ内のバージョン管理されたBicepです。検査し、カスタマイズし、エージェントコードと一緒にコミットできます。魔法のブラックボックスはありません。

開発の内部ループ

本当に気に入っているのはローカル開発の体験です。エージェントのロジックを反復しているとき、プロンプトを変更するたびに再デプロイしたくないですよね：

azd ai agent run

これでエージェントをローカルで起動します。azd ai agent invokeと組み合わせてテストプロンプトを送信すると、タイトなフィードバックループが得られます。コード編集、再起動、呼び出し、繰り返し。

invokeコマンドはルーティングも賢く — ローカルエージェントが実行中なら自動的にそちらをターゲットにします。実行中でなければリモートエンドポイントにアクセスします。

リアルタイムモニタリング

これが私を納得させた機能です。エージェントがデプロイされたら：

azd ai agent monitor --follow

エージェントを通過する全てのリクエストとレスポンスがリアルタイムでターミナルにストリームされます。本番環境の問題デバッグには計り知れない価値があります。Log Analyticsを掘り返す必要なし、メトリクス集計を待つ必要なし — 今何が起きているかが見えます。

コマンドの完全セット

クイックリファレンスはこちら：

コマンド	機能
`azd ai agent init`	IaCでFoundryエージェントプロジェクトをスキャフォールド
`azd up`	Azureリソースをプロビジョニングしてエージェントをデプロイ
`azd ai agent invoke`	リモートまたはローカルエージェントにプロンプトを送信
`azd ai agent run`	開発用にエージェントをローカルで実行
`azd ai agent monitor`	公開エージェントからリアルタイムログをストリーム
`azd ai agent show`	エージェントの健全性とステータスを確認
`azd down`	全てのAzureリソースをクリーンアップ

.NET開発者にとってなぜ重要か

アナウンスのサンプルはPythonベースですが、インフラストラクチャの話は言語に依存しません。あなたの.NETエージェントも同じBicepスキャフォールディング、同じマネージドID設定、同じモニタリングパイプラインを受け取ります。そして、すでに.NET Aspireアプリやazureデプロイメントにazdを使っているなら、既存のワークフローにそのまま組み込めます。

AIエージェントのデプロイメントギャップはエコシステムで最大の摩擦ポイントの一つでした。動くプロトタイプから適切なID、ネットワーキング、モニタリングを備えた本番エンドポイントへの移行に1週間のDevOps作業は必要ないはずです。今は2つのコマンドと数分で済みます。

まとめ

azd ai agentは今すぐ利用可能です。インフラストラクチャ設定が大変そうだからとAIエージェントのデプロイを先延ばしにしていたなら、試してみてください。フロントエンドチャットアプリ統合を含む完全なステップバイステップガイドは完全なウォークスルーをご覧ください。

Ai | The .NET Blog

NL2SQLはエージェント時代のSQLインジェクションだ

デモで誰も話さない問題

SQL MCP Serverが実際に解決すること

正しい質問

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つの業界シナリオ

まとめ

Foundry Local 1.1: リアルタイム文字起こし、Embeddings、Responses API

ライブ音声文字起こし

テキスト Embeddings

Responses API

パッケージサイズの改善

なぜこれが重要か

Cosmos DB Shell はパブリック プレビューに — そして MCP サーバーが内蔵されている

他のデータベース CLI との違い

オープン ソースの基盤が重要

簡単になる 3 つのシナリオ

始め方

Azure SQL がエンベディングを生成できるようになりました — 純粋な T-SQL で、アプリ層不要

何をするか

完全なワークフロー

サポートされる API フォーマットとオプション

.NET アプリケーションで何が可能になるか

まとめ

あなたの AI エージェントにはアイデンティティの問題があります（そしてこれがそれを解決するテンプレートです）

核心的な問題: 認証 ≠ 認可

トークンチェーンの仕組み

テンプレートがデプロイするもの

借りる価値のある設計原則

まとめ

Aspire 13.3: Kubernetes サポート、ブラウザログ、Aspireify スキル

Aspireify: エージェント支援のオンボーディング

ファーストクラスの Kubernetes と AKS デプロイ

ダッシュボードのブラウザログ

構造化されたコマンド結果

まとめ

SDD Conference 2026

トピック

スピーカー

チケットと情報

.NETのComposable StackでAI搭載カンファレンスアプリを構築する

ConferencePulseの機能

Microsoft.Extensions.AI：すべてのための1つの抽象化

DataIngestionパイプライン

VectorData：プロバイダーに依存しない検索

MCP：ツールとしてのセッションコンテンツ

Agent Framework：並列マルチエージェントサマリー

設計原則

Microsoft Agent Framework パート3：ツールからワークフローへ — ビルディングブロックがカチッとはまる

エージェントとは何か（チャットボットとの違い）

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

Cosmos DB Shell はパブリックプレビューに — そして MCP サーバーが内蔵されている

オープンソースの基盤が重要