【AI Architect認定資格】Claude公式試験ガイドの例題を収録してみた

Last updated at 2026-03-15Posted at 2026-03-15

最近、Anthropicが Claude Certified Architect　という資格を公開しており、

その試験ガイドにシナリオベースの例題12問と演習4個が収録されている。

読んでみると「APIの使い方を暗記する試験」ではなく、実際のプロダクション環境でのトレードオフ判断を問う問題ばかりで面白かった。

この記事では全問題をClaudeで日本語訳して、解説付きでまとめてみる。答えは折りたたんでいるので、まず自分で考えてから開いてみてほしい。

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

あなたはClaude Agent SDKを使ってカスタマーサポート解決エージェントを構築している。このエージェントは返品・請求トラブル・アカウント問題などの高曖昧度なリクエストを処理する。バックエンドシステムへのアクセスにはカスタムMCPツール（get_customer、lookup_order、process_refund、escalate_to_human）を使用する。目標は80%以上のファーストコンタクト解決率を達成しながら、適切にエスカレーションの判断を行うこと。

問題1

本番データを確認したところ、12%のケースで get_customer をまったく呼び出さず、顧客が自己申告した名前だけで lookup_order を呼び出していることがわかった。その結果、アカウントの誤認識や誤った返金処理が発生している。この信頼性の問題に最も効果的に対処するにはどうすればよいか？

A) get_customer が検証済み顧客IDを返すまで、lookup_order と process_refund の呼び出しをブロックするプログラム的な前提条件を追加する

B) システムプロンプトに「注文操作の前に必ず get_customer で顧客確認を行うこと」と明記する

C) get_customer を必ず最初に呼び出すパターンをfew-shotサンプルで示す

D) 各リクエストを分析してリクエストタイプに適したツールのみを有効化するルーティング分類器を実装する

✅ 答えと解説を見る

正解：A

顧客認証→返金処理のような失敗コストが高いビジネスロジックの実行順序は、プロンプトで「お願い」するのではなく、コードで「強制」する必要がある。

B・C はNG：LLMへの指示は確率的にしか守られない。金融処理で12%の失敗率は致命的
D はNG：ツールの可用性の問題ではなく、ツールの実行順序の問題。論点がズレている
A が正解：get_customer が完了するまで後続ツールをプログラム的にブロックすることで、決定論的な保証が得られる

ポイント：重要なビジネスルールほど、プロンプトではなくコードで保護する

問題2

本番ログを見ると、ユーザーが「注文 #12345 を確認してください」と言った場合に、lookup_order ではなく get_customer を呼び出すことが頻繁に起きている。両ツールの説明は「顧客情報を取得します」「注文詳細を取得します」と最小限で、受け付ける識別子のフォーマットも似ている。ツール選択の信頼性を改善するための最初のステップとして最も効果的なものはどれか？

A) 注文関連クエリが lookup_order にルーティングされる5〜8件のサンプルを含むfew-shotをシステムプロンプトに追加する

B) 各ツールの説明を拡充する（処理できる入力フォーマット、クエリ例、エッジケース、類似ツールとの使い分けの境界説明を含める）

C) 各ターンの前にユーザー入力を解析し、キーワードと識別子パターンに基づいて適切なツールを事前選択するルーティング層を実装する

D) 両ツールを単一の lookup_entity ツールに統合し、任意の識別子を受け付けて内部でクエリ先バックエンドを判断するようにする

✅ 答えと解説を見る

正解：B

LLMはツールの説明文を主要な判断材料としてツールを選択する。説明が薄いと、似た機能のツールが並んでいるときに迷子になる。

A はNG：few-shotはトークンのオーバーヘッドが増えるだけで根本原因（説明不足）を解決しない
C はNG：過剰設計。LLMの自然言語理解を活かさない
D はNG：アーキテクチャ的には有効な選択肢だが、「最初のステップ」としてはコストがかかりすぎ
B が正解：ツールの説明を充実させることが低コスト・高効果の第一手

ポイント：LLMと組み合わせるツールの説明文は、人間向けAPIドキュメントと同じくらい丁寧に書く

