Agents | 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?

あなたの 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

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

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

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ネイティブな設計は既に構築しているツールで機能することを意味する。公式発表で詳細を確認しよう。

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 — 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リポジトリで動作するサンプルを確認してください。

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 が対応していることを示しています。「エンタープライズ対応」シグナルを待っていたなら — これです。

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によるオープンモデル推論 — プラットフォームは本格的なワークロードに対応する準備が整っています。

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

VS Code 1.116 — Agentsアプリがキーボードナビゲーションとファイルコンテキスト補完を獲得

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

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

VS Code 1.116は2026年4月のリリースで、最近のいくつかのアップデートよりは軽めですが、変更点は的を絞った意味のあるものです — 特にAgentsアプリを日常的に使っている方にとっては。

公式リリースノートに基づいて、何が追加されたか見ていきましょう。

Agentsアプリの改善

Agentsアプリは、日常のワークフローに本当の違いをもたらすユーザビリティの磨き上げで成熟を続けています：

専用キーバインド — Changesビュー、Changes内のファイルツリー、Chat カスタマイズビューに専用のコマンドとキーボードショートカットでフォーカスできるようになりました。Agentsアプリ内をクリックして回っていた方には、これで完全にキーボード駆動のワークフローが実現します。

アクセシビリティヘルプダイアログ — チャット入力ボックスでAlt+F1を押すと、利用可能なコマンドとキーバインドを表示するアクセシビリティヘルプダイアログが開くようになりました。スクリーンリーダーユーザーはアナウンスの詳細度も制御できます。良いアクセシビリティはすべての人に利益をもたらします。

ファイルコンテキスト補完 — Agentsアプリのチャットで#を入力すると、現在のワークスペースにスコープされたファイルコンテキスト補完がトリガーされます。これはすべてのインタラクションを加速するあの小さなクオリティ・オブ・ライフの改善の一つです — コードを参照する際にフルファイルパスを入力する必要はもうありません。

CSS `@import`リンク解決

フロントエンド開発者にうれしいニュース：VS Codeがnode_modulesパスを使用するCSS @import参照を解決するようになりました。バンドラーを使用している場合、@import "some-module/style.css"のようなインポートをCtrl+クリックで辿れます。小さいですがCSSワークフローの摩擦点を解消します。

まとめ

VS Code 1.116は洗練がテーマです — Agentsアプリをより操作しやすく、よりアクセシブルに、よりキーボードフレンドリーにすること。Agentsアプリでかなりの時間を過ごしているなら（そして多くの方がそうだと思いますが）、これらの変更は積み重なっていきます。

完全なリストはフルリリースノートをご確認ください。

エージェンティックなプラットフォームエンジニアリングが現実になりつつある — Git-APEがその方法を示す

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

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

プラットフォームエンジニアリングは、カンファレンスでは素晴らしく聞こえるけど、実際には「内部ポータルとTerraformラッパーを作りました」という意味になりがちな用語の一つです。本当の約束 — 安全で、ガバナンスが効いていて、高速なセルフサービスインフラ — はいつもあと数歩先にありました。

Azureチームがエージェンティックなプラットフォームエンジニアリングシリーズのパート2を公開しました。今回はハンズオンの実装がテーマです。彼らはこれをGit-APEと呼んでいます（はい、頭字語は意図的です）。これはGitHub CopilotエージェントとAzure MCPサーバーを使って、自然言語のリクエストを検証済みでデプロイされたインフラに変換するオープンソースプロジェクトです。

Git-APEが実際にやること

コアアイデア：開発者がTerraformモジュールを学んだり、ポータルUIをナビゲートしたり、プラットフォームチームにチケットを切る代わりに、Copilotエージェントに話しかけます。エージェントが意図を解釈し、Infrastructure-as-Codeを生成し、ポリシーに対して検証し、デプロイします — すべてVS Code内で。

セットアップはこちら：

git clone https://github.com/Azure/git-ape
cd git-ape

