明示的基準プロンプト設計

明示的基準プロンプト設計は、Claude Certified Architect — Foundations（CCA-F）試験のDomain 4の機械的な核心だ。タスクステートメント4.1——「精度を向上させ偽陽性を削減するために明示的基準でプロンプトを設計する」——は20%の配点を持ち、構造化データ抽出シナリオの質問の不均衡に大きな割合を提供するドメインのアンカーだ。試験ガイドは要求を明確に述べている。「不審な取引にフラグを立てる」という曖昧な指示を「金額が$10,000を超え、かつ加盟店の国と請求先の国が異なり、かつそのアカウントが過去90日間その国での取引実績がない場合にフラグを立てる」という強制可能な基準ブロックに書き直せる受験者が合格する。プロンプティングを仕様ではなく散文として扱う受験者は、試験当日にこのタスクステートメントで失点する傾向がある。

この学習ノートでは、CCA-F受験者が習得しなければならない明示的基準設計の全表面を解説する。なぜ特異性が幻覚を減らすか、条件-閾値-アクションの三項構造、肯定的対否定的基準、数値閾値と定性的形容詞、エッジケースの列挙、分類境界ルール、締め付けが生み出す精度対リコールのトレードオフ、ラベル付きエッジセットに対する基準テスト、バージョン管理の規律、フィールドレベルの抽出ルール。よくある罠のセクションとFAQが、このタスクステートメントで試験が最も積極的に引用する構造化データ抽出シナリオにすべての抽象的な原則を結びつけてループを閉じる。

明示的基準が重要な理由——特異性が幻覚を減らす

大規模言語モデルはパターン補完機だ。プロンプトが「不審な取引にフラグを立てる」と言うとき、Claudeは事前学習の分布——銀行詐欺の教科書からアネクドートのフォーラム投稿、映画のプロットまですべてを含む——から「不審」の意味を推論しなければならない。明示的な基準がなければ、モデルはその空白を平均化された予測不可能な定義で埋め、同じプロンプトの2回の実行が互換性のない結果を生み出す可能性がある。

明示的基準はその推論の表面を折りたたむ。プロンプトが「金額が$10,000を超え、かつ加盟店の国が請求先の国と異なる場合にフラグを立てる」と言うとき、Claudeが発明すべきものは何も残らない。プロンプトは人間、ルールエンジン、またはモデルのいずれかの適合する実装が決定論的に実行できる仕様になった。基準がマッチの表面を狭めるため精度が上がり、以前はゆるい意味的重複でこっそり通り抜けていたエッジケースが明示的に除外されるため偽陽性が下がる。

CCA-F試験は常に4つの選択肢の中で最も引き締まった最も仕様のような基準に報酬を与える。「取引のコンテキストを考慮し、不審なアイテムにフラグを立てるために判断を使う」と読める選択肢の誤りは洗練されて聞こえるかもしれないが、「金額が$10,000を超え、かつ加盟店の国が請求先の国と異なり、かつアカウントがその国での取引実績を過去90日間持たない場合にフラグを立てる」に確実に負ける。明示的基準はほぼ常に試験が両方を提供するときにモデルの判断を上回る。

曖昧な指示は曖昧さの予算を作る

プロンプト内のすべての曖昧な言葉——「関連する」「合理的な」「重要な」「高品質な」——はClaudeが学習の事前確率に向かってドリフトすることで使う曖昧さの予算を作る。プロンプト内の曖昧なトークンが少ないほど、ドリフトが少ない。CCA-Fの構造化データ抽出シナリオでは、「重要な発見」を「信頼度スコアが≥0.85かつ深刻度が{high, critical}にある発見」として定義するプロンプトは、「重要な」という言葉だけに依拠するプロンプトを精度とランツーランの安定性の両面で上回る。

基準の解剖学——条件-閾値-アクションの三項

すべての適切に形成された明示的基準は3つの部分に分解される。この三項構造を内面化することは、CCA-F受験者がDomain 4に対して行えるレバレッジの最も高い一手だ。

1. 条件 — ルールがテストする入力の観察可能な特徴。例：transaction.amount、document.length、message.sender_domain、address.country_code。
2. 閾値 — 条件が比較される数値の境界、列挙されたセット、またはパターン。例：> 10000、in {US, CA, GB}、matches /^\d{3}-\d{2}-\d{4}$/。
3. アクション — 条件が閾値を満たしたときに基準が発動する決定。例：set flag = true、add to review queue、skip extraction、return confidence = low。

3つの部分のいずれかが欠けている基準は、未指定だ。「不審な取引にフラグを立てる」はアクション（フラグを立てる）はあるが条件も閾値もない。「金額>$10,000」は条件と閾値はあるがアクションがない。「不審なら、フラグを立てる」は条件とアクションはあるが閾値がない——そして「不審な」は観察可能ではない。

