AIエージェントは「増やせば賢くなる」のか　Metaとハーバード大の研究が示す“分業の条件”（5/5 ページ）

企業では「誤情報の扱い」と「アクセス権限」が課題に

　企業が自社の業務で使う場合には、論文の範囲外の問題が加わる。第1に、誤情報の扱いだ。元の資料、確認した日時、計算に使った条件まで追えるようにし、判断への影響が大きい項目は元資料と照合する仕組みを、企業側で別途設計しなければならない。

　第2に、アクセス権限だ。人事向けのエージェントが作った給与情報の要約を、営業向けのエージェントが検索できるなら、元の人事システムをどれだけ厳しく制限していても、情報は別の経路へ流れる。論文のデータストアは全員が同じものを読む前提であり、誰がどの投稿を読めるかという制御は扱っていない。

　以前の連載記事で「社員証」と「委任状」になぞらえて紹介した、エージェントの身元と権限の管理は、複数で働く場合にも変わらず必要になる。

　この空白を、プラットフォーマーは製品機能として埋めにかかっている。先述のGoogleの発表によれば、同社のGemini agentでは、全てのエージェントに暗号学的に証明された固有のIDを与えて従業員と同じように最小権限で管理し、エージェントの行動を全て監査証跡に記録して人ではなくエージェントに帰属させ、エージェント間の通信を含む全ての通信を「Agent Gateway」というAI向けのネットワークファイアウォールに通して組織の方針を適用する。

　例えば「エージェントは『Need to Know』に分類された文書を開いてはならない」という方針を一度書けば、社内の全エージェントに適用される。プロジェクトごとに支出上限を設け、上限に達したらエージェントを一時停止し、管理者が再開を判断する機能も含まれる。

　以上は研究を企業導入へ結び付ける際の検討事項であり、ScaleMASが解決を実証した問題ではない。論文が扱っているのは、情報を見つけやすくし、読み取り量を抑え、一部のエージェントの離脱に耐える仕組みである。その情報を信じてよいか、渡してよいかを判断する機能は、別に設計しなければならない。

企業が決めておくべき「3つのこと」

　ここまでの議論から、複数のAIエージェントによる分業を自社の業務に導入しようとする企業には、動かす数を決める前に整理しておきたい内容が3点あることが分かる。

　第1に、仕事のどの部分を並行して進められるか、そしてそれをどう測るかだ。冒頭の提案書作成なら、競合各社の情報収集は複数のエージェントで分業しやすいが、評価基準の決定や最終提案の判断には共通の前提が要る。Google Researchの研究が示したように、順序に依存する仕事では分けること自体が逆効果になり得る。

　分けた後は、論文のように、同じモデル、同じ資料、同じ数で、情報共有の有無だけを変えて比べてみる。1体で長く作業させた場合や、独立に複数回試して良い結果を選ぶ場合とも比較できれば、協力そのものの価値が見えやすくなる。成績が頭打ちになる地点は仕事ごとに違うので、数を増やすたびに新たに何ができるようになったのかを確かめることになる。

　第2に、引き継ぐ情報の条件だ。論文の投稿の形式は、社内の引き継ぎ規則の下敷きにできる。何をしたかは、同じ仕事をする人が検索する言葉で書く。何を土台にしたかは、元資料か先行する成果で示す。論文では参照先を付けるかどうかは任意だが、企業の業務で使うなら、判断に関わる成果には参照先の明記を義務付けるのが現実的だろう。

　これは筆者の提言だが、競合の料金なら、金額、通貨、契約条件、確認日、出典をそろえ、分からなかった項目は空欄にするか「未確認」と記載する。その上で、よく引用される情報ほど影響が大きいので、判断に関わる項目は元資料と照合する手順を決めること。そして、派生した要約や分析結果にも、元資料と同じアクセス権限を適用することだ。

　第3に、誰が、どの条件で仕事を終わらせるかだ。Pass@Nでは「候補の中に正解がある」ことを測っており、どの候補を採用するかは測っていない。数値の計算なら再計算、プログラムならテストという具合に、成果に応じた確認方法を組み込み、何社の何項目を確認したら完了なのか、資料同士が矛盾したら誰へ戻すのか、費用が上限に達したらどうするのかを決めておく。

　Googleが支出上限で「エージェントを止め、人が再開を判断する」設計を採ったように、上限は人へ戻す合図として使うのが現実的だ。一部のエージェントが止まったときに、残りで続けるのか、人へ戻すのかも同じだ。外部への送信や発注まで任せるなら、その直前の確認と、失敗時に戻す手順も要る。エージェント同士の会話が落ち着いたことや、全員が同意したことを、そのまま業務完了の条件にしてはいけない。

　これらの条件を、技術担当だけに任せてはならないことも強調しておきたい。調査結果を使う部署が、必要な正確さや許容できる欠落を示さなければ、開発側は何をもって成功とするか決められない。AIのチームを評価するには、仕事を依頼する側が、その仕事の完成条件を説明できる必要がある。

　今後、マルチエージェントの仕組みが製品や開発基盤に導入されるにつれ、企業は動かせるAIの数だけでなく、情報共有や業務の終了条件をどう設計するかも問われることになる。冒頭の提案書に戻れば、必要なのは、比較条件がそろい、数字の根拠を確認でき、人間が判断に使える資料である。そのために何体が必要かは、仕事の内容と、情報を受け渡す仕組みによって変わる。

　AIエージェントは、増やすほど賢くなるわけではない。読む負担を増やさずに、必要な情報が必要な担当へ届く仕組みを整えて初めて、数は力になる。その設計の責任は、AIではなく、仕事を任せる私たちの側にある。

小林啓倫のエマージング・テクノロジー論考

生成AIやメタバース、新たなサイバー攻撃など、テクノロジーの進化が止まらない。少しずつ生活の中に浸透し、その恩恵を預かれることもある一方、思いもよらない問題を生み出すこともある。このコーナーでは、さまざまな分野の新興技術「エマージング・テクノロジー」について、小林啓倫氏が解説する。

この連載の記事をもっと見る

この記事の著者

関連記事

• 

  「長く働くAI」が裏目に？　OpenAIの“脱走事件”が示すリスクの変化　企業に求められる対応は

• 

  「AIが勝手にやった」は通用しない？　AIエージェントにも“社員証”と“委任状”が要るワケ　今からできる対策も解説

• 

  Googleが“自社AIの裏切り”に備え始めた　異例の構想「AI Control Roadmap」とは

• 

  【徹底入門】AIエージェントで注目の「AX」とは何か　人間だけじゃなく“AI視点の使いやすさ”も重要に？

• 

  最新AI「ミュトス」を使えても「バグマゲドン」に？　Firefox開発元に学ぶセキュリティ対策