Phase 2: Prompt Engineering & Structured Output | Claude Architect 試験対策

プロンプトの基本構造

GitHub Tutorial Ch1: Basic Prompt Structure

Claude へのリクエストは system prompt と user message の2層で構成されます。それぞれの役割を理解することがプロンプト設計の出発点です。

2つの入力チャネル

system prompt

Claude の振る舞い、役割、制約を定義する指示文。ユーザーとの会話の外側に位置し、全てのやり取りに適用されます。

- ペルソナの設定
- 出力フォーマットの指定
- 禁止事項やガードレール
- 背景情報の提供

user message

実際のタスクやクエリを含むメッセージ。毎回変わる動的な入力です。

- 具体的な質問や指示
- 処理対象のデータ
- コンテキスト情報
- 出力の期待値

import anthropic

client = anthropic.Anthropic()

message = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system="あなたは経験豊富な技術文書のレビュアーです。"
           "簡潔で正確なフィードバックを提供してください。",
    messages=[
        {"role": "user", "content": "以下のAPI仕様書をレビューしてください: ..."}
    ]
)

        

プロンプトの構成要素チェックリスト

良いプロンプトには以下の要素が含まれます。全てが毎回必要なわけではありませんが、複雑なタスクほど多くの要素が求められます。

タスクの定義

Claude に何をしてほしいかを明確に述べる

コンテキスト

タスクに必要な背景情報や参照データ

出力フォーマット

期待する形式を具体的に指定する

制約条件

やってはいけないこと、守るべきルール

明確で具体的な指示

Ch2: Being Clear and Direct / Ch5: Formatting Output

Claude に対するプロンプトは「新入社員への業務指示」と同じ感覚で書きます。曖昧な表現を避け、期待する結果を具体的に記述することで、出力の精度が大幅に向上します。

曖昧 vs 具体的な指示

悪い例: 曖昧な指示

"この文章を改善してください"

何を改善するのか不明。文法？簡潔さ？トーン？Claude は推測するしかありません。

良い例: 具体的な指示

"この文章を以下の基準で編集してください:
- 受動態を能動態に変換
- 1文あたり30字以内に短縮
- 専門用語に括弧書きで説明を追加"
            

何をどうするかが明確。Claude は判断に迷わず作業できます。

試験で問われるポイント

Claude は指示が曖昧な場合、最善の推測で応答しますが、その推測がユーザーの意図と一致する保証はありません。「もっと良く」「適切に」「うまく」といった主観的な表現を避け、具体的な基準を示すことが鍵です。

プリフィル (Prefilling): Claude の出力を誘導する

assistant メッセージの冒頭を事前に設定することで、Claude の出力フォーマットや方向性を強力に制御できます。Claude はその続きから生成を開始します。

messages = [
    {"role": "user", "content": "このテキストの感情分析結果をJSONで返してください: ..."},
    {"role": "assistant", "content": "{"}  # プリフィル: JSONの開始を強制
]

        

用語解説: Prefilling

assistant ロールのメッセージに冒頭テキストを入れておくテクニック。Claude はそのテキストの続きとしてレスポンスを生成します。JSON出力を確実にしたいとき、特定のフォーマットで回答を始めさせたいときに有効です。

出力フォーマットの指定

Claude に望む出力形式を明示的に伝える方法はいくつかあります。

直接指定

「JSON形式で出力してください」「箇条書きで3点にまとめてください」のように出力形式を明示する

テンプレート提供

期待する出力のテンプレートを示し、Claude にその形式を埋めさせる

プリフィルによる強制

assistant メッセージの冒頭で出力の開始部分を指定し、形式を強制する

XMLタグによる構造化

Ch4: Separating Data from Instructions

XMLタグは Claude にとって最も理解しやすい構造化記法です。指示とデータを明確に分離し、複雑なプロンプトを整理するために不可欠なテクニックです。

なぜXMLタグなのか

Claude は学習データの中でXMLタグを大量に見ており、タグの開始と終了を正確に認識できます。Markdown の見出しやインデントよりも、データの境界を明確に伝えられます。

悪い例: データと指示が混在

"以下のメールを要約してください。
重要度を付けて3文で。
件名: 来月の予算について
本文: 先日の会議で議論した通り..."
            

どこまでが指示でどこからがデータか曖昧です。

良い例: XMLタグで分離

