3つのエージェント（planner / coder / QA）を並列で走らせ、自律的にコードをビルド・検証するパイプライン。X 上で「Day 10 AGI build」と銘打って公開された @gkisokay 氏の Hermes Agent 活用事例は、マルチエージェント編成の実装イメージを掴むうえで参考になる一次情報です。本記事では、株式会社Fyveが受託開発で扱ってきたエージェント設計の知見を踏まえ、この3エージェントパイプラインの構造、役割分担、運用の判断軸を実務目線で解説します。「複数エージェントを連携させたいが設計の指針が見えない」という方の判断材料を一気に揃えます。

事例の概要：3エージェント編成と役割分担

@gkisokay 氏は 2026年4月15日〜17日にかけて、Hermes Agent を使った「Day 10 AGI build」を X 上で公開しました。10日間のビルドログ形式で、自身が組み上げたplanner / coder / QA の3エージェント並列パイプラインと、それらを Codex runtime monitor で監視する構成を紹介しています。

3エージェントの役割は明確に分かれています。

• planner（計画）: タスクを受け取り、サブタスクへの分解・優先順位付け・依存関係の整理を担当。後続の coder に渡す作業仕様を生成する
• coder（実装）: planner から渡された仕様を受け取り、コードを実装する。複数の coder インスタンスを並列に走らせることで、独立したサブタスクを同時進行できる
• QA（検証）: coder の成果物をテスト・レビューし、失敗時は planner にフィードバックを返す。合格基準を満たすまでループする

そして、これら3エージェントの稼働状況を Codex runtime monitor が監視し、暴走・無限ループ・コスト超過などの異常を検知する役割を担います。エージェント本体ではなく、その「上位の監視レイヤー」を別建てで用意している点が、設計上の特徴です。

仕組み解説：オーケストレーションの構造

このパイプラインの肝は、3エージェントの「並列性」と「同期点」を分けて設計している点にあります。

並列実行と直列実行の組み合わせ

planner → coder → QA という流れ自体は直列（前の出力を次の入力にする）ですが、coder の内部では複数インスタンスが並列に動きます。具体的には次のような流れになります。

• Phase 1（planner 単独）: タスクを N 個のサブタスクに分解。サブタスク間の依存関係を整理し、並列実行可能なものをグループ化する
• Phase 2（coder 並列）: 独立したサブタスクをそれぞれ別の coder インスタンスに割り当て、並列にコードを生成。Hermes Agent のサブエージェント機能を使うことで、再帰無制限のサブエージェント呼び出しが可能になっている
• Phase 3（QA 検証）: 各 coder の成果物を QA エージェントが順次レビュー。失敗があれば planner に戻して再計画させる

このフェーズ分割により、独立性の高い作業は並列化してスループットを稼ぎ、依存関係のあるフェーズは直列に保って整合性を守る、というハイブリッド構成が成立します。

エージェント間の通信

Hermes Agent はサブエージェント機能と中期メモリを組み合わせることで、エージェント間の状態共有を実現します。@gkisokay 氏の構成では、以下のような通信パターンが想定されます。

• planner → coder への引き継ぎ: サブタスク定義（タスクID、入力、期待出力、依存サブタスクID）を構造化された形式で渡す。中期メモリに書き込むことで、coder 側はそれを読み取って作業を開始する
• coder → QA への引き渡し: 実装結果（ファイルパス、変更行数、テスト結果）を同様に構造化して渡す。QA はそれを読み取り、検証ロジックを走らせる
• QA → planner のフィードバック: 失敗ケースの詳細（どのテストが落ちたか、なぜ落ちたか）を planner に返し、再計画のトリガーにする

中期メモリを「共有ホワイトボード」として使うこの設計は、Hermes Agent の3層メモリ（短期・中期・永続）の特性を活かした実装パターンです。各エージェントが自分のセッションを持ちつつ、プロジェクト単位の共有情報を中期層に集約することで、独立性と連携性を両立できます。

Codex runtime monitor の役割

