Microsoft 365 Copilotの宣言型エージェントにナレッジソースを追加する方法と管理者の注意点

Microsoft 365 Copilotで宣言型エージェントを作るとき、回答精度を左右するのは「どのナレッジソースを追加するか」です。2026年5月16日に更新されたMicrosoft Learnでは、Agent Builderで追加できるナレッジソースの種類、上限、権限、ライセンス、管理者が確認すべき制御が整理されています。結論としては、社内文書ならSharePoint、個人作業ファイルならOneDrive、会話や会議の文脈ならTeams、外部システムならCopilot connectors、短期検証なら埋め込みファイルを使うのが基本です。ただし、埋め込みファイルは権限管理の考え方がSharePointとは異なるため、機密情報を扱う場合は特に注意が必要です。(Microsoft Learn)

Microsoft 365 Copilotの宣言型エージェントは、単にプロンプトを保存する仕組みではありません。Agent Builderでナレッジソースを追加すると、エージェントは社内データ、Web情報、メール、Teams、外部システムなどを根拠として回答できるようになります。この記事では、公式情報をもとに「何が変わったのか」「どの範囲に影響するのか」「管理者・開発者が展開前に何を確認すべきか」を、実務で使える判断基準に落とし込んで解説します。

Microsoft 365 Copilotの宣言型エージェントでナレッジソース追加が重要な理由

Microsoft 365 CopilotのAgent Builderでは、自然言語でエージェントを説明するだけで、名前、説明、指示、ナレッジソース、スタータープロンプトなどを自動的に構成できます。手動で設定する場合も、ConfigureタブのKnowledgeセクションからソースを追加できます。(Microsoft Learn)

ここで重要なのは、ナレッジソースが「回答の根拠」を決めることです。たとえば、同じ「規程を要約して」と聞いても、総務部のSharePointサイトを参照するエージェントと、一般的なWeb検索を使うエージェントでは、返ってくる内容の正確性や社内適合性が大きく変わります。

特に社内利用では、次のような失敗が起きやすくなります。

• 社内規程を参照させたいのに、一般的なAI知識で回答してしまう
• SharePointファイルの権限が不足し、利用者によって回答内容が変わる
• 埋め込みファイルを使った結果、エージェント利用者に想定以上の情報が見える
• TeamsやOutlookを追加したものの、スコープ制御の制約を理解していない
• Web検索が管理者設定で無効化されており、期待した外部情報が使われない

つまり、ナレッジソース追加は「便利機能」ではなく、Microsoft 365 Copilotのエージェントを業務に出せる品質にするための設計作業です。

2026年5月16日更新の公式情報で押さえるべきポイント

今回の公式情報では、Microsoft 365 CopilotのAgent Builderで宣言型エージェントに追加できるナレッジソースとして、公開Webサイト、SharePoint、OneDrive、Teams、Outlook、埋め込みファイル、Peopleデータ、Copilot connectorsなどが整理されています。公開Webサイトは最大4件、OneDriveファイルは最大50件、TeamsチャットURLは最大5件、埋め込みファイルは最大20件といった上限も示されています。(Microsoft Learn)

実務上の変更点として見るべきなのは、「追加できるものが増えた」というより、どのナレッジソースを選ぶべきかを管理・開発・利用者の観点で判断しやすくなった点です。

観点	確認すべき内容	実務上の意味
ナレッジソースの種類	SharePoint、OneDrive、Teams、Outlook、Web、People、Copilot connectors、埋め込みファイルなど	エージェントの用途ごとに根拠データを設計できる
上限	Web URL最大4件、OneDrive最大50ファイル、Teamsチャット最大5件など	大量データを雑に追加するのではなく、サイト・フォルダー・コネクタ単位で設計する必要がある
権限	SharePointやOneDriveは既存の権限と秘密度ラベルを尊重	利用者によって参照できる情報が変わる
埋め込みファイル	エージェントに直接アップロードしたファイルは扱いに注意	機密資料のPoC投入はリスク確認が必須
管理者制御	Web検索、Copilot connectors、共有範囲、ライセンスが影響	作成者だけでなく管理者の事前確認が必要