"以下のメールを要約してください。
重要度を付けて3文でまとめてください。

<email>
件名: 来月の予算について
本文: 先日の会議で議論した通り...
</email>"
            

指示とデータの境界が明確です。

よく使われるXMLタグパターン

# 複数のデータソースを整理
prompt = """以下の2つのドキュメントを比較し、矛盾点を指摘してください。

<document_1>
{doc1_content}
</document_1>

<document_2>
{doc2_content}
</document_2>

<instructions>
- 事実レベルの矛盾のみ報告すること
- 表現の違いは無視すること
- 各矛盾点にドキュメント番号と該当箇所を明記すること
</instructions>

<output_format>
矛盾1: [説明]
- Document 1: [該当箇所]
- Document 2: [該当箇所]
</output_format>"""
        

試験で問われるポイント

XMLタグはプロンプトインジェクション対策としても有効です。ユーザー入力を <user_input> タグで囲むことで、Claude は「これはデータであり、指示ではない」と認識しやすくなります。ただし完全な防御ではないため、追加のバリデーションも必要です。

出力にXMLタグを使わせる

Claude の出力にもXMLタグを使わせると、プログラムからのパース(解析)が容易になります。

prompt = """記事を分析し、以下のXMLフォーマットで出力してください:

<analysis>
  <summary>3文以内の要約</summary>
  <sentiment>positive / negative / neutral</sentiment>
  <key_topics>
    <topic>トピック名</topic>
  </key_topics>
</analysis>"""
        

XMLタグ付きの出力は正規表現や簡単なパーサーで抽出できるため、後続のパイプラインに接続しやすくなります。

ロールプロンプティング

Ch3: Assigning Roles

Claude に特定の専門家の役割を与えることで、回答のトーン、深さ、視点を制御できます。system prompt で設定するのが最も効果的です。

ロール設定の効果

# ロールなし
system = "ユーザーの質問に答えてください。"

# ロールあり - より専門的で深い回答が得られる
system = """あなたは10年以上の経験を持つセキュリティエンジニアです。
コードレビューでは以下の観点を重視してください:
- OWASP Top 10 の脆弱性パターン
- 認証・認可の実装ミス
- 入力バリデーションの不備"""
        

トーンの変化

医師なら慎重に、マーケターなら積極的に。役割に応じた語調で応答します。

知識の焦点化

特定分野の専門知識を優先的に活用し、関連性の高い情報を引き出します。

判断基準の設定

何を重要と判断し、何を無視するかの基準が役割に沿って変わります。

アンチパターン: 過度に複雑なペルソナ

「あなたは35歳のシリコンバレー出身のエンジニアで、スタンフォード大学卒で...」のような詳細な個人プロフィールは不要です。Claude に必要なのは専門分野と判断基準であり、架空の経歴ではありません。役割に必要な要素だけを簡潔に記述しましょう。

Few-shot学習 (例の活用)

Ch7: Using Examples

入力と出力のペアを具体例として示すテクニックです。Claude は例のパターンを学習し、新しい入力に同じパターンを適用します。「百聞は一見にしかず」はLLMにも当てはまります。

Few-shot の実装パターン

# XMLタグで例を構造化する方法
prompt = """テキストから製品情報を抽出してください。

<example>
  <input>新型iPhone 15 Proは999ドルから。A17チップ搭載。</input>
  <output>
    製品名: iPhone 15 Pro
    価格: 999ドル
    特徴: A17チップ
  </output>
</example>

<example>
  <input>Galaxy S24 Ultraが発表。価格は1299ドル、AI機能を強化。</input>
  <output>
    製品名: Galaxy S24 Ultra
    価格: 1299ドル
    特徴: AI機能強化
  </output>
</example>

以下のテキストを処理してください:
<input>{user_text}</input>"""
        

用語解説

Zero-shot: 例を一切示さず、指示文だけでタスクを実行させる方法。単純なタスクに適しています。
Few-shot: 2~5個の入出力ペアを例として示す方法。Claude はパターンを読み取り、新しい入力に適用します。
Many-shot: 多数の例を示す方法。分類タスクなど、全カテゴリの例を網羅したい場合に使います。

ベストプラクティス

