AsanaがGPT-6.1 Solでブラウザエージェントのコストを76分の1に:Codex主導のワークフロー最適化

2026年10月9日、OpenAIはAsanaに関する顧客事例を公開した。数字は目を引く。ブラウザエージェントのテストで、Asanaは推定モデルコストを76分の1に下げ、実行速度を5倍にした。最適化後のワークフローはGPT-6.1 Solで動き、1回あたりの平均推定モデルコストは0.47ドル、所要時間は約4分である。比較の基準は、Model B上の従来の本番構成だった。この二つの数字から単純に計算すると、従来のコストは1回あたり約36ドルになる。最初に断っておく。これはベンダーが公開した事例であり、コストは推定値で、比較はAsana自身が設計した144回の実行による検証から得られたものだ。重要なエンジニアリング上のシグナルではあるが、どのチームにもそのまま当てはまる業界基準ではない。 背景にはStackAIがある。Asanaが買収したこのプラットフォームでは、顧客がコードを書かずにワークフローを組み、エージェントにウェブサイトを操作させ、フォームに入力させ、情報を集めさせることができる。1回の実行では非効率は目立たない。しかしAsanaの規模では、小さな無駄が膨大な呼び出し回数で掛け算される。そこでStackAIのCTOであるFrank Hidalgo博士は、ブラウザエージェントをより速く、より安くすることに取り組んだ。彼はチームを率いて手作業で洗い出すのではなく、CodexのGPT-6 Astraに指示を出し、エージェントの調査、改善案の検証、結果の比較を行わせた。手作業なら1〜2か月かかると彼が見積もる作業は、約1週間で終わった。 この事例で最も学びが大きいのは、診断の過程である。Hidalgoはまず、GPT-6 Astraにコードベースを把握させ、エージェントが各モデルリクエストをどう組み立てているかを説明させた。その結果、エージェントは固定の指示とツール定義はキャッシュしていたが、増え続けるページ本文とスクリーンショットの履歴はキャッシュしていないことが分かった。これが何を意味するか考えてみたい。ブラウザエージェントは1ステップ進むたびに、それまでに見た内容と新しいスクリーンショットをモデルへ渡す。履歴が長くなるほど、各ステップで処理すべき入力は増える。この部分がキャッシュに当たらなければ、同じ内容が1回の実行の中で何度も通常料金で課金され、最初のトークンが返るまでの時間も毎回延びる。無駄はステップごとに積み上がり、入力の合計はステップ数そのものより急に増える。これは仕組みについての妥当な推論である。OpenAIの公開抜粋には、その後の変更点がすべて載っているわけではなく、欠けた項目をこちらで補うべきではない。

次に検証の設計を見る。Asanaは144回の実行を行った。対象はGPT-6.1 Solと、文中でModel A、B、Cと呼ばれる三つの最先端モデルである。この設計の強みは、モデル選択とワークフローの改造が同じ比較表に入っている点にある。同時に、はっきり述べておくべき解釈上の問題も生む。76倍という数字は、最適化したSolのワークフローを、Model B上の従来の本番構成と比べたものだ。つまり二つの変数が同時に動いている。76倍をすべてモデルの手柄にすれば、モデルの役割を過大に見ることになる。すべてワークフローの手柄にすれば、モデル自体の価格や速度の差を無視することになる。抜粋には両者を切り分ける対照が見当たらず、注意深い読者が問うべきはそこである。コストは推定値なので、各社の価格改定で変わる。144回という標本も大きくはなく、結果の安定性にはさらなる反復が要る。

第二の意味は、仕事の進め方にある。AsanaのCPOであるArnab Boseは、これが人間とエージェントのチームの実際の姿だと語った。エンジニアが方向を決め、GPT-6 Astraが実験を回し、結果はCommandを通って本番に入る。この一文には明確な分業の線がある。方向、取捨選択、出荷の判断は人に残り、最も時間のかかる部分、つまりコードを読み、仮説を立て、比較を回し、データを整理する作業はエージェントに渡った。実験の限界費用が下がれば、最適化は手が空く日を待つ必要がなくなり、日常の動作になりうる。だがその分、価値の重心は評価そのものに移る。繰り返せるタスク群があるか。比較できる指標があるか。結果を丁寧に読む人がいるか。これらがなければ、実験を速く回しても雑音が増えるだけである。 業界にとって、この事例は三つのシグナルを送る。第一に、ブラウザエージェントの競争は、できるかどうかから、1回あたり何ドル、何分かかるかへ移りつつある。数十ドルから1ドル未満へ下がって初めて、1日に何千回もの企業利用が現実味を帯びる。第二に、キャッシュの当たり方は、エージェントのアーキテクチャレビューの定例項目にすべきである。特にステップごとに伸びる文脈については、そうだ。第三に、この取り組みの目的の一つは、Asanaが顧客により高性能なモデルを提供できるようにすることだった。コストの削減は、能力のための余地を買う。読者にとって賢明なのは、数字ではなく手法を借りることだ。自分のリクエストのどの部分がキャッシュされていないかを監査し、固定したタスク群で統制比較を行い、モデルの変更とワークフローの変更を別々に試し、最後にコストを成功率と並べて報告する。76分の1というコストは見事だが、エージェントが仕事を正しくこなしてこそ意味を持つ。