CCA試験対策 D4完全解説 — プロンプトエンジニアリングと構造化出力の設計パターン

加えて、「保守的にレビューしてください」。このひとことをシステムプロンプトに書き加え、偽陽性が減ることを祈る。だが結果は変わらない。コードレビューツールは依然として変数名の好みにフラグを立て、開発者はレビュー結果を丸ごと無視するようになる。CCA試験 プロンプトエンジニアリング 構造化出力を正しく理解していれば、この失敗パターンは最初から回避できた。

さらに、前回の「CCA試験対策 D3完全解説 — Claude Code設定とワークフロー」では、CLAUDE.mdの階層構造やカスタムスラッシュコマンドなど、Claude Codeの設定とワークフロー最適化を扱った。本記事ではDomain 4に移り、プロンプト設計の具体的な技法から構造化出力、バッチ処理、マルチインスタンスレビューまでを網羅する。配点は全体の20%。実装寄りの設計判断が問われるドメインだ。

また、次回の「CCA試験対策 D5完全解説 — コンテキスト管理と信頼性」では、長期インタラクションでのコンテキスト保持とエラー伝播の管理を扱う。

曖昧な指示が機能しない理由 — T4.1: 明示的基準で精度向上

例えば、CCA試験 プロンプトエンジニアリング 構造化出力のドメインで最初に押さえるべきは、曖昧な指示と明示的基準の違いだ。

したがって、「be conservative」「慎重にレビューしてください」といった抽象的な指示は、モデルの精度を改善しない。モデルには「保守的」の定義が存在しないからだ。何を報告し何を無視すべきか、判断基準が一義的でなければ解釈がばらつく。

具体的には、明示的基準は、報告対象とスキップ対象を具体的に分離する。

あなたはコードレビューアシスタントです。以下の基準に従ってレビューしてください。

【報告対象（必ずフラグする）】
- セキュリティ脆弱性（SQLインジェクション、XSS、認証バイパス）
- 本番環境でクラッシュを引き起こす可能性のあるバグ
- データ損失のリスクがあるロジックエラー

【無視（フラグしない）】
- 変数名やフォーマットの好み
- コメントの追加・削除の提案
- 既存コードベースで一貫して使われているパターン

【判断に迷う場合】
- confidence フィールドを "medium" にし、理由を付記する

偽陽性が信頼を破壊するメカニズム

一方、偽陽性率が高いカテゴリが存在すると、開発者はレビュー結果「全体」を無視するようになる。重要な指摘も軽微な指摘もまとめて捨てられる。対策は3段階だ。

1. さらに、一時的に無効化: 偽陽性率の高いカテゴリを一時的にオフにする
2. また、プロンプト改善: そのカテゴリの判断基準をより明示的に書き直す
3. 具体的には、再有効化: 改善後に再度有効にし、偽陽性率を監視する

同様に、試験では「FCR（初回解決率）が55%で単純なケースまでエスカレーションされている」というシナリオが頻出する。解決策は明示的なエスカレーション基準の定義とFew-shotの組み合わせだ。

パターンで教える — T4.2: Few-shotプロンプティング

とりわけ、詳細な指示だけでは出力フォーマットの一貫性が出ない場合、Few-shotが最も効果的な手法となる。推奨する例の数は2〜4個。15個も入れればノイズになり逆効果だ。

Few-shot設計の4原則

Messages APIでのFew-shot実装

messages = [
    {
        "role": "user",
        "content": "以下の文書からデータを抽出してください: [請求書A - 標準フォーマット]"
    },
    {
        "role": "assistant",
        "content": '{"vendor": "ABC Corp", "total": 15000, "currency": "JPY", "confidence": "high"}'
    },
    {
        "role": "user",
        "content": "以下の文書からデータを抽出してください: [請求書B - 手書きスキャン、一部不鮮明]"
    },
    {
        "role": "assistant",
        "content": '{"vendor": "XYZ Ltd", "total": null, "currency": "USD", "confidence": "low", "note": "金額欄が不鮮明で読み取り不可"}'
    },
    {
        "role": "user",
        "content": "以下の文書からデータを抽出してください: [実際の処理対象文書]"
    }
]