Microsoft 365 Copilotのエージェントを業務展開する場合は、作成画面でソースを追加して終わりではありません。どのデータを、誰が、どの権限で、どの範囲に共有するかまで決めてから公開する必要があります。

追加できるナレッジソースの種類と選び方

Agent Builderで使えるナレッジソースは多いため、最初に「どのデータを根拠にしたいのか」を決めると迷いにくくなります。次の表は、実務での選定基準です。

ナレッジソース	向いている用途	主な注意点
公開Webサイト	製品ページ、公開FAQ、公式ドキュメントを参照するエージェント	URLは最大4件。深すぎるURLやクエリ付きURLは使えない
SharePoint	社内規程、部門ポータル、プロジェクト文書、ナレッジベース	既存権限と秘密度ラベルを尊重。Restricted SharePoint Searchが有効な場合は利用不可
OneDrive	個人が管理する作業ファイル、レビュー前の資料	共有・展開用途ではSharePoint化を検討した方がよい
Teams	チャネル、グループチャット、会議チャットの文脈を使う業務支援	特定チャットは最大5件。会議単位の細かなスコープには制約がある
Outlookメール	自分のメールをもとにした要約、返信支援、日次確認	Agent Builderではメールの細かなスコープ指定ができない
Peopleデータ	組織内の人物、役職、スキル、関係性を使った回答	Microsoft 365 Copilotライセンス利用者向け。個人情報の扱いに配慮
埋め込みファイル	短期検証、プロトタイプ、限定資料を使ったエージェント	アクセス制御と秘密度ラベルの確認が必須。Information Barriersは非対応
Copilot connectors	Jira、ServiceNow、GitHub、Confluence、Google Driveなど外部システム	管理者による有効化・接続設定・権限設計が必要

Microsoftの公式情報では、Copilot connectorsは外部の業務データをMicrosoft 365 Copilotに取り込み、ユーザーが検索・要約・推論できるようにする仕組みとして説明されています。同期型コネクタはMicrosoft Graphへインデックスし、フェデレーション型コネクタはMCPを使ってリアルタイムに取得するモデルです。(Microsoft Learn)

Agent Builderでナレッジソースを追加する基本手順

Microsoft 365 Copilotでエージェントを作る場合、自然言語で作成する方法と、Configureタブから手動設定する方法があります。自然言語で作成する場合、Agent Builderは説明文に基づいてナレッジソースを追加できます。たとえば「毎日のメールを要約し、添付ファイルも含める」と説明すると、メールをナレッジソースとして構成する例が示されています。(Microsoft Learn)

手動で追加する場合は、次の流れで確認します。

手順	操作	確認ポイント
1	Microsoft 365 CopilotでNew agentを選ぶ	自然言語で作るか、Skip to configureで手動構成するかを決める
2	ConfigureタブのKnowledgeセクションを開く	参照させたいデータの場所を先に整理しておく
3	Search、Enter URL、Browse、Uploadなどで追加	Teamsやメールは検索バー、SharePointやOneDriveはBrowseやURL指定が使える
4	必要に応じてSearch all websitesやOnly use specified sourcesを設定	Web検索や指定ソース優先の挙動を理解して選ぶ
5	Try itタブでテストする	利用者権限、回答根拠、引用、未参照データの有無を確認する
6	共有前に管理者設定と秘密度ラベルを確認	社内展開前のトラブルを防ぐ

手動構成では、URL入力、クラウドファイルの選択、デバイスからのアップロードなど複数の追加方法が用意されています。SharePointリンクは2階層までで、クエリパラメーターを含まない形式が求められるため、ブラウザーのアドレスバーからそのままコピーすると失敗する場合があります。(Microsoft Learn)

公開Webサイトを追加する場合の注意点

