Post
JA EN

確認が追いつかない ─ AIで増えた「量」をさばくのをやめ、質と見つけやすさに投資する

Posted
By
69 min read
確認が追いつかない ─ AIで増えた「量」をさばくのをやめ、質と見つけやすさに投資する
  • 想定読者： AI導入後に確認・レビューの負担が増えた管理職、レビュー体制を設計するテックリード・EM、チームで大量のAI出力を扱っているメンバー
  • 前提知識： 生成AIを業務で使った経験があること
  • 所要時間： 約23分

概要

チームにAIが入って、出てくるものが増えた。PRの数、提案書のドラフト、設計メモ、調査レポート。個人の手元では確実に速くなっている。それなのに、管理職の机の上には「見なければいけないもの」が積み上がり、1件あたりに割ける時間は減っていく。

この状態を放っておくと、行き着く先は決まっている。確認が雑になり、雑な確認をすり抜けた欠陥が手戻りとして返ってきて、確認対象がさらに増える。DORAの2024年報告では、AI採用が25%増えるとデリバリー安定性が7.2%下がるという推定が出ていた1。個人の生産性と満足度は上がっているのに、である。2025年の報告になると、AIはスループットにも正の相関を持つようになった一方で、不安定性との相関は残った。DORAはこれを、AIが開発を加速し、その加速が下流の弱点を露呈させるのだと説明している2。その下流のどこにレビューが位置するのかは、後述する研究が正面から論じている3。

だから「増えた量をどうさばくか」を考えるのは、たぶん筋が悪い。さばく速度を上げても、上流の生成速度には勝てないからだ。

この記事が提案するのは2つの投資で、どちらも確認そのものを速くしない。ひとつは、量ではなく質を先に決めること。ここでの質には「レビューしやすさ」を含める。もうひとつは、質の高い成果物が、すぐ見つかってすぐ使える形で残ること。この2つを同時に進めると、確認しなければならない対象そのものが減っていく。同じ失敗が繰り返されなくなり、同じ調査が二度行われなくなるからだ。

DORAが2025年に公開したAI Capabilities Modelでも、AIの効果を増幅する要因として「小さいバッチで働くこと」と「AIからアクセスできる社内データ」の両方が挙がっている4。DORAが繰り返し言っているのは、AIが増幅器だということだ。増幅される前の中身が整っている組織では効果が乗り、整っていない組織では弱いところがより早く壊れる。この記事の2つの方向性は、その「増幅される前の中身」の側に手を入れる話になる。

以下では、量が増えると確認が非線形に重くなる理由を確認したうえで、2つの方向性の中身を具体化し、確認負担を減らす他の方法論（自動ゲート、リスクベースのサンプリング、AIレビュアー、増員）との関係を整理する。

1. 「確認地獄」は実際に測られている

まず、これが体感の問題ではないことを押さえておきたい。

BetterUp LabsとStanford Social Media Labが米国のフルタイムのデスクワーカー1,150人を対象に行った調査では、回答者の40%が直前の1ヶ月間に「workslop」を受け取ったと答えている5。workslopは、AIが生成した、見た目は整っているが中身の深さ・正確さ・文脈が欠けている成果物を指す造語だ。1件あたりの対処に平均1時間56分かかり、自己申告の給与から逆算すると1人あたり月186ドル相当。1万人規模の企業なら年間900万ドルを超える。

この数字で重要なのは、コストが受け取る側に発生している点だ。作る側の時間は確かに短縮されている。短縮された分が、そのまま下流の確認コストに移動している（この調査は AIの最新情報を追うな、ワークフローを確立せよ でも取り上げた）。

エンジニアリングの現場ではもっと直接的な形で出ている。Stack Overflowの2025年開発者調査（177カ国、49,000人超）では、66%が「AIの解が惜しいところまで来ているのに正しくない」ことに不満を持ち、45%がAI生成コードのデバッグに時間を取られると答えた6。AI出力の正確さを信頼していると答えたのは33%（うち「強く信頼」は3%）で、信頼していないが46%。

