はじめに
昨今、「生成AIの登場で、プログラマやSEは不要になる」という言説をよく目にします。
私自身、主に製造業・SCM領域の基幹システムで、コンサルティング（上流）から実装（下流）の現場を見てきた経験を踏まえ、「生成AIにできること・苦手なこと」について整理してみたいと思います。
1. 「決定論」の基幹システムと「確率論」の生成AI
まず、大前提として、AIが生成するコードは確率論的であり、従来の決定論的なプロセスとは異なります。企業の基幹システム（ERP、SCM、会計システムなど）において、不確実性（同じアウトプットに対して、結果が異なる）は回避すべき点です。
財務会計のロジックは商法や会計基準（GAAP/IFRS）で定められており、決定論（Deterministic）的なロジックで作るべきです。インプットが同じであれば、何万回実行しても同じアウトプットが返ってくる必要があります。
一方、生成AI（LLM）は仕組み上、確率論（Probabilistic）で動作します。
AIは高機能になるほど「気を利かせて」しまう
最近、AIのモデル性能が上がった結果、意図しない挙動・余計な機能の追加が増えていると感じます。
初期のモデルに比べてGPT-4などの高性能モデルは文脈を深く読み取ろうとします。その結果、シンプルな指示に対しても、頼んでいない機能を追加実装してしまうことがあります。
- 「将来的な拡張性を考慮し、インターフェースを抽象化しました」
- 「念のため、例外処理の分岐を追加しておきました」
実際の企業のシステムでは、様々な制約（予算、レガシーシステム等）から、敢えてそぎ落としている機能もあります。したがって、世の中のベストプラクティスとは合致しない要件も存在します。
AIが気を利かせれば利かせるほど、人間が不要な機能を修正する工数が発生するという実態があります。
2. データに見る「AIコードの品質」
「修正の手間を含めても、AIが書いた方が速い」という意見もありますが、これに関しては興味深いデータがあります。
米GitClear社が1億5000万行以上のコード変更を分析した2024年の調査によると、GitHub Copilotなどの生成AIツールの普及以降、「コードの書き直し（Code Churn）」が増加しており、コード品質への影響が懸念されるという結果が出ています。
GitClear "Coding on Copilot: 2024 Data Suggests Downward Pressure on Code Quality"
具体的には、AIが生成したコードに関して以下の傾向が見られるとのことです。
- 人間が書いたコードに比べて、後から修正（書き直し）が必要になる率が高い
- 複雑でメンテナンス性の低いコードが増加傾向にある
コーディングの時間は短縮されても、その後のレビューや手戻りに多くの時間が割かれている可能性があります。
AIが書いたコードをプロダクト品質にまで高め、最終的にマージするには、AI以上にコードを熟知した人間による目利きが欠かせません。
3. 「ノーコードでエンジニアが要らなくなる」という議論は10年前から存在した
「AIで開発がなくなる」という論調は、かつての「ノーコード・ローコード」ブームの際にもよく見た言説でした。
SalesforceやKintone、ERPパッケージを活用すれば、スクラッチでコードを書く量は減りますが、それによってシステム導入が簡単になったかというと、そう単純ではありません。
その背景には、要件をワンボイスにまとめることの難しさがあります。
システム開発の工数を圧迫し、プロジェクトを複雑化させる主な要因は以下のプロセスにあります。
- 政治的な調整：同じ部署内でも、担当者によって業務ルールの認識や要望が異なる。
- 暗黙知の存在：「マニュアルにはないが、現場の慣習として行っている処理」などの隠れた要件。
- 要件の後出し：UAT（ユーザー受入テスト）の段階で初めて発覚する追加要望。
生成AIに正しいコードを書かせるには、正確なプロンプト（要件定義）が必要です。しかし、その要件を人間側が定義しきれていない点が、システム開発における最大のボトルネックであり続けています。結局、AIだろうがNCLCだろうが、要件が決まってなければ、プロンプトが作れません。
4. 生成AIが「現場で活用できる」領域
もちろん、現在のAIはエンジニアにとって「使える武器」となります。例えば、基幹システム開発などの堅牢性が求められる現場では、以下のような領域でAIが真価を発揮します。
① ログ解析と障害特定
AWS CloudWatchやサーバーの膨大なログを目視で追うのは大変な作業ですが、AIは得意分野です。「特定のエラーログとDBデッドロックの相関関係」などを問い合わせることで、原因特定までの時間を大幅に短縮できます。
② テストケースの網羅性確認（例：境界値分析）
「在庫引当ロジックのテストケースについて、負の値やNULL、極端に大きな数値が入った場合の異常系をリストアップして」といった使い方は非常に有効です。人間が見落としがちなコーナーケースの洗い出しにおいて、良き壁打ち相手となります。
③ 要件確定「後」のコード生成
要件や仕様が固まった状態での、単体機能（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プロジェクトにおいて、要件定義からアーキテクチャ設計までをリード。
現在は「現場で本当に使える技術と視点」をテーマに、エンジニア教育に従事。