AI は組織の強さも弱さも増幅する

by

生成 AI を導入すると、組織はそれまで持っていなかった生産能力を外部から追加できるように見える。コードを短時間で生成し、既存コードを説明し、仕様書やテスト項目の下書きを作り、複数の実装案を比較できる。人間が一つずつ読み書きしていた作業の一部を AI が並行して処理できるため、個々の工程だけを測れば、短時間に作成できる成果物の量は増える。

ただし、ソフトウェア開発で必要なのは成果物を生成することだけではない。要求として採用する内容を決め、既存システムへの影響を確認し、変更をレビューし、テストによって期待した挙動を確認し、安全に本番へ反映する必要がある。本番へ出した後には、障害や利用状況を観測し、その結果を次の要求へ戻さなければならない。コード生成が 2 倍になっても、レビュー、テスト、デプロイが従来と同じ処理能力のままなら、増えた変更はその工程で待つことになる。生成工程の高速化は、組織全体の処理能力を同じ割合で増やすのではなく、それまで生成速度の後ろに隠れていた制約を前面へ出す。

既稿「AI は思考設計格差を拡大する」では、生成 AI によって知識へ到達する費用が下がっても、問いを立て、得られた情報を評価し、複数の情報を統合して判断する能力まで均等になるわけではないと論じた[1]。そこで扱ったのは、同じ AI を利用できる個人の間でも、AI の出力をどのような思考過程へ組み込めるかによって成果が変わるという構造である。

「生成 AI の競争軸は、モデルから業務実装へ移る」では、同じ構造を企業による AI 利用の入口まで広げた。モデルの性能が上がり、複数の事業者から高性能なモデルを利用できるようになると、モデルへアクセスできること自体では差を作りにくくなる。そこで差になるのは、社内データ、業務手順、権限、既存システム、評価基準へ AI を接続し、実際の業務として動かせるかである[2]。

業務へ接続した後には、さらに別の差が現れる。同じ AI を開発組織へ導入し、同程度にコード生成を高速化できても、増えた変更を処理できる量は組織ごとに異なる。設計情報が更新されているか、内部データへ短時間で到達できるか、変更を小さく管理しているか、自動テストが十分に整備されているか、レビューが特定の担当者へ集中していないか、デプロイを安全に反復できるかによって、生成された変更が本番まで到達する割合と時間が変わる。

2025 年の DORA 調査は、この差を AI 単体の性能ではなく、AI が導入される組織側の条件との関係として分析している。そこで示された中心的な整理は、AI が高性能な組織の強みと、苦戦している組織の弱みの双方を増幅するというものである[3]。AI を追加すれば既存の組織能力が不要になるのではなく、AI によって作業量や変更速度が増えるほど、それを受け止める組織の構造が成果へ強く反映される。

この関係を考えると、AI 導入の評価を利用者数や生成コード量だけで行うことはできない。生成された変更がレビュー待ちとして積み上がれば、実装工程の生産性向上は組織全体の処理量へ変換されていない。逆に、変更を小さく分割し、自動検証を短時間で返し、安全な経路で継続的に本番へ届けられる組織なら、増えた生成能力を利用者への価値へ変換しやすい。AI によって追加された能力の大きさだけでなく、その能力を組織がどこまで吸収できるかが、最終的な成果を決める。

1. AI を導入しても、組織能力は手に入らない

1.1 個人の能力差から、組織の能力差へ

一人の開発者が AI を使って完結できる作業なら、成果を左右する条件は比較的見えやすい。生成されたコードを読めるか、要求と一致しているか判断できるか、既存コードとの不整合を見つけられるか、失敗したときに原因を切り分けられるかである。AI が誤ったコードを生成しても、利用者自身が誤りを発見して修正できれば、その時点で失敗を閉じ込められる。

組織では、変更が一人の手元で完結しない。実装されたコードはレビュー担当者へ渡り、自動テストと手動確認を通り、必要に応じてセキュリティ確認や運用部門との調整を経て、本番へ反映される。変更内容によっては、別チームが管理する API、データベース、認証基盤、監視設定、運用手順も同時に変更しなければならない。実装者が AI によって短時間で作業を終えても、後続工程の処理能力や組織間の調整時間が変わらなければ、利用者へ届くまでの時間は同じ割合では短くならない。

たとえば、あるチームで一日に作成できる変更が AI によって 5 件から 10 件へ増えたとする。レビュー担当者が一日に確認できる量が 5 件のままなら、初日に 5 件が未処理として残る。翌日も 10 件の変更が追加され、5 件しかレビューできなければ、未処理は 10 件になる。実装工程では生産性が 2 倍になっているにもかかわらず、レビュー工程を通過できる量は変わらず、組織全体の処理量も増えていない。

待ち行列が長くなると、単に完了が遅れるだけでは済まない。レビューを待っている間に別の変更が同じコードへ入れば、作成時には成立していた前提が変わる。差分が大きくなればレビュー担当者が確認すべき範囲も増える。指摘を受けて実装者へ戻された時点では、なぜその実装を選んだのかという文脈を再確認する必要も生じる。生成速度の向上が後工程の処理能力を超えると、待ち時間の増加が変更の陳腐化と再確認を生み、その再確認がさらにレビュー能力を消費する。

工程 AI による直接的な変化 処理能力が追いつかない場合 組織側で必要になる能力
要求・設計 要求候補、設計案、仕様書の下書きを短時間で増やせる。 比較対象だけが増え、採否を決める人間の判断待ちが増える。 利用者価値、費用、技術制約から採用する要求を絞り込む必要がある。
実装 コード生成、修正、既存コードの説明を高速化できる。 変更量が増え、後続工程へ流入する差分が処理能力を上回る。 変更を小さく分け、追跡可能な状態で統合する必要がある。
レビュー レビュー補助を利用できる一方、レビュー対象そのものも増える。 未確認の変更が滞留し、差分の陳腐化や競合が起きやすくなる。 自動検査と人間の判断を分担し、確認すべき変更を短時間で絞り込む必要がある。
テスト テストコードや試験ケースも生成できる。 生成されたテストが同じ前提に依存すると、実装とテストが同時に誤る可能性が残る。 再現可能な自動検証と、実装とは独立した期待値を用意する必要がある。
デプロイ 本番へ投入できる変更候補が短時間で増える。 手作業や承認待ちが残っていると、リリース待ちの変更だけが増える。 反復可能なデプロイ経路と、失敗時に短時間で切り戻せる仕組みが必要になる。
運用・改善 ログ分析、障害原因の候補、改善案の生成を支援できる。 生成された改善案を利用者の実態と照合できなければ、変更量だけが増える。 本番で観測した結果を要求と優先順位へ戻すフィードバック経路が必要になる。

工程ごとに見ると、AI は複数の場所を高速化できる。しかし、各工程は独立していない。要求段階で候補が増えれば採否判断が増え、実装量が増えればレビューとテストへ流入する仕事が増え、リリース候補が増えればデプロイと運用が処理する変更も増える。前工程の生産能力を上げることは、後工程へ渡す仕事量を増やすことでもある。

このため、AI による高速化の効果は、AI が処理した工程だけでは評価できない。実装が 2 倍になったときにレビューも 2 倍必要になるとは限らないが、増えた変更をどこかで確認し、統合し、本番へ届けなければ組織成果にはならない。ある工程の制約を解消すると、次に処理能力の低い工程が全体の速度を決める。AI がコード生成の制約を小さくするほど、変更管理、レビュー、テスト、デプロイ、利用者からのフィードバックといった別の組織能力が、全体の制約として見えやすくなる。

1.2 組織能力は、ツールの購入とは別に存在する

AI の利用契約は外部から購入できる。組織にアカウントを配布し、より性能の高いモデルへ切り替え、利用上限を増やすこともできる。導入作業だけを見れば、同じ製品を契約した複数の会社は同じ AI 能力へアクセスできる。

一方、AI が接続される組織内部の状態は購入だけでは揃わない。設計文書が何年も更新されていれば、AI は古い前提を参照する可能性がある。業務データが部門ごとのシステムへ分断されていれば、一つの要求を理解するために複数の情報源を人間が探して補う必要がある。自動テストが不足していれば、生成された変更が増えるほど人手による確認量も増える。デプロイに複数部署の申請と承認が必要なら、実装が一日で終わっても本番反映までの待ち時間は残る。