三項形式で基準を書く

CCA-F対応の基準ブロックに推奨されるプロンプトの形状は以下のとおりだ。

<criteria>
  <rule id="R1">
    Condition: transaction.amount
    Threshold: > 10000 USD
    Action: add "high-value" flag
  </rule>
  <rule id="R2">
    Condition: merchant_country != billing_country
    Threshold: equality test
    Action: add "cross-border" flag
  </rule>
  <rule id="R3">
    Condition: account.prior_transactions_in(merchant_country, 90 days)
    Threshold: == 0
    Action: add "novel-geography" flag
  </rule>
  <rule id="COMBINED">
    Condition: count(flags) >= 2
    Threshold: >= 2
    Action: route to fraud review; otherwise pass through
  </rule>
</criteria>

この形状は三項構造とClaudeに推奨されるXML構造化プロンプトに1対1でマップされる。明示的な <rule id="..."> の足場は試験に適している——散文から三項形式への書き直しを提示するシナリオ問題は一貫して三項形式を正解とする。

肯定的基準と否定的基準——すること「と」しないことを指定する

微妙だが高頻度の試験パターン：明示的基準はすべての境界の両側をカバーしなければならない。フラグを立てることだけを述べることは、フラグを立てないことをClaudeが事前学習の事前確率から推論することを残す。無視することだけを述べることも反対側に同じギャップを残す。

肯定的基準——包含ルール

肯定的基準はターゲットのアクションを取る場合を記述する。マッチの表面を「Claudeが不審だと考えるもの」から「まさにこれらの列挙されたケース」に絞り込む。

否定的基準——除外ルール

否定的基準はマッチに見えるが除外しなければならないケースを記述する。それがなければ、Claudeのパターン補完の傾向が近似マッチを引き込む——最も重要なケースで偽陽性を膨らませる振る舞いだ。

肯定的基準と否定的基準の対

本番レベルの基準ブロックは各敏感な境界に対して包含と除外のルールを対にする。

<criteria>
  <include>
    Flag transactions where amount > 10000 USD AND merchant_country != billing_country.
  </include>
  <exclude>
    Do NOT flag transactions where the merchant is on the user's allowlist,
    regardless of amount or geography.
  </exclude>
  <exclude>
    Do NOT flag recurring subscription charges (same merchant, same amount,
    monthly cadence, at least 3 prior payments) even if amount > 10000 USD.
  </exclude>
</criteria>

明示的な包含と除外を対にすることは、構造化データ抽出シナリオ問題で使われる標準パターンだ。否定的基準を含むシナリオの答えは肯定的基準だけを列挙する答えを一貫して上回る。なぜなら否定的基準こそが実際に偽陽性を削減するからだ。

基準の定量化——定性的形容詞より数値閾値

数値閾値は決定論的だ。定性的形容詞は解釈的だ。形容詞を数値に置き換えるすべての機会は、プロンプトから曖昧さの予算を削除する機会だ。

避けるべき形容詞

以下の言葉はCCA-Fのプロンプト書き直し問題での危険信号だ。

• 「高い」 → 明示的な数値閾値に置き換える（例：> 0.85）。
• 「重要な」 → 測定可能な大きさに置き換える（例：change >= 10 %）。
• 「大きな」 → 単位に置き換える（例：document_length > 50000 characters）。
• 「最近の」 → 時間の境界に置き換える（例：within the last 7 days）。
• 「多くの」 → カウントに置き換える（例：>= 3 occurrences）。
• 「重要な」 → 列挙されたカテゴリーに置き換える（例：severity in {high, critical}）。
• 「不審な」 → 条件-閾値-アクションのルールに分解する。

数値が形容詞を上回る理由

数値はプロンプトの作者に現実と交渉することを強いる。「高い信頼度」は感情だ。「confidence_score >= 0.85」は評価指標に応じて調整できるテスト可能な境界だ。エンジニアが精度が低すぎることに気づいたとき、数値を0.90に動かして影響を測定できる。「高い」という言葉には同等の調整が存在しない。

形容詞が避けられない場合

一部の基準は数値削減に本当に抵抗する——「文書が形式的な文体で書かれている」「答えが本題から外れている」「トーンが非専門的だ」。これらに対して、正しいフォールバックは例による列挙だ。形容詞を固定する少数のラベル付き例を提供する。ここで明示的基準はfew-shot prompting（タスク4.2）と合流する。基準がルールを提供し、few-shotの例がどうしても定性的な部分の調整を提供する。

エッジケース仕様——曖昧な既知ケースをプロンプト内に列挙する

優れた基準ブロックでさえ、経験豊富なドメインエキスパートが発見するであろう境界ケースを見逃す。修正策は基準を広げることではなく——既知の曖昧なケースをプロンプト内に直接列挙することだ。

