Copilotの「間違った回答」に困っていませんか？ ハルシネーションを防ぐ専用エージェントの作り方
前回の記事で紹介した「データソース→連携基盤→SharePoint→Copilot」という4ステップのうち、最後の「Copilot側」で必要な設定は、実は次の3つだけです。
- 保管場所の設計
- 権限設計
- 専用エージェント作成
特別な開発は不要で、Microsoft 365の標準機能の範囲で組めます。この記事では、それぞれの具体的な進め方を、実例つきで解説します。
目次
- STEP1 保管場所の設計 ── SharePointリストでCopilotの参照精度を上げる
- STEP2 権限設計 ── Copilotは「元の権限」しか見ない
- STEP3 専用エージェント作成 ── Copilot Studioでハルシネーションを防ぐ
- まとめ：特別な開発は不要、Microsoft 365の標準機能で完結する
STEP1 保管場所の設計 ── SharePointリストでCopilotの参照精度を上げる
保管場所の設計では、次のポイントを押さえます。
- 専用のSharePointサイトを新規作成し、既存の共有サイトと混在させない
- Excel/CSVより「SharePointリスト」形式の方が、Copilotが列単位で正確に参照できる
- 列名は質問で使われそうな言葉に合わせ、曖昧な表現を避ける
- 拠点名・部署名などの表記揺れは、連携基盤側で統一してから書き込む
具体例
「更新日」ではなく「契約更新日」という列名にすることで、Copilotが誤って別の日付列を参照するのを防げます。項目名を明確にする一手間が、AIの検索精度を大きく左右します。
STEP2 権限設計 ── Copilotは「元の権限」しか見ない
Copilotは「そのユーザーが元々アクセスできる範囲」しか参照しません。これはMicrosoft Graphの「セキュリティトリミング」と呼ばれる仕組みによるもので、Copilotに社内データを連携する際に多くの人が気にする「情報漏洩しないか」という懸念に対する、技術的な回答でもあります。
権限設計で押さえるべきポイントは次の通りです。
- 新しいSharePointサイトのメンバー権限は、Entra ID(旧Azure AD)のグループ単位で設計する
- 全社集計データは「誰が見てよいか」を先に整理しないと、見える/見えないの事故が起きる
- 機密度が高いデータは感度ラベル・DLPポリシーとの整合も確認する
具体例
経費データなら「部門長は自部門のみ閲覧」「経営層は全社閲覧」のように、既存の組織階層に合わせてSharePointグループを設計します。
なお、Microsoft Purviewの感度ラベルで暗号化されたデータについては、さらに踏み込んだ制御も可能です。Microsoftの公式ドキュメントによれば、Microsoft 365内のエージェント経由でアクセスされるコンテンツに対しては、暗号化設定で「プログラムからのアクセスを除外する」ことができ、これによってエージェントがそのコンテンツにアクセスすること自体を制限できます。人間のユーザーには見せてよいが、AIエージェントには読ませたくない、というような細かい制御をしたい場合に有効な選択肢です。
STEP3 専用エージェント作成 ── Copilot Studioでハルシネーションを防ぐ
そもそもAIはなぜ「ハルシネーション」を起こすのか
対策の前に、原因を簡単に整理しておきましょう。大規模言語モデル(LLM)は、本質的には「与えられた文脈の続きとして、統計的にもっともらしい言葉」を生成する仕組みです。学習データの中に答えが存在しない、あるいは根拠となるデータが与えられていない質問に対しても、LLMは「それらしい文章」を作ることができてしまいます。これが、AIが「わからない」と言わずに、自信満々に誤った情報を答えてしまう、いわゆるハルシネーションの根本的な原因です。
この性質はモデルの性能を上げても完全にはなくなりません。実務上の対策は、①回答の根拠にできる正しいデータを与える(グラウンディング)、②データがない場合には推測せず「わからない」と答えるようルールで縛る、という2つの組み合わせが基本になります。Copilot Studioでの専用エージェント作成は、まさにこの2つを実装する作業です。
宣言型エージェントの作り方
Copilot Studioで「宣言型エージェント」を作成し、知識ソースを該当SharePointサイトのみに限定します。参照範囲を絞り込むことで、関係のないデータを参照して誤った回答を生成するリスクを下げられます。
Microsoftの技術文書によれば、宣言型エージェントは次の4つの構成要素で定義されます。
エージェント定義
エージェントの目的・範囲・振る舞いを定めるインストラクションや制約
ケイパビリティ(アクション)
エージェントが実行できる操作。外部システムとの連携も含む
ナレッジソース
回答の根拠となる情報。構造化・非構造化を問わず、社内外のデータやAPIを指定できる
アプリメタデータ
名前・説明・アイコンなど、エージェントがどう認識・表示されるかを定める情報
宣言型エージェントは、Copilot Studio以外にも、Microsoft 365 Copilot内蔵の「Agent Builder」やSharePoint、Microsoft 365 Agents Toolkitといった複数のツールから作成できます。共通しているのは、Microsoft 365 Copilotと同じ基盤モデル・オーケストレーターの上で動くため、Copilot本体が持つデータ保護の仕組みをそのまま引き継げるという点です。また、社内向けに公開する前には、Microsoftが定める「Responsible AI(責任あるAI)」の検証チェックを通過する必要があり、これも誤った振る舞いを未然に防ぐ仕組みの一つになっています。
「わかりません」と答えさせるルール設計
「ナレッジソースの数字をそのまま使い、憶測で数値を作らない」等のルールをインストラクションに明記します。該当データが見つからない場合は「わかりません」と答えるよう指定することで、誤回答を防ぎます。
スタータープロンプトで利用開始のハードルを下げる
よくある質問を「スタータープロンプト」として事前登録しておくと、利用開始のハードルが下がります。たとえば「生産実績アシスタント」なら、起動時に「今週の良品率は?」等のスタータープロンプトを表示しておくと、初回から使ってもらいやすくなります。
📖まずはホワイトペーパーで詳細を確認する
「『Microsoft Copilot』活用のためのデータ連携入門！社内データをつないで業務AIを実現する方法」をダウンロードいただけます。 保管場所と権限の正しい設計・誤回答を防ぐエージェント設定・セキュアなデータ連携が1冊に。
ホワイトペーパーを無料ダウンロード
まとめ：特別な開発は不要、Microsoft 365の標準機能で完結する
保管場所の設計・権限設計・専用エージェント作成という3つのステップは、いずれもMicrosoft 365とCopilot Studioの標準機能の範囲で完結します。特別な開発は必要ありません。
次の記事では、これらの設定を実際に行った企業が、どのような業務でCopilotを活用しているのか、具体的な3つの事例を紹介します。
著者