公開Webサイトをナレッジソースにすると、エージェントは特定のWebページ群を根拠に回答しやすくなります。製品ドキュメント、公開FAQ、規約ページ、サポートページなど、社外にも公開されている情報を参照させたい場合に向いています。

ただし、公開Webサイトには明確な制約があります。URLは最大4件までで、2階層を超えるURLやクエリパラメーター付きURLは無効です。たとえば、https://example.org/a/b/c のように深いURLや、?test=1 のようなパラメーター付きURLは使えません。(Microsoft Learn)

管理者側でWeb検索が無効化されている場合、エージェント側でWeb検索が有効に見えても、実際の回答にはWeb検索が含まれないことがあります。しかも、エージェント利用時に明確なエラーが出ないケースがあるため、展開前にテナント設定を確認しておく必要があります。(Microsoft Learn)

公開Webサイトを使うべきケース

公開Webサイトが適しているのは、次のようなケースです。

• 自社の公開サポートページをもとにFAQエージェントを作る
• Microsoft Learnやベンダー公式ドキュメントを参照させる
• 製品ページ、料金ページ、利用規約など公開情報を案内する
• 社内データではなく、外部公開情報の要約・案内をしたい

一方で、頻繁に変わるページや、ログインが必要なページ、検索結果ページのようにURLが複雑なページは不向きです。安定した公式ページを選ぶのが基本です。

SharePointとOneDriveを追加する場合の注意点

社内利用で最も重要なのは、SharePointとOneDriveです。Microsoft 365 Copilotのエージェントは、SharePointのサイト、ファイル、フォルダー、OneDriveのファイルをナレッジソースとして参照できます。SharePointファイルはエージェントごとに最大100件、OneDriveファイルは最大50件を選択できるとされています。(Microsoft Learn)

SharePointやOneDriveの大きな利点は、既存のアクセス権限と秘密度ラベルが尊重されることです。つまり、同じエージェントを使っても、利用者がアクセス権を持たないファイルの内容は回答に使われません。社内規程、営業資料、プロジェクト文書など、権限設計済みの情報を使う場合は、埋め込みファイルよりSharePointを優先するのが実務上安全です。(Microsoft Learn)

ただし、Restricted SharePoint Searchが有効な場合は、SharePointをナレッジソースとして使えないとされています。Microsoft 365 Copilotの情報アクセス範囲を制限しているテナントでは、エージェント作成前にこの設定を確認してください。(Microsoft Learn)

SharePointを使うべきケース

SharePointは、次のような用途に向いています。

• 社内規程・手順書・申請ルールを回答する総務エージェント
• 製品仕様書や提案書を参照する営業支援エージェント
• プロジェクトフォルダーを参照するPMOエージェント
• 部門ポータルを根拠に問い合わせ対応する情報システム部門エージェント

実務では、ファイルを個別に大量追加するよりも、用途ごとにSharePointサイトやフォルダーを整理し、そこを参照させる方が保守しやすくなります。ファイルの移動、削除、権限変更が頻繁に起きる場合は、エージェント側の更新だけでなく、SharePoint側の情報設計も見直しましょう。

Excelファイルを使う場合の注意点

Excelデータをナレッジソースにする場合、公式情報では、1つのブック内の1シートにデータがまとまっている方がエージェントの応答に適しているとされています。複数シートに分散した台帳、結合セルが多い表、見出しが途中に何度も出る表は、Copilotが意図した構造で理解しにくい場合があります。(Microsoft Learn)

エージェント用にExcelを整えるなら、次の形に近づけると効果的です。

• 1行目に列名を置く
• 1シートに主要データを集約する
• 結合セルを避ける
• 日付、担当者、状態、分類など検索に使う列を明確にする
• 補足説明は別シートではなく、列やコメントとして整理する

Excelをそのまま追加して精度が悪い場合、エージェントの設定よりもファイル構造が原因のことがあります。

Teamsデータを追加する場合の注意点

