NTTデータが挑む「全工程AI自動化」…人手不足の救世主か、巨大ブラックボックス”への片道切符か

●この記事のポイント
・NTTデータが打ち出した「全工程AI自動化」は、人手不足に悩む日本SI業界の構造を根底から揺さぶる。人月商売の終焉と、成果報酬型への転換を迫る衝撃の中身を読み解く。
・要件定義から実装・テストまでをAIに委ねる開発は、生産性向上の切り札となる一方、「直せないシステム」という新たな技術的負債を生む危険性も孕む。その落とし穴とは。
・AIネーティブ開発は日本ITの希望か、それとも制御不能なブラックボックスへの道か。NTTデータの挑戦を通じ、AI時代に人間と組織が守るべき「知性と責任」の在り方を問う。

「日本のSIerの代名詞」が、ついに“禁断の一歩”を踏み出した。NTTデータグループが掲げるのは、要件定義から設計、コーディング、テスト、運用改善までを生成AIで連結する「AIネーティブ開発」への大転換だ。狙いは明快である。足りない人手を、AIで埋める。人月で回してきた業界の常識を、自ら壊す。

　だが、問いはここからだ。それは「生産性革命」なのか。それとも、誰も中身を説明できない“巨大ブラックボックス”を社会インフラに埋め込むことなのか。

●目次

• 「全工程AI化」とは何か――“コード自動生成”よりも大きい話
• 日本特有の“絶望的な需給ギャップ”とレガシーの呪縛
• SIを支えた「人月モデル」は、なぜ自壊に向かうのか
• いま広がる「バイブコーディング」の罠――“動く”と“直せる”は別物
• 「直せないシステム」が量産される──その現実的なシナリオ
• どうすれば“救世主”になり得るのか――AI全工程化の3条件
• 2026年、日本が直面する「真の岐路」

「全工程AI化」とは何か――“コード自動生成”よりも大きい話

　生成AI導入というと、どうしても「コードを書かせる」イメージに引っ張られる。しかし、本丸はむしろ前工程と後工程にある。

　要件定義：議事録・現行業務・例外パターンを整理し、矛盾や抜け漏れを検出する
　設計：アーキテクチャ、データモデル、API仕様、セキュリティ要件の“たたき台”を高速に作る
　実装：変更差分の整合性を保ちながら、依存関係更新・静的解析・ライセンス確認まで含めて回す
　テスト：ユニットからE2E、負荷、回帰までを自動化し、テストデータも生成する

　要するに、「人が手を動かす工程」をAIでつなぎ、開発を“連続生産”に近づけようという発想だ。国内大手SI出身のITジャーナリスト・小平貴裕氏はこう整理する。

「AI導入の主戦場は、実はコーディングより“要件の矛盾”と“テストの網”です。コード生成は見栄えがいい。でも障害を減らすのは、要件とテストと運用設計。そこまで含めて自動化しようとするなら、確かに産業構造を揺らします」

日本特有の“絶望的な需給ギャップ”とレガシーの呪縛

　舵を切らざるを得ない理由は、日本のIT現場が抱える構造問題にある。老朽化した基幹系の刷新、サイバー対策、AI導入の圧力――需要は増えるのに、供給（担い手）が追いつかない。

　現場ではすでに「属人化」と「燃え尽き」が同時進行している。古い言語、古い業務、古い運用に精通したベテランが抜ける一方で、若手は“保守で消耗するキャリア”を避けがちだ。需要過多のなかで、従来の延命策（増員・外注・残業）には限界が来ている。

「日本のレガシー刷新は、技術課題というより“人の課題”です。ノウハウを持つ人ほど希少で、引退も近い。AIは、その知の継承を仕組みに落とす最後のチャンスかもしれない。ただし、雑にやれば“継承”ではなく“断絶”になります」

SIを支えた「人月モデル」は、なぜ自壊に向かうのか

　ここで重要なのは、今回の動きが単なる効率化ではなく、SIの稼ぎ方そのものに踏み込む点だ。

1）効率化が「減収」になりうるパラドックス
　準委任（人月）中心のまま開発効率が上がれば、投入工数が減り、売上が目減りする。つまり、現行モデルのままでは「生産性向上＝自分の首を絞める」になりかねない。

2）成果報酬・バリューベースへの圧力
　だからこそSIerは、“工数”ではなく“価値”で対価を得る方向へ押し出される。たとえば「物流コストを15％削減」「与信審査の処理時間を半減」など、事業KPIと連動させる契約だ。

