企業内マルチエージェントチーム運用、2つのモデルの比較

マルチエージェント開発環境を導入しようとする組織は、概ね2つの道のどちらかを選ぶことになる。1つは、1つの中央化されたチームが要求をチケットとして受け付ける方式であり、もう1つは、各チームが自分たちのチームを自ら構築できるツールを配布される方式である。本章では、この2つのモデルを並べて何が異なるのかだけを整理する。

サービスチケットモデル

1つのマルチエージェントチームが、定められた範囲内の要求を常時チケットとして受け付ける。PM役のエージェントが窓口となり、Slackや社内チケッティングシステムで要求を受け取り、要求の性質に合った専門エージェントに作業を割り振り、結果を返す。利用者は自分のパソコンに何もインストールする必要はなく、使い慣れた社内ツールにメッセージを残すだけでよい。

ここでいう「定められた範囲」は、必ずしも会社全体を意味するわけではない。組織規模が小さければ会社全体でこの1つのチームを共有しても問題ないが、組織が大きくなると、本部・事業部単位でそれぞれの受付窓口を別々に運用する方が現実的になる。マーケティング本部にはマーケティング本部専用のエージェントチーム、財務本部には財務本部専用のエージェントチームを、というように分けるわけだ。いずれにせよこのモデルの本質は同じである。その範囲内では、要求が複数のチームではなく1つの窓口に集約されるという点だ。

具体的に考えるとこうなる。小規模組織であれば、マーケティングチームAの「今回のキャンペーンのランディングページの文言を整えてほしい」と財務チームBの「先月の支出データを整理してほしい」が同じ1つのPMエージェント／チケット窓口に届き、PMがそれぞれを文書作成エージェントとデータ分析エージェントに割り当てる。大規模組織であれば、マーケティング本部傘下のチームからの要求はマーケティング本部専用の窓口へ、財務本部傘下のチームからの要求は財務本部専用の窓口へ、それぞれ集約される。本部ごとに別々のエージェントチームを運用しつつも、各本部の内部では依然として「1つの窓口に集約する」という原則を守る。要求者は同じ窓口を使う他の要求者の存在を知らなくてよく、その範囲内ではエージェントチームを1つだけ構築・運用すればよいという点が、このモデルの魅力である。

なぜカンバン（Kanban）方式で運用すべきなのか

問題は、まさにこの「1つの窓口にその範囲内の要求がすべて集まる」という特性から生じる。異なるチーム・異なる性質の要求が同時に押し寄せる中で、これを順序を決めずに届いた順に処理していると、緊急ではない要求が緊急な要求を押しのけ、処理中だった作業が新しい要求に押されて途中で中断され、今何が処理されていて何が滞っているのかを誰も把握できない状態になる。人間が運営するヘルプデスクがチケット数の増加とともに破綻するのとまったく同じ理由だ。

カンバンはこの問題を3つの仕組みで解決する。第一に、可視化されたキュー（待ち行列）である。すべての要求を「待機 → 進行中 → レビュー → 完了」といった列に分けてボードに載せておけば、今何件が滞っているか、何が長く停滞しているかを誰もが一目で把握できる。第二に、進行中作業数の制限（WIP制限）である。PMエージェント（あるいはその先の専門エージェント）が同時に処理する作業数を意図的に制限すれば、第2章§2で扱った「コンテキスト過負荷」問題が組織レベルでも同じように再現されるのを防げる。制限なしに要求をすべて受け入れると、エージェントが複数の要求のコンテキストを行き来しながら混同し、品質が低下する。第三に、優先度に基づくプルである。新しい要求が届いた順ではなく優先度の高い項目から次の作業として引き上げるようにすれば、緊急の財務締切要求が緊急でない文言修正要求の後ろに埋もれ、何日も放置される事故を防げる。

結局のところ、サービスチケットモデルは「単一窓口」という利点と、「その範囲内のすべてのチームの要求が1か所に集中する」というリスクを同時に抱えており、カンバンは後者を制御可能な状態に保つための最低限の運用規律である。カンバンなしにチケットモデルだけを導入すると、最初のうちは便利に見えても、要求量が増えた瞬間に処理遅延・優先順位の逆転・コンテキストの混同という3つの失敗パターンがほぼ必然的に現れる。

開発ツール＋バリアントモデル

会社がすべての要求を代わりに処理する代わりに、各チームに「自分のチーム専用のマルチエージェントチームを自ら構築できる開発ツール」を配布する。チームは用意されたプロジェクトテンプレート（バリアント）の中から1つを選んで自分のプロジェクトをスキャフォールディングし、そうして作られたプロジェクトは独立したリポジトリとしてそのチームが継続して所有・運用する。ai-workspace-standardsが実際にどのようにこのモデルを実装しているかは、第5章§3で詳しく扱う。

同じ例で比較すると違いがはっきりする。マーケティングチームはco-workバリアントで自分のチーム専用プロジェクトをスキャフォールディングし、その中でキャンペーンの文言を継続的に磨き上げていき、財務チームはco-developやco-consultバリアントで自分のチーム専用のデータ分析パイプラインを整える。両チームとも互いの要求キューを共有せず、それぞれのリポジトリ・メモリログ・エージェント構成を独立して所有する。チケットモデルの「単一窓口の待ち行列」問題自体がそもそも発生しない代わりに、チームごとに初期セットアップと運用の負担を自ら負う必要がある。

両者を並べて比較する

要求が狭く反復的で、深いドメインコンテキストを必要としないのであれば、チケットモデルが効率的である。逆に、各チームが自分のプロジェクトを長期にわたり深く運用する必要があるなら、初期コストを許容してでもチームごとにエージェントチームを所有する方が持続可能である。

2つのモデルの長所と短所

§3の表が「何が異なるのか」を属性ごとに列挙したのに対し、ここではその違いが実際の運用でどのような利益と代償につながるのかを長所・短所として整理する。

サービスチケットモデル

開発ツール＋バリアントモデル