「惜しいけれど正しくない」というのが、確認コストの観点では最悪の性質を持つ。明らかに壊れているものは即座に捨てられる。8割方正しいものは、残りの2割を見つけるために全体を読まなければならない。読む量は変わらないのに、見つかる欠陥の密度だけが下がる。

実証研究の側でも、AI作成のPRはレビューされる頻度が低く、数倍速くマージされ、議論も少ないという傾向が報告されている3。ただしこの論文自身が、この傾向は分析上の選択を変えると反転しうる不安定なものだと断っている。その論文が中心に据えている主張のほうが本記事には効く。レビューは、コーディングエージェントがソフトウェアに与える効果の符号が決まる制御点であり、AIはその符号を決めてくれない。チームが決める。

2. 量が増えると、確認は「量に比例して」重くならない

なぜ確認が追いつかなくなるのか。生成量が2倍になったら確認負担も2倍、で済むなら、まだ人を増やすという解がある。実際にはそうならない。理由が3つ重なっている。

2.1 待ち行列は稼働率に対して非線形に伸びる

製品開発フローの文脈で繰り返し指摘されてきたとおり、待ち行列の長さは稼働率に対して線形には増えない。稼働率が60%から80%に上がると待ち行列はおよそ倍になり、95%に近づくにつれてさらに急激に伸びる7。

レビュアーの時間は有限のキャパシティであり、レビュー依頼はそこに入ってくるジョブだ。AIが入る前、レビュアーが週の6割をレビューに使っていた状態から、生成量が増えて8割になったとする。伸びるのは待ち時間だけではない。待っている間にコンテキストが古くなり、コンフリクトが増え、作者は次の作業に移ってしまっているので指摘への対応も遅れる。二次的な負担が待ち行列の長さに乗ってくる。

もっとも、この待ち行列モデルは到着がランダムで割り込みがないことを前提にしていて、人間のレビューにそのまま当てはまるわけではない。優先度で追い越しが起きるし、レビュアーは他の仕事と並行している。ここで使いたいのは倍率の正確さではなく、負荷が上がったときの効き方が線形ではないという形のほうだ。

2.2 1件あたりが大きくなると、検出できる欠陥の割合が落ちる

SmartBearがCisco Systemsで10ヶ月かけて2,500件のレビュー・320万行を分析した調査は、レビュー1回あたりの適正量を200〜400行とし、それを超えると欠陥を見つける能力が落ちると結論している8。500行/時を超えるペースでは欠陥密度が明確に下がり、連続60分を超えるとレビュアーは「消耗」して、それ以上欠陥を見つけられなくなる。

Googleの900万件の変更を対象にしたケーススタディも、対照的な数字を出している。35%以上の変更が単一ファイルのみを修正しており、75%以上の変更はレビュアーが1人9。小さい変更なら最初のフィードバックまで中央値1時間未満、非常に大きい変更では約5時間かかる。レビュー全体の中央値は4時間未満に収まっている。小さいから速いのではなく、小さくしてあるから速く回せている。

問題は、AIが小さい変更を作るのが得意ではないことだ。指示すれば一度に大量の変更を出せてしまうし、それが「効率的」に見える。DORAの2024年報告も、AIが安定性を下げる仮説としてバッチサイズの拡大を挙げていた1。

2.3 「たぶん大丈夫」が積み上がる

3つ目は、上の2つの帰結として起きる。時間が足りず、1件が大きく、欠陥密度が低いとわかっている。この条件下で人間が取る行動は、無意識のサンプリングだ。全部を同じ深さで見るのをやめ、なんとなく怪しそうなところだけ見る。

意識的にリスクベースでサンプリングするなら、それは後述するとおり有効な戦略になる。問題は、基準を決めずに疲労と時間切れでそうなることだ。何を見て何を見なかったのかが記録されないので、すり抜けたときに原因もわからない。

flowchart TB
    A["AIで生成量が増える"] --> B["レビュー待ち行列が伸びる"]
    B --> C["1件あたりの確認が浅くなる"]
    C --> D["欠陥・認識のズレが<br>下流に流れる"]
    D --> E["手戻り・再説明が発生する"]
    E --> F["確認対象がさらに増える"]
    F --> B