3エージェント本体とは別に走る Codex runtime monitor は、いわば「監督役」です。各エージェントの稼働時間、トークン消費、再帰深度、エラー頻度などをリアルタイムで監視し、しきい値を超えたら警告またはエージェント停止を発動します。

マルチエージェント構成を本番運用に乗せる場合、この監視レイヤーがあるかないかで運用の安心感が大きく変わります。エージェント自身に「自分の異常を検知させる」のは難しいため、外部の監視プロセスを別建てするのは合理的な判断です。

私たちの解釈：この構成が示す設計思想

この事例から、私たちは3つの設計思想を読み取っています。

1. 役割を「行為」で分けるのではなく「フェーズ」で分ける

planner / coder / QA という分け方は、いわゆる「役割分担」ですが、より正確には「ソフトウェア開発のフェーズ」を分割しています。計画フェーズ、実装フェーズ、検証フェーズ——人間の開発チームでも自然に存在する区分です。

マルチエージェント設計で陥りがちな落とし穴は、「フロントエンド担当」「バックエンド担当」「DB担当」のように領域で分けてしまうことです。領域で分けると、ひとつのタスクが複数領域にまたがるたびにエージェント間の調整コストが膨らみます。一方、フェーズで分けると、ひとつのタスクは1人の planner が計画 → 複数の coder が並列実装 → 1人の QA が検証、という流れで素直に進みます。

2. 並列性は「独立性」のあるところだけに使う

coder フェーズだけを並列化し、planner と QA は直列に保つ設計は、並列化の鉄則を踏まえています。並列実行できるのは、互いに依存しない作業のみ。依存関係のあるフェーズを無理に並列化すると、競合・矛盾・整合性の崩壊が起きます。

planner は全体像を1か所で把握する必要があるため並列化しない。QA も最終判定の一貫性を保つために並列化しない。実装だけが独立性を持つから並列化できる——この判断軸は、自社の受託開発でマルチエージェントを設計する際にも応用できる原則です。

3. 監視レイヤーを「同階層」ではなく「上位」に置く

Codex runtime monitor を3エージェントとは別建てにしている点は、特に重要です。エージェント同士が相互監視する設計（A が B を監視し、B が C を監視し、C が A を監視する）は一見冗長性が高そうに見えますが、実際には全員が同じ前提で動いているため、共通の暴走パターンに対しては全員が同時に騙されます。

上位レイヤーに監視を置くことで、エージェントの「外側」から客観的に状態を観測できる構造になります。これは Kubernetes の control plane と worker node の関係に似た発想で、システム設計として筋がよいパターンです。

実務落とし込み：役割分担設計の判断軸

この事例を自社の業務自動化に応用する場合、エージェントの役割をどう分けるかが最初の判断ポイントになります。私たちが実案件で使っている判断軸は次の通りです。

判断軸1：作業フローに自然なフェーズが存在するか

業務を観察したときに、「計画 → 実行 → 検証」のような明確なフェーズが存在する場合、それをそのままエージェントの役割境界にできます。例えば次のような業務はフェーズ分割が効きます。

• 記事制作: リサーチ → 執筆 → 校正
• 提案書作成: ヒアリング整理 → ドラフト生成 → レビュー
• データ分析: クエリ設計 → 集計実行 → 結果解釈

逆に、フェーズが明確でない作業（例：チャット応対のように1往復で完結する処理）は、無理に複数エージェントに分けず、単一エージェント＋スキルで構成したほうがシンプルです。

判断軸2：並列実行できる粒度のサブタスクに分解できるか

planner 相当の役割がサブタスクを切り出したときに、それらが互いに独立して進められるかを確認します。独立していれば並列化、依存関係があれば直列のまま——これを最初に整理しておかないと、並列実行したつもりが実は競合で停まる、という事態が起きます。

分かりやすい目安は、「サブタスクA を完了させずに B を開始できるか」を問うことです。Yes なら並列化候補、No なら直列です。

判断軸3：監視・停止の権限を持つレイヤーを最初に決める

