AI-Papers
- Asanaが自社のブラウザ操作エージェントを見直し、1回の実行コストを76分の1、所要時間を5分の1に短縮した
- 原因はプロンプトキャッシュが効かない閲覧履歴の送り直しで、履歴のキャッシュ化とスクリーンショットの一括削除で解消した
- GPT-6 AstraをCodex上で使ってコードを解析し、144通りの構成を並列で検証する開発プロセスを採った
何が改善されたのか
OpenAIが公開した導入事例によると、Asanaは同社のStackAIプラットフォームが提供するブラウザエージェントの運用コストと処理時間を大幅に削減しました。StackAIは、Webサイトの巡回やフォーム入力、情報収集といった作業をノーコードのワークフローとして組めるプラットフォームです。
最適化後の構成でGPT-6.1 Solを使うと、1回の実行あたりのモデルコストは0.47ドル、所要時間は約4分でした。従来の本番構成（記事中では「Model B」と匿名化）では最低36.21ドル、22.5分以上かかっていたため、コストで76分の1、速度で5倍の差になります。
取り組みを主導したのはStackAIのCTOであるFrank Hidalgo氏です。同氏は、コストが顧客に提供できるモデルの選択を制約してきたと述べ、エージェントの効率を上げることで、より高性能で高速なモデルを低い運用コストで提供できるようになったと説明しています。
ボトルネックはキャッシュ漏れ
調査の起点になったのは、モデルへのリクエストがどう組み立てられているかの洗い出しでした。Hidalgo氏はCodex上でGPT-6 Astraを動かしてコードベースを把握させ、各リクエストの構成を説明させています。
そこで判明したのが、固定の指示文とツール定義はプロンプトキャッシュに乗っている一方、ページのテキストやスクリーンショットが積み上がる閲覧履歴はキャッシュされず、毎回フルの料金で送り直されていたという点です。プロンプトキャッシュは、同じ先頭部分を含むリクエストを割安に処理する仕組みを指します。
さらに悪いことに、エージェントはほぼ毎ステップで古いスクリーンショットを捨て、テキストを切り詰めていました。履歴の内容が毎回変わるため、キャッシュの一致が成立しなくなっていたのです。
図1のように、履歴の削り方を変えるだけでキャッシュ判定の結果が変わります。対策として試されたのは、閲覧履歴をキャッシュ対象に含めること、テキストをより多く保持すること、スクリーンショットを毎ステップではなくまとめて削除することの3点です。
144通りの構成を並列検証
検証は総当たりに近い形で行われました。モデルは4種類（他社の小型モデル、従来の本番モデル、その更新版、GPT-6.1 Sol）、履歴の上限は12万文字と48万文字の2種類、キャッシュとスクリーンショットの方針が6種類で、各組み合わせを3回ずつ実行した計144回です。Astraが並列実行できるようコードをリファクタリングしたことで、この規模の比較が現実的になりました。
タスクは公開デモ用の書籍カタログから32冊分について6項目を収集するというもので、最も成績が良かったのはスクリーンショットを20枚まで溜めてから直近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分 |
従来モデルでも最適化によって29分の1までコストが下がっており、改善の大部分がモデルの入れ替えではなくリクエスト設計に由来することがわかります。GPT-6.1 Solでは新方針によって1.97ドルから0.47ドルへと4分の1になり、入力トークンの約89%がキャッシュ経由（非キャッシュ時の5%の価格）で処理されました。
精度面でも差が出ています。履歴の上限を大きい方に設定すると、正しい答えを返した実行は18回中3回から18回中18回へ増えました。履歴を削り過ぎることが、コストだけでなく回答品質も損なっていたことになります。GPT-6系モデルの採用事例としては、性能の高さよりも運用設計の寄与が大きい点が特徴です。
開発プロセスへの示唆
一連の作業は、Asana自身のCommandプラットフォームにセッションと結果を記録しながら進められました。得られた知見はチケットになり、プルリクエストを経て本番の変更として反映され、ブラウザ操作の改善はすでにStackAIに出荷済みです。
Asanaは今後、コスト、実行時間、回答品質を測る検証をプラットフォームの評価体系に組み込む方針を示しています。同社のCPOであるArnab Bose氏は、この取り組みを人間とエージェントのチームが協働した例と位置づけました。Astraは製品機能のリリース前テストにも使われており、エージェントが報告したバグを人間のQA担当者が確認する体制が取られています。
エージェント運用でコストとレイテンシが問題になる場合、モデルの変更より先に確認すべきなのはリクエストの組み立て方だという点が、この事例から読み取れます。履歴やスクリーンショットをどのタイミングで削るかという一見地味な実装判断が、請求額を2桁変える余地を持っていました。