3. 方向性①：量ではなく質を先に決める

ここで言う「質を優先する」は、丁寧に作りましょうという心構えの話ではない。確認する側の負担を下げる性質を、成果物の要件に入れるという設計の話だ。

3.1 質の定義に「レビューしやすさ」を含める

多くの組織で「質が高い」は、バグがない・仕様を満たす・読みやすい、あたりを指している。これに次の3つを足す。

ひとつ、小さいこと。1つの変更、1つのドキュメントが1つの意図だけを持つ。SmartBearの200〜400行、Googleの単一ファイル中心の運用は、どちらもこの性質を制度として実装したものだ。DORAのAI Capabilities Modelも、小さいバッチで働くことがAIのプロダクト性能への正の影響を増幅すると報告している4。

ふたつ、意図が先に書いてあること。何を変えたかはdiffを読めばわかる。なぜそう決めたか、どの案を捨てたか、何を確認済みで何が未確認かは、書いてないと読み取れない。確認コストの大部分はここを推測する時間に消えている。AIに書かせた成果物では特にそうで、生成過程に人間の判断が入っていないので、書いてなければ本当にどこにも存在しない。

3つ目は自己検証だ。テストが通っている、リンクが生きている、数字が出典と一致している。レビュアーが機械で確認できることを人力で確認している時間は、そっくり削れる。

この3つを満たすと、レビュアーの仕事は「間違い探し」から「判断の妥当性の確認」に変わる。前者は量に比例して重くなるが、後者はそこまで比例しない。

3.2 出す前に人が通す

AIの出力をそのまま次工程に流すと、確認の総量は減らない。誰かが必ず読むからだ。作った本人が読むか、レビュアーが読むかの違いしかない。

そして作った本人が読むほうが安い。文脈を持っているし、間違っていたときの修正も速い。workslopのコストが受け取る側に発生していたのは、この一手が省略されているからだった。

言いたいのはAIを使うなということではなく、生成はAI・責任は人間という分担を成果物の単位で明示してほしい、ということだ。「AIが出したものを、私が確認して、この部分については私が判断しました」がどこにも書かれていない成果物は、レビュアーから見ると出発点が不明な文書になる。

3.3 空いた時間を、仕事の詰め込みに使わない

ここが実は一番難しい。

AIで作業が速くなったとき、その時間の行き先には3つの選択肢がある。より多くの仕事を入れる、質を上げることに使う、何もしないで残す。DORAの2024年報告で、個人の生産性・フロー・職務満足がすべて上がっている（それぞれ+2.1%、+2.6%、+2.2%）のに、組織のスループットは下がっていた1という結果は、浮いた時間が組織の成果に変換されていないことを示唆している。1つ目の選択肢を無自覚に取ると、稼働率が上がって §2.1 の待ち行列が伸びるだけになる。

2つ目、つまり質を上げるための時間に使うという選択肢は、この記事の文脈ではかなり合理的だ。設計を学ぶ、扱っているドメインを深く理解する、AIへの指示の精度を上げる、既存の仕組みを整理する。これらはすべて、後続の成果物の質を上げて確認コストを下げる方向に効く。しかも効果が積み上がる。1件を速く終わらせた効果はその1件で終わるが、質の基準が1段上がった効果は以降の全部に乗る。

3つ目の「残す」も、意外に馬鹿にできない。待ち行列の議論からすると、稼働率100%は最悪の設定だからだ。割り込みや緊急対応を吸収する余地がないと、1件のトラブルが全体の待ち時間を跳ね上げる。

ただし、放っておくと必ず1つ目になる。仕事の量は使える時間まで膨らむし、空いているように見える時間には別の仕事が入ってくる。学習や整備の時間は、管理職が「これは埋めない」と明示的に確保しないと消える。ここは現場の意識では守れない部分で、意思決定として扱うしかない。

3.4 質の基準は、書いて共有されていないと機能しない

「質を上げよう」だけでは何も変わらない。何をもって質が高いのかが人によって違うからだ。

