最大配点ドメイン。この章は「土台レッスン(コードで心臓部を理解する)」→「タスクステートメント1.1〜1.7(試験が問う形で整理する)」→「演習」→「章末ミニクイズ」の順で、この1ページだけでDomain 1の学習が完結する。
コードが初めてなら、先に準備章で環境構築(30〜45分)を済ませること。
最初に知っておくべきことは1つだけ。Claude API は「会話の全履歴を毎回送りつけて、次の1通の返事をもらう」仕組みだということ。
Claude Codeが「ツールを呼んでは考え、また呼ぶ」あの動きは、すべてこの手紙の往復でできている。
まず道具なしの素の呼び出し。Pythonの公式SDK(準備章でインストール済みのもの)を使う。
# 最小のClaude API呼び出し
import anthropic
client = anthropic.Anthropic() # APIキーは環境変数 ANTHROPIC_API_KEY から読む
response = client.messages.create(
model="claude-sonnet-5", # 使うモデル
max_tokens=1024, # 返事の長さの上限
system="あなたは簡潔に答えるアシスタント。", # 役割設定(システムプロンプト)
messages=[
{"role": "user", "content": "日本で一番高い山は?"}
],
)
print(response.content) # 返事の中身(ブロックのリスト)
print(response.stop_reason) # ← この章の主役。なぜ止まったか
覚えるパラメータは4つだけ:model(誰に聞くか)、max_tokens(返事の上限)、system(役割)、messages(会話履歴)。messages は role(user か assistant)と content のペアが並んだリストで、会話が進むほどこのリストが長くなっていく。
返ってくる response には「返事の本文(content)」と一緒に、「なぜそこで書くのをやめたか」を示す stop_reason が入っている。ここが試験の最重要ポイント。
| stop_reason の値 | 意味 | プログラムがすべきこと |
|---|---|---|
"end_turn" | 言いたいことを言い終わった | ループ終了。返事をユーザーに見せる |
"tool_use" | 「このツールを使いたい」と要求して一時停止した | ループ継続。要求されたツールを実行し、結果を返す |
"max_tokens" | 上限に達して途中で切れた | 上限を増やす・続きを促す等の異常系処理 |
Claudeに「天気を調べる」などの能力を持たせるには、ツールのカタログ(名前・説明文・入力の型)を送信時に同封する。すると Claude は必要なときに「そのツールをこの引数で実行して」とお願いしてくる。実行するのはこちらのプログラム——Claudeは自分では何も実行できない。ここを誤解しないこと。
# ツールのカタログを定義して同封する
tools = [
{
"name": "get_weather",
"description": "指定した都市の現在の天気を返す。都市名は日本語でも英語でもよい。"
"天気・気温の質問に使う。ニュースや歴史の質問には使わない。", # ←説明文が命(第2章)
"input_schema": { # 入力の型(JSONスキーマ)
"type": "object",
"properties": {
"city": {"type": "string", "description": "都市名。例: 東京"}
},
"required": ["city"],
},
}
]
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
tools=tools, # ← カタログを同封
messages=[{"role": "user", "content": "大阪の天気は?"}],
)
# stop_reason が "tool_use" になり、content にツール要求ブロックが入る:
# ToolUseBlock(id="toolu_abc123", name="get_weather", input={"city": "大阪"})
ツール要求が来たら、こちらで実行して結果を会話履歴に追記して送り返す。このとき「どの要求への返答か」を tool_use_id で対応付ける。
# ツールを実行して、結果を「返信」する
weather = get_weather("大阪") # ←自分のプログラムで実行(API天気サービスを呼ぶ等)
messages.append({"role": "assistant", "content": response.content}) # Claudeの要求を履歴に残す
messages.append({
"role": "user",
"content": [{
"type": "tool_result",
"tool_use_id": "toolu_abc123", # どの要求への答えか
"content": "晴れ、28度",
}],
})
# → この messages でもう一度 create() を呼ぶと、Claudeは結果を踏まえた返事をする
レッスン2〜4の部品を while ループで繋ぐと、エージェントが完成する。これがこの章の到達点。
# エージェントループ完全版(これ単体で動く)
import anthropic
client = anthropic.Anthropic()
tools = [{ # レッスン4で作ったカタログ(再掲)
"name": "get_weather",
"description": "指定した都市の現在の天気を返す。天気・気温の質問に使う。",
"input_schema": {
"type": "object",
"properties": {"city": {"type": "string", "description": "都市名。例: 東京"}},
"required": ["city"],
},
}]
def run_tool(name, args):
"""要求されたツールを実際に実行する(ここは自分のコード)"""
print(f"[ツール実行] {name} {args}") # 何回・何が実行されたか見えるように
if name == "get_weather":
return f"{args['city']}は晴れ、28度" # 本物はAPIを呼ぶ
return f"不明なツール: {name}"
def agent(user_input):
messages = [{"role": "user", "content": user_input}]
while True: # ← エージェントループ
response = client.messages.create(
model="claude-sonnet-5",
max_tokens=1024,
tools=tools,
messages=messages,
)
# Claudeの応答(テキストやツール要求)を履歴に追記
messages.append({"role": "assistant", "content": response.content})
if response.stop_reason == "tool_use": # ★ ツールを使いたい → 続行
results = []
for block in response.content:
if block.type == "tool_use":
output = run_tool(block.name, block.input) # 実行するのは自分
results.append({
"type": "tool_result",
"tool_use_id": block.id, # 要求と結果を対応付け
"content": output,
})
messages.append({"role": "user", "content": results}) # 結果を履歴に追記
continue # → もう一周
if response.stop_reason == "end_turn": # ★ 話し終わった → 終了
return "".join(b.text for b in response.content if b.type == "text")
# ★ それ以外(max_tokens 等)で黙って回し続けない — 異常は異常として止める
raise RuntimeError(f"想定外の stop_reason: {response.stop_reason}")
print(agent("大阪と札幌の天気を比べて")) # 最後の返事を表示
読み解きのポイント:
stop_reason の分岐がすべて。tool_use なら実行して continue、end_turn なら return、それ以外は異常として明示的に止める(最後の raise)。想定外の値で黙ってループを回し続けない——レッスン3の表の「max_tokens=異常系処理」をコードで実装した形。試験の1.1はこの構造を言葉で問うているmessages に追記される(=会話履歴が育つ)。「結果を履歴に足すからこそ、モデルは新情報を踏まえて次を考えられる」——これも頻出の言い回しいま書いたループと、Claude Code の対応表:
| ループの部品 | Claude Code での姿 |
|---|---|
tools カタログ | Read / Write / Bash / Grep / Glob / Task / MCPツール群 |
run_tool() | Claude Code本体(ファイルを読む・コマンドを実行する側) |
stop_reason == "tool_use" の一周 | 画面で「ツールを呼んでは結果を読む」1回分 |
stop_reason == "end_turn" | ターンが終わって返事が表示される瞬間 |
messages が育っていく | コンテキスト消費が増えていく(→限界が来ると /compact) |
| ループの外側の安全装置 | hooks(実行前に割り込む検問。1.5で学ぶ) |
この対応が腹落ちすると、Domain 1の問題は「仕様の暗記」ではなく「いつも見ている光景の言語化」になる。ここから先は、その光景を試験が問う形(タスクステートメント)で1つずつ整理していく。
stop_reason だけで判定する。stop_reason を確認 →「tool_use(ツールを使いたい)」なら要求されたツールを実行して結果を返す →「end_turn(話し終わった)」ならループ終了Claude Code のターンそのもの。ツールを呼んでは結果を読み、また次のツールを呼ぶ動きの裏側が全部このループ。rules/workflow-cycle.md の停止条件(試行N回・CRITICAL到達で止める)は、このAPIレベルのループの上に載せた業務レベルの安全網という関係。試験ではまずAPIレベル(stop_reason)で答える。
stop_reason で判定する1体のエージェントで足りない仕事(広い調査、多段の分析)は、まとめ役が仕事を分けて子に配る。このとき構造の選択肢は実質1つで、すべての通信がまとめ役を通る「ハブ&スポーク」にする。子同士を直接つなぐと、誰が何をしたか観測できず、エラーがどこで起きたか追えず、情報の流れを制御できなくなる。会社組織で「報告は必ず上長経由」にするのと同じ理屈と覚えればよい。
まとめ役のもう1つの重要な仕事が分解の質。試験ではここを突く問題が出る:「AI×クリエイティブ産業の調査」をビジュアルアート3分野にだけ分解してしまい、音楽・文筆・映画が丸ごと欠けた——このとき悪いのは検索係や統合係ではなく、まとめ役の分解。統合結果に穴を見つけたら、まとめ役が追加のサブタスクを作って再委譲・再統合する反復までがワンセット。
試験が問うこと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 の引き継ぎテンプレ(確証/未確証/残り)が同じ思想。
実行前ブロック型の実物が hooks/larc-approval-gate.sh(Lark本番書込みを検問、exit 2でブロック)と hooks/git-identity-guard.sh。PostToolUse型は scripts/hooks/session-budget-breaker.js(トークン消費の監視)。「$500超の返金ブロック」は larc の広告予算変更ゲートと同型の問題として読める。
大きな仕事の割り方には2つの型がある。プロンプトチェイニングは工場のライン:手順が事前に分かっている仕事(例:20ファイルを「命名規約→型安全→テスト網羅」の3観点で順にレビュー)を、固定の段取りで流す。各段が1つのことに集中するので、1回の巨大プロンプトに全部詰め込んだときに起きる注意力の希釈(後半のファイルほど雑に見られる現象)を防げる。
動的分解は発掘調査:掘ってみるまで何が出るか分からない仕事(例:レガシーコードにテストを網羅的に足す)は、段取りを事前に固定できない。まず構造を把握→重要領域を特定→依存関係が見つかるたびに計画を更新、という「発見に応じてサブタスクを生む」進め方をする。選択基準は「先が読めるか」だけ。読める仕事に動的分解を使うのはコスト過剰(誤答)、読めない仕事に固定チェインを使うと計画が現実に負ける(誤答)。
試験が問うことCLAUDE.md のバッチ処理パターンが同じ判断軸:「各タスクが独立→並列」「相互依存→ループ」「対象が動的・大規模→動的ワークフロー」。rules/audit-independence.md の直列監査(editorial-checker → geo-auditor)はプロンプトチェイニングの実例。rules/lead-worker-orchestration.md の Competing Hypotheses(仮説ごとに検証Workerを立てる)は動的分解の実例。
数日がかりの仕事を続けるとき、道は2つ。再開(--resume)は前回の会話をそのまま続ける:履歴が全部残っているので効率的だが、履歴の中の「前回調べた事実」が今も正しいことが前提になる。対象のコードが大幅に変わっていたら、古い地図で運転することになる。そういう時は要約→新規セッション:前回の重要な発見だけを構造化したサマリーにして、まっさらなセッションに注入して始める。地図を描き直してから出発するイメージ。「前回のツール実行結果がまだ有効か」が唯一の判断基準。
試験が問うこと--resume <セッション名>:名前付きセッションの再開。数日がかりの調査を続きからfork_session:共通の分析結果を土台に、独立した枝を複数作って別アプローチを比較する(例:2つのリファクタ方針を同じ土台から試す)この「新規+構造化サマリー」がまさに rules/handoff-memory.md のセッション引き継ぎ(確証済み/未確証/残り の3分割で次セッションに渡す)。memory/project-*.md の「次回の続き」セクションは、試験用語でいう structured summary injection。fork は Agent tool の subagent_type: "fork" で日常的に使っている機能。
Anthropic 公式の無料学習サイト Claude Academy(2026-08-20 公開、/ja/ で日本語版)のうち、第1章(ドメイン1: エージェント設計)に対応するレッスン。土台レッスンの「手紙のやりとり → stop_reason → tool use → ループ」は Claude Platform 101 と API コースの序盤がそのまま対応する。使い方は「この章を読み終えてから、同じテーマを公式がどう説明しているかを確かめる」の一方向。先に公式を読む必要はない。レッスン本文の閲覧には無料アカウントでのサインインが必要。
この章で使うコース: Claude Platform 101 / Claude APIを使った構築 / サブエージェントの概要 / Claude Code 101 / 実践Claude Code
| この章の項目 | 対応する公式レッスン |
|---|---|
| 土台レッスン1〜6(API呼び出し・stop_reason・tool use・ループ) | Claude Platform 101 › The agent loop explained Claude Platform 101 › What is tool use? Claude APIを使った構築 › ツール使用の導入 Claude APIを使った構築 › メッセージブロックの処理 Claude APIを使った構築 › ツール結果の送信 Claude APIを使った構築 › 複数ターンの実装 |
| 1.1 エージェントループの設計 | Claude Platform 101 › The agent loop explained Claude APIを使った構築 › エージェントとツール Claude APIを使った構築 › ワークフロー対エージェント |
| 1.2 コーディネーター・サブエージェント型 | サブエージェントの概要 › サブエージェントとは サブエージェントの概要 › 効果的なサブエージェントの設計 Claude APIを使った構築 › ルーティングワークフロー |
| 1.3 サブエージェントの起動・コンテキスト受け渡し | サブエージェントの概要 › サブエージェントの作成 サブエージェントの概要 › サブエージェントを効果的に使用する Claude Code 101 › サブエージェント |
| 1.4 多段ワークフローの強制とハンドオフ | Claude APIを使った構築 › ワークフローの連鎖 Claude APIを使った構築 › エージェントとワークフロー |
| 1.5 hooks によるツールコール介入 | 実践Claude Code › Hooks Claude Code 101 › Hooks |
| 1.6 タスク分解の戦略 | Claude APIを使った構築 › 並列化ワークフロー Claude APIを使った構築 › ワークフロー対エージェント |
| 1.7 セッション管理(resume / fork) | 実践Claude Code › Steering long sessions resume / fork を正面から扱うレッスンは見当たらない。長いセッションの操縦法として最も近いのがこれ。試験用語(--resume / fork_session)はこの章の記述で押さえる。 |
対応付けはレッスン題名とコース説明文から行った(2026-08-25 時点)。レッスン本文までは精査していないので、読んでみて「この章の項目とずれている」と感じたら、その節は公式を優先せずこの章の記述で答える(試験ガイドのタスクステートメントに合わせて書いてあるため)。
この試験にコードを書く場面はない。必要なのは「コードを見て意味が分かる目」だけなので、ゼロから書けなくても、写経(見ながら書き写して動かす)で十分。Claudeに「c1演習やる」と言えば環境準備から伴走してもらえる。
| レベル | やり方 | 効果 |
|---|---|---|
| 🥉 ただ写す | 何も考えず書き写して実行する | ゼロよりはるかに良い。手と目がコードの「形」に慣れ、動いた結果を見ることで全体像がつかめる |
| 🥈 説明しながら写す(推奨) | 1行(または1ブロック)写すたびに「この行は何をしている行か」を声に出して言う。言えない行はコメントを読み直してから写す | 🥉との差が大きい。「教材を自分に説明しながら学ぶ」学習者は理解テストの成績が大幅に上がることが実証されている(自己説明効果・学習法ページ 原則3)。写経が「作業」から「学習」に変わる分かれ目がここ |
| 🥇 予測しながら写す | 実行する前に「この入力なら出力はこうなるはず」と予測してから動かし、答え合わせする | 予測が外れた瞬間が最高の学習イベント(原則5・望ましい困難)。余裕があれば |
しんどい日は🥉でもやる価値がある。ただし一言「この行は◯◯する行」と声に出すだけで🥈に変わるので、基本は🥈を推奨。説明できない行が残ったら、それが弱点の地図になる(言えなかった行をClaudeに聞く)。
stop_reason == "end_turn" のチェックを消す→ループが止まらなくなる→「だからこの分岐が要るのか」。tool_use_id を適当な値に変える→APIがエラーを返す→「対応付けは本当に照合されてるんだ」。説明を100回読むより、壊れた画面を1回見る方が記憶に残るget_weather に加えて get_weather_history(過去の天気)を定義し、説明文で境界を明確に書き分ける。「昨日の東京の天気は?」が正しく履歴側に行くかテストする(→第2章 2.1の体験){"errorCategory": "validation", "isRetryable": false, "message": "都市が見つからない"} の形でツール結果を返し、Claudeがユーザーに適切に説明することを確認する(→第2章 2.2の体験)Claudeの応答が「なぜそこで止まったか」を示すフラグ。tool_use=ツールを使いたいから一時停止(→ループ継続)、end_turn=言い終わった(→ループ終了)。エージェントループの制御はこれ一本で行う。
「送信 → stop_reason確認 → ツール実行 → 結果を履歴に追記 → 再送信」の反復。エージェントと呼ばれるものすべての心臓部。
車輪のように、中心(コーディネーター)とだけ各エージェントがつながる構造。子同士の直接通信を禁じることで、観測・エラー処理・情報の流れを一元管理できる。
Task=サブエージェントを生成する公式の仕組み。allowedTools=そのエージェントが使ってよいツールの許可リスト。コーディネーターの allowedTools に "Task" が入っていないと子を呼べない。
サブエージェントの型定義。説明文(いつ使う子か)・システムプロンプト・ツール制限を含む。うちの agents/*.md の frontmatter に相当。
サブエージェントは親の会話履歴・記憶を自動継承しない、という仕様。渡したい情報はプロンプトに明示的に書く。試験全体で繰り返し問われる大前提。
ツール実行の後/前に割り込む検問所。Post=結果の正規化・監視、実行前介入=ポリシー違反のブロック。「プロンプトは確率的、hookは決定論的」という対比で覚える。
大きな仕事を固定の直列ステップに割り、前段の出力を次段の入力にする方式。手順が予測できる多段レビュー向き。
resume=名前付きセッションの再開。fork=共通の土台から独立した複数の枝を分岐。「前回のツール結果が古いなら、要約を渡して新規セッション」が試験の推し判断。
人間や別エージェントへ引き継ぐときに、顧客ID・原因分析・推奨アクションなど決まった項目のセットで渡すこと。「会話ログを読めない相手」が前提。
本番形式の4択。この章で学んだことの思い出す練習(読み直しの3倍効く)。間違えても気にしない——間違えた瞬間が一番記憶に残るタイミング。総合模試(30問)は全章を終えてから。