Claude Fable のフィールドガイド：未知の領域を見つける方法

## 未知のものを把握する あなたの「未知のもの」とは何ですか？私が Claude に問題を持ち込むとき、私はそれを 4 つの観点に分解して考えます： - 既知の既知（Known Knowns）：これは本質的にプロンプトに含まれる内容です。エージェントに対して何を伝えたいのか。 - 既知の未知（Known Unknowns）：まだ解明していないが、自分がそれを知らないことを自覚していること。 - 未知の既知（Unknown Knowns）：あまりにも明白すぎて書き留める必要はないが、もし目にしたなら認識できること。 - 未知の未知（Unknown Unknowns）：全く考慮したことがないもの。どのような知識を欠いているのか？あるものがどれほど優れたものになり得るかを知っているか。 最も優秀なエージェント型コーディングを行う人々は、比較的少ない「未知のもの」しか持っていません。[Boris](https://www.linkedin.com/in/bcherny) や [Jarred](https://www.linkedin.com/in/jarred-sumner-a8772425) といった人物がプロンプトを打つ様子を見ていると、彼らが何を詳細に求めているかを明確に理解していることがわかります。彼らはコードベースとモデルの挙動の両方に深く精通しています。 ![image](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a4be4919e159adcdfa3ec52_cc0ee2de.png) しかし、彼らはまた「未知のもの」を前提としています。多くの点で、未知のものを減らし、それを見越して計画することが、**エージェント型コーディングにおけるスキル**です。ただし幸いなことに、これは Claude と共に作業することで向上できるスキルです。 ## Claude に協力してもらう ![image](https://cdn.prod.website-files.com/68a44d4040f98a4adf2207b6/6a4be4919e159adcdfa3ec55_c4646783.png) Claude への指示出しは、微妙なバランスの上に成り立っています。指示が細かすぎると、状況によっては方針転換の方が適切である場合でも、Claude は指示に従ってしまいます。逆に指示が曖昧すぎると、Claude は業界のベストプラクティスに基づいて判断や仮定を行いますが、それがあなたのタスクに適合しないこともあります。 未知の要素を考慮しない場合、どちらの方向にも失敗することになります。道に障害が待ち受けている時と、道がクリアな時に Claude が迂回すべきかどうかを、あなたは知り得ないのです。 Claude は、あなたが抱える未知の要素をより早く発見する手助けをしてくれます。コードベースやインターネットを極めて高速で検索でき、平均的なトピックについてはあなたよりも多くの知識を持っています。また、失敗からの反復も迅速に行えます。 このプロセスで最も重要なのは、スタート地点に関する文脈を Claude に与えることです。例えば、思考のどの段階にいるかを伝え、問題やコードベースに対する自身の経験を開示し、思考のパートナーとして共に作業できるようにします。 本記事では、これらの未知の要素を発見するために私が用いるいくつかのパターンについて詳述します： **実装前：** - ブラインドスポットの確認 - 脳内会議とプロトタイプ作成 - インタビュー - リファレンス（参考資料） - 実装計画 **実装中：** - 実装ノート **実装後：** - プレゼンテーションと解説資料 - クイズ ## Blind Spot Pass 作業を開始する際、最も有用なことのひとつは自分の盲点を理解することです。例えば、コードベースの新しい部分に機能を実装している場合や、デザインの反復など見慣れない作業を Claude に手伝ってもらう場合は、**未知の未知（unknown unknowns）**が非常に多く存在する可能性が高いです。 何を質問すべきか、何が良質なのか、過去のどのような作業が行われたのか、あるいは避けるべき落とし穴は何かといったことがわからないかもしれません。 このような状況では、Claude に自分の「未知の未知」を見つけ出し、それらを説明してもらうよう依頼できます。私は「盲点パス（blind spot pass）」や「未知の未知」という言葉をそのまま使うことを好みます。自分自身が誰で、何を既知としているかという文脈を与えることは、Claude があなたと協力する最善の方法を理解するために通常重要です。 **例となるプロンプト**: - 「新しい認証プロバイダーを追加しようとしていますが、このコードベース内の認証モジュールについては何も知りません。私の関連する未知の未知を特定し、より良いプロンプトを作成できるよう支援するための盲点パスを行っていただけますか。」 - 「カラーグレーディングが何かもわかりませんが、このビデオにカラーグレーディングを施す必要があります。カラーグレーディングに関する自分の未知の未知を理解できるように教えていただき、より良いプロンプトを作成できるようにしてください。」 ## Brainstorms and prototypes 私が**既知の未知（unknown knowns）**が多く、基準は目にしたときにしか定義できないような分野で作業している場合、Claude に私と一緒にブレインストーミングやプロトタイピングを依頼することがあります。 プロトタイピングの初期段階で既知の未知（unknown knowns）を特定し、言語化しておくことは極めて価値があります。なぜなら、実装段階になってからそれらを見つけるのは（相対的に）高コストになる可能性があるからです。機能や仕様における小さな変更が、コード上では劇的に異なる実装を引き起こすことがあり、その場合、エージェントが以前の修正を元に戻すのがより困難になることがあります。 例えば、バックエンドのルートを設定したり、フロントエンドで追加の状態管理を行ったりすることなく、フレームに追加されたボタンがどのように見えるかを確認したいだけの場合があります。 もう一つの例として、視覚デザインが挙げられます。私にとってこれは言語化するのが難しいものですが、目にした瞬間に自分が何を求めているかはわかります。このようなケースでは、アーティファクトに対して複数のデザインアプローチを求めます。 また、コーディングセッションのほとんどは、探索やブレインストーミングのフェーズから始めます。これにより、プロジェクトのスコープを定義する意図を持ってスタートできます。Claude は私が見過ごしていた高価値なアプローチを見つけ出すことが多く、時には木を見て森を見ないという状況に陥ることもあります。ブレインストーミングを行うことで、スコープが狭すぎたり広すぎたりすることを防いでいます。 **例となるプロンプト:** - 「このデータのダッシュボードを作りたいのですが、私はビジュアルセンスがなく、何が可能か分かりません。4 つの全く異なるデザイン方向性の HTML ページを作成して、私が反応できるようにしてください。」 - 「何かを接続する前に、新しいエディタツールバーをフェイクデータで模倣した単一の HTML ファイルを作ってください。実際のアプリに触れる前にレイアウトに反応したいのです。」 - 「私の大まかな問題はこうです：ユーザーはオンボーディング後に離脱します。コードベースを検索し、最も安価なものから最も野心的なものまで、介入できる 10 の場所をブレインストーミングしてください。私が共感するものを伝えます。」 ## インタビュー 十分なブレインストーミングを行った後でも、まだ不明な点が残っていることが多いです。 そのような場合は、Claude に不明点や曖昧な点についてインタビューしてもらうようにします。Claude にインタビューさせる際は、質問の方向性を示すために問題に関する文脈を伝えるよう心がけてください。 **プロンプト例:** - 「曖昧な点について一度に 1 つずつ質問してください。私の回答によってアーキテクチャが変わる可能性が高い質問を優先してください。」 ## レファレンス 時には、何を求めているかを詳細に説明できないこともあります。例えば、適切な言葉が見つからない場合や、説明が複雑すぎて時間がかかりすぎる場合があります。 そのような場合、最良のアプローチはレファレンス（参考資料）を使うことです。図解、ドキュメント、画像を含めることもできますが、最も優れたレファレンスは*ソースコード*です。 特定の方式で実装されたライブラリや、本当に気に入ったデザインコンポーネントがある場合は、Fable をそのフォルダに指し示して、何を探すべきかを伝えるだけで構いません。たとえそれが異なる言語で記述されていても問題ありません。これにより、例えばスクリーンショットと比較した場合、マークアップや構造に関する詳細が Claude にとってはるかに豊かになります。 **例のプロンプト:** - "vendor/rate-limiter のこの Rust クレートは、私が望むバックオフ動作を正確に実装しています。これを読み込み、同じセマンティクスを私たちの TypeScript API クライアントで再実装してください。" ## 実装計画 実装の準備ができたと感じたとき、私は通常 Claude にレビュー用の実装計画を作成するよう依頼します。この計画は、データモデル、型インターフェース、または UX フローなど、変更される可能性が最も高い部分に焦点を当てています。これにより、実際に修正が必要となる事項を Claude が浮き彫りにしてくれます。 **例のプロンプト:** - "HTML で実装計画を作成してください。ただし、データモデルの変更、新しい型インターフェース、ユーザー向け機能など、私が最も調整する可能性が高い決定事項から始めてください。機械的なリファクタリングは最後に記述し、その部分はあなたに任せます。" ## 実装中 ## 実装ノート 計画に満足したら、私は新しいセッションを開始し、作成したアーティファクトをプロンプトに渡します。これにより、Claude は計画段階で収集したすべての情報を保持しつつ、新鮮なコンテキストウィンドウを得ることができます。例えば、仕様書とプロトタイプを渡してエージェントに実装させるようなケースです。 しかし真実は、どれだけ綿密に計画を立てても、常に未知の未知（unknown unknowns）が潜んでいるということです。エージェントは作業中に、コード内で発見したエッジケースのために別のアプローチを取る必要があることに気づくかもしれません。 私は Claude Code に、一時的な「implementation-notes.md」（または .html）ファイルを作成させ、そこで意思決定を追跡させるようにしています。これにより、次の試行で学べるようになります。 **例のプロンプト:** - 「implementation-notes.md ファイルを維持してください。エッジケースに遭遇して計画から逸脱せざるを得なくなった場合は、保守的な選択肢を選び、『Deviations（逸脱）』の下に記録し、作業を継続してください。」 ## 実装後 ## ピッチと説明資料 何かをリリースする際、最も重要な部分の一つは関係者の合意形成と承認を得ることです。最終ドキュメントにピッチや説明資料のアーティファクトを組み込むことで、以下の効果が得られます: - レビュー担当者があなたと同じ未知の点から始めるとき、理解を加速させる - 専門家があなたが未知の点や、彼らが予期したであろう一般的な失敗点を考慮していることを確認したいときに、承認プロセスを加速させる **例のプロンプト:** - 「プロトタイプ、仕様書、実装メモを一つのドキュメントにパッケージ化し、Slack に貼り付けて合意形成を得られるようにしてください。デモ GIF を先頭に配置してください。」 ## クイズ 長時間の作業セッションの後、Claude は私が認識していた以上に多くのことを達成している可能性があります。コードの差分（diff）を読むだけでは、既存のコードパスに依存する動作が多いため、何が起きたのかを軽く理解する程度しかできません。 変更点について文脈を提示した後に、Claude にクイズを出してもらうことで、何が起きたのかを理解するのに役立ちます。私は完璧にクイズをクリアした後でしかマージしません。 **プロンプトの例:** - 「この変更で何が起こったのかをすべて理解しているか確認したいです。文脈、直感、何が行われたかなどを含め、読んで理解できるための HTML レポートと、私が合格しなければならない変更点に関するクイズを最後に作成してください。」 ## これがどう組み合わさって Fable のローンチにつながるか: Fable の[ローンチ動画](https://x.com/ClaudeDevs/status/2064399512664526853)は、Claude Code を用いて最初から最後まで編集されました。これは私にとって新しい分野であり、私は決して専門家ではありません。 そこで、私が知っていることから始めました。Claude がコードを使って動画を編集したり、文字起こしを行ったりできることは知っていましたが、それが十分な精度を持っているかどうかは確信が持てませんでした。そこで、Whisper などの文字起こしがどのように機能するのかを Claude に説明してもらい、ffmpeg を使って「um」や大きな一時停止などを正確にカットできるかどうかを尋ねました。 私は私が話している言葉とタイミングを合わせた UI を作成したいと考えていましたが、それが可能かどうか確信が持てなかったため、Remotion と文字起こしデータを使用してプロトタイプの動画を作成し、実際に機能するかを試すよう Claude に依頼しました。 最後に、動画自体が少し抑えめに見えたのですが、これはカラーグレーディングの結果だと知っていましたが、カラーグレーディングとは何かは本当に知りませんでした。最初の試みとして、Claude にいくつかのバリエーションを作成させて選んでもらおうとしましたが、カラーグレーディングにおいて「良い」状態がどう見えるのかを自分が知らないことに気づきました。そこで代わりに、私の未知の領域を見つけるために Claude にカラーグレーディングについて教えてもらうよう依頼しました。 ## マップとテリトリーの整合性 より優れたモデルほど、適切なアプローチを用いれば達成できることが増えます。長期にわたるタスクが誤って返ってきた場合、おそらく未知の領域を定義する時間をより多く取るか、あなたと Claude がそれらを通じて適応できるようにする実装計画を作成する必要があります。 すべての解説、ブレインストーミング、インタビュー、プロトタイプ、参照資料は、修正が高価になる前に自分が知らなかったことを発見するための安価な手段です。 したがって、次のプロジェクトでは、Claude に未知の領域を見つけるのを手伝ってもらうことから始めてください。 *この記事は、Anthropic の技術スタッフである Thariq Shihipar によって書かれました。*

Claude Fable のフィールドガイド：未知の領域を見つける方法

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト