Claude Codeチームが明かす「blindspot pass」──実装前に1分で盲点を潰すプロンプト技法

AIの実行力が上がるほど、盲点のコストも増大する

Anthropicが2025年10月から2026年4月にかけての約40万件のClaude Codeセッション（約23万5000人）を分析した調査結果によると、典型的なセッションでは人間が計画判断の約70％を、Claudeが実行判断の約80％を担っていた。

この数字が示すのは、AIの役割拡大が人間の関与縮小ではないという点だ。計画判断の7割は依然として人間が担い、実行の8割をAIが引き受けるようになったことで、計画段階のわずかな見落としが広い実行範囲に増幅されて伝播する構造に変わった。モデルの性能が上がるほど、失敗の芽は実装そのものではなく、計画段階の「気づけない盲点」に移っていく。

4象限で「気づけない盲点」を可視化する

Shihipar氏が提唱する分類は、知識を4つの象限に仕分ける枠組みだ：

最も厄介なのはUnknown Unknowns。「何を質問すればいいか」自体が分からない状態にあるため、通常のヒアリングやレビューでは拾い上げにくい。blindspot passはこの最後の区分だけを狙い撃ちで洗い出す。

blindspot passの実践手順

やり方は極めてシンプルだ。実装用のプロンプトを書く前に、まずAIへ次のように依頼する：

「このコードベースの[対象モジュール]について何も知らない。blindspot passをして、自分に関係するunknown unknownsを洗い出すのを手伝ってほしい」

AIはコードベースを検索し、依存関係やテストの有無、過去のコミット履歴などから、依頼者が言及していない前提や見落としがちな箇所を列挙して返す。これを実装の起点にすることで、要件を書き始める前に自分の無知の輪郭を先に把握できる。

実例：「認証プロバイダー追加」に潜む7つの落とし穴

Shihipar氏は「新しい認証プロバイダーを追加する」という一見単純な要件でblindspot passを実行。以下の7つの落とし穴が浮かび上がった：

• RedisとPostgres間で二重書き込みが発生し、片方だけ更新されるとデータ不整合を起こす
• SAML認証の追加が既存の認可パイプラインを迂回する経路を生む
• 同種の実装は過去のPRで一度差し戻されている
• 「アイデンティティ」と「アカウント」という2つの概念が混同されている
• トークン更新のフラグが本番環境では無効化されている
• 新しいプロバイダーの登録には本来3段階の手順が必須
• ログアウト時にイベントが発行されず、セッションが残存し続ける

これらはどれも要件定義のチェックリストに載っていない類の見落としであり、確認を怠ったわけではなく、そもそも確認すべき項目として認識されていなかった。だからこそUnknown Unknownsであり、実装後のレビューでは拾いにくい。

blindspot pass以外の4つの習慣

• 複数案の並行生成：1案だけを詰めるより、複数のデザイン案をHTMLアーティファクトとして並行生成し比較検討する
• 構造化インタビュー：AI側から段階的に質問を投げさせ、説明する側が「聞かれるまで気づかなかった前提」を洗い出す
• 実装計画の優先順位付け：データモデルやUI設計など変更しにくい要素から先に固める
• implementation-notes.md：実装中の意思決定を記録し、後で不具合が出たときに判断の妥当性を検証可能にする

日本語での開発への示唆

Fable 5はAPI経由で100万トークンあたり入力10ドル、出力50ドル（約1610円／8050円）。トークン単価が上がるほど実装の手戻りコストも比例して膨らむ。日本語の指示は英語に比べて主語や前提条件を省略しやすく、「言わなくても分かるだろう」という思い込みがそのままUnknown Unknownsとして残りやすい。

Shihipar氏が示すのは特別な魔法ではなく、依頼を出す前に自分が何を知らないかを先に洗い出させる地味な手順だ。次に複雑な機能追加をAIに頼むときは、要件を書く前にまずblindspot passを1回挟んでみるとよい。