深度・小互解読

Claude Fable 5 と仕事をする上での真の力量は、まず自分自身の「未知」を見つけ出すことにある

Anthropic の Thariq がまとめた要点:Claude Fable 5 と協業する際、成果物の質を左右するのは自分の「未知」をどれだけ明確に語れるかにかかっている。このフィールドガイドは実装前・実装中・実装後の3段階に分けて、未知を見つけ出す8つの技法を提示し、それぞれにそのまま使えるプロンプトを添えている。
1分でわかる要点
  • Anthropic の社員 Thariq が長文を発表し、Claude Fable 5 と協業する際に「未知」を特定するための実践的な技法をまとめた。
  • 核心となるフレームワークは未知を四つに分類する:既知の既知、既知の未知、未知の既知、未知の未知。
  • 8つの具体的な技法は「実装前 / 実装中 / 実装後」の三段階に分けて配置され、ブラインドスポットスキャン、逆インタビュー、参考ソースコード、実装ノート、小テストなどをカバーする。
  • 各技法には、そのままコピーして使える英語のプロンプト原文が添えられている。
  • 事例パートでは、この方法論を著者自身も不慣れな Fable リリース動画の編集という領域にどう応用したかを紹介する。
スタンス表明:著者の Thariq は Anthropic の社員(Claude Code / Claude Design チーム)であり、本文中の手法は自社モデル Claude Fable 5 を軸に展開している。サンプルプロンプトと事例はいずれも本人のプロジェクト実践から得たものである。
1誰が書いたか、詰まる箇所は何なのか

Claude と仕事をする時、詰まる箇所は一体どこなのか

Thariq(Anthropic の Claude Code / Claude Design チームメンバー)は2026年7月3日、X で長文を発表し、Claude Fable 5 と協業する際に「未知」を特定する実践的な技法をまとめた。

Claude Fable 5 と一緒にコードを書く中で、著者は成果物の質がいつも同じ箇所で詰まることに気づいた——自分がまだ考え抜けていない「未知」をどれだけ明確に語れるかである。この記事は「未知を見つける」ことを実行可能な8つの技法に分解し、それぞれにそのままコピーして使えるプロンプトを添えている。

読む価値があるポイント:著者は Anthropic Claude Code / Claude Design チームのメンバーであり、8つの技法は Fable リリース動画の編集など実際のプロジェクトから直接抽出された、実践経験に基づくものである。各技法には英語のプロンプト原文が添えられており、そのままコピーして使える。

著者が繰り返し思い知らされてきた古い格言がある——地図は地形ではない。地図、つまりやるべきことの簡略化された記述は、あなたが Claude に与えるプロンプト、スキル、コンテキストである。地形は、実際に物事が行われる場所——コードベース、現実世界、そこにある本当の制約である。両者のあいだのズレこそが、彼の言う「未知」だ。Claude がある未知にぶつかった時、それはあなたが何を望んでいるかについての最善の推測に頼って判断を下すしかない。やるべきことが多いほど、ぶつかる未知も多くなる。

N 地図=Claudeへのプロンプト ズレ=未知 地形=実コードベースと制約
地図は簡略化された記述であり、地形は実際に物事が行われる場所——両者は決して噛み合わない。羅針盤はスクロールに合わせて静かに振れ続け、そのズレは常に存在する。
地図と地形の図
原文の図版:地図はあなたが Claude に与えるプロンプト・スキル・コンテキストであり、地形は実際に物事が行われるコードベースと現実の制約である。両者のズレこそが「未知」である。出典:X・Thariq

著者いわく、Fable は「成果物の質が、自分の未知をどれだけ明確に語れるかという能力に左右される」と初めて感じさせたモデルだという。しかも事前に計画を立てるだけでは十分ではないことが多い——未知は実装の奥深くに隠れていて、そこで初めて姿を現すこともあれば、逆にこの問題は実はまったく違うやり方で解くべきだと気づかせてくれることもある。だから Fable との協業とは、実装の前・最中・後を通じて絶えず自分自身の未知を発見し続けるプロセスなのだ。

4
種類の未知:既知の既知 / 既知の未知 / 未知の既知 / 未知の未知
3
段階:実装前 / 実装中 / 実装後、技法はこの区分に沿って配置
8
個のそのまま使える技法、各技法に英語のプロンプト原文つき
1
本の全体を貫く比喩:地図は地形ではなく、ズレこそが探すべき未知
2四種類の「わからないこと」

あなたに足りないのは、一体どの種類の「わからないこと」なのか

著者はある問題を持って Claude に向き合う時、まず手元の未知を四つの枠に分けるのを習慣にしている。大きな仕事ほど、後の二つの枠に陥りやすい——まったく意識していなかったこと、あるいは当たり前すぎて決して書き留めることのないものだ。

既知の既知

プロンプトに書き込み、Claude に何が欲しいかを明確に伝えた部分。

「ログインボタンが欲しい、右上に置いて」

既知の未知

まだ考え抜けていないと自覚していて、ここに落とし穴があると意識している部分。

「このリストにページネーションを付けるか、まだ決めていない」

未知の既知

当たり前すぎて書き留めることはないが、見た瞬間に良し悪しがわかる常識。

「この配色は刺激的すぎる、一目でダメだとわかる」

未知の未知

そもそも考えたこともなく、「どこまでうまくできるか」すら知らない盲点。

「動画のポーズをコードで自動カットできるとは知らなかった」

未知の四象限マトリクス
原文の図版:著者は着手前の未知を四つに分類し、大きなプロジェクトほど後の二つに陥りやすいとしている。出典:X・Thariq
たとえて言うなら

新居への引っ越しに少し似ている。既知の既知は書き終えた買い物リスト。既知の未知はリビングにまだ家具が足りないとわかっているが、何を買うか決めていない状態。未知の既知は書き留めたことはないが、見た瞬間に「このコンセントの位置はおかしい」とわかること。未知の未知は床暖房を入れられるということ自体、そもそも知らなかったことだ。

著者の観察によれば、最も優れた協業者たち——例えば Boris Cherny や Jarred Sumner——は未知が相対的に少ない。彼らのプロンプトを見ると、自分が何を欲しいのかを明確に把握しており、コードベースやモデルの挙動ともよく同期している。それでも彼らは未知のための余地をきちんと残す。自分の未知を減らし、あらかじめ整理しておくこと——それはある意味、Claude との協業における核心的な力量であり、この力量は Claude と一緒に鍛えることができる。

3細かすぎても雑すぎても失敗する

Claude に仕事を教える時、なぜ細かすぎても雑すぎても失敗するのか