この記事は NTT ドコモソリューションズ Advent Calendar 2025 23日目 の記事です。
はじめに
こんにちは、NTT ドコモソリューションズの佐々木です。社内では LLM を使ったプロダクト創出や開発推進に携わっています。
これまでに「Qdrantで日本語のキーワード検索（BM25）を実装する」「Azure OpenAI で不適切な表現や、特定の語句・話題を回避する方法と実装例」という記事を書いてます（よかったら見てね）
わたしは趣味で OSS コントリビューションをしているのですが、最近の AI 駆動開発の煽りを受けてか、いつの間にか Git リポジトリに AGENTS.md や .claude が配置されることも増えてきました。
皆さんの周りでも AI を開発にどう活かすかという話が絶え間なく交わされているんじゃないかなと推測する一方で、正直うまく使いこなせないだとか、全く良さがわからないといった方もいらっしゃるのではないでしょうか。
本記事は「AI は究極的に〈プロジェクトに入ったばかりの中堅の部下〉である」ことを主張の根幹とし、少しでも皆さんの中にある AI 駆動開発に対するイメージを膨らませて AI をより扱いやすくすることを目的とします。
AI 駆動開発（AIDD, AI-Driven Development）
AI 駆動開発という言葉が完全に独り歩きしている部分があるかと思うので、本記事で取り扱う言葉の定義は以下のように定めます。
AI を開発の中に取り入れ、人と協働しながらシステム開発を駆動させる手法
つまり、Vibe Coding 1 やスペック駆動開発（SDD）が内包される、より抽象度の高い概念として AI 駆動開発を捉えます。
まず結論：AI は「プロジェクトに入ったばかりの中堅の部下」である
私自身 AI 駆動開発を実践して数ヶ月になりますが、AI のことを プロジェクトに入ったばかりの中堅の部下 と捉えるのが一番しっくり来ています。
（最近話題になっていた「2025年版 私がAIエージェントと協働しながら集中する方法」の内容とも一部合致するのではないかなと思います）
このアナロジーが適用できると、これから述べる AI 駆動開発における違和感や失敗の多くが説明できます。
AI が「部下っぽい」理由
みなさんは普段 Claude Code や Cline などを使っていて次のような経験はないでしょうか。
AI 駆動開発あるある
- プロジェクト固有の事情を一切考慮してくれない
- 書き方が微妙に統一されていないコードを出してくる
- 並列で作業させると、同じような実装を重複して書いてくる
- 想像していたのと全く異なる成果物を出してくる
これらは一見 AI の欠陥のように思えますが、よくよく考えるとこれらは人だけで構成された現実の開発プロジェクトでも起きていないでしょうか？
現実の開発との対比
プロジェクト固有の事情を一切考慮してくれない
→ 案件に参画して間もない開発者に案件の事情を汲んだ開発はできない
書き方が微妙に統一されていないコードを出してくる
→ コーディング規約やリンターが整備されていないプロジェクトで書き方は統一できない
並列で作業させると、同じような実装を重複して書いてくる
→ タスク分割が雑なら実装の衝突や重複が起きるのは当然
想像していたのと全く異なる成果物を出してくる
→ 「いい感じにやっといて」という指示で想像通りに仕上がることは無い。具体的な指示が必要
内部的には attention weights が均一化していたり、Context Poisoning が起きていたりしてそうですが2、外部からみたら全て「中堅レベルの技術知識をもった人間の部下」というアナロジーに帰納できるのではないでしょうか。
より厳密には LLM は既に学習済みの情報しか持ち合わせていないので プロジェクトに入ったばかりの 中堅レベルの技術知識をもった部下という評価になります。（この課題を解決するために Memory MCP や Serena などのツールが登場）
人間と AI の決定的な違いは「責任を持てるかどうか」
ただし、人間と AI は「説明責任を持てるかどうか」という点で異なります。
例えば人間は自分が書いたコードに起因して不具合が起きたとき、その不具合に対して責任を取ることができます。一方で、AI は不具合に対する責任追求があったとしても、その責任を負うことは原理的に不可能です。
制度的にリスクとして AI が負うべき責任を許容することもできますが、AI が説明責任を負わないという構成には変わりません。
故に「部下」という属性はさらに支持されるものの、人間が負うような責任をどう調理するのかは人間に委ねられます。
現実的には例えばこの責任分担は次のように現れます。
- AI が書いたコードは必ず人間がレビューして承認する
- どこまでを AI に任せて、どこからを人間が判断するかを決めておく
ただし、これもまた従来の開発と同様の取り決めといえます。（AI = メンバと読み替えれば同じ）
AI 駆動開発でもソフトウェア工学の原則は生き続ける
この世に銀の弾丸が存在しないように、AI 駆動開発も銀の弾丸ではありません。
これまでの議論からも明らかになった通り、人間に近しい部分があるからこそ 従来のソフトウェア工学的な原則の重要性が引き継がれます。
これまで皆さんはチーム開発において以下のような取り組みをしてきたかと思います。
- リンターやフォーマッタによるコードスタイルの統一
- タスクの疎結合化と具体化
- 網羅的かつ具体的な要件定義・設計
- 早期レビューによる手戻りの最小化
これらは全て「ルールや知識を明文化することで人によるバラつきを最小化する仕組み」と言い換えられます。つまり、本質的に生成結果に揺らぎを持つ AI に対し、その揺らぎを最小化する仕組みとして転用することができます。
Is vibe coding dead? - No.
となると設計書や仕様書をガチガチに組んで AI の出力を制御するのが正攻法に見えますが、私は必ずしもそうとは言いません。
コンテキストによる制御という意味合いでは最も緩いのが Vibe Coding で、最も厳しいのがスペック駆動開発といえるかと思います。
Vibe Coding はコンテキスト文書を作り込むよりも、まず動くものを出す価値が高い場面で有用だと考えています。例えば将来的に破棄することが明らかになっている実験的プロジェクトなどはこれに当てはまります。
一方でスペック駆動開発はコンテキスト文章を作り込んでまで将来の保守コスト削減に見合うような場面で有用だと考えています。
つまり Vibe Coding はまだ生きており、状況によって使い分けることが適切といえます。
AI 駆動開発は何が嬉しいのか
結局従来のソフトウェア開発と同じじゃん！ってことで気落ちしてしまうかもしれませんが、AI の優位性も当然ながらあります。
代表的な AIDD のメリット
- デリバリの速さは間違いなく向上する
- 試行錯誤のコストが下がり、プロダクトのフィードバックサイクルが加速する
- プロジェクトの暗黙知が露出し、運用のルール化や知識の形式化が進む
- 学習済み知識によって一定の品質を担保できる
What を定義しただけで忠実にタスク遂行してくれる部下を何人も抱えられる と考えれば、これほど強力な開発体制はないかと思います。
おわりに
AI 駆動開発は銀の弾丸ではありません。が、上手く活用すればこれまで自転車を漕いでいたのが車を運転するような感覚で開発を加速させることができます。
コンテキストやツールの準備というオンボーディングは必要かもしれませんが、あなたのもとにも１人、中堅の部下として新しく迎え入れてはいかがでしょうか。
記載されている会社名、製品名、サービス名は、各社の商標または登録商標です。