「作業の中心が、人からAIに転換する」――NTT DATAに聞く、AIネイティブ開発とエンタープライズ要件定義の行方

「作業の中心が、人からAIに転換する」。NTTデータグループ 技術革新統括本部 AI技術部 部長の海浦 隆一氏は、生成AIがもたらす開発現場の変化をそう表現する。

NTT DATAは、公共・社会基盤、金融、法人の各領域でミッションクリティカルなシステムを長年手がけてきた。そのなかで、AIが成果物を作り、人が品質と説明責任を担う「AIネイティブ開発」への移行を進めている。エンタープライズ品質を満たしながら、要件定義から実装、テストまでをAIにどう委ねていくのか――。現場の手応え、壁、そして要件定義そのものの再定義について聞いた。

AI技術部のミッション――生産技術の中心が変わる

――海浦さんは元々、開発畑と伺っています。現在の役割に至るまでの経緯を教えてください。

おっしゃるとおり、私自身、元々はシステム開発を中心に経験をしてきました。アプリケーション開発からインフラ面の開発責任者に至るまで、システム開発のあらゆる工程に対応してきました。生成AIへの本格的なシフトは、ChatGPTの3.5が登場して注目度が一気に高まった2023年の下期からです。生産技術の中心が変わってくる――そう見立てて、同年10月に専任メンバーとして体制を組みました。

――2025年7月に発足したAI技術部は、現在どのようなミッションを担っているのでしょうか。

大きく2つあります。1つは、全社における生成AI活用に関する技術開発です。新しい技術をどのようにNTT DATAのビジネスに落としていくかについて取り組んでいます。もう1つは、その先を見極めることです。現在はAIを中心に取り組んでいますが、その先の技術として登場してくるものは何か。その目利きもミッションの1つだと考えています。

人とAIの作業が逆転する「AIネイティブ開発」

――標準化、自動化、アジャイル。開発の生産性向上は、これまでもさまざまな形で進められてきました。その流れの中でみたときに、今回の生成AIは何が大きく違うのでしょうか。

基本的には、これまでの流れを加速させるものだと捉えています。生成AIも技術の1つであって、生成AIだけですべてを解消できるわけではありません。標準化のプロセスがあり、そのうえで生成AIを使って改善ポイントを見つけ出していく。そうしなければ、やはり改善は進まないのです。

生成AIは、指示した作業を形にすることはできます。ただし、毎回意図通りの成果物が得られる保証はありません。だからこそ、従来の自動化と組み合わせて活用する必要がある。そうすることで、成果物のばらつきを抑えることができます。加速の度合いは確かに大きいですが、従来の取り組みとはまったく別物だとは捉えていません。あくまで延長線上にあるものとして位置づけています。

――延長線上にあるとしても、何かしら質的な転換はありますか。

従来の自動化や標準化と大きく異なるのは、作業の中心が変わる点です。当社はこうした変化を踏まえた開発のあり方を「AIネイティブ開発」と呼び、先進的に適用できる領域から広げようとしています。

AIネイティブ開発とは、端的にいえば、AIエージェントが成果物を生成し、人がそれをレビューする開発スタイルです。中身や品質のチェック、何か起こった際の説明責任を果たすための検証など、人の役割がレビュー側へとシフトしていきます。つまり、人とAIの作業が逆転するイメージです。

これまでは、成果物の作成はすべて人が担い、AIがそれをフォローしていました。それをAIが代替してくれるのですから、ここは非常に大きな違いだと思っています。

――実際に生成AIを適用した現場では、どのあたりに効率化の手応えを感じていますか。

開発全体を通じて、効率化が実現できています。特にコーディングの領域では、成果物の作成をAIが担うことで、担当メンバーの作業は大きく改善されています。設計工程についても、成果物の作成はAIに任せる形で進めており、開発に必要なドキュメント生成に限定すれば、製造工程と同じくらいの効率化が実現できています。

一方で、試験などの後続工程については、工程ごとに求められる内容が異なるため、効率化の度合いには差があります。

――現場で止まりやすいのはどこでしょうか。

課題として大きく二つあります。一つは、AIが出力した内容の品質や、確認ポイントをどこに置くか、という点です。どのフェーズで確認を行えば、従来と同等の品質を担保できるのか――その最適解が悩ましく、現在はさまざまなパターンを試して、標準的なチェックプロセスを検討している段階です。

もう一つは、お客さまへの説明資料です。AI向けに最適化されたテキストは、機械にとって理解しやすい反面、人間にとってはかえってわかりにくくなる場合があります。特に、システムの実装に詳しくない承認者にとっては、そのままでは十分に腹落ちせず、結局、説明用の資料に作り替える工程が必要になります。

その修正自体もAIを活用することで一定の効率化は可能ですが、人の手作業はむしろ増える傾向にあります。そのため、設計工程全体でみると、製造工程ほどの効率化率は得られません。また、お客さまからの要望に応じて工数をかけなければ、最終的な納得感には繋がりません。

要件定義の再定義――上流で何を書き残すか

――生成AIを前提にすると、開発プロセスの順序そのものが組み変わる可能性もあると思います。たとえば、コードを先に作るといった発想も当初はあったと伺っています。

当初は、開発プロセスの順序も変わるのではないかと考えていました。生成AIはコーディングに強いという情報もあったため、要件としての適切な情報さえ与えれば、まずソースコードを生成し、そこから設計情報を逆算できるのではないかと考え、そうした進め方も検討していました。

