「複数のAIエージェントを作って、エージェント同士で会話させながら自律的に業務を進めさせたい」。
「AutoGPTやマルチエージェントフレームワークを試してみたが、エージェント同士が延々とチャットを繰り返してコストが溶け、期待した成果物が出てこない」。
1人法人や個人開発、あるいは本業の傍らでAIエージェントを実務に組み込もうとしたとき、誰もが一度は直面する壁が**「エージェント間の連携（マルチエージェント）の破綻」**です。
連載「1人法人1000馬力化計画」では、これまでに4人のAI社員（専門機能）を立ち上げてきました。
- 秘書役（タスク管理）: 期日や未マージPRを1枚にまとめる（第1回：Claude Codeのタスク管理）
- 制作担当（投稿生成）: 型と設定を分離してSNS投稿を量産する（第2回：Claude CodeでSNS投稿を自動化する方法）
- 分析担当（反響分析）: 評価式を固定して客観的な勝ち型を抽出する（第3回：Claude CodeでSNSの反響を分析する方法）
- 品質管理担当（検査採点）: 75点基準で形式検査と人間の判断を分ける（第4回：AIにブログ記事を採点させる方法）
単体で動くエージェント（点）が揃った次のステップは、それらをひとつの線、そして継続的に回る「業務ループ（面）」へつなぎ合わせることです。
しかし、ここで「エージェント同士を直接APIやチャットで会話させて連携させよう」とすると、ほぼ確実に現場で破綻します。
先に結論から言うと、私の会社（Nogawa L.prince合同会社）ではエージェント同士の直接対話を完全に捨てました。代わりに、すべての状態と引き継ぎを「Gitリポジトリ上のファイル（MarkdownやJSON）」をインターフェースにして非同期につなぎ、人間が握るべき2つの意思決定ゲート（公開GOと施策選定）だけを固定する設計を採用しました。
長期連載の第5回として、複数のAIエージェントを破綻させずに連携させる「自律稼働ループ（Software Factory）」の設計思想と運用のリアルを記録します。
この記事の結論（先に3点）
- エージェント同士を喋らせない。「Gitとファイル」を唯一の正本にする: チャットのやり取りで状態を持たせず、Git管理されたMarkdown/JSONファイルの入出力で疎結合に連携。コンテキストの汚染と無限ループを構造的に防ぐ。
- 制作・検査・分析をつなぐ「非同期パイプライン」を組む: 「制作（生成）→ 検査（静的解析・品質判定）→ 人間の承認（公開GO）→ 計測（自動収集）→ 分析（勝ち型抽出）→ 指示書の更新」という一方向の閉じたループを確立。
- 人間は「作業」を手放し「2つのゲート（意思決定）」だけを握る: 人間がボトルネックになる編集・集計作業は手放し、「本番公開・マージのGOサイン」と「抽出された型から次週の施策を選ぶ判断」だけに集中する。
適合する読者と限定事項
-
この記事が役に立つ人:
- 個別のAIプロンプトやスクリプトは動くようになったが、全体の業務フローとして自動化・半自動化したい人
- マルチエージェントの会話形式を試して、無限ループや品質低下に挫折したエンジニア
- 1人法人やスモールビジネスで、自分の作業時間を増やさずに事業のアウトプットを最大化したい人
-
限定事項:
- 特定のマルチエージェントライブラリ（LangGraphやCrewAIなど）のAPIチュートリアルではなく、Claude CodeやCLIツールを実務に組み込んで破綻させないための「アーキテクチャと運用設計の記録」です。
課題：なぜエージェント同士を「直接対話」させると破綻するのか
複数のAIに仕事を分担させようとするとき、最初に思い浮かぶのは「制作エージェントが下書きを作り、レビューエージェントにチャットで送り、修正点を対話しながらブラッシュアップする」という協調対話の構図です。
しかし、実際にこの対話型マルチエージェントを業務フローに組み込むと、以下の3つの壁に突き当たります。
1. 伝言ゲームによる文脈の劣化と「論点逸脱」
エージェントAが作った文章に対してエージェントBが指摘を出し、Aが再修正する……という往復を繰り返すと、往復のたびに最初の制約や前提（ペルソナ、文字数、絶対に守るべき規約）がコンテキストから薄れていきます。
3往復もすると、文章は滑らかになるものの、最初に狙っていた独自の尖りや具体的な数字が削ぎ落とされ、「無難で退屈な一般論」に変質してしまう現象が頻発しました。
2. APIコストの爆発と停止不能ループ
「合格基準を満たすまで対話を続ける」というループを組むと、エージェント同士が互いの些細な表現の好みを巡って指摘し合い、延々と会話が止まらなくなります。
気がついたときには大量のトークンを消費してAPI費用が急増し、途中でタイムアウトやレートリミットに達してエラー終了するという事故が起きます。
3. 「誰が何を決定したか」の監査ログが残らない
エージェント同士のチャット履歴の中に修正理由や採用判断が埋もれてしまうと、後から「なぜこの表現になったのか」「なぜ重要な注意書きが削られたのか」を人間が検証できません。
また、制作エージェントとレビューエージェントが同じセッションで動いていると、レビュー役が「自分が生成を支援した文脈」に引っ張られ、客観的な採点が甘くなる「自己レビューの罠」も発生します。
これらの失敗から得た結論は、**「人間同士のSlackのようなリアルタイム対話モデルを、そのままAIエージェント同士の連携に適用してはいけない」**ということでした。
解決策1：エージェント間の共通言語を「Gitとファイル」にする
この破綻を防ぐために自社で導入したのが、**GitOpsの思想を取り入れた「ファイルベースの疎結合アーキテクチャ」**です。
エージェント同士は互いのチャットセッションやメモリを直接参照しません。すべての受け渡しは、Gitリポジトリ上のMarkdownファイルまたはJSONファイルを介して行われます。
【制作担当エージェント】
↓（新規ファイル作成・PR作成）
[ drafts/xxx.md ] ← Gitが単一の真実源（Single Source of Truth）
↓（差分を読み取り、ルールベース＋静的検査）
【品質管理担当エージェント】
↓（検査レポートを出力・コメント）
[ GitHub PR / 検査ログ ]
↓（人間が差分とレポートを目視確認）
【社長（人間）の意思決定（マージ・公開GO）】
なぜ「ファイルとGit」が最強のインターフェースなのか
-
コンテキストが完全に隔離される:
制作エージェントがどれだけ試行錯誤して大量のトークンを使おうが、後続の品質管理エージェントに渡るのは「完成したMarkdownファイル1枚」だけです。途中の迷いや無駄なコンテキストが一切引き継がれないため、品質管理側は常にクリーンな状態で厳格な検査が行えます。 -
すべての変更履歴と理由がGitログに残る:
どのエージェントが、どの指示書に基づいて、何行目をどう修正したのかがコミットログとPRの差分として100%記録されます。問題が起きた際もgit diffやgit blameですぐに原因特定とロールバックが可能です。 -
並行作業（Worktree運用）が可能になる:
Git worktreeを使うことで、制作エージェントが記事Aを書いている最中に、別のエージェントが記事Bの検査を行い、さらに別のエージェントが先週の投稿分析を実行するという並行処理が、お互いの作業環境を汚さずに安全に実行できます。
解決策2：制作・検査・分析をつなぐ「自律稼働ループ」の全体像
単一の真実源（Git）を挟むことで、第1回〜第4回で個別に構築したエージェントたちが、ひとつの滑らかな「業務ループ」としてつながりました。
自社のオウンドメディア・SNS運用で実際に稼働しているループの全体構造は以下の通りです。
このループの要点は、**「エージェントがエージェントを直接呼び出すのではなく、イベントとファイルの状態遷移によって次の工程がトリガーされる」**点にあります。
各工程の役割分担
-
制作（Generation）:
最新の「勝ち型台帳」と「禁止・棄却パターン」を読み込み、Claude Codeの制作エージェントが新規下書きファイルを生成します。 -
検証（Verification）:
下書きが生成されると、ルールベースのスクリプトと品質管理エージェントが起動し、文字数、リンク数、SEOタグ、クエリ形式などを自動検査します。75点未満や足切り項目がある場合は制作側へ戻し、合格したものだけをPRとして提出します。 -
公開ゲート（Human-in-the-Loop ①）:
人間は上がってきたPRの差分と、事実確認・独自性のチェック項目（前回の「ウラトリ」の抽出結果）だけを確認し、問題がなければマージ・公開します。 -
計測（Measurement）:
公開された記事や投稿のパフォーマンスデータは、GitHub Actionsのcronジョブによって自動で取得・記録されます。 -
分析（Analysis）:
分析エージェントが固定の評価式に従って上位・下位の投稿を仕分け、なぜ伸びたのか／なぜ振るわなかったのかの型を客観的に抽出します。 -
施策選定ゲート（Human-in-the-Loop ②）:
人間は抽出された改善候補から「次週どの施策にリソースを振るか」を選択し、指示書や勝ち型台帳を更新します。更新された台帳が、次の制作工程のインプットになります。
解決策3：人間が握るべき「2つのゲート」と手放した作業
1人法人や少人数の組織で「1000馬力」を実現するための本質は、**「人間をプロセスのどこに配置するか」**です。
完全にすべてを自動化（ノーマン・イン・ザ・ループ）しようとすると、誤った情報の公開やコンプライアンス違反、炎上といった致命的な事故に直結します。
逆に、文章の校正や集計作業に人間が毎回入ってしまうと、社長の時間がいくらあっても足りません。
そこで自社では、人間の役割を**「2つの決定ゲート」**のみに絞り込みました。
| 人間が握る決定ゲート | 人間がやること | AI・機械に任せたこと |
|---|---|---|
| ゲート①：本番公開・マージの判断 | 一次体験の記述に嘘がないか確認する 守秘義務・顧客の機密に触れていないか確認する マージボタンを押し、公開を確定する |
文字数のカウント 内部リンクの妥当性確認 SEOタグの過不足検査 下書きファイルの作成とフォーマット整形 |
| ゲート②：改善施策の選択 | 提示された改善候補から次週試す型を決める 例外的なバズを普遍的な型として採用するか判断する リソース配分（どのテーマに注力するか）を決める |
インプレッションやエンゲージメント率の集計 上位・下位投稿の機械的分類 過去の失敗パターンとの重複チェック 勝ち型候補のテキスト抽出 |
人間が手放した具体的な作業
このゲート設計を導入した結果、社長（人間）の手元から以下の作業が完全に消えました。
- 「白紙の状態から構成案を考え、下書きをゼロから書く時間」
- 「文字数や内部リンクが基準を満たしているか定規を当てて数える時間」
- 「先週の投稿一覧をスプレッドシートにコピペして電卓を叩く時間」
- 「過去にどんな施策をやって失敗したかを記憶から掘り起こす時間」
人間が行うのは、**「検査済みの成果物を見てYES/NOを出すこと」と、「分析済みのデータを見て方針を決めること」**だけです。
作業（Do）を極限までAIと自動化に逃がし、意思決定（Decide）だけに人間が特化する。これこそが、1人法人が規模を拡大するための唯一の道です。
運用のリアル：自社でループを回して分かったこと
この自律稼働ループを実際に自社で回し始めてから、いくつかの重要な知見が得られました。
1. 「道具」ではなく「社員」として扱うとインターフェースが固まる
エージェントを単なる「便利なスクリプト」として扱っていた頃は、場当たり的なプロンプトを投げて結果をコピペする運用になりがちでした。
しかし、「採点のサイテン」「検査のモンバン」「分析のヨミ」「事実確認のウラトリ」のように役割と責任境界を定義し、それぞれの入出力ファイルを契約（インターフェース）として固定したことで、システム全体の保守性が飛躍的に向上しました。
2. 人間が確認するのは「実体験の整合性」と「全体の方針」の2点になった
以前は執筆から推敲、内部リンクの確認まで、記事1本の工程をすべて自分で回していました。
現在は、制作エージェントが下書きを作り、品質管理エージェントが機械チェックを済ませた状態でPRが届きます。文字数・内部リンク・表記のような機械で測れる項目を目で追う作業はなくなり、人間が確認するのは「実体験の整合性」と「全体の方針」だけになりました。確認にかかる時間は計測していないため、ここでは数字を出しません。
3. ループの改善そのものが会社の「資産」になる
エージェント同士を直接対話させず、Markdownや設定ファイルとして手順をコード化（Infrastructure as Codeならぬ「Workflow as Code」）しているため、運用の改善がすべてリポジトリにコミットとして蓄積されます。
「先週はこの検査ルールを追加した」「今週はこの勝ち型を指示書に反映した」という積み重ねが、そのまま1人法人の強固な事業基盤（1000馬力のエンジン）になっていきます。
まとめ：自律稼働ループが1人法人の背骨になる
長期連載「1人法人1000馬力化計画」の第5回として、複数のAIエージェントを破綻させずに連携させるループ設計を解説しました。
- エージェント同士を直接会話させない: チャットではなく「Gitとファイル」を唯一の正本にし、コンテキストを隔離する。
- 非同期のパイプラインを組む: 制作→検査→承認→計測→分析→指示書更新という一方向のループを作る。
- 人間の役割を意思決定ゲートに絞る: 公開GOと施策選定だけを人間が握り、それ以外の作業はすべて手放す。
AIエージェントを業務に導入する目的は、「面白い対話をすること」ではありません。「自分が手を動かさなくても、事業が前へ進む仕組みを作ること」です。
点として作ったエージェントたちをGitでつなぎ、堅牢な業務ループへと昇華させる。この設計こそが、本業や育児ですきま時間しか取れないエンジニアが、1人のままで大きな事業を動かすための最大の武器になります。
次回（第6回）は、**「採用したAI社員は翌週も使えたのか？ 実務で直面した陳腐化と指示書の再教育・メンテナンス運用」**について詳しく記録します。
関連記事
- AIにブログ記事を採点させる方法、点数と公開判断を分けた品質管理エージェントの設計（1人法人1000馬力化計画 第4回）
- Claude CodeでSNSの反響を分析する方法、評価式と勝ち型を抽出するエージェント設計と人に残る意思決定（1人法人1000馬力化計画 第3回）
- Claude CodeでSNS投稿を量産する：型と設定を分けたエージェント指示書の作り方（1人法人1000馬力化計画 第2回）
- Claude Codeのタスク管理：期日とPRの申し送りを1枚にする方法（1人法人1000馬力化計画 第1回）
- LLMの評価方法はどう設計するか、「デモでは動くが本番で使えない」を防ぐデータセット3分類と2軸評価
- LLM評価のプロンプトはどう書くか、LLM-as-a-judgeの判定がブレる原因と3つの対処