Asanaのブラウザエージェント試験、GPT-6.1 Solでモデルコストを76分の1に削減
Asanaによると、エンジニアが閲覧履歴の保持・キャッシュ方法を変更したことで、同社のブラウザエージェントはコストが76分の1、処理速度が5倍になったという。Asanaのブラウザエージェント試験では、GPT-6 AstraをCodex内で用い、システムの調査、実験の実行、トレースの分析を行った。その後、最適化されたワークフローにおいて、GPT-6.1 Solが推定モデルコストで最も低い結果を示した。
見出しの結果は、モデルの勝利のように見える。だが、より重要な発見はエージェントアーキテクチャに関するものだ。Asanaは、エージェントがスクリーンショットを削除するタイミング、履歴許容量の拡大、過去のステップの蓄積記録のキャッシュ方法を変更した。これらの変更により、エージェントがタスク完了に必要な情報を維持しつつ、重複処理を減らした。
この違いは、ブラウザエージェントを評価するあらゆる企業にとって重要である。チームはより安価なモデルへ切り替えても、コンテキスト管理が不十分ならトークンを無駄にし続ける可能性がある。一方で、より高性能なモデルを選び、適切な履歴を維持すれば、総運用コストを下げられる。Asanaの実験は、この2つの戦略を直接比較したものだ。
Asanaのブラウザエージェント研究で変わったのはモデルだけではない
Asanaの最大の成果は、単にモデルを置き換えることではなく、モデルを中心にワークフローを再設計したことによるものだった。
同社は2026年10月8日に結果を公開し、続いて10月9日にOpenAIのケーススタディが公開された。この取り組みは、Asanaが2026年初頭に買収したノーコード自動化プラットフォームStackAI内のブラウザエージェントに焦点を当てたものだ。
StackAIでは、顧客がWebサイトを操作し、情報を収集し、業務アプリケーションをまたいでフォームを完成させるエージェントを作成できる。こうしたワークフローは人間のブラウジングに似ているが、その裏側ではエージェントが指示、ツール、ページテキスト、スクリーンショット、過去の操作を繰り返しモデルへ送信する。
この反復的なコンテキストは、コストのかかるパターンを生む。新しいステップごとに、前のステップより多くの履歴が含まれるためだ。過去の内容が変化し続ければ、プロバイダーはキャッシュした表現を確実に再利用できない。
Asanaの元のエージェントは、固定の指示とツール定義をキャッシュしていた。しかし、増え続けるブラウジング履歴は効果的にキャッシュしていなかった。また、古いスクリーンショットを削除し、テキストを頻繁に切り詰めていたため、リクエストの前半部分が変化していた。
こうした編集は、連続するモデルリクエスト間で共有される、変化しない先頭部分である安定したプレフィックスを壊した。プレフィックスが変わると、ブラウジング履歴の大部分を再処理する必要が生じた。
AsanaのStackAI最高技術責任者であるFrank Hidalgoは、Codex内のGPT-6 Astraにこの挙動を調査させた。このモデルはコードベースをマッピングし、リクエストの組み立て方を確認し、検証すべき変数を特定した。
Asanaによると、この研究では4つのフロンティアモデルを対象に144回の主要実行を行った。6つのキャッシュおよびスクリーンショット方針、2つの履歴許容量を検証し、各条件で3回ずつ実行した。その後、同社はより小規模な追試も実施した。
各構成には同じ課題が与えられた。ブラウザエージェントは公開デモカタログに掲載された32冊の書籍について、それぞれ6項目を収集する必要があった。つまり、正しい最終回答を返すだけのコンテキストを維持しながら、192件の事実を見つける必要があった。
モデルにはGPT-6.1 Solと、匿名化された3つの代替モデルが含まれていた。AsanaはこれらをModel A、B、Cと呼んだ。Model Bは元の本番構成を支えており、Model Cは同じプロバイダーによるより新しいモデルだった。
Asanaはプロバイダー名を明らかにしておらず、直接的な競合比較には制約がある。ただし、最適化されたGPT-6.1 Solワークフローは、元のModel B構成の76分の1のコストだったとしている。完了速度もおよそ5倍だった。
同社はその後、ブラウザナビゲーションの変更をStackAIで公開した。これにより、この取り組みは実験室での比較から本番環境の変更へと移行した。ただしAsanaは、広範な顧客レベルのパフォーマンスデータをまだ公開していない。
決定的な仕組みとなったプロンプトキャッシュ
決定的な変数は、エージェントが呼び出し間で蓄積した履歴の大半を変えずに維持できるかどうかだった。
プロンプトキャッシュは、変化しないプロンプトプレフィックスに関連する再利用可能な計算状態を保存する。後続のリクエストでは、同じ素材を最初から処理する代わりに、その状態を再利用できる。
キャッシュは、完成済みの回答を再生するために保存するものではない。モデルは新しい素材を処理し、新たな応答を生成する。ただし、同一のまま維持される適格なコンテキストについて、同じ処理を繰り返す必要がなくなる。
OpenAIのプロンプトキャッシュガイドでは、安定した指示や参照資料を変化するコンテンツより前に配置することを推奨している。また、アプリケーションでは以前のターンを何度も書き換えるのではなく、会話履歴を追記するよう助言している。
Asanaの元の設計は、ブラウザ実行時にこの第2の原則に反していた。ほぼすべてのステップで、過去のスクリーンショットを削除し、ときには古いテキストも切り詰めていた。そのため、次のリクエストは履歴の途中で異なるものになっていた。
固定のシステムプロンプトだけをキャッシュしても、最大の反復入力源を捉えることはできなかった。ブラウザエージェントはタスクを進めるにつれ、ページテキスト、スクリーンショット、観察結果、ツールの結果を蓄積していた。
Asanaは、バッチプルーニングと呼ばれる別の方針を試した。プルーニングとは、蓄積した履歴が大きくなりすぎる前に、古いコンテキストを削除することを指す。選択された方針では、エージェントは最大20枚のスクリーンショットを保持し、その後、最新の1枚だけに減らした。
この手法により、追記専用の履歴がより長く維持された。エージェントは毎ステップで以前の内容を変えることなく、新しい観察結果を末尾に追加できた。そのため、各リクエストのより多くの部分が再利用の対象になった。
最適化されたワークフローでは、テキスト履歴の許容量も120,000文字から480,000文字へ拡大された。これにより、エージェントは以前に収集した事実を捨てずに保持する余地を広げた。
この大きな許容量は、完了率に重要な影響を与えた。小さい履歴設定では、GPT-6.1 Solが回答を生成したのは18回中わずか3回だった。Asanaによると、大きい設定では18回すべてで回答した。
Asanaは、これらの大きな履歴を用いた実行はいずれも正しい回答を返したとしている。この結果は、コンテキストを積極的に縮小すれば常にエージェントの効率が向上するという前提に疑問を投げかける。
コンテキストを削除すれば、リクエストの即時的なサイズは小さくなる。しかし、エージェントがページを再訪したり、ツール呼び出しを繰り返したり、以前に集めた証拠なしで処理を続けたりする可能性がある。また、削除によってリクエストプレフィックスが変われば、キャッシュ再利用も損なわれる。
したがって、最適な方針はタスク全体の経済性に左右される。チームは入力処理、繰り返されるナビゲーション、完了率、応答品質、失敗した実行からの回復を考慮しなければならない。
Asanaによると、最適化された構成では、GPT-6.1 Solの入力の89％がキャッシュから提供された。この比率は、より高性能なモデルがタスク全体では最も低コストの選択肢になり得る理由を説明している。
これが、Asanaのブラウザエージェントの結果を支える中心的な仕組みだ。同社は単にモデルへ使用トークンを減らすよう求めたのではない。反復トークンの処理コストが下がるよう、ワークフローを再編成した。
より多くのコンテキストがエージェントの確実な完了を支えた
最も安価なリクエストが、必ずしも最も安価な完了済みワークフローの一部とは限らないことを、この実験は示唆している。
エージェント開発者は、コンテキストを最小化すべきリソースとして扱うことが多い。長いプロンプトは入力処理を増やし、モデルのコンテキスト上限に近づくため、この考え方には妥当性がある。
ブラウザエージェントでは、計算がより複雑になる。過去の観察結果が作業記憶として機能するからだ。アドレス、製品属性、警告、ナビゲーション結果を削除すると、エージェントが最終回答を完成できなくなる可能性がある。
小さい履歴許容量では、一部のモデルで特に弱い結果が出た。Asanaによると、この条件下でModel Cは18回の実行すべてで回答を返さなかった。GPT-6.1 Solは3回しか回答しなかった。
これらの失敗は、モデルに一般的なブラウジング能力がないことを示すものではなかった。より大きな履歴許容量により、結果は変化した。必要な記録を保持するための十分な空間を与えられると、両モデルはすべての実行で回答した。
この結果は、より広範なエンジニアリング原則を裏付ける。コンテキスト方針はモデルとタスクに適合しなければならない。単一の普遍的なトークン上限では、異なるシステムで同等の挙動は得られない。
モデルごとに生成する説明、ツール呼び出し、推論トレースが異なるため、コンテキストの消費速度も異なり得る。あるエージェントは少ない操作でプルーニングのしきい値に達するかもしれない。別のエージェントは、はるかに長く続けられる場合がある。
Asanaは、より新しい、あるいは高性能なモデルが小さい許容量を自動的により効率よく使うわけではないと確認した。テストされたワークフローでは、Model CはModel Aよりはるかに早い段階で履歴の切り詰めを始めた。
実験では、キャッシュだけでは不十分であることも明らかになった。大きい履歴許容量では、バッチプルーニングなしのキャッシュは、4モデル中3モデルでキャッシュなしよりコストが高かった。
リクエスト構造を考慮すれば、この結果は矛盾しているようには見えない。アプリケーションが再利用したい素材を絶えず書き換えるなら、キャッシュの価値は限定的になる。システムは変化する履歴を処理するコストを負う一方、将来のキャッシュヒットを十分に得られない。
Asanaが選んだ方針は、3つの判断を整合させた。履歴をキャッシュし、より長い期間にわたり追記専用のシーケンスを維持し、切り詰めが必要になる前の許容量を大きくした。
追試では別の疑問も浮上した。Asanaは、スクリーンショットをプルーニングせずすべて保持する構成を試した。この特定のタスクでは、一部の構成が選択された方針より低い呼び出し単価を実現した。
同社はこれを、プルーニングをなくすべき証拠とは扱わなかった。より長いワークフローではコンテキスト上限を超える可能性があり、キャッシュ操作により高い料金を課すプロバイダーもある。不要なブラウジングへ逸脱するエージェントにも、明確な境界が必要だ。
Asanaは、ステップ数、トークン数、実行あたりの総コストに上限を設けることを推奨している。これらの制限は、誤作動した、あるいは混乱したエージェントが履歴を無限に拡大することを防ぐ。古い履歴を短い要約に置き換えるコンパクションも、別の選択肢となる。
コンパクションには独自のトレードオフがある。コンテキストサイズは減るが、以前のプロンプトが変わるため、キャッシュ再利用を妨げる可能性がある。要約は、後で重要になる詳細を省くこともある。
このため、チームにはアクティブなプロンプトの外部に記録が必要となる。Asanaは、ソフトウェアデリバリープラットフォームであるCommandにリクエスト、トレース、結果を記録した。エンジニアや追加のエージェントは、その後で完全な実験を確認できた。
永続的な記録は、検索可能なナレッジベースも支える。アクティブなエージェントには現在のステップに必要なコンテキストだけが渡され、レビュー担当者は完全な証拠の履歴にアクセスし続けられる。
この分離は、チームがモデルの記憶と組織の記憶を区別するのに役立つ。エージェントの作業コンテキストは制限されるべきだ。一方、実験記録は意思決定を再現し、失敗を調査できるだけの詳細を維持すべきである。
GPT-6 Astraが評価作業をエージェントのタスクへ変えた
Asanaは、システムを改善するために1つのモデルを使い、最適化された本番ワークフローを実行するために別のモデルを使った。
GPT-6 Astraは、研究・エンジニアリングエージェントとしてCodex内で機能した。GPT-6.1 Solは、ブラウザエージェントの実行時モデルの1つとして使われた。両者を別の役割として扱うことで、結果に対する誤解を招く解釈を避けられる。
Hidalgoは調査の方向性を定め、検証に値する提案変更を選定した。GPT-6 Astraはコードを精査し、リクエストを計測可能にし、予備試験を実行して、影響の大きい変数を特定した。
既存コードは、統制された比較のために設計されていなかった。Asanaによれば、Codex agentはシステムをリファクタリングし、共通のフロントエンドとバックエンドで複数の実験ワークフローを並行して支援できるようにした。
続いてGPT-6 Astraは調査を開始し、利用記録を分析して出力を比較した。別々のモデルセッションが作業の一部をレビューし、人間が結論を評価して本番変更を承認した。
Asanaは、このプロジェクトには手作業で1〜2か月を要したと見積もっている。Codexのワークフローでは、調査は約1週間で完了した。
この主張は独立した評価ではなく、企業自身によるものだ。また、システムに精通した技術責任者が主導した1件のエンジニアリングプロジェクトを説明している。他チームが同じほどの期間短縮を見込むべきではない。
それでも、このワークフローはコーディングエージェントの利用における重要な変化を示している。エージェントは完成した仕様から機能を実装しただけではない。実証的な調査の設計と実行にも貢献した。
この調査では、トレース、実験結果、チケット、プルリクエストが作成された。これらの成果物は、変更がStackAIの本番環境に届く前にCommandを通過した。
重要なのは、AIエージェントが機械的な作業の大半を担ったという主張以上に、このプロセスである。安定した記録がなければ、レビュー担当者は、どの設定が実行されたのか、なぜ失敗したのか、報告された改善がコード変更後も維持されたのかを確実に判断できない。
Asanaの調査によると、人間が目標と評価基準を設定し、調査結果もレビューした。コーディングエージェントは、その意思決定の間にチームが実行できる実験の量を拡大した。
Hidalgoは、就寝前に目標を設定し、翌朝に結果を確認するという日課を説明した。この非同期パターンは、エージェントの実行時間をエンジニアリング上のリソースへと変える。
同時に、ボトルネックも移る。実験を容易に生成できるようになると、人間は有効な問いの選定、測定値の検証、誤解を招く結論の却下により多くの時間を費やす必要がある。
リスクは、自動化された実験ノイズである。エージェントは、多数の実行を生成できても、強い証拠を生み出せるとは限らない。反復テストは依然として、ベンチマーク設計、隠れたタスク変動、採点エラーの影響を受けやすい。
Asanaは、固定されたタスクと独立して用意された参照回答を用いることで、このリスクの一部を低減した。また、テキスト長からトークン消費量を推定するのではなく、プロバイダー自身の利用カウンターを記録した。
同社は大半の設定で3回しか反復していない。Asanaは、この調査が示すのは大まかな傾向であり、数パーセントの差を信頼できる形で示すものではないと明言している。
この留保は重要だ。76倍と5倍の比較は注目に値するほど大きいが、アーキテクチャとモデルの変更を組み合わせている。GPT-6.1 Solの普遍的な優位性を切り分けて示すものではない。
Asanaの社内結果は、最適化されたワークフローを受けたModel Bも大きく改善したことを示している。GPT-6.1 Solがコストをさらに削減する以前に、アーキテクチャが改善の大きな部分を占めていた。
76倍という主張が立証していないこと
公開された結果は説得力のあるエンジニアリング上の証拠だが、ブラウザエージェント市場の中立的なベンチマークではない。
この調査は、公開書籍カタログ上の1つの構造化タスクを用いた。各実行は同じ目標に従い、同じ一連のフィールドを収集した。実際の企業ブラウジングには、認証、変化するレイアウト、曖昧な指示、予期しないダイアログからの復旧が伴うことが多い。
反復的な抽出に優れるワークフローも、調達、サポート、コンプライアンス、社内業務では異なる挙動を示す可能性がある。こうしたタスクでは、類似ページからの反復収集ではなく、複数のシステムにまたがる判断が求められる場合がある。
Asanaのブラウザエージェントテストは、GPT-6.1 Solを匿名化された3つのモデルとも比較した。読者はプロバイダー固有の設定を確認できず、各代替モデルが独自の最適化後にどのような性能を示すかも判断できない。
Asanaによれば、調査期間中、Models B、C、GPT-6.1 Solの標準価格は同程度だった。Model Aはより安価な代替案として位置付けられていた。公開記事ではその名称は明かされていない。
この匿名性により、結果が単純なモデルのランキング表になることは避けられる。また、十分な試行に裏付けられていないベンダー比較へと調査が流れることも防いでいる。
最大の見出しは、最適化されたGPT-6.1 Solのワークフローと、Model Bにおける元の本番設定を比較している。モデルとエージェントアーキテクチャという2つの変数が同時に変更された。
より限定的な比較では、新しいポリシーをGPT-6.1 Sol内で適用した場合、コストが4分の1に低下した。残る差は、その最適化済みシステムと古い本番ベースラインの比較から生じている。
これは結果を弱めるものではない。結論を変えるものだ。この調査は、モデルの切り替えだけを完全な解決策とみなすのではなく、有能なモデルとコンテキスト認識型アーキテクチャを組み合わせることを支持している。
実行時間が5分の1になったという改善にも、同様の留保がある。元のModel Bによる実行の一部は、完了前にステップ上限に達した。そのため、測定された所要時間は、完全なタスクに必要な時間の下限を示すにすぎない。
完了品質についても継続的な観察が必要だ。Asanaは、最良条件でのすべての実行が必要な事実を見つけ、正しい回答を生成したと報告している。公開資料には、顧客ワークロードや長期的なエラー率は含まれていない。
完全な調査はAsanaの実装とトレースに依存しているため、独立した再現は依然として限定的である。同社は手法とより詳細な調査を共有したが、外部チームには依然として独自のタスクスイートが必要となる。
StackAIの買収も、この結果に対する商業的利害を生んでいる。Asanaは、クロスシステムのエージェントワークフローを拡大するため、2026年5月にStackAIの買収を完了した。
OpenAIにも、GPT-6 AstraとGPT-6.1 Solがエンタープライズエージェントをどのように支援するかを示す利害がある。どちらの一次情報源も貴重な技術的詳細を提供するが、独立した業界監査を代表するものではない。
運用条件も結果を変えうる。キャッシュの利用可能期間には限りがある。同時利用する顧客では履歴が異なる場合があり、パーソナライズされたコンテキストによって共有可能な素材の量が減少することもある。
プライバシー要件により、どのコンテンツをモデルコンテキストへ入れられるかが制限される可能性がある。セキュリティチームには、ブラウジング中に収集されるスクリーンショット、認証情報、顧客記録、機密情報に対する管理も必要だ。
キャッシュはこうした義務をなくすものではない。変えるのは計算と課金の挙動であり、データガバナンスの必要性ではない。チームには依然として、保持ポリシー、アクセス制御、監査証跡、障害対応が必要である。
したがって、正しい受け止め方は条件付きのものとなる。Asanaは特定のブラウザエージェント向けに高価値な最適化を見つけ、それを本番環境に導入した。他チームは、そのメカニズムを検証可能な仮説として扱うべきだ。
次の検証は実際の顧客ワークフロー全体での性能だ
次の3つのシグナルが、Asanaの結果が再利用可能な運用モデルになるのか、それとも強力な社内ケーススタディにとどまるのかを示す。
第1のシグナルは、より広範な評価範囲である。Asanaは、顧客や社内チームがエージェント設定時にコスト、実行時間、回答品質を比較できるツールを開発していると述べている。
こうした評価には、構造化カタログからの抽出以外のタスクが必要だ。有用なテストスイートには、変化するWebサイト、認証済みアプリケーション、部分的な失敗、長いナビゲーション経路、停止点が曖昧な指示を含めるべきである。
同じ履歴ポリシーがこうしたワークフローも改善するなら、アーキテクチャ主導の最適化を支持する根拠は強まる。改善幅が縮小するなら、Asanaが選んだ設定は反復的な抽出に強く結び付いている可能性がある。
第2のシグナルは、本番導入から得られる証拠である。Asanaはすでにブラウザナビゲーションの変更をStackAIに導入しているが、顧客全体の集計成果は公開していない。
完了率は、呼び出し単位のコストより重要であるべきだ。顧客がジョブを再実行したり、不完全な出力を手作業で修復したりしなければならないなら、より安価なリクエストに大きな価値はない。
チームは、キャッシュから提供される入力の割合、タスク所要時間の中央値、ステップ上限による失敗、人間の介入率も確認すべきだ。これらの指標は、最適化された設計が変動する本番トラフィックに耐えられるかを明らかにする。
第3のシグナルは、競合するモデルプロバイダーやエージェントプラットフォームがどう対応するかである。プロンプトキャッシュは製品機能になっているが、開発者がその恩恵を受けられるかどうかはアプリケーションアーキテクチャによって決まる。
プロバイダーは、より長いキャッシュ保持期間、より優れた診断機能、より低いキャッシュ済み入力料金、より明確な利用データを通じて競争できる。エージェントフレームワークは、すべての顧客にカスタム計測機構の構築を強いることなく、履歴ポリシーを公開できる。
OpenAIは、GPT-6.1 Solを、GPT-6 Astraより低い運用コストで高度なエージェント型作業を行うモデルとして位置付けている。Asanaの調査は、その位置付けに具体的なアプリケーション事例を与えている。
しかし、最も強い競争圧力を受けるのはエージェントソフトウェアのチームだ。顧客は、モデル選択機能だけを提供するのではなく、プラットフォームが総タスクコストを自動的に最適化することをますます期待するようになる。
成熟したプラットフォームは、観測された挙動に基づいてコンテキスト上限を推奨すべきである。キャッシュを無効にする編集を特定し、ポリシーを比較し、プルーニングによってエージェントが以前のページを再訪する場合には警告すべきだ。
また、人間が結果を監査できるだけの外部証拠を保持すべきである。ブラウザエージェントには制限された作業メモリが必要である一方、組織には完全な運用記録が必要となる。
Asanaは同様のテストを評価システムに組み込む計画だ。また、CodexのGPT-6 Astraを利用して製品機能をナビゲートし、異なる入力を試し、人間のレビュー担当者向けにバグを報告している。
この拡張により、物語は1つのブラウザエージェントを超える。Asanaは、エンジニアリングエージェントが他のエージェントや製品機能を継続的に評価できるかを検証している。
機会は明確だ。自動化された実験は、小規模なエンジニアリングチームが手作業で試せるより多くの設定を評価できる。また、トレース分析からレビュー済みコード変更までの道のりも短縮できる。
制約も同様に明確である。エージェントが実験、発見、パッチを継続的に生成できるようになると、人間の注意力が希少な資源になる。チームは、どの結果を信頼し、本番環境に公開する価値があるかを判断しなければならない。
開発者にとって、当面の行動は孤立した呼び出しではなく、完全なタスクを測定することだ。現実的な条件下で、キャッシュヒット率、完了品質、実行時間、再試行、人間による修復作業を記録すべきである。
エンタープライズの購買担当者は、エージェントが増大する履歴をどのように管理するかをベンダーに尋ねるべきだ。モデル名だけでは、周辺システムが有用なコンテキストを保持しているのか、それともその処理に繰り返し費用を支払っているのかは分からない。
ナレッジワーカーにとって、この変化はより高速で能力の高いブラウザ自動化を約束する。その価値は、エージェントが機密データを露出させたり不要な手順をさまよったりすることなく、必要な事実を保持できるかにかかっている。
Asanaのブラウザエージェントの結果は、コンテキスト設計が今やあらゆるエージェント評価においてモデル選定と並ぶべきだという説得力ある根拠を示している。次の問いは、その教訓が顧客が実際に自動化したい雑多なワークフロー全体でも成り立つかどうかだ。
