title: "プロンプト工学" icon: "edit"
プロンプト工学
プロンプト（Prompt）とは、Claudeに与える「指示文」のことです。同じ内容を聞いても、プロンプトの書き方次第で結果の質が大きく変わります。この章では、高品質な回答を引き出すための実践的なテクニックを説明します。すべての原則が大事ですが、まずは「具体性」と「文脈」の2つを意識すれ十分です。
1. 原則1：具体的に書く（Be Specific）
一番大切な原則は「何をしてほしいかを具体的に伝える」ことです。漠然とした指示ほど、Claudeの回答も漠然としたものになります。
具体性のレベル
漠然度（高）
│
│ 「コードを直して」 ← まず回答されない
│
│ 「Pythonでエラーを直して」 ← どのファイルかわからない
│
│ 「auth.pyのログイン関数を修正」 ← まだ不够
│
低
│ 「auth.pyの authenticate_user() に、空文字チェックと
│ パスワード長さチェック（8文字以上）を追加し、
│ エラー時は ValueError を投げてほしい」
具体的であればあるほど、Claudeは意図を正確に理解和実行できます。文件名、行番号、関数名を指定する習慣をつけましょう。
具体性の実例
| 状况 | 漠然とした指示 | 具体的な指示 |
|---|---|---|
| バグ修正 | 「コードを直して」 | 「auth.py の25行目〜40行目のログイン関数に空文字チェックを追加して」 |
| 関数作成 | 「排序の関数を作って」 | 「整数の配列を昇順に排序する関数を作ってください。引数と戻り値の型も教えてください」 |
| エラー対応 | 「動きません」 | 「pip install requests を実行すると SSLError が出る。原因と解決方法を教えてください」 |
2. 原則2：文脈を与える（Give Context）
「なぜそれが必要か」「最終的な目標は何か」を伝えることで、Claudeはより適切なアドバイスができます。文脈がない状况では、Claudeは最も一般的な解答しがちです。
文脈があれば的回答が変わる例
# 文脈なし（不利な例）
# 「このコードのエラーを修正して」
def process(data):
return data.upper()
# 文脈あり（良い例）
# 「Eコマースの注文処理システムで使っています。
#顧客名が空でも処理が進んでしまう問題を修正したい。
# このコードのエラーを修正してください」
def process(data):
return data.upper()
文脈を与えることで、Claudeは「空文字チェックが必要」「注文データなのでNULL考慮が必要」など、表面的な修正以上のアドバイスをくれます。
文脈として有効な情報
- 関連ファイルのコード片（直接貼り付けてOK）
- 最終的な目標（「〜というWebアプリを作りたい」）
- 制約条件（「処理時間は1秒以内にしたい」「Python3.10以前」）
- 既に試みたこと（「このアプローチではうまくいかなかった」）
- エラー発生時の状況（「特定のユーザーだけ発生している」）
3. 原則3：複雑な作業は分割する（Break Down Tasks）
大きな任務は、一度に指示せず小さな手順に分割しましょう。Claudeは一度に処理できる情報量（コンテキスト）に制限があります。すべての要素を同時に指示すると、それぞれが浅くなりがちです。
一括指示 vs 分割指示
❌ 一括指示（不利）：
「ユーザー登録機能を作って。DB設計も、APIエンドポイントも、
バリデーションも全部やって」
→ Claudeが疲れ果てる（コンテキスト限界）
→ どれも中途半端になる
✅ 分割指示（良い）：
「まずDB設計から。ユーザーはID、名前、メールアドレス、パスワード、
作成日時が必要。設計だけ見せてください」
→ 回答を確認
→ 「次に、この設計に基づいて usersテーブルを作成するSQLを見せてください」
→ 回答を確認
→ 「そのテーブルにデータを挿入するAPIエンドポイントをFlaskで作成して」
分割指示の流れる:
Step 1: 「DB設計を見せてください」 →確認OK
↓
Step 2: 「SQLで見せてください」 → 確認OK
↓
Step 3: 「APIを作ってください」 → 完成
「まずXを見せてください。それが終わったらYをお願いします」と伝えるだけで、結果の品質が大きく上がります。
4. 原則4：コードだけでなく「説明」も求める
「動くコード」は得られたけど「なぜそうなるのか」がわからないと、次に類似问题时自力で解決できません。常に「なぜ」を尋ねる習慣をつけましょう。
説明を求めるプロンプト例
「この正規表現を説明してください。そして、自分が似た場面で
使えるようになるためのポイントを3つ教えてください」
「このコードなぜ効率的なのか？計算量を説明して ，
そして他の方法とのトレードオフも教えて」
「この関数の引数设计の意図を教えてください。
どんな場合にこの设计的优点が活きるのかもお願いします」
「動くけど理解できないコード」は、実質的なスキルにはなりません。説明を求めることで、次に類似问题时自力で解決できるようになります。
5. Chain of Thought（思考の連鎖）
複雑な推論が必要な问题时、think step by step（一歩一歩考えて）と一言添えるだけで、Claudeの回答の質が劇的に向上します。これは Chain of Thought（思考の連鎖）と呼ばれるテクニックです。
通常の回答 vs Chain of Thought
❌ 通常：
「12,345 × 67 を計算して」
→ 826,515 （答えだけ出力。過程が見えない）
✅ Chain of Thought：
「12,345 × 67 を計算して。step by stepで考えて」
→ 12,345 × 67 を計算します。
→まず 12,345 × 60 = 740,700
→ 次に 12,345 × 7 = 86,415
→ 合計: 740,700 + 86,415 = 827,115
→ ※検算: 827,115 ÷ 67 = 12,345 ✓
実用的な Chain of Thought の使い方
「このバグの原因を step by stepで分析してください」
「Pythonでのソートアルゴリズムを選択する基準を step by stepで
説明して、それに基づいて私のケースに最适合なものを推荐して」
「キャッシュ失效の問題考えられる原因を step by stepで列挙して、
それぞれの解決策もお願いします」
複雑な问题时、Claudeは途中で思考を間違うこともあります。その場合は「その推論の●手续が理解できません。もう一度お願いします」とフィードバックしましょう。
6. デバッグ：しくない回答が返ってきたとき
Claudeの回答が不正确な場合、責めるのではなくプロンプトを言い換えることを试试。AIは意见すれば変わる生き物なので、同じ失敗を責めるより、視点を変えて再说得効果的です。
デバッグの手引き
| 状况 | 尝试する对策 |
|---|---|
| 回答が的外れ | 文脈を追加する（コード片・目标的を貼り付け） |
| 解決策が動かない | エラーメッセージをそのまま貼り付ける |
| 解決策が複雑すぎる | 「もっと简单な方法は?""と问う |
| 推論が間違う | step by stepを添えて推論过程を見せる |
| コードが古臭い | 「现代的なPythonではどう書きますか?」と问う |
| 欲しい结果と違う | 「○○の观点は考虑されていますか?」と补足 |
具体例
❌ 責める言い方：
「さっきの答え错误でした。やり直して」
✅改善を求める言い方：
「それは试しましたが ‘ModuleNotFoundError’ が出ました。
エラーメッセージ: [ここに貼り付け]
原因と修正方法をstep by stepで教えてください」
エラーメッセージをそのまま貼り付けるのは、最もシンプルで効果的なデバッグテクニックです。エラー文には原因の手がかりが必ず含まれているので、Claudeに渡すことで正確な原因を探ってもらえます。
7. ロール・プロンプト（Role Prompting）
「あなたは〇〇の専門家です」と役割を与えると、専門家の知識が激活されて回答の質が上がります。これは Role Prompting（ロール・プロンプト）と呼ばれるテクニックです。
ロール・プロンプトの効果
❌ 役割なし：
「配列から重複を削除する方法を教えて」
→ set()を使う方法などの基本的な回答
✅ 役割あり：
「あなたはPythonのSenior Engineerです。配列から重複を削除する
方法を教えて。実務での選択基準も教えてください」
→ set()の方法に加え、「辞書の順序維持が必要な場合は dict.fromkeys()」
「大規模データでは NumPy の unique()」など、実務的な知識が加わる
実用的なロール例
| 役割 | 効果 |
|---|---|
Python Expert |
最新のPythonicな書き方で回答 |
Code Reviewer |
バグ・改善点を具体的に指摘 |
Teacher |
初心者のレベルに合わせて説明 |
Debugging Expert |
システム的なデバッグ手順を提案 |
Security Engineer |
セキュリティ上のリスクを指摘 |
ロールを指定する場合は、「あなたは○○です」加上「〜这样的回答が欲しい」と付け加えると、より望む结果に近づけます。
8. 反復的アプローチ：少しずつ確かめながら進める
Claudeと効率的に作業するには、一度に完璧を求めすぎないことが大事です。小さな一歩ずつ確認しながら進めると、失敗した際のやり直しコストを最小化できます。
反復的アプローチ
❌ 一度に完美を求める（非効率）：
「全部作った」→「错误了大量」→「どこが悪いのかわからない」
✅ 小さな一歩ずつ確認（効率的）：
「まず設計だけ見せてください」 → OK?
「次に骨組みを見せてください」 → OK?
「そこにロジックを追加してください」 → OK?
「完成!」 → 最初から全部正しい
确认しやすい指示の例
「まず、このログイン処理のフローチャートを見せてください」
「次に、HTMLフォームの雛形を見せてください」
「そのフォームから受け取ったデータを处理する部分を書いてください」
「最後に、错误处理的を追加してください」
こうすることで、最悪の場合でも「やり直す範囲」が一小部分で済みます。最初から全部を作らせると、問題の切り分けが難しくなります。
9. 制約・条件を指定する
Claudeに「こうなってほしい」と期望を伝えるのではなく、「这样的条件を満たす」ことを明確に指定すると、より精确な回答になります。
制約を指定する例
| 制約の種類 | 指示例 |
|---|---|
| 言語バージョン | 「Python 3.10以前的语法で書いてください」 |
| 性能制約 | 「処理时间是100ms以内に収めてください」 |
| ファイル構成 | 「单一行80文字、importはアルファベット順に並べてください」 |
| 既存の风格 | 「既存のコード同样的风格に合わせてください（例: snake_case）」 |
| 外部依存 | 「追加のライブラリ不使用。標準ライブラリだけ使ってください」 |
❌ 漠然とした期望：
「シンプルなコードで書いてください」
✅ 明確な制約：
「標準ライブラリだけ使い、行数を20行以内に抑えてください。
variable名はすべて snake_case で統一してください」
制約を指定することで、Claudeが「最も简单な方法」を選びやすくなります。また、後からコードレビューする際にも、判断基準が明确なので检查がしやすくなります。
10. 出力形式を指定する
Claudeに「这样帮我整理成表格好吗？」のように、出力形式を指定できます。報告や資料作成時に有効です。
出力形式の指定例
「APIエンドポイントを以下の表格で整理してください：
| エンドポイント | HTTPメソッド | 説明 |」
「引数の型とデフォルト値を以下の形式で見せてください：
- arg1: str (必須) —説明
- arg2: int = 10 (任意) — 説明」
「エラーケースを以下の形式で列挙してください：
【ケース名】原因と対策を簡単に」
コードの出力形式も指定可能
「TypeScriptで書かれたReactコンポーネントを、
以下の约束事项を守って書いてください：
- FC<Event> 型をexport
- CSS Modules を使って
- Storybook のストーリーファイルも同時に生成」
出力形式を指定すると、Claudeの回答が後で使いやすくなります。受け取った後に手作業で整形する必要がなくなります。
11. まとめ：良いプロンプトの条件
ここまでの原則を整理します。
| 原則 | やること | 効果 |
|---|---|---|
| 具体性 | 「どのファイルのどの部分」を明確に | 正確な回答 |
| 文脈 | コード・目標・制約を添付 | 適切なアドバイス |
| 分割 | 複雑な任務は小步骤に | 品質維持 |
| 説明を求める | 「なぜ」を常に尋ねる | 理解の深まり |
| Chain of Thought | step by stepを添える |
複雑な推論の正確化 |
| デバッグ | プロンプトを言い換える | 的外れ回答の修正 |
| ロール指定 | 専門家役割を付与 | 専門知識の激活 |
良いプロンプト = 具体性 + 文脈 + 分割 + 説明要求
↓
「何を」「なぜ」「どの範囲で」
を明確にした指示文
これらの原則を組み合わせることで、Claude Codeの可能性を最大限度に引き出すことができます。すべてを思い出すのは難しいので、まずは「具体性」と「文脈」の2つを意識してみましょう。この2つだけで、回答の品質は劇的に向上します。
次の章では、実際のプロジェクトでClaude Codeを活用する実践的な方法を学びます。