Fable フィールドガイド：自分の未知（Unknowns）を見つける

• Claude Fable 5 の作業の核心は、ユーザーが与える 地図（map、プロンプト・スキル・コンテキスト） と、作業が実際に起こる 領土（territory、コードベース・現実・制約） のギャップ、すなわち 未知（unknowns） を見つけて狭めること
• Fable は、作業品質が 未知を明確にするユーザーの能力 に左右される最初のモデルであり、作業量が増えるほど直面する未知も増える
• 未知は Known Knowns / Known Unknowns / Unknown Knowns / Unknown Unknowns の4種類に分けられ、未知を減らして備えることがエージェント的コーディングの中核的な能力
• 実装の 前・中・後 を通じて、blindspot pass、ブレインストーミング、インタビュー、リファレンス、実装計画、実装ノート、クイズなどの反復的手法で未知を発見する
• 説明・ブレインストーミング・インタビュー・プロトタイプ・リファレンスは、問題が 高コストになる前に低コストで未知を発見 する手段であり、次のプロジェクトを Claude に未知探しを依頼することから始めるのが重要

---

地図と領土、そして未知（Unknowns）

• 地図は実行する作業の表現であり、プロンプト・スキル・コンテキスト、つまり Claude に与えるものを指す。一方、領土は作業が実際に起こる コードベース・現実・実際の制約
• 地図と領土の差がそのまま 未知（unknowns） であり、Claude は未知にぶつかると、ユーザーが望むものについての最善の推測で判断を下さなければならない
• Fable は、作業品質が 未知を明確にする能力にボトルネック を持つ最初のモデル
• 事前計画だけでは不十分で、未知は実装の深部で見つかることもあれば、問題をそもそも 別のやり方で解くべき ことを知らせることもある
• Fable の作業は、実装前・実装中・実装後を通じて未知を発見する反復プロセス
• 未知のものを見つけるのに役立ついくつかの参考資料 は後で参照するとよい

未知を知る（Knowing your unknowns）

• 問題を4種類に分解する
  • Known Knowns: プロンプトに含まれているもの、エージェントに「欲しい」と伝えていること
  • Known Unknowns: まだ把握していないが、把握していないという事実は認識しているもの
  • Unknown Knowns: あまりに当然なので書き留めないが、見れば分かるもの
  • Unknown Unknowns: まったく考慮していないもの、認識していない知識、どれほど良くできるのかも分からないもの
• 優れたエージェント的コーダーは未知が比較的少なく、コードベースとモデルの挙動に 深く同期（in-sync） していて、何を望んでいるかを詳細に把握している
• 未知を減らして備えることは、Claude と作業しながら向上できるスキル

Claude があなたを助けられるようにする（Help Claude help you）

• 指示はバランスが重要で、具体的すぎると方向転換のほうが良い場合でも指示に従ってしまい、曖昧すぎると課題に合わない 業界の通念（best practices） に基づいた選択をしてしまう
• 未知を考慮しないと両側で失敗し、道が塞がっている時と開けている時の区別がつかないまま Claude に方向転換を期待することになる
• Claude はコードベースやインターネットを素早く検索でき、平均的なトピックについてより多くを知っており、失敗から素早く反復 できるため、未知の発見を加速させる
• 最も重要なのは 出発点に関するコンテキストの提供 であり、自分の思考の現在地、問題やコードベースに対する経験を明かし、思考パートナーのように協働すること
• 以前に Claude で HTML を使うこと について書いたことがあるが、多くの場合 HTML アーティファクト は可視化や表現に最適

実装前（Pre-implementation）

• Blind Spot Pass

  • 新しい領域の機能作成やデザインの反復のような不慣れな作業では unknown unknowns が多く、何を質問すべきか、何が良いのか、過去の作業、避けるべき落とし穴が分からないことがある
  • Claude に unknown unknowns を見つけて説明してもらうよう依頼し、"blindspot pass"、"unknown unknowns" という表現をそのまま使い、自分が誰で何を知っているかというコンテキストを与えることが重要
  • 例示プロンプト
    • "新しい auth provider の追加作業をしているが、このコードベースの auth モジュールをまったく知らない。blindspot pass で関連する unknown unknowns を把握して、より良くプロンプトできるよう助けてほしい"
    • "color grading が何か分からないが、この動画を grade しなければならない。より良くプロンプトできるよう、color grading の unknown unknowns を理解できるよう教えてほしい"

• ブレインストーミングとプロトタイプ（Brainstorms and prototypes）

  • unknown knowns が多い領域、つまり見れば分かるが事前定義しにくい基準が多い場合は、Claude とブレインストーミングやプロトタイプを進める
  • unknown knowns を実装中ではなく プロトタイピング初期に特定して言語化 することには価値がある。仕様の小さな変化がコード実装を大きく変え、以前の変更を巻き戻しにくくなることがあるため
    • 例: バックエンドルートやフロントエンド状態なしで、フレームにボタンを追加した見た目だけを確認したい場合
  • ビジュアルデザインは明確に表現しにくいが、見れば欲しいものが分かる領域であり、複数のデザインアプローチを依頼する
  • ほぼすべてのコーディングセッションを 探索・ブレインストーミング段階から開始 して意図を持ってスコープを定義することで、スコープが狭すぎたり広すぎたりするのを防げる
  • 例示プロンプト
    • "このデータ用のダッシュボードが欲しいが、視覚的センスがなく何が可能か分からない。まったく異なる4つのデザイン方向の HTML ページを作って、反応できるようにしてほしい"
    • "接続作業の前に、ダミーデータで新しいエディターツールバーをモックアップした単一の HTML ファイルを作ってほしい。実際のアプリを触る前にレイアウトに反応したい"
    • "大まかな問題はオンボーディング後のユーザー離脱だ。コードベースを検索して、最も低コストなものから最も野心的なものまで、介入できる10か所をブレインストーミングしてほしい"

