Microsoft Foundry / Azure OpenAIでエンタープライズ向けAIエージェントを試作するなら、2026年4月時点で注目すべきポイントは「単体のチャットボット作成」ではありません。社内文書をSharePointでグラウンディングし、Microsoft Learnなどの外部知識をModel Context Protocol（MCP）ツールで参照し、その応答品質をバッチ評価してから、multi-agent化やMicrosoft Foundryへのデプロイにつなげる流れが明確になった点です。
ただし、2026年4月24日のGitHub履歴で確認できる変更は、本文機能を大きく追加したものではなく、update-codeメタデータの1行更新です。Microsoft Learn本文の表示上の最終更新日は2026年3月31日であり、4月24日を「新機能が追加された日」と断定するのは避けるべきです。この記事では、その前提を押さえたうえで、IT管理者、プロダクトオーナー、Microsoftエコシステム利用者が実務でどう読むべきかを整理します。(GitHub)
Microsoft Foundry / Azure OpenAIの2026年4月更新でまず押さえるべき結論
今回の「Tutorial: Idea to prototype – Build and evaluate an enterprise agent」は、Microsoft Foundry / Azure OpenAIを使ってエンタープライズAIエージェントを作る際の、PoCから評価までの標準的な型として読むのが適切です。公式ソースの説明では、SharePoint grounding、MCP tools、batch evaluation、multi-agentへの拡張、Microsoft Foundryへのデプロイが一連の流れとして位置づけられています。(GitHub)
| 観点 | 実務での受け止め方 |
|---|---|
| 2026年4月24日の変更 | 本文の大幅な機能追加ではなく、メタデータ更新として扱う |
| チュートリアルの中心 | SharePointとMCPを組み合わせた単一エージェントの試作 |
| 重要な実務ポイント | 作って終わりではなく、batch evaluationで品質を確認する |
| IT管理者の関心 | 認証、RBAC、SharePoint権限、MCP接続、監査ログ |
| プロダクトオーナーの関心 | 業務シナリオ、回答の根拠、評価基準、運用移行の判断 |
| Azure OpenAI利用者の関心 | モデルデプロイ名、リージョン差、モデル更新ポリシー、コスト |
このチュートリアルは「すぐ本番投入できる完成品」ではなく、「本番化に進めるべきかを判断するための検証フレーム」です。Microsoft Learnでも、該当コードはプレビュー段階のパッケージを使っており、SLAなしで提供され、本番ワークロードには推奨されない旨が明記されています。(Microsoft Learn)
チュートリアルが示す全体像：社内知識と外部技術情報を1つのエージェントで扱う
このチュートリアルの題材は「Modern Workplace Assistant」です。社内規程をSharePointドキュメントから取得し、技術実装ガイダンスをMicrosoft LearnのMCP経由で参照し、両方を組み合わせて業務に使える回答を生成する構成です。単に「質問に答えるAI」ではなく、社内ルールと公式技術情報を結び付けるエージェントとして設計されている点が重要です。(Microsoft Learn)
たとえば、次のような質問に対応する想定です。
| 質問タイプ | 主な情報源 | 期待する回答 |
|---|---|---|
| 社内規程の確認 | SharePoint | リモートワーク規程、セキュリティ要件、データ分類などを説明 |
| 技術実装の確認 | Microsoft Learn via MCP | 条件付きアクセス、MFA、Azureセキュリティ設定などの実装方針を説明 |
| 業務と技術の組み合わせ | SharePoint + MCP | 社内規程を満たすためにAzure環境をどう構成するかを提案 |
この構成が実務で有効なのは、エンタープライズAIエージェントの失敗が「モデル性能不足」だけで起きるわけではないからです。多くの場合、失敗の原因は、参照すべき社内文書が曖昧、外部情報の根拠が不明、評価基準がない、権限設計が甘い、といった周辺設計にあります。
アーキテクチャの読みどころ
今回のサンプルは、Microsoft Foundry SDKを使ってエージェントを作成し、SharePoint toolとMCP toolを接続し、Responses APIで会話し、batch evaluationで検証する流れになっています。公式チュートリアルでは、SharePointとMCPをツールとして追加し、合計2つのツールを持つエージェントを作成する例が示されています。(Microsoft Learn)
| 構成要素 | 役割 | 実務で確認すべきこと |
|---|---|---|
| Microsoft Foundry project | エージェント、モデル、接続を管理する作業単位 | プロジェクト権限、リージョン、接続先リソース |
| Azure OpenAI / Foundry Models | 推論に使うモデル | デプロイ名、モデルバージョン、リージョン可用性 |
| PromptAgentDefinition | モデル、指示、ツールをまとめてエージェント定義を作る | 指示文が業務ルールと矛盾しないか |
| SharePoint grounding | 社内文書に基づいた回答を可能にする | SharePoint権限、同一テナント、対象サイト |
| MCP tool | 外部ツールや外部データをエージェントに接続する | 接続先の信頼性、承認、監査、allowed tools |
| Batch evaluation | 応答品質、安全性、タスク遵守を検証する | 評価データ、合格基準、CI/CD連携 |
Microsoft Foundry Agent Serviceは、AIエージェントの構築、デプロイ、スケーリングを行うフルマネージド基盤として説明されています。エージェントはモデル、instructions、toolsの3要素で構成され、単純なチャットボットとは異なり、ツール呼び出しや外部データ参照、複数ステップの意思決定を行える点が特徴です。(Microsoft Learn)
事前準備で決めるべきこと
このチュートリアルを試す前に、いきなりサンプルコードを実行するのではなく、PoCの判断基準を先に決めるべきです。特にIT管理者とプロダクトオーナーでは見るべきポイントが異なります。
| 役割 | 事前に決めること | 具体例 |
|---|---|---|
| IT管理者 | 認証、接続、権限、データ境界 | SharePointサイトのRead権限、Foundry projectのRBAC、MCP接続の承認フロー |
| プロダクトオーナー | 業務シナリオと成功条件 | 「リモートワーク規程に沿ったAzure設定案を提示できる」など |
| 開発者 | 実装言語、SDK、評価方法 | Pythonでcloud evalを使うか、C#でローカル評価から始めるか |
| セキュリティ担当 | 監査、データ共有、外部接続 | MCPに渡すプロンプト内容、ログ取得、承認履歴 |
| 運用担当 | 本番化後の更新・監視 | モデル更新、評価再実行、権限変更時の影響確認 |
前提条件として、チュートリアルではAzureサブスクリプション、Azure CLI 2.67.0以降、デプロイ済みモデルを持つFoundry project、Python 3.10以降、C#サンプル用の.NET SDK 8.0以降、SharePoint connectionなどが挙げられています。SDKバージョンやサンプルリポジトリ構造は変わる可能性があるため、開始前にREADMEや最新パッケージを確認することも明記されています。(Microsoft Learn)
実務で試す手順
チュートリアルの流れは、細かい実装を読む前にまず動かし、動いたあとで構成を理解する順序になっています。この順序は、プロトタイプ検証では理にかなっています。最初に動作確認を済ませることで、認証、モデルデプロイ名、SharePoint接続、MCP接続のどこで詰まっているかを早く切り分けられるからです。
サンプルコードを取得する
公式チュートリアルでは、リポジトリ全体のclone、sparse checkout、ZIPダウンロードの3パターンが示されています。実務では、検証環境を軽く保つためにsparse checkoutが向いています。共有サンプルリポジトリをそのまま本番コードベースにするのではなく、本番採用時は独立したリポジトリに移すのが安全です。(Microsoft Learn)
.envを設定する
Pythonサンプルでは、2026年3月31日の更新で環境変数名が整理されています。PROJECT_ENDPOINTではなくFOUNDRY_PROJECT_ENDPOINT、MODEL_DEPLOYMENT_NAMEではなくFOUNDRY_MODEL_NAMEを使う点に注意してください。GitHubの該当コミットでも、環境変数名の標準化と依存関係の整理が説明されています。(GitHub)
# Foundry configuration
FOUNDRY_PROJECT_ENDPOINT=https://<your-project>.aiservices.azure.com
FOUNDRY_MODEL_NAME=gpt-4o-mini
# The Microsoft Learn MCP Server
MCP_SERVER_URL=https://learn.microsoft.com/api/mcp
# SharePoint integration
SHAREPOINT_CONNECTION_NAME=<your-sharepoint-connection-name>ここでのFOUNDRY_MODEL_NAMEは、実際にFoundry projectにデプロイ済みのモデル名と一致している必要があります。Azure OpenAI in Microsoft Foundry Modelsは、モデルの種類、価格、リージョン可用性が異なるため、サンプルのモデル名をそのまま前提にせず、自社テナントとリージョンで利用可能なデプロイを確認してください。(Microsoft Learn)
SharePointにサンプル文書を配置する
チュートリアルでは、SharePointのドキュメントライブラリに次のようなサンプル文書をアップロードする流れが示されています。
| サンプル文書 | 想定される役割 |
|---|---|
remote-work-policy.docx | リモートワーク規程、VPN、MFA、デバイス要件 |
security-guidelines.docx | Azureセキュリティ標準 |
collaboration-standards.docx | Teams、SharePoint利用ルール |
data-governance-policy.docx | データ分類、保持ポリシー |
本番のSharePointサイトにサンプル文書を置く場合は、検証後に削除する運用まで決めておきましょう。チュートリアルのクリーンアップ手順でも、サンプル文書を本番サイトにアップロードした場合は削除することが案内されています。(Microsoft Learn)
エージェントと評価を実行する
Pythonでは次のように実行します。
python main.py
python evaluate.pyC#では、ModernWorkplaceAssistantとEvaluateの各ディレクトリでdotnet restoreとdotnet runを実行します。公式チュートリアルでは、SharePoint接続がある場合はSharePoint toolが構成され、接続がない場合でもGraceful degradationとしてSharePointなしでエージェントを作成する例が示されています。(Microsoft Learn)
このGraceful degradationは実務上かなり重要です。PoCでは、すべての接続が最初から完全に整うとは限りません。SharePointが未設定でも、MCPだけで技術ドキュメント参照を検証する。逆にMCPが使えないネットワーク環境では、SharePoint groundingだけを先に検証する。そうした段階的な切り分けができます。
SharePoint groundingで失敗しやすいポイント
SharePoint groundingは、社内文書を使うエンタープライズエージェントでは非常に実用的です。一方で、権限やテナント条件を軽視すると、エージェントは作成できても必要な文書を取得できません。
SharePoint toolはプレビュー機能として提供され、ユーザーがアクセス可能なSharePointコンテンツから関連テキストを取得して回答生成に使います。統合ではOn-Behalf-Ofのidentity passthroughが使われるため、SharePoint側の権限が各リクエストに適用されます。(Microsoft Learn)
| 症状 | よくある原因 | 確認すべきこと |
|---|---|---|
| SharePoint toolは構成されたが文書が見つからない | 文書未配置、ライブラリ違い、接続名違い | 対象ライブラリに文書があるか、SHAREPOINT_CONNECTION_NAMEが正しいか |
| 403 Forbiddenが返る | ユーザー権限不足 | 実行ユーザーがSharePointサイトにRead権限を持つか |
| テナントをまたぐ接続で失敗する | Foundry projectとSharePointが別テナント | 同一Microsoft Entraテナントか |
| Teams公開後に期待通り動かない | SharePoint toolの制限 | 公開先とツール制限を事前確認する |
| 複数のSharePoint toolを付けたい | 1エージェント1 SharePoint toolの制限 | サイト設計、文書整理、別エージェント化を検討する |
公式ドキュメントでは、SharePoint toolにはユーザーID認証が必要で、アプリのみ認証やサービスプリンシパルではなく、SharePointサイトとFoundry agentが同一テナントにある必要があること、1エージェントにつき1つのSharePoint toolのみ対応することなどが制限として示されています。(Microsoft Learn)
MCP toolは「便利な外部接続」ではなく「管理対象の外部接続」として扱う
Model Context Protocol（MCP）は、LLMに外部ツールやコンテキストデータを提供するためのオープン標準です。Microsoft Foundry Agent Serviceでは、MCP toolを使ってリモートMCPサーバーをエージェントに接続し、外部ツールや外部データソースへのアクセスを拡張できます。(Microsoft Learn)
このチュートリアルでは、Microsoft LearnをMCP経由で参照し、社内規程と公式技術情報を組み合わせた回答を作る構成になっています。これは、IT管理者向けのエージェントで特に有効です。たとえば「社内のリモートワーク規程を満たすには、Azure AD Conditional Accessをどう設定すべきか」という質問に対して、社内文書だけでなく公式ドキュメントの実装情報も参照できます。
ただし、MCPは接続先のツールをエージェントが呼び出せる仕組みです。便利さと同時に、操作範囲の制御が重要になります。
| 設定項目 | 実務での意味 |
|---|---|
server_url | 接続するMCPサーバーの場所 |
server_label | エージェント内でMCPサーバーを識別する名前 |
allowed_tools | エージェントが使えるツールを限定する |
require_approval | ツール呼び出しに承認を要求するか |
project_connection_id | 認証情報を保持するFoundry project connection |
MicrosoftのMCPドキュメントでは、MCPサーバー利用時のベストプラクティスとして、allowed_toolsによる許可リスト、書き込みやリソース変更など高リスク操作への承認要求、承認前のツール名・引数確認、承認とツール呼び出しのログ取得が推奨されています。(Microsoft Learn)
特にグローバル企業では、MCP接続先がどの国・地域でデータを処理するか、プロンプト内容が外部サービスに渡るか、監査ログをどこまで残すかを確認する必要があります。非MicrosoftサービスやサードパーティMCPサーバーを使う場合、Microsoftはそれらを検証・保証しないため、接続先の信頼性を自社で評価する必要があります。(Microsoft Learn)
Batch evaluationがプロトタイプの価値を決める
このチュートリアルで最も実務的に重要なのは、エージェントを作って終わりにしない点です。公式チュートリアルでは、Microsoft Foundry SDKのbatch evaluation機能を使い、現実的な業務シナリオでエージェントの応答を検証する流れが示されています。Pythonサンプルではopenai_client.evals APIとazure_ai_target_completionsを使って、クエリを直接エージェントに流し、評価結果を取得します。(Microsoft Learn)
評価では、次のような組み込みevaluatorsが使われます。
| Evaluator | 見るポイント | 実務での意味 |
|---|---|---|
builtin.violence | 暴力的・有害な内容の検出 | 安全性の最低限チェック |
builtin.fluency | 回答の自然さ、読みやすさ | 業務ユーザーが理解できる回答か |
builtin.task_adherence | 指示への準拠 | 社内規程や要求条件に沿っているか |
C#サンプルは、Pythonのcloud evalとは異なり、ProjectResponsesClientを使ったローカル寄りの評価アプローチです。質問をエージェントに送り、期待キーワードや応答長を確認し、結果をevaluation_results.jsonに保存する構成として説明されています。(Microsoft Learn)
PoCで使う評価データは、デモ用のきれいな質問だけでは不十分です。次のような観点を入れると、実運用に近い判断ができます。
| テスト種別 | 質問例 | 確認すること |
|---|---|---|
| 社内規程確認 | 「リモートワーク時に必要なセキュリティ条件は？」 | SharePoint文書を正しく参照できるか |
| 技術実装確認 | 「条件付きアクセスの基本的な設定手順は？」 | MCP経由で公式技術情報を使えるか |
| 複合質問 | 「当社規程を満たすAzure設定案を示して」 | 社内ルールと技術実装を結び付けられるか |
| 権限境界 | 「アクセス権のない文書の内容を教えて」 | 権限外情報を出さないか |
| 不明質問 | 「社内規程にない例外対応を断定して」 | 不確かな情報を断定しないか |
| 監査向け | 「回答の根拠を示して」 | 根拠文書や参照情報を説明できるか |
プロダクトオーナーは、評価結果を「合格・不合格」だけで見ないほうがよいです。どの業務シナリオなら使えるか、どの質問では人間の承認が必要か、どの回答形式なら現場に受け入れられるかを判断する材料として使うべきです。
Single agentからmulti-agentへ進める判断基準
今回のチュートリアルは単一エージェントのプロトタイプが中心です。しかし、公式チュートリアルの説明では、他ツール、multi-agent patterns、よりリッチな評価へ拡張できることが示されています。(Microsoft Learn)
Microsoft Foundry Agent Serviceでは、Prompt agents、Workflow agents、Hosted agentsの3種類が整理されています。Prompt agentsは設定中心で素早いプロトタイピング向き、Workflow agentsは複数ステップや複数エージェントの調整向き、Hosted agentsは独自コードやカスタムフレームワークを使う複雑な制御向きです。(Microsoft Learn)
| 使い分け | 向いているケース | 判断基準 |
|---|---|---|
| Prompt agent | 社内FAQ、規程検索、簡単な業務支援 | 単一の目的で、ツール呼び出しも限定的 |
| Workflow agent | 承認フロー、複数部署連携、手順化された業務 | 分岐、順序、human-in-the-loopが必要 |
| Hosted agent | 独自ロジック、外部システム連携、複雑なmulti-agent | コードで制御したい、コンテナ化したい |
最初からmulti-agentにする必要はありません。むしろ、PoCでは単一エージェントで「社内文書を正しく読めるか」「MCPで外部情報を安全に参照できるか」「評価で一定品質を出せるか」を確認してから、業務プロセスに合わせてmulti-agent化するほうが失敗しにくいです。
Microsoft Foundryへのデプロイは「公開先」ではなく「運用単位」として考える
Microsoft Foundryへのデプロイを考えるときは、単にエージェントを公開するだけでなく、認証、安定したエンドポイント、ライフサイクル管理、RBACを含む運用単位として設計する必要があります。
Foundry Agent Applicationsでは、エージェントバージョンを公開すると、呼び出しURL、認証ポリシー、一意のEntra agent identityなどを持つAgent Applicationリソースが作られ、その配下にDeploymentが作成されます。Agent Applicationは、エージェントをサービスとして公開するための安定した入口として機能します。(Microsoft Learn)
| 本番化で確認する項目 | なぜ重要か |
|---|---|
| Agent version | どのプロンプト・ツール構成を本番に出したか追跡するため |
| Agent Application | 利用者が呼び出す安定したエンドポイントを持つため |
| RBAC | 誰がエージェントを呼び出せるか制御するため |
| Tool authentication | SharePointやMCPの接続権限を安全に扱うため |
| Evaluation再実行 | モデル、文書、プロンプト変更後の品質劣化を検出するため |
| Monitoring | 本番利用後の失敗、遅延、異常なツール呼び出しを検知するため |
Agent ApplicationのResponses protocolでは、現時点でstateless Responses APIのみがサポートされ、会話履歴はクライアント側で保持する必要がある制限もあります。実装時には、マルチターン会話の履歴保存、個人情報の扱い、監査ログの保持方針を設計しておく必要があります。(Microsoft Learn)
Azure OpenAI利用者が注意すべきモデル運用
Microsoft Foundry / Azure OpenAIの文脈では、エージェントの品質はモデル選定にも左右されます。ただし、PoCでは「高性能なモデルを選べばよい」と単純化しないほうがよいです。実務では、リージョン可用性、コスト、レイテンシ、モデル更新ポリシー、データ境界が絡みます。
Azure OpenAI in Microsoft Foundry Modelsでは、モデルごとに機能、価格帯、リージョン可用性が異なります。また、Azure OpenAIでは一部のモデルデプロイに自動更新があり、Standard deployment typeでは自動更新設定を選べるケースがあります。(Microsoft Learn)
PoC時点で決めるべきモデル運用ルールは次のとおりです。
| 項目 | 推奨する確認 |
|---|---|
| モデルデプロイ名 | .envのFOUNDRY_MODEL_NAMEとFoundry project上のデプロイ名が一致しているか |
| リージョン | 自社の利用リージョンで対象モデルが使えるか |
| 更新ポリシー | 自動更新で回答傾向が変わる可能性を把握しているか |
| 評価タイミング | モデル変更、プロンプト変更、SharePoint文書更新後に評価を再実行するか |
| コスト | 評価実行、MCP呼び出し、SharePoint retrievalを含めて見積もるか |
本番化を考えるなら、モデルを固定するか、自動更新を許容するかをプロダクトオーナーとIT管理者が合意しておくべきです。モデル更新で回答の自然さが改善することもありますが、規程回答や監査用途では、回答傾向の変化がリスクになる場合があります。
IT管理者とプロダクトオーナーが見るべき実務ポイント
今回のチュートリアルは開発者向けに見えますが、実際にはIT管理者とプロダクトオーナーが一緒に読む価値があります。理由は、エンタープライズAIエージェントの成否が、コードだけでなく、業務設計、権限設計、評価設計に依存するためです。
| 読者 | 重点的に見るべき章 | 行動 |
|---|---|---|
| IT管理者 | SharePoint、MCP、RBAC、Agent Application | 接続方式、権限、監査、外部データ共有を確認する |
| プロダクトオーナー | 業務シナリオ、評価データ、成功条件 | エージェントに任せる範囲と人間承認が必要な範囲を決める |
| 開発者 | SDK、.env、Responses API、batch evaluation | サンプルを動かし、評価可能なPoCとして整える |
| セキュリティ担当 | MCP承認、SharePoint権限、プレビュー機能 | データ流出、過剰権限、外部接続のリスクを洗い出す |
| 運用担当 | デプロイ、監視、再評価 | 本番化後の変更管理と品質監視を設計する |
特に重要なのは、デモの成功をそのまま本番化判断にしないことです。デモでは3つの質問に答えられても、本番ではユーザーが曖昧な質問をします。文書が古い場合もあります。権限のない情報を聞くユーザーもいます。だからこそ、batch evaluationと権限テストをPoCの必須工程に入れる必要があります。
よくある誤解と注意点
4月24日に新機能が大量追加されたわけではない
2026年4月24日のGitHub履歴では、ms.customにupdate-code1を追加するメタデータ変更が確認できます。本文の説明やコード例が大きく変わった更新ではありません。記事化や社内共有では「4月24日の機能追加」と表現せず、「4月24日の履歴を含む2026年4月時点の確認ポイント」と表現するほうが正確です。(GitHub)
MCPをつなげば正しい情報が返るとは限らない
MCPは外部ツールや外部データに接続するための仕組みです。接続先が信頼できるか、どのツールを許可するか、承認が必要かを設計しなければ、便利なだけでリスクの高い構成になります。MicrosoftのMCPドキュメントでも、許可リスト、承認、ログ、接続先レビューが推奨されています。(Microsoft Learn)
SharePointに置いた文書が自動的に全員へ回答されるわけではない
SharePoint toolはidentity passthroughを使い、ユーザーのSharePoint権限に基づいて取得できるコンテンツが決まります。これはセキュリティ上は重要ですが、PoCでは「管理者は見えるが一般ユーザーは見えない」という差分が起きやすいです。評価時には複数ロールのユーザーで検証する必要があります。(Microsoft Learn)
評価は最後にやるものではない
評価は完成後の確認ではなく、PoCの設計段階から組み込むべきものです。質問セットを先に作ることで、エージェントに何を期待しているのかが明確になります。さらに、評価をCI/CDに組み込めば、プロンプト、モデル、文書、ツール設定の変更による品質低下を継続的に検知できます。公式チュートリアルでも、production scenariosではCI/CD pipelineの一部として評価を実行することが提案されています。(Microsoft Learn)
次に取るべき行動
Microsoft Foundry / Azure OpenAIでエンタープライズAIエージェントを検討しているなら、次の順序で進めるのが現実的です。
| ステップ | 実施内容 | 完了条件 |
|---|---|---|
| 1 | 業務シナリオを1つ選ぶ | 「誰が何を判断するためのエージェントか」が説明できる |
| 2 | SharePoint文書を整理する | 参照すべき文書、権限、更新責任者が明確 |
| 3 | MCP接続先を決める | 接続先、allowed tools、承認要否、ログ方針が決まっている |
| 4 | サンプルを実行する | 単一エージェントがSharePoint/MCPを使って回答できる |
| 5 | batch evaluationを作る | 業務質問、境界質問、失敗ケースを含む評価セットがある |
| 6 | multi-agent化を判断する | 単一エージェントでは足りない分岐や承認が明確 |
| 7 | デプロイ設計に進む | Agent Application、RBAC、監視、再評価の設計ができている |
今回のチュートリアルは、Microsoft Foundry / Azure OpenAIでエージェントを作るための「最小サンプル」ではなく、社内知識、外部技術情報、評価、デプロイをつなぐための実務的な出発点です。まずは単一エージェントで小さく検証し、評価で弱点を見つけ、権限と接続先を固めてから、multi-agentや本番デプロイへ進むのが安全です。
コメント