Teamsデータをナレッジソースにすると、Teamsチャット、会議情報、会議トランスクリプトなどをもとに回答できるようになります。特定のチャットにスコープすることも可能で、チームチャネル、グループチャット、会議チャットなどを選択できます。ただし、特定チャットとして追加できる数は最大5件です。(Microsoft Learn)

Teamsを使うと、プロジェクトの経緯や会議で決まったアクションを扱いやすくなります。たとえば、次のようなエージェントに向いています。

• プロジェクトチャネルの議論から決定事項を抽出する
• 会議チャットの内容をもとに次のアクションを整理する
• 特定チームの過去のやり取りから問い合わせ対応の文脈を補う
• 日次・週次の会議内容を要約する

注意点は、TeamsデータがMicrosoft 365 Copilotアドオンライセンスを持つユーザー向けの機能であることです。また、Agent Builderでは個別会議に細かくスコープすることに制約があり、すべての過去トランスクリプトへアクセスできるとは限らないと説明されています。(Microsoft Learn)

Outlookメールを追加する場合の注意点

Outlookメールをナレッジソースにすると、自分のメールボックスを根拠にしたエージェントを作れます。たとえば「未対応メールを整理する」「顧客からの依頼を要約する」「添付資料を含めて日次報告を作る」といった用途に向いています。

ただし、Agent Builderでメールを追加する場合、メールの細かなスコープ指定はできません。公式情報では、メールを追加すると自分のメールボックス内のすべてのメールがナレッジとして使われ、共有先のユーザーが作成者のメールをナレッジとして利用できるわけではないと説明されています。(Microsoft Learn)

このため、部署共通の問い合わせ対応や共有メールボックスを本格的に扱いたい場合は、Agent Builderだけで完結させるのではなく、Microsoft 365 Agents Toolkitや別の設計方法を検討した方がよい場合があります。公式のナレッジソース一覧では、Agents Toolkitを使う場合、メールのフォルダーや共有メールボックスを参照する構成例も示されています。(Microsoft Learn)

埋め込みファイルを使う場合は機密情報に注意

Agent Builderでは、デバイスからファイルを直接アップロードし、エージェントの埋め込みコンテンツとして使えます。埋め込みファイルは最大20件まで追加でき、Word、PDF、PowerPoint、テキスト、Excelなどのファイル形式がサポートされています。サイズ上限はファイル形式によって異なり、Word、PDF、PowerPoint、テキストは512MB、Excelは30MBとされています。(Microsoft Learn)

埋め込みファイルは、短期検証やプロトタイプには便利です。たとえば、まだSharePointに置いていない研修資料、検証用FAQ、限定的な説明資料を使ってエージェントの動作を試す場合に使えます。

一方で、機密情報を扱う場合は慎重に判断する必要があります。公式情報では、Microsoft Purview Information Barriersは埋め込みファイルではサポートされず、エージェントにアクセスできるユーザーは埋め込みファイルの内容を根拠にした回答を見る可能性があると説明されています。(Microsoft Learn)

埋め込みファイルを避けた方がよいケース

次のようなファイルは、埋め込みではなくSharePointに置いて権限とラベルを管理する方が安全です。

• 人事評価、給与、採用候補者情報
• 顧客との契約書、NDA、見積条件
• 未公開の製品ロードマップ
• 監査、法務、インシデント対応資料
• 部門外に公開すべきでない会議資料

埋め込みファイルは「ファイルをアップロードできるから安全に共有できる」という意味ではありません。エージェントの共有範囲と、ファイルに含まれる情報の機密度をセットで確認してください。

秘密度ラベルとアクセス権で確認すべきこと

埋め込みファイルに秘密度ラベルが付いている場合、エージェントの埋め込みコンテンツにもラベルが適用されます。複数のファイルを埋め込む場合は、最も優先度の高い秘密度ラベル、または組織の既定ラベルが適用されます。さらに、埋め込みコンテンツのラベルに対する抽出権限を持たないユーザーは、そのエージェントを利用できないと説明されています。(Microsoft Learn)

また、次のようなファイルはサポート対象外または失敗要因になります。

