グラレコ
はじめに
「A Field Guide to Fable: Finding Your Unknowns」は、Anthropic の開発者 Thariq Shihipar 氏（@trq212）が 2026年7月に X で公開した、Claude Fable 5 との働き方ガイドです。核心の主張はシンプルで、「仕事の品質は、モデルの能力ではなく、自分が unknowns（わかっていないこと）を明確化する能力がボトルネックになる」というものです。
この記事では、そのガイドの内容を日本語で整理します。具体的には、unknowns を4つの象限に分ける考え方、実装前・実装中・実装後の3フェーズに分かれた11のテクニック（Blindspot Pass、1問ずつのインタビュー、変わりやすい決定を先頭に置く実装計画、マージ前クイズなど）、そして氏が Fable のローンチ動画を Claude Code だけで編集した実例です。Fable 5 に限らず、エージェンティックコーディング全般に効く内容になっています。
地図は領土ではない：なぜ「自分の unknowns」なのか 🗺️
ガイドの土台には「地図は領土ではない（the map is not the territory）」という古い警句があります。ここでの地図はあなたが書くプロンプトや指示で、領土は実際のコードベースや、あなたの頭の中にある暗黙の基準です。この2つは必ずズレます。
モデルが弱かった時代は、このズレはあまり問題になりませんでした。どうせ数分ごとに人間が確認して軌道修正するからです。ところが Fable 5 のように長時間自走できるモデルになると、ズレた地図のまま何時間も走ってしまう。モデルが有能になるほど、地図と領土のギャップはむしろ高くつくようになります。
だから Thariq 氏の結論は、「Fable と働くうえで最も重要なのは、自分自身の unknowns を発見して、より良くプロンプトできるようになることだ」（本人の X ポストの大意）となります。
この図が示すとおり、自走時間が長いほど「地図の精度」に成果が比例します。そして地図の穴は、モデル側ではなく自分側にあります。それを体系的に見つけようというのが、このガイドの全体像です。
unknowns の4象限：自分の盲点を分類する 🔲
ガイドはまず、プロンプトに含まれる（含まれない）情報を、ラムズフェルドの有名な分類を借りて4つの象限に整理します。
それぞれ、具体例で見るとぐっと分かりやすくなります。
| 象限 | 意味 | 具体例 |
|---|---|---|
| Known Knowns | プロンプトに明示した情報 | 「TypeScript で書いて。/settings に追加して」 |
| Known Unknowns | 未回答だと自覚している論点 | Redis にするかインメモリキャッシュにするか、まだ決めていない |
| Unknown Knowns | 書かないけれど、見れば分かる自分の基準 | どこにも書いていないのに、4px の border radius を見た瞬間「違う」と却下する（自分の中の正解は 8px） |
| Unknown Unknowns | 考慮すらしていない要素 | コードベースに既にレートリミッターが存在していた |
品質のボトルネックになるのは、下半分の2つ——Unknown Knowns と Unknown Unknowns です。上半分は自覚があるのでプロンプトに書けますが、下半分は自覚がないので書きようがありません。Claude がどれだけ有能でも、あなたの頭の中にしかない基準や、あなたも知らないコードベースの地雷は、指示からは読み取れないわけです。
ここからがガイドの本領で、この「書きようがない2象限」を意図的に掘り起こすテクニックが、実装前・実装中・実装後の3フェーズで11個紹介されています。
実装前①：Blindspot Pass — 地雷を先に踏んでもらう 💣
いちばん引用されているテクニックです。未知のコードベースに手を入れる前に、Claude に「自分の unknown unknowns を探して」と頼みます。著者サイトの例をそのまま引用します。
I'm adding a new SSO auth provider to Acme but I've never touched
the auth module. Do a blindspot pass: find my unknown unknowns in
this part of the codebase, explain each one, and tell me how to
prompt you better for the implementation.
（Acme に SSO 認証プロバイダを追加したいが、auth モジュールは触ったことがない。ブラインドスポット・パスをやってほしい：このあたりのコードで私の unknown unknowns を見つけて、それぞれ説明して、実装をより良く指示できるように教えて——という依頼です）
著者の例では、このパスで7つの盲点が出てきます。セッションが Redis と Postgres に二重書き込みされていて読み取りは Postgres 側だったこと。SAML プロバイダの実装が認証パイプラインの外にマウントされていて、レート制限と監査ログを迂回していたこと。過去に同じ試みが PR #2841 で revert されていたこと。ログアウト時には auth.session.revoked イベントの発行が必要なこと——どれも、テストは通るのに本番で刺さるタイプの地雷です。
ポイントは、成果物が「盲点リスト」で終わらないことです。例では7つの発見を制約として統合した改良版プロンプト（実装順序つき）まで作らせています。盲点を見つける行為自体を、次のプロンプトの材料にする流れです。
実装前②：インタビューとブレインストーミング 🎤
Unknown Knowns（暗黙のこだわり）を掘るテクニック群です。
The Interview（インタビュー） は、Claude に質問させる側に回ってもらう方法です。コツは2つあり、1問ずつ聞かせること、そしてアーキテクチャへの影響が大きい質問から順に聞かせることです。まとめて10問投げられても人間は雑に答えてしまうので、影響の大きい順に1問ずつ。成果物は決定事項の表と、それを反映した実装用プロンプトになります。
Teach Me My Unknowns（未知を教わる） は、専門領域に踏み込む前に、まず Claude に先生役をやってもらうテクニックです。例集では、カラーグレーディング未経験のまま動画を仕上げる場面で、Ingest → Correct → Grade → Match の4段階のメンタルモデル、基礎語彙（露出、ホワイトバランス）から応用語彙（LUT、リフト/ガンマ/ゲイン）へ登っていく「語彙のはしご」、スライダー付きのビフォーアフター・プレビュー、仕上がりを判定する6項目のチェックリストまでを1ページに作らせています。これで「いい感じにして」という曖昧な依頼が、「控えめなティール＆オレンジで。リフトをわずかにティール寄りに、ゲインをわずかに暖色に」という、その道の人に通じる指示へ変わります。
ブレインストーミングとプロトタイプは、視覚や設計の好みのように「言語化できないが見れば分かる」基準をあぶり出します。例集から3つ紹介します。
「Four Design Directions」は、同じ要件（レビューキューのダッシュボード）を、対照的な4方向——情報密度の高い運用コンソール風、余白の多いエディトリアル・カード風、かんばんとタイムラインのハイブリッド、キーボード主体のミニマルなターミナル風——で実際に描かせる例です。気に入った1案を選んだうえで、他の案から「ここだけ盗みたい」ディテールをチップで2〜3個選ぶと、選択内容が構造化された返信に自動でまとまります。発想の根っこは「想像するより、反応するほうが簡単」だという点にあります。
「Mock Before You Wire」は、実装に入る前に使い捨ての HTML モックを1枚作らせる例です。動画アノテーション用ツールバーの配置を、フローティング型・左レール型・シークバー下型の3案としてダミーデータ入りでクリック可能にし、触り比べてから決めます。触ってみて初めて「左レールはシークバーから遠くて使いにくい」のような、頭の中の検討では出てこない問題が浮かびます。
「Brainstorm the Intervention」は、オンボーディング直後の解約という課題に対して、コードベースを調べたうえで介入案を10個、「今日の午後に出せる」〜「四半期がかりの賭け」の軸に並べさせる例です。面白いのは、出てくる案の多くが「もう作ってあるのに繋がっていない機能」（眠っているフィーチャーフラグ、どこからも参照されていない招待テーブルなど）だという点です。介入案を推測ではなく、コードに実在するものへ接地させる狙いがあります。チェックボックスで「刺さった案」に印を付けると、優先順位つきの返信が組み上がる仕掛けです。
いずれにも共通するのは、4案見せられて初めて「あ、自分はこれが嫌いだったのか」と気づく体験です——Unknown Knowns が Known Knowns に変わる瞬間です。
Point at a Reference（参考を指す） も強力で、ガイドは「ソースコードこそ最良の参考資料になる（別言語の実装でも構わない）」としています。「このライブラリの実装みたいにして」と既存コードを渡すほうが、言葉を尽くすより正確に好みが伝わります。
実装前③：実装計画は「変わりやすい決定」を先頭に 📋
実装計画を作らせるときの並べ方にも、ガイドは明確な指針を出しています。変わりやすい決定を計画の先頭に置くことです。具体的にはデータモデル、型インターフェース、ユーザーに見える部分。逆に、機械的で結果が予想できる作業は後ろに回します。
並べ方の基準は「自分が変更しそうな順」です。あとから変えると痛い決定（スキーマ、インターフェース）は人間が見るべき箇所として前に集め、結果の予想がつく機械的な作業は「そこは任せる（I trust you on that part）」と Claude に委ねる。著者の例集ではこれを「The Tweakable Plan」と呼び、変更可能性のある決定にフラグを立てさせています。人間のレビューの注意を、効く場所に集める仕掛けと言えます。
実装中：implementation-notes.md に決定を記録させる 📝
実装が始まったら、Claude に一時ファイル implementation-notes.md を持たせて、途中で下した決定や、計画からの逸脱を記録させます。
これが効くのは、長い自走の最中にも unknowns が湧いてくるからです。「計画には Redis と書いたが、既存のユーティリティがインメモリ前提だったのでそちらに合わせた」のような判断は、記録がなければ闇に消えます。ノートに残っていれば、レビュー時に「その判断は違う」と拾えますし、次回のプロンプトを改善する材料にもなります。ループを回すたびに地図が正確になっていく仕組みです。
実装後：マージ前クイズと Buy-In ドキュメント ✅
実装が終わっても、まだ unknowns は残っています。今度は「Claude が何をしたか、自分は本当に理解しているか」という unknowns です。
Quiz Me Before I Merge（マージ前クイズ） は、変更内容の解説レポートを HTML で作らせたうえで、理解度クイズを出してもらうテクニックです。クイズに答えられなければ、自分はその変更を理解しないままマージしようとしている、ということが分かります。レビューを「読んだつもり」で終わらせない仕掛けです。
The Buy-In Doc（バイイン・ドキュメント） は、完成した機能への承認（サインオフ）を取るための提案ドキュメントを作らせるものです。例集の構成が具体的で参考になります。先頭に90秒のデモ動画ループ、次に問題の提示とスコープ、続いてレビュアーが挙げそうな想定質問5件（権限・性能・コンプライアンス・インフラ・API 方針）への仕様引用つきの先回り回答、仕様サマリー表、リスクとロールバック手順、最後に承認者（エンジニアリング・セキュリティ・デザイン・PM）ごとのサインオフ欄。レビュアーは流し読みする前提で、動画の証拠を先頭に置く設計です。反論に先回りして答える過程で、実装中に Claude が下した暗黙の判断（隠れた仮定）が表に出てくる効果もあります。
実例：ローンチ動画の編集を Claude Code だけでやってみた話 🎬
ガイドには、テクニックが実戦でどう繋がるかを示す実例が載っています。Thariq 氏は Fable のローンチ動画の編集を、動画編集の経験がほぼないまま Claude Code だけで行いました。
流れはこうです。まず Known Unknowns の特定から始めます——文字起こしの精度は足りるか、ffmpeg で狙ったフレームで正確にカットできるか、カラーグレーディングはそもそも可能か。次に Remotion（React で動画を作るフレームワーク）でプロトタイプを作って検証します。
面白いのはそのあとです。仕上がりがどうにも平板に見えたとき、氏はバリエーションを何案も出させて当てずっぽうに選ぶのではなく、「カラーグレーディングについて教えて」と教育モードに切り替えました。語彙を獲得してから指示に戻る。これは例集の「Teach Me My Unknowns」そのもので、曖昧な不満（なんか平板）を精密な指示（コントラストとカラーバランスの調整）に変換する動きです。
「良し悪しは分かるが言葉にできない」状態から、まず言葉を仕入れる。unknowns 発見の考え方が、コーディング以外の領域でもそのまま機能する良い例だと思います。
さじ加減：具体的すぎても、曖昧すぎてもいけない ⚖️
ガイドには大事な注意書きがあります。具体的に書きすぎると、Fable 5 は指示を硬直的に守りすぎるリスクがある。逆に曖昧すぎると、業界のデフォルトに寄せた汎用的な出力になる。
つまり「全部書き尽くせ」という話ではないんです。自分が本当にこだわる点（Unknown Knowns から昇格させた基準）は明確に書き、それ以外はモデルの判断に委ねる余白を残す。unknowns の掘り起こしは、書くべきことと委ねてよいことを仕分けるための作業だ、と捉えるのが正確です。
ちなみにこのガイドは、最近話題の Loop Engineering（エージェントを回すループ自体を設計する考え方）とちょうど補完関係にあります。ループ設計が「いつ起動し、どう検証し、いつ止まるか」という外側の構造を扱うのに対して、このガイドは各ループに投入するプロンプトの質という内側を扱っています。外側のループがどれだけ上手く回っていても、投入する地図がズレていれば、ズレた成果物が量産されるだけ——両方セットで効く関係です。
付録：companion examples 全11例の早見表 📚
ここまで紹介したテクニックを含め、著者サイトの例集は全部で11本あります。フェーズ別の早見表としてまとめておきます。
| # | 例 | フェーズ | ねらい |
|---|---|---|---|
| 1 | Blindspot Pass | 実装前 | 未知のコードベースの unknown unknowns を洗い出す |
| 2 | Teach Me My Unknowns | 実装前 | 専門語彙を先に教わり、曖昧な要望を精密な指示に変える |
| 3 | Four Design Directions | 実装前 | 対照的な4案への「反応」で暗黙の好みを顕在化する |
| 4 | Mock Before You Wire | 実装前 | 使い捨てモックで配置・使い勝手を配線前に検証する |
| 5 | Brainstorm the Intervention | 実装前 | コードに接地した介入案10個を「手軽〜野心的」の軸で並べる |
| 6 | The Interview | 実装前 | 影響の大きい質問から1問ずつ聞かせ、決定表に落とす |
| 7 | Point at a Reference | 実装前 | 参考コードを渡し、移植前に理解を検証する |
| 8 | The Tweakable Plan | 実装前 | 変わりやすい決定を先頭に置いた実装計画を作る |
| 9 | Implementation Notes | 実装中 | 決定と計画からの逸脱を implementation-notes.md に記録する |
| 10 | The Buy-In Doc | 実装後 | 反論に先回りした提案ドキュメントで承認を取る |
| 11 | Quiz Me Before I Merge | 実装後 | 変更レポート＋クイズで自分の理解を検証してからマージする |
11本すべて、著者サイトで実際の HTML 成果物として公開されています。本記事の説明はあくまで要約なので、手触りを知るには原物を触るのがいちばんです。
まとめ
このガイドでいちばん持ち帰ってほしいのは、「プロンプトの改善とは、書き方の工夫ではなく、自分の盲点の発見だ」という視点の転換です。Known Knowns をいくら丁寧に書き直しても、品質の上限は変わりません。効くのは、Unknown Knowns（暗黙のこだわり）と Unknown Unknowns(想定外の地雷)を意図的に掘り起こして、Known Knowns に昇格させることです。
次のステップとしては、まず Blindspot Pass を1回試すのがおすすめです。次に触る予定の、自分がよく知らないモジュールに対して「blindspot pass をして、私の unknown unknowns を見つけて、より良い指示の仕方を教えて」と頼んでみてください。出てきた盲点の数が、そのまま「これまで地図のズレたまま走らせていた距離」の実感になります。
companion examples の11本は、付録の早見表からたどれます。どれも著者のサイトで実際の HTML 成果物として公開されているので、気になったものから原物を触ってみてください。
参考
- A Field Guide to Fable: Finding Your Unknowns（Thariq Shihipar / @trq212, X） — 原典（X の認証壁内）
- Know Your Unknowns — companion examples（著者サイト） — 11テクニックの実例集。Blindspot Pass の逐語プロンプトの出典
- Anthropic developer shares prompting tips for Fable 5（The Decoder） — 4象限の枠組み・各テクニック・動画編集例を伝える英文解説