書き下す最小限は、PRやドキュメントの単位でこれくらいになる。何が書いてあれば受け取れるか（意図・却下案・検証した範囲・検証していない範囲）。どこまで機械で検証済みであるべきか。1件の上限サイズはどれくらいか。逆に、何は書かなくてよいか。

最後の「書かなくてよいこと」を決めるのが効く。質を上げろという指示は、放っておくと網羅性の要求として受け取られ、長大なテンプレートを生む。それは §4.3 で扱うworkslopの製造装置になる。

3.5 叩き台としての最小基準

抽象的なまま終わらせないために、コード変更を例に具体値を置いておく。そのまま使うものではなく、議論を起こすための出発点として。

  • 1つのPRは原則200行以内、どれだけ大きくても400行まで。200行を超えるなら、分割できない理由をdescriptionに1行書く
  • descriptionには4項目を書く。何のために変えたか、検討して却下した案、検証した範囲、検証していない範囲
  • lint・型・テスト・リンク切れがCIを通ってからレビュー依頼を出す
  • AIに生成させた部分については、どこを自分が判断したかを1行添える
  • これ以上は求めない。設計背景の長文、diffを読めばわかる変更点の再説明、テストの実行手順はdescriptionに書かない

最後の1行が §3.4 で言った「書かなくてよいこと」にあたる。これがないと、4項目のリストは網羅性の要求として読まれて、埋めるための文章が増えていく。

ドキュメントなら、行数の枠が「1つの決定につき1ファイル」に置き換わり、検証範囲が「この記述の根拠はどこにあるか」に置き換わる。

200と400という数字は、§2.2 で引いた研究の結論をそのまま持ってきている（出典の言い方は「200行未満に収め、400行は超えない」）。ドメインのリスク特性によって動かして構わないし、動かすべき場合もある。効くのは、動かすときに「うちは何行が適正なのか」という議論が起きることのほうだ。数字が書いていないと、その議論自体が始まらない。

ひとつ試してみる価値があるのは、この基準を決める前に、自分のチームの直近10件のPRが何行だったかを数えてみることだ。感覚と実データがずれていることは、わりとよくある。

4. 方向性②：知識が「すぐ見つかってすぐ使える」状態にする

質の高い成果物を作っても、それが二度と参照されないなら、次の人はまた同じところで迷い、同じ質問をし、同じレビュー指摘を受ける。確認対象は減らない。

なお、この節が扱う範囲は組織のコンテキスト供給という大きなテーマの一部で、全体像は 組織のコンテキスト供給能力を整える にまとめてある。ここではAIが入ったことで何が変わったかに絞る。

4.1 探す時間は、そもそも大きい

McKinsey Global Instituteが2012年に出した報告では、インタラクションワーカーは週の約20%を社内情報の検索や、助けてくれる同僚を探すことに費やしていると推定されている10。同じ報告は、社内のやりとりが検索可能な記録として残ることで、この探索時間を最大35%削減しうるとも述べている。2012年の推定であり、対象も広いので、そのまま自分の組織に当てはめるべき数字ではない。それでも桁として無視できる量ではない。

この時間は、AIが入ると形を変えて残る。人が社内を探す代わりに、AIに聞いて、AIが社内文脈を知らないので一般論を返し、それを人が社内事情に合わせて直す。直すのは人で、直せるかどうかは人が社内事情を知っているかどうかで決まる。探索が消えたわけではない。

4.2 「AIから見つかる形」が新しい要件になった

DORAのAI Capabilities Modelで、7つの能力のうち2つが情報のアクセシビリティに関するものだった4。「健全なデータエコシステム」は、高品質で、アクセスしやすく、統合された社内データがAI採用の組織パフォーマンスへの正の影響を大きく増幅すると述べている。「AIからアクセスできる社内データ」は、AIツールを社内のデータソースに接続することが個人の有効性とコード品質への効果を高めるとしている。

つまり、社内の知識が整っているかどうかは、人間の生産性の話であると同時に、AIの出力の質を決める入力の話にもなった。ここが方向性①と②の繋がる場所だ。質の高い成果物が見つかる形で残っていれば、それが次のAI出力の入力になり、次の出力の質が上がり、確認が軽くなる。

