【検証】AIマルチエージェント開発、個人で32人のチームを動かしてわかったこと

現場の組織論は、AIにもそのまま効く

3つの開発チームが並列でタスクを処理し、コンテンツ調査チームがGA4分析や重複チェックを回す。これが今、私のPC上で動いている。メンバーは32人。全員AIだ。

数年前、「AIに性格を与えたら面白い」「チームに分けたらどうなる？」という実験があちこちで行われていた。結果は大体同じで、「面白いけどまともに動かない」がお決まりのオチだった。好き放題に動くエージェントたちはすぐに会話ループに陥り、矛盾した出力を吐き、収拾がつかなくなる。

ところが、2026年の今、状況が変わった。LLM（大規模言語モデル）の精度向上と、設計の工夫次第で、AIは本当に「組織」として機能する。この記事では、個人開発で32体のAIエージェントによる開発組織を構築し、実際に運用して得られた知見を共有する。

なぜ「AIの組織」を作ろうとしたのか

OpenClawのようなマルチエージェント系のOSSは、基本的に「1体のAIアシスタントをより便利にする」方向に進化している。24のメッセージングプラットフォームに対応し、560以上のスキルプラグインを揃え、音声やビジョンまで統合する。パーソナルAIアシスタントとしては完成度が高い。

でも、自分がほしかったのは「優秀なアシスタント1人」ではなく「チームとして機能するAI」だった。設計→実装→テスト→レビューのパイプラインが回り、複数のタスクを同時に処理し、人間は方向性の判断だけに集中できる。そういう開発組織がほしかった。

既存のOSSでそれを実現しているものは見つからなかった。OpenClawは「1つのゲートウェイに全部載せる」アーキテクチャで、サブエージェントはあくまでタスクの委譲先に過ぎない。チームとしての協調、ラウンド制の議論、フェーズごとの品質ゲートといった概念は設計に含まれていない。

だったら作るしかない。そう思って開発を始めた。

現実の組織構造をコードに落とし込む

設計で最も意識したのは、「現実世界の組織や構造は、長い年月をかけて最適化されたもの」という前提だ。企業のチーム編成、会議の進め方、承認フロー。これらはただの慣習ではなく、複数人が協調して品質を担保するために磨かれてきた仕組みだ。

正直に言えば、良い現場と悪い現場を思い出しながら作った。SIerとして働いていたとき、チームがうまく回っていた現場では何が機能していたか。逆に崩壊していた現場では何が欠けていたか。その経験をそのままコードに落とし込んだ。

キャラクターとロールの直交設計

各エージェントの定義は、「キャラクター（誰であるか）」と「ロール（何をするか）」の2軸で構成している。39種類のキャラクターファイルと21種類のロールファイルを組み合わせることで、同じ「イーロン」というキャラクターにリーダーでも開発者でもテスターでも任意の役割を割り当てられる。

# agent.py — キャラクターとロールを結合してシステムプロンプトを構築
def load_system_prompt(self) -> None:
    character_path = config_dir / "characters" / f"{self.character}.md"
    role_path = config_dir / "roles" / self.role_file

    # 性格（character.md）と職務内容（role.md）を単純に結合する
    content = character_path.read_text() + "\n\n" + role_path.read_text()

    # テンプレート変数を展開（ツールガイド、オーナー情報など）
    if "{{TOOLS_GUIDE}}" in content:
        content = content.replace("{{TOOLS_GUIDE}}", tools_guide.read_text())
    self.system_prompt = content

この設計が生む効果は大きい。キャラクターのMarkdownには口調や思考の癖を書き、ロールのMarkdownには「レビュアーとして合格/却下を判定する手順」のような職務記述を書く。性格と専門性が分離されているから、チーム編成を変えたいときはYAMLの1行を書き換えるだけで済む。

「お遊び」と言われていたキャラクター設定が、実はチーム運営の根幹だったことに気づいたのは、運用を始めてからだ。キャラクターが明確なエージェントは出力のブレが小さい。口調や判断基準が一貫するから、他のエージェントが「この人はこう返すだろう」と予測できる。人間のチームと同じで、相手の人となりがわかっていると連携がスムーズになる。

32エージェントのチーム構成

全体の構成はこうなっている。

各開発チームにはリーダー（設計・指示）、開発者（実装）、テスター（テスト）、レビュアー（品質判定）がいる。1チーム＝1Dockerコンテナではなく、1エージェント＝1コンテナで、物理的に独立したプロセスとして動く。3チームが3つの別タスクを本当に同時に処理できる。

