第1章 / Domain 1 全7項目+土台レッスン / 配点27%(最大)

エージェント設計と
オーケストレーション(配点27%)

最大配点ドメイン。この章は「土台レッスン(コードで心臓部を理解する)」→「タスクステートメント1.1〜1.7(試験が問う形で整理する)」→「演習」→「章末ミニクイズ」の順で、この1ページだけでDomain 1の学習が完結する。

この章の流れ(レッスン約90分+演習2〜3時間)

コードが初めてなら、先に準備章で環境構築(30〜45分)を済ませること。

土台レッスン 1大前提:AIとの通信は「手紙のやりとり」

最初に知っておくべきことは1つだけ。Claude API は「会話の全履歴を毎回送りつけて、次の1通の返事をもらう」仕組みだということ。

  • Claudeの側には記憶がない(ステートレス)。前に何を話したかは、こちらが毎回全部書いて送る(だからコンテキスト管理=第5章が試験ドメインになるほど重要になる)
  • 1回の送信=「system(役割設定)+ messages(今までの会話全部)」、1回の受信=「assistantの返事1通」
  • この往復をプログラムのループで自動化したものがエージェント。つまりエージェントは魔法ではなく「手紙の往復の自動化」

Claude Codeが「ツールを呼んでは考え、また呼ぶ」あの動きは、すべてこの手紙の往復でできている。

土台レッスン 2最小のAPI呼び出しを読む

まず道具なしの素の呼び出し。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(会話履歴)。messagesrole(user か assistant)と content のペアが並んだリストで、会話が進むほどこのリストが長くなっていく

土台レッスン 3応答の解剖 — stop_reason という「止まった理由」

返ってくる response には「返事の本文(content)」と一緒に、「なぜそこで書くのをやめたか」を示す stop_reason が入っている。ここが試験の最重要ポイント。

stop_reason の値意味プログラムがすべきこと
"end_turn"言いたいことを言い終わったループ終了。返事をユーザーに見せる
"tool_use"「このツールを使いたい」と要求して一時停止したループ継続。要求されたツールを実行し、結果を返す
"max_tokens"上限に達して途中で切れた上限を増やす・続きを促す等の異常系処理
試験の急所
  • ループを続けるか止めるかはこの値だけで判定する。「返事のテキストに『完了しました』とあるか」で判定する選択肢は常に誤答(自然言語は信用できない)
  • 「最大10回まで」のような回数上限は暴走への保険であって、主要な停止判定に使う選択肢も誤答

土台レッスン 4ツールを持たせる — tool use の往復

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は結果を踏まえた返事をする

土台レッスン 5本題:エージェントループを組み立てる

レッスン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追記される(=会話履歴が育つ)。「結果を履歴に足すからこそ、モデルは新情報を踏まえて次を考えられる」——これも頻出の言い回し
  • 1回の応答に複数のツール要求が入ることがある(for文で回しているのはそのため)。「大阪と札幌」なら get_weather が2個同時に来る——これが並列ツール呼び出しで、1.3の「1応答に複数のTask呼び出し=並列サブエージェント」と同じ原理

土台レッスン 6これが Claude Code の正体

いま書いたループと、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つずつ整理していく。

Task Statement 1.1エージェントループの設計(自律実行のしくみ)

AIエージェントの正体は「依頼を送る → 返事の止まり方を見る → ツールを実行して結果を返す → 繰り返す」という単純なループ。続けるか止めるかは、モデルが返すフラグ stop_reason だけで判定する。
試験が問うこと
  • ループの一生:リクエスト送信 → stop_reason を確認 →「tool_use(ツールを使いたい)」なら要求されたツールを実行して結果を返す →「end_turn(話し終わった)」ならループ終了
  • ツールの実行結果は会話履歴に追記して次のループに渡す。これでモデルが新しい情報を踏まえて次の一手を考えられる
  • 「モデル駆動の判断(Claudeが文脈から次のツールを選ぶ)」と「事前に固定した分岐(if文の決定木)」の違い。前者がエージェントの本質
うちの組織の実物(任意読み物)

Claude Code のターンそのもの。ツールを呼んでは結果を読み、また次のツールを呼ぶ動きの裏側が全部このループ。rules/workflow-cycle.md の停止条件(試行N回・CRITICAL到達で止める)は、このAPIレベルのループの上に載せた業務レベルの安全網という関係。試験ではまずAPIレベル(stop_reason)で答える。