ただ、試行を重ねるなかで、生成AIもある程度詳細な要件から設計をしなければ、品質の高いコードは出力しにくいことが分かってきました。品質を重視する場合は、人間中心のプロセスと同様な流れで作業をAIに代行させたほうが、結果として全体の効率化につながります。現在は順序を大きく入れ替えるというよりも、一連の流れ自体は維持しながら、AIにどのように情報を渡せば期待するアウトプットが得られるのか、そのプロセス設計を検討している段階です。

――では、上流工程の役割はどのように変わるのでしょうか。

従来の人間中心のプロセスでは、Excelベースで設計書を作成し、人間が読みやすい形で整理していました。その「読みやすい形」は、実は必要な情報がある程度補完された状態でもあったのです。1つのシステム、1つのプロジェクトで、同じお客さまを担当していれば、メンバー間で共通の前提や背景など理解が成り立っており、設計書とプログラムの間には、書かれていない暗黙知的な情報が存在していました。

ところが、その情報が欠けたままでは、AIは適切にコーディングすることができません。これまで明示していなかった情報まで、AIが活用できるよう言語化しておく必要がある――ここが大きな変化です。上流工程では、そうした情報をインプットとして用意しておくことが求められます。人が担っていた従来の開発との最大のギャップは、この追加情報をどこまで書き起こせるかにあると考えています。

では、その追加情報をどのように引き出すか。当社では、暗黙知を形式知化するために生成AIを活用する取り組みも進めています。インタビューエージェントやインタビューAIという形で、AIが有識者に質問を投げ、回答を蓄えていくのです。ただし、要件に必要な情報をすべてインタビューで得られるわけではありません。最終的には人が「この情報をAIに渡す観点ではどう書くべきか」と考えながら、インプットを設計する必要があります。

これまではお客さまとの合意事項を整理すれば十分でしたが、今後は背景情報も含めて、AIが適切なアウトプットを出すためのインプットを設計できる人をアサインしなければ、後続の開発を円滑に進めることは難しくなるでしょう。

エンタープライズの壁とプライベートLLMの現在地

――お客さまによっては、生成AIの活用に慎重な姿勢を取られることもあると思います。現在、現場ではどのような温度感で向き合っているのでしょうか。

お客さまによって状況はさまざまです。当社は公共・社会基盤、金融、法人、テクノロジーコンサルティング＆ソリューションの4つの分野に加え、グローバル領域も展開しています。そのなかには、インターネットに情報を出すことが絶対にNGというお客さまもおり、一般的なクラウド型の生成AIを利用できないプロジェクトも少なくありません。

そのため、オンプレミスで利用可能なエアギャップド環境や、プライベートAIと呼ばれるローカル構築のLLMを活用するなど、制約に応じた対応を進めています。また、インターネット利用が可能な環境であっても、生成コードの権利問題やアウトプットの信頼性への懸念から、活用を見送るケースもあります。何か問題が発生した場合の責任は最終的に我々のような開発側が負うことになります。

そのため我々は、AI任せにはしません。たとえば、従来から活用しているコードの静的解析サービスや、セキュリティチェックのツールを組み合わせたうえで納品することで、お客さまの求める品質水準に応えられる体制を整えています。

一方で、社内利用にとどまるシステムなど、品質面をあまり気にしないケースであれば、AIコーディングの効果はそのまま活用できるでしょう。しかしエンタープライズ領域では、それだけでは不十分な場面が多い。品質を担保しながら生産性も高める――この相反する要請に、どう折り合いをつけるかを日々検討しています。

――先ほど「プライベートAI」という言葉も出ました。あらためて、プライベートLLMについてはどう評価されていますか。セキュアな環境で利用できるため、導入したい企業も一定数あると思います。

性能面では、ハイパースケーラーのLLMに半年以上の遅れがある、というのが正直な印象です。リリース頻度も低く、差を詰めにくい。生産性向上を掲げる以上、お客さまが期待されるのは劇的な改善ですが、プライベートAIではその水準に応えきれず、期待外れに終わってしまうケースもあります。一方で、「何もしないよりは効率化できればよい」という前提で期待値を適切にコントロールできれば、プライベートAIも十分に活用できる場面もあります。

ハイパースケーラーのLLMはすでに実務に適用できる水準に達しており、必要な情報をコンテキストとして与えれば、多くのケースに対応可能です。同じ水準をプライベートAIで実現するには大きな投資が必要となり、単一の単位でみると現実的ではありません。プライベート環境で同等のモデルを運用するのは難しい、というのが今の見立てです。

また、小規模モデル（SLM）を活用する場合は、どこまで期待に沿うアウトプットを出せるかがポイントになります。そのためには適切なコンテキスト設計や、場合によってはファインチューニング（追加学習）も必要になるだろうと思います。

――6月11日の「AI要件定義サミット」では、聴衆に何を持ち帰ってほしいと考えていますか。

話の中心になるのは、要件定義工程でやるべきことです。後続工程をAIネイティブ開発で実行するためには、要件定義の段階で何を準備しておくべきか。ここを固めなければ、後工程の品質が担保できません――その具体的なポイントをお伝えできればと思っています。

エンタープライズシステムでは、高い品質を維持しながら高速化・効率化をどう両立するかが重要なテーマになります。そのために求められる要件定義やプロセスのあり方について、実践的な観点からご紹介する予定です。

また、成功事例だけでなく、「ここはなかなかうまくいかなかった」という失敗談も含めて、率直にお話しできればと考えています。みなさまの検討を進める一助になれば幸いです。