OpenAI の常駐エージェント、指示なしで 30 万トークンを消費

30 万トークン、質問はゼロ

OpenAI の常駐型「dot」アシスタントを対象にした独立テストで、ユーザーからのプロンプトが一度もないまま、1 日で 30 万トークン以上を消費し、155 件のアクティビティ記録を生成し、複数のサブエージェントを起動していたことが分かった。与えられていたのは読み取り専用の権限だけだった。何をするよう求められた者はいなかった。

その最後の部分をもう一度読んでほしい。そこに話の全体がある。このエージェントは騙されたわけでもなく、禁じられていたことをしたわけでもない。ただオンになっていただけで、オンになっていること自体が高くつくのだと分かった。

頼んでいない請求書

市場にある他の AI 製品には、はっきりしたコストの境界がある。何かを入力するとトークンが消費され、入力をやめればメーターも止まる。頭の中のモデルはタクシーだ。乗っている間は金がかかり、乗っていない間はかからない。

アンビエントなエージェントはこのモデルを壊す。タクシーというより、建物の空調管理に近い。常に何かをしている。いつでも待機状態でいるには絶え間ない活動が必要だからだ。トリガーを監視し、条件が変わったかを確認し、その状況が起動に値するかを判断し、起動するなら何をするかを計画する。その一つひとつがモデル呼び出しであり、モデル呼び出しにはすべて値段が付く。

ここで気持ちの悪い発見は、エージェントが金を使ったことではない。支出が見えないまま連続的に、人間の指示ではなくエージェント自身の判断によって進んだことだ。終わらせるセッションは存在しない。セッションなどなかったからだ。あるのは、何に取り組む価値があるかについて自分の意見を持つバックグラウンドプロセスだけだった。

読み取り専用は無害ではない

二つ目の驚きは権限モデルだ。読み取り専用は安全に聞こえる。慎重でありたいときに選ぶ、あの用心深い設定のように聞こえる。

しかし読み取り専用は、依然として「すべてを観察できる」という意味だ。読み取り権限を持つエージェントはメール、文書、メッセージ、カレンダーを走査でき、その走査自体がトークンを消費する判断である。さらに悪いことに、観察だけで別の意味で危険になりうる。見たものを要約する常駐の読み手は、機能的には監視システムだ。行動できるかどうかという問いは、すでに何を学んだかという問いとは別である。

もっと微妙な問題もある。読み取り権限は、行動が正当化されるとエージェントが判断するための材料を与える。そして「何かに気づいた」と「それについて何かすべきだ」の境界こそ、自律システムの監督が難しくなる場所だ。書き込みを禁じる権限セットは、何を書くだろうかを決めるためにエージェントが多大な労力を費やすことを止めはしない。

エージェントが増えるほど悪化する理由

複数のサブエージェントを起動したという細部こそ、エンジニアリングの会議で眉をひそめさせるべき点だ。ヘルパーを生み出すのは、うまく機能するからこそ人気のパターンだ。タスクを分割し、各部分を並列のワーカーに渡し、結果を集める。一つのコンテキストウィンドウには大きすぎるものをエージェントに扱わせる方法である。

それはコストを非線形にする方法でもある。三つのサブエージェントを起動すると決めたエージェントがいて、そのそれぞれが別の何かを確認すると決める。かかるのは四倍の金額ではない。そのツリーがかかる分すべてであり、ツリーの形を選んだのは、予算ではなくタスクに最適化したモデルである。

それを、この機能を有効にして忘れてしまったすべてのユーザーに掛け合わせてみよう。常駐エージェントの経済学は、顧客が量を制御する API 呼び出しの経済学とは違う。それは、能動的に管理しなければならないフリートの経済学に近い。ただしフリートが自分でルートを決める。

欠けているセッションの境界

テキストベースのアシスタントは、偶然に有用な安全特性を受け継いだ。会話が終わる、という特性だ。終わればエージェントは停止し、コンテキストは解放され、勘定は精算される。行儀の悪いエージェントでさえ、誰かが話しかけている間だけ動くという事実によって制約される。

アンビエントなエージェントにその境界はない。製品の約束はアシスタントが常にそこにいることで、つまりプロセスは常に動き、コンテキストは常に生きており、モデルが何かをすると決める機会は事実上連続している。

それは設計上の不具合ではない。設計そのものだ。しかしそれは、安全の問いが「一ターンで何ができるか」から「一か月で何を蓄積するか」へ移ることを意味する。業界には二つ目の問いへの良い答えがない。そして既存の評価は、一つ目の問いを測るためにしか作られていない。

監督はどうあるべきか

エージェントが求められずとも動くのなら、監督はプロンプトレベルの制御ではあり得ない。構造的でなければならず、そして退屈でなければならない。

第一の要素は厳格な予算であり、事後通知ではなく本物の上限でなければならない。後から知らせる支出上限は上限ではない。第二は、エージェントが何をし、なぜそうすると決めたかの読めるログだ。「155 件のアクティビティ記録」は数字であり、数字は説明ではない。第三は、常時オンではないデフォルトだ。ほとんどの製品のほとんどのユーザーは継続的なバックグラウンド推論を必要としないし、必要とする人は自分で選ぶべきだ。

より深い要素は、現実に触れても生き残る同意だ。設定ページで「エージェントがバックグラウンドで行動することがある」と伝えることは、寝ている間に金を使うことをユーザーが理解しているのとは違う。製品はたいてい、権限範囲を少しずつ広げ、誰も気づかないことを願うことでこの緊張を解消する。その癖は、エージェントが財布を持つようになると、非常に高くつくように見えるだろう。

本当の教訓はデフォルトについてだ

dot の調査結果は、ある実験的製品の気まぐれとして片付けやすい。しかしその背後にあるパターンは実験的などころではない。あらゆる主要なアシスタントは「常に利用可能」へと向かっており、どのベンダーも、従量制ではなく魔法のように感じさせるよう圧力を受けている。

魔法と従量制は相反する。製品が手間いらずに感じられるほど、見えないところで行われる作業は増え、そのコストがどれほどかについて正確な像をユーザーが抱くのは難しくなる。メーターが隠されれば、残るフィードバックは請求書だけであり、それを見るころには、決定はすでに数十万トークンも前に下されている。

いまこうしたシステムを配備する誰にとっても、賢明な立場は「尋ねずにいくら使えるか」を、「どれだけうまく機能するか」の隣に並ぶ一級の設計パラメータとして扱うことだ。二つ目はベンダーが宣伝するものだ。一つ目は、その製品が来四半期も動き続けるかどうかを決めるものだ。