エッジケースがプロンプトに属する理由

Claudeは見たことのないエッジケースを推論できない。ドメインが合理的な人間が意見を異にする曖昧な入力を定期的に遭遇するなら——額の閾値を満たすが顧客が事前にフラグを立てた取引、存在するが空の抽出フィールド、ターゲットエンティティを含むが引用コンテキスト内の文書——曖昧さを解消する正しい場所は後処理コードではなくプロンプトだ。

エッジケース列挙パターン

<edge_cases>
  <case id="E1">
    If a transaction matches R1-R3 but the customer has a "travel notice"
    flag active for the merchant_country, DO NOT flag the transaction.
  </case>
  <case id="E2">
    If the extraction field is present in the document but the value is
    empty string, null, or whitespace-only, return { "value": null, "confidence": 0.0 }.
    Do NOT attempt to infer a value from surrounding context.
  </case>
  <case id="E3">
    If the target entity appears inside a quotation (surrounded by quote marks
    or cited as a source), extract it but mark attribution = "quoted".
  </case>
</edge_cases>

列挙されたエッジケースはCCA-Fのお気に入りだ。暗黙のドメイン知識を監査可能、テスト可能、バージョン管理可能な明示的な指示に変換するからだ。また、few-shotの例とも構成される——各エッジケースをルールを強化するラベル付き例と対にできる。

分類基準の設計——境界ケースに対する決定ルール

分類はCCA-Fのタスクの中で明示的基準から最も恩恵を受けるものだ。分類の決定は境界の決定だ。隣接するクラスの各ペアには、プロンプトが解消しなければならない境界がある。境界を暗黙のままにしておくと事前学習の事前確率に引き渡される。明示的にすると分類器が安定する。

単一クラス境界ルールパターン

バイナリ分類器には、2つのクラスを明確に区別する1つのルールが必要だ。曖昧なルール（「メッセージが時間的に敏感に見える場合はurgentに分類する」）は失敗する。明示的なルール（「次のいずれかの場合はurgentに分類する：メッセージに「今日中に」というフレーズが含まれる、メッセージがVIPアカウントから送られた、メッセージがアクティブな障害に言及している」）は成功する。

マルチクラス境界ルールパターン

N個のクラス分類器には、N-1個の境界ルールと優先順位が必要だ。優先順位がなければ、Claudeはプロンプトで最初や最後にリストされたクラスに入力を割り当てるかもしれない。明示的な優先順位がこれを解消する。

<classification>
  <rule priority="1">
    If message contains explicit outage language (down, broken, not working)
    OR sender is a VIP account, classify as CRITICAL.
  </rule>
  <rule priority="2">
    If message asks a question that references a specific feature or workflow
    AND no CRITICAL conditions match, classify as TECHNICAL.
  </rule>
  <rule priority="3">
    If message is a thank-you, feedback, or general comment
    AND no higher-priority rule matches, classify as FEEDBACK.
  </rule>
  <rule priority="4">
    Otherwise classify as OTHER.
  </rule>
</classification>

クラスの定義はプロンプトに属する

Claudeがあなたの正確なクラス定義を共有していると仮定しないこと。プロンプトには、基準と同じ言語で書かれた各クラスの1〜2文の定義を含めなければならない。分類器に5つのクラスがある場合、プロンプトには5つのクラス定義がある。組み合わせたコスト（数百トークン）は精度の向上と比べてわずかだ。

偽陽性削減——マッチ表面を絞り込むための基準の引き締め

偽陽性はCCA-Fの構造化データ抽出シナリオで最も引用される精度の失敗だ。それらをメカニカルに削減することは基準を引き締める仕事だ。4つのレバーが支配する。

レバー1：数値閾値を上げる

confidence_score > 0.70 を confidence_score > 0.85 に移動することは偽陽性率をメカニカルに削減する。コストはより低いリコールだ（0.70 ≤ スコア < 0.85の一部の真陽性が見逃される）。しかし偽陽性が高コストなワークフロー——詐欺レビューキュー、法的保留、コンプライアンスフラグ——では、そのトレードは通常価値がある。

レバー2：必須のAND条件を追加する

ANDで結合されたすべての肯定的基準はマッチ表面を絞り込む。「金額>$10,000」は正当な取引が多すぎる。「金額>$10,000 AND 加盟店の国≠請求先の国 AND 加盟店の国での取引実績なし」はより小さく、はるかに高精度のセットを捉える。

レバー3：否定（除外）基準を追加する

除外は正当な見た目の入力をマッチ表面から切り出す。正側をさらに制限することなく。「定期的なサブスクリプションにフラグを立てない」は、真の詐欺シグナルに影響を与えることなく偽陽性のクラス全体を除外する。

レバー4：証拠フィールドを要求する

