試験で問われる概念を、毎日運用している ~/.agent/ 組織の実物に対応付けて覚えるための対応表。「知らない概念を暗記する」のではなく「体で知っていることに正式名称を付ける」ためのページ。
試験は6本のシナリオ（業務設定の長文）から当日ランダムに4本出題され、各シナリオにぶら下がる形で設問が来る。Domain 1 が主戦場になるのは次の3本。
| シナリオ | 設定 | tomoさんの組織でいうと |
|---|---|---|
| S1: カスタマーサポート解決エージェント | 返品・請求トラブルを扱うAIサポート。MCPツール（get_customer, process_refund, escalate_to_human）を持ち、初回解決率80%が目標 | 「いつ人間にエスカレーションするか」「返金を承認なしで実行させない」＝ larc-approval-gate の世界 |
| S3: マルチエージェント調査システム | まとめ役1体が、Web検索係・文書分析係・統合係・レポート係に仕事を配る調査パイプライン | Lead/Worker オーケストレーションそのもの。deep-research ワークフローの構造 |
| S4: 開発者生産性ツール | Read/Write/Bash/Grep/Glob などの組み込みツール＋MCPで、コードベース探索や定型作業を自動化 | Claude Code の日常利用。Explore サブエージェントの使い分け |
stop_reason だけで判定する。stop_reason を確認 →「tool_use（ツールを使いたい）」なら要求されたツールを実行して結果を返す →「end_turn（話し終わった）」ならループ終了Claude Code のターンそのもの。ツールを呼んでは結果を読み、また次のツールを呼ぶ動きの裏側が全部このループ。rules/workflow-cycle.md の停止条件（試行N回・CRITICAL到達で止める）は、このAPIレベルのループの上に載せた業務レベルの安全網という関係。試験ではまずAPIレベル（stop_reason）で答える。
stop_reason で判定するrules/lead-worker-orchestration.md がこのパターンの実装。「Lead は判定・分解・委譲・統合のみ」「Worker間の直接通信は禁止（必ずLeadを介す）」は、試験用語でいうハブ&スポークと情報ルーティングの一元化。rules/audit-independence.md の盲検原則は「サブエージェントのコンテキスト独立性」を監査品質に応用したもの。
allowedTools に "Task" が含まれている必要があるCLAUDE.md の「怠惰な委譲の禁止（具体的なファイルパス・行番号・変更内容を含むプロンプトで委譲）」＝明示的コンテキスト渡しの運用ルール化。agents/*.md の frontmatter（description / model / tools）が AgentDefinition に相当。「独立タスクは1メッセージで並列に投げる」運用もそのまま試験の正解パターン。
get_customer で顧客IDが確認されるまで process_refund の呼び出しをブロックする前提条件ゲートこの対立軸は rules/extension-layer-decision.md の「影響（確率的・お願い）か保証（決定論的・強制）か」そのもの。実装例は hooks/larc-approval-gate.sh（本番書込みを承認なしでは通さない）と hooks/git-identity-guard.sh（identity不一致のcommitをブロック）。構造化ハンドオフは rules/handoff-memory.md の引き継ぎテンプレ（確証／未確証／残り）が同じ思想。
PreToolUse型ブロックの実物が hooks/larc-approval-gate.sh（Lark本番書込みを検問、exit 2でブロック）と hooks/git-identity-guard.sh。PostToolUse型は scripts/hooks/session-budget-breaker.js（トークン消費の監視）や telemetry-aggregator。「$500超の返金ブロック」は larc の広告予算変更ゲートと同型の問題として読める。
CLAUDE.md のバッチ処理パターンが同じ判断軸：「各タスクが独立→並列」「相互依存→ループ」「対象が動的・大規模→動的ワークフロー」。rules/audit-independence.md の直列監査（editorial-checker → geo-auditor）はプロンプトチェイニングの実例。rules/lead-worker-orchestration.md の Competing Hypotheses（仮説ごとに検証Workerを立てる）は動的分解の実例。
4択の選択肢はこの語彙で書かれてくる。「読んだ瞬間に意味が浮かぶ」状態にする。
Claudeの応答が「なぜそこで止まったか」を示すフラグ。tool_use＝ツールを使いたいから一時停止（→ループ継続）、end_turn＝言い終わった（→ループ終了）。エージェントループの制御はこれ一本で行う。
「送信 → stop_reason確認 → ツール実行 → 結果を履歴に追記 → 再送信」の反復。エージェントと呼ばれるものすべての心臓部。
自転車の車輪のように、中心（コーディネーター）とだけ各エージェントがつながる構造。子同士の直接通信を禁じることで、観測・エラー処理・情報の流れを一元管理できる。
サブエージェントを生成する公式の仕組み。コーディネーター側の allowedTools に "Task" が入っていないと子を呼べない。
サブエージェントの型定義。説明文（いつ使う子か）・システムプロンプト・ツール制限を含む。うちの agents/*.md の frontmatter に相当。
そのエージェントが使ってよいツールの許可リスト。最小権限の原則で絞る（監査係にWriteを渡さない、など）。
サブエージェントは親の会話履歴・記憶を自動継承しない、という仕様。渡したい情報はプロンプトに明示的に書く。試験全体で繰り返し問われる大前提。
ある時点までの分析を共有の土台にして、そこから複数の別アプローチを枝分かれで試すセッション管理。
ツール実行の後／前に割り込む検問所。Post＝結果の正規化・監視、Pre＝ポリシー違反のブロック。「プロンプトは確率的、hookは決定論的」という対比で覚える。
大きな仕事を固定の直列ステップに割り、前段の出力を次段の入力にする方式。手順が予測できる多段レビュー向き。
決定論的＝毎回必ず同じ結果になる（プログラム・hook）。確率的＝だいたい従うが失敗率がゼロでない（プロンプト指示）。「絶対」が要る場面で確率的手段を選ぶ選択肢は常に誤答。
人間や別エージェントへ引き継ぐときに、顧客ID・原因分析・推奨アクションなど決まった項目のセットで渡すこと。「会話ログを読めない相手」が前提。
暗記確認ではなく「自分の言葉で30秒説明できるか」の確認。チェック状態はこのブラウザに保存される。