本文へスキップ
CCAR-F学習アプリ

公式試験ガイド（日英対訳）

Claude Certified Architect – Foundations Exam Guide の全内容

🔗 原文PDF（英語）をダウンロード

※本ページの日本語訳は個人学習目的で作成した非公式翻訳です。原文の著作権はAnthropicに帰属します。本訳は現行の試験ガイド v1.0（2026年7月発行・全18章）の全文対訳で、2026年8月23日に原文PDFと照合しています。

シバ
シバ
博士、この「公式試験ガイド」って何？ 試験の問題集みたいなもの？
博士
博士
問題集じゃないよ。Anthropic が公式に出している「試験の設計図」みたいなものだね。試験の目的、5つのドメインの詳細、6つのシナリオ、出題形式、そしてサンプル問題まで全部載っている。いわば「ここから出ますよ」という公式の宣言書だよ。
シバ
シバ
えっ、それってめちゃくちゃ大事じゃん！ 英語で40ページ近くあるんだよね？
博士
博士
そう。だからここでは全文を日本語に翻訳して、英語の原文と並べて読めるようにしてあるんだ。英日の切り替えもできるよ。まずはこのページでざっと流し読みして、試験の全体像をつかんでおこう。
シバ
シバ
で、Phase 0 に進んだら同じ内容をもう一度じっくり精読するんだね。2回読むから定着しそう！
表示：

目次

1. About This Certification / 本認定について

English

Version 1.0 · Effective July 2026 · Exam code: CCAR-F — This guide is subject to change without notice.

日本語

Version 1.0・2026年7月発効・試験コード: CCAR-F — 本ガイドは予告なく変更されることがあります。

English

The Claude Certified Architect – Foundations certification validates that practitioners can make informed decisions about tradeoffs when implementing real-world solutions with Claude. This exam tests foundational knowledge across Claude Code, the Claude Agent , the Claude , and Model Context Protocol () — the core technologies used to build production-grade applications with Claude.

日本語

Claude Certified Architect – Foundations 認定は、Claudeを使って実際のソリューションを実装する際に、トレードオフについて十分な情報に基づいた判断ができることを検証します。この試験は、Claude Code、Claude Agent 、Claude 、Model Context Protocol () という、Claudeで本番品質のアプリケーションを構築するためのコア技術に関する基礎知識をテストします。

English

Questions on this exam are grounded in realistic scenarios drawn from actual customer use cases, including building agentic systems for customer support, designing multi-agent research pipelines, integrating Claude Code into workflows, building developer productivity tools, and extracting structured data from unstructured documents.

日本語

この試験の問題は、実際の顧客ユースケースに基づいた現実的なシナリオに根差しています。カスタマーサポート用のシステム構築、マルチリサーチパイプラインの設計、ワークフローへのClaude Code統合、開発者生産性の構築、非構造化文書からの構造化データ抽出などが含まれます。

English

Candidates must demonstrate not only conceptual knowledge but practical judgment about architecture, configuration, and tradeoffs in production deployments.

日本語

受験者は概念的な知識だけでなく、本番メントにおけるアーキテクチャ、設定、トレードオフに関する実践的な判断力を実証する必要があります。

English

This guide is the authoritative reference for candidates preparing to sit the exam. It describes the exam content, lists the domains and task statements tested, provides sample questions, and recommends preparation strategies. Read it in full before scheduling your exam.

日本語

本ガイドは、受験を準備する方のための公式リファレンスです。試験内容の説明、テストされるドメインとタスクステートメントの一覧、サンプル問題の提供、準備戦略の推奨を行います。受験を予約する前に全文をお読みください。

🐕🎓 シバと博士の解説

シバ
シバ
つまり CCAR-F って、「Claude で何か作れます」じゃなくて「設計判断ができます」を証明する試験なんだ？
博士
博士
そのとおり。コードが書けるだけじゃ足りなくて、「なぜその設計にしたのか」「他の選択肢と比べてどんなトレードオフがあるか」を説明できる力が求められるんだ。
シバ
シバ
実際の顧客ユースケースに基づいたシナリオって書いてあるけど、暗記じゃ対応できないってこと？
博士
博士
そう。だからこそ、公式ドキュメントを読んで「なぜそうなっているのか」を理解することが大事なんだよ。
↑ 目次に戻る

2. Intended Audience / 対象受験者

English

The ideal candidate for this certification is a solution architect who designs and implements production applications with Claude. This candidate has hands-on experience with:

日本語

この認定の理想的な受験者は、Claudeで本番アプリケーションを設計・実装するソリューションアーキテクトです。以下の実践経験を持つ方が対象です：

English

Building agentic applications using the Claude Agent , including multi-agent orchestration, subagent delegation, tool integration, and lifecycle hooks.

日本語

Claude Agent を使ったアプリケーションの構築（マルチオーケストレーション、委任、統合、ライフサイクルを含む）。

English

Configuring and customizing Claude Code for team workflows using files, Agent , server integrations, and plan mode.

日本語

ファイル、Agent 、統合、を使ったチームワークフロー用のClaude Code設定・カスタマイズ。

English

Designing Model Context Protocol () tool and resource interfaces for backend system integration.

日本語

バックエンドシステム統合のためのModel Context Protocol () とリソースインターフェースの設計。

English

Engineering prompts that produce reliable structured output, leveraging schemas, few-shot examples, and extraction patterns.

日本語

、例、抽出パターンを活用した、信頼性の高い構造化出力を生成するエンジニアリング。

English

Managing context windows effectively across long documents, multi-turn conversations, and multi-agent handoffs.

日本語

長文ドキュメント、マルチターン会話、マルチハンドオフにわたるの効果的な管理。

English

Integrating Claude into pipelines for automated code review, test generation, and pull request feedback.

日本語

自動コードレビュー、テスト生成、プルリクエストフィードバックのためのパイプラインへのClaude統合。

English

Making sound escalation and reliability decisions, including error handling, human-in-the-loop workflows, and self-evaluation patterns.

日本語

エラーハンドリング、ヒューマン・イン・ザ・ループワークフロー、自己評価パターンを含む、適切なと信頼性の判断。

English

The candidate typically has 6+ months of practical experience building with Claude s, Agent , Claude Code, and , understanding both the capabilities and limitations of large language models in production environments.

日本語

受験者は通常、Claude 、Agent 、Claude Code、を使った6ヶ月以上の実践経験があり、本番環境における大規模言語モデルの能力と限界の両方を理解しています。

🐕🎓 シバと博士の解説

シバ
シバ
対象が「ソリューションアーキテクト」って書いてある…ぼく、アーキテクトじゃないんだけど大丈夫？
博士
博士
大丈夫だよ。ここに書いてあるのは「理想的な受験者像」であって、受験資格じゃない。実務経験がなくても、公式ドキュメントをしっかり読めば合格できる設計になっているからね。
シバ
シバ
Agent SDK、Claude Code、MCP、API… 全部やらないといけないの？
博士
博士
全部出るよ。でもこのアプリの Phase 1〜4 で一つずつ順番にやるから安心して。いきなり全部覚えようとしなくて大丈夫。
↑ 目次に戻る

3. Exam Details at a Glance / 試験詳細一覧

English

Credential: Claude Certified Architect – Foundations / Exam code: CCAR-F

日本語

認定資格：Claude Certified Architect – Foundations ／ 試験コード：CCAR-F

English

Number of items: 60. Item format: Multiple-choice and multiple-response items; each item states how many responses to select.

日本語

問題数：60問。出題形式：単一選択（multiple-choice）と複数選択（multiple-response）の混在。各問題に「いくつ選ぶか」が明記されます。

English

Exam structure: 4 scenarios drawn from a bank of 6. Time limit: 120 minutes.

日本語

試験構成：6本のシナリオバンクから4本が出題。制限時間：120分。

English

Delivery: Proctored — online proctored and/or test center, per program policy.

日本語

受験方法：監督付き — プログラムポリシーに基づき、オンライン監督またはテストセンター。

English

Passing score: Scaled score of 720 on a scale of 100–1,000. Exam fee: $125 USD.

日本語

合格スコア：100〜1,000のスケールドスコアで720。受験料：125米ドル。

English

Validity period: 12 months from the date the credential is awarded.

日本語

資格の有効期間：認定日から12ヶ月。

English

Result reporting: Pass/fail with scaled score (100–1,000), plus percent-correct by domain on the score report.

日本語

結果通知：合否とスケールドスコア（100〜1,000）に加え、スコアレポートにドメイン別の正答率が記載されます。
↑ 目次に戻る

4. Exam Content Outline (Blueprint) / 出題範囲（ブループリント）

English

The exam blueprint defines the content domains measured and the approximate weight of each domain on the exam. Weights reflect the relative importance of each domain to competent performance as determined through the job task analysis. The percentages indicate the approximate proportion of scored items drawn from each domain.

日本語

試験ブループリントは、測定される内容ドメインと、試験における各ドメインのおおよその配点比率を定義します。比率は、職務タスク分析によって決定された、有能な実務遂行に対する各ドメインの相対的な重要度を反映しています。パーセンテージは、各ドメインから出題される採点対象問題のおおよその割合を示します。

English

Domain 1: Agentic Architecture & Orchestration — 27%

日本語

ドメイン1：アーキテクチャとオーケストレーション — 27%

English

Domain 2: Tool Design & Integration — 18%

日本語

ドメイン2：設計と統合 — 18%

English

Domain 3: Claude Code Configuration & Workflows — 20%

日本語

ドメイン3：Claude Code設定とワークフロー — 20%

English

Domain 4: Prompt Engineering & Structured Output — 20%

日本語

ドメイン4：エンジニアリングと構造化出力 — 20%

English

Domain 5: Context Management & Reliability — 15%

日本語

ドメイン5：コンテキスト管理と信頼性 — 15%

English

Total: 100%

日本語

合計：100%

🐕🎓 シバと博士の解説

シバ
シバ
5つのドメインの配点、もう一回確認していい？
博士
博士
D1: エージェントアーキテクチャが27%で最大。D2: ツール設計 & MCP が18%。D3: Claude Code が20%。D4: プロンプトエンジニアリングが20%。D5: コンテキスト管理が15%。
シバ
シバ
D1 が一番多いんだね。Agent SDK をしっかりやらないと。
博士
博士
そうだね。D1が27%で最大配点だから、Phase 1ではここを中心に学ぶよ。あとはD3、D4が各20%とD1に続いて割合が大きいね。
↑ 目次に戻る

5. Exam Scenarios / 試験シナリオ

English

The exam uses scenario-based questions. Each scenario presents a realistic production context that frames a set of questions. During the exam, 4 scenarios are presented and picked at random from the full set of the 6 scenarios below.

日本語

試験はシナリオベースの問題を使用します。各シナリオは現実的な本番環境のコンテキストを提示し、それに基づいた問題が出題されます。試験中、以下の6つのシナリオの中から4つがランダムに出題されます。

English

Scenario 1: Customer Support Resolution Agent — You are building a customer support resolution agent using the Claude Agent . The agent handles high-ambiguity requests like returns, billing disputes, and account issues. It has access to your backend systems through custom Model Context Protocol () tools (get_customer, lookup_order, process_refund, escalate_to_human). Your target is 80%+ first-contact resolution while knowing when to escalate. Primary domains: Agentic Architecture & Orchestration, Tool Design & Integration, Context Management & Reliability

日本語

シナリオ1：カスタマーサポート解決 — Claude Agent を使用してカスタマーサポート解決を構築しています。は返品、請求紛争、アカウント問題などの曖昧性の高いリクエストを処理します。カスタム（get_customer、lookup_order、process_refund、escalate_to_human）を通じてバックエンドシステムにアクセスできます。目標は80%以上の初回解決率で、のタイミングも判断します。 主要ドメイン：アーキテクチャとオーケストレーション、設計と統合、コンテキスト管理と信頼性

English

Scenario 2: Code Generation with Claude Code — You are using Claude Code to accelerate software development. Your team uses it for code generation, refactoring, debugging, and documentation. You need to integrate it into your development workflow with custom slash commands, configurations, and understand when to use plan mode vs direct execution. Primary domains: Claude Code Configuration & Workflows, Context Management & Reliability

日本語

シナリオ2：Claude Codeによるコード生成 — Claude Codeを使ってソフトウェア開発を加速しています。チームはコード生成、リファクタリング、デバッグ、ドキュメント作成に使用しています。カスタムや設定を使って開発ワークフローに統合し、と直接実行の使い分けを理解する必要があります。 主要ドメイン：Claude Code設定とワークフロー、コンテキスト管理と信頼性

English

Scenario 3: Multi-Agent Research System — You are building a multi-agent research system using the Claude Agent . A coordinator agent delegates to specialized subagents: one searches the web, one analyzes documents, one synthesizes findings, and one generates reports. The system researches topics and produces comprehensive, cited reports. Primary domains: Agentic Architecture & Orchestration, Tool Design & Integration, Context Management & Reliability

日本語

シナリオ3：マルチリサーチシステム — Claude Agent を使ってマルチリサーチシステムを構築しています。が専門化されたに委任します：1つがWeb検索、1つがドキュメント分析、1つが知見の合成（synthesis）、1つがレポート生成を担当します。このシステムはトピックを調査し、包括的で引用付きのレポートを生成します。 主要ドメイン：アーキテクチャとオーケストレーション、設計と統合、コンテキスト管理と信頼性

English

Scenario 4: Developer Productivity with Claude — You are building developer productivity tools using the Claude Agent . The agent helps engineers explore unfamiliar codebases, understand legacy systems, generate boilerplate code, and automate repetitive tasks. It uses the built-in tools (Read, Write, Bash, Grep, Glob) and integrates with Model Context Protocol () servers. Primary domains: Tool Design & Integration, Claude Code Configuration & Workflows, Agentic Architecture & Orchestration

日本語

シナリオ4：Claudeによる開発者生産性向上 — Claude Agent を使って開発者生産性を構築しています。はエンジニアが不慣れなコードベースの探索、レガシーシステムの理解、ボイラープレートコードの生成、反復タスクの自動化を支援します。組み込み（Read、Write、Bash、Grep、Glob）を使用し、と統合します。 主要ドメイン：設計と統合、Claude Code設定とワークフロー、アーキテクチャとオーケストレーション

English

Scenario 5: Claude Code for Continuous Integration — You are integrating Claude Code into your Continuous Integration/Continuous Deployment () pipeline. The system runs automated code reviews, generates test cases, and provides feedback on pull requests. You need to design prompts that provide actionable feedback and minimize false positives. Primary domains: Claude Code Configuration & Workflows, Prompt Engineering & Structured Output

日本語

シナリオ5：におけるClaude Code — Claude Codeをパイプラインに統合しています。システムは自動コードレビュー、テストケース生成、プルリクエストへのフィードバックを実行します。実用的なフィードバックを提供し、偽陽性を最小化するを設計する必要があります。 主要ドメイン：Claude Code設定とワークフロー、エンジニアリングと構造化出力

English

Scenario 6: Structured Data Extraction — You are building a structured data extraction system using Claude. The system extracts information from unstructured documents, validates the output using JavaScript Object Notation () schemas, and maintains high accuracy. It must handle edge cases gracefully and integrate with downstream systems. Primary domains: Prompt Engineering & Structured Output, Context Management & Reliability

日本語

シナリオ6：構造化データ抽出 — Claudeを使って構造化データ抽出システムを構築しています。システムは非構造化文書から情報を抽出し、で出力を検証し、高い精度を維持します。エッジケースを適切に処理し、下流システムと統合する必要があります。 主要ドメイン：エンジニアリングと構造化出力、コンテキスト管理と信頼性

🐕🎓 シバと博士の解説

シバ
シバ
6つのシナリオから4つが出るってことは、毎回違う問題が出るの？
博士
博士
そう。どの4つが出るかはランダムだから、6つ全部を準備しておく必要があるよ。
シバ
シバ
シナリオ問題ってどんな感じ？ 長い文章を読むの？
博士
博士
うん。「あなたはXX社のエンジニアで、YYというシステムを構築しています。ZZという問題が発生しました。どう対処しますか？」みたいな形式。状況を正確に読み取る力が問われるんだ。
↑ 目次に戻る

6. Detailed Objectives by Domain / ドメイン別の詳細目標

English

Each domain below lists the task statements tested, with the knowledge and skills measured against each. Exam items are written against these objectives.

日本語

以下の各ドメインには、テストされるタスクステートメントと、それぞれに対して測定される知識・スキルが列挙されています。試験問題はこれらの目標に基づいて作成されます。
↑ 目次に戻る

6-1. Domain 1: Agentic Architecture & Orchestration / ドメイン1：エージェントアーキテクチャとオーケストレーション

English

Task Statement 1.1: Design and implement agentic loops for autonomous task execution Knowledge of: - The agentic loop lifecycle: sending requests to Claude, inspecting ("tool_use" vs "end_turn"), executing requested tools, and returning results for the next iteration - How tool results are appended to conversation history so the model can reason about the next action - The distinction between model-driven decision-making (Claude reasons about which tool to call next based on context) and pre-configured decision trees or tool sequences in: - Implementing agentic loop control flow that continues when is "tool_use" and terminates when is "end_turn" - Adding tool results to conversation context between iterations so the model can incorporate new information into its reasoning - Avoiding anti-patterns such as parsing natural language signals to determine loop termination, setting arbitrary iteration caps as the primary stopping mechanism, or checking for assistant text content as a completion indicator

日本語

タスクステートメント1.1：自律的タスク実行のためのの設計と実装 知識： - のライフサイクル：Claudeへのリクエスト送信、（"tool_use" vs "end_turn"）の検査、要求されたの実行、次のイテレーションへの結果返却 - モデルが次のアクションを推論できるように結果が会話履歴に追加される仕組み - モデル駆動の意思決定（Claudeがコンテキストに基づいて次に呼び出すを推論する）と、事前設定された決定木やシーケンスの区別 スキル： - が"tool_use"の時は継続し"end_turn"の時は終了する制御フローの実装 - イテレーション間で結果を会話コンテキストに追加し、モデルが新しい情報を推論に組み込めるようにする - の回避：自然言語シグナルの解析によるループ終了判定、任意のイテレーション上限を主な停止メカニズムとする、アシスタントテキストコンテンツの完了指標としてのチェック等

English

Task Statement 1.2: Orchestrate multi-agent systems with coordinator-subagent patterns Knowledge of: - Hub-and-spoke architecture where a coordinator agent manages all inter-subagent communication, error handling, and information routing - How subagents operate with isolated context—they do not inherit the coordinator's conversation history automatically - The role of the coordinator in task decomposition, delegation, result aggregation, and deciding which subagents to invoke based on query complexity - Risks of overly narrow task decomposition by the coordinator, leading to incomplete coverage of broad research topics in: - Designing coordinator agents that analyze query requirements and dynamically select which subagents to invoke rather than always routing through the full pipeline - Partitioning research scope across subagents to minimize duplication (e.g., assigning distinct subtopics or source types to each agent) - Implementing iterative refinement loops where the coordinator evaluates synthesis output for gaps, re-delegates to search and analysis subagents with targeted queries, and re-invokes synthesis until coverage is sufficient - Routing all subagent communication through the coordinator for observability, consistent error handling, and controlled information flow

