Claude Fable 5の品質は「未知」で決まる：Anthropic公式フィールドガイドをプロンプト例つきで読み解く

はじめに

Anthropicは2026年7月6日、公式ブログに「A field guide to Claude Fable 5: Finding your unknowns（Claude Fable 5フィールドガイド：あなたの未知を見つける）」を公開しました。 筆者は同社技術スタッフのThariq Shihipar氏です。

Claude Fable 5は、長時間のエージェント作業（人間が逐一指示せず、AIが自律的に進める作業）に向けた同社の最新モデルです。 Shihipar氏はこのモデルを「仕事の品質が、自分が未知を明確にできるかどうかで頭打ちになる最初のモデル」と評しています。 モデルの能力ではなく、使う側の「未知の扱い方」が上限を決めるようになった、という指摘です。

この記事では、ガイドが示す「未知（unknowns）」の考え方と8つのプロンプトパターンを、日本語で使えるプロンプト例に直しながら解説します。

「地図と領土」のずれが未知を生む

「地図は領土ではない」という言い回しは、学者アルフレッド・コージブスキーが1930年代に唱えた考え方で、表現（地図）と実物（領土）を混同するなという戒めです。 ガイドはこれを借りて、プロンプトやスキルなどClaudeに渡す情報を地図に、コードベースや現実の制約を領土にたとえます。

この両者のずれが 未知（unknowns） です。 Claudeは未知にぶつかるたび、依頼者の意図を推測して判断せざるを得ません。 任せる仕事が大きくなるほど、ぶつかる未知も増えます。

ガイドの立場では、事前の計画だけでは足りません。 実装の途中で未知が見つかることもあれば、見つけた未知が「そもそも別の解き方をすべきだ」と教えてくれることもあるからです。 そこでShihipar氏は、Fableとの作業を、実装の前、最中、後のそれぞれで未知を発見していく反復として捉えています。

未知はなぜ4種類に分けられるのか？

種類ごとに対処が違うからです。 ガイドは、Claudeに問題を持ち込むとき次の4つに分けると述べています。

• 既知の既知：プロンプトに書いた内容。何をしてほしいと伝えたか
• 既知の未知：まだ決めていないと自覚していること
• 未知の既知：当たり前すぎて書かないが、見せられれば「それだ」とわかること
• 未知の未知：考慮すること自体に気づいていないこと。どこまで良くできるかを知らないこと

この4分類は、2002年に当時の米国防長官ドナルド・ラムズフェルドが記者会見で使って広まった整理の応用です。

ガイドは、優れた使い手の例としてClaude Code開発者のBoris Cherny氏やBun開発者のJarred Sumner氏を挙げます。 2人のプロンプトを見ていると、欲しいものを細部まで知っており、コードベースとモデルの挙動の両方に通じていることがわかる、と氏は書いています。 それでも彼らは未知が残る前提で動きます。 未知を減らし、未知に備えることこそがエージェンティックコーディング（AIエージェントに開発を任せる進め方）の技能だ、というのがガイドの中心的な主張です。

指示の細かさにも均衡があります。 細かすぎれば、方針転換が適切な場面でもClaudeは指示に従い続けます。 曖昧すぎれば、業界の定石に沿った推測で進みますが、その定石が手元の仕事に合うとは限りません。 どちらの失敗も、未知を数えていないことから来ます。

実装前に未知を見つける5つのパターン

ガイドの中心は、実装に入る前の5つのパターンです。 いずれも、未知をまだ安いうちに発見するための道具です。 原文のプロンプトは英語のため、以下では意味を保った日本語訳を示します。

1. 盲点の洗い出し（Blind Spot Pass）

はじめての領域では「未知の未知」が多く、何を質問すべきかすら分かりません。 ガイドは「blind spot pass」「unknown unknowns」という言葉を文字どおりプロンプトに書き、自分が誰で何を知っているかを添えることを勧めています。