✓ 例の多様性を確保する。偏った例を示すと、出力も偏ります
✓ エッジケースを含める。通常パターンだけでなく例外の処理方法も示す
✓ 例の出力フォーマットを統一する。Claude はフォーマットのばらつきにも従います
✓ 3~5個の例で十分な場合が多い。多すぎると逆にノイズになります

Messages API による Few-shot

プロンプト内に例を埋め込む代わりに、会話履歴として例を渡す方法もあります。user/assistant のペアで例を構成します。

messages = [
    # 例1
    {"role": "user", "content": "感情分析: 今日は最高の一日だった！"},
    {"role": "assistant", "content": "positive"},
    # 例2
    {"role": "user", "content": "感情分析: 電車が遅延してうんざりだ"},
    {"role": "assistant", "content": "negative"},
    # 実際の入力
    {"role": "user", "content": "感情分析: 特に何もない普通の日だった"},
]

        

Chain-of-Thought (段階的思考)

Ch6: Precognition / Thinking Step by Step

Claude に「考えてから答えさせる」テクニックです。複雑な推論タスクでは、いきなり結論を出すよりも中間ステップを明示させることで精度が大幅に向上します。

基本的な使い方

prompt = """以下の質問にステップバイステップで答えてください。

<question>
ある店舗の月曜の売上が120万円、火曜が前日比15%増、
水曜が火曜の売上から8万円減でした。3日間の合計売上は？
</question>

まず各日の売上を計算し、その後合計を求めてください。
最終回答を <answer> タグで囲んでください。"""
        

なぜ効果があるのか

LLMはトークンを順番に生成します。中間ステップを出力させることで、次のトークンを生成する際に前のステップの結果を参照でき、論理的な一貫性が保たれます。いきなり答えを出そうとすると、複雑な計算で間違いやすくなります。

Extended Thinking (拡張思考モード)

Claude 3.5 Sonnet 以降で利用可能な機能で、Claude がレスポンスの前に内部的に思考プロセスを展開します。通常のChain-of-Thoughtよりも深い推論が可能になります。

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=16000,
    thinking={
        "type": "enabled",
        "budget_tokens": 10000  # 思考に使うトークン数の上限
    },
    messages=[{"role": "user", "content": "この数学の証明を検証してください: ..."}]
)

# 思考プロセスと最終回答は別々のブロックで返される
for block in response.content:
    if block.type == "thinking":
        print("思考:", block.thinking)
    elif block.type == "text":
        print("回答:", block.text)

        

用語解説: Extended Thinking

budget_tokens で思考に使えるトークン数を指定します。複雑な問題ほど多くの思考トークンが必要です。思考内容は thinking ブロックとして返されますが、これは Claude の内部推論であり、最終回答は別の text ブロックに含まれます。

アンチパターン

✗ 単純な事実質問に Chain-of-Thought を使う。「日本の首都は？」に段階的思考は不要でコストの無駄です
✗ 思考を強制しつつ、思考部分を出力に含めない指示を出す。出力しなければ精度向上の効果が得られません

ハルシネーションの防止

Ch8: Avoiding Hallucinations

ハルシネーション(幻覚)とは、Claude が事実ではない情報をあたかも事実であるかのように生成する現象です。完全に排除はできませんが、プロンプト設計で大幅にリスクを低減できます。

ハルシネーション防止の3つの戦略

1. 「わからない」と言える許可を与える

Claude は質問に答えようとする強い傾向があり、情報が不足していても何か生成しようとします。「情報が不足している場合は『わかりません』と回答してください」と明示的に許可することで、この傾向を抑制します。

system = """あなたは正確性を最優先する医療情報アシスタントです。
確信が持てない情報には必ず「この情報は確認が必要です」と付記してください。
情報が不足している場合は推測せず、その旨を伝えてください。"""
            

2. 引用と参照の要求

回答の根拠を示させることで、Claude が「作り上げた」情報を見つけやすくなります。引用元を要求すると、Claude は実在するソースに基づいた回答を優先します。

prompt = """提供されたドキュメントのみに基づいて回答してください。
各主張に対し、参照元のドキュメント名と該当部分を引用してください。
ドキュメントに記載されていない情報は含めないでください。

<documents>
{reference_docs}
</documents>"""
            

3. 段階的な検証プロセス

回答を生成した後に自己検証させるパターンです。「まず回答を生成し、次にその回答が提供された情報と矛盾しないか検証してください」と指示することで、ハルシネーションの自己検出が可能になります。

