2．AI-Native開発の品質を支えた3つの実践

1つ目：ドキュメントを起点に、全体の整合性を保つ

柳原
AI-Native開発の品質を担保するうえで、特に効果が大きかった取り組みは何でしたか。

茂呂
大きく3つあります。1つ目は、ドキュメントをAI-Native開発の核として、全体の整合性を継続的に確認できるようにしたことです。
ドキュメントを核とすることで、AIエージェントの作業品質を制御しやすくなり、システム全体に関するドキュメントと、機能ごとの詳細ドキュメントの間で整合性を保ちながら開発を進めることができました。そのうえで、コンポーネント間で担保すべき責務と、コンポーネント自身で担保すべき責務を、AIエージェント自身が確認できるようにしました。

柳原
ソースコードと複数のドキュメントの整合性を保つのは、実際にはかなり難しいですよね。具体的にはどのように実現したのでしょうか。

茂呂
ソースコード、テスト、ドキュメントすべてに導出元などの管理情報を記載することで、AIエージェントが作業時に参照すべき成果物を自ら判断できるようにし、整合性を保つことができました。その結果、下位のドキュメントから上位のドキュメントをたどれるようになり、上位ドキュメントへの追従性は非常に高く、一定の整合性を担保することができました。一方で、上位ドキュメントから下位のドキュメントをたどることが難しく、ドキュメント修正時の影響調査に時間がかかるなどの課題があります。この点は今後さらに改善していく必要があると考えています。

2つ目：AIエージェントのログを残し、後から検証できるようにする

茂呂
2つ目は、AIエージェントが何をしたのかをログとして残したことです。成果物だけを見るのではなく、そこに至るまでの作業の履歴もログとして見えるようにしました。
たとえば、バグ管理表を変更した際に修正日時の記載が漏れていた場合でも、ログを見れば、いつ、どのタイミングで漏れが発生したのかを確認できます。
すべての作業を追跡できるわけではありませんが、主要な判断や変更の履歴が残っていれば、品質を検証するうえで重要な手がかりになります。

柳原
AIエージェントの行動の見える化という意味では、データベースのジャーナルに近い考え方ですね。

茂呂
そうですね。私たちの仕事の本質は、「プロセスを組んで、開発者に仕事してもらう」ことです。その精度と解像度がAIエージェントとそのログによって、一気に向上したと感じています。AIエージェントの作業をログとして記録することで、実際にどのプロセスで、どのような開発タスクが行われたのかを細かく把握できます。また、これに伴い品質分析や成果物分析の精度も向上したと考えています。

3つ目：ウォーターフォールの型は変えず、開発サイクルを高速化する

茂呂
3つ目は、ウォーターフォール開発の進め方そのものは変えずに、その開発サイクルをAIエージェントによって大幅に短縮したことです。
これまでは、ある程度の規模の開発を経験するには1プロジェクトあたり3～4年かかるため、20年働いても5案件程度しか経験できませんでした。しかしAIエージェント登場後は、要件定義から総合試験までの1サイクルの結果が1か月足らずで確認でき、ログをたどることで以前の工程に戻ってやり直すことも可能になりました。その結果、従来より多くの経験を短期間で積むことができ、仕事の熟練度をより早く高められます。
実際に今回のプロジェクトでは、半年の間に部分的な再実施も含めて10回以上、ウォーターフォール開発のサイクルを回しています。
これは開発方式をアジャイルに置き換えたわけではなく、ウォーターフォール開発の進め方をそのまま踏襲しているため、品質を担保するプロセスも従来通り実行できています。AIエージェントによって変わったのは、サイクルを回す速さだけです。

柳原
これまでの人間だけの開発ではありえない速度でV字モデルを繰り返すことができるのですね。サイクルが速くなった分、人間が確認すべき範囲も変わったのではないでしょうか。

茂呂
はい。今回は、品質評価や設計判断などは人間が対応しました。一方で、コードの全量を人が逐一レビューする運用にはしていませんでした。
ただ、振り返るとコードレビューは実施すべきだったと考えています。たとえばTERASOLUNAの標準から外れた項目については、品質が担保できていない可能性があるため、コードレビューで検出すべきでした。
この反省を踏まえ、現在はAIによるコードレビューでどこまで品質を担保できるかの検証を進めています。直近では、観点表の工夫によりかなりのバグを検出できているため、手応えを感じており、近いうちに具体的な数値として示せる見込みです。

