設計書・コード・テストを全部AIに書かせて半年間開発してみたよ
1. はじめに
本記事は、私のチームが半年間AIネイティブ開発を行った経験とその感想をまとめたものです。
AIネイティブ開発とは、AI技術を活用してソフトウェア開発を行うことを指します。2025/10～2026/3の期間中、私たちはお客様に納品するシステムをAIネイティブで開発しました。その経験と私なりに感じたことをまとめてみました。
※ なお、私の取組は全社的な取組とは関係ありません。
※ あくまで、私のチームが独自に行っている取組ですので、その点はご留意ください。
2. 自己紹介
初めてテックブログに記事を書くので、簡単な自己紹介を。
- 名前：茂呂範（もろすすむ）
- 所属：株式会社NTTデータ 第三公共事業本部 デジタルソサエティ事業部 プロジェクト推進担当（参照）
- 立場：様々なシステムの基盤構築、基盤維持運用を担当している組織の責任者（参照）
- 肩書：エグゼクティブITアーキテクト
- 役職：部長
- 専門：大規模システムのアーキテクチャ設計、プロセス設計。新規開発よりマイグレーションの方が得意。
- 特技：問題プロジェクトの火消し。ブルドーザー役として燃え残った廃墟を更地にしてビルを立て直す仕事をしています。
- 趣味：お酒とプログラミング。もう３０年もコードを書き続けています。AIのおかげでコードを書くのがまた楽しくなりました。
3. 前提
3.1 案件概要
とある商用システムのサブシステムです。ゼロベースで構築するため、完全なスクラッチ開発となっています。
アーキテクチャは、弊社標準のTerasolunaアーキテクチャを採用し、Amazon Web Services（以下、AWS）上で動作します。また、利用する生成AIとして、GitHub Copilotを用いました。
この期間中、設計書、ソースコード、テストケース等、システム開発の成果物を全てGitHub Copilotで作成し、それを社員がレビューする流れで開発を行いました。そのため、社員は設計書やソースコード、テストケースを１行も手で書いていません。
3.2 体制
社員３名ですべての開発を行いました。
社員は、これまでお客様との仕様調整を中心に行っていたため、開発経験はそこまで高くありません。そこに、開発経験が豊富な社員をメンターとして配置して、様々な指導を行いながら、開発を行いました。
私は、見守り役＆お目付け役＆責任者です。
失敗したら、とドキドキしながら日々を過ごす役回りです。
3.3 開発規模
生産性がバレちゃうので秘密です。
そこまで大きくはないです。NTTデータとしてみると、小規模に分類される規模です。
3.4 生産性
秘密。
ですが、にわかに信じがたい生産性でした。
4. 工程別の雑記
4.1 要件定義
モックベースで要件定義を行いました。モックは、ChatGPTを使い、２時間ほどで最初の数画面を作り、概ね期待通りのものが出来たら、GitHub Copilotに切り替えて、どんどん画面を増やしていった感じです。その後、HTMLモックから要件定義書を生成しました。
工夫した点としては、実際に動くモックとすることや、一つのHTMLファイルに全ての画面を入れることで、そのままお客様に送付すれば、お客様の方で挙動の確認ができるようにしました。
最初のころは、お客様との打ち合わせ時にモックを使いながらコメントをもらいつつ、その場で修正することもあれば、後日修正版を提示したり、という形で要件定義を行いました。後半のころは、モックも安定してきたので、お客様のほうで、空いた時間にモックを触っていただき、コメントを一括でもらって要件定義を行いました。
モックを修正したら、その修正に合わせて要件定義書も修正する、そんな感じで仕事をしていました。この辺りは、ずっとバイブコーディングです。
もちろん、モックだけだと、バッチ系の要件や非機能要件が落ちてしまうので、その辺は、プロンプト指示で補完する形で要件定義を行っています。
4.2 エージェント環境の構築
要件定義の傍ら、GitHub Copilotが働きやすいように、エージェント環境の構築も行いました。と言っても、.githubの中身を整備していた感じです。
- .github
+ doc_format : ドキュメントのフォーマットを格納
+ prompts : 各種プロンプトファイルを格納 （７３個も作ったよ！！）
+ rules : 各種規約、開発ルール類を格納
+ skills : 本来はAgent skillsを格納する予定でしたが、現状はプロンプトファイル主体なのでまだ使ってません。
+ structures : プロジェクトディレクトリの構造定義とドキュメント体系などを格納
+ task-format : エージェント向けのタスク定義のフォーマットを格納
- copilot-instructions.md : GitHub Copilotへの指示をまとめたファイル（150行ほど。いっぱい工夫が入ってるから中身は秘密。）
これ以外にも、今回の開発向けの設計書体系、ほぼ１から作り上げました。
重要なことは、AIエージェントが必要なドキュメントを簡単に見つけられるようにすること、作成する成果物の整合性を取りやすいようにすること、AIエージェントが外部サービスを使わなくても容易に情報にアクセスできるようにすること、などを意識して、設計・試験ドキュメントの体系や、管理ドキュメントの体系を作りました。
そのドキュメント体系を前提に、アクティビティ定義を行って、７３個のプロンプトファイルや、各種規約類、開発ルール類の補足ファイルなども作りこんでいった感じです。
いま計測してみたら、.github内だけで空行除き9,000行ぐらい書かれてました。
ファイルは133個ありました。
すぐにコンテキストウィンドウが埋まってしまうので、１ファイルをなるべく小さく、小さく、小さく作って、参照するファイルを最低限にしつつ、コンテキストに余裕がある状態を維持するようにした感じです。
また、色々と工夫すると、マルチエージェントでの開発や、エージェントに長時間作業させることなどもできるのですが、エージェントの一つ一つの挙動を把握し、成果物の品質を上げるためのプロンプトのブラッシュアップが非常に重要なので、面倒だけど、細かく細かく区切っています。
今でも、毎日ブラッシュアップしている感じです。
4.3 設計
要件定義を終え、エージェント環境のドラフト版が出来上がったら、設計に入ります。やることは、ひたすらに、GitHub Copilotとのチャット欄に、コマンドを叩いていく感じです。
ここからは、バイブスは禁止にし、全てコマンドを叩いて、設計書やソースコードを生成していく形で開発を行いました。
直接プロンプトを入力してエージェントに仕事をさせることもできますが、それは禁止にしました。理由は、アウトプットの品質が個々人のプロンプトの作成能力に依存してしまい、開発が属人化してしまうからです。修正が必要なときは、プロンプトファイルを修正して再度色々とやり直すか、問題記述票（レビュー指摘票）を作成してAIエージェントに修正させるか、のいずれかのみ許可しました。
そうすれば、様々なノウハウが、プロンプトファイルもしくはレビュー指摘票に蓄積されていくので、開発が属人化せず、チーム全体でノウハウを蓄積し共有することができ、更に開発完了後にそのノウハウを他チームにそのまま移転可能になるからです。
ここは徹底しました。
あと一つこだわりポイントがあるとしたら、良くある処理フローを記述する詳細設計書は省きました。
私は、優秀なエンジニアには処理ロジックを提示しなくても、INPUT/OUTPUTさえ提示すれば、あとは自分で考えて実装できると思っています。AIエージェントにも同様のことを期待し、設計書の１行がソースコードの１行に対応するような、従来型の設計書とは異なるアプローチを採用しました。
4.4 製造（プログラミング）
設計と全く同じで、コマンドを叩いて、ソースコードを生成していく形で開発を行いました。
ポイントは、設計書体系とソフトウェアのアーキテクチャを対応させられるように設計書体系を作りこんだので、AIエージェントが特定のクラスを作るときに、特定の設計書を見ながら必要な情報を簡単に取得できるようにしたことぐらいです。
こう書くと、まるで１クラス１設計書のように見えてしまいますが、そんな残念な設計書体系にはなっていません。弊社の標準ドキュメント体系を踏襲しつつ、AIエージェントが必要な情報を簡単に取得できるように、工夫して作りこんだ感じです。なので、弊社社員であれば、すごく手になじむ感じになっています。
4.5 単体テスト
デトロイト派（古典派）を採用したぐらいで、他は製造と全く同じです。コマンドを叩いて、テストケースやテストコード（JUnitコード）を生成していく形で開発を行いました。
ただ、ここは悲しみが入っています。
テスト観点が不足しており、テストコードも不十分なものが多かったです。結果的には、すり抜けバグが相当数発生し、総合試験が大変でした。
テスト観点が不足していた理由は、観点表が十分ではなかったことです。既存の観点表を流用してしまった結果、それまで設計書体系によって無意識のうちにカバーされていた観点が、今回の設計書体系の変更によって完全に抜け落ちてしまったことが大きいと思います。
結果的に、設計書体系に合わせたテスト観点まで観点表を仕上げることができなかったことが、テスト観点の不足につながったと思います。
ここは現在改善中です。
4.6 結合テスト
ここも、これまでと同様です。コマンドを叩いて、テストケースやテストコード（Playwrightスクリプト）を生成し、それを実行していく形で結合テストを行いました。
ここにも悲しみが入っています。
上述の通り、単体レベルのバグが大量に出たことは当然として、今回のシステムはJavaScriptでDOMを大量に操作してダイナミックに画面が変わるタイプのシステムだったのですが、出力されているテストケースが、目的に向かって一直線に操作するものが多く、実際のユーザの操作を模したものが少なかったため、同じ操作を２回繰り返すなど、ちょっと変わった操作をしたときのDOM操作の不具合が大量に次工程（総合試験）に持ち越されることになってしまいました。
また、フレームワークを社内標準で選んでしまったため、JavaScriptでDOM操作するとき、フレームワーク類を使わずに素のJavaScriptでガリガリと書いてしまったのもまたテストしづらさを生んでしまったというところもあると思います。
いつもの業務システムのように扱ってしまったのが、敗因です。
さらに、私がフロントエンドにすごく弱いというのが顕著に表れてしまったなと思います。（だって、デスクトップアプリの開発で育ってると今のフロントエンドってなんか好きになれないんだよね。。。）
ここも現在改善中です。
4.7 総合テスト（人間受入れ試験）
ここも失敗しました。
私の考えでは、人間が様々な観点でテストケースを考えて、AIエージェントにテストコードを生成させる形でやるべきだったのですが、チームに正しく意図が伝わっておらず、AIエージェントがテストケースを生成し、人間が打鍵するというテストに切り替わっていました。
（ちゃんと指示出来てなくてごめんね＞AIネイティブ開発チームメンバー）
結果的に、テストケースが十分でなく、この段階で拾いきれないバグがそれなりに生まれていました。
現在、強化試験として、人手で探索的テストを行い新たな故障を発見することと、UTレベルのテストケースの追加を行っています。
4.8 現在の状況
めっちゃ強化試験してます。
最終的な品質分析の結果については、気が向いたら（＆会社の許可が下りれば）、この場を借りて共有できればと思います。
4.9 工程別の雑記まとめ
設計／製造まではそこそこうまくできたかなと思っていたのですが、テストに関しては完全に自動化できたとはいえ、ケース抽出が十分ではありませんでした。ガードレール等の問題というより、テストケースの抽出が圧倒的に不足していたので、しっかりと分析して、より良いプロセスへと改善していこうと思っています。
5. プロジェクト管理に関する雑記
5.1 計画策定
手を抜きました。
進捗管理のところにも記載しますが、想定成果物一覧を作って、ひたすらTODO管理です。それが計画になってます。
（まあ３名のチームなので、３名がやりやすい方法で自分たちで自分たちを管理して、ぐらい。）
5.2 進捗管理
凄くライトにやりました。
ほとんど、成果物ベースのTODO管理＋バーンダウンチャートで管理しています。
正直、マネジメント対象のメンバが３名しかいないのと、私の本業は複数の基盤構築・基盤維持チームの管理なので、オーバーヘッドが少ない進捗管理の方法に留めました。
5.3 バグ管理
ここはしっかりやったつもりでしたが、後になって失敗したと思っています。
バグ票をマークダウンで書いてしまったところです。
もちろん、バグ票自体は、AIエージェントが作成しているのですが、マークダウンで書いてしまったことで、定量評価するときに機械的に読み込むことができず、人間が一生懸命Excelを作り直すという悲しいことになってしまいました。
一度、マークダウンからJSON形式に変換するなどの工夫も入れたのですが、結局、そのJSONが妥当かどうかの確認が必要になることや、バグ票のフォーマットも途中途中で改善が入ってしまい、フォーマットが安定していなかったため、Excelで力業で集計してしまった感じです。
ここは、ちゃんと運用を見据えた構造を作りこむべきでした。これまで何も考えずにバグ管理システムをそのまま使っていたので、流れでそのままマークダウンにしてしまったことを後悔しています。
もっとリアルタイムに品質状況を確認したい！！と強くメンバに言っておけば良かった、という感じです。
6. GitHub Copilotに関する雑記
6.1 プレミアムリクエストの回数
普通のエンタープライズのライセンスで購入していますが、月のプレミアムリクエスト1,000回が、結構ギリギリという話を聞いていました。なので、利用回数を意識しながら、作業によってモデルを使い分けているように見えました。
6.2 他のツール（Claude Codeなど）との併用
今回、GitHub Copilot以外のツールは、ほとんど使いませんでした。
理由としては、ツールも重要ですが、それ以上に、AIエージェントがどう振舞うか、それに合わせて環境をどう整備するかを試行錯誤しながら悩みぬくことが重要だと思ったからです。そのため、今回の開発では、GitHub Copilotを徹底的に使いこなすことを目指し、他のツールはあまり使わないことにしました。
次の開発では、Codex や Claude Code なども併用してみたいと思っています。
6.3 利用モデル
ほとんど、Claude Sonnet系列（4.5がメインかな？）を使っていたように思います。ただ、時々、すごく変な動きをするときがあって、そういう日は、他のモデルに切り替えていました。
なんとなくですが、
- GPT系列：テストに向いてそう
- Claude系列：設計やコード生成に向いてそう
- Gemini系列：レビューに向いてそう
という感触はあるのですが、ちゃんとした比較はできていません。
6.4 .githubの中身
※ ここは社内向けのコメントです。
上の方でも書いたけど、結構頑張って作ったと思う。
社内の情報共有サイトで利用ガイドラインとともに公開していますので、社内の方であれば、誰でもダウンロード出来ます。なお、情報区分をしっかり守った利用をお願いします。
あと、使ったら、フィードバックください。
7. その他、最近のAIネイティブ開発の動向に関する感想
7.1 仕様駆動開発
今回、仕様駆動開発で開発するかどうか、結構悩みました。
個人開発では、バイブコーディングでコードを書くこともあれば、kiro等に代表される仕様駆動開発も使うし、色々と遊んでいるのですが、一般的な仕様駆動開発でスケールさせる（１００万行の開発を行う）イメージを私自身が持てなかったため、今回は、よりドキュメントを重視するドキュメント駆動開発のような形で開発を行いました。
仕様書をもとに、必要なドキュメントを段階的詳細化で整備していき、そのドキュメントに基づいてソースコードを作成するという、伝統的なV字モデルを高速に回すようなイメージです。
この方法だと、当社の文化に合っているし、普段から慣れているマネジメントなので、私のチーム以外でも導入しやすいだろうと思い、あまり派手な手法は採用しませんでした。
7.2 AIエージェントの並列化
行っていません。
上述の通り、社員がAIネイティブ開発に慣れる必要があると考え、あえて、AIエージェントは１人１台で、並列化は行わないことにしました。
その代わり、AIエージェントの動きをじっくりと観察して、AIエージェントがどのように仕事をしているのかを理解し、社員自らが、プロンプトファイルやドキュメント体系の改善を行えるようになってもらうことに重点を置きました。
7.3 労働時間
総労働時間については、各社員が昨年度より100時間減少しているので、減っていると言えます。
※ ここは管理職としてしっかりと書いておきたい。
ただ、社員の前の仕事が全く異なるため比較できないので、正直、良く分かりませんというのが本音です。
7.4 テストファースト
やればよかった。。。
せっかく、動作するモックを作ったのだから、画面操作のテストは最初に作っておけばよかったなと思います。
ここは、ガードレールを最初に用意することが重要と私自身も頭ではわかっていましたが、終わりが近づいてきてしまったので、試験で品質保証と、どこかでいつものやり方に頭の中が切り替わってしまいました。
ここは、次に向けた改善点ですね。
7.5 レビュー疲れ
プロンプトファイルを見ていると、ある時から、AIエージェントによるセルフレビュー用のプロンプトが急激に増え始めてました。きっと、巷でよく言われているレビュー疲れを起こして、嫌になったんだろうなあと思います。
AIエージェントによるセルフレビューがどこまで効果的だったかは、まだ分析していませんが、レビュー結果は残っているので、どこかで分析してみたいと思います。
とはいえ、ここは、ハーネスエンジニアリングにも通ずるものがありますが、AIエージェントの働かせ方のクオリティが上がってくれば、レビュー負荷は軽減されていくと信じています。
7.6 ハーネスエンジニアリング
OpenAIのハーネスエンジニアリングの記事が出たとき、鳥肌が立ちました。
違いはあれど、同じような考え方で、本家がチャレンジしているというのを見て、さらにそこで得られた知見が、僕らの方針とかなり似ていたところに、本当に鳥肌が立ち、今でも心臓がバクバクです。
7.7 若手層の育成
昨今のAIのトレンドを見ていると、若手層の育成に関してネガティブな話題が多いように思います。
今回の開発では、あえて若手層を中心に開発を行ってもらい、シニア層はメンター役に徹してもらう形で開発を行いました。これは、若手層を育てないと、組織としての持続性がなくなってしまうからです。
そして、今後どのような未来になるかは分からないけど、AIエージェントが集団で開発する未来が来ることは自明なので、
- AIの成果物を評価する能力（ここは後ろで言及します）
- AIエージェントの行動をマネジメントする能力（PJマネジメントという観点では人のマネジメントもAIエージェントのマネジメントも本質的には同じかなと）
- 完璧を求めずにそこそこでちゃんと終わらせる能力（AIエージェントが働き過ぎてしまうからもっと作りたくなる欲求を押さえる）
を身に着けておくのが良いだろうと思っています。
特にAIエージェントが高速に動作するからこそ、
INPUT -> (プロンプト) -> OUTPUT
というサイクルを高速に回すことで、OUTPUTが期待通りになってないとき、INPUTやプロンプトが良くないからOUTPUTが良くないんだ、というのが分かるようになり、じゃあ、INPUTをこう変えてみよう、プロンプトをこう変えてみよう、といった改善を高速に行えるようになります。
これを何度も繰り返すことで、社員が自身の目を今まで以上のスピードで肥やしていくことができるようになります。なので、私はAIネイティブ開発こそ、最高の若手育成の教材だと考えています。
8. 全体の感想まとめ
立ち上げたばかりの若いチームで、初めてのAIネイティブ開発、初めて自分たちで開発プロセスを定義し、ドキュメント体系を整備し、プロンプトファイルを作りこみながら、試行錯誤しながら開発を行ってきました。
各成果物を見ると、まだまだ改善の余地があるものも多いですが、全体としては、AIエージェントを活用して、これまでの開発スタイルとは全く異なる形で開発を行うことができ、生産性の向上を実現できたと思います。
また、生産性の向上だけではなく、社員自身が自分たちで開発できるという自信が、お客様との仕様調整の場面においても良い方向に繋がり、普通の開発のときにはすごく疲れた顔で帰宅していたメンバが、すごく楽しそうに開発している姿に、私としてもこの取り組みを始めて良かったと感じています。
この記事が掲載される頃には、強化試験も終え、品質分析も終えて、さらなる知見を得られていると思いますが、まずは速報ベースで、半年間のAIネイティブ開発を行った感想をまとめてみました。
この熱が冷めないうちに、次のステージにチャレンジしてみたいと思います。
9. 今後
OpenAIのハーネスエンジニアリングに負けないよう、僕らも１００万行のAIネイティブ・システム開発を目指すぜ。
X. その他
弊社経営幹部のみなさま、このテックブログ記事を読んでください。
これが、年末に突然出た日経の記事に対して、現場の最前線で試行錯誤を重ねながら２０年にわたりシステム開発に取り組んできた私なりの答えだ！
日本経済新聞：生成AIがシステム丸ごと開発 NTTデータ、IT人材不足に抜本策（2025/12/31）
以上、開発現場からの報告でした。
※ なお、私の取組は全社的な取組とは関係ありません。
※ あくまで、私のチームが独自に行っている取組ですので、その点はご留意ください。
NTT DATA公式アカウントです。 技術を愛するNTT DATAの技術者が、気軽に楽しく発信していきます。 当社のサービスなどについてのお問い合わせは、 お問い合わせフォーム nttdata.com/jp/ja/contact-us/ へお願いします。