結論として、2番目の例が決定的に重要だ。「読み取れない場合はnullにし、noteで理由を説明する」パターンを明示的に見せている。これにより、モデルが値を捏造するリスクを構造的に低減できる。Few-shotで「不明な場合はnull」パターンを示すことは、ハルシネーション削減の実践的手法として試験で問われる。

重要なポイント

JSON構文エラーを構造的に排除する — T4.3: tool_use + JSON Schema

さらに、CCA試験 プロンプトエンジニアリング 構造化出力の中核トピックが、tool_useとJSON Schemaの組み合わせだ。

手法比較: なぜtool_useが最強か

また、ここで試験に頻出する重要な区別がある。tool_use + JSON Schemaのstrict modeは「構文エラー」を排除するが、「セマンティックエラー（意味的な誤り）」は防げない。金額フィールドに型としては正しいnumberが入るが、値自体が間違っているケースは、スキーマでは捕捉できない。

tool_choiceの3モード

特に、"any"がテキスト応答を排除し、ツール呼び出しを保証する点は試験で必ず問われる。

スキーマ設計のベストプラクティス

つまり、nullable フィールドで捏造防止: "type": ["number", "null"]とすることで「不明ならnull」を許容し、値の捏造（ハルシネーション）を構造的に防止する。

例えば、enum + “other” + 詳細フィールド: 既知の選択肢をenumで定義し、想定外の値には"other"を用意。"other"選択時に詳細を記述するstringフィールドを併設する。

しかし、“unclear” enumで不確実性を表現: confidenceに"unclear"を含めることで、判断困難なケースを適切に処理する。

重要なポイント

tools = [{
    "name": "extract_invoice",
    "description": "請求書から構造化データを抽出する",
    "input_schema": {
        "type": "object",
        "properties": {
            "vendor_name": {"type": "string"},
            "total_amount": {"type": "number"},
            "currency": {
                "type": "string",
                "enum": ["USD", "EUR", "JPY", "other"]
            },
            "currency_detail": {
                "type": "string",
                "description": "currency が 'other' の場合に通貨コードを記載"
            },
            "line_items": {
                "type": "array",
                "items": {
                    "type": "object",
                    "properties": {
                        "description": {"type": "string"},
                        "amount": {"type": ["number", "null"]},
                        "confidence": {
                            "type": "string",
                            "enum": ["high", "medium", "low", "unclear"]
                        }
                    }
                }
            }
        },
        "required": ["vendor_name", "total_amount", "currency"]
    }
}]

response = client.messages.create(
    model="claude-sonnet-4-6",
    tools=tools,
    tool_choice={"type": "any"},
    messages=[{"role": "user", "content": f"請求書データを抽出:\n{document}"}]
)

したがって、requiredに含まれないフィールドは情報が欠落しうるため、nullableかoptionalにする。必ず存在するフィールドのみをrequiredに含めるのが設計原則だ。

失敗をフィードバックに変える — T4.4: バリデーション・リトライループ

retry-with-error-feedbackパターン

つまり、バリデーションエラーをプロンプトに追記して再試行する。フォーマット不整合や抽出漏れなど、モデルが修正可能なエラーに有効なパターンだ。

max_retries = 3
messages = [{"role": "user", "content": f"請求書データを抽出:\n{document}"}]

for attempt in range(max_retries):
    response = client.messages.create(
        model="claude-sonnet-4-6",
        tools=tools,
        tool_choice={"type": "any"},
        messages=messages
    )
    result = parse_tool_response(response)
    errors = validate(result)

    if not errors:
        break

    messages.append({
        "role": "assistant",
        "content": response.content
    })
    messages.append({
        "role": "user",
        "content": f"以下のバリデーションエラーが検出されました:\n{errors}\n修正して再抽出してください。"
    })

重要なポイント

リトライが有効なケース vs 無効なケース

特に、3回リトライしても同じエラーが出る場合、最も可能性が高い原因は「ソースドキュメントに該当情報が存在しない」ことだ。リトライ回数の問題ではない。

セマンティック・バリデーション

