Phase 1: Agentic Architecture & Orchestration | Claude Architect 試験対策

Claude API の基本

エージェントを理解するには、まずその土台となる Messages API の仕組みを押さえる必要があります。全てのエージェントはこの API の上に構築されています。

Messages API の基本構造

Claude との全てのやり取りは Messages API を通じて行われます。リクエストを送ると、Claude がレスポンスを返す。このシンプルな往復が全ての基盤です。

import anthropic

client = anthropic.Anthropic()  # 環境変数 ANTHROPIC_API_KEY を自動読み込み

message = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    messages=[
        {"role": "user", "content": "こんにちは、Claude!"}
    ]
)

print(message.content[0].text)

        

用語解説

Messages API: Claude とやり取りするための主要な API。ユーザーのメッセージを送り、Claude の応答を受け取る窓口です。
model: 使用する Claude モデルを指定します。Opus (最高性能)、Sonnet (バランス型)、Haiku (高速・低コスト) から選択します。
max_tokens: Claude が返すレスポンスの最大トークン数。トークンはテキストの最小単位で、日本語1文字は概ね1~2トークンです。

マルチターン会話

Claude は単発の質問に答えるだけでなく、複数回の会話を継続できます。そのためには過去のやり取り全体を messages 配列として毎回送り直します。Claude 自体は「記憶」を持たないので、会話の文脈は全てこの配列に含める必要があります。

messages = [
    {"role": "user", "content": "日本の首都は？"},
    {"role": "assistant", "content": "東京です。"},
    {"role": "user", "content": "その人口は？"},  # 「その」が「東京」を指すと理解できる
]

        

Claude は role が "user" と "assistant" を交互に繰り返すことで、文脈を維持した対話を実現します。これがエージェントの会話履歴管理の基盤になります。

system prompt (システムプロンプト)

system prompt は Claude の振る舞いを最初に設定する特別な指示文です。ユーザーとの会話の外側に位置し、Claude の「人格」や「ルール」を定義します。エージェントでは、このsystem prompt が「このエージェントは何をするものか」を定義する重要な要素になります。

message = client.messages.create(
    model="claude-sonnet-4-5-20250514",
    max_tokens=1024,
    system="あなたはカスタマーサポート担当です。丁寧な敬語で応対し、"
           "解決できない問題は人間のオペレーターにエスカレーションしてください。",
    messages=[
        {"role": "user", "content": "注文した商品が届きません"}
    ]
)

        

エージェントループ

Task Statement 1.1: Design and implement agentic loops for autonomous task execution

エージェントの心臓部はループ構造です。Claude にリクエストを送り、レスポンスを確認し、ツール呼び出しがあれば実行して結果を返す。この繰り返しがエージェントの「自律的な行動」を実現します。

エージェントループの全体像

1. Claude にメッセージを送信

2. レスポンスを受け取る

3. stop_reason を確認

"tool_use"

"end_turn"

4a. ツールを実行し
結果を messages に追加
↑ ステップ1に戻る

4b. 最終応答を
ユーザーに表示
■ ループ終了

試験で問われるポイント

このループの制御は stop_reason という値だけで判断します。"tool_use" ならツール実行が必要なのでループを継続。"end_turn" なら Claude がタスク完了と判断したのでループを終了。この2つの分岐がエージェントの全てです。

stop_reason とは何か

Claude がレスポンスを返すとき、必ず stop_reason というフィールドが付きます。これは Claude が「なぜ応答を止めたか」を示す信号です。

値	意味	エージェントでの扱い
`"tool_use"`	Claude がツールを使いたい	ツールを実行 → 結果を返す → ループ継続
`"end_turn"`	Claude が応答を完了した	最終テキストを取得 → ループ終了
`"max_tokens"`	トークン上限に達した	応答が途中で切れた状態。必要に応じて継続リクエスト

エージェントループの実装

以下は最小限のエージェントループです。Claude にメッセージを送り、stop_reason を確認し、ツール呼び出しがあれば実行して結果を返し、完了するまで繰り返します。

