プロンプトは「質問」ではなく「採点基準」だった

こんにちは。KDDIアイレットの新竹です。普段は Gemini Enterprise の導入支援をしています。

少し前の話です。参考にしようと思っていた記事の URL を貼って、生成AIに「これ要約して」と頼みました。

返ってきた要約は、よくできていました。構成も自然で、そのまま引用できそうな形に整っている。資料に貼り付けようとして、念のためと思って元記事を開きました。

調べてみると、そもそもその URL にアクセスできていませんでした。

タイトルから中身を推測して、それらしい要約を組み立てていたわけです。

このときぞっとしたのは、間違っていたこと自体ではありませんでした。間違っている気配がまったくなかったことです。派手に外してくれれば気づけます。厄介なのは、いつも通りの品質で返ってくる嘘の回答でした。

AI は「わかりません」で0点を取りたくない

そもそも、なぜ黙って推測するのか。

OpenAI が2025年9月に公開した「Why Language Models Hallucinate」という論文に、腑に落ちる説明がありました。いま AI を評価しているテストは、ほとんどが正答率だけを見ている。ということは「わかりません」と答えれば確実に0点で、適当に推測すれば当たる可能性がある。

要するに AI は、模試で絶対に空欄を作らない受験生をやっているだけ、という話です。同論文は対策として、誤答へのペナルティをプロンプトや指示の中に明記すべきだと述べています。（OpenAI、arXiv:2509.04664）。

ちなみに、これで痛い目を見ているのは我々だけではありません。2025年10月には大手コンサルの豪州法人が、政府向け報告書の参考文献14件が実在しなかったとして契約額（約4,400万円）の一部を返金しています（日本経済新聞、時事通信）。米国の法曹界では架空の判例を法廷に提出する事故が何年も続いていて、2026年6月にはミシシッピ州の連邦地裁が弁護士4名を訴訟から排除しました。4人とも、判事に指摘されるまで気づいていなかったそうです（ABA Journal、Business Insider Japan）。

文章を読むことを本業とする人たちでもこのようなミスはあるのです。

問題は、自分の頼み方のほうだった

論文を読んでいて、はっとしたことがあります。

AI がテストの点数を最大化するように振る舞うのだとしたら、私が投げているプロンプトは、そのテストそのものではないかと思います。

「これ要約して」という指示を、私は質問のつもりで書いていました。でも AI から見れば、これは採点基準です。しかも、かなり曖昧な基準です。「それっぽい要約が出ていれば満点」という基準になっています。読まなかったら減点とはどこにも書いていないので記事を読まずに満点を取るのが合理的です。

質問しているつもりで、雑な採点基準を渡していただけでした。

そう捉え直すと、やるべきことははっきりします。AI を賢くしようとするのではなく、採点基準のほうを書き換える。以下に、その基準を明確にするプロンプトの書き方を5つご紹介いたします。

1. 読まないと満点が取れない基準にする

冒頭の件です。要約させる前に、確認をひとつ挟みます。

以下の URL の記事を要約してください。

【手順】
1. まず記事の冒頭2文をそのまま引用する
2. 記事内の固有名詞・数字を3つ挙げる
3. その上で要約する

※アクセスできない場合は要約せず
　「アクセスできませんでした」とだけ答えてください。

URL：

冒頭を引用できないのに要約はできません。つまり、読まずに満点を取る道がなくなります。原始的ですが、これが一番確実でした。

小さいけれど大事なのは、最後の一文だと思っています。「アクセスできませんでした」と答えることを、失敗ではなく正解として認めている。逃げ道が用意されていないとAI は空欄を埋めようとしてしまいます。

2. 採点基準を変えても勝てない領域がある

提案書を書くときにやりがちなやつです。「うちの過去事例で似たのない？」と聞くと、AI は自社の実績など知らないので、業界の一般論から「ありそうな事例」を組み立てます。社名まで出てくることがあって、なかなかスリルがあります。

これは正直、プロンプトでは無理です。せいぜい参照範囲を絞るくらい。

添付資料に記載されている事例のみを使ってください。
記載のない業界・企業については「該当事例なし」と答え、
事例の詳細を補完しないでください。

どれだけ厳しく採点しても、答えを持っていない相手からは正解が出てきません。ここは RAG で社内データを参照させる領域です。

参考になったのが LINEヤフーさんの事例で、社内データを RAG で参照させる仕組みを全社導入し、サポート業務で正答率約98%と発表されています（プレスリリース、ASCII.jp）。ただ個人的に刺さったのは精度の数字ではなく、AI が読み込みやすい区切り方になるようフレームワークを自作した、という部分でした。

