Claude Code などの LLM エージェントを業務で使う際、最大のリスクは**ハルシネーション（幻覚）**です。プロンプトの改善ばかりが注目されがちですが、本当に必要なのは「仕組みで縛る」アプローチです。

きっかけとなった事故

ある開発者が実際に遭遇した事故が、この議論のきっかけです:

which コマンドの結果だけで「未インストール」と診断されたが、コードは PATH 外のディレクトリを直接参照していた。ログを1行も読まずに断言。

LLM エージェントは自信に満ちた口調で誤った結論を出すことがあり、人間がそれを鵜呑みにしてしまうリスクがあります。

Anti-Hallucination Protocol の4つの柱

提唱されている Anti-Hallucination Protocol は、以下の4つのルールで構成されます:

1. 事実主張にはツール実行による検証を義務化

LLM が「〜がインストールされていない」「〜が原因です」と主張する場合、必ず対応するコマンドやツールを実行して裏付けを取ることを求めます。推測だけで結論を出すことを許容しません。

2. 禁止パターンの明示

以下の4つのパターンを明示的に禁止します:

パターン説明
推測診断十分な証拠なしに原因を断定する
確認なし否定実際に確認せず「存在しない」「動かない」と主張する
記憶による主張過去の学習データだけに基づく事実主張
自信に満ちた誤り高い確信度で不正確な情報を提供する

3. 違反時のインシデント記録と伝播

ハルシネーションが検出された場合、インシデントとして記録し、全プロジェクト横断で伝播させます。これにより同じ失敗パターンを繰り返さない仕組みを構築します。

4. プロジェクト設定への組み込み

CLAUDE.md や類似の設定ファイルにルールを記述し、プロジェクト単位で一貫したガードレールを維持します。

2026年のハルシネーション対策の現状

2026年3月時点で、各 LLM のハルシネーション率は改善が進んでいます。LLM Hallucination Index 2026 によると、Claude Sonnet 4.6 は BS 検出成功率 91.0%、誤検出率 3.0% とトップクラスの精度を示しています。

しかし、モデル性能の向上だけでは不十分です。特に以下の場面ではハルシネーションが発生しやすいことが報告されています:

  • コンテキスト圧縮後: 長い会話でコンテキストが圧縮されると、計画と実装の乖離が起きやすい
  • Plan Mode での実装フェーズ: 計画作成後の実装で、計画にない機能を追加してしまう

実践的な対策

CLAUDE.md への記述例

1
2
3
4
5
6

## Anti-Hallucination Rules

- ファイルの存在確認は必ず `ls` や `cat` で実行すること
- パッケージのインストール状況は `which` だけでなく、実際のインポートやバージョン確認で検証すること
- エラーの原因を主張する前に、必ずログファイルを読むこと
- 「〜のはずです」「おそらく〜」という推測を事実として扱わないこと

CLEO のようなツールの活用

CLEO は Claude Code 向けのタスク管理ツールで、4層の Anti-Hallucination 保護と SQLite による不変の監査証跡を提供します。

批判と議論 — 「モデルに自己検証させる」ことの限界

Anti-Hallucination Protocol に対しては、本質的な批判が存在します。

批判: モデルの確信度問題

ハルシネーションはモデルの確信度の問題なので、モデル自身に確信度を評価させるループは原理的に機能しない。環境診断用の必要証拠セット（PATH確認・実行バイナリの絶対パス・コード中の参照・ログ）を外部仕様として定義し、揃わない回答を拒否する対策が有効だ。

この指摘は核心を突いています。モデルが「自分は正しい」と高い確信度で誤った出力をするのがハルシネーションの本質であり、そのモデルに「自信があるか確認して」と問いかけても意味がありません。

反論: 「ツール実行で外部検証している」

これに対し、Protocol の提唱者は次のように反論しています:

モデルに「自信ある？」と聞いても無意味なので、主張の種類ごとに必須の検証行動（ファイル存在確認、ログ grep 等）を CLAUDE.md で定義し、証拠なしの主張を禁止している。モデルの内省ではなく、ツール実行という外部検証を強制する仕組みだ。

反論の限界 — CLAUDE.md は「お願い」であり「強制」ではない

この反論は方向性として正しいものの、3つの構造的な弱点を抱えています。

1. ルール適用の判断がモデル内部にある

「この主張は環境診断だから証拠セットが必要」と判定するのはモデル自身です。主張の種類の分類を間違える — つまりハルシネーションする — 可能性があります。

2. 「証拠が揃った」の判断もモデル内部にある

which を実行して「確認しました」と言うのは一見すると外部検証ですが、「which だけで十分」と判断したのはモデルです。元の事故がまさにこのパターンでした。

