AI関連支出の増加に対し、最も一般的な対応は使用制限だ。消費上限、シート数、エージェント起動前の承認など。しかし、この分析によれば、画一的な制限は有用な利用を阻害し、誤った指標を測ることになりかねない。
トークン（言語モデルが処理するテキストの単位）あたりのコストは、消費量を測るものであり、成果ではない。支出の一部は、クエリの再実行や制御不能なループなどの無駄であり、別の一部はソフトウェアを実際に成果として届ける作業だ。単なるカウンターも、支出上限も、この両者を区別することはできない。
成果としてのソフトウェアを測定する
より適切な指標は、承認されたマージリクエストあたりのコスト、すなわちAI支援開発の総コストを、レビューを通過してコードに統合された変更（業界用語で「プルリクエスト」と呼ばれる）の数で割ったものだ。同時に、修正回数や欠陥も追跡する必要がある。さもないと、コストの低い変更が、品質低下を隠してしまう可能性がある。
品質を低下させることなく使用量が増加する中でこのコストが下がるなら、開発者はより多くの消費を有用なソフトウェアに変換していることになる。問題は使用されたトークンの数ではなく、投資が生み出す完了した作業量だ。このバランスを改善するため、二つの手段が提案されている。高価な推論はそれを必要とするタスクに限定すること、そして日常業務のコストを削減することだ。
タスクに応じてモデルを使い分ける
エージェントが自律的にコードを書き修正するエージェント開発では、各ステップで最も強力なモデルを必要としない。最先端のモデル、あるいは企業ポリシーで必要とされるオンプレミスでのフラグシップモデルは、複雑な計画立案や新規の推論に限定できる。コード生成、テスト作成、繰り返しのリファクタリングなどのより単純なタスクは、企業が直接運用できるオープンウェイトモデルに委ねることができる。
ゲートウェイは、各リクエストの複雑さ、データの機密性、コスト、レイテンシーに基づいて振り分けることができる。こうして、最初のモデルは状況が正当化する場合にのみ使用される。著者が要約するように、「例外を計測せよ、ワークロードを計測するな」のだ。
オープンウェイトモデルは、この振り分けをますます実践可能にしている。引用されたソフトウェアエンジニアリングのベンチマークによれば、最高のものは特定のタスクで最先端の性能に迫ることができる。ただし、この知見は全てのコードリポジトリやワークフローでの同等性を保証するものではない。したがって、本番作業を任せる前に、自社のコード、テスト、受け入れ基準を用いて候補モデルを評価することが推奨される。
繰り返し利用の経済性を変える
次に、誰が計算能力を所有するかを決める必要がある。レンタル推論では、呼び出しごとに請求が増える。所有する能力では、コストの大半は最初からコミットされるため、使用量が増えるほど追加の呼び出しは安くなる。