import anthropic, json

client = anthropic.Anthropic()

# 利用可能なツールの定義
tools = [{
    "name": "get_weather",
    "description": "指定された都市の天気を取得します",
    "input_schema": {
        "type": "object",
        "properties": {
            "city": {"type": "string", "description": "都市名"}
        },
        "required": ["city"]
    }
}]

# ツールを実際に実行する関数
def execute_tool(name, input_data):
    if name == "get_weather":
        return {"weather": "晴れ", "temp": "22°C"}

# エージェントループ本体
messages = [{"role": "user", "content": "東京の天気を教えて"}]

while True:
    # ステップ1: Claude にリクエスト
    response = client.messages.create(
        model="claude-sonnet-4-5-20250514",
        max_tokens=4096,
        tools=tools,
        messages=messages
    )

    # ステップ2: stop_reason で分岐
    if response.stop_reason == "end_turn":
        # Claude がタスク完了と判断 → ループ終了
        final_text = response.content[0].text
        print(final_text)
        break

    if response.stop_reason == "tool_use":
        # Claude がツールを使いたい → 実行して結果を返す
        # まず Claude の応答全体を会話履歴に追加
        messages.append({"role": "assistant", "content": response.content})

        # 各ツール呼び出しを処理
        tool_results = []
        for block in response.content:
            if block.type == "tool_use":
                result = execute_tool(block.name, block.input)
                tool_results.append({
                    "type": "tool_result",
                    "tool_use_id": block.id,
                    "content": json.dumps(result)
                })

        # ツール結果を会話履歴に追加 → ステップ1に戻る
        messages.append({"role": "user", "content": tool_results})

        

やってはいけないこと (アンチパターン)

✗ Claude のテキスト応答を解析して「完了」を判定する (例: "done" という単語を探す)
✗ 任意のイテレーション回数上限を設定してループを終了する
✗ assistant のテキスト内容を見て「これが最終回答だ」と判断する

ループの制御は必ず stop_reason だけで行います。Claude がツールを呼びたいか、応答を完了したかを正確に伝えてくれる唯一の信号です。

会話履歴の構造

エージェントループでは、ツール呼び出しとその結果が会話履歴にどんどん追加されていきます。Claude は次のリクエストでこの全履歴を受け取るため、前のツール結果を踏まえた判断ができます。

user

東京の天気を教えて

assistant

[text] 天気を調べますね。
[tool_use] get_weather(city="東京")

user

[tool_result] {"weather": "晴れ", "temp": "22°C"}

assistant

[text] 東京は現在晴れで、気温は22°Cです。

ツール結果は role: "user" として追加されます。これは API の仕様であり、実際のユーザー入力ではありません。Claude はこの結果を読んで次のアクションを決定します。

ツール利用 (Tool Use)

コース: Tool Use with Claude / GitHub Tool Use Course

ツール利用は、Claude が外部の関数や API を呼び出せる仕組みです。天気の取得、データベース検索、メール送信など、Claude 単体ではできない操作を実行可能にします。エージェントの「手足」にあたる機能です。

ツールスキーマの定義

Claude にツールを使わせるには、まず「どんなツールがあるか」を教える必要があります。ツール定義には3つの要素があります。

name

ツールの識別名。Claude がこの名前でツールを呼び出します。

description

ツールの説明文。Claude がどのツールを使うか判断する材料になります。ここの記述品質がツール選択の精度を左右します。

input_schema

JSON Schema 形式でツールの入力パラメータを定義します。型、説明、必須項目を指定します。

tools = [{
    "name": "lookup_order",
    "description": "注文IDから注文情報を検索します。"
                    "注文状況、配送先、商品一覧を返します。",
    "input_schema": {
        "type": "object",
        "properties": {
            "order_id": {
                "type": "string",
                "description": "注文ID (例: ORD-12345)"
            }
        },
        "required": ["order_id"]
    }
}]

        

description はツール選択の精度に直結します。Claude は description を読んでどのツールを使うか判断するため、そのツールが何をするか、どんな場面で使うかを具体的に記述することが重要です。

