●この記事のポイント
Claude CodeやCodex（GitHub Copilot）などの生成AI導入により、開発現場ではコード生成の高速化が進む一方、「レビュー・修正工数」と「意思決定負荷」が急増し、エンジニアの過労が深刻化している。AIが生む大量のコードに対し、人間が品質・セキュリティを担保する構造がボトルネック化。さらに経営側の「生産性向上」期待が納期短縮圧力を強め、実質的な労働密度を押し上げている。解決には評価軸を量から質へ転換し、レビュー工数の正式化が不可欠となる。
「AIを使えば、開発スピードは飛躍的に向上し、エンジニアは創造的な業務に集中できる」――。こうした期待のもと、アンソロピックの「Claude Code」やOpenAIの「Codex（GitHub Copilotなど）」といったAIプログラミング支援ツールは急速に普及している。
しかし、その裏側でいま、開発現場から聞こえてくるのは「むしろ疲弊が増した」という声だ。効率化の象徴とされたAIが、なぜエンジニアの負担を増大させているのか。本稿では、その構造的要因を掘り下げる。
●目次
「書く」から「直す」へ…開発プロセスの質的転換
従来のソフトウェア開発は、人間が設計し、コードを書き、テストするという積み上げ型のプロセスだった。しかし生成AIの導入により、この前提は大きく変わった。現在は「AIにコードを書かせ、それを人間が検証・修正する」というプロセスが主流になりつつある。
一見すると効率化だが、現場の実感は異なる。AIが生成するコードは一定の品質を持ちながらも、文脈理解の浅さや仕様の取り違え、セキュリティ上の脆弱性を内包するケースが少なくない。そのため、エンジニアは「他人が書いたコード」を精査し、既存システムとの整合性を確認しながら修正する必要がある。
大手IT企業でテックリードを務めるエンジニアは、こう指摘する。
「自分で書いたコードは思考の流れを把握しているが、AIが出力したコードは“ブラックボックス化した他人の思考”です。それを読み解く作業は、ゼロから書くよりも精神的負荷が高い」
つまり、AIは「作業量」を減らす一方で、「認知負荷」を増大させている。創造的なコーディングの時間が減り、代わりにレビューと修正に追われる構造が生まれているのだ。
AIと人間の速度差が生む「ボトルネック」
もう一つの問題は、AIと人間の処理速度の非対称性だ。AIは数秒で数百行のコードを生成し、複数の改善案やリファクタリング案を提示する。一方で、それらを評価・採用する判断は人間に委ねられる。
この「速度差」が、現場に新たなひずみを生んでいる。
第一に、コードレビューの限界だ。従来でもレビューはボトルネックになりがちだったが、AIの導入によりレビュー対象が爆発的に増加した。シニアエンジニアやプロジェクトリーダーは、膨大なコードを短時間で評価する必要に迫られている。
第二に、「決定疲労（Decision Fatigue）」の増大である。AIは複数の選択肢を提示するが、その中から最適解を選び続ける作業は高度な認知負荷を伴う。判断の連続は集中力を奪い、結果として意思決定の質を低下させるリスクすらある。
ITジャーナリストの小平貴裕氏は次のように分析する。
「生成AIは“選択肢の爆発”をもたらしました。問題は、それを評価する人間の認知資源が有限であることです。結果として、意思決定のコストが可視化されないまま増大している」
こうして、プロジェクト全体において最も遅い存在である「人間」がボトルネックとなり、その遅れを補うために労働時間が延びるという逆転現象が起きている。
「生産性向上」が招く期待値インフレ
さらに見逃せないのが、マネジメント側の期待値の変化だ。AI導入はしばしば「生産性向上」の象徴として扱われるが、その実態は単純な時間短縮ではない。それにもかかわらず、経営層やクライアントは「納期短縮」「成果倍増」を当然視し始めている。
結果として、効率化で生まれた余力は、休息やスキル向上に充てられるのではなく、さらなるタスクの投入に使われる。エンジニアは常に高い集中力を要求される「高密度労働」に置かれ、疲労が蓄積していく。
「AI導入は“時間短縮ツール”ではなく“アウトプットの質を変えるツール”です。それを誤解したままKPIを設定すると、現場に過剰なプレッシャーがかかり、逆に生産性を毀損します」（小平氏）
この「期待値インフレ」は、特に受託開発やSI業界で顕著だ。契約条件や納期がAI導入前の前提で見直されないまま、実質的な要求水準だけが引き上げられるケースも少なくない。
「シャドーワーク化」するレビュー業務
AI時代の開発現場では、もう一つの問題が浮上している。それが「レビュー業務のシャドーワーク化」だ。
AIが生成したコードの検証や品質担保は極めて重要だが、それが正式な工数として認識されていないケースが多い。結果として、レビューは「見えない労働」となり、エンジニアの残業や自己犠牲によって吸収されている。
特にセキュリティや法令遵守が求められる領域では、この問題は深刻だ。AIが生成したコードに含まれる脆弱性を見逃せば、企業にとって重大なリスクとなる。しかし、そのチェック体制は十分に整備されているとは言い難い。
求められるのは「評価軸」の再設計
では、この構造的な問題にどう対処すべきか。鍵となるのは、「ツール導入」ではなく「評価の再定義」である。
第一に、レビューや検証にかかる時間を正式な工数として組み込むこと。AIが生成するコードの品質を担保するためには、人間の判断が不可欠であり、そのコストを無視することはできない。
第二に、評価軸を「量」から「質」へと転換することだ。単純なアウトプット量ではなく、「適切な判断が行われたか」「リスクが管理されているか」といった観点を重視する必要がある。
第三に、AIとの役割分担を明確にすることも重要だ。AIに任せる領域と、人間が責任を持つ領域を切り分けることで、過剰な負荷を防ぐことができる。小平氏はこう総括する。
「AIは生産性を高める可能性を持つ一方で、マネジメントの未成熟を露呈させる装置でもあります。評価制度や業務設計を見直さない限り、現場の疲弊はむしろ加速するでしょう」
生成AIは、ソフトウェア開発の在り方を根本から変えつつある。しかし、それは単純な「効率化」ではなく、「仕事の質と負荷の再配分」に他ならない。
「AIで楽になる」という幻想に依存したままでは、現場の疲弊は見過ごされ、やがて品質低下や人材流出という形で企業に跳ね返る可能性が高い。
AIを真に生産性向上の武器とするためには、その裏側で生じる負荷を正しく認識し、制度と評価を再設計する必要がある。そうしたマネジメントの進化こそが、AI時代の競争力を左右する分水嶺となる。
（文＝BUSINESS JOURNAL編集部、協力＝小平貴裕／ITジャーナリスト）