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

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

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

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

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

Claude にタスクを指示するのは綱渡りのようなものだ。細かく指示しすぎると、途中で方向転換すべき場面でも、書いた手順どおりにしか動けなくなる。雑に指示しすぎると、業界一般のベストプラクティスに沿って推測するしかなく、必ずしもあなたの状況に合うとは限らない。自分の未知をきちんと把握していないと、どちらの側でもつまずく——どこに落とし穴があるのか、どこが実は問題ないのかがわからないまま、それでも必要な時には方向転換してほしいと望んでしまう。

幸い、Claude はあなたが未知をより早く発見する手助けをしてくれる——コードベースを読み込んだりネットを調べたりするのは非常に速く、たいていの話題について知識もあなたより豊富で、失敗から素早くイテレーションできる。このプロセスで最も重要な一歩は、自分の出発点を Claude に伝えることだ——自分の思考がどこまで進んでいるか、この問題やコードベースについての経験の深さを伝え、思考のパートナーとして一緒に取り組んでもらう。著者はまた、ほぼすべてのこうした場面において、HTML ページはアイデアを可視化して目の前に示す最良の方法だとも述べている。

以下の技法は「実装前・実装中・実装後」の三段階に沿って並べられている。著者は毎回すべてを使うわけではないと言うが、これは手元に備えておく価値のあるツールボックスだ。

原文の図版：Claude を導くのは微妙なバランス感覚であり、具体的すぎても曖昧すぎても失敗する。出典：X・Thariq

まず Claude に「自分でも気づいていない未知」を見つけてもらう

着手する際に最も役立つのは、まず自分の盲点をはっきりさせることだ。コードベースの馴染みのない部分に機能を書こうとしていたり、デザインの反復のような不慣れな仕事をしていたりする場合、あなたにはおそらく大量の未知の未知がある——何を尋ねればいいのかわからない、「良い」がどういう見た目かわからない、以前誰かが何をやったのかわからない、どんな落とし穴を避けるべきかもわからない。

I'm working on adding a new auth provider but I know nothing about the auth modules in this codebase. Can you do a blindspot pass to help me figure out my relevant unknown unknowns and help me prompt you better.

I don't know what color grading is but I need to grade this video. Can you teach me to understand my unknown unknowns about color grading, so that I can prompt better?

原文の図版：著者がまとめた未知を発見するための技法集。出典：X・Thariq

言葉では説明できなくても、見ればすぐわかることがある

この種の未知は、基準を言葉で説明できないが、目の前に出されればすぐに良し悪しがわかる——これが「未知の既知」だ。これらは早い段階でブレインストーミングとプロトタイプを使って掘り出すのが最善である。コードを書く段階になって初めて気づくと、コストはずっと大きくなる。仕様のわずかな変更が実装全体をひっくり返すことになりかねないし、Claude に以前の変更を巻き戻させるのもより難しくなる。著者はほぼ毎回、探索やブレインストーミングの段階から始め、それを使ってプロジェクトの範囲を定める——狭すぎず広すぎず。

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

例えば、あるインターフェースにボタンを追加したらどう見えるかを確認したいだけで、実際にバックエンドのルーティングを接続したり、フロントエンドに状態をもう一つ余分に管理させたりしたいわけではない場合がある。ビジュアルデザインは著者にとって特に言葉で説明しづらいものだが、目の前に出されればどれが欲しいかすぐにわかる。こういう時、彼は一度に複数のデザイン方向性を出させて反応を比較する。

I want a dashboard for this data but I have no visual taste and don't know what's possible. Make me an HTML page with 4 wildly different design directions so I can react to them.

Before wiring anything up, make a single HTML file mocking the new editor toolbar with fake data. I want to react to the layout before you touch the real app.

Here's my rough problem: users churn after onboarding. Search the codebase and brainstorm 10 places we could intervene, from cheapest to most ambitious. I'll tell you which ones resonate.

Claude に逆にインタビューしてもらう

ブレインストーミングの後にも、曖昧な点がいくつか残っていることが多い。この時は Claude に逆に一つずつ質問させ、この問題についての背景情報を少し与えて質問を導かせる。重要なのは、「答えがアーキテクチャを変えるような」質問を優先させることだ。

Interview me one question at a time about anything ambiguous, prioritize questions where my answer would change the architecture.

どう言えばいいかわからないものは、コードをそのまま見せればいい

時には、欲しいものを表現する言葉がまったく見つからなかったり、説明するには複雑すぎたりすることがある。こういう時、最良の参考資料はソースコードそのものだ。図、ドキュメント、スクリーンショットも渡せるが、間違いなく最良の参考は元のコードである。あなたの望む挙動をどこかのライブラリがすでに実装しているなら、あるいは気に入っているデザインコンポーネントがあるなら、そのフォルダを直接 Fable に指し示し、何を見ればいいか伝えればいい。たとえコードが別の言語であっても構わない。

Claude Design もこのように働く。ファイルを一つ渡す必要はない（もちろん渡してもいい）。ある Web ページ上であなたが気に入っているモジュールを指し示すだけでいい。Claude はスクリーンショットだけでなく、その裏側のコードを読む。そうすることで、マークアップ・構造・コンポーネントが実際にどう組み立てられているかについて、はるかに豊富な詳細を得られる。