tool_choice: ツール利用の制御

Claude にどの程度ツールを使わせるかを制御するパラメータです。

"auto"

自動判断 (デフォルト)

Claude が状況に応じてツールを使うか使わないかを自分で決めます。

"any"

必ずツールを使う

Claude は必ず何らかのツールを呼び出します。ツール経由で構造化データを取得したい場合に便利です。

{"type": "tool", "name": "..."}

特定のツールを強制

指定した名前のツールを必ず呼び出させます。JSON 構造化出力の強制にも使えるテクニックです。

構造化出力のテクニック

tool_choice でツールを強制し、ツールの input_schema で出力フォーマットを定義すると、Claude に常に同じ JSON 構造で出力させることができます。ツールを「実行」する必要はなく、Claude が生成した input パラメータをそのまま構造化データとして使います。

メッセージブロックの構造

Claude のレスポンスは1つの塊ではなく、複数のブロック (content blocks) で構成されます。テキスト応答とツール呼び出しが1つのレスポンスに混在することもあります。

# Claude のレスポンス例
response.content = [
    TextBlock(type="text", text="注文情報を確認しますね。"),
    ToolUseBlock(
        type="tool_use",
        id="toolu_abc123",          # 一意のID
        name="lookup_order",          # ツール名
        input={"order_id": "ORD-789"}  # 引数
    )
]
response.stop_reason = "tool_use"

        

ツール結果を返す際は、tool_use_id でどのツール呼び出しに対する結果かを紐付けます。これにより、複数のツールを同時に呼んだ場合でもClaude は正しく結果を理解できます。

複数ツールの並行利用

Claude は1回のレスポンスで複数のツールを同時に呼び出すことがあります。例えば「東京と大阪の天気を比較して」と頼むと、2つの get_weather 呼び出しが1つのレスポンスに含まれる場合があります。

この場合、全てのツール呼び出しの結果を1つの tool_result メッセージにまとめて返します。各結果は tool_use_id で紐付けられているので、Claude はどの結果がどのツール呼び出しに対応するか区別できます。

マルチエージェントシステム

Task Statement 1.2: Orchestrate multi-agent systems with coordinator-subagent patterns

複雑なタスクを1つのエージェントで処理しようとすると、コンテキストが肥大化し、精度が下がります。そこでタスクを分割し、専門化したサブエージェントに委任する「コーディネーター・サブエージェント」パターンが使われます。

Hub-and-Spoke アーキテクチャ

マルチエージェントの基本形は「車輪のハブとスポーク」のような構造です。中央にコーディネーター (ハブ) がいて、各サブエージェント (スポーク) に指示を出し、結果を集約します。

Coordinator
Agent

Web
検索

文書
分析

データ
取得

レポート
生成

コーディネーターの役割

- タスク分解: ユーザーのリクエストを分析し、サブタスクに分割
- 委任先決定: クエリの内容に応じてどのサブエージェントを呼ぶか判断
- 結果集約: 各サブエージェントの出力をまとめて最終回答を生成
- エラー処理: サブエージェントのエラーを検知し、リトライや代替手段を選択

サブエージェントの特性

- 独立したコンテキストで動作する (コーディネーターの会話履歴は自動で引き継がれない)
- 特定のタスクに特化した system prompt とツールセットを持つ
- コーディネーター経由でのみ通信する (サブエージェント同士は直接やり取りしない)

動的ルーティングと選択的呼び出し

良いコーディネーターは、全てのサブエージェントを毎回呼び出すのではなく、クエリの内容を分析して必要なサブエージェントだけを選択的に呼び出します。

悪い例: 固定パイプライン

全てのクエリを検索 → 分析 → 要約 → レポートの順で処理。単純な質問でも全工程を通過するため無駄が多い。

良い例: 動的ルーティング

クエリ内容を分析し、必要なサブエージェントのみ呼び出す。「去年の売上は？」→ データ取得だけ。「競合比較レポートを作って」→ 検索 + 分析 + レポート。

