← 試験の目次へ
Claude Certified Architect – Foundations 模擬テスト 1(64問・120分)
タイマーを一時停止 タイマーを隠す
試験ガイドの全30タスクステートメントを、どれも1問以上で確かめる64問です(D1 16 / D2 12 / D3 13 / D4 12 / D5 11)。本番は60問で、問題数とドメイン配分は本番とは少し違います。本番のように、問題は4つのシナリオに分かれています(本番では6つのうち4つがランダムに出ます。このテストはシナリオ1・2・3・6)。各シナリオの説明を読んでから問題に答えてください。単一選択と複数選択があり、複数選択の問題には選ぶ数が書いてあります。すべて答えたら、いちばん下の「採点する」を押すと、正解・解説・ドメイン別とシナリオ別の得点が表示されます。タイマーは目安なので、時間が過ぎても続けられます。内容は2026年11月時点の公式ドキュメントにもとづきます。試験ガイドの書き方が今の製品と違う点(Task ツール → Agent ツール、新しいモデルでのツールの強制の制限など)は、解説で両方を示しています。
ドメイン 配点 問題数 D1 エージェント型アーキテクチャとオーケストレーション 27% 16 D2 ツール設計と MCP 統合 18% 12 D3 Claude Code の設定とワークフロー 20% 13 D4 プロンプトエンジニアリングと構造化出力 20% 12 D5 コンテキスト管理と信頼性 15% 11
シナリオ 問題数 シナリオ1: カスタマーサポート解決エージェント 15 シナリオ2: Claude Code でのコード生成 17 シナリオ3: マルチエージェント調査システム 17 シナリオ6: 構造化データ抽出 15
シナリオ1: カスタマーサポート解決エージェント あなたは Claude Agent SDK で、カスタマーサポートの解決エージェントを作っています。エージェントは、返品、請求の争い、アカウントの問題など、あいまいさの大きい依頼を扱います。バックエンドには独自の MCP ツール(get_customer、lookup_order、process_refund、escalate_to_human)でつながります。目標は、初回の問い合わせでの解決率80%以上と、エスカレーションすべき場面を正しく見分けることです。
問1(1つ選んでください) サポートエージェントには、社内の管理画面の機能をそのまま移した22個のツールがあり、その中には delete_account や change_plan_price のような管理者向けの操作も含まれています。ツールの選び間違いが増え、危険な操作の誤用も心配です。最も良い対策はどれですか。
A. システムプロンプトに、管理者向けのツールは使わないよう書く B. サポートの役割に必要なツール(get_customer、lookup_order、process_refund、escalate_to_human など)だけを渡し、管理者向けの操作はエスカレーションの先で人が行う C. 22個のツールに番号を付けて、説明の先頭に優先順位を書く D. ツールを40個に増やし、もっと細かく分ける
ドメイン2: ツール設計と MCP 統合 / 2.3 ツールの配分
正解: B
ツールが多すぎると判断が複雑になり、選択の信頼性が下がります。役割に関係のないツールは誤用のもとにもなります。役割に必要なツールだけを渡すのが原則です。A は確率的で、危険なツールが残ります。C と D は選択をさらに難しくします。
問2(1つ選んでください) process_refund は、決済の接続がタイムアウトしたときも、注文がすでに返金済みのときも、同じ「返金に失敗しました」を返します。エージェントは返金済みの注文でも何度も再試行し、顧客には「しばらくお待ちください」と答えています。返金済みの場合に返すべき結果として最も良いものはどれですか。
A. isError を付けずに「返金に失敗しました」を返す B. isError: true で、種類は一時的なエラー、再試行できる、と返す C. isError: true で、種類は業務エラー、再試行できない(isRetryable: false)、「この注文はすでに返金済みです」という顧客に伝えられる説明を返す D. 成功として空の結果を返す
ドメイン2: ツール設計と MCP 統合 / 2.2 構造化エラー
正解: C
返金済みは業務ルールによるエラーで、くり返しても成功しません。種類、再試行できないこと、顧客向けの説明を構造化して返せば、エージェントはむだな再試行をやめ、正しく伝えられます。B は誤った再試行を招きます。A と D はエージェントが状況を判断できません。
問3(1つ選んでください) サポートエージェントを開発するチームは Claude Code を使っています。社内の注文 API の MCP サーバーの設定がリポジトリの .mcp.json にあり、API トークンが直接書かれてコミットされていました。また、あるメンバーは自分だけで試したい実験用の MCP サーバーがあります。正しい組み合わせはどれですか。
A. 注文 API のサーバーは各自の ~/.claude.json に移し、実験用のサーバーを .mcp.json に入れる B. トークンはそのままにしてリポジトリを非公開にし、実験用のサーバーも .mcp.json に入れる C. 両方のサーバーの設定を CLAUDE.md に書く D. 注文 API のサーバーは .mcp.json に残してトークンを ${ORDER_API_TOKEN} の環境変数展開に替え(すでにコミットしたトークンは無効にする)、実験用のサーバーはそのメンバーの ~/.claude.json に置く
ドメイン2: ツール設計と MCP 統合 / 2.4 MCP サーバーの設定
正解: D
チームで共有するサーバーはプロジェクト単位の .mcp.json、秘密は環境変数展開で、コミットしないのが原則です。個人・実験用のサーバーはユーザー単位の ~/.claude.json に置きます。一度コミットしたトークンは漏れたものとして扱い、無効にします。A は逆の配置です。B は秘密情報のコミットを続けます。C の CLAUDE.md はサーバーの設定の場所ではありません。
問4(1つ選んでください) 1つのセッションで、顧客が2つの注文(#5521 の 8,200円と #5530 の 15,600円)の返品を相談しています。会話が長くなるにつれ、エージェントは2つの金額を取り違えたり、片方の返品ラベルの発行済みという状態を忘れたりします。最も効果的な対策はどれですか。
A. 注文ごとの構造化データ(注文 ID、金額、状態、合意したこと)を会話の要約とは別の層に保ち、毎回のプロンプトに入れる B. 注文1件ごとにセッションを分け、顧客にもう一度最初から説明してもらう C. 会話の要約をより短くして、コンテキストを空ける D. 金額は顧客に毎回もう一度言ってもらう
ドメイン5: コンテキスト管理と信頼性 / 5.1 問題ごとの構造化データ
正解: A
複数の問題を扱うセッションでは、問題ごとの事実(注文 ID、金額、状態)を構造化して、要約される履歴とは別に保ちます。毎回入れることで取り違えや忘れを防げます。B と D は顧客の負担を増やします。C は数字がさらにあいまいになる方向です。
問5(1つ選んでください) escalate_to_human ツールの入力は、今は自由記述の reason という文字列1つだけです。人の担当者の画面には会話の記録が出ないため、担当者は毎回顧客に最初から聞き直しています。ツールの入力をどう変えるのが最も良いですか。
A. reason の最大文字数を増やし、詳しく書くよう説明に追加する B. 会話の全文とすべてのツール結果を、そのまま添付する項目を足す C. customer_id、issue_summary、root_cause、amount、actions_taken、recommended_action などの項目を持つ構造化された引き継ぎの入力にする D. エスカレーションのときは、顧客に担当者への説明文を書いてもらう
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.4 人への引き継ぎ
正解: C
会話の記録を見られない担当者には、判断に必要な事実(顧客 ID、根本原因、金額、推奨アクションなど)を構造化して渡します。ツールのスキーマで項目を決めておけば、毎回そろった形で届きます。A は形がそろわず抜けも出ます。B は量が多く要点が埋もれます。D は顧客の負担を増やします。
問6(1つ選んでください) 顧客の最初のメッセージは「AI ではなく人の担当者と話したいです。注文の件です」でした。今のエージェントは、まず get_customer と lookup_order で調べ、自分で解決を試みてから、うまくいかないときだけエスカレーションしています。この場面で最も適切な振る舞いはどれですか。
A. まず問題を調べて解決を試み、顧客が3回希望したらエスカレーションする B. 顧客の感情を分析し、怒りが強いときだけエスカレーションする C. 先に調べようとせず、顧客の希望どおりすぐに人の担当者へエスカレーションする D. 人の担当者は忙しいと伝えて、AI での対応を続ける
ドメイン5: コンテキスト管理と信頼性 / 5.2 人を求められたとき
正解: C
顧客がはっきり人の担当者を求めたら、先に調査をせず、すぐに応じるのが試験ガイドの基準です。不満はあるが人を求めていない単純な問題なら解決を申し出る、という場面とは区別します。B は感情を複雑さの指標にしていて当てになりません。A と D は顧客の明確な希望を無視しています。
問7(1つ選んでください) get_customer で本人確認をした後に返金する流れは守られています。ところが監査で、確認済みの顧客とは別の顧客の注文番号に対して process_refund が実行された例が見つかりました。顧客が会話の中で家族の注文番号を伝えたためです。誤った返金は会社の損失になります。最も確実な対策はどれですか。
A. システムプロンプトに「確認した顧客本人の注文だけを返金すること」と追加する B. process_refund の説明文に、他人の注文を扱わないよう書き足す C. 顧客が注文番号を伝えたら、もう一度 get_customer を呼ぶ few-shot 例を加える D. process_refund の PreToolUse フックで、注文の持ち主の顧客 ID が確認済みの顧客 ID と一致するかを調べ、一致しなければ拒否する
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.4 プログラムによる強制
正解: D
金銭に関わる条件を決定的に守らせるにはコードで止めます。PreToolUse フック(前提条件のゲート)で、注文の持ち主と確認済みの顧客の一致を確かめれば、プロンプトの解釈に関係なく誤った返金を防げます。A、B、C はどれもモデルが守る確率を上げるだけで、失敗をゼロにはできません。
問8(2つ選んでください) 新しいポリシーで「1件500ドルを超える返金」と「同じ顧客への30日以内の3件目の返金」は人の承認が必要になりました。エージェントはこのルールを確実に守り、顧客にも理由を正しく説明する必要があります。適切な組み合わせを2つ選んでください。
A. process_refund の PreToolUse フックで金額と30日以内の返金回数を調べ、条件に当たれば拒否し、理由に「escalate_to_human で承認を依頼すること」と書く B. process_refund の PostToolUse フックで、上限を超えた返金を実行後に取り消す C. ルールの判定はすべてシステムプロンプトの指示に任せ、フックは使わない D. システムプロンプトにもポリシーの内容を短く書き、承認が必要になったときに顧客へ理由と次の流れを説明できるようにする
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.5 ポリシー違反を止めるフック
正解: A、D
強制はフックで行い(A)、説明のための知識はプロンプトで渡す(D)のが良い組み合わせです。拒否の理由は Claude に届くので、エスカレーションへ自然に切り替えられます。B は実行した後では遅く、二重の処理やお金の移動が起きてしまいます。C は確率的で、確実な順守が必要な業務ルールには不十分です。
問9(1つ選んでください) チームの一部が「エージェントの判断が読めないので、返品・請求・アカウントの全パターンを決定木にして、呼ぶツールの順番をすべてコードで固定しよう」と提案しています。依頼はあいまいなものが多く、パターンは毎月増えています。アーキテクトとして最も良い方針はどれですか。
A. 提案どおり、すべての流れを決定木で固定する B. ツールをすべて外し、Claude には顧客への返答の文章だけを書かせる C. 決定木を作り、決定木に当てはまらない依頼はすべて人に回す D. どのツールを次に呼ぶかは文脈から Claude に判断させ、本人確認の後の返金のような必ず守る順番だけをフックやゲートで強制する
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.1 モデル主導の判断
正解: D
モデル主導の判断は、前もって読めないあいまいな依頼に強みがあります。全部を決定木にすると、新しいパターンに対応できず保守も重くなります。必ず守る順番だけをプログラムで強制し、残りはモデルに任せるのが組み合わせの基本です。B はエージェントの意味がなくなります。C は初回解決率を大きく下げます。
問10(1つ選んでください) ログを見ると、エージェントはポリシーに書かれていない依頼(例: 贈り物として受け取った人による、購入者の名前での返品)に、自分で判断して返金を進めていました。一方で、写真付きの破損の交換のような簡単なケースを人に回していました。最も効果的な改善はどれですか。
A. エージェントに確信度を1〜10で出させ、5未満なら人に回す B. システムプロンプトに、エスカレーションする条件(顧客が人を求めた、ポリシーに書いていない・あいまいな依頼、進展できない)と自分で解決する条件を明確に書き、その境目を示す few-shot 例を入れる C. 過去のチケットで学習した別の分類モデルを作り、エージェントの前に置く D. すべての返品を人に回す
ドメイン5: コンテキスト管理と信頼性 / 5.2 ポリシーの抜け
正解: B
判断の境目がはっきりしていないことが根本原因です。明確な基準と few-shot 例をシステムプロンプトに入れるのが、手間に見合った最初の対策です。A の自己申告の確信度は調整されておらず当てになりません(難しいケースで誤って自信を持つ)。C はデータと仕組みが必要で、プロンプトの改善を試す前としては大がかりです。D は初回解決率を大きく下げます。
問11(2つ選んでください) 注文データベースが一時的に止まっている間、lookup_order が空の配列を返していました。エージェントはそれを見て顧客に「お客様のご注文は見つかりませんでした」と答えています。lookup_order の作り方として正しいものを2つ選んでください。
A. データベースの停止中も空の配列を返し、エージェントに「空なら少し待って再試行」と指示する B. データベースにつながらないときは isError: true と、一時的なエラーで再試行できることを示す情報を返す C. 検索が正常に終わり該当がなかったときだけ、成功として空の結果(0件)を返す D. どんな失敗でも例外を投げて、エージェントの会話を終わらせる
ドメイン2: ツール設計と MCP 統合 / 2.2 失敗と空の結果
正解: B、C
アクセスの失敗(B)と、正当な空の結果(C)を区別して返します。失敗を空の成功として返すと、エージェントは「存在しない」と誤って結論します。A は本当に注文がない顧客にもむだに再試行させます。D は回復できる一時的な失敗でも会話を止めてしまいます。
問12(1つ選んでください) lookup_order は注文の状態を数字(1=受付、2=発送、3=配達済み、4=返品済み)で返し、get_shipping は "in_transit" のような文字で返します。エージェントは状態 4 を「配達済み」と読み違えて、返品済みの注文にさらに返金しようとすることがあります。最も確実な対策はどれですか。
A. システムプロンプトに数字と状態の対応表を貼る B. PostToolUse フックで、モデルが結果を読む前に数字の状態を共通の文字の値(例: "returned")に変換する C. 状態の数字を読むたびに、別の Claude 呼び出しで意味を確かめさせる D. lookup_order を使うのをやめ、get_shipping だけで判断させる
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.5 PostToolUse での正規化
正解: B
PostToolUse フックはツールの結果がモデルに届く前に動き、形をそろえられます。数字のコードを決まった文字の値に変換すれば、読み違えが起きません。A は確率的で、毎回トークンも使います。C は遅く高くつきます。D は返品済みかどうかなど必要な情報を失います。
問13(1つ選んでください) 顧客が「返金ではなくポイントでほしい」と言っても、エージェントは process_refund を呼んでしまいます。process_refund の説明は「顧客にお金を返す」、issue_store_credit の説明は「顧客に補償を与える」です。最初にやるべき最も効果の高い改善はどれですか。
A. 2つのツールの説明に、それぞれの用途、入力、例の依頼(「ポイントで」「カードに戻して」)、似たツールとの使い分けを詳しく書く B. issue_store_credit を削除し、ポイントの希望はすべて人に回す C. 顧客の発言に「ポイント」という単語があれば issue_store_credit を呼ぶよう、前段にキーワードの振り分けを入れる D. 2つのツールを compensate_customer という1つのツールにまとめ、中で判断する
ドメイン2: ツール設計と MCP 統合 / 2.1 ツールの説明と境界
正解: A
ツールの説明文は、Claude がツールを選ぶ主な手がかりです。説明が短くあいまいだと、似たツールを取り違えます。まず説明を詳しくし、使い分けの境界を書くのが、手間が小さく根本原因に効く最初の一手です。C は作り込みすぎで言い換えに弱く、D は設計としてはありえても最初の一手としては手間が大きいです。
問14(1つ選んでください) サポートエージェントのループは、次のように書かれています。「応答の最初のブロックがテキストならループを抜けて顧客に返す。そうでなければツールを実行する」。Claude はよく「ご注文を確認しますね」という短いテキストの後に lookup_order の tool_use ブロックを出すため、ツールが実行されないまま顧客に返ってしまいます。最も適切な修正はどれですか。
A. テキストブロックが2つ以上あるときだけループを抜けるようにする B. 応答の stop_reason を見て、"tool_use" なら要求されたツールをすべて実行して結果を履歴に足し、"end_turn" ならループを抜ける C. システムプロンプトで、ツールを呼ぶ前にテキストを書かないよう指示する D. ループの反復を最大3回に固定し、3回目の応答を顧客に返す
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.1 エージェントループ
正解: B
ループの判定に stop_reason を使うのが正しい形です。Claude はツールを呼ぶ前に説明のテキストを書くことがあるので、テキストの有無は完了の目印になりません。"tool_use" ならツールを実行して tool_result を履歴に足し、"end_turn" で終えます。A は同じアンチパターンのままです。C は確率的で、根本の判定の誤りが残ります。D は反復上限を主な停止手段にするアンチパターンです。
問15(1つ選んでください) 顧客が1通のメッセージで「先月の注文の返品」「今月の請求が二重になっている件」「配送先住所の変更」の3つを頼みました。エージェントは最初の返品だけを処理して会話を終えてしまい、顧客は同じ説明を何度もくり返すことになります。最も良い設計はどれですか。
A. 依頼を3つの項目に分け、共有のコンテキスト(確認済みの顧客 ID、注文の一覧)を使ってそれぞれを調べ、結果を1つの回答にまとめて返す B. 1つ目を処理したら、残りは新しい問い合わせとして送り直すよう顧客に頼む C. 3つの依頼をすべて人の担当者にエスカレーションする D. 最も金額の大きい1件だけを処理する
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.4 複数の問題を含む依頼
正解: A
複数の問題を含む依頼は、個別の項目に分けて、共有のコンテキストで(必要なら並列に)調べ、1つの解決策にまとめるのが試験ガイドのパターンです。B は顧客の負担を増やし、初回解決率を下げます。C は自分で解決できる問題まで人に回します。D は残りの問題を放置します。
シナリオ2: Claude Code でのコード生成 あなたのチームは、ソフトウェア開発を速くするために Claude Code を使っています。コードの生成、リファクタリング、デバッグ、文書化に使います。カスタムのスラッシュコマンドや CLAUDE.md の設定で開発の流れに組み込み、plan mode と直接実行をいつ使い分けるかを決める必要があります。
問16(1つ選んでください) 注文の処理を非同期にするため、メッセージキューを導入します。候補は2つあり、一方は自前でブローカーを運用する方式、もう一方はマネージドサービスで、必要なインフラも再試行の設計も違います。影響するファイルは数十個です。最も適切な進め方はどれですか。
A. 直接実行で一方の方式を実装してみて、うまくいかなければもう一方に変える B. plan mode でコードと依存関係を調べ、2つの方式を比べて方針を決め、計画を承認してから直接実行で実装する C. 直接実行に、すべてのファイルの変更内容を最初に細かく指示して渡す D. 直接実行で始め、複雑だと感じたら plan mode に切り替える
ドメイン3: Claude Code の設定とワークフロー / 3.4 plan mode
正解: B
妥当な方法が複数あり、インフラの要件が違う統合方法を選ぶ判断は、plan mode の典型です。調査と計画は plan mode、実装は直接実行と組み合わせます。A は手戻りが大きくなります。C はコードを調べずに正しい方針がわかっている前提です。D は、複雑さが最初から要件に書かれているのに後回しにしています。
問17(1つ選んでください) ある開発者は、自分の Claude Code にだけ「説明は日本語で、コード例には必ず型注釈を付けて」と答えてほしいと考えています。この好みをチームのメンバーの Claude Code には影響させたくありません。どこに書くのが最も適切ですか。
A. リポジトリのルートの CLAUDE.md B. リポジトリの .claude/rules/preferences.md C. 自分の ~/.claude/CLAUDE.md(ユーザー単位) D. リポジトリの .mcp.json
ドメイン3: Claude Code の設定とワークフロー / 3.1 CLAUDE.md の階層
正解: C
ユーザー単位の ~/.claude/CLAUDE.md は、その人の全プロジェクトだけに効き、バージョン管理でチームに共有されません。個人の好みにはこれが合います(このプロジェクトだけなら、gitignore した CLAUDE.local.md も使えます)。A と B はコミットするとチーム全員に効きます。D は MCP サーバーの設定ファイルです。
問18(1つ選んでください) チームは分散キャッシュを初めて導入します。開発者はキャッシュの無効化や障害時の振る舞いに詳しくありません。Claude Code にいきなり実装させると、考慮が抜けた設計になりそうです。実装の前に最も役立つ進め方はどれですか。
A. 「よくある設計で実装して」と頼み、出てきたコードをそのまま使う B. temperature を下げて、確実な設計を出させる C. 実装の前に、Claude に開発者へ質問させ(無効化のタイミング、古いデータを許せる時間、キャッシュが落ちたときの動き など)、答えをもとに設計を決める D. キャッシュの導入をやめる
ドメイン3: Claude Code の設定とワークフロー / 3.5 インタビューパターン
正解: C
インタビューパターンは、なじみのない分野で、開発者が気づいていない考慮点を実装の前に引き出す方法です。A は考慮の抜けをそのまま持ち込みます。B は設計の抜けを解決せず、新しいモデルではサンプリングのパラメータ自体が使えません。
問19(1つ選んでください) API のミドルウェアの1つの関数に、「リクエストヘッダー X-Request-Id がなければ 400 を返す」というチェックを1つ足したいです。変更する場所と期待する動きははっきりしています。最も適切な進め方はどれですか。
A. plan mode でコードベース全体の設計を調べ、計画を承認してから実行する B. Explore サブエージェントで全ミドルウェアを調べてから決める C. インタビューパターンで、Claude に設計上の考慮点を10個質問させる D. 直接実行で、その関数にチェックを足し、テストを動かして確かめる
ドメイン3: Claude Code の設定とワークフロー / 3.4 直接実行
正解: D
範囲がはっきりしていて、方法も1つに決まっている小さな変更は、直接実行が向いています。A、B、C は設計の判断がある大きな仕事や、なじみのない分野のための方法で、この変更には手間が見合いません。
問20(1つ選んでください) Claude Code に2つの作業をさせます。(1) リポジトリの中の、名前が *.test.tsx のファイルをすべて見つける。(2) config.ts の中の timeout: 30 を、payment の設定の1か所だけ timeout: 60 に変える。ただし timeout: 30 はこのファイルの中に5か所あり、Edit は「一致が一意でない」として失敗しました。組み込みツールの使い方として最も適切なものはどれですか。
A. (1) は Grep で全ファイルの中身から "test" という文字を探す。(2) は Bash の sed で、ファイルの中の timeout: 30 をすべて置き換える B. (1) は Read でリポジトリのファイルを1つずつ開いて名前を確かめる。(2) は Write で新しい空の config.ts を作り直す C. (1) は Glob で **/*.test.tsx を探す。(2) は同じ入力の Edit を、成功するまで何度もくり返す D. (1) は Glob で **/*.test.tsx を探す。(2) は Read で config.ts 全体を読み、payment の1か所だけを直した全体を Write で書く
ドメイン2: ツール設計と MCP 統合 / 2.5 組み込みツールを適切に選んで使う
正解: D
名前や拡張子のパターンでファイルを探すのは Glob、ファイルの中身を検索するのは Grep です。Edit は、置き換える文字列がファイルの中で一意に決まるときに使うツールで、一意な目印がなくて失敗したときは、Read でファイル全体を読み、直した全体を Write で書くのが試験ガイドの示す代わりの方法です。A: 中身を検索する Grep では、名前のパターンに合うファイルを正しく選べません。sed ですべて置き換えると、変えてはいけない4か所まで変わります。B: 1つずつ開くのはむだが多く、空のファイルで作り直すと中身が消えます。C: 同じ入力の Edit は何度試しても一意にならず、同じように失敗します。
問21(1つ選んでください) モノレポの docs/conventions/ に、money.md、i18n.md、api-errors.md、logging.md の4つの規約ファイルがあります。請求パッケージには money.md と api-errors.md だけが関係し、画面のパッケージには i18n.md だけが関係します。各パッケージの担当者が、関係する規約だけを Claude Code に読ませたいです。最も保守しやすい方法はどれですか。
A. 各パッケージの CLAUDE.md で、関係する規約ファイルだけを @docs/conventions/money.md のように @import で読み込む B. 4つの規約ファイルの中身を、すべてルートの CLAUDE.md にコピーする C. 各パッケージの CLAUDE.md に、関係する規約の中身をコピーして貼る D. 規約をスキルにして、開発者に毎回 /conventions を呼んでもらう
ドメイン3: Claude Code の設定とワークフロー / 3.1 @import によるモジュール化
正解: A
@import を使えば、規約の本体を1か所に保ったまま、パッケージごとに関係するものだけを含められます。B は関係のない規約まで全員に読ませます。C はコピーが古くなり、保守が重くなります。D は呼ばれないと読み込まれません。なお import は整理の手段で、読み込んだファイルは一緒に全部入るので、コンテキストの量そのものは減りません。
問22(2つ選んでください) チームでデータベースのマイグレーションを作るスキル /generate-migration を用意します。条件は「リポジトリを clone した全員が使える」「対象のテーブル名を引数で受け取り、付け忘れたときに入力を促す」です。正しい設定を2つ選んでください。
A. リポジトリの .claude/skills/generate-migration/SKILL.md に作り、コミットする B. frontmatter に argument-hint(例: "[テーブル名]")を書く C. 各自の ~/.claude/skills/generate-migration/SKILL.md に作る D. スキルの手順をルートの CLAUDE.md に書き、常に読み込ませる
ドメイン3: Claude Code の設定とワークフロー / 3.2 スキルの置き場所と frontmatter
正解: A、B
チームで共有するスキルはプロジェクトの .claude/skills/ に置いてコミットします(古い形式の .claude/commands/ でも同じ /generate-migration になります)。引数の入力を促すのは argument-hint です。C は個人用で共有されません。D は毎セッション常に読み込まれ、作業のときだけ呼ぶスキルの利点を失います。
問23(1つ選んでください) チームは CI で Claude Code(claude -p)に PR をレビューさせ、結果を PR のインラインコメントとして自動で投稿しています。開発者が指摘を直して新しいコミットを push すると、レビューがもう一度動き、すでに直した指摘や前と同じ指摘が毎回また投稿されて、PR がコメントでうまってしまいます。最も効果的な改善はどれですか。
A. 再レビューのときは前回の指摘(場所と内容)をコンテキストに入れ、新しく生まれた問題と、まだ直っていない問題だけを報告させる B. 再レビューをやめ、PR を作った最初のコミットのときだけレビューする C. --output-format json をやめ、レビューの結果をふつうの文章で1つのコメントにまとめて投稿する D. コメントを投稿する前に、毎回 PR にある既存のコメントをすべて消す
ドメイン3: Claude Code の設定とワークフロー / 3.6 Claude Code を CI/CD パイプラインに組み込む
正解: A
CI での再レビューでは、前回の指摘をコンテキストに渡し、新しい問題とまだ直っていない問題だけを報告させると、同じコメントが重ならなくなります(試験ガイドのタスク 3.6 のスキル)。B: 後のコミットで入った新しい問題を見逃します。C: 機械が読める構造化結果がなくなり、インラインコメントとして自動で投稿しにくくなるうえ、重なりも解決しません。D: 人のやりとりや、直したかどうかの記録まで消えてしまいます。
問24(2つ選んでください) 大きなリファクタリングの調査で、Claude Code のセッションが数時間続いています。最初は具体的なクラス名やファイル名で答えていたのに、最近は「一般的にはこうします」と一般論で答えるようになり、前に決めた方針とも食い違い始めました。効果のある対策を2つ選んでください。
A. 同じ質問をもう一度して、前の答えを思い出させる B. 重要な発見(クラス名、依存関係、決めた方針)をスクラッチパッドのファイルに書かせ、後の質問ではそのファイルを参照させる C. コードベースの全ファイルを、もう一度 Read させる D. 探索の出力でコンテキストが埋まっているので、/compact で使用量を減らす(重要な事実は先にスクラッチパッドやCLAUDE.md に残しておく)
ドメイン5: コンテキスト管理と信頼性 / 5.4 長いセッションの劣化
正解: B、D
一般論を語り始めるのは、長いセッションでのコンテキストの劣化のサインです。スクラッチパッドのファイルに発見を残すと、コンテキストの境界をこえて参照できます(B)。探索の出力で埋まったコンテキストは /compact で減らします(D)。A は改善しません。C はコンテキストをさらに埋めます。
問25(1つ選んでください) 大きな移行を「調査のフェーズ」と「実装のフェーズ」に分け、それぞれでサブエージェントを使っています。実装のフェーズのサブエージェントが、調査のフェーズで見つかった注意点(古い API を使う3つのモジュールなど)を知らずに作業し、同じ問題に何度もぶつかっています。最も良い改善はどれですか。
A. 実装のサブエージェントに、調査のフェーズの会話の全文を渡す B. 実装のフェーズのサブエージェントを生成する前に、調査のフェーズの重要な発見を要約し、そのサブエージェントの最初のプロンプトに入れる C. 実装のサブエージェントに、調査をもう一度最初からやり直させる D. サブエージェントをやめ、すべてメインの会話で行う
ドメイン5: コンテキスト管理と信頼性 / 5.4 フェーズの間の要約
正解: B
サブエージェントは親や前のフェーズの文脈を自動では受け取りません。次のフェーズを始める前に重要な発見を要約し、最初のコンテキストに入れるのが効果的です。A は量が多すぎて要点が埋もれ、コンテキストも使います。C はむだです。D はメインのコンテキストが埋まる問題に戻ります。
問26(1つ選んでください) チームの /review スキルは、指摘を重大なものだけに絞っています。ある開発者は、自分のときだけ細かいスタイルの指摘まで出す厳しい版を使いたいです。チームの /review の動きは変えたくありません。最も適切な方法はどれですか。
A. チームの .claude/skills/review/SKILL.md を書き換えて、厳しくする B. ~/.claude/skills/review-strict/SKILL.md のように、ユーザー単位に別の名前で個人用のスキルを作る C. ルートの CLAUDE.md に「この開発者のときは厳しくレビューすること」と書く D. /review を呼ぶたびに、長い追加の指示を手で入力する
ドメイン3: Claude Code の設定とワークフロー / 3.2 個人用の変種
正解: B
個人用の変種は ~/.claude/skills/ に別の名前で作り、チームに影響させません。A はチーム全員の /review を変えてしまいます。C はチームの共有ファイルに個人の事情を入れることになり、Claude には誰が使っているかもわかりません。D はくり返しの手間がかかり、ぶれます。
問27(1つ選んでください) Claude Code が作ったモジュールに3つの問題があります。(1) user_id を account_id に名前を変える必要がある、(2) その名前の変更に合わせて入力の検証とシリアライザーも変える必要がある、(3) 別の画面のログの文言に誤字がある。最も良い伝え方はどれですか。
A. 互いに影響する (1) と (2) は1つの詳しいメッセージでまとめて伝え、独立した (3) は別に直してもらう B. 3つを1つずつ、別々のメッセージで順番に直してもらう C. 3つを1つの短いメッセージで「全部直して」と伝える D. (3) を先に直し、(1) と (2) は次のセッションで別々に伝える
ドメイン3: Claude Code の設定とワークフロー / 3.5 まとめて伝えるか順番に直すか
正解: A
修正が互いに影響するときは、1つの詳しいメッセージで伝えます。ばらばらに頼むと、後の修正が前の修正と食い違うことがあります。独立した問題は順番に直してかまいません。B は (1) と (2) の整合が崩れやすく、C は詳しさが足りず、D は関係する修正を分けてしまいます。
問28(1つ選んでください) ルートの CLAUDE.md に、週に1回しか使わない45行のリリース手順(タグの付け方、変更履歴の作り方、確認の順番)が書かれています。毎セッション読み込まれるためコンテキストを使い、ほかの指示も守られにくくなっています。最も良い整理はどれですか。
A. 手順を ~/.claude/CLAUDE.md に移す B. 手順を短く要約して、CLAUDE.md に残す C. 手順をプロジェクトのスキル(例: .claude/skills/release/SKILL.md)に移し、リリースのときに呼び出す。CLAUDE.md には常に必要な共通の決まりだけを残す D. 手順を削除し、リリースのたびに口頭で説明する
ドメイン3: Claude Code の設定とワークフロー / 3.2 スキルと CLAUDE.md の使い分け
正解: C
CLAUDE.md は常に読み込まれる共通の決まり、スキルは特定の作業のときに呼ぶ手順、という使い分けです。たまにしか使わない複数ステップの手順はスキルに移すと、ふだんのコンテキストを節約できます。A はチームに共有されなくなります。B は手順の情報を失います。D は手順がぶれます。
問29(1つ選んでください) 同じリポジトリで作業する2人の開発者の Claude Code が、テストの書き方について違う振る舞いをします。どの CLAUDE.md やメモリファイルがそれぞれのセッションに関わっているかを確かめて、原因を診断したいです。最初に使うべきものはどれですか。
A. /init で CLAUDE.md を作り直す B. /compact で会話を要約する C. /clear で会話をリセットする D. /memory でメモリファイルの一覧と中身を確かめる(今のバージョンでは /context all で実際に読み込まれたファイルも確認できる)
ドメイン3: Claude Code の設定とワークフロー / 3.1 /memory による診断
正解: D
/memory は、ユーザー単位とプロジェクト単位の CLAUDE.md などのメモリファイルを一覧し、開いて中身を確かめられます。試験ガイドはこれを診断の方法としています。今の公式ドキュメントでは、セッションに実際に読み込まれたファイルを /context all の Memory files で確かめることも勧めています。A は既存の設定を作り直すもので、原因の診断ではありません。
問30(1つ選んでください) 返金の処理を変える前に、「返金フローの依存関係をすべてたどる」「関係するテストファイルを全部探す」という2つの調べものが必要です。前回は、メインの会話でこれをやったため、大量の検索結果でコンテキストが埋まりました。最も良い進め方はどれですか。
A. メインの会話で、2つの調べものを順番に全部やる B. 調べものをやめ、変更を始める C. それぞれの具体的な問いを調べるサブエージェント(例: Explore)を生成し、メインには要約だけを返させて、メインは全体の調整を続ける D. 2つの調べものの結果を、すべて CLAUDE.md に貼っておく
ドメイン5: コンテキスト管理と信頼性 / 5.4 サブエージェントで探索を分ける
正解: C
量の多い探索の出力はサブエージェントに任せて分離し、メインのエージェントは全体の理解と調整を保ちます。具体的な問いごとにサブエージェントを生成するのが試験ガイドのパターンです。A は前回と同じ問題を起こします。D は毎セッション大量の内容を読み込ませることになります。
問31(1つ選んでください) 料金の計算関数を Claude Code に作らせると、ふつうのケースは正しいのに、端数の丸めや割引の上限などの例外ケースで毎回どこかが間違います。何度か文章で指摘しましたが、直すと別の所が壊れます。最も効果的な進め方はどれですか。
A. 毎回、間違いを見つけたら文章でもっと強く指摘する B. 関数の実装をすべて自分で書き、Claude Code は使わない C. モデルを大きいものに変える D. 期待する動き、例外ケース(丸め、上限)、性能の要件を含むテストを先に書き、Claude に実装させて、失敗したテストの結果を共有しながら直させる
ドメイン3: Claude Code の設定とワークフロー / 3.5 テスト駆動の反復
正解: D
テスト駆動の反復では、先にテストを書き、テストの失敗を Claude に見せて改善させます。どの例外ケースが壊れたかが毎回はっきりし、直したことで別の所が壊れてもすぐわかります。A はあいまいさが残ります。C は根本の進め方の問題を解決しません。
問32(1つ選んでください) GraphQL のリゾルバーは、機能ごとのフォルダー(src/features/orders/resolvers/、src/features/users/resolvers/ など30か所以上)に散らばっています。リゾルバーを編集するときだけ、エラーの返し方と認可のチェックの決まりを自動で当てたいです。最も保守しやすい方法はどれですか。
A. .claude/rules/graphql-resolvers.md を作り、YAML frontmatter に paths: ["src/features/**/resolvers/**/*.ts"] を書く B. 30か所以上の resolvers フォルダーそれぞれに、同じ内容の CLAUDE.md を置く C. ルートの CLAUDE.md に書き、Claude にどれがリゾルバーかを推測させる D. 決まりをスキルにして、リゾルバーを編集する前に毎回呼んでもらう
ドメイン3: Claude Code の設定とワークフロー / 3.3 パス別ルール
正解: A
コードのあちこちに散らばったファイルに同じ規約を当てるには、glob の paths を持つルールが向いています。合うファイルを扱うときだけ読み込まれます。B はディレクトリに縛られ、30か所のコピーの保守が重くなります。C は推測に頼り、関係ない作業でも読み込まれます。D は呼び忘れると効きません。
シナリオ3: マルチエージェント調査システム あなたは Claude Agent SDK で、マルチエージェントの調査システムを作っています。コーディネーターのエージェントが、専門のサブエージェントに仕事を任せます。1つは Web を検索し、1つは文書を分析し、1つは結果を統合し、1つは報告書を作ります。システムはテーマを調べ、出典付きの総合的な報告書を作ります。
問33(1つ選んでください) 調査システムの最終レポートは、財務の数字、最近のニュース、技術的な結果を、すべて同じ形の箇条書きで並べています。研究者の間で意見が分かれている結果も、確立した結果と同じ書き方で混ざっています。さらに、2019年の統計と2025年の統計が並んで「矛盾している」と書かれていました。最も適切な改善はどれですか。
A. 読みやすくするため、すべてを同じ形の短い文章にそろえ、日付は省く B. サブエージェントの構造化出力に公開日やデータ収集日を必ず入れさせ、レポートは確立した結果と議論のある結果を節で分け、内容に合った形(財務は表、ニュースは文章、技術的な結果は構造化リスト)で書かせる C. 議論のある結果は読み手を混乱させるので、統合の段階で新しいほうの値だけを残し、ほかは消す D. 出典の URL は最後にまとめて一覧にし、どの主張がどの出典から来たかの対応は省いて短くする
ドメイン5: コンテキスト管理と信頼性 / 5.6 複数の情報源をまとめるとき、出典を保ち不確かさを扱う
正解: B
出典と不確かさの扱いでは、公開日やデータ収集日を構造化出力に入れて時期の違いを矛盾と取りちがえないようにし、確立した結果と議論のある結果を分けて示し、内容の種類に合った表現を選びます(B)。A: 日付を消すと時期の違いがわからなくなり、形をそろえすぎると内容に合いません。C: 食い違いや議論は、勝手にどちらかを選ばず、出典付きで示します。D: 主張と出典の対応がなくなると、どの数字をどこで確かめればよいかわからなくなります。
問34(1つ選んでください) 処理を速くするため、チームから「Web 検索サブエージェントが結果を統合サブエージェントに直接送り、コーディネーターを通さないようにしよう」という提案が出ました。アーキテクトとしての判断として最も適切なものはどれですか。
A. 提案を採用し、すべてのサブエージェントが自由に互いを呼べるようにする B. サブエージェント間の通信はコーディネーターを通す形を保つ。何が起きたかを1か所で見られ、エラー処理をそろえ、情報の流れを制御できるため C. コーディネーターをなくし、統合サブエージェントに全体の指揮を任せる D. Web 検索と統合を1つのサブエージェントにまとめる
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.2 ハブ・アンド・スポーク
正解: B
ハブ・アンド・スポーク型では、コーディネーターがサブエージェント間のすべての通信、エラー処理、情報の振り分けを管理します。直接の通信を許すと、可観測性と一貫したエラー処理が失われます。速さが問題なら、まず並列の呼び出しなどを検討します。C と D は役割の分離を崩します。
問35(1つ選んでください) 関係する40本の資料の読み込みと分析が1つのセッションで終わりました。ここから、報告書の構成を「地域別」にした場合と「技術別」にした場合の2案を作って比べたいです。分析をやり直さずに進める最も良い方法はどれですか。
A. 新しいセッションを2つ作り、それぞれで40本の資料を読み直す B. fork_session で、分析が終わった時点から2つの独立した枝を作り、それぞれで別の構成を試す C. 同じセッションで地域別を作り、その後に同じセッションで技術別を作る D. --resume で同じセッションを2つの端末から同時に再開する
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.7 fork_session
正解: B
フォークは、元の履歴をコピーした新しいセッションを作り、共通の分析を起点に別々の方針を試す方法です。元のセッションは変わりません。A は分析のやり直しでむだです。C は1案目の内容が2案目に影響します。D は同じ履歴に2つの流れが書き込まれ、比べる形になりません。
問36(1つ選んでください) コーディネーターは「電気自動車の電池のリサイクル」を、2つの Web 検索サブエージェントに同じ依頼文で配っています。結果を比べると、2つが返した資料の7割が同じでした。費用がかかるうえ、網羅も広がりません。最も良い改善はどれですか。
A. Web 検索サブエージェントを5つに増やす B. 同じ資料が出たら、統合サブエージェントで重複を消す C. 1つの Web 検索サブエージェントだけにする D. コーディネーターが調査の範囲を分けて割り当てる(例: 一方は技術と工程、もう一方は政策と市場。または一方は学術論文、もう一方は業界の報告と報道)
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.2 調査範囲の割り当て
正解: D
重複を減らすには、サブトピックや情報源の種類ごとに調査範囲を分けて割り当てます。A は重複をさらに増やします。B は費用のむだを後から片付けるだけで、網羅は広がりません。C は並列の利点を失います。
問37(1つ選んでください) レポート作成サブエージェントが作る報告書に、出典が1つも付いていません。調べると、コーディネーターは統合サブエージェントの出した散文の要約だけを、レポート作成サブエージェントへのプロンプトに入れていました。最も良い修正はどれですか。
A. レポート作成サブエージェントに、出典を自分で Web 検索させる B. レポート作成サブエージェントのシステムプロンプトに「必ず出典を付けること」と書く C. 統合の出力を、主張ごとに出典の URL、文書名、ページ、抜粋を分けて持つ構造化データにし、それをそのままレポート作成サブエージェントのプロンプトに入れる D. コーディネーターの会話履歴を、レポート作成サブエージェントが読めるようにする設定を探す
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.3 コンテキストの受け渡し
正解: C
サブエージェントはプロンプトで渡されたものしか知りません。出典を保つには、本文とメタデータを分けた構造化データで渡します。B は材料がないので、出典を作り話する危険があります。A は役割外の仕事で重複します。D について、サブエージェントは親の会話履歴を自動では受け取らない設計です。
問38(1つ選んでください) 論文データベースの MCP ツールは、有料の論文にアクセスすると 403 を受け取ります。ツールは「エラー」とだけ返すため、文書分析サブエージェントは同じ論文を5回ずつ再試行し、時間を使い切っています。最も良い改善はどれですか。
A. 再試行の回数を10回に増やす B. 403 のときは空の結果を成功として返す C. 403 を受け取ったら、調査のワークフロー全体を止める D. isError を付け、種類は権限のエラー、再試行できない(isRetryable: false)ことと説明を返す。サブエージェントは再試行せず、試したことと代わりの情報源(要旨、公開版の論文など)を添えてコーディネーターに伝える
ドメイン2: ツール設計と MCP 統合 / 2.2 再試行できないエラー
正解: D
権限のエラーは、くり返しても成功しません。種類と再試行の可否を構造化して返せば、むだな再試行を防げます。解決できないエラーは、試したことと代案を添えてコーディネーターに伝えます。A は時間をさらに使い、B は失敗を隠し、C は回復できる調査まで止めます。
問39(2つ選んでください) 調査システムを、社内で使っている課題管理サービス(広く使われている SaaS)と、チーム独自の「調査依頼の承認フロー」につなぎたいです。試験ガイドの考え方に合うものを2つ選んでください。
A. 課題管理サービスの連携も、ゼロから自作の MCP サーバーを作る B. 課題管理サービスには、信頼できる既存の(公式やコミュニティの)MCP サーバーを使う C. 承認フローも、課題管理サービスの既存の MCP サーバーの中で動くよう、そのサーバーのコードを書き換える D. チーム独自の承認フローは、自作の MCP サーバーで提供する
ドメイン2: ツール設計と MCP 統合 / 2.4 既存の MCP サーバーと自作
正解: B、D
標準的な連携には既存の MCP サーバーを選び(B)、自作はチーム固有のワークフローに限ります(D)。A は不要な開発と保守を増やします。C は他者のサーバーを改造することになり、更新のたびに保守が重くなります。既存のサーバーは、信頼できる提供元のものを選びます。
問40(2つ選んでください) 調査システムの Web 検索サブエージェントは、1回だけのタイムアウトでも、すぐコーディネーターに「失敗」を返しています。また、ある情報源が最後まで使えなかったとき、コーディネーターは調査全体を止めて、利用者に何も返しません。試験ガイドの考え方に合う改善を2つ選んでください。
A. 失敗したときは空の結果を成功として返し、コーディネーターに失敗を見せないようにする B. 一時的な失敗はサブエージェントがその場で再試行して回復し、解決できないエラーだけを、失敗の種類、試したこと、部分的な結果と一緒にコーディネーターに伝える C. どの情報源のエラーでも、ワークフロー全体を止め、利用者に最初からやり直してもらう D. 1つの情報源が使えなくても、取れた結果で統合を続け、レポートに網羅の注記(十分に裏付けのある分野と、情報源が使えず抜けがある分野)を付ける
ドメイン5: コンテキスト管理と信頼性 / 5.3 マルチエージェントシステムでのエラー伝播の戦略
正解: B、D
エラー伝播の設計では、サブエージェントが一時的な失敗をその場で回復し、解決できないものだけを、失敗の種類・試したこと・部分的な結果などの構造化された文脈と一緒に伝えます(B)。コーディネーターは取れた結果で先に進め、どの分野に抜けがあるかを網羅の注記で示します(D)。A: 失敗を黙って握りつぶすと、「該当なし」と区別できず、まちがった結論になります。C: 1つの失敗でワークフロー全体を止めるのも、試験ガイドが挙げるアンチパターンです。
問41(1つ選んでください) 社内の調査資料のライブラリは、MCP サーバーの list_folders、list_documents、search_documents ツールで探します。文書分析サブエージェントは、どんな資料があるかを知るだけで毎回10回以上ツールを呼んでいます。最も良い改善はどれですか。
A. ツールの呼び出し回数に上限を付ける B. すべての資料の本文をシステムプロンプトに貼る C. 資料ライブラリの目次(フォルダーの階層、文書名、要約)を MCP リソースとして公開し、探索のためのツール呼び出しなしで全体を見渡せるようにする D. search_documents だけを残し、ほかのツールを消す
ドメイン2: ツール設計と MCP 統合 / 2.4 MCP リソース
正解: C
MCP リソースで内容の一覧(文書の階層、要約など)を見せると、探索のためのツール呼び出しが減ります。A は必要な探索まで止めます。B はコンテキストを浪費し、資料も古くなります。D は、どんな資料があるかを知るための検索がまだ何度も必要です。
問42(1つ選んでください) コーディネーターに、すべてのサブエージェントのツール(検索、文書の読み込み、統合用、レポート用など)を合わせた18個を渡しています。するとコーディネーターは委任せずに自分で検索を始め、ツールの選び間違いも増えました。最も良い設計はどれですか。
A. コーディネーターに渡すツールを30個に増やす B. コーディネーターには委任と全体の管理に必要なツール(サブエージェントを起動するツールなど)だけを渡し、専門のツールは各サブエージェントに役割ごとに配る C. コーディネーターのシステムプロンプトに「自分で検索しないこと」と書く D. サブエージェントをなくし、コーディネーターに18個のツールで全部やらせる
ドメイン2: ツール設計と MCP 統合 / 2.3 ツールの配分
正解: B
ツールが多すぎると選択の信頼性が下がり、役割外のツールは誤用されます。各エージェントには、その役割に必要なツールだけを渡します。C は確率的で、ツールが残る限り誤用の可能性があります。A と D は問題を悪くします。
問43(1つ選んでください) 利用者の依頼は「わが社の主力製品の売上が、なぜこの半年で地域によって大きく違うのか調べて」です。何が原因かは事前にわかりません。コーディネーターの分解のしかたとして最も適切なものはどれですか。
A. 検索 → 分析 → 統合 → レポートの決まった4段階を一度だけ通す B. 最初に50個の決まった質問を作り、すべてを並列に調べる C. まず全体の構造(地域、期間、関係しそうな要因)を把握し、影響の大きそうな手がかりから調べ、途中の発見に合わせて次のサブタスクを作り直す動的な分解にする D. 利用者に、原因の候補をすべて挙げてもらってから始める
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.6 タスク分解の戦略
正解: C
答えが決まっていない調査には、途中の発見に応じてサブタスクを作る動的な分解が向いています。A の固定のチェーンは、予測できる多面的な仕事向けです。B は的外れな質問にも費用をかけ、発見に合わせて変えられません。D は調べる仕事を利用者に押し付けています。
問44(1つ選んでください) 文書分析サブエージェントは fetch_url ツールを持っており、渡された文書を読むだけでなく、関係のない Web ページを次々に開いて Web 検索サブエージェントの仕事と重なっています。最も良い対策はどれですか。
A. fetch_url を、文書の URL(許可した文書の保存場所や形式)であることを検証してから読む load_document のような制約付きのツールに置き換える B. fetch_url の説明に「Web ページは開かないこと」と書き足すだけにする C. 文書分析サブエージェントにも WebSearch を渡し、検索サブエージェントをなくす D. fetch_url の呼び出し回数を1回に制限する
ドメイン2: ツール設計と MCP 統合 / 2.3 汎用ツールを制約付きにする
正解: A
何でも読める汎用のツールは、専門外の使い方を招きます。目的に合った制約付きのツールに置き換えると、役割を超えた使い方ができなくなります。B は確率的です。C は役割の分離をさらに崩します。D は複数の文書を読む本来の仕事までできなくなります。
問45(1つ選んでください) 「都市の暑さ対策」の報告書を作ったところ、緑化と建物の素材の話は詳しいのに、健康への影響と費用の面がほとんど書かれていませんでした。各サブエージェントは頼まれた範囲を正しく調べています。コーディネーターの設計として最も良いものはどれですか。
A. 統合の結果をコーディネーターが評価して抜けている観点を見つけ、その観点だけを絞った問いで検索・分析サブエージェントに再委任し、十分な網羅になるまで統合をやり直す B. 報告書の最後に「健康と費用は調査の範囲外」と書き足す C. 統合サブエージェントに、抜けている部分を自分の知識で補わせる D. 最初から全部をやり直す
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.2 反復改善ループ
正解: A
試験ガイドの反復改善ループです。コーディネーターが統合の結果の抜けを評価し、絞った問いで再委任し、網羅できるまで統合を回します。B は利用者の求める網羅を満たしません。C は出典のない内容を混ぜます。D は有効な結果まで捨てるむだです。
問46(1つ選んでください) コーディネーターのログを見ると、4つのサブトピックについて、1つ目の Task 呼び出しを出して結果を待ち、次のターンで2つ目を出す、という順番をくり返しています。4つのサブトピックは互いに独立しています。全体の時間を最も縮める方法はどれですか。
A. コーディネーターが1回の応答の中で4つの Task(今の名前は Agent)呼び出しを並べて出し、サブエージェントを並列に動かすようにする B. サブエージェントの max_turns を減らす C. サブトピックを2つに減らす D. コーディネーターのモデルを小さくして、各ターンを速くする
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.3 並列の生成
正解: A
複数のサブエージェントを並列に動かすには、1回のコーディネーターの応答で複数の Task 呼び出しを出します。別々のターンに分けると、前の結果を待つことになります。B は仕事の途中で止まる危険があり、C は網羅を減らし、D は待ちの構造を変えません。
問47(1つ選んでください) レポート作成サブエージェントには render_narrative_report と render_table_report の2つのツールがあります。サブエージェントがツールを呼ばずに、会話の文章で報告書を返してしまうことがあり、下流の処理が止まります。強制のツール選択が使える世代のモデルで、どちらかのツールを必ず呼ばせたいとき、最も合う設定はどれですか。
A. tool_choice: {"type": "auto"} B. tool_choice: {"type": "none"} C. tool_choice: {"type": "any"} D. tool_choice: {"type": "tool", "name": "render_table_report"}
ドメイン2: ツール設計と MCP 統合 / 2.3 tool_choice
正解: C
"any" は、どれか1つのツールを必ず呼ばせ、会話の文章だけで終わらせません。どちらの形が合うかは内容によるので、D のように1つに決め打ちしません。A はテキストだけを返すことがあります。なお Claude Opus 5.5・Sonnet 5.5 などの新しいモデルでは "any" が 400 エラーになるため、auto と strict: true とプロンプトの指示で導くか、構造化出力を使います。
問48(1つ選んでください) コーディネーターのプロンプトには、サブエージェントへの40段階の手順(「まず検索語Aで検索し、次に上位3件を開き…」)が細かく書かれています。想定外の情報源(PDF しかない政府の資料など)に当たると、サブエージェントは手順どおりに進めず失敗します。最も良い改善はどれですか。
A. 手順をさらに増やし、想定外のケースもすべて書き足す B. サブエージェントを1つにまとめ、手順を簡単にする C. 失敗したら、コーディネーターがその仕事を自分で引き受ける D. 細かい手順の代わりに、調査の目的、出力の形、品質の基準(例: 一次資料を優先、日付と出典を必ず付ける)、仕事の範囲を伝え、やり方はサブエージェントに任せる
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.3 コーディネーターのプロンプト
正解: D
コーディネーターのプロンプトは、手順の細かい指示ではなく、目的と品質の基準を示し、サブエージェントが状況に合わせて動けるようにするのが試験ガイドの考え方です。A はきりがなく、想定外には必ず漏れが出ます。B と C は専門化と委任の利点を失います。
問49(2つ選んでください) Agent SDK で、コーディネーターと4種類のサブエージェントを設定します。試験ガイドのベストプラクティスに合う設定を2つ選んでください。
A. 統合サブエージェントの AgentDefinition では、tools を統合に必要なもの(例: verify_fact と Read)だけに絞る B. すべてのサブエージェントに WebSearch と WebFetch を持たせ、どのサブエージェントでも検索できるようにする C. コーディネーターの allowedTools に、サブエージェントを起動するツール(ガイドの名前は "Task"、今の名前は "Agent")を入れる D. サブエージェントのプロンプトには何も書かず、コーディネーターの会話履歴から必要な情報を読ませる
ドメイン1: エージェント型アーキテクチャとオーケストレーション / 1.3 AgentDefinition と allowedTools
正解: A、C
AgentDefinition でサブエージェントの種類ごとにツールを制限し(A)、コーディネーターがサブエージェントを呼べるよう起動用のツールを allowedTools に入れます(C)。B は専門外のツールの誤用と重複を招きます。D は誤りで、サブエージェントは親の会話履歴を自動では受け取らないので、必要な情報はプロンプトで明示的に渡します。
シナリオ6: 構造化データ抽出 あなたは Claude を使って、構造化データの抽出システムを作っています。システムは非構造化の文書から情報を抜き出し、JSON スキーマで出力を検証し、高い精度を保ちます。例外的なケースをうまく扱い、下流のシステムとつなぐ必要があります。
問50(2つ選んでください) 受付に届く書類は請求書・注文書・領収書のどれかですが、種類は事前にわかりません。3つの抽出ツール(それぞれ JSON スキーマ付き)を用意し、必ずどれかのツールの構造化出力を得たいです。正しい説明を2つ選んでください。
A. 強制のツール選択が使える世代のモデルでは、tool_choice: {"type": "any"} にすると、必ずどれかの抽出ツールが呼ばれる B. Claude Opus 5.5 や Sonnet 5.5 のような新しいモデルでは "any" が 400 エラーになるので、tool_choice は "auto" にして各ツールに strict: true を付け、必ずどれかのツールを使うようプロンプトで指示する(または構造化出力を使う) C. 新しいモデルでは、temperature を 0 にすれば必ずツールが呼ばれる D. どのモデルでも、tool_choice: {"type": "tool", "name": "extract_invoice"} にすれば、3種類の書類すべてを正しく扱える
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.3 tool_choice と新しいモデル
正解: A、B
種類がわからないときに必ずどれかを呼ばせるのは "any" です(A)。新しいモデルでは強制が使えないため、auto と strict: true とプロンプトの指示、または構造化出力に置き換えます(B)。C は、新しいモデルではサンプリングのパラメータ自体が 400 エラーになり、ツールの呼び出しも保証しません。D は請求書のツールに決め打ちしており、注文書や領収書に合いません。
問51(1つ選んでください) 抽出の後に Pydantic で検証し、「明細の合計 48,000 円が総額 52,800 円と一致しない」のような意味のエラーを見つけています。今の再試行は、最初と同じプロンプトをもう一度送るだけで、多くの場合同じ結果に戻ります。最も効果的な改善はどれですか。
A. 再試行のリクエストに、元の文書、失敗した抽出の結果、具体的な検証エラーの内容を入れ、どこを直すべきかがわかるようにする B. 再試行の回数を5回に増やす C. 検証をやめ、最初の抽出結果をそのまま使う D. 再試行のときだけ、別の会社のモデルを使う
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.4 エラーを伝えて再試行
正解: A
具体的な検証エラーを再試行のプロンプトに入れると、モデルは何を直せばよいかわかり、自己修正できます。同じプロンプトの再送(B)は同じ誤りをくり返しがちです。C は誤ったデータを下流に流します。
問52(1つ選んでください) 抽出の精度を上げるため、今は同じ会話の中で「今の抽出結果をもう一度見直して、間違いがあれば直して」と頼んでいます。しかし見直しでは、ほとんど誤りが見つかりません。最も効果的な改善はどれですか。
A. 抽出の推論のコンテキストを持たない、独立した別の Claude インスタンスに、元の文書と抽出結果を渡して検証させる。各項目に確信度も付けさせ、振り分けに使う B. 同じ会話で、もっと強い言葉で「厳しく見直して」と頼む C. 同じ会話で extended thinking の量を増やして見直させる D. 見直しをやめる
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.6 独立したインスタンスでの検証
正解: A
同じ会話のモデルは、抽出のときの推論を持っているので、自分の判断を疑いにくいです。生成の文脈を持たない独立したインスタンスのほうが、微妙な誤りを見つけやすいです。確信度を付けさせれば、レビューの振り分けにも使えます(その確信度は検証セットで調整してから使う)。B と C は同じ文脈のままです。
問53(1つ選んでください) 10,000件の文書のバッチのうち、3%が errored になりました。原因の多くは、とても長い文書がコンテキストの上限を超えたことでした。残りは succeeded です。最も効率的な対応はどれですか。
A. 10,000件すべてを、もう一度バッチで送り直す B. 失敗した文書は捨てて、成功した97%だけで進める C. バッチをやめ、すべて同期の API で処理し直す D. 失敗したものを custom_id で特定し、長すぎる文書を分割するなど原因を直してから、失敗した分だけを再投入する
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.5 バッチの失敗の処理
正解: D
custom_id でリクエストと結果を対応づけ、失敗した文書だけを特定し、原因に合った修正(コンテキスト上限を超えた文書の分割)をして再投入します。A は成功した分の費用と時間をむだにします。B はデータを失います。C はコストの利点を捨てます。
問54(1つ選んでください) 200ページの基本契約書から、解約、損害賠償、秘密保持などの条項を抜き出しています。最初と最後の章にある条項は正しく取れますが、文書の中ほどにある条項の抜けが目立ちます。最も効果的な対策はどれですか。
A. 抜き出す条項の一覧を、プロンプトの中ほどにも書く B. 文書を章ごとに分けて処理し、それぞれの結果を集めるとき、最初に重要な結果の要約を置き、詳細は章の見出しで整理する(長い文書を1回で渡すなら、文書を上に、指示と問いを後ろに置き、先に関係する箇所を引用させる) C. 契約書を要約してから、要約から条項を抜き出す D. 最初の50ページと最後の50ページだけを渡す
ドメイン5: コンテキスト管理と信頼性 / 5.1 lost in the middle
正解: B
長い入力では中ほどの内容が抜けやすくなります(lost in the middle)。分けて処理する、集めた入力の最初に重要な要約を置く、見出しで整理する、などで位置の影響を減らします。C は要約の段階で条項の細部が消えます。D は中ほどの条項を最初から捨てています。
問55(2つ選んでください) 抽出の失敗を分類しました。検証エラーを伝えて再試行することで直る見込みが高いものを2つ選んでください。
A. 日付が「2025/03/04」の形で出ていて、決めた YYYY-MM-DD の形に合わない B. 請求書に発注番号がそもそも書かれていない C. 明細の配列のはずの項目に、明細が1つの文字列としてまとめて入っている D. 総額が、今回は渡していない別添の見積書にだけ書かれている
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.4 再試行が効くかどうか
正解: A、C
書式の不一致(A)や出力の構造のエラー(C)は、具体的なエラーを伝えた再試行で直せます。必要な情報が元の文書にない(B)、または渡していない別の文書にしかない(D)場合は、何度再試行しても直りません。その場合は null にして人に回すか、必要な文書を入力に加えます。
問56(1つ選んでください) 毎日届く大量の文書を Message Batches API で処理します。業務の約束(SLA)は「文書が届いてから36時間以内に結果を出す」です。バッチは最大24時間かかると考えます。文書を集めてバッチにまとめて投入する間隔として、SLA を守れる最も適切なものはどれですか。
A. 1日1回(24時間ごと)に投入する B. 少なくとも12時間ごと、余裕を見てたとえば8時間ごとに投入する C. 36時間ごとに投入する D. バッチは時間が読めないので、すべて同期の API に切り替える
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.5 SLA と投入の間隔
正解: B
届いた文書が投入まで待つ最大の時間と、バッチの最大の処理時間の合計が SLA に収まる必要があります。36 − 24 = 12時間なので、12時間以内ごとに投入すればよく、余裕を見て8時間ごとなどにします。A は最悪で 24 + 24 = 48時間かかります。C はさらに悪化します。D は、待たなくてよい処理で50%の削減を捨てることになります。
問57(1つ選んでください) 確信度の高い抽出を自動で通すようにして3か月がたちました。最近、取引先が新しい様式の請求書を使い始めています。自動で通している抽出の誤り率を続けて測り、新しい誤りのパターンに早く気づくには、どうするのが最も良いですか。
A. 確信度の低い抽出だけを人が見続ける B. 利用者から苦情が来たときだけ調べる C. 確信度の高い抽出からも、文書の種類や取引先などの層ごとにランダムに少しずつ取り出して人が確かめる D. 確信度のしきい値を毎月少しずつ下げていく
ドメイン5: コンテキスト管理と信頼性 / 5.5 層別ランダムサンプリング
正解: C
層別ランダムサンプリングは、自動で通している確信度の高い抽出の誤り率を測り、新しい誤りのパターンを見つける方法です。A では自動で通した側の誤りに気づけません。B は見つかるのが遅すぎます。D は根拠なくレビューを減らす方向です。
問58(1つ選んでください) 手書きの発注書から数量を抜き出しています。「半ダース」「2箱(1箱12個)」「約3kg」のようなくだけた書き方のときに、数量や単位がよく間違います。最も効果的な改善はどれですか。
A. くだけた単位の表記を含む入力と、期待する正規化した出力(数量、単位、元の表記)の few-shot 例を加える B. くだけた表記がある発注書は、すべて捨てる C. スキーマの数量の型を文字列にして、何でも入るようにする D. 「単位に気をつけること」と指示に書く
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.2 くだけた単位の表記
正解: A
few-shot 例は、くだけた単位の表記のような抽出の難しいケースの扱いを示し、ハルシネーションも減らします。元の表記も残すと検証しやすくなります。C は下流で使える値でなくなります。D は一般的な指示で、ぶれが残ります。
問59(1つ選んでください) 請求書の抽出結果に「要確認」の印を付ける仕組みがあります。今の指示は「怪しい点があれば要確認にして」です。全体の4割に印が付き、経理の担当者は印を見なくなりました。最も効果的な改善はどれですか。
A. 「本当に怪しいときだけ」と、指示をもっと強い言葉にする B. 印を付ける条件を具体的に決める(例: 明細の合計と総額が1円以上ずれる、請求日が支払期日より後、取引先コードが登録にない)。それ以外の表記の揺れなどでは付けない C. 印の数を1日100件までに制限する D. 印を付ける機能をやめる
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.1 明確な基準
正解: B
「怪しい点」のようなあいまいな指示より、何を報告し何を飛ばすかの明確な基準のほうが精度を上げます。誤検知が多いと、正しい印まで信頼されなくなります。A は一般的な指示のままです。C は本当の問題も落とします。D は役に立つ確認の仕組みを失います。
問60(1つ選んでください) 研究論文から「対象者の人数」と「研究の方法」を抜き出しています。方法を独立した章に書く論文は正しく抜き出せますが、本文の途中に方法が埋め込まれている論文では、人数が null になったり、別の研究の人数を拾ったりします。最も効果的な改善はどれですか。
A. 人数の項目を必須にして、null を許さないようにする B. 論文の最初の1ページだけを渡すようにする C. モデルを大きいものに変える D. 方法の章がある論文と、本文に方法が埋め込まれた論文の両方について、正しく抜き出した few-shot 例を加える(引用された別の研究の数字を拾わない例も含める)
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.2 文書構造の few-shot
正解: D
few-shot 例は、さまざまな文書構造の正しい扱いを示し、必須の項目が空になる問題やハルシネーションを減らすのに効きます。A はモデルに値を作らせる方向です。B は必要な情報を落とします。C は構造の扱い方を教えないので、根本の解決になりません。
問61(1つ選んでください) 契約書の日付が「令和7年3月4日」「3/4/25」「2025年3月4日」「March 4, 2025」などさまざまな書き方で書かれています。スキーマでは日付を文字列の項目にしており、出力の書式がばらばらで下流のシステムが読めません。最も適切な対策はどれですか。
A. 日付の項目を削除する B. 出力をそのまま受け取り、下流のシステムで全部の書き方に対応する C. 日付の項目を enum にして、ありうる日付をすべて列挙する D. 厳密なスキーマと合わせて、プロンプトに書式の正規化ルール(YYYY-MM-DD に直す、和暦は西暦に変換する、日と月の順がわからない「3/4/25」は null にして要確認の印を付ける など)を書く
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.3 書式の正規化ルール
正解: D
元の書式がばらばらなときは、厳密なスキーマと一緒に、プロンプトで正規化のルールを示します。あいまいで決められないものは推測させず、null と印で知らせます。A は必要な情報を失います。B は下流の負担と誤りを増やします。C は現実的ではありません。
問62(1つ選んでください) 抽出を strict なツール利用に替えた結果、JSON の構文エラーはなくなりました。ところが、支払期日の項目に請求日の日付が入っているケースが2%あります。この問題について正しい説明はどれですか。
A. strict なスキーマなので、このようなことは起きないはずで、API の不具合である B. スキーマで issue_date と due_date に別々の enum を付ければ防げる C. これはスキーマでは防げない意味のエラーで、検証(例: 支払期日は請求日より後か)で見つけ、具体的なエラーを伝えて再試行するか、プロンプトの説明や例を直す必要がある D. 構文エラーがないので、2%の誤りは許容するしかない
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.3 構文のエラーと意味のエラー
正解: C
厳密な JSON スキーマで構文エラーはなくなりますが、値が別の項目に入るなどの意味のエラーは防げません。検証で見つけ、具体的なエラーで再試行したり、項目の説明や例を改善したりします。A と B はスキーマが守るものを誤解しています。D は直せるエラーを放置します。
問63(2つ選んでください) 人のレビュー担当は1日に200件しか見られません。抽出は1日5,000件です。限られたレビューの時間を最も効果的に使う設計として正しいものを2つ選んでください。
A. 毎日、最初に届いた200件をレビューする B. モデルに項目ごとの確信度を出させ、正解のわかっているラベル付きの検証セットで確信度と実際の正しさを比べて、レビューに回すしきい値を決める C. モデルが自己申告した確信度を、そのまましきい値(例: 0.8)と比べて使う D. 確信度の低い抽出と、元の文書があいまい・矛盾している(conflict_detected が true の)抽出を優先してレビューに回す
ドメイン5: コンテキスト管理と信頼性 / 5.5 確信度の調整と振り分け
正解: B、D
項目ごとの確信度を、ラベル付きの検証セットで調整してしきい値を決め(B)、確信度の低いものや、元の文書があいまい・矛盾したものを優先して人に回します(D)。A は誤りの多いものを優先できません。C は調整していない自己申告の確信度で、当てになりません。
問64(1つ選んでください) 請求書の中には、表紙の総額と明細の合計が実際に食い違っているもの(取引先の書き間違い)があります。今のモデルは、どちらかに合わせて黙って数字を「直して」しまいます。下流で問題に気づけるようにするには、スキーマをどう設計するのが最も良いですか。
A. 総額の項目だけを残し、明細は抜き出さない B. モデルに、食い違いがあれば必ず明細の合計に合わせるよう指示する C. 文書に書かれた stated_total と、明細から計算した calculated_total を並べて抜き出し、元の文書の値が矛盾していれば conflict_detected を true にする D. 食い違いのある請求書は抽出せずに捨てる
ドメイン4: プロンプトエンジニアリングと構造化出力 / 4.4 自己修正の検証フロー
正解: C
stated_total と calculated_total を並べると、食い違いを機械で見つけられます。元のデータの矛盾には conflict_detected を付けて、勝手に直さず下流や人に知らせます。B は誤りを隠します。A と D は必要な情報を失います。
採点する
結果
ドメイン別 シナリオ別 本番の合否は正答率ではなくスケールスコア(720 / 1,000)で決まります。学習計画の目安は、全ドメインで7割以上です。正答率の低いドメインの教材と、苦手なシナリオの解説を読み直してください。各問題の解説は問題の下に表示されています。
教材の目次へ シナリオの解説へ