問題3

エージェントのファーストコンタクト解決率が55%で、80%の目標を大幅に下回っている。ログを見ると、写真付きの標準的な破損品交換のような単純なケースをエスカレーションする一方、ポリシー例外が必要な複雑な状況を自律的に処理しようとしていることがわかった。エスカレーション判断の精度を改善するために最も効果的な方法はどれか？

A) 自律的に解決すべきケースとエスカレーションすべきケースを示すfew-shotサンプル付きの明示的なエスカレーション基準をシステムプロンプトに追加する

B) エージェントが各応答前に信頼度スコア（1〜10）を自己報告させ、閾値を下回った場合に自動的に人間にルーティングする

C) 過去のチケットで学習した分類モデルを別途デプロイし、メインエージェント処理前にエスカレーションが必要かを予測する

D) 顧客のフラストレーションレベルを検出する感情分析を実装し、ネガティブ感情が閾値を超えた場合に自動エスカレーションする

✅ 答えと解説を見る

正解：A

問題の本質は判断境界が不明確なことで、明示的な基準とfew-shotサンプルを追加することが直接的な解決策。

B はNG：LLMの自己報告信頼度は精度が低い。難しいケースで間違って「高信頼度」を報告してしまっていることが問題の原因でもある
C はNG：ラベル付きデータとML基盤が必要な過剰設計。プロンプト改善を試す前に取る手段ではない
D はNG：感情と案件の複雑さは相関しない。問題の本質を解決していない
A が正解：不明確な判断境界に対する最初のアプローチとして、プロンプトの明示化が最も比例的で低コスト

ポイント：エスカレーション基準は「複雑そうなとき」ではなく、「ポリシーの空白」「顧客の明示的な要求」「進捗できないとき」で定義する

シナリオ2：Claude Codeによるコード生成

あなたはClaude Codeを使ってソフトウェア開発を加速させている。チームはコード生成・リファクタリング・デバッグ・ドキュメント作成に活用している。カスタムスラッシュコマンド、CLAUDE.md設定を統合し、plan modeと直接実行の使い分けを理解する必要がある。

問題4

チームの標準コードレビューチェックリストを実行するカスタム /review スラッシュコマンドを作成したい。このコマンドはリポジトリをクローンまたはプルしたすべての開発者が使えるようにしたい。このコマンドファイルはどこに作成すべきか？

A) プロジェクトリポジトリ内の .claude/commands/ ディレクトリ

B) 各開発者のホームディレクトリの ~/.claude/commands/

C) プロジェクトルートの CLAUDE.md ファイル内

D) commands 配列を持つ .claude/config.json ファイル内

✅ 答えと解説を見る

正解：A

プロジェクトスコープのカスタムスラッシュコマンドはリポジトリ内の .claude/commands/ に配置する。バージョン管理されるため、クローンまたはプル時にすべての開発者に自動的に共有される。

B はNG：~/.claude/commands/ は個人用。バージョン管理に含まれないのでチームには共有されない
C はNG：CLAUDE.md はプロジェクトの指示やコンテキストを記述する場所であり、コマンド定義の場所ではない
D はNG：そのような設定の仕組みはClaude Codeに存在しない

ポイント：チーム共有→.claude/commands/（リポジトリ内）、個人用→~/.claude/commands/（ホームディレクトリ）

問題5

チームのモノリシックアプリケーションをマイクロサービスに分割する作業を担当することになった。数十のファイルにまたがる変更が必要で、サービス境界とモジュール依存関係についての意思決定も求められる。どのアプローチを取るべきか？

A) plan modeに入り、変更を加える前にコードベースを探索し、依存関係を把握し、実装アプローチを設計する

B) 直接実行から始め、実装が自然なサービス境界を明らかにしていくのに任せながら段階的に変更する

C) 各サービスをどのように構造化すべきかを詳細に記述した包括的な事前指示を用意した上で直接実行する

D) 直接実行モードで開始し、実装中に予想外の複雑さに直面した場合にのみplan modeに切り替える

✅ 答えと解説を見る

正解：A