これらは AI の推論性能を上げても直接は解消しない。モデルが既存コードを正確に読めるようになっても、どの設計書が現在有効なのかという組織内の事実が整理されていなければ、正しい文脈を選べない。より大量のコードを生成できるようになっても、変更を統合して安全性を確認する経路が同じなら、後工程へ流入する量だけが増える。AI の性能向上と組織内部の処理能力は、別々の変数として存在している。

DORA 2025 は、AI の導入効果を左右する条件として、明確な AI 利用方針、健全なデータ環境、AI から利用可能な内部データ、強いバージョン管理、小さな単位での作業、利用者中心の開発、高品質な内部プラットフォームを挙げている[3]。ここで列挙されているのは、モデルのパラメータ数や生成速度ではない。AI に何をさせるかを決め、必要な文脈を渡し、増えた変更を制御し、安全な経路で利用者へ届けるための組織側の能力である。

この区別を置くと、AI 導入によって起きる現象を説明しやすくなる。同じモデルを使う二つの組織で、一方は設計文書とコードが同期し、小さな変更を自動テストして継続的に本番へ届けられる。もう一方は情報が分断され、大きな変更を長期間保持し、レビューとリリースを担当者の手作業へ依存している。前者では AI が増やした変更を既存の経路へ流せるが、後者では生成速度が上がるほどレビュー待ち、確認作業、調整作業が増える。

組織が AI を導入するとは、完成した組織能力を外から移植することではない。既存の仕事の流れへ、新しい生成能力を追加することである。その能力がどこまで成果へ変換されるかは、追加された AI の性能だけでなく、接続先の情報、変更管理、検証、デリバリーがどの程度の仕事量を受け止められるかで決まる。

この構造では、AI は既存の弱点を覆い隠すより、むしろ表面化させる。コード生成が遅かった時代には、レビュー工程に余裕があるように見えていても、単に前工程から十分な仕事が流れていなかった可能性がある。生成量が増えて初めてレビュー待ちが常態化すれば、組織の本当の制約が実装ではなくレビュー能力にあったことが分かる。AI によって一つの制約が小さくなるほど、それまで隠れていた次の制約が観察可能になる。

2. コード生成が速くなっても、価値提供まで速くなるとは限らない

2.1 一工程の高速化と、全体の高速化は違う

AI による開発支援を評価するとき、最初に分ける必要があるのは、個人が作業を終えるまでの速度と、組織が変更を利用者へ届けるまでの速度である。コード生成、既存コードの説明、テストコードの作成が速くなれば、実装者が一つの変更を作るまでの時間は短くできる。しかし、その変更はレビュー、検証、統合、リリースを通過しなければ利用者には届かない。前工程で短縮した時間が後工程の待ち時間へ置き換われば、個人の作業時間は減っても、組織全体のリードタイムは同じだけ短くならない。

2024 年の DORA 調査では、この違いが実際の測定結果にも現れている。AI 利用の増加は、個人の生産性、作業の流れ、仕事の満足度とは正の関係を示した一方、ソフトウェアデリバリーの処理量と安定性には負の関係が観測された[4]。これは、AI が開発を一律に遅くしたことを意味しない。個人側の指標と、変更を安全に本番へ届ける組織側の指標が、同じ方向には動いていなかったことを示している。

たとえば、実装者が一つの変更を 4 時間で作っていた状態から、AI によって 2 時間で作れるようになったとする。実装だけを測れば生産性は 2 倍である。しかしレビュー開始まで 1 日待ち、テスト環境の準備に半日かかり、リリース承認にさらに 1 日必要なら、利用者へ届くまでの時間の大部分は実装以外にある。実装時間を半分にしても、全体の所要時間は半分にはならない。

さらに実装量そのものが増えると、後工程には別の影響が生じる。従来は一日に 5 件しか流れてこなかった変更が 10 件になれば、レビューとテストが一日に 5 件しか処理できない限り、残りは待ち行列になる。待ち行列が伸びると、変更作成から確認までの時間が延び、その間に周辺コードや前提条件が変わる可能性も高くなる。確認時点で追加調査や競合解消が必要になれば、増えた変更量が後工程の一件当たり処理時間まで押し上げる。

このため、一工程の高速化には二つの結果があり得る。後工程にも十分な余力があれば、実装時間の短縮をそのまま価値提供の短縮へつなげられる。後工程がすでに限界に近ければ、前工程で増えた処理量は滞留へ変わり、組織全体では別の制約が支配的になる。AI の効果を判断するには、生成工程で何分短縮したかだけではなく、その変更が最終的にどこまで流れたかを見る必要がある。

2.2 生成能力が上がると、制約は後工程へ移る

この構造を具体的に示すのが、2026 年に公開された企業内の縦断研究である。研究では 802 人の開発者と 196,212 件の pull request を分析し、一人当たりの処理量が 2026 年 4 月には施策前の 2.09 倍へ達した。一方で、レビュー担当者一人当たりの負荷もおおむね倍増し、レビュー工程では自動化への依存が強まった[5]。

この研究は観察研究であり、処理量の増加をすべて AI の因果効果として分離したものではない。それでも、変更を作る側の供給量が増えれば、受け取る側の仕事量も増えるという工程間の関係は明確に観察できる。実装者が短時間で多くの pull request を作れるようになると、レビュー担当者はより多くの差分を確認しなければならない。レビュー担当者の人数や確認能力が同じ割合で増えなければ、一人当たりの負荷が上がる。

負荷の増加に対して、組織はレビューを高速化する仕組みを導入するか、レビュー対象を減らすか、変更単位を小さくするか、担当者を増やす必要がある。何も変えなければ、AI が解消した実装工程の制約がレビュー工程へ移る。AI による高速化はボトルネックそのものを消したのではなく、システムの中で最も処理能力の低い場所を変えたことになる。

ただし、AI を利用すれば常に変更供給量が増えるわけでもない。成熟したオープンソースのコードベースを長年扱ってきた熟練開発者 16 人、246 件の実タスクを対象とした 2025 年の無作為化比較試験では、当時の AI ツールを利用できた条件の方が完了時間は 19% 長かった[6]。

この結果では、開発者は対象リポジトリをよく理解しており、自分で直接変更する場合には、ファイルの場所、既存設計、暗黙の制約をすでに把握していた。AI を使うと、指示を書く、生成結果を待つ、出力を読む、誤った変更を修正するといった追加作業が発生する。既存知識によって人間自身の実装がすでに速い環境では、AI に委譲するための調整費用が、生成による短縮分を上回る場合がある。

つまり、AI による生産性向上は、モデル性能だけから決まらない。対象コードへの習熟度、タスクの複雑さ、品質要求、AI へ渡せる文脈、出力を確認する費用によって、同じ AI でも正味の効果が変わる。前工程の供給量が必ず増えるわけではなく、増えた場合にも、その増分をどこまで後工程が処理できるかという別の条件がある。

2026 年の縦断調査では、この変化が開発者の時間配分にも現れている。82% の参加者がコードを書く時間の減少を報告する一方、AI への指示、生成結果の評価、修正に使う時間が増え、仕事の重心が生成から検証へ移っていた。研究者は、AI の出力を指示し、評価し、修正する仕事を「監督的なエンジニアリング作業」として整理している[7]。

コードを書く時間が減っても、変更を正しいと判断する仕事まで同じ割合で減るとは限らない。AI が実装案を短時間で作れば、人間はゼロからコードを書く代わりに、その案が要求を満たすか、既存設計と矛盾しないか、テストが十分かを確認する。作業の総量が単純に消えるのではなく、生成から評価へ配分が変わる。

観測された状況 直接起きていること 組織全体で現れる制約
pull request の処理量が増える 実装側からレビュー側へ流れる変更量が増える。 レビュー能力が追いつかなければ、一人当たりの確認負荷と待ち時間が増える。
熟練者が AI を使うと遅くなる場合がある 指示、待機、確認、修正の費用が発生する。 既存知識による直接作業より委譲費用が大きい環境では、AI が新たな摩擦になる。
コードを書く時間が減る AI が実装作業の一部を代替する。 生成結果を評価し、統合し、修正する作業の比率が上がる。

