Herdrベースのマルチエージェントワークフロー構築記

1. プロンプト一つで終わるという幻想、そして直面した壁

最近では Claude Code、Antigravity、Cursor、Codex などの優れた AI コーディングツールが普及し、プロンプト一行で「機能を追加して」と依頼すれば、コードがあっという間に完成するという驚きの体験を、誰もが一度は味わったことでしょう。

トイプロジェクトや単純なスクリプト作成の段階では、AI エージェントを一つだけ起動し、対話形式でコーディングしても十分に優れた成果を得られます。しかし、複数の開発者が協業し、複雑なビジネスルール、厳格な DDD アーキテクチャ、トランザクション境界が絡み合う実際のエンタープライズバックエンド環境に入った瞬間、単一エージェント方式は急激に限界を露呈し、失敗し始めます。

チームプロジェクトで自分に割り当てられた複雑な機能チケットに対応する際、たった一つのエージェントセッションに、DB マイグレーション DDL から JPA リポジトリ、ドメインエンティティ、サービスロジック、REST API、テストコードまでの全工程を丸ごと任せると、ほどなくして致命的な問題が次々と発生します。会話が 15～20 ターンを超えると、序盤に強調したフレームワークの規約やドメイン不変条件を忘れ、コードを勝手に上書きしてしまいます。エージェントが書いたコードを開発者が一行ずつ目視でデバッグし、構文エラーやビジネス例外の漏れを手作業で指摘する、疲れるピンポンが繰り返されます。時には、自分で作成した設計とコードの欠陥を自ら見つけられず、「完璧です」と言いながら盲点を正当化することさえあります。

こうした問題に直面した末、私は問いの方向を変えました。
「AI 一台にすべてを任せるのではなく、各分野の専門エージェントが互いを検証し、改善する自律エージェントチームを構築してみてはどうだろう？」

2. なぜ単一エージェントではなく「マルチエージェント（Multi-Agent）」なのか？

マルチエージェント体制には、単一エージェントで進める開発プロセスにはない、いくつかのメリットがあります。

① 認知負荷の分散と役割の純粋性

単一エージェントに「既存コードを分析し、設計を作成したうえで、実装してテストまでして」と指示すると、LLM の内部メカニズムは認知過負荷に陥ります。

一つのプロンプトの中で、調査員、設計者、開発者、テスターの役割を同時に与えられると、最も時間と労力のかかるコードベースの調査段階を省略し、不十分な Context のまま適当にコードを書く近道を選ぶようになります。

一方、マルチエージェント体制では、担当エージェントに「あなたは事実関係（Domain の関係、DB スキーマ、呼び出しフロー）だけを調査する調査員だ。決してコードを書くな」という単一の目的だけを与えます。各エージェントが一つのペルソナに 100% 集中すると、成果物の密度と正確性が最大化されます。

② 自己確証バイアスの打破と独立した検証

人間も、自分が作成したレポートの誤字や論理的な誤りを自分で見つけるのは非常に困難です。LLM もまた、自ら立てた仮定や設計に対して自己確証バイアスを持ちます。

単一エージェントのセッションで「自分が書いたコードにバグはある？」と尋ねると、たった今自分で書いたロジックの前提をそのまま引き継ぎ、「問題なく完璧です」と答えることが少なくありません。

マルチエージェント体制では、設計者が作成した計画を、その内容をまったく知らない独立した検証者に渡します。検証者は「この設計／コードには必ず致命的な欠陥がある」という前提に立ち、実際のソースコードを直接開いて実測と照合します。この過程で、多数の潜在的なランタイム例外やレースコンディションを事前に排除できます。

③ コンテキストウィンドウの衛生管理と性能低下の防止

LLM のコンテキストウィンドウが 100 万トークン以上に拡大したとしても、長い会話が続くほど初期の指示を忘れたり、途中の情報を見落としたりする「Lost in the Middle」や推論性能の低下は、依然として現実に存在する問題です。

単一エージェントは、30 個のファイルを開いて得た数万行のテキスト、Gradle のビルドエラーログ、冗長なスタックトレースをすべて一つのセッションコンテキストに抱えたまま進みます。

マルチエージェント環境では、各作業段階が終わるたびに、精製された中核成果物だけを次のエージェントにハンドオフします。数千行に及ぶ調査過程やビルドログは該当する Pane に隔離されるため、オーケストレーターと設計者のコンテキストは常にクリーンで鋭い状態を保てます。

