Anthropic Academy 完全ガイド 2026 — 無料15コースでClaudeをマスターするロードマップ
ゲンキ swiftwand.ai
CCA試験対策 D1後編 — 多段ワークフロー・Agent SDKフック・タスク分解の設計判断
ゲンキ
CCA試験対策 D1後編 — 多段ワークフロー・Agent SDKフック・タスク分解の設計判断
一方、あなたのエージェントは、12%の確率で顧客情報を取得せずに返金処理を実行している。例えば、プロンプトに「必ず先に取得してください」と追記すれば解決するだろうか。しかし、答えはNoだ。つまり、CCA試験 ワークフロー Agent SDK タスク分解を正しく理解していれば、この問題の根本原因と解決策が即座に見える。
さらに、本記事は前編（D1前半: T1.1〜1.3）の続編であり、CCA Foundations試験Domain 1の後半タスク（T1.4〜1.7）を徹底解説する。特に、エージェントループの基礎とマルチエージェントのオーケストレーションを前編で押さえた読者が、次に直面するのが「ワークフローの確実性をどう担保するか」という設計判断だ。
目次
まず、プログラマティック・エンフォースメントが必要な理由（T1.4）
プロンプト指示の限界: 非ゼロの失敗率
特に、CCA試験で最も重要な概念の一つが、プロンプトベースのガイダンス vs プログラマティック・エンフォースメントの使い分けである。
具体的には、エージェントのワークフロー制御には2つのアプローチがある:
| アプローチ | 確実性 | 適用場面 |
|---|---|---|
| プログラマティック（hooks / prerequisite gates） | 100%確定的 | コンプライアンス必須の処理順序 |
| プロンプトベース（指示文で誘導） | 高いが非ゼロの失敗率 | 柔軟な判断が必要な場面 |
同様に、プロンプトに「必ずこの順番で実行してください」と書いても、LLMは確率的に動作するため非ゼロの失敗率が残る。つまり、決定論的なコンプライアンスが求められる場面では、プロンプトだけでは不十分だ。
前提条件ゲート（Prerequisite Gate）の実装
とりわけ、特定のツール呼び出しの前に、別のツールが完了していることをプログラム的に保証する仕組みが前提条件ゲートである。
class WorkflowEnforcer:
def __init__(self):
self.completed_steps = set()
def pre_tool_check(self, tool_name, tool_input):
"""ツール呼び出し前の前提条件チェック"""
# process_refund は get_customer が完了していなければブロック
if tool_name == "process_refund":
if "get_customer" not in self.completed_steps:
return {
"error": "process_refund を実行するには、"
"先に get_customer で顧客情報を取得してください。"
}
return None # チェックOK、実行許可
def post_tool_record(self, tool_name):
"""ツール実行後に完了を記録"""
self.completed_steps.add(tool_name)
具体的には、このコードでは、process_refundが呼ばれた時点でget_customerがcompleted_stepsに含まれていなければエラーを返す。したがって、プロンプトに頼らず、コードレベルで順序を強制している。
重要なポイント
構造化ハンドオフプロトコル
結論として、多段ワークフローでステージ間の情報受渡しを構造化する設計も、CCA試験 ワークフロー Agent SDK タスク分解の重要トピックだ。
handoff_payload = {
"stage": "customer_verified",
"customer_id": "C-12345",
"verification_method": "email_confirmed",
"timestamp": "2026-03-25T10:30:00Z",
"next_allowed_actions": ["process_refund", "escalate_to_human"],
"restrictions": {
"max_refund_amount": 500,
"requires_manager_approval_above": 200
}
}
さらに、ハンドオフペイロードには、顧客ID、根本原因分析、推奨アクション、制約条件を含める。結論として、これにより次ステージのエージェントは必要な情報をすべて構造化された形で受け取れる。
重要なポイント
試験問題パターン: 「何が問題か？」型
例えば、 カスタマーサポートエージェントが12%の確率で
get_customerをスキップしてprocess_refundを実行する。最適な解決策は？
| 選択肢 | 判定 |
|---|---|
A: プログラマティック前提条件でprocess_refundをブロック | 正解 — 100%確定的な制御 |
| B: プロンプトに「必ず顧客情報を先に取得して」と追記 | 不正解 — 非ゼロの失敗率が残る |
| C: イテレーション上限を増やす | 不正解 — 問題の本質と無関係 |
| D: ワークフロー全体をプロンプトチェーンに変更 | 不正解 — 依然としてプロンプトベースの制御 |
つまり、出題者の意図は 「信頼性保証が必要」な場面では、プロンプトではなくプログラマティックな手段が正解になる。
Agent SDKフック: 確定的な介入メカニズム（T1.5）
PreToolUse と PostToolUse
具体的には、Agent SDKのフックは、エージェントの動作に確定的な介入を行う仕組みである。
| フック | タイミング | 用途 |
|---|---|---|
| PreToolUse | ツール実行前 | ポリシー違反の検出とブロック |
| PostToolUse | ツール実行後 | 結果の変換・正規化 |
PostToolUseフック: データ正規化の実装
また、ツールの出力をモデルに渡す前に加工する。例えば、異なるツールがUnixタイムスタンプ、ISO 8601、MM/DD/YYYY形式など異なるフォーマットで日付を返す場合、PostToolUseフックで統一する。
def post_tool_use_hook(tool_name, tool_input, tool_result):
"""ツール結果の Unix タイムスタンプを ISO 8601 に変換"""
if tool_name == "get_order_details":
import json
from datetime import datetime, timezone
data = json.loads(tool_result)
if "created_at" in data:
ts = data["created_at"] # 例: 1711036200
data["created_at"] = datetime.fromtimestamp(
ts, tz=timezone.utc
).isoformat() # "2026-03-21T18:30:00+00:00"
return json.dumps(data)
return tool_result # 他のツールはそのまま返す
つまり、モデルが「1711036200は何日？」と計算する必要がなくなり、したがって、推論の精度と効率が向上する。
重要なポイント
PreToolUseフック: ポリシー違反のブロック
def pre_tool_use_hook(tool_name, tool_input):
"""$500 を超える返金をブロック"""
if tool_name == "process_refund":
amount = tool_input.get("amount", 0)
if amount > 500:
return {
"blocked": True,
"reason": (
f"返金額 ${amount} がポリシー上限 $500 を超えています。"
"マネージャーへのエスカレーションが必要です。"
)
}
return None # ブロックしない
特に、$500を超える返金リクエストをツール実行前にインターセプトし、人間によるエスカレーションにリダイレクトする。具体的には、プロンプトで「高額な返金は避けてください」と書いても確率的にしか遵守されないが、フックなら100%ブロックできる。
重要なポイント
フック vs プロンプトの使い分け判断基準
| 要件 | フック | プロンプト |
|---|---|---|
| 100%の確実性が必要（コンプライアンス） | 適切 | 不十分 |
| 柔軟な判断が必要 | 不向き | 適切 |
| データ形式の変換 | 適切 | 不向き |
| ユーザー体験の調整（口調等） | 不向き | 適切 |
具体的には、CCA試験の鍵: 「確定的な保証」が問われたらフック、「柔軟な対応」が問われたらプロンプト。加えて、この判断基準を覚えておくだけで、複数の設問に対応できる。
試験問題パターン: 「hook vs prompt」型
例えば、 ツールが返す日付形式がバラバラで、モデルが混乱している。最適な解決策は？
したがって、正解は PostToolUseフックで全ツールの日付出力をISO 8601に正規化する。したがって、プロンプトで「日付を解釈して」と指示するより確実で、モデルの推論負荷も軽減される。
タスク分解: 固定パイプライン vs 動的分解（T1.6）
2つの主要パターン
加えて、CCA試験 ワークフロー Agent SDK タスク分解の中でも、分解戦略の選択は設計判断として頻出する。
| 戦略 | 別名 | 構造 | 適用場面 |
|---|---|---|---|
| 固定順次パイプライン | Prompt Chaining | ステージ1→ステージ2→ステージ3（線形） | 予測可能な多段階処理 |
| 動的適応型分解 | Dynamic Decomposition | Coordinatorが状況に応じてサブタスクを動的に生成 | 探索的・不確実なタスク |
固定順次パイプライン（Prompt Chaining）
例えば、各ステージの出力が次ステージの入力になる線形パイプラインだ。
[入力] → ステージ1: 要約 → ステージ2: 分析 → ステージ3: レポート生成 → [出力]
したがって、ステージ数と順序が事前に決定されており、各ステージの入出力形式が明確。つまり、予測可能でテスト・デバッグが容易であり、ステージ間でバリデーションゲートを挟める。
一方、適用例としては、ドキュメントレビュー（文法チェック→事実確認→改善提案）やデータ処理パイプライン（抽出→検証→変換→格納）がある。
動的適応型分解（Dynamic Decomposition）
同様に、Coordinatorが実行時にサブタスクを決定する柔軟なアプローチだ。
[入力] → Coordinator が分析 → 必要なサブタスクを動的に決定
├── SubAgent A（発見に基づき生成）
├── SubAgent B（Aの結果に基づき追加生成）
└── 結果統合 → ギャップ検出 → SubAgent C を追加起動
とりわけ、タスクの範囲が事前に完全には定義できず、中間結果に基づいて次のステップが決まる。一方、探索的な調査に適しているが、Coordinatorの判断コストというオーバーヘッドがある。
意思決定マトリクス
| 判断基準 | 固定パイプライン | 動的分解 |
|---|---|---|
| タスク構造が事前に定義可能 | 適切 | 過剰 |
| 中間結果で方向性が変わる | 不向き | 適切 |
| 再現性・テスト容易性が重要 | 適切 | 困難 |
| オープンエンドな探索 | 不向き | 適切 |
| 処理ステップ数が固定 | 適切 | 過剰 |
| コスト・レイテンシを最小化したい | 適切 | 高コスト |
大規模コードレビューへの応用
結論として、大規模コードレビューでは、2つの戦略を組み合わせるパターンがある:
大規模コードベースのレビュー
├── フェーズ1: ファイルレベルのローカル分析（並行実行可能）
│ ├── SubAgent: auth/ ディレクトリ
│ ├── SubAgent: api/ ディレクトリ
│ └── SubAgent: db/ ディレクトリ
└── フェーズ2: クロスファイル統合パス（順次実行）
└── Coordinator: 依存関係の整合性を評価
さらに、ファイルごとに分析する固定パイプライン（フェーズ1）と、クロスファイルの統合パス（フェーズ2）を順次実行する。
試験問題パターン: 「最適なアプローチは？」型
例えば、 法的文書を3つの観点（法的正確性、読みやすさ、コンプライアンス）でレビューするタスクに最適な分解戦略は？
したがって、正解は 固定順次パイプライン（Prompt Chaining）。つまり、レビュー観点が事前に明確で、各ステージの入出力が予測可能。
例えば、 ユーザーからのバグ報告を調査し、原因を特定して修正案を出すタスクに最適な分解戦略は？
したがって、正解は 動的適応型分解。しかし、バグの原因は事前に不明であり、ログ分析→仮説生成→検証→追加調査のサイクルが必要。
セッション管理: 再開・フォーク・構造化サマリー（T1.7）
3つのセッション管理手法
| 手法 | コマンド/API | 用途 |
|---|---|---|
| 名前付きセッションで再開 | --resume | 中断した作業の続行 |
| セッションフォーク | fork_session | 共有ベースラインから独立ブランチを作成 |
| 構造化サマリーで新規開始 | 手動 | コンテキストが肥大化した場合のリセット |
–resume による名前付きセッション
# セッションを名前付きで開始
claude --session "auth-refactor"
# 後日、同じセッションを再開
claude --resume "auth-refactor"
また、再開時のポイントとして、会話履歴は復元されるが、ツールの状態（ファイルシステムの変更等の外部状態）は保持されない。例えば、セッション再開時に外部でファイルが変更された場合、エージェントにその変更を通知することが重要だ。
fork_session による分岐探索
また、fork_sessionは、共有分析ベースラインから独立したブランチを作成する。
共有ベースライン（コード分析完了）
├── Fork A: --resume "perf-optimization"
│ → パフォーマンス最適化の検討
├── Fork B: --resume "security-hardening"
│ → セキュリティ強化の検討
└── Fork C: --resume "refactor-approach"
→ リファクタリングアプローチの検討
つまり、同じコードベースを異なる観点で並行分析し、A/Bテスト的に異なるアプローチを試して比較できる。つまり、各フォークは独立しており、互いの変更に影響されない。
resume vs 新規開始の判断基準
| 状況 | 推奨アプローチ |
|---|---|
| 短時間の中断（数時間以内） | --resumeで再開 |
| コンテキストが肥大化（長時間セッション） | 構造化サマリーを作成して新規開始 |
| ファイルが大幅に変更された | 変更内容をエージェントに通知して再開 |
| 完全に異なるタスクに移行 | 新規セッションを開始 |
CCA試験では、古いツール結果を持つセッションを再開するより、構造化サマリーで新セッションを開始する方が信頼性が高いという判断がポイントになる。
構造化サマリーの設計
具体的には、コンテキストが肥大化した場合の引き継ぎテンプレート:
## セッション引き継ぎサマリー
### 完了したタスク
- auth/middleware.py のリファクタリング完了
- JWT 検証ロジックを RS256 に移行済み
### 未完了のタスク
- [ ] エラーハンドリングの改善（auth/errors.py）
- [ ] テストカバレッジ 80% 達成（現在 65%）
### 重要な設計判断
- トークンリフレッシュはクライアント側で実装する方針に決定
- Redis セッションストアは Phase 2 に延期
### 既知の問題
- rate limiter が高負荷時に誤動作する可能性あり
特に、完了タスク、未完了タスク、設計判断、既知の問題を構造化することで、新セッションが必要な文脈を即座に把握できる。
CCA試験の出題パターン総整理
具体的には、Domain 1後半（T1.4〜1.7）に関する出題パターンを5つに分類する。CCA試験 ワークフロー Agent SDK タスク分解の理解度を問う設問は、以下のいずれかに該当する。
パターン1: 「何が問題か？」型
まず、シナリオを提示し、設計の欠陥を特定させる。
- 例: 「エージェントが15%の確率でステップをスキップする」→ programmatic enforcementの不在
パターン2: 「最適なアプローチは？」型
さらに、複数の選択肢から最適な設計パターンを選ばせる。
- 例: 「予測可能な3段階レビュー」→ 固定パイプライン（動的分解ではない）
パターン3: 「hook vs prompt」型
加えて、確定的保証が必要な場面と柔軟な判断が必要な場面を区別させる。
- 例: コンプライアンス要件→hook、ユーザー体験の調整→prompt
パターン4: 「分解戦略の選択」型
さらに、タスクの性質に応じた分解戦略を選ばせる。
- 例: 事前に構造が定まるレビュー→固定パイプライン、原因不明のバグ調査→動的分解
パターン5: 「セッション管理の判断」型
加えて、状況に応じたセッション管理手法を選ばせる。
- 例: コンテキスト80%消費→構造化サマリーで新規開始
正答パターンの法則
| パターン | 正解の傾向 | 不正解の傾向 |
|---|---|---|
| 信頼性保証が必要 | プログラマティック（フック/ゲート） | プロンプト指示、few-shot |
| 予測可能なタスク | 固定パイプライン | 動的分解（過剰） |
| 探索的タスク | 動的分解 | 固定パイプライン（不適合） |
| コンテキスト肥大化 | 構造化サマリーで新規開始 | そのまま再開 |
CCA頻出パターン：D1後編の出題傾向分析
例えば、Domain 1後半（T1.4〜1.7）は、前半（T1.1〜1.3）と比較して「設計判断」の選択を問う出題比率が高い。具体的には、ここでは、タスク別の出題傾向と回答戦略を分析する。
T1.4: エンフォースメント問題の出題傾向
したがって、T1.4からの出題は、ほぼ例外なく「プロンプト vs プログラマティック」の二択を判断させる形式だ。具体的には、出題パターンは3種類に分類できる。
パターンA: 失敗率の提示型
一方、「エージェントがX%の確率でステップをスキップする」というシナリオが提示される。つまり、X%という具体的な失敗率は、プロンプトの非ゼロ失敗率を暗示している。したがって、正解は常にプログラマティック・エンフォースメント（前提条件ゲート）だ。
さらに、パターンB: コンプライアンス要件型
同様に、「規制要件として処理順序が義務付けられている」というシナリオでは、100%の確実性が求められる。つまり、「プロンプトを改善する」選択肢は確実に不正解だ。
パターンC: 複合選択肢型
とりわけ、4つの選択肢に「プロンプト改善」「フック実装」「イテレーション上限増加」「プロンプトチェーン」が並ぶ。同様に、プロンプトチェーンも結局はプロンプトベースの制御であり、確定的ではない点に注意する。一方、イテレーション上限の増加は問題の本質と無関係だ。
T1.5: フック問題の出題傾向
結論として、Agent SDKフックに関する出題は、「PreToolUse vs PostToolUse」のタイミング判断が中心だ。
| シナリオのキーワード | 正解のフック |
|---|---|
| 「ブロックしたい」「防止したい」「制限したい」 | PreToolUse |
| 「変換したい」「正規化したい」「フォーマットを統一したい」 | PostToolUse |
| 「日付形式がバラバラ」 | PostToolUse |
| 「ポリシー上限を超える操作」 | PreToolUse |
判断基準は単純だ。つまり、ツール実行「前」に介入するか、ツール実行「後」に結果を加工するか。シナリオを読んだら、まず「ツールの実行自体を止めたいのか、結果を変えたいのか」を判断する。
T1.6: タスク分解問題の出題傾向
さらに、分解戦略の選択問題では、シナリオの性質を素早く分類する必要がある。具体的には、以下の判断フローを試験中に適用する。
また、よくある誤答パターンとして、「柔軟性が高い方が優れている」という先入観で動的分解を選んでしまうケースがある。しかし、固定パイプラインが適切な場面で動的分解を選ぶと「過剰（overkill）」として不正解になる。つまり、テスト容易性とコスト効率を考えれば、タスク構造が明確な場合は固定パイプラインの方が設計として優れている。
T1.7: セッション管理問題の出題傾向
つまり、セッション管理の出題は、状況に応じたアプローチの選択が問われる。具体的には、頻出シナリオは以下の3つだ。
シナリオ1: コンテキスト肥大化
特に、「長時間セッションでコンテキストの80%を消費した」場合、正解は構造化サマリーを作成して新規セッションを開始すること。--resumeでの再開は不正解になりやすい。古いツール結果が蓄積されたセッションをそのまま再開すると、品質低下のリスクがある。
シナリオ2: 外部ファイルの変更
具体的には、セッション再開時に外部でファイルが変更されていた場合、重要なのはエージェントにその変更を通知することだ。--resumeは会話履歴を復元するが、外部状態の変化は自動的に反映されない。
シナリオ3: 複数アプローチの比較
同じ分析結果を起点に異なるアプローチを試したい場合、fork_sessionが正解だ。新規セッションでは共有ベースラインの会話履歴が失われるため、fork_sessionの方が効率的だ。
横断的な正答パターン
加えて、Domain 1後半全体を通じて、以下の原則が正答選択の判断軸になる。
| 原則 | 正解の方向 | 不正解の方向 |
|---|---|---|
| 確実性の保証 | プログラマティック制御（フック/ゲート） | プロンプト改善、few-shot追加 |
| タスクの予測可能性 | 固定パイプライン | 動的分解（過剰設計） |
| コンテキスト管理 | 構造化サマリーで新規開始 | 肥大化したセッションの無理な継続 |
| データ正規化 | PostToolUseフック | プロンプトで「解釈して」と指示 |
例えば、試験では「最も適切なもの」を選ぶため、複数の選択肢が部分的に正しく見えることがある。その場合、上記の原則に照らして「最も直接的かつ確定的な解決策」を選ぶのが鉄則だ。
まとめ: D1後半の設計判断チェックリスト
したがって、Domain 1後半のタスク（T1.4〜1.7）を横断する設計判断のチェックリストを整理する。
- 前提条件ゲート: コンプライアンス必須の処理順序は、プロンプトではなくプログラマティックに強制しているか
- PreToolUse / PostToolUse: ポリシー違反のブロックとデータ正規化に、フックを活用しているか
- 固定 vs 動的: タスクの性質に応じた分解戦略を選択できているか
- セッション管理: コンテキスト肥大化時に、構造化サマリーによる新規開始を選択できるか
- 構造化ハンドオフ: ステージ間の情報受渡しが、顧客ID・根本原因・制約条件を含む構造化フォーマットになっているか
前編ではエージェントループ、マルチエージェント・オーケストレーション、サブエージェントのスポーンを解説した。次回はDomain 2: ツール設計とMCPインテグレーションに進む。ツール記述の設計、構造化エラーレスポンス、tool_choiceの3モードを掘り下げる。
さらに詳しい情報はAnthropic Documentationでご覧いただけます。
重要なポイント
さらに深く学ぶために: 本記事はCCA試験の設計判断パターンを概説したものです。合格に向けた実践的な準備には、Anthropic Academy公式コースでのハンズオン学習と、模擬問題サイトでの演習を併せて実施してください。本シリーズの完全ガイド（Day 1）で推奨する「3本柱」の学習戦略も参照してください。
ABOUT ME
AIを使って、毎日の生活をもっと快適にするアイデアや将来像を発信しています。
初心者にもわかりやすく、すぐに取り入れられる実践的な情報をお届けします。 Sharing ideas and visions for a better daily life with AI.
Practical tips that anyone can start using right away.