これら三つの研究は、対象、研究方法、AI の利用条件が異なるため、同じ効果量として比較することはできない。一方で、共通して否定されている見方がある。AI の能力を「コード生成速度」という一つの値だけで測り、その値をそのまま組織の生産性へ置き換える見方である。

実装が速くなれば、変更供給量が増え、レビューやテストへ流れる仕事が増える。生成を AI に任せれば、人間の作業は評価と統合へ移る。反対に、対象への習熟度が高く委譲費用が大きければ、AI 自体が追加工程になる。どの場合でも、最終的な効果を決めているのは生成速度だけではなく、AI が入った結果として仕事がどの工程へ移動し、その工程を組織がどの程度処理できるかである。

この観点から見ると、AI 導入後に問うべきなのは「開発者が何倍速くコードを書けたか」だけではない。実装で短縮した時間がレビュー待ちへ移っていないか、変更量の増加がテスト負荷を押し上げていないか、生成を減らした代わりに評価作業が増えていないかを追う必要がある。AI によって一つの工程の制約が小さくなるほど、次に処理能力の低い工程が組織全体の速度を決める。

3. AI の効果を受け止める 7 つの組織能力

DORA は 2025 年の調査と分析から、AI 導入の便益を増幅する 7 つの組織能力を整理している[8]。調査では AI の利用状況だけでなく、組織側について、AI 利用方針、内部データ、バージョン管理、変更単位、利用者志向、内部プラットフォームといった条件を測定している[9]。AI を導入した組織と導入していない組織を単純に比較するのではなく、AI を使ったときにどの組織条件が成果との関係を強めたり弱めたりするかを見ている点に特徴がある。

この 7 項目は、AI 導入のために新しく必要になった特殊な技術を列挙したものではない。バージョン管理、小さな変更単位、利用者中心の開発、内部プラットフォームなどは、AI が普及する以前からソフトウェア開発で重視されてきた。AI 導入後に変わるのは、それらの能力の存在意義ではなく、生成される変更量が増えることで、既存能力の不足がより直接的に成果へ影響することである。

たとえば AI が一日に生成できる変更を増やしても、どの変更を作るべきか決められなければ、価値の低い作業まで高速化する。正しい内部情報へアクセスできなければ、古い仕様や誤った前提に基づく生成も速くなる。変更を小さく追跡できなければ、レビューと切り戻しの負荷が増える。テストやデプロイの共通経路がなければ、実装工程で短縮した時間が後工程の待ち時間へ移る。

7 つの能力をこの因果関係から整理すると、四つの役割に分けられる。AI をどこへ向けるかを決める「方向」、組織固有の事実を渡す「文脈」、増えた変更を安全に扱う「変更制御」、個人の高速化を組織全体へ流す「共通経路」である。

役割 DORA が示す能力 不足した場合に起きること 組織成果へ変換する機能
方向を決める 明確に共有された AI 方針、利用者中心の開発 AI を使う範囲や目的がばらつき、価値の低い作業まで高速化しやすい。 AI をどこで使い、何を利用者価値として作るかを決める。
文脈を与える 健全なデータ環境、AI から利用可能な内部データ 古い仕様や断片的な情報を基に生成し、確認と修正の負荷が増える。 現在のコード、設計、業務情報、運用状況を正しい判断材料として利用できるようにする。
変更を制御する 強いバージョン管理、小さな単位での作業 変更理由と失敗原因を追跡しにくくなり、レビューと切り戻しの範囲が広がる。 増えた変更を分離し、検証し、必要なときに戻せる状態へ保つ。
組織へ配る 高品質な内部プラットフォーム 実装だけが高速化し、テスト、セキュリティ確認、デプロイで待ち時間が発生する。 検証とリリースを反復可能な共通経路へ載せ、個人の速度を組織全体へ展開する。

四つは独立していない。方向が正しくても、文脈が誤っていれば正しい実装にはつながらない。正しい実装ができても、変更を安全に管理できなければ統合時の負荷が増える。変更を管理できても、テストとデプロイが手作業なら、本番へ届けるところで止まる。AI の効果を組織成果へ変換するには、生成の前後を含めた連続した経路が必要になる。

3.1 速度には方向が必要になる

AI の利用方針が曖昧な組織では、各開発者が自分で利用範囲を判断することになる。機密情報を入力してよいのか、生成コードをどこまでそのまま利用できるのか、社内コードを外部サービスへ送ってよいのか、生成物にどの程度のレビューを要求するのかが決まっていなければ、同じ組織の中でも利用方法が分かれる。

この状態では、慎重な開発者ほど利用を避ける一方、別の開発者は独自判断で利用範囲を広げる可能性がある。前者では利用可能な生産能力を活用できず、後者では情報管理や品質保証の境界が崩れる。AI の性能が同じでも、組織として許容する用途と責任の所在が定義されていなければ、利用量を増やすこと自体が成果にはならない。

DORA は、AI の利用方針が明確に共有されている組織では、AI 利用と個人の有効性、組織成果、ソフトウェアデリバリーの処理量との正の関係が強くなると報告している[10]。方針の役割は、利用を一律に禁止したり推奨したりすることではなく、どの仕事へ AI を使い、どこから人間の確認を必要とするかという境界を共通化することにある。

ただし、AI を使ってよい範囲が明確でも、作る対象そのものを誤れば成果にはつながらない。実装候補を高速に生成できるということは、価値の低い要求も高速に実装できるということである。利用者が実際に困っていることを確認せず、社内で思いついた機能を次々に作る組織なら、AI はその判断過程を修正せず、実装部分だけを短縮する。

DORA は利用者中心の開発を、AI の効果を左右する能力の一つとして位置づけている[11]。利用者中心であるとは、単に要望を一覧化することではない。利用者が達成しようとしている目的を把握し、提供した変更が実際にその目的へ寄与したかを観測し、その結果から次の優先順位を更新することである。

たとえば、AI によって月 10 件だった新機能の実装を 30 件まで増やせたとしても、その 30 件の多くが使われなければ、生成能力の増加は製品価値には変換されていない。一方、利用状況を確認して価値の低い要求を早い段階で捨てられるなら、AI の生成能力を必要な変更へ集中できる。AI が増やすのは実装可能な選択肢であり、その中から何を作るかを決める能力は組織側に残る。

このため、方向を決める能力には二つの段階がある。AI をどこでどの条件なら使えるかを定めることと、その AI を使って何を作るべきかを定めることである。前者がなければ利用方法がばらつき、後者がなければ価値の低い仕事まで高速化する。生成速度を上げるほど、方向を誤った場合に消費する開発能力も増える。

3.2 AI は、組織知が整っていなければ正しい文脈を得られない

AI に組織固有の作業を任せるには、一般知識だけでは足りない。現在のシステム構成、社内 API の仕様、データ定義、運用ルール、過去の設計判断、障害時の制約など、その組織だけが持つ情報が必要になる。コード生成能力が高くても、前提となる情報が欠けていれば、AI は不足部分を一般的な慣習や推測で補うことになる。

組織内の情報が分断されている場合、人間が AI へ適切な文脈を渡す前に調査が必要になる。仕様は社内 Wiki、実装上の注意点はリポジトリの文書、例外的な運用はチケット、最新の決定事項はチャットにしか残っていない、といった状態では、一つの変更に必要な情報を複数の場所から集めなければならない。AI がコードを 1 分で生成できても、その前提を確認するために 30 分かかれば、生成速度だけを上げても全体の作業時間は大きく減らない。

DORA が健全なデータ環境として測定しているのは、必要な内部データへアクセスしやすいか、重要なデータが分断されていないか、品質を信頼できるか、必要な情報へ短時間で到達できるかといった条件である[12]。これは AI のためだけのデータ整備ではない。人間が現在の事実を確認するために必要だった基盤が、そのまま AI に文脈を与える基盤にもなる。

さらに DORA は、AI から利用可能な内部データを独立した能力として扱っている。対象には、コードベース、設計文書、社内 Wiki、業務データ、運用指標などが含まれ、AI が組織固有の文脈へアクセスできることが、AI 利用と個人の有効性、コード品質との正の関係を増幅すると報告している[13]。

