AI の同僚と聞くと、多くの人はまず、チームのように働くものだと考えます。役割ごとにエージェントを一人ずつ。エンジニアリング担当、マーケティング担当、ブログ記事だけを書く担当、という具合です。
私たちも最初はそう作りました。Okou ではワークスペースにいくつものエージェントを作成でき、それぞれが独自の名前、アバター、指示、ワークフローを持っていました。8 月には、複数のエージェントがどう仕事を分担し、引き継ぐかを紹介する記事まで公開しています。私たち自身のワークスペースにも、たくさんのエージェントがいました。Lucas はブログ記事を書き、Lisa は経理を担当し、Iris は投資家対応を受け持ち、私には Emily という、メールを仕分けてくれるエージェントがいました。
しかし、ユーザーの直感はあくまで参考にすぎません。Notion が登場する前、ドキュメントツールにはヘッダーとフッターが必要だと、多くの人が直感的に考えていました。
マルチエージェントは、基盤となる機能でもありません。基盤となる機能とは、どの AI プロダクトもいずれ必要になるもの、つまりチャット、スライドやウェブサイトの作成、コンピューターの操作です。複数のエージェントは、そのリストに入っていません。
かつてのブログ担当エージェント、Lucas を例に挙げます。その指示のおよそ 3 分の 1 は、デフォルトの Okou が使っているのと同じ汎用テンプレートです。残りは 3 つの具体的な手順でした。Strapi でブログ記事を公開する方法、自社サイトのユースケースページを書く方法、そして毎日のサインアップ転換率レポートを作る方法です。Lucas に紐づく 13 のワークフローは、すべてワークスペース内で公開されています。Lucas だけのものは、ひとつもありません。
つまり、Lucas とデフォルトの Okou の違いは、名前とアバター、そして本来ワークフローであるべきだった 3 つの手順だけです。その手順は Lucas の中に閉じ込められています。デフォルトの Okou にブログ記事の公開を頼んでも、そうしたルールは何ひとつ持っていません。
エージェントの数が増えるにつれて、組み合わせも増えていきました。多数のエージェント、多数のワークフロー、多数の会話が互いに絡み合い、その組み合わせの一つひとつが、私たちが保守し、ユーザーが覚えなければならないロジックになります。ユーザーの立場から見て、うまく答えられない疑問にもぶつかりました。
- なぜ 2 つのエージェントで同じワークフローを共有できないのか？
- なぜ Slack では Okou としか話せず、自分専用のエージェントとは話せないのか？ Lucas が一人の人なら、どこからでも話しかけられるはずだ。
- なぜメモリーがすべてのエージェントで共有されているのか？ 各エージェントが一人の人なら、それぞれ自分のメモリーを持つべきだ。
どれも解決はできますが、どれにも相応のエンジニアリング作業が必要です。放置すれば、マルチエージェントは中途半端な体験のままです。さらに、複数のエージェントでなければ解決できない課題も、なかなか見つかりませんでした。むしろよく耳にしたのは、管理すべきエージェントが多すぎるという不満でした。
そこで私たちは、一人にひとつの Okou と決めました。モデルはよりシンプルになります。
- 一人ひとりが、デフォルトの Okou をひとつ持つ。
- あなたの Okou はあなたのものであり、プライベートである。
- あなたの Okou と同僚の Okou は、同じエージェントではない。
- あなたの Okou は、組織内の誰かが Public にしたワークフローを、どれでも使える。
これまでエージェントにぶら下がっていたものは、より適した場所に移ります。
- 指示はあなたのものです。一式を書いておけば、Okou はウェブでも Slack でも自動化でも、それに従います。
- ワークフローはワークスペースのものです。同僚が公開した Public のワークフローは誰でも使え、コピーして自分用に作り変えることもできます。
- 連携アカウントはあなたのものなので、どのエージェントにアクセス権を与えるかを選ぶ必要は、もうありません。
- 会話はプロジェクトでまとめ、顧客別、案件別、テーマ別に整理します。
このモデルでは、エージェントは指示のセットとほとんど変わりません。Lucas の中にある 3 つの手順は、誰でも使えるワークフローになるべきです。
マルチエージェントは、実のところ組織内のマネジメント手法、つまり AI にできることを管理するためのやり方です。組織にはそれぞれ独自のマネジメント手法があり、すべてに合う唯一のやり方はありません。単一のエージェントはツールに近く、ツールのほうが理解しやすく、導入もしやすいものです。ユーザーがいちばん必要としているのは、タスクを片づけること。その次が、そのためのツール。いちばん必要としていないのが、やり方の方法論です。
Anthropic の Applied AI チームも、エンタープライズにおけるエージェント導入についての最近の記事で、似たことを指摘しています。複数の導入事例を比較したところ、Skills を備えた単一のエージェントのほうが、専門のサブエージェントに分割した設計よりも品質で上回ることが多く、しかもタスクあたりのコストやレイテンシーも低く抑えられることが多かったといいます。さらに、「チームや問題の種類ごとに専用のサブエージェントを用意し、エージェントのアーキテクチャが組織図の写しになってしまっている企業を、あまりにも頻繁に目にする」とも書いています。この記事が扱っているのはプロダクト設計ではなくエージェントのアーキテクチャですが、その論理はそのまま当てはまります。
現在の AI プロダクトを見渡すと、4 つのモデルがあります。
- 多数のエージェント、多数の会話。これがかつての Okou でした。
- ひとつのエージェント、多数の会話。ChatGPT、Codex、Claude Cowork はこの形です。
- ひとつのエージェント、ひとつの会話。Instinct はこの形です。
- 多数のエージェント、それぞれに会話がひとつ。Grok bot はこの形です。
私たちはもっとも複雑な組み合わせを採っていましたが、それでより多くの課題を解決できたわけではありませんでした。
これが互換性を壊す変更であることは承知しています。もっと早く踏み切れなかった理由は 2 つありました。ひとつの Okou とワークフローという新しい働き方を覚えてもらう必要があること、そして、すでに作ってきたものをどう移行するかの明確な道筋がなかったことです。その道筋は次のとおりです。
- 会話はそのまま残っています。 プロジェクト、検索、元のリンクから見つけられます。
- エージェントを使い分けて会話を整理していた場合は、代わりにプロジェクトを使ってください。 会話をカテゴリーごとにまとめておくことが、多くの人が追加のエージェントを作った主な理由でした。Claude と ChatGPT も、同じニーズをプロジェクトで解決しています。
- エージェントごとに別々の指示を書いていた場合は、 共通する部分を個人の指示に残し、個別の手順をワークフローにしてください。
複数のエージェントの上に抽象化を積み重ねるのは、早くやめるほどいい。Okou を開いたとき、どのエージェントに頼むかを決める必要は、もうありません。やってほしいことを Okou に伝えれば、あとは Okou が引き受けます。
