ツバキリ商会 Claude Code案内所

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

上手な頼み方のコツは山ほど流れてきますが、公式ベストプラクティスの芯は「具体的に頼む・先に計画させる・確認手段を渡す」の3つに集約できます。型にして持っておきましょう。

型1: 先に質問させる(いきなり作らせない)

大きめの頼みごとは、作り始める前に不明点を吐き出させて、合意内容をファイルに残してから着手させます。やり直しが一番高くつくからです。

コピーして、( )を書き換えて使う
(作りたいもの)を作りたいです。
まだ作り始めないでください。
先に、決めておくべきことを質問リストにして私に聞いてください。
私が答えたら、合意した内容を SPEC.md にまとめて、
私が「OK」と言ってから作業を始めてください。

公式ベストプラクティスでも「まず計画を立てさせ、良さそうならコードを書かせる」流れが推奨されています。計画段階では「まだコードを書かないで」と明示するのがコツです。

出典: Anthropic公式: Claude Code best practices(Explore, plan, code)

型2: 候補を出させて選ぶ(丸投げしない)

「いい感じにして」と頼むと、Claudeの好みで進みます。方針が複数ありえるときは、先に候補を出させて自分で選ぶと、後戻りが減ります。

コピーして、( )を書き換えて使う
(やりたいこと)のやり方を3案出してください。
それぞれ「利点」「欠点」「かかる手間」を1行ずつ。
私が番号で選んでから作業を始めてください。

公式docsの拡張思考の項でも、複雑な問題では「代替案を検討させてから決める」使い方が案内されています。

出典: Anthropic公式: Claude Code best practices / 公式docs: よくあるワークフロー

型3: 検証手段をセットで渡す(「できた」を確認させる)

頼みごとと一緒に「どうなったら成功か」「どうやって確かめるか」を渡すと、Claudeが自分で確認→修正を繰り返せるようになり、精度が大きく上がります。

コピーして、( )を書き換えて使う
(直してほしいこと)をお願いします。
終わったら (確認方法: 例「open index.html で開いてスマホ幅でも崩れないこと」) で
自分で確認して、ダメなら直して、もう一度確認してください。
確認結果も報告に含めてください。

公式ベストプラクティスでは、これは「ターゲット(テストや期待結果)を渡す」やり方として紹介されており、成果物の品質を上げる一番効く工夫とされています。

出典: Anthropic公式: Claude Code best practices(Write tests, commit; iterate against targets)

おまけ: 型がうまくいったらCLAUDE.mdへ

同じお願いを2回書いたら、それはCLAUDE.mdに入れるサインです。次回から書かなくてよくなります。会話の途中なら # で始まるメッセージを送ると、Claudeがその内容をメモリに追加してくれます。

出典: Anthropic公式docs: メモリ(#での追加)