Azure AI Foundryでエンタープライズ向けAIエージェントを試すなら、今回確認すべきポイントは「チャットボットを作る手順」ではありません。重要なのは、SharePoint上の社内文書を根拠に回答し、MCPで外部の技術情報を参照し、バッチ評価で品質を確認してから、Microsoft Foundry上で本番展開へ進める流れが公式チュートリアルとして整理されたことです。
結論として、管理者は Entra ID/RBAC、SharePoint接続、MCPの通信・承認、モデルのデプロイ種類、評価と監視 を先に確認する必要があります。開発者は Azure AI Projects 2.x前提のサンプル、.env設定、SharePointグラウンディング、MCPツール、バッチ評価、マルチエージェント拡張 を順番に検証すると、試作から本番化までの手戻りを減らせます。なお、対象チュートリアルのコードはプレビュー段階のパッケージを使用しており、公式情報でも運用ワークロードには推奨されていないため、最初から本番SharePointや機密データに接続しない判断が重要です。(Microsoft Learn)
Azure AI FoundryのAI/Copilot更新で何が変わるのか
今回の「Tutorial: Idea to prototype – Build and evaluate an enterprise agent」は、Azure AI Foundry、現在の公式ドキュメント上ではMicrosoft Foundryの文脈で、アイデア段階からエンタープライズエージェントのプロトタイプを作る流れを示すチュートリアルです。社内ナレッジ、外部ドキュメント、評価、将来のマルチエージェント化を一つの開発導線にまとめている点が大きなポイントです。(Microsoft Learn)
| 変更・注目点 | 何ができるようになるか | 管理者・開発者への影響 |
|---|---|---|
| SharePointグラウンディング | 社内ポリシーや手順書を根拠に回答できる | SharePointサイト、権限、接続ID、同一テナント条件の確認が必要 |
| MCPツール連携 | Microsoft Learnなど外部技術情報をエージェントから参照できる | 外部接続先、承認フロー、ネットワーク、認証方式の設計が必要 |
| バッチ評価 | 複数の業務シナリオでエージェント応答を検証できる | リリース前評価、CI/CD連携、評価データセット整備が重要 |
| Azure AI Projects 2.x前提 | 新しいFoundry SDK前提で開発できる | 1.x系や旧クラシックAPI利用環境では移行確認が必要 |
| マルチエージェント拡張 | 単一エージェントからA2Aやワークフローへ拡張できる | 役割分担、責任範囲、ログ、監査の設計が必要 |
| Microsoft Foundryへの展開 | 管理されたエージェント基盤でデプロイ・スケールできる | RBAC、モデルデプロイ種類、監視、公開先の検討が必要 |
このチュートリアルは、単に「SharePointを読ませるAI」を作るものではありません。社内規程を読むエージェント、Microsoft Learnを参照する技術支援エージェント、両方を組み合わせた実装助言、さらにその回答を評価する仕組みまでを一連のプロトタイプとして扱います。公式チュートリアルでは、SharePoint文書、MCP経由のMicrosoft Learn、組み合わせ回答、バッチ評価をビジネスシナリオとして扱っています。(Microsoft Learn)
このチュートリアルで作るエンタープライズエージェントの全体像
チュートリアルの中心は「Modern Workplace Assistant」という単一エージェントです。このエージェントは、SharePointに置いた会社のポリシー文書と、MCP経由で参照するMicrosoft Learnの技術情報を組み合わせて回答します。たとえば、リモートワークポリシーだけを聞く質問、Conditional Accessの実装方法だけを聞く質問、社内ポリシーに準拠したAzure設定を聞く質問に分けて動作を確認します。(Microsoft Learn)
| 構成要素 | 役割 | 実務での使いどころ |
|---|---|---|
| Foundryプロジェクト | エージェント、モデル、接続、評価を管理する作業単位 | 開発・検証・本番を分離して管理 |
| デプロイ済みモデル | エージェントの推論に使うモデル | 用途、コスト、データ所在地、性能要件で選定 |
| SharePoint接続 | 社内文書を根拠として取得 | 規程、手順書、社内FAQ、セキュリティ基準 |
| MCPツール | 外部ツールや外部データソースへ接続 | Microsoft Learn、社内API、開発者向けナレッジ |
| バッチ評価 | 複数質問に対する品質・安全性を確認 | 本番前ゲート、回帰テスト、CI/CD |
| マルチエージェント拡張 | 専門エージェントを分担させる | 法務、セキュリティ、IT運用、開発支援の分業 |
実務で特に価値が出るのは、「社内ルール」と「実装手順」を分離して扱える点です。たとえば、社内のリモートワーク規程に「MFA必須」「会社管理デバイスのみ」「VPN利用」と書かれている場合、SharePointからポリシーを取得し、MCP経由でMicrosoft Learnの技術ガイダンスを参照し、Azure側で何を設定すべきかをまとめる構成にできます。
管理者が先に確認すべき影響範囲
プレビュー機能を本番前提で扱わない
対象チュートリアルでは、現在プレビュー段階のパッケージを使うコードが含まれます。プレビューはSLAなしで提供され、運用ワークロードには推奨されていないと明記されています。したがって、最初の検証では本番テナントや本番SharePointサイトではなく、検証用プロジェクト、検証用ドキュメントライブラリ、限定されたテストユーザーで始めるべきです。(Microsoft Learn)
特に管理者は、次の3点を明確にしてから展開してください。
| 確認項目 | 判断基準 |
|---|---|
| 利用環境 | 開発、検証、本番を分ける。最初から本番データに接続しない |
| 利用データ | 機密文書、人事情報、契約情報、顧客情報を初期検証に含めない |
| 利用者 | 検証ユーザーを限定し、監査できるIDで実行する |
Entra IDとRBACを前提にする
エンタープライズ利用では、APIキーではなくMicrosoft Entra IDによる認証を前提にするのが安全です。Microsoft Foundryの公式情報では、Entra IDは条件付きアクセス、MFA、マネージドID、最小特権RBACに対応し、APIキーは迅速な評価には便利でも、ユーザー単位の追跡や細かなスコープ制御が難しいと説明されています。(Microsoft Learn)
管理者が最初に確認すべきロールは、少なくとも次の通りです。
| 対象者 | 推奨される考え方 |
|---|---|
| 開発者 | 事前にデプロイされたモデルを使ってエージェントを構築するならFoundry User相当から始める |
| チームリード | モデルデプロイやプロジェクト管理が必要ならProject Manager相当を検討する |
| 管理者 | リソース管理、接続、キー管理を扱う場合は高権限ロールを限定付与する |
| 監視担当 | Foundry側の権限に加え、Application InsightsやAzure Monitorの閲覧権限を検討する |
FoundryのRBACロール名は変更が進んでおり、以前のAzure AI系ロール名が表示される場合があります。ロールIDと基本権限は変更されないとされているため、IaCやスクリプトではロール名だけに依存しない設計が無難です。(Microsoft Learn)
SharePoint接続の権限と制限を確認する
SharePointグラウンディングは便利ですが、管理上の注意点が多い領域です。公式ドキュメントでは、SharePointツールはユーザーID認証を必要とし、SharePointサイトとFoundryエージェントは同じテナントに存在する必要があります。また、エージェントごとに追加できるSharePointツールは1つで、Teamsに発行された場合は機能しない制限も示されています。(Microsoft Learn)
さらに、SharePointツールはユーザーがアクセスできる文書から関連テキストを取得するため、SharePoint側のアクセス権限がそのまま重要になります。検証環境では、全社文書ライブラリではなく、チュートリアル用の小さなドキュメントライブラリを作り、テストユーザーにRead権限だけを付与する構成から始めると安全です。(Microsoft Learn)
| 確認項目 | 注意点 |
|---|---|
| テナント | FoundryプロジェクトとSharePointが同一Microsoft Entraテナントか |
| 権限 | 開発者・エンドユーザーが対象ライブラリにReadアクセスを持つか |
| 接続URL | SharePointのアドレスバー全体ではなく、指定形式のサイトURLまたはフォルダーURLを使う |
| コンテンツ | 画像やグラフ中心の非テキスト情報を前提にしない |
| 文書範囲 | 初期検証では短く、構造が分かりやすい文書から始める |
MCPは「便利な外部接続」ではなく「管理対象のツール接続」として扱う
MCPは、LLMに外部ツールやコンテキストデータを提供するためのオープン標準です。Foundry Agent Serviceでは、MCPツールを使ってリモートMCPサーバーに接続し、外部データソースや開発者がホストするツールをエージェントから利用できます。(Microsoft Learn)
管理者が見落としやすいのは、MCP接続が外部通信を伴う点です。公式ドキュメントでは、パブリックMCPエンドポイントとプライベートMCPエンドポイントの両方が説明されており、プライベートMCPにはStandard Agentセットアップや専用MCPサブネットが必要とされています。社内ネットワーク内のツールや非公開APIに接続する場合は、ネットワーク、認証、承認、ログの設計を先に決める必要があります。(Microsoft Learn)
また、多くのMCPサーバーでは認証が必要です。Foundry Agent Serviceでは、アプリに資格情報を直接埋め込むのではなく、プロジェクト接続を使ってAPIキーやベアラートークンなどを保存する方式が説明されています。(Microsoft Learn)
開発者が確認すべき設定と実装ポイント
前提条件はローカル環境だけでなくFoundry側も確認する
チュートリアルでは、Azureサブスクリプション、Azure CLI 2.67.0以降、デプロイ済みモデルを含むFoundryプロジェクト、Python 3.10以降、C#サンプル用の.NET SDK 8.0以降、SharePoint接続などが前提条件として示されています。(Microsoft Learn)
開発者が最初にやるべきことは、コードを書くことではなく、次の値を確実にそろえることです。
FOUNDRY_PROJECT_ENDPOINT=https://<your-project>.aiservices.azure.com
FOUNDRY_MODEL_NAME=gpt-4o-mini
MCP_SERVER_URL=https://learn.microsoft.com/api/mcp
SHAREPOINT_CONNECTION_NAME=<your-sharepoint-connection-name>.envの値では、FOUNDRY_PROJECT_ENDPOINTがhttps://で始まっているか、FOUNDRY_MODEL_NAMEが実際にプロジェクトへデプロイ済みのモデル名と一致しているかを必ず確認してください。モデル名の不一致は、試作段階で最も起きやすいエラーの一つです。 (Microsoft Learn)
Azure AI Projects 1.x利用環境は移行確認が必要
対象チュートリアルのサンプルはAzure AI Projects 2.xを使用し、Azure AI Projects 1.xとは互換性がないとされています。既存のAzure AI FoundryやAzure AI Studio時代のサンプル、社内テンプレート、CI/CDスクリプトを流用する場合は、依存パッケージ、名前空間、接続方法、エージェント作成APIの差分を確認してください。(Microsoft Learn)
特に注意したいのは、次のような環境です。
| 既存環境 | 確認すべきこと |
|---|---|
| Azure AI Projects 1.xのサンプルを利用 | 2.x向けにコード構成を見直す |
| 旧クラシックAPIの接続済みエージェントを利用 | A2Aツールまたはワークフローへの移行候補を確認する |
| 社内テンプレートで固定バージョンを指定 | PyPI、NuGet、サンプルREADMEで最新の要件を確認する |
| 本番リポジトリにサンプルを直接流用 | サンプル用構成から独立したリポジトリ構成へ整理する |
チュートリアルでも、SDKバージョンやサンプルリポジトリ構造は公開後に変わる可能性があるため、開始前にサンプルリポジトリREADMEを確認し、参照バージョンが利用できない場合は最新公開バージョンを使うよう案内されています。(Microsoft Learn)
SharePointとMCPは失敗してもエージェントが落ちない設計にする
公式サンプルでは、SharePoint接続やMCP接続が未設定・利用不可の場合でも、エージェントがそれらなしで動作する「グレースフルデグラデーション」の考え方が示されています。たとえば、SHAREPOINT_CONNECTION_NAMEが未設定ならSharePoint連携をスキップし、それでもエージェント作成自体は継続します。(Microsoft Learn)
実務では、この設計が非常に重要です。外部ツールが一時的に使えないだけで全体のワークフローを止めると、利用者は「AIが壊れた」と受け取ります。実装では、少なくとも次のように応答を分けるべきです。
| 状態 | エージェントの振る舞い |
|---|---|
| SharePoint利用可 | 社内文書を根拠にし、出典や対象文書を明示する |
| SharePoint不可 | 社内文書に基づく回答はできないことを明示する |
| MCP利用可 | 外部技術情報を参照し、実装手順や公式ドキュメントの根拠を示す |
| MCP不可 | 一般的な回答に留め、最新の公式情報確認を促す |
| 両方不可 | 回答範囲を限定し、管理者に接続確認を依頼する |
バッチ評価で何を確認すべきか
チュートリアルでは、Microsoft Foundry SDKのバッチ評価機能を使い、現実的なビジネスシナリオでエージェントをテストする流れが示されています。Pythonサンプルでは、builtin.violence、builtin.fluency、builtin.task_adherenceなどの組み込みエバリュエーターとopenai_client.evals APIを使い、クラウド上で反復可能な評価を実行します。(Microsoft Learn)
評価は「動いたかどうか」を見るだけでは不十分です。エンタープライズエージェントでは、次の観点でテストケースを作る必要があります。
| 評価観点 | テスト例 | 合格基準の例 |
|---|---|---|
| 社内文書の参照 | 「当社のリモートワーク規程は？」 | SharePoint文書に基づき、推測で補完しない |
| 外部技術情報の参照 | 「Conditional Accessの設定方法は？」 | MCP経由の技術情報を使い、根拠を示す |
| 組み合わせ回答 | 「当社規程に合わせてAzureをどう設定する？」 | 社内要件と実装手順を分けて説明する |
| 権限不足 | アクセス権のない文書について質問 | 権限外情報を出さず、取得不可と説明する |
| 安全性 | 危険・不適切な内容を含む質問 | 安全性評価で問題がない |
| タスク遵守 | 「箇条書きで3点だけ」など制約付き質問 | 指示形式を守る |
評価結果は、Foundryポータルで確認したり、プログラムから取得したりできます。出力項目には、合格・不合格ラベル、スコア、しきい値、理由などが含まれます。品質系の評価は1〜5、安全系の評価は0〜7、タスク遵守は1〜5のように、評価器によってスケールが異なるため、単純に数値だけを横並び比較しないよう注意してください。(Microsoft Learn)
C#サンプルについては、Pythonのクラウド評価APIとは異なり、ローカルのバッチ評価アプローチでエージェントへクエリを送り、期待キーワードなどを確認してevaluation_results.jsonに保存する構成が説明されています。PythonとC#で評価方式が完全に同じではないため、チームで使う言語に合わせて評価パイプラインを設計する必要があります。(Microsoft Learn)
マルチエージェント化と本番展開の判断基準
単一エージェントのままで十分なケースは、質問の種類が限定され、1つの指示セットで回答品質を保てる場合です。一方、社内ポリシー確認、セキュリティレビュー、Azure構成提案、承認ワークフロー、監査ログ確認など、役割が明確に分かれる場合は、マルチエージェント化を検討する価値があります。
Microsoft Foundry Agent Serviceでは、A2Aツールやマルチエージェントワークフローを使った連携が説明されています。A2Aツールでは、呼び出し元エージェントが別のA2A互換エンドポイントを呼び出し、その回答を受け取ってユーザー応答を生成します。一方、ワークフローやその他のマルチエージェントオーケストレーションでは、呼び出された側のエージェントが後続のユーザー入力を処理する場合があります。(Microsoft Learn)
旧クラシックAPIのagent.as_toolや接続済みエージェントツールは、新しいFoundry Agent Serviceでは利用できないとされています。既存実装を移行する場合は、単純な置き換えではなく、A2Aツールまたはワークフローのどちらに寄せるかを設計し直す必要があります。(Microsoft Learn)
本番展開ではモデルのデプロイ種類も設計対象になる
Microsoft Foundryにモデルをデプロイする際は、データ処理場所、支払い方法、パフォーマンス特性に関わるデプロイ種類を選択します。公式ドキュメントでは、Standardとプロビジョニング済みが主なカテゴリとして説明され、グローバル、データゾーン、単一リージョンといった処理場所の選択肢も示されています。(Microsoft Learn)
| 要件 | 選び方の目安 |
|---|---|
| まず小さく検証したい | Standard系で開始し、利用量と遅延を測る |
| データ所在地が重要 | Data Zoneまたは単一リージョンを検討する |
| 高スループットが必要 | プロビジョニング済みを検討する |
| 大量の非同期処理 | Batch系を検討する |
| 低遅延のばらつきを抑えたい | プロビジョニング済みを検討する |
重要なのは、プロトタイプで動いたモデル構成をそのまま本番に持ち込まないことです。エージェントは回答生成だけでなく、SharePoint取得、MCP呼び出し、評価、ログ、ユーザー権限確認を含むため、本番化ではモデル単体の性能だけでなく、全体の応答時間と失敗時の挙動を測定してください。
Microsoft Foundryへの展開では公開先と監視を同時に決める
Foundry Agent Serviceは、AIエージェントを構築、デプロイ、スケーリングするためのフルマネージドプラットフォームです。公式概要では、ホスティング、スケーリング、ID、可観測性、エンタープライズセキュリティを処理し、エージェントロジックに集中できると説明されています。(Microsoft Learn)
また、エージェントサービスの概要では、エージェントのバージョン管理、安定したエンドポイント作成、Microsoft Teams、Microsoft 365 Copilot、Entra Agent Registryを介した共有が「公開」の要素として示されています。公開先を決める前に、誰が利用するのか、どのIDで実行するのか、どのログを監査するのかを整理してください。(Microsoft Learn)
失敗しやすいポイントと対策
| 症状 | 主な原因 | 対策 |
|---|---|---|
DefaultAzureCredentialで認証エラー | Azure CLIのセッション切れ、未サインイン | az loginを実行し、テナントとサブスクリプションを確認する |
Model deployment not found | .envのモデル名とFoundry上のデプロイ名が不一致 | FoundryポータルのDeploymentsを確認し、FOUNDRY_MODEL_NAMEを修正する |
| SharePointツールは構成済みだが文書が見つからない | 文書未アップロード、接続名違い、権限不足 | 対象ライブラリに文書があるか、接続名とRead権限を確認する |
| MCPツールがタイムアウトする | MCPサーバーに到達できない、HTTPS通信不可 | MCP_SERVER_URLと送信HTTPS許可を確認する |
SharePointで403 Forbidden | ユーザーにSharePoint側の権限がない | サインインIDに対象ライブラリのRead権限を付与する |
これらのトラブルは、公式チュートリアルのトラブルシューティングにも示されています。開発者だけで解決しようとせず、Azure管理者、Microsoft 365管理者、ネットワーク管理者の確認が必要になるケースが多い点に注意してください。(Microsoft Learn)
管理者・開発者向けの確認チェックリスト
管理者向け
- 検証用Foundryプロジェクトを本番環境と分けている
- Microsoft Entra ID認証を前提にしている
- APIキー利用を検証用途に限定している
- Foundry User、Project Manager、Ownerなどのロールを最小権限で割り当てている
- SharePointサイトとFoundryプロジェクトが同一テナントにある
- SharePointの接続先をサイトまたはフォルダー単位で限定している
- MCPの接続先、認証方式、承認フローを確認している
- モデルのデプロイ種類をデータ所在地、遅延、コスト、スループットで選んでいる
- 本番展開前に評価、監視、ログ、削除手順を用意している
開発者向け
- Azure CLI、Python、.NET SDKなどの前提バージョンを確認している
- Azure AI Projects 2.x前提のコードとして扱っている
- サンプルREADMEで最新の依存関係を確認している
.envのエンドポイント、モデル名、SharePoint接続名、MCP URLを確認している- SharePoint接続なし、MCP接続なしでも落ちない実装にしている
- 社内文書のみ、外部情報のみ、組み合わせ回答の3種類でテストしている
- バッチ評価の結果を保存し、リリース前の判断材料にしている
- サンプルを本番リポジトリへそのままコピーせず、構成を整理している
最初の検証は「小さく、権限を絞って、評価まで」進める
Azure AI Foundryでエンタープライズエージェントを作る場合、最初から大規模なCopilot連携や全社SharePoint検索を目指すと、権限、データ範囲、評価、監査でつまずきやすくなります。最初の一歩は、検証用Foundryプロジェクト、短いSharePoint文書、限定ユーザー、1つのMCP接続、数件の評価データで十分です。
実務では、次の順序で進めると安全です。
| フェーズ | 実施内容 | 完了条件 |
|---|---|---|
| 準備 | Foundryプロジェクト、モデル、RBAC、SharePoint検証ライブラリを用意 | 開発者がFoundryとSharePointへ適切にアクセスできる |
| 単一エージェント作成 | SharePointとMCPを接続したModern Workplace Assistantを作る | 社内文書のみ、外部情報のみ、組み合わせ回答が動く |
| 評価 | バッチ評価で安全性、流暢さ、タスク遵守を確認 | 失敗ケースを把握し、改善項目を記録する |
| 拡張判断 | 単一エージェントで十分か、A2Aやワークフローが必要か判断 | 責任範囲と公開先が明確になる |
| 本番設計 | Entra ID、RBAC、監視、デプロイ種類、CI/CD、運用手順を整備 | 評価と監視を含むリリース基準がある |
今回のチュートリアルは、Azure AI Foundryでエージェントを試すための単発サンプルではなく、社内ナレッジ活用、外部ツール連携、品質評価、本番展開をつなぐ実践的な出発点です。管理者は権限と接続範囲を先に固め、開発者は単一エージェントから評価までを通し、結果を見てからマルチエージェント化やMicrosoft Foundryへの本番展開へ進むのが現実的です。
コメント