ただし、AI からアクセス可能にするだけでは十分ではない。設計書 A には旧仕様、設計書 B には新仕様が書かれ、どちらが有効なのか示されていなければ、検索可能になったことで矛盾した情報へ到達しやすくなるだけである。古いデータを大量に参照できる状態は、正しい文脈が豊富な状態とは違う。

たとえば認証方式を変更したシステムで、旧方式の手順書が検索結果の上位に残っていれば、AI は旧方式を前提とした変更案を生成する可能性がある。その出力が構文上正しく、テストの一部まで通れば、人間が前提の古さに気づくまで誤りが残る。情報基盤の品質が低いと、AI は誤りを作るだけでなく、既存の誤った組織知を短時間で再利用する経路にもなる。

組織知を AI に利用させる順序は、まず現在の事実を人間が識別できる状態にし、その後で AI から参照可能にすることである。どの文書が正本か、誰が更新責任を持つか、いつの情報か、どのシステムへ適用されるかが分かれば、人間と AI が同じ情報基盤を利用できる。AI は組織知の代替物ではなく、整備された組織知を再利用する新しい利用者になる。

3.3 変更量が増えるほど、戻せることと小さく保つことが効く

AI がコード生成を高速化すると、一人の開発者が同じ時間内に扱える変更量が増える。ここで変更管理が弱いと、生成できる量の増加がそのまま統合の難しさへ変わる。どの変更が何のために入ったのか、どの設定と組み合わせて動くのか、障害が発生したときにどこまで戻せばよいのかが分からなければ、生成速度が上がるほど確認範囲も広がる。

バージョン管理は、この状態を避けるための記録基盤になる。DORA の調査では、アプリケーションコードだけでなく、設定、ビルドや構成の自動化、システム設定、AI 用のプロンプトまで管理対象としている。また、小さく頻繁に変更を記録し、必要なときに取り消しや切り戻しへ依存できる状態も測っている[14]。

ソースコードだけを履歴管理していても、AI に与えた指示やシステム設定が別管理なら、同じ結果を再現できない場合がある。AI が生成した変更の原因を調べるとき、どのモデルを使ったかだけでなく、どのプロンプト、どのコード、どの設定を前提に生成したかが必要になる。管理対象が増えたことで、AI 時代には「何をバージョン管理するか」という境界も広がる。

変更単位の大きさも同じ構造に関係する。AI は数十ファイルにまたがる修正を一度に生成できるが、一度に生成できることと、一度に検証すべきことは同じではない。認証、データ形式、画面、テストをまとめて変更した場合、失敗したときに原因候補が複数残る。変更を分割すれば、一つの段階で確認する前提を減らせる。

DORA は、小さな単位で作業することが AI 利用と製品成果との正の関係を増幅し、組織内の摩擦にも良い影響を与えるとしている[15]。小さい変更はレビュー時間を必ず短くするわけではないが、確認すべき因果関係を限定できる。失敗した場合の影響範囲も狭くなり、切り戻す単位も明確になる。

既稿「AI による大規模開発では、未確定な状態を一件ずつ閉じる」で扱った、検証済みの状態を一つずつ積み上げ、未確定な成果を後続作業の前提にしないという考え方も、この構造の具体例である[16]。最初の変更に誤りがある状態で AI が 10 個の後続作業を進めれば、後続成果もその誤りを前提として生成される。途中で原因が見つかったときには、10 個すべてを再確認しなければならない。

一方、一つの変更を実装し、テストし、レビューし、確定した後で次へ進めば、後続作業が依存する前提は確認済みになる。AI が長い作業列を自律的に処理できるようになるほど、この差は大きくなる。生成できる作業数を増やすことより、誤りが後続へ伝播する距離を短く保つことが、組織全体の修正費用を抑える。

バージョン管理と小さな変更単位は、AI の生成能力を制限するための仕組みではない。AI が増やした変更を、追跡可能で、検証可能で、必要なら戻せる状態へ変換するための仕組みである。生成量が増えるほど、一件の誤りを局所化できる能力の価値も大きくなる。

3.4 個人の高速化を、共通経路で組織へ配る

個人の実装能力が上がっても、その後の工程を毎回別の担当者へ依頼する構造では、短縮できる範囲に限界がある。テスト環境を作るには基盤チームへ申請し、セキュリティ検査には別部署との日程調整が必要で、デプロイは運用担当者が手順書を見ながら実行する。この状態では、コードが 1 日早く完成しても、その後の待ち時間は残る。

さらに AI によって変更候補が増えると、依頼件数そのものも増える。実装者が一週間に 5 件しか変更を作れなかったときには処理できていた申請経路でも、20 件作れるようになれば基盤担当者や運用担当者へ集中する仕事が増える。前工程の高速化によって、共有部門が新しい待ち行列になる。

内部プラットフォームは、この繰り返し作業を個別依頼から共通経路へ移すための仕組みである。開発者が標準化された方法で環境を作り、テストを実行し、必要なセキュリティ検査を通し、承認された経路でデプロイできれば、変更件数が増えても人間同士の依頼回数を同じ割合で増やさずに済む。

DORA は、内部プラットフォームの品質が高い場合、AI 利用と組織成果との関係が強く正になる一方、品質が低い場合にはその関係がほとんど見られないとしている[17]。AI が一人の開発者へ追加した速度を、組織全体へ伝播させるには、その速度を受け取れる共通経路が必要になる。

高品質な内部プラットフォームは、単に開発ツールを一か所へ集めたポータルではない。組織として安全だと判断したテスト、セキュリティ、デプロイ、監視の方法を、開発者が繰り返し利用できる形へしたものである。個々の開発者が毎回正しい手順を調べ、別部署へ依頼し、例外処理を相談する必要が減れば、AI によって増えた変更を後工程へ流す際の調整費用も小さくなる。

この構造では、内部プラットフォーム自体の品質も制約になる。利用方法が分かりにくい、実行に長時間かかる、必要な機能がなく結局個別申請が必要、といった状態では、共通化しただけで待ち時間は減らない。AI の速度を組織へ配るには、利用者である開発者が実際にその経路を選ぶだけの使いやすさと信頼性が必要になる。

7 つの能力を通して見ると、AI 導入の成否を決める構造はかなり具体的になる。AI の利用方針と利用者理解が生成の向きを決め、内部データが正しい文脈を与え、バージョン管理と小さな変更単位が生成物を安全に制御し、内部プラットフォームが検証とデリバリーを共通経路へ流す。

この連鎖の途中に弱い部分があれば、AI が追加した能力はそこで別の負荷へ変わる。方向が弱ければ不要な実装が増え、文脈が弱ければ修正作業が増え、変更制御が弱ければレビューと切り戻しが難しくなり、共通経路が弱ければ待ち時間が増える。AI の性能が同じでも成果が組織ごとに異なるのは、生成の後ろにあるこの変換経路が同じではないからである。

4. 同じ AI が、組織の強さと弱さを別々に増幅する

4.1 良い基盤では、増えた変更を価値へ変換できる

AI によって実装量が増えたとき、その増分を組織成果へ変換できるかは、生成後の工程がどの程度まで短いフィードバックで接続されているかに左右される。設計文書が現在の実装と一致し、必要な情報を検索でき、変更を小さな単位で履歴へ残し、自動テストが数分から数十分で結果を返し、同じ手順で本番へ反映できる組織では、一件の変更を作ってから結果を確認するまでの距離が短い。AI が生成する変更数が増えても、この経路を繰り返し利用できれば、生成能力の増加をそのまま未処理作業の増加へ変えずに済む。

この性質は AI のために新しく作られたものではない。DORA は以前から、文書品質が高い組織では、継続的デリバリー、継続的インテグレーション、疎結合なチーム、バージョン管理といった技術能力と組織成果との関係が大きく増幅されることを報告している[18]。正確な文書は単なる説明資料ではなく、変更時に確認すべき前提を短時間で特定し、別の担当者やチームが同じ状態認識から作業を始めるための共有基盤になる。

AI が加わると、この共有基盤はさらに直接的に使われる。人間だけが読む文書であれば、古い記述が残っていても経験者が違和感から補正できる場合がある。しかし AI が設計文書、コード、運用資料をまとめて文脈として利用する場合、文書の品質は生成結果の前提へ入り込む。現在の状態が正確に記録されている組織では、その情報を人間だけでなく AI にも繰り返し利用させられるため、文書整備へ投じてきた能力が新しい生成能力の土台になる。

