CCA-F 練習問題と解説【2026年】Claude認定アーキテクトの本番形式シナリオ問題

サブエージェントは親の会話を引き継ぎません。コンテキストの分離は意図的なもので、各ワーカーのウィンドウをきれいで予測可能な状態に保ちます。そのため、ワーカーが必要とするものはすべて、タスクのプロンプトで明示的に渡す必要があります。選択肢Cは問題の診断を誤っています。max_tokens が制限するのは出力の長さで、サブエージェントに何が見えるかとは関係ありません。選択肢Bは、1つの値を渡せば済むところにツールと繰り返しの照会を加え、サブエージェントのツールの数も増やします。選択肢Dは、委任のプロンプトに1行加えれば直るバグを回避するために、妥当な責任の分離を崩してしまいます。

3つの地域の調査は互いに独立しているので、コーディネーターの1ターンで並列のタスク呼び出しとして出力すべきです。経過時間は、最も遅い地域の時間程度まで短くなります。ダイジェストは3つの結果すべてに依存するため、その後に順番に実行します。これが選択肢Cです。選択肢Aは、入力がそろう前に依存するステップを始めてしまい、書き直しが必要なダイジェストができます。選択肢Dはコンテキストの分離を崩します。サブエージェントには必要な範囲の指示だけを渡すべきで、会話全体を共有するとコストとノイズが増えるだけで、連携は改善しません。結果をまとめるのはコーディネーターの仕事だからです。

N回試みても進展がないことは、信頼できる3つのきっかけ（ほかの2つは、人間の担当者への明示的な依頼と、ポリシーが曖昧な場合）の1つであり、モデルに何も尋ねなくてもツールのログから観測できます。選択肢Cは自己申告の確信度に頼っており、これはキャリブレーションが不十分です。選択肢Aは感情を使っており、くだけた言葉遣いに反応する一方で、丁寧な表現の不満は見逃します。選択肢Dは複雑さと曖昧さを混同しています。明確なポリシーの範囲内にある、複数のツールを使うチケットこそ、エージェントが自分で完了すべき仕事です。

名前付きのセッションを再開すると会話の履歴が正確に復元され、それがシフトの引き継ぎに必要なことです。フォークは同じ起点から独立したブランチを作るため、別の仮説は本線に書き戻すことなく分岐できます。選択肢Bはツールの履歴を捨て、分離が必要な作業に再開を使っています。選択肢Aは2つを逆にしています。引き継ぎにフォークを使うと誰も統合しない2つ目のブランチができ、仮説に新しいセッションを使うと共有の起点が失われます。選択肢Dはプロセスが決して終了しないことに頼っており、数日にわたるケースには脆い前提です。

Messages API はすべての応答で決定論的な stop_reason を返し、それがループの制御のためのサポートされたシグナルです。tool_use はツールを実行して続行すること、end_turn はモデルが終えたこと、max_tokens は出力が途中で切れて続きの処理が必要なことを意味します。選択肢Cは自由形式のテキストを解析しており、だからこそドライバーに通知されないことがあり（作業の途中でその語句が現れる）、ループが動き続けることもあります（その語句が現れない）。選択肢Aは平均で上限を決めるため、長いインシデントが途中で打ち切られます。選択肢Bは自己申告を制御フローにしており、Cと同じ脆さに呼び出しが1回加わります。反復回数やトークンの予算は、ログを残す安全網としてだけ持っておきます。

tool_choice は Claude がツールを呼び出すかどうかと、どのツールを呼び出すかを制御するもので、名前を指定したツールの強制がプログラムによる保証になります。応答は、その入力スキーマに準拠した extract_candidate の呼び出しになります。選択肢Dは文章の応答をなくしますが、まだ抽出されていない履歴書に対して、モデルが check_duplicate や notify_recruiter を選ぶ余地を残します。選択肢Aはプロンプトによる指示で確率的なままであり、それが現在の失敗です。選択肢Cはスキーマによる強制を完全にやめてプロンプトだけの JSON に頼っており、試験ではこれが最も弱い構造化出力の方法として扱われます。

