「AI導入でコーディング速度が○倍になった」という話は増えましたが、あなたのチームは本当に速くなりましたか?
実際は「出力は増えても、速度は上がらず、疲弊感が」という声も聞こえてきます。この問題と、AI時代に必要な「信頼の再設計」について整理したいと思います。
- 問題の本質
- 解決へむけての考え方
- 今後利用される解決策
時間がない方は、3だけ読んでもよいかもです。
１. 問題の本質 - なぜ「速く」ならないのか
AI Productivity Paradox
AI導入で個人の生産性は上がっているのに、チーム全体のスピードは向上していません。10,000人以上の開発者を対象にした調査では
- PRマージ数：+98%
- レビュー時間：+91%
また別の調査では、速くなったと思い込んでるだけ というのも。
- 本人の主観：20%速くなった
- 実際の完了時間：19%遅延
「進んでいる感覚」だけが先行し、検証・修正コストが過小評価されるためで、生産性プラセボともいわれています。 #
なぜこんなことが起きるのかといえば、AIが生成する 「ほぼ正しい(Almost-Right)」コード が原因です。構文的には正しく見えるが論理的に誤っている。間違っていてもエラーを出さないため、レビュワーは一行ずつ意図を調べることになり、認知コストが高まっています。
さらに、開発者の コンテキストスイッチの増大 も報告されています。調査では、開発者が1日に触れるPRコンテキストが 約47%増加し、注意力が断片化 していることが示されています。AI疲れ..
この現象は、近年 AI Productivity Paradox(AI開発の矛盾) と呼ばれています。#
品質劣化とシニアエンジニア殺しの未来
さらに、2020年から2024年にかけての2億行以上のコード分析で、静かな品質劣化が確認されています。#
- リファクタリングの消失：25% → 10%未満
- 重複コードの増加：48%増
- 5回以上重複するコードブロック：2024年だけで 8倍
出力の増加によってレビューが追い付かなくなることで、「とりあえず動いているからいいか」とマージが許容されていると考えられます。現場や人類の努力不足ではなく構造的な問題なわけです。
シニアエンジニアの負担
「70%問題」を知っている方も多いのではないでしょうか、Google Geminiの開発者の方によると、AIは機能の70%（定型パターンなど）を素早く構築できるものの、残りの30%（エッジケース、セキュリティなど）が依然として困難という話です。
さらに続きがあり、30%に責任を持つ役割は、シニアエンジニアに集中すると話しています。
That's going to be an interesting challenge, because we tend to have finite senior engineers #
エンジニア経験の差による検証スキルの差で起きてると考えられ、レビューにかけた時間の調査#でも示されていそうです。
-
ジュニアエンジニア
- レビュー時間： 平均1.2分（LGTM率83%）
- 70%を「完成」と誤認し、実は崩れやすい不安定なコードを受け入れる
-
シニアエンジニア
- レビュー時間：平均4.3分（LGTM率50)
- 「残りの30%」の欠陥を見抜くために、結果として手書きよりも遅くなる
本来イノベーションや戦略的設計に時間を割くべきシニアエンジニアが、AIの「監視役」として忙殺され組織の停滞を招くなんて未来も。
本質は、"信頼"の欠如
どんな改善策を講じても、最終的な人間による検証コストがボトルネックになり続けます。
なぜなら、私たちはAIを信頼していないからです。
- AIの回答を「高度に信頼している」：わずか3% # Stack Overflowの調査
「間違っていてもエラーを出さず、正しく見える」という特性は、出力が増えるほど不信感を増幅させます。人間同士なら経験を通じて育つ「この人は大丈夫」という信頼が、AIとの間では蓄積されません。
- 見ないと： 品質事故が怖い。
- 見ると： レビューが爆発して速度が出ない。
この二律背反が、「速度は上がらないのに、消耗だけが増える」という状況を生み出します。
アジャイル開発は、重厚なドキュメントよりも 信頼できる人間同士の協調 によってスピードを上げてきました。GoogleのHRT原則（Humility / Respect / Trust）なども、すべて「人と人」を前提です。しかしAI時代、相手は高速だが平気で嘘をつきます。
私たちは再び 「信頼できない相手」 と仕事をすることになりました。
2. 解決へむけての考え方
人間の関わり方を変える(Human-in-the-Loop)
信頼できない相手と仕事をする方法、その解決に繋がるのが Human-in-the-Loop (HITL) という考え方です。
「人が適切なポイントで介入し続ける」 というのがHITLの設計思想で、機械学習(ML)のライフサイクルで生み出されChatGPTの成功を支えたRLHF(人間フィードバックによる強化学習) も、このHITLです。
この考え方は、ソフトウェアエンジニアリングにも適用できます。70問題のGemini開発者も「人間が主導権を握る Human-in-the-Loop の姿勢が不可欠である」と述べています。#
ソフトウェアエンジニアリングでは、二つの適用がポイントになっていくかと思います。
- 適切なポイントでの介入: 重要な箇所に集中的に人間を配置
- フィードバックの蓄積: 人間の修正をAIに学習させ、AIそのものを改善し続ける
"信頼"の再設計
この適用方法ですが、「信用できない相手との協働」は、ソフトウェアエンジニアリングにおいて初見ではありません。
- 失敗を前提で、単一に依存しない(分散システム / SRE)
- 判断や根拠を後から追える(DevOps / 可観測性)
- 人間のレビューや判断を、属人化させずに蓄積する(継続的改善)
- すべてを同じ重さで扱わず、対応を変える(アジャイル)
既に持っている設計思想 を、AIにも適用し再設計するだけとも言えます。
3: 今後利用される解決策
これまでの方向性をもとに、今後利用されるであろう解決策をまとめてみました。
-
AI レビューによる階層型レビューの導入
人間が全てを見るのではなく、多層的なフィルターを通します -
設計駆動(x Design Driven)開発などの、ヒューマンリソースのシフトレフト
「コードのレビュー」から「設計のレビュー」に人間のリソースをシフトします -
レビューなどのフロー情報の蓄積や、持続的コンテキストの拡張
レビューコメントなどをその場限りにせず、ナレッジ として蓄積します -
信頼度スコアによるトリアージなどの、"人/AIが見ない領域"の定義と自動化
リスクを明確にすることで「人/AIが見ない領域」を作ることで、自動化を実現していきます -
ワークフローの衛生管理や、AI-DLCなどのAIに最適化したワークフローの整備
AIが活躍するための土台や、AI-DLCなどのAIに最適化したワークフローを整備していきます -
人の役割やマインドセットとスキルの再定義
オーケストレーターとしての役割や検証能力スキルなど、人側の「マインドセットとスキル」を再定義が進みます。 -
新たな生産性指標の導入
単なる「コード量」や「PR数」ではなく、真の価値を測る指標で評価します。
解決策の詳細
① AIレビューによる階層型レビューの導入
人間が全てを見るのではなく、多層的なフィルターを通します。最終判断は人間が行いますが、その手前でノイズを削ぎ落とすことで負担を激減させます。
-
3層のゲート構造
静的解析(Linter/フォーマッタ) / AIレビュアー(CodeRabbit/Qodo等) / 人間レビュアー -
リフレクション(自己反省)パターン
AIに生成されたコードを別のAIインスタンスに自己レビューさせる手法です。
② 設計駆動(x Design Driven)開発などの、ヒューマンリソースのシフトレフト
人間の介入タイミングを早期の段階に移します。膨大に膨らむコードをレビューするのではなく、事前に方針を固めそこで詳細な精査をすることで、人のリソースの効率化を図り、問題の早期発見と修正コストの削減を実現します。
-
PRD主導の計画(Plan-First)アプローチ
- Plan(計画)/Implement(実装)/Verify(検証)
- 「何を書いたか」の事後確認ではなく、「何を書こうとしているか」の事前合意に人間の知能を使うことで、手戻りとレビュー負荷を下げます。
- SPEC駆動開発の導入
③ レビューなどのフロー情報の蓄積や、持続的コンテキストの拡張
人間が行ったレビューや修正などのフロー情報も、AIの資産として蓄積・活用します。
組織の暗黙知を形式知に変換し、AIが学習可能な形で保持できるようにします。
-
レビューなどのフロー情報のナレッジの蓄積
- レビューコメントからチーム固有のルールを抽出し、AIのプロンプト(Custom Instructions)にフィードバックする
-
コンテキストの継続的拡張
- MCP/"llms.txt"の活用
- 依存関係にある他のリポジトリや共有ライブラリや内部SDKの挙動の獲得
- 「Jira」や「ADO」などの要件チケットに記されたビジネス要件(Acceptance Criteria)
④ 信頼度スコアによるトリアージなど、人が見ない領域の定義と自動化
すべてのタスクを同じ強度で確認する必要はないため、「人が見ない領域」を定義するで、自動化を実現していきます。領域の指針となる信頼度などもAIに算出させることができます。また、逆にAIの禁止区域などを設定するのもガードレールになります。
-
AIによる信頼度スコアの算出
- リスクスコア、変更内容の規模、対象の複雑度や、などから、信頼度をAIに算出させる。
-
AI禁止区域の設定
- 法的・セキュリティ上クリティカルな領域(決済処理、暗号化、個人情報など)などを領域を分離する
-
信頼度スコアやマトリクスによる自動
- Low Risk / High Confidence: 自動テストが通ればマージ
- High Risk / Low Confidence: シニアエンジニアによる厳密なレビュー
- などなど
⑤ ワークフローの衛生管理や、AI-DLCなどのAIに最適化したワークフローの整備
AIが活躍するための土台や、AI-DLCなどのAIに最適化したワークフローを整備していきます
-
テスト拡充やDescription充実など従来のベストプラクティスの強化
- 人に効果があるものは、AIに効果があると言われています。そのため、従来のプラクティスを強化も有効です。CICDなきゃそもそもとか。
-
スモールバッチやマイクロPRの強制
- AIが生成する巨大なPRを禁止し、小さな単位に分割して提出させ、レビューの「流し見」を防いだり伏臥位があった際に変更の追跡を容易にします。
-
AI-DLC(Development Life Cycle)の導入
- 数時間〜数日単位の超短期間ワークサイクル**「ボルト(Bolts)」**に移行していくようです。Amazonがいってた
⑥ 人の役割やマインドセットとスキルの再定義
プロセス(仕組み)を整えても、その上で動く人間の「マインドセットとスキル」の再定義が不可欠です。
-
「オーケストレーター」としての役割へのシフト
- エンジニアの役割は、「コードを書く人」から「AIを指揮し、品質を保証する人」へとシフトします。
-
必要なスキルセットの変化
- 検証スキル「一見正しいが微妙に誤っている(Almost-Right)」コードを見抜く批判的思考力。
- プロンプト・デコンポジション 複雑な要件を誤解なく実行できるように分解する指示能力。
-
マインドセットの転換
- 走るではなく導く / Perfectではなくお好きな言葉
-
AIデトックス
- スキル低下を防ぎ、コードへの理解を維持するためAIを使わない開発期間を作る
⑦ 新たな生産性指標の導入
単なる「コード量」や「PR数」や「リリース数」ではなく、真の価値を測る指標で評価します。これまでもHowの難しさがあった領域ですが、今後はより重要になるかと思います。
-
質を重視した指標
- 欠陥流出率(Defect Escape Rate) / 技術的負債の蓄積速度 / レビュー負荷の軽減率
-
ビジネス価値の指標
- 顧客価値提供速度/イノベーション時間の割合
おわりに "信頼"の再設計
「シニアエンジニアは、ボトルネックなので、彼らを外す必要がある。(レビューなどに追われるのではなく、リソース視点で戦略的な対応に関わるべき)」
そんな話を、AIと一緒に書こうとした結果、この記事は想定以上に膨らみ、
私はアウトプットよりも検証に時間を取られる側になっていました。後半は正直、燃え尽きました。
人がテクノロジーを使って課題を解こうとする姿勢自体は、まだしばらく続きそうだ、という感触は得られました。
後半の内容について、もっと詳しくなどあれば、声をかけて頂けると一緒に検討出来たり。
まずは、あなたのチームで最近行われたレビューのうち、「AIによる一次チェックだけで防げたはずの指摘」がどのくらいあったか振り返ってみてください。
by AI