ひっかけ(誤答として出るパターン)
  • 「応答テキストに『完了しました』が含まれるかでループ終了を判定する」→ 自然言語のパースは不可。stop_reason で判定する
  • 「無限ループ防止のため反復回数の上限を主要な停止手段にする」→ 上限は保険であって主要判定ではない
  • 「アシスタントのテキスト出力があるか=完了」→ テキストとツール要求は同時に来ることがある

Task Statement 1.2コーディネーター・サブエージェント型(ハブ&スポーク)

複数のAIを協働させるときは、まとめ役(コーディネーター)1体がすべての通信を仲介する車輪のハブのような形にする。子エージェント同士を直接会話させない。

1体のエージェントで足りない仕事(広い調査、多段の分析)は、まとめ役が仕事を分けて子に配る。このとき構造の選択肢は実質1つで、すべての通信がまとめ役を通る「ハブ&スポーク」にする。子同士を直接つなぐと、誰が何をしたか観測できず、エラーがどこで起きたか追えず、情報の流れを制御できなくなる。会社組織で「報告は必ず上長経由」にするのと同じ理屈と覚えればよい。

まとめ役のもう1つの重要な仕事が分解の質。試験ではここを突く問題が出る:「AI×クリエイティブ産業の調査」をビジュアルアート3分野にだけ分解してしまい、音楽・文筆・映画が丸ごと欠けた——このとき悪いのは検索係や統合係ではなく、まとめ役の分解。統合結果に穴を見つけたら、まとめ役が追加のサブタスクを作って再委譲・再統合する反復までがワンセット。

試験が問うこと
  • ハブ&スポーク構造:エージェント間通信・エラー処理・情報の流れをすべてコーディネーターが管理する
  • サブエージェントは独立したコンテキストで動く。親(コーディネーター)の会話履歴を自動では引き継がない
  • コーディネーターの仕事=タスク分解・委譲・結果集約・「どの子を呼ぶか」の動的選択。毎回全員を呼ぶのではなく、依頼の複雑さに応じて選ぶ
  • 分解を細かくしすぎる/狭く切りすぎるリスク:広いテーマのカバー漏れ(上の例)。出力の穴はまず分解の質を疑う
  • 統合結果に穴があれば、コーディネーターが再委譲して再統合する反復ループ
うちの組織の実物(任意読み物)

rules/lead-worker-orchestration.md がこのパターンの実装。「Lead は判定・分解・委譲・統合のみ」「Worker間の直接通信は禁止(必ずLeadを介す)」は、試験用語でいうハブ&スポークと情報ルーティングの一元化。rules/audit-independence.md の盲検原則は「サブエージェントのコンテキスト独立性」を監査品質に応用したもの。

ひっかけ
  • 「効率のためサブエージェント同士に直接結果を共有させる」→ 観測不能・エラー処理不能になる。誤答の定番
  • 「すべての依頼を常に全サブエージェントのフルパイプラインに通す」→ 動的選択が正解
  • 「出力に穴がある=下流(統合係・検索係)の性能問題」→ まずコーディネーターの分解の質を疑う

Task Statement 1.3サブエージェントの起動・コンテキスト受け渡し

子エージェントは白紙の状態で生まれる。親が知っていることを使わせたければ、依頼文(プロンプト)に明示的に書いて渡すしかない。
試験が問うこと
  • サブエージェントを起動する仕組みは Task ツール。コーディネーターが子を呼ぶには、許可ツールリスト allowedTools"Task" が含まれている必要がある
  • 子は親の会話履歴もメモリも自動継承しない。必要な文脈はプロンプトに全部書く
  • AgentDefinition:各サブエージェントの型定義(説明文・システムプロンプト・使えるツールの制限)
  • 親から子へ渡すデータは、本文とメタ情報(出典URL・文書名・ページ番号)を構造化して分離する→出典の追跡が壊れない
  • 並列実行は「1回の応答の中で複数のTask呼び出しをまとめて出す」。ターンをまたいで1体ずつ呼ぶのではない(土台レッスン5の「1応答に複数ツール要求」と同じ原理)
  • 子への指示は手順書ではなくゴールと品質基準で書く→子が状況に適応できる
