The Map Is Not the Territory
Claude Fable 5 と働くたびに、古い教訓を学び直している——地図は領土ではない。仕事の質を決めるのは、自分の「未知」をどれだけ明確にできるかだ。未知を見つけるための 8 つのテクニックを紹介する。
01 — 地図と領土
地図とは、これからやる仕事の表現——プロンプト、スキル、コンテキストなど、あなたが Claude に渡すもの。領土とは、実際に仕事が行われる場所——コードベース、現実の世界、そこにある本当の制約だ。
Claude が未知にぶつかると、「あなたが何を望んでいるか」の推測にもとづいて判断するしかない。任せる仕事が大きくなるほど、Claude がぶつかる未知も増えていく。
Fable は、仕事の質が「自分の未知をどれだけ明確にできるか」で頭打ちになる、初めてのモデルだ。
重要なのは、事前に計画するだけでは足りないということ。実装の奥深くで未知が見つかることもあれば、見つけた未知が「そもそも別の解き方をすべきだ」と教えてくれることもある。だから Fable との仕事は、実装の前・最中・後を通じて自分の未知を発見していく反復プロセスになる。
02 — 未知を知る
問題を Claude に持ち込むとき、原文の筆者は次の 4 つに分解して考えるという。
プロンプトに書いてあること。エージェントに「これが欲しい」と伝えた内容そのもの。
まだ決めていないが、決めていないことを自覚していること。
当たり前すぎてわざわざ書かないが、見せられれば「これだ」と分かること。
そもそも考えたことがないこと。自分が知らないと気づいていない知識。「どこまで良くできるか」を知らないこと。
優れたエージェンティック・コーダーは、未知が相対的に少ない。Boris や Jarred のような人のプロンプトを見ていると、欲しいものを細部まで分かっているのが伝わってくる。コードベースともモデルの挙動とも深く同期しているのだ。
それでも彼らは「未知はある」という前提で動く。未知を減らし、未知に備えることこそが、エージェンティック・コーディングというスキルだ。そして幸い、これは Claude と一緒に働くことで鍛えられる。
03 — 指示のバランス
Claude への指示は繊細なバランスの上に成り立っている。
未知を考慮しないと、この両側で同時に失敗する。道に障害物があるかどうかも、道が開けているのに曲がってほしい場面も、事前には分からないからだ。
一方で、Claude は未知の発見を速くしてくれる。コードベースもインターネットも猛スピードで調べられるし、たいていの話題についてはあなたより物知りで、失敗からの立て直しも速い。
このプロセスで最も大事なのは、自分の出発点についてコンテキストを渡すこと。いま思考のどの段階にいるのか、その問題やコードベースにどれくらい馴染みがあるのかを開示し、思考のパートナーとして一緒に働いてもらう。こうした可視化には、ほとんどの場合 HTML アーティファクトが最適だ。
ここからは、原文の筆者が未知をあぶり出すために使っているパターン集。毎回すべてを使うわけではなく、「持っておくと便利な道具箱」として紹介されている。
04 — 8つのテクニック
作業を始めるとき、まず自分の盲点を把握する。コードベースの新しい領域で機能を書くときや、デザイン修正のような不慣れな仕事では、未知の未知が大量にあるはずだ。何を質問すべきか、何が「良い」のか、過去にどんな経緯があったか、どんな落とし穴があるか——それすら分からない。
そこで Claude に「未知の未知を見つけて説明して」と頼む。“blindspot pass” や “unknown unknowns” という言葉をそのまま使うのがコツ。自分が誰で、何を知っているかのコンテキストも添える。
プロンプト例
未知の既知(見れば分かるのに言葉にできていない基準)が多い領域では、Claude と一緒にブレストと試作をする。未知の既知は、実装中に発覚すると(相対的に)高くつく。仕様の小さな変更がコードでは大改修になり、エージェントが以前の変更を巻き戻すのは難しくなるからだ。早い段階で言語化しておく価値は大きい。
たとえば、バックエンドの配線や状態管理を作り込む前に「フレームにボタンを足したらどう見えるか」だけを確かめたい、というように。ビジュアルデザインは特に「言葉にしづらいが、見れば分かる」の典型で、そういうときは 1 つのアーティファクトに複数のデザイン案を出してもらう。
筆者はほぼ毎回のコーディングセッションを探索・ブレストから始めるという。Claude は自分では思いつかない高価値なアプローチを見つけてくれることが多く(逆に木を見て森を見ずになることもある)、ブレストのおかげでスコープを狭すぎず・広すぎず設定できる。
プロンプト例
十分ブレストしても、未知は残る。そこで今度は、曖昧な点について Claude に自分をインタビューしてもらう。質問の的を絞れるよう、問題のコンテキストを渡しておくとよい。
プロンプト例
欲しいものを言葉で細かく説明できないこともある。語彙がなかったり、説明にとても時間がかかったり。そういうときの最善手はリファレンス(参照物)を渡すこと。図や資料や画像でもいいが、最強のリファレンスはソースコードだ。
望む挙動を実装しているライブラリや、気に入っているデザインコンポーネントがあるなら、そのフォルダを Fable に指して「これを見て」と言えばいい。別の言語で書かれていても構わない。Claude Design も同じ仕組みで動いている——好きなウェブサイトのモジュールを指せば、スクリーンショットではなくその下にあるコードを読む。マークアップや構造、実際の組み立て方まで、ずっと豊かな情報が手に入る。
プロンプト例
実装の準備ができたと思ったら、レビュー用の実装計画を作ってもらう。ポイントは、変わる可能性が高い部分——データモデル、型インターフェース、UX フロー——を先頭に置いてもらうこと。自分が実際に手を入れるべき箇所を Claude が浮かび上がらせてくれる。
プロンプト例
計画に満足したら、新しいセッションを立ち上げ、スペックやプロトタイプなどのアーティファクトをプロンプトに渡して実装してもらう。しかし、どれだけ計画しても未知の未知は必ず潜んでいる。エージェントは作業中に、コードで見つけたエッジケースのせいで別の進路を取る必要に迫られるかもしれない。
そこで Claude Code に、一時的な implementation-notes.md(.html でも)を持たせ、下した判断を記録してもらう。次の挑戦への学びになる。
プロンプト例
何かを世に出すうえで最も重要な工程のひとつが、周囲の理解と承認を得ること。ピッチ資料・説明資料を成果物に添えると、(1) あなたと同じ未知からスタートするレビュアーの理解が速くなり、(2)「想定すべき未知や典型的な失敗点をちゃんと考慮したか」を見たい専門家の承認も速くなる。
プロンプト例
長い作業セッションの後、Claude は自分が思っていた以上のことを成し遂げているかもしれない。コードの差分を読むだけでは浅い理解しか得られない——挙動の多くは既存のコードパスに依存しているからだ。
そこで、コンテキストをたっぷり与えたうえで変更内容について自分にクイズを出してもらう。筆者は、クイズに満点で合格するまでマージしないという。
プロンプト例
05 — ケーススタディ
Fable のローンチ動画は、すべて Claude Code で編集された。筆者にとって動画編集は新しいドメインで、専門家でもなんでもない。それでも上のテクニックを組み合わせて完成させた。
Claude がコードで動画編集と文字起こしをできることは知っていた。しかし精度は未知数。そこでまず、Whisper のような文字起こしがどう動くのか、「um」や長い間(ま)を ffmpeg で正確にカットできるのかを Claude に説明してもらった。
話している言葉にタイミングを合わせた UI を作りたかったが、可能かどうか確信がない。Remotion と文字起こしを使ったプロトタイプ動画を作ってもらい、成立するかを先に確認した。
映像が少しくすんで見えた。原因がカラーグレーディングにあることは知っていたが、それが何かはよく知らない。最初はバリエーションを何案か作らせて選ぼうとしたが、「そもそも自分は何が良いのか分かっていない」と気づいた。そこで方針を変え、Claude にカラーグレーディングを教えてもらって自分の未知を発見することから始めた。
06 — まとめ
モデルが良くなるほど、正しいアプローチさえあれば達成できることは増えていく。長時間のタスクが間違った結果で返ってきたなら、それはおそらく未知の定義にもっと時間をかけるべきサイン——あるいは、Claude が未知に出会っても即興で乗り切れるような実装計画が必要だったというサインだ。
説明資料も、ブレストも、インタビューも、プロトタイプも、リファレンスも——どれも「知らなかったこと」を、修正が高くつく前に安く知るための方法だ。
次のプロジェクトは、Claude に「私の未知を見つける手伝いをして」と頼むところから始めよう。