継続的デリバリーも同じ構造を持つ。変更を常にリリース可能な状態へ保つには、コードを書き終えた後に人間が一件ずつ判断するのではなく、バージョン管理、自動ビルド、自動テスト、監視、再現可能な環境、切り戻しといった複数の仕組みを接続する必要がある[19]。この経路がすでに動いている組織では、AI が生成した変更も既存の検証経路へ載せられる。

逆に、この経路がなければ AI が増やしたのはリリース可能な成果物ではなく、確認待ちの変更候補である。コードが短時間で完成しても、テスト環境を手作業で用意し、担当者が手順書を見ながら検証し、決められた時間帯にだけリリースできるなら、生成速度の向上はその前までしか届かない。継続的デリバリーが効く理由は、AI がコードを書くからではなく、生成から本番までの各工程を反復可能な処理として接続しているからである。

組織構造とシステム構造も、増えた変更をどこまで独立して流せるかを決める。ある機能を変更するたびに、認証基盤、共通データベース、別サービス、運用チームの調整が必要なら、一件の変更が複数チームの作業予定へ波及する。AI が実装を 30 分で終えても、関係部署との調整に数日必要なら、その 30 分は組織全体の処理時間をほとんど変えない。

DORA は、疎結合なチームとシステムでは、他チームとの細かな調整を常時必要とせず、独立してテストし、デプロイできることを重要な能力として整理している[20]。ここでいう疎結合は、単にマイクロサービスを採用することではない。変更のために他チームへ許可や同時作業を求める範囲が限定され、自分たちの担当領域について設計、検証、リリースまで責任を持てる状態である。

この状態では、AI によって一つのチームの変更量が増えても、その増分がほかの多数のチームへ同じ割合で調整作業を発生させにくい。生成能力の増加を局所的な変更として吸収できるため、組織全体で並行して処理できる量も増やしやすい。反対に密結合な構造では、AI が一人の開発者を高速化するほど、周囲のチームへ依頼する件数まで増え、別の場所に待ち行列を作る。

正確な文書、継続的デリバリー、疎結合な構造に共通するのは、AI を直接速くすることではない。変更を作った後に必要となる確認、調整、検証、リリースの費用を小さくし、変更同士の依存を限定することである。AI が生成能力を増やしたとき、その増分を同じ経路へ流せる組織では、既存の基盤能力が AI の効果を組織成果へ変換する。

4.2 弱い基盤では、既存の問題まで速くなる

同じ AI を、情報、変更管理、検証、デリバリーの弱い組織へ入れると、増えた生成能力は別の場所へ流れる。内部文書が古ければ、AI は古い設計を短時間で再利用できる。変更を大きな単位で扱っていれば、AI はさらに大きな差分を一度に作れる。レビューが特定の担当者へ集中していれば、レビュー待ちの件数が増える。自動テストが弱ければ、生成された変更を確認する人手が増える。利用者からの反応が要求へ戻らなければ、使われない機能も以前より短期間で実装できる。

このとき AI が新しい欠陥を組織へ持ち込んだとだけ考えると、原因を見誤る。AI が入る前にも、古い文書、巨大な変更、レビュー集中、手動テスト、長い承認経路は存在していた。生成量が少ない間は、それぞれの弱点が処理能力の範囲内に収まり、致命的な待ち時間として観測されていなかった可能性がある。AI が前工程の供給量を増やすと、同じ構造へより多くの仕事が流れ、その処理能力の上限を超えた時点で滞留や失敗として表面化する。

古い内部情報を例にすると、この因果が分かりやすい。従来は開発者が設計書を読み、実装との違いに気づけば、経験から正しい状態を補完できた。しかし AI が文書を直接参照して実装案を作る場合、古い記述は生成の入力になる。さらに AI が複数箇所を一度に変更すれば、一つの古い前提が複数ファイルへ展開される。情報管理上の小さな負債が、AI の生成能力によって短時間で広い範囲へ複製される。

変更単位が大きい場合も同様である。人間だけで実装していたときには、数十ファイルを一度に変更する作業自体に時間がかかるため、大きな変更の発生頻度には自然な上限があった。AI がその実装時間を短縮すると、この物理的な制約が弱くなる。一度に大きな変更を作れる回数が増える一方、レビュー担当者が数十ファイルの因果関係を理解する能力は同じ割合では増えない。生成能力の向上が、大きな変更を避けていた偶然の制約まで取り除く。

レビュー工程でも、処理能力が固定されたまま入力だけが増えれば、待ち行列が伸びる。待ち時間が長くなると、レビュー開始までに別の変更が入り、作成時の差分と現在のコードとの差が広がる。競合や追加修正が発生すれば、一件を確認する費用も上がる。単純に「変更が 2 倍になればレビュー件数も 2 倍になる」だけではなく、滞留によって一件当たりの確認費用まで上がり得る。

テストが弱い組織では、AI にテストコードも生成させれば解決するとは限らない。実装とテストを同じ要求解釈から生成すれば、誤った前提を両方が共有する可能性がある。既存の期待値、契約テスト、本番データから得た不変条件など、生成された実装とは独立した検証基準がなければ、コードとテストがそろって間違うこともある。AI が生成できるテスト数の増加と、検証能力の増加は同じではない。

利用者から遠い意思決定では、さらに別の増幅が起きる。従来は実装費用が高かったため、要求を採用する前に「本当に作る価値があるか」を議論する圧力が働いていた場合がある。AI によって実装費用が下がると、「安く作れるから試してみる」という判断が増えやすい。短いフィードバックで不要な機能を捨てられる組織なら実験回数の増加になるが、利用状況を測らない組織では、使われない機能が製品へ蓄積する速度まで上がる。

既存の状態 AI が直接増やすもの 直接発生する変化 組織で現れる帰結
正確で検索可能な内部情報 組織固有の文脈を使った検索と生成 必要な前提へ短時間で到達できる。 調査時間を減らし、生成能力を実装へ接続しやすい。
古く矛盾した内部情報 古い情報を利用した検索と生成 誤った前提が複数の成果物へ再利用される。 既存の情報負債を広い範囲へ短時間で複製し得る。
小さく追跡可能な変更 独立して処理できる変更数 一件ごとに検証し、失敗時に限定して戻せる。 生成量を増やしても失敗の影響範囲を局所化しやすい。
巨大で長期間未統合の変更 一度に生成できる差分 確認すべき因果関係と競合範囲が広がる。 レビュー、原因特定、切り戻しの費用が増えやすい。
自動化されたテストとデプロイ 検証・リリース候補となる変更 変更を既存の自動経路へ繰り返し流せる。 生成速度を利用者への提供速度へ変換しやすい。
手作業と承認待ちが多い工程 後工程へ流入する変更件数 人間への依頼と確認待ちが増える。 前工程の高速化が待ち行列と調整負荷へ変わる。
利用者からの短いフィードバック 短期間に試せる案の数 価値の低い案を早い段階で識別できる。 生成能力を価値の高い変更へ再配分しやすい。
利用者から遠い意思決定 短期間に実装できる機能の数 採用判断より実装が先行しやすくなる。 利用されない機能と保守対象まで増え得る。

この差を「AI の使い方が上手い組織と下手な組織」という言葉だけで説明すると、組織構造の問題が個人のプロンプト技術や AI 習熟度へ還元される。実際に差を作るのは、AI が入る前から存在していた情報の鮮度、変更単位、レビュー能力、テスト基盤、デプロイ経路、チーム間依存、利用者からのフィードバックである。AI の操作技術が同程度でも、この基盤が異なれば生成後の仕事の流れは変わる。

DORA 2025 が AI を増幅器として整理しているのは、この構造による[3]。増幅されるのは生産性だけではない。正確な内部情報を持つ組織では、その情報を使った生成を増やせる。小さな変更を安全に流せる組織では、その変更数を増やせる。反対に、古い情報、長い承認待ち、大きな変更、弱い検証経路を持つ組織では、その構造へ流れ込む仕事量が増える。

