核心原則 & アンチパターン
試験ガイド v1.0 から抽出した、CCAR-F試験で繰り返し問われる判断基準と、誤答選択肢に頻出するアンチパターン集
核心原則 6つ
試験全体を貫く設計思想。迷ったときの判断軸になる。
プログラム的制御 > プロンプト指示
確実性が必要な振る舞い（金融操作のブロック、本人確認の強制等）は、プロンプトではなく hooks やプログラム的な前提条件で制御する。プロンプト指示は非ゼロの失敗率がある。
"When deterministic compliance is required (e.g., identity verification before financial operations), prompt instructions alone have a non-zero failure rate"
Task 1.4, 1.5 / サンプル Q1
stop_reason でループ制御する
エージェントループは stop_reason === "tool_use" で継続し、"end_turn" で終了する。自然言語のパース、任意のイテレーション上限、アシスタントテキストの存在チェックでループ終了を判定してはいけない。
"Implementing agentic loop control flow that continues when stop_reason is 'tool_use' and terminates when stop_reason is 'end_turn'"
サブエージェントはコンテキストを自動継承しない
サブエージェントは親（コーディネーター）の会話履歴を自動で受け取らない。必要な情報はプロンプトに明示的に渡す。構造化データでコンテンツとメタデータ（ソースURL等）を分離して渡すのがベスト。
"How subagents operate with isolated context—they do not inherit the coordinator's conversation history automatically"
ツール数は 4-5個にスコープする
エージェントに与えるツール数は 4-5個が最適。18個のような大量のツールを与えると選択精度が劇的に低下する。各サブエージェントにはその役割に必要なツールだけを制限して渡す。ただし例外があり、高頻度の単純ニーズにはスコープを絞ったクロスロールツールを1つだけ与え、複雑なケースはコーディネーター経由に残す折衷が正解になる（サンプルQ9）。
"Giving an agent access to too many tools (e.g., 18 instead of 4-5) degrades tool selection reliability by increasing decision complexity"
同セッションでの self-review は効果が低い
コードを生成したのと同じセッション（同じ推論コンテキスト）でレビューしても、自分の判断を疑いにくい。独立したレビューインスタンス（先行の推論コンテキストなし）の方が効果的。
"Self-review limitations: a model retains reasoning context from generation, making it less likely to question its own decisions in the same session"
Batch API はブロッキング処理に使わない
Message Batches API は 50% コスト削減だが、24時間以内の処理保証がない。pre-merge check のようなブロッキング処理には不向き。overnight レポートや weekly 監査に使う。
"Batch processing is appropriate for non-blocking, latency-tolerant workloads (overnight reports, weekly audits, nightly test generation) and inappropriate for blocking workflows (pre-merge checks)"
Task 4.5 / サンプル Q11
アンチパターン 10個
試験の誤答選択肢に頻出するパターン。「これが選択肢にあったら不正解」と即判断できるようにする。
❌ 自然言語パースでループ終了を判定
なぜダメか：stop_reason が唯一信頼できるシグナル。テキスト内容のパースは不安定で誤判定する。
✅ 正解：stop_reason === "end_turn" で終了判定
❌ 任意のイテレーション上限を主要な停止メカニズムにする
なぜダメか：タスクの複雑さによって必要なイテレーション数は変わる。固定上限は早期終了や不完全な結果を招く。
✅ 正解：stop_reason ベースの終了 + 安全策としてのみ上限を設定
❌ プロンプト指示だけで確実性が必要な動作を制御
なぜダメか：LLM のプロンプト遵守は確率的。金融操作やセキュリティ要件など「100%守る必要がある」ルールには不十分。
✅ 正解：hooks（PreToolUseによる実行前のブロック）やプログラム的前提条件で制御
❌ 感情分析（sentiment）でエスカレーション判断
なぜダメか：感情と案件の複雑さは相関しない。怒っている顧客が単純な問題を抱えていることも、冷静な顧客が複雑な問題を抱えていることもある。
✅ 正解：明示的なエスカレーション基準 + few-shot 例で判断
❌ 未較正の self-reported confidence だけでルーティング
なぜダメか：較正していない自己報告 confidence は不正確。難しいケースで自信過剰、簡単なケースで過小評価することがある。※較正したうえで使うのは推奨技能（Task 4.6・5.5）で、NGなのは「未較正のままエスカレーション判断に使う」こと。
✅ 正解：明示的なエスカレーション基準 + few-shot 例（Q3の正答）。人間レビューのルーティングに信頼度を使う場合は、ラベル付き検証セットで較正したフィールド別信頼度を用いる（Task 5.5）
❌ エラーを握りつぶす（空結果を success として返す）
なぜダメか：コーディネーターが障害を検知できず、不完全な結果を最終出力してしまう。リカバリの機会が失われる。
✅ 正解：構造化エラーコンテキスト（failure type, 試行内容, 部分結果, 代替案）を返す
❌ 単一障害でワークフロー全体を終了する
なぜダメか：1つのサブエージェントが失敗しても、他の結果で部分的な成果は出せる。全終了は過剰反応。
✅ 正解：部分結果で続行 + カバレッジギャップを注釈
❌ 汎用エラー応答（"Operation failed"）を返す
なぜダメか：コーディネーターが適切なリカバリ判断をするための情報が不足する。リトライすべきか、代替手段を使うべきかがわからない。
✅ 正解：errorCategory（transient/validation/permission）、isRetryable、human-readable description を含む構造化エラー
❌ エージェントにツールを大量に与える（18個等）
なぜダメか：選択対象が増えると判断の複雑さが増し、類似ツール間の誤選択が頻発する。
✅ 正解：各エージェントに 4-5個の役割特化ツールのみをスコープ（例外：高頻度の単純ニーズに限り、スコープ限定のクロスロールツールを1本だけ足す折衷もある＝サンプルQ9）
❌ 同セッションで生成 & レビューする
なぜダメか：生成時の推論コンテキストが残っているため、自分の判断を疑いにくい。extended thinking よりも独立インスタンスの方が効果的。
✅ 正解：先行の推論コンテキストを持たない独立した Claude インスタンスでレビュー