GPT-6.1 Solの76倍ブラウザエージェント結果：Asanaが実際に測定したもの

Asanaは2026年10月8日にブラウザエージェントのコスト調査を公開し、GPT-6.1 Solの開発者が翌日それを記事にした。見出しは「Asana、ブラウザテストでモデルコストを76倍削減、GPT-6.1 Solを用いて」。76倍という数字は、誰かが測定したという意味では本物だが、GPT-6.1 Solの価格に関する事実ではない。それは、ブラウザエージェントの壊れたプロンプトキャッシュを直し、その背後にあるモデルを差し替えると何が起きるか、という事実だ。同じ最適化を、Asanaがすでに本番環境で使っていたモデル——同社がModel Bと呼ぶモデル——に対して実行すると、それだけでコストが29倍削減された。残りの2.6倍分をもたらしたのがGPT-6.1 Solだ。実験はCodex内で作業するGPT-6 Astraが実施し、ベースラインの背後にあるモデルはAsanaがModel Bと呼ぶ競合他社のモデルである。つまり、同じベンダーの2つのティアと、名を明かされていない1社の競合が、この話にはすべて登場する。以下では、この結果のうち月曜日にもそのまま真似できる部分と、Asana特有のスタックに属する部分を切り分ける。

正確に述べられた比較

Asanaのこれに対するスタックは、同社が買収したワークフロー自動化プラットフォームであるStackAIで、ノーコードでウェブサイトをナビゲートし、フォームに入力し、情報を収集するブラウザエージェントを実行している。テストタスクは狭く具体的だった：公開デモカタログから32冊の本それぞれについて6つのフィールドを収集する。これは一部の顧客が実行している内容を代表しており、また、144回の実行の調査が1週間に収まるほど小規模である。

実験計画は、6つのキャッシュおよびスクリーンショットポリシーを2つの履歴バジェットで、4モデルにわたり、条件ごとに3回実行するというものだった——144回の実行、さらに12回の追試。コストは各プロバイダー自身のトークンカウンターから計算され、すべての回答は独立に用意された参照に照らして採点された。4モデルは、3つの名前非公開のフロンティアモデル（モデルA、B、C）とGPT-6.1 Solだった。モデルAは別のラボによる、より小型で安価なモデルで、2025年秋にリリースされ、価格はGPT-6.1 Solの半分。モデルBは本番環境で使われていたモデルで、Aと同じラボによるもので、2026年夏にリリースされ、価格はGPT-6.1 Solと同じ。モデルCはモデルBの新しいバージョンで、2026年秋にリリースされ、こちらも価格はGPT-6.1 Solと同じ。この3つはどちらの記事でも名前が伏せられているため、この比較は読者には再現できない——29倍を他社のモデルについての数字として扱う前に知っておく価値がある。これらはAsanaとOpenAIが公表した数値であり、独立に監査されたものではない。

成果のはしご、すべてAsana自身の数字：

• モデルBでのベースライン生産 — 1回あたり少なくとも$36.21、1回あたり少なくとも22.5分。一部のベースライン実行は完了前にステップ上限に達したため、平均は真の平均ではなく下限値である。

• モデルB、最適化エージェント — 実行1回あたり$1.24、ベースラインの4倍高速、コストは29分の1に削減。

• GPT-6.1 Sol、同じ最適化エージェント — 1回あたり$0.47、約4分、コスト76分の1削減で5倍高速。

• GPT-6.1 Sol、修正前と修正後 — 実行1回あたり$1.97から$0.47、キャッシュとプルーニングの変更だけで4分の1に削減。

ベースラインは下限値なので、76倍自体が下限である。正直に読めば「少なくとも76倍」であって、「76倍」ではない。

実際に何が変わったのか、そしてなぜそれがモデルの機能ではないのか

仕組みはプロンプトキャッシュのからくりであり、これを理解する価値はあります。どんなモデルでどんなエージェントを動かす場合でも当てはまるからです。ブラウザエージェントは、モデルを呼び出すたびに、ツール群、システムプロンプト、そしてページのテキストとスクリーンショットの増え続ける履歴を再送信します。プロンプトキャッシュは繰り返される部分を割引しますが、それは最長の未変更プレフィックスに限られます。リクエストの途中で何かが変わった瞬間、それ以降は再利用が途切れてしまいます。