この意味で、AI 導入によって最初に変わるのは組織の性質ではなく、既存の組織構造へ流れる仕事の量と速度である。強い経路にはより多くの成果を流せる一方、弱い経路にはより大きな滞留や修正費用が生じる。AI の性能が同じでも結果が分かれるのは、生成能力の差ではなく、その能力を受け取った後の組織システムが異なるためである。

5. AI が広げ得るのは、導入格差より組織能力の成果差である

5.1 重要な能力の多くは、AI より前から存在していた

DORA が 2025 年に AI の効果を左右する能力として挙げたものを見ると、その多くは生成 AI のために新しく作られた能力ではない。バージョン管理、小さな単位での変更、利用者中心の開発、質の高い内部プラットフォームは、AI がコードを書く以前から、ソフトウェアを速く安全に届けるために必要とされてきた。2023 年の DORA 調査でも、利用者を重視するチームは組織成果が 40% 高い傾向を示し、継続的インテグレーション、疎結合なチーム、速いコードレビュー、質の高い文書などが成果と結びついていた[21]。

この点は、AI 導入によって組織に何が起きているかを考えるうえで重要である。AI が普及したことで、従来の開発能力が古くなったのではない。むしろ、コード生成という一工程の制約が小さくなったため、それまで実装速度の後ろに隠れていた組織能力が、全体の成果を左右する条件として前面へ出てきた。

一方、複数週間分の変更をまとめて統合し、レビューを特定の担当者へ集中させ、テスト環境やリリース作業を手作業に依存する組織では、同じ 5 件の増加が別の結果を生む。コードは早く完成しても、レビュー待ち、統合作業、試験環境の準備、リリース承認へ仕事が積み上がる。AI によって増えたのは最終的な価値提供能力ではなく、後工程へ投入される変更候補の量になる。

この違いは、AI 導入後に突然生まれたものではない。AI 導入前から存在していた変更管理、情報共有、アーキテクチャ、レビュー、テスト、デリバリーの能力差が、生成量の増加によって観察しやすくなったと考える方が実態に近い。AI が遅かった工程を高速化すると、その工程に隠されていた次の制約へより多くの仕事が到達するからである。

そのため、AI 時代の組織能力を「AI を使いこなす能力」だけで捉えると範囲を狭くしすぎる。プロンプトの書き方やモデル選択も実務上は必要だが、それだけでは生成された変更を本番へ届けられない。AI によって追加された生成能力を組織成果へ変換するのは、AI 導入以前から蓄積されてきた開発システムそのものである。

5.2 「組織間格差が拡大した」とまではまだ言えない

ここから先は、DORA が直接確認した結果と、そこから導ける仮説を分ける必要がある。DORA 2025 が示しているのは、AI の効果が組織の既存能力によって変わり、強い基盤では便益が大きくなり、弱い基盤では既存の問題も増幅され得るという関係である[3]。AI 導入前後の企業を長期間追跡し、企業間の成果格差そのものが統計的に拡大したことを証明した研究ではない。

確認されているのは「能力差が AI の効果を変える」ことであり、「その結果として企業間格差が拡大した」ことではない。この二つの間には時間を含む因果が一段残っている。組織能力の違いによって AI から得られる成果が変わり、その違いが長期間積み重なったときに初めて、組織間の成果差が拡大する可能性が生じる。

具体的には、同程度の AI を利用できる二つの開発組織を考えればよい。一方では、内部仕様を検索でき、変更を小さく分割し、自動テストを短時間で返し、チームが独立してデプロイできる。もう一方では、現在の仕様を調べるために複数の担当者へ確認し、大きな変更をまとめてレビューし、テスト環境を手作業で用意し、リリースのたびに別部署の承認を待つ。

両者で AI によってコード生成時間が同じだけ半減しても、短縮された時間の行き先は異なる。前者では短くなった実装時間を、そのまま次の検証とリリースへ接続できる。後者では実装が早く終わった分だけ、レビュー、調整、承認の待ち時間がより大きな割合を占めるようになる。AI の性能差がなくても、追加された生成能力を成果へ変換できる割合に差が生じる。

観点 組織能力が高い場合 組織能力が低い場合
AI へのアクセス 同程度のモデルを利用できる。 同程度のモデルを利用できる。
生成速度 コードや文書の作成時間を短縮できる。 コードや文書の作成時間を短縮できる。
内部情報 現在の仕様やコードへ短時間で到達できる。 情報探索と事実確認に追加時間がかかる。
変更管理 小さな差分として検証し、独立して戻せる。 大きな差分となり、確認と切り戻しの範囲が広がる。
後工程 自動テストや標準化されたデプロイ経路へ流せる。 レビュー、承認、手作業の待ち時間へ流れやすい。
AI による増分の行き先 価値提供量の増加へ変換しやすい。 滞留、調整、確認負荷の増加へ変換されやすい。

この差が一度だけ発生するなら、組織間の成果差への影響は限定的かもしれない。しかし、AI を日常的な開発工程へ組み込み、変更を継続して生成する状態では、一回ごとの変換率の差が繰り返される。前者が増えた生成能力を製品改善へ戻し、その結果からさらに利用者情報を得られる一方、後者が増えた変更を待ち行列として抱えるなら、両者は同じ AI を利用していても異なるフィードバック循環へ入る。

ここから、AI 時代の格差を単純な「導入できる企業と導入できない企業」の差として見るだけでは不十分だという仮説が導かれる。高性能な AI が広く利用可能になり、モデルへのアクセス差が縮小しても、その能力を自社の情報、変更管理、検証、デリバリーへ接続する能力までは均等にならない。AI へのアクセスが一般化するほど、むしろ同じ AI を何へ変換できるかという組織能力の差が相対的に見えやすくなる。

ただし、ここから「AI が企業間格差を拡大した」と断定することはできない。現時点で確認できるのは、AI の効果が組織能力によって異なるところまでである。その差が長期的な市場成果や企業間格差として蓄積するかは、継続的な観測が必要になる。

それでも、組織にとって実務上の含意はすでにある。競争条件が「AI を導入したか」だけで決まるなら、同じ製品を契約すれば差は縮まりやすい。しかし AI の効果が既存の組織能力によって増幅されるなら、契約を揃えても成果は揃わない。AI そのものが希少でなくなるほど、AI によって増えた能力を価値へ変換できる組織構造の方が、成果差を生む条件として残る。

6. AI 導入を「どれだけ使ったか」で測ると、増幅先を見誤る

6.1 利用量は、組織成果そのものではない

AI 導入では、測りやすい数字から管理を始めやすい。何人が利用しているか、週に何回使ったか、何行のコードを生成したか、何件の pull request を作ったか、どれだけ token を消費したかは、利用基盤から比較的容易に取得できる。導入直後に利用が定着しているかを確認するには有用だが、これらの数字が増えたこと自体は、ソフトウェア開発組織の成果が改善したことを意味しない。

理由は、これらが主として AI への入力や開発活動の量を測っており、その活動が後工程を通過して利用者価値へ変換されたかを測っていないからである。生成コードが 2 倍になれば、レビュー対象も増え得る。pull request が増えれば、テスト、統合、デプロイへ流れ込む変更も増える。前工程の活動量だけを成果として扱うと、AI によって増えた仕事が後工程で滞留していても、生産性が向上したように見える。

2026 年の企業内縦断研究では、一人当たりの pull request 処理量が大きく増えた一方、レビュー担当者一人当たりの負荷もおおむね倍増していた[5]。pull request の処理量だけを見れば、変更を作って統合する能力が向上したと評価できる。しかし、同時にレビュー負荷が増えているなら、その高速化を支えるために別の工程へ仕事が移っている。

この移動を測らずに pull request 数だけを目標にすると、さらに厄介なことが起こる。開発者は大きな変更を一件にまとめるより、小さく pull request を分ければ件数を増やせる。逆に一件当たりの変更価値が下がっても、件数だけなら改善して見える。測定値が評価指標になると、組織は本来の目的ではなく、その数字を増やす行動へ適応する可能性がある。

生成コード量も同じである。AI が 1,000 行を生成し、そのうち 800 行を削除して 200 行だけ採用した場合、生成量は大きい。しかし組織が価値として保持したのは 200 行であり、その 200 行にもレビュー、テスト、保守が必要になる。さらに、同じ機能を 100 行で実現できたなら、生成量が多いことはむしろ将来の保守対象を増やしている可能性もある。コード量は AI がどれだけ働いたかの一側面を示しても、ソフトウェアがどれだけ良くなったかは示さない。

