Microsoft 365 CopilotのAgent Builderで、SharePointリストをエージェントのナレッジソースとして使えるようになります。結論からいうと、案件管理表、FAQ一覧、問い合わせ台帳、設備台帳、契約管理リストのような構造化されたSharePointリストの情報をもとに、ユーザーが自然言語で質問できるエージェントを作りやすくなる更新です。
ただし、今回のリリースでは「1エージェントにつき参照できるSharePointリストは1つ」「最大20,000アイテム」「リスト添付ファイルと参照列は未対応」という制限があります。管理者は、単に機能を有効活用するだけでなく、リストの権限、列設計、共有範囲、Agent Builderの利用制御を事前に確認しておく必要があります。Microsoft 365 Roadmapでは本機能はRoadmap ID 561920として掲載され、一般提供は2026年6月予定、状態は記事執筆時点でIn developmentです。ロードマップ情報は変更される可能性があります。(Microsoft)
Microsoft 365 CopilotのAI/Copilot更新で何が変わるのか
今回の「Microsoft Copilot (Microsoft 365): SharePoint list support in Agent Builder」は、Microsoft 365 CopilotのAgent Builderで作成するエージェントに、SharePointリストをナレッジソースとして指定できるようにする更新です。
従来のAgent Builderでは、SharePointのサイト、フォルダー、ファイル、Webサイト、Copilot connectorsなどをナレッジソースとして使う流れが中心でした。Microsoft Learnでは、Agent Builderは自然言語またはConfigureタブからエージェントを作成でき、ナレッジソースを指定してコンテキストに応じた回答を行うエージェントを構築できる機能として説明されています。(Microsoft Learn)
今回の変更により、ドキュメントだけでなく、行と列で整理されたSharePointリストのデータをエージェントの回答根拠にできる点が重要です。たとえば、ユーザーは「今月期限が近い契約は？」「ステータスが未対応の問い合わせを要約して」「A社に関する案件の現在の状況は？」といった質問を、リストを直接開いてフィルターする代わりにCopilot上で聞けるようになります。
| 項目 | 内容 |
|---|---|
| 対象機能 | Microsoft 365 CopilotのAgent Builder |
| 変更内容 | SharePointリストをエージェントのナレッジソースとして利用可能 |
| 主な用途 | 構造化されたリストデータに基づく質問応答 |
| リリース段階 | General Availability |
| 提供予定 | 2026年6月予定 |
| 対象クラウド | Worldwide Standard Multi-Tenant |
| 対象プラットフォーム | Desktop、Web |
| 主な制限 | 1エージェントにつきSharePointリスト1つ、最大20,000アイテム、添付ファイルと参照列は未対応 |
SharePointリストをナレッジソースにできるメリット
SharePointリストは、Excelのように見える一方で、Microsoft 365上のアクセス権、ビュー、列の型、Power Automate連携などを持つ業務データ基盤です。これをAgent Builderのナレッジソースにできると、社内の「表形式の業務情報」をCopilotから扱いやすくなります。
特に効果が出やすいのは、次のようなリストです。
| SharePointリストの例 | ユーザーが聞ける質問例 | 期待できる効果 |
|---|---|---|
| 問い合わせ管理リスト | 「未対応で優先度が高い問い合わせを教えて」 | 対応漏れの発見 |
| 案件管理リスト | 「今週更新があったA社の案件を要約して」 | 営業・PMの状況把握 |
| 社内FAQリスト | 「経費精算で領収書がない場合の対応は？」 | ヘルプデスク負荷の軽減 |
| 備品・資産管理リスト | 「貸出中のPCで返却期限を過ぎているものは？」 | 管理業務の効率化 |
| 契約管理リスト | 「来月更新期限を迎える契約を一覧にして」 | 契約更新の見落とし防止 |
ポイントは、単なる全文検索ではなく、列に意味があるデータを扱いやすくなることです。ステータス、担当者、期限、分類、金額、優先度などの列が整っているリストほど、エージェントの回答も実務に使いやすくなります。
既存のSharePointエージェントやCopilot Studioとの違い
今回の更新は「SharePointでエージェントを作る機能」や「Copilot Studioで高度なエージェントを作る機能」と混同しやすい内容です。導入前に、どの機能で何を作るべきかを整理しておきましょう。
Microsoftのサポート情報では、SharePointでもサイト、ライブラリ、リストなどからエージェントを作成でき、ユーザーがアクセスできるソースに基づいて回答することが説明されています。(Microsoft サポート) 一方、Agent BuilderはMicrosoft 365 Copilot上で宣言型エージェントをすばやく作るための機能で、より複数のMicrosoft 365体験に近い文脈でエージェントを作成・共有する用途に向いています。(Microsoft Learn)
| 目的 | 向いている機能 | 判断基準 |
|---|---|---|
| SharePointサイト内の情報を手軽に探したい | SharePointエージェント | 利用範囲が特定サイトやチーム中心 |
| Microsoft 365 Copilot上で業務別エージェントを作りたい | Agent Builder | 自然言語でエージェントを作り、社内ユーザーに共有したい |
| 外部API連携、ワークフロー実行、複雑な会話制御をしたい | Copilot Studio | 回答だけでなく処理実行や業務アプリ連携が必要 |
| 開発者が本格的な宣言型エージェントを構築したい | Microsoft 365 Agents Toolkit | パッケージ化、組織カタログ、複数チャネル展開が必要 |
今回のSharePoint list support in Agent Builderは、リスト作成を自動化する機能ではありません。既存のSharePointリストを、Agent Builderで作成したエージェントの知識として使う機能と理解すると誤解しにくくなります。
影響範囲：誰が何を確認すべきか
この更新は、Copilot利用者だけでなく、SharePoint管理者、Microsoft 365管理者、業務部門のリスト所有者にも影響します。特に、Copilotはユーザーのアクセス許可を前提に情報を扱うため、リストの権限設計がそのままエージェントの回答範囲に影響します。Microsoft 365 Copilotは、ユーザーが少なくとも表示アクセス許可を持つ組織データのみを表示し、SharePointなどのMicrosoft 365サービスのアクセス許可モデルを使うことが重要だと説明されています。(Microsoft Learn)
| 立場 | 主な影響 | 確認すべきこと |
|---|---|---|
| 一般ユーザー | リストを開かずに自然言語で情報を確認できる | 回答の根拠となるリスト、参照できる範囲、回答の限界 |
| エージェント作成者 | 業務リストを使ったエージェントを作成できる | リストの列設計、説明文、テスト質問、共有範囲 |
| SharePoint管理者 | リスト権限や情報設計の重要度が上がる | 過剰共有、古いリスト、機密列、添付ファイル依存 |
| Microsoft 365管理者 | Agent Builderとエージェント共有のガバナンスが必要 | Agent Builderの利用可否、共有・公開ポリシー、エージェント棚卸し |
| 開発者 | 軽量な質問応答はAgent Builderで実現しやすくなる | Copilot StudioやAgents Toolkitで作るべきケースとの切り分け |
管理者が最初に確認すべき設定
Agent Builderを誰に使わせるか
Agent Builderは便利ですが、全ユーザーが自由にエージェントを作成・共有できる状態が望ましいとは限りません。Microsoft Learnでは、管理者が組織内ユーザーにAgent Builderを利用可能にするか制御できること、またエージェント管理はMicrosoft 365管理センター側の管理機能と関係することが説明されています。(Microsoft Learn)
まずは、次の3段階で展開するのが現実的です。
| 段階 | 対象 | 目的 |
|---|---|---|
| 検証 | 情シス、Microsoft 365管理者、業務代表者 | 制限事項、権限、回答品質を確認 |
| パイロット | 1〜2部門のリスト所有者 | 実業務で使えるリストと質問パターンを検証 |
| 本番展開 | 利用ルールを理解した作成者 | 社内標準に沿ってエージェントを展開 |
最初から全社開放すると、似たようなエージェントが乱立したり、古いリストを根拠にした回答が広まったりする可能性があります。作成者を絞り、テンプレートとなる命名規則や説明文の書き方を決めてから広げる方が安全です。
エージェントの共有と公開の違いを確認する
Agent Builderで作成したエージェントは、共有と公開を分けて考える必要があります。Microsoft Learnでは、共有は特定ユーザーやグループへの限定的なアクセスに向いており、広範な展開や複数チャネルへの統合には公開が必要になると説明されています。(Microsoft Learn)
| 区分 | 用途 | 管理上の注意点 |
|---|---|---|
| 共有 | チーム内検証、限定利用、フィードバック収集 | 共有先と元リストの権限を両方確認する |
| 組織カタログへの公開 | 部門横断・全社利用 | 管理者レビュー、所有者、更新手順を決める |
| Copilot Studioでの公開 | 複数チャネル、外部連携、業務処理 | Power Platform側の環境・DLP・所有者管理も必要 |
管理者は、組織全体への共有を誰に許可するか、既存の共有済みエージェントをどう棚卸しするかを決めておきましょう。Microsoft Learnでは、テナント管理者がエージェント共有を「全ユーザー」「特定ユーザーまたはグループ」「なし」で制御できること、設定変更は新しい共有操作に適用され、既存共有は手動更新が必要であることも説明されています。(Microsoft Learn)
Microsoft 365管理センターでエージェントを棚卸しする
Microsoft 365のエージェント管理では、Copilot Control SystemやMicrosoft 365管理センターで、エージェントのアクセス、共有、公開、インベントリ、割り当てなどを管理する考え方が示されています。管理に必要なロールとしては、AI Admin、Global Admin、閲覧のみのGlobal Readerが挙げられています。(Microsoft Learn)
SharePointリスト対応を展開する前に、管理者は次を確認してください。
| 確認項目 | 見るべきポイント |
|---|---|
| Agent Builderの利用対象 | 誰がエージェントを作成できるか |
| エージェントインベントリ | 既存エージェントの所有者、公開範囲、利用状況 |
| ナレッジソース | SharePointリスト、ファイル、Web、コネクタの利用状況 |
| セキュリティとコンプライアンス | 機密情報、外部公開リスク、不要なエージェント |
| 所有者不在のエージェント | 異動・退職後も残るエージェントの扱い |
Microsoft Learnでは、エージェントの詳細画面でCapabilities、Knowledge、Actionsを確認し、ユーザーに割り当てる前にセキュリティとコンプライアンスを検討することが説明されています。(Microsoft Learn) SharePointリストを使うエージェントでは、特にKnowledgeにどのリストが入っているかをレビュー対象にしてください。
移行・展開前に見直すべきSharePointリスト設計
リストの列を「AIが理解しやすい名前」にする
エージェントの回答品質は、リストの情報設計に左右されます。列名が「備考1」「分類A」「区分2」のように曖昧だと、ユーザーの質問と列の意味が結びつきにくくなります。
改善例は次のとおりです。
| 悪い列名 | 改善例 | 理由 |
|---|---|---|
| 区分 | 問い合わせ種別 | 何を分類しているか分かる |
| 日付 | 回答期限 | 期限なのか登録日なのか明確 |
| 担当 | 担当部署 | 個人担当か部署担当か分かる |
| メモ | 対応履歴メモ | 回答に使う文脈が明確 |
| 状態 | 対応ステータス | 業務上の意味が伝わりやすい |
また、選択肢列の値も統一してください。「未対応」「未処理」「Open」「対応前」が混在していると、質問時に漏れが出やすくなります。ステータスや優先度は、業務部門と合意した選択肢に寄せるのが基本です。
20,000アイテムを超えるリストは分割や絞り込みを検討する
今回のリリースでは、1つのSharePointリストについて最大20,000アイテムまでが対象とされています。(Microsoft) すでに20,000件を超えているリスト、または短期間で超える見込みのあるリストは、そのままエージェント化しない方が安全です。
実務上は、次のような整理が考えられます。
| 状況 | 対応案 |
|---|---|
| 過去データが大量にある | 年度別・部門別にリストを分ける |
| 完了済みデータが多い | アーカイブ用リストへ移す |
| エージェントで使う範囲が限られる | 現行案件、未完了、直近年度などに対象を絞る |
| 全件横断が必須 | Agent Builderではなく、Copilot Studioや別の検索・連携設計を検討する |
「とりあえず全部入れる」よりも、エージェントの目的に合わせてリストを絞った方が回答品質は上がります。たとえば契約更新エージェントであれば、10年前の終了契約まで含めるより、現在有効な契約と更新予定契約に絞る方が実用的です。
添付ファイルと参照列に依存しているリストは注意する
今回の公式ロードマップでは、リスト添付ファイルと参照列はこのリリースでは未対応とされています。(Microsoft) これは実務上かなり重要です。
たとえば、問い合わせリストの本文は短く、詳細が添付PDFに入っている場合、エージェントは期待した回答を返せない可能性があります。また、顧客名や製品名を別リストへの参照列で管理している場合、その参照関係を前提にした回答がうまく機能しない可能性があります。
| リストの状態 | 起きやすい問題 | 対応策 |
|---|---|---|
| 添付ファイルに詳細資料がある | エージェントが詳細を根拠にできない | 主要情報をリスト列に転記する、または文書を別ナレッジソースとして扱う |
| 参照列で顧客マスタを参照 | 顧客情報の文脈が不足する | 必要な顧客名・分類をテキスト列として持たせる |
| 複数リストを前提に業務が成立 | 1つのリストだけでは回答が不完全 | Agent Builder以外の構成を検討する |
| 画像・PDF中心の台帳 | リストデータだけでは回答が浅い | 添付依存を減らし、列に要約情報を持たせる |
移行前には、「ユーザーが聞きたい答えが、本当にリストの列だけで説明できるか」を確認してください。ここを見落とすと、エージェントは作れたものの、現場から「肝心な情報が返ってこない」と評価されがちです。
エージェント作成者向け：実務で使える作成手順
対象リストを決める
最初の1本は、業務上よく参照され、かつ列構造が整理されているリストを選びます。おすすめは、FAQ、問い合わせ台帳、案件管理、タスク管理、備品管理のように、質問のパターンが想定しやすいリストです。
逆に、自由記述だらけのリスト、添付ファイル依存のリスト、複数リストの参照関係がないと意味が分からないリストは、最初の検証対象には向きません。
エージェントの目的を1つに絞る
1つのエージェントに多くの役割を持たせると、回答が曖昧になります。たとえば「営業支援エージェント」よりも、「進行中案件の状況確認エージェント」の方が、質問例も指示文も作りやすくなります。
エージェントの説明文には、次のように具体的な対象と範囲を書きます。
このエージェントは、営業部のSharePoint案件管理リストをもとに、進行中案件のステータス、次回アクション、期限、担当者を確認するためのものです。回答時は、案件名、顧客名、ステータス、期限、担当者を明記してください。不明な情報は推測せず、リストに情報がないことを伝えてください。
Microsoft Learnでは、Agent Builderで名前、説明、指示、ナレッジソース、スタータープロンプトを設定でき、説明や指示がエージェントの用途や動作を決める要素になると説明されています。(Microsoft Learn)
スタータープロンプトを現場の質問に寄せる
スタータープロンプトは、ユーザーに「何を聞けばよいか」を示す入口です。ここが抽象的だと利用されません。
| 悪い例 | 良い例 |
|---|---|
| リストについて教えて | 今週期限を迎える未完了タスクを担当者別にまとめて |
| 案件を検索して | A社に関する進行中案件のステータスと次のアクションを教えて |
| FAQを確認して | 交通費精算で領収書を紛失した場合の対応を教えて |
| 問い合わせ状況を出して | 優先度が高く、まだ未対応の問い合わせを一覧にして |
スタータープロンプトは、現場で実際に使う言葉に合わせることが大切です。リストの列名どおりの専門用語ではなく、ユーザーが普段使う表現を入れると定着しやすくなります。
テストは管理者アカウントだけで終わらせない
テスト時にありがちな失敗は、作成者や管理者のアカウントだけで確認してしまうことです。管理者は多くのデータにアクセスできるため、一般ユーザーで使ったときの回答範囲を見誤る可能性があります。
最低限、次のユーザーで確認してください。
| テストユーザー | 確認すること |
|---|---|
| リスト所有者 | 期待どおりの項目が回答に出るか |
| 一般利用者 | 自分がアクセス可能な情報だけが回答されるか |
| 閲覧権限が限定されたユーザー | 見えてはいけない項目が回答されないか |
| 対象外部門ユーザー | エージェントまたはリストにアクセスできない状態になっているか |
Microsoft Learnでは、エージェント共有時にユーザーが基盤となるSharePointナレッジソースへアクセスできない場合、そのコンテンツは回答に含まれないこと、またSharePointサイト全体へのアクセスが自動付与されるわけではないことが説明されています。(Microsoft Learn)
失敗しやすいポイントと対策
古いリストをそのまま使ってしまう
SharePointリストは長く使われるほど、古い列、使われていない選択肢、退職者名、過去部門名が残りがちです。この状態でエージェント化すると、Copilotの回答が「正しいが実務では使えない」ものになります。
対策は、エージェント化前にリストを棚卸しすることです。不要列の削除、列名の見直し、ステータス値の統一、古いアイテムのアーカイブを行ってからナレッジソースにしましょう。
権限の見直しを後回しにする
Copilotは基本的にユーザーの権限を尊重しますが、そもそもSharePointリストの権限が広すぎる場合、その広すぎる状態を前提に回答が返る可能性があります。Microsoft 365 CopilotはMicrosoft 365の既存のアクセス許可モデルを使うため、適切なユーザーやグループが適切なコンテンツにアクセスできるようにすることが重要です。(Microsoft Learn)
特に、次の列があるリストは注意してください。
| 機密になりやすい列 | 注意点 |
|---|---|
| 金額、単価、契約条件 | 部門外に見せてよいか確認 |
| 人事評価、面談メモ | Copilot対象にすべきか慎重に判断 |
| 顧客の個人情報 | 最小権限と利用目的を確認 |
| 障害・インシデント詳細 | 公開範囲と運用ルールを確認 |
| 未公開案件、商談確度 | 営業部門内でも閲覧範囲を分ける場合がある |
エージェントを作る前に、SharePointリスト自体のアクセス権を確認することが最優先です。
参照列や添付ファイル前提の業務を無理に載せる
公式ロードマップで未対応とされている添付ファイルや参照列を前提にしたリストは、無理にAgent Builderで使うより、設計を変えるか、別の実装方法を検討した方がよいです。(Microsoft)
たとえば契約管理で「契約書PDFの中身まで答えてほしい」場合、リストだけをナレッジソースにしても十分ではありません。契約書ファイルそのものを適切にナレッジソースへ含める設計や、Copilot Studioでの構成を検討する必要があります。
開発者・IT部門が考えるべき切り分け
Agent Builderは、軽量で素早く作れる点が強みです。一方で、すべての業務要件をAgent Builderで満たすべきではありません。Microsoft Learnでも、外部サービスと統合するActionsなど高度な機能が必要な場合はCopilot Studioを使う考え方が示されています。(Microsoft Learn)
| 要件 | Agent Builderで対応しやすいか | 推奨判断 |
|---|---|---|
| SharePointリストに基づく質問応答 | 高い | Agent Builderで検証 |
| リストの要約、抽出、確認 | 高い | Agent Builderで開始 |
| 複数リストを横断した業務判断 | 中〜低 | 構成を慎重に検討 |
| 外部CRMや基幹システムとの連携 | 低い | Copilot StudioやAgents Toolkitを検討 |
| 承認、登録、更新などの処理実行 | 低い | ワークフローやAPI連携が必要 |
| 厳密な監査・バージョン管理が必要 | 中 | 管理センターや開発基盤との併用を検討 |
開発者の視点では、今回の機能は「簡易RAGの対象にSharePointリストが加わる」と捉えると分かりやすいです。ただし、リストの行を業務データとして扱う以上、回答の正確性、権限、データ鮮度、列定義を無視できません。PoCで終わらせず、データ所有者と運用ルールまで決めることが重要です。
展開前チェックリスト
SharePointリスト対応のAgent Builderを社内展開する前に、次のチェックを行ってください。
| チェック項目 | 確認内容 | 未対応の場合のリスク |
|---|---|---|
| リストの所有者が明確か | 部門、管理者、更新責任者が決まっている | 古い情報をもとに回答する |
| リスト権限が適切か | 閲覧・編集・共有範囲が最小限か | 機密情報の過剰共有 |
| 列名が分かりやすいか | 業務上の意味が明確か | 回答の精度が下がる |
| 添付ファイル依存がないか | 主要情報が列に入っているか | 不完全な回答になる |
| 参照列依存がないか | 必要情報がリスト内で完結しているか | 文脈不足の回答になる |
| 20,000アイテム以下か | 件数と将来増加を確認したか | 制限に抵触する可能性 |
| エージェントの目的が明確か | 対象業務と回答範囲が絞られているか | 何でも屋になり使われない |
| 共有範囲を決めたか | 特定ユーザー、グループ、全社のどれか | 意図しない利用拡大 |
| 一般ユーザーでテストしたか | 権限差による回答の違いを確認したか | 本番後に情報不足や過剰表示が判明 |
| 更新・廃止ルールがあるか | 所有者変更、リスト廃止、エージェント更新手順 | 放置エージェントが増える |
よくある質問
SharePointリストを使えば、Excel台帳は不要になりますか？
すぐに不要になるわけではありません。ただし、複数人で管理する台帳、権限管理が必要な台帳、Copilotから質問したい台帳は、ExcelよりSharePointリストの方が向いている場合があります。特にステータス、期限、担当者、分類で整理された業務データは、SharePointリスト化する価値があります。
1つのエージェントで複数のSharePointリストを参照できますか？
今回のリリースでは、1エージェントが参照できるSharePointリストは1つとされています。ただし、他のナレッジソース種別と併用できることもロードマップに記載されています。(Microsoft) 複数リストを前提にした業務では、リスト統合、対象範囲の分割、Copilot Studioの利用を検討してください。
リストの添付ファイルも回答に使えますか？
このリリースでは、リスト添付ファイルは未対応です。(Microsoft) 添付ファイルに重要な情報が入っている場合は、主要な要約を列として持たせるか、ファイルを別のナレッジソースとして扱える設計を検討してください。
参照列を使っているリストは使えませんか？
リスト自体を使える可能性はありますが、参照列は今回のリリースでは未対応とされています。(Microsoft) 回答に必要な顧客名、製品名、部門名などは、テキスト列や選択肢列としてリスト内に保持するなど、エージェントが理解しやすい形に整えるのが現実的です。
Copilotの回答はそのまま業務判断に使ってよいですか？
重要な契約、金額、人事、法務、セキュリティに関わる判断では、Copilotの回答を最終判断にしないでください。エージェントはリスト情報をもとに回答を支援しますが、データの古さ、列の不備、権限、未対応機能の影響を受けます。最終判断は、リスト本体や業務責任者の確認と組み合わせるべきです。
まずは「使えるリスト」を1つ選び、小さく検証する
今回のSharePoint list support in Agent Builderは、Microsoft 365 Copilotを「文書を読むAI」から「業務リストを参照して答えるAI」へ広げる実用的な更新です。特に、問い合わせ管理、案件管理、FAQ、契約更新、備品管理のように、列で整理された情報を日常的に参照する業務では効果が出やすいでしょう。
一方で、制限事項を無視して展開すると、回答が不完全になったり、リスト権限の問題が表面化したりします。管理者はAgent Builderの利用対象、共有範囲、エージェント棚卸しを整え、作成者は列名、ステータス、添付ファイル依存、参照列依存を見直してから進めるべきです。
最初の一歩としては、全社展開ではなく、20,000アイテム未満で、添付ファイルや参照列に依存せず、所有者が明確なSharePointリストを1つ選ぶことです。そのリストで小さくエージェントを作成し、一般ユーザーの権限でテストし、回答品質と運用ルールを確認してから対象業務を広げていきましょう。
コメント