試験で問われるポイント

ハルシネーション防止は「確率的」な対策であり、プロンプトだけで100%防ぐことはできません。クリティカルな用途では、RAG (検索拡張生成) で事実に基づくコンテキストを提供し、さらに後処理で出力を検証するなど、複数の防御層を組み合わせることが推奨されています。

構造化出力 (JSON Schema)

Structured Output / tool_choice による出力制御

API連携や後続処理のために、Claude の出力を正確なJSON形式で取得する手法です。プロンプト指示だけでなく、tool_choice による強制やプリフィルなど、複数のアプローチがあります。

手法1: tool_choice によるJSON出力の強制

ツールを「ダミー」として定義し、そのスキーマをJSON出力のフォーマットとして利用するテクニックです。ツールを実際に実行する必要はなく、Claude が生成した input パラメータをそのまま構造化データとして使います。

# ツールの input_schema で出力フォーマットを定義
tools = [{
    "name": "extract_info",
    "description": "テキストから情報を構造化して抽出する",
    "input_schema": {
        "type": "object",
        "properties": {
            "name": {"type": "string", "description": "人物名"},
            "company": {"type": "string", "description": "所属企業"},
            "role": {"type": "string", "description": "役職"},
            "topics": {
                "type": "array",
                "items": {"type": "string"},
                "description": "議論のトピック"
            }
        },
        "required": ["name", "company", "role", "topics"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    tools=tools,
    tool_choice={"type": "tool", "name": "extract_info"},  # 強制
    messages=[{"role": "user", "content": "名刺情報: ..."}]
)

# ツールの input がそのまま構造化データ
structured_data = response.content[0].input
print(structured_data)
# {"name": "田中太郎", "company": "ABC Corp", "role": "CTO", "topics": [...]}

        

試験で問われるポイント

この手法の利点は、JSON Schema で出力の型を厳密に定義できることです。required フィールドで必須項目を指定でき、enum で値の選択肢を制限することもできます。プロンプトで「JSONで出力して」と頼むだけでは、フォーマットが安定しない場合があります。

手法2: プリフィルによるJSON出力

assistant メッセージの冒頭に { を設定し、JSONの開始を強制します。tool_choice に比べて柔軟ですが、スキーマの厳密な保証はありません。

messages = [
    {"role": "user", "content": """以下のレビューを分析し、JSON形式で返してください:
{
  "sentiment": "positive/negative/neutral",
  "confidence": 0.0~1.0,
  "key_phrases": ["フレーズ1", "フレーズ2"]
}

レビュー: この商品は期待以上の品質でした。配送も迅速で満足しています。"""},
    {"role": "assistant", "content": "{"}
]

        

バリデーションとエラー処理

構造化出力は必ずしも完璧ではありません。バリデーション層を設けることが実務では不可欠です。

import json
from jsonschema import validate, ValidationError

def safe_extract(response, schema):
    try:
        # tool_choice 経由の場合
        data = response.content[0].input
        validate(instance=data, schema=schema)
        return data
    except ValidationError as e:
        # スキーマ不一致: リトライまたはフォールバック
        print(f"バリデーションエラー: {e.message}")
        return None
    except (json.JSONDecodeError, AttributeError):
        # JSON パースエラー: リトライ
        return None

        

ベストプラクティス

✓ tool_choice を使う方法が最も安定。JSON Schema で型を厳密に定義できます
✓ プリフィルはシンプルな出力に有効。複雑なネスト構造には tool_choice を推奨
✓ 必ず出力のバリデーションを行い、失敗時のリトライロジックを実装する

プロンプト評価 (Evals)

Prompt Evaluation / promptfoo

プロンプトの品質は「なんとなく良さそう」ではなく、体系的に計測する必要があります。評価ワークフローを確立することで、プロンプトの改善を科学的に進められます。

評価ワークフロー全体像

1. テストデータセットの生成

2. プロンプトの実行 (Evals Run)

3. 結果の採点 (Grading)

4. 分析とプロンプト改善

採点手法の比較

コードベースの採点

プログラムで正解を機械的に判定する方法。完全一致、部分一致、正規表現マッチなどを使います。

# 分類タスクの採点例
def grade_classification(output, expected):
    return output.strip().lower() == expected.lower()

# 部分一致の採点例
def grade_extraction(output, required_fields):
    data = json.loads(output)
    return all(f in data for f in required_fields)
            

向いている場面: 分類、データ抽出、フォーマット検証など、正解が明確に定義できるタスク

モデルベースの採点

別のLLM(またはClaude自身)を採点者として使い、出力の品質を評価する方法。自由文の品質判定に適しています。

# Claude を採点者として使う
grading_prompt = f"""以下の回答を1-5で採点:
<criteria>正確性、完全性、簡潔性</criteria>
<response>{model_output}</response>
<rubric>
5: 全基準を満たす
3: 概ね正確だが不足あり
1: 不正確または的外れ
</rubric>"""
            

向いている場面: 要約、文章生成、説明文など、品質が主観的なタスク

promptfoo によるEval自動化

promptfoo はプロンプト評価を自動化するオープンソースツールです。テストケースの定義、実行、採点を一括で管理できます。

# promptfooconfig.yaml の例
prompts:
  - "テキストの感情を分析してください: {{text}}"

providers:
  - "anthropic:messages:claude-sonnet-4-5-20250514"

tests:
  - vars:
      text: "今日は最高の一日でした！"
    assert:
      - type: contains
        value: "positive"
  - vars:
      text: "電車が遅延して最悪だ"
    assert:
      - type: contains
        value: "negative"
  - vars:
      text: "普通の日だった"
    assert:
      - type: contains
        value: "neutral"

        

用語解説: promptfoo

YAML設定ファイルでテストを定義し、promptfoo eval コマンドで一括実行します。contains、equals、is-json、llm-rubric など多様なアサーションタイプをサポートし、コードベースとモデルベースの両方の採点が可能です。

実践: 複雑なプロンプト構築

Ch9: Complex Prompts / Real World Prompting

ここまで学んだテクニックを組み合わせて、実務レベルのプロンプトを構築します。医療問診、コールセンター、カスタマーサポートなど、実際のユースケースに基づいた設計パターンを見ていきましょう。

ケース1: 医療情報アシスタント

正確性が最優先で、ハルシネーションが致命的な領域です。ロール設定、引用要求、不確実性の表明を組み合わせます。

system = """あなたは医療情報の整理を支援するアシスタントです。

<role>
医学文献に基づいた情報整理を行います。
診断や治療の提案は行いません。
</role>

<rules>
- 提供されたドキュメントに記載された情報のみ使用すること
- 各回答に参照元の文献名とページ番号を付記すること
- 情報が不足している場合は「この点について提供資料に記載がありません」と明記
- 一般的な医学知識で補完する場合は「一般的な医学知識として」と前置きする
- 最終的な判断は必ず医療専門家に委ねるよう注記する
</rules>

<output_format>
1. 要約 (3文以内)
2. 詳細 (参照付き)
3. 注意事項
</output_format>"""
        

使われているテクニック

- ロールプロンプティング: 医療情報アシスタントという役割を定義
- XMLタグ: role, rules, output_format をタグで構造化
- ハルシネーション防止: 引用要求、不確実性の表明、範囲の限定
- 出力フォーマット: 構造化された回答形式を指定

ケース2: 通話要約システム

コールセンターの通話記録を構造化データに変換するプロンプトです。Few-shot と構造化出力を組み合わせています。

system = """コールセンターの通話記録を分析し、構造化された要約を生成してください。

<example>
<transcript>
オペレーター: お電話ありがとうございます。ご用件をお伺いします。
顧客: 先週注文した商品がまだ届かないんですけど。注文番号はORD-5678です。
オペレーター: 確認いたします。配送が遅延しており、明日到着予定です。
顧客: わかりました。ありがとうございます。
</transcript>
<summary>
カテゴリ: 配送問い合わせ
顧客の問題: 注文商品の未着 (ORD-5678)
解決状況: 解決済み - 翌日配達予定を案内
顧客満足度: 良好
要対応: なし
</summary>
</example>"""
        

ケース3: カスタマーサポートBot

ツール利用とプロンプトチェーニングを組み合わせた実践的な例です。

system = """あなたはECサイトのカスタマーサポートBotです。

<tools_usage>
- lookup_order: 注文番号で注文情報を検索
- check_inventory: 商品の在庫確認
- create_ticket: エスカレーション用チケット作成
</tools_usage>

<workflow>
1. 顧客の問い合わせ内容を分類する
2. 必要な情報をツールで取得する
3. 回答を生成する
4. 解決できない場合は create_ticket でエスカレーション
</workflow>

<guardrails>
- 返金の実行は行わない (案内のみ)
- 個人情報は確認のために復唱しない
- 対応できない要求は丁重に断り、代替手段を提示する
</guardrails>"""
        

プロンプト設計のプロセス

実務のプロンプト設計は以下のサイクルで進めます。(1) ユースケースの明確化 (2) 最小限のプロンプトで試作 (3) 失敗パターンの収集 (4) テクニックの追加で対処 (5) Evalで効果を検証 (6) 2に戻る。最初から完璧を目指すのではなく、反復的に改善します。

プロンプトチェーニング

複雑なタスクを複数のプロンプトに分割し、前のステップの出力を次のステップの入力として使う手法です。1つの巨大なプロンプトで全てを処理するよりも信頼性が高まります。

Step 1 文書を分類し、カテゴリを出力

Step 2 カテゴリに応じた専用プロンプトでデータ抽出

Step 3 抽出データをバリデーションし、不足があれば再抽出

完了構造化されたデータをデータベースに保存

アンチパターン: 過度なチェーン

単純なタスクを無理に分割すると、レイテンシが増加しコストも倍増します。チェーニングは「1つのプロンプトでは品質が出ない」場合にのみ採用すべきです。

Temperature とモデル動作の制御

Temperature / Streaming / System Prompts Best Practices

Temperature パラメータ

temperature は Claude の出力のランダム性を制御するパラメータです。0に近いほど決定論的になり(毎回同じような出力)、1に近いほど多様な出力が得られます。

値	特性	適したユースケース
`0.0`	最も決定論的	分類、データ抽出、コード生成、数学的計算
`0.3~0.5`	やや変化あり	一般的な Q&A、要約、ビジネス文書
`0.7~1.0`	多様で創造的	ブレインストーミング、クリエイティブライティング、対話

response = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    temperature=0.0,  # 分類タスクでは低めに設定
    messages=[{"role": "user", "content": "..."}]
)

        

レスポンスストリーミング

長いレスポンスを全て待つのではなく、生成されるそばからトークン単位で受け取る方式です。ユーザー体験の向上に直結します。

with client.messages.stream(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    messages=[{"role": "user", "content": "..."}]
) as stream:
    for text in stream.text_stream:
        print(text, end="", flush=True)

        

system prompt のベストプラクティス

役割とコンテキストを最初に置く

Claude が最初に読む情報が以降の解釈に影響するため、役割定義を先頭に配置します

XMLタグで構造化する

長い system prompt は role, rules, examples, output_format のようにタグで区分けする

禁止事項は肯定形で書く

「~しないでください」よりも「~の場合は~してください」の方が遵守率が高い

避けるべきこと

矛盾する指示を含める、過度に長くする(重要な指示が埋もれる)、ビジネスクリティカルなルールをsystem promptだけに頼る

確認テスト

試験形式に合わせた選択式問題です。各問題をクリックして回答を確認してください。

▶

Q1. Claude のプロンプトでデータと指示を分離するために最も推奨される方法は？

A) Markdown の見出しで区切る

B) XMLタグでデータを囲む

C) インデントで階層を示す