日本語

タスクステートメント1.2：・パターンによるマルチシステムのオーケストレーション 知識： - が間の通信、エラーハンドリング、情報ルーティングを管理するハブ・アンド・スポークアーキテクチャ - は分離されたコンテキストで動作し、の会話履歴を自動的に継承しない - タスク分解、委任、結果集約、クエリの複雑さに基づく呼び出し判断におけるの役割 - による過度に狭いタスク分解のリスク（広範なリサーチトピックのカバレッジ不足につながる） スキル： - 常にフルパイプラインを通すのではなく、クエリ要件を分析して動的にどのを呼び出すかを選択する設計 - 間でリサーチ範囲を分割し重複を最小化（例：各に異なるサブトピックやソースタイプを割り当て） - が合成出力のギャップを評価し、ターゲットクエリで検索・分析に再委任し、カバレッジが十分になるまで合成を再実行する反復改善ループの実装 - 観測可能性、一貫したエラーハンドリング、制御された情報フローのためにすべての通信を経由でルーティング

English

Task Statement 1.3: Configure subagent invocation, context passing, and spawning Knowledge of: - The Task tool as the mechanism for spawning subagents, and the requirement that allowedTools must include "Task" for a coordinator to invoke subagents - That subagent context must be explicitly provided in the prompt—subagents do not automatically inherit parent context or share memory between invocations - The AgentDefinition configuration including descriptions, system prompts, and tool restrictions for each subagent type - Fork-based session management for exploring divergent approaches from a shared analysis baseline in: - Including complete findings from prior agents directly in the subagent's prompt (e.g., passing web search results and document analysis outputs to the synthesis subagent) - Using structured data formats to separate content from metadata (source URLs, document names, page numbers) when passing context between agents to preserve attribution - Spawning parallel subagents by emitting multiple Task tool calls in a single coordinator response rather than across separate turns - Designing coordinator prompts that specify research goals and quality criteria rather than step-by-step procedural instructions, to enable subagent adaptability

日本語

タスクステートメント1.3：の呼び出し、コンテキスト受け渡し、生成の設定 知識： - 生成のメカニズムとしてのTask。がを呼び出すにはallowedToolsに"Task"を含める必要あり - のコンテキストはで明示的に提供する必要があり、親コンテキストを自動的に継承したり呼び出し間でメモリを共有したりしない - 各タイプの説明、、制限を含むAgentDefinition設定 - 共有分析ベースラインから分岐アプローチを探索するためのフォークベースセッション管理 スキル： - 先行の完全な発見をのに直接含める（例：Web検索結果とドキュメント分析出力を合成に渡す） - 間でコンテキストを渡す際にコンテンツとメタデータ（ソースURL、ドキュメント名、ページ番号）を分離する構造化データフォーマットを使用して帰属を保持 - 別々のターンではなく単一のレスポンスで複数のTask呼び出しを発行して並列を生成 - の適応性を可能にするため、段階的な手順指示ではなくリサーチ目標と品質基準を指定するの設計

English

Task Statement 1.4: Implement multi-step workflows with enforcement and handoff patterns Knowledge of: - The difference between programmatic enforcement (hooks, prerequisite gates) and prompt-based guidance for workflow ordering - When deterministic compliance is required (e.g., identity verification before financial operations), prompt instructions alone have a non-zero failure rate - Structured handoff protocols for mid-process escalation that include customer details, root cause analysis, and recommended actions in: - Implementing programmatic prerequisites that block downstream tool calls until prerequisite steps have completed (e.g., blocking process_refund until get_customer has returned a verified customer ID) - Decomposing multi-concern customer requests into distinct items, then investigating each in parallel using shared context before synthesizing a unified resolution - Compiling structured handoff summaries (customer ID, root cause, refund amount, recommended action) when escalating to human agents who lack access to the conversation transcript

日本語

タスクステートメント1.4：制御とハンドオフパターンを用いたマルチステップワークフローの実装 知識： - ワークフロー順序付けにおける（、前提条件ゲート）とベースのガイダンスの違い - なコンプライアンスが必要な場合（金融操作前の本人確認など）、指示だけでは失敗率がゼロにならない - 顧客詳細、根本原因分析、推奨アクションを含むプロセス途中ののための構造化ハンドオフプロトコル スキル： - 前提条件ステップが完了するまで下流の呼び出しをブロックするプログラム的前提条件の実装（例：get_customerが検証済み顧客IDを返すまでprocess_refundをブロック） - 複数の懸念を持つ顧客リクエストを個別アイテムに分解し、共有コンテキストを使って各項目を並行調査してから統一的な解決策を合成 - 会話トランスクリプトにアクセスできない人間にする際の構造化ハンドオフサマリー（顧客ID、根本原因、返金額、推奨アクション）の作成

English

Task Statement 1.5: Apply Agent hooks for tool call interception and data normalization Knowledge of: - Hook patterns (e.g., PostToolUse) that intercept tool results for transformation before the model processes them - Hook patterns that intercept outgoing tool calls to enforce compliance rules (e.g., blocking refunds above a threshold) - The distinction between using hooks for deterministic guarantees versus relying on prompt instructions for probabilistic compliance in: - Implementing PostToolUse hooks to normalize heterogeneous data formats (Unix timestamps, ISO 8601, numeric status codes) from different tools before the agent processes them - Implementing tool call interception hooks that block policy-violating actions (e.g., refunds exceeding $500) and redirect to alternative workflows (e.g., human escalation) - Choosing hooks over prompt-based enforcement when business rules require guaranteed compliance

日本語

タスクステートメント1.5：呼び出しインターセプションとデータ正規化のためのAgent の活用 知識： - 結果をモデルが処理する前に変換するパターン（PostToolUseなど） - コンプライアンスルールを強制的に守らせるために送信呼び出しをインターセプトするパターン（例：閾値を超える返金のブロック） - 保証のための使用と、確率的コンプライアンスのための指示依存の区別 スキル： - 異なるからの異種データフォーマット（Unixタイムスタンプ、ISO 8601、数値ステータスコード）を処理前に正規化するPostToolUseの実装 - ポリシー違反アクション（例：500ドルを超える返金）をブロックし代替ワークフロー（例：人間）にリダイレクトする呼び出しインターセプションの実装 - ビジネスルールが保証されたコンプライアンスを必要とする場合にベースの制御よりを選択

English

Task Statement 1.6: Design task decomposition strategies for complex workflows Knowledge of: - When to use fixed sequential pipelines (prompt chaining) versus dynamic adaptive decomposition based on intermediate findings - Prompt chaining patterns that break reviews into sequential steps (e.g., analyze each file individually, then run a cross-file integration pass) - The value of adaptive investigation plans that generate subtasks based on what is discovered at each step in: - Selecting task decomposition patterns appropriate to the workflow: prompt chaining for predictable multi-aspect reviews, dynamic decomposition for open-ended investigation tasks - Splitting large code reviews into per-file local analysis passes plus a separate cross-file integration pass to avoid attention dilution - Decomposing open-ended tasks (e.g., "add comprehensive tests to a legacy codebase") by first mapping structure, identifying high-impact areas, then creating a prioritized plan that adapts as dependencies are discovered

日本語

タスクステートメント1.6：複雑なワークフローのためのタスク分解戦略の設計 知識： - 固定的な順次パイプライン（チェイニング）と中間結果に基づく動的適応型分解の使い分け - レビューを順次ステップに分割するチェイニングパターン（例：各ファイルを個別に分析し、その後クロスファイル統合パスを実行） - 各ステップで発見された内容に基づいてサブタスクを生成する適応型調査計画の価値 スキル： - ワークフローに適切なタスク分解パターンの選択：予測可能な多面的レビューにはチェイニング、オープンエンドの調査タスクには動的分解 - 注意の希薄化（attention dilution）を避けるため、大規模コードレビューをファイルごとのローカル分析パスと別途のクロスファイル統合パスに分割 - オープンエンドタスク（例：「レガシーコードベースに包括的なテストを追加」）を、まず構造をマッピングし、影響の大きい領域を特定し、依存関係の発見に応じて適応する優先順位付き計画を作成して分解

English

Task Statement 1.7: Manage session state, resumption, and forking Knowledge of: - Named session resumption using --resume <session-name> to continue a specific prior conversation - fork_session for creating independent branches from a shared analysis baseline to explore divergent approaches - The importance of informing the agent about changes to previously analyzed files when resuming sessions after code modifications - Why starting a new session with a structured summary is more reliable than resuming with stale tool results in: - Using --resume with session names to continue named investigation sessions across work sessions - Using fork_session to create parallel exploration branches (e.g., comparing two testing strategies or refactoring approaches from a shared codebase analysis) - Choosing between session resumption (when prior context is mostly valid) and starting fresh with injected summaries (when prior tool results are stale) - Informing a resumed session about specific file changes for targeted re-analysis rather than requiring full re-exploration

日本語

タスクステートメント1.7：セッション状態、再開、フォークの管理 知識： - --resume <session-name>を使用した名前付きセッション再開で特定の以前の会話を継続 - 分岐アプローチを探索するための共有分析ベースラインから独立したブランチを作成するfork_session - コード修正後のセッション再開時に、以前分析したファイルの変更についてに通知することの重要性 - 古い結果でのセッション再開より、構造化されたサマリーでの新規セッション開始がより信頼性が高い理由 スキル： - セッション名付きの--resumeを使用して、作業セッション間で名前付き調査セッションを継続 - fork_sessionを使用して並行探索ブランチを作成（例：共有コードベース分析から2つのテスト戦略やリファクタリングアプローチを比較） - セッション再開（以前のコンテキストがほぼ有効な場合）と注入サマリーでの新規開始（以前の結果が古い場合）の選択 - 完全な再探索を要求するのではなく、特定のファイル変更について再開セッションに通知してターゲット再分析を行う

🐕🎓 シバと博士の解説

シバ
シバ
D1 のタスク、エージェントループとかサブエージェントとか出てくるけど、要は何ができればいいの？
博士
博士
ひとことで言うと「Claude を使ったエージェントシステムを正しく設計できる」ということ。ループの設計、止め方、エラーハンドリング、複数エージェントの役割分担、全部入りだよ。
シバ
シバ
stop_reason って何？ あと、エージェントの暴走を防ぐ仕組みも出るの？
博士
博士
stop_reason は「Claude がなぜ応答を終えたか」の理由。end_turn（自然終了）、tool_use（ツール呼び出し）、max_tokens（上限到達）などがある。暴走を防ぐ仕組みは、ガイドでは hooks や前提条件ゲートによる「プログラム的な強制」として出てくるよ（guardrails という用語自体はガイドには出てこない）。Phase 1 で詳しくやるよ。
↑ 目次に戻る

6-2. Domain 2: Tool Design & MCP Integration / ドメイン2：ツール設計とMCP統合

English

Task Statement 2.1: Design effective tool interfaces with clear descriptions and boundaries Knowledge of: - Tool descriptions as the primary mechanism s use for tool selection; minimal descriptions lead to unreliable selection among similar tools - The importance of including input formats, example queries, edge cases, and boundary explanations in tool descriptions - How ambiguous or overlapping tool descriptions cause misrouting (e.g., analyze_content vs analyze_document with near-identical descriptions) - The impact of system prompt wording on tool selection: keyword-sensitive instructions can create unintended tool associations in: - Writing tool descriptions that clearly differentiate each tool's purpose, expected inputs, outputs, and when to use it versus similar alternatives - Renaming tools and updating descriptions to eliminate functional overlap (e.g., renaming analyze_content to extract_web_results with a web-specific description) - Splitting generic tools into purpose-specific tools with defined input/output contracts (e.g., splitting a generic analyze_document into extract_data_points, summarize_content, and verify_claim_against_source) - Reviewing system prompts for keyword-sensitive instructions that might override well-written tool descriptions

日本語

タスクステートメント2.1：明確な説明と境界を持つ効果的なインターフェースの設計 知識： - が選択に使用する主要なメカニズムとしての説明。最小限の説明は類似間の信頼性の低い選択につながる - 説明に入力形式、クエリ例、エッジケース、境界の説明を含めることの重要性 - 曖昧または重複する説明がミスルーティングを引き起こす仕組み（例：ほぼ同一の説明を持つanalyze_contentとanalyze_document） - の文言が選択に与える影響：キーワードに敏感な指示が意図しない関連付けを作成する可能性 スキル： - 各の目的、期待される入力、出力、類似との使い分けを明確に区別する説明の記述 - 機能的重複を排除するための名変更と説明更新（例：analyze_contentをWeb特化の説明付きextract_web_resultsにリネーム） - 汎用を定義された入出力契約付きの目的特化に分割（例：汎用analyze_documentをextract_data_points、summarize_content、verify_claim_against_sourceに分割） - 適切に書かれた説明を上書きする可能性のあるキーワードに敏感な指示についてをレビュー

English

Task Statement 2.2: Implement structured error responses for tools Knowledge of: - The isError flag pattern for communicating tool failures back to the agent - The distinction between transient errors (timeouts, service unavailability), validation errors (invalid input), business errors (policy violations), and permission errors - Why uniform error responses (generic "Operation failed") prevent the agent from making appropriate recovery decisions - The difference between retryable and non-retryable errors, and how returning structured metadata prevents wasted retry attempts in: - Returning structured error metadata including errorCategory (transient/validation/permission), isRetryable boolean, and human-readable descriptions - Including retriable: false flags and customer-friendly explanations for business rule violations so the agent can communicate appropriately - Implementing local error recovery within subagents for transient failures, propagating to the coordinator only errors that cannot be resolved locally along with partial results and what was attempted - Distinguishing between access failures (needing retry decisions) and valid empty results (representing successful queries with no matches)

日本語

タスクステートメント2.2：の構造化エラーレスポンスの実装 知識： - 失敗をに通知するのisErrorフラグパターン - 一時的エラー（タイムアウト、サービス不可用）、検証エラー（無効な入力）、ビジネスエラー（ポリシー違反）、権限エラーの区別 - 統一的なエラーレスポンス（汎用的な「操作失敗」）がの適切な復旧判断を妨げる理由 - リトライ可能エラーとリトライ不可能エラーの違い、構造化メタデータの返却が無駄なリトライ試行を防ぐ仕組み スキル： - errorCategory（transient/validation/permission）、isRetryableブーリアン、人間が読める説明を含む構造化エラーメタデータの返却 - ビジネスルール違反に対するretriable: falseフラグと顧客フレンドリーな説明の付与（が適切にコミュニケーションできるように） - 内での一時的障害のローカルエラー復旧実装。ローカルで解決できないエラーのみ、部分的結果と試行内容とともにに伝播 - アクセス障害（リトライ判断が必要）と有効な空結果（マッチなしの成功クエリ）の区別

English

Task Statement 2.3: Distribute tools appropriately across agents and configure tool choice Knowledge of: - The principle that giving an agent access to too many tools (e.g., 18 instead of 4-5) degrades tool selection reliability by increasing decision complexity - Why agents with tools outside their specialization tend to misuse them (e.g., a synthesis agent attempting web searches) - Scoped tool access: giving agents only the tools needed for their role, with limited cross-role tools for specific high-frequency needs - configuration options: "auto", "any", and forced tool selection ({"type": "tool", "name": "..."}) in: - Restricting each subagent's tool set to those relevant to its role, preventing cross-specialization misuse - Replacing generic tools with constrained alternatives (e.g., replacing fetch_url with load_document that validates document URLs) - Providing scoped cross-role tools for high-frequency needs (e.g., a verify_fact tool for the synthesis agent) while routing complex cases through the coordinator - Using forced selection to ensure a specific tool is called first (e.g., forcing extract_metadata before enrichment tools), then processing subsequent steps in follow-up turns - Setting : "any" to guarantee the model calls a tool rather than returning conversational text

日本語

タスクステートメント2.3：間での適切な配布と選択の設定 知識： - に多すぎる（例：4-5個ではなく18個）を与えると判断の複雑さが増し選択の信頼性が低下する原理 - 専門外のを持つがそれらを誤用する傾向がある理由（例：合成がWeb検索を試みる） - スコープ付きアクセス：各の役割に必要なのみを付与し、特定の高頻度ニーズに限定的なクロスロールを提供 - 設定オプション："auto"、"any"、強制選択（{"type": "tool", "name": "..."}） スキル： - 各のセットをその役割に関連するものに制限し、専門外の誤用を防止 - 汎用を制約付きの代替に置換（例：fetch_urlをドキュメントURLを検証するload_documentに置換） - 高頻度ニーズにスコープ付きクロスロールを提供（例：合成用のverify_fact）しつつ、複雑なケースは経由でルーティング - 特定のが最初に呼び出されることを保証する強制選択の使用（例：エンリッチメントの前にextract_metadataを強制）、後続ステップはフォローアップターンで処理 - モデルが会話テキストではなくを呼び出すことを保証する: "any"の設定

English

Task Statement 2.4: Integrate servers into Claude Code and agent workflows Knowledge of: - server scoping: project-level (.mcp.json) for shared team tooling vs user-level (~/.claude.json) for personal/experimental servers - Environment variable expansion in .mcp.json (e.g., ${GITHUB_TOKEN}) for credential management without committing secrets - That tools from all configured servers are discovered at connection time and available simultaneously to the agent - resources as a mechanism for exposing content catalogs (e.g., issue summaries, documentation hierarchies, database schemas) to reduce exploratory tool calls in: - Configuring shared servers in project-scoped .mcp.json with environment variable expansion for authentication tokens - Configuring personal/experimental servers in user-scoped ~/.claude.json - Enhancing tool descriptions to explain capabilities and outputs in detail, preventing the agent from preferring built-in tools (like Grep) over more capable tools - Choosing existing community servers over custom implementations for standard integrations (e.g., Jira), reserving custom servers for team-specific workflows - Exposing content catalogs as resources to give agents visibility into available data without requiring exploratory tool calls

日本語

