Asana、GPT-6.1 Solでブラウザエージェントのコストを76分の1に

背景と概要

OpenAIが公開した顧客事例によると、プロジェクト管理ソフトを手がけるAsanaは、Codex上でGPT-6系列のモデルを使い、自社のブラウザエージェントを作り直しました。テストでは、エージェントの実行コストが76分の1になり、処理速度は5倍に向上しています。Asanaは、コストと遅延が大きく下がったことで、タスクごとの請求額が膨らむ心配をせずに、より高性能なモデルを顧客へ提供できると説明しています。

ただし、前提には注意が必要です。これらの数字はテスト環境での結果であり、本番環境全体の公開統計ではありません。対象としたタスクの内容、比較の基準、課金の算出方法について、原文は詳しく述べていません。76分の1という数字は、あらゆるブラウザエージェントに当てはまる係数ではなく、方向性を示す目安として読むのが妥当です。

ブラウザエージェントの運用費が高くなりやすいのはなぜでしょうか。このエージェントは、クリック、入力、スクロール、ページの読み取りを繰り返します。各ステップでページの状態をモデルに渡し、モデルが次の動作を決めます。ページの状態は文書構造やスクリーンショットで、どちらもデータ量が大きくなります。1つのタスクが数十ステップに及ぶことも多く、入力される文脈は積み上がっていきます。そのため費用は直線的ではなく、ステップ数に応じて増幅されます。

深掘り分析

この設計には、無駄が生まれやすい場面が3つあります。1つ目は、各ステップで無関係なページ内容を大量に再送してしまうことです。2つ目は、近道がある場面でもモデルが試行錯誤を繰り返すことです。3つ目は、異常時の復旧の仕組みがなく、最初からやり直すしかないことです。 76分の1という削減幅を、単一の要因で説明するのは難しいといえます。原文は内訳を示していないため、ここからは推論ですが、複数の改善が重なったと見るのが自然です。ページをより正確に理解できるモデルなら、最初から正しい動作を選べるので、ステップ数が減ります。1回の呼び出し単価が下がった可能性もあります。さらに、文脈の絞り込みやキャッシュといった工程面の工夫が加われば、毎ステップの入力量は小さくなります。

Codexの役割は、エンジニアリングチームが実行ロジック、テストスクリプト、評価の流れを素早く書き換え、改善を回せるようにした点にあります。モデルの更新とコードの工程化という2本の取り組みが並行して進んだからこそ、この規模の改善が出た可能性があります。 5倍の高速化にも同じ二重の意味があります。ステップ数が減り、1ステップあたりの推論も速くなれば、利用者の待ち時間は短くなります。待ち時間は、エージェントがデモの段階から日常利用へ進めるかどうかを左右する体験指標です。 Asanaはブラウザエージェントのコストを76分の1にどう抑えたのでしょうか。原文によれば、AsanaはCodexでGPT-6系列のモデルを使ってエージェントを再構築し、テストでコスト76分の1、速度5倍を確認しました。ただし、モデルの寄与とエンジニアリング変更の寄与がそれぞれどれだけかは、示されていません。

業界への影響

この事例は、企業がエージェントを導入する際の最も現実的な壁である、単位あたりの採算性に関わっています。試作段階では良好でも、規模を広げるとタスク1件のコストが代替する人件費を上回り、計画が止まる例は少なくありません。コストが数十分の1になれば、同じ予算で数十倍のタスクをこなせます。あるいは、その分をより強力なモデルに充てることもできます。Asanaが言う「より高性能なモデルを顧客に提供できる」とは、こうした意味です。

Asanaのような協働ソフトの事業者にとって、エージェントは採算ぎりぎりの追加機能ではなく、標準機能になり得ます。タスクの整理、システム間のデータ入力、ステータス同期といった日常業務に組み込めるからです。競合への圧力も明らかです。Notion、Atlassian、Monday.comも同様にエージェントをワークフローへ組み込んでおり、1タスクあたりのコストを先に下げた企業が、価格設定と機能の範囲で優位に立ちます。

モデル提供側のOpenAIにとっても、この事例は分かりやすい訴求です。ベンチマークの点数ではなく、実業務でのコストと速度を顧客に語らせています。これは、Codexを実装の入り口として売り込む方針とも一致します。一方で、独立系のブラウザ自動化スタートアップやオープンソースの選択肢は、比較の圧力が強まります。大手のモデルと開発環境の組み合わせがコスト曲線を下げ続ければ、モデル呼び出しを包むだけの製品は、守りの堀が薄くなります。

今後の展望

注目点は4つあります。1つ目は、Asanaがより詳しい評価方法を公開するかどうかです。タスクの成功率、失敗後の復旧、サイトやページの複雑さごとの結果が含まれるべきです。コスト削減は品質が保たれて初めて意味を持ちます。成功率なしにコストと速度だけを見ても、結論は不完全です。 2つ目は、削減分が顧客に届くかどうかです。価格の引き下げ、利用上限の拡大、より強力なモデルの選択肢といった形で現れるかが焦点です。節約が利用者側に伝わらなければ、この事例の業界的な意味は小さくなります。 3つ目は、他社が同規模の数字を示すかどうかです。複数の企業が異なる場面で数十分の1の削減を再現できれば、改善の源はモデルとツールチェーン全体の進歩だと分かります。個別の事例にとどまるなら、特定タスクに合わせた最適化の可能性が高くなります。

4つ目は、安全と権限の問題です。コストが下がっても、この問題は消えません。ブラウザエージェントは利用者に代わって実際のシステムを操作できるため、利用が広がるほど、誤操作、不正アクセス、プロンプトインジェクションのリスクも大きくなります。企業は、監査、確認、巻き戻しの仕組みを同じ速度で整える必要があります。 全体として、この事例はエージェント競争の重心が動いていることを示しています。問われるのは、誰のモデルが賢いかから、誰が低いコストと短い時間で現実のタスクを安定してこなせるかへ移りつつあります。今後1〜2四半期のうちに、より多くの企業が自社の数字を出せば、比較がはっきりしてくるでしょう。