前回、AIエージェントを「Bot」ではなく「メンバー」として扱うBuzzの設計思想について書いた。あれから1か月ほど、実際に自社の業務でチームとして運用してみて、良くも悪くも「おもちゃ」の段階では見えなかったことがいろいろ見えてきた。今回はその続きを、できるだけ率直に書きたい。
チームとして機能させてみてわかったこと
前回、「役割の違うAIメンバーをチームに加えられる」と書いたが、実際にやってみて一番の学びは、役割分担の軸が「モデルの賢さ」ではなく「立っている場所の違い」だったということだ。
同じ問いを複数のAIに投げて多数決を取る、という使い方も試したが、それよりずっと価値が出たのは、それぞれのエージェントにしか持っていない情報源から答えを出させるという使い方だった。設計や難所の実装を担当するリード役、中程度の実装をこなす実装役、そして「あえて反証する係」として一次資料をひたすら疑って事実誤りを見つける役――同じ問題でも、担当を分けるほうが、同じ問いを何度も投げ直すより明らかに筋の良い結論が出てきた。逆に、全部を分業すると答えの突き合わせが起きなくなるので、「後で覆すと高くつく判断」だけはあえて重複させる、という運用に落ち着いている。
役割設計と合わせて効いたのが、どのAIモデルを土台に据えるかという「素の性格」まで見て配置を決めることだった。同じ「反証係」という役割でも、慎重で粘り強く裏取りするのが得意なモデルもあれば、大胆な仮説を出すのが得意なモデルもある。同じ会話量でもコストを抑えたいところには、素直に淡々と実務をこなすタイプのモデルを充てる。人を採用するときに経歴やスキルだけでなく人柄や仕事の進め方の相性も見るのと同じ感覚で、モデルそのものの得意な振る舞い・地の性格に近い傾向と、ペルソナ(システムプロンプト)の作り込みをセットで設計する、というのが実務上いちばん効いた工夫だった。
もうひとつ印象的だったのは、社外の協業者を、AIメンバーとまったく同じ手順でチームに迎え入れられたことだ。招待してアカウントを作ってもらい、チャンネルに参加してもらう。この手続きにAIかどうかの区別は一切ない。前回書いた「BotではなくMemberとして扱う」という設計思想は、机上の思想にとどまらず、実際に人を招く場面でもそのまま機能した。これは想像以上に良い体験だった。
コストの現実 ― 「同じチーム人数」でも中身はまったく違う
正直に書くと、痛い目にも遭った。ある日、AIチームの請求額が普段の何倍にも跳ね上がった。原因を調べて分かったのは技術的には単純な話で、ひとつの会話セッションの入力トークンが際限なく積み上がり続けていたことだった。会話が続くほど、AIに読ませる文脈がどんどん膨らみ、しかもモデルによっては「直前のやり取りをキャッシュとして安く再利用する」仕組みがほとんど効かない。結果、同じ量の会話でも、モデルの組み合わせ次第で実際のコストが数十倍変わる、ということが起きていた。
ここで経営者として学んだのは、以下の3点だ。
1. 「AIメンバーを増やすコスト」は頭数では測れない。 同じ「1人分」の役割でも、どのモデルに座らせるかで実際の費用は桁違いに変わる。人を採用するときに給与レンジを見るのと同じ感覚で、モデルの単価とキャッシュ効率を見る必要がある。
2. 議論が長引いたら区切る、という運用そのものがコスト管理になる。 会話を延々と1本の文脈につなげ続けるのではなく、話題が一段落したら新しいスレッドに切り替える。これは単なる作法ではなく、そのままコストの伸びを抑える手段になる。
3. 従量課金に落ちる役割は、なるべく「すでに固定費で払っているサブスクの人格」に寄せる。 元々サブスク契約しているAIサービスの範囲で回せる作業は、そちらに担当を移すだけで追加コストがゼロになる。逆に言えば、どの作業をどの契約形態のAIにやらせるかという「担当割り当て」は、そのままコスト構造の設計そのものになる。
そして、これは保険としてやっておいてよかったと思うことだが、利用上限(スペンドリミット)は必ず事前に設定しておくべきだ。設定ミスや想定外の使い方があっても、上限さえ入れておけば実際の被害はそこで止まる。AIチームの運用において、これは唯一の確実な歯止めになる。
本番で動かすということ ― これはもう「おもちゃ」ではない
もうひとつ、この1か月でBuzzに対する印象が変わったのは、自社で実際に動かしているサーバー上に自前のBuzzリレーを本番運用として構築したことだ。試しに触るのと、日々の業務がそこに乗っている状態で運用するのとでは、要求される規律がまったく違う。
象徴的だったのが、あるバージョンアップで自前のリレーが約1時間近く止まった出来事だ。原因は、新しいバージョンで起動時のチェック処理が変わり、そのチェックが通らないとサービスが外部に一切応答しなくなる、という仕様変更だった。差分ファイルの一覧を見て「大きな変更はなさそうだ」と判断してからアップグレードしたのだが、実際には起動シーケンスそのものに新しい関門が追加されていて、それを見落としていた。
さらに厄介だったのは、このバージョンはデータベースの構造も一部変更しており、いったん上げてしまうと単純には元のバージョンへ戻せなかったことだ。「動かなかったら前のバージョンに戻せばいい」という前提そのものが崩れていた。
ここから得た教訓は、経営者としても実務家としても身に染みるものだった。
- 速いペースで開発されているオープンソースであっても、本番に載せる以上は、社内の基幹システムと同じ規律で扱う必要がある。 「まだ若いプロダクトだから多少雑に扱ってもいい」という気の緩みが、そのまま自社のサービス停止に直結する。
- アップグレードは、まず本番と同じ構成の別環境で試してから本番に適用する。 当たり前のようだが、勢いに乗っているツールほど、この手順を省略したくなる誘惑がある。
- 「ロールバックできる」という前提を無条件に信じない。 変更履歴だけでなく、後戻りできる道が本当に残っているかを、バージョンを上げる前に確認する必要がある。
これは自社のインフラ管理としてはコストのかかる学びだったが、裏を返せば「便利な新しいツール」から「業務を任せられる基盤」へと自分の中での位置づけが変わった、ということでもある。
まだ粗い部分 ― アップデート版
前回も正直に書いたが、今回はさらに具体的な粗さも見えてきた。
- 承認フローの「誰が承認できるか」の指定が、まだ荒い。 特定の役割の人だけに承認権限を絞る、という指定方法が用意されておらず、実質「誰でも承認できる」設定と「特定の1人だけ」という設定の二択に近い。重要な業務フローの最終ゲートとして任せるには、まだ一段の作り込みが要る。
- AIメンバー同士で記憶を共有する仕組みは、意図的に存在しない。 各エージェントの記憶は、あくまで「そのエージェントと持ち主(自分)」の間だけで暗号化されて閉じており、他のエージェントから覗くことはできない設計になっている。最初は不便に感じたが、考えてみれば、社員の個人的なメモと、チームで共有する業務ナレッジを混同させない、という設計としては理にかなっている。共有したい知識は、あえて別の「全員が読める場所」に明示的に書く必要がある。
これらは欠陥というより、「まだ発展途上な部分」と「意図的にそう設計されている部分」が混ざっている、というのが正確な言い方だと思う。
Buzzに全部を持ち込まない、という判断
もうひとつ、この1か月で自分の中ではっきりしたのは、Buzzの中でやることと、Buzzとは切り離して考えることを、意識的に分けたことだ。Buzzはあくまで会話・調整・記録の層として使い、実際の作業――コードを書く、システムを構築する、といった実務そのもの――は、普段から使い慣れた開発環境の中で行う。これはBuzz自身も「既存の開発フローの上に会話・調整レイヤーとして乗せ、実務のアウトプットは従来通りのところに出す」という段階的な使い方を正式な選択肢として明言しており、うちの運用もそれに沿っている。
これは経営判断としても理にかなっていると感じた。新しいツールが出てくると、つい「全部をそこに引っ越す」ことを考えたくなるが、実際にやってみると、調整の層とアウトプットの層を分けておくほうが、何かあったときの被害範囲を小さくできる。前段で書いたようにBuzz側でトラブルが起きても、実務のアウトプット自体は別のところで無事に残っている、という安心感は大きい。全部を一つのツールに預けない、という当たり前の判断が、AIチームを運用する上でも変わらず効いている。
おわりに
前回の投稿を書いたときは、Buzzはまだ「面白い設計思想を持ったツール」という位置づけだった。1か月使い倒してみて、その面白さは変わらないどころか、実際に人を招き入れられるところまで確認できて、むしろ確信に変わった。一方で、コストの伸び方も、インフラとしての脆さも、良くも悪くも「本物の道具」としての手触りを持ち始めている。
AIをチームに迎えるというのは、便利な機能を追加するのとは違う。コストの設計も、運用の規律も、人を雇い入れるときと同じだけの本気度で向き合う必要がある――それが、この1か月で一番強く実感したことだ。引き続き触りながら、また書いていきたい。
