CLI型AIコーディングエージェントの導入効果はPR数ではなくレビュー・保守・障害率で見る

先に結論

CLI型AIコーディングエージェント（Claude Code、GitHub Copilot CLI など、ターミナルから対話的にコードを生成・編集させるツール）の導入効果は、PR数や生成行数だけでは測れません。生成が速くなること自体は前進ですが、それは「作った量」であって「本番に安全に届いた量」ではありません。

見るべきは、変更のリードタイム（着手から本番稼働まで）、レビュー1件あたりの所要時間、レビュー差し戻し率、変更失敗率（デプロイ後の障害・切り戻し）、平均復旧時間、そしてコードの重複・複雑度の推移です。これらが悪化していれば、PR数がいくら増えても開発組織の実質的な生産性は下がっています。

発注者側の結論も同じです。外部ベンダーがAIを使う前提で開発を進めるなら、「速く作れます」という説明だけを受け取るのではなく、AI利用後にどの品質指標がどう動くのかを、契約と受け入れ基準の段階で決めておく必要があります。この記事では、なぜPR数で測ると判断を誤るのか、代わりに何を見るのか、導入前に何を決めておくべきかを、発注者と開発責任者の両方の目線で整理します。

この記事を読むべき人

次のような立場の方に向けて書いています。

• 開発チームがAIコーディングエージェントを使い始め、PR数や「生産性◯%向上」という報告は上がってくるが、それが本当に事業価値につながっているのか判断できない経営者・事業責任者
• 外部の開発会社がAIで開発を進めると言い始め、成果物の品質をどう確認すればよいか分からない発注担当者
• 生成は速くなったのに、レビューが追いつかず、リリース前のボトルネックがむしろ増えたと感じている開発責任者・テックリード
• ひとり情シス・兼任情シスとして、AI導入の可否や社内ルールを整理する立場にあるが、判断の軸を持っていない方

技術的な導入手順ではなく、「効果をどの指標で見るか」「導入前に何を決めるか」という経営・発注の判断軸を求めている方に役立つ内容です。

何が起きているのか

2026年7月1日、Microsoftの研究チームが、同社内でのCLI型AIコーディングエージェント（Claude CodeおよびGitHub Copilot CLI）の初期展開を分析したプレプリント（arXiv:2607.01418、査読前の論文）を公開しました。数万人規模のエンジニアを対象にした調査で、ツールの利用は上からの号令ではなく同僚経由の社会的なつながりを通じて広がったこと、そして利用者は約4か月の観測期間を通じて「そうでなかった場合と比べて約24%多くのPRをマージした」と報告しています。

この「24%多くのPR」という数字は、CLI型AIコーディングエージェントが一過性の目新しさでは終わらず、現場に定着し始めていることを示す点で意味があります。ただし、ここで立ち止まって考える価値があります。この研究が測ったのは、あくまでマージされたPRの「数」です。そのPRが顧客価値をどれだけ生んだか、後の保守コストをどれだけ増やしたか、障害率にどう影響したかまでを示したものではありません。査読前のプレプリントであるという前提も含め、この数字を「生産性が24%上がった」と読み替えて社内やベンダーの評価に持ち込むのは、測る対象を取り違えるリスクがあります。

同じ時期には、規制業種向けにエージェント型のコード生成へ段階的な人間の監督を組み込む枠組み（GAIEフレームワーク）を提案したプレプリント（arXiv:2606.22484、査読前の論文）も公開されています。こちらは、コード生成のタスクを規制上のインパクトで分類し、人が逐一確認する層、人が全体を監視する層、監視付きで自動化する層に振り分けることで、開発速度の大部分を保ちながらガバナンスを効かせる、という考え方を示しています。これも査読前の段階ですが、「速く生成できること」と「安全に本番へ届けること」を別々に設計するという発想は、規制業種でなくても参考になります。