タスク分解が狭すぎるリスク

コーディネーターがタスクを細かく分解しすぎると、各サブエージェントが断片的な情報しか扱えず、全体像を見失います。特にリサーチ系のタスクでは、トピックの関連性や文脈の重なりを考慮した適切な粒度が必要です。

例: 「AIの医療応用について調べて」

狭すぎる分解: エージェントA「画像診断」、エージェントB「創薬」、エージェントC「電子カルテ」→ 分野横断的な規制やプライバシーの問題が抜け落ちる

適切な分解: エージェントA「技術応用事例」、エージェントB「規制と倫理的課題」→ 広いカバレッジを確保しつつ、重要な横断テーマを漏らさない

サブエージェントの設定と起動

Task Statement 1.3: Configure subagent invocation, context passing, and spawning

Task ツールによるサブエージェント起動

Agent SDK では Task ツールを使ってサブエージェントを起動します。これは「別のClaude を立ち上げて仕事を任せる」イメージです。

重要な仕組み

1. サブエージェントはコーディネーターの会話履歴を自動的に引き継ぎません
2. 必要な情報はプロンプトに明示的に含める必要があります
3. サブエージェント同士はメモリを共有しません

allowedTools に "Task" を含める

コーディネーターがサブエージェントを起動するには、コーディネーターの allowedTools に "Task" を含める必要があります。これがないとサブエージェントを生成できません。

AgentDefinition の構成要素

AgentDefinition は各エージェント (コーディネーターもサブエージェントも) の設定を定義するオブジェクトです。

description

エージェントの目的や役割の説明。コーディネーターがどのサブエージェントに任せるか判断する際に参照されます。

system prompt

エージェントの振る舞いを定義する指示文。「あなたはデータ分析の専門家です」のように、特化した役割を与えます。

allowedTools

そのエージェントが使えるツールの一覧。サブエージェントには最小限のツールだけ与えることでセキュリティと予測可能性を確保します。

コンテキストの受け渡し方

サブエージェントに仕事を任せるとき、必要な情報をどう渡すかが設計の肝です。

ベストプラクティス: 構造化データで渡す

先行エージェントの出力をそのままテキストで渡すのではなく、メタデータ (情報源URL、ページ番号、信頼度) を含む構造化形式で渡します。

# 良い例: 構造化されたコンテキスト
prompt = f"""以下の検索結果を分析してレポートを作成してください。

## 検索結果
{json.dumps(search_results, ensure_ascii=False)}

## 各結果のメタデータ
- ソース: {sources}
- 取得日時: {timestamp}
- 信頼度: {confidence_scores}
"""

            

避けるべきパターン

「さっきの検索結果を使って」のような曖昧な参照。サブエージェントはコーディネーターの会話履歴を持っていないので、「さっきの」が何を指すかわかりません。

並行起動 (Parallel Spawning)

複数のサブエージェントを同時に起動するには、1回のコーディネーターレスポンスで複数の Task ツール呼び出しを発行します。別々のターンで1つずつ呼び出すと直列実行になり、時間がかかります。

並行 (推奨)

1レスポンスで Task A, Task B, Task C を同時に発行 → 3つのサブエージェントが並行実行

直列 (非効率)

ターン1で Task A → 結果を受けてターン2で Task B → ... 順番に待つので遅い

fork_session: 分岐探索

fork_session は、現在の分析ベースラインから独立したブランチを作成する機能です。Git のブランチに似ています。共通の前提を共有しつつ、異なるアプローチを並行して探索したい場合に使います。

例えば、データ分析の前処理まで完了した状態から、「手法A: 回帰分析」と「手法B: クラスタリング」を別々のセッションで試し、結果を比較する使い方ができます。

ワークフローパターン

コース: Agents and Workflows / Task Statement 1.4, 1.6

エージェントには「あらかじめ決められた手順で進むワークフロー」と「状況に応じて自分で判断するエージェント」の2種類があります。コースではこの違いと、代表的なワークフローパターンを扱います。

ワークフロー vs エージェント

ワークフロー (Workflow)