新しい認証プロバイダーを追加したいのですが、このコードベースの認証まわりを何も知りません。
盲点の洗い出し（blind spot pass）をして、私の「未知の未知」を特定し、
あなたへの指示をうまく書けるように手伝ってください。

2. ブレインストーミングとプロトタイプ

「見ればわかるが言葉にできない」未知の既知に効くパターンです。 仕様の小さな違いがコードでは大きく違う実装になるため、実装後に見つけると修正が高くつきます。

このデータのダッシュボードが欲しいのですが、視覚的なセンスに自信がなく、何ができるのかも知りません。
まったく方向性の違うデザイン案を4つ、1枚のHTMLページにして見せてください。それを見て私が反応します。

大まかな課題はこれです：利用者がオンボーディング直後に離脱します。
コードベースを調べて、介入できる場所を、安上がりな順に10個挙げてください。響いたものを伝えます。

Shihipar氏は、ほぼ毎回の作業をこの探索から始めると書いています。 Claudeが自分では思いつかない筋の良い案を見つけることもあれば、逆に大局を外すこともあるため、範囲を狭すぎず広すぎず定める助けになるからです。

3. インタビュー

ブレインストーミングを終えても残る曖昧さは、Claudeに質問させて潰します。

曖昧な点について、1問ずつ私にインタビューしてください。
答えによってアーキテクチャが変わる質問を優先してください。

4. 参照（リファレンス）

欲しいものを言葉で説明できないときは、実物を渡します。 図や資料や画像も使えますが、ガイドが最良の参照として挙げるのはソースコードです。 言語が違っても構いません。

vendor/rate-limiter にあるRustのクレートが、私の欲しいバックオフ挙動そのものです。
読んで、同じ意味論をこちらのTypeScript APIクライアントに実装し直してください。

5. 実装計画

実装に入る前に、変わりそうな判断を先頭に置いた計画を書かせ、レビューします。

実装計画をHTMLで書いてください。ただし、私が調整しそうな判断を先頭に置いてください。
データモデルの変更、新しい型インターフェース、ユーザーに見える部分です。
機械的なリファクタリングは末尾で構いません。そこはあなたを信頼します。

実装中と実装後には何をすればいいのか？

実装中は、判断の記録を残させます。 どれだけ計画しても未知の未知は潜んでいて、エージェントは作業中に見つけたエッジケースのために方針を変えることがあるからです。

implementation-notes.md というファイルを残してください。
計画から外れざるを得ないエッジケースに当たったら、保守的な選択肢を選び、
「Deviations（逸脱）」の見出しの下に記録して、作業を続けてください。

実装後のパターンは2つです。 1つ目は、承認を得るためのピッチ資料（提案をまとめた説明資料）です。 レビュアーは多くの場合、依頼者が最初に持っていたのと同じ未知から出発するため、未知に答える資料は理解と承認の両方を速めます。

プロトタイプ、仕様、実装ノートを1つの資料にまとめてください。
Slackに貼って賛同をもらうためのものです。冒頭はデモのGIFにしてください。

2つ目はクイズです。 長い作業の後では、Claudeは依頼者が把握しているより多くのことを成し遂げています。 差分を読むだけでは挙動の理解は浅いままなので、変更内容のレポートとクイズを作らせます。

この変更で起きたことをすべて理解しておきたいです。
背景、直観、何をしたかを含むHTMLレポートを作り、最後に私が合格すべきクイズを付けてください。

Shihipar氏は、クイズに満点で合格するまでマージしないと書いています。

コード以外にも効くのか？Fable発表動画の実例

効きます。 ガイドの締めくくりの実例は、開発ではなく動画編集です。 Fable 5の発表動画は、Claude Codeを使って最初から最後まで編集されました。