加えて、構文的に正しいJSONでも、意味的に誤っている場合がある。calculated_total（明細合計）とstated_total（記載合計）が不一致の場合、どちらかを自動選択するのではなく、不一致をフラグし両方の値を保持して人間のレビューに回すのが正しい対応だ。

同様に、フィードバックループでは、detected_patternフィールドを設けて体系的にリジェクト理由を蓄積する。頻出するリジェクトパターンからプロンプトやスキーマの改善点を特定できる。

50%コスト削減の条件 — T4.5: バッチ処理戦略

Message Batches APIの特徴

バッチ適否の判断基準

具体的には、試験で頻出するのは「2つのワークロードのうちどちらをバッチ化すべきか」というシナリオだ。判断基準は「開発者やユーザーをブロックするか否か」に尽きる。

バッチAPIのコード例

batch = client.messages.batches.create(
    requests=[
        {
            "custom_id": f"doc-{i}",
            "params": {
                "model": "claude-sonnet-4-6",
                "max_tokens": 1024,
                "messages": [
                    {"role": "user", "content": f"以下の文書を分析:\n{doc}"}
                ]
            }
        }
        for i, doc in enumerate(documents)
    ]
)

result = client.messages.batches.retrieve(batch.id)
print(result.processing_status)  # "in_progress" / "ended"

結論として、custom_idが不可欠な理由は、バッチ処理では応答順序が保証されないためだ。リクエストとレスポンスを正確に紐付けるには、各リクエストに一意の識別子を付与する必要がある。

重要なポイント

加えて、バッチAPIでマルチターンのツール呼び出しが必要な場合は、バッチAPIではなく通常のMessages APIを使用する。これは試験で直接問われるポイントだ。

自分を疑えないAIの限界 — T4.6: マルチインスタンスレビュー

セルフレビューの構造的限界

例えば、同一インスタンスでのセルフレビューには3つの構造的問題がある。

• 特に、先行推論コンテキスト: 自分の過去の推論がコンテキストに残っており、自分の判断を疑いにくい
• つまり、確証バイアス: 最初の分析結果を支持する方向に傾きやすい
• 例えば、見落としの再発: 最初に見落としたものは再レビューでも見落としやすい

したがって、先行推論コンテキストを持たない独立インスタンスは、先入観なく出力を評価でき、最初のインスタンスが見逃したエラーを検出できる。これがセルフレビューより独立インスタンスレビューが優れている根本的理由だ。

マルチパスレビュー戦略

とりわけ、Pass 1 — ファイルレベルのローカル分析: 各ファイルを独立して分析する。ファイル内のバグ、スタイル違反、セキュリティ問題を検出する。並列処理が可能だ。

一方、Pass 2 — クロスファイル統合パス: Pass 1の結果を集約し、ファイル間の依存関係やインターフェース不整合を検出する。API契約違反、型の不一致、インポート漏れを確認する。

一方、14ファイルのPRをシングルパスでレビューしてファイル間の依存関係エラーを見落とした場合、改善策は「ファイルレベルのローカル分析 + クロスファイル統合パスの2パスに分割」だ。

マルチインスタンスレビューのアーキテクチャ

同様に、オーケストレーターがレビュー結果を集約・判定する。Instance Aがファイル1〜5のローカル分析、Instance Bがファイル6〜14のローカル分析、Instance Cがクロスファイル統合分析を担当する。各インスタンスは独立したコンテキストで動作し、先行推論を持たない。ローカル分析は並列実行でスループットを向上させ、統合分析は全ローカル結果を入力として受け取る。

D4の落とし穴：よくある設計ミスと回避策

とりわけ、CCA試験 プロンプトエンジニアリング 構造化出力の領域では、「一見正しく見えるが実は不適切な設計」を見抜く力が問われる。ここでは、Domain 4で頻出する設計ミスとその回避策を整理する。

ミス1：Few-shotの例を大量に投入する