要するに、AIでコードを書く速度が上がるのは事実として観測され始めている一方で、その速度をそのまま生産性や事業価値の向上と読み替えてよいという証拠にはなっていません。速く書けても、レビュー待ちが伸び、テストが薄くなり、設計から逸脱し、障害対応が増えるなら、組織全体としてはむしろ遅く、そして高くつきます。

なぜPR数で測ると失敗するのか

PR数を効果指標に据えると、なぜ判断を誤るのか。理由は、開発というプロセスのボトルネックが、コードを「書く」工程にあるとは限らないからです。

多くの開発現場で、変更が本番に届くまでの時間の大半は、書く時間ではなく、レビュー待ち、テスト、仕様確認、リリース調整といった「書いた後」の工程で消費されています。AIコーディングエージェントが速くするのは、主に「書く」工程です。ここだけを速くすると、下流のレビューやテストに、これまで以上の量の変更が一度に押し寄せます。生成が2倍速くなっても、レビューできる量が変わらなければ、増えた分はレビュー待ちの列に積み上がるだけです。

積み上がったPRは、マージされて本番に届くまで、価値を生みません。それどころか、待っている間にコードは陳腐化し、他の変更と衝突し、レビュー時に「これは何のための変更だったか」を思い出すコストがかかります。滞留したPRは、在庫と同じで、抱えているだけでコストが発生する負債です。PR数という指標は、この滞留をまったく捉えられません。むしろ「たくさん作った」ことを成果に見せてしまうため、滞留を悪化させる方向に人を動かします。

さらに、PR数は「同じ価値を生むのに、より多くのPRを要するようになった」場合と「本当に多くの価値を生んだ」場合を区別できません。AIに任せると、一つの機能を実現するのに細かいPRが乱発されたり、いったん生成したものを作り直すために追加のPRが積まれたりします。数だけ見れば増えますが、事業から見れば同じ場所を行き来しているだけ、ということが起こります。

だからこそ、測る対象を「作った量」から「本番に安全に届き、価値を生み、そして壊れなかった量」へ移す必要があります。以下では、その移し方を具体的な指標に落とします。

見るべき指標

PR数の代わりに見るべきなのは、変更が本番に届くまでの流れと、届いた後の安定性を捉える指標です。ソフトウェア配信の分野では、変更のリードタイム・デプロイ頻度・変更失敗率・平均復旧時間の4つが代表的な指標として知られています（いわゆるDORAの4指標）。ここでは業界平均値のような具体的な数字は挙げません。重要なのは他社と比べることではなく、AI導入の「前」と「後」で自社の数字がどう動いたかを見ることだからです。

• 変更のリードタイム（着手から本番稼働まで）：一つの変更が、作業に着手してから実際に本番で動くまでにかかる時間。AIで書く時間が短くなっても、この総リードタイムが縮まなければ、ボトルネックは書く工程になかったことを意味します。逆にここが伸びていれば、生成量が下流に詰まっているサインです。
• レビュー1件あたりの所要時間：レビュアーが1つのPRを見終えるまでにかかる時間。AI生成コードは「動いてはいるが、なぜそう書いたのかが読み取りにくい」ことがあり、レビューに余計に時間がかかる場合があります。1件あたりが伸びていれば、レビュー体制に負荷が寄っています。
• レビュー差し戻し率：レビューで修正を求められて戻される割合。AIが生成したコードが設計方針やコーディング規約から外れていると、この率が上がります。高止まりしていれば、「生成→差し戻し→再生成」の空回りが起きています。
• 変更失敗率（デプロイ後の障害・切り戻し）：本番に出した変更のうち、障害や切り戻しを引き起こした割合。速く出せても、この率が上がっていれば、速さは品質を犠牲にして買ったものだったことになります。ここは事業への影響が最も直接的に出る指標です。
• 平均復旧時間：障害が起きてから復旧するまでの平均時間。AIが書いた、担当者本人も完全には理解していないコードで障害が起きると、原因の特定に時間がかかり、この数字が伸びます。復旧の速さは、コードの理解度と保守性の裏返しです。
• コードの重複・複雑度の推移：似たような処理の重複、条件分岐の入り組み具合、1関数の長さなどの推移。AIは目の前のタスクを解くことに最適化されるため、既存コードとの重複や、後から読みにくい複雑な構造を生みやすい傾向があります。この推移が右肩上がりなら、今は動いていても保守コストが静かに積み上がっています。

