プロンプト術＝Claude への上手な頼み方

1はっきり伝えるほど、いい答えが返る

Claude Code はファイルを読み、コマンドを実行し、自分でコードを直してくれる「動く相棒」です。だからこそ、あなたの最初のひとことがとても大事。公式ガイドもこう言っています ―― 「Claude は意図を推測できますが、あなたの心を読むことはできません」。

🍔たとえ話：ハンバーガーを注文する

お店で「なんかおいしいの」とだけ言ったら、何が出てくるか分かりませんよね。でも「チーズバーガー、ピクルス抜き、ポテトはLで」と言えば、ほしいものがそのまま届きます。Claude への頼み方もまったく同じ。具体的に言うほど、ほしい結果に近づくのです。

flowchart TD
    A["あなたの頼みごと"] --> B{"具体的かな?"}
    B -->|"いいえ あいまい"| C["Claudeが意図を推測する"]
    C --> D["見当ちがいの答え"]
    D --> E["何度も手直し"]
    B -->|"はい はっきり"| F["Claudeが正しく理解"]
    F --> G["ほしかった答え"]
    G --> H["ほぼ一発で完成"]

このページで学ぶ型は、Anthropic（＝Claude を作っている会社）の公式ガイドにもとづいています。出典はこちら。Claude Code のベストプラクティス（公式・ja）

2ダメな頼み方 → 良い頼み方

いちばん効くのは「実例で見くらべること」。公式ガイドの例をもとに、Before（＝残念な頼み方）と After（＝うまい頼み方）を並べてみましょう。

# ❌ Before：ふわっとしすぎ
ログインボタンが動かない。直して

# ✅ After：場所・症状・ゴール・段取りが入っている
login.js のログインボタンが反応しない。原因を調べて直して、
テストも追加して。動くことを確認してから報告して

公式ガイドの「具体的なコンテキストを提供する」表から、4つの言いかえパターンを紹介します。

3良いプロンプトの5要素

うまい頼み方には、共通する「5つの部品」があります。全部入れなくてもOK。でも入れるほど精度が上がります。

1. 頼む前に1秒考える「これ、初対面の人に伝わる？」と自問する。あいまいなら言葉を足す。
2. 5要素をチェック具体・文脈・ゴール・お手本・段取り。足りない部品を1つでも補う。
3. 検証手段を添える「テストを実行して」「スクショを撮って元と比べて」など、確かめ方をセットで頼む。

4文脈（コンテキスト）の渡し方

「文脈を渡す」とは、Claude に判断材料をわたすこと。材料が多いほど、精度の高い答えが返ってきます。渡す方法はいくつもあります。

🧠CLAUDE.md＝毎回読むメモ帳

CLAUDE.md は、Claude が会話のはじめに必ず読む特別なファイル。「ES Modules を使う」「終わったら型チェックして」のようなプロジェクト共通のルールを書いておくと、毎回伝えなくてよくなります。最初は /init で自動生成できます。

flowchart TD
    A["精度を上げたい"] --> B["関係するファイルを @ で渡す"]
    A --> C["エラー画面やデザインを Cmd+V で貼る"]
    A --> D["ゴールと制約を言葉で書く"]
    A --> E["共通ルールは CLAUDE.md に常駐"]
    B --> F["Claudeの理解が深まる"]
    C --> F
    D --> F
    E --> F
    F --> G["手直しの少ない答え"]

もっと詳しくは公式の「リッチコンテンツを提供する」「ファイルとディレクトリを参照する」へ。一般的なワークフロー（公式・ja）

5計画させてから実行する

大きめの作業ほど、いきなり書かせず「まず計画」が正解。公式の合言葉は「最初に探索し、次に計画し、その後コーディングする」です。

計画モード（/plan または Shift+Tabで切替）に入ると、Claude はファイルを読んで作戦を立てますが、承認するまで一切ファイルを書き換えません。だから「方向ちがいのまま突っ走る」事故を防げます。

sequenceDiagram
    participant You as あなた
    participant CC as Claude
    You->>CC: 計画モードで OAuth 追加の計画を作って
    CC-->>You: 変更ファイルと手順の計画を提示
    Note over You,CC: ここで内容を確認・修正できる
    You->>CC: この計画でOK 実行して
    CC-->>You: コードを実装しテストを実行
    You->>CC: 結果を確認して問題があれば修正依頼

公式おすすめの4フェーズはこちら。

1. 探索計画モードで「@src/auth を読んでセッション処理を理解して」と依頼。読むだけで書き換えない。
2. 計画「どのファイルを変える？ 計画を作って」。難所は ultrathink をプロンプトに書いて深く考えさせる。
3. 実装計画モードを抜けて「計画どおり実装して。テストを書いて実行し、失敗を直して」。
4. 仕上げ「説明的なメッセージでコミットして PR を作って」。

6思考の深さを調整する

Claude は「どれくらいじっくり考えるか」を変えられます。軽い作業は軽く、難所は深く ―― このメリハリが、速さと質を両立させるコツです。

# 難しい設計はじっくり考えてほしい
ultrathink この認証まわりの設計をレビューして、安全な方式を提案して

# 全体の思考レベルを高めに設定
/effort high

# 軽い作業はサッと
/fast

7反復（くりかえし）で仕上げる

一発で100点を狙わなくて大丈夫。小さく頼む → 確認する → 直すをくりかえすのが、いちばん速くて確実です。公式も「タイトなフィードバックループ（＝こまめな修正の往復）」をすすめています。

flowchart TD
    A["小さく頼む"] --> B["Claudeが変更する"]
    B --> C["/diff で確認"]
    C --> D{"OK?"}
    D -->|"はい"| E["次の小さな依頼へ"]
    D -->|"いいえ"| F["具体的に直してと頼む"]
    F --> B
    E --> G["少しずつ完成に近づく"]

8すぐ使えるプロンプト型（テンプレ）

最後に、コピーしてすぐ使える「頼み方テンプレ」を3つ用意しました。[ ] の中を自分の状況に書き換えるだけ。公式のレシピをもとにしています。

🔍調査用テンプレ

# コードの仕組みを理解したいとき
このプロジェクトの概要を教えて。
そのあと [認証] がどう処理されているか、関係するファイルを示して、
フロントエンドからデータベースまでの流れを追って説明して

🐛バグ修正用テンプレ

# 症状・場所・ゴール・検証をセットで
[npm test] を実行すると [エラー内容] が出る。
[@src/auth/] のあたりが怪しい。
まず問題を再現する失敗テストを書いて、原因を直して、
テストが通ることを確認してから報告して。
症状ではなく根本原因に対処して、エラーを抑え込まないで

👀レビュー用テンプレ

# 別視点でエッジケースを洗い出す
サブエージェントを使って [@src/middleware/rateLimiter.ts] をレビューして。
エッジケース、競合状態、既存パターンとの一貫性をチェックして、
スタイルの好みではなく、正しさに関わる問題だけを報告して

9まとめ：頼み方は技術、必ず上達する

プロンプト術は、特別な才能ではなく「練習で身につく型」です。今日のポイントをぎゅっとおさらいしましょう。

もっと深めたい人は公式ガイドへ。ベストプラクティス（公式・ja） ／ 一般的なワークフロー（公式・ja）