結論として、「例が多いほど精度が上がる」という直感は誤りだ。15個のFew-shot例を投入すると、コンテキストウィンドウを圧迫するだけでなく、例同士の微妙な矛盾がノイズとなり精度が低下する。推奨は2〜4個のターゲットを絞った例だ。重要なのは量ではなく、境界的なケース（曖昧な入力、欠損データ、エッジケース）を含めることだ。

ミス2：tool_use + JSON Schemaで「意味的な正しさ」も保証されると思い込む

tool_use + JSON SchemaのStrict modeはJSON構文エラーを排除する。しかし、フィールドに入る「値」の正しさは保証しない。金額フィールドに12800と入るか128000と入るかは、スキーマでは判定できない。

さらに、回避策はセマンティック・バリデーションを別途実装することだ。calculated_totalとstated_totalの不一致検出、日付の論理的整合性チェック（発行日 < 支払期限）、金額の妥当性範囲チェックなどをバリデーション層で行う。

ミス3：リトライすれば必ず改善されると考える

また、リトライが有効なのは「モデルが修正可能なエラー」に限定される。ソースドキュメントに該当情報が存在しない場合、何回リトライしても情報は現れない。むしろリトライを繰り返すとハルシネーションのリスクが増大する。3回リトライしても同じエラーが出たら、ソースデータの問題を疑うべきだ。

ミス4：セルフレビューで品質を担保しようとする

つまり、コード生成と同一セッションでのレビューは、先行推論コンテキストによるバイアスが働く。自分が書いたコードの問題点を、同じ思考の流れの中で発見するのは構造的に困難だ。

特に、回避策は独立インスタンスでのレビューだ。CI/CDパイプラインでClaude Codeを独立インスタンスとして起動し、生成セッションとは分離されたコンテキストでレビューを実行する。

ミス5：バッチAPIをリアルタイム処理に使う

具体的には、Message Batches APIの50%コスト削減は魅力的だが、レイテンシSLAがないため最大24時間かかる可能性がある。PRマージ前のコードレビューやリアルタイムチャット応答にバッチAPIを使うと、開発者やユーザーがブロックされる。

加えて、判断基準は「誰かがブロックされるか」だ。夜間レポートや週次監査のように、結果を待つ人がいない処理にのみバッチAPIを適用する。

ミス6：曖昧な指示を「temperature調整」で解決しようとする

例えば、「出力がばらつく」問題に対して、temperatureを下げることは根本的な解決策にならない。temperatureはランダム性を制御するパラメータであり、判断基準の曖昧さを解消するものではない。CCA試験の選択肢に「temperatureを下げる」「temperatureを0にする」が含まれている場合、ほぼ確実に不正解の選択肢だ。

正しい対処は、明示的基準（報告対象とスキップ対象の分離）の追加、またはFew-shot例によるフォーマットの明示だ。

設計ミスの回避チェックリスト

CCA試験対策: Domain 4 模擬問題

したがって、CCA試験 プロンプトエンジニアリング 構造化出力の理解度を確認するための模擬問題を掲載する。

まず、Q1: コードレビューツールの偽陽性率が40%に達している。最も効果的な最初のステップは?
A) モデルをfine-tuneする
B) 偽陽性率の高いカテゴリを特定し、明示的基準を追加する
C) temperatureを下げる
D) 出力トークン数を制限する
正解: B — 明示的基準の追加が最も直接的かつコスト効率の高い改善策。

最終的に、Q2: 詳細なプロンプト指示を書いたが、出力フォーマットがリクエストごとにばらつく。最も効果的な改善策は?
A) systemプロンプトを長くする
B) Few-shot例を2〜3個追加する
C) temperatureを0にする
D) max_tokensを増やす
正解: B — フォーマットの一貫性にはFew-shotが最も効果的。

重要なポイント

さらに、Q3: 構造化出力でJSON構文エラーを完全に排除したい。最も適切な手法は?
A) プロンプトでJSONフォーマットを指示
B) tool_use + JSON Schema
C) 出力を正規表現でパース
D) Few-shotでJSON例を示す
正解: B — tool_use + JSON Schemaのみが構文エラーを構造的に排除できる。