This Rust crate in vendor/rate-limiter implements the exact backoff behavior I want. Read it and reimplement the same semantics in our TypeScript API client.

実装計画：最も変わりやすいものを先頭に置く

着手する準備が整うと、著者はまず Claude に実装計画を出させて目を通す。重点は最も変更されやすい部分に置く——データモデル、型インターフェース、ユーザーに見える部分だ。機械的なリファクタリングは最後に回し、その部分は任せてしまえばいい。こうすることで、あなたが本当に調整する必要がある部分を先に目の前に出してくれる。

Write an implementation plan in HTML, but lead with the decisions I'm most likely to tweak with: data model changes, new type interfaces, and anything user-facing. Bury the mechanical refactoring at the bottom, I trust you on that part.

着手した後は、Claude に作業しながら「その場の判断」を記録させる

どれほど計画を練り込んでも、実装の過程では予想外の未知が必ず出てくる。著者は計画に満足すると、新しいセッションを開始し、仕様書やプロトタイプなどの成果物をプロンプトに投げ込んで、agent に実装させる。しかし Claude が作業を進めるうちに、コード内のあるエッジケースのせいでやり方を変える必要が出てくることがある。著者は Claude Code に一時的な implementation-notes.md（あるいは .html）ファイルを維持させ、下した判断を記録させておく。そうすれば次回の試行で振り返って学べる。

Keep an implementation-notes.md file. If you hit an edge case that forces you to deviate from the plan, pick the conservative option, log it under 'Deviations', and keep going.

完成したら、マージする前にまず Claude にテストされる

作業が終わったら、締めくくりに二つの技法がある。一つは成果を承認を得るためのドキュメントにパッケージングすること、そしてもう一つが最も肝心な——Claude に逆にあなたをテストさせることだ。

説得資料へのパッケージング

何かを納品する際、重要な一歩は承認と了承を得ることだ。最終ドキュメントに「説得」と「解説」の要素を盛り込むことには、二つの利点がある。レビューする人はあなたが当初持っていたのと同じ未知を抱えたまま読み始めるので、より早く理解できる。また、詳しい専門家はあなたがそれらの落とし穴やよくある失敗ポイントを考慮したかを確認したがるものだが、それもより早くうなずいてもらえる。

原文の図版：プロトタイプ・仕様書・実装ノートを一つの承認申請用ドキュメントにパッケージングする。出典：X・Thariq

Package the prototype, the spec, and the implementation notes into a single doc I can drop in Slack to get buy-in. Lead with the demo GIF.

小テスト：合格しなければマージしない

I want to make sure I understand everything that's happened in this change. Give me a HTML report on the changes for me to read and understand with context, intuition, what was done, etc. and a quiz at the bottom on the changes that I must pass.

Fable のリリース動画を編集する時、彼はこの方法論をどう使ったか

Fable のリリース動画は完全に Claude Code によって編集された。これは著者にとってまったく新しい領域であり、彼自身も素人だと認めている。このプロセス全体が、まさに前述の技法を一通りつなげたものになった——自分がすでに知っていることから出発し、一歩ずつ未知を一つずつあぶり出していったのだ。

著者の締めくくりの提案はこうだ——モデルが強力になるほど、正しい方法を使えばやれることも増える。長時間かかったタスクが間違った結果で返ってきたら、それはたいてい、自分の未知を定義するのにもっと時間をかける必要があること、あるいは Claude がそれらの未知の中で自由に判断できるような実装計画を書く必要があることを示している。解説、ブレインストーミング、インタビュー、プロトタイプ、参考資料——そのすべてが、コストの安い段階であなたの知らないことを先に見つけ出し、コストの高い段階になってから穴埋めせずに済むようにするためのものだ。だから、次のプロジェクトは、Claude に未知を見つけてもらうその一言から始めればいい。

この方法論の第一歩は要求を急いで書くことではなく、まず「わからないこと」を四種類に分けることだ。指示が細かすぎれば方向転換できず、雑すぎればあてずっぽうになる。まず自分がどの枠で詰まっているかを見極めよう。大きな仕事ほど、後の二つの——あなたがまったく気づいていない——盲点に陥りやすい。

• 既知の既知：プロンプトに書き込み、何が欲しいかを明言したもの（ボタンを右上に置く）。
• 既知の未知：まだ考え抜けていないと自覚しているもの（リストにページネーションを付けるかまだ決めていない）。
• 未知の既知：決して書き留めることはないが、見れば良し悪しがわかるもの（配色が刺激的すぎて一目で却下）。
• 未知の未知：そもそも考えたこともなく、「どこまでうまくできるか」すらわからないもの（動画のポーズをコードで自動カットできるとは知らなかった）。

未知を見つけることは着手前に一度やるものではなく、着手前・中・後を貫くものだ。著者は8つの技法をこの三段階に分けて示しており、それぞれがコストの安いうちに盲点を先に掘り出すためのものだ。これらの技法には、本文でそのままコピーして使える英語のプロンプトが添えられている。

著者が繰り返し強調するのは：ブレインストーミング・インタビュー・プロトタイプ・参考資料はどれも、コストの安いうちにあなたの知らないことを掘り出し、コストの高い段階まで持ち越して手戻りするのを避けるためのものだ。