社内の勉強会（WG）で話し合った内容をもとに、AIを使った開発で「何が速くなり、何が速くならないのか」をご紹介します。テーマは「AI駆動開発で『作って見せる』は早くなる。では何が遅くならないのか」です。
ChatGPTやClaudeなどのAIを使えば、画面や機能のたたき台は驚くほど短時間で作れます。自社で試してみて「思ったより簡単にできた」と感じた方も多いのではないでしょうか。WGでは、その実感と、実際に業務で使えるシステムを作るために必要な作業量との間に、大きな差が生まれやすいことが話題になりました。開発を依頼する側・受ける側の双方に役立つ視点として、ポイントを整理します。
1. 「実装」は開発全体の一部にすぎない
WGでまず共有されたのは、プログラミング（実装）が開発工程全体に占める割合は2〜3割程度だという点です。AIが速くしてくれるのは主にこの部分で、残りの工程はそのまま残ります。
AIで「すぐできた」と感じるとき、次のような作業が見えにくくなりがちです。
- 計測範囲の違い：AIとの対話やコード生成にかかった時間だけを数えてしまい、変更内容をまとめて確認する作業、AIによるレビューの繰り返し、手動での動作確認などの時間が抜け落ちる
- 工程範囲の違い：要件の確認、結合テスト（複数の機能を組み合わせた確認）、検証環境への反映、本番での確認、デグレ確認（以前動いていた機能が壊れていないかの確認）などの品質を守る工程が意識されない
- 既存コードを読み解くコスト：すでに誰かが手を加えたコードに機能を追加する場合、その変更の意図を理解し、変更同士の衝突（コンフリクト）を解消する作業が必要になる
どちらかが間違ったことを言っているわけではなく、「どこからどこまでを工数として数えるか」の定義が違うことが、認識のずれの原因になります。AIによる局所的な効率化だけを見て全体の工数を判断すると、プロジェクトの進め方そのものが迷走しやすくなります。
2. 「デモで動く」と「本番で使える」は別物
「作って見せる」進め方は、方向性をすり合わせたり、見た目や基本動作を確認したりするには非常に有効です。ただし、デモ画面で動くことと、本番運用に耐えられることは別の話です。
WGでは、デモでは問題なく動いていても本番で問題になりうる典型例として、次のようなものが挙げられました。
- プッシュ通知の宛先情報の扱い：一時的なネットワーク障害が起きただけで、通知の宛先となるトークン（FCMトークン）をデータベースから削除してしまい、利用者がアプリを再起動するまで通知が届かなくなる
- エラーの種類を見分けない処理：エラーコードを判定せず、障害が起きたら一律にデータを削除してしまう
- ログや監視の不足：エラーを可視化する仕組み（Crashlyticsなど）が十分でなく、本番でHTTP 500エラー（サーバー側のエラー）が多発していても気づけない
- データベース変更の確認不足：起動時に自動で適用されるDBマイグレーション（データベース構造の変更手順。Flywayなど）の確認が不十分で、既存の機能が壊れてしまう
いずれも、画面を触っているだけでは気づきにくい「裏側」の問題です。また、手元での検証を飛ばして、本番や検証環境で直接修正とデプロイ（反映）を何度も繰り返す進め方や、本番の利用者データを使ってテストする進め方は非常に危険だという点も確認されました。
「作って見せる」は方向性の確認、「テスト」は壊れていないかの確認で、目的がまったく違います。前者がいくら速くなっても、後者を飛ばせば不具合のツケは運用障害として返ってきます。
3. AI時代の「テスト」の考え方
コード生成をAIに任せられるようになった今、開発の中心は「人がコードを書くこと」から「テストや受け入れ基準を決めて、仕様を確定させること」へ移りつつある、というのがWGでの議論の中心でした。具体的には次の4点です。
テストが仕様書の役割を果たす
詳しい仕様書を先に作らずに進めるアジャイル開発（短い周期で作って確認を繰り返す進め方）では、先に書く受け入れテストそのものが「仕様書」になります。これはTDD（テスト駆動開発：先にテストを書き、それを満たすようにコードを書く手法）の考え方です。
「イジワルテスト」は人が考える
コードとテストの両方をAIに書かせると、AIは同じ前提・同じ誤解を共有したまま作業するため、間違った実装でもテストが通ってしまうことがあります。境界値（上限・下限ぎりぎりの値）や、わざと例外を起こすような「イジワルテスト」（異常系・限界値のテスト）の設計には、人の関与が欠かせません。
回帰テストを最優先にする
新しい機能を足すスピードが上がるほど、既存の機能を壊すリスクも高まります。変更を加える前に、今の正しい動きを守るための回帰テスト（リグレッションテスト：変更で既存機能が壊れていないかを確かめる自動テスト）を「ガードレール」として先に用意しておくことが重要です。
人のレビュー対象を変える
エンジニアの仕事は、コードを1行ずつ目で追うことから、「テストケースに抜け漏れがないか」「受け入れ基準を満たしているか」を評価することへ移っていきます。AI時代には、コードを書く力以上に、境界値・例外・悪意ある使われ方まで含めた異常系を言葉にして設計できる力が重要になる、という意見で一致しました。
4. 開発を進めるうえでの実践ポイント
ここまでの議論を踏まえ、WGでは開発の進め方として次のような考え方が整理されました。発注側の方にとっても、見積もりや契約を見るときの参考になるはずです。
- 見積もりを工程ごとに分けて示す：実装（コード生成）の工数と、品質検証・テスト・統合の工数を分けて提示し、「AIで速くなる部分」と「速くならない部分」を見える化する
- 「完成」の定義をはっきりさせる：アジャイルで進める場合も、完成の条件を「自動テストの通過」などと明確にし、納品の単位を区切る。発注側が自らコードに手を加えた場合の責任の範囲も、あらかじめ取り決めておく
- コードとテストはセットで扱う：テストを含まない変更は原則としてメインのコードに取り込まない
- 既存システムには先に回帰テストを用意する：AIで機能を追加する前に、今の動作を守る自動テストに投資する
- レビューの重点をテストの妥当性に置く：テストの網に抜けがないかを人が確認する
また、AIの活用が進むなかで、1人のエンジニアが役割の異なる複数のAIエージェント（作業を自律的に進めるAI）を率い、設計・実装・テストを短いサイクルで回す体制は合理的だ、という意見もありました。分業によるやり取りの手間を減らせる一方で、ここでもテストによる品質の担保が前提になります。
まとめ
AIによって「作って見せる」までのスピードは確かに大きく上がりました。しかし、要件の確認、テスト、既存コードとの統合、本番での確認といった品質を守る工程は、AIだけでは速くなりません。むしろ開発が速くなるほど、テストの重要性は増していきます。
AIで作ったたたき台を本番で使えるものに育てるには、「どこまでが速くなり、どこからが速くならないのか」を関係者全員で共有しておくことが大切です。弊社でも、こうした考え方を開発の進め方に取り入れていきます。
技術ブログのほかの記事