plan modeは大規模変更・複数の有効な実装アプローチ・アーキテクチャ上の意思決定を伴う複雑なタスクのために設計されている。

B はNG：依存関係が後になって発覚したときに高コストな手戻りが発生するリスクがある
C はNG：コードを探索せずに正しい構造を事前に知っていると仮定している
D はNG：要件に複雑さがすでに明記されているのに、「問題が出てから切り替える」という判断がおかしい
A が正解：変更をコミットする前にコードベースを安全に探索・設計できる

ポイント：plan modeは「アーキテクチャ的な判断が必要」「複数のアプローチが考えられる」「複数ファイルにまたがる」ときに使う

問題6

コードベースには異なるコーディング規約を持つ領域がある（ReactコンポーネントはHooksを使った関数スタイル、APIハンドラはasync/awaitと特定のエラーハンドリング、DBモデルはリポジトリパターン）。テストファイルはコードベース全体に散在しており（例：Button.test.tsx が Button.tsx の隣）、場所に関わらずすべてのテストで同じ規約に従わせたい。Claudeがコード生成時に自動的に正しい規約を適用するための最も保守性の高い方法はどれか？

A) ファイルパスに基づいて条件付きで規約を適用するglob patternを持つYAML frontmatterを指定したルールファイルを .claude/rules/ に作成する

B) すべての規約をルートの CLAUDE.md にエリアごとのヘッダー付きでまとめ、Claudeがどのセクションが適用されるかを推論するのに任せる

C) 各コードタイプ用のスキルを .claude/skills/ に作成し、関連する規約をそれぞれの SKILL.md ファイルに含める

D) 各サブディレクトリにそのエリア固有の規約を含む CLAUDE.md ファイルを配置する

✅ 答えと解説を見る

正解：A

