インテリジェンスへの投資対効果を最大化する
David Pan
昨年末にかけて、エージェント型エンジニアリングがようやく実用になり始めました。そして、いったん機能し始めると、すべてが同時に拡大しました。ツールを使うエンジニアが増え、利用するタスクも増えました。さらに、思考やツール呼び出しの増加に伴い、タスクあたりのコストも上昇しました。この3つは掛け算で効いてくるため、多くのエンジニアリングチームでAI支出がJカーブを描くことになったのです。
こうしたチームは、その支出には十分な価値があったと言うでしょう。リリースのスピードが上がり、実際に価値を得ています。しかし、価値があるかどうかにかかわらず、2026年の予算を大幅に超えつつあります。今や、私たちが話をするほぼすべての顧客から、同じような要請を受けます。加速を続けながら、コストを規律をもって管理することです。
言うは易く行うは難しです。ここでは、よく寄せられる質問に対する私の考えをお伝えします。
1. より安価なモデルを使うべきですか？
Fable と Opus はかなり高価なので、もっと安価なモデルを使えないかと考えるのは当然です。ただし、もっともな懸念もあります。安価なモデルの成果物をやり直す必要があるなら、何も節約できていません。二重にコストがかかり、時間も無駄になります。
昨年末、重要なエンジニアリング作業を任せられるモデルは Opus 4.5 だけでした。現在では、それを上回るモデルが十数種類あります。トップモデル間では、知能の差はかなり小さい一方、価格と速度の差は非常に大きくなっています。適切なモデルを選べば、同じタスクを多くの場合、わずかなコストで同等にこなせます。
ただし、適切に選ぶのは簡単ではありません。すべてのタスクで最適なモデルはなく、最先端の状況は数週間ごとに変化します。その比較をエンジニア全員が頭に入れておくのは現実的ではありません。実は、これも AI に任せるべき仕事です。私たちは、まさにこのためにカスタム学習したモデルを搭載するモデルルーターを構築しました。特定のタスクを確実に処理できるモデルを見極め、基準を満たす中で最も安価なモデルにルーティングします。当社のルーターは、Fable と同等のユーザー満足度を 68% 低いコストで実現します。
つまり、より安価なモデルは実際にコストを削減できます。ただし、ルーティングをエンジニアに任せるべきではありません。
2. オープンウェイトモデルを使うべきですか？
原則として、はい。特定のタスクでオープンウェイトモデルが最高のコストパフォーマンスを発揮するなら、モデル構成に含めるべきです。理想的には、他のモデルと同様にルーターの背後に配置します。
ただし、本稿執筆時点では、オープンウェイトモデルはパレートフロンティア上にありません。評価を実行し、表面的な価格だけでなくトークン効率も考慮すると、主要なクローズドモデルは依然として1ドルあたりでより高い知能を提供します。
朗報は、自分で実行しなくてもオープンウェイトモデルの恩恵を受けられることです。主要なラボはいずれもオープンウェイトのエコシステムを注視しており、それはクローズドモデルの価格設定にも確実に影響しています。ですから、これからもオープンウェイトを応援してください。どちらに転んでもメリットがあります。
3. クラウドエージェントを使うべきですか？高額ではありませんか？
今、「ソフトウェアファクトリー」、つまりクラウドエージェントのフリートが24時間体制でソフトウェアを生み出すことに大きな注目が集まっています。エンジニアリングリーダーからよく聞かれるのは、「魅力的ですが、すでに費用をかけすぎています」という反応です。
もっともです。しかし、クラウドエージェントによって新たに発生し得るコストの多くは、すでに毎日あなたの会社で発生しています。エンジニアはすでに、コードレビュー、マージ競合、CIの失敗などを支援するためにエージェントを使っています。ただ、現状ではこれらのタスクにも多くのエンジニアリング時間が費やされ、エンジニアごとにばらつきのある形で実行されています。
たとえばコードレビューを考えてみましょう。諸経費込みのエンジニアの1時間あたりのコストが50かかります。Bugbotのレビューは1ドル未満で、しかも継続的に改善されています。最新バージョンは、3倍以上高速で、22%安く、10%多くのバグを見つけます。この計算に複雑なROIモデルは必要ありません。
クラウドエージェントのワークフローには、シンプルなプレイブックがあります。まず動かし、次に優れたものにし、最後に低コスト化することです。時間はあなたの味方です。月日が経つにつれ、インテリジェンスのコストは下がる一方です。
4. 追跡すべきメトリクスは何ですか？
達成したい目標に対応するメトリクスを選びましょう。通常は3つの段階で考えます。まず導入状況です。実際にツールが使われているかを確認します。次にエンジニアリングメトリクスを測定します。リリースのスピードは上がっているか。効率的にリリースできているか。こうした効果を実証してから、初めてビジネス成果とのつながりを検討します。
導入状況の指標として、コード行数やトークン使用量は避けてください。どちらも見かけだけ整えやすく、かえって逆効果な行動を促しかねません。代わりに、毎日ツールを利用するエンジニアの人数と、どの程度活用しているかを測定してください。
エンジニアリングメトリクスでは、次の指標が有効です。効果の代償として他の面に悪影響が出ていないか把握できるよう、ガードレールメトリクスと組み合わせてください。
- 速度: PRの進行速度、チケット完了率、ストーリーポイントの消化率。AI導入前のベースラインと比較した、プロジェクトのエンドツーエンドの提供速度。
- 効率: 繰り返しタスクの自動化によって削減できた時間、およびそれらのワークフローにおけるタスクあたりのコスト。
- ガードレール: バグ件数、リバート率、コードの入れ替わり。
ビジネスへの影響を測定するのは難しく、簡単な答えがあるとは言いません。AIへの支出が増えるほど、それをビジネス成果に結び付けるよう求められる圧力も高まります。当然のことです。会社の取締役会はエンジニアリングメトリクスには関心がありません。売上と利益への影響を見たいのです。
5. エンジニアごとに利用予算を設定すべきですか？
おそらく、その方がよいでしょう。どのように設定するかは会社によって大きく異なり、唯一の正解となる金額はありません。広く当てはまるヒントをいくつか紹介します。
厳格な上限ではなく、引き上げ可能なソフト上限を設け、最初の引き上げは簡単に行えるようにしてください。そうすることで支出への意識を高めつつ、判断の大部分はエンジニアに委ねられます。その後、増額が大きくなるにつれて、より慎重に検討します。AIへの支出は請負業者を雇うこととそれほど変わらず、そのために白紙小切手を切ることはないでしょう。
また、べき乗則を想定してください。一部のエンジニアは他の人より大幅に多く利用しますが、それは必ずしも悪いことではありません。使用量データでは、パワーユーザーとその他のユーザーの間に大きな差があることが示されており、最も多く利用するユーザーは、多くの場合、会社全体でもAIを最も効率的に活用しているユーザーです。
6. AIへの支出をどのように見直すべきですか？
この答えは気に入らないかもしれませんが、支出は定期的に、財務チームと連携して見直すべきです。ほとんどのソフトウェア企業はすでに、クラウドへの支出を規律を持って追跡・最適化しています。この記事を読んでいるなら、AIへの支出も同じように扱うべき規模になっているはずです。財務チームも喜ぶでしょう。これらの課題はCFOにとって非常に重要な関心事であるため、検討を進める場として CFO Council を立ち上げました。
使用量データを、チーム別、プロジェクト別、ワークフロー別、作業タイプ別の4つに分類します。必要な可視性を確保できているかを判断するには、次のような質問に答えられるかを確認してください。
- 支出のうち、上位3つのプロダクト施策それぞれにどれだけ充てられていますか？
- チームのエンジニアが先月トークンに$10kを費やしました。これは生産性につながる支出でしたか？
- バグ修正にかかるトークンコストの中央値はいくらで、どのように推移していますか？
外れ値や、「不明」に分類される大きな支出項目を徹底的に調べます。すべてを理解し、それがビジネスにどのような価値をもたらしているかに納得できるまで掘り下げてください。
次に、見つけたことに基づいて行動します。AIが真に成果を上げている領域への投資を増やしましょう。ROIの高いユーザーには、予算を減らすのではなく増やしてください。最後に、予算変更はできるだけゼロサムに近づけるようにします。ある領域で大幅な超過が必要なら、その分はどこかから捻出しなければなりません。
7. チームをどのように育成すべきですか？
請求書を支払う立場でなければ、悪い習慣に陥りがちです。多くの組織では、チームが請求書を目にすることすらありません。まずはコストを可視化しましょう。
次に、マネジメントの階層全体に説明責任を浸透させます。現場のエンジニアリングマネージャーには、採用判断や大規模な技術的負債の解消への投資と同様に、チームのAI支出が十分な価値を生んでいることを確認するのも自分の仕事だと考えてもらう必要があります。
この2点を適切に行えば、指導の大半は自然に進みます。エンジニアは最適化を得意とします。コストと成果に対する責任を可視化すれば、効率的な道筋を自ら見つけます。