「要件定義はAIの指示書」――NTT DATAが示す、AI時代に品質と速度を両立する条件

AIはコードを書く速度を一変させたが、速くなったぶん、曖昧なままの要件も同じ速度でシステムに反映されていく。6月11日に開催された「AI要件定義サミット2026」において、NTTデータグループの海浦（かいうら） 隆一氏が「AI時代の開発プロセス実践論」と題して登壇した。大規模金融系システムの開発を経て、全社の生成AI活用手法の確立と普及を担ってきた人物である。実装を速くしたAIが品質問題の発生源を上流へ押し上げたというのが海浦氏の見立てであり、その打開の鍵として示したのが、要件を「正しく定義する力」だった。

AI-Native開発で「何が変わったのか」

海浦氏はまず、生成AIの活用がコーディングの一部にとどまらず、ソフトウェア開発のプロセス全体へ広がっている現状を示した。NTT DATAはその活用を、既存の標準開発プロセスへの生成AI適用と、「AI-Native開発」という2つの軸で進めている。

前者は、NTT DATAの標準開発プロセスであるTERASOLUNA®（テラソルナ）をベースに、これまで人手でやってきた工程を生成AIで効率化する取り組みで、2023年にGPT-3.5が登場した頃から加速させ、いまでは多くの案件で適用できる状態まで広げてきたという。ただし2つの軸は性格が異なり、既存プロセスへの適用が多くの案件で今すぐ効く代わりに生産性の伸びは中〜高にとどまるのに対し、一方のAI-Native開発は伸びが非常に大きい代わりに適用には条件がつく。

そのAI-Native開発では、生成AIが成果物を作り、人はそのレビューと承認に回るというように、開発の組み立て方そのものが変わる。開発の主体が人からAIエージェントへ移ることが従来との分かれ目であり、海浦氏はコード生成の速さを「コーディングの速度は劇的に高まった」と表現した。

もっとも、速くなったのは出力の側だけであり、入力が曖昧であれば、その曖昧さも同じ速度で成果物に乗ってしまう。「曖昧な内容を入力すると、それが曖昧なまま出力にも出てしまう」と海浦氏は言う。生産性の向上率は高い一方で、レビューに時間を取られて期待したほどの効果に届かない場面も出ているといい、速くなったぶん、入力の曖昧さもそのまま増幅される。だとすれば、次に問われるのは、AIに何をどう入力するかである。

実装が速くなり、ボトルネックは上流へ移った

コーディングがここまで速くなった背景を、海浦氏はLLMの進化に求める。NTT DATAがChatGPT EnterpriseのDeep Research機能とcodeforcesの2024年レーティングを独自に対応づけた図では、プログラミング能力の指標はGPT-4oで808程度（下位11%、新人レベル）だった。それがGPT-o3で2,700超（上位0.2%）、GPT-5.4で3,100超へと伸び、縦軸の上限6,000に向けてなお上昇を続けている。

実装が軽くなると、開発全体のボトルネックがこれまでと変わる。実装の工数が縮む一方で、出力を確かめるテストの比重は相対的に増し、要件定義や設計の工数はむしろ従来と変わらないか少し増えるため、速くなった部分だけを取り出して生産性が上がったとは言いにくい、というのが海浦氏の見立てである。

加えて、エンタープライズ開発に求められる品質の水準そのものは変わらない。非機能要求グレードで示される性能や可用性、セキュリティといった観点は、AIが書いたコードであっても引き続き満たす必要があり、動けばよいという話にはならない。特に日本ではこの水準が当面下がる見込みはなく、しかもこれらをAIがすべて自動で確認できる段階には、まだ至っていないと海浦氏は見る。

こうして品質問題の出どころが変わる。従来は実装からテストの段階で表面化していた不具合が、AI開発では上流へとさかのぼり、海浦氏は「品質問題の発生源が、実装より前の工程から出てくるのではないか」と見立てる。要件や設計の曖昧さが、そのまま最終品質に直結する構図であり、問題はその曖昧さがどこから生まれるかへと移っていく。

システム開発は入力品質で決まる――AIは「曖昧さ」を補完しない

要件定義の成果物が設計の入力になり、その設計が実装の入力になるように、システム開発では各工程の成果物の品質が、そのまま次工程の入力品質を左右していく。AIが成果物を作る側に回っても、この連鎖の構造は変わらない。だからこそ海浦氏は、システムの品質は入力の品質で決まると説く。

入力が曖昧なとき、人は書かれていない前提を自分で補える。ドキュメントにない業界の常識や顧客との約束事を、同じプロジェクトのメンバー同士の共通認識として読み取り、経験や業務知識、対話やレビューを通じて足りない部分を埋めていく。「人間は、書いていないことまで補完できてしまう」と海浦氏は振り返る。

