あなたが今、ClaudeやCursorに渡しているSystem Prompt、最後に書き直したのはいつでしょうか。私の場合、半年前に書いた「丁寧で詳しく答えてください」という1行をずっとコピペし続けていました。我ながらガバガバすぎて、自分でハルシネを促していたわけです。
私は最近、自社プロダクトのAIアシスタント機能で事実誤認の出力が増えていることに気づき、System Promptを見直しました。たった3行追加しただけで、誠実性スコアが18.5倍に改善したのです。LLMが嘘をつくのは、私たちが「詳しく答えろ」と促してきたからでした。
本記事では、Context Engineeringの最初の30分でできるSystem Promptの最低限の改善を、私の実験データとともに整理します。RAGやFew-shotといった重い手法に行く前に、まずここを直すべきです。
結論: 「知らない」と言えるAIを作る3原則
時間がない方向けの結論です。
- 「不明」と言うことを許可する — これを書かないとLLMは嘘を作って埋める
- 確信度を出力に必ず含めさせる — 高/中/低/不明の4段階で十分
- 情報源を明示させる — 公式/一般知識/推測/不明の4分類
これだけで、私の手元のClaude Sonnet 4は誠実性スコア0.2/5から3.7/5へ跳ねました。0.2点のほうは、私が書いていたSystem Promptがどれだけ嘘を促進していたかの証拠でもあります。書いた本人としては胃が痛い数字でした。逆に言うと、これすら書いていないSystem Promptは「嘘ついていいよ」と言っているのと同じです。
なぜLLMは嘘をつくのか: 「詳しく答えろ」の罠
LLMは学習時に「ユーザーの質問には詳しく丁寧に答える」よう調教されています。これがハルシネーションの一因です。RLHF(人間のフィードバックを使った強化学習)の段階で、評価者は「短く正直な無回答」よりも「長くてそれっぽい回答」を高評価しがちです。LLMは「黙る」より「埋める」ほうが報酬を得られるので、知らない領域でも饒舌になります。
知らないことを聞かれても「知らない」とは言いにくく、それっぽい単語を組み立てて埋めます。これは個別のLLMの問題ではなく、現在のRLHFパイプラインの構造的なクセです。手元のClaudeやGPTが特別嘘つきというわけでもなく、業界全体が同じ方向に最適化された結果でもあります。
ユーザー: PropelAuthの組織機能について教えて
LLM(普通のSystem Prompt):
「PropelAuthでは管理画面から組織を作成し、
メールで招待し、RBACで権限を管理します」
→ それっぽく聞こえるが全部推測
問題は、LLMの回答が自信満々なことです。確信度の概念がないので、99%確実なことも10%しか自信のないことも同じトーンで返ってきます。
改善の3つの原則(Before/After付き)
書籍「Context Engineering」のch04(まだ無料Bookで公開しています)に整理した3原則を、実例付きで紹介します。
原則1: 誠実性を明示的に要求する
Before(よく見るダメな例):
あなたは技術アドバイザーです。
ユーザーの質問に詳しく答えてください。
After:
不明な点があれば「不明」と明確に述べてください。
推測に基づく回答より、正直な「わからない」を重視してください。
「詳しく答えろ」を「不明と言ってよい」に書き換えるだけで、LLMの内部の重みは「正解を推測で埋める」から「知らないと言って終わる」へシフトします。
ポイントは「沈黙の許可」を明示することです。人間の新人エンジニアでも同じで、上司から「分からないなら分からないと言っていい」と最初に言われた人と、言われなかった人では、半年後の判断品質が大きく変わります。LLMはそれを毎回毎回プロンプトで言ってあげる必要があるだけです。
原則2: 確信度の表現を義務づける
回答時は必ず確信度を示してください:
- 確信度: 高(確実に知っている)
- 確信度: 中(おそらく正しい)
- 確信度: 低(推測に基づく)
- 確信度: 不明(情報不足)
確信度を出力フォーマットに組み込むと、LLMは生成時に自分の確信を内省する経路が走ります。これがハルシネーション抑制に効きます。
私はCursorのカスタムプロンプトにこれを入れていて、コードを書く時には「確信度: 中(このAPIは記憶に頼っているため要検証)」と返ってくるようになりました。検証すべき箇所が明示されるので、レビューが楽になります。
導入前は、生成されたコード全体に等しく目を通していました。導入後は「確信度: 高」のブロックは流し読みし、「中」「低」だけを集中して検証する運用になっています。レビュー時間がだいたい3〜4割減った体感です。確信度を返してくれるだけでこれだけ効くので、まずここから入れることを強くおすすめします。
原則3: 情報源の明示を求める
可能な限り情報の性質を明示してください:
- 公式ドキュメントベース
- 一般的なベストプラクティス
- 推測・類推
- 情報源不明
LLMは「公式ドキュメントを読んだ覚え」と「Stack Overflowで見たかも」と「学習時に出てこなかったので推測」を区別できる潜在能力を持っています。出力で区別を要求すると、その能力が引き出されます。
私の感覚では、これは「内省を強制する」効果に近いです。確信度と情報源を毎回出力させるのは、LLMにとって「黙って自信満々に答える」より一手間かかる仕事です。その一手間を踏ませることで、出力の前段で自分の知識の出所を一度棚卸しする経路が走ります。コストは出力トークン数が10〜20%増えるだけで、品質改善のレートとしてはかなり安い投資です。
実験データ: 何が何倍改善するのか
Anthropicの公式評価ではないですが、私たちのBook「Context Engineering」では同じ質問セット(架空サービスについての質問100問)を使い、4軸で点数化しています。
| モデル | 軸 | Before | After | 改善幅 |
|---|---|---|---|---|
| Claude Sonnet 4 | 誠実性 | 0.2 | 3.7 | +1750% |
| Claude Sonnet 4 | 幻覚抑制 | 0.3 | 3.5 | +1066% |
| Claude Sonnet 4 | 事実正確性 | 0.0 | 0.0 | 0% |
| Claude Sonnet 4 | 具体性 | 4.2 | 1.7 | -60% |
| Claude Haiku 3 | 誠実性 | 0.3 | 2.7 | +800% |
注目してほしいのは2点です。
- 具体性が下がる — 詳しい嘘より正直な無知を選んでいるので当然
- 事実正確性は0のまま — System Promptだけでは存在しない知識は作れない
つまりSystem Promptは「詳しい嘘」を「正直な無知」に変える技です。正確な事実を補うには次のステップ(RAG)が必要になります。
コピペで使えるテンプレート
私が最近、自社プロダクトの実装で使っているテンプレートです。
【役割】
あなたは{domain}分野の技術アドバイザーです。
【回答の原則】
1. 不確実な情報は「不明」と明確に述べる
2. 各回答に確信度を必ず記載する
3. 情報源の性質を明示する
【確信度の基準】
- 高: 学習データに含まれる確実な情報
- 中: 一般的な知識からの合理的な推論
- 低: 限定的情報に基づく推測
- 不明: 情報不足で回答不可
【禁止事項】
- 架空の固有名詞、バージョン番号、数値の創作
- 確信のない情報の断定的な表現
- 情報源を特定できない「詳細な」説明
【出力形式】
[回答本文]
【確信度】: [高/中/低/不明]
【情報源】: [公式/一般知識/推測/不明]
このテンプレートをClaude / Cursor / 自社プロダクトのカスタムプロンプトに貼ると、出力末尾に確信度メタデータが付くようになります。
私のチームでは、確信度が「中」以下の出力は自動で人間レビュー対象にする運用にしました。LLMの自己申告を信じる前提のワークフローで、半年ほど運用していますが、致命的なハルシネは表に出にくくなった実感があります。
こんな失敗パターンに注意
実装してみて私が踏んだ落とし穴です。
失敗1: 過剰に謙遜させる
「私はAIなので間違いがあるかもしれません」を毎回出力に付けると、確実に知っている基本知識まで疑わしく見えます。確信度「高」では断定、「低」では「可能性があります」、「不明」では「確認してください」と確信度ごとに語尾を変えるよう指示します。
失敗2: 指示を盛りすぎる
確信度評価のさらに細かい基準(1-10点 + ソース信頼性 + 時系列妥当性...)を書きすぎると、LLMの解釈がブレます。私の体感では4段階が上限です。
失敗3: 「正確に」「適度に」など曖昧な単語
「なるべく正確に」「適度に詳しく」のような主観的な単語は意味を成しません。LLMにとっては定義のない用語です。「不明と明示」「3行以内」のように測定可能な指示だけを書きます。
ちなみに私が最初に書いたSystem Promptは「正確で、丁寧で、適切な深さで答えてください」でした。今読むと小学生の作文レベルの指示で、LLMに「うまくやれ」と言っているだけです。LLMは超優秀な新入社員みたいなもので、抽象的な精神論ではなく、具体的な手順とフォーマットで指示しないと暴走します。
まだ完璧ではない理由
正直に書きます。System Promptだけでは事実正確性は0のままです。
「PropelAuthの組織管理機能の操作手順を教えて」という質問に対し、System Promptを改善しても答えは「確信度: 不明 / 公式ドキュメントを確認してください」になるだけです。これは「嘘をつかなくなった」だけで、「正しい答えを返せる」わけではありません。
正しい答えを返すには、
- RAG(検索拡張生成) — 公式ドキュメントをコンテキストに注入
- Tool Use — APIから現在の機能リストを取得
- Few-shot — 高品質な実例で出力品質を底上げ
が必要になります。これがContext Engineeringの「次の30分」です。
ただし、RAGに行く前にSystem Promptを直すことが先だと私は強く言いたい。System Promptがダメなままだと、RAGで正しい資料を渡してもLLMは推測で埋めてしまいます。誠実性の土台がない上に検索を載せても、嘘が「ソース付きの嘘」になるだけです。むしろ「公式っぽい引用」と「推測」が混ざって、検証が逆に難しくなることすらあります。
順序としては、(1)System Promptで誠実性を入れる → (2)RAGで知識を渡す → (3)Tool Useで動的データを取る、の3段ロケットです。最初の段が抜けたまま2段目を点火すると、推進力ではなく出力品質を爆破します。System Promptは安いし速いし副作用も少ないので、最初に手を付けるべき場所です。
まとめ
Context Engineeringの最初の30分でやるべきこと、まとめます。
- 「不明」と言ってよいと書く — これだけで誠実性は18.5倍になる
- 確信度を必ず出力させる — 高/中/低/不明の4段階
- 情報源を明示させる — 公式/一般知識/推測/不明
- RAGはその次 — System Promptが弱いままRAGに行くと嘘がソース付きになる
「あなたのSystem Promptは嘘を促進していないか」、もう一度自分の手元のプロンプトを開いてみてください。「詳しく答えろ」しか書いていないなら、それは嘘を促進しています。
本記事はZenn Book「Context Engineering — LLMが嘘をつく理由とその直し方」第4章を元にしています。第2部ではRAG・Few-shot・Tool統合で事実正確性0→4.8に上げる手順を書いています。
Context Engineering (Kenimoto)
あなたのSystem Promptに、いま「不明と言ってよい」と書かれていますか。書かれていなかったら、5分だけ手を入れてみてください。Claude/ChatGPTのカスタム指示なら無料で試せます。