タスクステートメント2.4：Claude Codeとワークフローへの統合 知識： - のスコーピング：チーム共有用のプロジェクトレベル（.mcp.json）vs 個人/実験用サーバーのユーザーレベル（~/.claude.json） - 秘密情報をコミットせずに資格情報管理するための.mcp.jsonでの環境変数展開（例：${GITHUB_TOKEN}） - 設定されたすべてのからのが接続時に発見され、に同時に利用可能 - 探索的呼び出しを減らすためのコンテンツカタログ（例：イシューサマリー、ドキュメント階層、データベーススキーマ）公開メカニズムとしてのリソース スキル： - 認証用の環境変数展開付きでプロジェクトスコープの.mcp.jsonに共有を設定 - ユーザースコープの~/.claude.jsonに個人/実験用を設定 - 説明を強化して機能と出力を詳細に説明し、がより高機能なより組み込み（Grepなど）を好むのを防止 - 標準的な統合（例：Jira）にはカスタム実装より既存のコミュニティを選択し、カスタムサーバーはチーム固有のワークフローに限定 - 探索的呼び出しを必要とせずにに利用可能データの可視性を提供するためリソースとしてコンテンツカタログを公開

English

Task Statement 2.5: Select and apply built-in tools (Read, Write, Edit, Bash, Grep, Glob) effectively Knowledge of: - Grep for content search (searching file contents for patterns like function names, error messages, or import statements) - Glob for file path pattern matching (finding files by name or extension patterns) - Read/Write for full file operations; Edit for targeted modifications using unique text matching - When Edit fails due to non-unique text matches, using Read + Write as a fallback for reliable file modifications in: - Selecting Grep for searching code content across a codebase (e.g., finding all callers of a function, locating error messages) - Selecting Glob for finding files matching naming patterns (e.g., **/*.test.tsx) - Using Read to load full file contents followed by Write when Edit cannot find unique anchor text - Building codebase understanding incrementally: starting with Grep to find entry points, then using Read to follow imports and trace flows, rather than reading all files upfront - Tracing function usage across wrapper modules by first identifying all exported names, then searching for each name across the codebase

日本語

タスクステートメント2.5：組み込み（Read、Write、Edit、Bash、Grep、Glob）の効果的な選択と適用 知識： - コンテンツ検索にはGrep（関数名、エラーメッセージ、import文などのパターンでファイル内容を検索） - ファイルパスパターンマッチングにはGlob（名前や拡張子パターンでファイルを検索） - フルファイル操作にはRead/Write、一意のテキストマッチングによるターゲット修正にはEdit - テキストの一意性がないためEditが失敗する場合、信頼性の高いファイル修正のフォールバックとしてRead + Writeを使用 スキル： - コードベース全体でコードコンテンツを検索するためにGrepを選択（例：関数のすべての呼び出し元の検索、エラーメッセージの特定） - 命名パターンに一致するファイルを検索するためにGlobを選択（例：**/*.test.tsx） - Editが一意のアンカーテキストを見つけられない場合にReadでフルファイル内容を読み込み後Writeを使用 - コードベース理解を段階的に構築：まずGrepでエントリポイントを見つけ、次にReadでインポートを追跡しフローをトレースする（すべてのファイルを事前に読み込むのではなく） - まずすべてのエクスポート名を特定し、次にコードベース全体で各名前を検索することにより、ラッパーモジュール間の関数使用をトレース

🐕🎓 シバと博士の解説

シバ
シバ
D2 は MCP とツール設計か。MCP って何がすごいの？
博士
博士
MCP は Claude と外部システムをつなぐ標準プロトコルだよ。試験では特に Tools（アクション実行）と Resources（データカタログの公開）が重要。Resources を使えば探索的なツール呼び出しを減らせるんだ。
シバ
シバ
ツールの「定義」と「実装」は別なんだ？
博士
博士
そこが大事なポイント！ ツール定義（名前・説明・パラメータのJSON Schema）は Claude が理解するためのもの。実装はサーバー側のコード。試験では特に「良いツール定義とは何か」が問われるよ。
↑ 目次に戻る

6-3. Domain 3: Claude Code Configuration & Workflows / ドメイン3：Claude Code設定とワークフロー

English

Task Statement 3.1: Configure files with appropriate hierarchy, scoping, and modular organization Knowledge of: - The configuration hierarchy: user-level (~/.claude/), project-level (.claude/ or root ), and directory-level (subdirectory files) - That user-level settings apply only to that user—instructions in ~/.claude/ are not shared with teammates via version control - The @import syntax for referencing external files to keep modular (e.g., importing specific standards files relevant to each package) - .claude/rules/ directory for organizing topic-specific rule files as an alternative to a monolithic in: - Diagnosing configuration hierarchy issues (e.g., a new team member not receiving instructions because they're in user-level rather than project-level configuration) - Using @import to selectively include relevant standards files in each package's based on maintainer domain knowledge - Splitting large files into focused topic-specific files in .claude/rules/ (e.g., testing.md, api-conventions.md, deployment.md) - Using the /memory command to verify which memory files are loaded and diagnose inconsistent behavior across sessions

日本語

タスクステートメント3.1：適切な階層、スコーピング、モジュール構成によるファイルの設定 知識： - 設定の階層：ユーザーレベル（~/.claude/）、プロジェクトレベル（.claude/またはルート）、ディレクトリレベル（サブディレクトリのファイル） - ユーザーレベル設定はそのユーザーにのみ適用される—~/.claude/の指示はバージョン管理を通じてチームメイトと共有されない - をモジュール化するための外部ファイル参照用@importシンタックス（例：各パッケージに関連する特定の規約ファイルをインポート） - モノリシックなの代替としてトピック別ルールファイルを整理する.claude/rules/ディレクトリ スキル： - 設定階層の問題診断（例：新しいチームメンバーがプロジェクトレベルではなくユーザーレベル設定にあるため指示を受け取れない） - メンテナーのドメイン知識に基づいて各パッケージのに関連する規約ファイルを選択的に含めるための@import使用 - 大きなファイルを.claude/rules/内のトピック別ファイルに分割（例：testing.md、api-conventions.md、deployment.md） - /memoryコマンドを使用してどのメモリファイルが読み込まれているか確認し、セッション間の不整合な動作を診断

English

Task Statement 3.2: Create and configure custom slash commands and skills Knowledge of: - Project-scoped commands in .claude/commands/ (shared via version control) vs user-scoped commands in ~/.claude/commands/ (personal) - in .claude/skills/ with SKILL.md files that support frontmatter configuration including context: fork, allowed-tools, and argument-hint - The context: fork frontmatter option for running skills in an isolated sub-agent context, preventing skill outputs from polluting the main conversation - Personal skill customization: creating personal variants in ~/.claude/skills/ with different names to avoid affecting teammates in: - Creating project-scoped slash commands in .claude/commands/ for team-wide availability via version control - Using context: fork to isolate skills that produce verbose output (e.g., codebase analysis) or exploratory context (e.g., brainstorming alternatives) from the main session - Configuring allowed-tools in skill frontmatter to restrict tool access during skill execution (e.g., limiting to file write operations to prevent destructive actions) - Using argument-hint frontmatter to prompt developers for required parameters when they invoke the skill without arguments - Choosing between skills (on-demand invocation for task-specific workflows) and (always-loaded universal standards)

日本語

タスクステートメント3.2：カスタムとスキルの作成と設定 知識： - .claude/commands/のプロジェクトスコープコマンド（バージョン管理で共有）vs ~/.claude/commands/のユーザースコープコマンド（個人用） - .claude/skills/のスキル：SKILL.mdファイルがfrontmatter設定（context: fork、allowed-tools、argument-hint）をサポート - スキルを分離されたコンテキストで実行し、スキル出力がメイン会話を汚染するのを防ぐcontext: forkフロントマターオプション - 個人スキルカスタマイズ：チームメイトに影響を与えないよう異なる名前で~/.claude/skills/に個人バリアントを作成 スキル： - バージョン管理によるチーム全体の利用のため.claude/commands/にプロジェクトスコープを作成 - 冗長な出力を生成するスキル（例：コードベース分析）や探索的コンテキスト（例：代替案のブレインストーミング）をメインセッションから分離するcontext: forkの使用 - スキル実行中のアクセスを制限するためskillフロントマターでallowed-toolsを設定（例：破壊的アクションを防ぐためファイル書き込み操作に制限） - 開発者が引数なしでスキルを呼び出した際に必要なパラメータの入力を促すargument-hintフロントマターの使用 - スキル（タスク固有ワークフローのオンデマンド呼び出し）と（常時ロードされるユニバーサル規約）の使い分け

English

Task Statement 3.3: Apply path-specific rules for conditional convention loading Knowledge of: - .claude/rules/ files with YAML frontmatter paths fields containing glob patterns for conditional rule activation - How path-scoped rules load only when editing matching files, reducing irrelevant context and token usage - The advantage of glob-pattern rules over directory-level files for conventions that span multiple directories (e.g., test files spread throughout a codebase) in: - Creating .claude/rules/ files with YAML frontmatter path scoping (e.g., paths: ["terraform/**/*"]) so rules load only when editing matching files - Using glob patterns in path-specific rules to apply conventions to files by type regardless of directory location (e.g., **/*.test.tsx for all test files) - Choosing path-specific rules over subdirectory files when conventions must apply to files spread across the codebase

日本語

タスクステートメント3.3：条件付き規約読み込みのためのパス固有ルールの適用 知識： - 条件付きルールアクティベーションのためのglobパターンを含むYAML frontmatterのpathsフィールドを持つ.claude/rules/ファイル - パススコープのルールはマッチするファイルの編集時のみ読み込まれ、無関係なコンテキストと使用量を削減 - 複数ディレクトリにまたがる規約（例：コードベース全体に散在するテストファイル）に対するディレクトリレベルファイルよりglobパターンルールの利点 スキル： - YAML frontmatterパススコーピング付きの.claude/rules/ファイルの作成（例：paths: ["terraform/**/*"]）でマッチするファイル編集時のみルールがロード - ディレクトリ位置に関係なくファイルタイプに基づいて規約を適用するパス固有ルールでのglobパターンの使用（例：すべてのテストファイルに**/*.test.tsx） - 規約がコードベース全体に散在するファイルに適用される場合、サブディレクトリファイルよりパス固有ルールを選択

English

Task Statement 3.4: Determine when to use plan mode vs direct execution Knowledge of: - Plan mode is designed for complex tasks involving large-scale changes, multiple valid approaches, architectural decisions, and multi-file modifications - Direct execution is appropriate for simple, well-scoped changes (e.g., adding a single validation check to one function) - Plan mode enables safe codebase exploration and design before committing to changes, preventing costly rework - The Explore subagent for isolating verbose discovery output and returning summaries to preserve main conversation context in: - Selecting plan mode for tasks with architectural implications (e.g., microservice restructuring, library migrations affecting 45+ files, choosing between integration approaches with different infrastructure requirements) - Selecting direct execution for well-understood changes with clear scope (e.g., a single-file bug fix with a clear stack trace, adding a date validation conditional) - Using the Explore subagent for verbose discovery phases to prevent context window exhaustion during multi-phase tasks - Combining plan mode for investigation with direct execution for implementation (e.g., planning a library migration, then executing the planned approach)

日本語

タスクステートメント3.4：と直接実行の使い分けの判断 知識： - は大規模な変更、複数の有効なアプローチ、アーキテクチャの意思決定、マルチファイル修正を伴う複雑なタスク向けに設計 - 直接実行は単純で明確にスコープされた変更に適切（例：1つの関数への単一バリデーションチェックの追加） - は変更をコミットする前に安全なコードベース探索と設計を可能にし、コストのかかる手戻りを防止 - 冗長な探索出力を分離しメイン会話コンテキストを保持するサマリーを返すExplore スキル： - アーキテクチャへの影響を伴うタスクにを選択（例：マイクロサービス再構築、45以上のファイルに影響するライブラリ移行、異なるインフラ要件を持つ統合アプローチの選択） - 明確なスコープを持つよく理解された変更に直接実行を選択（例：明確なスタックトレースがある単一ファイルのバグ修正、日付バリデーション条件の追加） - マルチフェーズタスクでの枯渇を防ぐため、冗長な探索フェーズにExploreを使用 - 調査に、実装に直接実行を組み合わせ（例：ライブラリ移行を計画し、計画されたアプローチを実行）

English

Task Statement 3.5: Apply iterative refinement techniques for progressive improvement Knowledge of: - Concrete input/output examples as the most effective way to communicate expected transformations when prose descriptions are interpreted inconsistently - Test-driven iteration: writing test suites first, then iterating by sharing test failures to guide progressive improvement - The interview pattern: having Claude ask questions to surface considerations the developer may not have anticipated before implementing - When to provide all issues in a single message (interacting problems) versus fixing them sequentially (independent problems) in: - Providing 2-3 concrete input/output examples to clarify transformation requirements when natural language descriptions produce inconsistent results - Writing test suites covering expected behavior, edge cases, and performance requirements before implementation, then iterating by sharing test failures - Using the interview pattern to surface design considerations (e.g., cache invalidation strategies, failure modes) before implementing solutions in unfamiliar domains - Providing specific test cases with example input and expected output to fix edge case handling (e.g., null values in migration scripts) - Addressing multiple interacting issues in a single detailed message when fixes interact, versus sequential iteration for independent issues

日本語

タスクステートメント3.5：段階的改善のための反復的改良テクニックの適用 知識： - 散文の説明が一貫性なく解釈される場合に期待される変換を伝える最も効果的な方法としての具体的な入出力例 - テスト駆動イテレーション：まずテストスイートを書き、テスト失敗を共有して段階的改善をガイド - インタビューパターン：実装前に開発者が予想していなかった考慮事項を表面化させるためClaudeに質問させる - すべての問題を単一メッセージで提供する場合（相互作用する問題）と順次修正する場合（独立した問題）の使い分け スキル： - 自然言語の説明が一貫性のない結果を生む場合に変換要件を明確にする2-3個の具体的な入出力例の提供 - 実装前に期待される動作、エッジケース、パフォーマンス要件をカバーするテストスイートの作成、テスト失敗の共有によるイテレーション - 不慣れなドメインでのソリューション実装前に設計考慮事項（例：キャッシュ無効化戦略、障害モード）を表面化させるインタビューパターンの使用 - エッジケース処理を修正するための例示入力と期待出力付き具体的テストケースの提供（例：移行スクリプトでのnull値） - 修正が相互作用する場合は単一の詳細メッセージで複数の問題に対処、独立した問題の場合は順次イテレーション

English

Task Statement 3.6: Integrate Claude Code into pipelines Knowledge of: - The -p (or --print) flag for running Claude Code in non-interactive mode in automated pipelines - --output-format json and --json-schema CLI flags for enforcing structured output in CI contexts - as the mechanism for providing project context (testing standards, fixture conventions, review criteria) to CI-invoked Claude Code - Session context isolation: why the same Claude session that generated code is less effective at reviewing its own changes compared to an independent review instance in: - Running Claude Code in CI with the -p flag to prevent interactive input hangs - Using --output-format json with --json-schema to produce machine-parseable structured findings for automated posting as inline PR comments - Including prior review findings in context when re-running reviews after new commits, instructing Claude to report only new or still-unaddressed issues to avoid duplicate comments - Providing existing test files in context so test generation avoids suggesting duplicate scenarios already covered by the test suite - Documenting testing standards, valuable test criteria, and available fixtures in to improve test generation quality and reduce low-value test output

日本語

タスクステートメント3.6：パイプラインへのClaude Code統合 知識： - 自動化パイプラインでClaude Codeを非対話モードで実行するための-p（または--print）フラグ - CIコンテキストで構造化出力を強制するための--output-format jsonと--json-schema CLIフラグ - CI呼び出しのClaude Codeにプロジェクトコンテキスト（テスト規約、フィクスチャ慣例、レビュー基準）を提供するメカニズムとしての - セッションコンテキスト分離：コードを生成した同じClaudeセッションが、独立したレビューインスタンスと比較して自身の変更をレビューする効果が低い理由 スキル： - 対話入力ハングを防ぐため-pフラグでCIでClaude Codeを実行 - インラインPRコメントとして自動投稿するための機械解析可能な構造化結果を生成する--output-format jsonと--json-schemaの使用 - 新しいコミット後にレビューを再実行する際にコンテキストに以前のレビュー結果を含め、重複コメントを避けるため新規または未対応の問題のみ報告するようClaudeに指示 - テスト生成がテストスイートで既にカバーされている重複シナリオを提案しないよう、既存テストファイルをコンテキストに提供 - テスト生成品質を向上させ低価値テスト出力を減らすため、にテスト規約、価値あるテスト基準、利用可能なフィクスチャを文書化

🐕🎓 シバと博士の解説

シバ
シバ
D3 は Claude Code か。CLAUDE.md って設定ファイルなの？
博士
博士
そう。プロジェクトのルールや慣例を Claude Code に伝えるためのマークダウンファイルだよ。「テストは必ず書く」「このライブラリを使う」みたいな指示を書いておくと、Claude Code がそれに従って動いてくれる。ユーザー/プロジェクト/ディレクトリの3階層で設定できるんだ。
シバ
シバ
Skills って何？
博士
博士
.claude/skills/ に SKILL.md を置いて Claude Code の能力を拡張するものだよ。context: fork や allowed-tools といったフロントマターで動作を制御できる。試験では Agent SDK の Hooks との区別も重要だよ。Hooks には、ツール結果をインターセプトするパターン（PostToolUse）と、送信前のツール呼び出しをインターセプトしてポリシー違反をブロックするパターンがある。
↑ 目次に戻る

6-4. Domain 4: Prompt Engineering & Structured Output / ドメイン4：プロンプトエンジニアリングと構造化出力

English

Task Statement 4.1: Design prompts with explicit criteria to improve precision and reduce false positives Knowledge of: - The importance of explicit criteria over vague instructions (e.g., "flag comments only when claimed behavior contradicts actual code behavior" vs "check that comments are accurate") - How general instructions like "be conservative" or "only report high-confidence findings" fail to improve precision compared to specific categorical criteria - The impact of false positive rates on developer trust: high false positive categories undermine confidence in accurate categories in: - Writing specific review criteria that define which issues to report (bugs, security) versus skip (minor style, local patterns) rather than relying on confidence-based filtering - Temporarily disabling high false-positive categories to restore developer trust while improving prompts for those categories - Defining explicit severity criteria with concrete code examples for each severity level to achieve consistent classification

日本語

タスクステートメント4.1：精度向上と偽陽性削減のための明示的基準を持つ設計 知識： - 曖昧な指示より明示的な基準の重要性（例：「コメントが正確かチェック」ではなく「主張された動作が実際のコード動作と矛盾する場合のみコメントをフラグ」） - 「保守的に」や「高信頼度の発見のみ報告」などの一般的な指示が、具体的なカテゴリ基準と比較して精度改善に失敗する理由 - 偽陽性率が開発者の信頼に与える影響：偽陽性の多いカテゴリが正確なカテゴリの信頼性も損なう スキル： - 信頼度ベースのフィルタリングに頼るのではなく、どの問題を報告し（バグ、セキュリティ）どれをスキップするか（軽微なスタイル、ローカルパターン）を定義する具体的なレビュー基準の記述 - 開発者の信頼を回復するため偽陽性の多いカテゴリを一時的に無効化し、それらのカテゴリのを改善 - 一貫した分類を実現するため各重大度レベルの具体的なコード例付き明示的重大度基準の定義

English

Task Statement 4.2: Apply few-shot prompting to improve output consistency and quality Knowledge of: - examples as the most effective technique for achieving consistently formatted, actionable output when detailed instructions alone produce inconsistent results - The role of few-shot examples in demonstrating ambiguous-case handling (e.g., tool selection for ambiguous requests, branch-level test coverage gaps) - How few-shot examples enable the model to generalize judgment to novel patterns rather than matching only pre-specified cases - The effectiveness of few-shot examples for reducing hallucination in extraction tasks (e.g., handling informal measurements, varied document structures) in: - Creating 2-4 targeted few-shot examples for ambiguous scenarios that show reasoning for why one action was chosen over plausible alternatives - Including few-shot examples that demonstrate specific desired output format (location, issue, severity, suggested fix) to achieve consistency - Providing few-shot examples distinguishing acceptable code patterns from genuine issues to reduce false positives while enabling generalization - Using few-shot examples to demonstrate correct handling of varied document structures (inline citations vs bibliographies, methodology sections vs embedded details) - Adding few-shot examples showing correct extraction from documents with varied formats to address empty/null extraction of required fields

日本語

タスクステートメント4.2：出力の一貫性と品質向上のためのプロンプティングの適用 知識： - 詳細な指示だけでは一貫性のない結果を生む場合に、一貫したフォーマットで実用的な出力を得る最も効果的な手法としての例 - 曖昧なケースの処理（例：曖昧なリクエストの選択、ブランチレベルのテストカバレッジギャップ）を示す例の役割 - 例がモデルに事前指定されたケースのみのマッチングではなく新しいパターンへの判断の一般化を可能にする仕組み - 抽出タスクでの幻覚を減らすための例の効果（例：非公式な測定値、様々なドキュメント構造の処理） スキル： - もっともらしい代替案よりなぜ1つのアクションが選択されたかの推論を示す曖昧なシナリオ向けの2-4個のターゲット型例の作成 - 一貫性を達成するため特定の望ましい出力フォーマット（位置、問題、重大度、修正提案）を示す例の含有 - 一般化を可能にしつつ偽陽性を削減するため、許容可能なコードパターンと本物の問題を区別する例の提供 - 様々なドキュメント構造（インライン引用vs参考文献、方法論セクションvs埋め込み詳細）の正しい処理を示す例の使用 - 必須フィールドの空/null抽出に対処するため様々なフォーマットのドキュメントからの正しい抽出を示す例の追加

English

Task Statement 4.3: Enforce structured output using tool use and schemas Knowledge of: - Tool use (tool_use) with schemas as the most reliable approach for guaranteed schema-compliant structured output, eliminating syntax errors - The distinction between : "auto" (model may return text instead of calling a tool), "any" (model must call a tool but can choose which), and forced tool selection (model must call a specific named tool) - That strict schemas via tool use eliminate syntax errors but do not prevent semantic errors (e.g., line items that don't sum to total, values in wrong fields) - Schema design considerations: required vs optional fields, enum fields with "other" + detail string patterns for extensible categories in: - Defining extraction tools with schemas as input parameters and extracting structured data from the tool_use response - Setting : "any" to guarantee structured output when multiple extraction schemas exist and the document type is unknown - Forcing a specific tool with : {"type": "tool", "name": "extract_metadata"} to ensure a particular extraction runs before enrichment steps - Designing schema fields as optional (nullable) when source documents may not contain the information, preventing the model from fabricating values to satisfy required fields - Adding enum values like "unclear" for ambiguous cases and "other" + detail fields for extensible categorization - Including format normalization rules in prompts alongside strict output schemas to handle inconsistent source formatting

日本語

タスクステートメント4.3：使用とを用いた構造化出力の強制 知識： - 構文エラーを排除するスキーマ準拠の構造化出力を保証する最も信頼性の高いアプローチとしての付きtool_use - : "auto"（モデルが呼び出しの代わりにテキストを返す可能性あり）、"any"（モデルはを呼び出す必要があるが選択可能）、強制選択（モデルは特定の名前付きを呼び出す必要あり）の区別 - tool_useによる厳格なは構文エラーを排除するがセマンティックエラーは防げない（例：合計に一致しない行項目、間違ったフィールドの値） - スキーマ設計の考慮事項：必須vs任意フィールド、拡張可能カテゴリのための"other" +詳細文字列パターン付きenumフィールド スキル： - を入力パラメータとする抽出の定義とtool_useレスポンスからの構造化データの抽出 - 複数の抽出スキーマが存在しドキュメントタイプが不明な場合に: "any"を設定して構造化出力を保証 - 特定の抽出がエンリッチメントステップの前に実行されることを保証するため: {"type": "tool", "name": "extract_metadata"}で特定を強制 - ソースドキュメントに情報がない可能性がある場合にスキーマフィールドをオプショナル（nullable）に設計し、モデルが必須フィールドを満たすために値を捏造するのを防止 - 曖昧なケースのための"unclear"などのenum値と拡張可能カテゴリのための"other" +詳細フィールドの追加 - 一貫性のないソースフォーマットを処理するため厳格な出力スキーマとともににフォーマット正規化ルールを含有

English

Task Statement 4.4: Implement validation, retry, and feedback loops for extraction quality Knowledge of: - Retry-with-error-feedback: appending specific validation errors to the prompt on retry to guide the model toward correction - The limits of retry: retries are ineffective when the required information is simply absent from the source document (vs format or structural errors) - Feedback loop design: tracking which code constructs trigger findings (detected_pattern field) to enable systematic analysis of dismissal patterns - The difference between semantic validation errors (values don't sum, wrong field placement) and schema syntax errors (eliminated by tool use) in: - Implementing follow-up requests that include the original document, the failed extraction, and specific validation errors for model self-correction - Identifying when retries will be ineffective (e.g., information exists only in an external document not provided) versus when they will succeed (format mismatches, structural output errors) - Adding detected_pattern fields to structured findings to enable analysis of false positive patterns when developers dismiss findings - Designing self-correction validation flows: extracting "calculated_total" alongside "stated_total" to flag discrepancies, adding "conflict_detected" booleans for inconsistent source data

日本語

タスクステートメント4.4：抽出品質のための検証、リトライ、フィードバックループの実装 知識： - エラーフィードバック付きリトライ：リトライ時にに具体的な検証エラーを追加してモデルの修正をガイド - リトライの限界：ソースドキュメントに必要な情報が単に存在しない場合（フォーマットや構造エラーとは異なり）、リトライは効果がない - フィードバックループ設計：どのコード構造が発見をトリガーするかを追跡（detected_patternフィールド）し、却下パターンの体系的分析を可能にする - セマンティック検証エラー（値が合計に一致しない、フィールド配置が間違い）とスキーマ構文エラー（tool_useで排除）の違い スキル： - 元のドキュメント、失敗した抽出、特定の検証エラーを含むフォローアップリクエストの実装（モデルの自己修正用） - リトライが効果的でない場合（例：情報が提供されていない外部ドキュメントにのみ存在）と成功する場合（フォーマット不一致、構造的出力エラー）の見極め - 開発者が発見を却下した際の偽陽性パターンの分析を可能にする構造化発見へのdetected_patternフィールドの追加 - 自己修正検証フローの設計：不一致をフラグするためstated_totalとともにcalculated_totalを抽出、不整合なソースデータのためのconflict_detectedブーリアンの追加

English

Task Statement 4.5: Design efficient batch processing strategies Knowledge of: - The Message Batches : 50% cost savings, up to 24-hour processing window, no guaranteed latency SLA - 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) - The batch does not support multi-turn tool calling within a single request (cannot execute tools mid-request and return results) - custom_id fields for correlating batch request/response pairs in: - Matching approach to workflow latency requirements: synchronous for blocking pre-merge checks, batch for overnight/weekly analysis - Calculating batch submission frequency based on SLA constraints (e.g., 4-hour windows to guarantee 30-hour SLA with 24-hour batch processing) - Handling batch failures: resubmitting only failed documents (identified by custom_id) with appropriate modifications (e.g., chunking documents that exceeded context limits) - Using prompt refinement on a sample set before batch-processing large volumes to maximize first-pass success rates and reduce iterative resubmission costs

日本語

タスクステートメント4.5：効率的な戦略の設計 知識： - Message Batches ：50%のコスト削減、最大24時間の処理ウィンドウ、保証されたレイテンシーSLAなし - はブロッキングでない遅延許容ワークロード（夜間レポート、週次監査、夜間テスト生成）に適切で、ブロッキングワークフロー（マージ前チェック）には不適切 - バッチは単一リクエスト内でのマルチターン呼び出しをサポートしない（リクエスト途中でを実行して結果を返すことができない） - バッチリクエスト/レスポンスペアの相関のためのcustom_idフィールド スキル： - ワークフローのレイテンシー要件にアプローチをマッチング：ブロッキングのマージ前チェックには同期、夜間/週次分析にはバッチ - SLA制約に基づくバッチ送信頻度の計算（例：24時間で30時間SLAを保証するための4時間ウィンドウ） - バッチ失敗の処理：失敗したドキュメントのみ（custom_idで特定）を適切な修正とともに再送信（例：コンテキスト制限を超えたドキュメントのチャンク化） - 大量前にサンプルセットで改善を行い、初回成功率を最大化し反復再送信コストを削減

English

Task Statement 4.6: Design multi-instance and multi-pass review architectures Knowledge of: - Self-review limitations: a model retains reasoning context from generation, making it less likely to question its own decisions in the same session - Independent review instances (without prior reasoning context) are more effective at catching subtle issues than self-review instructions or extended thinking - Multi-pass review: splitting large reviews into per-file local analysis passes plus cross-file integration passes to avoid attention dilution and contradictory findings in: - Using a second independent Claude instance to review generated code without the generator's reasoning context - Splitting large multi-file reviews into focused per-file passes for local issues plus separate integration passes for cross-file data flow analysis - Running verification passes where the model self-reports confidence alongside each finding to enable calibrated review routing

日本語

タスクステートメント4.6：マルチインスタンス・マルチパスレビューアーキテクチャの設計 知識： - セルフレビューの限界：モデルは生成時の推論コンテキストを保持するため、同じセッション内で自身の判断を疑いにくい - 独立したレビューインスタンス（事前の推論コンテキストなし）の方が、セルフレビュー指示や拡張思考より微妙な問題を検出するのに効果的 - マルチパスレビュー：注意の希薄化（attention dilution）と矛盾する発見を避けるため、大規模レビューをファイルごとのローカル分析パスとクロスファイル統合パスに分割 スキル： - 生成者の推論コンテキストなしで生成されたコードをレビューする第2の独立したClaudeインスタンスの使用 - 大規模マルチファイルレビューをローカル問題用のファイルごとの焦点パスとクロスファイルデータフロー分析用の個別統合パスに分割 - 各発見とともにモデルが信頼度を自己報告する検証パスを実行し、較正されたレビュールーティングを可能にする

🐕🎓 シバと博士の解説

シバ
シバ
D4 のプロンプトエンジニアリングって、いい感じにお願いすればいいだけじゃないの？
博士
博士
それだけじゃ試験には受からないよ（笑）。System Prompt の設計、Few-shot プロンプティング（具体例を添えて精度を上げる技法）、明示的なレビュー基準の設計、多パスレビューの構成——ガイドが正面から問うのはこのあたり。有名な Prefill や Chain-of-Thought といったテクニック名は、実はガイドには出てこないんだ。
シバ
シバ
核心原則ってここでも関係ある？
博士
博士
大いに関係ある！ 「保証が必要な振る舞いは、プロンプトではなくプログラム的に制御する」。プロンプトだけで制御しようとするのはアンチパターン。出力形式を保証したいなら tool use と JSON スキーマで構造化出力を強制する、みたいな判断が求められるよ。
↑ 目次に戻る

6-5. Domain 5: Context Management & Reliability / ドメイン5：コンテキスト管理と信頼性

English

Task Statement 5.1: Manage conversation context to preserve critical information across long interactions Knowledge of: - Progressive summarization risks: condensing numerical values, percentages, dates, and customer-stated expectations into vague summaries - The "lost in the middle" effect: models reliably process information at the beginning and end of long inputs but may omit findings from middle sections - How tool results accumulate in context and consume tokens disproportionately to their relevance (e.g., 40+ fields per order lookup when only 5 are relevant) - The importance of passing complete conversation history in subsequent requests to maintain conversational coherence in: - Extracting transactional facts (amounts, dates, order numbers, statuses) into a persistent "case facts" block included in each prompt, outside summarized history - Extracting and persisting structured issue data (order IDs, amounts, statuses) into a separate context layer for multi-issue sessions - Trimming verbose tool outputs to only relevant fields before they accumulate in context (e.g., keeping only return-relevant fields from order lookups) - Placing key findings summaries at the beginning of aggregated inputs and organizing detailed results with explicit section headers to mitigate position effects - Requiring subagents to include metadata (dates, source locations, methodological context) in structured outputs to support accurate downstream synthesis - Modifying upstream agents to return structured data (key facts, citations, relevance scores) instead of verbose content and reasoning chains when downstream agents have limited context budgets

日本語

タスクステートメント5.1：長い対話にわたって重要な情報を保持するための会話コンテキスト管理 知識： - 漸進的要約のリスク：数値、パーセンテージ、日付、顧客の期待を曖昧な要約に圧縮してしまう - 「中間部分の喪失」効果：モデルは長い入力の先頭と末尾の情報は確実に処理するが、中間部分の発見を見落とす可能性がある - 結果がコンテキストに蓄積し、関連性に不釣り合いなを消費する仕組み（例：5個のみ関連する場合に注文検索で40以上のフィールド） - 会話の整合性を維持するため後続のリクエストに完全な会話履歴を渡すことの重要性 スキル： - トランザクション事実（金額、日付、注文番号、ステータス）を要約履歴の外側で各に含まれる永続的な「ケースファクト」ブロックに抽出 - マルチイシューセッション用に構造化イシューデータ（注文ID、金額、ステータス）を別のコンテキストレイヤーに抽出・永続化 - コンテキストに蓄積する前に冗長な出力を関連フィールドのみにトリミング（例：注文検索から返品関連フィールドのみを保持） - 位置効果を軽減するため集約入力の先頭に重要発見のサマリーを配置し、明示的なセクションヘッダーで詳細結果を整理 - 正確な下流合成をサポートするため構造化出力にメタデータ（日付、ソース位置、方法論的コンテキスト）を含めることをに要求 - 下流のコンテキスト予算が限られている場合、冗長なコンテンツと推論チェーンではなく構造化データ（重要事実、引用、関連性スコア）を返すよう上流を修正

English

Task Statement 5.2: Design effective escalation and ambiguity resolution patterns Knowledge of: - Appropriate escalation triggers: customer requests for a human, policy exceptions/gaps (not just complex cases), and inability to make meaningful progress - The distinction between escalating immediately when a customer explicitly demands it versus offering to resolve when the issue is straightforward - Why sentiment-based escalation and self-reported confidence scores are unreliable proxies for actual case complexity - How multiple customer matches require clarification (requesting additional identifiers) rather than heuristic selection in: - Adding explicit escalation criteria with few-shot examples to the system prompt demonstrating when to escalate versus resolve autonomously - Honoring explicit customer requests for human agents immediately without first attempting investigation - Acknowledging frustration while offering resolution when the issue is within the agent's capability, escalating only if the customer reiterates their preference - Escalating when policy is ambiguous or silent on the customer's specific request (e.g., competitor price matching when policy only addresses own-site adjustments) - Instructing the agent to ask for additional identifiers when tool results return multiple matches, rather than selecting based on heuristics

日本語

タスクステートメント5.2：効果的なと曖昧さ解決パターンの設計 知識： - 適切なトリガー：人間への顧客リクエスト、ポリシーの例外/ギャップ（単に複雑なケースではなく）、有意義な進展を達成できない場合 - 顧客が明示的に要求した場合に即座にすることと、問題が単純な場合に解決を提案することの区別 - 感情ベースのと自己報告の信頼度スコアが実際のケースの複雑さの信頼できない代理指標である理由 - 複数の顧客マッチがヒューリスティック選択ではなく明確化（追加識別子の要求）を必要とする仕組み スキル： - いつし、いつ自律的に解決するかを示す例付き明示的基準をに追加 - 人間のへの明示的な顧客リクエストを調査を試みることなく即座に尊重 - 問題がの能力範囲内の場合はフラストレーションを認めつつ解決を提案し、顧客が希望を繰り返す場合のみ - ポリシーが顧客の特定のリクエストについて曖昧または沈黙している場合に（例：ポリシーが自社サイトの調整のみを扱う場合の競合他社価格マッチング） - 結果が複数マッチを返した場合にヒューリスティックに基づく選択ではなく追加識別子を求めるように指示

English

Task Statement 5.3: Implement error propagation strategies across multi-agent systems Knowledge of: - Structured error context (failure type, attempted query, partial results, alternative approaches) as enabling intelligent coordinator recovery decisions - The distinction between access failures (timeouts needing retry decisions) and valid empty results (successful queries with no matches) - Why generic error statuses ("search unavailable") hide valuable context from the coordinator - Why silently suppressing errors (returning empty results as success) or terminating entire workflows on single failures are both anti-patterns in: - Returning structured error context including failure type, what was attempted, partial results, and potential alternatives to enable coordinator recovery - Distinguishing access failures from valid empty results in error reporting so the coordinator can make appropriate decisions - Having subagents implement local recovery for transient failures and only propagate errors they cannot resolve, including what was attempted and partial results - Structuring synthesis output with coverage annotations indicating which findings are well-supported versus which topic areas have gaps due to unavailable sources

日本語

タスクステートメント5.3：マルチシステム全体でのエラー伝播戦略の実装 知識： - の賢明な復旧判断を可能にする構造化エラーコンテキスト（障害タイプ、試行したクエリ、部分的結果、代替アプローチ） - アクセス障害（リトライ判断が必要なタイムアウト）と有効な空結果（マッチなしの成功クエリ）の区別 - 汎用的なエラーステータス（"search unavailable"）がから貴重なコンテキストを隠す理由 - エラーの暗黙的抑制（空結果を成功として返す）も単一障害でのワークフロー全体終了もである理由 スキル： - の復旧を可能にするため、障害タイプ、試行内容、部分的結果、潜在的代替案を含む構造化エラーコンテキストの返却 - が適切な判断を下せるようエラー報告でアクセス障害と有効な空結果を区別 - が一時的障害のローカル復旧を実装し、解決できないエラーのみを試行内容と部分的結果とともに伝播 - どの発見が十分に裏付けられているか、どのトピック領域が利用不能なソースのためギャップがあるかを示すカバレッジ注釈付き合成出力の構造化

English

Task Statement 5.4: Manage context effectively in large codebase exploration Knowledge of: - Context degradation in extended sessions: models start giving inconsistent answers and referencing "typical patterns" rather than specific classes discovered earlier - The role of scratchpad files for persisting key findings across context boundaries - Subagent delegation for isolating verbose exploration output while the main agent coordinates high-level understanding - Structured state persistence for crash recovery: each agent exports state to a known location, and the coordinator loads a manifest on resume in: - Spawning subagents to investigate specific questions (e.g., "find all test files," "trace refund flow dependencies") while the main agent preserves high-level coordination - Having agents maintain scratchpad files recording key findings, referencing them for subsequent questions to counteract context degradation - Summarizing key findings from one exploration phase before spawning sub-agents for the next phase, injecting summaries into initial context - Designing crash recovery using structured agent state exports (manifests) that the coordinator loads on resume and injects into agent prompts - Using /compact to reduce context usage during extended exploration sessions when context fills with verbose discovery output

日本語

タスクステートメント5.4：大規模コードベース探索におけるコンテキストの効果的な管理 知識： - 長時間セッションでのコンテキスト劣化：モデルが一貫性のない回答を始め、以前発見した特定のクラスではなく「典型的なパターン」を参照する - コンテキスト境界を超えて重要な発見を永続化するためのスクラッチパッドファイルの役割 - メインが高レベルの理解を調整する間、冗長な探索出力を分離するための委任 - クラッシュ復旧のための構造化状態永続化：各が既知の場所に状態をエクスポートし、が再開時にマニフェストをロード スキル： - メインが高レベルの調整を保持しながら特定の質問を調査するための生成（例：「すべてのテストファイルを見つける」「返金フロー依存関係をトレースする」） - コンテキスト劣化に対抗するため重要な発見を記録するスクラッチパッドファイルをに維持させ、後続の質問で参照 - 1つの探索フェーズの重要な発見を要約してから次のフェーズのを生成し、サマリーを初期コンテキストに注入 - が再開時にロードしに注入する構造化状態エクスポート（マニフェスト）を使用したクラッシュ復旧の設計 - 冗長な探索出力でコンテキストが埋まった長時間の探索セッション中のコンテキスト使用量を削減するための/compact使用

English

Task Statement 5.5: Design human review workflows and confidence calibration Knowledge of: - The risk that aggregate accuracy metrics (e.g., 97% overall) may mask poor performance on specific document types or fields - Stratified random sampling for measuring error rates in high-confidence extractions and detecting novel error patterns - Field-level confidence scores calibrated using labeled validation sets for routing review attention - The importance of validating accuracy by document type and field segment before automating high-confidence extractions in: - Implementing stratified random sampling of high-confidence extractions for ongoing error rate measurement and novel pattern detection - Analyzing accuracy by document type and field to verify consistent performance across all segments before reducing human review - Having models output field-level confidence scores, then calibrating review thresholds using labeled validation sets - Routing extractions with low model confidence or ambiguous/contradictory source documents to human review, prioritizing limited reviewer capacity

日本語

タスクステートメント5.5：人間レビューワークフローと信頼度較正の設計 知識： - 全体的な精度指標（例：97%全体）が特定ドキュメントタイプやフィールドでの低パフォーマンスを隠す可能性のリスク - 高信頼度抽出のエラー率測定と新しいエラーパターン検出のための層別ランダムサンプリング - レビュー注意をルーティングするためラベル付き検証セットで較正されたフィールドレベル信頼度スコア - 高信頼度抽出の自動化前にドキュメントタイプとフィールドセグメントごとの精度を検証することの重要性 スキル： - 継続的なエラー率測定と新しいパターン検出のための高信頼度抽出の層別ランダムサンプリング実装 - 人間レビューを削減する前にすべてのセグメントで一貫したパフォーマンスを確認するためドキュメントタイプとフィールドごとの精度分析 - モデルにフィールドレベル信頼度スコアを出力させ、ラベル付き検証セットを使用してレビュー閾値を較正 - モデル信頼度が低いまたは曖昧/矛盾するソースドキュメントの抽出を人間レビューにルーティングし、限られたレビュアー能力を優先

English

Task Statement 5.6: Preserve information provenance and handle uncertainty in multi-source synthesis Knowledge of: - How source attribution is lost during summarization steps when findings are compressed without preserving claim-source mappings - The importance of structured claim-source mappings that the synthesis agent must preserve and merge when combining findings - How to handle conflicting statistics from credible sources: annotating conflicts with source attribution rather than arbitrarily selecting one value - Temporal data: requiring publication/collection dates in structured outputs to prevent temporal differences from being misinterpreted as contradictions in: - Requiring subagents to output structured claim-source mappings (source URLs, document names, relevant excerpts) that downstream agents preserve through synthesis - Structuring reports with explicit sections distinguishing well-established findings from contested ones, preserving original source characterizations and methodological context - Completing document analysis with conflicting values included and explicitly annotated, letting the coordinator decide how to reconcile before passing to synthesis - Requiring subagents to include publication or data collection dates in structured outputs to enable correct temporal interpretation - Rendering different content types appropriately in synthesis outputs—financial data as tables, news as prose, technical findings as structured lists—rather than converting everything to a uniform format

日本語

タスクステートメント5.6：マルチソース合成における情報の出所保持と不確実性の処理 知識： - 主張-出所マッピングを保持せずに発見が圧縮される要約ステップ中にソース帰属が失われる仕組み - 合成が発見を組み合わせる際に保持・マージすべき構造化主張-出所マッピングの重要性 - 信頼できるソースからの矛盾する統計の処理方法：1つの値を恣意的に選択するのではなくソース帰属の注釈で矛盾を注記 - 時系列データ：時間的差異が矛盾として誤解されるのを防ぐため構造化出力に出版/収集日を要求 スキル： - 下流が合成を通じて保持する構造化主張-出所マッピング（ソースURL、ドキュメント名、関連抜粋）の出力をに要求 - 確立された発見と争われている発見を区別する明示的セクション付きレポートの構造化（出典側の元の性格づけ・表現と方法論的コンテキストを保持） - 矛盾する値を含めて明示的に注釈を付けたドキュメント分析の完了（合成に渡す前にが調整方法を決定できるよう） - 正しい時系列解釈を可能にするため構造化出力に出版日またはデータ収集日を含めることをに要求 - 合成出力で異なるコンテンツタイプを適切にレンダリング—財務データはテーブル、ニュースは散文、技術的発見は構造化リスト—すべてを統一フォーマットに変換するのではなく

🐕🎓 シバと博士の解説

シバ
シバ
D5 のコンテキスト管理って、要は「入力が長すぎて困る」問題？
博士
博士
そうだね。Claude にはコンテキストウィンドウ（入力の最大長）があるから、大量の情報をどう効率的に渡すか、いつ要約するか、逆に何を要約せずに残すか、という設計判断が問われる。
シバ
シバ
Prompt Caching って何？
博士
博士
同じ System Prompt やドキュメントを何度も送るとコストがかさむよね。Prompt Caching は、そういった繰り返し部分をキャッシュして、コストと速度を改善する機能だよ。ただし試験では「存在を知っている」レベルで十分。実装詳細は出題範囲外と明記されているんだ。
↑ 目次に戻る

7. How to Prepare / 準備の進め方

English

To prepare for this certification exam:

日本語

この認定試験に向けた準備として：

English

Build an agent with the Claude Agent : implement a complete agentic loop with tool calling, error handling, and session management. Practice spawning subagents and passing context between them.

日本語

Claude Agent でを構築する：呼び出し、エラーハンドリング、セッション管理を含む完全なを実装します。の生成と、間でのコンテキストの受け渡しを練習します。

English

Configure Claude Code for a real project: set up with a configuration hierarchy, create path-specific rules in .claude/rules/, build custom skills with frontmatter options (context: fork, allowed-tools), and integrate at least one server.

日本語

実プロジェクトでClaude Codeを設定する：階層構成のをセットアップし、.claude/rules/ にパス固有ルールを作成し、frontmatterオプション（context: fork、allowed-tools）付きのカスタムスキルを作り、少なくとも1つのを統合します。

English

Design and test tools: write tool descriptions that clearly differentiate similar tools. Implement structured error responses with error categories and retryable flags. Test tool selection reliability with ambiguous requests.

日本語

を設計・テストする：類似を明確に区別できる説明文を書きます。エラーカテゴリとリトライ可否フラグを持つ構造化エラーレスポンスを実装します。曖昧なリクエストで選択の信頼性をテストします。

English

Build a structured data extraction pipeline: use tool_use with schemas, implement validation-retry loops, design schemas with optional/nullable fields, and practice batch processing with the Message Batches .

日本語

構造化データ抽出パイプラインを構築する：を伴うtool_useを使い、バリデーション・リトライループを実装し、オプショナル／nullableフィールドを持つスキーマを設計し、Message Batches でのを練習します。

English

Practice prompt engineering techniques: write few-shot examples for ambiguous scenarios. Define explicit review criteria to reduce false positives. Design multi-pass review architectures for large code reviews.

日本語

エンジニアリング手法を練習する：曖昧なシナリオ向けのfew-shot例を書きます。偽陽性を減らすための明示的なレビュー基準を定義します。大規模コードレビュー向けのマルチパスレビューアーキテクチャを設計します。

English

Study context management patterns: practice extracting structured facts from verbose tool outputs, implementing scratchpad files for long sessions, and designing subagent delegation to manage context limits.

日本語

コンテキスト管理パターンを学ぶ：冗長な出力からの構造化ファクト抽出、長時間セッション用スクラッチパッドファイルの実装、コンテキスト限界を管理するための委任の設計を練習します。

English

Review escalation and human-in-the-loop patterns: understand when to escalate (policy gaps, customer requests, inability to progress) versus resolve autonomously. Practice designing human review workflows with confidence-based routing.

日本語

とヒューマン・イン・ザ・ループのパターンを復習する：どのような場合にすべきか（ポリシーギャップ、顧客の要求、進展不能）と自律解決すべき場合を理解します。信頼度ベースのルーティングによる人間レビューワークフローの設計を練習します。

🐕🎓 シバと博士の解説

シバ
シバ
最後にまとめると、合格するために一番大事なことは？
博士
博士
3つだけ覚えて。 ① 公式ドキュメントを精読する — 試験の根拠はすべてここにある ② 核心原則を常に意識する — 「保証が必要な振る舞いは、プロンプトではなくプログラム的に制御する」 ③ アンチパターンを知る — 消去法で2〜3択を即排除できるようになる
シバ
シバ
よし、このアプリで Phase 0 から順番にやっていくぞ！
博士
博士
その意気だよ。焦らず、でも毎日少しずつ進めていこう。合格したらシュークリームでお祝いだね。
↑ 目次に戻る

8. Preparation Exercises / 準備演習

English

Complete these hands-on exercises to build practical familiarity with the topics covered on the exam. Each exercise is designed to reinforce knowledge across one or more exam domains.

日本語

試験でカバーされるトピックの実践的な理解を深めるため、これらのハンズオン演習を完了してください。各演習は1つ以上の試験ドメインにわたる知識を強化するよう設計されています。

English

Exercise 1: Build a Multi-Tool Agent with Escalation Logic Objective: Practice designing an agentic loop with tool integration, structured error handling, and escalation patterns. Steps: 1. Define 3-4 tools with detailed descriptions that clearly differentiate each tool's purpose, expected inputs, and boundary conditions. Include at least two tools with similar functionality that require careful description to avoid selection confusion. 2. Implement an agentic loop that checks to determine whether to continue tool execution or present the final response. Handle both "tool_use" and "end_turn" stop reasons correctly. 3. Add structured error responses to your tools: include errorCategory (transient/validation/permission), isRetryable boolean, and human-readable descriptions. Test that the agent handles each error type appropriately (retrying transient errors, explaining business errors to the user). 4. Implement a programmatic hook that intercepts tool calls to enforce a business rule (e.g., blocking operations above a threshold amount), redirecting to an escalation workflow when triggered. 5. Test with multi-concern messages (e.g., requests involving multiple issues) and verify the agent decomposes the request, handles each concern, and synthesizes a unified response. Domains reinforced: Domain 1 (Agentic Architecture & Orchestration), Domain 2 (Tool Design & Integration), Domain 5 (Context Management & Reliability)

日本語

演習1：ロジック付きマルチの構築 目的：統合、構造化エラーハンドリング、パターンを含むの設計を練習する。 手順： 1. 各の目的、期待入力、境界条件を明確に区別する詳細な説明付きの3-4個のを定義する。選択の混乱を避けるために慎重な説明が必要な類似機能を持つを少なくとも2つ含める。 2. 実行の継続または最終レスポンスの提示を決定するためにをチェックするを実装する。"tool_use"と"end_turn"の両方のを正しく処理する。 3. に構造化エラーレスポンスを追加：errorCategory（transient/validation/permission）、isRetryableブーリアン、人間が読める説明を含める。が各エラータイプを適切に処理することをテスト（一時的エラーのリトライ、ビジネスエラーのユーザーへの説明）。 4. ビジネスルールを適用するために呼び出しをインターセプトするプログラム的を実装（例：閾値を超える操作のブロック）、トリガーされた際にワークフローにリダイレクト。 5. 複数の懸念を含むメッセージ（例：複数の問題を含むリクエスト）でテストし、がリクエストを分解し、各懸念を処理し、統一されたレスポンスを合成することを検証。 強化されるドメイン：ドメイン1（アーキテクチャとオーケストレーション）、ドメイン2（設計と統合）、ドメイン5（コンテキスト管理と信頼性）

English

Exercise 2: Configure Claude Code for a Team Development Workflow Objective: Practice configuring hierarchies, custom slash commands, path-specific rules, and server integration for a multi-developer project. Steps: 1. Create a project-level with universal coding standards and testing conventions. Verify that instructions placed at the project level are consistently applied across all team members. 2. Create .claude/rules/ files with YAML frontmatter glob patterns for different code areas (e.g., paths: ["src/api/**/*"] for conventions, paths: ["**/*.test.*"] for testing conventions). Test that rules load only when editing matching files. 3. Create a project-scoped skill in .claude/skills/ with context: fork and allowed-tools restrictions. Verify the skill runs in isolation without polluting the main conversation context. 4. Configure an server in .mcp.json with environment variable expansion for credentials. Add a personal experimental server in ~/.claude.json and verify both are available simultaneously. 5. Test plan mode versus direct execution on tasks of varying complexity: a single-file bug fix, a multi-file library migration, and a new feature with multiple valid implementation approaches. Observe when plan mode provides value. Domains reinforced: Domain 3 (Claude Code Configuration & Workflows), Domain 2 (Tool Design & Integration)

日本語

演習2：チーム開発ワークフロー用のClaude Code設定 目的：マルチ開発者プロジェクトのための階層、カスタム、パス固有ルール、統合の設定を練習する。 手順： 1. ユニバーサルコーディング規約とテスト慣例を含むプロジェクトレベルのを作成。プロジェクトレベルに配置された指示がすべてのチームメンバーに一貫して適用されることを検証。 2. 異なるコード領域用のYAMLフロントマターglobパターン付き.claude/rules/ファイルを作成（例：慣例用のpaths: ["src/api/**/*"]、テスト慣例用のpaths: ["**/*.test.*"]）。ルールがマッチするファイルの編集時のみロードされることをテスト。 3. context: forkとallowed-tools制限付きの.claude/skills/にプロジェクトスコープスキルを作成。スキルがメイン会話コンテキストを汚染せずに分離して実行されることを検証。 4. 資格情報用の環境変数展開付きで.mcp.jsonにを設定。~/.claude.jsonに個人実験用を追加し、両方が同時に利用可能であることを検証。 5. 様々な複雑さのタスクでと直接実行をテスト：単一ファイルのバグ修正、マルチファイルのライブラリ移行、複数の有効な実装アプローチを持つ新機能。が価値を提供する時を観察。 強化されるドメイン：ドメイン3（Claude Code設定とワークフロー）、ドメイン2（設計と統合）

English

Exercise 3: Build a Structured Data Extraction Pipeline Objective: Practice designing schemas, using tool_use for structured output, implementing validation-retry loops, and designing batch processing strategies. Steps: 1. Define an extraction tool with a schema containing required and optional fields, an enum with an "other" + detail string pattern, and nullable fields for information that may not exist in source documents. Process documents where some fields are absent and verify the model returns null rather than fabricating values. 2. Implement a validation-retry loop: when Pydantic or schema validation fails, send a follow-up request including the document, the failed extraction, and the specific validation error. Track which errors are resolvable via retry (format mismatches) versus which are not (information absent from source). 3. Add few-shot examples demonstrating extraction from documents with varied formats (e.g., inline citations vs bibliographies, narrative descriptions vs structured tables) and verify improved handling of structural variety. 4. Design a batch processing strategy: submit a batch of 100 documents using the Message Batches , handle failures by custom_id, resubmit failed documents with modifications (e.g., chunking oversized documents), and calculate total processing time relative to SLA constraints. 5. Implement a human review routing strategy: have the model output field-level confidence scores, route low-confidence extractions to human review, and analyze accuracy by document type and field to verify consistent performance. Domains reinforced: Domain 4 (Prompt Engineering & Structured Output), Domain 5 (Context Management & Reliability)

日本語

演習3：構造化データ抽出パイプラインの構築 目的：の設計、構造化出力のためのtool_use使用、バリデーション・リトライループの実装、戦略の設計を練習する。 手順： 1. 必須フィールドと任意フィールド、"other" +詳細文字列パターン付きenum、ソースドキュメントに存在しない可能性のある情報用のnullableフィールドを含むで抽出を定義。一部のフィールドがないドキュメントを処理し、モデルが値を捏造するのではなくnullを返すことを検証。 2. バリデーション・リトライループを実装：Pydanticまたは検証が失敗した場合、ドキュメント、失敗した抽出、特定の検証エラーを含むフォローアップリクエストを送信。リトライで解決可能なエラー（フォーマット不一致）と不可能なエラー（ソースに情報がない）を追跡。 3. 様々なフォーマットのドキュメント（例：インライン引用vs参考文献、ナラティブ記述vs構造化テーブル）からの抽出を示す例を追加し、構造的多様性の処理改善を検証。 4. 戦略を設計：Message Batches で100ドキュメントのバッチを送信、custom_idで障害を処理、修正とともに失敗ドキュメントを再送信（例：オーバーサイズドキュメントのチャンク化）、SLA制約に対する総処理時間を計算。 5. 人間レビュールーティング戦略を実装：モデルにフィールドレベル信頼度スコアを出力させ、低信頼度抽出を人間レビューにルーティング、ドキュメントタイプとフィールドごとの精度を分析して一貫したパフォーマンスを検証。 強化されるドメイン：ドメイン4（エンジニアリングと構造化出力）、ドメイン5（コンテキスト管理と信頼性）

English

Exercise 4: Design and Debug a Multi-Agent Research Pipeline Objective: Practice orchestrating subagents, managing context passing, implementing error propagation, and handling synthesis with provenance tracking. Steps: 1. Build a coordinator agent that delegates to at least two subagents (e.g., web search and document analysis). Ensure the coordinator's allowedTools includes "Task" and that each subagent receives its research findings directly in its prompt rather than relying on automatic context inheritance. 2. Implement parallel subagent execution by having the coordinator emit multiple Task tool calls in a single response. Measure the latency improvement compared to sequential execution. 3. Design structured output for subagents that separates content from metadata: each finding should include a claim, evidence excerpt, source URL/document name, and publication date. Verify that the synthesis subagent preserves source attribution when combining findings. 4. Implement error propagation: simulate a subagent timeout and verify the coordinator receives structured error context (failure type, attempted query, partial results). Test that the coordinator can proceed with partial results and annotate the final output with coverage gaps. 5. Test with conflicting source data (e.g., two credible sources with different statistics) and verify the synthesis output preserves both values with source attribution rather than arbitrarily selecting one, and structures the report to distinguish well-established from contested findings. Domains reinforced: Domain 1 (Agentic Architecture & Orchestration), Domain 2 (Tool Design & Integration), Domain 5 (Context Management & Reliability)

日本語

演習4：マルチリサーチパイプラインの設計とデバッグ 目的：のオーケストレーション、コンテキスト受け渡しの管理、エラー伝播の実装、出所追跡付き合成の処理を練習する。 手順： 1. 少なくとも2つの（例：Web検索とドキュメント分析）に委任するを構築。のallowedToolsに"Task"が含まれ、各が自動コンテキスト継承に依存するのではなくでリサーチ発見を直接受け取ることを確認。 2. が単一レスポンスで複数のTask呼び出しを発行して並列実行を実装。順次実行と比較してレイテンシー改善を測定。 3. コンテンツとメタデータを分離するの構造化出力を設計：各発見には主張、証拠抜粋、ソースURL/ドキュメント名、出版日を含める。合成が発見を組み合わせる際にソース帰属を保持することを検証。 4. エラー伝播を実装：のタイムアウトをシミュレートし、が構造化エラーコンテキスト（障害タイプ、試行したクエリ、部分的結果）を受け取ることを検証。が部分的結果で続行し最終出力にカバレッジギャップの注釈を付けることをテスト。 5. 矛盾するソースデータ（例：異なる統計を持つ2つの信頼できるソース）でテストし、合成出力が1つを恣意的に選択するのではなく両方の値をソース帰属付きで保持し、確立された発見と争われている発見を区別するようレポートを構造化することを検証。 強化されるドメイン：ドメイン1（アーキテクチャとオーケストレーション）、ドメイン2（設計と統合）、ドメイン5（コンテキスト管理と信頼性）

🐕🎓 シバと博士の解説

シバ
シバ
公式の準備演習って、全部やった方がいい？
博士
博士
できればやった方がいいけど、優先順位をつけよう。まず Exam Guide のサンプル問題を解く → 次に Practice Test → 余裕があれば演習問題、という順番がおすすめだよ。
↑ 目次に戻る

9. Sample Questions / サンプル問題

English

The following sample questions illustrate the format and difficulty level of the exam. These are drawn from the practice test and include explanations to aid learning.

日本語

以下のサンプル問題は、試験の形式と難易度を示しています。これらは模擬試験から抜粋されたもので、学習を助けるための解説が含まれています。

English

Scenario: Customer Support Resolution Agent Question 1: Production data shows that in 12% of cases, your agent skips get_customer entirely and calls lookup_order using only the customer's stated name, occasionally leading to misidentified accounts and incorrect refunds. What change would most effectively address this reliability issue? A) Add a programmatic prerequisite that blocks lookup_order and process_refund calls until get_customer has returned a verified customer ID. B) Enhance the system prompt to state that customer verification via get_customer is mandatory before any order operations. C) Add few-shot examples showing the agent always calling get_customer first, even when customers volunteer order details. D) Implement a routing classifier that analyzes each request and enables only the subset of tools appropriate for that request type. Correct Answer: A When a specific tool sequence is required for critical business logic (like verifying customer identity before processing refunds), programmatic enforcement provides deterministic guarantees that prompt-based approaches cannot. Options B and C rely on probabilistic compliance, which is insufficient when errors have financial consequences. Option D addresses tool availability rather than tool ordering, which is not the actual problem.

日本語

シナリオ：カスタマーサポート解決 問題1：本番データによると、12%のケースでがget_customerを完全にスキップし、顧客の申告した名前のみでlookup_orderを呼び出し、時にアカウントの誤認識と誤った返金につながっています。この信頼性の問題に最も効果的に対処する変更は何ですか？ A) get_customerが検証済み顧客IDを返すまでlookup_orderとprocess_refundの呼び出しをブロックするプログラム的前提条件を追加する。 B) get_customerによる顧客確認が注文操作の前に必須であることをで明記する。 C) 顧客が注文詳細を自発的に提供した場合でもが常にget_customerを最初に呼び出す例を追加する。 D) 各リクエストを分析し、そのリクエストタイプに適切なのサブセットのみを有効にするルーティング分類器を実装する。 正解：A 重要なビジネスロジック（返金処理前の顧客本人確認など）に特定のシーケンスが必要な場合、はベースのアプローチでは不可能な保証を提供します。選択肢BとCは確率的なコンプライアンスに依存しており、エラーが金銭的影響を持つ場合には不十分です。選択肢Dはの順序付けではなくの利用可能性に対処するものであり、実際の問題とは異なります。

