Asana、GPT‑6.1 Sol を用いたブラウザテストでモデルコストを 76 分の 1 に削減

Asana は Codex の GPT‑6 Astra で実験を実施し、GPT‑6.1 Sol 上のブラウザエージェントのワークフローを最適化しました。その結果、実行コストを 76 分の 1 に削減し、速度を 5 倍に向上させました。

Asana は、同社が買収した⁠（新しいウィンドウで開く）プラットフォーム StackAI⁠（新しいウィンドウで開く） を通じて、複数の業務アプリケーションにまたがる作業の自動化を支援しています。StackAI を使えば、顧客はコードを書かずに、ウェブサイトの操作、フォームへの入力、情報収集を行うワークフローを構築できます。Asana の規模では、こうしたワークフローの小さな無駄も積み重なると大きな負担になります。

Asana で StackAI の CTO を務める Frank Hidalgo 博士は、ブラウザエージェントの高速化と実行コストの削減に取り組みました。同氏は Codex の GPT‑6 Astra に、エージェントの調査、改善案の検証、結果の比較を指示しました。手作業なら 1～2 か月かかったと同氏が見積もる作業が、約 1 週間で完了しました。

Asana が計 144 回の実行で行った検証⁠（新しいウィンドウで開く）では、GPT‑6.1 Sol と、ここではモデル A、B、C と呼ぶ他の 3 つのフロンティアモデルをテストしました。この検証で最適化された GPT‑6.1 Sol のワークフローは、1 回の実行あたりの推定モデルコストが平均 0.47 ドル、実行時間が約 4 分でした。モデル B を使用した当初の本番構成と比べ、コストは 76 分の 1、速度は 5 倍になりました。

Hidalgo 氏は調査を迅速に進めるため、まず Codex の GPT‑6 Astra を使ってコードベースの構造を把握し、エージェントがモデルへの各リクエストをどう組み立てているかを説明させました。GPT‑6 Astra は、エージェントが固定の指示やツール定義はキャッシュしている一方、収集し続けるページ本文やスクリーンショットの履歴はキャッシュしていないことを発見しました。このため、リクエストのたびに履歴全体が再送され、通常料金がかかっていました。

さらに、エージェントはほぼすべてのステップで古いスクリーンショットを削除し、テキストを切り詰めていました。編集のたびに履歴が変わるため、単に履歴をキャッシュしても効果はありません。また、情報が失われることで、すでに読んだページをエージェントが再訪する必要も生じかねませんでした。

Hidalgo 氏は GPT‑6 Astra が提案した修正案を確認し、次の 3 つを検証対象に選びました。

• キャッシュの対象をエージェントの閲覧履歴に拡張

• 保持できるテキスト量を増加

• スクリーンショットをステップごとではなく、まとめて削除

GPT‑6 Astra はまず短時間のテストを行い、結果に影響する変数を特定しました。既存のコードは条件を統制した実験を想定していなかったため、続いてリファクタリングを行いました。これにより、単一のフロントエンドとバックエンドで、それぞれ異なる設定のワークフローを多数並列実行できるようにしました。

Astra は検証全体を実施しました。履歴の保持上限を 120,000 文字と 480,000 文字に設定し、キャッシュとスクリーンショット管理の 6 種類のポリシーを、4 つのモデルそれぞれで 3 回ずつテストしました（下表参照）。最も優れた結果を示したのは、スクリーンショットが 20 枚になるまで蓄積し、その後で最新の 1 枚だけを残すポリシーでした。これにより、削除と削除の間、過去の履歴を変更せずに保てる期間が長くなりました。このポリシーと履歴保持上限の拡大を組み合わせたものが、最適化済みワークフローとなりました。各構成では、公開デモカタログから 32 冊の書籍について 6 項目ずつ情報を収集する、同じタスクを実行しました。これは、一部の Asana 顧客が StackAI で実行している処理を代表するものです。

GPT‑6 Astra がワークフローを実行し、リクエスト、使用量の記録、出力を調べ、別のモデルセッションがその作業をレビューしました。各セッションのリクエスト、データトレース、結果は、Asana のソフトウェアデリバリープラットフォーム Command⁠（新しいウィンドウで開く） に記録されました。これにより、チームは後から検証全体を確認できました。Command に記録された調査結果はチケット化され、さらにプルリクエストとなり、変更が本番環境に反映されました。

モデル B では、最適化によって 1 回の実行あたりの推定モデルコストが 36.21 ドル以上から 1.24 ドルへ、29 分の 1 に削減されました（最適化前の実行の一部は、完了前にステップ数の上限に達していました）。GPT‑6.1 Sol の最適化済みワークフローでは、さらに 2.6 分の 1 の 0.47 ドルになりました。最適化済みワークフローでは、すべての実行でタスクが完了し、正しい回答が返されました。

GPT‑6.1 Sol 単体でも、履歴保持上限を拡大した条件で、新しいキャッシュとスクリーンショット管理のポリシーを適用すると、1 回の実行あたりのコストが 1.97 ドルから 0.47 ドルへ、4 分の 1 に削減されました。入力の 89% がキャッシュから供給され、料金が非キャッシュ時の 5% になったため、1 回の呼び出しあたりのコストは約 3 分の 1 になりました。実行時間も短縮されました。モデル B の当初の構成では 22.5 分以上かかっていましたが、GPT‑6.1 Sol の最適化済みワークフローでは約 4 分になりました。

この調査では、履歴管理が、エージェントが回答を生成できるかどうかにも影響することがわかりました。GPT‑6.1 Sol が保持できる閲覧履歴の量を増やすと、回答を生成できた実行は、保持上限が小さい場合の 18 回中 3 回から、大きい場合の全 18 回に増えました。そのすべてが正しい回答でした。Hidalgo 氏が考えるビジネス上の価値は、運用コストを持続可能な水準に保ちながら、より高速で高性能なモデルを顧客に提供できることです。

Asana は StackAI のブラウザ操作機能に今回の変更を反映し、同様の実験を繰り返し行いやすくするツールを開発しています。チームは今後、このテストをプラットフォームの評価機能に組み込み、顧客や社内チームがエージェントを設定する際に、コスト、実行時間、回答品質を比較できるようにする予定です。

Asana は現在、Codex の GPT‑6 Astra を使って、リリース前の製品機能をテストしています。Astra がプラットフォームを操作してさまざまな入力を試し、人間の QA レビュー担当者にバグを報告します。Hidalgo 氏は、これが多数のクラウドエージェントセッションで機能を並列テストする、新しいソフトウェア開発ライフサイクルの基盤になると考えています。

検証の全容は、Asana⁠（新しいウィンドウで開く） と StackAI⁠（新しいウィンドウで開く） のブログでご覧いただけます。