事前に定義された固定のステップを順番に実行。開発者がコードで制御フローを決める。

- 結果が予測しやすい
- デバッグしやすい
- 定型業務に向いている

エージェント (Agent)

Claude が状況に応じて次のアクションを自律的に判断。モデル駆動の意思決定。

- 柔軟で複雑なタスクに対応
- 動作が非決定的になりうる
- オープンエンドな問題に向いている

使い分けの判断基準

手順が明確で毎回同じ流れなら「ワークフロー」。状況によって取るべきアクションが変わるなら「エージェント」。実際のシステムではこの2つを組み合わせることが多く、ワークフローの一部のステップでエージェント的な判断を入れる設計もあります。

1. 並列化 (Parallelization)

同じ入力データを複数の処理に同時に渡すパターン。各処理は独立しているので並行実行できます。

入力

→

処理A: 感情分析

処理B: カテゴリ分類

処理C: 要約生成

→

結果を統合

用途例: レビューテキストの分析。感情分析、カテゴリ分類、要約を同時に実行して結果を結合。

2. チェーン (Chaining)

前のステップの出力が次のステップの入力になる直列処理。各ステップの結果を検証してから次に進めるので品質管理しやすい。

入力

→

Step 1: 文書解析

→

Step 2: 情報抽出

→

Step 3: 検証

→

出力

用途例: コードレビュー。ファイルごとに個別分析 → クロスファイル統合パス → 最終レポート。

3. ルーティング (Routing)

入力の内容を分析して、適切な処理パスに振り分けるパターン。カスタマーサポートでよく使われます。

入力を分類

→

技術的質問 → 技術サポート

請求関連 → 経理対応

苦情 → エスカレーション

用途例: 試験シナリオ1のカスタマーサポートAgent。返品、請求紛争、アカウント問題を適切な処理パスに振り分ける。

Hooks と強制パターン

Task Statement 1.5: Apply Agent SDK hooks for tool call interception and data normalization

エージェントにビジネスルールを守らせる方法は2つあります。プロンプトで「これをやるな」と指示する方法と、Hooks でプログラム的にブロックする方法です。どちらを使うかの判断が試験で問われます。

確定的保証 vs 確率的コンプライアンス

Hooks (確定的)

コードで強制するため、100% 守られる。ビジネスルールの違反を完全にブロックできる。

使う場面:

- 金融操作前の本人確認の強制
- 返金額の上限チェック (例: $500 超はブロック)
- データフォーマットの正規化

プロンプト指示 (確率的)

Claude に「こうしてください」と頼むだけ。ほぼ従うが、稀に無視される可能性がある。

使う場面:

- 応答のトーンや敬語の使い方
- 回答フォーマットの指定
- ワークフローの順序のガイド

試験での判断基準

「守れなかったときの影響が大きい」 → Hooks で確定的に保証。「守れなくても致命的でない」 → プロンプトで十分。例えば「本人確認前に返金処理を許す」は金銭的損失に直結するので Hooks 必須。「回答が少しカジュアルになる」は Hooks 不要。

PostToolUse フック

PostToolUse は、ツールの実行結果が Claude に渡される前に割り込むフックです。結果を加工したり、ブロックしたりできます。

用途1: データフォーマットの正規化

異なるMCPツールが返す日時フォーマットがバラバラだと Claude が混乱します。PostToolUse で統一します。

# PostToolUse フックの例: タイムスタンプ正規化
def normalize_timestamps(tool_result):
    # Unix timestamp → ISO 8601 に変換
    if "timestamp" in tool_result:
        ts = tool_result["timestamp"]
        if isinstance(ts, (int, float)):
            tool_result["timestamp"] = datetime.fromtimestamp(ts).isoformat()
    return tool_result

            

用途2: ポリシー違反のブロック

特定の条件に合致するツール呼び出しを検出してブロックし、代替ワークフロー (人間へのエスカレーション等) にリダイレクトします。