これらの指標の要点は、単独の値ではなく「導入前後の変化」で読むことです。リードタイムが縮み、差し戻し率と変更失敗率が横ばい以下で、複雑度が増えていないなら、その導入は本物の効果を出しています。逆に、PR数だけが増えて他が悪化しているなら、それは生産性向上ではなく負債の前借りです。

AIが書いたコードの保守コストは後から来る

AIコーディングエージェントの効果を測るとき、最も見落とされやすいのが、コストの発生タイミングです。生成の速さは「今」得られますが、その代償は「後で」やってきます。

典型的なのが、動くが理解されていないコードです。AIに書かせて、テストが通り、レビューも大きな指摘なく通過し、本番で動いている。ここまでは何も問題がないように見えます。しかし、そのコードが「なぜその実装なのか」「どういう前提で動いているのか」を、チームの誰も説明できない状態だと、半年後に仕様変更や障害対応が必要になったとき、誰も安全に手を入れられません。書いた本人ですら、AIとの対話の文脈を忘れていれば、他人のコードと変わりません。

テストのないコードも同じ構造です。生成を速く回すために、その場では動作確認だけで済ませ、自動テストを書かないまま本番に出す。動いているうちは何のコストも見えませんが、次の変更でそのコードを壊したとき、壊れたことに気づく仕組みがないため、障害という形で最も高い場所で発覚します。

その場しのぎの依存追加も後から効いてきます。AIは目の前の課題を解くために、手近なライブラリを追加することを厭いません。一つひとつは小さな判断でも、積み重なると、更新の追随、脆弱性対応、ライセンスの確認といった保守作業が、誰も全体像を把握しないまま増えていきます。セキュリティの観点では、依存関係や入力検証、秘密情報の扱いに生成コード特有の穴が生まれやすく、OWASPのGenAIセキュリティ関連のガイダンス（LLM Top 10など）でも、生成AIを組み込む際の典型的なリスクとして整理されています。

保守コストが後から来るということは、導入直後の評価では効果が過大に見えるということです。「速くなった」という実感は初日から得られ、「保守が重くなった」という痛みは数か月後に、しかも別の人に降りかかります。だからこそ、評価は導入直後のスピード感ではなく、時間をかけて保守性の指標を追って判断しなければなりません。AIが修正したコードを本番に出す前の具体的な確認観点は、AIが修正したコードを本番に出す前のレビュー基準でも整理しています。

レビュー体制が先に壊れる

生成が速くなったとき、組織の中で最初に悲鳴を上げるのは、たいていレビュー体制です。書く速度が上がった分、レビューに回ってくる量が増えます。しかしレビューできる人の数と時間は、すぐには増えません。結果として、レビューが工程全体のボトルネックになります。

このとき現場で取られがちな打ち手と、それぞれの限界を整理しておきます。

• レビューを分担する：レビュアーを増やし、負荷を分散する。ただし、レビューは書くより属人的で、設計の意図や過去の経緯を理解している人でないと質が落ちます。頭数を増やしても、浅いレビューが増えれば、通過率は上がっても品質は担保されません。
• AIにレビューさせる：生成AIに一次レビューをさせ、明らかな問題を機械的に拾わせる。定型的な規約違反や単純なバグの検出には有効ですが、「この変更はそもそも作るべきだったか」「既存設計と整合しているか」という、事業と文脈に踏み込んだ判断はAIには任せきれません。AIが書いたコードをAIがレビューして人が最終責任を放棄する構図になると、誰も全体を理解していないコードが本番に積み上がります。
• 変更を小さくする：1つのPRを小さく保ち、レビューしやすくする。これは最も効果的な打ち手ですが、AIは放っておくと大きな塊で生成しがちなので、「小さく出す」という規律をチーム側で維持する必要があります。規律が緩めば、すぐに大きなPRが戻ってきます。

