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

背景と概要

OpenAI Newsは、プロジェクト管理ソフトを手がけるAsanaの導入事例を公開しました。Asanaは、Codexの中でGPT-6シリーズのモデルを使い、自社のブラウザエージェントを作り直しました。テストでは、エージェントの実行コストが76分の1になり、速度は約5倍になったと報告されています。

Asanaは、コストと遅延が下がったことで、顧客により高性能なモデルを提供する余地が生まれたと説明しています。出費を抑えるために機能を絞る必要がなくなる、という考え方です。

ただし、数字の読み方には注意が必要です。これらはテスト環境での結果であり、本番環境にある全顧客のタスクの平均ではありません。原文には、テストセットの規模、タスクの種類、比較対象の詳しい条件も示されていません。76分の1は特定の条件での結果であり、一般的なコスト削減の約束ではありません。

深掘り分析

ブラウザエージェントのコストが76分の1になった理由は何でしょうか。原文は結果を伝えていますが、要因の内訳は公表していません。モデル単価、ステップ数、プロンプト設計のそれぞれがどれだけ効いたのかは不明です。 この数字が重要な理由は、ブラウザエージェントの仕組みを見ると分かります。通常のチャットは、質問に一度答えれば終わります。ブラウザエージェントは違い、次の流れを繰り返します。まず、画面のスクリーンショットや、ページ構造と表示テキストを読み取ります。次に、モデルが次の操作を判断します。そして、クリック、入力、遷移を実行し、新しい画面の状態を読み直します。プロジェクト管理ツールでタスクを作り、担当者を割り当て、項目を埋めるだけでも、数十ステップかかることがあります。

各ステップでモデルを呼び出すうえ、操作履歴が積み上がるため、文脈も長くなっていきます。そのため、コストと待ち時間は段階ごとに積み重なります。1ステップが少し遅ければタスク全体が大きく遅れ、少し高ければタスク全体が大きく高くなります。この種の製品の採算は、1ステップあたりの性能に敏感です。 76分の1という幅は、単価の低下だけでは説明しにくいでしょう。以下は一般的な仕組みからの推測で、原文の記述ではありません。各ステップの判断が正確になって遠回りや再試行が減り、必要なステップ数が減り、1ステップの推論も速く安くなり、プロンプトや文脈も整理された、という複数の要因が重なった可能性があります。 もう一つの注目点は、Asanaが作業をCodexの中で行ったことです。コーディングエージェントで自社のエージェントの流れを組み直し、テストし、改良したことを示唆します。ただし、具体的な作業手順は原文に書かれていません。

業界への影響

この事例は、企業向けソフトの大きな課題に触れています。エージェント機能はデモでは見栄えがしますが、規模を広げるのが難しいのです。試作では良好でも、全顧客に開放すると、1回あたりのコストと待ち時間のせいで、無料提供も価格設定も難しくなります。 Asanaのような業務管理プラットフォームは、顧客数が多く、操作も頻繁です。タスクごとに高価で遅ければ、提供側は利用回数に上限を設けるか、能力の低い小型モデルに戻すしかありません。コストが許容範囲まで下がれば、より強いモデルを標準にでき、使い勝手も機能の幅も広がります。

モデル提供側にとっても意味があります。OpenAIにとって、新世代モデルの価値はベンチマークの点数だけではない、という説得材料になります。エージェントを採算に合う形で動かせることが価値だ、という主張です。企業顧客を競う場面で効く訴求といえます。 同じ分野のタスクボードやワークフローのツールには、圧力がかかります。競合のエージェントが速くて安ければ、繰り返し作業をより多く自動化でき、手作業でクリックする画面への顧客の我慢は小さくなるでしょう。ブラウザ自動化やRPAの既存ベンダーにとっても、スクリプトやルールに基づく方式が、ページ変更に適応するモデル駆動の方式と競う時代の合図です。利用者にとっては待ち時間の短縮と機能の増加が利点ですが、エージェントが代行できる操作が増えるほど、権限管理、操作の監査、誤操作の取り消しが重要になります。

今後の展望

見るべき点は幾つかあります。第一に、Asanaがこの方式を全顧客に広げるか、本番データを公表するかです。タスク成功率、平均ステップ数、タスクあたりのコスト、ユーザーの継続率のほうが、単一の倍率よりも実態を語ります。 第二に、他の企業向けソフト会社が似た成果を報告するかです。複数社が桁違いのコスト低下を示せば、モデル世代の変化による共通の効果といえます。Asanaだけなら、自社の最適化の成果という見方が強まります。 第三に、価格の付け方が変わるかです。コストが下がった後も、エージェントを追加の有料機能として残すのか、基本プランに含めるのかで、各社がこの能力をどう位置づけているかが分かります。 第四に、安くなっても信頼性の問題は消えません。ログイン認証、ページの改修、ポップアップなどでブラウザエージェントが失敗する可能性は残ります。呼び出しが安くなると、再試行を重ねて成功率を買う誘惑も生まれるため、総コストの計算は続ける必要があります。

最後に、コーディングエージェントと業務エージェントの相互作用です。Codexで業務エージェントを作り、調整することで、改良のコストが下がる可能性があります。この流れが成り立てば、企業向けソフトの更新ペースは速まるかもしれません。現時点で、76分の1と5倍はテスト結果であり、より広い検証が待たれます。