「Claude Codeに頼んでも、思ったのと違うものが返ってくるんです」 — 研修でいちばん多い相談です。だいたいの原因は、Claude側ではなく、頼み方(プロンプト)のほうにあります。

プロンプトは、Claude Codeに出す指示の文章のことです。この記事は、思ったとおりに動かすための書き方のコツを、非エンジニア向けに整理したものです。なお以下では、ツールとしてのClaude Codeを、文脈上わかる範囲で「Claude」と略すことがあります。

曖昧な依頼が空振りする理由

まず、よくある失敗から。「いい感じにして」「うまくやって」のような曖昧な依頼は、たいてい空振りします。

Claude Codeは賢いですが、こちらの頭の中までは読めません。「いい感じ」が何を指すかは、人によって違う。だから、何を作りたいのか、どうなったら完成なのかを、言葉にして渡す必要があります。

私が最初にやった失敗も、まさにこれでした。「このデータを集計して」とだけ頼んで、想像と違う集計が返ってきた。何で集計したいか(日付別なのか商品別なのか)を言っていなかったんです。

前提と完了条件を渡す

思ったとおりに動かすコツは、2つです。前提を渡すことと、完了条件を伝えること。

前提というのは、「このプロジェクトはこういうもの」「この言語で」「この形式で」といった背景です。完了条件は、「こうなったら完成」というゴールの線引きです。

$ claude
> 売上データを集計してください。
> 前提として、これは月次の店舗別売上です。
> 店舗ごとに月の合計を出して、多い順に並べた表にしてください。

「集計して」だけのときと比べて、返ってくるものの精度がまるで違います。

1回で全部頼まず、区切る

長い作業を1つの指示に詰め込むと、途中でずれます。

「アプリを作って」のような大きな依頼は、Claudeが何から手をつけるか迷い、こちらの想像とずれた方向に進みがちです。大きな作業は、段階に区切って頼むほうが、結果のコントロールが効きます。

まず設計だけ相談する、次に一部分だけ作らせる、確認してから次へ。重い作業を任せる前に計画を立てさせるやり方は、別記事に整理しています。

「やってほしくないこと」も伝える

意外と効くのが、やってほしくないことを先に言っておくことです。

「テストは変えないで」「このファイルは触らないで」「勝手にライブラリ(外部の部品)を追加しないで」。こうした禁止を最初に渡しておくと、想定外の変更が減ります。私はよく「既存の動いている部分は壊さないで」と添えます。

プロジェクトの決まりごとは、毎回プロンプトに書くより、CLAUDE.mdにまとめておくほうがラクです。

うまくいかないときは一度立ち止まる

それでもずれるときは、頼み方を変えるより、まず何がずれているかをClaudeに説明させると早いです。

「いまの出力の、ここが想像と違う。なぜそうしたか教えて」と聞く。すると、こちらの指示のどこが曖昧だったかが見えてきます。これは、自分のプロンプトの穴を見つける練習にもなります。

研修先でも、「うまくいかない→頼み方を変える」を闇雲に繰り返すより、「どこがずれたか聞く」を挟むほうが、上達が早い人が多いです。

具体的な固有名詞で伝える

もうひとつ効くのが、抽象的な言い方を避けて、具体的な名前で指すことです。

「あのファイル」「さっきの処理」より、「売上.csv(表データのファイル)の集計部分」のように、ファイル名や場所をはっきり書く。Claude Codeはプロジェクトの中身を見ていますが、こちらが何を指しているかが曖昧だと、別の場所を触ってしまうことがあります。

私が研修先で見ていても、指示に具体的な名前が入っている人ほど、一発で当たる確率が高い。「これ」「それ」を、固有名詞に置き換えるだけで精度が変わります。

完璧な一文を目指さない

最後に、肩の力を抜く話を。

最初から完璧なプロンプトを書こうとしなくて大丈夫です。ざっくり頼んで、返ってきたものを見て、足りない前提を足していく。この往復で精度を上げていくほうが、現実的だし速い。

私自身、いまだに一発で完璧な指示は書けません。1回目で7割、対話しながら10割に近づける。そういうものだと思って使うと、気が楽になります。

まとめ

  • 「いい感じにして」のような曖昧な依頼は空振りしやすい
  • 前提(背景)と完了条件(ゴール)を言葉にして渡すと精度が上がる
  • 大きな作業は1回で詰め込まず、段階に区切って頼む
  • 「やってほしくないこと」を先に伝えると想定外の変更が減る
  • ずれたら頼み方を変える前に「どこがずれたか」をClaudeに説明させる
  • 最初から完璧を目指さず、対話しながら精度を上げていく