個人のbotが増えても、組織AIにはならない〜秘書botだけではなく、チームのbotへ〜

少なくとも、見えるようになった

dotsもGrok botも、自分で使っていて、どちらも良くできていると思う。SlackのチャンネルでAIに頼むと、誰が何を頼んで、AIが何を返したかが、チャンネルにいる全員に見える。AIが一人の画面の中にいた頃と比べると、少なくとも、見える。これは確かに進歩だと思う。

マルチプレイヤーAIが何かは「AIを一人の画面から、チームのテーブルへ」に書いた。Own What AI Saysでは、見えるようになったことで、人がAIの中継役になっている場面が目に入るようになった、という話を書いた。今回は、Slackでもう一つ気になってきたことの話だ。

秘書botをスレッドに持ち込むと、読めなくなる

dotsのような、何でもこなすパーソナルAIエージェントを、個人秘書のように使うのは、それ自体はとても便利だし、否定したいわけでもなく、どんどん使いたい。ただ気になっているのは、それを共有のワークスペース、たとえばSlackのスレッドに持ち込んだときのことだ。

Slackに各自がdotsを入れて、それぞれが「サマリーして」「これのたたきを作って」とスレッドでやりとりを続けているのを見ていると、新手のAIスロップに見えてくる。

dotsのbotが一つのスレッドに複数入った瞬間に、どれも返事が長くなりがちで、スレッドを追えなくなる。

見えると、スロップも全員に届く

AIが一人の画面の中にいた頃は、長い返事を読むのは、頼んだ本人だけだった。チャンネルに出てくると、その長い返事を、スレッドにいる全員が目にすることになる。

見えるようになったのは進歩だと、今でも思う。ただ、見えるようになっただけでは、見えているものの質までは良くならない。むしろ、各自が秘書botをスレッドに持ち込むほど、スロップを目にする人も増えていく。

それに、秘書botをスレッドで使っても、やっていることは、各自の一人用のセッションを、スレッドに並べているのに近い。頼んだ人以外は、そのセッションに入れないし、そのbotを直すこともできない。

共有には、見える・触れる・育てるがある

そう考えると、AIをチームで共有すると言っても、段階がある気がしてくる。

一段目の「見える」は、いまのSlackのbotで、もうできている。二段目の「触れる」は、前回のnoteで書いたマルチプレイヤーAIの定義に近い。AIのセッションやコンテキストに複数の人がアクセスできて、共同で編集できてこそ、マルチプレイヤーAIであり、組織AIだと思う。そこに届いていない限り、どこまでいってもcopilotの延長線上にいる。dotsは、設定次第でセッションを共有できるとも聞いた。

三段目の「育てる」は、botそのものをみんなで直していけるかどうかだ。秘書botは本人の仕事を助けるためのものなので、チームでの共有という意味では、何台並んでも一段目にとどまる。

みんなでメンテする、役割のbot

なので最近は、秘書botはそれぞれの手元で使いつつ、チームで共有する仕事については、役割ごとのエージェントがいて、それをチームのみんなでメンテしている方が、組織AIとしては良いのではないか、と考えるようになった。秘書botか役割のbotか、の二択ではなく、使いどころの違いだと思っている。

自分も、cpto室長と名付けたbotを、プロダクト領域のbotとして運用していて、プロダクトまわりのことは、意識してこのbotに集めるようにしている。誰かの秘書に聞くのではなく、その役割のbotに聞く、という形だ。

手本は、もう身近にある。GitHubとPRだ。誰でも差分を見られて、コメントできて、必要なら自分でコミットを足せる。そして、どれが正なのか（SSoT）がはっきりしている。役割のbotの指示や知識も、コードのようにみんなで直せて、どれが正かが分かる場所にあれば、三段目の「育てる」までいけるのではないかと思う。

上限は、人と人のあいだで来る

AIで作る量はどんどん増えていく。一方で、人と人の調整、承認、レビューは人のままで、ここがこれからの最大のボトルネックになると思っている。

セッションが一人用のままだと、このボトルネックに手を打ちにくい。たとえばレビューでは、レビュワーが指摘を書いて作成者に返し、作成者がそれをAIに投げて、直ったものを持ち帰る。作成者が間に挟まるのは、セッションに入れるのが作成者だけだからだ。

もしセッションやコンテキスト、成果物がマルチプレイヤーになっていれば、レビューする代わりに、レビュワーがAIに指示して修正までできる。作成者が間に入って中継する必要がない。

うちでは最近、みんながAIでHTMLばかり生成している。そのHTMLを引き継いで仕事を進めようとすると、少なくとも「触れる」まではマルチプレイヤーになっていないと、人がレビュワーとAIのあいだをプロキシすることになる。HTMLを一度もらって、手元で直して、また返す。そういう作業が増えている。そういう意味で、マルチプレイヤーAIの大事さを、最近よりひしひしと感じている。

逆に、セッションが一人用のままだと、AIで速くなるのは一人ひとりの手元だけで、人と人のあいだの受け渡しは減らない。そうなると、チームとして伸ばせるのは、一人で完結する仕事の量だけになる。誰とも調整せずに済むくらい、一人で100倍の生産性を出せるのでなければ、上限は早く来る。

AIエージェントが仕事をどんどん生み出し、人は確かめて責任を持つ側に回る。そういうソフトウェアファクトリーのような仕組みが、規模を広げても回り、誰が何に責任を持つかもはっきりしている。そこを目指すなら、一人用のセッションを並べているうちは、まだその手前にいるのだと思う。

Harness is the company

自分の今の関心は、パーソナルAIエージェントより、チームの複数人から使えるAIチームメイトの方に移ってきた。マルチプレイヤーAIや、組織AIと呼ばれるものだ。

理由は、Harness is the companyを実践したいからだ。これはShrivu Shankarの同名のエッセイのタイトルで、ハーネスは「ステートレスな（会話の状態を自分では持たない）LLMを取り囲む、インフラ、インターフェース、コンテキスト、状態のすべて」と定義されている。そのうえで、人間もハーネスの一部だと書いている。

そう考えると、セッションもコンテキストも、botそのものも、一人ひとりの手元に閉じている限り、ハーネスは会社のものにならないのではないか。秘書botが増えるだけでは、会社のハーネスは育たない。

AWSは、必要になったらその場でサーバーを足せる。組織AI、マルチプレイヤーAIの先にあるのも、こういう姿なのではないかと思っている。必要なときに、すぐ規模を広げられる。SlackにAIが並んで見えるようになったのは、その手前の一歩だと思う。