9月23日、James Shoreが「James Shore: Measuring AI's Unintended Consequences」と題した記事を公開した。AIが開発速度を向上させる一方で生じる保守性の低下・バーンアウト・ベンダーロックインといった「意図しない結果」を定量的に測定・モデル化する手法について詳しく紹介している。
本稿はJames ShoreによるAIの開発インパクト定量化シリーズの第3回にあたる。第1回ではAI投資評価の重要性と避けるべき落とし穴、第2回ではデリバリー速度の測定手法を扱った。今回のテーマは「AIを使い続けることで、じわじわと積み上がるコスト」だ。
「保守性なんて関係ない」は本当か
「バグ修正も保守も、AIがやればいいじゃないか」という声は根強い。だが著者はこれを経済的な問題として正面から捉え直す。
- コードが人間に理解できなければ、機能追加もバグ修正もコストが膨らむ
- バーンアウトが起きれば、パフォーマンスが落ち、人が辞め、採用コストが発生する
- ロックインが発生した状態でトークン単価が上がれば、開発規模の縮小か高騰したコストの甘受かを迫られる
これらは「感情論」ではなく、実際のキャッシュフローに直結する問題だと著者は主張する。一方で、重度のAI活用がコードの可読性を下げるという点には広い合意がある一方、それが実際に問題になるかどうかには意見が分かれており、「だからこそ測る必要がある」という立場だ。
変更コスト（Cost of Change）を中心に据える
著者が「最も重要な一指標」として挙げるのが変更コスト（Cost of Change）だ。変更コストが低ければ複雑な改修も現実的な範囲に収まるが、高くなると単純な変更でも数週間かかり、複雑な変更は事実上不可能になる。
変更コストを直接測るのは難しい。そのため著者は以下の指標を組み合わせて「判断の材料」にすることを勧める。
最も信頼できる指標：バリューアド率（Value-Add Percentage）
バリューアド率とは、開発工数のうち「ビジネスに価値をもたらす作業」が占める割合だ。新機能開発がこれにあたる。対して、バグ修正・インシデント対応・手動テスト・リリース作業などは「ムダ（muda）」※に分類される。
※ムダ：トヨタ生産方式に由来するリーン開発の概念。顧客が直接価値を認めない作業を指す。
著者はこのムダをさらに「裁量的ムダ（技術的負債返済など、自分で選べるもの）」と「非裁量的ムダ（バグ修正・依存関係アップグレードなど、対応せざるを得ないもの）」に分ける。非裁量的ムダが増加傾向にあれば、価値ある仕事に使える時間が侵食されているサインだ。
著者自身がVP of Engineeringだった時期に、このバリューアド率を主要KPIとして運用し、3年間で数値を2倍に改善したと述べている。これにより、ヘッドカウントを増やさずに新規イニシアチブへ人を振り向けることができた。
実用上のポイントは「精度を求めすぎない」こと。日次の工数表は不要で、数日単位の粒度で月次レビューするだけで十分だ。ただし、トレンドが見えるまでに3〜6ヶ月はかかることは念頭に置く必要がある。
その他の補助指標
- **DORAメトリクス**（変更リードタイム、デプロイ頻度、変更失敗率など）：すでに導入済みの組織も多く、変化の傾向を追うのに有効
- トークン使用量：文字通りのコストであり、変更コストの代理指標になり得る。ただしモデル変更やプロンプト変更でも変動するため、あくまで「追加調査のトリガー」として使う
数字だけでは足りない：モデルとシナリオ計画
指標は必然的にノイズが多く遅効性があるため、著者はモデルを作ってシナリオを探索することを強く勧める。モデルは未来を予測するものではなく、「何が起き得るか」を可視化して意思決定を支えるツールだ。
保守性モデル（最優先）
バリューアド開発1ヶ月ごとに、翌年の保守コスト（エンジニア工数）を見積もり、以降は低めの継続コストを見積もる。これをもとに「毎月使えるエンジニアリング工数のうち、実際にバリューアドに使えるのはどれだけか」を可視化するモデルだ。
著者が公開しているスプレッドシートを使ったシミュレーション例が印象的だ。AIによって開発速度が50%向上しても、トークンコストでヘッドカウントが25%削減され、保守コストが2倍になると仮定した場合、長期的には「ほぼ損益分岐点」に戻ってしまう。
AI導入直後は1日あたりのバリューアドコストが1/3以上下がる。しかし保守コストの蓄積により、9ヶ月でベースラインに追いつき、10年後にはベースラインの約2倍に達する。
総生産量で見ても、導入後しばらくはベースラインを上回るが、10年後にはベースラインを約12,000日分下回る。短期的な数字だけを見て「AIは効果あり」と結論づけることの危うさが、このモデルで浮き彫りになる。
コード変更量モデル
コード行数そのものは生産性指標として不適切だが、保守コストの代理指標としては有効だ。コミットを「バリューアド」と「保守」に分類し、バリューアドのコード変更量に対して将来の保守コード変更量を予測する。
著者はオープンソースのtmuxプロジェクトの実データでこのモデルを検証しており、「バリューアド1行あたり、初年度は1行の保守、以降は年0.1行」という単純な仮定が実績データとかなり近い値を示したと報告している。
19年間のデータでは、保守コードが年々増加し、最終的にバリューアドの約2倍に達している。この実績がモデルの妥当性を裏付けている。
ロックインとバーンアウト
ロックインシナリオでは、トークン単価の上昇に応じてヘッドカウントやAI利用量を変化させた場合の影響を、保守性モデルに組み込んで試算する。
バーンアウトについては、1〜10段階の精神的疲労スケールを用いた定期的なチェックインと、その数値の推移を追跡することを推奨している。生産性との相関を見ることで、バーンアウトが実際のアウトプットにどう影響しているかを可視化できる。
まとめ
著者の主張を一言で言えば、「AIの恩恵を享受しながら、意図しないコストに気づかないまま数年後に大きな問題を抱えないよう、今から測定とモデリングを始めよ」ということだ。特にバリューアド率は、軽量な運用でありながら「時間がどこに消えているか」を組織全体で共有するための有力な指標となる。
詳細はJames Shore: Measuring AI's Unintended Consequencesを参照していただきたい。
