トークン消費からワークフローの経済学へ：BCGの「Return-on-AI」フレームワークが求めるもの

トークンの請求書からは、推論にいくらかかったかは分かりますが、その作業が承認されたのか、人間によるやり直しが発生したのか、あるいはビジネス上の成果が2週間後に現れたのかまでは分かりません。AIの経済性を管理するには、「ワークフローの実行」と「最終的な成果」を紐付けた、新たな管理単位が必要です。

BCGの提言は有益です。トークンを管理単位とするのをやめ、成功した成果にかかるコストを測定し始めるべきだという考え方です。同社の「AI投資収益率（Return-on-AI）」という枠組みは、人間の知能とトークンコストを合わせた総コストに対して、経済的リターンを重視するものです。また、支出を可視化し、コストを最適化し、価値を証明する（あるいは活動を停止する）ための、ワークフローレベルの運用モデルの必要性も説いています。

考え方は理にかなっていますが、難しいのはその実装です。

モデルゲートウェイはリクエストを監視し、エージェントランタイムはターン、ツール、再試行、一時停止を監視します。財務部門は請求書を確認し、業務システムは案件の完了、支払いの確定、プルリクエストの出荷、エスカレーションの再開などを監視します。しかし、これらの記録を単独で見ても、AIの投資収益率は分かりません。

1. トークンは課金単位であり、ビジネス単位ではない

トークンは依然として重要なテレメトリです。入力サイズ、出力サイズ、キャッシュの動作、モデル呼び出しコストの一部を説明する指標となります。しかし、モデルやプロバイダーをまたいで一貫したビジネス上の意味を持つわけではありません。トークナイザーはそれぞれ異なり、入力、出力、キャッシュ済み入力、キャッシュ作成、推論、音声などのモダリティによって課金ルールも異なります。ある製品の100万トークンが、別の製品の100万トークンと等価であるとは限りません。

同じ価格カテゴリ内であっても、請求コストがトークン量に比例して拡大するとは限りません。コンテキストが大きくなればモデルの挙動は変わり、安価なモデルは再試行回数を増やす可能性があります。簡潔な回答は人間によるレビューの負担を増やすかもしれません。キャッシュヒットは推論呼び出しを減らしますが、ユーザーの現在の状態に対しては古い回答を返す可能性があります。エージェントは、1回あたりのコストは低くても、案件解決までには多大なコストがかかるツールループに陥ることもあります。

BCGは、コストに影響を与える4つの力として、導入の広さと深さ、タスクの強度、コンテキストとループ、モデルの組み合わせを挙げています。この枠組みが重要なのは、それぞれの力が個別のリクエストを超えたレベルで存在しているからです。単一のリクエストは作業内容を把握するには小さすぎ、月次のプロバイダー請求書は責任や価値を割り当てるには大きすぎます。

2. ダッシュボード構築前に2つの契約を定義する

信頼できるワークフロー経済システムは、2つの明確な契約から始まります。それは「コストの範囲」と「成果の定義」です。前者はどのリソースをカウントするかを定め、後者は何をもって成功とするかを定めます。どちらかが曖昧なままだと、成果あたりのコストは、分母が不安定であったり、分子が交渉の余地ありという数値になってしまいます。

コストの範囲

各ワークフローの実行において、意思決定に実質的な影響を与えるコストを捕捉します。これには通常、モデル推論、ツールやインフラの使用料、人間の監視コスト、失敗ややり直しにかかるコストが含まれます。これらのカテゴリは相互に排他的であるか、あるいは割り当てルールによって管理され、同じ修正時間が二重にカウントされないようにする必要があります。目標は誤った精度を追求することではありません。例えば、人間の時間はすべてのクリックを計測するのではなく、ワークフローや役割ごとにサンプリングしてもよいでしょう。重要なのは一貫性であり、ポリシーを比較する際には常に同じ包含ルールを使用することです。

成果の定義

「成功」とは、バージョン管理され、テスト可能な定義である必要があります。サポートワークフローの場合、チケットが7日以内に再開されるのであれば、完了したとは言えません。コーディングの場合、変更がレビューを通過しなかったり、リリースされなかったりすれば、生成されたコード行数は意味をなしません。文書処理の場合、フィールド抽出は、ドメイン検証や後続の照合を通過するまで承認されたとはみなされません。

これは財務報告のための計算式ではなく、運用上の指標です。成果の価値を責任を持って収益化できない場合は、「承認された成果あたりのコスト」を使用し、品質、レイテンシ、リスク、レビュー負荷を併せて報告してください。単に比率を作るためだけに、あらゆる目的を1つのドル換算値に圧縮してはいけません。

3. 帰属関係を紐付ける結合を構築する

コストと成果の契約は、その記録を結合できて初めて有用なものとなります。最適化を始める前に結合の設計を行っておく必要があります。コストが急増した後に所有者や成果のIDを後付けしようとすると、多くの場合、データの欠落が生じるためです。

実用的な記録には、少なくとも以下の情報が含まれます。

• ワークフローの識別情報： ワークフロー名とバージョン、実行ID、環境、所有者、チーム、およびコストセンター。
• 実行の識別情報： エージェント、セッション、ターン、リクエストまたはトレースID、モデルポリシー、プロバイダー、ツール、およびプロンプトやスキルのバージョン。
• コストの根拠： 推論、キャッシュ、ツール、インフラストラクチャ、人間によるレビュー、再試行、および修正にかかるコスト。また、計算を再現するために必要な価格設定のソースとバージョン。
• 成果の識別情報： 成果ID、ソースシステム、暫定または確定状態、評価手法、および確定タイムスタンプ。