窓口（Reception）にタスクを投げると、空いているチームに自動ルーティングされる。ルーティングのロジックは極めてシンプルだ。

# registry.py — 空きチームを探してタスクをルーティング
def find_available_team(self) -> DevChannel | None:
    """セッション未使用のDevChannelを返す（オーバーフロー型ルーティング）。"""
    for ch in self.dev_channels():
        session = ch.read_session()
        if not session.get("active"):
            return ch
    return None

LLMに「どのチームが最適か判断して」と任せることもできたが、やめた。理由は後述する。

ウォーターフォールが正解だった

これは自分でも驚いた発見だ。

AI以前、直前の開発現場ではアジャイルが主流で、それが最強という空気があった。自分も実際に働きやすいと思っていた。だからAIチームにも最初はアジャイル的なアプローチを想定していた。

ところが、AIにゴールだけ渡して「いい感じにやっておいて」と任せると、保守性もへったくれもない、機能も穴あき、セキュリティも穴あきのものができ上がる。AIは言われたことはやるし、言われていないこともよしなにやる。だが「よしなに」の方向が毎回違う。明確なゴールビジョンがないと、成果物の品質が安定しない。

そこで開発フローを完全にウォーターフォール＋V字モデルに切り替えた。要件整理、基本設計、詳細設計、実装、各工程に対応したテスト。そして各工程の最後に、昔でいう顧客の外部レビュー地点で、人間のチェックを入れる構造にした。

# dev.py — レビューテキストからverdictを機械的に抽出。LLM不要
@staticmethod
def _extract_verdict(text: str) -> str:
    if "[却下]" in text:
        return "rejected"
    if "[合格]" in text:
        return "approved"
    return ""

レビュアーの出力テキストに[合格]または[却下]が含まれるかを正規表現で判定する。LLMに「このレビューは合格だと思いますか？」と聞くのではなく、機械的にテキストを読む。合格ならフェーズが進み、却下なら同フェーズのやり直しになる。

さらに、開発チーム内のレビューを通過した成果物は、外部レビューチャネルに自動提出される。ここで人間が/approveまたは/rejectで最終判断を下す。フィードバックは次のラウンドで開発チームのコンテキストに自動注入される。

これで完全な品質制御が可能になった。AIに任せるべきところは任せ、人間が判断すべきところで確実に止まる。ウォーターフォールの「各工程ゲート」は、AIチーム開発においてはアジャイルのスプリントレビューより遥かに機能した。

LLMに任せる部分と機械で制御する部分

開発を進めるなかで、最初よりもLLMにやらせる部分はかなり減った。これが安定運用における最大の学びだと思っている。

イベント駆動からポーリングへ

最初はイベント駆動でLLMを呼び出していた。メッセージが来たら即座にLLMを起動して次のアクションを決める。直感的には正しそうに見えるが、実際には安定しなかった。タイミングの競合、状態の不整合、予測不能な連鎖反応。デバッグが地獄だった。

途中で全エージェントをポーリング＋ステータス参照起動に切り替えた。5秒間隔で全エージェントのステータスファイルを監視し、全員がIDLE（待機中）になったらリーダーのLLMを呼んで次の指示を生成する。

# monitor.py — 5秒間隔のポーリングでエージェントの状態を監視
async def start(self) -> None:
    while True:
        try:
            await self._tick()      # 全員の状態チェック → 次ラウンド判定
        except Exception as e:
            logger.error("SessionMonitor error: %s", e)
        await asyncio.sleep(5.0)    # 5秒待機

ステータスは機械的に制御する。それを元にLLMが起動する。この順番にしたら圧倒的に安定した。LLMにステータス管理を任せると、「今自分は作業中なのか待機中なのか」の判断すら揺らぐ。状態遷移はIDLE → ASSIGNED → WORKING → AWAITING_APPROVALの4段階で、遷移ルールはプログラムが決める。LLMの仕事は「IDLEからASSIGNEDに変わったとき、何をするか考える」ことだけだ。

ルーティングもLLMから取り上げた

タスクのルーティングも同じだ。「このタスクはどのチームが最適か」をLLMに判断させると、毎回違う理由で違うチームを選ぶ。結果に一貫性がない。FIFO（先着順）で空いているチームに投げるシンプルなロジックに変えたら、何の問題もなく回るようになった。