AIはそうした補完をしない。「AIは曖昧さを自ら補完しない」。不足した前提や意図を理解しないまま、もっともらしい成果物を生成してしまうため、「この種のシステムなら、この程度の非機能要件は満たして当然」といった暗黙の前提は、指示しない限り出力に反映されない。

AIが指示なしには拾わない観点は、性能や可用性などの非機能要件、例外やエラーの処理、セキュリティ、運用・保守、データ整合性にまで及び、こうした「満たして当然」の前提が分厚く積み上がっているエンタープライズ開発ほど、その差は結果に効いてくる。従来のプロセスのまま生成AIを「追加ツール」として脇に付け足すだけでは効果が限定的になるのも、入力の作り込みそのものを変えていないからにほかならない。曖昧さの排除こそが品質を決めるとすれば、次の問いは、その曖昧さをどうやって消すかである。

要件定義はAIの指示書――問われる「正しく定義する力」

その曖昧さを消せるかどうかは、入力をどこまで作り込めるかにかかっている。海浦氏は登壇で、自然言語の簡単なプロンプトだけを渡してコードを生成させる「バイブコーディング（自然言語の指示だけでAIにコードを生成させる手法）」と、要件を構造化して渡すやり方とを、航空券予約システムを思わせる題材のデモで対比してみせた。前者はClaude Opusに短い指示を渡すだけでも画面まで組み上がってしまうが、運賃の割引率や運賃のバリエーションといった肝心の条件はライトにしか書かれておらず、エンタープライズの品質を満たすレベルでは確約が取れないと海浦氏は留保をつけた。速度は上がっても品質は安定しない、というのがその見立てである。

これに対し、もう一方の「AIレディ（AIが処理しやすい形に整備された状態）」な入力では、同じ要件を設計の手前まで踏み込んで細かく定義し、構造化したうえでAIに渡す。業務フローやデータ要件、非機能要件、コーディング規約といった要件の構造化に加えて、ドメイン知識やインシデントの知見、レビュー経験、暗黙知という、これまで人が当然のものとして抱えてきた知見を、従来以上の粒度で重ねていくものだ。海浦氏によれば、「詳細な設計まで行かずとも、要件定義の段階である程度細かい情報まで渡せば、ほぼ期待どおりの成果物が得られる」という。

人が開発の中心にいた時代は、要件定義をいったん粗く決めても、設計工程での段階的な詳細化を通じて品質を作り込むことができた。だがAIが実装を一気に進める以上、その詳細化を一つずつチェックする手順そのものが回らなくなりかねず、最初に与える入力の質が、最終品質を大きく左右する。海浦氏はこれを「要件定義はAIの指示書」と言い切る。従来の要件定義とは異なるレベルまで作り込んだものをAIに渡すことが、品質と速度を両立させる第一歩になる。

どこから適用するか――成熟度の「現実路線」

最後に海浦氏は、AI-Native開発をどこから適用するかを、システムの特性に応じた4象限で整理した。デモやMVP、PoCといったアジリティ重視の領域では、簡単なものならバイブコーディングが今すぐ商用案件で使え、同社でも適用が増えているという。顧客接点や社内ワークフロー、中規模のエンタープライズ領域でも、AI-Native開発をチャレンジとして適用できる状況になりつつあり、既存プロセスへの生成AI適用なら即着手できる。

難所は、決済インフラや勘定系のようなミッションクリティカルな領域である。ここでは既存システムに設計書をはじめとする大量の資産があり、それがAIレディな状態になっていないことが最大の壁になる。海浦氏は、適切な品質を保ちながらAI-Nativeを適用できるのはまず新規開発、かつ規模がそれほど大きくない領域だと、同社が現時点で置く制約として率直に語った。

成熟度の観点でも、現実は段階的である。同社はAIへ委ねる範囲に応じて、成果物の生成をAIが担うLevel 1（AI-Generated）から、品質チェックまで担うLevel 2、プロセスの透明性まで自律化するLevel 3までを定義しているが、実践しているのは現状Level 1にとどまる。海浦氏は、Level 3を掲げるホワイトペーパーがある一方で、日本で説明責任を果たすうえでは「レベル1プラスアルファ」が現実的なラインだと、個人的な見解と断ったうえで述べた。

海浦氏が示したポイントは3点だ。生成AIの活用が開発プロセス全体へ広がっていること、それでもAIだけで品質を担保できるわけではなく人の適切な介在が要ること、そしてAIに質の高い出力をさせるには要件定義と入力情報の作り込みが欠かせないことである。最後はこう締めくくった。「AIに高いアウトプットを出させるには、要件定義や入力情報をしっかり作り込むことが非常に重要だ」。