ファイルの状態	起きる可能性がある問題	対応
二重キー暗号化が有効	ナレッジとして使われない	アップロードを避ける
ユーザー定義権限付きの秘密度ラベル	エージェント作成に失敗する可能性	ラベル設定を確認し、別の共有方法を検討
抽出権限が無効	エージェント作成または利用に失敗する可能性	利用者の権限を確認
他テナントの暗号化ラベル付きファイル	ナレッジとして使われない可能性	自テナントで管理されたファイルを使う
パスワード保護ファイル	アップロード時にエラーになる	パスワード保護を解除せず、管理された場所で共有を検討

機密資料を扱うエージェントでは、作成者だけでなく、Microsoft 365管理者、情報保護担当、SharePoint管理者を含めて確認するのが安全です。

Copilot connectorsを使う場合の設計ポイント

Copilot connectorsは、Microsoft 365外の業務データをエージェントのナレッジとして使いたい場合に重要です。たとえば、Azure DevOps、Confluence、Google Drive、GitHub、Jira、ServiceNowなどのデータを、特定のプロジェクト、リポジトリ、フォルダー、ナレッジベースにスコープして使えます。(Microsoft Learn)

特に開発・運用部門では、SharePointだけでは情報が足りないことが多くあります。問い合わせチケットはServiceNow、課題管理はJira、ソースコード関連情報はGitHub、仕様メモはConfluenceというように、業務データが分散しているためです。

Copilot connectorsを使う場合は、次の観点で設計します。

確認項目	内容
接続対象	どの外部システムを使うか
スコープ	プロジェクト、リポジトリ、フォルダー、スペースなどで絞り込むか
権限	外部システム側のアクセス権をどう反映するか
管理者設定	Microsoft 365 admin centerでコネクタが有効化・設定済みか
検索品質	タイトル、本文、メタデータがCopilotに理解しやすい形か

Microsoftのコネクタ概要では、同期型コネクタはMicrosoft Graphにコンテンツを取り込んでセマンティックインデックスを活用し、フェデレーション型コネクタは外部サービスからリアルタイムに情報を取得すると説明されています。用途が「文書やナレッジの検索」なのか、「常に最新の外部データ取得」なのかで、選ぶ方式が変わります。(Microsoft Learn)

「指定したソースのみ」を使う設定の誤解に注意

Agent Builderには、指定したナレッジソースを優先するための「Only use specified sources」に相当する設定があります。これを有効にすると、ナレッジベース検索が必要な質問では、追加したSharePointファイルや埋め込みファイルなどを優先して回答します。該当情報が見つからない場合は、情報を見つけられない旨のフォールバック応答を返すと説明されています。(Microsoft Learn)

ただし、ここで大きな誤解が起きやすいです。この設定は、一般的なAI知識を完全にブロックするものではありません。公式情報では、Agent Builder in Microsoft 365 Copilotは一般的なAI知識をエージェントの回答から完全にブロックすることをサポートしておらず、より厳密な制御が必要な場合はCopilot Studioを使うよう案内されています。(Microsoft Learn)

たとえば、次のような使い分けが現実的です。

• 社内FAQや手順書を優先したい：Agent Builderの指定ソース優先を使う
• 回答を特定文書だけに厳格に限定したい：Copilot Studioで設計する
• 公開Webと社内文書を混在させたい：出典確認とテストプロンプトを必ず行う
• 法務・医療・金融など厳格な根拠管理が必要：Agent Builderだけでの展開は慎重に判断する

「指定したソースのみ」という名前から、完全な閉域RAGのように理解すると危険です。業務上の責任が大きいエージェントでは、回答根拠、フォールバック、一般知識の混入可能性をテストしてください。

管理者が展開前に確認すべき設定

Microsoft 365 Copilotのエージェントは、作成者が画面上で設定できても、テナント側の管理設定によって動作が変わります。管理者は、少なくとも次の項目を確認してください。