どの打ち手にも共通する限界は、レビューという行為が「人がコードを理解して責任を引き受ける」工程である以上、生成の速さと同じようには自動化・高速化できないことです。だからこそ、生成を速くする前に、レビュー体制がその速度に耐えられるかを見積もり、耐えられないなら生成の量そのものを制御する、という順序が要ります。速く作れるようになったからといって、作る量を無制限に増やしてよいわけではありません。

前段のROI論点（そもそも投資に見合うのか）については、CLI型AIコーディングエージェント導入は本当にROIが出るのかで、6つの測定軸に沿って掘り下げています。

導入前に決めておくこと

CLI型AIコーディングエージェントは、使い始めてから運用ルールを整えようとすると、すでに機密コードが渡っていた、責任の所在が曖昧なままマージされていた、という後戻りできない状態になりがちです。導入前に、少なくとも次の項目を決めておくことをおすすめします。

• どのリポジトリで使うか：全リポジトリで一斉に解禁するのではなく、影響範囲の小さいものから段階的に許可する。基幹システムや顧客データを扱う部分は、最後まで慎重に扱う。
• 機密コードを渡してよいか：AIツールにどこまでのコードやデータを入力してよいかを線引きする。顧客情報、認証情報、未公開の事業ロジックなど、渡してはいけないものを明文化する。ツール側のデータ取り扱い条件（学習利用の有無、保存期間）も確認する。
• 生成物の責任は誰が持つか：AIが生成したコードでも、本番に出した以上、責任は生成した人間の側にあります。「AIが書いたから」は免責になりません。誰がその変更の責任を負うのかを、PR単位で明確にする。
• テストの最低ライン：AI生成コードであっても満たすべきテストの下限を決める。この線を下回るものはマージしない、というルールがないと、生成の速さがそのままテスト省略の速さになります。
• レビューなしでマージしてよい変更の範囲：どこまでを自動化・省略してよく、どこからは必ず人のレビューを要するかを、変更の影響度で分類する。前述のGAIEフレームワークのように、影響の小さい変更は監視付きで通し、影響の大きい変更は必ず人が確認する、という段階設計が現実的です。

これらを整理する際は、AIツールを入れるかどうかの前に、そもそも自社の開発プロセスのどこが詰まっているのかを見極める必要があります。実装が遅いのか、レビューが遅いのか、仕様確認で往復しているのか、リリースで止まっているのか。詰まりの場所を取り違えたままAIを入れても、詰まりが移動するだけです。この見極めには、AI導入可否アセスメントのような、導入の前段で現状を棚卸しする診断が向いています。開発プロセスや体制そのものの立て直しが論点なら、DX・システム開発やAI・自動化支援の観点も合わせて検討する価値があります。

効果を測る前に「導入前の数字」を取る

ここまで挙げた指標は、どれも「導入前と比べてどう変わったか」で読むものです。ということは、導入前の数字を取っていなければ、効果は永遠に測れません。そして、導入前の数字は、導入してしまった後からは取り戻せません。

導入前に記録しておきたいのは、変更のリードタイム、レビュー1件あたりの所要時間、レビュー差し戻し率、変更失敗率、平均復旧時間、コードの複雑度・重複の水準です。完璧な計測環境を用意する必要はありません。過去数か月のPR履歴や障害記録、リリース記録から、おおよその水準を押さえておくだけでも、後から「良くなったのか悪くなったのか」を語れるようになります。