.claude/rules/ のglob pattern（例：**/*.test.tsx）を使うと、ディレクトリの場所に関わらずファイルパスに基づいて規約を自動的に適用できる。テストファイルがコードベース全体に散在しているケースに最適。

B はNG：推論に依存するため不確実。明示的なマッチングではない
C はNG：スキルは手動で呼び出すか、Claudeが選択することに依存する。ファイルパスに基づく自動適用にならない
D はNG：複数のディレクトリにまたがるファイル（散在するテストファイルなど）を扱えない

ポイント：コードベース全体に散らばるファイルタイプへの規約適用には .claude/rules/ のglob patternが最適

シナリオ3：マルチエージェント研究システム

あなたはClaude Agent SDKを使ってマルチエージェント研究システムを構築している。コーディネーターエージェントが専門化されたサブエージェントに委任する（ウェブ検索・文書分析・知見統合・レポート生成）。システムはトピックを調査し、出典付きの包括的なレポートを生成する。

問題7

「AIが創造産業に与える影響」というトピックでシステムを実行したところ、各サブエージェントは正常に完了した（ウェブ検索エージェントは関連記事を発見、文書分析エージェントは論文を正しく要約、統合エージェントは一貫した出力を生成）。しかし最終レポートはビジュアルアートのみをカバーし、音楽・文章・映像制作がまったく含まれていなかった。コーディネーターのログを確認すると、トピックを「デジタルアートにおけるAI」「グラフィックデザインにおけるAI」「写真撮影におけるAI」の3つのサブタスクに分解していた。最も可能性の高い根本原因は何か？

A) 統合エージェントが受け取った知見のカバレッジギャップを特定するための指示を持っていない

B) コーディネーターエージェントのタスク分解が狭すぎて、トピックの関連ドメインをすべてカバーするサブエージェントへの割り当てになっていない

C) ウェブ検索エージェントのクエリが十分に包括的でなく、より多くの創造産業セクターをカバーするために拡張する必要がある

D) 文書分析エージェントが過度に制限的な関連性基準によってビジュアルアート以外の創造産業に関連するソースをフィルタリングしている

✅ 答えと解説を見る

正解：B

コーディネーターのログが根本原因を直接示している。「創造産業」をビジュアルアートのサブタスクのみ（デジタルアート・グラフィックデザイン・写真）に分解し、音楽・文章・映像を完全に省いていた。

各サブエージェントは割り当てられた範囲を正しく実行した。問題は何を割り当てたかにある。

A・C・D はNG：ダウンストリームのエージェントを責めているが、それらは正しく動作していた

ポイント：マルチエージェントシステムの出力品質はコーディネーターのタスク分解の質に大きく依存する

問題8

ウェブ検索サブエージェントが複雑なトピックの調査中にタイムアウトした。このエラー情報をコーディネーターエージェントに返す方法を設計する必要がある。インテリジェントなリカバリーを最もよく可能にするエラー伝播アプローチはどれか？

A) 失敗の種類・試みたクエリ・部分的な結果・代替アプローチを含む構造化されたエラーコンテキストをコーディネーターに返す

B) サブエージェント内で指数バックオフによる自動リトライロジックを実装し、すべてのリトライが尽きた後にのみ汎用的な「検索利用不可」ステータスを返す

C) サブエージェント内でタイムアウトをキャッチし、成功としてマークした空の結果セットを返す

D) タイムアウト例外をトップレベルのハンドラに直接伝播させ、研究ワークフロー全体を終了させる

✅ 答えと解説を見る

正解：A

構造化されたエラーコンテキストにより、コーディネーターは「変更したクエリでリトライすべきか」「代替アプローチを試すか」「部分的な結果で進むか」をインテリジェントに判断できる。

B はNG：汎用的なステータスはコーディネーターから貴重なコンテキストを隠す
C はNG：失敗を成功として隠蔽する。リカバリーを不可能にし、不完全な研究出力のリスクがある
D はNG：リカバリー戦略が成功する可能性があるときに、ワークフロー全体を不必要に終了させる

ポイント：エラーは「発生したこと」だけでなく「何を試みたか・部分的な結果は何か・代替手段は何か」を構造化して返す

問題9

テスト中、統合エージェントが知見を結合する際に特定のクレームを頻繁に検証する必要があることがわかった。現在、検証が必要な場合、統合エージェントはコーディネーターに制御を返し、コーディネーターがウェブ検索エージェントを呼び出した後、結果と共に統合エージェントを再呼び出しする。これにより1タスクあたり2〜3往復が追加され、レイテンシが40%増加している。評価では、これらの検証の85%が単純なファクトチェック（日付・名前・統計）で、15%がより深い調査が必要なケースだった。オーバーヘッドを減らしながらシステムの信頼性を維持する最も効果的なアプローチはどれか？

A) 統合エージェントに単純な検索用のスコープを絞った verify_fact ツールを与え、複雑な検証はコーディネーター経由でウェブ検索エージェントに委任し続ける

B) 統合エージェントにすべての検証ニーズを蓄積させ、パス終了時にバッチとしてコーディネーターに返し、コーディネーターがすべてをウェブ検索エージェントに一度に送る

C) 統合エージェントにすべてのウェブ検索ツールへのアクセスを与え、コーディネーター経由の往復なしに任意の検証ニーズを直接処理できるようにする

D) ウェブ検索エージェントが初期調査中に各ソースの周辺に追加コンテキストを事前にキャッシュし、統合エージェントが検証する必要があることを予測する

✅ 答えと解説を見る

正解：A

最小権限の原則を適用する。統合エージェントには85%の一般的なケース（単純なファクト検証）に必要なものだけを与え、複雑なケースには既存の調整パターンを維持する。

B はNG：バッチアプローチは後続の統合ステップが以前に検証したファクトに依存する可能性があり、ブロッキング依存が生じる
C はNG：統合エージェントを過剰にプロビジョニングし、関心の分離に違反する
D はNG：統合エージェントが何を検証する必要があるかを確実に予測できる投機的キャッシュに依存している

ポイント：エージェントのツールは役割に必要な最小限に絞る（最小権限の原則）

シナリオ4：CI/CDへのClaude Code統合

あなたはCI/CDパイプラインにClaude Codeを統合している。システムは自動コードレビュー・テストケース生成・プルリクエストへのフィードバックを行う。アクションにつながるフィードバックを提供し、偽陽性を最小化するプロンプトを設計する必要がある。

問題10

パイプラインスクリプトで claude "このプルリクエストのセキュリティ問題を分析してください" を実行したが、ジョブが無期限にハングした。ログにはClaude Codeがインタラクティブな入力を待っていると表示されている。自動化パイプラインでClaude Codeを実行する正しいアプローチはどれか？

A) -p フラグを追加する：claude -p "このプルリクエストのセキュリティ問題を分析してください"

B) コマンド実行前に環境変数 CLAUDE_HEADLESS=true を設定する

C) stdinを /dev/null からリダイレクトする：claude "このプルリクエストのセキュリティ問題を分析してください" < /dev/null

D) --batch フラグを追加する：claude --batch "このプルリクエストのセキュリティ問題を分析してください"

✅ 答えと解説を見る

正解：A

-p（または --print）フラグがClaude Codeを非インタラクティブモードで実行するための公式の方法。プロンプトを処理し、結果をstdoutに出力して、ユーザー入力を待たずに終了する。

B はNG：CLAUDE_HEADLESS という環境変数は存在しない
C はNG：Unix的な回避策で、Claude Codeのコマンド構文に対して適切に対処できていない
D はNG：--batch フラグは存在しない

ポイント：CI/CDでClaude Codeを使う場合は必ず -p フラグを付ける

問題11

チームはAPIコストを削減するために自動分析のすべてをBatch APIに移行したいと考えている。対象は（1）開発者がマージ前に完了を待つ必要があるブロッキングのpre-mergeチェックと（2）翌朝レビュー用に夜間生成されるテクニカルデットレポートの2つのワークフロー。このプロポーザルをどう評価すべきか？

A) テクニカルデットレポートのみBatch処理に切り替え、pre-mergeチェックはリアルタイム呼び出しを維持する

B) ステータスポーリングで完了を確認しながら、両ワークフローをBatch処理に切り替える

C) バッチ結果の順序問題を避けるために両ワークフローのリアルタイム呼び出しを維持する

D) 両方をBatch処理に切り替え、バッチが時間がかかりすぎる場合はリアルタイムへのタイムアウトフォールバックを設ける

✅ 答えと解説を見る

正解：A

Message Batches APIは50%のコスト削減があるが、処理時間は最大24時間でレイテンシのSLAは保証されない。

ブロッキングpre-mergeチェック：開発者が結果を待つ必要があるため、Batch APIは不適切
夜間テクニカルデットレポート：翌朝レビューなので24時間の処理窓は問題ない。Batch APIに最適
B はNG：「しばしば速い」ことに依存するのはブロッキングワークフローでは許容できない
C はNG：バッチ結果は custom_id フィールドで関連付けできるため、順序問題は誤解
D はNG：単純に各APIを適切なユースケースに対応させれば済むのに、不必要な複雑さを加えている

ポイント：Batch API＝レイテンシ非依存のワークフロー向け。ブロッキング処理には同期APIを使う

問題12

プルリクエストが株式追跡モジュール全体の14ファイルを変更している。すべてのファイルを一緒に分析するシングルパスレビューは一貫性のない結果を出している（一部のファイルには詳細なフィードバック、他のファイルには表面的なコメント、明らかなバグの見落とし、同じコードパターンを1つのファイルでは問題として指摘しながら別のファイルでは承認するといった矛盾するフィードバック）。レビューをどのように再構成すべきか？

A) フォーカスしたパスに分割する：各ファイルを個別にローカルな問題について分析し、その後クロスファイルのデータフローを検査する別の統合フォーカスパスを実行する

B) 自動レビューが実行される前に開発者が大きなPRを3〜4ファイルの小さな単位に分割して提出することを要求する

C) より大きなコンテキストウィンドウを持つ上位モデルに切り替えて、1回のパスですべての14ファイルに十分な注意を与える

D) 完全なPRに対して3回の独立したレビューパスを実行し、少なくとも2回で指摘された問題のみをフラグする

✅ 答えと解説を見る

正解：A

フォーカスしたパスへの分割は根本原因（多くのファイルを一度に処理する際の注意力の希薄化）に直接対処する。ファイルごとの分析で一貫した深さが確保され、別の統合パスでクロスファイルの問題を検出できる。

B はNG：システムを改善せずに開発者に負担を転嫁している
C はNG：より大きなコンテキストウィンドウは注意力の品質問題を解決しない（根本的な誤解）
D はNG：複数回のパスで一貫して検出されない可能性のある実際のバグを「コンセンサス」が必要とすることで検出を抑制してしまう

ポイント：大規模なコードレビューは「ファイルごとのローカル分析パス＋クロスファイル統合パス」に分割する

ボーナス：試験ガイド収録の実践演習4題

試験ガイドには選択問題とは別に、ハンズオンの準備演習が4つ収録されている。こちらは選択問題ではなく「実際に手を動かしてみよう」系の内容だ。要点だけ日本語でまとめる。

演習1：エスカレーションロジック付きマルチツールエージェントを構築する

目的：ツール統合・構造化エラーハンドリング・エスカレーションパターンを持つagentic loopの設計を練習する

📋 演習の内容を見る

ステップ概要

MCPツールを3〜4個定義する
- 各ツールの目的・期待する入力・境界条件を明確に差別化した説明文を書く
- 少なくとも2つは機能が似ていて、説明が不十分だと選択ミスが起きるツールを含める
agentic loopを実装する
- stop_reason をチェックして「ツール実行を続けるか」「最終応答を返すか」を制御する
- "tool_use" と "end_turn" の両方を正しく処理する
構造化エラーレスポンスをツールに追加する
- errorCategory（transient / validation / permission）、isRetryable boolean、人間向け説明を含める
- 各エラータイプをエージェントが適切に処理することを確認（一時的エラーはリトライ、ビジネスエラーはユーザーに説明）
ツール呼び出しをインターセプトするプログラム的フックを実装する
- ビジネスルール（例：閾値を超えた操作のブロック）を強制する
- トリガー時にエスカレーションワークフローにリダイレクトする
マルチ懸念メッセージでテストする
- 複数の問題を含むリクエストでエージェントがリクエストを分解し、各懸念を処理し、統合した応答を生成することを確認する

強化されるドメイン：Domain 1（Agentic Architecture）、Domain 2（Tool Design & MCP）、Domain 5（Context Management & Reliability）

演習2：チーム開発ワークフロー向けにClaude Codeを設定する

目的：CLAUDE.md階層・カスタムスラッシュコマンド・パス固有ルール・MCPサーバー統合を練習する

📋 演習の内容を見る

ステップ概要

プロジェクトレベルの CLAUDE.md を作成する
- 全チームメンバーに適用する普遍的なコーディング標準とテスト規約を記述する
- プロジェクトレベルに置いた指示がチーム全員に一貫して適用されることを確認する
.claude/rules/ にYAML frontmatterのglob patternを持つルールファイルを作成する
- 例：paths: ["src/api/**/*"]（API規約）、paths: ["**/*.test.*"]（テスト規約）
- マッチするファイルを編集するときだけルールがロードされることを確認する
.claude/skills/ にプロジェクトスコープのスキルを作成する
- context: fork と allowed-tools の制限を設定する
- メインの会話コンテキストを汚染せずにスキルが分離して実行されることを確認する
.mcp.json にMCPサーバーを設定する
- 認証情報に環境変数展開を使う（例：${GITHUB_TOKEN}）
- ~/.claude.json に個人用の実験的MCPサーバーを追加し、両方が同時に利用可能なことを確認する
様々な複雑さのタスクでplan modeと直接実行を比較する
- 単一ファイルのバグ修正、複数ファイルのライブラリ移行、複数の有効な実装アプローチがある新機能
- plan modeが価値を発揮する場面を観察する

強化されるドメイン：Domain 3（Claude Code Configuration）、Domain 2（Tool Design & MCP）

演習3：構造化データ抽出パイプラインを構築する

目的：JSONスキーマの設計・tool_use による構造化出力・バリデーション＋リトライループ・バッチ処理戦略を練習する

📋 演習の内容を見る

ステップ概要

JSONスキーマを持つ抽出ツールを定義する
- 必須フィールドと任意フィールド、"other" + detail stringパターンのenum、ソース文書に情報がない場合のnullableフィールドを含める
- 一部フィールドが欠落している文書を処理し、モデルが値を捏造せずに null を返すことを確認する
バリデーション＋リトライループを実装する
- PydanticやJSONスキーマのバリデーションが失敗した場合、文書・失敗した抽出結果・具体的なバリデーションエラーを含むフォローアップリクエストを送る
- リトライで解決できるエラー（フォーマットのミスマッチ）とできないエラー（情報がソース文書に存在しない）を追跡する
多様なフォーマットからの抽出を示すfew-shotサンプルを追加する
- インライン引用 vs 参考文献リスト、記述的な説明 vs 構造化テーブルなどの例を含める
- 構造的なバリエーションへの対処が改善されることを確認する
バッチ処理戦略を設計する
- Message Batches APIを使って100件の文書をバッチ送信する
- custom_id で失敗した文書を特定して再送信する（例：コンテキスト制限を超えた文書のチャンク分割）
- SLA制約に対して総処理時間を計算する
人間によるレビューのルーティング戦略を実装する
- モデルにフィールドレベルの信頼度スコアを出力させる
- 低信頼度の抽出を人間レビューにルーティングする
- 文書タイプとフィールドごとの精度を分析して一貫したパフォーマンスを確認する

強化されるドメイン：Domain 4（Prompt Engineering & Structured Output）、Domain 5（Context Management & Reliability）

演習4：マルチエージェント研究パイプラインを設計・デバッグする

目的：サブエージェントのオーケストレーション・コンテキスト受け渡し・エラー伝播・出典追跡を持つ統合の実装を練習する

📋 演習の内容を見る

ステップ概要

少なくとも2つのサブエージェントに委任するコーディネーターエージェントを構築する
- コーディネーターの allowedTools に "Task" が含まれていることを確認する
- 各サブエージェントは自動的なコンテキスト継承ではなく、プロンプトに直接調査結果を受け取るようにする
並列サブエージェント実行を実装する
- コーディネーターが1回の応答で複数の Task ツール呼び出しを発行することで並列実行する
- 順次実行と比較してレイテンシの改善を測定する
コンテンツとメタデータを分離した構造化出力をサブエージェントに設計する
- 各知見はクレーム・エビデンスの抜粋・ソースURL/文書名・公開日を含める
- 統合サブエージェントが知見を結合するときにソースの帰属を保持することを確認する
エラー伝播を実装する
- サブエージェントのタイムアウトをシミュレートし、コーディネーターが構造化されたエラーコンテキスト（失敗の種類・試みたクエリ・部分的な結果）を受け取ることを確認する
- コーディネーターが部分的な結果で処理を続行し、最終出力にカバレッジギャップをアノテーションできることをテストする
競合するソースデータでテストする
- 2つの信頼できるソースが異なる統計を示すケースを使う
- 統合出力がどちらか一方を恣意的に選択するのではなく、両方の値をソースの帰属付きで保持することを確認する
- 確立された知見と議論のある知見を区別するレポート構造になっているかをチェックする

強化されるドメイン：Domain 1（Agentic Architecture）、Domain 2（Tool Design & MCP）、Domain 5（Context Management & Reliability）

まとめ

選択問題12問＋実践演習4題を通じて見えてくる共通テーマ：

テーマ	核心的な考え方
プロンプト vs コード	重要なビジネスルールはコードで強制する
ツール設計	説明文がLLMの判断基準。丁寧に書く
マルチエージェント	コンテキストは自動で引き継がれない。明示的に渡す
エラーハンドリング	構造化されたエラーで後続の判断を助ける
API選択	ワークフローの性質（ブロッキング/非ブロッキング）に合わせる
コードレビュー	大規模レビューはパスを分割して注意力を保つ
実践演習	知識は「読む」より「手を動かす」ことで定着する

試験ガイド自体はAnthropicが公開しているので、実際にClaudeを使ったシステムを構築している人はぜひ読んでみてほしい。

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up