VS Codeでワークスペースを開くと、エージェント設定ファイルがGitHub Copilotによって自動検出されます。エージェントと直接やり取りします：

@git-ape deploy a function app with storage in West Europe

エージェントは内部でAzure MCPサーバーを使ってAzureサービスとやり取りします。VS Code設定のMCP構成で特定の機能を有効にします：

{
 "azureMcp.serverMode": "namespace",
 "azureMcp.enabledServices": [
 "deploy", "bestpractices", "group",
 "subscription", "functionapp", "storage",
 "sql", "monitor"
 ],
 "azureMcp.readOnly": false
}

なぜこれが重要か

Azureで構築している私たちにとって、これはプラットフォームエンジニアリングの議論を「ポータルをどう構築するか」から「ガードレールをどうAPIとして記述するか」にシフトさせます。プラットフォームのインターフェースがAIエージェントになると、制約とポリシーの品質がプロダクトになります。

パート1のブログは理論を提示しました：よく記述されたAPI、コントロールスキーマ、明示的なガードレールがプラットフォームをエージェント対応にします。パート2は実際のツールを提供することでそれが機能することを証明しています。エージェントはリソースを盲目的に生成するのではなく、ベストプラクティスに対して検証し、命名規則を尊重し、組織のポリシーを適用します。

クリーンアップも同様に簡単です：

@git-ape destroy my-resource-group

私の見解

正直に言うと、これは特定のツールよりもパターンについてです。Git-APE自体はデモ/リファレンスアーキテクチャです。しかし根底にあるアイデア — プラットフォームへのインターフェースとしてのエージェント、プロトコルとしてのMCP、ホストとしてのGitHub Copilot — これがエンタープライズの開発者体験が向かう方向です。

内部ツールをエージェントフレンドリーにする方法を探しているプラットフォームチームなら、これ以上の出発点はありません。そして.NET開発者として自分の世界とどう繋がるか気になるなら：Azure MCPサーバーとGitHub Copilotエージェントはどんなのワークロードでも動作します。ASP.NET Core API、.NET Aspireスタック、コンテナ化されたマイクロサービス — すべてがエージェンティックなデプロイフローのターゲットになり得ます。

まとめ

Git-APEは、エージェンティックなプラットフォームエンジニアリングの実践における初期だが具体的な姿です。リポジトリをクローンし、デモを試し、プラットフォームのAPIとポリシーがエージェントに安全に使われるためにどうあるべきか考え始めてください。

完全な記事でウォークスルーとデモ動画をご覧ください。

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エージェント — このアップデートは価値があります。

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

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アナウンスメントをご覧ください。

Agents | The .NET Blog

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

デモで誰も話さない問題

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

正しい質問

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

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

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

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

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

まとめ

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

CodeActとは？

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

最小セットアップ

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

今すぐ試す

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

2つの基本パターン

Agent Frameworkによる抽象化

プロバイダー早見表

選び方

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

Toolboxとは

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

実践的な例

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

今なぜ重要か

まとめ

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

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

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

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

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

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

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

まとめ

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

6つのオプション早見表

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

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

組み込みの会話管理

私の判断フレームワーク

まとめ

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

Azure MCP Server とは？

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

セキュリティの強化

どこで使用できますか？

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

はじめに

まとめ

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

Foundry Agent Serviceが本番環境対応に

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

SDKがついに安定版に

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

その他のハイライト

まとめ

VS Code 1.116 — Agentsアプリがキーボードナビゲーションとファイルコンテキスト補完を獲得

Agentsアプリの改善

CSS @importリンク解決

まとめ

エージェンティックなプラットフォームエンジニアリングが現実になりつつある — Git-APEがその方法を示す

Git-APEが実際にやること

なぜこれが重要か

私の見解

まとめ

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

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

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

Container App Jobsとデプロイの改善

DXの改善

まとめ

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

Responses APIの上に構築

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

MCP認証を正しく

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

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

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

CSS `@import`リンク解決