④ 異種モデルのシナジーと死角の相殺

すべての作業に最上位モデルを使うと API コストが爆発し、すぐにトークン上限へ達します。逆に、すべての作業に軽量モデルだけを使うと、複雑なドメインアーキテクチャの推論が破綻します。

大規模な探索や単純な反復コーディング／テストは、コストが安く、トークンコンテキストが広大で、処理速度の速いモデルに任せ、高度なドメインおよびアーキテクチャ設計には、深い推論能力を持つ最上位モデルを集中的に投入します。

Claude が作成したコードを Gemini がレビューし、Gemini が作成したコードを Claude がレビューすることで、異なる学習データとアーキテクチャを持つ二つのモデルが互いの死角を補完します。

3. 実践の始まり：Antigravity と Claude Code の異種ペアリング

始まりは、ごく単純な実験でした。
「Anthropic の Claude Code と Google の Antigravity を両側で起動し、互いに連携させたらどうだろう？」

実際に二つのモデルを連携させてみると、そのシナジーは想像をはるかに超えていました。

Claude Code の Opus モデルは、複雑なビジネスロジック、オブジェクト指向に基づく責務分離、ユースケース設計で圧倒的な強みを見せました。Antigravity の Gemini 3.6 Flash モデルは、膨大なコンテキストと驚異的な速度で実際のファイルシステムを調べ、DB カラムの型、Spring Bean の依存関係、レガシーのトランザクションルールを調査する能力において、他の追随を許しませんでした。

同一モデル間の検証では見逃していた死角を、学習アーキテクチャと視点がまったく異なる二つのビッグテックモデルが相互にクロス検証し、隙間なく埋めることで、コードの完成度を高められました。

4. 「コピペシャトル」の終焉：ターミナルマルチプレクサ Herdr の導入

異種モデルのペアリングは素晴らしいものでしたが、すぐに新たな物理的ボトルネックにぶつかりました。

1 番のターミナル（Claude）で設計をコピーし、2 番のターミナル（Antigravity）へ切り替えて貼り付け、「検証して」と依頼し……再び結果をコピーして 1 番に貼り付け、「こういう問題がある。確認して」と依頼する……。同じ作業が繰り返されていました。

エージェントの役割は分担したのに、肝心の開発者である私が、ターミナル間を行き来する「コピペシャトル」になってしまったのです。

この手動切り替え地獄を終わらせるためにさまざまな方法を探していたところ、ちょうど見つけたのが Herdr でした。

Herdr は、画面を分割して表示するだけの一般的なターミナルツールとは性質が異なります。エージェントのライフサイクルとメッセージ伝達を統括する「エージェント専用バックグラウンドオーケストレーションエンジン」に近いものでした。

• Herdr は各 Pane の出力ストリームをリアルタイムで監視し、エージェントが作業中なのか（Working）、行き詰まっているのか（Blocked）、完了したのか（Done）を自ら判断します。人がターミナルの前で待機し、Enter キーを押すタイミングを見計らう必要は完全になくなりました。

• 一つの Pane が設計を終えて Done を表示した瞬間、Herdr デーモンが JSON-over-Socket IPC で出力された Markdown を取り込み、次の Pane の標準入力（stdin）へプロンプトとともに即座に直接注入します。コピペの疲労度は文字どおり 0 になりました。

• 単一セッションで長時間のビルドや全体テストを実行すると、開発者のプロンプト画面まで完全に固まってしまうことがありました。Herdr では各 Pane が独立したプロセスと仮想 TTY に隔離されているため、一つの Pane がバックグラウンドで数百件のテストを実行している間も、別の Pane のターミナルではいつでも作業を進められました。

5. Herdr マルチ Pane の進化：コーディング Pane の分離から 8 個の Agent Pane 完成まで

最初から 8 個の Pane を完璧にそろえて始めたわけではありません。複雑な開発 task を一つずつ処理する中で数多くの失敗とボトルネックを経験し、問題が発生するたびに専用 Pane を一つずつ切り出して進化させる道のりを歩みました。

第 1 段階：一対一のピンポンから始まった最初の分離（coding Pane）

