メインコンテンツにスキップ

パート6: コストの管理

AI開発についてよく聞かれる問いは「どれだけ速くリリースできるか？」です。より良い問いは「これを所有するにはどのくらいコストがかかるか？」です。ベロシティは本当の経済性を隠します。正直な指標は総所有コストであり、AIワークフローではそれは一つのことに支配されています：トークンエコノミーです。

速さの隠れた負債​

場当たり的なプロンプティングはほぼ無料に見えます — サブスクリプションとカジュアルなプロンプト、ほぼゼロの先行コスト。請求書は後で届き、複利で増えます：

  • トークン消費。 巨大な非構造化ファイルをコンテキストウィンドウに投入し、モデルに未検証の自分のミスを修正させることで、一次通過成功率が低い高価なリトライループが生まれます。失敗した試みはすべて何も得られないためのトークン消費です。
  • 保守の税金。 非構造化の生成コードは一貫性を欠きます。6ヶ月後、エンジニアが誰も設計しなかった「スパゲッティ」をリバースエンジニアリングするのに何日も費やします。
  • セキュリティ修復。 評価ハーネスなしでは、高速なコード生成が高速な脆弱性生成になります。設計時に発見するよりも、本番環境で欠陥を修正する方がはるかにコストがかかります。

構造的なアプローチはこれを逆転させます：スキーマ、テスト、コンテキストへの先行投資をし、各フィーチャーをリリースして保守する限界コストを急激に下げます。構築コストは高くなりますが、所有コストははるかに低くなります。

レバー1：一次通過成功率​

リトライに使わないトークンが最も安価なトークンです。密度が高くシグナルの高いルールファイル（パート1）とうまく管理されたコンテキスト（パート2）は、エージェントの一次通過成功率を高め、コストを消費する試行錯誤ループを直接削減します。コンテキストエンジニアリングは品質のプラクティスだけでなく、コスト管理のプラクティスでもあります。アウトプットを改善する同じ厳密な CLAUDE.md が支出も削減します。

100,000トークンのリポジトリ全体をすべてのプロンプトに渡すことは、スケールでは財政的に実行不可能です。関連するものを取得し、使用するものだけを支払いましょう。

レバー2：タスク別ルーティング​

場当たり的なワークフローでは、すべてに一つの大きなフロンティアモデルを使います — 誤字修正やボイラープレートテスト生成にプレミアム価格を支払います。設計されたワークフローはタスクの複雑さでルーティングします：

  • アーキテクチャ、難しい設計 → フロンティアモデル — 最大の推論が必要
  • 複雑な初期実装 → フロンティアモデル — ハイリスク、曖昧
  • テスト生成 → 小型・安価なモデル — 決定論的、仕様が明確
  • コードレビュー（一次通過） → 小型・安価なモデル — パターンマッチング
  • CI / 監視チェック → 小型・安価なモデル — 繰り返し、範囲が狭い

シンプルなルーティング設定でこれを具体化します：

routing:
  default: small-fast
  rules:
    - match: ["architecture", "design", "migration plan"]
      model: frontier
    - match: ["write tests", "lint", "review diff", "ci check"]
      model: small-fast
    - match: ["implement feature"]
      model: frontier

マルチモデルミックスをオーケストレートすることで、重要な部分のアウトプット品質を維持しながら、決定論的な作業の大部分のコストを下げられます。

レバー3：動的コンテキストとスキル​

これをパート2に結び付けます。すべてを静的に読み込むことは、すべての呼び出しでそれを支払うことを意味します。タスク固有の知識をオンデマンドで読み込まれるスキルに押し込み、ツールをプロンプトに焼き付けるのではなくオンデマンド呼び出しを通じて利用することで、リクエストごとのペイロードを小さく保てます。スケールでは、「常にすべてを読み込む」と「必要なものだけ」の差が、実行可能なコスト構造と実行不可能なコスト構造の差になります。

直感的な試算​

ルールファイルといくつかのスキルに投資した後、一次通過成功率が40%から80%に上がったとします。以前は約2.5回の試行が必要だったタスクが、今は約1.25回で済みます。それは同じアウトプットのためのトークン半減です — まだ1つのタスクもより安価なモデルにルーティングする前の話です。ルーティングをその上に積み重ねると（安価なモデルがテスト生成とレビューを処理し、それが呼び出しの半分かもしれません）、OpExの曲線が急激に曲がります。

自分のワークフローをセットアップする​

  • 速度だけを計測するのをやめ、リリースされたフィーチャーあたりのトークン支出を追跡し始める。
  • 一次通過成功率を高め、リトライループをなくすために特にルールファイルを厳密にする。
  • モデルルーティングを設定する：テスト生成、レビュー、CIには安価なモデル、アーキテクチャと難しい実装にはフロンティアモデル。
  • タスク固有のコンテキストをオンデマンドスキルに移し、毎回の呼び出しで支払わなくて済むようにする。
  • 投資前後のフィーチャーあたりのコストを比較する — 先行投資は継続的な請求額の低下として現れるはずです。