3. CLAUDE.md はプロンプトの一部に過ぎない

ファイルとして外部に存在していても、LLM にとっては system prompt と同じコンテキストです。「外部仕様」のように見えて、実行時にはモデルの内部処理に組み込まれます。

本当の「外部検証」とは

批判者が指摘する外部仕様とは、モデルの判断を介さずに機械的に検証する仕組みのことです:

アプローチ仕組みモデルの関与
CI/CD パイプライン特定のコマンド群の実行結果をモデル外のスクリプトが検証なし
pre-commit hook「環境診断を含むコミットには which, readlink, grep log の実行履歴が必要」と機械的にチェックなし
MCP サーバー側フィルタ証拠不足の応答を返さないようサーバー側でフィルタリングなし
CLAUDE.md ルールモデルがルールを読んで自主的に従う全面的に依存

CLAUDE.md でのルール定義は「モデルへのお願い」であり、「外部からの強制」ではありません。これが本質的な違いです。

議論の帰結 — 「判定者をモデルの外に出せるか」

最終的に、この議論は以下の結論に収束しました:

構造としては「X を主張する前に Y を実行せよ」という前提条件命題であり、ベクトルは一致している。ただし「証拠なしの主張を禁止」という前提条件の充足判定がモデル内部にある限り、本質的な問題は解決しない。判定者をモデルの外に出せるかが、プロンプトと仕組みの分岐点だ。

この整理が示す重要な点は、Anti-Hallucination Protocol の方向性（ツール実行の義務化）自体は正しいということです。問題は「Y を実行したか」ではなく、「Y が十分に実行されたか」を誰が判定するかにあります。

構造化出力による外部検証 — 具体的な解決策

判定者をモデルの外に出す方法として、モデルの出力を構造化し、evidence 性をシステム側で検証するアプローチがあります。

設計例: 構造化された証拠付き応答

モデルに対して、主張と証拠を分離した構造化出力を強制します:

1
2
3
4
5
6
7
8
9

{
  "claim": "パッケージXは未インストール",
  "claim_type": "environment_diagnosis",
  "evidence": [
    {"tool": "which", "command": "which X", "result": "not found"},
    {"tool": "readlink", "command": "readlink -f /usr/local/bin/X", "result": null},
    {"tool": "grep_log", "command": "grep X /var/log/install.log", "result": null}
  ]
}

外部システムが evidence 配列を検査し、claim_type に対して必要な証拠が揃っていなければ（null が含まれていれば）回答を拒否します。こうすることで、充足判定がモデルの外に出ます。

検証レイヤーの比較

レイヤー判定者実効性
プロンプト（CLAUDE.md）モデル低 — 従うかどうかもモデル次第
構造化出力 + 外部検証外部システム中 — 出力形式は強制できるが、evidence の中身の正確性はモデル依存
ツール実行ログの外部監査外部システム高 — モデルが実際に何を実行したかをランタイムが記録・検証

注目すべきは、構造化出力方式でも完全ではないという点です。モデルが evidence の中身を捏造する可能性は残ります。最も実効性が高いのは、エージェントランタイム側がツール実行ログを独立に記録し、モデルの主張と突き合わせる方式です。

Claude Code における実現可能性

Claude Code はすべてのツール実行をログとして保持しています。これを活用すれば:

  1. モデルが環境診断の主張を出力する
  2. ランタイムが直近のツール実行ログを参照する
  3. 必要な証拠コマンド（which, readlink, grep）の実行履歴がなければ、応答をブロックまたは警告する

この仕組みは hooks 機能や MCP サーバーとして実装可能であり、CLAUDE.md の「お願い」よりもはるかに強い強制力を持ちます。

まとめ

「仕組みで縛れ」の本質は、判定者をモデルの外に出すこと。

Anti-Hallucination Protocol をめぐる議論から見えてきたのは、ハルシネーション対策の3つの段階です:

段階アプローチ判定者限界
第1段階CLAUDE.md でルール定義モデルモデルがルールを無視・誤解する可能性
第2段階構造化出力 + 外部検証外部システムevidence の中身の正確性はモデル依存
第3段階ツール実行ログの外部監査外部システムモデルの関与なしに検証可能

現時点で多くの開発者が実践しているのは第1段階です。これは「ないよりはるかに良い」ものの、原理的な限界があります。

目指すべきは第3段階 — モデルが何を実行したかをモデルの外側で記録・検証し、証拠不足の主張を機械的に拒否する仕組みです。Claude Code の hooks 機能や MCP サーバーの活用により、この実現は技術的に射程圏内にあります。

「AI を信用するな。仕組みで縛れ。」— この原則を貫くなら、仕組みの判定者もまた、AI であってはなりません。