初期には、メインセッション（Claude Code）だけで要件分析、アーキテクチャ設計、コード作成、コンパイルまですべてを担っていました。しかし、数十個のファイルの編集履歴と膨大なコンパイルエラーログがメインセッションにそのまま蓄積され、会話が 10 ターンを超えただけでも初期のドメインルールを忘れてしまう、コンテキスト汚染が発生しました。

これを解決するため、最初に coding Pane を分離しました。メインオーケストレーターは全体的な設計と指示だけを行い、大量のコード入力とコンパイルエラーのデバッグは圧倒的な速度を持つ Gemini Flash に委任し、メインのコンテキストをクリーンに保護し始めました。

第 2 段階：「自分の書いたコードは完璧だ」を打ち砕いた異種ダブルレビュアー

コーディング Pane を分離すると、すぐに新たな問題に直面しました。コーディングの完了後、コードを書いたエージェント本人や開発者一人に「レビューして」と依頼すると、自己確証バイアスに陥り、「すべての要件が完璧に満たされています」という魂のない回答だけが返ってきて、最終的にバグがメインブランチへ流入しました。

そこで、「このコードには必ず欠陥が潜んでいる」と仮定して破壊的にレビューする、異なるモデルによる 2 つの独立したレビュー Pane を新設しました。アーキテクチャ違反とドメイン不変条件を指摘する claude-review と、Null 安全性・SQL N+1・トランザクションのロールバックを深掘りする antigravity-review を配置しました。特に、二人のレビュアーを順番ではなく同時に（Parallel）稼働させることで待ち時間を半減し、相互に独立した多角的なクロス検証網を完成させました。

第 3 段階：コーディング後にひっくり返すのでは遅すぎる ― 設計検証（design-verify）の導入

しかし、コーディングとレビューがどれほど完璧でも、別の大きな無駄が残っていました。コーディングがすべて終わってレビュー段階に入って初めて、「基本的なドメインモデリングが間違っている」あるいは「トランザクション境界の設計がずれている」といった根本的な欠陥を発見するケースです。そのたびに、せっかく作成した数百行のプロダクションコードを丸ごとロールバックし、最初から書き直さなければなりませんでした。

この膨大な手戻りを根本から防ぐため、欠陥の検出時点をコーディング開始前へ前倒しする戦略を導入しました。設計ドキュメントが作成されるとすぐに実際のソースコードを開いて照合・検証する design-verify Pane を配置しました。設計段階でエッジケースとアーキテクチャ上の欠陥を 100% 洗い出してからコーディングに入ることで、開発サイクル全体の反復が減り、開発時間を半分に短縮できました。

4段階：指揮官と設計者の分離 - 設計専任（design）Paneの独立

設計検証ループが定着すると、新たなボトルネックが現れました。メインオーケストレーターが数百行に及ぶ詳細なドメイン設計書の作成を直接担っていたため、深い設計推論の過程でオーケストレーターのコンテキストウィンドウが急速に枯渇したのです。その結果、複数のPaneを調整し、開発者とコミュニケーションを取りながら統制すべき指揮官の認知能力が低下していました。

そこで、「オーケストレーターは自ら文書を書かず、指揮とゲートキーピングだけに専念する」という原則を定め、深いオブジェクト指向の推論と設計を専任するdesign Paneを独立させました。

5段階：想像で設計するな - 調査（research）Paneの隔離

設計専任Paneを分離したにもかかわらず、ときどき的外れな設計が生まれることがありました。設計エージェントに調査と設計を一度に任せたところ、膨大なコードベースの探索を飛ばし、自分の記憶に頼って設計を始める現象が起きたのです。

これを根本から防ぐため、設計着手前にコードベースのパッケージ依存関係、DBスキーマの型、非同期イベントの流れ、既存の実装パターンだけを徹底的に調査し、ファクトシートを作成するresearch Paneを独立させました。「設計者はコードを直接想像して調べるのではなく、調査員が提出した客観的なファクトシートだけを根拠に設計する」という厳格な分業ルールを確立しました。

6段階：ログの逆襲 - テスト（test）Paneの分離

最後に残った伏兵は、全体テストの実行でした。gradle test全体を実行するたびに、数千行に及ぶビルド出力と、以前から認識されていた別エージェントのベースライン失敗ログがターミナルを覆い尽くし、メインオーケストレーターの対話画面とContextを深刻に圧迫しました。

