AI駆動開発とは何か ── 何が速くなって、何が速くならないのか

AI駆動開発、という言葉をよく見るようになりました。ただ、中身の定義は会社によってばらばらです。社内でAIツールを使っているという意味で使っている会社もあれば、開発の進め方そのものを組み替えている会社もあります。

私たちはこの言葉を看板に使っている側なので、何をしていて何をしていないのかを書いておきます。発注を検討する立場から見て、どこが変わってどこが変わらないのかが伝わればと思います。

実際にやっていること

開発の工程は、おおまかに「何を作るか決める」「作る」「確認する」に分かれます。AIを使っているのは、主に2番目と3番目です。

画面の実装、データの構造に沿った処理、入力チェック、テストコード。こうした、決まったことを形にする作業は、以前と比べてかなり速くなりました。使ったことのないライブラリの調べ物も速いです。設計を考えるときの壁打ち相手としても使います。

ただ、生成されたものをそのまま使うことはありません。読んで、直して、テストを通します。速くなったのは「書く」ところで、「決める」ところと「確認する」ところは人の仕事のままです。

速くならない工程のほうが、実は重い

ここが一番伝えたいところです。

業務システムやMVPを作るとき、時間を食うのは実装ではありません。誰がどの画面を使うのかを整理する、いまの業務の例外パターンを洗い出す、今回は作らないものを決める、社内で合意を取る。この部分はAIでは短縮できません。相手が人であり、決めるのが人だからです。

自社の業務システムを作ったときも、同じことが起きました。26画面の初版が動くまで4日でしたが、その前に業務フローと状態遷移と権限の設計書を書き切っています。経緯は研修事業の業務コンソールに書きました。作る工程は速くなりましたが、決める工程は速くなっていません。

私たちが8週間のうち最初の2週間をコードを書かずに使っているのは、この理由です。ここを飛ばして実装を始めると、速く作れるぶんだけ速く間違ったものができます。工程の中身は2ヶ月で作れるもの、作れないものに週ごとに書きました。

言い方を変えると、AI駆動開発の効果は「実装が速くなる」ことそのものより、実装が速くなったぶんを、決める工程と確認する工程に回せることにあります。従来の進め方では、要件定義に十分な時間を使うと、そのぶん実装が押して納期が延びました。いまはそのトレードオフが緩くなっています。

発注側から見て、何が変わるか

	これまでの受託開発	私たちの進め方
体制	営業・PM・設計・開発・テストで分業	相談した相手がそのまま作り、リリース後も見る
初期費用	人月の積み上げ（300万〜1,000万円）	画面数を基準に50万円（税別）から
確認のタイミング	要件定義書、設計書、そして完成品	3週目以降、毎週動くものを触ってもらう
仕様変更	工程が進むほど高くつく	毎週見てもらうので、ずれが小さいうちに直る

金額が下がる主な理由は、実はAIではなく体制です。分業をやめると、会議と伝言と資料作成がまるごと無くなります。人月の積み上げから外れられるのはそのためで、AIの活用はそこに重なっている、という順序です。この構造についてはMVP開発の費用は、何で決まるのかに詳しく書きました。

進め方の側で大きいのは、毎週動くものを見てもらえることです。仕様書を読んで想像して承認する、という工程が減ります。想像が食い違っていたことに完成時点で気づく、という一番痛い失敗が起きにくくなります。

品質はどう担保しているか

「AIが書いたコードで大丈夫か」は当然の質問だと思います。やっていることは、従来と大きく変わりません。

型のある言語で書いて、コンパイルの段階で不整合を落とします。自動テストを書いて、変更のたびに通します。そのうえで人が読みます。読むのは、生成されたコードが動くかどうかではなく、この業務にとって正しいかです。処理としては正しくても業務の例外を取りこぼしている、というのが実際に起きるずれで、それは業務を理解している人間にしか見つけられません。

もうひとつ、リリース後の12ヶ月を私たち自身が見ることが、品質に効いています。作って引き渡して終わりなら、動きさえすれば済みます。1年間自分で面倒を見るとなると、読みにくいコードも、直しにくい構造も、自分に返ってきます。

よくある誤解を3つ

「AIが作るから安い」。 半分です。前述のとおり、金額に効いているのは体制のほうが大きいです。AIツールを導入しただけで料金を半額にしている会社があるとしたら、どこかにしわ寄せがあるはずなので、何を削ったのかを聞いてみてください。

「AIが作ると品質が落ちる」。 使い方次第です。生成物をそのまま納品すれば落ちます。逆に、空いた時間をテストとレビューに回せば上がります。発注側が確認できるのは、テストをどう書いているか、誰がコードを読んでいるかを説明できるかどうかです。

「ノーコードと同じようなもの」。 違います。ノーコードは既製サービスの上に設定で組み立てるので、早くて安い代わりに、ツールの想定を外れる要件は作れず、ツールの提供が止まると動かなくなります。私たちが作るのは通常のコードで、ソースコードは手元に残ります。要件が既製品の枠に収まるなら、正直ノーコードのほうが向いています。

開発会社に聞くとしたら

AI駆動開発を掲げている会社に相談するなら、この2つを聞いてみてください。

ひとつは「どの工程でAIを使っていますか」。要件整理から実装まで全部、という答えなら、決める工程を人がやっていない可能性があります。もうひとつは「生成されたコードは誰が読みますか」。読む人がいないなら、速いだけです。

私たちの8週間の進め方は進め方のページに、MVP開発という枠組みそのものについてはMVP開発とは何かに書いています。