English

Question 2: Production logs show the agent frequently calls get_customer when users ask about orders (e.g., "check my order #12345"), instead of calling lookup_order. Both tools have minimal descriptions ("Retrieves customer information" / "Retrieves order details") and accept similar identifier formats. What's the most effective first step to improve tool selection reliability? A) Add few-shot examples to the system prompt demonstrating correct tool selection patterns, with 5-8 examples showing order-related queries routing to lookup_order. B) Expand each tool's description to include input formats it handles, example queries, edge cases, and boundaries explaining when to use it versus similar tools. C) Implement a routing layer that parses user input before each turn and pre-selects the appropriate tool based on detected keywords and identifier patterns. D) Consolidate both tools into a single lookup_entity tool that accepts any identifier and internally determines which backend to query. Correct Answer: B Tool descriptions are the primary mechanism s use for tool selection. When descriptions are minimal, models lack the context to differentiate between similar tools. Option B directly addresses this root cause with a low-effort, high-leverage fix. examples (A) add token overhead without fixing the underlying issue. A routing layer (C) is over-engineered and bypasses the 's natural language understanding. Consolidating tools (D) is a valid architectural choice but requires more effort than a "first step" warrants when the immediate problem is inadequate descriptions.

日本語

問題2：本番ログによると、ユーザーが注文について質問した際（例：「注文#12345を確認して」）、がlookup_orderではなく頻繁にget_customerを呼び出しています。両は最小限の説明（「顧客情報を取得」/「注文詳細を取得」）を持ち、類似の識別子形式を受け付けます。選択の信頼性を改善する最も効果的な最初のステップは何ですか？ A) 正しい選択パターンを示す例をに追加し、注文関連クエリがlookup_orderにルーティングされる5-8個の例を示す。 B) 各の説明を拡張し、処理する入力形式、クエリ例、エッジケース、類似との使い分けの境界を含める。 C) 各ターンの前にユーザー入力を解析し、検出されたキーワードと識別子パターンに基づいて適切なを事前選択するルーティングレイヤーを実装する。 D) 両を任意の識別子を受け付け内部的にどのバックエンドにクエリするかを決定する単一のlookup_entityに統合する。 正解：B 説明はが選択に使用する主要なメカニズムです。説明が最小限の場合、モデルは類似を区別するためのコンテキストが不足します。選択肢Bはこの根本原因を低コスト・高効果な修正で直接対処します。例（A）は根本的な問題を修正せずオーバーヘッドを追加します。ルーティングレイヤー（C）は過剰設計での自然言語理解をバイパスします。統合（D）は有効なアーキテクチャ選択ですが、直近の問題が不十分な説明である場合「最初のステップ」にはより多くの労力を必要とします。

