エージェントチェーン

複数のエージェントをファイル出力やフックを介して順次接続し、一連のワークフローを構成するパターン。エージェントのネスト（サブエージェントからサブエージェントを呼ぶこと）が制限されている場合に、代替として採用される。

動機

エージェントオーケストレーションでは、サブエージェントの深さが1レベルに制限されることが多い（無限ネスト防止のため）。しかし複雑なワークフローでは、「AがBを呼び、BがCを呼ぶ」ような直列パイプラインが必要になる。

エージェントチェーンはこの制約を、ファイルの受け渡しや**フックの自動実行**によって回避する。

仕組み

エージェントA         エージェントB         エージェントC
（仕様作成）    →     （アーキテクチャ）  →   （実装・テスト）
      ↓                     ↓                     ↓
  ファイル出力          ファイル出力            最終成果物
READY_FOR_ARCH       READY_FOR_BUILD           DONE

各エージェントは前のエージェントが出力したファイルを入力として受け取り、処理を完了したら次のステージを示すファイルを出力する。フック（PostToolUseなど）を使って、ファイルの出現を検知して次のエージェントを起動することもできる。

実装パターン

ファイルベースの受け渡し

pm-spec エージェント → spec.md を出力
   ↓ (フックが spec.md の作成を検知)
architect エージェント → architecture.md を出力
   ↓ (フックが architecture.md の作成を検知)
implementer エージェント → 実装ファイルを出力

ステートファイルによる進捗管理

# エージェントAが完了時に書き込む
echo "READY_FOR_ARCH" > .pipeline-state

# フックがステートを監視してエージェントBを起動
if [ "$(cat .pipeline-state)" = "READY_FOR_ARCH" ]; then
  claude --agent architect
fi

直接ネストとの比較

トレードオフ

• 疎結合による複雑さ: 直接呼び出しより状態追跡が難しくなる
• レイテンシ: ファイルI/Oやフックのオーバーヘッドが加わる
• エラー伝播: 途中のエージェントが失敗した場合の対処が必要

関連

• エージェントオーケストレーション
• サブエージェント
• フック
• タスク委譲
• ワークフロー