また、Q4: tool_choiceを"any"に設定する主な理由は?
A) コスト削減
B) レスポンス速度向上
C) 必ず構造化出力を得るため
D) エラーハンドリングの簡略化
正解: C — "any"はテキスト応答を排除し、ツール呼び出しを保証する。

具体的には、Q5: リトライを3回繰り返しても同じエラーが発生する。原因として最も可能性が高いのは?
A) リトライ回数が不足
B) ソースドキュメントに該当情報が存在しない
C) APIレート制限
D) モデルバージョンの問題
正解: B — 情報がソースに存在しなければリトライは無効。

特に、Q6: Message Batches APIの最大の利点は?
A) 低レイテンシ
B) 50%コスト削減
C) マルチターン対応
D) リアルタイムストリーミング
正解: B — 50%のコスト削減が最大の利点。レイテンシSLAはない。

つまり、Q7: セルフレビューが独立インスタンスレビューより劣る主な理由は?
A) 計算コストが高い
B) 先行推論コンテキストが残り自分の判断を疑いにくい
C) API制限
D) モデルの能力不足
正解: B — 先行推論コンテキストがバイアスの原因。

Domain 4 総合チェックリスト — 試験前の最終確認

一方、試験当日にDomain 4の全範囲をカバーしているか、最終確認用のチェックリストを掲載する。

• しかし、曖昧な指示 vs 明示的基準の違いを説明できるか
• したがって、偽陽性が開発者信頼を損なうメカニズムを理解しているか
• 加えて、Few-shotが最も効果的な状況を判断できるか（フォーマット一貫性、曖昧ケース処理）
• 同様に、Few-shotの推奨例数（2〜4個）と設計原則を把握しているか
• さらに、tool_use + JSON Schemaが構文エラーを排除する仕組みを説明できるか
• また、tool_choiceの3モード（auto / any / forced）を使い分けられるか
• 具体的には、nullableフィールド、enum + “other”、”unclear”の設計意図を説明できるか
• 特に、リトライが有効なケースと無効なケースを判別できるか
• つまり、セマンティック・バリデーション（自己整合性チェック）を設計できるか
• 例えば、Message Batches APIの特徴（50%割引、24時間、レイテンシSLAなし）を把握しているか
• しかし、バッチ適否の判断基準（ブロッキング vs 非ブロッキング）を適用できるか
• したがって、セルフレビューの限界と独立インスタンスの優位性を説明できるか
• 加えて、マルチパス（ローカル + 統合）レビュー戦略を設計できるか

重要なポイント

まとめ — 設計判断の引き出しを増やす

同様に、Domain 4の本質は「正しい設計判断を選べるか」にある。曖昧な指示ではなく明示的基準、テキスト出力ではなくtool_use + JSON Schema、セルフレビューではなく独立インスタンス。試験は常に「最も効果的な手法の選択」を問う。

例えば、出題パターンを整理すると、5つの型に集約される。

1. 同様に、「最も効果的な改善策は?」型: 曖昧指示→明示的基準、フォーマット不安定→Few-shot
2. さらに、「適切なAPI/手法の選択」型: リアルタイム→Messages API、バッチ処理→Batches API
3. また、「なぜ機能しないか?」型: セルフレビューの限界、リトライの無効ケース
4. 具体的には、「設計判断」型: tool_choiceモード選択、スキーマのnullable設計
5. 特に、シナリオベース型: 複数ワークロードのバッチ化判断、PRレビューの分割方法

とりわけ、CCA試験 プロンプトエンジニアリング 構造化出力は、理論だけでなく実装レベルの判断力が問われる。コード例とスキーマ設計パターンを手元で動かし、各手法の挙動を体感することが合格への最短経路だ。

さらに詳しい情報はAnthropic Prompt Engineering Guideでご覧いただけます。

重要なポイント

さらに深く学ぶために: 本記事はCCA試験の設計判断パターンを概説したものです。合格に向けた実践的な準備には、Anthropic Academy公式コースでのハンズオン学習と、模擬問題サイトでの演習を併せて実施してください。本シリーズの完全ガイド（Day 1）で推奨する「3本柱」の学習戦略も参照してください。

swiftwand

X

AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。 初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI. Practical tips that anyone can start using right away.