English

Question 3: Your agent achieves 55% first-contact resolution, well below the 80% target. Logs show it escalates straightforward cases (standard damage replacements with photo evidence) while attempting to autonomously handle complex situations requiring policy exceptions. What's the most effective way to improve escalation calibration? A) Add explicit escalation criteria to your system prompt with few-shot examples demonstrating when to escalate versus resolve autonomously. B) Have the agent self-report a confidence score (1-10) before each response and automatically route requests to humans when confidence falls below a threshold. C) Deploy a separate classifier model trained on historical tickets to predict which requests need escalation before the main agent begins processing. D) Implement sentiment analysis to detect customer frustration levels and automatically escalate when negative sentiment exceeds a threshold. Correct Answer: A Adding explicit escalation criteria with few-shot examples directly addresses the root cause: unclear decision boundaries. This is the proportionate first response before adding infrastructure. Option B fails because self-reported confidence is poorly calibrated—the agent is already incorrectly confident on hard cases. Option C is over-engineered, requiring labeled data and ML infrastructure when prompt optimization hasn't been tried. Option D solves a different problem entirely; sentiment doesn't correlate with case complexity, which is the actual issue.

日本語

問題3：の初回解決率は55%で、80%の目標を大きく下回っています。ログによると、単純なケース（写真証拠付きの標準的な損傷交換）をする一方、ポリシー例外を必要とする複雑な状況を自律的に処理しようとしています。較正を改善する最も効果的な方法は何ですか？ A) いつし、いつ自律的に解決するかを示す例付きの明示的な基準をに追加する。 B) が各レスポンス前に信頼度スコア（1-10）を自己報告し、信頼度が閾値を下回るとリクエストを自動的に人間にルーティングする。 C) メインが処理を開始する前に、過去のチケットで訓練された別の分類器モデルをして、どのリクエストにが必要かを予測する。 D) 感情分析を実装して顧客のフラストレーションレベルを検出し、ネガティブ感情が閾値を超えると自動的にする。 正解：A 明示的な基準と例の追加は、根本原因である不明確な判断境界に直接対処します。これはインフラストラクチャを追加する前の適切な最初の対応です。選択肢Bはの自己報告信頼度が不正確に較正されているため失敗します—は既に困難なケースで誤って自信を持っています。選択肢Cは最適化が試されていない段階でラベル付きデータとMLインフラを必要とする過剰設計です。選択肢Dは全く別の問題を解決します。感情はケースの複雑さ（実際の問題）と相関しません。