D) 改行で区切る

正解: B

XMLタグは Claude が最も正確に認識できる構造化記法です。データの開始と終了を明確にマークでき、ネストも可能です。Anthropic の公式ドキュメントでも推奨されている手法です。

▶

Q2. Claude からJSON形式の構造化出力を確実に得るための最も信頼性の高い方法は？

A) プロンプトに「JSONで出力してください」と記述する

B) Few-shot でJSON出力の例を示す

C) tool_choice でツールを強制し、input_schema で出力フォーマットを定義する

D) assistant メッセージのプリフィルに "{" を設定する

正解: C

tool_choice による強制が最も信頼性が高い方法です。JSON Schema で型、必須フィールド、enum などを厳密に定義でき、Claude はスキーマに従った出力を生成します。A, B, D はいずれも有効なテクニックですが、フォーマットの安定性では C に劣ります。

▶

Q3. ハルシネーションを防止するためにプロンプトに含めるべき指示として、最も効果的なのは？

A) 「正確に回答してください」と注意を促す

B) temperature を 0 に設定する

C) 「提供されたドキュメントのみに基づいて回答し、情報が不足している場合はその旨を明記してください」と指示する

D) 最大トークン数を制限する

正解: C

情報源を限定し、不確実な場合の振る舞いを明示的に指示することが最も効果的です。A の抽象的な注意は効果が薄く、B の temperature は創造性の制御であってハルシネーション防止には直結しません。D はレスポンスの長さの制限であり、正確性とは無関係です。

