Microsoft Copilot StudioでSharePointをナレッジソースに追加する場合、重要なのは「SharePointサイトURLを使うのか」「SharePointリストを使うのか」「既存のファイル取り込み方式とどう使い分けるのか」を最初に決めることです。2026年5月時点の公式情報では、エージェントにSharePoint URLまたはSharePointリストを関連付け、ユーザーの権限に基づいて生成回答の根拠として使う流れが整理されています。(Microsoft Learn)
管理者や開発者が特に確認すべき点は、認証方式、SharePointのアクセス権、Work IQ、検索範囲、SharePointリストの制限、Teams展開時の再公開です。設定自体は難しくありませんが、権限や検索範囲を曖昧にしたまま公開すると、「期待した情報が返らない」「古い情報を参照する」「監査時に根拠を追いにくい」といった問題が起きやすくなります。
Microsoft Copilot StudioのSharePointナレッジソースで何ができるのか
Microsoft Copilot Studioの「Add SharePoint as a knowledge source」は、エージェントにSharePointサイト、SharePoint配下のURL、またはSharePointリストをナレッジソースとして追加する機能です。ユーザーが質問したとき、該当するトピックがない場合や生成回答ノードで指定された場合に、SharePoint上の情報を検索し、回答として要約します。SharePointサイトURLを指定すると、そのURLとサブパスが検索対象になります。(Microsoft Learn)
たとえば、社内規程サイトをナレッジソースにすると、従業員が「経費精算の締め日はいつですか」と質問した際に、SharePoint上の規程ページやPDFをもとに回答できます。SharePointリストを追加すれば、FAQ一覧、申請区分、問い合わせ分類、製品マスター、拠点情報など、表形式の業務データを会話の根拠として使えます。Microsoftの2026 release wave 1では、SharePointリストをナレッジソースとして利用する機能が2026年5月のパブリックプレビューおよび一般提供予定として示されています。(Microsoft Learn)
| 追加対象 | 向いている用途 | 実務上のポイント |
|---|---|---|
| SharePointサイトURL | 社内ポータル、規程サイト、部門Wiki、ナレッジベース | URL配下のサブパスも検索対象になるため、範囲を広げすぎない |
| SharePointリスト | FAQ、台帳、分類表、申請メニュー、拠点一覧 | リストのアクセス権と列設計が回答品質に直結する |
| 個別ファイル・フォルダー | 特定のPDF、Word、PowerPointを根拠にした回答 | 「ファイルアップロード欄のSharePoint」と混同しない |
| 生成回答ノード内のSharePoint | 特定トピックだけで参照先を変えたい場合 | トピックレベルのナレッジソースはエージェントレベルより優先される |
SharePointサイトURLをナレッジソースに追加する手順
SharePointサイトをナレッジソースに追加する基本手順は、エージェントを開き、「Add knowledge」からSharePointを選び、URL、名前、説明を入力して追加する流れです。URLは複数指定でき、複数URLを入れる場合は手動改行で区切ります。説明は生成AIのオーケストレーションにも使われるため、単に「社内情報」と書くのではなく、どのような質問で使うべき情報なのかを具体的に書くことが重要です。(Microsoft Learn)
| 手順 | 操作 | 実務メモ |
|---|---|---|
| 1 | Microsoft Copilot Studioで対象エージェントを開く | 本番エージェントではなく、まず検証用エージェントで試す |
| 2 | Overview、Knowledge、または生成回答ノードのPropertiesから「Add knowledge」を選ぶ | どこに追加するかで、全体利用かトピック限定利用かが変わる |
| 3 | Featuredセクションで「SharePoint」を選択する | ファイルアップロード欄のSharePointとは用途が異なる |
| 4 | SharePoint URLを入力する | 範囲が広すぎるURLは避け、部門・用途単位で分ける |
| 5 | 名前と説明を入力する | 「人事規程」「ITヘルプデスクFAQ」など、用途が分かる名前にする |
| 6 | 「Add to agent」で追加する | 追加後は想定質問で必ずテストする |
URLを指定するときは、SharePointサイト全体を雑に指定するよりも、回答に使わせたい情報が置かれている範囲に絞るほうが安全です。たとえば、contoso.sharepoint.com/sitesのように広い範囲を指定すると、複数部門の情報が混ざる可能性があります。社内規程なら規程サイト、IT問い合わせならIT部門のFAQサイトというように、業務単位でナレッジソースを分けると、回答のブレを抑えやすくなります。
また、公式の制限情報では、SharePointのURLはsharepoint.comドメインが認識対象であり、URL指定時にはhttps://を省く旨が示されています。画面上の入力ガイドやテナント側の挙動と合わせて確認し、認識されない場合はURL形式を見直してください。 (Microsoft Learn)
SharePointリストをナレッジソースに追加する手順
SharePointリストを追加する場合も、入口は「Add knowledge」からSharePointを選ぶ流れです。リストは「Browse items」から探すか、SharePointサイトまたはリストのURLを入力して指定できます。My ListsにはSharePoint Listsアプリで作成したリストが表示され、それ以外はRecent Listsに表示されます。目的のリストが出てこない場合は、一度SharePointでそのリストを開くとRecent Listsに表示されることがあります。(Microsoft Learn)
| 手順 | 操作 | 確認ポイント |
|---|---|---|
| 1 | エージェントで「Add knowledge」を選ぶ | 追加先がエージェント全体かトピック単位か確認する |
| 2 | Featuredセクションで「SharePoint」を選ぶ | リストを使う場合もSharePointから追加する |
| 3 | 「Browse items」またはURL入力でリストを探す | 共有リストが表示されない場合はURLを貼り付ける |
| 4 | 対象リストを選択する | 一度に選べるリストは最大15件 |
| 5 | 「Confirm selection」を選ぶ | 各リストは個別のナレッジソースとして追加される |
| 6 | 名前と説明を入力する | 列の意味や利用シーンを説明に入れる |
| 7 | テストチャットで確認する | 行・列の値を使った質問で期待どおり回答するか見る |
SharePointリストは、FAQや台帳のような表形式データに向いています。ただし、リストを追加すれば何でも分析できるわけではありません。公式の制限では、SharePointリストのクエリは最初の2,048行までが対象で、添付ファイル列の内容はインデックス化されず、リストビューはナレッジソースとして選択できません。また、既定ビューに12を超える参照列があるリストはサポートされないため、実運用前に列設計を見直す必要があります。(Microsoft Learn)
2つのSharePointオプションを混同しない
Copilot StudioのAdd knowledge画面には、SharePointに関係する選択肢が複数あります。今回の公式ページが扱うのは、FeaturedセクションのSharePointです。一方、ファイルアップロード欄にあるSharePointは、SharePoint上の個別ファイルやフォルダーを取り込み、Dataverse側で処理する用途です。Microsoft Learnでも、この2つは役割が異なるものとして説明されています。(Microsoft Learn)
| 比較項目 | FeaturedのSharePoint | ファイルアップロード欄のSharePoint |
|---|---|---|
| 主な用途 | SharePointサイトURL、SharePointリストをナレッジソースにする | SharePoint上の個別ファイル・フォルダーを取り込む |
| データの扱い | SharePoint側の情報を検索して使う | SharePointからDataverseにコピーし、インデックス化する |
| 鮮度 | 最新情報を使いやすい | 同期タイミングの影響を受ける |
| 向いているケース | 社内ポータル、Wiki、リスト、頻繁に更新される情報 | 特定の文書セットを高品質に検索したい場合 |
| 注意点 | URL範囲、認証、SharePoint Search、リスト制限を確認 | Dataverse容量、同期、ファイル数・サイズ制限を確認 |
判断基準はシンプルです。社内サイトやSharePointリストをそのまま業務チャットの根拠にしたいならFeaturedのSharePoint、特定のPDFやWord文書を厳選して使わせたいならファイルアップロード欄のSharePointを検討します。両方を同じ情報源に対して重ねて使うと、似た内容が複数ソースから返り、回答の根拠が分かりにくくなるため注意してください。
管理者が確認すべき認証・権限設定
SharePointをナレッジソースにする場合、認証は最重要項目です。SharePointを使った生成回答の呼び出しは、エージェントと会話しているユーザーの代わりに行われます。既定では、Copilot StudioやMicrosoft Teamsで作成されたエージェントは「Authenticate with Microsoft」が構成され、Microsoft Teams、Power Apps、Microsoft 365 Copilotなどの環境で利用できます。(Microsoft Learn)
手動認証を使う場合は、Microsoft Entra IDアプリ登録でSites.Read.AllとFiles.Read.Allのスコープが必要です。ただし、これらのスコープはユーザーの権限を増やすものではありません。エージェントは、SharePoint側でそのユーザーに許可されているコンテンツだけを参照します。No authenticationを選んだ場合、SharePointから情報を取得しない点も押さえておく必要があります。(Microsoft Learn)
| 確認項目 | 見るべきポイント | 失敗しやすい例 |
|---|---|---|
| 認証方式 | Authenticate with Microsoftか、手動認証か | Teams公開後に認証変更を反映し忘れる |
| Microsoft Graphスコープ | Sites.Read.All、Files.Read.All | スコープ不足でSharePoint結果が返らない |
| SharePointアクセス権 | ユーザーが対象サイト・リストを読めるか | 管理者だけ回答でき、一般ユーザーは回答できない |
| Restricted SharePoint Search | 有効化されていないか | SharePoint利用がブロックされる |
| ゲストユーザー | SSO有効アプリで利用できるか | ゲストに生成回答が返らない |
認証設定の変更は保存しただけでは反映されず、エージェントの公開が必要です。Microsoftの認証設定ドキュメントでも、認証構成の変更は公開後に有効になると説明されています。展開前には、管理者アカウントだけでなく、実際の利用者権限を持つ一般ユーザーでもテストしてください。(Microsoft Learn)
Teams展開で注意すべき点
SharePointを使うエージェントをMicrosoft Teamsに展開する場合、既存エージェントの認証方式を「Authenticate with Microsoft」に変更して再公開することで、Teamsチャット内で手動認証なしにSharePointデータを使った生成回答を利用できます。ただし、変更が反映されるまで数時間かかる場合があります。会話中のユーザーに反映されない場合は、チャットで「start over」と入力して会話を再開始することで、最新バージョンを使える場合があります。(Microsoft Learn)
注意したいのは、この変更がTeamsの1対1チャット向けであり、グループチャットやチャネルメッセージではまだ利用できないと説明されている点です。社内展開時に「Teamsで使える」とだけ案内すると、チャネル投稿で使おうとしたユーザーから問い合わせが増えます。利用可能なチャネルと会話形式を、社内マニュアルやリリースノートに明記しておきましょう。(Microsoft Learn)
Work IQを有効にするか判断する
SharePointを根拠にしたエージェントでは、Work IQを有効にすると検索取得と回答品質の向上が期待できます。Microsoft Learnでは、Work IQによりより多くのコンテキストを高い精度で取得できる一方、複雑性が増すため、一部のユーザーやクエリではわずかに遅延が増える可能性があると説明されています。(Microsoft Learn)
また、Work IQの設定には認証方式が関係します。Turn on Work IQは、エージェントのユーザー認証がAuthenticate with Microsoftに設定されている必要があります。Microsoft 365 Copilotライセンスが同一テナントにある場合、SharePointやコネクタに含まれる大きめのファイルを扱える条件も整理されています。応答品質を優先するヘルプデスクや社内検索エージェントでは有効化を検討し、速度が重要な単純FAQではテスト結果を見て判断するとよいでしょう。(Microsoft Learn)
| 判断軸 | Work IQを有効に向きやすいケース | 慎重に確認したいケース |
|---|---|---|
| 回答品質 | 複数文書を横断して根拠を探す | 単純な固定FAQだけを返す |
| コンテキスト量 | 規程、手順書、製品資料が多い | 情報量が少なく検索範囲が狭い |
| レイテンシ | 多少の遅延より正確性を優先する | 即時応答が重視される窓口 |
| 認証 | Authenticate with Microsoftで運用できる | 手動認証を前提にしている |
検索範囲はフィルターで絞り込む
SharePointナレッジソースでは、検索クエリパラメーターを使って検索対象を絞り込めます。指定できる条件には、Title、Author、Modified by、Modified onがあります。たとえば、過去6か月以内に更新された文書だけを検索対象にすれば、古い規程や廃止済み資料を回答に使うリスクを下げられます。(Microsoft Learn)
フィルターを使う場合は、Web Searchや一般知識の利用設定にも注意が必要です。公式情報では、SharePointソースをフィルターする場合、Web Search、エージェントレベルのUse general knowledge、トピックレベルの「Allow the AI to use its own general knowledge」をオフにすることで、フィルター済みSharePointに結果がないときに「no response」を返せると説明されています。(Microsoft Learn)
| 目的 | フィルター例 | 効果 |
|---|---|---|
| 古い文書を避ける | Modified onが一定日以降 | 更新済み情報だけを参照しやすくなる |
| 部門所有文書に限定する | AuthorまたはModified by | 管理部門やIT部門の文書に絞れる |
| 特定テーマだけ使う | Titleにキーワードを含める | 規程、手順、FAQなどを分けやすい |
| ユーザー入力で範囲を変える | 変数を条件値に使う | 部門や製品別の動的検索が可能になる |
実務では、最初から細かく絞り込みすぎると回答できる範囲が狭くなります。まずは対象サイトを適切に分け、そのうえで「更新日」「タイトル」「作成者」など、運用ルールとして守れる条件を追加するのがおすすめです。
変数URLで製品別・地域別・環境別に切り替える
SharePointまたは公開WebサイトのナレッジソースURLには、変数を挿入できます。これにより、複数のナレッジソースを作らなくても、会話中の条件に応じて参照先URLを切り替えられます。たとえば、製品名をトピック入力で受け取り、製品ごとのSharePointパスに変換して、該当製品の資料だけを検索させる設計ができます。(Microsoft Learn)
活用例は次のとおりです。
| 活用シーン | 変数の例 | 使い方 |
|---|---|---|
| 製品別サポート | Product | 製品名に応じて参照するSharePointフォルダーを変える |
| 地域別ナレッジ | Region | 日本、米国、欧州など地域別のサイトに切り替える |
| 言語別FAQ | User.Language | ユーザー言語に応じてローカライズ済みURLを使う |
| 環境別運用 | Environment | 開発、検証、本番のナレッジソースを分ける |
ただし、変数はURLの参照先を変えるだけです。URL構造の要件や深さの制限を無効化するものではありません。変数が不正なURLに解決されると結果が返らない可能性があるため、設定後は必ずテストチャットで実際に解決されるURLを確認してください。(Microsoft Learn)
トピックレベルとエージェントレベルの使い分け
Copilot Studioでは、エージェント全体にナレッジソースを追加するだけでなく、生成回答ノードの中でトピック単位のナレッジソースを指定できます。トピック内の生成回答ノードで定義したナレッジソースは、エージェントレベルのナレッジソースより優先され、エージェントレベルのソースはフォールバックとして機能します。(Microsoft Learn)
設計の目安は次のとおりです。
| 設計パターン | 向いているケース | 例 |
|---|---|---|
| エージェントレベルに追加 | どの質問でも共通して参照したい情報 | 全社規程、共通FAQ、IT基本手順 |
| トピックレベルに追加 | 特定業務だけ参照先を固定したい場合 | 経費精算トピックでは経理サイトだけ使う |
| 両方を併用 | 基本情報は全体、専門情報はトピックで補う | 全社FAQを全体、製品別FAQをトピック別に設定 |
よくある失敗は、全社サイトをエージェントレベルに広く追加し、その後でトピック別の情報を追加するケースです。この設計自体は可能ですが、回答の根拠が広がりすぎると、ユーザーの質問に対して別部門の古い資料が混ざる可能性があります。トピックで明確に対象が決まる業務は、生成回答ノード側に限定したナレッジソースを設定しましょう。
失敗しやすい制限と対策
SharePointを追加しても、すべてのSharePointコンテンツが期待どおり回答に使われるわけではありません。公式の制限では、サポートされるSharePointページやファイル形式、リストの行数、添付ファイル列、ゲストユーザー、手動認証との組み合わせなど、複数の注意点が示されています。(Microsoft Learn)
| つまずきやすい点 | 影響 | 対策 |
|---|---|---|
| クラシックASPXページは回答生成に使われない | 古い社内ポータルの情報が返らない | Modern SharePointページへ移行する |
| SPFxコンポーネントを含むページはサポート対象外 | カスタムWebパーツ内の情報を拾えない | 重要情報は本文や対応ファイルに整理する |
| 対応ファイル形式が限られる | 想定したファイルが検索対象にならない | DOC/DOCX、PPT/PPTX、PDF中心に整備する |
| ファイル名を指定した質問に答えられない | 「〇〇.pdfの内容を教えて」に弱い | 質問例を「〇〇の手順を教えて」に変える |
| SharePointリストは最初の2,048行が対象 | 大規模リストの後半データが使われない | リスト分割、ビュー設計、別データソースを検討する |
| 添付ファイル列は内容を推論できない | 添付PDFの中身が回答に使われない | 添付ではなく文書ライブラリや本文列に整理する |
| リストビューは選択できない | ビュー単位で絞り込めない | ナレッジソース側のフィルターやリスト分割を使う |
| 12を超える参照列がある既定ビューは非対応 | リストが期待どおり使えない | 既定ビューの参照列を12以下に調整する |
| SSO有効アプリのゲストユーザーに非対応 | 外部ユーザーに回答できない | 外部公開用途では別構成を検討する |
特に社内で多いのは、古いSharePointサイトをそのまま指定して「回答が出ない」と判断してしまうケースです。AI側の問題ではなく、ページ形式、検索インデックス、アクセス権、リスト構造が原因のことがあります。SharePoint管理者とCopilot Studio作成者が別チームの場合は、公開前に対象サイトの棚卸しを行いましょう。
移行時に確認すべきポイント
既存のエージェントで、アップロード済みファイルや古いSharePoint連携を使っている場合は、いきなり本番エージェントを切り替えないでください。まず、現在のナレッジソース、参照しているSharePointサイト、利用者、認証方式、Teams公開先を一覧化します。そのうえで、SharePoint URL方式にするのか、SharePointリストを追加するのか、ファイルアップロード方式を継続するのかを判断します。
| 移行作業 | 確認内容 | 判断基準 |
|---|---|---|
| 現行ソースの棚卸し | ファイル、URL、リスト、トピック別設定 | 重複や古い資料を削除する |
| 情報の整理 | 廃止文書、古いFAQ、未承認資料 | RAGに使ってよい情報だけ残す |
| 権限確認 | 一般ユーザー、管理者、ゲスト | 実利用者権限でテストする |
| 回答テスト | 想定質問、NG質問、曖昧な質問 | 根拠と回答の妥当性を見る |
| Teams再公開 | 認証変更後の反映 | 1対1チャットで確認する |
| ロールバック準備 | ナレッジソース無効化、旧版再公開 | 公開後の問い合わせに備える |
Microsoftの実装チェックリストでも、RAGに使うナレッジソースが正確で最新か、古い情報や禁止データが削除されているか、ファイルサイズやインデックスルールが各プロバイダーの制限に合っているかを確認することが求められています。SharePoint連携は「つなげたら終わり」ではなく、情報管理の運用まで含めて設計する必要があります。(Microsoft Learn)
展開前チェックリスト
本番公開前には、次の項目を確認してください。
| チェック項目 | 確認済み |
|---|---|
| 追加するSharePointサイト、リスト、ファイルの用途が明確になっている | |
| FeaturedのSharePointとファイルアップロード欄のSharePointを使い分けている | |
| SharePoint URLの範囲が広すぎない | |
| ナレッジソース名と説明が、生成AIに伝わる具体的な内容になっている | |
| 一般ユーザー権限でSharePointアクセスをテストした | |
Sites.Read.All、Files.Read.Allなど必要なスコープを確認した | |
| Restricted SharePoint Searchの影響を確認した | |
| Work IQを有効にするか、応答品質と遅延を比較した | |
| SharePointリストの行数、参照列、添付ファイル列を確認した | |
| Web Searchや一般知識を併用するか、SharePoint限定にするか決めた | |
| Teams公開後の再公開と反映確認を行った | |
| 想定質問と期待回答を用意し、公開前テストを実施した | |
| 期待しない回答が出た場合の問い合わせ窓口と修正フローを決めた |
実務でのおすすめ構成
社内利用で最初に導入するなら、次の構成が扱いやすいです。
まず、エージェントレベルには全社共通のFAQや規程サイトだけを追加します。次に、経費精算、人事手続き、ITヘルプデスクなど、業務ごとにトピックを分け、生成回答ノードで該当部門のSharePointサイトやリストを指定します。SharePointリストは、行数が多すぎないFAQや分類表から始めると検証しやすくなります。
回答品質を上げたい場合は、ナレッジソースの説明に「このソースは何を答えるためのものか」「どの質問では使わないか」を書きます。たとえば、単に「IT FAQ」ではなく、「社内PC、Microsoft 365、VPN、パスワードリセットに関する従業員向けFAQ。人事・経理・契約に関する質問には使用しない」と書くと、生成AIがソースを選びやすくなります。
また、SharePointを使ったエージェント回答は会話トランスクリプトに含まれないと説明されています。品質改善では、トランスクリプトだけに頼らず、ユーザーの質問、評価、テストセット、SharePoint側の更新履歴を組み合わせて確認しましょう。(Microsoft Learn)
まず何から始めるべきか
最初にやるべきことは、SharePoint側の情報整理です。Copilot Studioの画面で追加作業を始める前に、対象サイトやリストが最新で、ユーザー権限が正しく、AIに見せてもよい情報だけになっているかを確認してください。
そのうえで、検証用エージェントにSharePoint URLまたはリストを追加し、実際の利用者が聞きそうな質問でテストします。回答が不安定な場合は、ナレッジソースの説明、URL範囲、フィルター、SharePointリストの列設計、一般知識の利用設定を見直します。認証変更やTeams展開を伴う場合は、必ず再公開後の動作確認まで行いましょう。
Microsoft Copilot StudioにSharePointをナレッジソースとして追加する価値は、社内情報を会話で探せるようにすることです。ただし、成功するかどうかはAI設定だけでなく、SharePointの情報設計と権限設計に左右されます。小さな範囲で検証し、回答品質と運用負荷を確認してから、部門単位、全社単位へ広げていくのが安全です。
コメント