2026年4月24日に更新されたMicrosoft公式ドキュメントでは、Microsoft Agent FrameworkからMicrosoft Foundryを使う際の構成がより明確になりました。結論から言うと、今回押さえるべきポイントは、直接推論で素早く作るか、Foundry Agent Serviceで管理されたエージェントを使うかを明確に選べるようになったことです。
IT管理者にとっては、認証方式、エンドポイント、ツール利用、バージョン管理の整理が重要です。プロダクトオーナーにとっては、PoC向けの柔軟な構成と、本番運用向けのガバナンス重視構成を切り分けやすくなった点が大きな意味を持ちます。Microsoft ecosystem全体でAIエージェント活用を進める企業は、今回のMicrosoft Foundry更新を「開発手法の変更」ではなく、エージェント運用設計を見直すタイミングとして捉えるべきです。
Microsoft ecosystemの最新動向: Microsoft Foundryで何が変わったか
Microsoft Learnの「Microsoft Foundry」ページは、2026年4月24日に更新され、Microsoft Agent FrameworkがMicrosoft Foundryのプロジェクトエンドポイントを使った直接的なモデル推論と、Foundry Agent Service上のサービス管理エージェントの両方をサポートすることを明示しています。(Microsoft Learn)
この更新で重要なのは、単に「Microsoft Foundryに対応した」という話ではありません。アプリケーション側でエージェント定義を持つ構成と、Foundry側で定義・管理・バージョン化されたエージェントを使う構成が、実務上の選択肢として整理されたことです。
| 観点 | 更新ポイント | 実務での意味 |
|---|---|---|
| エージェント構成 | 直接推論とサービス管理エージェントを使い分け可能 | PoCと本番運用で設計を分けやすい |
| .NET | AIProjectClient.AsAIAgent(...)でFoundry連携 | C#アプリからFoundryエージェントを扱いやすい |
| Python | Foundry関連クライアントがagent_framework.foundryに集約 | 依存関係とimportの整理が必要 |
| ツール管理 | Foundry Toolboxesでツール構成を再利用可能 | 複数エージェントでツール設定を共通化しやすい |
| 運用 | Foundry Agentは定義・ツール・指示を厳格に管理 | 変更管理、監査、ロールバック設計が重要 |
Microsoft ecosystemの読者がまず確認すべきなのは、自社のAIエージェントが「アプリケーションコード主導」なのか、「Foundry側で管理される業務資産」なのかです。この判断によって、使うクライアント、認証、デプロイ、運用ルールが変わります。
直接推論とサービス管理エージェントの違い
今回のMicrosoft Foundry更新では、主に2つの利用パターンが示されています。1つはResponses Agentによる直接推論、もう1つはFoundry Agent Serviceで管理されるバージョン付きエージェントです。公式ドキュメントでは、Responses AgentはChatClientAgent、Foundry AgentはFoundryAgentとして整理されています。(Microsoft Learn)
| 利用パターン | 代表的な型・クライアント | 向いている用途 | 注意点 |
|---|---|---|---|
| Responses Agent | .NET: ChatClientAgent / Python: FoundryChatClient | アプリ側でモデル、指示、ツールを柔軟に指定したい場合 | エージェント定義の管理責任はアプリ側に寄る |
| Foundry Agent | .NET: FoundryAgent / Python: FoundryAgent | FoundryポータルやAPIで定義済みのエージェントを使いたい場合 | 実行時に指示やツールを自由に変更する設計には向かない |
直接推論は、開発チームが素早く試す場面に向いています。たとえば、社内FAQボットのプロトタイプを作る、営業支援アプリに一時的な要約機能を組み込む、特定画面だけで使う軽量エージェントを作る、といったケースです。
一方、Foundry Agentは、業務部門とIT部門が共同で管理する本番向けエージェントに向いています。たとえば、カスタマーサポート用エージェント、人事ポリシー確認エージェント、社内規程検索エージェントなど、回答品質やツール権限を継続的に管理したい用途です。
特に注意したいのは、Foundry Agentでは作成時に設定されたツールや指示が厳格に扱われ、実行時にツールや指示を変更することはサポートされていない点です。(Microsoft Learn)
つまり、「本番ではFoundry側で定義を固定し、アプリ側では呼び出すだけにする」という設計が基本になります。
.NETでの変更ポイント
.NETでは、Microsoft Foundry連携に必要なパッケージとしてAzure.IdentityとMicrosoft.Agents.AI.Foundryが示されています。公式ドキュメント上では、Microsoft.Agents.AI.Foundryは--prerelease付きでインストールする例が掲載されています。(Microsoft Learn)
dotnet add package Azure.Identity
dotnet add package Microsoft.Agents.AI.Foundry --prerelease直接推論では、AIProjectClientにFoundryのプロジェクトエンドポイントと資格情報を渡し、AsAIAgent(...)でモデル名、エージェント名、指示を指定します。
using Azure.AI.Projects;
using Azure.Identity;
using Microsoft.Agents.AI;
AIAgent agent = new AIProjectClient(
new Uri("<your-foundry-project-endpoint>"),
new ManagedIdentityCredential())
.AsAIAgent(
model: "gpt-4o-mini",
name: "SupportAgent",
instructions: "You answer internal support questions clearly.");
Console.WriteLine(await agent.RunAsync("VPNに接続できない場合の確認手順を教えてください。"));開発中はDefaultAzureCredentialが便利ですが、本番環境では意図しない資格情報探索やフォールバックによるリスクを避けるため、ManagedIdentityCredentialなど具体的な資格情報を検討するよう公式ドキュメントでも注意されています。(Microsoft Learn)
IT管理者は、サンプルコードをそのまま本番に持ち込むのではなく、次の観点で確認する必要があります。
| 確認項目 | 実務上のチェックポイント |
|---|---|
| 認証方式 | 本番はManaged Identityなど明示的な資格情報を使う |
| エンドポイント | FoundryプロジェクトエンドポイントとAzure OpenAI単体エンドポイントを混同しない |
| 権限 | エージェント作成、実行、ツール利用に必要なロールを分ける |
| ログ | 誰が、どのエージェントを、どのバージョンで実行したか追えるようにする |
| 変更管理 | モデル、指示、ツール変更をリリース管理の対象にする |
Pythonではagent_framework.foundryへの集約が重要
Pythonでは、Foundry関連のクライアントがagent_framework.foundry配下に整理されています。公式ドキュメントでは、クラウドのFoundry連携にagent-framework-foundry、ローカル実行にagent-framework-foundry-localを使う形が示されています。(Microsoft Learn)
pip install agent-framework-foundry
pip install azure-identity直接推論を使う場合は、FoundryChatClientを標準のAgentに渡します。
from agent_framework import Agent
from agent_framework.foundry import FoundryChatClient
from azure.identity import AzureCliCredential
agent = Agent(
client=FoundryChatClient(
project_endpoint="https://your-project.services.ai.azure.com",
model="gpt-4o-mini",
credential=AzureCliCredential(),
),
name="FoundrySupportAgent",
instructions="You help users troubleshoot Microsoft 365 issues.",
)サービス管理エージェントに接続する場合は、FoundryAgentを使います。Prompt Agentではバージョンを指定し、Hosted Agentではバージョンを省略できるケースが示されています。(Microsoft Learn)
Pythonプロジェクトをすでに運用している場合は、特にimportと依存関係の棚卸しが必要です。MicrosoftのPython 2026 Significant Changes Guideでは、Foundryのチャット、サービス管理エージェント、メモリ、埋め込みはagent-framework-foundryをインストールし、agent_framework.foundry名前空間を使う方針が示されています。(Microsoft Learn)
| 旧来の見直し対象 | 新しい確認ポイント |
|---|---|
agent_framework.azureに依存したimport | agent_framework.foundryへ移行できるか確認 |
| Azure AI系の埋め込みクライアント | FoundryEmbeddingClientを使う構成に整理 |
| 依存パッケージの暗黙利用 | agent-framework-foundryを明示的にrequirementsへ追加 |
| Azure OpenAI単体利用 | FoundryではなくOpenAI provider側を使うべきか確認 |
プロダクトオーナーの視点では、この整理により「Microsoft Foundryを中核にする機能」と「Azure OpenAIやOpenAI APIとして独立して扱う機能」を分けやすくなります。将来的な保守を考えると、接続先とクライアントの対応関係を設計書に残しておくべきです。
Foundry Toolboxesはツール管理の実務に効く
今回のドキュメントで注目したいのが、Foundry Toolboxesです。Foundry Toolboxは、Microsoft Foundryプロジェクト内で管理される、名前付き・バージョン付きのサーバー側ツール構成のまとまりです。コードインタープリター、ファイル検索、画像生成、MCP、Web検索などのホスト型ツール構成をまとめて管理できます。(Microsoft Learn)
これにより、複数のエージェントで同じツール設定を再利用しやすくなります。たとえば、以下のような使い方が考えられます。
| 活用シーン | Toolbox化するメリット |
|---|---|
| 社内文書検索エージェント | ファイル検索や検索対象の設定を共通化できる |
| 開発支援エージェント | コード実行やMCP連携の設定をチーム単位で管理できる |
| 調査・リサーチエージェント | Web検索、MCP、ファイル検索を組み合わせやすい |
| 部門別エージェント | 同じツール構成を使い、指示だけ部門別に変えられる |
ただし、Toolbox APIsは実験的な位置づけであり、将来変更される可能性があるとされています。また、Agent FrameworkはToolboxの消費を扱い、Toolboxの作成や更新はFoundryポータルまたはazure-ai-projects SDK側で行うと説明されています。(Microsoft Learn)
本番導入では、Toolboxを単なる便利機能として扱わず、以下のように運用設計へ組み込む必要があります。
| 注意点 | 対応策 |
|---|---|
| デフォルトバージョンがサーバー側で変わる可能性 | 本番ではToolboxのバージョンを明示的に固定する |
get_toolbox()はネットワークアクセスを伴う | 高頻度実行ではアプリ側でキャッシュ方針を決める |
| 不要なツールまで渡すと誤呼び出しのリスクがある | select_toolbox_toolsで必要なツールだけに絞る |
| MCP連携では認証設計が複雑になりやすい | Entra ID、接続ID、同意フローを事前に確認する |
公式ドキュメントでは、Toolbox内のツールを絞り込むことで、不要なツール定義をモデルへ送らず、意図しないツール呼び出しを防ぎやすくなる点も説明されています。(Microsoft Learn)
IT管理者が優先して確認すべきポイント
Microsoft Foundryの更新は、開発者だけでなくIT管理者にも影響します。AIエージェントは、モデルを呼び出すだけでなく、社内データ、外部サービス、ファイル検索、MCPサーバー、コード実行などに接続する可能性があるためです。
エンドポイントを混同しない
Microsoft FoundryのPythonクライアントでは、FoundryChatClientとFoundryAgentはプロジェクトエンドポイントを使い、FoundryEmbeddingClientは別のmodels endpointを使うと説明されています。(Microsoft Learn)
実務では、以下を分けて管理するとトラブルを減らせます。
| 種類 | 主な用途 | 管理上の注意 |
|---|---|---|
| Foundry project endpoint | チャット、エージェント実行 | アプリの実行権限と紐づけて管理 |
| Foundry models endpoint | 埋め込み生成など | APIキーやモデル名の管理が必要 |
| Azure OpenAI resource endpoint | Azure OpenAI単体利用 | Foundry providerではなくOpenAI provider側を確認 |
接続先を曖昧にしたまま実装すると、認証エラー、権限不足、誤ったモデル利用、課金確認の難しさにつながります。特にグローバル展開では、リージョン、データ境界、監査ログの確認も必要です。
サードパーティ連携時のデータ境界を確認する
Microsoft Agent Frameworkの公式ドキュメントでは、サードパーティのサーバー、エージェント、コード、非Azure Directモデルなどを使う場合、データの共有、保持、所在地、組織のAzureコンプライアンス境界を確認する責任が利用者側にあると注意されています。(Microsoft Learn)
これは、Microsoft ecosystem内のサービスだけを使う場合でも軽視できません。MCP、外部API、独自ホストのツールをつなぐと、エージェントが扱うデータの流れは複雑になります。
IT管理者は、最低限次の項目を確認しておくべきです。
| 確認項目 | 具体例 |
|---|---|
| 入力データ | 個人情報、顧客情報、社外秘文書が含まれるか |
| ツール呼び出し先 | Microsoft管理サービスか、社外サービスか |
| 認証方式 | Entra ID、Managed Identity、APIキーのどれを使うか |
| ログ保存 | プロンプト、レスポンス、ツール実行結果をどこまで記録するか |
| 承認フロー | 高リスクツールの実行に人の承認を入れるか |
プロダクトオーナー向けの判断基準
プロダクトオーナーは、技術的に使えるかだけでなく、どの構成が製品・業務要件に合うかを判断する必要があります。Microsoft Foundryの更新ポイントを踏まえると、次のように選ぶと分かりやすいです。
| やりたいこと | 推奨される方向性 | 理由 |
|---|---|---|
| まずAI機能を試したい | Responses Agent / FoundryChatClient | アプリ側で指示やツールを素早く変えられる |
| 本番向けの業務エージェントを作りたい | Foundry Agent / FoundryAgent | 定義をFoundry側で管理・バージョン化しやすい |
| 社内文書を検索させたい | File SearchやToolboxを検討 | ナレッジ検索をエージェントに組み込みやすい |
| 複数エージェントで同じツールを使いたい | Foundry Toolboxes | ツール構成の再利用と統制に向く |
| ローカルモデルで検証したい | Foundry Local | Pythonの標準Agent体験でローカル実行できる |
Foundry Localについては、サポートされるMicrosoft Foundryモデルをローカルマシン上で実行しながら、Agent FrameworkのPython Agent体験を使えると説明されています。ただし、.NETでは現在サポートされていない点や、モデルによって機能が異なる点に注意が必要です。(Microsoft Learn)
既存環境で失敗しやすいポイント
Microsoft Foundryの更新内容を既存プロジェクトに適用する際、よく起きる失敗は「サンプルは動いたが、本番運用で詰まる」パターンです。特に次の点は早めに確認してください。
| 失敗しやすいポイント | 起きる問題 | 回避策 |
|---|---|---|
DefaultAzureCredentialを本番でそのまま使う | 意図しない資格情報探索や権限の混乱 | 本番ではManaged Identityなどを明示 |
| Foundry Agentを実行時に自由変更できると思い込む | 指示やツール変更が反映できない | バージョン付き定義として変更管理する |
| Pythonの旧importを残す | アップグレード後にimportエラー | agent_framework.foundryへ整理 |
| Toolboxのバージョンを固定しない | デフォルト変更で挙動が変わる | 本番では明示的にバージョン指定 |
| エンドポイントを混同する | 認証エラーや誤ったサービス利用 | project endpoint、models endpoint、Azure OpenAI endpointを分ける |
| classic agentsの扱いを放置する | 将来的な移行リスク | 新しいMicrosoft Foundry Agents Serviceへの移行計画を立てる |
なお、Microsoft Foundryのclassic agentsについては、Microsoft公式ドキュメントで非推奨となり、2027年3月31日に廃止予定であることが示されています。新しいMicrosoft Foundry Agents Serviceへの移行が推奨されています。(Microsoft Learn)
導入前に作るべきチェックリスト
Microsoft ecosystemでMicrosoft Foundryを使う場合、いきなり実装に入るより、次のチェックリストを埋めてから進めると失敗を減らせます。
| チェック項目 | 確認内容 |
|---|---|
| ユースケース | 要約、検索、問い合わせ対応、業務実行のどれか |
| エージェント方式 | 直接推論か、サービス管理エージェントか |
| 管理主体 | 開発チーム、IT管理部門、業務部門のどこが定義を管理するか |
| 認証 | 開発用と本番用の資格情報を分けているか |
| ツール利用 | ファイル検索、MCP、コード実行などを使うか |
| データ境界 | 入力データが外部サービスへ流れる可能性はないか |
| バージョン管理 | エージェント、Toolbox、モデルを固定・追跡できるか |
| 監査 | 実行ログ、ツール呼び出し、エラーを追跡できるか |
| 移行 | classic agentsや旧Python importが残っていないか |
このチェックリストで重要なのは、エージェントを「チャットUIの部品」として扱わないことです。業務データや外部ツールに接続する時点で、AIエージェントはアプリケーション基盤の一部になります。
今回の更新を受けて次に取るべき行動
今回のMicrosoft Foundry更新は、Microsoft ecosystemでAIエージェントを作るチームにとって、設計方針を整理する良い機会です。
まず、既存または計画中のエージェントを一覧化し、直接推論で十分なものと、Foundry Agent Serviceで管理すべきものに分けてください。次に、Pythonプロジェクトではagent_framework.foundryへの移行状況を確認し、.NETプロジェクトでは本番用の認証方式を見直します。
Toolboxを使う場合は、便利さだけでなく、バージョン固定、不要ツールの除外、MCP認証、キャッシュ方針まで決めておくことが重要です。classic agentsを利用している環境では、2027年3月31日の廃止予定を前提に、新しいMicrosoft Foundry Agents Serviceへの移行計画を早めに作成してください。
Microsoft Foundryは、単体のAI機能ではなく、エージェント、ツール、認証、データ管理をまとめて扱う基盤になりつつあります。PoCでは柔軟性を優先し、本番ではガバナンスと再現性を優先する。この切り分けが、2026年以降のMicrosoft ecosystemにおけるAI活用の成否を左右します。
コメント