この「導入前の数字」を取らないまま導入すると、評価は必ず主観に流れます。「なんとなく速くなった気がする」「PRは増えた」という印象論だけが残り、保守コストの増加や障害率の悪化は、別の原因のせいにされて見過ごされます。逆に、導入前の数字さえ押さえておけば、たとえPR数が増えていても「その裏で変更失敗率が上がっているから、この導入はまだ効果が出ていない」と、事実に基づいて判断できます。

外部ベンダーにAI活用込みで発注する場合も同じです。着手前の自社の数字と、ベンダーの提案が前提としている改善幅を突き合わせておかないと、「AIで速くなります」という説明の妥当性を、後から検証できません。他社の見積もりや提案を発注前に第三者の目で確認したい場合は、他社見積・提案書を、発注前に30分でレビューのような、発注前レビューを使う手もあります。

よくある誤解

最後に、CLI型AIコーディングエージェントの導入判断でつまずきやすい誤解を整理します。いずれも、直感的には正しそうに見えて、実際には判断を誤らせるものです。

• 「開発が速くなる＝安く済む」：速く作れることと、総コストが下がることは別です。生成が速くても、レビュー負荷、テスト、保守、障害対応のコストが増えれば、総額はむしろ上がります。安くなったかどうかは、書くコストだけでなく、後工程と保守まで含めた総コストで見なければ分かりません。
• 「AIが書いたコードは人が書いたコードと同じ」：見た目は同じでも、チームがその意図を理解しているかという点で決定的に違います。人が設計意図をもって書いたコードは、後から人が直せます。AIが文脈依存で生成し、誰も意図を把握していないコードは、動いていても保守できない在庫になり得ます。
• 「テストもAIに書かせれば品質は保てる」：AIにテストを書かせること自体は有効ですが、「実装を書いたのと同じ理解で、その実装に都合よく通るテスト」を書いてしまうと、テストは品質の保証になりません。実装が間違っていても、その間違いを追認するテストが一緒に生成される危険があります。何を検証すべきかという設計は、人が責任を持つ領域です。
• 「導入すれば人を減らせる」：生成が自動化されても、レビューし、責任を負い、設計を決め、障害に対応する人は必要です。むしろ、生成量が増えた分、レビューと保守を担う人の重要性は上がります。人員削減を効果の前提に置くと、レビュー体制が薄くなり、品質が先に壊れます。

これらの誤解に共通するのは、「書く」工程だけを見て、その前後にある設計・レビュー・保守・責任という工程を軽く見ていることです。CLI型AIコーディングエージェントは、書く工程を速くする強力な道具ですが、それ以外の工程を肩代わりしてくれるわけではありません。効果を正しく測り、期待値を適切に置けば有力な選択肢になり、測らずに期待だけを膨らませれば、静かに負債を積む装置にもなります。

導入前に確認すること

社内でこれから使い始める場合も、外部ベンダーがAIを使う前提で発注する場合も、確認したいのは次の点です。

• 開発の遅れは、実装・レビュー・テスト・仕様確認・リリースのどこで起きているか
• AIに任せる作業と、人間が責任を持つ作業を分けているか
• PRテンプレートに、AI利用の有無、実施した確認テスト、想定リスクを書く欄があるか
• 外部ベンダーのAI利用条件（機密情報の扱い、成果物の責任、ライセンス確認）を契約で確認しているか
• 導入前後で、レビュー時間・変更失敗率・保守工数を比較できる数字を取っているか

これらを整理したうえで、自社に合った品質ゲートを設計するのが、導入の成否を分けます。AI基盤そのものの選定を並行して検討している場合はAIデータセンター建設ラッシュから考える、中小企業のAI基盤選定は「GPU」より電力・冷却・契約が先、SaaSや外部ツールの契約更新が絡む場合はSaaS席数課金がAIエージェントで崩れる前に、中小企業が契約更新で見るべき項目も、あわせて発注判断の材料になります。

GXOが支援できること

