Asana、GPT-6.1 Sol でブラウザエージェントのコストを76分の1に

Asanaは、限られた工学上の課題を、本番でエージェントを運用する誰にとっても参考になる事例に仕上げた。同社のStackAIは、コードを書かずにウェブサイトを巡回し、フォームに入力し、情報を集めるワークフローを顧客が構築できるプラットフォームである。Asanaの規模では、ブラウザエージェントのわずかな非効率が膨大な実行回数に掛け合わされる。StackAIのCTOであるFrank Hidalgo博士は、このエージェントを速く安くしようと考え、CodexのGPT-6 Astraに調査、改善案の検証、結果の比較を指示した。公表された成果は明快である。GPT-6.1 Solで最適化したワークフローは、推定モデルコストが平均0.47ドル、1回あたり約4分で、モデルBで動いていた従来の本番構成より76倍安く、5倍速かった。Hidalgo氏は、手作業なら1〜2か月かかる作業だったと見積もっており、実際には約1週間で終わった。

原因は、エージェントがモデルへのリクエストを組み立てる方法にあった。GPT-6 Astraはまずコードベースを整理し、各リクエストがどう作られるかを説明した。そこで分かったのは、エージェントが固定の指示とツール定義はキャッシュしていたが、収集したページテキストとスクリーンショットから成る増え続ける履歴はキャッシュしていなかったことである。そのため、毎回のリクエストで履歴が全額で再送されていた。さらにエージェントは、ほぼ毎ステップで古いスクリーンショットを捨て、テキストを切り詰めていた。この編集のたびに履歴が変わる。プロンプトキャッシュは安定した先頭部分に対して効くため、履歴の前方が変われば後ろ全体が無効になる。履歴だけをキャッシュしても効果はなかっただろう。また、情報を失えば、すでに読んだページを再訪する必要が生じかねない。キャッシュ、保持量、削除のタイミングは一つの設計問題であり、一部だけを直しても請求額は変わらない可能性がある。

Hidalgo氏はGPT-6 Astraが示した修正案を確認し、三つを試すことにした。キャッシュを閲覧履歴に広げること、保持できるテキスト量を増やすこと、スクリーンショットを毎ステップではなくまとめて削除することである。Astraはまず短い試験でどの変数が効くかを見極めた。既存のコードは対照実験を想定していなかったため、次に、一つのフロントエンドとバックエンドで多数のワークフローを、それぞれ別の設定で並列実行できるようにリファクタリングした。そのうえで本実験を実施した。履歴予算は12万文字と48万文字の2通り、キャッシュとスクリーンショットの方針は6通りで、各条件を4つのモデルで3回ずつ試した。合計は144回である。最良の方針は、スクリーンショットを20枚まで蓄積してから最新の1枚だけに戻すものだった。削除と削除の間は過去の履歴が長く変わらないため、キャッシュが有効なまま保たれる。これに大きな履歴予算を組み合わせたものが、最適化されたワークフローとなった。

実験の設計にも注目したい。どの構成も同じ課題を実行した。公開デモカタログから32冊の書籍それぞれについて6つの項目を集めるもので、Asanaの一部の顧客がStackAIで実行している作業を代表している。比較した4モデルは、GPT-6.1 Solと、別のフロンティアラボの3モデルである。モデルAは2025年秋に公開された小型で安価なモデルで、価格はGPT-6.1 Solの半分。モデルBは従来の本番で使われていた2026年夏公開のモデルで、価格はGPT-6.1 Solと同じ。モデルCはモデルBの更新版で、2026年秋公開、価格は同じである。4モデルのうち3つが同価格か安価であるため、コスト差の大半はワークフローがキャッシュをどれだけ活用できたかによると読める。公表値から0.47ドルに76を掛けると、従来の1回あたりコストは約36ドルとなる。これは本稿の概算であり、Asanaが開示した数値ではない。

実験を取り巻く運用も、結果と同じくらい重要である。GPT-6 Astraがワークフローを実行し、リクエスト、使用量記録、出力を調べ、別のモデルセッションがその作業をレビューした。すべてのセッションのリクエスト、データトレース、結果は、Asanaのソフトウェア配信基盤Commandに記録され、チームは後から研究の全体を確認できた。Commandでは、知見がチケットになり、プルリクエストになり、変更が本番に届いた。Hidalgo氏は、寝る前に/goalを設定し、朝に結果を確認したと述べている。AsanaのCPOであるArnab Bose氏は、エンジニアが方向を決め、GPT-6 Astraが実験を行い、成果がCommandを通じて本番に入ったと要約した。人とエージェントのチームの具体像であり、各段階に記録が残る。

業界への示唆は三つある。第一に、エージェントのコストを決めるのはモデルの単価よりも文脈設計である。4モデル中3つが同価格か安価であるなら、決め手は、長く伸びていく各リクエストの先頭部分がキャッシュから提供されたかどうかになる。トークン単価だけを比べるチームは、より大きなてこを見逃しかねない。第二に、エージェントでエージェントを改善できるのは、実験が再現可能で、証拠が追跡できる場合に限られる。Asanaは対照比較を可能にするためにコードを改め、すべてのトレースを一つのシステムに残した。個々の設定より、この規律のほうが真似る価値がある。第三に、数字は慎重に読む必要がある。単一の課題、公開デモカタログ、請求額ではなく推定コストという条件である。手法が有効であることは示すが、すべてのブラウザワークフローで76倍になることを保証はしない。本番へエージェントを移すチームは、まずリクエストのどこがキャッシュされ、どこが毎ステップ変わるかを点検し、小規模な対照実験で確かめてから展開するのが現実的である。1〜2か月の手作業を1週間に縮めたことは、工数の節約にとどまらず、試行の敷居を下げた点でも意味が大きい。