グラレコ

はじめに

「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象限の枠組み・各テクニック・動画編集例を伝える英文解説