AI開発ツールを入れる前に、どの指標で効果を測るか、レビュー基準と保守KPIをどう置くか、外注契約でAI利用条件をどう確認するかを整理したい場合、GXOがその設計を支援します。ツールの導入可否だけでなく、発注者が品質を自分で確認できる基準に落とし込むところまでを対象にします。

システム開発の発注前相談で整理する

FAQ

Q. PR数を見るのは意味がないのですか。 A. 意味がないわけではなく、単独で効果指標に据えると判断を誤る、ということです。PR数は活動量の目安にはなりますが、その変更が価値を生んだか、保守コストや障害率を悪化させていないかは示しません。リードタイムや変更失敗率と組み合わせて、初めて意味を持ちます。

Q. Microsoftの研究で「24%多くPRをマージした」とありますが、これは生産性が24%上がったということですか。 A. 違います。その数字（arXiv:2607.01418、査読前のプレプリント）が示したのは、あくまでマージされたPRの「数」の増加です。顧客価値や保守性、障害率への影響までを測ったものではありません。数字を「生産性24%向上」と読み替えるのは、まさにこの記事が避けるべきだと述べている取り違えにあたります。

Q. AIにレビューさせれば、レビューのボトルネックは解消しますか。 A. 定型的な規約違反や単純なバグの検出には有効ですが、完全な解消にはなりません。「そもそもこの変更を作るべきだったか」「既存設計と整合しているか」という事業と文脈に踏み込んだ判断は人が担う必要があり、そこの責任まで手放すと、誰も理解していないコードが積み上がります。

Q. 効果を測るには、何から始めればよいですか。 A. 導入前の数字を取ることから始めてください。過去数か月のPR履歴や障害記録から、変更リードタイム、レビュー差し戻し率、変更失敗率、平均復旧時間のおおよその水準を押さえておきます。導入後にしか測り始めないと、良くなったのか悪くなったのかを事実で語れなくなります。

Q. 保守コストが増えているかどうかは、どうやって気づけますか。 A. コードの重複・複雑度の推移、変更失敗率、平均復旧時間を継続して追うのが基本です。特に、障害からの復旧に時間がかかるようになってきたら、「動いてはいるが誰も理解していないコード」が増えているサインです。導入直後のスピード感だけで評価しないことが重要です。

Q. 外部ベンダーがAIを使って開発する場合、発注側は何を確認すべきですか。 A. 機密コードやデータをAIツールに渡してよい範囲、生成物の責任の所在、ライセンス・著作権の確認方法、テストの最低ライン、そしてAI利用後にどの品質指標をどう報告するかを、契約と受け入れ基準の段階で確認してください。「速く作れます」という説明だけを受け取らないことが肝心です。

Q. AIコーディングを導入すれば、開発人員を減らせますか。 A. 減らせるという前提は危険です。生成が自動化されても、レビューし、設計を決め、責任を負い、障害に対応する人は必要で、むしろ生成量が増えた分、その重要性は上がります。人員削減を効果の前提に置くと、レビュー体制が薄くなり、品質が先に壊れます。

参考・出典

• Emerson Murphy-Hill ほか「Adoption and Impact of Command-Line AI Coding Agents: A Study of Microsoft's Early 2026 Rollout of Claude Code and GitHub Copilot CLI」arXiv:2607.01418（査読前のプレプリント、2026年7月1日投稿） https://arxiv.org/abs/2607.01418 （2026-07-10確認）
• 「Governed AI-Assisted Engineering: Graduated Human Oversight for Agentic Code Generation in Regulated Domains」arXiv:2606.22484（査読前のプレプリント、2026年6月投稿・7月改訂） https://arxiv.org/abs/2606.22484 （2026-07-10確認）
• OWASP GenAI Security Project（LLM Top 10 ほか、生成AIのセキュリティ指針） https://genai.owasp.org/ （2026-07-10確認）
• NIST AI Risk Management Framework（AI RMF、2023年1月公開） https://www.nist.gov/itl/ai-risk-management-framework （2026-07-10確認）