プロジェクトレベルの .mcp.json は共有されバージョン管理されるスコープで、${VAR} の展開でシークレットをファイルの外に出せます。そのため選択肢Dなら、チーム全体が1つの定義を使え、トークンも漏れません。1人だけが使うサーバーはユーザーレベルの設定に置くのが適切で、これが選択肢Cです。選択肢Bは共有のファイルを共有できないものにしたうえ、平文のシークレットをディスクに残します。選択肢Aはチームのサーバーを12回重複させ、それぞれがずれていきます。変数の展開を使えば、サーバーの定義は共有したまま、シークレットはローカルに保てます。

ツールの説明は振り分けの主要なシグナルで、この2つの説明はほとんど同じなので、モデルには選ぶ手がかりがありません。入力の形式、出力、境界（「名前の一部なら find_customer を使う」）を書いた説明があれば、根本から選択が直ります。選択肢Cの効果はわずかです。名前は説明よりもはるかに小さな重みしか持ちません。選択肢Dは振り分けのロジックをシステムプロンプトに移しており、そこではほかのすべての指示と競合し、ツールの定義からずれていきます。選択肢Bはツールの呼び出しを強制しますが、正しいほうを選ぶ助けにはなりません。

構造化されたエラーがあれば、エージェントは次のアクションを判断できます。一時的な 429 なら間隔を空けてリトライし、恒久的な 403 なら止めてエスカレーションします。どちらの結果も空の結果とは異なり、モデルは空の結果を「操作が完了し、何も見つからなかった」と読みます。選択肢Bは構造がないため、リトライの判断が自由形式のテキストの解釈に委ねられます。選択肢Aは権限の失敗を終わりのないリトライの裏に隠し、ループをハングさせる可能性があります。選択肢Dは、再試行可能なケースで黙って空を返すアンチパターンを残し、報告してきちんとエスカレーションすべきケースでループをクラッシュさせます。

ユーザーレベルの CLAUDE.md は個人用で、リポジトリとともに移動することはありません。だからこそチームメイトには何も見えないのです。共有の規約は、すべてのクローンが読み込むプロジェクトレベルに置き（B）、個人の好みはユーザーレベルに置きます（C）。選択肢Dは手作業でファイルをコピーするため、リードが元のファイルを編集した瞬間にずれていきます。選択肢Aは、常に適用すべき規約を、誰かがスキルの起動を覚えているかどうかに依存させます。スキルは必要に応じて使う手順のためのもので、常に守るルールは CLAUDE.md に置きます。

フックは、Claude Code のハーネスがライフサイクルのイベントで実行するシェルコマンドで、モデルの判断の外にあります。終了コード2を返す PreToolUse フックはツールの呼び出しをブロックして理由を Claude に返し、PostToolUse フックは実際の編集のたびにフォーマッターを実行します。選択肢Bも文章であることに変わりはなく、条件付きで読み込まれます。助言はできても、ブロックはできません。選択肢Aは遵守を改善しますが確率的なままで、それが報告されている失敗です。選択肢Cは、人間が気づいた場合にしか誤った編集を止められず、すべての変更を遅くし、black の実行には何の役にも立ちません。

-p（print）フラグは Claude Code を非対話にするため、パイプラインが与えられない入力を待つことはありません。また --output-format json は、下流のジョブが決定論的に解析できる機械可読な出力を生成します。スキーマのチェックがあれば、形式の崩れた出力は明確な失敗になります。選択肢Bはヘッドレスのジョブで対話型セッションを動かし続け、文章を解析しています。選択肢Dはハングは直しますが、プロンプトだけの JSON に頼っています。選択肢Cは設定の問題を処理能力の問題として扱い、解析の失敗をそのまま残します。

context: fork はスキルを独自のコンテキストを持つサブエージェントで実行するため、監査の冗長な出力が親の会話に入ることはありません。disallowed-tools は、スキルがアクティブな間、列挙したツールを Claude が使えるツールから外すため、Edit と Write は呼び出せなくなります。選択肢Cはよくある誤解です。allowed-tools は列挙したツールを確認なしで使えるように事前に承認するもので、使えるツールを制限するものではありません。Edit と Write は呼び出せるままです。選択肢Bはファイルを書き込むツールを残したまま、使わないようお願いしているだけです。選択肢Aは編集が起きるのを許して後から片付けるもので、防ぐよりもリスクが高く、ノイズも多くなります。