マッチを引き起こした具体的な証拠を返すようClaudeに要求する——「マッチを示す正確なテキスト抜粋を含める」「ルールを満たしたフィールド名を含める」。証拠を要求することは、Claudeがフラグを捏造するよりも証拠を捏造しにくいため、幻覚によるマッチを削減する。

偽陰性のトレードオフ——基準が引き締まるときの精度対リコール

追加するすべての基準は偽陽性と真陽性の両方を削減する。これが精度対リコールのトレードオフであり、CCA-F試験では受験者がそれを認識するかどうかをテストする。

プロンプト設計のための精度対リコール——定義

• 精度 = プロンプトがフラグを立てたアイテムのうち、実際に正しいマッチである割合。高精度は偽陽性が少ないことを意味する。
• リコール = 実際に正しいマッチであるすべてのアイテムのうち、プロンプトがフラグを立てた割合。高リコールは偽陰性が少ないことを意味する。

すべてにフラグを立てるほど緩い基準を持つプロンプトは100%リコールで低精度だ。何にもフラグを立てないほど厳しい基準を持つプロンプトはリコールが未定義で偽陽性がゼロだ。これらの極端の間の動作点はビジネスの決定であり、モデルの決定ではない。

ドメインのコストが動作点を決定する

厳しい基準（高精度、低リコール）は偽陽性が高コストなとき——法的レビュー、詐欺キュー、セキュリティインシデント——に適切だ。緩い基準（高リコール、低精度）は偽陰性が高コストなとき——医療スクリーニング、安全クリティカルアラート、規制コンプライアンス——に適切だ。CCA-F試験では受験者がこのトレードオフをシナリオの答えで明示的に表現することを期待する。

評価を通じた調整

ラベル付きの評価セットなしに精度-リコールのトレードオフを調整することはできない。正しいワークフローは以下のとおりだ。

1. ラベル付きセットに対してプロンプトを実行する。
2. 現在の基準での精度とリコールを測定する。
3. 基準を調整する（引き締めるか緩める）。
4. 再実行して再測定する。
5. 動作点がビジネス要件に合致するまで繰り返す。

これはプロンプト設計（タスク4.1）から検証とリトライループ（タスク4.4）へのブリッジだ。明示的基準は調整するノブを提供し、ラベル付きの評価セットはどこまで調整するかを教える。

基準テスト——ラベル付きエッジケースセットに対するプロンプトの評価

明示的な基準ブロックはそれを調整する評価と同じくらいしか良くない。CCA-Fでは受験者がコード変更と同様にプロンプトの変更を扱うことを期待する。固定されたテストセットに対して測定し、明示的な合格/不合格の閾値を持つ。

最小限のラベル付きセット

基準ブロックの使用可能な評価セットは以下のとおりだ。

• 30〜100の肯定的ケース — 基準にマッチすべき入力。典型的な分布をカバーする。
• 30〜100の否定的ケース — マッチすべきでない入力。以前に偽陽性を生み出した見た目が似ているものを含む。
• 10〜30のエッジケース — プロンプトが明示的に対処する列挙された曖昧なケース。それぞれが期待される出力でラベル付けされている。

これは研究グレードの評価ではない。基準を引き締めるか緩めるときに回帰を捕まえるための最小限の実行可能なハーネスだ。

評価の実行

全ラベル付きセットに対してプロンプトを実行する。肯定/否定の分割で精度とリコールを計算する。エッジケースについては、完全一致の精度を計算する——プロンプトが各既知の曖昧なケースに対して期待される出力を生み出したか。

結果の読み方

• 精度が低すぎる場合、上記の4つのレバーを使って基準を引き締める。
• リコールが低すぎる場合、基準を緩めるか閾値を緩和する。
• エッジケースの精度が低い場合、列挙されたエッジケースのルールが適用されていない——表現を洗練させるか強化するfew-shotの例を追加する。

評価ループが設計ループだ

評価ループのない明示的基準は推測だ。ループは以下のとおりだ。基準を変更 → 評価を実行 → 精度/リコール/エッジケース精度を測定 → コミット、洗練、または元に戻すかを決定。これはソフトウェアエンジニアリングの単体テストと同じ規律であり、プロンプトに適用される。

基準バージョン管理——プロンプトの変更とその精度への影響を追跡する

基準ブロックはソースコードだ。変更履歴、コードレビュー、ロールバックパスとともにバージョン管理に属する。

バージョン管理すべきもの

• システムプロンプト、基準ブロック、エッジケース、few-shotの例を含むプロンプトテキスト全体。
• 評価セット（肯定、否定、エッジケース、ラベル付き）。
• コミットされた各バージョンでの測定済みの指標（精度、リコール、エッジケースの精度）。

変更ログの規律

すべての基準の変更には以下を記録するエントリを持つべきだ。