▶

Q4. プロンプト評価(Eval)で、要約タスクの品質を評価する最適な採点方法は？

A) 出力の文字数が指定範囲内かチェックする

B) キーワードの完全一致で正解を判定する

C) LLM を採点者として使い、ルーブリックに基づいてスコアリングする (モデルベース採点)

D) 出力がJSON形式かバリデーションする

正解: C

要約タスクは「正解」が一意に定まらないため、コードベースの機械的な判定(A, B, D)では品質を適切に評価できません。モデルベース採点では、評価基準(ルーブリック)を定義し、別のLLMに多角的に判定させることで、人間の評価に近い採点が可能です。

▶

Q5. Chain-of-Thought (段階的思考) の使用が最も効果的なのはどのタスクか？

A) テキストの感情分類 (positive/negative/neutral)

B) 複数の条件を考慮した法的文書の分析

C) 定型フォーマットへのデータ変換

D) 単語の翻訳

正解: B

Chain-of-Thought は複数のステップにわたる推論が必要なタスクで最も効果を発揮します。法的文書の分析では、各条項の関連性を段階的に検討する必要があり、中間ステップを明示させることで論理的な一貫性が保たれます。A, C, D は比較的単純なタスクであり、段階的思考のメリットは限定的です。

▶

Q6. プリフィル (Prefilling) について正しい説明はどれか？

