オピニオン分析

コードは3倍速でも会社全体は15%——AI生産性「期待とのギャップ」の正体

住友電装の実測4倍とシニアエンジニアの体感15%が示す、ボトルネック移動という見落とし

山本 浩二|2026.09.02|7|更新: 2026.09.02

富士通20%・日立30%は目標値、住友電装の改善速度4倍は実測。コード生成が3倍速でもシニア技術者の1日は約15%しか速くならない構造的ギャップが浮かぶ。

Key Points

Business Impact

経営者は「〇%向上」という発表を見たら、まず測定対象が『特定工程』か『業務全体』かを確認し、コード生成だけでなくレビュー・テスト・意思決定にかかる時間を含めた前後比較を自社で実施してから投資判断をすべきだ。

white and black typewriter on green grass during daytime

「生成AIでコーディング生産性が20%向上」「3倍速く書ける」——こうした数字が飛び交う一方、実際に組織全体のスループットで見ると、その効果は驚くほど小さいことが複数のデータから見えてきた。問題はAIの性能ではなく、局所的な高速化を全体の生産性向上と混同する認識のズレにある。

AI生産性向上「20%」「30%」の数字、その大半は実測ではなく目標値だった
出典: nohumans.jp
Shin丨AI×プロダクト開発の専門家🤵🏻 (@shin_sasaki19) on X
出典: X (formerly Twitter)

「20%」「30%」という数字の正体

富士通のソフトウェアオープンイノベーション事業本部長・粟津正輝氏は、Azure OpenAI Serviceを使ったコーディングと単体テストで「平均20%の生産性向上を期待」すると述べているが、これは実測ではなく期待値である。日立製作所も基本設計から総合テストまでの工程で2027年に30%向上を目標に掲げるが、研究開発グループ主管研究長・小川秀人氏はこれを「ChatGPTを使った結果から推測した目標値」と説明しており、確定した実測値ではない。人間不要新聞の報道によれば、実測データを公表しているのは住友電装のカンボジア拠点(改善速度約4倍)などごく一部にとどまる。三菱UFJ銀行も約3万人の生産性改善を掲げるが、具体的な向上率は示されていない。実測には半年単位のパイロット運用と比較計測が必要で、住友電装のケースでも14人体制・半年をかけている。目標値はPoC段階でも発表できるため、市場には期待値の方が多く流通するという非対称性が生まれている。

コードは3倍速でも、全体は15%

この「期待と実測のズレ」を最も端的に説明するのが、エンジニアリングリーダーBjorn Roche氏の試算だ。Shin氏の解説投稿によれば、シニアエンジニアの1日8時間のうち、AI導入前は新規コード作成1.5時間、既存コード読解・デバッグ1.5時間、設計・アーキテクチャ1時間、レビュー0.75時間、管理業務0.75時間、テスト・デプロイ0.5時間、メンタリング0.5時間、会議1.5時間という内訳だった。AIによってコード作成は1.5時間から0.5時間へ、読解・デバッグは1.5時間から1時間へ短縮される一方、設計・レビュー・管理業務・メンタリング・会議はほぼ変化しない。むしろ生成コードが増えた分、テスト・デプロイは0.5時間から0.75時間へ増加する。合計は8時間から6.75時間、改善率はわずか約15%にとどまる。局所では3倍速、全体では15%——これはソフトウェア開発版の「アムダールの法則」であり、一部の工程だけを高速化しても、変わらない工程が全体の上限を決めてしまう構造だ。一方でジュニアエンジニアは新規コード作成の比率が高いため、8時間から6時間へと約25%の改善が見込まれるとされ、シニアより恩恵が大きいという逆説も指摘されている。

実測が示す「効果はあるが局所的」の実例

局所最適化の効果自体は否定できない。レバレジーズのテック部門の報告では、デザインシステム導入によりフロントエンド全体のUI実装速度が30%向上したとデータで確認されている。開発者からは「Figmaのコンポーネント名と実装名が一致し迷わず実装できる」「Storybookでコミュニケーションコストが大幅削減された」といった声も寄せられ、UI一貫性担保では5段階評価で4.27点という高評価も得ている。ただしこの30%は「UI実装」という特定工程に限定した実測値であり、要件定義や意思決定、リリースまでのリードタイム全体を含む数字ではない。同社は今後AI Agent Skillsを活用し、Template as a Serviceを「AIが使いこなすプラットフォーム」へ進化させる計画を掲げているが、これもまた特定工程の効率化であり、事業全体のスループットを直接測る指標ではない点に留意が必要だ。

ギャップの構造——ボトルネックの移動

Roche氏の指摘で重要なのは、アウトプットが増えてもリリースが増えないなら「AIが効いていない」のではなく「次のボトルネックが見えた」だけだという整理だ。コード生成だけを高速化すれば、制約はレビュー、テスト、意思決定へ移動する。要求が曖昧なままなら、AIは「間違ったものを速く作る」だけになる。個人は速くなってもチーム全体は遅くなるという逆転すら起こり得る。富士通社内でも、粟津氏が量的な生産性向上を語る一方、同社人工知能研究所の小林健一氏は「コード生成より設計の品質向上に効果がある」と別の観点を示しており、同一組織内で評価軸が割れていること自体が、実測の乏しさと工程間のギャップの表れといえる。

経営者は何を測るべきか

測定すべきは生成コード行数やプルリクエスト数ではない。要求確定までの時間、設計判断の時間、レビュー待ち時間、テストと修正の往復回数、デプロイまでのリードタイム、リリース後の不具合数——これらを含めた業務全体の前後比較こそが、期待と実測のギャップを埋める唯一の方法だ。「〇%向上」という発表を鵜呑みにせず、まず自社の小規模拠点で工程全体をストップウォッチ計測し、目標値と実測値を明確に切り分けてから全社展開を判断する規律が、AI投資の成否を分けるだろう。

Verification

信頼ラベル分析
一次ソース3件確認
最終検証2026.09.02
VerifiedRev. 1
sha256:6111af455dd22e65...9026f4cd

この記事はEd25519デジタル署名で検証済みです。改ざんは検出されていません。

検証API
Ethics Score85/100
引用密度20/20
ソースURL数15/20
信頼ラベル10/15
表現の慎重さ10/15
キーポイント10/10
サマリー品質10/10
本文充実度10/10

v1.0.0 — ルールベース自動採点

詳細API
Share

関連記事