プロンプトの型(3つだけ)

公式のベストプラクティスに書かれている考え方を、そのまま貼れる形にしました。どれも「Claude に考える材料と、終わったと判断する材料を渡す」型です。

型1: 先に質問させる(インタビュー → SPEC.md)

大きめの作業は、いきなり作らせずに先に Claude から質問させます。公式docsに載っている原文のプロンプトがこれです([brief description] を自分の作りたいものに置き換える)。

Claude Code の中で(公式原文)

I want to build [brief description]. Interview me in detail using the AskUserQuestion tool.

Ask about technical implementation, UI/UX, edge cases, concerns, and tradeoffs. Don't ask obvious questions, dig into the hard parts I might not have considered.

Keep interviewing until we've covered everything, then write a complete spec to SPEC.md.

日本語で頼むならこうです(意味は同じ。言い回しはこのサイトの訳)。

Claude Code の中で(日本語訳)

[作りたいもの] を作りたい。AskUserQuestion ツールを使って、私に詳しくインタビューして。

技術的な実現方法、画面や使い勝手、例外的なケース、心配な点、トレードオフについて聞いて。当たり前の質問はしないで、私が考えていなさそうな難しいところを掘って。

全部聞き終わるまでインタビューを続けて、終わったら完全な仕様を SPEC.md に書いて。

公式docsのコツ: 仕様ができたら新しいセッション(/clear)で実装を始める。実装専用のきれいなコンテキストになり、書いた仕様を参照できます。

公式docs: ベストプラクティス「Claude にインタビューさせる」

型2: 候補を出させて選ぶ(計画モード)

やり方に迷うときは、計画モードにしてから頼みます。Shift+Tab を何度か押すと、画面下に「plan mode on」と出ます。計画モードでは Claude はファイルを読んで案を出すだけで、書き換えません。

Claude Code の中で(計画モードにしてから)

[やりたいこと] をしたい。まずこのフォルダを読んで、やり方の案を2〜3個出して。
それぞれ「変えるファイル」「良い点」「危ない点」を表にして。私が選ぶまで何も書き換えないで。

公式docsの位置づけ: 計画モードは「探索 → 計画 → 実装 → コミット」の最初の2段階を分けるための機能です。案を選んだら Shift+Tab で計画モードを抜けて実装させます。Ctrl+G で計画をエディタで直接編集することもできます。

公式docsの注意: 計画モードは手間も増えます。タイポ修正や1行の変更のように「差分を1文で言える」作業は、計画を飛ばして直接頼んでOKです。

公式docs: ベストプラクティス「まず探索、次に計画、それからコード」 / 公式docs: 権限モード(計画モード)

型3: 検証手段をセットで渡す

公式docsの言葉を借りると「Claude が自分で実行できるチェックを渡す。それが、見張る必要のあるセッションと、席を離れられるセッションの違い」です。チェックは、テスト・ビルド・スクリプト・画面のスクリーンショット、何でも構いません。

Before(公式docsの例)	After(公式docsの例)
「メールアドレスを検証する関数を作って」	「validateEmail 関数を書いて。テスト例: user@example.com は true、invalid は false、user@.com は false。実装したらテストを実行して」
「ダッシュボードをもっと良くして」	「[スクショを貼る] このデザインを実装して。結果のスクショを撮って元と比べ、違いを列挙して直して」
「ビルドが失敗する」	「ビルドがこのエラーで失敗する: [エラーを貼る]。直してビルドが通ることを確認して。エラーを握りつぶさず根本原因を直して」

非エンジニアがそのまま使える形にすると、こうなります。

Claude Code の中で

[やりたいこと] をして。終わったら [確認方法: 例 python3 -m http.server 8000 で開いて画面を撮る / テストを実行する] で確認して、
その結果(コマンドの出力やスクショ)を見せて。「できました」だけの報告はなしで。

公式docsはさらに「証拠を見せてもらう」ことを勧めています。テストの出力、実行したコマンドと結果、スクショ。自分で再実行するより、証拠を見るほうが速いからです。

公式docs: ベストプラクティス「Claude に検証手段を渡す」

おまけ: ずれたら早めに止める

Esc: 途中で止める(それまでの内容は残る)
Esc Esc または /rewind: 前の時点に会話やコードを巻き戻す
「それ取り消して」: Claude 自身に元に戻させる
同じことを2回以上訂正したら /clear: 失敗した試行でコンテキストが汚れているので、学んだことを入れたプロンプトで最初からやり直すほうが速い(公式docs)

公式docs: ベストプラクティス「早めに軌道修正する」 / 公式docs: チェックポイント(/rewind)