スクラッチ開発とAIで変わること｜減る負担と人の判断
AIを使った開発が広がり、スクラッチ開発（既製品に頼らず、一から設計して作る開発）の進め方も変わりつつあります。この記事では、AIによって負担が減りやすい部分と、AIを使っても人が決めて確かめる必要がある部分を分けて整理します。新規事業でスクラッチ開発を検討するときの、判断の手がかりとしてお読みください。
スクラッチ開発にAIが入ると、何が変わるのか
スクラッチ開発とは、既製のパッケージやノーコードツールを土台にせず、要件に合わせて設計から実装まで一から作る開発方法です。言葉の意味や既製品との違いは、スクラッチ開発とは？英語の意味と既製品・ノーコードとの違いで詳しく整理しています。
自由度が高い一方で、作る量が多いことが負担でした。画面、データの持ち方、処理の流れ、テストなどを、ひとつずつ作らなければなりません。
AI駆動開発（AIを開発工程に組み込んで進める開発）では、この「作る量の多さ」の一部をAIが担います。要件の整理、設計、コードの記述、テストの下書きといった工程で、AIが案を出し、人が確認します。基本的な考え方はAI駆動開発とは｜AIと人の役割分担と発注側の要点でも説明しています。
ここで押さえておきたいのは、AIが手伝うのは主に「作る」作業だという点です。「何を作るか」「それで事業として成り立つか」「品質は十分か」という判断は、AIを使っても残ります。以降では、この二つを分けて見ていきます。
AIで負担が減りやすい部分
定型的なコードの書き起こし
ログイン、一覧表示、入力フォーム、データの登録・更新・削除といった、多くのシステムに共通する処理があります。こうした定型的な部分は、AIが得意とする領域です。一から書く手間は、以前より小さくなる場合があります。
スクラッチ開発では、こうした共通部分の作業が積み重なって、全体の工数を押し上げてきました。そこをAIが下書きし、人がレビューする形に変わると、人は事業の独自性に関わる部分に時間を使いやすくなります。
設計のたたき台づくり
画面構成、データベースの項目、処理の流れなどの設計も、AIがたたき台を出せる領域です。ゼロから考えるより、案を見て直すほうが速いことは少なくありません。
ただし、たたき台はあくまで案です。データの持ち方は後の機能追加や分析のしやすさに関わるため、どこまで任せてどこから人が見るかを決めておく必要があります。この点はAI設計でDB設計はどこまで任せる？役割分担の考え方で扱っています。
テストコードや資料の下書き
テストの観点の洗い出しや、テストコード・設計資料の下書きも、AIが手伝いやすい部分です。人が一から書くと後回しになりがちな作業なので、下書きがあるだけでも進めやすくなります。
ただし、テストの網羅性や、事業にとって重要な場面が押さえられているかは、人が確認することになります。任せる範囲と人が見る項目は、AIのテスト自動生成｜任せる範囲と人が見る確認項目に整理しています。
動くものを早く見せられること
新規事業にとって大きいのは、実際に動くものを早い段階で用意しやすくなることです。企画書の段階では伝わりにくかった「何ができるのか」を、触れる形で示せます。
動くものを見ながら話せると、「思っていたのと違う」という気づきを早く得られます。スクラッチ開発の弱点だった「完成まで実物が見えない」という状況を、変えやすくなる点だと私たちは考えています。
人が決めて確かめる部分は減らない
何を作るか、何を作らないか
AIは、指示された範囲で案を出します。事業として何を最初に作り、何を後回しにするかは決めてくれません。機能の取捨選択は、事業の目的と検証したい仮説から人が決めます。
作る速度が上がると、機能を足したくなる場面も増えます。しかし、機能が増えるほど、確かめることも増えます。最初に作る範囲の考え方は、MVP開発の機能の絞り方｜最初に作るものと後回しの基準が参考になります。
業務や事業のルール
料金の計算方法、承認の流れ、例外の扱いといった、事業ごとの独自ルールは、AIが推測で補えるものではありません。ここを曖昧にしたまま進めると、動くけれど事業の実態に合わないものができます。
AIに作らせる場合でも、作りたいものを言葉にする作業は人の仕事です。その手順はAI開発の仕様の伝え方｜作りたいものを言葉にする手順で解説しています。要件の抜け漏れやズレを防ぐ考え方は、要件定義とは？新規事業で抜け漏れとズレを防ぐ進め方も参照してください。
品質とセキュリティの最終判断
AIが書いたコードは、動いているように見えても、想定外の入力への対応や権限の管理に弱点が残る場合があります。品質の最終判断は人が持つ、という前提は変わりません。
特に、個人情報や決済を扱うシステムでは、セキュリティの確認を後回しにできません。確認の観点はAI生成コードのセキュリティ｜確認点と人の役割に、品質確認の考え方全般はAI開発でも品質には人の確認が必要な理由にまとめています。
責任の所在
不具合や事故が起きたとき、「AIが作ったので」という説明は通りません。発注した会社と開発会社のあいだで、誰がどこまで確認し、誰が責任を持つのかを、あらかじめ明確にしておく必要があります。
これは、AIを使うかどうかにかかわらず、開発では大切な考え方です。AIが入ることで、むしろ「誰が確認したのか」を記録しておく重要性が増すと私たちは考えています。
新規事業のスクラッチ開発で見直したい進め方
仕様を先に固めきる進め方からの転換
従来のスクラッチ開発では、要件定義書や仕様書を先に固め、その内容で費用と期間を見積もる流れが一般的でした。しかし、新規事業では最初から正しい仕様が分かっているとは限りません。使ってみて初めて分かることが多くあります。
AIで試作を作りやすくなると、「先に動くものを作り、見ながら決める」進め方が現実的になります。言葉だけで要件を決めると、完成後に「これじゃない」となりやすいためです。実物を見ながらすり合わせる考え方は、システム開発の認識のズレを防ぐ、実物を見ながらのすり合わせで扱っています。
試作にはモック、プロトタイプ、MVPなどの種類があり、確かめたいことによって使い分けます。違いはプロトタイプとMVP・モックの違いを整理｜新規事業の使い分けで確認できます。
既製品・ノーコードとの選び方
AIによって、スクラッチ開発の作る負担が下がる場合があります。そのため、「既製品では足りないが、スクラッチは大変そうだ」という悩みの前提が、以前とは変わってきています。
とはいえ、既製品やノーコードが向く場面がなくなったわけではありません。決済や認証のように、外部のサービスを使ったほうが安全で早い領域もあります。自作と外部サービスの分け方は、新規事業の決済システム開発｜外部サービスと自作の分け方を参考にしてください。
判断の軸は、システムが事業そのものの差別化になるかどうかです。差別化の中心になる部分は一から作り、そうでない部分は既存のものを組み合わせるという考え方が、現実的な選択になりやすいと私たちは考えます。
AIを使いこなす体制の問い
AIが書いたコードの扱い方には、いくつかの方法があります。個人がAIに指示してコードを書かせる方法と、工程ごとに役割を分けて進める方法とでは、品質の安定度が変わります。
勢いで作る手法と、工程を踏む手法の違いは、バイブコーディングとは｜AI駆動開発との違いと事業での使い方で整理しています。複数のAIが役割を分担する仕組みについては、AIエージェントが開発チームになる仕組みと発注の要点を参照してください。
AI時代のスクラッチ開発で起きやすい落とし穴
作れてしまうので、決めずに進めてしまう
AIで作る速度が上がると、「とりあえず作ってみる」ことが容易になります。これは利点ですが、何を確かめたいのかが決まっていないと、動くものだけが増えて判断材料が増えません。
動くものを作る前に、検証したい仮説と、続けるか止めるかの判断基準を決めておくと、試作が生きてきます。指標の作り方はMVP検証の指標を先に決める方法｜判断基準の作り方で解説しています。
作った後の保守を考えていない
AIが書いたコードは、書き方や構成がばらつくことがあります。作った時点では動いても、数か月後に改修や引き継ぎが必要になったとき、誰も全体を把握していない状態では困ります。
保守のしやすさは、設計の方針や記録の残し方で変わります。引き継ぎと改修で確認したい点は、AI生成コードの保守は可能か｜引き継ぎと改修の確認点にまとめています。
機密情報や権利の扱いが曖昧になる
AIに事業のアイデアや社内情報を入力する場合、情報の扱いを確認しておく必要があります。開発会社がどのAIを使い、入力した情報がどう扱われるのかは、発注前に確かめたい点です。観点は生成AI開発の情報漏洩を防ぐ確認点｜機密と事業アイデアで解説しています。
また、できあがったソースコードの権利が誰に帰属するかは、契約前に確認します。AIを使って作った場合も含めて、システム開発の著作権帰属は誰のもの？契約前の確認点を見ておくと、確認項目を整理できます。
発注する側が確かめておきたいこと
スクラッチ開発をAIで進める開発会社に相談するときは、次のような点を確かめておくと、判断しやすくなります。
- どの工程でAIを使い、どの工程で人が判断・確認するのか
- 動くものを見て判断する機会が、開発の早い段階にあるか
- 設計やコードのレビューを、誰がどんな基準で行うのか
- 納品後の保守や、機能追加の進め方が決まっているか
- 入力した情報の扱いと、成果物の権利が明確か
これらは、AIを使わない開発でも確認する内容と重なります。AIが入ったからこそ、「何をAIがして、何を人がするのか」を言葉にして確認できることが、安心して任せられるかどうかの目安になります。依頼前の確認事項は、AI受託開発に依頼する前に確かめたい6つのことにも整理しています。
なお、AI駆動開発には向く開発と向かない開発があります。長所と注意点をまとめて確認したい場合は、AI駆動開発のメリットとデメリット｜向く開発と注意点も合わせて参考にしてください。
まとめ
AI駆動開発によって、スクラッチ開発の「一から作る」負担のうち、定型的なコードの記述、設計のたたき台、テストや資料の下書き、動く試作の用意といった部分は、小さくなる場合があります。一方で、何を作るかを決めること、事業のルールを言葉にすること、品質とセキュリティを最終的に判断すること、責任の所在を明確にすることは、これからも人の役割として残ります。
新規事業では、仕様を先に固めきるより、動くものを見ながら決めていく進め方が現実的になってきています。ただし、作る速度が上がるぶん、確かめたい仮説や判断基準を先に決めておくことが大切です。AIに任せる範囲と、人が確かめる範囲を分けて考えることが、スクラッチ開発を事業に役立てる出発点だと私たちは考えています。
JustFitは、株式会社LEGAREAが運営する完全オーダーメイドの受託開発サービスで、「先に作って、後から決める（PROTOTYPE FIRST）」を考え方としています。構想をもとに約1ヶ月で動くプロトタイプを開発し、実物を見てから契約を判断できます。開発では、独自のAI開発基盤「LAF」を使い、「何を作るか」と「品質の最終判断」を人が担う体制で進めます。仕様が固まっていない段階でも相談できますので、新規事業のスクラッチ開発を検討されている場合は、JustFitのサービス紹介もご覧ください。