Claude Fable 5 と仕事をするたびに、古い教訓を思い知らされます。地図は領土そのものではない、と。
行うべき作業を表現した「地図」とは、私のプロンプトやスキル、コンテキストであり、Claude に与えるものです。「領土」とは、作業が行われるべき場所、つまりコードベースや現実世界、その実際の制約のことです。
地図と領土の違い、それが私が「未知の要素」と呼んでいるものです。Claude が未知の要素に遭遇すると、私が何を望んでいるかを最善の推測に基づいて判断する必要があります。作業が増えれば増えるほど、Claude が遭遇する未知の要素も増える可能性があります。
Fable は、作業の質が、私がその未知の要素を明確に説明できるかどうかによって制限されると感じる初めてのモデルです。
重要なのは、事前に計画を立てるだけでは必ずしも十分ではないということです。実装の深部で未知の要素が見つかることもあれば、未知の要素が示すものは、そもそも別の方法で問題を解決すべきだという事実かもしれません。
Fable と仕事をするということは、実装の前、最中、そして後に、自分の未知の要素を発見するという反復プロセスだと気づきました。
未知の要素を見つけるためのサンプルアーティファクトはこちらに作成しましたが、必ず戻ってきて、いつそれらを使うべきかの直感を磨いてください。
自分自身の「未知の要素」を知る
あなたの未知の要素とは何でしょうか？ 私が Claude に問題を提示するときは、それを 4 つの方法で分解する傾向があります。
- 既知の既知: これは基本的にプロンプトに書かれていることです。エージェントに何をしてほしいと伝えているか？
- 既知の未知: まだ解決していないが、自分が理解していないことを認識していることは何か？
- 未知の既知: あまりにも明白すぎて書き留めることすらしないが、見ればすぐに認識できることは何か？
- 未知の未知: まったく考慮していないことは何か？ 知らない知識は何か？ 成果がどれほど優れたものになるかを理解しているか？
最も優秀なエージェンティックコーダーは、未知の要素が比較的少ないのが特徴です。Boris や Jarred といった人たちのプロンプトを見ると、彼らが自分が望むものを詳細に理解していることは明らかです。彼らはコードベースとモデルの振る舞いの両方に深く同期しています。
しかし、彼らも未知の要素を想定しています。多くの点で、未知の要素を減らし、それに備えることは、エージェンティックコーディングのスキルと言えます。幸いなことに、このスキルは Claude と仕事をすることで向上させることができます。
Claude があなたを助けられるようにする
Claude への指示は微妙なバランスを必要とします。指示を詳細にしすぎると、方向転換が適切な場合でも Claude はその指示に従ってしまいます。指示が曖昧すぎると、Claude はタスクに適さないかもしれない業界のベストプラクティスに基づいて選択や仮定をすることがよくあります。
未知の要素を考慮しないと、両方の方法で失敗します。道のりが障害でいっぱいになる時もわからなければ、道がクリアな時もわからない。それでも、Claude には進路を変えてほしいと思うのです。
Claude は、あなたが自分の未知の要素をより早く発見するのを助けてくれます。コードベースやインターネットを極めて迅速に検索でき、平均的なトピックについてあなたよりもはるかに多くの知識を持っています。また、失敗からより早く反復することもできます。
このプロセスで最も重要な部分は、Claude にあなたの出発点に関するコンテキストを与えることです。例えば、思考プロセスのどこにいるのかを伝え、問題やコードベースに対する経験を開示し、思考パートナーのように一緒に作業させましょう。
私は以前、HTML と Claude の併用について書きましたが、これらのケースのほぼすべてにおいて、HTML アーティファクトが未知の要素を可視化し表現する最良の方法です。
この記事では、これらの未知の要素を明らかにするために私が使っているいくつかのパターンを詳しく説明します。毎回すべてのテクニックを使うわけではありませんが、持っておくと便利なテクニック集です。
実装前
盲点チェック
作業を始める際に最も役立つことの 1 つは、自分の盲点を理解することです。例えば、コードベースの新しい部分で機能を書いている場合や、デザインの反復のような不慣れな作業で Claude の助けを借りている場合、多くの未知の未知がある可能性が高いです。
何を尋ねるべきか、良い状態がどのようなものか、これまでに行われた作業や避けるべき落とし穴がわからないかもしれません。
これを行うには、Claude にあなたの未知の未知を見つけて説明するよう依頼します。「盲点チェック」や「未知の未知」という言葉をそのまま使うのが好きです。自分が誰で、何を知っているかというコンテキストを Claude に与えることが、通常は重要です。
プロンプト例:
- 「新しい認証プロバイダーを追加しようとしていますが、このコードベースの認証モジュールについて何も知りません。盲点チェックを行って、関連する未知の未知を特定し、より良いプロンプトが作れるように手伝ってくれますか？」
- 「カラーグレーディングが何かは知りませんが、この動画をグレーディングする必要があります。カラーグレーディングに関する未知の未知を理解し、より良いプロンプトが作れるように教えてくれますか？」
ブレインストーミングとプロトタイプ
「未知の既知」が多く、見れば定義できる基準が関わる分野で作業する場合、Claude に一緒にブレインストーミングとプロトタイプ作成を依頼するのが好きです。
プロトタイピングの初期段階で未知の既知を特定し明確にすることは非常に価値があります。なぜなら、実装中にそれらを発見するのは（比較的）コストがかかるからです。機能や仕様の小さな変更は、コードの実装に劇的な違いをもたらす可能性があり、エージェントが以前の変更を元に戻すのはより困難になります。
例えば、バックエンドのルートを配線したり、フロントエンドで追加の状態を維持したりしなくても、フレームに追加されたボタンがどのように見えるかだけを見たい場合があります。
ビジュアルデザインは、私にとっては言葉にしにくいものですが、見ればそれが何かはわかります。そのような場合、私はアーティファクトに対していくつかのデザインアプローチを依頼します。
また、ほとんどのコーディングセッションは、探索またはブレインストーミングの段階から始めます。これにより、プロジェクトの範囲を定義する意図を持って開始できます。Claude は、私が見逃していたであろう価値の高いアプローチを見つけることがよくありますが、木を見て森を見ずになることもあります。ブレインストーミングは、範囲を狭く設定しすぎたり、広く設定しすぎたりするのを防いでくれます。
プロンプト例:
- 「このデータのダッシュボードが欲しいのですが、視覚的なセンスがなく、何が可能かもわかりません。4 つの根本的に異なるデザインの方向性を示す HTML ページを作成し、それに反応できるようにしてください。」
- 「何かを配線する前に、新しいエディターツールバーを模擬した、偽のデータを使った 1 つの HTML ファイルを作成してください。実際のアプリに触る前に、レイアウトに対して反応したいのです。」
- 「大まかな問題はこうです。ユーザーがオンボーディング後に離脱してしまいます。コードベースを検索し、最も安価なものから最も野心的なものまで、介入できる 10 の箇所をブレインストーミングしてください。どれが共感できるか教えます。」
インタビュー
十分なブレインストーミングを行った後でも、おそらくまだ未知の要素は残っています。
そのような場合、私は Claude に未知の要素や曖昧な点について私にインタビューするよう依頼します。Claude にインタビューを依頼するときは、その質問を導くために問題に関するコンテキストを伝えるようにしてください。以下にいくつかの例を示します。
プロンプト例:
- 「曖昧な点について、一度に 1 つの質問ずつインタビューしてください。私の答えがアーキテクチャを変えるような質問を優先してください。」
リファレンス
自分が欲しいものを詳細に説明できないこともあります。例えば、それに関する語彙がないか、非常に複雑で説明にかなりの時間がかかる場合です。
その場合、最善の答えはリファレンスです。図やドキュメント、画像を含めることもできますが、最も優れたリファレンスはソースコードです。
特定の方法で何かを実装しているライブラリや、非常に気に入ったデザインコンポーネントがある場合は、たとえそれが別の言語であっても、Fable をそのフォルダに向けて、何を探すべきかを指示するだけで十分です。
これは Claude Design が機能する方法でもあります。ファイルを渡す必要はありません（ただし、それも可能です）。好きなウェブサイトのモジュールを指定すると、スクリーンショットだけでなく、その基礎となるコードを読み取ります。これにより、マークアップ、構造、コンポーネントが実際にどのように構築されているかについて、はるかに豊富な詳細が提供されます。
プロンプト例:
- 「vendor/rate-limiter にあるこの Rust クレートは、私が望む正確なバックオフ動作を実装しています。それを読み、同じセマンティクスを我々の TypeScript API クライアントに再実装してください。」
実装計画
実装の準備ができたと思ったら、私は Claude に、変更される可能性が最も高い部分に焦点を当てた実装計画（例：データモデル、型インターフェース、UX フローのレビュー）をまとめてもらうように依頼する傾向があります。これにより、Claude は実際に変更する必要があるかもしれない点を浮き彫りにしてくれます。
プロンプト例:
- 「実装計画を HTML で書いてください。ただし、私が最も調整しそうな決定事項（データモデルの変更、新しい型インターフェース、ユーザーインターフェースに関わるもの）を先頭に配置してください。機械的なリファクタリングは最後に置いてください。その部分はあなたを信頼しています。」
実装中
実装ノート
計画に満足したら、新しいセッションを開始し、すべてのアーティファクトをプロンプトに渡します。例えば、仕様ファイルとプロトタイプを渡し、エージェントに実装を依頼するかもしれません。
しかし、どれだけ計画を立てても、常に未知の未知が潜んでいるのが実情です。エージェントは作業中に、コード内で見つけたエッジケースのために別の方法を取る必要があることに気づくかもしれません。
私は Claude Code に一時的な 'implementation-notes.md'（または .html）ファイルを保持するよう依頼し、そこで行った決定を記録して、次の試行で学べるようにしています。
プロンプト例:
- 「implementation-notes.md ファイルを保持してください。計画から逸脱せざるを得ないエッジケースに遭遇した場合は、保守的なオプションを選択し、それを「逸脱」として記録して、作業を続けてください。」
実装後
提案書と説明資料
何かをリリースする上で最も重要な部分の 1 つは、賛同と承認を得ることです。最終ドキュメントに提案書や説明資料のアーティファクトを作成することは、以下の点で役立ちます。
- レビュアーがあなたと同じ未知の要素からスタートする場合、理解を加速する
- エキスパートが、あなたが未知の要素や、彼らが予想していたであろう一般的な失敗点を考慮していることを確認したい場合、承認を加速する
プロンプト例:
- 「プロトタイプ、仕様、実装ノートを 1 つのドキュメントにまとめて、Slack に投稿して賛同を得られるようにしてください。デモ GIF を先頭に置いてください。」
クイズ
長時間の作業セッションの後、Claude は私が認識しているよりもはるかに多くのことを成し遂げているかもしれません。コードの差分を読んでも、動作の多くは既存のコードパスに依存するため、何が起こったのかを表面的にしか理解できません。
Claude に、多くのコンテキストを与えた上で変更についてクイズを出すよう依頼すると、何が起こったのかを理解するのに役立ちます。私はクイズに完璧に合格した後にのみ、マージを行います。
プロンプト例:
- 「この変更で起こったことをすべて理解していることを確認したいです。コンテキスト、直感、行われた作業などを含む、変更内容について理解するための HTML レポートと、それに合格しなければならない変更に関するクイズを下部に作成してください。」
これらがどのように統合されるか：Fable のローンチ
Fable のローンチ動画は、Claude Code によって完全に編集されました。これは私にとって新しい領域であり、決して専門家ではありません。
そこで、私は自分が知っていることから始めました。Claude がコードを使って動画を編集し、文字起こしができることは知っていましたが、それが十分に正確かどうかは確信が持てませんでした。そこで、Claude に Whisper のような文字起こしがどのように機能するのか、そして ffmpeg を使って「えーと」や長い間を正確にカットできるかどうかを説明してもらいました。
Claude に、自分の発言に合わせたタイミングの UI を作成してもらいたいと考えましたが、それが可能かどうか確信が持てなかったため、Remotion と文字起こしを使ってプロトタイプ動画を作成し、それが機能するかどうかを確認するよう Claude に依頼しました。
最後に、動画自体の色味が少しくすんで見えたため、カラーグレーディングの結果だとわかりましたが、カラーグレーディングが何なのかは実際にはよく知りませんでした。最初の試みは、Claude にいくつかのバリエーションを作成させて選ぼうとすることでしたが、カラーグレーディングに関して「良い」状態がどのようなものか、自分が知らないことに気づきました。そこで代わりに、Claude にカラーグレーディングについて教えてもらい、自分の未知の要素を発見することにしました。
より詳細な説明はこちらでご覧いただけます。
地図と領土の一致
モデルが優れれば優れるほど、適切なアプローチで達成できることが増えます。長期にわたるタスクが期待通りに戻ってこない場合、おそらく未知の要素を定義するため、または Claude がそれらを通過して即興で対応できる実装計画を作成するためにより多くの時間を費やす必要があります。
説明資料、ブレインストーミング、インタビュー、プロトタイプ、リファレンスはすべて、修正にコストがかかる前に、自分が知らなかったことを見つけるための安価な方法です。
次のプロジェクトを始める際は、Claude にあなたの未知の要素を見つけるのを手伝ってもらうことから始めましょう。
