春の入門祭り2026の5本目です。
開発へのAIの活用はまったなしというこで、仕事やら趣味でいろいろ開発しています。せっかくなので、従来の手法をアンラーニングAIをより生かした開発スタイルでやろいうことで、現時点で作法としてまとまっているAI-DLCとSDDなどに入門して試しつつ、普段の業務への適応方法を考えたり、最近してきたことの言語化をしてみます。
開発におけるAI活用はみんな今関心を持っていることかと思います。設計書を作ればコードは自動でできる、というのはよく言われますが、IPAの資料を見るとウォーターフォールだと実装の工数の割合の中央値は23%-32%ぐらい（新規なのか改良なのかで変わる）となっています。仮にここが3倍になっても得られるゲインは全体の7-10%ぐらい。AIで効率アップをしたい！という目標値はだいたいこんなものではないと思うので、そういう観点で見ています。
スペック駆動開発（SDD）
以前、スペック駆動開発(SDD)はFindyさんのイベントで発表させてもらったことがありました。Kiroが提唱した手法です。まずは対話しながらスペックと呼ばれるドキュメント群を作っていきます。Kiroではrequirements.md, design.md, tasks.mdです。その後、タスクに書かれているサブタスクごとに新しいセッションをオープンしながらタスクを進めていきます。
スペック駆動が画期的だった点はドキュメントを作る点ではなくサブタスクごとに新しいセッションを作ってコンテキストあふれが起きにくいようにする、そのために必要な、現在出てきているメモリー機能のようなものを自然に実現できるワークフローになっている点かなと思います。実際、当時のSonnet-3.5とかでもそうですし、コーディング能力が高くないモデルでもそこそこ動いてくれる点です。
ClaudeもCodexもCopilotも、現在はSDDをプランモードという形で取り込んでいます。ぽちっとプランモードを有効にすると、まずはソースコードの修正を封じて、plan.mdなどのドキュメントを作り、そのレビュー後に実装を進めます。今どきのモデルは以前よりは高性能ですし、コンテキスト圧縮でも性能は落ちにくくなっていると感じるのでこれでも十分動いてくれるのでしょう。Claude系モデルはドキュメントといいつつコードスニペットまみれのdesign.mdを書いていたので、ファイルを分ける意味もあまりなかったですし。
スペックの単位
なお、「スペック（仕様）駆動開発」という言葉があまりにも一般名詞の組み合わせすぎるせいか、「それ今までの開発と何が違うのか」みたいな言い方も登場時はされていました。また、仕様という言葉を見て、今までの仕様書相当のものを詰め込むみたいな解説も見られました。
実際にはAIが扱えるコンテキストサイズには限界があるので、システム一本分の要求を入れるということは現実的ではないです。システム開発を行う場合は機能分解をすると思いますが、そういう単位、あるいは大きなリファクタリング見たい感じごとにスペックを作って進めていくのがやりやすいですね。ウェブアプリだと画面ごと（バックエンド込み）とかで進めていくとか。
何を作るかの全体構想やタスクやモジュールに分割して外部仕様の一番外側ぐらいは人間がやりつつ、詳細設計や実装はAIがメインで進めていく、という感じかと思います。
テストを書かせる指示を入れるか？
これも定期的に話題になる気がしますが、今どきのモデルは何も指示しなくてもテストを書いてくれるし、コードを書いたあとに実行して壊れたところの修正もしてくれます。品質維持という点では最低限やってくれます。フロントエンドは何も言わなくてもTypeScriptになるし、型ののチェックも自動です。
テストをレビューするかどうかですが、自動で書かれたテストをレビューする価値はないかなと思います。人間が意思をこめたrequirementsに対してそれが実装されているかどうかは確認すべきですが、AIが勝手に決めた内部実装をレビューする価値はありません。
コーディング規約的なのもある程度の水準で最初から書いてくれます。とはいえ、ちょっとスタイルが古かったりするので、そこは意思入れしてもよいかなとは思います。ただ自然言語でLLMにやらせるとチェックと修正とかなりクレジットを消費するので静的チェックLinterのルールを作ってそれの実行とかがいいですね。
AI-DLC
AI-DLCはAmazonが提唱している、AI中心の開発ライフサイクルにしていくために提案しているあたらしいライフサイクルです。KiroもそうですがこちらもAmazonです。
アジャイルの1-2週間のイテレーションをさらにエクストリームにして1日1回、もしくは数回のボルトというイテレーションを導入します。そして、その中で、インセプションフェーズ（設計）、構築フェーズ（実装）、オペレーションフェーズ（デプロイ）という3つのフェーズを繰り返していきます。
ライフサイクルのすべてをAIが制御し、必要なことはAIが人間に尋ね、AIがどんどんやっていきますよ、とう方針です。なんだかすごそうです。既存のAIコーディングエージェントでAI-DLCを実現するためのハーネスがGitHubで提供で提供されています。個人的に普段使っているCodexは対象にはなかったので、GitHub Copilotに入れてやってみました。
レビューが重い
必要なことは全部AIが聞いてくるので、質問に答えていくだけで適切なエンジニアリングが行われてシステムが出てくる、みたいな感じとのことですが、やってみると、結構細かいところまでガシガシ聞かれて、それにこたえる必要がありました。AIが判断を下すために情報が必要とはいえ、考えるのを後回しにしたいな、というところまで細かく聞かれます。趣味開発なのにすごい仕事している気分というか、そんな気持ちになりました。あと、質問内容はかなりシステム観点での理解が求められるような質問が多い。
AIに大量のものを作らせるのは楽しいと感じるかもしれないが、AIが作った大量のコンテンツを消費させられるのはなんというか消耗が大きいし疲れるな、と。
ちょっと大きな開発に入れるにはアレンジが必要
元Amazonの人から教えてもらったのは、GitHubで提供しているワークフローはあくまでもAI-DLCの体験用プロンプトとのこと。公式READMEにもオペレーションフェーズは将来対応、と書かれています。論文に書かれているフローをきちんとやるには組織に合わせたアレンジだとかが必要とか。
今回、基本機能をまず作ってから追加の機能、みたいに一人で複数ボルトを体験してみようと思いフェーズを分けたのですが、どうもワークフローが複数イテレーションに対応していないのか、途中で前のフェーズの作業のタスクと混雑し始めて、途中で「ここの部分のドキュメントは前のイテレーションだから分けて（ボルトという言葉は通じなかった）」と整理させたりしました。提供されたまま使うのは1ボルト分のあまり大きくないプロダクトには良いがそれなりに工夫が必要かと思います。実際にはきちんとプロジェクト運営をしたことがあって、AIエージェントもわかって、ハーネスエンジニアリングできて、AI-DLCをアレンジできる人が必要そうです。
トークン消費が激しい
ちょっとした機能の修正もすべてドキュメントを整備してから動こうとします。そしてスペック駆動以上に大量に生成されるドキュメントをすべて読み込んで整合性を取ろうとします。たぶん、同じような機能を単純なスペック駆動で開発するのと比べると5倍ぐらいCopilotのプレミアムクレジットを消費しているように思います。
Markdownはちょっとした内容のやり取りにはいいかもしれませんが、大量の文章を横断的に確認して矛盾を検知するみたいなコンパイル言語における型チェックのような仕組みはなく、大量のクレジットを消費して無理くりやっている感じです。形式仕様記述言語も人間が読み書きで判断は難しいのですが、ヒューリスティックではない何かしらの静的解析ができるドキュメント記述フォーマットが生まれない限り、このまま大きくスケールさせるのはちょっと難しい気がします。
今後やるべき実験
普段からCodexが好きなのでCopilotでもCodexを選んでやっていました。エージェントを組み合わせて使う人もCodexはレビューに使って整合性をきちんと取らせるのによい、と言われるので、それだけインセプションフェーズの質問もヘビーよりだったのかもしれません。もっとイケイケでコードをガンガン書くというClaude系モデルにやらせるとまた印象は変わるのではないかと思います。
現時点での使い方
どちらもAIを活用したコーディング自動化の効果は得られます。どちらもAmazonがベースを作ったものですし、どちらも、動くシステムを日々作りながら育てていくという共通点があります。大きく違う点は、要件の整理やタスクの分解までAIにやらせるかどうかです。
現時点のモデルの能力などを考えると、AI-DLCをそのまま実現するにはまだ何段階か技術の進展が必要かも、とは思いますが、大きく活用方法を分けるとイメージとしては以下の2つかなぁと思います。
- アジャイルにタスク整理などを行って実装部分はSDD
- AI-DLCで高速ウォーターフォール
AI-DLCはドキュメントも多く、実装を後回しにしたい部分も要件を固めるためにAIにきちんと情報をインプットしていく必要があります。また、足りない情報はかなり突っ込んで聞いてきます。日次とかで回していくという考え方であってもかなりフロントヘビーな頭の使い方をします。そして、計画変更もそれなりに重くなります。今回のテストでは雑にバイブコーディングで作らせたプロトタイプがあったのでそれを読み込ませてみましたが、既存のコードの分析から要件を固める部分はなかなかよくできているな、と思いました。しかしそれは既存システムがあって、なおかつ大きく仕事の流れが変わらない前提ではうまくいく、ということでそうではない場合はかなり工夫が必要なんじゃないかと思います。ただ、ある程度やることが決まっているなら、頑張って質問に答え続ければ形になっていくので、これはこれで面白い体験でした。
SDDは逆に、現時点できちんとアーキテクチャを考えられて設計できる人からするとかなり気軽です。自分である程度モジュールや機能に分割し、必要な順番で実装していけばいいですし、そのタスクの遂行にだけ必要な情報をインプットすれば良いです。軽めに走らせて動くものができて、それをユーザーと確認して作っていくという流れとはかなりマッチしています。ただし、全体像を全部は作らないし、やってみて方針転換とかがしやすいという点では全体のスケジュール管理やプロジェクト推進はアジャイルに乗せるといいのかなと思っています。
今回のエントリーの出発点はウォーターフォール的なプロジェクトの進め方ではメリットがあまり出ないぞ、という感じで話を進めてきましたが、そもそもアメリカのウォーターフォールの採用割合がかなり少ないということもあり、アメリカ企業から出てくる開発支援のツールの思想がウォーターフォールに考慮していないで作られている点は想像に難くないです。ウォーターフォールかつAI活用だと要件定義とか前段のドキュメント類をいかに早く作るか、が勝負になってくるという点で、AI-DLCの一部適用を模索する必要はあるかと思います。ただ、AIによる開発はうまく歯車が噛み合えば爆速でいける一方、AIと人間のコミュニケーションがボトルネックで工数が読みにくいという扱いがされているのが現状かと思います。機能の境界をしっかり決め、予算も決め、スケジュールをしっかり決めて進みたいというウォータフォールのニーズが減ることはないと思いますが、実装フェーズ周りはアジャイルにしていかないとバッファーを取り過ぎてしまうのではないかという気がします。
まとめ
2つの手法は同じ会社から出てきたということもあり、だいぶ手触りは違いますが似ているものも多いと感じました。どちらもAIの活用度を大きく上げる方針であることは間違いありません。
SDDはお客さんへの技術支援案件ではすでに取り組んだことがあります。要件定義やシステムのユースケースの整理、DFDやERDの分析や設計をある程度形が整うまで伴走し、AI駆動開発の紹介や手ほどきを行ったり、SDDを実現するためのskillsを提供し、実際の実装はお客さんのIT部門の人がSDD（用のハーネスを設定したCopilot）で開発を進めていくという流れでやりましたが、思った以上にうまくいっています。今までのDXは、事業会社のIT人材不足というボトルネックがありましたが、このような伴走型の技術コンサルティングはそこの突破にはかなり追い風になりそうです。
どちらにしても、一筆書きできるような小さいシステムはともかく、大きなシステム、特に様々なシステム間の連携が必要となるような基幹システムだと、まだまだITのスキルが不要にはならなそうだなぁ、と思いました。