実装前PRE / 5 TECHNIQUES
1
ブラインドスポット・パスBLIND SPOT PASS
作業を始めるとき、まず自分の盲点を把握する。コードベースの新しい領域で機能を書くときや、デザインを反復して詰めていくような不慣れな作業を Claude に手伝ってもらうときは、未知の未知が大量にあるはずだ。何を質問すべきか、何が「良い」のか、過去にどんな経緯があったか、どんな落とし穴を避けるべきか——それすら分からない。
そこで Claude に「未知の未知を見つけて説明して」と頼む。“blindspot pass” や “unknown unknowns” という言葉をそのまま使うのがコツ。自分が誰で、何を知っているかのコンテキストも添える。
プロンプト例
新しい認証プロバイダを追加したいけど、このコードベースの認証まわりを何も知らない。ブラインドスポット・パスをして、関係する「未知の未知」を洗い出して、もっと上手くプロンプトできるように手伝って。
カラーグレーディングが何か知らないまま、この動画をグレーディングしないといけない。もっと良いプロンプトが書けるように、カラーグレーディングについての「未知の未知」を理解させて。
2
ブレストとプロトタイプBRAINSTORMS & PROTOTYPES
未知の既知(見れば分かるのに言葉にできていない基準)が多い領域では、Claude と一緒にブレストと試作をする。未知の既知は、実装中に発覚すると(相対的に)高くつく。仕様の小さな変更がコードでは大改修になり、エージェントが以前の変更を巻き戻すのは難しくなるからだ。早い段階で言語化しておく価値は大きい。
たとえば、バックエンドの配線や状態管理を作り込む前に「フレームにボタンを足したらどう見えるか」だけを確かめたい、というように。ビジュアルデザインは特に「言葉にしづらいが、見れば分かる」の典型で、そういうときは 1 つのアーティファクトに複数のデザイン案を出してもらう。
筆者はほぼ毎回のコーディングセッションを探索・ブレストのフェーズから始めるという。こうすると、プロジェクトのスコープを意図を持って決めた状態でスタートできる。Claude は自分では思いつかなかった高価値なアプローチを見つけてくれることが多く(逆に木を見て森を見ずになることもある)、ブレストのおかげでスコープを狭すぎず・広すぎず設定できる。
プロンプト例
このデータのダッシュボードが欲しいけど、視覚的センスに自信がなくて何が可能かも分からない。まったく方向性の違う 4 つのデザイン案を 1 つの HTML ページにして。それを見て反応するから。
配線は何もしなくていいから、新しいエディタのツールバーをダミーデータでモックした HTML ファイルを 1 枚作って。実アプリに触る前に、レイアウトに反応したい。
ざっくりした課題:オンボーディング後にユーザーが離脱している。コードベースを調べて、介入できそうな場所を、手軽なものから野心的なものまで 10 個ブレストして。響いたものを伝えるから。
3
インタビューINTERVIEWS
十分ブレストしても、未知は残る。そこで今度は、曖昧な点について Claude に自分をインタビューしてもらう。質問の的を絞れるよう、問題のコンテキストを渡しておくとよい。
プロンプト例
曖昧な点について、1 問ずつ私にインタビューして。「答え次第でアーキテクチャが変わる質問」を優先して。
4
リファレンスREFERENCES
欲しいものを言葉で細かく説明できないこともある。語彙がなかったり、説明にとても時間がかかったり。そういうときの最善手はリファレンス(参照物)を渡すこと。図や資料や画像でもいいが、最強のリファレンスはソースコードだ。
望む挙動を実装しているライブラリや、気に入っているデザインコンポーネントがあるなら、そのフォルダを Fable に指して「これを見て」と言えばいい。別の言語で書かれていても構わない。Claude Design も同じ仕組みで動いている。ファイルを手渡す必要はなく(もちろん渡してもいい)、気に入ったウェブサイトのモジュールを指させれば、スクリーンショットではなくその下にあるコードを読んでくれる。マークアップや構造、そのコンポーネントが実際にどう組み立てられているかまで、ずっと豊かな情報が手に入る。
プロンプト例
vendor/rate-limiter にある Rust クレートが、まさに欲しいバックオフ挙動を実装してる。これを読んで、同じセマンティクスをうちの TypeScript API クライアントに再実装して。
5
実装計画IMPLEMENTATION PLANS
実装の準備ができたと思ったら、レビュー用の実装計画を作ってもらう。ポイントは、変わる可能性が高い部分——データモデル、型インターフェース、UX フロー——を先頭に置いてもらうこと。自分が実際に手を入れるべき箇所を Claude が浮かび上がらせてくれる。
プロンプト例
実装計画を HTML で書いて。ただし私が調整しそうな決定——データモデルの変更、新しい型インターフェース、ユーザーに見える部分——を先頭に。機械的なリファクタリングは最後に回していい。そこは任せる。
実装後POST / 2 TECHNIQUES
7
ピッチと説明資料PITCHES & EXPLAINERS
何かを世に出すうえで最も重要な工程のひとつが、周囲の理解と承認を得ること。ピッチ資料・説明資料を成果物に添えると、(1) あなたと同じ未知からスタートするレビュアーの理解が速くなり、(2)「想定すべき未知や典型的な失敗点をちゃんと考慮したか」を見たい専門家の承認も速くなる。
プロンプト例
プロトタイプとスペックと実装ノートを、Slack に置くだけで賛同を得られる 1 つのドキュメントにまとめて。デモ GIF を先頭に。
8
クイズQUIZZES
長い作業セッションの後、Claude は自分が思っていた以上のことを成し遂げているかもしれない。コードの差分を読むだけでは浅い理解しか得られない——挙動の多くは既存のコードパスに依存しているからだ。
そこで、まず変更にまつわるコンテキストをたっぷり説明してもらったうえで、その内容について自分にクイズを出してもらう。筆者は、クイズに満点で合格するまでマージしないという。
プロンプト例
この変更で起きたことを全部理解しておきたい。背景、直感的な説明、何をやったかを含む HTML レポートを作って、最後に「合格必須」のクイズを付けて。