• 何が変更されたか（どのルール、どの閾値、どのエッジケース）。
• なぜ変更されたか（どの失敗例、どいステークスホルダーのリクエスト、どのビジネスルールの更新）。
• 評価セットでの前後の測定済みの精度/リコール。
• コミットハッシュまたは同等のバージョン識別子。

ロールバックは設計機能だ

偽陽性のクレームに応じて基準を引き締めることは、正当なケースのリコールを意図せず損なう可能性がある。バージョン管理なしでは元に戻せない。バージョン管理があれば、ロールバックは1つのコマンドだ。プロンプトバージョン管理に言及するCCA-Fシナリオの答えは一貫して、プロンプトを使い捨てのアーティファクトとして扱う答えを上回る。

抽出タスクの基準——構造化データのフィールドレベルルール

構造化データ抽出シナリオは、CCA-F試験で明示的基準が最も重い仕事をする場所だ。構造化抽出とは非構造化または半構造化された入力から名前付きフィールドを取り出し、スキーマに適合したオブジェクトを発行することを意味する。各フィールドには独自の基準ブロックが必要だ。

フィールドレベルの基準

抽出スキーマのすべてのフィールドについて、プロンプトは次を指定すべきだ。

• ソースルール — 入力のどこを探すか（例：「customer_nameはヘッダーブロックの「Customer:」に続く値だ」）。
• フォーマットルール — 値の期待される形状（例：「ISO 8601の日付文字列」「E.164の電話番号」「大文字の国コード」）。
• 存在ルール — フィールドが欠落しているときに何をするか（例：「nullを返す。周囲のコンテキストから推論しない」）。
• 曖昧さルール — 複数の候補値が存在するときに何をするか（例：「複数の顧客名が表示される場合、ヘッダーにあるものを選ぶ。ヘッダーがない場合、nullを返す」）。

強制レイヤーとしての厳格なtool use

明示的基準は正しい値を生成する。厳格なtool useは正しい形状を生成する。strict: true のツールスキーマとともに抽出をツール呼び出しとして定義することは、Claudeの出力がJSON Schemaに準拠することを保証する——欠落フィールド、間違った型、余分なキーはすべて不可能になる。基準ブロックはコンテンツを管理し、厳格なスキーマは構造を管理する。これらの2つのレイヤーは構成される——代替ではない。

証拠リンク付きフィールド

監査に敏感な抽出には、各フィールドに値を正当化したソーステキスト抜粋を含めることを要求する。これは基準に追加するのが安い（「各抽出フィールドについて、値を正当化する入力からの逐語的なテキストを含む source_excerpt を含める」）そして幻覚による抽出を劇的に削減する。試験はこのパターンを構造化データ抽出のベストプラクティスとして認識する。

基準とfew-shotの例がどう構成されるか

明示的基準とfew-shotの例は補完的であり、競合しない。試験は受験者がこれを知っているかどうかを一貫してテストする。

基準がルールを定義し、例がルールを調整する

基準は決定ルールを散文または構造化された形式で表現する。例は微妙なエッジケースを明確にする具体的なインスタンスでルールを根拠づける。基準があり例がゼロのプロンプトはルールの文字通りを実行する傾向があるが精神を見逃す。例があり基準がないプロンプトは例をオーバーフィットする傾向があり、例のセットと異なる入力で誤動作する。

基準に例を追加する場合

few-shotの例を追加するのは次の場合だ。

• 基準にどうしても定性的な要素（トーン、文体、専門性）が含まれる場合。
• エッジケースのルールに、視覚的な強化から恩恵を受ける非自明な正しい出力がある場合。
• 出力フォーマットが散文よりも文字通りのインスタンスがより良く示すほど複雑な場合。

推奨される組み合わせ形状

<instructions>
  [task description]
</instructions>
<criteria>
  [explicit rules as triplets]
</criteria>
<edge_cases>
  [enumerated ambiguous cases with rules]
</edge_cases>
<examples>
  [3-5 input/output pairs that exercise criteria and edge cases]
</examples>
<input>
  [the actual input to process]
</input>

この順序はAnthropicの公開された推奨事項に一致する。基準とエッジケースがロジックを確立し、例がロジックを根拠づけ、入力が最後に来るので最新のコンテキストがアテンションで最も新鮮だ。

XMLタグはオプションではない

ClaudeはプロンプトのXMLタグを解析するように訓練されている。<criteria>、<edge_cases>、<examples>、<input> を明示的なセクションとして使用することで、非構造化散文と比較して基準の遵守が劇的に向上する。試験は一貫してXMLタグ付きプロンプトを同一コンテンツの散文プロンプトより正解としてマークする。

やさしい解説: 抽象的な基準の仕組みは、ほとんどの受験者がすでに知っている物理的なシステムに固定することで直感的になる。3つの全く異なる類比が明示的基準設計の全範囲をカバーする。

類比1：衛生検査官のチェックリスト——三項としての基準

