AI 2026年4月19日

設計書・コード・テストを全部AIに書かせた半年間：NTTデータの実録から見えてきたこと

何をやったのか

2025年10月から2026年3月の半年間、NTTデータ第三公共事業本部の茂呂範氏のチームは、お客様に納品する商用システムのサブシステムをゼロから「AIネイティブ」で開発しました。 Zenn

設計書・ソースコード・テストケースなどシステム開発の成果物をすべてGitHub Copilotで生成し、社員がそれをレビューするという流れで開発を行いました。社員は設計書やソースコード、テストケースを1行も手で書いていません。体制は社員3名で、開発経験の豊富な社員がメンターとして配置されました。 Zenn

アーキテクチャはNTTデータ標準のTerasolunaを採用し、AWS上で動作します。 Zenn生産性の数値は公開されていませんが、茂呂氏は「にわかに信じがたい生産性だった」と記しています。

どう設計・実装したのか

73個のプロンプトファイルで属人化を防ぐ

この実験の核心は、AIを「補助ツール」として個人が使うのではなく、チーム全体のワークフローとして組み込んだ点にあります。

要件定義の傍らに、GitHub Copilotが働きやすい「エージェント環境」を構築しました。.github以下に、ドキュメントフォーマット・プロンプトファイル（73個）・各種規約・プロジェクト構造定義・タスクフォーマットなどを格納。copilot-instructions.mdには150行以上の指示をまとめました。空行除きで9,000行、133ファイルに及ぶ環境です。 Zenn

直接プロンプトを入力して指示することを禁止し、アウトプットの品質が個人のプロンプト作成能力に依存して開発が属人化してしまうことを防ぐため、修正が必要な場合はプロンプトファイルを改修するか、問題記述票（レビュー指摘票）を作成してAIエージェントに修正させるかのいずれかのみ許可しました。 Zennこれにより、ノウハウがファイルに蓄積され、他チームへの移転も可能になります。

設計書の作り方を根本から変えた

処理フローを記述する従来型の詳細設計書は省略しました。AIエージェントに対しても「優秀なエンジニア」と同様に、INPUT/OUTPUTさえ提示すれば実装は自分で考えさせるという方針を採用しました。 Zenn

また、コンテキストウィンドウがすぐに埋まってしまうため、1ファイルをなるべく小さく作り、参照するファイルを最低限にしつつコンテキストに余裕がある状態を維持する設計にしました。 Zennこの制約を意識した設計がなければ、AIの出力品質は安定しません。

テスト工程で何が起きたか

この実験で最も示唆深いのは、テスト工程での失敗の経緯です。

茂呂氏の考えでは「人間が様々な観点でテストケースを考えて、AIエージェントにテストコードを生成させる」形が正しかったのですが、チームに意図が正確に伝わらず、「AIエージェントがテストケースを生成し、人間が打鍵する」という逆の形に切り替わっていました。結果的にテストケースが十分でなく、この段階で拾いきれないバグが相当数発生しました。 Zenn

現在は強化試験として人手による探索的テストを行い、新たな故障を発見するとともに、UTレベルのテストケースの追加も進めています。 Zenn

この失敗は、「AIに任せる範囲」の設計ミスが品質に直結するという点を具体的に示しています。テストケースの「観点」を定義するのは人間の仕事であり、AIはその観点に基づいてテストコードを実装する役割に徹させるべきだった、というのが教訓です。