こんにちは。株式会社SalesNowでCTOを努めている梅本です。今回はAI駆動開発・バイブコーディングによって大きく変わろうとしている開発手法について紹介します。
はじめに：エンジニアの価値が再定義される時代
Devin、Claude Code、Gemini CLI の登場により、ソフトウェアエンジニアの役割は大きな転換点を迎えています。これまでエンジニアの価値の中核を占めてきた「コードを記述する能力」という専門能力は、AIによって急速に大衆化し、その前提が根底が覆されようとしています。
これは悲観すべき事態ではなく、エンジニアの価値が「実装の詳細（How）」から「仕様やアーキテクチャ（What, Why）」へとシフトする、必然的な進化です。昔からSIer/SESの世界では海外のオフショア活用で実装は手から離れていました。事業会社では品質やスピード優先でオフショア活用は進んでいませんでしたが、生成AIによって事業会社でもエンジニアの役割は、ビジネス価値を最大化するシステム設計者と、設計に基づき生成AIを動かす指揮者の2つに変化します。
本稿では、この新しい時代に適応するために、私自身が有効だと考えている4つの新常識を、お話します。
1：実装では生成AIがCopilotから"ドライバー"に。エンジニアは指揮者に
これまでの生成AIはCopilotで、ペアプログラミングにおける「ナビゲーター」の役割分担でした。しかし、生成AIの発達により、役割は逆転しこれからは生成AIが「ドライバー」となり、エンジニアは生成AIをナビゲートする立場になります。また、生成AIは調査時間、思考時間、実装時間が必要のため、１つの依頼に平均数分程度の処理時間が必要です。そのため１：１でナビゲートするのではなく、一人で複数のターミナルを立ち上げ、多数の生成AIを同時にナビゲートする指揮者になります。
人間の価値は戦略的な"指示出し"と"レビュー"
生成AIはゴールが明確になれば、バグが少なくルールに従った実装を行ってくれます。大きい粒度でタスクを与えるとゴールが不明確になり、期待していた結果は得られません。その一方で小さい粒度でタスクを与えると、修正に必要な範囲を見逃し、極めて局所的な修正しか行われません。
- 指示自体が自然言語でファジーな点があること
- コンテキストに必要な情報が入っておらず曲解や誤った推測をすること
- 生成AI自体がバイアスが掛かった思考を行うこと（学習したデータを正としがち）
という点から、一回で完全な結果を得ることは難しく、結果をレビューして調整を何回か繰り返すことになります。
これからのエンジニアは、上記の問題に対応するため、システムの全体最適を考え、AIの出力を的確に批評・修正する能力が必要です。また、どこは人力でやったほうが良いのかの境界線の判断も重要です。この「どの粒度でどこまでのタスクを依頼するのか」という判断こそが、今後のエンジニアの中核的な専門能力になります。
2：ウォーターフォール開発の終焉。開発は「超高速プロトタイピング」が基本に
従来のウォーターフォール型のような「設計→実装」という直線的なプロセスは必要性が減ります。従来のアジャイル型よりさらに高速なプロトタイピング型開発が今後は主流になりそうです。
元々、開発手法はざっくりとウォーターフォール、アジャイル、プロトタイピングの3つがありました。プロトタイピングは数多くのメリットがありましすが、デメリットとして「期間が長くなり、費用が高くなる」ことから、時間に余裕があり、特に高品質を目指したい状況でしか採用しづらかったです。
しかし生成AIによって、このデメリットが解消されるのであれば、UIを持つ開発はプロトタイピングが第一の選択肢になります。生成AIを用いれば、自然言語のラフなアイデアから、操作可能なプロトタイプを数分で生成できます。クライアントやビジネスサイドに画面を見せ、意見を聞きながら、その場で瞬時にプロトタイプを修正することも可能です。
| 開発手法 | メリット | デメリット |
|---|---|---|
| ウォーターフォール開発 | ・工程やスケジュールが明確で計画が立てやすい ・各工程で設計書等の成果物があるので品質管理しやすい ・予算の見積もりが正確でコストを把握しやすい ・要件が明確で変更が少ない大規模プロジェクトに向いている |
・仕様変更が発生すると、手戻りのコストが非常に大きい ・開発終盤まで動きを確認できないため、依頼者の要求とズレが生じやすい ・テストで重大な問題発覚などリスクの発見が遅く、修正が困難になる場合がある |
| アジャイル開発 | ・短い期間で開発を繰り返すため、仕様変更に柔軟対応できる ・短いサイクルで確認するため依頼者の要求とズレにくい ・優先度の高い機能からリリースできるため、ビジネス価値を早く生み出せる ・短いサイクルでテストするため、リスクを早期に発見できる |
・長期的な計画や正確な見積もりが難しく、全体のスケジュールや予算が見えにく ・依頼者の要求に柔軟に応える反面、方向性がぶれやすい ・チームメンバーの自律性や高いコミュニケーション能力が求められる ・動作するソフトウェアを重視するため、仕様書などドキュメントが残りにくい |
| 従来のプロトタイプ開発 | 試作品（プロトタイプ）を作成するため、依頼者の要求とズレにくい ・試作品に対するフィードバックで仕様変更が容易で手戻りを減らせる ・新しい技術を使う場合など技術的な実現可能性を早期に確認できる ・実際に操作してもらうことで、UI/UXを改善し、依頼者の満足度を高めやすい |
・試作品の作成のため開発期間とコストが増加する ・試作品をそのまま製品として使うと、品質や拡張性に問題が出ることがある ・システムの一部やUIの確認には有効だが、大規模なシステムのシステム全体の構造設計には向かないことがある |
| 生成AIによる超高速プロトタイピング | 従来のプロトタイプ開発のメリットに加え ・試作品作成にかかる時間とコストを劇的に削減 ・関係者が触りながらリアルタイムでの調整が可能 |
・しっかりコントロールしないとアーキテクチャや品質を軽視し、長期的に不安定 ・人間の意思決定が追いつかずステークホルダーのフィードバックがボトルネックになる可能性がある |
3：ソースをAIに最適化。「コンテキストエンジニアリング」という攻撃的戦略
LLMの精度向上でプロンプトの重要性は減り、何を参照させるかのコンテキストが重要になりました。現在はAIの特性に最適化した「コンテキストエンジニアリング」が必要です。
極論を言えば、全てのソースをコンテキストで与えるのが最も精度が高くなります。しかし、小さなプロジェクトならともかく、大規模なプロジェクトでは、どこまでをコンテキストとして与えるのかが問題になります。明確に指示したり、情報が不足すれば生成AI自体がソースを辿って調査してくれますが、この時の精度がさほど高くなく、過剰に検索しまくったり、必要なファイルを見逃したりすることが数多くあります。
そうすると人間の可読性より、生成AIの検索性を重視したソース構造が重要になってきます。例えば１つの大きい機能は、再利用しなくてもコンポーネント化して可読性を高めていましたが、生成AIでは別コンポーネントにすることで見落とされるリスクが高まります。
そのため、コンテキストから漏れることを防ぐため、1ファイルの行数が長くなってもソースとしてはあえて１つにする戦略が考えられます。人間の可読性はVSCodeでリージョン折りたたみを活用するなど他の工夫でカバー出来ます。
フロントとバックエンドが別言語・別システムならモノレポ構造に集約するのも有効でしょう。フロントとバックエンドを別々に開発するのではなく、１つの振る舞いを指示することで一気通貫に実装させます。
現時点の生成AIだとDDDなど抽象度が高いアーキテクチャは不向きで、生成AIを最大限に活かすには30年ぐらい前に流行っていたコンポーネント指向が最適解かもしれないと思ってます。（コンポーネント指向：特定の機能に関してあらゆる処理を詰め込んだ独立した自己完結型の巨大なコンポーネントを用意し、使う側は中身ブラックボックスで使う手法）
4："聖域"を定めて、AIの破壊的変更から守る防御的戦略
生成AIは開発速度を最大化する一方で、他への影響影響についての考慮せず、指示された内容のみをミニマムで実装しようとするため、破壊的変更を引き起こすこともしばしばあります。
そのためシステムのコア部分は意図的にAIの影響から隔離する防御的戦略が不可欠です。
コアアーキテクチャという「聖域」
共有データモデル、重要なビジネスロジック、アプリケーションの基盤となるインターフェース群など、システムの安定性を司る中核部分は「聖域」として定義し、AIによる安易な変更から保護したほうが安全です。
一方で画面の動作などは振る舞いだけで制御・テストがしやすいため、実装をブラックボックスで生成AI任せでも問題ないと思います。まったく異なる書き方のソースが量産は良くないのですが、1本だけソースレベルで納得するものを作り上げて、横展開だけ生成AIに任せるとそこまで酷いものにはなりません。
コアアーキテクチャについては、基本触らせない、触る場合はかなり綿密にソースレビューするなど防御的戦略が必要です。
まとめ
これまで述べてきた4つの新常識は、単なるテクニック論ではありません。最も重要なのは、私たちエンジニア自身のマインドセットの変革です。
これからのエンジニアはビジネスの課題を深く理解し、最適なアーキテクチャを描き、AIという最強のツールを率いてプロダクトを創造する「建築家」であり「指揮者」なのです。
実装という"How"をAIに委ねる勇気を持ち、私たちは"What"（何を創るべきか）と"Why"（なぜそれが必要か）の探求にこそ、情熱と能力を注いでいくべきです。この意識改革こそが、AIに代替されないエンジニアの生存戦略となるでしょう。
Discussion