具体的に何をするかは、組織によってかなり違う。ただ、共通して効くのは次のあたりだ。

まず、テーマごとに「ここが正」を1つ決める。全社でツールを1つに統一する話ではない。むしろツール統一は移行コストと部門固有のニーズの前で大抵失敗する（この論点は ツール散乱 ─ single source of truth が崩壊する組織 に詳しい）。決めるのは「デプロイ手順ならここ」「アーキテクチャ判断ならここ」という、テーマ単位の正の所在だ。同じ情報が4つのツールに散っていると、AIも人も、どれが最新かを判定できない。

決定は記録に残す。ADR（Architecture Decision Record）の形式で、何をなぜ決めたか、どの選択肢を捨てたかを書く。1決定1ファイル、docs/adr/NNNN-短いタイトル.md のような連番と固定の置き場所まで決めておくと、人もAIも探索なしで辿り着ける。この形式は人間にとって読みやすいだけでなく、AIに渡したときの効きがいい。

そして、賞味期限と持ち主。ファイル冒頭に最終確認日と担当者を置き、たとえば最終確認から6ヶ月を過ぎたものは棚の別の場所に移す。この6ヶ月は §3.5 の行数と違って研究の裏付けがあるわけではなく、動かす前提の叩き台にすぎない。決めておきたいのは期間そのものより、期限が来たときに誰の手元に通知が飛ぶかのほうになる。古い情報が現役と同じ棚に並んでいると、検索の精度は情報量に反比例して落ちる。

4.3 ただし、量を増やすと逆効果になる

ここで注意が必要で、知識共有を「ドキュメントを増やすこと」と読み替えると、確実に失敗する。

DORAの2024年報告は、AI採用が25%増えるとドキュメント品質が7.5%上がると推定していた。報告が推定した効果のうち、最大の伸びだった1。しかしこれは、AIを使えばドキュメントが良くなるという意味ではない。同じ時期に、AIで量産された中身の薄い文書が受け取る側のコストになっている（§1のworkslop）ことも報告されている。

分かれ目は、その文書に人間の判断が入っているかどうかだ。AIが既存情報を要約し直しただけの文書は、情報量を増やさずに検索結果だけを汚す。決定・却下・制約・失敗といった、そこにいた人しか持っていない情報が入っている文書だけが、次の誰か（と、次のAI）の役に立つ。書く動機はあっても古くする動機がないために死んだ文書が累積していく構造は、ドキュメンテーション・シアター ─ 大量に書いて全部死んでいる組織 で扱った。

5. 2つを同時に進めると起きること

方向性①と②は、片方だけだと効果が限定される。

質だけを上げて共有しないと、質の高さが個人に閉じる。その人がいなくなれば消えるし、隣のチームは同じ失敗を独立に踏む。共有だけを進めて質を上げないと、質の低いものが検索可能になるだけで、探す時間が増える。

両方が回ると、ループの向きが変わる。

flowchart TB
    A["質の基準を先に決める<br>（小さい・意図が明示・検証済み）"] --> B["確認が速く済む"]
    B --> C["浮いた時間を<br>学習と整備に回す"]
    C --> D["判断が入った成果物が<br>見つかる形で残る"]
    D --> E["人とAIの<br>次の入力になる"]
    E --> F["初回から質の高い<br>出力が出る"]
    F --> G["確認すべき対象が減る"]
    G --> C

ただし、この図で唯一ひとりでに回らないのが B から C への遷移だ。§3.3 のとおり、浮いた時間は放っておくと次の仕事で埋まる。ここだけは意思決定で押さえるしかなく、そこが抜けるとループはB止まりになって、あとは何も起きない。

ここで減っているのは「1件あたりの確認時間」ではない。確認しなければならない件数だ。すでに決着した論点が再燃しない。同じ調査が二度行われない。前回指摘された同じ間違いが出てこない。

即効性はない。数ヶ月単位で効いてくる種類の投資であり、四半期の目標にはしにくい。この点は正直に言っておくべきだと思う。

6. 他の方法論との比較

確認負担を減らすアプローチは他にもあり、それぞれ実績がある。この記事の提案がそれらを置き換えるものではないので、関係を整理しておく。

