マルチエージェント
読み: マルチエージェント
マルチエージェントとは協調AI
マルチエージェントは単一のAIモデルではなくプロンプトエンジニアやリサーチャーなどの異なる役割を与えられた複数のAIが自律的に対話と協調を行いながら複雑な業務を処理するシステムである。
かんたんに言うと
優秀な専門家たちが集まるプロジェクトチームを想像してほしい。それぞれが自分の専門領域の知見を持ち寄り議論を重ねて一つの成果物を作り上げるプロセスそのものである。
単一AIの限界を超える複数エージェント協調の仕組みと基本構造
ChatGPTのような単一のLLMに複雑な指示を出すと途中で文脈を見失うことが多い。プロンプトをどれだけ工夫しても限界がある。
そこで複数のAIに役割を分割する。
例えばコードを書くAIとそれをレビューするAIを分ける。互いにダメ出しをさせながら品質を上げていく。OpenAIのAPIを叩いて単純な一問一答を繰り返すのとは次元が違う。それぞれのエージェントにシステムプロンプトで明確なペルソナと制約を与え自律的に動かす。
ただエージェント同士の会話が無限ループに陥ることもある。相手の出方を待ってフリーズするケースも珍しくない。どこで議論を打ち切るかの設計が悩ましい。
実務で使える主要な開発フレームワークと法務や経理での活用イメージ
開発フレームワークとしてMicrosoftのAutoGenやソフトウェア開発に特化したChatDevがよく知られている。最近ではOpenAIがSwarmという軽量なフレームワークを公開した。
法務部門での契約書チェックを考えてみよう。
下書きを作成するエージェント、過去の判例と照合するエージェント、自社に不利な条項を指摘するエージェント。これらが連携してリスクを洗い出す。経理部門なら複数拠点から上がってくる経費精算の領収書データと社内規定を突き合わせる作業を分担させる。各エージェントが専門特化することで単一モデルの限界を突破できる。
本当に実務に耐えうるのか。判断が分かれるところである。
技術的限界と現場の落とし穴
複数のAIが裏で何度もAPIを呼び出すためトークン消費量が跳ね上がる。月末の請求書を見て青ざめることになる。
さらに厄介なのがハルシネーションの連鎖である。
一人のエージェントが嘘をつくと他のエージェントがそれを前提に議論を進めてしまう。結果として非常に説得力のある架空のレポートが出来上がる。これを防ぐための監視機構をどう組み込むか。途中で人間の承認プロセスを挟む設計も可能だがそれではシステムの自律性が損なわれる。現場のエンジニアの腕が試される。
スピードと精度を競う業務では使う気にはならない。
導入を見極めるための評価基準
自社の業務に組み込むべきか。
まずは物流部門の配車計画のような変数が多く正解が一つではない領域でPoCを回してみるのがいい。単一のモデルで処理できる単純作業にマルチエージェントを持ち込むのは無駄である。
投資対効果をどう測るか。
APIの利用料と開発工数を天秤にかけ本当にそれだけの価値があるのかシビアに計算する必要がある。エラーが起きたときの責任の所在も曖昧になりがちである。流行りだからと飛びつくと痛い目を見る。システムを運用する覚悟はあるか。
当社の見解
当社ではClaude Code・Antigravity・Codexの3つのAIエージェントを日常業務で併用している。記憶を共有しているため、別のAIに同じ説明を繰り返す必要がない。ただし、記憶共有だけでは足りなかった。一方のAIが他方の成果物を勝手に修正して壊す事故が起きた。これを受けてファイル所有権制度を導入し、どのAIがどのファイルを所有するかを定義した。AIの自主性に頼らず、仕組みで上書きや巻き戻りを防いでいる。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。