10月9日、OpenAIが「Asana cuts model costs 76x in browser tests with GPT-6.1 Sol」と題した記事を公開した。Asanaが買収したノーコードAIワークフロープラットフォームのStackAIが、ブラウザエージェントのモデルコストを76分の1（$36.21→$0.47）、実行速度を5倍に改善した実験の詳細が紹介されている。削減の鍵はプロンプトキャッシュの活用と履歴管理の見直しであり、その調査と実験を担ったのは人間ではなくAIエージェント自身だ。
※本記事に登場する「GPT-6.1 Sol」「GPT-6 Astra」はいずれもOpenAIのモデルであり、元記事（2026年10月公開）に明記されている。現時点で一般公開されていないモデルを含む可能性があるため、最新の提供状況はOpenAI公式サイトを参照されたい。
コスト削減の核心：キャッシュと履歴管理の最適化
Asanaは、同社が買収したノーコードワークフロー自動化プラットフォームStackAIを通じて、顧客がWebブラウザを操作するエージェントを構築できるサービスを提供している。このブラウザエージェントのコストが問題だった。
StackAIのCTO Frank Hidalgo氏が調査を依頼したのは人間ではなく、GPT-6 AstraをCodex上で動かしたAIエージェントだ。CodexはOpenAIが提供するクラウドベースのソフトウェアエンジニアリングエージェントで、コードベースの解析・修正・テストを自律的に実行できるサービスである。AstraはまずAsanaのコードベースを解析し、非効率な部分を特定した。
発見された問題は明快だった。ブラウザエージェントは固定の命令やツール定義はキャッシュしていたが、ページテキストとスクリーンショットの閲覧履歴はキャッシュせず、毎リクエストで全履歴を送り直していた。しかも古いスクリーンショットを削除し、テキストをほぼ毎ステップでトリミングしていたため、履歴が変わり続けてキャッシュが効かない構造になっていた。
Astraが提案し、Hidalgo氏が採用した改善策は3点だ：
- 閲覧履歴へのキャッシュ適用範囲の拡大
- 保持できるテキスト量の増加
- スクリーンショットを毎ステップではなくバッチで削除
144回の実験を1週間で完走
コードは並列実験向けに設計されていなかったため、Astraはコードをリファクタリングしてひとつのフロントエンド・バックエンドで複数のワークフローを並列実行できる構造に書き換えた。その上で144回の実験を自律的に実施した。
実験の内訳は、履歴バジェット（12万文字・48万文字）× キャッシュ・スクリーンショットポリシー6種 × 4モデル × 各3回。タスク内容は「公開デモカタログから32冊の書籍情報を6フィールドずつ収集する」という、StackAI顧客の実際のユースケースを再現したものだ。
比較対象となったモデルは下表の通り（競合モデルはA〜Cと匿名化されている）：
| モデル | 概要 | 価格 |
|---|---|---|
| Model A | 別フロンティアラボの小型モデル（2025年秋リリース） | GPT-6.1 Solの半額 |
| Model B | 元の本番モデル（2026年夏リリース） | GPT-6.1 Solと同価格 |
| Model C | Model Bの更新版（2026年秋リリース） | GPT-6.1 Solと同価格 |
| GPT-6.1 Sol | OpenAIのモデル | — |
「寝る前に
/goalをセットして、朝起きたら結果を確認するだけだった。手作業なら1〜2ヶ月かかる作業が、約1週間で終わった」
— Frank Hidalgo PhD（StackAI CTO at Asana）
実験結果と次のアクションはAsanaのソフトウェアデリバリープラットフォームCommandに記録され、チケット→プルリクエスト→本番リリースの流れで展開された。
数字で見る効果
最適化の結果は具体的だ：
- 元の本番モデル（Model B）の推定コスト：1回あたり$36.21以上 → 最適化後で**$1.24**（29分の1）
- GPT-6.1 Solの最適化ワークフロー：**$0.47**（Model B最適化版の2.6倍安い）
- 元のModel Bとの比較では76分の1のコスト、5倍の速度（22.5分以上 → 約4分）
コスト削減の主因はプロンプトキャッシュの活用だ。GPT-6.1 Solでは入力トークンの89%がキャッシュから供給され、未キャッシュ価格の5%のコストで処理された。プロンプトキャッシュとは、同一または類似のプロンプト先頭部分を再利用することでAPIコストを大幅に削減する仕組みで、OpenAIのAPIではPrompt cachingとして提供されている。
また、履歴管理の変更は精度にも直結した。GPT-6.1 Solに大きな履歴バジェット（48万文字）を与えたところ、正答を返した実行数が18回中3回から18回中18回へと改善した。
「コストがネックで、これらのワークロードに提供できるモデルが制限されていた。エージェントを効率化することで、より良いモデルを顧客に提供しながら運用コストを下げられる」
— Frank Hidalgo PhD（StackAI CTO at Asana）
次のステップ：継続的なエージェントテストへ
今回のブラウザナビゲーション改善はすでにStackAIに反映済みだ。Asanaは現在、GPT-6 Astraをリリース前のプロダクト機能テストにも活用している。Astraがプラットフォームを実際に操作してバグを発見し、人間のQAレビュアーに報告する仕組みだ。
また、今回のような実験を繰り返しやすくするツールの開発も進めており、将来的にはコスト・実行時間・回答品質の比較をプラットフォームの評価フローに組み込む計画だという。
「出荷速度はもはやボトルネックではない。人間の注意力がボトルネックだ。すべてのエンジニアがエージェントの群れを率いるPMになる世界に近づいている」
— Frank Hidalgo PhD（StackAI CTO at Asana）
詳細はAsana cuts model costs 76x in browser tests with GPT-6.1 Solを参照していただきたい。
