AIを使った開発の鍵は「ドキュメント駆動」とボトムアップでの理解
仕様駆動開発（Spec-Driven Development：SDD）の広がりは、私たちが提唱するドキュメント駆動開発と重なります。しかし仕様書だけでは開発は回りません。AI時代の鍵となる、ドキュメント駆動とボトムアップの理解について整理します。
仕様書が一次成果物になる ― 仕様駆動開発というAI時代のアプローチ
GitHub Spec KitやAWS Kiro、Claude Codeなど主要な開発ツールは軒並み仕様駆動開発に対応し始めました。仕様書を一次成果物とし、コードはそこから生成されるビルド出力として扱う考え方です。
これは私たちが提唱するドキュメント駆動開発と、方向性がほぼ一致します。ただし私たちは対象を仕様書だけに絞らず、業務プロセスや作業ログまで含めて「ドキュメント」と広く捉えています。
理由は単純です。AIが高速かつ永続的に開発を続けるには、仕様だけでなく判断の経緯まで参照できる必要があります。仕様書は、ドキュメントという土台の一部に過ぎません。
仕様書だけでは回らない現実
仕様駆動開発やドキュメント駆動は「仕様書が一次成果物」という発想の転換ですが、仕様書だけを見ていれば済む状況は、現実にはまだ多くありません。ビジネスとして継続的にシステムを維持していく限り、次のような課題に人間が向き合い続ける必要があります。
- 人間側の認証・権限管理、シークレット情報の管理
- AIが生み出す冗長性（技術的負債）の解消とリファクタリングの見極め
- パッケージ管理・脆弱性対応の定期チェック
- モデルが学習した古い技術が紛れ込んでいないかの確認
- 成果物の技術的な正しさの保証、実装漏れの有無
- 人間側の説明責任
AIは既存のコンテキストやドキュメント、ソースコードの構成に沿った出力を行う「現状維持バイアス」を本質的に持ちます。課題を発見し対応を始める起点は、常に人間が与える必要があります。
AIに現状維持バイアスが働くことはAIの役割としてはむしろ健全です。与えられたコンテキストに沿った出力をするという汎用的な仕組みがAI（LLM）の本質です。
もし、新機能追加を頼むたびにAIが勝手に課題を探してリファクタリングを始めるようでは、AIの汎用性を損ないます。必要なタイミングで定期的にテコ入れするのは、これからも人間の役割です。
二極化 ― ドキュメントを維持できる企業とできない企業
過去にも上流工程やドキュメント整備を重視する取り組みは何度も試みられ、多くが現場の実態に追いつかれず失敗してきました。理想論が先行し、書いても読まれないドキュメントは静かに腐っていきます。
AI時代がこれまでと違うのは、AIにとってドキュメントは肝となるコンテキストであり、人とは違ってドキュメントの不足が致命的となる場合が増えることです。ドキュメントの劣化は、成果物の劣化として即座に跳ね返ってくるため、劣化を隠せなくなります。
裏を返せば、これは人間側の「読む・評価する」力への投資をこれまで以上に要求します。ドキュメント駆動が機能する企業と、旧来のやり方から抜け出せない企業とで、競争力の差は今後さらに開いていくはずです。
AIへの過剰適応というリスク
委任の範囲が広がるほど深刻化するのが、人間が説明責任を果たせなくなることです。無秩序にコンテキストを与え判断まで委ねた結果、誰も成果物をコントロールできなくなる状態が起こり得ます。
これは人のマネジメントで起きてきた現象と同じ構造です。部下に丸投げする上司が良い上司になれないように、何でもAIに任せれば競争力が上がるという発想は危険です。現場を知らない人が突然トップに立って失敗する組織に似ています。
違いはAIによる出力量の多さです。生成速度にガバナンスの能力が追いつかない組織ほど、問題が顕在化したときの影響範囲は大きくなり、負債は指数関数的に積み上がっていきます。
この過剰適応を避ける鍵は、委任する側の人間が持つボトムアップからの理解です。
「ボトムアップ」からの理解が「予測可能性」を支える
「自分で設計・実装する」「設計は自分で行い実装は他者に委ねる」「要件だけを示し設計〜実装まで他者に委ねる」など、自分がどんな役割になったとしても最終的な品質を左右するのは細部への深い理解です。
これは全ての設計やコードを自分で書く事ではありません。勘所を掴んだ上で全体の予測が立てられることです。
そしてAIの登場で理解の仕方は変わりました。すべてのコードを自分で書かなくても、AIが代わりに書いてくれるからです。それでも成果の質を上げるためなら必要に応じてコードにも踏み込むべきです。これは精神論ではなく、その方が合理的で効率的なケースも多いからです。
個々の仕組みを深く理解した経験が、全体構造を類推し勘所を掴む力になります。SIerには「模範となる雛形をつくり、それをもとに進めてもらう」という仕事の型がありますが、AI時代も雛形を自分で理解しコントロールできることの重要性は変わりません。
AI開発には、指示さえすれば何でも実現してくれる気がする「トップダウン」の罠があります。「AIを沢山動かして出力が多いほうが仕事をこなしている」という錯覚に陥ってしまうと、上記のボトムアップの大切さを見失います。
気づかないうちに成果物へのコントロールと納得感を失っている危険性が高いのです。
組織としてどう育てるか
AIによって学習や実装のコストが大きく下がった以上、上流工程や下流工程といった各開発の工程、各自のロールで壁はあまり作らないほうが良いです。企画や営業や上流工程においてシステムの詳細の設計、勘所がつかめていれば提案の幅も広がります。
これまで「上流」「下流」で役割を分けてきたのは、複数領域の学習・実装コストが個人には重すぎたためです。AIがそのコストを大きく下げた以上、あえて役割の壁を残すことは成長機会を狭め、提案力や設計判断の幅を狭めることにつながります。
育成の実務としては、担当領域に縛られず、必要に応じて仕様書やソースコード、アーキテクチャに踏み込んで学ぶ機会を用意することが有効です。AIに「なぜ？」を問い続け、納得感を得ながら理解を深める細かい経験の積み重ねが、全体の動きの予測可能性へ繋がります。
AIによる成果をどう評価するか
評価では「AIをどれだけ使ったか」を称える文化を避けるべきです。使用量を評価基準にすると、品質を伴わない見せかけの生産性が横行し、負債を増やしたり組織として信頼を毀損する恐れがあります。そういった環境の悪化が、現場を実際に支えている人材の意欲を損なう可能性もあります。
AIを導入するにあたっては、企業がこれまで積み上げてきたノウハウに対して「何が強みか」「その強みをAIでどう補助・拡張するか」を考えることが大切です。この分析は、現場で活躍する人材への丁寧なヒアリングを通じて行うべきです。
現場で企業を支えている人材は、必ずこのAI導入の過程で必要になります。そうした人材がAIを使ってどれだけ「予測可能な成果物」を作れているかに焦点を当てて評価するとよいでしょう。遠回りに見えて、これが最も確実な道です。
まとめ
AIを使った開発は、仕様書という形式知だけでは支えきれません。本当に鍛えるべき力は、次のように整理できます。
- 仕様書は一次成果物になるが、それだけで開発は回らない
- ドキュメントを読み、問い続ける人材への投資が競争力を左右する
- 無秩序なAI依存は品質低下・説明責任の喪失・信頼の毀損を招く
- ボトムアップからの理解が、成果物をコントロールする力を支える
私たちITものづくり株式会社は、AI活用による内製化支援に加え、業務ナレッジやシステム仕様のドキュメント化、AIが参照できるナレッジベースの構築を支援しています。開発体制やドキュメント文化づくりにお悩みの企業様は、ぜひお気軽にご相談ください。