3-11.開発の常識を変える「AI駆動開発(AIDD)」を契約に盛り込んだ理由
※以前「番外編」として先出しした内容に、設計シリーズの文脈と詳細を加えた完全版です。先に番外編を読んだ方は、本記事で背景まで通してご覧ください。
このシリーズの核心の一つを、ようやく書ける。私たちは、次期基幹システムの開発契約にAI駆動開発(AIDD:AI-Driven Development)の採用を明記した。生成AIを開発の正式な道具として使うことを、発注者側から契約に盛り込んだのだ。第11回は、なぜそうしたのか、そして何を期待しているのかを書く。先に結論を言えば、狙いは費用の圧縮ではない。品質の向上だ。
そしてこの回こそ、本シリーズの通奏低音がもっとも素直に響く場所だ。AIで「作る」——コードを書くという行為そのものは、コモディティになる。 これは脅威ではなく前提だ。コードが安く速く誰にでも書ける時代になればなるほど、価値の重心は「書く」から、その手前と後ろ——何を作るか(設計)と作ったものをどう検証するか(品質)——へ移る。AIDDとは、その重心移動を正面から受け入れる作り方だ。
Before:人間だけの開発が抱える構造的な限界
従来のシステム開発の品質は、突き詰めれば「担当エンジニアの力量と、レビューにかけられる時間」で決まっていた。優秀なエンジニアでも、人間である以上、見落としはある。コードレビューは効果的だが、レビュアーの時間は有限で、納期が迫れば真っ先に削られる。単体テストは品質の生命線だが、テストコードを書く工数は「動くものを作る」工数と常に綱引きになり、カバレッジ(テストがコードをどれだけ網羅しているか)は理想を下回りがちだ。つまり、品質を上げる活動はどれも正しいと分かっているのに、時間という制約がそれを許さない。これが人間だけの開発の構造的な限界だった。
なぜ「契約に明記」したのか
AIDDを契約に盛り込んだ理由は、AIの活用をベンダー任せの偶然にしないためだ。何も言わなければ、AIを使うかどうかは現場のエンジニア個人の裁量になる。使う人は使い、使わない人は使わない。それではAIがもたらす品質向上はプロジェクト全体の標準にならない。逆に、発注者が「AIDDを採用すること」を契約レベルで求めれば、ベンダーは組織としてAI活用の体制・ルール・ツールを整えることになる。前シリーズで書いた「品質保証プロセスを見積もりの前提条件にする」のと同じ構図だ。後からお願いするのではなく、最初から前提にする。 ここには、私自身がAIを業務で使い込んできた実感もある。EC運用の分析でAIプロンプトを型化し、思考の速度が変わる体験をした。あの変化が開発の世界で起きないはずがない——その確信が、契約明記という一歩を後押しした。
AIDDの中身その1:コード生成と自動コードレビュー
具体的に何をするのか。一つ目は生成AIを用いたコード生成だ。エンジニアが仕様を示せば、AIがコードの叩き台を生成する。定型的な処理、データアクセス層、画面の骨格——人間がゼロから書いていた部分の多くをAIが下書きする。エンジニアの仕事は「全部を手で書く」ことから「設計を示し、生成物を検証し、磨く」ことへ移る。ここに重心移動がはっきり表れている。コードを書くという手段はAIに譲り、人間は「何を作るべきか」という本質に集中する。 二つ目が自動コードレビューだ。人間のレビューに加えて、AIがコードを常時レビューする。バグの兆候、セキュリティ上の危険なパターン、コーディング規約からの逸脱。人間のレビュアーの時間が有限でも、AIのレビューは疲れず、漏れず、全コードに目を通す。人間は、AIが拾えない設計判断や業務の妥当性に集中できる。
AIDDの中身その2:単体テストの自動生成とカバレッジ向上
私が最も期待しているのが単体テストの自動生成だ。前述のとおり、テストコードは「正しいと分かっているのに工数の都合で削られる」筆頭だった。AIがテストコードを生成すれば、この綱引きの構図が変わる。網羅的なテストケースを揃えるコストが激減し、カバレッジを高い水準で維持できる。なぜカバレッジにこだわるのか。このシステムは、作って終わりではないからだ。 第4回で書いたとおり、BOMやかんばんといった次期フェーズの拡張が控えている。機能を追加・変更するたびに既存機能が壊れていないかを確かめる必要がある。テストが充実していれば、変更のたびに全テストを自動で流し、壊れた箇所を即座に検知できる。つまりテストの充実は、いま品質を上げるためであると同時に、将来の拡張に耐えうる堅牢さへの投資だ。AIDDは、その投資のコストを劇的に下げる。
AIと人間の分担こそが本質である
誤解されたくないので繰り返す。AIDDの目的は、開発費を値切ることではない。同じ時間とコストで、これまで届かなかった品質——全コードへのレビュー、高いテストカバレッジ、一貫した規約遵守——に届くようにすること。AIは品質の天井を上げる道具であり、その天井の高さを発注者として契約で求めた。
ここで強調したいのは、AIと人間の役割分担の設計こそがAIDDの成否を分ける、ということだ。AIを過小評価して「結局は人が全部書くべき」と退けるのも、過大評価して「AIに任せれば全部できる」と丸投げするのも、どちらも間違っている。冷静に線を引く。「どう作るか」はAIに大きく委ねられる。だが「何を作るか」——どんなデータ構造にするか、どの業務をどう構造化するか、何を品質の基準とするか——は、自社にしか決められない。 だからこそ、生成AIが書いたコードを無検証で信じることはしない。生成物の検証責任は人間のエンジニアにあり、その規律も含めてベンダーと合意している。AIが安く速く「作る」ほど、人間が握るべき「本質の見極め」の価値は、むしろ上がっていく。
なお、2026年の今となってはAIDDは急速に当たり前になりつつある。だが当時、発注者側から契約に明記した例はまだ少なかったはずだ。早く動いた分の学びを、こうして残しておく。手段が「できて当たり前」に横並びになる流れは、もう止まらない。だとすれば、焦って手段を追うのではなく、自社が本質をどこに定めるかへ、早く意識を移したほうがいい。
次回はシリーズ最終回。AIDDによる静的解析と外部セキュリティ診断を組み合わせた「二段構え」のセキュリティ戦略を書く。
評決ではなく、レンズを。
「どう作るか」はAIに大きく委ねられても、「何を作るか・何を品質の基準とするか」は自社にしか決められません。AIで作るがコモディティになるほど、この分担を冷静に見極める力が、AIDDの成否を分けます。
AIで「作る」はコモディティになります。手段が横並びになるほど、散らばった知識の“点と点”をつなぎ、自社の本質——何を、どの基準で選び、どう活かすか——を見極める力が問われます。私はアトムビットとして、その見極めを特定ベンダーに肩入れしないフラットな評価軸でお渡しします。売るのは「どれが一番か」という評決ではなく、「あなたの制約でどう選ぶか」というレンズです。最終選定と結果責任は発注者にあります。
選定とAIDDレディネスの要点を1枚にした無料の「評価軸チェックシート」を配布中です。
▶ 無料で受け取る:https://atomb.it/lens?utm_source=note&utm_medium=article&utm_campaign=s3