レストランの厨房に入る食品衛生検査官を想像してほしい。曖昧な検査官は「不衛生なものすべてにフラグを立てる」と言いながら歩き回る。2人の検査官は何が不衛生かについて常に意見が合わず、同じ検査官が別の日に異なる結論に達する。プロの検査官はチェックリストを持っている。「調理された肉の表面温度が60°C以下の場合にフラグを立てる」（条件＋閾値＋アクション）。「生の鶏肉がすぐに食べられる食品の上に保存されている場合にフラグを立てる」（条件＋閾値＋アクション）。「拭き取れるステンレスの軽微な水滴にはフラグを立てない」（否定的基準）。チェックリストは検査を解釈的な芸術から再現可能な手順に変える。同じチェックリストを持つ2人の検査官は同じレポートを生み出す。明示的基準はチェックリストが検査官に対してすることをClaudeに対してする。解釈的な判断を観察可能なルールに置き換えるため、精度が向上しランツーランの分散が下がる。CCA-F試験は曖昧な指示のチェックリストバージョンを書ける受験者に報酬を与える。

類比2：空港のセキュリティスクリーニングライン——精度、リコール、トレードオフ

空港のセキュリティは生きた精度対リコールの実験だ。緩いスクリーニングポリシーは全員を素早く通過させる（非脅威に対して高いリコール、偽陽性ゼロだが、本物の脅威が抜けてしまう——脅威検出での低精度）。厳しいポリシーはすべての乗客を精査する（脅威に対して高精度だが、多くの無実の旅行者がフラグを立てられる——非脅威の素早い通過での低リコール）。セキュリティのリーダーシップは各エラータイプのコストに基づいて動作点を選ばなければならない。見逃した脅威のコスト対誤警報のコスト。そのポリシーは明示的基準として動作点を表現する。「次のいずれかに該当する場合、乗客を二次スクリーニングに送る——液体>100ml、金属>Xグラム、ランダム選択、またはウォッチリスト上。」これらが条件-閾値-アクションの三項だ。新しい脅威が浮上すると基準が引き締まる（閾値を下げ、新しい条件を追加）。長い行列への不満が急増すると基準が緩む。ClaudeのプロンプトエンジニアもCCA-F受験者も同じ経済に直面する。基準を引き締めると、偽陽性がリコールを犠牲にして削減される。基準を緩めると、偽陽性を犠牲にしてリコールが増加する。CCA-F試験は、引き締めを無条件の勝利として扱うのではなく、トレードオフを明確に表現する受験者を求める。

類比3：薬剤師の処方チェック——エッジケースと除外ルール

薬剤師が処方を受け取り、調剤するかどうかを決定しなければならない。肯定的基準：「処方には有効な署名がある、患者IDが一致する、薬が在庫にある、投与量がガイドライン内だ」。否定的基準：「患者が禁忌の薬を服用している場合は調剤しない。投与量が体重調整した最大値を超えている場合は調剤しない。保険がクレームを拒否する場合は調剤しない」。薬剤師がこれまでに見たエッジケース：「処方された投与量が通常でないが、処方者がこの状態の既知の専門家である場合、完全に拒否するのではなく処方者に電話して確認してから調剤する」。これらはそれぞれプロンプトパターンにマップされる。肯定的基準は包含ルールだ。否定的基準は除外ルールだ。エッジケースは明示的な解決策を持つ列挙されたルールだ。これらのルールを書き留めてそれに従う薬剤師は、書かれたルールが監査可能で新しいスタッフに教えられ新しい安全情報が届いたときに更新可能であるため、経験だけに依存する薬剤師よりミスが少ない。明示的基準を持つプロンプトは同じように振る舞う——特定のルールに遡ることができる、監査準備が整った精度に最適化された出力を生み出す。

どの類比がどの試験問題に当てはまるか

• 基準の構造に関する質問 → 衛生検査官のチェックリストの類比。
• 基準の引き締めとトレードオフに関する質問 → 空港のセキュリティの類比。
• エッジケースと除外に関する質問 → 薬剤師の類比。

よくある試験の罠

CCA-F Domain 4は明示的基準設計に関して5つの繰り返しの罠のパターンを一貫して悪用する。すべて構造化データ抽出シナリオの尤もらしい選択肢の誤りとして偽装されている。

罠1：「基準が多ければ多いほど良い」

過剰な仕様は脆弱性を引き起こす。40個の基準を持つプロンプトは4個の基準を持つプロンプトをトレーニングの例でフラグを立て上回るが、40個の予想された形状のいずれにも一致しない入力で壊滅的に誤動作する。CCA-F試験は、シナリオがトレーニング分布からドリフトした入力を含む場合に「ルールを追加する」を誤った答えとして一貫してマークする。正しい答えはしばしば基準を引き締まっているが小さく保ち、few-shotの例でロングテールをカバーすることだ。

