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

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

Microsoft-Foundry | The .NET Blog