6.1 自動ゲート（機械で検証できるものは機械に渡す）

テスト、静的解析、型検査、リンター、セキュリティスキャンをCIに置き、通らなければ人間のレビューに回さない。レビュアーが「信じるしかなかった主張」を、機械で確認できる証拠に変換していく発想だ。

効果は大きく、実装も比較的容易で、AI生成コードの量が増えたときに真っ先に手を付けるべき場所でもある。製造業のjidoka（自働化）やpoka-yoke（ポカヨケ）が、事後の検査ではなく工程に品質を作り込むことで検査工程そのものを不要にしようとしたのと同じ構造になっている。

限界は、機械で検証できるものしか検証できないことだ。この設計判断がドメインとして妥当か、この仕様解釈が顧客の意図と合っているか、という部分は自動化できない。そして、AI生成物で問題になりやすいのは、ちょうどその部分だ。

併用というより、自動ゲートは方向性①の「自己検証が済んでいること」を制度として実装する手段にあたる。「シンプルに作って確認を要らなくする」という設計側からの同じ発想は、『シンプルに作る』が一番速い で扱っている。

6.2 リスクベースのレビューとサンプリング

すべての変更を同じ深さで見るのをやめる。認証まわりや課金まわりは厳しく、テストカバレッジの高いユーティリティ関数は自動ゲートを通れば人間の承認を待たずに進む。post-merge review（マージ後に抜き取りでレビューする）を組み合わせる運用もある。

これは §2.3 で挙げた「無自覚なサンプリング」を、意識的な設計に変えるものだ。基準が書かれ、何を見て何を見なかったかが記録される。有効性は高い。

限界は2つある。リスクの判定自体に判断が要ること。そして、抜き取り対象から外れた領域で品質が徐々に劣化しても気づきにくいこと。

これも併用でき、方向性①が進んでいるほどリスク判定は簡単になる。1つの変更が1つの意図しか持っていなければ、それが高リスク領域に触れるかどうかは機械的に判別しやすい。

6.3 AIレビュアー

AIにレビューさせて、人間の負担を減らす。生成量の増加に対して、レビュー側もスケールさせるという素直な発想だ。

ただし、240件のPRと739件のレビューコメントを分析した研究では、AI（GPT-4）が指摘できたのは人間が見つける品質問題の約1割にとどまっている11。同じ研究は、AIが人間の2.4倍の指摘を出し、その追加分の約4割は有意義な問題だったとも報告している。人間の代わりにはならないが、人間が見ない側を埋める役には立つ、という関係になる。総説の側でも、コード規約や軽微な欠陥は扱えるが、深いデータフロー解析やセキュリティ知識を要する高深刻度の脆弱性の検出は弱い、という評価になっている12。加えて、AI出力を人間が確認するという構造自体は変わらないので、レビュー指摘の確認という新しい確認対象が増える面もある。

併用はできるが、これ単体を主軸に置くと §1 の構造が一段深いところで再現する。AIレビュアーが最も効くのは、機械的に判定できる規約違反や見落としを拾い、人間を判断に集中させる使い方だろう（この論点は 「AIがやるんだから確認は軽くていい」は本当か でより詳しく扱っている）。

6.4 レビュアーを増やす・レビュー時間を増やす

最も直接的な解であり、短期的には効く。稼働率を下げれば待ち行列は縮む（§2.1）。

限界は、上流の生成速度が下がらない限り、追加したキャパシティがすぐ埋まることだ。そして、レビューに人を回した分だけ作る側が減るので、組織全体としては何も増えていない。§2.2 のとおり、1人あたりのレビュー量には検出率の観点からも上限がある。

緊急避難としては妥当だが、恒久策にはならない。

6.5 まとめると

賭けている場所が違うだけで、これらは競合しない。

自動ゲートは確認の単価を下げるが、工程に品質を作り込んで手戻りを消す限りにおいて、件数にも効く。jidokaの発想はそこにあった。リスクベースのサンプリングは、確認の単価を下げる。AIレビュアーとレビュアー増員は、確認のキャパシティを増やす。そしてこの記事の2つの方向性は、件数の側に正面から賭ける。