これを防ぐため、テストスイート全体の実行と不具合判定を専任するtest Pane（Gemini Flash）を分離し、大量のログ出力をサブPane内に隔離しました。Gemini Flashモデルで動作するAgentは、非常に長いテストログを高速で一度に処理し続けました。

7段階：セッション開始と同時に準備完了 - フック（Hook）ベースの自動プロビジョニング完成

これで7つの専門Pane体制が完成しましたが、Herdrを開始するたびに7つのウィンドウを手動で分割し、それぞれにツールとプロンプトを注入する作業は、また別の煩わしさとなっていました。

これをセッション開始フックのスクリプトで自動化しました。これでHerdrセッションが開いた瞬間、1つのMain Orchestrator + 7つの専門Specialist Paneが有機的に整列した完全なワークスペースが、わずか1秒で自動的に展開されます。

6. 1 Orchestrator + 7 Specialists

先に見てきた段階的な分離を経て、現在は指揮と品質ゲートキーピングだけを専任するメインオーケストレーター1つと、専門化された7つの下位Agent Paneからなる、合計8つのPane体制へと最終的に収束しました。

各Paneはもはや重複したり曖昧だったりする役割を持たず、単一責任の原則に基づいて、それぞれ固有の専任任務と、その任務に最適化されたLLMエンジンを与えられ、独立して稼働します。

メインオーケストレーターPaneはコードを直接読んだり書いたりせず、以下に定義した7つの専門Paneに明確なプロトコルで作業を委任し、その結果を検証・統合する役割だけを担います。

Pane名称	専任任務	搭載モデル	選定理由および中心的役割
main	パイプライン全体の指揮とゲートキーピング	Claude Sonnet	開発者とのコミュニケーション、段階的な委任、Gitコミット／マージの統制
research	コードベースの事実関係に関する実測調査	Gemini 3.7 Flash	高速処理と膨大なコンテキストを活かした、パッケージ、DBスキーマ、呼び出しフローの探索
design	アーキテクチャおよび詳細設計書の作成	Claude 3.7 Opus	深い推論能力に基づく設計書の作成
design-verify	敵対的な設計検証	Gemini 3.7 Flash	「この設計は間違っている」という前提で、欠陥とエッジケースを攻撃的に検証
coding	コード実装およびコンパイル	Gemini 3.7 Flash	圧倒的な速度とフレームワーク規約の遵守による高速コーディング
claude-review	1次コードレビュー（構造／DDD）	Claude Sonnet	アーキテクチャ層の違反、結合度、トランザクション境界、ビジネス不変条件のレビュー
antigravity-review	2次コードレビュー（バグ／安定性）	Gemini 3.7 Flash	Null安全性、SQL／N+1、例外の漏れ、べき等性、コーディング規約のレビュー
test	テストスイート全体の回帰検証	Gemini 3.7 Flash	Gradleの全テストを実行

7. エンドツーエンドのMulti-Agentワークフロー

どれほど優秀な7つの専門エージェントを配置しても、厳格かつ決定論的なワークフロールールがなければ、マルチエージェントシステムは瞬く間に混乱と非効率の泥沼に陥ります。エージェントとともに作業する中で実感した、ワークフローの主な必要性は次のとおりです。

1. 「放任型の自律性」の失敗を防ぐ：エージェントたちに「君たちだけで話し合って、機能を開発してみて」と自律性を与えると、エージェントは早まってコーディングを始めたり、終わりのないピンポンのような会話でトークンだけを浪費したりします。各エージェントに明確な入力と出力の契約を強制するパイプラインが不可欠です。

2. ソフトウェア工学における「Shift-Left」原則の実現：欠陥は発見時期が遅くなるほど、修正コストが幾何級数的に増大します。コーディング開始前の設計ドキュメント段階で欠陥を可能な限り取り除くことが、開発全体のリードタイムを短縮し、コードのロールバックをなくす最善の方法です。

3. 品質ゲートの決定論的な収束：「問題がなくなるまで検証を繰り返す」「テスト失敗が0件であることを確認する」といった厳格なゲートキーピングにより、LLMのコンディションや確率的なばらつきに左右されず、常にプロダクションレベルの無欠陥品質へと成果物を収束させることができます。

4. 人間の開発者の認知エネルギーを温存する：プロセスが明確に定義されていれば、開発者はエージェントの細かな作業ごとに不安を感じて介入する必要がありません。

