Microsoft Copilot StudioでSharePointコンテンツを生成的な回答に使う場合、最初に確認すべき結論は「SharePointのURLを生成回答ノードの知識ソースとして設定し、ユーザー認証・Dataverse検索・SharePoint権限を正しくそろえる必要がある」という点です。単にURLを追加するだけではなく、どの範囲のSharePointを検索させるか、Teamsでどう認証させるか、既存エージェントを再公開するかまで確認しないと、回答が返らない、想定外の情報を参照する、テストでは動くが本番で失敗するといった問題が起きやすくなります。
2026年5月7日時点で確認したMicrosoft Learnの公式情報では、トピック内の生成回答ノードでSharePointを知識ソースとして使う方法、認証済みユーザーとしてSharePointコンテンツを参照する仕組み、Teams展開時の注意点が整理されています。なお、Microsoft Learn上の当該ページは「Last updated on 2026-05-06」と表示されています。日本時間で運用確認する場合も、この版の情報を基準に設定を見直すのが安全です。(Microsoft Learn)
Microsoft Copilot StudioでSharePointコンテンツを生成的な回答に使うと何ができるのか
Microsoft Copilot Studioの生成回答ノードでは、SharePointサイトを知識ソースとして指定できます。ユーザーが質問したときに、該当するトピックで固定的な回答が用意されていない場合、エージェントは指定されたSharePoint URLとそのサブパスを検索し、見つかったコンテンツをもとに回答を生成します。(Microsoft Learn)
たとえば、社内規程サイトとして次のようなSharePoint URLを指定した場合を考えます。
contoso.sharepoint.com/sites/policiesこの設定により、従業員が「育児休業の申請期限は？」「出張精算で領収書が不要なケースは？」と質問したときに、Copilot StudioのエージェントがSharePoint上の規程ページや文書を参照して回答できます。
重要なのは、SharePointを使った生成回答は「誰でも全情報を参照できるAI検索」ではないことです。エージェント公開後の生成回答は、チャットしているユーザーの代わりに、エージェントに設定された認証を使ってSharePointへアクセスします。既定では、Copilot StudioやMicrosoft Teamsで作成されたエージェントは「Authenticate with Microsoft」を使う構成です。(Microsoft Learn)
つまり、実務上は次のように考えると分かりやすいです。
| 利用場面 | できること | 注意点 |
|---|---|---|
| 社内FAQ | SharePoint上の社内規程や手順書をもとに回答できる | ユーザーがSharePoint側で閲覧権限を持っている必要がある |
| 部門別問い合わせ対応 | 部門サイトごとに知識ソースを分けられる | URLの範囲を広げすぎると、回答対象が曖昧になる |
| 製品・サービス別ヘルプ | 変数を使って参照URLを動的に切り替えられる | 変数はURLの参照先を変えるだけで、URL構造や深さの制限は変えない |
| Teams内の社内チャットボット | Teams 1対1チャットでSharePointデータを使った回答が可能 | グループチャットやチャネルメッセージでは同じ変更がまだ利用できない |
今回の公式情報で押さえるべき変更点・明確化点
今回の公式情報で特に重要なのは、SharePointを生成回答ノードで使う際の「知識ソースの優先順位」「認証」「Teams展開」「Dataverse検索の前提」が明確に示されている点です。
トピック内の知識ソースがエージェント全体の知識ソースより優先される
生成回答ノードで定義したSharePoint知識ソースは、エージェントレベルの知識ソースより優先されます。エージェントレベルの知識ソースはフォールバックとして動作します。(Microsoft Learn)
これは、実務ではかなり重要です。
たとえば、エージェント全体には「社内ポータル全体」を知識ソースとして追加し、特定のトピックでは「人事規程サイト」だけを知識ソースに指定した場合、そのトピックでは人事規程サイトが優先されます。問い合わせ内容に応じて参照範囲を絞れるため、回答精度を上げやすくなります。
一方で、意図せずトピック側に古いSharePoint URLを残していると、エージェント全体の新しい知識ソースより古い情報が優先される可能性があります。既存エージェントを更新する際は、トピックごとの生成回答ノードに残っているURLも必ず確認してください。
SharePointを使った回答は会話トランスクリプトに含まれない
公式情報では、トピックレベルまたはエージェントレベルでSharePointを知識ソースとして使ったエージェントの応答は、会話トランスクリプトに含まれないと説明されています。(Microsoft Learn)
これは管理者や監査担当者にとって見落としやすいポイントです。問い合わせ履歴を後から分析したい場合、通常の会話ログだけを前提にすると、SharePoint由来の回答内容を十分に追跡できない可能性があります。
運用前に、次の点を整理しておきましょう。
| 確認項目 | 実務上の意味 |
|---|---|
| 監査ログで何を確認したいか | 誰が、いつ、どのエージェントを使ったかだけで足りるか |
| 回答内容の再現性が必要か | 問い合わせ対応や法務確認で、後から回答内容を確認する必要があるか |
| SharePoint側の更新履歴を追えるか | 回答元コンテンツが後から変更された場合に追跡できるか |
| 高リスク領域で使うか | 人事、契約、セキュリティ、医療、財務など誤回答の影響が大きい領域か |
高リスクの業務に使う場合は、回答に出典リンクを表示する設計や、最終判断は担当部門へ誘導する文言を入れる設計を検討すべきです。
Teams 1対1チャットでは手動認証なしでSharePointデータを使える構成がある
公式情報では、Microsoft Teamsチャット内でSharePointデータを使った生成的な回答を利用でき、手動認証を不要にできる方法が示されています。既に公開済みのエージェントでこの方法を使うには、「Authenticate with Microsoft」に再構成し、Microsoft Teamsへ再公開する必要があります。変更の反映には数時間かかる場合があります。(Microsoft Learn)
ただし、この変更はTeamsのユーザーとエージェント間の1対1チャットで利用可能とされており、グループチャットやチャネルメッセージではまだ利用できないと説明されています。(Microsoft Learn)
展開時は、次のようにテストパターンを分けると失敗を見つけやすくなります。
| テスト対象 | 確認すべきこと |
|---|---|
| Teams 1対1チャット | SharePoint由来の回答が返るか |
| Teamsグループチャット | 同じ挙動を期待していないか |
| Teamsチャネル | 1対1チャットと同じ前提で展開していないか |
| 権限のある一般ユーザー | 自分が閲覧できるSharePoint情報だけ回答されるか |
| 権限のないユーザー | アクセスできない情報が回答されないか |
| ゲストユーザー | SSO対応アプリでSharePoint生成回答が使えない前提を説明できているか |
管理者・開発者への影響範囲
管理者は認証方式とDataverse検索を先に確認する
SharePointを生成回答の知識ソースにするには、Copilot Studio環境でDataverse検索が必要です。Dataverse対応ファイルをエージェントに追加できない場合は、管理者が環境でDataverse検索を有効にする必要があります。(Microsoft Learn)
Dataverse検索は、Copilot StudioエージェントやCopilot体験がビジネスデータを理解・処理するための基盤として説明されています。構造化データと非構造化データの検索・AI活用を支える仕組みであり、Copilot Studioエージェントの知識ソース利用にも関係します。(Microsoft Learn)
管理者が最初に確認すべき項目は次のとおりです。
| 確認項目 | 判断基準 |
|---|---|
| Dataverse検索 | 対象環境で有効になっているか |
| 認証方式 | Teams、Power Apps、Microsoft 365 Copilotで使うならAuthenticate with Microsoftを基本に検討する |
| SharePoint権限 | 利用者ごとに適切な閲覧権限が設定されているか |
| Restricted SharePoint Search | 有効な場合、SharePoint利用がブロックされる前提で設計する |
| Microsoft Entra IDアプリ登録 | 手動認証時に必要なスコープを設定できているか |
| ゲスト利用 | SSO対応アプリではSharePointソースからの生成回答がゲストユーザーに提供されない点を周知する |
特に「No authentication」を選ぶと、エージェントはSharePointから情報を取得しないと公式情報で説明されています。SharePointの社内情報を使いたい場合、認証なしの構成は基本的に適しません。(Microsoft Learn)
開発者・作成者はトピック単位の参照範囲を設計する
Copilot Studioで実際にエージェントを作る担当者は、SharePoint URLをどこまで広げるかを慎重に決める必要があります。
公式情報では、指定したSharePoint URLとすべてのサブパスが検索対象になると説明されています。たとえば、contoso.sharepoint.com/sitesを指定すると、contoso.sharepoint.com/sites/policiesのようなサブパスも含まれます。(Microsoft Learn)
これは便利ですが、範囲を広げすぎると回答が不安定になります。実務では、次のように「広すぎるURL」を避けるのが基本です。
| URL設計 | 評価 | 理由 |
|---|---|---|
contoso.sharepoint.com/sites | 避けたい | 複数部門の情報を横断し、回答元が曖昧になりやすい |
contoso.sharepoint.com/sites/hr | 使いやすい | 人事領域に絞れる |
contoso.sharepoint.com/sites/hr/benefits | より精密 | 福利厚生FAQなど用途が明確な場合に向く |
| 変数で部門別URLを切り替える | 条件付きで有効 | 製品、地域、環境ごとに参照先を制御できる |
URLを決めるときは、「ユーザーがどんな質問をするか」ではなく、「どの情報だけを根拠に回答してよいか」から逆算するのがコツです。
生成回答ノードでSharePointを設定する手順
SharePointを生成回答ノードに追加する基本手順は、次の流れです。公式情報では、トピック内で生成回答ノードを追加し、データソース設定からSharePointを知識ソースとして追加する手順が示されています。(Microsoft Learn)
| 手順 | 操作 | 実務上のポイント |
|---|---|---|
| 1 | トピック内に生成回答ノードを追加する | 既存トピックに追加する場合は、固定回答との優先関係を確認する |
| 2 | 生成回答ノードのデータソース設定を開く | ノードの「編集」またはプロパティから開く |
| 3 | 「Add knowledge」を選ぶ | 「Search only selected sources」がオンになっているか確認する |
| 4 | FeaturedからSharePointを選ぶ | 他の知識ソースと混在させる場合は回答範囲を明確にする |
| 5 | SharePoint URLを入力する | 複数URLは手動改行で分ける |
| 6 | 名前と説明を入力する | 説明は生成オーケストレーションの助けになるため、用途まで書く |
| 7 | 保存する | トピック変更を保存し忘れない |
| 8 | 想定質問でテストする | 権限あり・権限なしの両方で試す |
設定時に「Integrated Security」が選択されていると、作成キャンバスやTopic Checkerでエラーが表示される場合があります。ただし、公式情報ではこのエラーは無害で、機能の動作を妨げないと説明されています。(Microsoft Learn)
とはいえ、本番展開前のレビューでは「無害な既知エラー」と「実際に回答できないエラー」を区別する必要があります。テスト質問でSharePoint由来の回答が返るか、対象ユーザーの権限で回答が変わるかを確認してください。
URL変数を使うと参照先を動的に切り替えられる
今回の公式情報では、SharePointまたは公開Webサイトの知識ソースURLに変数を使い、実行時に参照範囲を動的に変えられることも説明されています。1つの知識ソースに変数を挿入し、実行時に解決されたURLをグラウンディングに使う仕組みです。(Microsoft Learn)
たとえば、製品ごとにSharePointサイトが分かれている場合、次のような使い方が考えられます。
contoso.sharepoint.com/sites/support/{ProductArea}ユーザーの質問やトピック入力からProductAreaを決めれば、製品Aの質問は製品AのSharePoint、製品Bの質問は製品BのSharePointへ誘導できます。
ただし、変数は万能ではありません。公式情報では、変数は対象URLを変更するだけで、URL構造の要件や深さの制限を変えるものではないと説明されています。(Microsoft Learn)
実務では、次のような用途に向いています。
| 用途 | 具体例 | 注意点 |
|---|---|---|
| 製品別ルーティング | 製品名に応じて製品別サイトを参照 | 製品名の表記ゆれを吸収する設計が必要 |
| 地域・言語別切り替え | 日本語ユーザーは日本語サイト、英語ユーザーは英語サイト | 言語プロパティとURL体系を一致させる |
| 開発・検証・本番の切り替え | 環境変数で参照先を変える | 本番エージェントが検証用SharePointを参照しないよう注意 |
| 部門別FAQ | 人事、経理、ITでURLを切り替える | 権限設定とセットで設計する |
URL変数を使う場合は、「変数が空のとき」「想定外の値が入ったとき」「アクセス権がないURLに解決されたとき」の挙動もテストしてください。
認証設定で確認すべきポイント
Authenticate with Microsoftを使う場合
Teams、Power Apps、Microsoft 365 Copilot経由でエージェントに接続する場合、Copilot Studioは既定でMicrosoft認証を使ってユーザーを認証し、SharePointソースにアクセスする構成です。(Microsoft Learn)
Teams内で使う社内向けエージェントなら、まずこの構成を前提に検討するとよいでしょう。Teamsではユーザーが既にMicrosoft Entra IDで識別されているため、追加のサインイン負担を抑えやすくなります。
ただし、認証設定の変更は、エージェントを公開した後に反映されます。公式情報でも、認証構成の変更は公開後にのみ有効になるため、事前に計画する必要があると説明されています。(Microsoft Learn)
手動認証を使う場合
手動認証が必要な場合は、Microsoft Entra IDのアプリ登録やスコープ設定が重要になります。公式情報では、Microsoft Entra IDアプリ登録時にSites.Read.AllとFiles.Read.Allスコープを指定する必要があると説明されています。(Microsoft Learn)
また、SharePointは手動認証で次のプロバイダーをサポートしています。
| サポートされる手動認証プロバイダー |
|---|
| Microsoft Entra ID |
| Microsoft Entra ID V2 with federated credentials |
| Microsoft Entra ID V2 with certificates |
| Microsoft Entra ID V2 with client secrets |
一方で、SharePointはGeneric OAuthによる手動認証をサポートしていません。さらに、この認証設定は生成的な回答にのみ適用され、Power Platformコネクタには適用されない点にも注意が必要です。(Microsoft Learn)
開発者がよく混同するのは、「Copilot Studioの生成回答でSharePointを読む設定」と「Power PlatformコネクタでSharePointを操作する設定」です。両者は同じSharePointを扱っていても、認証や権限の考え方を同一視しないでください。
SharePoint知識ソースの制限と設計上の注意点
SharePointを知識ソースにすれば何でも回答できるわけではありません。Microsoft Copilot Studioの制限ページでは、SharePoint Webアプリの制限として、対応ページ、対応ファイル、リスト、ファイルサイズなどの条件が示されています。(Microsoft Learn)
| 項目 | 主な制限・注意点 | 実務での対処 |
|---|---|---|
| SharePointページ | モダンSharePointページのみ対応。クラシックASPXページは回答生成に使われない | 古い社内ポータルはモダンページへ移行する |
| SPFxコンポーネント | モダンページでもSPFxコンポーネントを含むものは未対応 | 重要情報は通常の本文や対応ファイルに配置する |
| 対応ファイル | DOC/DOCX、PPT/PPTX、PDFが対象 | 社内規程や手順書は対応形式に整理する |
| XLSX | SharePoint上の構造化ファイルを追加できるが、分析質問への回答は最適でない場合がある | 表計算の集計・分析は別機能との組み合わせを検討する |
| ファイルサイズ | Microsoft 365 CopilotライセンスとWork IQ利用で、SharePoint検索結果や最大200MBファイル対応の改善が説明されている | 大容量ファイルは分割や要約ページ化を検討する |
| ライセンスがない作成者 | Microsoft 365 Copilotライセンスが同一テナントにない場合、生成回答で使えるSharePointファイルは7MB未満とされる | 大きなPDFやPPTは分割する |
| URL形式 | 認識されるSharePoint URLはsharepoint.comドメイン。制限ページではhttps://を省くと説明されている | 入力形式を統一し、テストで確認する |
| ファイル名指定の質問 | 「file-name.pdfに書かれた内容は？」のようなファイル名参照の質問には回答できない | ユーザーには内容ベースで質問してもらう |
| SharePointリスト | リストクエリは最初の2,048行のみ。添付列の中身は推論対象にならない | リスト設計を見直し、必要情報を列に持たせる |
| リスト選択 | Add knowledgeダイアログでは1回のセッションで最大15リスト | 多数のリストは段階的に追加する |
| ゲストユーザー | SSO対応アプリではSharePointソースからの生成回答をゲストユーザーに提供できない | 外部ユーザー向けには別の知識ソースや公開情報を使う |
特にファイルサイズとページ形式は、導入時によく問題になります。社内では古いASPXページや大容量PDFが残っていることが多く、「SharePointにあるのに回答されない」という問い合わせにつながりやすいからです。
導入前に、対象SharePointサイトを次の観点で棚卸ししてください。
- 重要な情報がモダンページ、DOCX、PPTX、PDFに整理されているか
- 1ファイルが大きすぎないか
- ファイル名だけでなく、本文に検索されやすい説明が入っているか
- アクセス権限が部門・役職・雇用形態ごとに適切か
- 古いページや重複文書が回答元にならないよう整理されているか
SharePointソースを絞り込む設定も活用する
エージェントレベルでSharePointを知識ソースとして追加する場合、検索条件を設定して、SharePointソース内で検索する範囲を調整できます。公式情報では、タイトル、作成者、更新者、更新日などを条件に含めたり除外したりできると説明されています。(Microsoft Learn)
たとえば、次のような条件は実務で有効です。
| 目的 | 条件例 | 効果 |
|---|---|---|
| 古い情報を避ける | Modified on が過去6か月以内 | 最新の手順書やFAQを優先しやすい |
| 特定部門の文書に絞る | AuthorまたはModified byが部門管理者 | 管理された文書を参照しやすい |
| タイトルで絞る | Titleに「FAQ」「手順」「規程」を含む | 回答に使いたい文書群を狭められる |
| ユーザー入力で絞る | 会話中の変数を条件に使う | 部門名や製品名に応じて検索範囲を変えられる |
また、SharePointソースをフィルターする場合は、Web Search、エージェントレベルの一般知識、トピックレベルの一般知識利用をオフにすることが推奨されています。これにより、フィルターされたSharePoint知識ソースに結果がない場合、一般知識で補完せず「回答なし」とする挙動に近づけられます。(Microsoft Learn)
業務利用では、これは非常に大切です。社内規程や契約条件の問い合わせで、一般知識による「それらしい回答」が混ざると危険だからです。
移行・展開時に失敗しやすいポイント
既存エージェントは再公開を忘れやすい
既にTeamsへ公開済みのエージェントで、SharePoint生成回答を手動認証なしで使う構成へ変える場合は、Authenticate with Microsoftに再構成したうえでTeamsへ再公開する必要があります。反映には数時間かかる場合があり、会話中のユーザーは「start over」と入力することで最新バージョンの会話へ切り替えられると説明されています。(Microsoft Learn)
本番展開時は、ユーザー向け案内に次の一文を入れると混乱を減らせます。
更新後に回答が変わらない場合は、Teamsチャットで「start over」と入力して会話を再開始してください。日本語環境では、実際のユーザー案内としては次のように書くと自然です。
更新内容が反映されない場合は、チャットで「start over」と入力して会話を最初からやり直してください。作成者アカウントにSharePoint権限がない
公式情報では、copilotstudio.microsoft.comへサインインしているユーザーアカウントがSharePointサイトにアクセスできない場合、コンテンツが表示されない、またはシステムエラーが表示される可能性があると説明されています。(Microsoft Learn)
これはテスト段階でよく起きます。管理者はSharePointにアクセスできるが、エージェント作成者はアクセスできない。あるいは、開発者はアクセスできるが、実際の一般ユーザーはアクセスできない、というケースです。
対策として、最低でも次の3種類のユーザーでテストしてください。
| テストユーザー | 確認内容 |
|---|---|
| エージェント作成者 | 設定画面でSharePointソースを追加できるか |
| 一般利用者 | 必要な回答が返るか |
| 権限のない利用者 | 閲覧できない情報が回答されないか |
Restricted SharePoint Searchが有効な環境でブロックされる
公式情報では、Restricted SharePoint Searchが有効な場合、SharePointの使用はブロックされると説明されています。(Microsoft Learn)
セキュリティ強化のためにRestricted SharePoint Searchを有効化している組織では、Copilot Studio側だけを設定してもSharePoint知識ソースが機能しない可能性があります。導入前に、Microsoft 365管理者、SharePoint管理者、Power Platform管理者の間で設定方針を確認してください。
URL範囲が広すぎて回答がぼやける
SharePoint URLはサブパスも含めて検索されます。そのため、上位階層を指定すると、多くの部門サイトや古いページが対象に入る可能性があります。(Microsoft Learn)
よくある失敗は、社内ポータル全体を指定してしまうことです。最初は便利に見えますが、問い合わせ内容が「経費精算」なのに古いプロジェクト資料が参照されるなど、回答品質が落ちる原因になります。
おすすめは、最初から全社横断にせず、次の順で広げることです。
| フェーズ | 推奨範囲 |
|---|---|
| 検証 | 1部門、1用途、数十ページ程度 |
| 初期展開 | 人事FAQ、ITヘルプ、営業手順など用途別 |
| 拡張 | 変数やフィルターを使って部門・製品別に展開 |
| 全社展開 | 権限、監査、回答品質の運用ルールを整備してから |
実務で使いやすい活用シーン
社内規程FAQ
もっとも分かりやすい用途は、就業規則、福利厚生、経費精算、情報セキュリティ規程などの社内FAQです。
ユーザーは「有給休暇の繰越日数は？」「PCを紛失した場合の初動は？」のように自然文で質問できます。エージェントはSharePoint上の規程や手順書を根拠に回答します。
この用途では、一般知識を混ぜないことが重要です。社内規程は企業ごとに異なるため、Web Searchや一般知識で補完すると誤回答につながります。
ITヘルプデスク
Microsoft 365、VPN、端末申請、パスワード、Teams運用ルールなどをSharePointにまとめている企業なら、ITヘルプデスクの一次回答に向いています。
設計時は、問い合わせカテゴリごとにSharePoint URLを分けると回答精度が上がります。
| カテゴリ | SharePoint範囲の例 |
|---|---|
| アカウント | ID申請、退職者処理、MFA手順 |
| 端末 | PC配布、紛失時対応、交換申請 |
| Microsoft 365 | Teams、Outlook、OneDrive、SharePointの使い方 |
| セキュリティ | 標的型メール、USB利用、外部共有ルール |
製品別ナレッジ検索
製品マニュアルやサポート文書がSharePointに整理されている場合、URL変数を使って製品別に知識ソースを切り替える構成が有効です。
たとえば、ユーザーが最初に製品名を選択し、その値をもとにSharePoint URLを組み立てます。これにより、製品Aの質問で製品Bの文書が混ざるリスクを下げられます。
部門別ナレッジの段階展開
全社導入を急ぐより、部門ごとに小さく始めるほうが成功しやすいです。
最初に1部門でSharePoint文書を整備し、質問ログやユーザーフィードバックをもとに文書の不足を補います。その後、人事、経理、IT、営業企画などへ横展開します。
Copilot Studioのエージェント開発では、AIの回答設定だけでなく、SharePoint側の情報設計そのものが成果を左右します。古い文書、重複文書、タイトルが分かりにくい文書が多いと、生成回答の品質も安定しません。
管理者・開発者向けチェックリスト
本番展開前に、次のチェックリストを使って確認してください。
| チェック項目 | 確認済み |
|---|---|
| 対象環境でDataverse検索が有効になっている | □ |
| エージェントの認証方式を決めている | □ |
| Teams利用時にAuthenticate with Microsoftを使うか確認した | □ |
| 認証設定変更後にエージェントを再公開した | □ |
| SharePoint URLの範囲が広すぎない | □ |
| トピック内の知識ソースとエージェントレベルの知識ソースの優先関係を確認した | □ |
| 「Search only selected sources」を必要に応じてオンにしている | □ |
| SharePointの対象ページ・ファイル形式が対応範囲内である | □ |
| 大容量ファイルを分割または整理した | □ |
| Restricted SharePoint Searchの影響を確認した | □ |
| ゲストユーザーに提供できないケースを把握している | □ |
| 一般ユーザー、権限なしユーザー、管理者でテストした | □ |
| Teams 1対1、グループ、チャネルの違いをテストした | □ |
| SharePoint由来の回答が会話トランスクリプトに含まれない点を運用担当者に共有した | □ |
| 回答できない場合の問い合わせ先やフォールバック文言を用意した | □ |
まず何から始めるべきか
Microsoft Copilot StudioでSharePointコンテンツを生成的な回答に使う場合、最初にやるべきことは、エージェントの設定画面を開くことではありません。まず、回答に使わせたいSharePoint情報を棚卸しし、範囲、権限、鮮度を確認することです。
実務では、次の順番で進めると失敗を減らせます。
- 対象業務を1つに絞る
例：人事FAQ、ITヘルプ、経費精算など。 - SharePoint上の回答元を整理する
古いページ、重複文書、大容量PDF、非対応ページを確認します。 - Dataverse検索と認証方式を確認する
管理者が環境設定、認証、SharePoint権限を確認します。 - 生成回答ノードにSharePointを追加する
トピック単位でURLを絞り、必要に応じて変数やフィルターを使います。 - 権限別にテストする
管理者だけでなく、実際の一般ユーザーで動作を確認します。 - Teamsなどの利用チャネルへ再公開する
既存エージェントでは再公開と反映待ちを忘れないようにします。
SharePointを知識ソースにした生成回答は、社内文書を「検索しやすい情報」から「対話で使える情報」へ変える強力な機能です。ただし、AI側の設定だけでは品質は上がりません。SharePointの情報設計、ユーザー権限、認証、Dataverse検索、Teams展開まで含めて整えることで、現場で使えるCopilot Studioエージェントになります。
コメント