AI 利用率にも同じ限界がある。利用率が低ければ、利用環境、教育、権限、対象業務との適合に問題がある可能性を調べる材料にはなる。しかし利用率が 90% になっても、その利用によって変更時間が短くなったのか、レビュー負荷が増えたのか、品質が改善したのかまでは分からない。利用率は「AI が使われた」という事実を測る指標であり、「AI が組織に価値を生んだ」という結果を測る指標ではない。

指標 直接測っているもの 増えたときに考えられること 単独では判断できないこと
AI 利用者数・利用率 AI が組織内でどの程度利用されているか 利用環境や業務への組み込みが広がっている可能性がある。 利用によって開発速度、品質、製品価値が改善したかは判断できない。
トークン消費量 AI サービスへ投入された処理量 AI を使った作業量が増えている可能性がある。 有効な成果物が増えたか、同じ作業を何度もやり直しているかは判断できない。
生成コード量 AI が生成へ関与したコードの量 実装工程で AI の利用範囲が広がっている可能性がある。 採用率、品質、保守性、重複、利用者価値は判断できない。
pull request 数 変更の作成・統合回数 変更の流入量や統合頻度が増えている可能性がある。 レビュー負荷、変更一件当たりの価値、障害への影響は判断できない。

これらの活動指標が不要なのではない。導入が進んでいるか、どこで AI が使われているか、費用がどこに発生しているかを知るには必要である。ただし、利用量を成果指標へ昇格させると、AI が何を増幅しているのかを見失う。生成が増えたのか、価値提供が増えたのか、レビュー負荷が増えたのか、手戻りが増えたのかを分けて測る必要がある。

6.2 測る対象は、導入目的から逆算する

AI 導入の評価指標は、AI そのものから決めるのではなく、導入によって何を改善したかったのかから逆算する必要がある。目的が実装時間の短縮なら、AI 利用回数ではなく、要求が着手可能になってから変更が完成するまでの時間を見る。目的がリリース速度の向上なら、コード生成時間だけでなく、本番へ届くまでのリードタイムやリリース頻度を見る。目的が品質向上なら、障害、手戻り、変更失敗、レビュー指摘、保守負荷まで含めなければならない。

DORA は、AI が開発工程へ入っても、既存の測定枠組みをすべて捨てて AI 専用の指標へ置き換える必要はないと整理している。DORA、SPACE、DevEx、H.E.A.R.T. などはそれぞれ測る対象が異なるため、組織が改善したい結果に応じて組み合わせ、必要な場合にだけ AI 固有の指標を追加する[22]。

この考え方は、AI 導入前後で評価対象そのものを変えないためにも必要になる。たとえば導入前には「変更を利用者へどれだけ速く安全に届けられるか」を重視していたのに、AI 導入後だけ「生成コード行数」を成功指標にすれば、比較対象が途中で変わる。AI は目的ではなく手段である以上、導入前に重要だった製品成果やデリバリー成果が、導入後に改善したかを継続して測る方が因果を追いやすい。

SPACE も、開発者の生産性を一つの活動量へ還元できないものとして整理している。満足度と幸福、性能、活動、コミュニケーションと協働、効率と流れという複数の観点を組み合わせるのは、commit 数やコード量だけでは、一人の開発者が本当に成果を出しやすくなったかを判断できないためである[23]。

AI 導入では、この多面的な測定がさらに必要になる。AI がコード作成時間を短縮した一方で、生成結果の確認時間が増えれば、作業時間は別の場所へ移っただけかもしれない。pull request 数が増えた一方でレビュー待ちが長くなれば、処理量の増加が組織全体の流れを改善したとは限らない。リリース頻度が増えても、変更失敗率や復旧時間が悪化すれば、速度を安定性と交換した可能性がある。

そのため、測定は工程の入口から出口まで対応させる必要がある。AI がどれだけ使われたかを入口で測り、変更がどれだけ作られたかを途中で測り、どれだけ安全に本番へ届いたかをデリバリーで測り、最終的に利用者が価値を得たかを製品側で確認する。一つの層だけを見るのではなく、前の層で増えたものが次の層で何へ変換されたかを見る。

測定層 代表的な指標 確認できること 次に確認すべきこと
AI 利用 利用率、利用者数、トークン消費量 AI がどの程度業務へ入っているかを確認できる。 利用によって実際の作業時間や成果物が変化したかを確認する必要がある。
開発活動 生成コード量、pull request 数、変更件数 変更の作成量や実装工程の処理量を確認できる。 増えた変更をレビュー、テスト、統合できているかを確認する必要がある。
開発フロー レビュー待ち時間、リードタイム、作業中断、手戻り 仕事がどこで滞留し、AI 導入後に制約がどこへ移ったかを確認できる。 短縮された流れが安全なリリースへつながったかを確認する必要がある。
デリバリー 変更のリードタイム、リリース頻度、変更失敗率、復旧時間 変更を本番へ届ける速度と安定性を確認できる。 届けた変更が利用者にとって価値を持ったかを確認する必要がある。
製品・利用者 利用率、継続利用、目標達成率、問い合わせ、業務成果 提供した変更が利用者の目的へ寄与したかを確認できる。 どの開発能力や変更が成果へ寄与したかを前工程と結びつけて分析する必要がある。

たとえば「AI によって利用者への機能提供を速くする」ことが導入目的なら、AI 利用率が 80% から 95% へ上がったことだけでは成功を判断できない。変更のリードタイムが短くなったか、レビュー待ちは増えていないか、変更失敗率は悪化していないか、届けた機能が実際に利用されたかまで追う必要がある。入口の利用量から出口の利用者成果までつながって初めて、AI による追加能力が組織成果へ変換されたと判断できる。

逆に、生成量だけが増え、レビュー待ちと変更失敗が増え、利用者指標が変わっていないなら、AI が増幅したのは価値提供能力ではなく、未処理の変更量だった可能性がある。コード生成時間が短縮してもリードタイムが変わらないなら、制約は別工程へ移っている。利用率が増えたのに手戻りも増えたなら、利用定着と品質改善を分けて考える必要がある。

この測り方は、第 3 章と第 4 章で扱った組織能力の差を検出する方法でもある。内部データが整備されていれば調査時間や修正回数が減るはずであり、小さな変更単位が機能していればレビューと切り戻しの範囲を限定しやすい。内部プラットフォームが機能していれば、実装からテスト、デプロイまでの待ち時間を短縮できる。AI 利用量ではなく、こうした工程上の変化を測れば、組織のどの能力が AI の効果を成果へ変換し、どこが増幅された負荷を受け止められていないかを特定できる。

AI 導入の成功は、組織が AI を多く使う状態を作ることではない。AI が追加した生成能力を、レビュー、検証、デリバリーの能力と接続し、品質と安定性を損なわずに利用者価値へ変換することである。利用量を測るだけでは、その変換が起きたかは分からない。入口から出口までを追って初めて、AI が組織の強みを増幅したのか、それとも既存の制約へ仕事を積み上げただけなのかを区別できる。

7. AI 導入は、組織能力を買うことではなく、組織能力が試されることである

AI は、コード生成、文書作成、検索、分析といった知的作業の一部を、人間だけで処理する場合より短時間で実行できる。既存コードの説明を求め、実装案を複数出し、テストコードを生成し、長い文書から必要な情報を抽出するといった作業では、開発者一人が同じ時間内に扱える仕事量を増やせる。組織が AI を導入すると、まず目に見えるのはこの局所的な生産能力の増加である。

しかし、ソフトウェア開発組織が価値を生むまでには、その前後に別の能力が必要になる。どの要求を採用するかを決め、現在の仕様と設計を共有し、変更を追跡可能な単位へ分け、レビューとテストで妥当性を確認し、安全な経路で本番へ届ける。さらに、本番で何が起きたかを観測し、その結果を次の優先順位へ戻さなければならない。AI が代替しやすい工程だけを高速化しても、この連鎖全体が同じ割合で速くなるわけではない。