3つの層が、それぞれの不具合に対応します。スキーマ（ツールの定義に付けた JSON Schema で、応答はこれに一致しなければならない）は形式の崩れた JSON をなくし、検証のコードは合わない合計を捉え、リトライは具体的な検証エラーを送り返すため、修正が的を絞ったものになります。選択肢Aはスキーマの働きを過大評価しています。スキーマが強制するのは構文（フィールドと型）で、合計のような意味は強制しません。選択肢Bはすでに失敗しているプロンプトだけの方法を続け、例を、効果がある2〜4個の範囲を超えて増やしています。選択肢Dはすべての注文でコストを2倍にし、それでも食い違う2つの出力のどちらが正しいかはわかりません。

Batch API（多数のリクエストを非同期に送信し、24時間以内に半額で処理される）はアーカイブに合っています。期限が2日のバックグラウンドのジョブで、結果を待っているユーザーもいないからです。アシスタントは Batch API の2つの制約に同時に引っかかります。誰かが結果を待っており、さらに複数ターンの会話が必要ですが、Batch API は1つのリクエストの中での複数ターンのやり取りに対応していません。選択肢Dは、数分で返ることも何時間もかかることもあるジョブで、作業中のユーザーを待たせてしまいます。選択肢Aは、リアルタイムで届けても何の得もないワークロードに定価を払うことになります。

曖昧な指示（「注意すること」）はモデルに測れるものを何も与えないため、判断のしきい値が定まりません。明示的な基準（「X、Y、Z のいずれかを含む場合だけフラグを立てる」）があれば各判断を確認でき、許容できる境界上の内容を示す少数の例が、フラグを立てずに残すべきものを教えます。選択肢Dは同じ曖昧さを強い調子で言い直しただけです。選択肢Aは2〜4個という例の範囲を大きく超え、コンテキストを消費し、一貫しないパターンの一致を生みがちです。選択肢Cは不明確な仕様を補うためにコストをかけていますが、より大きなモデルにとっても不明確な仕様は不明確なままです。

異なる2つのシグナルには、異なる2つの値が必要です。情報がない場合は null、情報はあるが曖昧な場合は unclear です。「記載はあるが種類は不明」と答える正当な手段をモデルに与えれば、誤ったカテゴリを無理に選ぶことはなくなり、それらの行をレビューに回せば査定は正確に保たれます。選択肢Bは両方のケースを null にまとめてしまうため、下流では「駐車場の記載なし」と「駐車場の記載はあるが種類は不明」を区別できません。選択肢Aはもっともらしい推測からデータを作り出しています。選択肢Dは列挙型の一貫性を捨て、分類の問題を自由記述を利用する側に押し付けています。

これは「lost in the middle」効果です。長いコンテキストでは最初と最後に最も注意が向き、その間の内容は軽く扱われます。呼び出しごとのコンテキストを小さくすれば（セクションごとのパスの後、抽出結果をもとに統合する）、モデルにもっと頑張るよう求めるまでもなく、中ほどそのものがなくなります。選択肢Bは、問題の原因そのものを大きくしています。選択肢Cは位置による偏りにプロンプトの指示で対抗しようとしており、max_tokens が制御するのは出力の長さだけです。選択肢Aは構造を加えますが、契約書全体を1回の呼び出しに入れたままなので、中ほどは中ほどのままです。

マニフェストは、何が終わったかを記録する永続的な外部の記録です。タスクの一覧、項目ごとのステータス、部分的な結果を保持します。再起動時にそれを読むからこそ、回復は完了した作業を繰り返さずに飛ばせます。2つは組み合わせて初めて機能します。選択肢Dはチームが今実質的に行っていることで、コストの倍増を確実にします。選択肢Aは、クラッシュとともに消えるコンテキストウィンドウの中に状態を置き、コードが追跡すべきものをモデルに追跡させています。

限られたレビューの予算は、誤りが集中しているところに向けたときに最も品質保証の効果を上げます。そして、監査はすでにその場所を突き止めています。層化抽出（リスクの高い出力は高い割合で、日常的な出力は低い割合でレビューする）と層ごとの誤りの追跡を組み合わせれば、レビューはプロンプトと検証のためのフィードバックのループになります。選択肢Dは、1日に500件しか処理できないチームに1日16,000件以上を回すことになります。選択肢Bは無作為のままなので、追加の労力のほとんどはリスクの低い判定に費やされます。選択肢Cは自己申告の確信度で、キャリブレーションが不十分なうえ、モデルが自信を持っている誤りを見逃します。