確認項目	なぜ重要か
Microsoft 365 Copilotライセンス	SharePoint、OneDrive、メール、Teams、Peopleなど一部ナレッジソースはライセンス要件がある
Web検索の有効化状態	管理者がWeb検索を無効化していると、Web検索が回答に含まれない
Copilot connectorsの有効化	外部システムを使うには管理センター側の設定が必要
Restricted SharePoint Search	有効な場合、SharePointをナレッジソースとして使えない
秘密度ラベルと抽出権限	埋め込みファイルやSharePointファイルの利用可否に影響する
Information Barriers	埋め込みファイルではサポートされないため、機密情報の扱いに注意
エージェント共有ポリシー	組織全体、特定ユーザー、共有禁止などの制御を確認する
既存共有エージェント	管理ポリシー変更後も既存共有が残る場合がある

エージェント共有については、Microsoft 365 Copilot上の共有は限定的な直接アクセス向けであり、正式な組織展開や複数チャネルへの公開にはCopilot Studioが必要と説明されています。また、管理者は組織全体への共有を全ユーザー、特定ユーザー・グループ、または無効に制御できます。(Microsoft Learn)

共有・公開時に失敗しやすいポイント

エージェント作成後の共有では、ナレッジソースの権限が問題になりやすいです。共有されたユーザーがエージェント自体にアクセスできても、根拠となるSharePointファイルにアクセス権がなければ、その内容は回答に使われません。公式情報では、SharePointのファイルやフォルダーは、作成者に共有権限がある場合に自動共有できる一方、サイト全体のアクセス権が自動的に付与されるわけではないと説明されています。(Microsoft Learn)

特に次の点に注意してください。

• 「エージェントを共有した」ことと「SharePointサイトを共有した」ことは同じではない
• SharePointファイルの共有に失敗しても、エージェント自体は共有される場合がある
• エージェントのアクセスを削除しても、別途共有済みのファイル権限は自動で消えない
• 共有済みエージェントを更新した場合、SharePointファイル・フォルダーの再共有が必要になることがある
• ZIPパッケージによる手動展開では、埋め込みファイルを含めることができない

このため、展開前テストでは「作成者本人」ではなく、実際の利用者ロールを持つテストユーザーで確認することが重要です。作成者だけでテストすると、権限不足や共有漏れに気づけません。

開発者が確認すべき移行・実装上の注意点

開発者がMicrosoft 365 Agents Toolkitやマニフェストを使って宣言型エージェントを構成する場合、Agent BuilderのUIとは異なる選択肢があります。公式のナレッジソース一覧では、Web検索、Scoped web search、Email、Teams messages、Dataverse、People、Meetingsなどで、マニフェストスキーマのバージョン要件が示されています。たとえば、Scoped web searchやDataverse、Email、Teams messagesではバージョン1.3以降、Meetingsではバージョン1.6以降が必要とされています。(Microsoft Learn)

開発者が特に確認すべきなのは、次の3点です。

UIでできることとマニフェストでできることを分ける

Agent Builderは素早く作るには便利ですが、細かなスコープ制御や外部システム連携ではAgents ToolkitやCopilot Studioの方が適している場合があります。たとえば、メールのフォルダー指定や共有メールボックス、会議IDによるスコープ指定などは、UIだけでは要件を満たせないことがあります。

ナレッジソースのスコープを狭くする

外部システムをコネクタでつなぐ場合、すべてのデータを対象にすると回答が曖昧になりやすく、権限確認も難しくなります。Azure DevOpsならArea path、ConfluenceならSpace、Google DriveならFolder、GitHubならRepository、JiraならProjectのように、業務単位でスコープする設計が有効です。(Microsoft Learn)

本番展開は共有ではなく公開プロセスを設計する

Microsoft 365 Copilot上の共有は、テスト、フィードバック、限定利用向けです。組織展開、チャネル連携、承認フロー、ライフサイクル管理が必要な場合は、Copilot Studioでの公開や管理プロセスを検討してください。(Microsoft Learn)

実務でおすすめのナレッジソース設計パターン

