Microsoft Foundry / Azure OpenAIでAIエージェントを本番利用するなら、今回の「Agent development lifecycle – Microsoft Foundry」の更新は、単なるドキュメント更新ではなく、開発・公開・監視をどう標準化するかを見直す合図です。結論から言うと、エージェント開発は「プロンプトを作って公開する作業」ではなく、作成、バージョン管理、トレース、評価、公開、監視を継続的に回すライフサイクルとして扱うべきです。Microsoft Learnの該当ページは2026年4月23日に更新され、エージェントを初期作成から本番監視まで扱う流れとして整理しています。(Microsoft Learn)
特にIT管理者、プロダクトオーナー、MicrosoftエコシステムでAI機能を展開する担当者が見るべきポイントは、公開後のIDと権限、バージョン固定、トレースと評価、運用監視です。Azure OpenAIを使ったチャットボット開発の延長で考えると、権限移行やリリース管理でつまずきやすくなります。
Microsoft Foundry / Azure OpenAIの2026年4月更新ポイント
2026年4月23日の更新で最も実務上重要なのは、エージェントを「作る」だけでなく「運用する」前提の流れが明確になったことです。公式ドキュメントでは、エージェントタイプの選択、作成とテスト、ツールとデータの追加、バージョン保存、トレース、品質・安全性評価、公開と統合、監視と改善という8段階のライフサイクルが示されています。(Microsoft Learn)
同日のGitHub上の差分では、publish-agent から agent-applications への名称・リンク整理、TOC上の配置変更、複数ファイルの内部リンク更新が確認できます。つまり「新機能が突然追加された」というより、公開フェーズをAgent Applicationという概念に寄せ、開発から運用への導線を明確にした更新と捉えるのが現実的です。(GitHub)
| 更新ポイント | 実務での意味 | 確認すべき担当者 |
|---|---|---|
| ライフサイクルの明確化 | PoCではなく、本番運用まで含めた設計が必要になる | プロダクトオーナー、開発リーダー |
| Agent Applicationへの導線整理 | 公開後のエンドポイント、ID、権限を個別に管理する必要がある | IT管理者、Azure管理者 |
| バージョン管理の重視 | プロンプト変更やツール追加をリリース単位で扱う必要がある | 開発者、QA担当 |
| トレース・評価・監視の組み込み | 失敗原因、品質低下、コスト増を継続的に確認できる体制が必要 | 運用担当、SRE、セキュリティ担当 |
| IDと権限の見直し | 開発時に動いたツールが公開後に動かない可能性がある | IT管理者、セキュリティ担当 |
エージェント開発は「作成」から「ライフサイクル管理」へ移る
Microsoft Foundryにおけるエージェントは、Foundry model catalogのモデルを中核に、指示、ツール、データ、外部APIとの接続を組み合わせて動作します。公式ドキュメントでは、Foundryポータルまたはコードでエージェントを構築し、トレース、評価、監視を通じて品質と信頼性を改善する流れが示されています。(Microsoft Learn)
これまでAzure OpenAIの活用では、「どのモデルを使うか」「プロンプトをどう書くか」に関心が集まりがちでした。しかしAgent development lifecycleの観点では、モデル選定だけでは不十分です。以下のように、運用品質を支える項目まで最初から設計する必要があります。
| 従来の見方 | ライフサイクル視点での見方 |
|---|---|
| プロンプトを改善する | 変更内容をバージョンとして保存し、比較できるようにする |
| 動作確認して公開する | トレースと評価を通して、失敗パターンと品質劣化を検出する |
| ユーザーに使わせる | エンドポイント、認証方式、RBAC、監視指標を運用する |
| 障害が出たら調査する | 事前にApplication Insightsや評価ルールを準備する |
| 便利なツールを追加する | ツールの認証、権限、リージョン対応、監査性を確認する |
この変化は、IT管理者とプロダクトオーナーにとって大きな意味があります。AIエージェントは、単なるチャットUIではなく、社内データにアクセスし、外部APIを呼び出し、場合によっては業務アクションを実行するアプリケーションだからです。
3種類のエージェントを用途で選ぶ
公式ドキュメントでは、Microsoft Foundryのエージェントタイプとして、Prompt-based、Workflow、Hostedの3種類が整理されています。Prompt-basedはモデル、指示、ツール、自然言語プロンプトで定義する単一エージェント、Workflowは複数アクションや複数エージェントを調整する構成、Hostedはコードで作成したコンテナ化エージェントをFoundry Agent Serviceで運用するプレビュー機能です。(Microsoft Learn)
| エージェントタイプ | 向いている用途 | 判断基準 |
|---|---|---|
| Prompt-based | 社内FAQ、ナレッジ検索、問い合わせ支援、定型業務の補助 | ポータル中心で素早く作り、指示とツール設定で制御したい場合 |
| Workflow | 複数ステップの業務処理、承認フロー、複数エージェントの連携 | 「検索して回答」だけでなく、順序のある処理や役割分担が必要な場合 |
| Hosted | 独自コード、既存フレームワーク、複雑なオーケストレーション | LangGraphなどのフレームワークや独自ロジックを使い、コンテナとして管理したい場合 |
最初の判断では、いきなりHostedを選ぶ必要はありません。業務要件が「社内文書を参照して回答する」「問い合わせ内容を分類する」「簡単なAPIを呼び出す」程度であれば、Prompt-basedから始めるほうが検証は速くなります。一方で、複数の業務システムをまたいだ処理、担当エージェントの分業、独自の状態管理が必要なら、WorkflowやHostedを検討します。
Hosted agentsは柔軟性が高い一方で、プレビュー扱いの要素が含まれるため、本番導入ではサポート条件、SLA、リージョン、セキュリティレビューを別途確認する必要があります。Foundry Agent Service自体はGAとされていますが、Hosted agentsなど一部のサブ機能はパブリックプレビューとして扱われる可能性があります。(Microsoft Learn)
バージョン管理はプロンプト管理ではなくリリース管理として扱う
Microsoft FoundryのAgent development lifecycleで重要なのが、変更をバージョンとして保存する考え方です。公式ドキュメントでは、保存後の各バージョンは不変であり、既存バージョンを変更する場合は新しいバージョンとして保存する必要があると説明されています。また、未保存の変更は実験には使えますが、履歴確認、監視、フル評価には保存が必要です。(Microsoft Learn)
これは、エージェントを「プロンプトのメモ」ではなく「リリース対象のソフトウェア」として扱うべきだという意味です。たとえば、顧客サポート用エージェントで「返金条件の案内」を変更した場合、その変更は単なる文言修正ではありません。誤回答が法務リスクや顧客対応コストにつながる可能性があるため、変更理由、評価結果、公開日、ロールバック先を記録しておくべきです。
| 変更内容 | バージョン保存すべきか | 理由 |
|---|---|---|
| システム指示を変更した | 必須 | 回答方針や制約が変わるため |
| 利用モデルを変更した | 必須 | 応答品質、コスト、レイテンシが変わるため |
| File SearchやMCPなどのツールを追加した | 必須 | 外部データや外部操作の範囲が変わるため |
| ナレッジファイルを差し替えた | 原則必須 | 根拠データが変わり、回答内容に影響するため |
| テスト中の軽微な言い回し修正 | 保存前テストでも可 | ただし本番反映前には保存が必要 |
運用ルールとしては、バージョンごとに「変更目的」「対象ユーザー」「利用ツール」「評価結果」「既知の制約」を残すのが実用的です。特にグローバル展開する組織では、日本語版、英語版、地域別ナレッジを混在させると、どのバージョンがどの市場向けか分からなくなりやすいので、命名規則も先に決めておきます。
公開後はIDと権限が変わる点に注意する
今回の更新で特にIT管理者が注意すべきなのは、公開後のエージェントを開発時の延長で考えないことです。Agent Applicationとして公開すると、エージェントは開発プロジェクト内の資産から、外部利用者が安定したエンドポイント経由で呼び出せる管理対象リソースへ移ります。Agent Applicationには独自の呼び出しURL、認証ポリシー、Entra agent identity、agent blueprintが作成されると説明されています。(Microsoft Learn)
重要なのは、開発時に動作していたツールが公開後もそのまま動くとは限らない点です。公式ドキュメントでは、公開後にエージェントのIDが変わるため、必要なRBAC権限を新しいエージェントIDに再割り当てしないと、ツール呼び出しが認可エラーになる可能性があると説明されています。(Microsoft Learn)
たとえば、開発中のエージェントがAzure Storage上の社内資料を参照できていたとしても、それはプロジェクト側の共有IDに権限があっただけかもしれません。公開後のAgent Applicationが独自IDで動く場合、そのIDにもAzure Storage、Azure AI Search、Key Vault、Microsoft Graphなどへの必要最小限の権限を付与する必要があります。
| 確認項目 | 本番公開前に見るべきポイント |
|---|---|
| エージェントID | 開発時と公開後で使用されるIDが同じか、別か |
| RBAC | 公開後のIDに必要なロールだけが付与されているか |
| ツール接続 | Azure Storage、AI Search、MCP、OpenAPIなどの接続が公開後も認証できるか |
| シークレット | プロンプトやコードに資格情報を埋め込んでいないか |
| 監査 | 誰が、どのエージェントに、どの権限を付与したか追跡できるか |
最小権限の原則は、AIエージェントでは特に重要です。通常のアプリケーションと違い、エージェントはユーザー入力に応じてツール呼び出しを判断します。必要以上の権限を与えると、誤った指示、プロンプトインジェクション、不適切なツール呼び出しが発生した際の影響範囲が大きくなります。
Agent Applicationsと新しいエンドポイントモデルを混同しない
注意したいのは、公開モデルが移行期にある点です。Agent Applicationsの公式ページには、当該ページがレガシー公開体験を説明しており、新しいagent endpoint and publishing experienceへの移行ページを参照するよう注記があります。(Microsoft Learn)
一方、別の公式ドキュメントでは、Microsoft Foundryの各エージェントには作成時点から安定したエンドポイントがあり、アクティブなエージェントバージョン、プロトコル、認証方式を設定して共有する流れが説明されています。デフォルトでは最新バージョンへルーティングされ、安定性が必要な本番環境では特定バージョンに固定することが推奨されています。(Microsoft Learn)
実務では、社内手順書に次の確認を入れてください。
| 確認すること | なぜ重要か |
|---|---|
| 自社環境がAgent Applications前提か、新しいagent endpointモデル前提か | 公開手順、認証、権限、エンドポイント設計が変わるため |
| 本番トラフィックが最新バージョンへ自動追従するか | 予期しない変更が即時反映される可能性があるため |
| TeamsやMicrosoft 365 Copilot連携で必要なプロトコルが有効か | Responses、Activity、Invocationsなどの使い分けが必要なため |
| APIキー認証を前提にしていないか | 公式ドキュメントではEntra IDとAzure RBACによる認可が示されているため |
特にプロダクトオーナーは、「公開済みだから安定している」と考えないほうが安全です。バージョン選択が「常に最新」になっている場合、新しいバージョン作成がそのままユーザー体験に影響する可能性があります。本番環境では、評価済みバージョンにピン留めし、次バージョンをステージングで検証してから切り替える運用が現実的です。
トレースは「なぜその回答になったか」を確認するための基盤
AIエージェントのトラブルシューティングでは、最終回答だけを見ても原因が分かりません。ツールを呼んだのか、どの入力を渡したのか、どの処理で遅延したのか、どの外部APIが失敗したのかを追跡する必要があります。
Microsoft Foundryのトレース機能は、エージェント実行時の入力、出力、ツール使用、リトライ、レイテンシ、コストなどを取得し、複雑なエージェント実行の流れを確認するための仕組みとして説明されています。ただし、トレースはPrompt agentsでは一般提供、Workflow、Hosted、custom agentsではプレビューとされています。(Microsoft Learn)
実務では、以下のようなケースでトレースが役立ちます。
| 問題 | トレースで確認すること |
|---|---|
| 回答が古い | File SearchやWeb searchが呼ばれたか、参照データが想定通りか |
| 回答が遅い | モデル呼び出し、外部API、ツール処理のどこで時間がかかったか |
| 外部APIが動かない | ツール呼び出しの入力、認証、レスポンス、例外を確認する |
| コストが増えた | トークン消費や不要なツール呼び出しが増えていないか |
| 期待と違う処理をした | 指示、ツール選択、ツール出力の利用方法を確認する |
トレースは、障害発生後に慌てて有効化するものではありません。PoC段階から有効化し、正常時の実行パターンを把握しておくと、本番障害時の原因切り分けが速くなります。
評価は「人が読んで良さそう」から脱却するために使う
生成AIの評価でありがちな失敗は、少数のサンプルを担当者が読んで「問題なさそう」と判断してしまうことです。エージェントはツールを呼び出し、複数ステップで判断するため、最終回答だけでなく、途中のツール選択やパラメータの正確性も評価対象になります。
Microsoft FoundryのAgent evaluatorsは、エージェントワークフローに対して品質、安全性、パフォーマンスを体系的に測定する仕組みとして説明されています。評価には、最終成果を確認するSystem evaluationと、ツール呼び出しなどの途中プロセスを確認するProcess evaluationがあります。(Microsoft Learn)
| 評価観点 | 見るべき内容 | 具体例 |
|---|---|---|
| Task Completion | ユーザーの依頼を最後まで完了したか | 「請求書の再発行手順を案内して」への回答が完結しているか |
| Task Adherence | 指示やポリシーを守ったか | 禁止された返金判断を勝手にしていないか |
| Intent Resolution | ユーザー意図を正しく理解したか | 解約相談なのか、料金プラン変更なのかを識別できたか |
| Tool Selection | 適切なツールを選んだか | FAQ検索で足りる場面で外部APIを呼んでいないか |
| Tool Input Accuracy | 正しいパラメータを渡したか | 顧客ID、日付、リージョン、SKUを誤っていないか |
| Tool Output Utilization | ツール結果を正しく使ったか | 検索結果の一部だけを誤解して回答していないか |
本番公開前には、代表的な成功パターンだけでなく、失敗しやすい入力も評価セットに入れてください。たとえば、曖昧な質問、権限のない依頼、個人情報を含む依頼、複数言語の入力、社内ポリシーに抵触しそうな依頼などです。
監視では品質・安全性・コストを同時に見る
公開後のエージェントは、通常のアプリケーションと同じように監視対象です。Microsoft FoundryのAgent Monitoring Dashboardでは、トークン使用量、レイテンシ、成功率、評価結果などを確認でき、Application Insightsに接続されたテレメトリを利用すると説明されています。(Microsoft Learn)
監視で見るべき指標は、単に「動いているか」だけではありません。AIエージェントでは、動いていても品質が落ちる、ツール呼び出しが増えてコストが膨らむ、特定の地域や言語で失敗率が高い、といった問題が起こります。
| 監視指標 | 見る理由 | アクション例 |
|---|---|---|
| トークン使用量 | コスト増や冗長な回答を検出する | システム指示、回答長、RAG対象を見直す |
| レイテンシ | ユーザー体験や業務処理時間に影響する | ツール呼び出し数、モデル、外部APIを見直す |
| Run success rate | 実行失敗やツールエラーを検出する | 認証、API制限、入力形式を確認する |
| 評価スコア | 回答品質や安全性の低下を検出する | 評価に失敗したケースをテストセットへ追加する |
| Red teaming結果 | データ漏えいや不適切操作のリスクを見る | 指示、権限、ツール制限を見直す |
監視設計では、プロダクトオーナーとIT管理者の視点を分けると整理しやすくなります。プロダクトオーナーはタスク完了率、回答品質、ユーザー満足度を見るべきです。IT管理者は認証エラー、権限、レイテンシ、トークン使用量、監査ログを重視します。
ツール追加では「便利さ」より「認証と制御」を先に見る
Microsoft Foundry Agent Serviceのツールは、エージェントにWeb検索、コード実行、ファイル検索、外部API呼び出しなどの能力を追加します。公式ドキュメントでは、built-in toolsとcustom toolsが整理され、MCP、Agent-to-Agent、OpenAPI toolなどの選択肢も示されています。(Microsoft Learn)
ただし、ツールを増やせばエージェントが賢くなるとは限りません。ツールが多すぎると、選択ミス、レイテンシ増加、権限管理の複雑化、コスト増が起こります。業務用エージェントでは、必要なツールを少数に絞り、指示の中で「いつ使うか」「いつ使わないか」を明確にすることが重要です。
| ツール例 | 活用シーン | 注意点 |
|---|---|---|
| File Search | 社内文書、FAQ、製品資料の参照 | 古い文書や重複文書を入れると回答品質が落ちる |
| Web search | 最新情報の取得 | 業務利用では出典確認と利用範囲のルールが必要 |
| Code Interpreter | データ分析、計算、表作成 | 入力データの扱いと実行環境の制約を確認する |
| Function calling | 自社アプリとの連携 | アプリ側で認可、入力検証、エラー処理を行う |
| MCP | 複数ツールの統合、外部サービス連携 | 認証方式、承認フロー、監査ログを確認する |
| OpenAPI tool | HTTP APIの呼び出し | API仕様、レート制限、権限スコープを明確にする |
導入初期は、ツールを足す前に「そのツールがないと完了できない業務か」を確認してください。単に回答を詳しくしたいだけなら、プロンプト改善やナレッジ整理で足りる場合があります。一方、顧客情報の参照、チケット作成、在庫確認など実データや操作が必要な場合は、ツール連携を検討します。
Azure OpenAI利用者が見落としやすいリージョンとクォータ
Microsoft Foundry / Azure OpenAIでエージェントをグローバル展開する場合、リージョンとモデル可用性を必ず確認してください。公式ドキュメントでは、Foundry Agent ServiceはAzure OpenAI Responses APIをサポートするリージョンのFoundryプロジェクトで利用でき、Azure OpenAIモデルが同じリージョンで利用できるとは限らないと説明されています。また、一部ツールもリージョンによって利用可否が異なります。(Microsoft Learn)
グローバル企業では、米国、欧州、日本、アジア太平洋で同じエージェントを展開したくなるケースがあります。しかし、モデル、ツール、データ保管、監査、ネットワーク要件が地域ごとに異なるため、単純な横展開は危険です。
| 確認項目 | 実務上の判断 |
|---|---|
| 対象リージョンでAgent Serviceが使えるか | 利用予定のFoundryプロジェクト単位で確認する |
| 利用モデルがそのリージョンで使えるか | Azure OpenAIモデルとFoundry catalogモデルを分けて確認する |
| ツールがそのリージョンで使えるか | File Search、Code Interpreter、MCPなど個別に見る |
| クォータが足りるか | モデル側のTPM/RPM、Agent Service側の固定制限を分けて見る |
| データ境界に問題がないか | 社内ポリシー、規制、顧客契約と照合する |
特に本番前の負荷試験では、モデルのレート制限だけでなく、ツール呼び出し、メッセージ数、ファイルサイズ、スレッド設計も確認してください。Agent Serviceにはファイル、メッセージ、ツール登録などに関する制限があり、モデル側のクォータとは別に設計する必要があります。(Microsoft Learn)
本番導入前のチェックリスト
Microsoft Foundry / Azure OpenAIのAgent development lifecycleを社内標準に落とし込むなら、以下のチェックリストから始めると実務に移しやすくなります。
| フェーズ | チェック項目 |
|---|---|
| 企画 | 対象業務、利用者、成功指標、禁止事項を定義したか |
| 設計 | Prompt-based、Workflow、Hostedのどれを使うか決めたか |
| データ | 参照する文書、インデックス、外部APIの責任者を決めたか |
| セキュリティ | Entra ID、RBAC、Key Vault、接続情報の管理方法を決めたか |
| 開発 | 変更をバージョンとして保存し、比較できる状態にしたか |
| テスト | 成功例だけでなく、曖昧な依頼、権限外の依頼、多言語入力を試したか |
| 評価 | Task Completion、Tool Selection、Tool Input Accuracyなどを評価したか |
| 公開 | 公開後のID、権限、エンドポイント、認証方式を確認したか |
| 監視 | Application Insights、ダッシュボード、アラート、評価ルールを設定したか |
| 改善 | 監視結果をもとに、次バージョンへ反映する運用を決めたか |
このチェックリストで特に優先すべきなのは、公開前の権限確認と、公開後の監視設計です。多くの失敗は、エージェントそのものの性能よりも、「開発環境では動いたが本番で権限がない」「更新したら意図せず本番に反映された」「品質低下に気づけなかった」といった運用面で起こります。
よくある失敗と回避策
| 失敗しやすいポイント | 起こる問題 | 回避策 |
|---|---|---|
| エージェント名を安易に決める | 作成後に名前を変えられず、運用名とズレる | 命名規則を決めてから作成する |
| 未保存の変更で検証を進める | 履歴、監視、評価に使えず再現できない | 重要な変更は必ずバージョン保存する |
| 最新バージョン自動反映のまま本番運用する | 未評価の変更がユーザーに出る | 本番は評価済みバージョンへピン留めする |
| 開発時の権限で公開後も動くと思い込む | ツール呼び出しが認可エラーになる | 公開後IDに必要最小限のRBACを再付与する |
| ツールを増やしすぎる | 遅延、誤選択、コスト増が起きる | 業務完了に必要なツールだけを設定する |
| 評価を人手レビューだけにする | 品質劣化や回帰に気づきにくい | 評価セットと自動評価を用意する |
| 監視を後回しにする | 本番での失敗原因が追えない | PoC段階からトレースと監視を有効化する |
公式ドキュメントでも、未保存の変更は一時的であること、ツールは保存前に構成が必要なこと、公開後には権限更新が必要なことが、よくある落とし穴として示されています。(Microsoft Learn)
IT管理者とプロダクトオーナーが次にやるべきこと
Microsoft Foundry / Azure OpenAIのAgent development lifecycleを取り入れるうえで、最初にやるべきことは大規模な移行ではありません。まず、既存または予定中のエージェントについて、以下の4点を棚卸ししてください。
| 担当 | 最初に確認すること |
|---|---|
| IT管理者 | エージェントごとのID、RBAC、接続、Key Vault、監査ログ |
| プロダクトオーナー | 対象業務、KPI、許容できない回答、評価基準 |
| 開発者 | バージョン管理、ツール構成、テストケース、トレース |
| 運用担当 | 監視指標、アラート、障害時の切り戻し、改善サイクル |
今回の更新は、Microsoft Foundry / Azure OpenAIでエージェントを作るチームに対して、「PoCの成功」から「本番で継続運用できる設計」へ進むことを求めています。まずは、作成済みエージェントのバージョン、公開状態、権限、監視の有無を確認し、次のリリースからライフサイクル管理を標準化するのが現実的な第一歩です。
コメント