罠2：明示的基準がfew-shotの例を置き換える

そうではない。基準と例は補完的だ。few-shotの例をより多くの基準に置き換えたプロンプトは、定性的な用語を固定する例に根拠づけられた調整を失う。基準をより多くのfew-shotの例に置き換えたプロンプトは、新しい入力を予測可能にするルールベースの決定論を失う。CCA-Fシナリオの答えで基準と例の両方を明示的に保持するものは、一方を優先する答えを一貫して上回る。

罠3：基準に偽装した曖昧な形容詞

「高い信頼度」は基準ではない。「重要な影響」は基準ではない。「不審な振る舞い」は基準ではない。シナリオの選択肢の誤りはしばしば基準のような構文に曖昧な形容詞を包む——<rule>flag anything significant</rule>——そしてこれを「明示的基準」のオプションとして提供する。そうではない。正しい答えは形容詞を数値閾値または列挙されたカテゴリーに置き換える。

罠4：除外なしの肯定的基準のみ

「偽陽性を削減する」という目標を持つシナリオ問題はしばしば、肯定的基準を引き締めるが除外ルールを追加しない選択肢を提供する。この選択肢は限界まで精度を向上させるが、既知の見た目が似ているものの明示的な除外ルールと同じ肯定的基準を対にした選択肢に負ける。CCA-Fでは、述べられた目標が偽陽性削減のときに除外が対になった答えがほぼ常に勝つ。

罠5：評価またはバージョン管理なしの基準変更

「基準を引き締めた後に次に何をするか」を尋ねるシナリオ問題はしばしば「即座にデプロイする」を選択肢の誤りとして提供する。正しい答えはラベル付きの評価セットに対して引き締められた基準を実行し、精度とリコールを測定し、デプロイ前にプロンプトをバージョン管理することを含む。プロンプトを使い捨てのアーティファクトとして扱うことはペナルティを受ける。バージョン管理されたコードとして扱うことは報酬を受ける。

練習アンカー

明示的基準設計は6つのCCA-Fシナリオのうち1つで最も多く出題される。以下をシナリオクラスター問題のアーキテクチャの骨格として扱う。

構造化データ抽出シナリオ

このシナリオでは、パイプラインが文書（請求書、医療記録、契約、サポートチケット）を取り込み、名前付きフィールドを構造化スキーマに抽出する。テストする質問を期待する。曖昧な抽出指示（「主要なフィールドを引き出す」）をソース、フォーマット、存在、曖昧さルールを持つフィールドレベルの基準に書き直すかどうか。見た目が似ているフィールドの明示的な除外ルールと肯定的な包含基準を対にするかどうか。「重要な」や「重大な」のような形容詞を数値閾値または列挙されたカテゴリーに置き換えるかどうか。既知のエッジケース（空のフィールド、引用されたエンティティ、マルチマッチ入力）をプロンプト内に列挙するかどうか。スキーマの適合性を保証するために明示的基準と strict: true tool useを組み合わせるかどうか。基準変更をデプロイする前にプロンプトをバージョン管理してラベル付きの評価セットを実行するかどうか。

カスタマーサポート解決エージェントシナリオ

カスタマーサポートシナリオは、エージェントがチケットを分類し、緊急度を検出し、エスカレーションするタイミングを決定しなければならないときに明示的基準を練習する。優先順位付きの分類ルール設計、主観的な「緊急に見える」ヒューリスティックではなく明示的な緊急閾値、ClaudeによるエスカレーションではなくClaudeによるエスカレーショントリガーの列挙をテストする質問を期待する。同じ条件-閾値-アクションの三項構造が適用される。

マルチエージェント調査システムシナリオ

マルチエージェント調査シナリオは、サブエージェントが「十分な答え」または「高品質なソース」を構成するものを決定するときに明示的基準を練習する。回答品質基準がサブエージェントの判断に任せるのではなく明示的なルールとして定義されているかどうか（最小限の引用ソース数、最小限の信頼度スコア、必須の証拠フィールド）をテストする質問を期待する。サブエージェントのプロンプトレベルの明示的基準が調査パイプライン全体での品質ドリフトを防ぐものだ。

FAQ — 明示的基準設計上位5問

なぜ明示的基準はCCA-Fシナリオの答えで自然言語指示を上回るのか？

明示的基準は、Claudeが事前学習の事前確率で埋める曖昧さの表面を折りたたむ。「不審な取引にフラグを立てる」のような自然言語指示は、Claudeに「不審」の定義を推論することを要求する。2回の実行が異なる定義を生み出す可能性がある。なぜなら推論が不決定だからだ。明示的基準——amount > 10000 AND merchant_country != billing_country AND no prior transactions in that country within 90 days——は推論するものを何も残さない。マッチ表面が狭いため精度が上がる。ルールが決定論的なため一貫性が上がる。レビュアーが各ルールを各入力に対してチェックできるため監査可能性が上がる。条件-閾値-アクションの三項形式で明示的基準を提示するCCA-Fシナリオの答えは、モデルの判断に依存する答えを一貫して上回る。

