AI 駆動開発で、実際に何が速くなり、何が速くならないか

AI を使った開発で生産性が上がるのは事実ですが、
工程によって効果がまったく違います。実際の体感を分解します。

大きく速くなる領域

1. 定型的な実装

CRUD、フォーム、管理画面、APIのエンドポイント。
パターンが決まっているものは劇的に速くなります。

2. 書き慣れていない言語・ライブラリ

調べながら書く時間がほぼゼロになります。
「知らないから遅い」が解消されるのが最大の変化でした。

3. テストコード

書くべきだと分かっていても手が回らなかった領域が、
現実的なコストで書けるようになりました。

4. 定型文書

設計メモ、手順書、コミットメッセージ、リリースノート。

5. 既存コードの理解

引き継いだコードの全体像を掴む時間が短縮されます。
「この関数は何をしているか」を聞けるのは大きい。

ほとんど変わらない領域

1. 何を作るべきかの判断

顧客の困りごとを聞き、本当に必要な機能を見極める工程。
ここは情報を持っている人にしかできません。

2. 設計の意思決定

「この規模ならモノリスで十分」「ここは分離すべき」といった判断。
選択肢は出せますが、その事業の制約を知っているのは自分です。

3. 顧客とのやり取り

要件の確認、仕様変更の相談、進捗の報告。

4. 本番運用と障害対応

実際のサーバーで何が起きているかの調査。
状況が特殊であるほど、自分で切り分けることになります。

5. 最後の20%

動くところまでは速いのですが、
細部を詰めて実運用に耐える形にする工程は、あまり変わりません。

全体としてどうなるか

工程ごとの比率で考えると、実感に近くなります。

要件・設計の判断    30%  → ほぼ変わらない
実装               40%  → 大幅に速くなる
テスト             15%  → 速くなる
運用・障害対応     15%  → ほぼ変わらない

実装が3倍速くなっても、全体では2倍前後というのが実際の感覚です。
「10倍速くなる」は、実装だけを見た数字だと考えています。

速度以外の変化

実は、速度より効果が大きいと感じている点があります。

1. 着手のハードルが下がる

「面倒だから後回し」が減りました。
テストを書く、ドキュメントを残す、リファクタリングする。
やったほうがよいと分かっていたことが実行されるようになりました。

2. 試す回数が増える

実装が速いと、捨てる前提で作れます。
2案作って比べる、という進め方が現実的になりました。

3. 一人でできる範囲が広がる

不慣れな領域も自分で手を出せるようになり、
外注や相談で止まる時間が減りました。

気をつけていること

• 理解していないコードをそのまま使わない（保守できなくなる）
• 生成されたものを読む時間を確保する
• 設計判断は自分で行う

速く書けることと、正しく作れることは別です。

まとめ

速度以上に、着手のハードルが下がり、試行回数が増えることの効果が大きい、
というのが実際に使い続けての結論です。