Asana、GPT-6.1 Solでブラウザエージェントを76倍低コスト化

Published · AI Daily — AI-assisted deep research, methodology & disclosure

AsanaはCodexを活用し、テストでブラウザエージェントのコストを76分の1、速度を5倍に改善しました。これにより、顧客により高性能なモデルを提供できるようになります。

背景と概要

2026年10月9日、OpenAIは業務管理ソフトを手がけるAsanaの導入事例を公開しました。事例によると、AsanaはCodexを使い、自社のブラウザエージェントの実行コストをテストで76分の1に、速度を5倍に改善したということです。事例ではGPT-6.1 Solというモデル名も挙げられています。OpenAIの説明では、コストと遅延が下がったことで、Asanaは出費を抑えるために性能の低いモデルへ戻る必要がなくなり、より高性能なモデルを顧客に提供できるようになりました。

ただし、この数字は慎重に読む必要があります。値はテスト環境のもので、提携先が公表したものです。本番の全トラフィックの平均ではありません。要約には、比較の基準となる構成、タスクセットの規模、成功率の変化が書かれていません。76倍という数字の価値は、この三つの事実で決まります。

ブラウザエージェントとは何で、なぜコストが重要なのでしょうか。ブラウザエージェントは、利用者の代わりにWeb画面を操作するソフトウェアです。ページを読み、モデルに次の操作を尋ね、クリックや入力を行い、再びページを読みます。Asanaのような製品では、画面やツールをまたぐ定型作業を自動化できます。利用が増えるほど、1回あたりのコストがそのまま製品の利益率に響きます。

深掘り分析

ブラウザエージェントの費用構造を見ると、大幅な削減が起こりうる理由が分かります。エージェントはループで動き、一巡ごとにモデルを呼び出します。ページ内容は長いことが多く、1回の呼び出しで入力トークンが大量に発生します。数十ステップかかるタスクの総コストは、ステップ数に1回あたりの費用を掛けたものです。両方とも、タスクが複雑になるほど膨らみます。 単一の施策だけで76分の1になるとは考えにくく、複数の工夫が重なった結果とみるのが自然です。ただし、Asanaがどの手法を使ったかは元の情報に書かれていません。考えられる手段は、モデルに渡すページ表現の圧縮、無駄なステップや再試行の削減、繰り返し現れる手順の固定プログラム化、変わらない文脈のキャッシュ、新しいモデルによる少ないステップでの完了などです。これらはこの種のエージェントの仕組みからの推測であり、事例の記述ではありません。

Codexの役割も推測です。CodexはOpenAIのコーディングエージェントで、この事例にはそのタグが付いています。実行履歴の分析、ツールやスクリプトの書き換え、変更の検証といったエンジニアリング作業を担った可能性があります。そうだとすれば注目点は、あるエージェントが別のエージェントを調整した点です。従来はプロンプトや手順を人が手作業で調整してコストを下げていました。役割分担の詳細は原文で確認が必要です。 成功率のデータがなくても、76分の1というコスト削減に意味はあるのでしょうか。それだけでは意味を持ちません。Asanaのブラウザエージェントがその後もタスクを確実に完了できて初めて価値が出ます。成功率が維持または向上したなら強い結果です。簡単なタスクでしか成り立たないなら、主張は割り引いて考えるべきです。速度が5倍になったことは、1タスクあたりのモデル呼び出しが減るか軽くなったことを示唆します。

業界への影響

Asanaにとって、実行コストが下がることは提供できる機能の幅が広がることを意味します。1タスクあたりの費用が大幅に下がれば、エージェントを一部の高付加価値な用途から、日常的で頻度の高い用途へ広げられます。浮いた予算でより強いモデルを選べることも、事例が強調している結果です。古いモデルのまま利益を積み増すより、良い選択といえます。

OpenAIにとっては、モデルとCodexの両方を示す好例です。モデルがタスクを実行し、コーディングエージェントが周辺システムを最適化します。この組み合わせは、エージェントを企業で大規模に展開できるという主張を後押しします。ただし、ベンダーが選んだ事例ですので、典型的な結果の指標ではなく、可能性を示す証拠として読むべきです。 競合には二つの面で圧力がかかります。ブラウザ自動化やコンピュータ操作の製品は、ステップ数が多く文脈が長いという同じコスト構造を抱えています。説得力のある削減の道筋を示せなければ、企業の調達で割高に見える可能性があります。他のモデルベンダーも、ベンチマークの点数だけでなく、再現可能な顧客事例を求められるでしょう。 導入を検討する企業にとっての実務的な教訓は一つです。エージェント案件を評価するときは、モデルの能力だけでなく、1タスクあたりの実コストと遅延を測ることです。この二つが、機能を全利用者に常時開放できるかどうかを決めます。

今後の展望

注目すべき点がいくつかあります。第一に、OpenAIまたはAsanaが手法の詳細を補足するかどうかです。基準となる構成、タスクの種類、成功率、失敗時のフォールバック、そして76分の1と5倍が本番環境でも成り立つかが焦点です。第二に、この手法が他社に転用できるかです。文脈の圧縮、手順の固定化、エージェントによる最適化といった汎用的な手段に頼っているなら、普及は速いでしょう。Asana固有の製品構造に強く依存しているなら、再利用の余地は限られます。

第三に、ベンダーがエージェント用途で強いモデルを実質的に安い価格で提供し始めれば、価格体系やモデルの階層が変わる可能性があります。第四に、安くなったからといって安全になるわけではありません。ブラウザエージェントは利用者の代わりに実際のシステムを操作します。権限の範囲、誤操作の追跡可能性、人による確認の仕組みは、企業導入で引き続き必須の条件です。

全体として、Asanaの事例は、企業向けエージェントの主要な問いが変わりつつあることを示しています。できるかどうかから、大規模に運用して採算が合い、速く、信頼できるかどうかへの移行です。76倍という数字は有望な出発点ですが、確かな結論とするには、欠けている基準構成と成功率のデータが必要です。

Sources

FAQ

AsanaはCodexとGPT-6.1 Solで何を実現したのですか?

2026年10月9日、OpenAIはAsanaの事例を公開しました。AsanaはCodexを使い、テストでブラウザエージェントのコストを76分の1、速度を5倍に改善したとされます。GPT-6.1 Solも事例に挙げられています。数値はテスト結果で、本番全体の平均ではありません。

ブラウザエージェントのコスト76分の1はなぜ重要ですか?

ブラウザエージェントは毎ステップでモデルを呼び出すため、タスクごとのコストが利益率に直結します。Asanaはコストと遅延が下がったことで、費用を抑えるために性能の低いモデルへ戻らず、顧客により高性能なモデルを提供できるとされています。

Asanaのコスト削減事例で今後注目すべき点は何ですか?

注目点は、OpenAIやAsanaがベースライン、タスク数、成功率を公開するか、そして76分の1と5倍が本番環境でも成立するかです。記事の要約にはこれらの情報がありません。また、実システムを操作するため、権限管理と人の確認も引き続き重要です。