　ただしこれは、発注側にとっても簡単ではない。価値算定、監査、責任分界、要件変更の扱い――稟議と会計の世界が追いつかない。理想論ではなく、制度の変化が必要になる。

3）“中間マージン”の居場所が薄くなる
　多重下請け構造は、管理コストと情報ロスを生む。工程がAIで連結されれば、「人数を束ねて回す」だけのプレイヤーは価値を出しづらくなる。逆に、業務理解・設計責任・セキュリティ統制を担える企業に価値が集中する。

　大手企業の情報システム部門で調達改革を担当した経験者はこう指摘する。

「AIで工数が縮むほど、“何を成果とするか”の合意が重要になります。SIerの変革というより、発注側の調達・契約の変革でもある。ここを変えずにAI化だけ進めると、揉め事が増えるだけです」

いま広がる「バイブコーディング」の罠――“動く”と“直せる”は別物

　効率化の先に潜む最大のリスクは、「理解しないまま作れてしまう」ことだ。生成AIとの対話で、ロジックを腹落ちさせる前に“それっぽいもの”ができる。しかも、部分的にはうまく動く。これが、いわゆるバイブコーディング的な落とし穴である。

　問題は、規模が大きくなるほど露呈する。

　例外処理の欠落：正常系は通るが、境界条件で壊れる
　局所最適の継ぎはぎ：一箇所を直すと別の箇所が崩れる
　設計判断の不在：なぜその構造なのか、理由が残らない
　運用の弱さ：ログ、監視、トレースが薄く、原因特定が遅れる

　ここで怖いのは「バグ」そのものではない。直す速度（MTTR）が落ちることだ。社会インフラ級の基幹系では、復旧が遅れるほど損失が雪だるま式に膨らむ。

　セキュリティ監査に携わる専門家はこう釘を刺す。

「AI生成コードの怖さは“脆弱性が混ざる”より、“混ざったことに気づけない運用”です。設計の根拠、依存関係、テスト証跡が残っていないと監査も復旧も地獄になります。AIを使うなら、証跡（エビデンス）を自動で残す設計が先です」

「直せないシステム」が量産される──その現実的なシナリオ

　仮に、全工程AI化の勢いのまま大規模基幹システムを作ったとしよう。数年後、制度改正や業務変更で大きな改修が必要になる。そこで起きうるのは、次の“静かな破綻”だ。

　・当時の設計判断がドキュメント化されておらず、意図が追えない
　・生成物の整合性を検証する回帰テストが薄く、改修のたびに事故が増える
　・開発者は「AIに指示して作る人」になり、内部構造を説明できる人が減る
　・結果として、変更コストが跳ね上がり、改修が怖くて止まる

　それは「技術的負債」の爆発であり、経営にとっては将来の保守費用という“見えない負債”になる。

どうすれば“救世主”になり得るのか――AI全工程化の3条件

　NTTデータの挑戦が成功するかどうかは、「AIを入れる」ではなく「統制を作る」で決まる。ポイントは3つだ。

1．設計判断を“人が読める形”で残す
AIが生成した仕様・設計・変更理由を、レビュー可能な形で自動記録する。後から説明できることが前提になる。

2．品質KPIを“効率KPI”より上位に置く
リードタイムだけで評価すると、ブラックボックス化が加速する。変更失敗率やMTTR、脆弱性混入率などを同じ重さで追う。

3．責任分界を明確にする（AIは責任を負えない）
最終責任は人と組織が持つ。だからこそレビュー、承認、監査の線を引く必要がある。プロダクト開発を支援するテックコンサルタントはこうまとめる。

「AIは“速く作る”道具ではなく、“速く検証する”道具として設計すべきです。要件の矛盾検出、テスト生成、セキュリティ解析、変更影響分析。ここにAIを使い、最終判断は人が持つ。この逆にすると、破綻が早い」

2026年、日本が直面する「真の岐路」

　日本は今、周回遅れの熱狂に乗るのか、それとも慎重な実装で先行者利益を取りに行くのか――岐路に立っている。

　NTTデータの「AIネーティブ開発」への踏み込みは、成功すれば人手不足を乗り越える大きな突破口になる。だが、統制なき全自動化は、将来の保守・監査・説明責任という形で“高くつく”。

　問われているのは、AIを使えるかどうかではない。AIが吐き出した答えに対して「なぜそうなるのか」「それは責任を持って説明できるか」と問い続ける、組織としての知性――その設計思想である。

（文＝BUSINESS JOURNAL編集部）