Microsoft Foundryの「Use SharePoint content with agent API」は、SharePoint / OneDrive上の社内文書をAIエージェントの回答根拠として使いたい企業にとって、管理・開発の両面で確認すべき更新です。結論から言うと、Foundry Agent ServiceのSharePointツールを使うことで、SharePointサイトまたはフォルダーを接続し、ユーザー本人の権限を引き継いだまま文書のテキストを取得して回答に反映できます。つまり、独自のRAG用インデックスを一から作る前に、Microsoft 365の既存の検索・権限管理を活かせる選択肢が増えた、という位置づけです。(Microsoft Learn)
ただし、すぐ本番展開できる万能機能ではありません。現時点ではプレビュー機能であり、ユーザーID認証、同一テナント、Microsoft 365 Copilotライセンスまたは従量課金、SharePointのREAD権限、URL形式、Teams発行時の制約などを事前に確認する必要があります。この記事では、2026年5月16日時点で確認すべき公式情報を前提に、管理者・開発者がどこを見ればよいかを実務目線で整理します。(Microsoft Learn)
SharePoint / OneDriveのAI・Copilot更新で何が変わるのか
今回のポイントは、SharePointそのものの画面機能が大きく変わるというより、Microsoft FoundryのエージェントがSharePointコンテンツを安全に参照しやすくなることです。Foundry Agent ServiceのSharePointツールは、SharePointサイトやフォルダーから関連テキストを取得し、エージェントの回答をその内容でグラウンディングします。ユーザーが質問すると、エージェントはSharePointツールを呼び出し、そのユーザーがアクセスできる文書から関連するテキストを取得して回答を生成します。(Microsoft Learn)
従来、社内文書をAIで参照させるには、SharePointからデータをエクスポートし、別のベクトルDBや検索インデックスに登録し、権限同期や更新処理を独自に設計するケースがありました。今回の方式では、Microsoft 365 Copilot Retrieval APIやMicrosoft 365のインデックス機能を活用し、データを別管理せずに取得パイプラインを使える点が実務上の大きな違いです。(Microsoft Learn)
| 観点 | これまで起こりがちだった対応 | 今回のSharePointツールで変わる点 |
|---|---|---|
| 文書取得 | SharePointから別基盤へ同期・コピー | SharePointサイトまたはフォルダーを接続して取得 |
| 権限管理 | 独自インデックス側で権限同期が必要 | IDパススルーによりSharePoint側の権限を反映 |
| 更新反映 | クローラーや再インデックス設計が必要 | Microsoft 365側の検索・インデックス基盤を利用 |
| 回答根拠 | 独自実装で引用元を管理 | 取得したSharePoint文書への引用情報を扱える |
| 導入リスク | データ複製・過剰権限・同期漏れが課題 | 既存権限を活かせるが、過剰共有はそのまま影響する |
OneDriveについては、基盤となるMicrosoft 365 Copilot Retrieval APIのデータソースとしてSharePoint、OneDrive、Copilotコネクタが示されています。ただし、Foundryの今回のSharePointツールはSharePointサイトまたはフォルダー接続を中心に設計されているため、OneDriveを含むシナリオではライセンス条件とデータソースの扱いを分けて確認する必要があります。特にMicrosoft 365 Copilotライセンスを持たないユーザー向けの従量課金では、OneDriveなどのユーザーレベルのデータソースは利用できないとされています。(Microsoft Learn)
Use SharePoint content with agent APIでできること
「Use SharePoint content with agent API」の中核は、FoundryエージェントにSharePointツールを追加し、SharePoint内の業務文書を回答の根拠に使わせることです。たとえば、次のような用途が想定できます。
- 社内規程サイトを参照する人事・総務向けFAQエージェント
- プロジェクトの議事録や仕様書を要約するチーム向けエージェント
- 契約書テンプレートや申請手順を探すバックオフィス支援エージェント
- 顧客別フォルダーの資料をもとに営業準備を支援するエージェント
- SharePoint上のナレッジをもとに一次回答を作る社内ヘルプデスク
重要なのは、エージェントが「組織の全SharePointを自由に読める」わけではない点です。この統合ではIDパススルー、つまりOn-Behalf-Of認証が使われ、SharePointのアクセス許可が各リクエストに適用されます。ユーザーAが閲覧できない文書は、ユーザーAの質問への回答根拠として使われない設計です。(Microsoft Learn)
一方で、これは管理者にとって「SharePointの共有設定がそのままAI回答範囲になる」という意味でもあります。すでに全社員に過剰共有されているフォルダー、退職者が作成したまま放置された共有リンク、部署外から読める機密文書がある場合、エージェント導入をきっかけに情報露出のリスクが顕在化します。AIの設定だけでなく、SharePointの権限棚卸しを先に行うべきです。
導入前に確認すべき前提条件
公式ドキュメントでは、SharePointツールの利用にあたってライセンス、Foundry側のRBAC、SharePoint側のREAD権限、同一Microsoft Entraテナント、SDK、環境変数、接続IDなどが前提として示されています。英語版ではFoundry RBACロール名が「Foundry User」などへ名称変更されたことも記載されているため、管理画面や日本語ドキュメントで旧名称が残っている場合は、表示名だけでなく実際の権限で確認しましょう。(Microsoft Learn)
| 確認項目 | 管理者・開発者が見るべきポイント | 見落とした場合の影響 |
|---|---|---|
| プレビュー扱い | パブリックプレビューであり、SLAなし。本番ワークロードには慎重に適用する | 障害時の責任範囲やサポート前提を誤る |
| ライセンス | Microsoft 365 Copilotライセンス、または対象となる従量課金モデルを確認 | Forbiddenやライセンス不足エラーが発生する |
| Foundry RBAC | 開発者・利用者にFoundry User相当のロールがあるか確認 | エージェント作成・呼び出し・検証ができない |
| SharePoint権限 | 利用者が対象サイト・文書にREADアクセスを持つか確認 | ツールが結果を返さない |
| テナント | SharePointテナントとFoundryプロジェクトが同じMicrosoft Entraテナントか確認 | 401や認証エラーが発生する |
| 認証方式 | ユーザーID認証が必須。アプリ専用・サービスプリンシパル認証は不可 | App-only前提のバックエンド設計が使えない |
| ツール数 | 1エージェントに追加できるSharePointツールは1つ | 複数サイトを雑に横断する設計が難しい |
| 配布先 | SharePointツールは、エージェントをMicrosoft Teamsへ発行した場合に動作しないと明記されている | Teams配布前提の計画が破綻する |
| 対象ファイル | セマンティック・ハイブリッド取得の対象形式や非テキスト制約を確認 | 画像・グラフ中心の資料で期待した回答が出ない |
特に注意したいのは、アプリ専用認証が使えない点です。バックエンドサービスがサービスプリンシパルでSharePointを読み、全ユーザーに同じ回答を返すような設計ではなく、ユーザー本人の権限を前提にした対話型エージェントとして設計する必要があります。(Microsoft Learn)
設定手順は「小さなサイト」から始める
公式ドキュメントでも、最初はシンプルなフォルダー構造と少数の短いドキュメントを持つSharePointサイトから始めることが推奨されています。いきなり全社ポータルや大規模なドキュメントライブラリを接続すると、検索範囲が広すぎて応答が遅くなったり、期待した文書にヒットしにくくなったりします。(Microsoft Learn)
| 手順 | 作業内容 | 実務上のコツ |
|---|---|---|
| 1 | 対象サイト・フォルダーを選ぶ | まずは社内規程、FAQ、手順書など、短く構造化された文書群に絞る |
| 2 | 権限を棚卸しする | 管理者、一般社員、閲覧不可ユーザーの3パターンでテストする |
| 3 | FoundryプロジェクトにSharePoint接続を追加する | サイトURLまたはフォルダーURLを正しい形式で入力する |
| 4 | 接続IDを取得する | SHAREPOINT_PROJECT_CONNECTION_IDとして環境変数化する |
| 5 | エージェントにSharePointツールを追加する | sharepoint_grounding_previewを使ってツール定義を行う |
| 6 | 引用元付きで回答を検証する | 回答の正確性だけでなく、参照された文書が妥当か確認する |
| 7 | 検索範囲を調整する | 遅い、曖昧、ヒットしない場合はサイトやフォルダーをさらに絞る |
SharePoint接続で入力するURLは、アドレスバーからコピーした長いURLをそのまま使うと機能しない場合があります。公式ドキュメントでは、サイトURLはhttps://<company>.sharepoint.com/sites/<site_name>、フォルダーURLはhttps://<company>.sharepoint.com/sites/<site_name>/Shared%20documents/<folder_name>のような形式が例示されています。 (Microsoft Learn)
開発者がAPI側で見るべき最小構成は、SharePointツールのtypeとプロジェクト接続IDです。
{
"tools": [
{
"type": "sharepoint_grounding_preview",
"sharepoint_grounding_preview": {
"project_connections": [
{
"project_connection_id": "<SHAREPOINT_PROJECT_CONNECTION_ID>"
}
]
}
}
]
}Python、C#、JavaScript、Java、REST APIのサンプルが用意されているため、既存の開発スタックに合わせて検証できます。SDKの例では、Pythonはazure-ai-projects>=2.0.0、JavaScriptは@azure/ai-projects、Javaはcom.azure:azure-ai-agents:2.0.0などが前提として示されています。(Microsoft Learn)
管理者が見るべき影響範囲
SharePointの権限設計がそのままAI利用範囲になる
IDパススルーはセキュリティ上の大きな利点ですが、同時にSharePoint側の権限設計の品質が問われます。AIエージェント導入前に、少なくとも次の観点で対象サイトを確認してください。
| 確認対象 | チェック内容 |
|---|---|
| サイトメンバー | 不要な所有者・メンバー・閲覧者が残っていないか |
| 共有リンク | 「リンクを知っている全員」など広すぎる共有がないか |
| 全社共有 | Everyone except external users相当の共有が機密文書に使われていないか |
| 外部ユーザー | ゲストユーザーが対象ライブラリに残っていないか |
| 文書分類 | AI回答に使われても問題ない文書群か |
| 更新責任者 | 古い規程や廃止手順が残っていないか |
エージェントが間違った回答をしたように見えても、原因がAIではなく「古い文書が検索対象に残っていた」「文書名が似ていて最新資料より旧資料が拾われた」というケースは十分あり得ます。AI導入プロジェクトでは、モデル選定より先にコンテンツ整理を行うほうが効果的です。
Teams配布前提の設計には注意する
Foundryのエージェントアプリケーション自体はMicrosoft 365 CopilotやTeamsなどのチャネル配布と関係しますが、今回のSharePointツールについては、エージェントをMicrosoft Teamsに発行した場合にツールが機能しないと明記されています。SharePointグラウンディングを使うエージェントをすぐTeamsで全社展開する計画は、現時点では避けたほうが安全です。(Microsoft Learn)
実務では、まずResponses API経由で限定ユーザーに検証してもらい、検索精度、権限反映、引用元表示、応答速度を確認します。Teams配布を要件に含める場合は、SharePointツールの制約が変わったかを公式ドキュメントで再確認してから設計を進めてください。
OneDriveを使いたい場合はライセンスと用途を分けて考える
Microsoft 365 Copilot Retrieval APIは、SharePoint、OneDrive、Copilotコネクタからデータを取得できると説明されています。一方で、従量課金モデルではOneDriveなどのユーザーレベルのデータソースは使用できないとされています。(Microsoft Learn)
そのため、OneDrive上の個人作業ファイルをAIエージェントに活用したい場合は、次のように整理すると判断しやすくなります。
| シナリオ | 判断 |
|---|---|
| 部署の正式文書をAIで参照したい | OneDriveではなくSharePointライブラリへ集約する |
| 個人のOneDriveにある一時ファイルを参照したい | ライセンス条件とRetrieval APIの対応範囲を確認する |
| Copilotライセンスなしで従量課金を使いたい | OneDriveが対象外になる可能性を前提に設計する |
| 全社ナレッジ化したい | 個人OneDriveではなく、管理されたSharePointサイトへ移す |
AIエージェントの知識源として使うなら、「個人のOneDriveに散らばった資料」よりも、「所有者・更新責任・権限が明確なSharePointライブラリ」のほうが運用しやすくなります。
開発者がつまずきやすい実装ポイント
SharePointツールの実装で多い失敗は、コードそのものよりも認証・権限・URL・インデックスにあります。公式ドキュメントのトラブルシューティングでも、アプリ専用認証、ライセンス不足、テナント不一致、READ権限不足、検索範囲の広さ、インデックス遅延、URLパス誤りが代表的な問題として挙げられています。(Microsoft Learn)
| 症状 | 主な原因 | 対処 |
|---|---|---|
AuthenticationError: AppOnly OBO tokens not supported by target service | アプリケーションIDで呼び出している | ユーザーID認証、IDパススルー前提に変更する |
Forbidden: Authorization Failed - User does not have valid license | Microsoft 365 Copilotライセンスまたは従量課金設定がない | 対象ユーザーのライセンスと課金モデルを確認する |
| 401または認証エラー | SharePointとFoundryが別テナント | 同一Microsoft Entraテナント内で構成する |
| ツールが結果を返さない | ユーザーにREAD権限がない | 対象サイト・ライブラリ・文書の閲覧権限を確認する |
| 応答が遅い | 検索対象が広すぎる | サイト、ライブラリ、フォルダー単位で範囲を絞る |
| 文書取得が不完全 | Microsoft Search側でまだインデックスされていない | 新規文書は時間を置いて再検証する |
Resource not found | URLやライブラリパスが不正 | アドレスバーのURLではなく、指定形式のサイト・フォルダーURLを使う |
| 結果が安定しない | セマンティックインデックス同期の遅延 | 大量更新直後の評価を避け、同期後に再テストする |
また、SharePointツールはテキスト抽出を前提とします。Microsoft 365 Copilot Retrieval APIでは、画像やグラフなどの非テキストコンテンツからの取得はサポートされず、SharePointまたはOneDriveでのセマンティック・ハイブリッド取得は.doc、.docx、.pptx、.pdf、.aspx、.oneなどに限定されています。図表中心の提案書や、画像化されたPDFを大量に使う場合は、期待どおりの回答にならない可能性があります。(Microsoft Learn)
クラシック版からの移行で確認すること
既存環境でFoundryのクラシックエージェントや旧SharePointツールを使っている場合は、移行計画が必要です。Microsoft Learnのクラシック向けドキュメントでは、エージェント（クラシック）が非推奨となり、2027年3月31日に廃止されること、新しいMicrosoft Foundry Agents Serviceのエージェントを使うことが案内されています。(Microsoft Learn)
| 移行観点 | クラシック側で見直すもの | 新しい構成で確認するもの |
|---|---|---|
| エージェント基盤 | Microsoft Foundry classic agents | Microsoft Foundry Agents Service |
| SharePointツール | 旧SharePointツール、旧SDKサンプル | SharepointPreviewToolまたはsharepoint_grounding_preview |
| 接続管理 | 接続名や旧環境変数中心の実装 | SharePoint接続ID、SHAREPOINT_PROJECT_CONNECTION_ID |
| 認証 | 旧実装での前提 | ユーザーID認証、OBO、同一テナント |
| ファイル対応 | 旧ドキュメントの対応形式 | 現行のRetrieval API制限を確認 |
| 配布 | 既存の公開・利用チャネル | Teams利用可否、Responses API利用可否を再確認 |
移行時にありがちなミスは、「旧コードのクラス名や環境変数だけを置き換えて、権限設計を見直さない」ことです。新しいFoundryエージェントでは、発行状態によってエージェントIDやRBACの扱いも変わります。公開されたエージェントは一意のエージェントIDを持ち、ツール認証に使うIDが変わる場合はロール割り当ての再設定が必要です。(Microsoft Learn)
SharePointツール自体はユーザーID認証・IDパススルーが中心ですが、同じエージェントにMCP、A2A、Azure Storage、Logic Appsなど他のツールを組み合わせる場合は、エージェントIDに対する最小権限の割り当ても合わせて確認してください。
本番展開前の判断基準
現時点では、SharePointツールはプレビュー扱いです。公式ドキュメントでも、プレビュー機能はSLAなしで提供され、本番ワークロードには推奨されないと説明されています。そのため、全社本番導入ではなく、まずは限定用途の検証から始めるのが現実的です。(Microsoft Learn)
| 導入に向いているケース | まだ慎重に判断すべきケース |
|---|---|
| 社内規程、FAQ、手順書などテキスト中心の文書を参照する | 図表、画像、スキャンPDF中心の文書を参照する |
| 対象サイトやフォルダーを明確に絞れる | 全社SharePointを横断検索したい |
| ユーザー権限を使った回答制御が重要 | アプリ専用認証で一括処理したい |
| Responses APIで限定利用から始められる | Teams配布を必須要件にしている |
| Copilotライセンスまたは従量課金を整理できる | OneDriveを含むユーザーデータを課金条件未確認で使いたい |
| クラシック版から計画的に移行したい | 旧SDKや旧エージェント構成をそのまま延命したい |
本番前のチェックリストは次のとおりです。
| チェック | 確認内容 |
|---|---|
| 対象範囲 | SharePointサイトまたはフォルダーを最小限に絞ったか |
| 権限 | 管理者、一般ユーザー、閲覧不可ユーザーで回答差分をテストしたか |
| ライセンス | 開発者・利用者それぞれのCopilotライセンスまたは従量課金条件を確認したか |
| URL | site_urlを正しい形式で登録したか |
| 引用元 | 回答に使われた文書が妥当か、古い文書が混ざっていないか |
| 応答速度 | 検索範囲が広すぎて遅くなっていないか |
| ファイル形式 | 対象文書がテキスト抽出に向いているか |
| 配布先 | Teams発行を前提にしていないか |
| 移行 | クラシック版利用中の場合、2027年3月31日までの移行計画があるか |
| 監査 | 誰がどのエージェントを使い、どの範囲の文書を参照するか記録できるか |
まず何から始めるべきか
管理者は、最初にSharePointの対象サイトを1つ選び、権限と文書の棚卸しを行ってください。おすすめは、社内規程やITヘルプデスクFAQのように、内容がテキスト中心で、所有部署と更新責任者が明確なライブラリです。全社ポータルや個人OneDriveを最初の対象にすると、権限・品質・検索範囲の問題が同時に出やすくなります。
開発者は、FoundryプロジェクトにSharePoint接続を作成し、接続IDを使ってsharepoint_grounding_previewを設定します。そのうえで、閲覧権限の異なる複数ユーザーで同じ質問を投げ、回答内容と引用元が権限どおりに変わるかを確認してください。ここまで確認できれば、次に対象フォルダーの拡大、プロンプト設計、運用ログ、ユーザー教育へ進めます。
「Use SharePoint content with agent API」は、SharePoint / OneDrive時代の社内AI活用を進めるうえで有力な選択肢です。ただし成功の鍵は、APIをつなぐことではなく、SharePointの権限、文書品質、ライセンス、配布経路を先に整えることです。まずは小さなSharePointフォルダーで検証し、回答精度とアクセス制御が確認できた範囲から段階的に展開しましょう。
コメント