RAG は入れれば効くものではなくて、参照させるデータをどう整えるかがほぼ全部です。そしてそこが、一番地味で辛い作業になります。

3. 採点範囲を限定する

ライブラリの使い方を聞いて、返ってきたコードを実行したら AttributeError。公式ドキュメントを見てもわからないという場合はだいたいバージョンのズレです。AI の知識は特定時点のもので、その後の変更までを網羅しているわけではないです。

【前提】ライブラリ: ○○ v1.2.3 / Python 3.12

【回答ルール】
– 上記バージョンに存在すると確信できる API のみ使う
– 確信が持てない箇所には
# 要確認: 公式ドキュメント未確認 を付ける
– 不明な場合は「わかりません」で構いません。
動きそうなコードを推測で書くほうが有害です。

ここでもうひとつ効いているのが、# 要確認 のコメントです。怪しい箇所を自己申告させると、レビューで見るべき場所が絞られます。 全部を疑うのは無理でも、印がついた3行なら確認できる。

コードは動かせば嘘がバレるのでエンジニアはこの点だけは恵まれているとも思います。厄介なのは、実行して確かめられない文章や数字や制度のほうです。

4. 時間軸を採点基準に入れる

AI の知識には賞味期限があります。しかも改正前の情報は「昔は正しかった」ものなので、文章としてどこも壊れていない。読み直しても気づけません。

【回答ルール】
1. 必ず Web 検索で最新情報を確認してから回答する
2. 以下を必ず併記する
   ・根拠となる法令名／条文
   ・施行日
   ・参照した公式ページの URL
3. 上記を満たせない場合は回答せず、確認先を案内する

施行日と URL を必須にすると、答えが正しいかどうかを自分で確認できる形になります。運用で効いているのは、変わらないもの（概念・仕組み）は聞いて、変わるもの（制度・価格・バージョン）は検索させる、という線引きです。Gemini なら「Google 検索で確認してから答えて」の一言で挙動が変わります。

5. 「未定」を満点に含める

「じゃあ誰かやっといて」で流れた項目に、AI が推測で担当者を立ててしまうケース。

そのまま議事録として共有されるので、後日「聞いてないです」が発生します。

【ルール】
- 担当者・期限は、発言中で明示されていた場合のみ記載する
- 明示がなければ「担当者未定」と書く（推測で埋めない）
- 判断が曖昧なものは末尾に【要確認】として分ける

ToDo 表の担当者欄が空いていると、AI は埋めたくなります。埋まっているほうが「良い議事録」に見えるからです。だから、空けておくことが正解だと先に伝えておきます。

結局、書いていたのは2つのことだった

5つ並べて気づいたんですが、やっていたことは2つに集約されます。

ひとつは、「言わない」を正解に含めること。「わかりません」「該当なし」「未定」を明示的に許可しておく。許可がなければ、AI は埋めます。0点を取りたくないので。

もうひとつは、確認できる形で出させること。冒頭2文の引用、# 要確認 のコメント、施行日と URL。どれも精度そのものは上げていません。上げているのは、こちらが検証できる余地です。

そして、この2つの範囲には限界があります。ケース2のように、そもそも AI が答えを持っていない領域では、いくら採点基準を厳しくしても意味がない。そこはデータを繋ぐ話に切り替えたほうが早いです。

「AI が嘘をつくかどうか」は、こちらの聞き方でだいぶ変わります。少なくとも、聞き方でしか変えられない部分は確実にある。それが今回の一番の学びでした。

わからなかったこと

ハルシネーションの記事なので、調べきれなかったところも置いておきます。

  • 国内で、ハルシネーションが直接の原因になって法的責任が問われた公表事例は見つけられませんでした。単に報道されていないだけかもしれません
  • 引用した論文はどれも英語での検証です。日本語で同じだけ効くのかは、確かめていません

このあたりは社内で試した結果が溜まったら、また書かせていただきます。

生成 AI の導入・活用のご相談はこちらから

生成 AI 導入・活用支援サービス｜クラウドの活用なら cloudpack

PoC の実施検証、開発支援はもちろん、本番導入のための教育支援や導入後の内製化支援までワンストップでサポートいたします。Gemini Enterprise の導入検討やグラウンディング設計のご相談も、お気軽にお声がけください。

参考文献

※ URL の確認は2026年7月30日時点のものです。