Shihipar氏にとって動画編集は経験のない領域でした。 そこで氏は、知っていることから始めます。 Claudeがコードで動画の編集と文字起こしをできることは知っていたため、まず文字起こしの仕組み（Whisperなど）を説明させ、言い淀みや長い間をffmpegで正確に切れるかを確かめました。 話している言葉に同期した画面表示についても、可能かどうか分からなかったため、Remotionという動画生成ライブラリで試作品を作らせて検証しています。

興味深いのは色調整（カラーグレーディング）の逸話です。 氏は最初、複数の候補を作らせて選ぼうとしましたが、そもそも自分が「良い色調整」を見分けられないことに気づきました。 そこで方針を変え、色調整の基礎を自分に教えるようClaudeに頼んでいます。 候補から選ぶ前に、選べる目を作ったわけです。

日本の開発現場への示唆

ここからは、ガイドを踏まえた私たちZenChAIneの考察です。

未知の発見は、日本の受託開発では要件定義という工程の名前で値付けされてきた作業です。 ヒアリングを重ね、決まっていないことを洗い出し、文書に固める。 ガイドのパターンは、この探索の1往復を数分のプロンプトまで安くします。 インタビューのパターンでは、質問する側がAIに替わり、人間は答える側に回ります。

一方で、4分類を日本の組織に当てはめると、未知の未知の多くは暗黙知（社内規約、過去の障害の経緯、部署間の力関係など、文書になっていない知識）に潜んでいます。 リポジトリとWebを高速に探索できるClaudeでも、どこにも書かれていないことは見つけられません。 盲点の洗い出しを機能させる前提として、暗黙知をCLAUDE.mdやスキルとして書き下ろしておく習慣が効きます。 エージェントが働ける環境を整えるこの作業については、エージェント・レディネスの実践でも扱いました。

もう1つ、動画編集の逸話は導入の順序を示しています。 氏は変化の大きい判断（色調整の良し悪し）を、選択肢の比較ではなく学習で解きました。 AIの出力を選べるだけの目がない領域では、まず教わることが結果的に近道になります。

よくある質問

Q. 「未知の未知」に気づいていないのに、どう指示すればいいですか？

A. 見つける作業自体をClaudeに頼みます。 「盲点の洗い出し（blind spot pass）をして」「私の未知の未知を特定して」と文字どおり書き、自分の経験や知識の現在地を添えるのがガイドの推奨です。

Q. Claude Fable 5でなくても使えるテクニックですか？

A. 使えます。 ただしガイドは、モデルが強くなるほど正しい進め方の効果が大きくなると述べており、長時間の自律作業をこなすFable 5では「未知の明確化」がそのまま品質の上限になるという位置づけです。

Q. 計画を立てても長いタスクが失敗するのはなぜですか？

A. どれだけ計画しても未知の未知が残るためです。 ガイドは、失敗して返ってきた長期タスクは「未知の定義に時間を使うべきだった」という合図と読み、実装中の逸脱を記録させて次の試行に学びを持ち越す方法を勧めています。

まとめ

ガイドの主張は1つの文に要約できます。 説明、ブレインストーミング、インタビュー、プロトタイプ、参照はどれも、修正が高くつく前に「知らなかったこと」を安く見つける手段です。

• 未知とは、Claudeに渡した指示（地図）と現実の制約（領土）のずれ
• 未知は4種類に分け、種類に合うパターンで潰す
• 実装前に5パターン、実装中に1パターン、実装後に2パターン
• 長期タスクの失敗は、未知の定義不足の合図として読む

ガイドは「次のプロジェクトは、未知を見つける手伝いをClaudeに頼むことから始めよう」と結ばれています。 ZenChAIneでも、エージェントに未知を探させるこの進め方を記事制作と開発の両方で使っており、導入を検討する企業の支援を行っています。

参考ソース

• A field guide to Claude Fable 5: Finding your unknowns（英語原文）
• 同記事の日本語版
• Fable 5発表動画（Claude Codeで編集）