反対に、現在の状態を確認できる内部情報があり、変更が小さな単位でバージョン管理され、自動テストが短時間で結果を返し、標準化された経路でデプロイできる組織では、増えた変更を既存の仕組みへ流しやすい。一件の変更に問題があっても、その差分だけを止め、必要なら戻し、ほかの変更を進められる。利用者から短い周期で反応を得られれば、増えた実装能力を価値の低い要求へ使い続けることも避けやすい。

DORA 2025 が AI を「増幅器」と整理しているのは、この差である[3]。AI が強い組織へ特別に高性能なモデルを与えるわけではない。同じ種類の生成能力が追加されたとき、その能力を受け取る情報基盤、変更管理、利用者理解、内部プラットフォームが異なるため、最終的な成果も変わる。強い経路にはより多くの仕事を安全に流せる一方、弱い経路にはより多くの滞留、確認、手戻りが発生する。

この構造は、AI 導入を「不足している組織能力を外部から購入すること」と捉えた場合に見落としやすい。モデルへのアクセス、利用ライセンス、計算資源は購入できる。しかし、どの文書が現在の正本なのか、変更をどこまで独立させられるのか、誰が品質を確認するのか、どの条件なら自動的に本番へ届けられるのか、といった組織内部の状態は契約と同時には変わらない。

たとえば二つの組織が同じ AI コーディングツールを導入しても、一方ではリポジトリ内の文書が更新され、変更が小さく、自動テストと継続的デリバリーが機能している。もう一方では仕様が複数の場所へ分散し、大きな変更をまとめてレビューし、リリースのたびに人手の承認を必要としている。AI が両者の実装時間を同じだけ短縮しても、短縮された時間を利用者価値へ変換できる割合は同じにならない。

AI によって追加できるもの 購入や導入だけでは追加できないもの 不足した場合に起きること
コードや文書を生成する能力 何を作るべきかを決める能力 価値の低い要求まで短時間で実装できるようになる。
内部情報を検索・要約する能力 現在の事実を正確に管理する情報基盤 古い仕様や矛盾した情報の再利用を高速化し得る。
大きな変更を短時間で生成する能力 変更を小さく分離し、追跡し、戻せる変更管理 レビュー、原因特定、切り戻しの範囲が広がる。
テストや修正案を生成する能力 独立した期待値に基づいて妥当性を確認する検証基盤 実装と検証が同じ誤った前提を共有する可能性が残る。
実装候補を大量に作る能力 安全に反復できるテストとデプロイの共通経路 完成した変更が後工程の待ち行列として蓄積する。

個人の水準でも似た構造がある。既稿「AI は思考設計格差を拡大する」では、AI によって利用できる知識や生成能力が増えても、問いを立て、出力を評価し、複数の情報を統合して判断する能力まで自動的に揃うわけではないと論じた[1]。組織では、この差が個人の頭の中だけに存在するのではなく、文書管理、権限、チーム境界、アーキテクチャ、レビュー手順、テスト基盤、デプロイ経路として制度化されている。

この違いによって、組織レベルの増幅は、個人レベルより持続しやすいと考えられる。個人なら不足している知識を学び、作業方法を変えることで改善できる場合がある。しかし、密結合なアーキテクチャを分割し、手作業のデプロイを自動化し、古い内部情報を整理し、複数部署にまたがる承認経路を変更するには、個人の努力だけでは足りない。AI が弱点を表面化させても、その制約を取り除くには組織的な変更が必要になる。

このため、AI 導入後に成果が伸びないとき、最初に「もっと高性能なモデルへ替える」「AI の利用率を上げる」と考えるだけでは原因を取り違える可能性がある。実装はすでに速くなっているのにレビュー待ちが増えているなら、必要なのは生成能力の追加ではなくレビュー経路の改善である。AI が古い仕様を繰り返し参照するなら、必要なのはプロンプト技巧より情報基盤の整理かもしれない。コードは完成しているのに本番へ届かないなら、制約はデプロイ経路にある。

AI を導入すると、組織がそれ以前から持っていた仕事の流れに、より大きな入力が与えられる。その入力を短いフィードバックで価値へ変換できれば、AI は既存の強さを拡大する。処理能力の低い工程が残っていれば、AI はそこへより多くの仕事を送り込み、弱点を待ち時間、手戻り、品質低下として表面化させる。

AI は弱い組織を自動的に強い組織へ変える道具ではない。むしろ、高性能な生成能力を接続したときに、その組織が何を正しく管理できており、どこで仕事を止め、どこまで安全に変更を流せるのかを露出させる。AI 時代に試されるのは、AI を導入できるかだけではない。増えた生成能力を、情報、変更管理、検証、デリバリーを通して利用者価値へ変換できる組織であるかどうかである。

その意味で、AI 時代に広がり得る差は、単純な導入格差ではない。同じ AI へアクセスできるようになった後にも、追加された能力を成果へ変換する割合は組織によって異なる。AI へのアクセス差が縮小するほど、モデルそのものより、AI が増幅する対象となる組織能力の差が成果へ反映されやすくなる可能性がある。

参考文献

  1. id774, AI は思考設計格差を拡大する（2026-02-19）. https://blog.id774.net/entry/2026/02/19/3698/
  2. id774, 生成 AI の競争軸は、モデルから業務実装へ移る（2026-06-25）. https://blog.id774.net/entry/2026/06/25/4922/
  3. DORA, State of AI-assisted Software Development 2025. https://dora.dev/research/2025/dora-report/
  4. DORA, Accelerate State of DevOps Report 2024. https://dora.dev/research/2024/dora-report/
  5. Hao He, Shyam Agarwal, Yegor Denisov-Blanch, Pavel Azaletskiy, Sanmi Koyejo, Bogdan Vasilescu, AI Writes Faster Than Humans Can Review: A Longitudinal Study of an Enterprise 2x Mandate（2026）. https://arxiv.org/abs/2607.01904
  6. Joel Becker, Nate Rush, Elizabeth Barnes, David Rein, Measuring the Impact of Early-2025 AI on Experienced Open-Source Developer Productivity（2025）. https://arxiv.org/abs/2507.09089
  7. Annie Vella, Kelly Blincoe, The Impact of AI Coding Assistants on Software Engineering: A Longitudinal Study（2026）. https://arxiv.org/abs/2605.23135
  8. DORA, DORA AI Capabilities Model（2025）. https://dora.dev/ai/capabilities-model/report/
  9. DORA, DORA AI Capabilities Model: Survey Questions（2025）. https://dora.dev/ai/capabilities-model/questions/
  10. DORA, Clear and communicated AI stance. https://dora.dev/capabilities/clear-and-communicated-ai-stance/
  11. DORA, User-centric focus. https://dora.dev/capabilities/user-centric-focus/
  12. DORA, Healthy data ecosystems. https://dora.dev/capabilities/healthy-data-ecosystems/
  13. DORA, AI-accessible internal data. https://dora.dev/capabilities/ai-accessible-internal-data/
  14. DORA, Version control. https://dora.dev/capabilities/version-control/
  15. DORA, Working in small batches. https://dora.dev/capabilities/working-in-small-batches/
  16. id774, AI による大規模開発では、未確定な状態を一件ずつ閉じる（2026-08-15）. https://blog.id774.net/entry/2026/08/15/5503/
  17. DORA, Platform engineering. https://dora.dev/capabilities/platform-engineering/
  18. DORA, Documentation quality. https://dora.dev/capabilities/documentation-quality/
  19. DORA, Continuous delivery. https://dora.dev/capabilities/continuous-delivery/
  20. DORA, Loosely coupled teams. https://dora.dev/capabilities/loosely-coupled-teams/
  21. DORA, Accelerate State of DevOps Report 2023. https://dora.dev/research/2023/dora-report/
  22. Sarah D’Angelo, Ambar Murillo, Sarah Inman, Kevin Storer, Choosing measurement frameworks to fit your organizational goals（2025）. https://dora.dev/research/2025/measurement-frameworks/
  23. Nicole Forsgren, Margaret-Anne Storey, Chandra Maddila, Thomas Zimmermann, Brian Houck, Jenna Butler, The SPACE of Developer Productivity: There’s more to it than you think.（2021）. https://queue.acm.org/detail.cfm?id=3454124