TL;DR
- この記事で分かること: AnthropicのThariq Shihipar氏が提唱する「blindspot pass」という盲点発見プロンプト技法の仕組み
- なぜ今重要か: AIの実行力が上がるほど、指示を出す人間側の設計力の差が成果を左右するようになるため
- 読後に活かせること: 実装を頼む前に4象限で盲点を洗い出し、認証機能のような複雑な要件で落とし穴を事前に潰す具体的な手順
AIコーディングエージェントに実装を任せたのに、思わぬ箇所で不具合が出た経験はないだろうか。仕様を丁寧に説明したつもりでも、認証まわりのような複雑な機能では、そもそも自分が何を見落としているかに気づけないまま指示を出してしまう。Anthropicの新モデル群「Claude 5」が公開され、実装力そのものは大きく底上げされた。それでも同社のClaude CodeチームのエンジニアであるThariq Shihipar氏は、うまくいかない原因はモデルの性能ではなく、指示を出す人間側の「気づけない盲点」にあると指摘する。氏が公開した「blindspot pass」という技法は、実装を頼む前にAI自身へ盲点探しを依頼するという逆転の発想だ。
AIが実行の8割を担っても、判断のボトルネックは消えない
Anthropicは2026年6月9日、新シリーズ「Claude 5」を発表した。その一角である「Fable 5」は「Mythos級」と呼ばれる区分に属する、これまでのOpusを上回る最上位モデルで、公開翌日の6月10日には東京で開発者向けイベント「Code with Claude」も開催されている。Fable 5には安全策も組み込まれており、一部の質問はClaude Opus 4.8が代わりに応答する設計だが、この切り替えは平均でセッションの5%未満にとどまるという。
モデルの実装力そのものが底上げされる中、Shihipar氏はFable 5向けのプロンプト設計tipsをXスレッドと自身のブログで公開した。元スレッドは2026年6月11日に公開されたと報じられており、公開から数時間で約28万8000回表示されたとされる。
その内容を裏付けるように、Anthropicは2025年10月から2026年4月にかけての約40万件のClaude Codeセッション(利用者約23万5000人)を分析した調査結果を2026年6月16日ごろに公表した。典型的なセッションでは、人間が計画判断の約70%を、Claudeが実行判断の約80%を担っていたという。
2つの数字を並べると、AIの役割拡大が示すのは人間の関与縮小ではないと分かる。計画判断の7割は依然として人間が担っており、実行の8割をAIが引き受けるようになったことで、計画段階に紛れ込んだわずかな見落としが、より広い実行範囲に増幅されて伝播する構造に変わったということだ。この見立てをShihipar氏が体系化したのが、次に説明する4象限の盲点分類だ。
4象限で「気づけない盲点」を可視化するblindspot pass
Shihipar氏が使う分類は「Known Knowns(既知の既知)」「Known Unknowns(既知の未知)」「Unknown Knowns(無自覚の既知)」「Unknown Unknowns(未知の未知)」の4つに知識を仕分ける枠組みだ。このうちKnown UnknownsとUnknown Unknownsという言葉は、2002年2月12日に当時の米国防長官Donald Rumsfeld氏が国防総省の記者会見で使った表現に由来する。イラクの大量破壊兵器をめぐる文脈での発言は当時批判も浴びたが、後年になって危機管理の実務的な知恵として再評価されている。
コーディングに当てはめると、4つの区分はこうなる。Known Knownsは仕様書に明記された要件そのもの。Known Unknownsは「分からないと自覚している」項目で、新しいAPIの挙動など調べれば埋まる空白だ。Unknown Knownsはコードベースの奥に眠る過去の実装パターンや意思決定で、既に存在するのに自分が意識していない知識を指す。そして最も厄介なUnknown Unknownsは、存在にすら気づいていない前提であり、実装が終わってから初めて表面化する。
前者3つは意識さえすれば調べられる、あるいは説明を受ければ埋まる空白だ。一方でUnknown Unknownsは「何を質問すればいいか」自体が分からない状態にあるため、通常のヒアリングやレビューでは拾い上げにくい。Shihipar氏の技法が焦点を当てるのは、この最後の区分だけを狙い撃ちで洗い出す点にある。
blindspot passのやり方は単純だ。実装用のプロンプトを書く前に、まずAIへ「このコードベースの認証モジュールについて何も知らない。blindspot passをして、自分に関係するunknown unknownsを洗い出すのを手伝ってほしい」と依頼する。AIはコードベースを検索し、依存関係やテストの有無、過去のコミット履歴などから、依頼者が言及していない前提や見落としがちな箇所を列挙して返す。これを実装の起点にすることで、要件を書き始める前に自分の無知の輪郭を先に把握できる。
「認証プロバイダーを1つ追加する」に潜む7つの落とし穴
この技法の効果を示す例として、Shihipar氏は自身のサイトで「新しい認証プロバイダーを追加する」という一見単純な要件を取り上げている。額面通りに読めば、既存の認証フローに新しいログイン方式を1つ足すだけの作業に見える。実際にblindspot passを走らせると、次の7つの落とし穴が浮かび上がったという。
- RedisとPostgres間で二重書き込みが発生し、片方だけ更新されるとデータ不整合を起こす
- SAMLによる認証を追加すると、既存の認可パイプラインを迂回してしまう経路が生まれる
- 同種の実装は過去のプルリクエストで一度差し戻されている
- 「アイデンティティ」と「アカウント」という2つの概念が混同されている
- トークン更新のフラグが本番環境では無効化されている
- 新しいプロバイダーの登録には本来3段階の手順が必須
- ログアウト時にイベントが発行されず、セッションが残存し続ける
これら7項目に共通するのは、どれも要件定義のチェックリストに載っていない類の見落としだという点だ。担当者が確認を怠ったわけではなく、そもそも確認すべき項目として認識されていなかった。だからこそUnknown Unknownsであり、実装後のレビューやテストでは拾いにくい。Shihipar氏はこの実例を踏まえ、次のように述べている。「あらゆる説明、ブレインストーミング、インタビュー、プロトタイプ、参考資料は、修正コストが高くつく前に自分が知らなかったことを知るための安価な手段だ」。
blindspot pass以外にも。実装前に盲点を潰す4つの習慣
Shihipar氏はblindspot pass以外にも、実装前のルーティンとして4つの工夫を挙げている。複数のデザイン案をHTMLアーティファクトとして並行生成し、実装前に比較検討するブレインストーミングもその1つだ。1案だけを詰めるより、選択肢を並べたほうが「他に取り得た道」が見え、結果として何を選ばなかったかが自覚できる。単一案の検討では気づけない前提の差異も、複数案を横に並べることで自然と浮かび上がってくる。
曖昧な点を1問ずつ確認していく構造化インタビューも同様の狙いを持つ。要件を一括で説明させるのではなく、AI側から段階的に質問を投げさせることで、説明する側が「聞かれるまで気づかなかった前提」を洗い出せる。実装計画自体も、データモデルやUI設計のように後から変更しにくい要素に絞って先に固め、細部は実装しながら詰めるという順序が推奨されている。
もう1つの工夫が、実装中の意思決定を記録する一時ファイル「implementation-notes.md」だ。なぜその設計を選んだのかを都度書き残しておけば、後で不具合が出たときに「その判断が今も妥当か」を検証しやすくなる。さらに実装が終わった後、AIにクイズ形式で変更内容を問わせる検証も紹介されている。差分をただ承認するのではなく、何がどう変わったかを自分の言葉で答えられるかを試すことで、理解しないままマージしてしまう事態を防ぐ狙いだ。
盲点探しにもコストはある。日本の開発現場への示唆
この技法にも見えないコストがある。blindspot pass自体がAIとの追加のやり取りを必要とし、その分の時間とトークンを消費する。AIが提示する「盲点」が実在しない懸念にすぎない、いわゆる誤検出を含む可能性も否定できない。さらにAnthropicが示した「人間70%・AI80%」という数字はセッション全体の傾向であり、blindspot passという個別の技法が実際に手戻りを減らしたかどうかを独立に検証したベンチマークは、今のところ確認できない。Anthropic自身の調査であることを踏まえれば、自社モデルに有利な語り口になっている可能性も考慮する必要がある。
日本の開発者にとっても他人事ではない。Fable 5はAPI経由で100万トークンあたり入力10ドル、出力50ドルで提供されており、2026年7月上旬のドル円相場(1ドル=161円換算)では入力約1610円、出力約8050円に相当する。トークン単価が上がるほど、実装の手戻りにかかるコストも比例して膨らむため、事前の盲点洗い出しに投資する動機は強まる。日本語の指示は英語に比べて主語や前提条件を省略しやすく、「言わなくても分かるだろう」という思い込みがそのままUnknown Unknownsとして残りやすい。Anthropicが東京でも開発者イベントを開いている以上、この技法は英語圏だけの話では終わらない。
モデルの実行力が上がるほど、失敗の芽は実装そのものではなく計画段階の見落としに移っていく。Shihipar氏が示すのは特別な魔法ではなく、依頼を出す前に自分が何を知らないかを先に洗い出させる地味な手順だ。次に複雑な機能追加をAIに頼むときは、要件を書く前にまずblindspot passを1回挟んでみるとよい。