Asana、GPT-6.1 Solでブラウザエージェント費用を76分の1に
AsanaはCodexでGPT-6 Astraを活用し、テストでブラウザエージェントのコストを76分の1に、速度を5倍に改善しました。これにより、顧客へより高性能なモデルを提供できます。
背景と概要
プロジェクト管理ソフトを手がけるAsanaが、自社のブラウザエージェントをCodex上のGPT-6.1 Solで作り直しました。OpenAIが2026年10月9日に公開した顧客事例によると、テストでは運用コストが76分の1になり、速度は5倍になりました。Asanaは、この改善によって1回の呼び出しごとに高い費用を払わなくても、顧客により高性能なモデルを提供できる余地が生まれたと説明しています。
ただし、公開されている情報はテスト環境での結果です。使われたタスクの集合、比較対象のベースラインモデル、費用の計算方法は、概要の中では示されていません。76倍と5倍という数字は、規模感を知る手がかりとして読むのが適切です。他社が自分たちの業務でそのまま再現できる約束ではありません。
ブラウザエージェントは、構造上どうしても費用がかさみます。ページの構造やスクリーンショットを読み取り、クリックや入力の次の一手を決め、新しい画面の状態を読み直す。この循環をタスクが終わるまで繰り返します。1件の作業で十数手から数十手に及ぶことも珍しくありません。しかも毎回、ページの内容と履歴をモデルに送り直すため、入力トークンが積み上がり、遅延も少しずつ膨らみます。
深掘り分析
コストと速度は同じ問題の表と裏です。手数が増え、文脈が長くなるほど、費用は上がり、ユーザーの待ち時間も延びます。費用を2桁近く下げるには、安いモデルに差し替えるだけでは足りないことが多く、複数の要因が重なったと見るのが自然です。 モデル側では、同じ作業をより少ない手数で終えられるようになった可能性があります。ページ情報の読み取りが正確になり、失敗後の再試行が減ったことも考えられます。エンジニアリング側では、モデルに渡すページ内容を絞り込む、キャッシュした文脈を再利用する、確定的なコードで済む処理をモデル呼び出しから切り出す、といった見直しが効いたかもしれません。
この事例には見落としやすい点もあります。Asanaはこの作業をコーディングエージェントのCodexで進めました。AIの製品を動かす効率を、AIの開発ツールで改善したことになります。最終製品の中のモデルだけでなく、作り直しの工程にもエージェントが関わったと読めます。 一方で、76倍のうちモデルの寄与とエンジニアリングの寄与がどれだけかは、公開情報から分かりません。この内訳は重要です。大半が工学的な改善なら、他社も有能なモデルで追いかけられます。大半がモデルの性能なら、特定の供給元への依存が強まります。追加のデータが出るまでは、慎重な姿勢が妥当です。
業界への影響
この事例は、エージェント製品が抱える最も現実的な矛盾に触れています。企業向けソフトの提供側は、エージェントを製品機能にしたいと考えています。しかし呼び出しごとに課金されるモデル費用は、利用が広がると魅力的な機能を赤字の原因に変えかねません。1タスクあたりの費用が数十分の1まで下がれば、いくつかのことが同時に変わります。 第一に、高額プランに閉じ込めず、より多くのユーザーに標準で開放できます。第二に、節約した予算を重要なタスクの強いモデルに回し、成功率を買えます。Asanaが言う、より高性能なモデルを顧客に提供できるとは、この意味です。第三に、速度が5倍になると操作感が変わります。数秒で終わる操作は日常の作業の流れに組み込めますが、数分かかる操作はバックグラウンド処理にしかなりません。 Asanaのような業務管理基盤にとって、ブラウザエージェントの価値は、システムをまたぐ反復作業の代行にあります。タスクの整理、ステータスの同期、公開APIを持たないウェブツール間での情報の転記などです。こうした場面は、遅延にも1回あたりの費用にも敏感です。 市場全体への影響は三つの層で考えられます。モデル供給元にとっては、顧客事例がベンチマークの点数ではなく、タスクごとの実費と所要時間を示す場になりました。競争の軸は、最強のモデルから、価格に見合う実用的なモデルへ移りつつあります。Notion、Atlassian、Salesforceなど、同じくエージェント機能を進める企業にとっては、費用が大きく下げられると示された以上、推論コストの高さを価格の言い訳にしにくくなります。機能の標準化が早まり、差は、データ、権限、ワークフローへの統合の深さに移るでしょう。
独立系のブラウザエージェント企業への圧力はさらに強まります。大手の基盤が低コストでエージェントを動かし、しかも利用者の業務データを最初から持っているからです。汎用の自動化ツールは、信頼性、対応範囲、特定分野での強みを、より明確に示す必要があります。
今後の展望
今後は、いくつかの点を見ておく必要があります。まず情報の開示です。AsanaまたはOpenAIが、タスクの成功率、サンプル数、旧方式との比較条件、そしてモデルとエンジニアリングそれぞれの寄与を明らかにすれば、この事例の評価と再現のしやすさが大きく変わります。 次に価格です。削減分が顧客向けのプランに反映され、エージェント機能がより多くのユーザーに開かれれば、節約は製品戦略になったと言えます。社内の利益率の改善にとどまるなら、市場への波及は小さくなります。 三つ目は信頼性です。費用が下がっても、既存のリスクは消えません。サイトのレイアウト変更、ログイン認証、権限の境界、誤操作による被害は残ります。企業の顧客は最終的に、安定性と監査のしやすさでこの種の機能を評価するでしょう。
四つ目は他のモデル企業の反応です。競合が自社のコストと速度のデータで応じれば、1タスクあたりの費用を軸にした競争が一気に進む可能性があります。 この事例の価値は、二つの倍率そのものにはありません。示しているのは方向です。エージェントが実演の段階を超え、毎日使われる基本機能になるには、運用費用が十分に下がる必要があります。Asanaのテストはその道筋の早い時点のデータにすぎず、より広い裏付けがこれから求められます。
Sources
FAQ
AsanaはGPT-6.1 Solでブラウザエージェントをどう改善しましたか?
AsanaはCodexでGPT-6.1 Solを使いブラウザエージェントを改修し、テストで費用を76分の1、速度を5倍に改善しました。OpenAIが2026年10月9日に事例として公開しました。
ブラウザエージェントの費用が76分の1になるとなぜ重要なのですか?
費用と速度が改善すると、より多くの利用者に機能を開放でき、重要な作業で高性能モデルを選べます。5倍の高速化で日常業務への組み込みも現実的になります。
この76倍という結果は他の現場でも期待でき、今後何に注目すべきですか?
76倍はテスト環境の数値で、タスク内容や比較対象は未公開です。成功率などの詳細データ、顧客向け価格への反映、ウェブ変更時の信頼性を注視してください。