Microsoft Copilot StudioでSharePointリストを知識ソースとして利用できるようになると、問い合わせ台帳、案件一覧、障害管理表、申請状況などの構造化データを、自然な日本語で検索・集計できるAIエージェントを作りやすくなります。
結論として、SharePointリストに業務データを蓄積しており、担当者が検索や集計に時間を取られている組織は、限定ユーザーでの検証を始める価値があります。一方、厳密な件数集計が必要な業務、大規模リスト、外部ゲスト向けの利用では、現時点の制限を踏まえて慎重に判断すべきです。
Microsoft 365ロードマップの項目566859は、日本時間の2026年7月8日に公開または実質更新されました。パブリックプレビューは2026年7月、一般提供は同年9月が予定されていますが、ロードマップ上の状態は「In development」であり、提供時期や仕様は変更される可能性があります。(Microsoft)
Microsoft Copilot StudioでSharePointリストを知識ソースにできる
「Microsoft Copilot Studio: Use SharePoint lists as a knowledge source」は、SharePointリストをCopilot Studioエージェントへ直接接続し、リスト内の行や列を回答の根拠として利用する機能です。
従来のSharePoint文書を使った検索だけでなく、次のような構造化データに対する質問が可能になります。
- 問い合わせ番号を指定して、現在の対応状況を確認する
- 未処理の申請件数を部門別に集計する
- チケットが完了するまでの平均日数を調べる
- 購入申請のうち、特定の商品に関する件数を数える
- 未解決案件が最も多いカテゴリーを特定する
公式ドキュメントでは、自然言語による検索やFAQ形式の回答に加え、集計・分析を伴う質問も想定されています。SharePointリストの現在のデータを使って照会するため、定期的に文書を書き出して再登録する運用を減らせる点が大きな利点です。(Microsoft Learn)
文書検索との違い
| 観点 | SharePoint文書を知識ソースにする場合 | SharePointリストを知識ソースにする場合 |
|---|---|---|
| 主なデータ | Word、PDF、ページ、手順書 | 行と列で管理された案件・申請・台帳 |
| 得意な質問 | 「手続き方法を教えて」 | 「未処理は何件あるか」 |
| データ更新 | 文書の更新内容を参照 | リストの現在の値を参照 |
| 集計 | 文書構成によっては難しい | 数値、状態、日付などを使った分析が可能 |
| 向いている用途 | 規程、マニュアル、FAQ | チケット、在庫、案件、進捗、申請管理 |
ただし、この機能はあくまで知識ソースから情報を検索・推論して回答する機能です。ロードマップや公式ドキュメントでは、リスト項目の新規作成や更新を中心機能として説明していません。エージェントからリストを書き換えたい場合は、Power Automate、コネクタ、エージェントのアクションなどを別途設計する必要があります。(Microsoft)
公開時期と対象環境
2026年7月19日時点のロードマップ情報は次のとおりです。
| 項目 | 内容 |
|---|---|
| ロードマップID | 566859 |
| 機能名 | Microsoft Copilot Studio: Use SharePoint lists as a knowledge source |
| パブリックプレビュー | 2026年7月予定 |
| 一般提供 | 2026年9月予定 |
| 開発状況 | In development |
| 対象クラウド | Worldwide（Standard Multi-Tenant） |
| 対象プラットフォーム | Web |
| 関連製品 | Microsoft Copilot Studio、Microsoft 365 Copilot |
ロードマップにはWorldwideの標準マルチテナント環境が記載されており、政府機関向けクラウドなどは対象として明記されていません。また、Microsoft 365ロードマップの日付は予定であり、テナントや展開リングによって実際の利用開始時期が異なる場合があります。(Microsoft)
利用前に確認すべき条件
ライセンスと課金
SharePointリストを接続できるからといって、すべてのMicrosoft 365ユーザーが追加条件なしで利用できるわけではありません。
Microsoft 365 Copilotのアドオンライセンスでは、認証されたユーザーがAgent BuilderやCopilot Studioを利用できます。Microsoft 365 Copilotライセンスを持たないユーザーに組織データを使ったエージェントを提供する場合は、Copilot Creditsや従量課金の設定が必要になることがあります。(Microsoft Learn)
導入前には、少なくとも次の3点を確認します。
- エージェント作成者がCopilot Studioを利用できるか
- 利用者にMicrosoft 365 Copilotライセンスがあるか
- ライセンスがない利用者について、従量課金を許可するか
実際の課金条件は、エージェントの公開先、利用者のライセンス、テナントの課金設定によって変わります。技術検証だけでなく、対象ユーザー数を基にした費用確認も必要です。
認証とSharePointアクセス権
SharePointリストの情報は、エージェント利用者自身のアクセス権に基づいて取得されます。利用者には対象サイトまたはリストに対する、少なくとも読み取り権限が必要です。
標準的な構成では「Authenticate with Microsoft」を使い、Microsoft Entra IDで認証されたユーザーとしてSharePointへアクセスします。エージェントに設定されたアプリ権限が、利用者本人のSharePoint権限を引き上げるわけではありません。(Microsoft Learn)
手動認証を設定する場合、公式ドキュメントではSites.Read.AllとFiles.Read.Allのスコープが案内されています。ただし、これらを設定しても、利用者が元々閲覧できないリストを参照できるようにはなりません。「認証なし」を選択した場合は、SharePointから情報を取得できません。(Microsoft Learn)
利用できない構成
次の環境では、そのまま利用できない、または制約が生じます。
| 条件 | 影響 |
|---|---|
| Restricted SharePoint Searchが有効 | SharePointを知識ソースとして使用できない |
| SSO対応アプリを外部ゲストが利用 | SharePointの生成回答はゲストユーザーに非対応 |
| 認証なしのエージェント | SharePointデータを取得できない |
| Generic OAuthによる認証 | SharePoint知識ソースでは対象外 |
| パスワードで保護されたファイル | 内容を回答に利用できない |
特にRestricted SharePoint Searchは、組織内検索の範囲を制限する移行措置として使われることがあります。これを有効にしているテナントでは、機能検証を始める前に、検索制限の目的とCopilot Studio導入の優先順位を整理する必要があります。(Microsoft Learn)
リスト数・行数・列に関する制限
SharePointリストを知識ソースにするときは、単に接続できるかではなく、期待する精度と応答時間を維持できるかを確認する必要があります。
| 項目 | 公式情報から読み取れる制限・目安 |
|---|---|
| 接続するリスト数 | プレビュー機能ページでは最大10リスト |
| 別の制限ページ | 最大15リストとの記載あり |
| 1リストの行数 | 最大35,000行を一つの目安として記載 |
| 全リストの合計 | 最大120,000行との記載あり |
| 大規模リスト | 行数増加に伴い精度低下や応答遅延の可能性 |
| クエリ対象行 | 制限ページには先頭2,048行のみ返すとの記載あり |
| 添付ファイル列 | 添付ファイルの内容はインデックスや推論の対象外 |
| リストビュー | ビュー自体は知識ソースとして選択できない |
| ルックアップ列 | 既定ビューに12列を超えるルックアップ列があるリストは非対応 |
| 用語集・同義語 | SharePointリストでは非対応 |
| ドキュメントライブラリ | SharePointリストとしては扱われない |
新しいプレビュー機能のページでは、最大10リスト、合計120,000行までの利用が説明されています。一方、Copilot Studio全体の制限ページには最大15リスト、さらにリストクエリは先頭2,048行を対象とするとの記載があります。公式ドキュメント間で上限の表現が一致していないため、現時点では最大値を本番設計の前提にしない方が安全です。(Microsoft Learn)
特に、数万行のリスト全体を対象にした厳密な集計を行う場合は注意が必要です。「接続に成功した」ことと「すべての行を正しく集計できた」ことは同じではありません。既知の正解を用意し、エージェントの回答とSharePoint側の集計結果を照合してください。
また、新しいプレビュー機能のドキュメントでは、GPT 5.4以降やSonnet系モデルで良好な結果を得やすいと案内されています。他の対応モデルでも利用できますが、回答品質に差が出る可能性があります。モデルを変更できる環境では、同じ評価用質問を使って比較することが重要です。(Microsoft Learn)
データ境界とセキュリティ
利用者の権限を越えて検索する機能ではない
SharePointリストを知識ソースとして接続した場合、エージェントは会話している利用者の資格情報を使って情報を取得します。利用者に閲覧権限がないデータを、エージェントが新たに開示する仕組みではありません。(Microsoft Learn)
ただし、ここで注意すべきなのは権限の迂回ではなく、既存の過剰共有が見つけやすくなることです。
例えば、全社員に読み取り権限が付いた人事案件リストがある場合、従来はリストの存在や列の意味を知らなければ情報を見つけにくかったかもしれません。AIエージェントを使うと、利用者が自然な質問をするだけで該当情報へ到達しやすくなります。
そのため、公開前に確認すべきなのはエージェントの共有範囲だけではありません。SharePointサイト、リスト、アイテムの権限そのものを先に見直す必要があります。
モデル学習への利用
Microsoftは、Microsoft 365 Copilotに送信されたプロンプト、応答、Microsoft Graph経由の組織データを、基盤LLMの学習には使用しないと説明しています。エージェントから利用する外部データについても、Microsoft 365 Copilotの基盤モデルを学習させる目的では使用されません。(Microsoft Learn)
これは「一切処理されない」という意味ではありません。回答生成のために質問や取得データが処理され、監査、保持、会話履歴などの組織設定も適用されます。
会話履歴に残る情報
SharePoint知識ソースを利用した会話では、回答生成に使った検索結果やソース文書の内容自体は、会話トランスクリプトの専用フィールドには含まれません。一方、利用者の質問とエージェントの回答は会話履歴に残ります。(Microsoft Learn)
したがって、エージェントがリスト内の個人情報や機密情報を回答文に含めた場合、その回答は履歴や監査対象になり得ます。「検索結果が保存されないから安全」と判断するのではなく、回答内容を含めた保持期間、監査権限、エクスポート範囲を確認してください。
Microsoft 365の既存ガバナンスを引き継ぐ
SharePointのアクセス権、秘密度ラベル、DLP、保持ポリシー、監査ログなど、Microsoft 365の既存の保護機能は引き続き重要です。Copilot Studioエージェントがデータに新しい権限を付与するわけではなく、基になるMicrosoft 365のデータ境界内で動作します。(Microsoft Learn)
管理者が確認すべき3つの管理レイヤー
SharePointリスト対応を安全に導入するには、SharePoint、Power Platform、Microsoft 365管理センターの3層で管理します。
| 管理レイヤー | 主な確認事項 |
|---|---|
| SharePoint | サイト・リスト・アイテム権限、共有リンク、機密列、Restricted SharePoint Search |
| Power Platform／Copilot Studio | データポリシー、認証、利用可能な知識ソース、コネクタ、HTTP接続、公開チャネル |
| Microsoft 365管理センター | エージェントの一覧、割り当て、許可、ブロック、削除、共有対象、課金設定 |
SharePoint側の管理
まず、対象リストについて次の項目を確認します。
- 本当に全メンバーへ読み取り権限を付与する必要があるか
- サイト権限を継承した結果、不要な利用者まで閲覧可能になっていないか
- 個人情報や機密情報を含む列が混在していないか
- アイテム単位の権限が意図どおり機能しているか
- 古い共有リンクや外部共有が残っていないか
リストの権限設計に問題がある場合、エージェント側だけで完全に補うことはできません。
Power Platform側の管理
Power Platform管理センターのデータポリシーでは、SharePointなどの知識ソースを環境またはテナント単位で許可・制限できます。認証方式、コネクタ、HTTP要求、公開チャネル、トリガーなども管理対象です。(Microsoft Learn)
必要に応じて、次のように環境を分離します。
| 環境 | 用途 |
|---|---|
| 開発環境 | 作成者が接続やプロンプトを試す |
| 検証環境 | 権限別テスト、精度評価、監査確認 |
| 本番環境 | 承認済みリストと限定された公開先のみ使用 |
Copilot StudioのセキュリティFAQでは、エージェント作成そのものを単純な一つの設定で全面停止するのではなく、データポリシーやチャット・公開の制御を使って実利用を管理する考え方が示されています。(Microsoft Learn)
Microsoft 365管理センター側の管理
Microsoft 365管理センターでは、エージェントの作成者、作成日、利用されるホスト製品、利用可能なユーザーなどを確認できます。管理者はエージェントを有効化、無効化、割り当て、ブロック、削除できます。(Microsoft Learn)
また、エージェントの共有対象を次のように制御できます。
- すべてのユーザー
- 指定したユーザーまたはグループ
- すべてのユーザーに対して無効
最初から全社公開するのではなく、対象部門のセキュリティグループへ限定して公開するのが安全です。
業務で効果を得やすい使いどころ
問い合わせ・障害管理
IT部門の問い合わせリストや障害管理リストは、相性のよい用途です。
質問例は次のとおりです。
- 「優先度が高く、未解決の問い合わせを担当者別に表示して」
- 「今月受け付けた障害のうち、対応中は何件ですか」
- 「問い合わせ番号INC-1048の現在の担当者と最終更新日を教えて」
- 「解決までに5営業日以上かかった案件の共通点を整理して」
状態、優先度、受付日、完了日、担当者などが個別の列に整理されているほど、回答の精度を高めやすくなります。
申請・調達管理
物品購入、アカウント発行、設備利用などの申請リストでは、申請者と管理者の双方に利用価値があります。
| 利用者 | 質問例 |
|---|---|
| 申請者 | 「私の申請で承認待ちのものはありますか」 |
| 担当者 | 「30日以上止まっている申請を表示して」 |
| 管理者 | 「部門別の申請件数と平均処理日数を教えて」 |
| 調達担当 | 「MacBookに関する購入申請は何件ありますか」 |
Microsoftの公式ドキュメントでも、調達申請件数や処理時間の集計が利用例として挙げられています。(Microsoft Learn)
プロジェクト・開発管理
SharePointリストで課題や変更要求を管理している開発チームでは、次の用途が考えられます。
- スプリント内の未完了課題を担当者別に確認する
- 重大度の高いバグを抽出する
- リリース対象の変更要求を一覧化する
- 期限を超過したレビュー項目を探す
- 類似する過去の障害や対応履歴を要約する
ただし、GitHub IssuesやAzure DevOpsが正式な管理元である場合、SharePointへ複製した古いデータを知識ソースにするべきではありません。エージェントが参照するデータは、業務上の正本であることが重要です。
リスク・監査・契約管理
リスク台帳、監査指摘、契約更新一覧にも活用できますが、回答をそのまま最終判断に使うのは避けるべきです。
例えば「今月更新期限を迎える契約」を調べる用途には向いています。一方、法的期限や金額を伴う確定処理では、元のリストを開いて確認する手順を残す必要があります。
開発では「検索」「処理」「確定」を分ける
業務エージェントを設計するときは、すべてを生成AIに任せず、役割を3つに分けると安定します。
| 役割 | 適した仕組み | 例 |
|---|---|---|
| 検索・説明 | SharePointリストの知識ソース | 対象案件の抽出、状況説明 |
| 処理・更新 | Power Automate、コネクタ、アクション | 担当者変更、承認依頼、項目更新 |
| 厳密な確定 | API、Dataverse、SQL、業務システム | 金額計算、法定期限判定、確定集計 |
例えば「未処理の購入申請を教えて」という質問には知識ソースを使い、「選択した申請を承認者へ送って」という処理にはPower Automateを使います。
件数や金額を必ず正確に出す必要がある場合は、自然言語による推論だけに任せず、フィルター条件を固定したAPIやフローで計算し、その結果をエージェントへ返す構成が適しています。
SharePointリストを追加する基本手順
Copilot Studioでの大まかな設定手順は次のとおりです。
- 対象のエージェントを開く
- 「Build」または作成画面から「Knowledge」を開く
- 知識ソースとしてSharePointを選択する
- 一覧からリストを選ぶか、リストのURLを貼り付ける
- 知識ソースの名前と説明を入力する
- 追加後、テスト画面で質問する
- 認証と公開先を確認して再公開する
「My Lists」には、Microsoft Listsアプリで作成したリストのみが表示される場合があります。目的のリストが見つからないときは、SharePointで一度対象リストを開いて「Recent Lists」から選ぶか、URLを直接貼り付けます。(Microsoft Learn)
知識ソースの説明を具体的に書く
知識ソース名を単に「問い合わせリスト」とするだけでは、複数のリストを接続したときにエージェントが使い分けにくくなります。
説明欄には、次のようにデータの意味と用途を記載します。
社内IT問い合わせの管理リスト。1行が1件の問い合わせを表す。問い合わせ番号、申請者、所属、受付日、優先度、状態、担当者、完了日を保持している。問い合わせの進捗確認、未解決件数、担当者別件数、平均処理日数の回答に使用する。
公式ドキュメントでも、知識ソースへ明確な名前と説明を付けることが、エージェントのオーケストレーションに役立つと案内されています。(Microsoft Learn)
列名もAIが理解しやすい名前にする
次のような列名は、人にもAIにも意味が伝わりにくくなります。
| 分かりにくい列名 | 改善例 |
|---|---|
| 状態1 | 申請状態 |
| 日付 | 受付日 |
| 日付2 | 完了日 |
| 担当 | 主担当者 |
| 区分 | 問い合わせカテゴリー |
| FLG | 対応期限超過フラグ |
列名だけで意味が分からない場合、回答に使用する列を誤る可能性があります。選択肢の値も、「1」「2」「3」ではなく、「未着手」「対応中」「完了」のように意味が分かる表現へ整えるのが効果的です。
本番公開前に実施するテスト
少なくとも、次のテストを異なる権限のユーザーで実施します。
| テスト | 質問例 | 確認すること |
|---|---|---|
| 単一項目検索 | 「REQ-1008の状態は」 | 正しい行を特定できるか |
| 条件抽出 | 「優先度が高い未解決案件」 | 複数条件が正しく反映されるか |
| 集計 | 「担当者別の未処理件数」 | SharePoint側の集計と一致するか |
| 日付計算 | 「平均処理日数」 | 空欄や未完了案件の扱いが適切か |
| 最新性 | 更新直後の項目を質問 | 現在の値を参照できるか |
| 権限 | 権限のないユーザーで質問 | 非公開項目が回答されないか |
| 該当なし | 存在しない番号を質問 | 推測で回答しないか |
| 大量データ | 全期間の件数を質問 | 遅延や一部行のみの集計がないか |
特に重要なのは、アクセス権を持つ管理者だけでテストしないことです。一般利用者、限定権限ユーザー、対象リストへアクセスできないユーザーでも確認します。
SharePointだけを根拠に回答させる
エージェントがSharePointリストに該当データを見つけられなかったとき、一般知識やWeb検索を使って回答すると、業務データと無関係な推測が混ざる可能性があります。
SharePointの情報だけを回答根拠にしたい場合は、Web検索、一般知識、トピック独自の知識利用を無効にします。この構成では、根拠が見つからないときに回答しない動作へ近づけられます。(Microsoft Learn)
業務エージェントでは、「回答できない」ことより「根拠のない回答を正しいように表示する」ことの方が危険です。該当情報がない場合は、次のような定型応答にします。
対象リスト内に回答の根拠となる情報が見つかりませんでした。問い合わせ番号または検索条件を確認してください。
よくある失敗と対処方法
| 症状 | 主な原因 | 対処 |
|---|---|---|
| リストが選択画面に出ない | My Listsの表示対象外 | リストを一度開く、Recent Listsを確認、URLを貼り付ける |
| 常に回答できない | 認証や読み取り権限がない | Microsoft認証とSharePoint権限を確認する |
| SharePointへ接続できない | Restricted SharePoint Searchが有効 | テナントの検索設定を確認する |
| 添付資料の内容を回答できない | 添付ファイル列が推論対象外 | 文書ライブラリを別の知識ソースとして追加する |
| 件数が実際と合わない | 大量行、2,048行制限、曖昧な条件 | 既知の集計結果と照合し、必要ならAPIで計算する |
| 回答が遅い | リスト数や行数が多い | リストを分割し、不要な列や対象期間を減らす |
| 関係のないリストを参照する | 知識ソースの説明が曖昧 | 名前と説明に対象業務・列・用途を書く |
| 機密情報が回答される | 元のSharePoint権限が広すぎる | サイト、リスト、アイテム権限を修正する |
| 存在しない情報を回答する | 一般知識やWeb検索へフォールバック | SharePoint以外の知識利用を無効にする |
対応要否を判断する基準
早期に検証した方がよい組織
次の条件が複数当てはまる場合は、限定的なパイロットを始める価値があります。
- 問い合わせ、案件、申請などをSharePointリストで管理している
- 「現在どうなっているか」という質問が担当者へ繰り返し届く
- 状態、日付、担当者などが明確な列に分かれている
- 主な利用者が組織内の認証済みユーザーである
- リストの権限とデータ品質を管理できている
- 回答の正否を確認できる担当者がいる
一般提供まで慎重に待った方がよい組織
次の用途では、プレビュー段階での本番利用を急ぐべきではありません。
- 法令、契約、会計に関する確定件数を回答させる
- 数万行以上を対象に厳密な全件集計を行う
- 添付ファイルが主要な情報源になっている
- 複数リスト間の複雑な結合が必要
- 外部ゲストへ提供したい
- Restricted SharePoint Searchを有効にしている
- SharePointの権限や共有状況を把握できていない
新しいエージェント体験は実運用を意識したプレビューとして案内されていますが、SharePointリスト機能自体はプレリリース情報を含み、仕様変更の可能性があります。一般提供前は、重要業務の唯一の確認手段にはせず、元リストを確認できる導線を残してください。(Microsoft Learn)
導入に向けて今行うべきこと
まず、問い合わせ台帳や申請一覧など、質問が多くデータ構造が比較的単純なSharePointリストを一つ選びます。続いて、アクセス権、列名、選択肢、空欄、重複行を確認し、開発または検証環境でエージェントへ接続します。
検証では、単一項目の検索だけでなく、集計、権限、該当なし、大量行、更新直後のデータを含む質問を用意します。回答精度と応答時間を記録し、正解が保証されなければならない処理はPower AutomateやAPIへ分離してください。
この機能の価値は、SharePointリストを接続すること自体ではありません。業務データを整理し、適切な権限の範囲で、職員や従業員が自然な言葉から必要な情報へ到達できる状態を作ることにあります。2026年9月の一般提供予定を待つだけでなく、今の段階で候補リストの整理と権限点検を進めておくことが、最も実務的な対応です。(Microsoft)
コメント