何が起きたか
Writerの研究チームが、基盤モデルを変えずに「AIハーネス」=モデル呼び出しを実務に組み立てるオーケストレーション層を体系的に最適化する論文を公開しました（arXiv掲載、VentureBeatが報道）。6つの基盤モデルと22の固定されたエンタープライズタスク（グラウンディング・検索、複数ステップのワークフロー、ツール利用、コンテンツ生成）を用い、従来型の本番エージェントループを凍結した状態と、Writer Agent Harnessを比較しました。
結果は、タスクあたりトークンが38%減（14.2k→8.8k）、混合コストが41%減（21セント→12セント）、成功タスクあたりコストは最大61%減、中央値の処理時間は44%減（48秒→27秒）。一方で成功率は78%→81%と品質は落ちていません。モデルのファインチューニングは一切不要で、すべて開発者側の制御範囲にあります。
なぜ重要か
論文が指摘するのは「トークンマキシング（tokenmaxxing）」という業界の悪癖です。巨大なコンテキストウィンドウに生ドキュメントを詰め込み、力任せにトークンを消費する設計です。CTO室のWaseem AlShikh氏は「請求額はタスクあたりトークン×トークン単価だが、多くのチームは後者しか見ていない」と述べています。
特にエージェント型のワークロードでは、ループのたびに膨らむコンテキストを再送信するため、タスクあたりトークンが複利的に増加します。しかもその増加は、トークン単価の下落より速い。値下げは麻酔にすぎず、ループ自体が出血している事実を覆い隠す、という指摘です。出力トークンは全主要プロバイダで入力トークンより大幅に高く、非効率な実行は「静かな予算破壊者」になります。
具体的な打ち手
最適化の主要レバーは、システムプロンプトのキャッシュ、対話履歴のコンパクション、ツール管理、検索戦略、エラー管理です。開発者向けの実践としては、静的要素を上部の安定ゾーン、動的要素を下部の変動ゾーンに分ける「Two-Zoneプロンプト」でキャッシュを効かせる手法や、履歴と中間生成物をウィンドウ外の検索可能ストレージに退避する「コンテキスト・オフローディング」が挙げられます。
ガードレールはモデルに自己申告させず、APIの手前=コード側に置くのが原則です。タスクあたりの厳格なトークン予算、ステップ・ツール呼び出し・再帰深度の上限（生成フェンシング）、失敗時支出のガバナンスという3つのハードチェックを推奨しています。
ただし万能ではありません。検索などを専用サブエージェントに委譲する「サブエージェント・オーケストレーション」が実用水準に達したのは、最も強力な2モデル（Palmyra X6が0.86、Claude Sonnet 4.6が0.85）のみ。Gemini Flash 3.5は0.45、Qwen 3.6は0.42と、小型モデルでは調整トークンがかさんで逆効果でした。足場を増やすほどモデルに文脈保持と遵守を要求するためで、「除去するタスクトークンより多くの調整トークンを足す機能は削れ」という『ハーネス・レバレッジ』の原則が示されています。
💼 事業会社視点：これは自社にどう効くか
日本の事業会社にとって、これは「モデル選定に数カ月かけてオーケストレーションは既製品で借りる」という一般的な構造への警鐘です。AlShikh氏の言葉を借りれば、ハーネスを握る者が自社のユニットエコノミクスを握る。SaaSやAI受託開発の事業者は、粗利がトークン単価ではなく「タスクあたりトークン」で決まる点をKPI化すべきで、Completions Per Million（CPM）を計測指標に据えるのが実務的な第一歩です。
特にAIエージェントを従量課金で提供する日本のSaaSは、値下げ交渉より自社ハーネスの最適化が効きます。成功タスクあたり最大61%のコスト差は、そのまま営業利益率とスケール余地に直結します。一方、プロトタイプ段階での作り込みは過剰で、日次数百万リクエスト規模に乗せて初めて投資回収できる点も冷静に見るべきです。経営者は、ハーネスを使い捨ての「接着剤コード」ではなくテスト・バージョン管理を伴う正式なソフトウェア資産として扱う体制を、いま社内に作るべきです。