会議の翌日、Copilotが生成した議事録を送ってきた参加者から「自分はそんな発言をしていない」と連絡が来た。
確認してみると、確かにCopilotはその発言を「存在したもの」として書いていた。会議は30分のオンライン打ち合わせで、参加者は5人。録音データもある。しかし議事録の一部は実際の会議にはなかった内容だった。
本業で大企業へのMicrosoft 365 CopilotとCopilot Studioの導入を担当している立場から、こういった「ハルシネーション（AI が事実と異なる回答を生成する問題）」にどう向き合うかを整理する。
この記事で確認できること
- Copilotが間違える場面と、なぜ起きるかの仕組み（Microsoft公式の説明の範囲）
- 頼み方を変えることで嘘が混じりにくくなる3つのパターン
- 「出典を確認しながら使う」実際のワークフロー
公式で確認できていない部分は「未検証」と書く。
なぜCopilotは嘘をつくのか（Microsoftの説明の範囲）
CopilotはOpenAIの大規模言語モデル（LLM）を使っている。LLMは確率的に次のトークンを予測する仕組みで、「正確に記憶して引用する」のではなく、「それらしい続きを生成する」ことが本質だ。
MicrosoftのCopilot公式ヘルプ（Microsoft 365 Copilotのよくある質問）には次の記載がある。
Copilot は、大規模言語モデルを使用して応答を生成します。AI によって生成されたコンテンツには誤りが含まれている場合があります。重要な情報については、必ずソースから確認してください。
出典: Microsoft 365 Copilot についてよく寄せられる質問
つまり「誤りが含まれる可能性がある」というのはMicrosoft自身が認めている。前提として受け入れた上で、どう使うかを設計しなければならない。
Teams Meeting CopilotとRecap機能
議事録生成に使っていたのはTeams Meeting Copilotのまとめ（Recap）機能だった。これはリアルタイムの文字起こしデータをもとにCopilotが要約と議事録を生成する。
「文字起こしがあるなら正確では？」と思うかもしれない。実際には2つの問題がある。
問題1: 文字起こし自体が不完全なことがある
音声認識の精度は参加者の発音・マイクの品質・背景雑音に左右される。「〇〇という案件について」という発言が「何々という反件について」と変換されることがある。これは文字起こしが誤っている。
問題2: CopilotはRecapを「参考」にしつつも独自に補完する
ここが問題だった。文字起こしデータと会議の文脈からCopilotは要約を生成するが、その際に「会議でありそうな発言」を補完することがある。公式ドキュメントに明確な記述はないが、実務で複数件確認している現象だ。
嘘が混じりにくくなった頼み方3パターン
導入後の試行錯誤と、Microsoftの公式Copilotプロンプトガイド（Microsoft Copilot Lab）を参考にして、以下の3つを変えた。
パターン1: 「文字起こしを元に書いて、補完しないで」と明示する
変更前の頼み方:
この会議の議事録を作って
変更後の頼み方:
この会議の文字起こしだけを根拠にして議事録を作ってください。
文字起こしにない発言は書かないでください。
不明瞭で起こせなかった部分は「（聞き取り不明）」と書いてください。
結果: 存在しない発言の混入は大幅に減った。ただし「（聞き取り不明）」が多く出るようになり、むしろ文字起こしの精度問題が可視化された。
Microsoftのプロンプトガイドでも「制約を明示する」ことは推奨されている。
パターン2: 「この範囲だけ答えて」と文書を限定する
SharePointやTeamsのコンテンツに対してCopilotに質問する場合、「全体から推定して答える」のではなく「この文書だけを見て答える」と指定できる。
Microsoft 365 CopilotのChat（Copilot in Teams）では、参照ファイルを明示的に添付して「添付したファイルだけを参照して答えて」と入力することで、他のデータを参照しにくくできる（完全な分離ではない。実測での傾向として）。
【添付ファイル: meeting-minutes-draft.docx】
添付した文書だけを参照して、以下の質問に答えてください。
この文書に記載がない場合は「この文書には記載がありません」と答えてください。
質問: ◯◯プロジェクトの次のアクションアイテムは何ですか？
この形式にすると「文書に書かれていること」と「Copilotが補完した内容」が分かれやすくなる。
パターン3: 「確認できないことは書かないで」を入れる
汎用的に効いたのはこれだった。
確認できないことは答えないでください。
根拠として参照したファイル名やセクションを回答の末尾に書いてください。
「根拠を書く」という制約を入れることで、Copilotは根拠がないことを書きにくくなる（「参照元: なし」となった場合にこちら側で確認するトリガーになる）。
MicrosoftのCopilotプロンプトエンジニアリングガイドには「具体的で明確な指示」「コンテキストを提供する」「根拠を求める」の3つが推奨されている（Microsoft Copilot を使いこなすためのヒント）。
「出典を確認しながら使う」実際のワークフロー
現在、チーム内でのCopilot活用ガイドラインに入れているワークフロー。
| ステップ | 内容 |
|---|---|
| 1. 生成を依頼する | 上の3パターンのうちいずれかを使う |
| 2. 出典を確認する | 回答末尾の「参照元」を開いて、実際に書いてあるか確認する |
| 3. 不明な部分をフラグ | 出典が確認できない部分は別色でハイライトして保留にする |
| 4. 最終確認 | 重要な意思決定に使う文書は、人が最終確認してから配布する |
このフローを入れてから「存在しない発言が議事録に入る」問題は再発していない。ただし工数は増えている（ステップ2と3の確認作業）。「完全自動化」ではなく「AI支援＋人が確認」の位置づけで使っている。
Copilot Studioで社内ナレッジに回答させる場合
Copilot Studioでエージェントを作り、SharePointの社内文書に回答させる構成の場合、ハルシネーションを減らすために設定できる項目がある。
グラウンディングの設定（Generative Answersノード）
Copilot Studioのフロー内でGenerative Answersノードを使う場合、「Allow the AI to use its own general knowledge」をオフにすることで、ナレッジソース以外の情報を参照しにくくできる（完全ではない）。
オフにすると「登録されているナレッジに回答が見つかりませんでした」と返すことが増える。一見不便に見えるが、嘘をつくよりはましだという判断で、いくつかの用途ではこの設定を採用している。
出典: Copilot Studio - Configure knowledge sources（英語ページ。設定項目の名称は公開時のUI次第で変わることがある）
ナレッジソースの整備
登録するSharePointの文書が古いと、古い情報をもとに回答する。これはハルシネーションではなく「古いデータを正直に答えている」だけだが、利用者からは「嘘をついた」と受け取られることがある。
ナレッジの更新頻度と、Copilotがどのデータを参照しているかの「鮮度」管理が必要になる。
やってみて分かったこと
- 頼み方を変えるだけで、混入する嘘の量は体感で半分以下になった（比較測定はしていない。あくまで実務での印象）
- 「根拠を書かせる」が一番汎用的に効いた。 どの用途でも使えて、確認のトリガーになる
- 「完全に信頼できる」状態にしようとするのは難しい。 「重要な文書は人が確認する」ラインを決めておく方が現実的
- ハルシネーションが目立つのは「文脈の補完が必要な場面」。単純なデータ抽出や整形は比較的正確。使い所の見極めが大事
Microsoftは今後もCopilotの品質改善を続けると公表しているため、現時点での話として受け取ってほしい。
この設定と頼み方は公式ドキュメントで確認した範囲のみを書いている。実際の効果は環境・テナント設定・利用シーン によって変わる。試した結果や別のパターンがあれば、コメントで教えてもらえると参考になる。