# ツール呼び出しインターセプトの例
def check_refund_policy(tool_name, tool_input):
    if tool_name == "process_refund":
        amount = tool_input.get("amount", 0)
        if amount > 500:
            # $500超の返金はブロック → 人間にエスカレーション
            return {
                "blocked": True,
                "reason": "返金額が$500を超えています。人間の承認が必要です。",
                "redirect": "escalate_to_human"
            }
    return None  # ブロックしない

            

前提条件ゲート (Prerequisite Gates)

特定のツールが呼ばれる前に、別のツールが正常完了していることを強制するパターンです。

例: process_refund は get_customer が検証済みの顧客IDを返すまでブロックする

get_customer

→ 検証OK →

process_refund 許可

get_customer 未実行

→

process_refund ブロック

タスク分解戦略

Task Statement 1.6: Design task decomposition strategies for complex workflows

2つのアプローチ

固定パイプライン (Prompt Chaining)

事前に定義されたステップを順番に実行。結果が予測しやすく、テストしやすい。

向いている場面:

- コードレビュー (ファイルごと分析 → 統合レポート)
- 文書処理 (解析 → 抽出 → 検証 → 整形)
- 定型的なマルチステップ処理

動的適応分解 (Dynamic Decomposition)

途中の発見に基づいてサブタスクを動的に生成。探索的なタスクに適する。

向いている場面:

- レガシーコードベースの調査
- 原因不明のバグ調査
- リサーチ (調べるほど新しい論点が出てくる)

コードレビューの具体例

大規模なコードレビューをエージェントにさせる場合、1回のプロンプトで全ファイルを渡すと注意力が分散します。代わりに、ファイルごとに個別分析 (ローカルパス) → 全ファイルの結果を集めてクロスファイル統合分析 (グローバルパス) の2段階に分けることで、精度を維持できます。

反復的洗練ループ

コーディネーターが合成結果を評価し、不足があればサブエージェントに再委任するパターンです。

Step 1 サブエージェントに初回の検索/分析を委任

Step 2 合成エージェントが結果をレポートにまとめる

Step 3 コーディネーターがレポートのギャップを評価

Step 4 不足がある場合、ターゲットを絞って再検索を委任 → Step 2 に戻る

完了カバレッジが十分になったらレポートを最終化

セッション管理

Task Statement 1.7: Manage session state, resumption, and forking

セッションの再開と分岐

--resume <session-name>

以前の会話を名前で指定して再開します。前回の会話履歴がそのまま読み込まれます。ただし、前回のセッション以降にコードが変更されている場合は、変更内容をエージェントに伝える必要があります。古いツール結果が残ったまま再開すると、現在の状態と矛盾する情報を参照してしまうリスクがあります。

fork_session

現在のセッションから独立したブランチを作成します。共有された分析ベースラインから異なるアプローチを並行して試すのに使います。

再開 vs 新規セッション: どちらを選ぶか

再開が適している場合

- 短時間の中断後に作業を継続
- コードに変更が入っていない
- 前回のコンテキストが正確に残っている

新規セッションが適している場合

- コードに大きな変更が入った
- 前回のツール結果が古くなっている (stale)
- 前回の結果を構造化サマリーとして渡せる

一般的に、stale なツール結果を抱えた長いセッションを再開するよりも、前回の結果を構造化サマリーにまとめて新しいセッションを始める方が信頼性が高いです。

確認テスト

試験形式に合わせた選択式問題です。各問題をクリックして回答を確認してください。

▶

Q1. エージェントループで、Claude のレスポンスに対する次のアクションを決定する正しい方法は？

A) Claude のテキスト応答に「完了」という文字列が含まれているか確認する

B) ループの反復回数が上限に達したかチェックする

C) response.stop_reason の値を確認し、"tool_use" なら継続、"end_turn" なら終了する

D) Claude の応答の長さが一定以下なら完了と判断する

正解: C

stop_reason がエージェントループの唯一の正しい制御信号です。A, B, D はいずれもアンチパターンとして試験ガイドに明記されています。テキスト内容のパース、任意のイテレーション上限、応答内容での完了判定は全て避けるべきです。

