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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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