レビューの合格/却下判定、メンションの名前解決、セッション状態の管理。実装が進むごとに、こうした「判断に見えるが実はルールで決まる」処理をLLMから取り上げてプログラムに移していった。LLMが本当に力を発揮するのは、タスクの分解、設計判断、コードの実装、レビューコメントの生成。つまり「正解がない問題を考えること」だ。

ファシリテーションで「好き放題」を制御する

マルチエージェントの「やってみた」系で最も多い失敗パターンは「全員が好き放題に動いて収拾がつかなくなる」だ。自分も最初はそうだった。

解決したのは、リーダーやファシリテータのポジションを設けてメンションで取りまとめ、方向づけして、次に振る。この仕組みを入れたら完全に機能した。

# facilitation_monitor.py — ラウンド制のファシリテーション制御
for round_num in range(2, self.max_rounds + 1):
    if assigned:
        await self._wait_for_members(assigned)   # 指名されたメンバーの発言を待つ
    if complete:
        break
    response, assigned = await self._next_round(round_num)
    # ファシリテータが[DISCUSSION_COMPLETE]を宣言したら終了
    if "[discussion_complete]" in response.lower() and not assigned:
        complete = True

ファシリテータが各ラウンドで「誰に発言を求めるか」を@メンションで指名し、全員が発言したら次ラウンドに進む。議論が十分だとファシリテータが判断したら[DISCUSSION_COMPLETE]を宣言してまとめに入る。

ここでも「現実の会議で機能している仕組み」をそのまま再現している。議長がいて、発言順を管理し、脱線したら戻し、合意が得られたら次に進む。何百年も使われてきた会議のプロトコルは、AIにもそのまま効く。

OpenClawとai-team、設計思想の違い

OpenClawはスター34.7万の巨大プロジェクトで、個人AIアシスタントとしての完成度は非常に高い。ここでは優劣ではなく、同じ問題をそれぞれどう解決しているかを整理する。

OpenClawは「万能ナイフ」で、ai-teamは「専用の工具セット」だ。OpenClawが24のメッセージングプラットフォームに繋がるのは素晴らしいが、ai-teamが解決したい問題は「どこから指示を受けるか」ではなく「複数のAIがどう協調して1つの成果物を作るか」だった。

UIにDiscordを使ったのも意図的な選択だ。OpenClawは自前のWeb UIを数千行のSPAとして実装しているが、ai-teamはDiscordをそのまま使っている。チャット、ファイル共有、スレッド、リアクション、検索、権限管理。Discordが無料で提供しているものを自前で作り直す理由がなかった。「作らない」という判断が、個人開発では最も強い設計判断になる。

まだ試していないこと

現在、3つの開発チームに特にカテゴリ分けはしていない。だが、チームごとに性格をチューニングする余地はある。たとえばリファクタリングに強いチーム、逆にアジャイル的に素早くプロトタイプを出すチーム。ロールとキャラクターが分離しているから、YAML上の変更だけで試せる。

cronで自律的に動かし続ける機能も実装済みだが、コストの問題で常時稼働は止めている。正直なところ、使ったらとんでもないことが起きる気しかしない。いい方にも、悪い方にも。

YouTubeにデモ動画を上げることも検討している。32体のエージェントがDiscord上で議論し、コードを書き、レビューし、公開まで走る様子を見てもらうのが、一番伝わると思う。準備ができたらこの記事に追記する。

役職を分けて業務範囲を限定するのは、AIにも同じだった

この仕組みを使い始めて一番の驚きは、人間の組織で当たり前とされてきたことが、AIにもそのまま通用したことだ。

役職を分けて業務範囲を限定する。リーダーが方向性を示し、開発者が実装し、テスターが検証し、レビュアーが品質を判定する。会議にはファシリテータを置き、承認フローにはゲートを設ける。ウォーターフォールで工程を区切り、各工程の末尾で顧客（人間）が確認する。

どれも何十年も前から存在する、枯れた組織運営の手法だ。それがAIにも同じことが言えた。

そしてそれをやっていった結果、今私一人で32人のAI組織の社長になった。

参照元

• • ai-team-template（GitHub、公開準備中。記事の開発チームで完全自律開発中）
• • OpenClaw（GitHub、比較対象として参照）
• • コードの全文はGitHubリポジトリを参照