SharePointとCopilot｜Knowledge Agentと文書整備が回答品質を決める理由【2026年9月】

【結論】SharePoint Knowledge Agentとは、SharePointとOneDriveのファイルを、Microsoft 365 Copilotや宣言型エージェントが根拠情報として使える状態に整える機能と運用の総称です。

• 宣言型エージェントは「OneDriveAndSharePoint」という能力を追加するだけでSharePoint／OneDriveをナレッジにできる
• 対象URLを指定しないと、ユーザーが元々アクセスできる組織内のOneDrive／SharePointがすべて検索対象になる
• SharePoint／OneDriveの参照にはMicrosoft 365 Copilotのライセンスが必須で、無いユーザーは応答が失敗する

この記事ではMicrosoft 365とSharePointを所管する情シス・情報システム部門・業務部門の推進担当向けに、2026年9月時点の公開情報に基づいて解説します。

---

SharePoint Knowledge Agentとは

SharePoint Knowledge Agentとは、SharePointとOneDriveのコンテンツを、Copilotが回答の根拠として参照しやすい状態に整えるための機能領域です。宣言型エージェントの仕組みでは、マニフェストのcapabilitiesに「OneDriveAndSharePoint」オブジェクトを1つ追加するだけで、ユーザーのSharePoint・OneDriveをナレッジソースにできます。範囲はitems_by_url（絶対URLで指定）かitems_by_sharepoint_ids（サイトID・ライブラリIDなどのGUIDで指定）のどちらかで絞り込みます（出典：Add knowledge sources to your declarative agent – Microsoft Learn）。エージェントを賢くする作業の半分以上は、モデルの調整ではなくSharePoint側の文書整備です。

対象URLを指定しないと何が起きるか

公式ドキュメントは、items_by_urlとitems_by_sharepoint_idsの両方を省略した場合の挙動を明記しています。この場合、宣言型エージェントは「ユーザーがアクセスできる組織内のOneDriveおよびSharePointのすべてのコンテンツ」にアクセスできる状態になります。これはユーザーの既存の権限を超えるわけではありませんが、検索対象が一気に広がる点に注意が必要です。ある部門向けに作ったつもりのエージェントが、そのユーザーが読める全社のサイトから根拠を拾ってくることがあります。

これはMicrosoft 365 Copilot全体で以前から指摘されている「オーバーシェアリング」の問題と地続きです。個々のユーザーの権限設定自体は正しくても、AIが一括で読み上げて要約する対象になると、これまで気づかれなかった過剰共有が見えるようになります。宣言型エージェントを作るたびに範囲を確認する運用を、権限見直しのきっかけとしても使えます。特定サイト・特定ライブラリ向けに作るなら、items_by_urlで対象を明示することを実務上の既定にすべきです。

ライセンスと利用条件

SharePoint・OneDriveをナレッジとして使うには、利用するユーザー自身がMicrosoft 365 Copilotのライセンスを持っている必要があります。ライセンスが無いユーザーが問い合わせると、要求は失敗し「Sorry, I wasn’t able to respond」という応答になると公式が説明しています（出典：Add knowledge sources to your declarative agent）。主要な機能・知識ソースのライセンス要否は次のとおりです。

ライセンス未購入のまま「動くはず」で設計を進めると、検証段階で応答失敗が続き原因調査に時間を取られます。対象ユーザーのライセンス状況を先に確認してください。

文書側の整備チェックリスト

Copilotは参照した文書の品質を超える正確さを出せません。SharePoint側の整備が回答品質の土台になります。

進め方（現場向け5ステップ）

一般的なRAG構築の5ステップはRAG構築の進め方で解説しています。SharePoint整備はこの手順の「データ整備」フェーズそのものです。RAG一般の失敗要因として文書不備が大きな割合を占めることは、キヤノンITSの評価事例でも示されています。

Copilot全体設計との位置づけ

宣言型エージェントのSharePointナレッジは、Microsoft Copilot環境で構築するAgentic RAGの1つの入口にすぎません。単一サイトのFAQ対応であればここまでの整備で十分ですが、複数部署・複数システムをまたぐ調査が要件になると、SharePoint単体の検索では足りない場面が出てきます。より広いマルチソース検索を組み合わせたい場合は、Microsoft Copilot環境でAgentic RAGを構築するを参照してください。

Copilotが浸透しない・使われないという悩みは、モデルの性能不足ではなく文書整備の不足が原因であることが多いです。SharePointの整理は情シス単独では完結せず、各部署の文書オーナーに版管理と有効期限の運用を継続してもらう体制づくりが必要になります。業務への実装まで含めて整える場合はAI導入支援（AI BPR）の対象領域になります。

導入後の運用と点検

ナレッジ範囲を決めて公開した後も、点検を1回で終わらせないことが重要です。文書は日々追加・更新されるため、公開時の権限設定がそのまま数か月後も正しいとは限りません。四半期ごとに次の3点を確認する運用を組み込んでください。

この点検を情シスだけで回すのは負担が大きいため、文書オーナーである各部署と役割を分けるのが現実的です。棚卸しの頻度は、文書の更新頻度が高い部署ほど短くする判断も有効です。

---

よくある質問（FAQ）

---

参考文献・出典

• Add knowledge sources to your declarative agent – Microsoft Learn
• Declarative agent schema 1.2 for Microsoft 365 Copilot – Microsoft Learn
• キヤノンITS RAGテクニカルレポート

本記事は2026年9月時点の公開情報に基づいています。ライセンス条件・機能範囲は変化するため、最新情報は各公式ドキュメントをご確認ください。

---

x3d株式会社では、本記事で解説したSharePoint整備とCopilot定着に関する企業研修・導入支援・システム開発を提供しています。
まずはお気軽にご相談ください。

→ 無料相談・お問い合わせはこちら