【小ネタ】 Anthropic の公式ブログ 「A Field Guide to Claude Fable」 を読んで（Claude Codeで「わからないこと」を潰す技術）
こんにちは。
Fable は何度でも蘇る
運用イノベーション部のかわいです。
2026年7月6日、Anthropic公式ブログに A Field Guide to Claude Fable: Finding Your Unknowns) という記事が公開されました。
（執筆者は Anthropic の Thariq Shihipar氏）
記事は「Claude に何を聞くべきかわかっていない状態」をどう解消するか？、という視点で書かれた、プロンプト設計の内容でした。
普段コンテキストまわりは意識しつつ使用しているつもりですが、あらためて問題提起されてみると「やっぱ難しいなあ」と感じたので、今回は同記事を紹介します。
Claude Code への指示出しや、プロンプト設計等のきっかけになれば！
地図と土地、そして unknowns
筆者はまず、Claude Codeと仕事をする感覚を「地図（map）」と「土地（territory）」の違いに例えています。
When working with Claude Code, I’m often reminded of the difference between the map and the territory.
- 地図 → プロンプトやスキル、コンテキストなど、自分がClaudeに与える情報
- 土地 → 実際にコードを書く場所。コードベースや現実世界の制約そのもの
この地図と土地のズレを、筆者は「unknowns（わからないこと、未知のもの）」と呼んでいます。Claude が何かわからないことにぶつかると、そのつど「たぶんこういう意図だろう」と推測して手を進めることになります。作業量が増えるほど、この推測の回数も増えてしまいます。
筆者いわく、Fable は「作業の質が、自分がunknownsをどれだけうまく言語化できるかにボトルネックされる」と初めて感じたモデルだそうです。
Claude Fable is the first model where I find the quality of the work is bottlenecked by my ability to clarify its unknowns.
モデルの性能が上がるほど、こちらの伝え方の精度がそのまま結果に跳ね返ってくる、という話は実感として納得できます。コンテキストやプロンプト、ほんとに大事。
「既知」と「未知」の4分類
記事では、知っていることと、知らないことを次の4つに分類しています。
| 分類 | 内容 |
|---|---|
| Known Knowns | プロンプトに書いてあること。自分が Claude に伝えてわかっていること |
| Known Unknowns | まだわかっていないが、わかっていないと自覚しているもの |
| Unknown Knowns | 当たり前すぎて書かないが、見れば"ああ、これか"とわかるもの |
| Unknown Unknowns | そもそも考慮すらしていないこと。自分がどこまで知らないかも把握できていない領域 |
（なんか、偽陽性とか偽陰性を思い出しましたが）
優秀なエージェンティックコーダーほど、この unknowns の絶対量が少ない、と筆者は書いています。
何が欲しいかを細部まで言語化できていて、コードベースとモデルの挙動の両方に精通しているから、とのこと（言語化だいじ）。
unknownsを見つけるためのプロンプト集
本題はここからで、記事では「実装前」「実装中」「実装後」の3フェーズに分けて、unknownsをあぶり出すプロンプトパターンを紹介しています。
実装前
自分が何を知らないかすら自覚できていないなら、Blind spot passが有効です。
「認証プロバイダを追加したいが、このコードベースの認証周りを何も知らない。ブラインドスポットパスをして、関連する unknown unknowns を洗い出してほしい」というように、自分の立場と知識レベルをそのまま伝えて依頼します。
In these situations, you can ask Claude to help you find your unknown unknowns and explain them to you.
UIデザインのように「見ればわかるが言葉にはできない」領域は、Brainstorms and prototypesを実践します。
実装してから直すと手戻りが大きい部分は、先に複数案をHTMLでモックしてもらってから選びます。
Another example is visual design, which for me, is something that is difficult to articulate, but I know what I want when I see it. In these cases, I’ll ask for several design approaches to an artifact.
次に、ブレインストーミングしてもなお曖昧さが残る場合、逆に Claude から聞いてもらうInterviewsという方法があります。
「アーキテクチャに影響する質問を優先して、1つずつ聞いてほしい」という指示だけで、こちらの言語化を待たずに輪郭がはっきりします。
I ask Claude to interview me about any unknowns or ambiguities. When asking Claude to interview you, try and give it context about your problem to guide its questions.
言葉で説明しきれないものは、Referencesとして実装済みのコードそのものを読ませます。
言語が違っていても、狙った挙動を持つ既存コードを読ませて再実装させるほうが、スクリーンショットより情報量が多いそうです。
This provides Claude much richer detail around the markup and structure, compared to for example a screenshot.
そして実装に入る前にImplementation planとして計画書を作らせます。ポイントは順番で、変更されやすい部分（データモデル、型定義、UXフロー）を先頭に、機械的なリファクタは末尾に回すよう指示します。
実装中
実装は計画通りに進まないことが多いです。
そこでImplementation notesとして、implementation-notes.md のような一時ファイルを用意し、計画からの逸脱（Deviations）とその判断理由を記録させながら進めます。エージェント側が別路線での対処を見つけてくれるかも。
The agent may find during its work that it needs to take a different tack due to an edge case it found in the code.
実装後
レビュー依頼や社内承認を得る場面では、Pitches and explainersとしてプロトタイプ、仕様書、実装ノートを1つのドキュメントにまとめさせます。
レビュアが自分と同じ unknowns からスタートできるようにする、という狙いです。
長時間のセッション後、差分を読むだけでは変更点を把握しきれないことがあります。
そこでQuizzes、変更内容を踏まえたクイズを作ってもらい、それに正解できてからマージするというチェック方法が紹介されています（これは好みが分かれそうですが、人間にも通じるやり方かも）。
Fable 自身のローンチ動画もこの手法で作られた
記事の後半では、筆者が Fable のローンチ動画を Claude Code だけで編集した際の実例が紹介されています。
動画編集は筆者にとって未経験の領域だったとのことで、実践の流れは以下。
- 音声の書き起こし精度に不安があったため、Whisper といったトランスクリプションの仕組みと、ffmpeg で無音区間や「えーと」といったフィラーを正確にカットできるかをClaudeに説明してもらう
- 発話に同期した UI が実現可能か自信がなかったため、Remotion でプロトタイプ動画を先に作らせて検証する
- 色調整（カラーグレーディング）については良い状態の判断基準すら持っていなかったため、複数案を出させるのではなく、まずカラーグレーディングとは何かを Claude に教えてもらうところから始める
技術検証だけでなく、自分の知識が足りない領域では教えてもらうことから入る、という順番が徹底されています。
まとめ的な
この公式ブログは、派手な新機能の話ではなく Claude Codeとの向き合い方そのものを扱った記事でした。
「指示が具体的すぎるとClaudeが本当は取るべきピボットを逃す。曖昧すぎると業界標準の無難な選択に流れる」というくだりは、普段プロンプトを書いていて感じるもどかしさ的な感情をそのまま言語化されたようでした、
特に Blind spot pass や Implementation notes あたりは、次の作業からそのまま真似できそうです。
完
