強いエージェントに最低限必要なもの

強いエージェントには、最低限何が必要なのか？

Orchestrator-Workers によるタスク委譲、Pipeline、Circuit Breaker、State Machine。

最近の OpenCode が高く評価されている理由のひとつは、3社のモデルを同時に動かしてコード設計と実装を進められる点だ。各モデルの得意分野が違うため、長所を引き出しやすい。

複雑に聞こえるが、本質はシンプルだ。3つをそれぞれ SubAgent と見なし、接続先のモデル API だけ切り替える。さらに、その3つを専用にオーケストレーションする主 Agent を1つ置けば、この効果を実現できる。

このとき少し面倒なのは、3社それぞれのプロトコルを同時に扱う点だ。ただ、多くのラッパーアプリがすでに実装しており、そこまで難しい話ではない（多くの OSS フレームワークには最初から機能がある）。

実際、これは多くの Agent プロダクトで事実上の標準構成だ。表に出していないだけで、特にモデルを選べないタイプの製品は、裏側で複数モデルが連携してタスクを処理しているはずだ。

最近、自分も物語を自動生成する Skill を作っている（純粋に学習目的で、記事はすべて自分で書いている）。もちろん中身は完全な Agent だが、Skill という形でラップしているのは、SDK で Agent を一から作らず、Claude Code の基礎能力をそのまま再利用したいからだ。

この Skill を題材に、私が Agent 設計でよく使う4つのパターンを共有する。

1. 委譲パターン & Evaluator-Optimizer

いわゆる委譲は、よく言われる Orchestrator-Workers（オーケストレーター-ワーカー）パターンだ。オーケストレーター Agent がすべての SubAgent を駆動して実行させ、この過程でオーケストレーター自身はタスク分配とレビューに専念する。

SubAgent は Plan Agent と Workers Agent の2種類に分けている。Plan Agent が計画を立て、オーケストレーターのレビューを通したあと、Workers Agent が実行する。

もちろん Evaluator Agent をさらに分離し、SubAgent の成果を専任評価させてもよい。私は通常、オーケストレーター Agent にそのまま評価させる。

この方式の利点は、各 SubAgent が独立したコンテキストを持てることだ。コンテキストの肥大化を起こしにくい。

パイプラインを構築し、すべての SubAgent の実行をオーケストレーションする。1つ前の Agent の最終出力を、次の Agent の入力にする。

例えばこの Skill では、流れは次のとおりだ：タスク設計 → 素材リサーチ → 各章の初稿 → 文書レビュー（真実性 & 句読点）→ 推敲。

このフローでは、各段階が終わるたびにレビュー機構が動く。現段階が合格かどうかを判定するレビューアは、先ほど触れたオーケストレーター Agent だ。

この設計の利点は、中間のどこかで失敗しても最初からやり直さなくてよい点にある。該当箇所を担当する Agent だけを再反復させればよい。

例えば章初稿の作成中に、オーケストレーター Agent が「前半2章ですでに計画文字数を超えている」と検出した場合、レビュー時点でその問題を明示する。そのうえで、章初稿担当 Agent に再反復と最適化を指示できる。

一方で、その前の計画や素材リサーチなど、完了済みの工程は繰り返す必要がない。

オーケストレーター Agent が各 SubAgent の結果を評価するとき、反復カウンターを維持する。

SubAgent に再反復を指示するたびにカウンターを +1 し、閾値を超えたら、オーケストレーター Agent は一時的にすべてのオーケストレーションを停止する。そのうえで現在の行き詰まりをユーザーに説明し、判断を待つ。

ステートマシンには、すべての Agent の現在の実行結果、中間結果、そして実行中に使う中間変数（反復回数など）を保持する。

同時に、Hook に近い役割も担う。前述のとおり、各タスクの終了後にはオーケストレーター Agent のレビューが入るが、その判定条件をステートマシンに置いておく。レビュー通過後、オーケストレーター Agent はステートマシン上の状態も更新する。

これは、より複雑な TodoList だと考えると分かりやすい。しかも、その状態を操作できるのはオーケストレーター Agent だけだ。

さらに、実行コンテキストの復元も重要な責務になる。もし Claude Code が予期せずクラッシュしても、再起動後にステートマシンの記録から元の状態を復元できる。オーケストレーター Agent はそのまま統括を続け、残りのタスクを完了できる。

以上は私がよく使うパターンにすぎない。必要に応じて、適切なパターンはいつでも追加できる。例えば素材リサーチ工程に並列 Agent を入れ、並列パターンでネット検索効率を上げることも可能だ。

最後に、より良い実践があればぜひコメントで教えてほしい。例に挙げた Skill の完了フローは下図のとおりだ。

Agent 设计流程