AI支援開発のROIを測定する方法と、IBMの実践例
エージェント型AIソフトウェア開発におけるコスト管理とROI測定に関する3部構成シリーズの第2部です。第1部ではAIコストの発生源について説明しました。第3部では、AI支援開発のROIを最適化する方法について解説します。
組織は測定できないものを最適化することはできません。そして現時点では、ほとんどの組織が測定できていません。IBM Institute for Business Valueの研究によると、経営幹部の79％がAIによる生産性向上を実感していると回答している一方で、自信を持ってROIを測定できるのは約29％に過ぎません。このギャップは、データの問題というより、AIのROIが、成果ではなく活動を捉えるメトリクスや、誤解を招く可能性のあるベースラインを用いて評価されていることによるものかもしれません。
この記事では、AI支援開発のROIをより適切に測定する方法、何を測定するか、何と比較するか、そして財務責任者が納得できる形で成果をどのように表現するかについて説明します。次に、IBMのAIトランスフォーメーション組織が、本番稼働しているプログラムでIBM BobのROIを測定するために、このアプローチをどのように適用したかについて説明します。
収集しやすいメトリクスが、必ずしも最も有用とは限りません。トークン・カウントは価値ではなく消費量を表します。チームが何もリリースしていないにもかかわらず、トークンの使用量を2倍にすることもできるためです。より適切な単位は、タスクあたり、プル要求あたり、解決済みチケットあたりのコストなど、成果あたりのコストです。
これに加えて、品質調整済みの生産性も重要です。これは、レビューやテストを通過し、本番環境でも機能するスループットを指します。タスクを最初の試行で正しく完了するAIワークフローは、1回のやり取りあたりのコストが高くなる可能性があります。ただし、やり直しや開発者の時間の浪費につながるワークフローと比べると、成果を得るまでのコストは大幅に低くなります。
すべてのROI計算はベースラインに依存します。ただし、一部のAI ROI分析では、この点が十分に考慮されていない可能性があります。最も一般的なアプローチは、前後の比較です。ただし、AIの導入と同時に、チーム、コードベース、優先順位、人員が変わることも多いため、すべての改善をAIだけの効果とすることは困難です。
自己報告による見積もりではなく、期間を厳密にそろえ、安定したチームと成果物レベルのデータを使用すれば、導入前後の比較も有効です。AI対応チームと、条件の似たAI非対応チームを比較したり、段階的に展開したりすることで、より確かな根拠を得ることができます。
どのような方法であれ、自己報告された生産性は慎重に扱いましょう。METRのランダム化比較試験では、経験豊富な開発者は2025年初頭のAIツールを使用した場合、実際のタスクの完了に19％長い時間を要しました。しかしその後、開発者自身は、AIによって約20％速くなったと推定しました（認識と現実とのギャップは約39ポイント）。
METRが2025年後半に実施したフォローアップでは、エージェント型ツールの成熟に伴い、測定上は小幅な生産性向上が示唆されました。ただし、METR自身もこの推定には不確実性があると注意を促しています。ツールが成熟するにつれて生産性は変化し、自己報告はより楽観的になる傾向があります。開発者の意識は、利用体験や導入状況を理解するうえで有用ですが、客観的なメトリクスに代わるものではありません。
ユーザーと非ユーザーの比較グループを使用する場合は、厳密な方法で比較することが重要です。GitClearは、AIを頻繁に利用するユーザーの生産性が非ユーザーの4～10倍高かったことを明らかにしました。しかし、その差の大部分はAI導入以前から存在していました。自身の過去の実績と比較すると、同じ開発者の生産性は約25％向上していました。誤った比較グループを使用すると、基礎となる測定値がすべて正確であっても、AIの影響力が数倍に過大評価される可能性があります。
最後に、AIの導入が他の変化とは切り離して行われることはほとんどありません。組織がエージェント型開発を導入するのと同じ年に、チームを再編成したり、CI/CDをアップグレードしたり、人員配置を変更したりする可能性もあります。完全にAIの効果だけを特定することはできませんが、それが目標ではありません。目標は、一貫したメトリクス、明示された前提、複数の根拠に基づく信頼性の高い推定値を得ることです。
コホート比較、導入前後の分析、タスクレベルのベンチマークが同じ方向の変化を示している場合、複数の方法で結果が一致していることは、単一の方法から得られる過度に精密な数値よりも価値があります。
開発者レベルの測定には、確立されたフレームワークを活用すると効果的です。エンジニアリング・リーダーには、DORAのデリバリーメトリクスとSPACEフレームワークが広く知られています。具体的には、以下を追跡します。
- 一般的な開発タスクを完了するまでの時間
- 開発サイクル・タイム
- コードレビューにかかる工数
- 必要な再作業
- 不具合流出率
- 既存コードの理解に費やす時間
- 開発者の満足度
次に、AIのメリットの多くは組織内の別の領域にも現れるため、開発現場の成果だけでなく、組織全体にも目を向けましょう。組織レベルの指標には、以下が含まれます。
- 新しいエンジニアのオンボーディング時間
- レガシー環境のモダナイゼーション・スループット
- ライフサイクルの早い段階で検出されたセキュリティー上の問題
- デプロイメントの頻度と変更の失敗率
- コンプライアンス対応の工数とインシデント解決にかかる時間
これらの組織レベルの指標は、エージェント型AIが最大の価値をもたらすことの多い領域です（たとえば、以前は多大な手作業を必要としていた複数ステップの作業など）。また、これらは経営幹部が追跡する成果に最も直接的につながります。
AIのコストは、直接的な使用にとどまりません。信頼性の高い総コストには、人間によるレビュー時間、手直し、ガバナンス、インフラストラクチャーと統合、セキュリティーとコンプライアンス、トレーニング、機能が重複するツールの保守コストが含まれます。トークンの使用量やライセンスだけに基づくROI計算では、投資の一部しか捉えられません。
コストとメリットはどちらも時間の経過とともに現れます。毎月の運用コストや開発生産性の向上など、すぐに現れて測定しやすい効果もあります。一方、製品提供の迅速化、手直しの削減、複数の四半期にわたって測定可能になる運用上の改善など、より長い期間をかけて現れる成果もあります。
最も長期的な効果は測定も最も難しくなりますが、場合によっては最も大きな効果となることもあります（例えば、技術的負債の削減や、熟練した開発者が他の業務に時間を充てられるようになることなど）。これらのメリットを常にAIの効果として正確に特定できるとは限りませんが、長期的なROIを評価する際には、これらも考慮する必要があります。
IBMは、AI駆動型の価値を4つのカテゴリーに分けて測定することを推奨しています。
コスト削減：直接的に削減または排除される費用。
コスト回避：追加雇用、請負業者の延長、再作業などの発生しない将来のコスト。
キャパシティーの創出：同じチームがより多くの成果を生み出すことができます。これは、AI支援開発において最大の価値の源となることが多いものです。
収益実現：以前は非現実的または非経済的であった機能。IBM IBVは、それを新しい機能の創造または手の届かなかった機会を追求する能力と説明しています。
これら4つのカテゴリーのうち、2つについてはさらに詳しく見ていく必要があります。キャパシティーの創出は、コスト削減として報告されるべきではありません。この価値は運用コストの削減ではなく、アウトプットの増加という形で生まれます。この2つを混同すると、財務部門に誤った期待を抱かせることになります。収益創出は定量化が最も難しく、最も厳しく精査されますが、すべての前提を明示すれば、前提に基づくモデルでも十分に成り立ちます。
成熟した実験プログラムに関する研究によると、出荷された機能の約3分の1が測定可能なビジネス価値を生み出し、迅速な納品による収益への影響を推定する際に正当化できるデフォルト成功率として機能します。
多くのCFOが最初に尋ねるのはROIの割合ではなく、投資回収期間、つまり投資がいつ回収されるかです。2つの方法によって、より信頼性の高い回答を得ることができます。
まず、投資の種類に応じて期待値を設定します。対象を絞ったスループットの改善は数四半期以内に投資を回収できる可能性がありますが、より広範なトランスフォーメーションでは、さらに長い期間を要する可能性があります。IBMのCEO調査によると、CEOの85％が、AIによる効率化への投資を拡大した場合、2027年までにプラスのリターンが得られると予想しています。さらに、成長への投資については、その割合が77％となっています。
第2に、投資回収期間は一点の数値ではなく、範囲として提示します。保守的、標準的、楽観的なシナリオを設定し、不確実性を後から発見するのではなく、あらかじめ織り込みます。保守的なケースでも投資が回収されれば、ビジネス・ケースに対する信頼が高まります。
財務部門が認識するもう1つの違いは、先行指標と遅行指標です。導入率と開発者の満足度は、トランスフォーメーションが進行していることを示します。しかし、デリバリーのスピードとビジネス成果こそが、取り組みが成果を上げたことを示します。初期段階のプログラムは、主に先行指標に基づいて判断する必要があります。生産性J曲線に関する研究は、汎用技術で測定可能な成果が現れるには補完的な投資が必要であり、AIプログラムを早い段階で遅行指標だけに基づいて評価すると、その価値を過小評価することになると示しています。
前のセクションで説明した原則は、実際に適用するとより有用になります。IBMのAIトランスフォーメーション組織は、IBMの市場開拓プラットフォームであるRevTech上でIBM BobのROIを測定しました。RevTechは、17の市場にわたる営業、マーケティング、クライアント・エンゲージメント・システムを統合した規制環境です。何百万件もの顧客記録にコンプライアンス上の義務が伴うため、生産性向上の主張を裏付けるには、測定可能な証拠が必要です。
各ステップは、ほとんどの企業がすでに収集しているテレメトリー・データと財務データを使用して応用できます。
ステップ1：すでに管理している価値の単位を選択します。チームは、プル・リクエストを単位として生産性を測定しました。プル・リクエストは、デリバリーの一環としてすでにレビュー、承認、保管されており、豊富なメタデータも備えています。つまり、新たな計測や自己報告による推定値は必要ありません。それに相当するものが何であれ、AI導入の前後で、既存のプロセスが一貫して生成・検証している単位を選択してください。
ステップ2：ベースラインを慎重に設定します。比較可能なコントロール・グループがなかったため、チームは導入前後の比較を慎重に設計しました。導入前後で同じ12週間の期間を設定し、その期間を通じてアクティブな開発者と成果物レベルのデータが存在する一貫したリポジトリー・セットを使用しました。短い期間にすることで、関連性のない組織変更の影響を抑えられ、成果物データを使用することで記憶に頼る必要もなくなります。
ステップ3：価値への換算方法が異なるため、作業を分類します。プル・リクエストは、マージ済みPRを対象に検証され、公開されている精度が0.90を超える自動分類器を使用して、機能開発、欠陥修正、脆弱性修復に分類されました。エラー率を公開することは、分類器そのものと同じくらい重要です。これにより、結果をどの程度信頼すべきかを利害関係者に明確に示すことができます。
ステップ4：スループットを金額に換算します。1つ目のバリュー・ストリームは、スループットの向上です。これは、IBM Bobの使用によって開発者1人当たりに追加で完了したプル・リクエストを指します。計算はシンプルな方法で行いました。開発者1人当たりの1週間の完了プル・リクエスト数の増加に、各タイプのプル・リクエストに要するエンジニアリング工数を掛けました。次に、その値に総人件費を含む1時間当たりの労働単価を掛け、52週間分に年換算しました。
すべての入力には明確な情報源がありました。PR数はリポジトリーのテレメトリーから、工数の見積もりは過去のエンジニアリング・データから、労働単価は財務部門から取得しました。開発者ごとの構造により、モデルをチームまたは組織レベルに簡単に拡張できました。
ステップ5：スループットと品質面でのコスト削減を分けます。欠陥の修正によって生まれる価値は、欠陥が発見された場所によって異なります。非本番環境で欠陥が発見された場合、その価値は主にエンジニアリング時間の節約になります。本番環境に到達していた可能性のある欠陥の場合、その価値は、発生を防げたインシデントとして別のカテゴリーに分類されます。
各PRは1つのバリュー・ストリームにのみ貢献するため、二重計上を防ぎ、結果を前述の4つの価値カテゴリーと整合させることができます。
ステップ6：回避できた損失の価値は、ビジネス部門のためではなく、ビジネス部門と協力して算定します。品質面でのコスト削減額を算定するには、エンジニアリング・チームだけでは判断できない情報が必要です。チームはプロジェクトごとに、アプリケーション・オーナーから1時間当たりのビジネス損失額を取得しました。これには、顧客向けインシデントによる収益損失、レガシー・システムにおける侵害リスク、内部ツールによる生産性損失が含まれます。
脆弱性については、エクスポージャーの低いシステムでは修復時間を、高いシステムでは予想侵害コストを用いる2つの方法で算定しました。両方の方法を適用できる場合、同程度の結果が得られました。ビジネス部門の責任者が算定に関与した見積もりは、通常、財務レビューにおいてより高い信頼性を得られます。
ステップ7：コスト全体を算定します。RevTech分析では、ソフトウェアのライセンス・コストだけでなく、継続的なDevOps、サポート活動、およびIBM Bobを維持するために必要な運用作業が考慮されました。コストと価値の両方に同じ厳密な基準を適用したため、最終的な数値には信頼性があります。
分析の結果、ROIは開発者1人あたりのBobの年間コストの約10倍となり、最大の貢献要因は不具合による損失の回避でした。分析の結果、ROIは開発者1人あたりのBobの年間コストの約10倍となり、最大の貢献要因は不具合による損失の回避でした。
これらの結果は、競争力、オンボーディング、人材などの価値を考慮していないため、控えめな見積もりとして捉えるのが適切です。大部分の作業を担ったのは、2つのステップです。組織がすでに管理している単位で測定することと、ビジネス部門に損失額を設定してもらうことです。すべての入力データは、ほとんどの企業がすでに保有しているシステムと財務データから得られました。
多くの企業にとって、測定のギャップを埋めるために新たなデータを用意する必要はありません。すでに収集しているデータを、財務チームがすでに使用している方法で整理すれば、そのギャップを埋めることができます。
パート3では、先ほど測定した数値を改善する方法として、パート1で説明した3つのレバー全体でコストと品質を最適化する方法について説明します。具体的には、開発者に必要なスキル、リーダーが設定すべき方針、そしてその両方を可能にするためにシステムが提供すべき機能について取り上げます。
パート3の公開時に通知を受け取るには、IBM Thinkニュースレターに配信登録してください。