先に結論
同社によると、AsanaはGPT‑6 AstraをCodexで調査役として使い、GPT‑6.1 Solの最適化ワークフローで推定モデル費用を76倍改善し、実行時間を約5倍短縮しました。日本企業が同様の手法を試す場合は、まずは限定実験で費用・時間・完了率を確認することを推奨します。限定実験で得た実測を基に、モデル選定、キャッシュ戦略、再現性の担保をルール化すれば本格導入の判断材料になります。
GLOBAL AI BRIEF ・ COMPARISON
何を変えればコストが下がるか？
- STEP 011. 現状のエージェントが送る ・ページテキスト ・スクリーンショット ・会話履歴（全体）
- STEP 022. 最適化の施策 ・履歴バジェットを拡大 ・固定指示と履歴をキャッシュ ・スクショをまとめて保持／整理
- STEP 033. 効果（同社によると） ・入力トークン削減 ・$0.47／ラン（平均） ・処理時間約4分／ラン
- STEP 044. 日本企業の検証ポイント ・限定実験（複数モデル×設定） ・完了率と正答の確認 ・運用のモニタリング体制
一次情報の概要（何が発表されたか）
今回の一次情報はOpenAIが掲載した記事『Asana cuts model costs 76x in browser tests with GPT‑6.1 Sol』の要約と、Asanaの公表内容に基づく編集部の分析です。出典URLは記事末尾に記載します。
同社によると、Asanaは自社のブラウザ型エージェント（StackAI上のエージェント）について144ランの評価を行い、複数のモデルとワークフローを比較しました。
同社の報告では、最適化後の平均推定モデルコストは$0.47／ランで、旧来構成に比べて76倍のコスト改善、実行時間は約5倍の高速化（平均約4分／ラン）を得たとしています（同社によると）。
何をテストしたか（実験の構成）
Asanaの実験は次の要素を組み合わせて行われました：履歴（history）予算の違い、キャッシュ方針、スクリーンショットの扱い、複数モデルの比較。これらを組み合わせた144構成のランで評価したと同社は説明しています。
同社によると、主要な改善点は固定指示とツール定義のキャッシュ化とブラウジング履歴のキャッシュ対象拡張、およびスクリーンショットの蓄積とトリミングポリシーの見直しでした。
具体的には、履歴バジェットを拡大し、スクリーンショットを「一度にまとめて削る」設計に変えたことで再送信する入力の量を劇的に減らしたと同社は説明しています。
数値と効果の詳細（一次情報に基づく固有事実）
一次情報の主要数値は次の通りです（同社によると）：
– コスト削減：最適化ワークフローで76xのコスト改善が報告されている。
– 平均コスト：最適化後の平均推定モデルコストは$0.47／ラン（同社によると）。
– 実行時間：最適化ワークフローの平均実行時間は約4分／ランで、旧来の一部構成に比べ約5倍の高速化が示されています（同社によると）。
– 比較例：旧来の一部ベースライン（Model B）での平均推定コストは上限があり、ある比較では$36.21→$1.24と段階的に改善し、さらにGPT‑6.1 Solの最適化で$0.47へ至ったと報告されています（同社によると）。
仕組み（最適化の技術的ポイント）
Asanaが効果を得た技術的なポイントは主に三点です。
1) 履歴（history）キャッシュの拡大：ブラウザエージェントが収集するページテキストやスクリーンショットの“履歴”を部分的にキャッシュし、毎回のリクエストで再送するデータを削減しました。
2) プレフィックスの階層キャッシュ：固定指示とツール定義だけでなく、増え続けるブラウジング履歴もキャッシュ対象へ広げ、同じ履歴を毎回未キャッシュ料金で再送する状態を改めています。
3) スクリーンショットの蓄積ポリシー変更：実験ではスクリーンショットを最大20枚まで蓄積してから最新1枚を残す方針が最良で、過去の履歴を長く変えずにキャッシュを効かせられたと説明されています。
実務判断：日本企業が踏むべき検証順序
Asanaの手法を社内で検証する際の順序を整理します。編集部は次の5段階を推奨します。
– STEP 01：対象ワークフローの絞り込み。UI操作を伴うエージェントで「繰り返し発生し、同じプレフィックスが使える」業務を選びます（例：テンプレート入力、定型レポート作成）。
– STEP 02：計測指標の定義。評価は単に成功率ではなく、平均推定モデル費用／ラン、平均処理時間、タスク完了率、回答の正しさを分けて計測します。
– STEP 03：限定実験（複数条件を反復比較）。複数モデルとキャッシュ方針を組み合わせ、十分な反復回数で費用・時間・完了率への寄与を分けて確認します。Asanaの公開事例は144ランで比較していますが、自社の回数は業務のばらつきに合わせて決めます。
– STEP 04：閾値の決定と運用ルール化。タスク完了率と回答の正しさが許容水準にあることを確認したら、キャッシュTTL、最大履歴長、スクリーンショット数など運用パラメータを社内ルールとして固定します。
– STEP 05：本番化とモニタリング。導入後はキャッシュヒット率や未完了・不正答の推移を週次で監視し、運用閾値を継続改善します。
この順序の根拠は、Asanaが示す「キャッシュ設計と履歴管理がコストに直結する」点にあります。評価は必ず実環境に近い入力分布で行ってください。
比較表：採用可否・導入条件・確認項目
| 判定軸 | Asanaの最適化で示された条件（同社によると） | 日本企業が確認すべき具体項目 |
|---|---|---|
| コスト効率 | $0.47／ラン（最適化後／同社によると） | 実行頻度でのTCO試算、キャッシュヒット率の見積もり |
| 再現性 | 144ランの系統的実験で比較（同社によると） | 自社データで同規模の回数を回せるか、安定した評価環境の用意 |
| 完了・正答（品質） | 小さい履歴予算では18件中3件が回答。大きい履歴予算では18件すべてが回答し、全件正答（同社によると） | 未完了・不正答時の再試行条件、人のレビュー工数、業務への影響 |
| 運用負荷 | キャッシュ管理・履歴設計の運用が必要 | TTL運用、モニタリングダッシュボード、ロール（SRE/PO）の責任分界 |
適用しない条件・未検証の範囲
Asanaの一次情報が公開しているのは実験結果と設計のスナップショットで、次の点は未検証領域です。
– すべての業務で同様の利益が出る保証はない：UIの複雑さ、入力の多様性、外部APIの変動があるワークロードでは改善幅が小さくなる可能性があります。
– 公開実験と実業務の差：公開実験は、デモ用の書籍カタログから32冊分の6項目を集める同一タスクです。実際の顧客業務での品質や人の確認工数は、この結果だけでは判断できません。
– モデル・インフラ依存：AsanaはGPT系とCodexを用いた事例を示していますが、同等の改善を別ベンダーのモデルで実現できるかは未確認です。
編集部の判断（導入推奨の条件）
編集部の結論を三点にまとめます。
1. 限定対象での短期実験を先に行うことが現実的です。効果は業務特性に依存するため、まずは再現実験で実行コストと品質を確認してください。
2. AIは履歴の保持と読み取りを効率化する役割に限定し、重要な判定は固定ルールへ移す運用が望ましいです。Asanaの事例でも「履歴と読み取りの改善」が主因であり、判定ルールはプログラム側に置いています（同社によると）。
3. 完了率と正答を維持できるかが導入の分岐点であり、未完了や不正答が担当者の確認工数を増やす場合は本番化を再考してください。
実務で使うためのチェックリスト
導入前チェックリスト（短くまとめたもの）：
- 対象業務の明確化（UI操作と定型性の有無）
- 評価指標の定義（平均推定モデル費用、処理時間、タスク完了率、回答の正しさ）
- 評価回数の確保（実験は複数モデル×複数設定で最低数十〜百回）
- キャッシュと履歴の運用設計（TTL、最大履歴長、スクリーンショット数）
- モニタリングとロール定義（SRE・PO・担当者の役割）
よくある質問（FAQ）
Q1: Asanaの数値は自社にそのまま当てはまりますか？
A1: いいえ。同社によると改善は実験条件とワークフロー設計に依存します。自社データでの限定実験が必要です。
Q2: キャッシュはどの程度の効果がありますか？
A2: Asanaはキャッシュと履歴管理の改善が大きな要因だとしています。効果はキャッシュヒット率に比例するため、事前にヒット率試算を行ってください（同社によると）。
Q3: 未完了や不正答が増えたらどうするべきですか？
A3: 履歴予算、キャッシュ、スクリーンショット方針を一度に変えず、条件ごとの完了率と正答を再測定します。本番では再試行条件と人が確認する経路を残してください。
出典・検証範囲
一次情報：OpenAI News “Asana cuts model costs 76x in browser tests with GPT‑6.1 Sol” （公開日：2026‑10‑09、編集部確認日：2026‑10‑11）。本記事は同社の公表に基づき、同社による数値と設計説明を引用して整理・分析しています。
検証範囲：同社の公開記事に記載された実験設計、数値、手法の説明（公開一次情報）。
未検証範囲：第三者環境での再現性、実業務での品質、総TCO、人の確認工数（編集部での実測は未実施）。