うちの組織の実物(任意読み物)

CLAUDE.md の「怠惰な委譲の禁止(具体的なファイルパス・行番号・変更内容を含むプロンプトで委譲)」=明示的コンテキスト渡しの運用ルール化。agents/*.md の frontmatter(description / model / tools)が AgentDefinition に相当。「独立タスクは1メッセージで並列に投げる」運用もそのまま試験の正解パターン。

ひっかけ
  • 「サブエージェントは親の会話を参照できるので要点だけ渡せばよい」→ 継承しない。全文脈を明示的に渡す
  • 「検索結果の要約だけを統合係に渡す」→ 出典メタデータが失われる。構造化して渡すのが正解
  • 「子エージェントへの指示は詳細な手順書ほどよい」→ ゴール+品質基準型が正解(適応性が失われるため)

Task Statement 1.4多段ワークフローの「強制」とハンドオフ

「絶対に守らせたい順序」はプロンプトのお願い文では守られない(非ゼロの失敗率がある)。プログラムで物理的にブロックする=決定論的な強制を使う。
試験が問うこと
  • プログラムによる強制(hooks・前提条件ゲート)とプロンプトによる誘導の使い分け。このドメインで最重要の対立軸
  • 本人確認が済むまで金融操作をさせない、のような「決定論的コンプライアンスが必要」な場面では、プロンプト指示だけでは足りない
  • 例:get_customer で顧客IDが確認されるまで process_refund の呼び出しをブロックする前提条件ゲート
  • 複数の要望が混ざった依頼は、個別の論点に分解して並列に調べ、統合した1つの解決策にまとめる
  • 途中で人間へエスカレーションするときの構造化ハンドオフ:顧客情報・原因分析・推奨アクションをセットで渡す(会話ログを読めない人でも引き継げる形)
うちの組織の実物(任意読み物)

この対立軸は rules/extension-layer-decision.md の「影響(確率的・お願い)か保証(決定論的・強制)か」そのもの。実装例は hooks/larc-approval-gate.sh(本番書込みを承認なしでは通さない)と hooks/git-identity-guard.sh(identity不一致のcommitをブロック)。構造化ハンドオフは rules/handoff-memory.md の引き継ぎテンプレ(確証/未確証/残り)が同じ思想。

ひっかけ
  • 「システムプロンプトに『必ず本人確認を先に行うこと』と書けば保証される」→ 確率的。保証にはならない
  • 「エスカレーション時は会話ログのURLを渡せば十分」→ 相手はログにアクセスできない前提。構造化サマリーを渡す

Task Statement 1.5hooks によるツールコール介入とデータ正規化

hooks は、ツールの呼び出しや結果に割り込む検問所。「結果をモデルに見せる前に整形する」「ルール違反の操作を実行前に止める」の2方向で使う。
試験が問うこと
  • PostToolUse 型:ツールの実行結果に割り込み、モデルが読む前に変換する。例:MCPツールごとにバラバラな日付形式(Unixタイムスタンプ / ISO 8601)や数値ステータスコードを統一フォーマットに正規化
  • 発信側への割り込み:ポリシー違反のツールコールを実行前にブロックする。例:500ドルを超える返金をブロックして人間エスカレーションのフローに迂回させる
  • 判断基準:ビジネスルールが「保証されたコンプライアンス」を要求するなら hooks、ベストエフォートでよいならプロンプト
うちの組織の実物(任意読み物)

実行前ブロック型の実物が hooks/larc-approval-gate.sh(Lark本番書込みを検問、exit 2でブロック)と hooks/git-identity-guard.sh。PostToolUse型は scripts/hooks/session-budget-breaker.js(トークン消費の監視)。「$500超の返金ブロック」は larc の広告予算変更ゲートと同型の問題として読める。

ひっかけ
  • 「データ形式の正規化はシステムプロンプトで『ISO形式に直して解釈せよ』と指示する」→ 確率的で漏れる。PostToolUse hookで機械的に変換
  • 「高額返金の禁止はツールの説明文(description)に書く」→ descriptionは選択の参考情報であって強制力がない

Task Statement 1.6タスク分解の戦略(固定パイプライン vs 動的分解)

手順が予測できる仕事は固定の直列パイプライン(プロンプトチェイニング)、掘ってみないと分からない仕事は途中の発見に応じてサブタスクを生む動的分解。どちらを選ぶかが問われる。

大きな仕事の割り方には2つの型がある。プロンプトチェイニングは工場のライン:手順が事前に分かっている仕事(例:20ファイルを「命名規約→型安全→テスト網羅」の3観点で順にレビュー)を、固定の段取りで流す。各段が1つのことに集中するので、1回の巨大プロンプトに全部詰め込んだときに起きる注意力の希釈(後半のファイルほど雑に見られる現象)を防げる。

動的分解は発掘調査:掘ってみるまで何が出るか分からない仕事(例:レガシーコードにテストを網羅的に足す)は、段取りを事前に固定できない。まず構造を把握→重要領域を特定→依存関係が見つかるたびに計画を更新、という「発見に応じてサブタスクを生む」進め方をする。選択基準は「先が読めるか」だけ。読める仕事に動的分解を使うのはコスト過剰(誤答)、読めない仕事に固定チェインを使うと計画が現実に負ける(誤答)。

試験が問うこと
  • プロンプトチェイニング:決まった多段レビューを順番に流す(例:ファイルを1つずつ分析→最後にファイル横断の統合パスを1回)。注意力の希釈(attention dilution)を防ぐ
  • 動的・適応的分解:オープンエンドな仕事は、構造把握→重要領域特定→依存関係の発見に応じて計画を更新
  • 選択基準:「予測可能な多面レビュー→チェイニング」「先が読めない探索→動的分解」
うちの組織の実物(任意読み物)

CLAUDE.md のバッチ処理パターンが同じ判断軸:「各タスクが独立→並列」「相互依存→ループ」「対象が動的・大規模→動的ワークフロー」。rules/audit-independence.md の直列監査(editorial-checker → geo-auditor)はプロンプトチェイニングの実例。rules/lead-worker-orchestration.md の Competing Hypotheses(仮説ごとに検証Workerを立てる)は動的分解の実例。

ひっかけ
  • 「柔軟性が高いので常に動的分解を選ぶ」→ 予測可能なレビューには過剰でコスト高。固定チェインが正解になる
  • 「1回の巨大プロンプトで全ファイルレビューを済ませる」→ 注意力が薄まり一貫性が崩れる。段階分割が正解

Task Statement 1.7セッション管理 — 再開と分岐(resume / fork)

長い調査は「名前を付けたセッション」として中断・再開できる。ただし古い調査結果が混ざったまま再開するより、要約を渡して新規セッションを始めた方が確実な場面がある。この判断が問われる。

数日がかりの仕事を続けるとき、道は2つ。再開(--resume)は前回の会話をそのまま続ける:履歴が全部残っているので効率的だが、履歴の中の「前回調べた事実」が今も正しいことが前提になる。対象のコードが大幅に変わっていたら、古い地図で運転することになる。そういう時は要約→新規セッション:前回の重要な発見だけを構造化したサマリーにして、まっさらなセッションに注入して始める。地図を描き直してから出発するイメージ。「前回のツール実行結果がまだ有効か」が唯一の判断基準

試験が問うこと
  • --resume <セッション名>:名前付きセッションの再開。数日がかりの調査を続きから
  • fork_session:共通の分析結果を土台に、独立した枝を複数作って別アプローチを比較する(例:2つのリファクタ方針を同じ土台から試す)
  • 再開 vs 新規+要約の判断:前回のコンテキストがまだ概ね有効なら再開、前回のツール実行結果が古くなっている(コードが変わった等)なら「構造化した要約を注入して新規セッション」の方が信頼できる
  • 再開時は「前回から変わったファイル」を明示的に伝えて、狙った再分析をさせる(全部をゼロから探索し直させない)
うちの組織の実物(任意読み物)

この「新規+構造化サマリー」がまさに rules/handoff-memory.md のセッション引き継ぎ(確証済み/未確証/残り の3分割で次セッションに渡す)。memory/project-*.md の「次回の続き」セクションは、試験用語でいう structured summary injection。fork は Agent tool の subagent_type: "fork" で日常的に使っている機能。

ひっかけ
  • 「常にセッション再開が効率的」→ ツール結果が陳腐化していたら、古い前提で推論する。要約→新規が正解になる場面がある
  • 「再開すれば自動で変更を検知してくれる」→ しない。変わったファイルは明示的に伝える

公式コースで補強Claude Academy の対応レッスン

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 時点)。レッスン本文までは精査していないので、読んでみて「この章の項目とずれている」と感じたら、その節は公式を優先せずこの章の記述で答える(試験ガイドのタスクステートメントに合わせて書いてあるため)。

演習手を動かして確かめる(公式演習1の日本語版・2〜3時間)

この試験にコードを書く場面はない。必要なのは「コードを見て意味が分かる目」だけなので、ゼロから書けなくても、写経(見ながら書き写して動かす)で十分。Claudeに「c1演習やる」と言えば環境準備から伴走してもらえる。

先に読む:写経の作法

レベルやり方効果
🥉 ただ写す何も考えず書き写して実行するゼロよりはるかに良い。手と目がコードの「形」に慣れ、動いた結果を見ることで全体像がつかめる
🥈 説明しながら写す(推奨)1行(または1ブロック)写すたびに「この行は何をしている行か」を声に出して言う。言えない行はコメントを読み直してから写す🥉との差が大きい。「教材を自分に説明しながら学ぶ」学習者は理解テストの成績が大幅に上がることが実証されている(自己説明効果・学習法ページ 原則3)。写経が「作業」から「学習」に変わる分かれ目がここ
🥇 予測しながら写す実行する前に「この入力なら出力はこうなるはず」と予測してから動かし、答え合わせする予測が外れた瞬間が最高の学習イベント(原則5・望ましい困難)。余裕があれば

しんどい日は🥉でもやる価値がある。ただし一言「この行は◯◯する行」と声に出すだけで🥈に変わるので、基本は🥈を推奨。説明できない行が残ったら、それが弱点の地図になる(言えなかった行をClaudeに聞く)。

作法が腹落ちしないときの3つの技

  1. 壊し学習(一番おすすめ):写経が終わったコードを、わざと1箇所壊して実行する。stop_reason == "end_turn" のチェックを消す→ループが止まらなくなる→「だからこの分岐が要るのか」。tool_use_id を適当な値に変える→APIがエラーを返す→「対応付けは本当に照合されてるんだ」。説明を100回読むより、壊れた画面を1回見る方が記憶に残る
  2. その場で「なぜ」を聞く:「この行なぜ必要?」「これ消したらどうなる?」を疑問が湧いたその場でClaudeに聞く。溜めない
  3. 悪い例と並べて見る(対比学習):「動くけど作法違反の版を書いて」とClaudeに頼み、正解版と見比べる。各項目の「ひっかけ」欄が誤答パターンを併記しているのも、この対比の原理
  1. 最小ループの写経:土台レッスン5の「完全版」ループを動かす。「大阪と札幌の天気を比べて」で2回のツール実行が起きることをprintで確認する
  2. 紛らわしいツールを足すget_weather に加えて get_weather_history(過去の天気)を定義し、説明文で境界を明確に書き分ける。「昨日の東京の天気は?」が正しく履歴側に行くかテストする(→第2章 2.1の体験)
  3. 構造化エラーを返す:存在しない都市を聞かれたら {"errorCategory": "validation", "isRetryable": false, "message": "都市が見つからない"} の形でツール結果を返し、Claudeがユーザーに適切に説明することを確認する(→第2章 2.2の体験)
  4. 業務ルールの割り込み:run_tool の手前に「1ターンにツール実行は3回まで。超えたら実行せず『上限に達した』を返す」というゲート関数を挟む(→1.5 hookの原理の体験)
  5. 複数論点の依頼:「大阪の天気と、京都の天気と、傘が要るかの判断」を1回で投げ、分解→並列実行→統合の流れをログで観察する

用語ミニ辞書(第1章)

stop_reason (ストップリーズン)

Claudeの応答が「なぜそこで止まったか」を示すフラグ。tool_use=ツールを使いたいから一時停止(→ループ継続)、end_turn=言い終わった(→ループ終了)。エージェントループの制御はこれ一本で行う。

エージェントループ / agentic loop

「送信 → stop_reason確認 → ツール実行 → 結果を履歴に追記 → 再送信」の反復。エージェントと呼ばれるものすべての心臓部。

ハブ&スポーク / hub-and-spoke

車輪のように、中心(コーディネーター)とだけ各エージェントがつながる構造。子同士の直接通信を禁じることで、観測・エラー処理・情報の流れを一元管理できる。

Task ツール / allowedTools

Task=サブエージェントを生成する公式の仕組み。allowedTools=そのエージェントが使ってよいツールの許可リスト。コーディネーターの allowedTools に "Task" が入っていないと子を呼べない。

AgentDefinition

サブエージェントの型定義。説明文(いつ使う子か)・システムプロンプト・ツール制限を含む。うちの agents/*.md の frontmatter に相当。

コンテキスト分離 / isolated context

サブエージェントは親の会話履歴・記憶を自動継承しない、という仕様。渡したい情報はプロンプトに明示的に書く。試験全体で繰り返し問われる大前提。

PostToolUse / ツールコール介入 hook

ツール実行の後/前に割り込む検問所。Post=結果の正規化・監視、実行前介入=ポリシー違反のブロック。「プロンプトは確率的、hookは決定論的」という対比で覚える。

プロンプトチェイニング / prompt chaining

大きな仕事を固定の直列ステップに割り、前段の出力を次段の入力にする方式。手順が予測できる多段レビュー向き。

--resume / fork_session

resume=名前付きセッションの再開。fork=共通の土台から独立した複数の枝を分岐。「前回のツール結果が古いなら、要約を渡して新規セッション」が試験の推し判断。

構造化ハンドオフ / structured handoff

人間や別エージェントへ引き継ぐときに、顧客ID・原因分析・推奨アクションなど決まった項目のセットで渡すこと。「会話ログを読めない相手」が前提。

章末ミニクイズ(5問)

本番形式の4択。この章で学んだことの思い出す練習(読み直しの3倍効く)。間違えても気にしない——間違えた瞬間が一番記憶に残るタイミング。総合模試(30問)は全章を終えてから。

MQ1 — 1.1 エージェントループ
経費精算エージェントのループが時々止まらなくなる。調べると「応答テキストに『処理完了』の文字があればループを抜ける」実装だった。正しい修正は?
ループ制御は stop_reason 一本。自然言語のパース(A)は表現が変わるたびに壊れる。回数上限やタイムアウト(C/D)は暴走への保険であって主要判定ではない。→ 1.1
MQ2 — 1.2 ハブ&スポーク
「再生医療の市場調査」をコーディネーターが「国内クリニック動向」1本にだけ分解し、統合レポートに海外動向・規制・保険の話が全く無い。最初に見直すべきは?
出力の穴はまず分解の質を疑う。広いテーマを狭いサブタスク1本にしか割っていないのが根本原因で、下流(A/B)やモデル性能(D)をいじっても欠けたテーマは戻らない。→ 1.2
MQ3 — 1.4 強制とハンドオフ
法律相談エージェントで「契約書レビューの前に必ず利益相反チェックを完了させる」ことを保証したい。最も確実な方法は?
「保証」が要件ならプログラム的強制。プロンプト・few-shot・説明文(A/B/C)はすべて確率的で、非ゼロの失敗率が残る。→ 1.4 / 正解の哲学①
MQ4 — 1.6 タスク分解
「30本のブログ記事を『薬機法・誤字・リンク切れ』の3観点で毎月チェックする」定型業務を自動化する。最適な構造は?
手順が毎回同じ=予測可能な多面レビューはチェイニング。動的分解(A)は過剰、一括(C)は注意力の希釈で後半が雑になる、多数決(D)は間欠的にしか出ない本物の指摘を潰す。→ 1.6
MQ5 — 1.7 セッション管理
1週間前に中断したリファクタ調査を再開したい。この間にチームが対象モジュールを大幅改修している。最も信頼できる進め方は?
前回のツール実行結果(コードの中身)が陳腐化しているので、resumeは古い地図で運転することになる。構造化サマリー→新規が正解。fork(B)は複数アプローチ比較用、ログ全文(D)は陳腐化した生データの持ち込み。→ 1.7

仕上げチェックリスト(30秒で説明できたらチェック)

← ホーム 第2章へ(D3 Claude Codeの設定)→