Asanaの本番エージェントには、複合的に作用し合う2つの欠陥があった。固定の指示とツール定義はキャッシュしていたが、閲覧履歴はキャッシュしていなかった。しかも、ほぼ毎ステップでその履歴を編集していた。毎回、前回のスクリーンショットを捨て、履歴の上限に収めるために古いテキストを切り詰めていた。編集のたびにプレフィックスが無効化されるため、たとえキャッシュを有効にしていても、ほぼ役には立たなかっただろう。Asanaの記事によると、テストしたモデルでは、キャッシュ読み取りのコストは標準入力価格の0.05倍から0.1倍だった。つまり、得られる見返りは大きく、エージェントは体系的にそれを拒否していたことになる。

修正は2つの部分からなる。まず、履歴もキャッシュする。最新のツール結果にキャッシュマーカーを付ける。次に、毎回の呼び出しでそれを編集するのをやめる。スクリーンショットを保持し、20対1の比率でまとめて間引く。つまり、エージェントは最大20枚保持し、その後は最新の1枚まで削減する。すると、約19回連続の呼び出しで未変更のプレフィックスが再利用される。履歴の予算を120,000文字から480,000文字に引き上げて、古いテキストが切り捨てられないようにすると、計算が合う。GPT-6.1 Solでは、入力の89%がキャッシュから来たため、各呼び出しのコストはおよそ3分の1になった。

ここで最も重要な発見は、否定的なものだ。バッチ剪定なしで履歴をキャッシュすることは、より大きな予算のもとでは、4つのモデルのうち3つにおいて、まったくキャッシュしない場合よりも多くのコストがかかった——キャッシュは絶えず書き換えられ、ほとんど読まれなかったのだ。追記専用の履歴規律なしに有効化されたキャッシュ基盤は、何の見返りもなく書き込みの割増コストを払う手段にほかならない。この失敗モードはモデルに依存せず、同じ修正がモデルBを29倍動かした理由でもある。

モデル選択が実際に効果を発揮した場面

ワークフローの修正を除外して、条件を揃えて比較しよう。同じ最適化済みエージェントにおいて、GPT-6.1 Sol は同じ表示価格で Model B より 2.6 倍安く実行された。追加の要因は料金表ではなく、キャッシュヒットの挙動だ。Sol は入力の 89% をキャッシュから読み込んだ。Asana は Model B について同等の割合を公表していないため、この 2.6 倍は、公表された内訳のない測定結果である。これは「このモデルが、このワークロードで、キャッシュをよりうまく使った」と捉えるべきであり、名前を挙げられないモデルに対する一般的な 2.6 倍の優位性と捉えるべきではない。

ランタイム側は明白だ。ベースラインより5倍高速で、最適化されたSolワークフローは約4分、ベースラインは少なくとも22.5分かかる。トークン単位で課金されるエージェントでは速度がコストに直結する。なぜなら、ループする遅いモデルはそのループの分だけ費用を支払うからだ。

これをコスト計算する人向けに言うと、GPT-6.1 Sol の標準 API 料金は、入力トークン 100万あたり $2.00、キャッシュ済み入力トークン 100万あたり $0.10、出力トークン 100万あたり $10.00 で、キャッシュ読み取り割引は入力料金の 0.05倍です。これは OpenAI の現行の料金表で最も深い割引です。Codex でエンジニアリング作業を担ったモデルである GPT-6 Astra は、入力 $10.00、出力 $50.00 で、これが OpenAI のローンチ時の打ち出しが依拠した5倍の差です。この調査で $2 の実行ではなく $0.47 の実行が生まれた理由は、料金表ではありません。非常に反復的なリクエストの 89% が入力料金の 20分の1 で請求されたことです。キャッシュを多用するエージェントでは、割引の行はヘッドライン価格よりも大きな働きをします。そして当社自身のカタログでは、プロバイダーの定価は0%のマークアップでパススルーされるので、ベンダーがキャッシュ済み入力のメーターを動かせば、同じ日にあなたの請求書でもそれが動きます。

研究におけるもう一つの数字：エージェントがそもそも回答したかどうかを決めていたのは履歴の予算だった

1回あたりのコストは誰もが口にする数字だが、この調査でより有用な結果は信頼性に関するものであり、運用担当者がまず目を通すべきなのはそちらだ。