用途別に考えると、Microsoft 365 Copilotの宣言型エージェントは次のように設計すると失敗しにくくなります。

用途	推奨ナレッジソース	設計のポイント
社内規程FAQ	SharePointサイトまたはフォルダー	人事、総務、情シスなど部門別に分ける
プロジェクト支援	SharePointフォルダー、Teamsチャット	決定事項はSharePointに文書化しておく
営業支援	SharePoint、OneDrive、公開Webサイト	公開情報と社内提案資料を混在させる場合は出典確認を徹底
開発チーム支援	GitHub、Azure DevOps、Confluence、JiraのCopilot connectors	リポジトリやプロジェクトでスコープする
ITSM・問い合わせ対応	ServiceNow、SharePoint FAQ	チケット分類やナレッジベース単位で絞る
個人秘書型	Outlook、Teams、People	個人のライセンスとプライバシーに注意
PoC・短期検証	埋め込みファイル	機密情報を入れず、検証後はSharePoint化を検討

独自性を出すなら、「エージェントに何を読ませるか」よりも「回答に使ってよい情報の境界」を先に決めることが重要です。たとえば、社内規程エージェントにTeamsチャットまで読ませると、現場の未確定な会話が回答に混ざる可能性があります。逆に、プロジェクト支援エージェントでSharePoint文書だけを見せると、直近の会議決定が反映されないことがあります。

エージェント設計では、次の順序で考えると整理しやすくなります。

1. 回答させたい業務範囲を決める
2. 正式な根拠データをSharePointや外部システムに整理する
3. 補助情報としてTeamsやOutlookを使うか判断する
4. 機密情報は埋め込みファイルではなく権限管理された場所に置く
5. テストユーザーで回答差分を確認する
6. 限定共有か正式公開かを決める

展開前チェックリスト

Microsoft 365 Copilotの宣言型エージェントを社内に出す前に、次のチェックを行ってください。

チェック項目	確認内容
目的	エージェントが答える業務範囲は明確か
ナレッジソース	SharePoint、OneDrive、Teams、Outlook、Web、コネクタの選定理由があるか
権限	利用者ロールごとに参照できるデータを確認したか
秘密度ラベル	埋め込みファイルやSharePointファイルのラベルと抽出権限を確認したか
Web検索	テナントでWeb検索が許可されているか
コネクタ	管理者がCopilot connectorsを有効化・設定しているか
ライセンス	利用者が必要なMicrosoft 365 Copilotライセンスを持っているか
共有範囲	Only you、Specific users、Anyone in your organizationのどれにするか決めたか
テスト	作成者以外のテストユーザーで回答を確認したか
更新運用	ファイル変更、権限変更、エージェント更新時の再確認手順があるか

このチェックを省略すると、作成者の環境では正しく動くのに、利用者には回答できない、または想定外の情報が回答に含まれるといった問題が起きやすくなります。

まず何から対応すべきか

Microsoft 365 Copilotの宣言型エージェントにナレッジソースを追加する場合、最初にやるべきことは、エージェントの用途ごとに「正式な根拠データ」と「補助的に使うデータ」を分けることです。社内文書はSharePoint、個人作業はOneDrive、会話の文脈はTeams、外部業務データはCopilot connectors、短期検証は埋め込みファイルという考え方をベースにすると、設計がぶれにくくなります。

管理者は、Web検索、Copilot connectors、共有ポリシー、ライセンス、Restricted SharePoint Search、秘密度ラベルを確認してください。開発者は、Agent BuilderのUIで足りるのか、Agents ToolkitやCopilot Studioが必要なのかを見極める必要があります。

本番展開前には、必ず作成者以外のユーザーでテストし、回答根拠、権限差分、共有範囲を確認しましょう。Microsoft 365 Copilotのエージェントは、ナレッジソースを増やすほど賢くなるとは限りません。正しいデータを、正しい範囲で、正しい権限のもとに追加することが、実務で使えるエージェントを作る近道です。