はじめに
昨今、「生成AIの登場で、プログラマやSEは不要になる」という言説をよく目にします。
私自身、主に製造業・SCM領域の基幹システムで、コンサルティング（上流）から実装（下流）の現場を見てきた経験を踏まえ、「生成AIにできること・苦手なこと」について整理してみたいと思います。
1. 「決定論」の基幹システムと「確率論」の生成AI
まず、大前提として、AIが生成するコードは確率論的であり、従来の決定論的なプロセスとは異なります。企業の基幹システム（ERP、SCM、会計システムなど）において、不確実性（同じアウトプットに対して、結果が異なる）は回避すべき点です。
財務会計のロジックは商法や会計基準（GAAP/IFRS）で定められており、決定論（Deterministic）的なロジックで作るべきです。インプットが同じであれば、何万回実行しても同じアウトプットが返ってくる必要があります。
一方、生成AI（LLM）は仕組み上、確率論（Probabilistic）で動作します。
AIは高機能になるほど「気を利かせて」しまう
最近、AIのモデル性能が上がった結果、意図しない挙動・余計な機能の追加が増えていると感じます。
初期のモデルに比べてGPT-4などの高性能モデルは文脈を深く読み取ろうとします。その結果、シンプルな指示に対しても、頼んでいない機能を追加実装してしまうことがあります。
- 「将来的な拡張性を考慮し、インターフェースを抽象化しました」
- 「念のため、例外処理の分岐を追加しておきました」
実際の企業のシステムでは、様々な制約（予算、レガシーシステム等）から、敢えてそぎ落としている機能もあります。したがって、世の中のベストプラクティスとは合致しない要件も存在します。
AIが気を利かせれば利かせるほど、人間が不要な機能を修正する工数が発生するという実態があります。
2. データに見る「AIコードの品質」
「修正の手間を含めても、AIが書いた方が速い」という意見もありますが、これに関してはAIコードの品質リスクを示す具体的なデータがあります。
米GitClear社およびAIレビューツールを提供するCodeRabbit社の調査レポートによると、AI生成コードは人間が書いたコードと比較して、承認（マージ）率が著しく低く、バグを含む確率が高いことが示されています。
① AIによるプルリクエスト承認率の低さ（GitClear調査）
GitClearが1億行以上のコード変更を分析した結果、AIアシスタント（GitHub Copilot等）の導入前後で以下の傾向が確認されています。
-
AI生成PRの承認率：約33%
AIによって生成されたプルリクエスト（PR）のうち、最終的にマージ（承認）されたものは全体の約33%に留まります。残りの多くは、レビューで差し戻されるか、放置（Stale）されています。 -
人間によるPRの承認率：80%以上
比較対象として、AIを使わずに人間が作成したプルリクエストのマージ率は一般的に80%以上で推移しています。
GitClear "Coding on Copilot" Report
② 不具合混入率は1.7倍（CodeRabbitレポート）
また、AIコードレビューツールを提供するCodeRabbitの2025年版レポートでも、上記を裏付けるデータが示されています。
-
不具合発生率：1.7倍
100万件以上のプルリクエストを分析した結果、AI生成コードは人間と比較して「不具合が含まれる確率が1.7倍高い」ことが判明しました。これにより、レビュー段階での却下率が高くなっています。
CodeRabbit: State of AI vs Human Code Generation 2025
「AIでコーディング時間は短縮されたが、レビューを通らず、手戻りが発生している」というデータが見えます。
結局、AIが書いたコードの品質を担保し、最終的にシステムに組み込む判断（マージ）をするには、AI以上にコードを熟知した人間による目利きが欠かせません。
3. 「ノーコードでエンジニアが要らなくなる」という議論は10年前から存在した
「AIで開発がなくなる」という論調は、かつての「ノーコード・ローコード」ブームの際にもよく見た言説でした。
SalesforceやKintone、ERPパッケージを活用すれば、スクラッチでコードを書く量は減りますが、それによってシステム導入が簡単になったかというと、そう単純ではありません。
その背景には、要件をワンボイスにまとめることの難しさがあります。
システム開発の工数を圧迫し、プロジェクトを複雑化させる主な要因は以下のプロセスにあります。
- 政治的な調整：同じ部署内でも、担当者によって業務ルールの認識や要望が異なる。
- 暗黙知の存在：「マニュアルにはないが、現場の慣習として行っている処理」などの隠れた要件。
- 要件の後出し：UAT（ユーザー受入テスト）の段階で初めて発覚する追加要望。
生成AIに正しいコードを書かせるには、正確なプロンプト（要件定義）が必要です。しかし、その要件を人間側が定義しきれていない点が、システム開発における最大のボトルネックであり続けています。結局、AIだろうがNCLCだろうが、要件が決まってなければ、プロンプトが作れません。
4. 生成AIが「現場で活用できる」領域
もちろん、現在のAIはエンジニアにとって「使える武器」となります。例えば、基幹システム開発などの堅牢性が求められる現場では、以下のような領域でAIが真価を発揮します。
① ログ解析と障害特定
AWS CloudWatchやサーバーの膨大なログを目視で追うのは大変な作業ですが、AIは得意分野です。「特定のエラーログとDBデッドロックの相関関係」などを問い合わせることで、原因特定までの時間を大幅に短縮できます。
② テストケースの網羅性確認（例：境界値分析）
「在庫引当ロジックのテストケースについて、負の値やNULL、極端に大きな数値が入った場合の異常系をリストアップして」といった使い方は非常に有効です。人間が見落としがちなコーナーケースの洗い出しにおいて、良き壁打ち相手となります。
③ セキュリティチェックとベストプラクティスの照合
コードレビューにおいて、AIは強力なレビュアーになります。特にCVE（共通脆弱性識別子）のような公開されたセキュリティ推奨事項との照合は、人間が手作業で行うよりも遥かに高速です。
「膨大な公開データを検索し、目の前のコードと照合する」というプロセスはAIの得意分野です。
ただし、これらはあくまで「一般的な正解」との照合です。ビジネス要件のレビューは、文脈を知る人間にしかできません。
④ 要件確定「後」のコード生成
要件や仕様が固まった状態での、単体機能（Function）レベルのコード生成は非常に高速です。
一方で、画像生成や動画生成などはToC向けマーケティングでは有用ですが、BtoBの基幹システム開発においては、活用の場面が限定的であるのが現状です。
5. 生成AIには難しい「意思決定」と「責任」
技術的にAIが可能であっても、以下の領域は人間が担う必要があります。
① ビジネス要件の抽出と意思決定
例えば「来期のサプライチェーン戦略に合わせて、グラフ形式で在庫回転率レポートを見たい」という要望に対し、具体的にどう可視化するかは、人間の意志や利便性に基づく決定が必要です。過去のデータから確率的に答えを出すAIには、この意思決定は困難です。
② 結果に対する責任
AIには法的な人格がありません。仮に基幹システムが停止し、多額の損害が発生した際、「AIが生成したコードだから、我々の責任ではない」という理由は通用しません。
システムを納品し運用するということは、その挙動の全責任を人間である開発者が負うということです。責任能力を持たないAIは、あくまで支援ツールという位置付けになります。
6. おわりに：ヒューマン・イン・ザ・ループの重要性
これからの時代、エンジニアの役割は「コードを書く作業」から「AIの成果物を評価・修正し、責任を持つ役割」へとシフトしていくと考えています。
AIにドラフトを作成させ、それを人間が精査する「ヒューマン・イン・ザ・ループ」が標準になっています。
AIが書いたコードの正誤を判断し、セキュリティリスクを見抜くためには、AI以上に深い知識が必要になります。
GitClear社の調査が示す通り、AIコードを無批判に受け入れれば品質低下を招く恐れがあります。そのため、「プログラマ不要論」とは逆に、「コードの中身を理解し、ビジネス要件と照らし合わせて判断できるエンジニア」の価値が、今後ますます高まっていくと思います。
プロフィール
[Maruchin Tech]
AWS、製造業・SCM DXを専門とするUdemy講師・技術顧問。
新卒で日産自動車に入社。その後アクセンチュア、NTTデータを経て独立。
大手製造業の基幹システム刷新やDXプロジェクトにおいて、要件定義からアーキテクチャ設計までをリード。
現在は「現場で本当に使える技術と視点」をテーマに、エンジニア教育に従事。