効率性の罠：トークン、TOON、そして可用性をめぐる本質的な問い

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

現在、極めて効率的な推論、トークン圧縮、巧妙なエンコーディング方式が追求されるなか、可用性も自然についてくるかのように、パフォーマンスとコストばかりを追い求めがちです。しかし、そうはなりません。ベンチマーク資料でエンコーディングがどれほど巧妙に見えても、可用性には関係ありません。

最近では、トークン効率化のトレンドを背景に、ソーシャルメディア上でToken-Oriented Object Notation (TOON)が大きな注目を集めました。これは、トークン数に基づく料金体系を踏まえ、推論に必要なトークンを削減するために設計された形式です。その後、パロディが登場しましたが、真剣なイノベーションとして受け止められ、「JSONの終焉」として広まりました。皮肉はテキストでは伝わりにくく、誇大な期待は常に細かなニュアンスより先行することが、改めて浮き彫りになりました。

ここで本当に重要なのは、フォーマット間の争いではありません。これは、パフォーマンス、可用性、信頼性とコストのバランスを取るという、数十年にわたって取り組んできた運用上の課題にほかなりません。ハードコストは、コンピューティングとネットワークの費用として測定されます。ソフトコストは、ユーザーからの信頼、ブランドへのダメージ、運用担当者の作業負荷、顧客離れという形で表れます。連休に向けたキャパシティプランニングを経験したことがある方なら、このバランス調整が目新しいものではないとご存じでしょう。

しかし、AI推論では、可用性に正確性も含まれるようになりました。回答が速くても不正確なシステムは「利用可能」なのではなく、正常に機能していません。午前3時にぬるくなったコーヒーを握りしめ、転職を考えながら変更をロールバックしたことのある運用担当者なら、よく分かるでしょう。

すべてに通用する万能策はない

だからこそTOONも、他の圧縮技術と同様に、理想論ではなく現実的な視点で捉える必要があります。HTTP圧縮はテキストベースのコンテンツには非常に有効だった一方、標準で圧縮されているJPGなどの画像には効果がなかったことを覚えている方もいるでしょう。現在もこの違いは変わりません。構造化データは命令ではありません。

TOONは、構造化データを最適化するよう設計されており、検索精度をわずかに向上させながら、トークンを大幅に削減できるとしています。用途によっては有用かもしれません。しかし、構造だけですべてを捉えられるわけではありません。推論システムやエージェント駆動型システムが扱う対象は、データベースのレコードやAPIレスポンスに限られず、指示、意図、推論経路も含まれます。データのトークン数を削減することと、意思決定を改善することは同じではありません。

エージェントに対するシンプルなJSON命令を考えてみましょう。

{
"action": "create_ticket",
"priority": "high",
"summary": "User cannot access their account",
"user_id": 84713
}

TOONでは、次のように圧縮されます。

action: create_ticket
priority: high
summary: User cannot access their account
user_id: 84713

簡潔でコンパクトです。しかし残念ながら、メリットはそこまでです。エージェントは依然として、actionが文脈上何を意味するのかを解釈しなければなりません。「create ticket」には、確認、場所の特定、担当者の割り当て、分類、ルーティング、関連付けのどれが必要なのでしょうか。TOONはスペースを節約できますが、推論の明確さは向上しません。

A 2025年のarXiv論文（2510.14453）では、別のアプローチとして、自然言語によるツール出力が提案されています。その結果、トークン数を30%以上削減しながら、精度が18%以上向上しました。なぜでしょうか。モデルは、独自の小規模なデータ言語ではなく、主に自然言語でトレーニングされているためです。

このアプローチを用いて、次のように送信します。

ユーザー84713について、優先度の高いサポートチケットを作成してください。問題：ユーザーが自分のアカウントにアクセスできません。

JSONよりトークン数が少なく、TOONより明確で、モデルがすでに行っている思考方法にも合致しています。これは自由形式の創作ではありません。自然言語で表現された、テンプレートの範囲内に限定される指示です。さらに、トークン数が少ないうえに、操作を検出しやすくなるため、意図せずセキュリティ上のメリットも得られます。

教訓はシンプルです。すべての入力が同じではなく、1つの形式ですべてのユースケースに対応することはできません。大規模な構造化データセットを渡す場合は、TOONのような圧縮形式が優れている可能性があります。一方、推論モデルに指示を与える場合は、自然言語テンプレートの方が適している可能性があります。1つのソリューションですべてに対応できると思い込むことが、障害を招くのです。

トークン数は重要だが、最上位の成功指標ではない

トークン数は、AIの成功を測る最上位の指標ではありません。パフォーマンス、信頼性、可用性など、複数の変数間のトレードオフを構成する1つの要素にすぎません。さらに、コストも考慮する必要性が高まっています。1つの変数を最適化しても、システム全体が改善するとは限らず、かえって悪化することもあります。歴史を振り返ると、最も重要な成果ではなく、最も目につきやすい指標を追い求めたエンジニアの例は枚挙にいとまがありません。

推論を提供するには、運用面とビジネス面の両方をバランスよく考慮する必要があります。

• パフォーマンス：システムの応答速度
• 可用性：正しく応答するかどうか
• 信頼性：一貫して応答するかどうか
• コスト：ビジネスが大規模に運用しても維持できるかどうか

トークン数は削減しても、明確さは損なわない。速度は向上させても、推論を犠牲にしない。コストは最適化しても、再試行やエスカレーション、手動レビューに転嫁しない。

業界では、用途に応じて複数の形式を使い分ける形にほぼ確実に落ち着くでしょう。構造化データにはTOON、指示には自然言語テンプレート、互換性にはJSON、さらに特殊なワークロードには別の形式が採用される可能性があります。

まだ初期段階にあり、最終的な勝利を宣言する人は、エンジニアリングではなく注目を追い求めています。目指すべきは、最小または最新の形式を選ぶことではありません。信頼できる結果をもたらす形式を選ぶことです。

コスト削減によって信頼性が損なわれるなら、それはシステムの改善ではなく、障害を後工程に先送りしているにすぎません。

著者について

Lori Mac Vittie特別技術者兼チーフエバンジェリスト | F5

Lori MacVittieは、F5のOffice of the CTOに所属するDistinguished Engineer兼Chief Evangelistであり、アプリケーションデリバリ、自動化戦略、インフラストラクチャに関する深い専門知識を有しています。AIエージェントのガードレール策定、脆弱なマルチクラウドアーキテクチャの分析、スケーラブルなシステムの限界の検証など、複雑な事柄を明快にすることで知られています。アプリケーション開発、ITアーキテクチャ、ネットワークおよびシステム運用の分野で、30年以上にわたる業界経験を有しています。F5入社前は、受賞歴のあるテクノロジー編集者として活躍していました。 MacVittieはコンピューターサイエンスの修士号を取得しており、セキュリティ、クラウド、エンタープライズアーキテクチャにわたる分野で多数の著作を発表しています。また、テーブルトークゲームとビデオゲームをこよなく愛し、チーズについては遠慮なく強いこだわりを語ります。

Lori Mac Vittieのその他のブログ記事