English

Scenario: Code Generation with Claude Code Question 4: You want to create a custom /review slash command that runs your team's standard code review checklist. This command should be available to every developer when they clone or pull the repository. Where should you create this command file? A) In the .claude/commands/ directory in the project repository B) In ~/.claude/commands/ in each developer's home directory C) In the file at the project root D) In a .claude/config.json file with a commands array Correct Answer: A Project-scoped custom slash commands should be stored in the .claude/commands/ directory within the repository. These commands are version-controlled and automatically available to all developers when they clone or pull the repo. Option B (~/.claude/commands/) is for personal commands that aren't shared via version control. Option C () is for project instructions and context, not command definitions. Option D describes a configuration mechanism that doesn't exist in Claude Code.

日本語

シナリオ：Claude Codeによるコード生成 問題4：チームの標準コードレビューチェックリストを実行するカスタム/reviewを作成したいと考えています。このコマンドはすべての開発者がリポジトリをクローンまたはプルした際に利用可能である必要があります。このコマンドファイルはどこに作成すべきですか？ A) プロジェクトリポジトリの.claude/commands/ディレクトリ B) 各開発者のホームディレクトリの~/.claude/commands/ C) プロジェクトルートのファイル D) commands配列を持つ.claude/config.jsonファイル 正解：A プロジェクトスコープのカスタムはリポジトリ内の.claude/commands/ディレクトリに保存すべきです。これらのコマンドはバージョン管理され、開発者がリポジトリをクローンまたはプルすると自動的に利用可能になります。選択肢B（~/.claude/commands/）はバージョン管理で共有されない個人コマンド用です。選択肢C（）はプロジェクトの指示とコンテキスト用で、コマンド定義用ではありません。選択肢DはClaude Codeに存在しない設定メカニズムを説明しています。

English

Question 5: You've been assigned to restructure the team's monolithic application into microservices. This will involve changes across dozens of files and requires decisions about service boundaries and module dependencies. Which approach should you take? A) Enter plan mode to explore the codebase, understand dependencies, and design an implementation approach before making changes. B) Start with direct execution and make changes incrementally, letting the implementation reveal the natural service boundaries. C) Use direct execution with comprehensive upfront instructions detailing exactly how each service should be structured. D) Begin in direct execution mode and only switch to plan mode if you encounter unexpected complexity during implementation. Correct Answer: A Plan mode is designed for complex tasks involving large-scale changes, multiple valid approaches, and architectural decisions—exactly what monolith-to-microservices restructuring requires. It enables safe codebase exploration and design before committing to changes. Option B risks costly rework when dependencies are discovered late. Option C assumes you already know the right structure without exploring the code. Option D ignores that the complexity is already stated in the requirements, not something that might emerge later.

日本語

問題5：チームのモノリシックアプリケーションをマイクロサービスに再構築する任務を任されました。これは数十のファイルにまたがる変更を伴い、サービス境界とモジュール依存関係に関する判断が必要です。どのアプローチを取るべきですか？ A) に入り、コードベースを探索し、依存関係を理解し、変更を加える前に実装アプローチを設計する。 B) 直接実行から始め、段階的に変更を行い、実装が自然なサービス境界を明らかにするのに任せる。 C) 各サービスがどのように構造化されるべきかを正確に詳述する包括的な事前指示とともに直接実行を使用する。 D) 直接実行モードで開始し、実装中に予期しない複雑さに遭遇した場合のみに切り替える。 正解：A は大規模な変更、複数の有効なアプローチ、アーキテクチャの意思決定を伴う複雑なタスク向けに設計されています。これはまさにモノリスからマイクロサービスへの再構築に必要なものです。変更をコミットする前に安全なコードベース探索と設計を可能にします。選択肢Bは依存関係が遅くに発見された場合にコストのかかる手戻りのリスクがあります。選択肢Cはコードを探索せずに正しい構造をすでに知っていると仮定しています。選択肢Dは複雑さが要件に既に記載されており、後から出現するものではないことを無視しています。

English

Question 6: Your codebase has distinct areas with different coding conventions: React components use functional style with hooks, handlers use async/await with specific error handling, and database models follow a repository pattern. Test files are spread throughout the codebase alongside the code they test (e.g., Button.test.tsx next to Button.tsx), and you want all tests to follow the same conventions regardless of location. What's the most maintainable way to ensure Claude automatically applies the correct conventions when generating code? A) Create rule files in .claude/rules/ with YAML frontmatter specifying glob patterns to conditionally apply conventions based on file paths. B) Consolidate all conventions in the root file under headers for each area, relying on Claude to infer which section applies C) Create skills in .claude/skills/ for each code type that include the relevant conventions in their SKILL.md files D) Place a separate file in each subdirectory containing that area's specific conventions Correct Answer: A Option A is correct because .claude/rules/ with glob patterns (e.g., **/*.test.tsx) allows conventions to be automatically applied based on file paths regardless of directory location—essential for test files spread throughout the codebase. Option B relies on inference rather than explicit matching, making it unreliable. Option C requires manual skill invocation or relies on Claude choosing to load them, contradicting the need for deterministic "automatic" application based on file paths. Option D can't easily handle files spread across many directories since files are directory-bound.

日本語

問題6：コードベースには異なるコーディング規約を持つ領域があります：Reactコンポーネントは付き関数型スタイル、ハンドラーはasync/awaitと特定のエラーハンドリング、データベースモデルはリポジトリパターンに従います。テストファイルはテスト対象のコードの隣にコードベース全体に散在しており（例：Button.tsxの隣のButton.test.tsx）、場所に関係なくすべてのテストが同じ規約に従うようにしたいと考えています。Claudeがコード生成時に正しい規約を自動的に適用する最も保守可能な方法は何ですか？ A) .claude/rules/にYAMLフロントマターでglobパターンを指定するルールファイルを作成し、ファイルパスに基づいて条件付きで規約を適用する。 B) ルートファイルに各領域のヘッダーの下にすべての規約を統合し、Claudeがどのセクションが適用されるかを推論することに依存する。 C) 各コードタイプ用の.claude/skills/にスキルを作成し、SKILL.mdファイルに関連する規約を含める。 D) 各サブディレクトリにその領域固有の規約を含む別のファイルを配置する。 正解：A 選択肢Aが正しいのは、.claude/rules/のglobパターン（例：**/*.test.tsx）がディレクトリの場所に関係なくファイルパスに基づいて規約を自動適用できるためです。これはコードベース全体に散在するテストファイルに不可欠です。選択肢Bは明示的マッチングではなく推論に依存し、信頼性が低くなります。選択肢Cは手動スキル呼び出しが必要またはClaudeがロードを選択することに依存し、ファイルパスに基づくな「自動」適用の必要性と矛盾します。選択肢Dはファイルがディレクトリに紐づくため、多くのディレクトリに散在するファイルを簡単に処理できません。

English

Scenario: Multi-Agent Research System Question 7: After running the system on the topic "impact of AI on creative industries," you observe that each subagent completes successfully: the web search agent finds relevant articles, the document analysis agent summarizes papers correctly, and the synthesis agent produces coherent output. However, the final reports cover only visual arts, completely missing music, writing, and film production. When you examine the coordinator's logs, you see it decomposed the topic into three subtasks: "AI in digital art creation," "AI in graphic design," and "AI in photography." What is the most likely root cause? A) The synthesis agent lacks instructions for identifying coverage gaps in the findings it receives from other agents. B) The coordinator agent's task decomposition is too narrow, resulting in subagent assignments that don't cover all relevant domains of the topic. C) The web search agent's queries are not comprehensive enough and need to be expanded to cover more creative industry sectors. D) The document analysis agent is filtering out sources related to non-visual creative industries due to overly restrictive relevance criteria. Correct Answer: B The coordinator's logs reveal the root cause directly: it decomposed "creative industries" into only visual arts subtasks (digital art, graphic design, photography), completely omitting music, writing, and film. The subagents executed their assigned tasks correctly—the problem is what they were assigned. Options A, C, and D incorrectly blame downstream agents that are working correctly within their assigned scope.

日本語