柳原
AIエージェントによる開発が進むことで、人間がコードを1行ずつ読む時代ではなくなるという未来を以前に語ったことがありますが、もしかしたらすぐそこまで来ているのではないかという印象を受けました。

茂呂
はい、私もそう感じます。実際に今回の振り返りを通じて、開発面だけでなく管理面も含めたシステム開発全般の作業をAIエージェントへ委託する検証を進めています。現在の検証では、ソースコードレビューだけでなく品質評価や設計判断についても人のレビューを大幅に省略しており、このような開発方式を実務に投入する日も近いと考えています。
従来の大規模開発では多くの人が参画し、高額なツールも必要でしたが、GitHub Copilotはライセンスコストが非常に低く、かつ機能も豊富であるため、そういった要素に後押しされて、このような革新的な取り組みを進めることができていると考えています。

3．AIエージェント導入に苦戦するプロジェクトへのメッセージ

柳原
AIエージェントの導入に苦戦しているプロジェクトでは、どのようにAIを活用していくべきだと考えますか。

茂呂
エンタープライズ領域におけるAIエージェント導入では、これまで私たちが得意としてきた開発マネジメントの中に、AIエージェントという「開発者」が参画してきたと捉えることが重要です。
たとえば、人にタスクを依頼する際には、目的や前提条件、役割分担、成果物の期待値を伝えますが、AIエージェントに対しても同様です。何を作ってほしいのか、どのドキュメントを参照すべきか、どの品質基準を満たすべきかを明確にしたうえでタスクを進めることが大切です。
もちろん、人とAIエージェントでは品質特性の勘所は異なりますが、根本的な考え方は変わらないと考えています。「開発者」が人であろうとAIエージェントであろうと、不確実性のある状況下で開発を進めていくためのノウハウは私たちの中に既に蓄積されているため、それに気付くことができればAIエージェントの活用は一気に進むのではないでしょうか。

4．今後の展望：規模拡大と基盤への挑戦

柳原
茂呂さんの今後の展望についても聞かせてください。まず、AI-Native開発のプロジェクト規模拡大についてはいかがでしょうか。

茂呂
今年度の目標は、100万行規模のシステムでAI-Native開発を実践することです。100万行規模は当社にとっても大規模な部類に入るので、これに成功すればAI-Native開発を適用できる領域が大きく広がると考えています。

柳原
大規模化すると、プロジェクト全体で用語を厳密に定義するユビキタス言語のような考え方が必要になりそうですね。

茂呂
はい。大規模なAI-Native開発を進めるにあたって用語の統一は必須です。ただし、その用語統一すら将来的に不要になる可能性もあり、AIエージェントの発展についてはまだ見通せていない部分が多くあります。引き続き技術的な連携をお願いしたいと考えています。

柳原
規模の拡大以外に、今後取り組みたい方向性はありますか。

茂呂
基盤領域へのAIエージェント適用です。今回の取り組みは機能要件の開発が中心でしたが、今後は非機能要件やデプロイまでAIエージェントで扱えるようにしたいと考えています。
たとえば、基盤構成コードの作成からアプリケーションのデプロイまでをAIエージェントが担い、進捗管理や品質管理などのプロジェクト管理面もAIエージェントに担わせ、人間は判断に徹するという形を目指しています。そこまでできれば、本当に一気通貫のAI-Native開発が実現できると考えています。

柳原
最後に、AIエージェントの活用が進むことで、NTT DATAの仕事は変わると思いますか。

茂呂
本質は変わりません。むしろ、手段が高度化したことで、私たちがこれまで培ってきたノウハウを最大限に活かせる時代が来ていると感じています。
AI時代のソフトウェア開発において、LLMのハルシネーションや非決定性への対処が前例のないものとして議論されていますが、人の誤りや非決定性への対処は、私たちNTT DATAが長年に渡りノウハウを積み上げてきた領域です。また、モデルが変わったときの特性や品質の見極めについても、プロジェクトごとにメンバーが変わる中で、その開発者との付き合い方を学んでいくという意味でも、これまで当たり前にやってきたことと何ら変わりありません。
NTT DATAが積み重ねてきたシステム開発の知見は、AI時代の競争力そのものと言えるのではないでしょうか。品質を保ちながら安心して使えるシステムを社会に届ける。そこに、これからもNTT DATAが果たすべき役割があると考えています。