Microsoft 365 Copilot で業務データを根拠にした回答を作りたい場合、今回の「Add Dataverse tables as a knowledge source」は重要な確認ポイントです。結論から言うと、これは Copilot Studio のエージェントに Dataverse テーブルをナレッジソースとして追加し、テーブル内のデータを回答の根拠にできる機能です。
ただし、単にテーブルを選ぶだけでは安定した回答にはなりません。管理者は Dataverse search の有効化、エージェント認証、Dataverse のセキュリティロール、検索対象列、容量消費、プレビュー機能の扱いを事前に確認する必要があります。2026年6月26日更新の Microsoft 公式ドキュメントでは、移行期限や廃止期限は明記されていませんが、設定不足があるとテーブルを追加できない、回答に反映されない、検索品質が上がらないといった問題につながります。(Microsoft Learn)
Microsoft 365 Copilot で Dataverse テーブルをナレッジソースにする意味
「Add Dataverse tables as a knowledge source」は、Microsoft Copilot Studio で作成するエージェントに Dataverse テーブルを追加し、そのテーブル内の業務データをもとに回答させるための機能です。Microsoft 365 Copilot から利用するエージェントを設計する場合、SharePoint や Web サイトだけでなく、Dataverse に蓄積された顧客、案件、申請、在庫、問い合わせ履歴などの構造化データを回答の根拠にしやすくなります。
公式ドキュメントでは、Dataverse テーブルをナレッジソースとして統合すると、エージェントがテーブル内のデータに基づいて回答できるようになり、テーブルや列に対してシノニムや用語定義を追加する流れが示されています。さらに、Dataverse テーブルをナレッジとして使うには Dataverse search が必要で、エージェントの認証方式は「Authenticate with Microsoft」である必要があります。(Microsoft Learn)
実務上は、次のような用途で効果が出やすい機能です。
| 活用シーン | 具体例 | 向いている理由 |
|---|---|---|
| 営業・顧客対応 | 案件、取引先、問い合わせ履歴をもとに状況を確認する | Dataverse に構造化されたレコードがあり、権限管理もしやすい |
| 社内申請・承認 | 申請ステータス、承認者、締切日を確認する | テーブルの列と業務用語を対応付けやすい |
| サポート業務 | 製品、契約、問い合わせ分類をもとに回答を補助する | 用語集やシノニムを追加すると質問意図を拾いやすい |
| Dynamics 365 連携 | 営業、カスタマーサービス、フィールドサービスのデータを使う | Dataverse を基盤にした業務データをそのまま活用しやすい |
一方で、「Dataverse にあるからすべて Copilot に読ませる」という設計は避けるべきです。検索対象が広すぎると、回答品質、容量消費、権限設計、運用責任のすべてが複雑になります。
2026年6月26日更新で確認すべき主なポイント
今回確認すべきポイントは、機能追加そのものよりも「前提条件」と「検索品質を上げる設定」です。公式ページの最終更新日は 2026年6月26日で、Dataverse テーブルをナレッジソースとして追加する手順、シノニムと用語集、複数行テキスト列やファイル列に関するプレビュー機能、既知の制限が整理されています。(Microsoft Learn)
| 確認項目 | 内容 | 管理者・作成者への影響 |
|---|---|---|
| Dataverse search | Dataverse テーブルのナレッジ利用に必要 | 環境で無効だとテーブル追加や回答利用に影響する |
| 認証方式 | 「Authenticate with Microsoft」が必要 | No authentication、Authenticate manually はこの用途では非対応 |
| 権限 | 元データにアクセスできる権限が必要 | 権限不足だとテーブルが表示・選択できない可能性がある |
| テーブル数 | 1つのナレッジソースに最大15個の Dataverse テーブルを追加可能 | 業務単位でテーブルを絞り込む設計が必要 |
| シノニム・用語集 | テーブル名や列名と、ユーザーの自然な質問を結び付ける | 回答精度を左右する重要なチューニング項目 |
| 複数行テキスト・ファイル列 | プレビューとして非構造化推論を利用可能 | 本番利用では制限と変更可能性を考慮する |
特に重要なのは、Dataverse の列名がそのまま利用者の言葉と一致しないケースです。たとえば列名が cr_123_abc のようなシステム寄りの名前になっている場合、AI はそれが「出発地」なのか「便名」なのかを自然には判断できません。公式ドキュメントでも、数値やコードのように意味が伝わりにくい列では、列の説明を追加して AI が解釈できるようにする例が示されています。(Microsoft Learn)
影響範囲：誰が何を確認すべきか
この更新の影響は、Copilot Studio の作成者だけにとどまりません。Dataverse search、Power Platform 環境、セキュリティロール、容量管理が関係するため、複数の担当者で確認する必要があります。
| 担当者 | 確認すべきこと | 失敗しやすいポイント |
|---|---|---|
| Microsoft 365 管理者 | Microsoft 365 Copilot から使うエージェントの公開範囲 | エージェントを公開しても、認証や共有設定が不十分で利用できない |
| Power Platform 管理者 | Dataverse search の状態、環境設定、容量 | 検索インデックスの容量消費を見落とす |
| Copilot Studio 作成者 | ナレッジソース、説明文、シノニム、用語集 | テーブルを追加しただけで、業務用語の調整をしない |
| Dataverse 管理者 | テーブル、列、Quick Find view、検索対象列 | 必要な列が検索対象になっておらず回答に使われない |
| セキュリティ担当者 | セキュリティロール、データアクセス、共有範囲 | 権限が広すぎる、または狭すぎて実運用で回答できない |
| 業務部門 | 実際の質問例、用語、判断ルール | 作成者だけで用語集を作り、現場の言葉とずれる |
Dataverse search は、Copilot Studio エージェントや Microsoft 365 Copilot で動作するエージェントなど、Dataverse をデータソースとして使う AI 体験を支える基盤です。Microsoft の説明では、Dataverse search は構造化データと非構造化データのインデックスを扱い、Copilot Studio エージェントなどの生成 AI 体験に使われます。(Microsoft Learn)
設定変更で最初に確認すること
Dataverse テーブルを Microsoft 365 Copilot 向けエージェントのナレッジとして使う前に、次の順番で確認すると手戻りを減らせます。
Dataverse search が有効か確認する
Dataverse テーブルをナレッジソースとして追加するには、対象環境で Dataverse search が利用できる必要があります。Dataverse search の設定状態は、Power Platform 管理センターの環境設定から確認します。
Dataverse search の設定は、単なる検索バーの表示だけではありません。設定が Off の場合、Dataverse search に依存する Copilot Studio のナレッジ利用や生成 AI 体験にも影響します。Microsoft の説明では、Dataverse search を Off にすると、Copilot Studio エージェントでファイルのアップロードや Dataverse テーブルの選択ができず、該当データに基づく回答が利用できないとされています。(Microsoft Learn)
| Dataverse search の状態 | 実務上の意味 |
|---|---|
| On | グローバル検索と Dataverse search を使う AI 体験で利用しやすい |
| Default | 環境や体験によって Dataverse search が使われる場合がある |
| Off | Dataverse search に依存する検索・AI 体験が利用できない |
既存環境では、管理者が「検索バーを使っていないから Off でよい」と判断している場合があります。しかし Copilot Studio の Dataverse ナレッジでは、エージェントの回答基盤として Dataverse search が関係します。検索UIの要否だけで判断せず、AI エージェントの利用予定まで含めて確認してください。
エージェント認証を「Authenticate with Microsoft」にする
Dataverse テーブルをナレッジソースとして使う場合、Copilot Studio エージェントの認証は「Authenticate with Microsoft」にする必要があります。公式ドキュメントでは、No authentication と Authenticate manually はこのナレッジソースではサポートされないと説明されています。(Microsoft Learn)
「Authenticate with Microsoft」は Microsoft Entra ID 認証を使う方式で、Teams + Microsoft 365 チャネルへの公開にも関係します。Microsoft の認証設定ドキュメントでは、このオプションを選ぶと Teams + Microsoft 365 チャネルを利用でき、Teams 内では通常、ユーザーに追加サインインを求めない構成になると説明されています。(Microsoft Learn)
確認手順は次のとおりです。
| 手順 | 操作 |
|---|---|
| 1 | Copilot Studio で対象エージェントを開く |
| 2 | Settings から Security を開く |
| 3 | Authentication を選択する |
| 4 | Authenticate with Microsoft を選ぶ |
| 5 | 保存後、エージェントを公開して反映する |
注意点として、既存エージェントが手動認証を前提にトピックを作っている場合、変数や認証フローの見直しが必要になることがあります。認証方式を変えるだけで終わらせず、テスト会話で実際のユーザー権限を使って確認することが重要です。
Dataverse のセキュリティロールを確認する
Dataverse テーブルを追加できるかどうか、また回答時にどのデータを参照できるかは、ユーザーや作成者の権限に左右されます。公式ドキュメントでは、適切な権限がない場合、セットアップ時にテーブルが表示または選択できない可能性があるとされています。(Microsoft Learn)
Dataverse のセキュリティロールは、ユーザーがどのデータを表示・操作できるかを制御します。Microsoft の説明では、セキュリティロールに含まれるアクセスレベルと権限の組み合わせによって、ユーザーが見られるデータや操作範囲が決まります。(Microsoft Learn)
実務では、次の3種類のユーザーでテストするのが安全です。
| テストユーザー | 確認すること |
|---|---|
| 管理者 | テーブル追加、検索対象列、ナレッジ設定ができるか |
| 標準利用者 | 本来見えるべきデータだけ回答に使われるか |
| 権限のない利用者 | 見えてはいけないデータが回答に出ないか |
「管理者では正しく動くが、一般ユーザーでは回答できない」という問題はよく起こります。これは Copilot の不具合ではなく、Dataverse の権限設計や検索対象設定が原因であることが多いです。
検索品質を上げるにはシノニムと用語集が重要
Dataverse テーブルを追加しただけでは、ユーザーの自然な質問とテーブル構造がうまく結び付かないことがあります。たとえば、業務部門のユーザーが「失注した案件」と質問しても、Dataverse 側ではステータス値が「Canceled」「Not qualified」「Closed」など別の表現になっているかもしれません。
このずれを埋めるのが、シノニムと用語集です。Microsoft の関連ドキュメントでも、作成者がデータ構造とユーザーの質問の仕方を理解し、シノニムや定義を追加することで Copilot の回答品質を改善できると説明されています。(Microsoft Learn)
| 追加する情報 | 例 | 期待できる効果 |
|---|---|---|
| シノニム | 「顧客」=「取引先」「アカウント」 | ユーザーの言い換えを拾いやすくする |
| 用語定義 | 「失注案件」= ステータスが不成立またはキャンセルの案件 | 業務上の判断ルールを回答に反映しやすくする |
| 列の説明 | cr_status_code は申請ステータスを表す | システム列名の意味を AI が解釈しやすくする |
| 略語の説明 | 「VP」は Vice President を指す | 部門固有の略語による誤解を減らす |
シノニムや用語集は、最初から完璧に作る必要はありません。まずは現場でよく使う質問を20〜30個集め、回答がずれた質問から優先的に追加していくと、短期間で改善しやすくなります。
複数行テキスト列・ファイル列のプレビューは慎重に扱う
2026年6月26日更新の公式ページでは、Dataverse テーブル内の Multiline Text、つまり MemoType 列や、File、つまり FileType 列に対して、非構造化推論を使ってより高品質な回答を得るプレビュー機能も説明されています。ただし、このセクションはプレビューであり、変更される可能性があり、本番用途を前提にした機能ではないと明記されています。(Microsoft Learn)
プレビュー機能を試す場合は、Power Apps 側で対象テーブルを構成し、Quick Find View にテーブル、複数行テキスト列、ファイル列を明示的に含め、検索可能にする必要があります。設定後は保存して公開する流れになります。(Microsoft Learn)
注意すべき制限もあります。
| 制限・注意点 | 実務上の対策 |
|---|---|
| プレビュー機能であり仕様変更の可能性がある | 本番必須機能として設計しない |
| 検索インデックス作成に追加の Dataverse 容量コストが発生する可能性がある | 容量レポートで利用量を確認する |
| 先にナレッジソースを追加してから列を構成した場合、バックフィルに最大2日かかる可能性がある | 急ぐ場合は設定後に Dataverse ナレッジを追加し直すことを検討する |
| ファイル添付内の表、画像、組織のベース言語以外のテキストには制限がある | 多言語・画像中心の資料は別のナレッジ設計を検討する |
| Dataverse 仮想テーブルは Finance and Operations データプロバイダー関連のみ選択可能 | 外部データプロバイダーの仮想テーブル利用は事前検証する |
特にグローバル企業では、多言語データの扱いに注意が必要です。日本語、英語、現地語が混在するファイルを Dataverse のファイル列に置いている場合、プレビュー機能だけに依存すると、期待した回答品質にならない可能性があります。
Quick Find View と検索対象列の見直しが必要
Dataverse search の検索対象は、テーブルを選ぶだけでは決まりません。Power Apps 側の Quick Find View が、検索対象列や表示列に関係します。Microsoft の構成ドキュメントでは、Dataverse search を設定する際に、検索対象テーブル、検索される列、表示される列、フィルター条件を確認する必要があると説明されています。(Microsoft Learn)
また、Dataverse search には組織全体で有効化できる検索フィールド数の上限があります。公式ドキュメントでは、既定で50フィールドがインデックス化され、最大1,000の検索可能フィールドまで構成できるため、追加で構成できるのは最大950フィールドと説明されています。(Microsoft Learn)
このため、すべての列を検索対象にするのではなく、回答に必要な列だけを選ぶべきです。
| 判断基準 | 検索対象に向いている列 | 検索対象から外す候補 |
|---|---|---|
| ユーザーが質問に使うか | 顧客名、案件名、ステータス、カテゴリ、担当者 | 内部ID、更新者ID、システム管理用フラグ |
| 回答根拠になるか | 金額、期限、進捗、説明文 | 一時的な計算列、監査用列 |
| 用語として意味があるか | 製品名、地域、契約種別 | コード値だけで意味が分からない列 |
| 権限上問題ないか | 利用者が閲覧できる業務データ | 機密情報、個人情報、限定公開データ |
変更後すぐに結果が反映されるとは限りません。Microsoft のドキュメントでは、Dataverse search の構成や検索対象データの変更が検索サービスに表示されるまで最大15分かかる場合があり、平均的な組織でフル同期に1時間以上、大規模組織では数日かかる場合があると説明されています。(Microsoft Learn)
容量とコストは事前に見積もる
Dataverse テーブルをナレッジソースとして使う場合、検索インデックスの容量消費も確認が必要です。特に、複数行テキスト列やファイル列を含める場合は、通常のテーブル検索よりも容量への影響が大きくなりやすいです。
公式ドキュメントでは、検索インデックスの作成に追加の Dataverse 容量コストが発生すると説明されています。また、Dataverse search の利用量は DataverseSearch テーブルとして環境単位で確認でき、Power Platform 管理センターの容量レポートからも確認できます。(Microsoft Learn)
管理者は、次の観点で見積もると判断しやすくなります。
| 確認項目 | 見るべきポイント |
|---|---|
| 対象テーブル数 | 業務に必要なテーブルだけに絞っているか |
| 対象列数 | Quick Find View に不要な列が含まれていないか |
| ファイル列 | 大量の添付ファイルを検索対象にしていないか |
| 更新頻度 | 頻繁に更新されるデータで同期遅延が問題にならないか |
| 環境数 | 開発、検証、本番で同じインデックスを重複して持たないか |
最初から全社展開するより、1つの業務シナリオに絞ってパイロット運用し、容量、回答品質、権限の3点を確認してから広げる方が安全です。
移行期限はあるのか
2026年6月26日更新の公式ドキュメントを確認する限り、このページには Dataverse テーブルをナレッジソースにする機能について、特定の移行期限や強制移行日は明記されていません。したがって、現時点で管理者が取るべき対応は「期限までに移行すること」ではなく、「利用予定の環境で前提条件を満たしているか確認すること」です。(Microsoft Learn)
ただし、既存の Copilot Studio エージェントで次の条件に該当する場合は、早めに見直した方がよいでしょう。
| 状況 | 見直すべき理由 |
|---|---|
| No authentication または Authenticate manually のエージェントで Dataverse を使いたい | Dataverse テーブルのナレッジソースでは Authenticate with Microsoft が必要 |
| Dataverse search を Off にしている | テーブル追加や回答利用に影響する可能性が高い |
| 既存の Quick Find View が整理されていない | 不要な列がインデックス化され、容量と品質に影響する |
| 複数行テキスト列やファイル列を本番で使いたい | 対象機能はプレビューであり、制限を前提に検証が必要 |
| グローバル環境で多言語ファイルを扱う | 言語やファイル内容の制限を確認する必要がある |
よくある失敗と対処法
テーブルが Copilot Studio で表示されない
まず確認すべきなのは、Dataverse search と権限です。対象環境で Dataverse search が利用できない場合、Dataverse テーブルをナレッジとして選択できない可能性があります。また、作成者に対象テーブルへの十分なアクセス権がない場合も、テーブルが見えないことがあります。(Microsoft Learn)
対処としては、Power Platform 管理センターで Dataverse search の状態を確認し、Dataverse のセキュリティロールで対象テーブルへの読み取り権限を確認します。カスタムテーブルの場合は、検索対象として含まれているか、管理プロパティで外部検索インデックスへの同期が許可されているかも確認してください。
回答が業務用語と合わない
これはシノニムや用語集が不足しているケースが多いです。たとえば、ユーザーが「未対応の問い合わせ」と聞くのに、Dataverse 側ではステータスが「Open」や「In progress」になっている場合、用語の対応関係を追加しないと意図が伝わりにくくなります。
対処としては、現場の質問例を集め、回答がずれた質問から用語集を追加します。列名、コード値、略語、業務ルールは優先的に定義すると効果が出やすいです。
ファイル列や長文列の内容が回答に出ない
複数行テキスト列やファイル列は、プレビュー機能として扱われています。Power Apps 側で対象列を Searchable にし、Quick Find View に含め、保存と公開を行っているか確認してください。先にナレッジソースを追加してから列設定を変更した場合、反映に時間がかかることもあります。(Microsoft Learn)
本番業務で確実な回答が必要な場合は、プレビュー機能だけに依存せず、重要情報を構造化列に分ける、SharePoint など別のナレッジソースと組み合わせる、回答できない場合のフォールバックを設計するなどの対策を取るべきです。
管理者では動くが一般ユーザーでは回答できない
管理者権限でテストすると、ほとんどのデータが見えるため問題に気付きにくくなります。しかし一般ユーザーでは Dataverse のセキュリティロールによって見えるレコードが制限されます。Dataverse search はセキュリティロールと権限を尊重し、ユーザーがアクセスできるレコードだけを表示する仕組みです。(Microsoft Learn)
本番前には、実際の利用者に近い権限を持つテストアカウントを用意し、回答内容とアクセス制御を確認してください。
管理者向けチェックリスト
Dataverse テーブルを Microsoft 365 Copilot 向けエージェントのナレッジとして使う場合は、次の順番で確認すると安全です。
| チェック項目 | 確認内容 |
|---|---|
| 利用シナリオ | どの業務質問に答えさせるのかを明確にする |
| 対象環境 | 本番、検証、開発のどの環境で使うか決める |
| Dataverse search | 対象環境で利用可能か確認する |
| 認証方式 | エージェントが Authenticate with Microsoft になっているか確認する |
| 対象テーブル | 1つのナレッジソースで最大15テーブルに収まるよう整理する |
| 検索対象列 | Quick Find View と Searchable 設定を見直す |
| 用語定義 | 現場の言葉、略語、ステータス、コード値を定義する |
| 権限 | 管理者・標準ユーザー・権限なしユーザーで確認する |
| 容量 | Dataverse search の容量消費を確認する |
| テスト | 代表的な質問と失敗パターンをテストする |
| 運用 | 用語集、テーブル構成、権限変更時の見直し担当を決める |
特に重要なのは、テーブル追加前に「どの質問に答えるためのナレッジなのか」を決めることです。目的が曖昧なまま複数テーブルを追加すると、検索対象が広がりすぎ、回答品質と管理負荷の両方が悪化します。
まず取るべき行動
Microsoft 365 Copilot で Dataverse データを活用したい組織は、いきなり全社展開するのではなく、1つの業務シナリオで小さく検証するのが現実的です。たとえば「営業担当が自分の案件状況を確認する」「サポート担当が問い合わせ分類を確認する」など、対象ユーザー、テーブル、質問例を絞ると効果を測定しやすくなります。
最初に行うべきことは、対象環境の Dataverse search、エージェントの認証方式、Dataverse セキュリティロール、Quick Find View を確認することです。そのうえで、シノニムと用語集を追加し、実際の利用者権限でテストします。
今回の更新は、Dataverse を Microsoft 365 Copilot の回答基盤に近づけるうえで有用です。一方で、検索、権限、容量、用語設計を伴う機能でもあります。管理者と業務部門が一緒に「何を答えさせるか」「どのデータを使わせるか」「誰に見せるか」を決めてから導入することで、Copilot Studio のエージェントを実務で使えるレベルに引き上げやすくなります。
コメント