マルチエージェント構成では、コスト超過・無限ループ・暴走を止めるための「強制停止権限」を誰が持つかを最初に決める必要があります。@gkisokay 氏の構成では Codex runtime monitor がそれを担っていますが、自社実装の場合は次のいずれかになります。

• 監視専用エージェントを別建てする: 本事例のパターン。本格運用に推奨
• ホスト OS のリソース監視を使う: トークン消費・実行時間をホスト側で計測し、しきい値超過でプロセス停止
• 人間の承認ゲートを挟む: 重要な分岐点で人間の確認を必須にする。検証段階の業務向け

初期検証段階では人間の承認ゲートで始め、安定運用フェーズで監視エージェントに切り替える、という段階的な導入が現実的です。

関連事例：他のマルチエージェント実装パターン

マルチエージェント構成は @gkisokay 氏の事例以外にも、海外のビルド事例が複数公開されています。役割分担の設計を比較するための参考として、いくつか紹介します。

事例1：Teknium 氏の12並列インスタンス構成（Nous Research 公式）

Hermes Agent の開発元である Nous Research の Teknium 氏は、2026年4月25日に「Hermes Agent 自身の開発に Hermes Agent を12並列で使っている」と公開しました。バックエンド監視・post-training・RL環境の3チーム編成で、各チームが複数のサブエージェントを抱える構造です。@gkisokay 氏の3エージェント構成より大規模ですが、「チーム＝担当領域」「サブエージェント＝実作業者」という階層構造は共通しています。

事例2：@codewithimanshu 氏の UGC 広告スタジオ

2026年4月24日に @codewithimanshu 氏が公開した UGC 広告生成パイプラインは、「商品URL → スクレイピング → 広告ライブラリ調査 → ブリーフ生成」を約4分で完結させる構成です。役割分担としては「情報収集」「分析」「生成」のフェーズ分割で、@gkisokay 氏のパターンと類似の設計思想です。

事例3：Nous Research 公式の autonovel

autonovel は79,456語の英語小説を世界構築 → 章執筆 → adversarial編集 → Opusレビュー → LaTeX組版 → カバーアート生成 → ランディング公開まで自律実行する公式リファレンス実装です。7段階以上のフェーズ分割で、各フェーズが専用のサブエージェントを持つ構造になっています。@gkisokay 氏の3エージェント構成の発展形と捉えると、設計の連続性が見えます。

まとめ

• @gkisokay 氏の Day 10 AGI build は、planner / coder / QA の3エージェント並列パイプライン + Codex runtime monitor で構成される
• 役割分担は「領域」ではなく「フェーズ」で分けるのが基本。計画・実装・検証のように、人間の開発チームでも自然に存在する区分を踏襲する
• 並列化は coder のような「独立性」のあるフェーズだけに使う。planner と QA は一貫性を保つために直列のまま運用する
• 監視レイヤーは3エージェントと同階層ではなく「上位」に別建てする。Codex runtime monitor のように、エージェントの外側から客観的に状態を観測する構造が筋がよい
• 自社業務に応用する判断軸は「自然なフェーズの有無」「並列実行可能な粒度のサブタスク分解」「強制停止権限の所在」の3点
• Teknium 氏の12並列構成や autonovel の7段階パイプラインなど、同じ設計思想で規模を拡張した事例が存在する

マルチエージェント構成は「すごそう」という雰囲気だけで採用すると、調整コストで沈みます。本事例のように、フェーズ分割・並列性の制限・監視レイヤーの分離という3つの軸で設計を整えてから取り組むことを推奨します。私たちもエージェント自動化案件では、まずこの設計レビューを最初に行うようにしています。

出典

• @gkisokay の X 投稿（2026年4月15日〜17日 / Day 10 AGI build シリーズ）
• @Teknium の X 投稿（2026年4月25日 / 12並列インスタンス開発体制）
• @codewithimanshu の X 投稿（2026年4月24日 / UGC 広告スタジオ約4分）
• Nous Research 公式 autonovel リファレンス実装（github.com/NousResearch/autonovel）
• Hermes Agent 公式ドキュメント（hermes-agent.nousresearch.com/docs/）