• 120,000文字の予算では、Model Cは18回の実行のいずれでも回答せず、GPT-6.1 Solは18回中3回で回答しました——ほとんどの実行は回答を生成することなくステップ上限に達しました。

• 480,000文字では、両方のモデルにおけるすべての実行が回答し、それぞれが正しい答えを出しました。

• 新しいモデルほど、より小さい予算を速く使い切った。Model C が最初に履歴を削減したのは呼び出し 10 回目、Model A は 64 回目だった。

• 最適化されたワークフローでは、すべての実行がタスクを完了して正しい回答を返し、各モデルでの最良条件の実行はすべて、収集することになっていた192件の事実すべてに遭遇した。

それは「より安い」とは別の議論です。能力のあるモデルでの履歴バジェットが小さすぎると、エージェントは部屋が足りなくなることで失敗し、ステップ上限に達することで失敗します。これは最も高くつく失敗の仕方です — 実行全体の料金を払って何も得られません。バジェットを上げると呼び出しあたりのコストは上がり、回答あたりのコストは下がりました。これはプロダクションの責任者が追うべき唯一の数値です。このようなエージェントのために未検証のモデルを評価しているなら、低リスクのパターンは、本番ルートを信頼できるモデルに維持し、新しいモデルをフェイルオーバーまたは分割ルートの背後に置くことです。そうすれば、ステップ制限の失敗はインシデントではなくルーティングの事実として現れます。この比較のすべてのモデルは、次を通じて利用できます：200以上のモデルに対応する1つのAPI。プロバイダーのリスト価格がそのまま適用され、これはまた、キャッシュ読み取りの割引を5つのダッシュボードではなく同じ請求書上でベンダー間で比較可能にします。

これから何を、順番に取るべきか

ブラウザまたはコンピュータ操作エージェントを運用しているなら、Asanaの調査にある3つのレバーは、料金表に目を通す前に引いておく価値があります。

• リクエストのプレフィックスは追記専用にしてください。履歴の途中に対する呼び出しごとの編集は、その地点以降のキャッシュ再利用を無効にします。

• バッチでプルーニングする。Asanaの追加調査では、すべてのスクリーンショットを保持すると、Model BとGPT-6.1 Solでは最良のプルーニング条件より1回あたりのコストが1.2倍少なく、Model Cでは約5%少なかった。プルーニングは依然として長いタスク、小さなコンテキストウィンドウ、高価なキャッシュ読み取りにとって重要だ — しかし20:1のバッチ比率を支持する根拠はキャッシュの安定性にあり、スクリーンショット自体にあるのではない。

・モデルごとに履歴バジェットを設定し、それをステップ上限と照らし合わせて確認してください。あるモデルに収まるバジェットでも、次のモデルには足りなくなることがあります。

この調査で示された2つのガードレールは見落としがちだが、見落とすべきではない。どの実行も480,000文字の予算には達しなかった。そのため、この予算がこれらの実行を制約することはなかった。しかし、逸脱していくエージェントはコンテキスト制限に向かって成長し、キャッシュが壊れると、すべての呼び出しが全コストを支払うことになる。悪い実行を抑え込むのは、ステップ数、トークン数、および実行あたりのコストの上限である。別に、この調査では条件ごとに3回または4回の実行を、変動する呼び出し回数で行った。Asana自身が言うには、これは大まかなパターンを示すには十分だが、数パーセントしか違わない条件を区別するには不十分である。ここから5%の差分を読み取って、それに合わせてパイプラインを再構築してはいけない。

本当に新しい部分と、そうではない部分

セットアップに関する注意点は率直に述べておく価値がある。4つのモデル、そのうち3つは名称非公開、狭い範囲の32冊の本を扱うタスク、Asana自身の計測カウンター、そして結果を掲載しているベンダー自身の記事。ここにあるものはどれもAsanaの外部で再現されていない。しかし、そのメカニズムは完全に明示されている——追記専用の履歴、最後のツール結果へのキャッシュマーカー、バッチ枝刈り、より大きな予算、プロバイダーのカウンターによるキャッシュ読み取りの測定——そしてこれは、間違ったラボに帰属されても生き残る類の発見だ。76倍は、AsanaのワークロードにおけるAsanaの数字である。これが読む価値があるのは、午後のひとときで検証できるルールを示しているからだ。各ステップで自分の履歴を編集するエージェントは、すでに交わした会話に対して満額を支払っている。