コードを書く前に、/probeを使ってAIの幻覚を検出する

/probeの機能

/probe手法は、AIが生成した計画に、各主張事実を番号付きのCLAIMとEXPECTED値として出力させます。その後、実際のシステムに対してコマンドを実行してプローブを行い、期待値と実際の結果の差分を捕捉します。

ソースからの実例

ある開発者が~/.claude/projects/...以下に保存されているClaudeのJSONLセッションファイルを解析しようとしていました。Claudeは自信を持って形式を説明しましたが、/probeを実行することで4つの誤認が明らかになりました：

• 主張1： AIはトップレベルのタイプが2つ（user、assistant）あると述べた。実際： queue-operation、file-history-snapshot、attachment、system、permission-mode、summaryを含む7つのタイプ。
• 主張2： AIはassistantの内容 = text + tool_useと述べた。実際： 拡張思考モードではassistant出力の約3分の1を占めるthinkingブロックを見落としていた。
• 主張3： AIはuserの内容は常に配列であると述べた。実際： 多態的：文字列または配列。
• 主張4： AIはフォルダ名付けで/を-に置き換えると述べた。実際： 実際にはダッシュを前置してから置き換える。

/probeがなければ、jqフィルターは文字列形式のuser内容でエラーを起こし、thinkingブロックをゴミとして出力し、7つのメッセージタイプのうち5つを完全に見逃していたでしょう。

プローブの仕組み

AIはjq -r '.type' file.jsonl | sort -uのようなコマンドを実行する前に、「EXPECTED: 2 types」のような主張を記述します。あるプローブ出力は次のようになりました：

CLAIM 1: JSONLには2つのトップレベルタイプがある（user、assistant）
EXPECTED: 2
COMMAND: jq -r '.type' *.jsonl | sort -u | wc -l
ACTUAL: 7
DELTA: +5 未知のタイプ（queue-operation、file-history-snapshot、attachment、system、permission-mode、summary）

ソースからの重要な洞察

プローブする価値のある主張は、AIが最も自信を持っていることが多いものです。AIが曖昧な表現をしているときは、すでに確認が必要だと分かっています。AIがXと断言しているときは、分かりません。高信頼度の主張こそが誤認が隠れている場所です。

もう一つの利点は、1つのプローブがN個の永続的なテストになることです。7タイプの発見は、新しいタイプが現れたらCIが失敗するスキーマテストになります。文字列または配列の発見は、両方の形状をファジングするプロパティテストになります。上流の形式が変更されると、テストが失敗し、再プローブを行い、オラクルが更新されます。

制限と改善点

プローブは、AIが主張しようと考えたものだけを捕捉します。未知の未知は見えません。役立つこと：

• 主張を生成する前に、現実を列挙するためにjq 'keys'を最初に実行する
• Dex HorthyのCRISPYパターンは、AIに自身のギャップリストを表面化させるよう促す
• GitHubのSpec Kitは、AIに盲点をマークさせるために仕様書に[NEEDS CLARIFICATION]マーカーを使用する
• 主張リストの人間による確認も推奨される

従来のTDDとの対比

従来のTDDは、起こるべきだと考えることに基づいてテストを書きます。プローブ駆動TDDは、スパイクした、または検証した実際の出来事に基づいてテストを書きます。モックはシステムのモデルをテストします。プローブはシステムそのものをテストします。

ソースファイル

開発者は完全な/probeスキルファイルを2つのファイルでgistに共有しました：

• README.md: REPL-as-oracleの視点とTDDの対比を含む詳細な説明
• probe-skill.md: Claude Codeスキルとして読み込まれる7ステップのプロトコル

このパターンは単に「主張テーブル + 実際のシステムプローブ + 差分の捕捉」であり、コーディング対象のシステムを照会できる任意のREPLやCLIツールで機能します。