A) system prompt の先頭にキーワードを置くテクニック

B) user メッセージの末尾にヒントを追加する方法

C) assistant ロールのメッセージに冒頭テキストを設定し、Claude にその続きから生成させる方法

D) Few-shot の例をキャッシュに保持する機能

正解: C

プリフィルは assistant ロールのメッセージの冒頭に文字列を設定するテクニックです。例えば {"role": "assistant", "content": "{"} と設定すると、Claude はJSONオブジェクトの続きとしてレスポンスを生成します。出力フォーマットの制御や、特定の形式での回答開始を強制するのに有効です。

▶

Q7. 感情分類タスクの temperature 設定として最適なのは？

A) temperature = 1.0 (最大の多様性)

B) temperature = 0.7 (適度な変化)

C) temperature = 0.0 (決定論的)

D) temperature は分類精度に影響しない

正解: C

分類タスクでは同じ入力に対して毎回同じ結果を返すべきであり、ランダム性は不要です。temperature = 0.0 にすることで、最も確率の高いトークンが常に選択され、一貫した分類結果が得られます。

Prompt Engineering& Structured Output

プロンプトの基本構造

2つの入力チャネル

プロンプトの構成要素チェックリスト

明確で具体的な指示

曖昧 vs 具体的な指示

プリフィル (Prefilling): Claude の出力を誘導する

出力フォーマットの指定

XMLタグによる構造化

なぜXMLタグなのか

よく使われるXMLタグパターン

出力にXMLタグを使わせる

ロールプロンプティング

ロール設定の効果

Few-shot学習 (例の活用)

Few-shot の実装パターン

Messages API による Few-shot

Chain-of-Thought (段階的思考)

基本的な使い方

Extended Thinking (拡張思考モード)

ハルシネーションの防止

ハルシネーション防止の3つの戦略

構造化出力 (JSON Schema)

手法1: tool_choice によるJSON出力の強制

手法2: プリフィルによるJSON出力

バリデーションとエラー処理

プロンプト評価 (Evals)

評価ワークフロー全体像

採点手法の比較

promptfoo によるEval自動化

実践: 複雑なプロンプト構築

ケース1: 医療情報アシスタント

ケース2: 通話要約システム

ケース3: カスタマーサポートBot

プロンプトチェーニング

Temperature とモデル動作の制御

Temperature パラメータ

レスポンスストリーミング

system prompt のベストプラクティス

確認テスト

Prompt Engineering
& Structured Output