シナリオ：マルチリサーチシステム 問題7：「AIのクリエイティブ産業への影響」というトピックでシステムを実行した後、各は正常に完了しました：Web検索は関連記事を見つけ、ドキュメント分析は論文を正しく要約し、合成は一貫した出力を生成しました。しかし、最終レポートは視覚芸術のみをカバーし、音楽、執筆、映画制作を完全に見落としています。のログを調べると、トピックを3つのサブタスクに分解していました：「デジタルアート制作におけるAI」「グラフィックデザインにおけるAI」「写真におけるAI」。最も可能性の高い根本原因は何ですか？ A) 合成が他のから受け取った発見のカバレッジギャップを特定するための指示を持っていない。 B) のタスク分解が狭すぎ、トピックの関連するすべてのドメインをカバーしない割り当てになっている。 C) Web検索のクエリが十分に包括的ではなく、より多くのクリエイティブ産業セクターをカバーするよう拡張する必要がある。 D) ドキュメント分析が過度に制限的な関連性基準のため非視覚系クリエイティブ産業に関するソースをフィルタリングしている。 正解：B のログが根本原因を直接明らかにしています：「クリエイティブ産業」を視覚芸術のサブタスク（デジタルアート、グラフィックデザイン、写真）のみに分解し、音楽、執筆、映画を完全に省略しました。は割り当てられたタスクを正しく実行しました—問題は何が割り当てられたかです。選択肢A、C、Dは、割り当てられた範囲内で正しく動作している下流を誤って非難しています。

English

Question 8: The web search subagent times out while researching a complex topic. You need to design how this failure information flows back to the coordinator agent. Which error propagation approach best enables intelligent recovery? A) Return structured error context to the coordinator including the failure type, the attempted query, any partial results, and potential alternative approaches. B) Implement automatic retry logic with exponential backoff within the subagent, returning a generic "search unavailable" status only after all retries are exhausted. C) Catch the timeout within the subagent and return an empty result set marked as successful. D) Propagate the timeout exception directly to a top-level handler that terminates the entire research workflow. Correct Answer: A Structured error context gives the coordinator the information it needs to make intelligent recovery decisions—whether to retry with a modified query, try an alternative approach, or proceed with partial results. Option B's generic status hides valuable context from the coordinator, preventing informed decisions. Option C suppresses the error by marking failure as success, which prevents any recovery and risks incomplete research outputs. Option D terminates the entire workflow unnecessarily when recovery strategies could succeed.

日本語

問題8：Web検索が複雑なトピックの調査中にタイムアウトします。この障害情報がにどのように戻るかを設計する必要があります。インテリジェントな復旧を最もよく可能にするエラー伝播アプローチはどれですか？ A) 障害タイプ、試行したクエリ、部分的結果、潜在的な代替アプローチを含む構造化エラーコンテキストをに返す。 B) 内に指数バックオフ付きの自動リトライロジックを実装し、すべてのリトライが尽きた後にのみ汎用的な「検索利用不可」ステータスを返す。 C) 内でタイムアウトをキャッチし、成功としてマークされた空の結果セットを返す。 D) タイムアウト例外をリサーチワークフロー全体を終了するトップレベルハンドラーに直接伝播する。 正解：A 構造化エラーコンテキストはにインテリジェントな復旧判断に必要な情報を提供します—修正クエリでリトライするか、代替アプローチを試すか、部分的結果で進めるか。選択肢Bの汎用ステータスはから貴重なコンテキストを隠し、情報に基づく判断を妨げます。選択肢Cは障害を成功としてマークしてエラーを抑制し、復旧を妨げ不完全な研究出力のリスクがあります。選択肢Dは復旧戦略が成功する可能性がある場合に不必要にワークフロー全体を終了します。

English

Question 9: During testing, you observe that the synthesis agent frequently needs to verify specific claims while combining findings. Currently, when verification is needed, the synthesis agent returns control to the coordinator, which invokes the web search agent, then re-invokes synthesis with results. This adds 2-3 round trips per task and increases latency by 40%. Your evaluation shows that 85% of these verifications are simple fact-checks (dates, names, statistics) while 15% require deeper investigation. What's the most effective approach to reduce overhead while maintaining system reliability? A) Give the synthesis agent a scoped verify_fact tool for simple lookups, while complex verifications continue delegating to the web search agent through the coordinator. B) Have the synthesis agent accumulate all verification needs and return them as a batch to the coordinator at the end of its pass, which then sends them all to the web search agent at once. C) Give the synthesis agent access to all web search tools so it can handle any verification need directly without round-trips through the coordinator. D) Have the web search agent proactively cache extra context around each source during initial research, anticipating what the synthesis agent might need to verify. Correct Answer: A Option A applies the principle of least privilege by giving the synthesis agent only what it needs for the 85% common case (simple fact verification) while preserving the existing coordination pattern for complex cases. Option B's batching approach creates blocking dependencies since synthesis steps may depend on earlier verified facts. Option C over-provisions the synthesis agent, violating separation of concerns. Option D relies on speculative caching that cannot reliably predict what the synthesis agent will need to verify.

日本語

問題9：テスト中、合成が発見を組み合わせる際に特定の主張を頻繁に検証する必要があることが観察されます。現在、検証が必要な場合、合成がに制御を返し、がWeb検索を呼び出し、結果とともに合成を再呼び出しします。これはタスクごとに2-3回のラウンドトリップを追加し、レイテンシーを40%増加させます。評価によると、これらの検証の85%は単純なファクトチェック（日付、名前、統計）で、15%がより深い調査を必要とします。オーバーヘッドを削減しつつシステムの信頼性を維持する最も効果的なアプローチは何ですか？ A) 単純な検索用のスコープ付きverify_factを合成に付与し、複雑な検証はを通じてWeb検索への委任を継続する。 B) 合成にすべての検証ニーズを蓄積させ、パスの終了時にバッチとしてに返し、がそれらをすべて一度にWeb検索に送信する。 C) 合成にすべてのWeb検索へのアクセスを付与し、を経由するラウンドトリップなしにあらゆる検証ニーズを直接処理できるようにする。 D) Web検索が初期リサーチ中に各ソース周辺の追加コンテキストをプロアクティブにキャッシュし、合成が検証する必要があるものを予測する。 正解：A 選択肢Aは最小権限の原則を適用し、85%の一般的なケース（単純なファクト検証）に必要なものだけを合成に付与し、複雑なケースには既存の調整パターンを維持します。選択肢Bのバッチングアプローチは合成ステップが先に検証された事実に依存する可能性があるためブロッキング依存関係を作成します。選択肢Cは合成を過剰プロビジョニングし、関心の分離に違反します。選択肢Dは合成が何を検証する必要があるかを確実に予測できない投機的キャッシングに依存します。

English

Scenario: Claude Code for Continuous Integration Question 10: Your pipeline script runs claude "Analyze this pull request for security issues" but the job hangs indefinitely. Logs indicate Claude Code is waiting for interactive input. What's the correct approach to run Claude Code in an automated pipeline? A) Add the -p flag: claude -p "Analyze this pull request for security issues" B) Set the environment variable CLAUDE_HEADLESS=true before running the command C) Redirect stdin from /dev/null: claude "Analyze this pull request for security issues" < /dev/null D) Add the --batch flag: claude --batch "Analyze this pull request for security issues" Correct Answer: A The -p (or --print) flag is the documented way to run Claude Code in non-interactive mode. It processes the prompt, outputs the result to stdout, and exits without waiting for user input—exactly what pipelines require. The other options reference non-existent features (CLAUDE_HEADLESS environment variable, --batch flag) or use Unix workarounds that don't properly address Claude Code's command syntax.

日本語

シナリオ：におけるClaude Code 問題10：パイプラインスクリプトがclaude "Analyze this pull request for security issues"を実行しますが、ジョブが無限にハングします。ログによるとClaude Codeが対話入力を待っています。自動化パイプラインでClaude Codeを実行する正しいアプローチは何ですか？ A) -pフラグを追加する：claude -p "Analyze this pull request for security issues" B) コマンド実行前に環境変数CLAUDE_HEADLESS=trueを設定する C) /dev/nullからstdinをリダイレクトする：claude "Analyze this pull request for security issues" < /dev/null D) --batchフラグを追加する：claude --batch "Analyze this pull request for security issues" 正解：A -p（または--print）フラグはClaude Codeを非対話モードで実行するための文書化された方法です。を処理し、結果をstdoutに出力し、ユーザー入力を待たずに終了します—まさにパイプラインが必要とするものです。他の選択肢は存在しない機能（CLAUDE_HEADLESS環境変数、--batchフラグ）を参照するか、Claude Codeのコマンド構文に適切に対処しないUnix回避策を使用しています。

English

Question 11: Your team wants to reduce costs for automated analysis. Currently, real-time Claude calls power two workflows: (1) a blocking pre-merge check that must complete before developers can merge, and (2) a technical debt report generated overnight for review the next morning. Your manager proposes switching both to the Message Batches for its 50% cost savings. How should you evaluate this proposal? A) Use batch processing for the technical debt reports only; keep real-time calls for pre-merge checks. B) Switch both workflows to batch processing with status polling to check for completion. C) Keep real-time calls for both workflows to avoid batch result ordering issues. D) Switch both to batch processing with a timeout fallback to real-time if batches take too long. Correct Answer: A The Message Batches offers 50% cost savings but has processing times up to 24 hours with no guaranteed latency SLA. This makes it unsuitable for blocking pre-merge checks where developers wait for results, but ideal for overnight batch jobs like technical debt reports. Option B is wrong because relying on "often faster" completion isn't acceptable for blocking workflows. Option C reflects a misconception—batch results can be correlated using custom_id fields. Option D adds unnecessary complexity when the simpler solution is matching each to its appropriate use case.

日本語

問題11：チームは自動分析のコストを削減したいと考えています。現在、リアルタイムClaude呼び出しが2つのワークフローを支えています：(1) 開発者がマージする前に完了する必要があるブロッキングのマージ前チェック、(2) 翌朝のレビュー用に夜間生成される技術的負債レポート。マネージャーは50%のコスト削減のため両方をMessage Batches に切り替えることを提案しています。この提案をどう評価すべきですか？ A) は技術的負債レポートのみに使用し、マージ前チェックにはリアルタイム呼び出しを維持する。 B) 完了チェックのステータスポーリング付きで両ワークフローをに切り替える。 C) バッチ結果の順序問題を避けるため両ワークフローにリアルタイム呼び出しを維持する。 D) 両方をに切り替え、バッチが長すぎる場合はリアルタイムへのタイムアウトフォールバックを設ける。 正解：A Message Batches は50%のコスト削減を提供しますが、処理時間は最大24時間で保証されたレイテンシーSLAがありません。これにより開発者が結果を待つブロッキングのマージ前チェックには不適切ですが、技術的負債レポートのような夜間バッチジョブには理想的です。選択肢Bは「多くの場合より速い」完了に依存することがブロッキングワークフローに許容されないため誤りです。選択肢Cはバッチ結果がcustom_idフィールドで相関できるという点を誤解しています。選択肢Dは各を適切なユースケースにマッチングするシンプルな解決策があるのに不必要な複雑さを追加します。

English

Question 12: A pull request modifies 14 files across the stock tracking module. Your single-pass review analyzing all files together produces inconsistent results: detailed feedback for some files but superficial comments for others, obvious bugs missed, and contradictory feedback—flagging a pattern as problematic in one file while approving identical code elsewhere in the same PR. How should you restructure the review? A) Split into focused passes: analyze each file individually for local issues, then run a separate integration-focused pass examining cross-file data flow. B) Require developers to split large PRs into smaller submissions of 3-4 files before the automated review runs. C) Switch to a higher-tier model with a larger context window to give all 14 files adequate attention in one pass. D) Run three independent review passes on the full PR and only flag issues that appear in at least two of the three runs. Correct Answer: A Splitting reviews into focused passes directly addresses the root cause: attention dilution when processing many files at once. File-by-file analysis ensures consistent depth, while a separate integration pass catches cross-file issues. Option B shifts burden to developers without improving the system. Option C misunderstands that larger context windows don't solve attention quality issues. Option D would actually suppress detection of real bugs by requiring consensus on issues that may only be caught intermittently.

日本語

問題12：プルリクエストが在庫追跡モジュール全体で14ファイルを修正しています。すべてのファイルを一度に分析するシングルパスレビューが一貫性のない結果を生成します：一部のファイルには詳細なフィードバックがある一方、他のファイルには表面的なコメントのみ、明らかなバグの見落とし、矛盾したフィードバック—あるファイルでパターンを問題としてフラグしながら、同じPRの別の場所で同一コードを承認しています。レビューをどのように再構築すべきですか？ A) 焦点を絞ったパスに分割する：ローカルの問題について各ファイルを個別に分析し、次にクロスファイルデータフローを検査する別の統合焦点パスを実行する。 B) 自動レビューの実行前に開発者に大きなPRを3-4ファイルの小さな提出に分割することを要求する。 C) すべての14ファイルに1パスで十分な注意を払えるよう、より大きなを持つ上位モデルに切り替える。 D) フルPRに対して3つの独立したレビューパスを実行し、3回のうち少なくとも2回に現れる問題のみをフラグする。 正解：A レビューを焦点を絞ったパスに分割することで、根本原因に直接対処します：多くのファイルを一度に処理する際の注意の希薄化（attention dilution）です。ファイルごとの分析で一貫した深さを確保し、別の統合パスでクロスファイルの問題をキャッチします。選択肢Bはシステムを改善せずに開発者に負担を転嫁します。選択肢Cはより大きなが注意品質の問題を解決しないことを誤解しています。選択肢Dは断続的にしか検出されない問題に対してコンセンサスを要求することで実際のバグの検出を抑制してしまいます。

🐕🎓 シバと博士の解説

シバ
シバ
サンプル問題、今の段階で解ける気がしないんだけど…
博士
博士
それが正常だよ！ Phase 0 の目的は「解ける」ことじゃなくて「どんなレベルの問題が出るか」を体感すること。Phase 1〜4 を終えた後に戻ってくれば、ちゃんと解けるようになっているはずだよ。
シバ
シバ
不正解の選択肢も見た方がいい？
博士
博士
むしろ不正解の方が大事かも。「なぜこれが間違いなのか」の解説を読むと、試験で使える消去法のパターンが見えてくるんだ。アンチパターンを知ることは、正解を覚えるのと同じくらい価値があるよ。
↑ 目次に戻る

10. How the Exam Is Scored / 採点方式

English

The Claude Certified Architect – Foundations exam is a criterion-referenced assessment: each candidate is measured against a fixed performance standard, not against other candidates. You pass by demonstrating the knowledge and skills defined in the blueprint, not by outperforming a percentage of peers.

日本語

Claude Certified Architect – Foundations試験は基準準拠評価です。各受験者は固定された合格基準に対して測定され、他の受験者との比較では測定されません。合格は、ブループリントに定義された知識とスキルを実証することで決まり、他の受験者の一定割合を上回ることによってではありません。

English

Passing standard: The passing score was established through a formal standard-setting study in which trained subject matter experts judged the level of performance expected of a minimally qualified candidate. The score is reported on a scaled range of 100–1,000, and the cut score is 720. Scaled scoring models help equate scores across multiple exam forms that might have slightly different difficulty levels.

日本語

合格基準：合格スコアは、訓練を受けた領域専門家が「最低限の資格を満たす受験者」に期待される到達水準を判定する正式な基準設定調査によって定められました。スコアは100〜1,000のスケールで報告され、合格ラインは720です。スケールドスコアリングは、難易度がわずかに異なりうる複数の試験フォーム間でスコアを等化するのに役立ちます。

English

Result reporting: Your result is reported as a pass or fail status with a scaled score from 100 to 1,000. Your score report also shows the percentage of items you answered correctly within each content domain. Section-level percentages are provided to help you understand your performance and are not used to determine your pass or fail result, which is based on your total scaled score.

日本語

結果通知：結果は、100〜1,000のスケールドスコアとともに合否として通知されます。スコアレポートには、各内容ドメイン内で正答した問題の割合も表示されます。ドメイン別の正答率は自身のパフォーマンス理解を助けるために提供されるもので、合否判定には使われません。合否は総合スケールドスコアに基づいて決まります。
↑ 目次に戻る

11. Registration and Scheduling / 登録と予約

English

Registration and scheduling are handled through the Anthropic Partner Academy and Pearson VUE:

日本語

登録と予約は、Anthropic Partner AcademyとPearson VUEを通じて行います：

English

1. Go to the certification page for your exam on the Anthropic Partner Academy and review the exam details. 2. Download the Exam Guide and review the Certification Terms and Conditions and the Certification Exam Policy before registering. 3. Register for the exam and complete checkout. The fee shown at checkout reflects any discount that applies to your partner tier.

日本語

1. Anthropic Partner Academyの当該試験の認定ページにアクセスし、試験の詳細を確認します。 2. Exam Guideをダウンロードし、登録前に認定利用規約と認定試験ポリシーを確認します。 3. 試験に登録し、決済を完了します。決済時に表示される料金には、パートナーティアに応じた割引が反映されます。

English

4. Follow the confirmation instructions to create your Pearson VUE account, then sign in to schedule your exam session. 5. Choose an available date and select either online proctoring or a Pearson test center. The exam is delivered by Pearson VUE. 6. You may cancel or reschedule up to 24 hours before your appointment. Changes made within 24 hours forfeit the exam fee.

日本語

4. 確認の案内に従ってPearson VUEアカウントを作成し、サインインして試験セッションを予約します。 5. 空いている日付を選び、オンライン監督またはPearsonテストセンターのいずれかを選択します。試験はPearson VUEによって配信されます。 6. 予約の24時間前までキャンセル・変更が可能です。24時間を切ってからの変更は受験料が没収されます。
↑ 目次に戻る

12. Exam Policies / 試験ポリシー

English

Identification: On exam day you must present a valid, unexpired, government-issued photo identification. The name on your ID must match the name on your registration exactly. If you need to correct the name on your registration, contact certifications-support@anthropic.com before scheduling your exam.

日本語

本人確認：試験当日は、有効期限内の政府発行の写真付き身分証明書を提示する必要があります。身分証明書の氏名は登録時の氏名と完全に一致していなければなりません。登録氏名の修正が必要な場合は、試験を予約する前に certifications-support@anthropic.com に連絡してください。

English

Accommodations: Reasonable accommodations are available for candidates with documented disabilities or needs, in accordance with applicable law. Accommodations must be requested and approved by Pearson VUE before you schedule your exam. Do not schedule your appointment until your request has been approved. Request accommodations at pearsonvue.com/us/en/test-takers/accommodations.

日本語

配慮措置：適用法令に従い、証明可能な障害やニーズを持つ受験者には合理的配慮が提供されます。配慮措置は、試験を予約する前にPearson VUEへ申請し、承認を受ける必要があります。申請が承認されるまで予約しないでください。配慮措置の申請は pearsonvue.com/us/en/test-takers/accommodations から行います。

