【CCA Foundations対策 / Claude API編 #6】プロンプトの書き方①——明確に・具体的に書く
Anthropic Academyの「Claude APIを使用した構築」コースをもとに解説しています。
#4〜#5でEvalパイプラインを作った。スコアを計測できる環境が整ったので、いよいよプロンプト自体を改善していく。この記事では「明確・直接的に書く」「具体的に指示する」の2テクニックを適用して、スコアが3.1から8.3まで上がる過程を追う。
この記事でわかること：
- プロンプトエンジニアリングの改善サイクルの回し方
- 「明確・直接的に書く」とスコアが上がる理由
- 属性型とステップ型、2種類のガイドライン使い分け
- 「丁寧に」「しっかり」が機能しない理由と、それがfalse positiveにつながるパターン
プロンプトエンジニアリングとは
プロンプトエンジニアリングは、書いたプロンプトを「測りながら改善する」技術。感覚ではなく、Evalスコアという数値を根拠に変化を確認できる。
改善サイクルはシンプル：
- ベースラインのプロンプトを書く
- Evalでスコアを取る
- テクニックを1つ適用する
- スコアを再計測して比較する
- 満足いくまで3〜4を繰り返す
「なんとなく良くなった気がする」ではなく、「スコアが5.2から8.1に上がった」という根拠を持って改善を進められる。これが#4〜#5でEvalを先に作る理由でもある。
なぜ「丁寧に」では機能しないか
プロンプトに「丁寧に回答してください」「しっかり要約してください」と書いても、スコアが安定しない。なぜか。
Claudeは指示の言葉をそのまま実行するのではなく、その言葉から意図を推測しようとする。「丁寧に」という指示は、Claudeの解釈空間が広い——敬語を増やすことかもしれないし、詳細な説明を加えることかもしれない。あなたの意図とClaudeの解釈がズレると、スコアがばらつく。
このズレが実際の問題として現れやすいのが**false positive（偽陽性）**だ。分類タスクにおいて「本来は問題ない」ものを「問題あり」と誤って判定してしまうこと。たとえばコンテンツ審査のプロンプトに「conservative（保守的）に判断してください」と書くと、Claudeは安全側に振れて、問題のないコンテンツも不適切と判定するようになる。本来「承認すべきケース」を不必要に弾いてしまう——これがfalse positiveで、プロダクトの信頼性を下げる。
# 曖昧な指示（false positiveを生みやすい）
「不適切なコンテンツを保守的に判断してください」
# 具体的な基準（false positiveを減らせる）
「以下のカテゴリに該当する場合のみ不適切と判定してください：
- 暴力・グロテスクな描写
- 個人を特定できる情報の無断掲載
- 違法行為の明示的な促進」
「カテゴリを明示する」という設計は、Claudeに解釈の余地を与えない。その分、あなたの意図通りに動く確率が上がる。
📋 試験ガイドより
公式試験ガイドのDomain 4 Task 4.1では、曖昧な指示がfalse positiveを増やすリスクと、カテゴリを明示した基準設計の重要性が取り上げられている。
今回のお題：議事録の要約ツール
この記事では「会議の議事録を要約するプロンプト」を例題として使う。入力は議事録テキスト、出力はビジネスで使える要約。
まずベースラインを計測するための実装から始める。
Evalの準備
import anthropic
import json
from statistics import mean
from dotenv import load_dotenv
load_dotenv()
client = anthropic.Anthropic()
model = "claude-haiku-4-5-20251001"
def add_user_message(messages, text):
messages.append({"role": "user", "content": text})
def add_assistant_message(messages, text):
messages.append({"role": "assistant", "content": text})
def chat(messages, system=None, stop_sequences=None):
params = {
"model": model,
"max_tokens": 1000,
"messages": messages,
}
if system:
params["system"] = system
if stop_sequences:
params["stop_sequences"] = stop_sequences
return client.messages.create(**params).content[0].text
テストデータセットの生成
def generate_dataset():
prompt = """
会議の議事録要約タスクのEvalデータセットを生成してください。
以下の形式でJSON配列を出力してください：
[
{
"minutes": "会議の議事録テキスト（200〜300字程度）",
"context": "会議の種類（例：週次定例、プロジェクト進捗など）"
}
]
3件生成してください。内容は多様にしてください。
"""
messages = []
add_user_message(messages, prompt)
add_assistant_message(messages, "```json")
text = chat(messages, stop_sequences=["```"])
return json.loads(text)
dataset = generate_dataset()
グレーダーの実装
採点は生成とは独立したリクエストとして送る（#4の「自己採点問題」を避けるため）：
def grade(minutes, context, output):
eval_prompt = f"""
以下の議事録要約を評価してください。
議事録：{minutes}
会議種別：{context}
要約：{output}
以下の形式でJSONを返してください：
- "strengths": 良い点（配列）
- "weaknesses": 改善点（配列）
- "reasoning": 評価の理由
- "score": 1〜10のスコア
【採点基準】
8〜10点：決定事項・アクションアイテムを含み、簡潔で構造化されている
5〜7点：主要な内容はカバーできているが、構造や網羅性に課題がある
1〜4点：情報が抜け落ちている、または冗長で使いにくい形式になっている
"""
messages = []
add_user_message(messages, eval_prompt)
add_assistant_message(messages, "```json")
text = chat(messages, stop_sequences=["```"])
return json.loads(text)
def run_eval(prompt_fn):
scores = []
for case in dataset:
output = prompt_fn(case["minutes"], case["context"])
result = grade(case["minutes"], case["context"], output)
scores.append(result["score"])
avg = mean(scores)
print(f"平均スコア: {avg:.1f}")
return avg
v1：ベースライン
まず意図的にシンプルなプロンプトで計測する：
def run_prompt_v1(minutes, context):
prompt = f"この議事録を要約してください：\n\n{minutes}"
messages = []
add_user_message(messages, prompt)
return chat(messages)
run_eval(run_prompt_v1)
平均スコア v1: 3.1
v1の出力例：
先週の売上は前週比105%でした。新機能のリリースについては来月予定とのことです。
引き続き対応を進めてまいります。
このスコアが出発点。出力を見ると、何が問題かは明確——長さも形式もばらばらで、「決定事項」や「アクションアイテム」が含まれていない。ビジネスの場で使える状態ではない。
テクニック①：明確・直接的に書く
プロンプトの最初の1行が、Claudeの応答全体の方向を決める。あいまいな書き出しは出力をあいまいにする。
改善のポイント
構造：動詞 + タスク + 出力仕様 の順で書く
| 要素 | 例 |
|---|---|
| 動詞 | 「要約してください」ではなく「生成してください」 |
| タスク | 何を、誰のために |
| 出力仕様 | 形式・長さ・用途 |
指示 vs 質問：「〜してください」という命令形で書く。質問形式（「〜できますか？」）は避ける。Claudeが「はい、できます」と答えてから実行するのか、すぐ実行するのか、解釈が揺れる。
v2：明確・直接的に書く
def run_prompt_v2(minutes, context):
prompt = f"""
以下の会議議事録から、ビジネス利用に適した要約を生成してください。
会議種別：{context}
議事録：
{minutes}
"""
messages = []
add_user_message(messages, prompt)
return chat(messages)
run_eval(run_prompt_v2)
平均スコア v2: 5.4 (v1: 3.1 → +2.3)
v2の出力例：
【週次定例 要約】
・売上：前週比105%。堅調に推移
・新機能リリース：来月予定。準備状況を継続確認
・次回定例：来週同時刻
最初の1行を改善しただけでスコアが2.3上がった。「何を（会議議事録から）」「何のために（ビジネス利用）」「どんな形で（要約を生成）」が明示されたことで、出力の方向性が揃ってきた。ただし「決定事項」や「アクションアイテム」は依然として不安定——形式の指示がないので、Claudeの判断に委ねられている。
テクニック②：具体的に指示する
明確さで出力の方向は揃った。次は「どんな出力を期待しているか」を詳細に指定する。
2種類のガイドライン
プロンプトに追加できる具体的な指示は2種類ある：
属性型（Output Quality Guidelines）
出力の特性を指定する。長さ・構造・含めるべき要素など。
- 箇条書きで3〜5項目にまとめる
- 決定事項と次のアクションを必ず含める
- 200字以内
ステップ型（Process Steps）
Claudeが出力に至るまでの推論の手順を指定する。複雑な判断が必要なタスクに向く。
1. まず議事録全体を読んで主要トピックを把握する
2. 決定事項とアクションアイテムを抽出する
3. 重要度の高い順に整理する
4. 要約を生成する
使い分けの目安
| ガイドライン種別 | 使うタイミング |
|---|---|
| 属性型 | ほぼすべてのプロンプトに追加する |
| ステップ型 | 複雑な判断・複数の視点が必要なタスク |
多くのプロンプトでは両方を組み合わせるのが実践的。ステップ型は「推論のルート」を固定することで、複数ステップの判断が必要な出力を安定させる効果がある。
v3：具体的に指示する
def run_prompt_v3(minutes, context):
prompt = f"""
以下の会議議事録から、ビジネス利用に適した要約を生成してください。
会議種別：{context}
議事録：
{minutes}
【出力ガイドライン】
- 全体を3〜5項目の箇条書きにまとめる
- 「決定事項」と「アクションアイテム（担当者・期日があれば含める）」を必ず別項目で記載する
- 各項目は1〜2文で簡潔にまとめる
- 専門用語はそのまま使い、不必要な言い換えはしない
【出力手順】
1. 議事録全体を読み、主要トピックを把握する
2. 決定事項とアクションアイテムを抽出する
3. 重要度・緊急度の順に並べる
4. 上記ガイドラインに従って要約を生成する
"""
messages = []
add_user_message(messages, prompt)
return chat(messages)
run_eval(run_prompt_v3)
平均スコア v3: 8.3 (v2: 5.4 → +2.9)
v3の出力例：
【週次定例 要約】
・売上：前週比105%。計画比でも堅調に推移中
【決定事項】
・新機能は来月リリース確定。詳細スケジュールは山田が今週中に共有
【アクションアイテム】
・山田：リリーススケジュール策定・共有（今週中）
・各チーム：来週定例までに進捗報告を準備
スコアが2.9ポイント改善した。出力の構造が揃い、「決定事項」「アクションアイテム」という具体的な要素が安定して含まれるようになった。
ステップ型ガイドラインの効果が特に大きい——「抽出 → 整理 → 生成」という手順を明示することで、Claudeが情報を見落とさずに処理する確率が上がる。
2テクニック適用後の変化
| バージョン | 変更内容 | スコア | 改善幅 |
|---|---|---|---|
| v1 | ベースライン | 3.1 | — |
| v2 | 明確・直接的に書く | 5.4 | +2.3 |
| v3 | 具体的に指示する | 8.3 | +2.9 |
2テクニックの適用で3.1から8.3まで改善できた。ここで押さえておきたいのは、1つのテクニックを適用するたびにスコアを確認すること。まとめて変えると「どの変更が効いたか」がわからなくなる。
よくある誤解まとめ
| 誤解 | 実際 |
|---|---|
| 「丁寧に」「しっかり」と書けば質が上がる | Claudeの解釈空間が広すぎてスコアがばらつく。具体的な基準が必要 |
| 「conservative（保守的）に」と書けば安全方向に動く | false positiveを増やす可能性がある。カテゴリ定義の方が精度が高い |
| 最初のプロンプトから完璧を目指すべき | ベースラインを計測してから改善する。最初のスコアが低くて当然 |
| 属性型とステップ型はどちらか一方だけ使う | 多くのケースで両方の組み合わせが効果的 |
| テクニックをまとめて適用して最終スコアだけ見ればいい | 1テクニックずつ適用してスコアを確認しないと、何が効いたかわからなくなる |
まとめ
- プロンプトエンジニアリングはEvalスコアで変化を数値確認しながら進める
- 最初の1行に「動詞 + タスク + 出力仕様」を入れるだけでスコアが上がる
- 「丁寧に」「conservative」などの曖昧な指示は解釈がばらつき、false positiveの原因にもなる
- 属性型ガイドラインはほぼ全プロンプトに追加する価値がある
- ステップ型ガイドラインは複雑な判断が必要なタスクで効果が大きい
- 1テクニックずつ適用してスコアを確認することで、何が効いたかを把握できる
次回は残り2テクニック——XMLタグによる構造化と、例示（ワンショット/マルチショット）を扱う。