単価とキャパシティだけで対処していると、生成量が増え続ける限りいつか追いつかれる。件数を減らす投資は、そこにもっとも直接的に手を付ける方向になる。

7. 実践するときにぶつかること

きれいな話ばかりしても仕方がないので、確実に問題になる点を挙げる。

「質を上げろ」は、基準がないと精神論になる。§3.4 のとおり、何をもって質が高いのかを書き下していない状態でこれを言うと、受け取る側は「もっと頑張れ」と解釈するか、網羅的なテンプレートを埋める作業に変換する。どちらも確認負担を増やす方向に働く。先に基準を書く。

知識共有が続かない構造的な理由は、コストが書く側に乗って便益が読む側に出るという非対称性にある。書いた人が評価されず、読んだ人が助かるだけなら、合理的な個人は書かない。書く時間を業務として確保し、参照されたことが見える形にする、くらいの手当てが要る。

「ドキュメントが少ないからAIに書かせよう」は、状況を悪化させることがある。§4.3 のとおり、検索結果を汚して探索コストを上げる方向に効くからだ。

短期の指標では悪化して見える。1件あたりを小さくすると、PR件数は増える。基準を上げると、初期はリードタイムが伸びる。学習時間を確保すると、その期の稼働は下がる。効果が出るのは数ヶ月後で、その間は「遅くなった」ように見える。ここを説明して守るのは管理職の仕事で、現場の努力ではどうにもならない。

もうひとつ厄介なのは、AIの出力が「そこそこ良い」ことが、質の基準を静かに下げていくことだ。§1 の「惜しいけれど正しくない」問題の別の顔になる。以前なら差し戻していた水準のものが、AIが出したというだけで通ってしまう。基準を明文化しておく実務上の効き目は、この漂流を防ぐところにもある。

最後に、正直なところを書いておく。これは管理職が自分の仕事を減らすための施策ではない。少なくとも最初の数ヶ月は増える。基準を書き、合意し、守り、時間を確保して説明する。減るのは、それが回りはじめてからだ。

まとめ

AIで出てくるものの量が増えるのは、もう止められない。止めるべきでもない。

問題は、増えた量をそのまま下流に流すと、確認が非線形に重くなることだった。待ち行列は稼働率に対して急激に伸び（§2.1）、1件が大きくなるほど欠陥の検出率は落ち（§2.2）、時間切れの無自覚なサンプリングが起きる（§2.3）。

これに対して確認を速くする方向で対処すると、単価を下げるかキャパシティを増やすかになる。どちらも有効で、自動ゲートのように手戻りを消して件数まで効くものもある。ただし上流の生成速度が上がり続ける限り、それだけではいつか追いつかれる。

残る手は、確認しなければならない件数を減らすことになる。そのために2つ。ひとつ、質の定義に「小さいこと・意図が書いてあること・自己検証が済んでいること」を含めて、先に合意する。ふたつ、判断が入った成果物が、人とAIの両方からすぐ見つかる形で残るようにする。

そして、AIで浮いた時間を仕事の詰め込みに使わないこと。ここに手を付けないと、稼働率が上がって待ち行列が伸びるだけで終わる。浮いた時間を質を上げるための学習や、仕組みの整備に回せば、効果は以降の成果物すべてに乗る。1件を速く終わらせた効果は、その1件で終わる。

DORAが繰り返し言っているとおり、AIは増幅器として振る舞う。強い組織はより強くなり、弱いところはより早く壊れる。増幅される前の中身を整えるほうが、増幅された後の出力を1つずつ確認するより、たぶん安い。

関連記事

このテーマに関連する他の記事もご覧ください：

参考資料

本文中の引用番号に対応する参考資料を番号順に記載しています。