開発者は「設計検証完了後の最終承認」と「最終マージの時点」という最も重要なコントロールポイントにのみ、エネルギーを集中できるようになります。

そのために、オーケストレーターエージェントに7つの専門Agent Paneを次のようなワークフローで配置し、動作するようにしました。そしてワークフローが稼働する中で、エージェント間の責任はさらに明確になり、開発者の介入が必要な設計レビューと最終検証以外のプロセスは、開発者が介入しなくても自然に進行する構造が完成しました。さらに、開発者の介入が減ったことで、私は重要なレビューや検証のプロセスにより集中できるようになりました。

8. Multi-Agent Workflow導入後に実感した4つの変化

チーム単位で協働するバックエンドプロジェクトの環境で、自分に割り当てられた複雑な機能チケットを処理するためにこのワークフローを構築・活用した結果、劇的な変化を実際に体感できました。

第一に、精神的な疲労と不安感が減少しました。以前は、AIが作成したコードに潜在的なバグがないか不安を感じながら、数百行のコードを一行ずつ確認してデバッグすることに大きなエネルギーを費やしていました。今では、research、design-verify、二重のレビュアーが多段階で検討してくれるため、開発者は中核となるビジネス設計の承認とアーキテクチャ上の意思決定だけに、脳のエネルギーを完全に集中できます。

第二に、設計段階で早期に欠陥を阻止することで、大規模な手戻りが減りました。AIのコーディングがすべて終わった後になって、ドメインモデリングの誤りを発見し、コード全体を作り直していた無駄がなくなりました。設計段階で欠陥を事前に取り除くことで、コーディング開始後に不要な試行錯誤をすることなく、高い完成度で実装を仕上げられるようになりました。

第三に、作業速度と品質の両方を確保できるようになりました。一人でチケットを担当しているにもかかわらず、成果物はまるで専任のシニアスクワッドが付きっきりで事前調査、詳細なMarkdown設計書、二重のクロスレビュー、日本語のJavadoc、全体回帰テストを完璧に終えたかのような最高品質となり、チームのコードベースに貢献できるようになりました。

第四に、自動化された設計ドキュメントと透明性のある意思決定の履歴を資産化できるようになりました。忙しいスケジュールに追われてドキュメント化を省略していた過去とは異なり、ワークフローに沿って進めるだけで、実測ファクトシート、ドメイン設計書、敵対的検証のフィードバックがそのままファイルとして残り、チームの永続的な知識資産として蓄積されています。

9. おわりに：自分だけの最適化されたMulti-Agent Workflowを見つける

本稿で紹介した1 Orchestrator + 7 Specialistsという構成は、約2週間にわたって何度も試行錯誤を重ねた末に導き出した、私独自の成果です。この構成がすべての開発者とすべてのプロジェクトに適した「万能の正解」ではありません。UI中心のフロントエンド環境であれば視覚的回帰テストエージェントが中心になるでしょうし、迅速な仮説検証が重要な初期スタートアップであれば、2～3個の軽量なPane構成のほうが適している可能性があります。

重要なのは数ではなく「原則」です

1. 役割の純粋性：1つのエージェントにあまり多くの役割を担わせず、調査・設計・実装・検証を分離して集中度を最大化すること。

2. 自己肯定バイアスを打ち破る敵対的な相互検証：自分が作成した設計を盲信せず、異なる視点を持つエージェントに欠陥を攻撃させること。

3. 簡潔なコンテキスト：冗長な生ログは個々のエージェントに隔離し、精製された成果物だけでコミュニケーションすること。

4. 開発者の最終的な統制権：AIにすべての判断を委ねず、設計承認や最終レビューなどの重要なコントロールポイントを開発者が握ること。

Multi-Agent Workflowを構築して以来、私は自分だけの自律エージェントチームを指揮し、品質ゲートを最終承認するエージェントリーダーへと役割が進化しました。AIコーディングの真の未来は、「より巨大な単一プロンプト」に依存することではなく、自分のプロジェクトとニーズに合わせて、最も信頼できる協働パイプラインを自ら設計し、進化させていくことにあります。ぜひ皆さんも、それぞれの技術スタックと開発環境にぴったり合ったAI自律協働チームを構築してみてください。

informalife