• インタビュー（Interviews）

  • 十分にブレインストーミングした後でも未知が残るなら、Claude に未知や曖昧さについて インタビュー してもらい、質問を引き出せるよう問題のコンテキストを提供する
  • 例示プロンプト
    • "曖昧な部分を一度に1つずつ質問し、私の答えがアーキテクチャを変えうる質問を優先してほしい"

• リファレンス（References）

  • 望むものを詳細に描写できないとき、最良の答えはリファレンスであり、図、文書、画像でもよいが、ソースコードが絶対的に最高のリファレンス
  • 特定のやり方で実装されたライブラリや気に入ったデザインコンポーネントがあるなら、別言語であってもフォルダを指し示して見るべき場所を伝える
  • Claude Design も同じで、気に入った Web サイトのモジュールを指し示せば、スクリーンショットではなく 基になるコードを読んで、マークアップ、構造、実際の実装方法について豊富な情報を与えてくれる
  • 例示プロンプト
    • "vendor/rate-limiter にあるこの Rust crate は、欲しい backoff の挙動を正確に実装している。これを読み、同じ意味を私たちの TypeScript API クライアントに再実装してほしい"

• 実装計画（Implementation Plans）

  • 実装の準備ができたら、変更可能性が最も高い部分（データモデル、型インターフェース、UX フロー）に焦点を当てた実装計画をレビュー用に依頼し、修正が必要な箇所を表面化させる
  • 例示プロンプト
    • "HTML で実装計画を書き、私が最も手を入れそうな決定（データモデル変更、新しい型インターフェース、ユーザー向け要素）を先に置き、機械的なリファクタリングは一番下に回してほしい"

実装中（During implementation）

• 実装ノート（Implementation notes）

  • 計画に満足したら新しいセッションを作り、仕様ファイルやプロトタイプなどのアーティファクトをプロンプトに渡して、エージェントに実装を依頼する
  • どれだけ計画しても unknown unknowns は常に潜んで おり、エージェントが作業中に見つけたエッジケースによって別のやり方を取る必要があるかもしれない
  • Claude Code に、一時的な implementation-notes.md（または .html） ファイルに下した決定を記録させ、次の試行で学習できるようにする
  • 例示プロンプト
    • "implementation-notes.md ファイルを維持せよ。計画から外れさせるエッジケースに出会ったら保守的な選択をし、'Deviations' に記録したうえで続行せよ"

実装後（Post implementation）

• ピッチと説明資料（Pitches and explainers）

  • 何かをリリースするうえで最も重要な部分の1つは 合意と承認の確保 であり、最終文書にピッチや説明用アーティファクトを作ると役立つ
    • レビュアーがあなたと同じ未知から出発する場合、理解を加速 する
    • 専門家が未知やよくある失敗ポイントを考慮したか確認したい場合、承認を加速 する
  • 例示プロンプト
    • "プロトタイプ・仕様・実装ノートを、Slack に投稿して合意を得るための単一文書にまとめてほしい。デモ GIF を先頭に置いてほしい"

• クイズ（Quizzes）

  • 長い作業セッションの後では、Claude が想定以上に多くをやっていることがあり、コード diff だけでは既存コードパスに依存する挙動を表面的にしか理解できない
  • コンテキストを与えたうえで、Claude に変更点について クイズを作ってもらうよう依頼 し、理解を確認して、クイズを完璧に通過した後にのみマージする
  • 例示プロンプト
    • "この変更で起きたすべてを理解したい。コンテキスト、直感、実施内容などを含む HTML レポートと、必ず合格しなければならないクイズを末尾に付けてほしい"

Fable のリリース事例に見る統合（How this comes together）

• Fable ローンチ動画 は全面的に Claude Code で編集 されており、新しい領域であり専門分野でもなかった
• 分かっていることから始め、Claude がコードで動画編集や文字起こしを行えることは知っていたが、精度に確信がなかったため、Whisper 方式の文字起こし原理 と ffmpeg で ums や長い無音を正確に切り取れるかの説明を求めた
• 話している単語とタイミングが合った UI を望んでいたが、可能かどうか確信がなかったため、Remotion と文字起こし でプロトタイプ動画を作って検証した
• 動画がやや muted に見えたのは color grading のせいだと分かったが、それが何かは分からなかったため、バリエーションを選り分ける代わりに color grading を教えてほしいと依頼 して未知を発見した

地図と領土を合わせる（Matching the Map and Territory）

• モデルが良くなるほど、正しいアプローチによってより多くを達成できるようになり、長期課題がうまくいかない場合は、たいてい 未知の定義 や Claude がその場で対応できる実装計画により多くの時間を使う必要がある
• すべての説明・ブレインストーミング・インタビュー・プロトタイプ・リファレンスは、問題が 高コストになる前に低コストで未知を発見 するための手段
• 次のプロジェクトは、Claude に未知探しを依頼することから始めるのが重要