- Asanaはブラウザエージェントを最適化し、推定モデルコストを76分の1、実行時間を5分の1にした
- 改善の鍵は、閲覧履歴までキャッシュを広げ、スクリーンショットの削除間隔を伸ばすことだった
- GPT-6 AstraをCodexで使った実験自動化により、手作業で1〜2か月の調査が約1週間に短縮された
何が発表されたのか
OpenAIは2026年10月9日、Asanaがブラウザエージェントを効率化した事例を公開した。Asanaは買収したStackAIのブラウザエージェントについて、GPT-6.1 Sol上でワークフローを最適化し、推定モデルコストを76分の1、実行時間を5分の1にしたという。ブラウザエージェントとは、Webサイトを自動で操作して情報収集やフォーム入力を行うAIエージェントを指す。
StackAIでは、顧客がコードを書かずに、Webサイトを巡回しフォームを埋め情報を集めるワークフローを構築できる。記事は、Asanaの規模ではこうしたワークフローのわずかな非効率が積み重なると説明している。今回の取り組みは、その非効率をGPT-6 Astraに調査させて解消したものだ。
ボトルネックは履歴の再送
StackAIのCTOであるFrank Hidalgo氏は、GPT-6 AstraをCodex上で使ってエージェントのコードベースを解析させた。GPT-6 Astraは、固定の指示とツール定義はキャッシュされている一方、増え続けるページテキストとスクリーンショットの履歴はキャッシュされておらず、毎回のリクエストでフルプライスで再送されていたことを突き止めた。
さらにエージェントはほぼ毎ステップで古いスクリーンショットを削除しテキストを切り詰めていた。各編集で履歴が変わるため、履歴だけをキャッシュしても効果はなく、失った情報を取り戻すために既読のページを再訪問する必要が生じうると記事は指摘する。
3つの改善策を検証
Hidalgo氏はGPT-6 Astraが提案した修正を精査し、3つを選んで検証した。ブラウジング履歴までキャッシュを拡張すること、保持できるテキスト量を増やすこと、スクリーンショットを毎ステップではなくまとめて削除することの3点である。
GPT-6 Astraはまずどの変数が効くかを素早く確かめ、その後、1つのフロントエンドとバックエンドで多数のワークフローを並列に動かせるようコードをリファクタリングした。本調査では履歴バジェットを12万文字と48万文字の2水準、キャッシュとスクリーンショットのポリシーを6種類用意し、それぞれ4モデルで3回ずつ実行した。
最も良い結果を出したポリシーは、スクリーンショットを20枚まで蓄積し、その後直近の1枚まで削減するものだった。削除の間隔が長くなるため、それ以前の履歴がより長く変わらずに保たれる。大きい履歴バジェットと組み合わせたものが最適化ワークフローとなった。
コストと実行時間の変化
本番で使っていたModel Bでは、推定モデルコストが少なくとも$36.21（一部の実行は完了前にステップ上限に達した）から$1.24へと29分の1に減った。最適化ワークフローをGPT-6.1 Solで動かすとさらに2.6倍安くなり、1回あたり$0.47になった。
GPT-6.1 Sol単体で見ると、大きい履歴バジェットの下で新しいキャッシュとスクリーンショットのポリシーがコストを4分の1にした（$1.97から$0.47）。1回の呼び出しは約3分の1のコストになり、入力の89%がキャッシュから供給され、その価格はキャッシュなしの5%だった。
実行時間も、Model Bの元の構成で少なくとも22.5分だったものが、GPT-6.1 Solの最適化ワークフローで約4分になった。履歴管理は回答が得られるかどうかにも影響し、小さい履歴バジェットでは18回中3回しか回答が得られなかったが、大きいバジェットでは18回すべてが正解を返したと記事は伝えている。
製品テストへの展開
AsanaはStackAIのブラウザナビゲーションの変更をすでにリリースし、同様の実験を繰り返しやすくするツールを開発している。将来的にはこのテストをプラットフォームの評価に組み込み、顧客や社内チームがエージェントを設定する際にコスト・実行時間・回答品質を比較できるようにする計画だ。
Asanaは現在、GPT-6 AstraをCodexで使い、リリース前に製品機能をテストしている。Astraがプラットフォームを操作し、さまざまな入力を試し、人間のQAレビュアー向けにバグを報告するという。Hidalgo氏はこれを、多数のクラウドエージェントセッションが並列で機能をテストする新しいソフトウェア開発ライフサイクルの基盤と位置づけている。
| 構成 | 1回あたり推定モデルコスト | 1回あたり実行時間 |
|---|---|---|
| Model B（本番・最適化前） | 少なくとも$36.21 | 少なくとも22.5分 |
| Model B（最適化後） | $1.24 | 原文に記載なし |
| GPT-6.1 Sol（最適化前） | $1.97 | 原文に記載なし |
| GPT-6.1 Sol（最適化後） | $0.47 | 約4分 |
This would have taken me one to two months by hand. With GPT-6 Astra in Codex, it took about a week: I'd set a /goal before going to bed and review the results in the morning.
手作業なら1〜2か月かかっていたでしょう。CodexのGPT-6 Astraを使えば約1週間でした。寝る前に/goalを設定し、朝に結果を確認するだけです。
今後の見通し
AsanaはすでにStackAIのブラウザナビゲーションの改善をリリースしており、同様の実験を繰り返しやすくするツールの開発や、プラットフォームの評価への組み込みを進めている。GPT-6 AstraをCodexで使ってリリース前に機能をテストする取り組みも始まっており、エージェントが並列で検証する開発スタイルへの移行が示唆される。一方、記事にはGPT-6.1 SolやGPT-6 Astraの提供時期・価格、実験を再現するための具体的な手順は示されていない。こうした情報や、他社が同様の最適化を適用した結果が公開されれば、この手法がどこまで一般的に効くかを判断できるとみられる。
日本の開発者・IT企業にとっての意味
日本のIT企業や開発者にとって、この事例はLLMエージェントの運用コストが設計次第で大きく変わることを示している。特に、固定プロンプトだけでなく閲覧履歴までキャッシュ対象を広げるか、スクリーンショットやテキストをいつ削るかといった履歴管理が、コストと回答品質の両方を左右する点は、自社でエージェントを組む際に直接参考になる。ブラウザ操作の自動化は問い合わせ対応や業務システムの入力代行など国内でも需要が見込まれ、実行時間が22.5分から4分に短縮されるような差は、ユーザー体験や適用範囲を左右しうる。一方、記事は特定のモデルとAsanaの社内基盤を前提とした事例であり、そのまま同じ数値が出るわけではない。自社環境では、入力のうちキャッシュで賄える割合と、履歴を削るタイミングを測ることから始めるのが現実的とみられる。
気になる点
- 今回の最適化の効果は特定のモデルに依存するのか
- 記事では、Model Bでコストが29分の1、GPT-6.1 Solで4分の1と、複数のモデルで削減効果が確認されています。最も良い結果はGPT-6.1 Solで出ていますが、改善の中心はキャッシュ範囲と履歴管理の設計にあり、特定モデル固有の機能ではないとみられます。
- コスト削減で最も効いた要因は何か
- 記事によれば、最適化ワークフローでは入力の89%がキャッシュから供給され、その価格はキャッシュなしの5%でした。固定指示だけでなくブラウジング履歴までキャッシュ対象を広げたことが、1回の呼び出しを約3分の1のコストにしたと説明されています。
- 日本企業でも同じ手法を試せるのか
- 記事はStackAIやCommandといったAsana固有の構成を前提としていますが、キャッシュ範囲の拡張や履歴・スクリーンショットの保持方針の見直しは一般的な手法です。ただしGPT-6.1 SolやGPT-6 Astraの提供条件は記事に記載がなく、日本での利用可否は現時点では分かりません。
用語解説
- ブラウザエージェント
- Webブラウザを自動操作し、ページ遷移やフォーム入力、情報収集を行うAIエージェント。
- プロンプトキャッシュ
- 同じ入力の計算結果を再利用し、API呼び出しのコストや遅延を下げる仕組み。
- Codex
- 記事中では、GPT-6 Astraを動かしてコードベースの解析や実験を行う環境として登場する。
- フロンティアモデル
- 最前線の性能を持つ大規模AIモデル。記事ではModel A・B・CとGPT-6.1 Solを指す。
- 履歴バジェット
- エージェントが保持できる閲覧履歴の文字数の上限。記事では12万文字と48万文字を比較した。
出典
Asana cuts model costs 76x in browser tests with GPT-6.1 Sol
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する