▶

Q2. カスタマーサポートAgentで、$500 を超える返金を確実にブロックする最適な方法は？

A) system prompt に「$500 を超える返金は処理しないでください」と記述する

B) PostToolUse フックで process_refund の金額を検証し、超過時はブロックする

C) Claude に返金額を毎回確認させてからツールを呼ぶようプロンプトで指示する

D) 返金上限をツールの description に記載して Claude に認識させる

正解: B

金銭に関わるビジネスルールには確定的保証が必要です。プロンプト指示 (A, C, D) はいずれも確率的であり、稀に違反する可能性があります。Hooks によるプログラム的強制だけが 100% の保証を提供します。

▶

Q3. マルチエージェントシステムで、コーディネーターから合成サブエージェントにコンテキストを渡す最適な方法は？

A) サブエージェントはコーディネーターの会話履歴を自動継承するので、特に何もしない

B) 「さっきの検索結果を使って」とプロンプトで参照する

C) 先行エージェントの出力をソースURL・信頼度等のメタデータと共に構造化データとしてプロンプトに含める

D) 全サブエージェントで共有メモリを使ってデータを受け渡す

正解: C

サブエージェントはコーディネーターの会話履歴を自動継承しません (A は誤り)。メモリ共有機能もありません (D は誤り)。曖昧な参照 (B) はサブエージェントが理解できません。先行エージェントの完全な出力をメタデータ付きで明示的にプロンプトに含めるのが正しい方法です。

▶

Q4. 大規模なコードレビューのタスク分解として最適なアプローチは？

A) 全ファイルを1つのプロンプトにまとめて一度にレビューさせる

B) ファイルごとに個別分析 (ローカルパス) → クロスファイル統合分析 (グローバルパス) の2段階

C) ランダムにファイルを選んでレビューし、問題が見つかったら拡大する

D) 行数の多いファイルから順にレビューする

正解: B

全ファイルを1度に渡すと注意力が分散します (attention dilution)。ファイルごとの個別分析で深い問題を検出し、その後のクロスファイル統合パスで依存関係やパターンの問題を検出する2段階アプローチが推奨されています。

▶

Q5. セッション再開より新規セッションを始めるべき場面は？

A) 作業を中断してすぐに再開する場合

B) 前回のセッション以降にコードに大きな変更が入り、ツール結果が古くなっている場合

C) 同じファイルに対する作業を継続する場合

D) エラーが発生して復旧する場合

正解: B

前回のセッション中のツール結果が古くなっている (stale) 場合、それらを含んだまま再開すると現在の状態と矛盾する情報を参照するリスクがあります。前回の結果を構造化サマリーとして新規セッションのプロンプトに含める方が信頼性が高いです。

Agentic Architecture& Orchestration

Claude API の基本

Messages API の基本構造

マルチターン会話

system prompt (システムプロンプト)

エージェントループ

エージェントループの全体像

stop_reason とは何か

エージェントループの実装

会話履歴の構造

ツール利用 (Tool Use)

ツールスキーマの定義

tool_choice: ツール利用の制御

メッセージブロックの構造

複数ツールの並行利用

マルチエージェントシステム

Hub-and-Spoke アーキテクチャ

動的ルーティングと選択的呼び出し

タスク分解が狭すぎるリスク

サブエージェントの設定と起動

Task ツールによるサブエージェント起動

AgentDefinition の構成要素

コンテキストの受け渡し方

並行起動 (Parallel Spawning)

fork_session: 分岐探索

ワークフローパターン

ワークフロー vs エージェント

1. 並列化 (Parallelization)

2. チェーン (Chaining)

3. ルーティング (Routing)

Hooks と強制パターン

確定的保証 vs 確率的コンプライアンス

PostToolUse フック

前提条件ゲート (Prerequisite Gates)

タスク分解戦略

2つのアプローチ

反復的洗練ループ

セッション管理

セッションの再開と分岐

再開 vs 新規セッション: どちらを選ぶか

確認テスト

Agentic Architecture
& Orchestration