その他参考資料（本文中で番号引用なし）

  1. Accelerate State of DevOps Report 2024 - Google Cloud / DORA (2024). AI採用25%増に対するデリバリー安定性・スループット・ドキュメント品質・個人生産性の推定値。【信頼性: 高】 ↩︎ ↩︎2 ↩︎3 ↩︎4

  2. Announcing the 2025 DORA Report - Google Cloud (2025). AIの増幅器としての性質、スループットと不安定性の関係、加速が下流の弱点を露呈させるという説明。自社研究を紹介するベンダーブログ。【信頼性: 中〜高】 ↩︎

  3. 3100 Opinions on Code Review in an AI World: Building Causal Theory from Practitioner Discourse - Shyam Agarwal, Courtney Miller, Christian Kästner, Bogdan Vasilescu / arXiv preprint（査読前、2026）. 38,709文書から3,100件を層化抽出し、26の構成概念と67の関係からなる因果モデルを構築。AI作成PRのレビュー頻度・マージ速度・議論量の傾向と、その不安定性。「レビューは効果の符号が決まる制御点」という中心主張。【信頼性: 中】 ↩︎ ↩︎2

  4. Introducing DORA’s inaugural AI Capabilities Model - Google Cloud / DORA (2025). 7つの能力（AIスタンスの明示、健全なデータエコシステム、AIからアクセスできる社内データ、強いバージョン管理、小さいバッチ、ユーザー中心、質の高い社内プラットフォーム）とその増幅効果。自社研究を紹介するベンダーブログ。【信頼性: 中〜高】 ↩︎ ↩︎2 ↩︎3

  5. AI-Generated “Workslop” Is Destroying Productivity - Kate Niederhoffer, Gabriella Rosen Kellerman, Angela Lee, Alex Liebscher, Kristina Rapuano, Jeffrey T. Hancock / Harvard Business Review (2025). BetterUp Labs + Stanford Social Media Lab による米国のフルタイムのデスクワーカー1,150人調査。【信頼性: 中〜高】 ↩︎

  6. Stack Overflow Developer Survey 2025: AI - Stack Overflow (2025). 177カ国・49,000人超。AI出力の正確さへの信頼度、「惜しいが正しくない」への不満、デバッグ時間。【信頼性: 中〜高】 ↩︎

  7. Managing Queues in Product Development - M/M/1 待ち行列モデルに基づく製品開発フロー文脈の解説。稼働率60%→80%で待ち行列が倍になり、95%に近づくにつれてさらに急激に伸びる。同種の主張は Donald Reinertsen『The Principles of Product Development Flow』(2009) でも展開されている。【信頼性: 中】 ↩︎

  8. Code Review at Cisco Systems - SmartBear (2006). 10ヶ月・2,500レビュー・320万行の分析。1回あたり200〜400行、500行/時、連続60分の閾値。実務指針は Best Practices for Code Review にまとめられている。【信頼性: 中〜高】 ↩︎

  9. Modern Code Review: A Case Study at Google - Caitlin Sadowski, Emma Söderberg, Luke Church, Michal Sipko, Alberto Bacchelli / ICSE-SEIP (2018). 900万件の変更のレビューログ分析、インタビュー12件、調査44件。【信頼性: 高】 ↩︎

  10. The social economy: Unlocking value and productivity through social technologies - McKinsey Global Institute (2012). インタラクションワーカーの時間配分推定と、検索可能な記録による削減余地。【信頼性: 中】 ↩︎

  11. Studying Quality Improvements Recommended via Manual and Automated Code Review - Crupi, Tufano, Bavota / ICPC (2026). 240 PR・739コメントの分析。AI（GPT-4）は人間が見つける品質問題の約1割しか捕捉できない一方、人間の2.4倍の指摘を出し、その追加分の約4割は有意義な問題だった。人間レビューの代替ではなく補完にとどまる。【信頼性: 中〜高】 ↩︎

  12. A Review of Research on AI-Assisted Code Generation and AI-Driven Code Review - Academic Journal of Science and Technology (2025). LLM支援レビューはコード規約や低深刻度の欠陥は扱えるが、SQLインジェクション・XSS等の高深刻度脆弱性の検出は弱いとする総説。小規模ジャーナル掲載の総説であり、個別の実験結果ではない。【信頼性: 中】 ↩︎

マネジメント・組織
AI AI活用 コードレビュー ナレッジマネジメント マネジメント
This post is licensed under CC BY 4.0 by the author.