基準を引き締めるとリコールが失われるバランスをどう取るか？

基準を引き締めることは決して無料の改善ではない——追加するすべてのルールが偽陽性と一部の真陽性の両方を削減する。バランスは各エラータイプのコストによって決まるビジネスの決定だ。偽陽性が高コストなキュー（法的レビュー、詐欺調査、安全インシデント）では積極的に引き締める。偽陰性が高コストなワークフロー（医療スクリーニング、規制コンプライアンス）では基準を緩めに保ち、下流の人間レビューに偽陽性を捕まえることを頼る。調整はラベル付きの評価セットを必要とする。現在の基準で精度とリコールを測定し、調整し、再測定する。トレードオフを明示的に名指しするCCA-Fシナリオの答え——「これらの基準を引き締めると精度は向上するがリコールが削減されるかもしれない。ラベル付きの評価セットでリコールを監視する」——は一貫して、引き締めを無条件の勝利として扱う答えを上回る。

明示的基準はfew-shotの例を置き換えるべきか？

いや。基準と例は補完的であり、CCA-F対応のプロンプトには両方が存在すべきだ。基準は決定ルールを構造化された形式で定義する。例はルールの残りの定性的要素を調整し、出力フォーマットを文字通りの形式でデモンストレーションする。基準があり例がないプロンプトはルールの文字通りを実行する傾向があるが、微妙なフォーマット規則を見逃す。例があり基準がないプロンプトは例をオーバーフィットする傾向があり、それらと異なる入力で誤動作する。推奨される形状は両方をインターリーブする。基準＋エッジケースのルール＋3〜5のfew-shotの例、すべてXMLタグに包まれている。CCA-F試験は基準と例の両方を保持する答えを、一方を優先する答えより正解として一貫してマークする。

基準が解決できない既知の曖昧なケースをどう扱うか？

曖昧なケースを明示的な <edge_cases> エントリとしてプロンプト内に直接列挙する。各ケースについて、そのケースを識別する条件（「取引が金額閾値に一致するが、顧客が加盟店の国のアクティブなトラベルノーティスを持っている」）と明示的な解決策（「取引にフラグを立てない。代わりに出力に travel_notice_overrode_flag = true を設定する」）を指定する。列挙されたエッジケースは暗黙のドメイン知識を監査可能なプロンプト指示に変換する。CCA-F試験は一貫してこのパターンを、主要な基準ブロックを拡張したり下流コードでケースを処理したりするソリューションより優先する。エッジケースはプロンプトに属する。なぜならClaudeが適用できる場所がそこだからだ。後処理に隠れたエッジケースはClaudeが誤った中間出力を生み出すことを引き続き許す。

本番の基準ブロックの最小限の評価規律は何か？

基準ブロックの最小限の実行可能な評価ハーネスには、30〜100個のラベル付きの肯定的ケース、30〜100個のラベル付きの否定的ケース（以前に偽陽性を引き起こした既知の見た目が似ているものを含む）、列挙された <edge_cases> ルールに対応する10〜30個のラベル付きエッジケースが含まれる。全セットに対してプロンプトを実行し、肯定/否定の分割で精度とリコールを計算し、エッジケースで完全一致の精度を計算する。すべての基準の変更には評価の再実行と前後のメトリクスを記録するコミットが伴う。プロンプト、評価セット、測定を一緒にバージョン管理する。評価の再実行なしに基準変更をデプロイすることを提案するCCA-Fシナリオの答えは一貫して誤りとしてマークされる。評価ループとバージョンコミットを含む答えは、試験が報酬を与える成熟したエンジニアリングの応答としてマークされる。

さらに読む

• Prompt engineering overview: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/overview
• Use examples (multishot prompting) to guide Claude's behavior: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/multishot-prompting
• Increase output consistency — structured outputs: https://docs.anthropic.com/en/docs/test-and-evaluate/strengthen-guardrails/increase-consistency
• Use XML tags to structure your prompts: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/use-xml-tags
• Strict tool use — schema-guaranteed output: https://docs.anthropic.com/en/docs/agents-and-tools/tool-use/strict-tool-use
• Claude 4 prompting best practices: https://docs.anthropic.com/en/docs/build-with-claude/prompt-engineering/claude-4-best-practices

関連するExamLabのトピック：Few-Shot Prompting for Output Consistency and Quality、Structured Output with Tool Use and JSON Schemas、Validation, Retry, and Feedback Loops for Extraction Quality、Multi-Instance and Multi-Pass Review Architectures。