カスタムメタデータは、これらを結びつける結合組織の役割を果たします。ゲートウェイリクエストには、ワークフロー実行ID、所有者、環境、顧客または製品の境界、および必要に応じてコストセンターを含めるべきです。ランタイムは、ターンやツールの活動を通じて一貫した実行IDを保持する必要があります。アプリケーションは、記録システム内の最終的な成果の横に、その実行IDを書き込む必要があります。

メタデータが便利だからといって、機密性の高いコンテンツをタグに入れないでください。不透明な識別子を使用し、許可リストを適用し、ビジネス上の詳細は認可された分析環境内で解決するようにします。帰属情報の管理は、可観測性フィールドを新たなデータ漏洩の経路にすることなく、説明責任を向上させるものであるべきです。

4. 成果はコストよりも遅れて発生する

推論コストは通常、数秒以内に判明します。一方、ビジネス上の成果は、数分後、数日後、あるいは数ヶ月後に確定することがあります。コーディングエージェントは今日タスクを完了しても、その変更がリリースされるのは来週かもしれません。サービスの会話は今終了しても、後で再開される可能性があります。営業アシスタントが作成したメールの商業的効果が判明するのは、四半期後になることもあります。

そのため、台帳には以下の状態が必要です。

• オープン： ワークフローが実行中であるか、人間による対応を待機している状態。
• 暫定： 実行は終了しましたが、観測期間は継続しています。
• 承認または却下： 信頼できる情報源（ソース・オブ・トゥルース）が、定義された成果を評価しました。
• 取り消し： 以前に承認された成果が取り消された、再開された、ロールバックされた、または異議が申し立てられた状態です。

これは、本日の完了コストと本日の未完了の成果を比較してしまうという、見落としがちな報告エラーを防ぐためのものです。ダッシュボードには、コホート期間と決済の網羅率を表示すべきです。実行の60%しか評価に足る成熟度に達していない場合、見かけ上の成功あたりのコストは暫定的なものに過ぎません。

5. 相関関係と因果関係を切り分ける

AIの実行に関連付けられた成果は、データベース上の意味では帰属可能ですが、自動的にAIが原因であるとは限りません。季節性、人員配置、ポリシーの変更、製品の変更、選択バイアスなども同じ指標を変動させる要因となり得ます。

重要な意思決定を行う際は、ベースラインを確立し、可能な限り実験的または準実験的な設計（ランダム化されたホールドアウト、段階的なロールアウト、マッチドコホート、中断時系列分析など）を用いてください。少なくとも、本番環境のポリシーバージョンを記録し、ワークフローのセグメント間で同条件の比較を行ってください。

この区別は、人間の労力が消失するのではなく「移動」する場合に特に重要です。アシスタントがドラフト作成を高速化しても、その後のレビュー作業が増加すれば、局所的な生産性指標は向上しても、エンドツーエンドのコストは変わらない可能性があります。分母は、組織の境界を越えてワークフロー全体を追跡しなければなりません。

6. 一度に一つのレバーを最適化し、品質を制約条件として維持する

BCGは、不要なモデル利用の削除、タスクの複雑さによるルーティング、コンテキストとコンポーネントの再利用、トークン管理のためのトレーニングを提案しています。これらは妥当なレバーです。しかし、それぞれが品質、レイテンシ、リスクを変動させる可能性があるため、最適化は単なるコスト削減ではなく、ガードレールを備えたループとして行う必要があります。

タスクが決定論的な場合はモデルを排除する

算術演算、正確なルックアップ、ポリシーのしきい値判定、スキーマ検証、決定論的なルーティングなどは、多くの場合、従来のソフトウェアで行うべきです。これにより、コストを削減し、信頼性を向上させることができます。重要な設計上の判断は、推論を無差別に排除することではなく、曖昧さや判断が必要な場面のために推論を残しておくことです。

タスクの複雑さに基づいてルーティングする

日常的なタスクには小型モデルやオープンウェイトモデルを主力として使い、より困難なケースには高性能なモデルを割り当てるのが適切かもしれません。しかし、ルーティングは約束ではなく実験です。ルートごとのエスカレーション率、再試行回数、承認された品質、レイテンシ、レビュー時間を測定してください。リクエスト単価が下がっても、失敗のループが増えれば、結果として成果のコストは高くなってしまいます。

コンテキストを意図的に再利用する

安定したプレフィックス、プロバイダーのプロンプトキャッシュ、ゲートウェイのレスポンスキャッシュ、バッチ実行、検索の規律、遅延読み込みなどは、繰り返しの作業を削減できます。これらはそれぞれ異なるセマンティクスを持つ異なるメカニズムです。プロバイダーのプロンプトキャッシュはプロンプト処理を再利用しますが、レスポンスは新たに生成されます。正確なレスポンスキャッシュやセマンティックキャッシュはモデルの呼び出しを回避できますが、分離、有効期限、正確性の制御が必要です。バージョン管理されたプロンプトやスキルは再利用性とガバナンスを向上させますが、それ自体がキャッシュ可能性を保証するものではありません。

バインドされたループと出力

ワークフローに適した最大ターン数、ツール試行回数、推論の労力、コンテキスト予算、出力制限を設定してください。また、実行が停止した理由を記録します。停止ルールは、成功、人間への引き継ぎ、ポリシーによるブロック、タイムアウト、予算超過、回復不能なエラーを区別できる必要があります。これらが明確でないと、コスト削減が単なる作業の放棄と見なされてしまう可能性があります。

7. 比較例：安価なリクエストがもたらす高コストな結果

文書レビューのワークフローにおいて、軽量モデルと高性能モデルのどちらかを選択する場合を考えてみましょう。以下の数値は説明のための正規化されたコスト単位であり、ベンチマークデータではありません。

‍