English

Retake policy: Candidates who do not pass may retake the exam after a required waiting period. Waiting periods increase with each failed attempt: 14 days after the first, 30 days after the second, and 90 days after the third. You may take an exam up to four times within a rolling twelve-month period. Limits apply per exam, so not passing one exam does not prevent you from registering for a different one. The exam fee applies to each attempt.

日本語

再受験ポリシー：不合格の場合、所定の待機期間の後に再受験できます。待機期間は不合格のたびに長くなります：1回目の後は14日、2回目の後は30日、3回目の後は90日。直近12ヶ月間で同一試験を受験できるのは最大4回です。回数制限は試験ごとに適用されるため、ある試験に不合格でも別の試験への登録は妨げられません。受験料は毎回かかります。

English

No-show and late arrival: Candidates who fail to appear for a scheduled exam, or who arrive after the permitted late-arrival window, forfeit the exam fee and must re-register. Cancellation and rescheduling deadlines are described in Section 11.

日本語

無断欠席と遅刻：予約した試験に現れなかった場合、または許容される遅刻時間を過ぎて到着した場合は、受験料が没収され、再登録が必要になります。キャンセルと予約変更の期限は第11章に記載のとおりです。
↑ 目次に戻る

13. Exam-Day Experience and Rules of Conduct / 試験当日の流れと行動規範

English

The exam is administered in a standardized, secure, proctored environment. Whether you test online or at a Pearson VUE test center, the following rules apply to protect the integrity of the credential for everyone who holds it.

日本語

試験は標準化された安全な監督付き環境で実施されます。オンライン受験でもPearson VUEテストセンターでの受験でも、資格保持者全員のために資格の信頼性を守る目的で、以下のルールが適用されます。

English

During the exam you must: remain within view of the proctor and webcam for the entire session (if testing online); keep your workspace clear of notes, books, phones, secondary monitors, and other materials; refrain from communicating with any other person during the exam; not capture, copy, photograph, or reproduce any exam content in any form.

日本語

試験中は次を守る必要があります：（オンライン受験の場合）セッション全体を通じて監督とWebカメラの視野内に留まる／机上にメモ・書籍・スマートフォン・サブモニタその他の資料を置かない／試験中に他者と連絡を取らない／試験内容をいかなる形でも記録・複製・撮影・再現しない。

English

Prohibited items include mobile phones, smart watches, headphones, study materials, and any recording device. Permitted items, if any, such as scratch paper provided by the proctor, are specified by Pearson VUE.

日本語

持ち込み禁止品には、携帯電話、スマートウォッチ、ヘッドホン、学習資料、あらゆる録音・録画機器が含まれます。監督者が提供するメモ用紙など、許可される持ち物がある場合はPearson VUEが指定します。

English

Consequences of misconduct: Cheating, attempting to access prohibited resources, or disclosing exam content may result in invalidation of your result, revocation of your credential, and a ban from future exams.

日本語

不正行為の帰結：カンニング、禁止されたリソースへのアクセスの試み、試験内容の漏洩は、結果の無効化、資格の取り消し、今後の受験禁止につながる可能性があります。
↑ 目次に戻る

14. Confidentiality and Non-Disclosure Agreement / 秘密保持契約（NDA）

English

Before the exam begins you must accept a confidentiality and non-disclosure agreement. By accepting, you agree that all exam content, including questions, answer options, and scenarios, is the confidential and proprietary property of Anthropic, and that you will not disclose, reproduce, or distribute any portion of it. If you do not accept the agreement, the exam session ends and no refund is issued.

日本語

試験開始前に、秘密保持契約（NDA）に同意する必要があります。同意により、問題・選択肢・シナリオを含むすべての試験内容がAnthropicの機密かつ専有の財産であること、そしてそのいかなる部分も開示・複製・配布しないことに同意したことになります。契約に同意しない場合、試験セッションは終了し、返金はされません。
↑ 目次に戻る

15. Credential Maintenance and Recertification / 資格の維持と更新

English

The Claude Certified Architect – Foundations credential is valid for 12 months from the date it is awarded. Because the underlying technology evolves rapidly, the credential is time-limited so that holders maintain current knowledge.

日本語

Claude Certified Architect – Foundations資格は、認定日から12ヶ月間有効です。基盤となる技術の進化が速いため、保持者が最新の知識を維持できるよう、資格には期限が設けられています。

English

To renew on time, you review what has changed since you certified and complete a free, non-proctored assessment on the Anthropic Partner Academy. There is no fee for on-time renewal. If your credential lapses, you must retake the full exam at the full fee to regain certified status.

日本語

期限内の更新では、認定取得後の変更点を確認し、Anthropic Partner Academy上で無料・監督なしのアセスメントを完了します。期限内更新に費用はかかりません。資格が失効した場合は、正規の受験料で本試験を再受験して認定を取り戻す必要があります。

English

If exam content changes significantly, Anthropic may require holders to retake the full exam to recertify rather than complete the renewal assessment. Holders remain subject to the rules of conduct described in Section 13.

日本語

試験内容が大きく変わった場合、Anthropicは更新アセスメントではなく本試験の再受験による再認定を求めることがあります。資格保持者は、第13章に記載の行動規範に引き続き従う義務があります。
↑ 目次に戻る

16. Candidate Support, Appeals, and Privacy / サポート・不服申立て・プライバシー

English

Support: To correct the name on your registration, contact certifications-support@anthropic.com. For all other questions, including registration, scheduling, accommodations, and results, contact Pearson VUE support at pearsonvue.com/us/en/anthropic.html.

日本語

サポート：登録氏名の修正は certifications-support@anthropic.com へ連絡してください。登録・予約・配慮措置・結果に関するその他すべての質問は、Pearson VUEサポート（pearsonvue.com/us/en/anthropic.html）へ連絡してください。

English

Appeals and complaints: You may appeal a decision within 14 days of the date you are notified of it, or, for a concern about your exam result, within 14 days of your exam date. Submit your appeal to Pearson VUE support at the link above. Appeals are reviewed under the program's appeals policy. The standard-setting outcome and the content of individual exam items are not subject to appeal.

日本語

不服申立てと苦情：決定の通知日から14日以内、または試験結果に関する懸念については試験日から14日以内に不服申立てができます。不服申立ては上記リンクのPearson VUEサポートに提出してください。不服申立てはプログラムの不服申立てポリシーに基づき審査されます。合格基準の設定結果および個々の試験問題の内容は、不服申立ての対象外です。

English

Privacy: Personal data collected during registration and testing is handled in accordance with Anthropic's privacy policy, Pearson VUE's privacy policy, and applicable data-protection law.

日本語

プライバシー：登録および受験の過程で収集される個人データは、Anthropicのプライバシーポリシー、Pearson VUEのプライバシーポリシー、および適用されるデータ保護法に従って取り扱われます。
↑ 目次に戻る

17-1. Appendix: Technologies and Concepts / 付録：テクノロジーとコンセプト

English

The following list contains technologies and concepts that might appear on the exam:

日本語

以下のリストは、試験に出題される可能性のあるテクノロジーとコンセプトを含みます：

English

Claude Agent — Agent definitions, agentic loops, handling, hooks (PostToolUse, tool call interception), subagent spawning via Task tool, allowedTools configuration

日本語

Claude Agent — 定義、、ハンドリング、（PostToolUse、呼び出しインターセプション）、Taskによる生成、allowedTools設定

English

Model Context Protocol () — servers, tools, resources, isError flag, tool descriptions, tool distribution, .mcp.json configuration, environment variable expansion

日本語

Model Context Protocol () — 、、リソース、isErrorフラグ、説明、配布、.mcp.json設定、環境変数展開

English

Claude Code — configuration hierarchy (user/project/directory), .claude/rules/ with YAML frontmatter path-scoping, .claude/commands/ for slash commands, .claude/skills/ with SKILL.md frontmatter (context: fork, allowed-tools, argument-hint), plan mode, direct execution, /memory command, /compact, --resume, fork_session, Explore subagent

日本語

Claude Code — 設定階層（ユーザー/プロジェクト/ディレクトリ）、YAMLフロントマターパススコーピング付き.claude/rules/、用.claude/commands/、SKILL.mdフロントマター付き.claude/skills/（context: fork、allowed-tools、argument-hint）、、直接実行、/memoryコマンド、/compact、--resume、fork_session、Explore

English

Claude Code CLI — -p / --print flag for non-interactive mode, --output-format json, --json-schema for structured CI output

日本語

Claude Code CLI — 非対話モード用-p / --printフラグ、--output-format json、構造化CI出力用--json-schema

English

Claude — tool_use with schemas, options ("auto", "any", forced tool selection), values ("tool_use", "end_turn"), max_tokens, system prompts

日本語

Claude — 付きtool_use、オプション（"auto"、"any"、強制選択）、値（"tool_use"、"end_turn"）、max_tokens、

English

Message Batches — 50% cost savings, up to 24-hour processing window, custom_id for request/response correlation, polling for completion, no multi-turn tool calling support

日本語

Message Batches — 50%のコスト削減、最大24時間の処理ウィンドウ、リクエスト/レスポンス相関用custom_id、完了ポーリング、マルチターン呼び出し非対応

English

— Required vs optional fields, enum types, nullable fields, "other" + detail string patterns, strict mode for syntax error elimination

日本語

— 必須vs任意フィールド、enumタイプ、nullableフィールド、"other" +詳細文字列パターン、構文エラー排除のための厳格モード

English

Pydantic — Schema validation, semantic validation errors, validation-retry loops

日本語

Pydantic — スキーマ検証、セマンティック検証エラー、バリデーション・リトライループ

English

Built-in tools — Read, Write, Edit, Bash, Grep, Glob — their purposes and selection criteria

日本語

組み込み — Read、Write、Edit、Bash、Grep、Glob — それぞれの目的と選択基準

English

prompting — Targeted examples for ambiguous scenarios, format demonstration, generalization to novel patterns

日本語

プロンプティング — 曖昧なシナリオ向けターゲット例、フォーマットデモンストレーション、新しいパターンへの一般化

English

Prompt chaining — Sequential task decomposition into focused passes

日本語

チェイニング — 焦点を絞ったパスへの順次タスク分解

English

Context window management — Token budgets, progressive summarization, lost-in-the-middle effects, context extraction, scratchpad files

日本語

管理 — 予算、漸進的要約、中間部分喪失効果、コンテキスト抽出、スクラッチパッドファイル

English

Session management — Session resumption, fork_session, named sessions, session context isolation

日本語

セッション管理 — セッション再開、fork_session、名前付きセッション、セッションコンテキスト分離

English

Confidence scoring — Field-level confidence, calibration with labeled validation sets, stratified sampling for error rate measurement

日本語

信頼度スコアリング — フィールドレベル信頼度、ラベル付き検証セットでの較正、エラー率測定のための層別サンプリング

🐕🎓 シバと博士の解説

シバ
シバ
付録に載ってる技術一覧、全部覚えないとダメ？
博士
博士
暗記する必要はないよ。これは「試験に出る可能性がある技術の範囲」を示したもの。各技術が何のためにあるかを理解していれば十分。名前と目的を結びつけられればOKだよ。
↑ 目次に戻る

17-2. Appendix: In-Scope Topics / 付録：出題範囲トピック

English

The following topics are explicitly tested on the exam:

日本語

以下のトピックは試験で明示的にテストされます：

English

Agentic loop implementation: Control flow based on , tool result handling, loop termination conditions

日本語

実装：に基づく制御フロー、結果処理、ループ終了条件

English

Multi-agent orchestration: Coordinator-subagent patterns, task decomposition, parallel subagent execution, iterative refinement loops

日本語

マルチオーケストレーション：・パターン、タスク分解、並列実行、反復改善ループ

English

Subagent context management: Explicit context passing, structured state persistence, crash recovery using manifests

日本語

コンテキスト管理：明示的コンテキスト受け渡し、構造化状態永続化、マニフェストを使用したクラッシュ復旧

English

Tool interface design: Writing effective tool descriptions, splitting vs consolidating tools, tool naming to reduce ambiguity

日本語

インターフェース設計：効果的な説明の記述、の分割vs統合、曖昧さを減らす命名

English

tool and resource design: Resources for content catalogs, tools for actions, description quality for adoption

日本語

とリソース設計：コンテンツカタログ用リソース、アクション用、採用のための説明品質

English

server configuration: Project vs user scope, environment variable expansion, multi-server simultaneous access

日本語

設定：プロジェクトvsユーザースコープ、環境変数展開、マルチサーバー同時アクセス

English

Error handling and propagation: Structured error responses, transient vs business vs permission errors, local recovery before escalation

日本語

エラーハンドリングと伝播：構造化エラーレスポンス、一時的vsビジネスvs権限エラー、前のローカル復旧

English

Escalation decision-making: Explicit criteria, honoring customer preferences, policy gap identification

日本語

判断：明示的な基準、顧客の希望の尊重、ポリシーギャップの特定

English

configuration: Hierarchy (user/project/directory), @import patterns, .claude/rules/ with glob patterns

日本語

設定：階層（ユーザー/プロジェクト/ディレクトリ）、@importパターン、globパターン付き.claude/rules/

English

Custom commands and skills: Project vs user scope, context: fork, allowed-tools, argument-hint frontmatter

日本語

カスタムコマンドとスキル：プロジェクトvsユーザースコープ、context: fork、allowed-tools、argument-hintフロントマター

English

Plan mode vs direct execution: Complexity assessment, architectural decisions, single-file changes

日本語

vs直接実行：複雑さの評価、アーキテクチャの意思決定、単一ファイル変更

English

Iterative refinement: Input/output examples, test-driven iteration, interview pattern, sequential vs parallel issue resolution

日本語

反復改良：入出力例、テスト駆動イテレーション、インタビューパターン、順次vs並列問題解決

English

Structured output via tool_use: Schema design, configuration, nullable fields to prevent hallucination

日本語

tool_useによる構造化出力：スキーマ設計、設定、幻覚防止のためのnullableフィールド

English

prompting: Ambiguous scenario targeting, format consistency, false positive reduction

日本語

プロンプティング：曖昧なシナリオのターゲティング、フォーマット一貫性、偽陽性削減

English

Batch processing: Message Batches appropriateness, latency tolerance assessment, failure handling by custom_id

日本語

：Message Batches の適切性、レイテンシー許容度評価、custom_idによる障害処理

English

Context window optimization: Trimming verbose tool outputs, structured fact extraction, position-aware input ordering

日本語

最適化：冗長な出力のトリミング、構造化事実抽出、位置を考慮した入力順序

English

Human review workflows: Confidence calibration, stratified sampling, accuracy segmentation by document type and field

日本語

人間レビューワークフロー：信頼度較正、層別サンプリング、ドキュメントタイプとフィールドごとの精度セグメンテーション

English

Information provenance: Claim-source mappings, temporal data handling, conflict annotation, coverage gap reporting

日本語

情報の出所：主張-出所マッピング、時系列データ処理、矛盾の注釈、カバレッジギャップ報告

🐕🎓 シバと博士の解説

シバ
シバ
「出題範囲内」のリスト、結構多いね…
博士
博士
多く見えるけど、Phase 1〜4 で全部カバーするから大丈夫。このリストは「ここに載っていないことは出ない」という安心材料でもあるんだ。
シバ
シバ
あ、逆に考えるとそうか！ ここに載ってないことは勉強しなくていいんだね。
博士
博士
そのとおり。効率的に勉強するために、このリストを時々見返すといいよ。
↑ 目次に戻る

17-3. Appendix: Out-of-Scope Topics / 付録：出題範囲外トピック

English

The following related topics will not appear on the exam:

日本語

以下の関連トピックは試験に出題されません：

English

Fine-tuning Claude models or training custom models

日本語

Claudeモデルのファインチューニングまたはカスタムモデルのトレーニング

English

Claude authentication, billing, or account management

日本語

Claude 認証、課金、またはアカウント管理

English

Detailed implementation of specific programming languages or frameworks (beyond what's needed for tool and schema configuration)

日本語

特定のプログラミング言語やフレームワークの詳細な実装（とスキーマ設定に必要な範囲を超えるもの）

English

Deploying or hosting servers (infrastructure, networking, container orchestration)

日本語

のまたはホスティング（インフラストラクチャ、ネットワーキング、コンテナオーケストレーション）

English

Claude's internal architecture, training process, or model weights

日本語

Claudeの内部アーキテクチャ、トレーニングプロセス、またはモデル重み

English

, RLHF, or safety training methodologies

日本語

、RLHF、または安全性トレーニング手法

English

Embedding models or vector database implementation details

日本語

埋め込みモデルまたはベクトルデータベースの実装詳細

English

Computer use (browser automation, desktop interaction)

日本語

コンピュータ使用（ブラウザ自動化、デスクトップ操作）

English

Vision/image analysis capabilities

日本語

ビジョン/画像分析機能

English

Streaming implementation or server-sent events

日本語

ストリーミング実装またはサーバー送信イベント

English

Rate limiting, quotas, or pricing calculations

日本語

レート制限、クォータ、または価格計算

English

OAuth, key rotation, or authentication protocol details

日本語

OAuth、キーローテーション、または認証プロトコルの詳細

English

Specific cloud provider configurations (AWS, GCP, Azure)

日本語

特定のクラウドプロバイダー設定（AWS、GCP、Azure）

English

Performance benchmarking or model comparison metrics

日本語

パフォーマンスベンチマークまたはモデル比較指標

English

Prompt caching implementation details (beyond knowing it exists)

日本語

キャッシングの実装詳細（その存在を知っている以上のもの）

English

Token counting algorithms or tokenization specifics

日本語

カウントアルゴリズムまたは化の詳細

🐕🎓 シバと博士の解説

シバ
シバ
「出題範囲外」も確認しておいた方がいい？
博士
博士
絶対に見ておいて。ここに載っているものが選択肢に出てきたら、それは不正解の可能性が高い。消去法の強力な武器になるよ。
シバ
シバ
例えば？
博士
博士
例えば「Fine-tuning」「埋め込みモデルやベクトルDBの実装詳細」「コンピュータ使用（ブラウザ自動化）」は範囲外。もし選択肢に「Fine-tuning で解決する」があったら、それは不正解だとわかるよね。
↑ 目次に戻る

18. Document Control / 文書管理

English

Version 1.0 — Formatting and layout updates (July 2026). Version 0.2 — Draft revision (June 2026). Version 0.1 — Initial draft (February 2026).

日本語

バージョン1.0 — 書式とレイアウトの更新（2026年7月）。バージョン0.2 — ドラフト改訂（2026年6月）。バージョン0.1 — 初版ドラフト（2026年2月）。
↑ 目次に戻る

試験ガイドを読み終えたら、学習の進め方を確認しましょう。

学習フローへPhase別学習へ