開発会社から届いた提案書に「フルスクラッチで開発します」と書かれていて、ノーコードで作るより何倍も高い金額が並んでいる。自己資金で立ち上げる人がこの場面で迷うのは、「ゼロから全部作る」という言葉の印象と、実際に何にお金を払うのかが結びつかないからです。この記事では、フルスクラッチ開発の意味を確認したうえで、個人のサービスで「自前で書く部分」と「外部から借りる部分」をどう見分け、見積もりで何を聞けばよいかを整理します。
先に要点をまとめます。
- フルスクラッチ開発は、ノーコードツールや既製のパッケージの上に組み立てず、自分のサービス専用のプログラムを書いて作る方式です。ただし実際の開発では、ログイン・決済・サーバーなどを外部のサービスやオープンソースの部品で組み合わせるのが一般的で、文字どおり「全部ゼロから」書くことはほとんどありません
- 言葉の使い方は会社によって幅があるため、見積もりでは呼び方より「どこを書き、どこを借りるか」の一覧を確認してください。月額費用・作り直すときに持ち出せるもの・権利の範囲が、この一覧で決まります
- 個人の立ち上げで全体をフルスクラッチにする必要が出てくるのは、独自の判断ロジックや画面の流れがサービスの価値そのもので、ノーコードの制約に当たる見込みがあるときです。需要を確かめる前の段階なら、ノーコードや一部だけの開発で足りることが多くあります
フルスクラッチ開発とは?
既製のアプリやツールを土台にせず、そのサービスのためだけのプログラムを設計・実装する開発方式です。英語の「from scratch(ゼロから)」が語源で、オーダーメイドの開発と説明されることもあります。
フルスクラッチ開発の対になるのは、主に次の2つです。
- パッケージやSaaSを使う方式:すでに完成している業務ソフトやクラウドサービスを契約し、設定や一部の追加開発で使う
- ノーコードツールで作る方式:Bubbleなどのツールの画面上で部品を並べ、プログラムを書かずにアプリを組み立てる
注意したいのは、「フルスクラッチ」と「スクラッチ」の使い分けが会社や解説記事によって揃っていない点です。開発の土台になる枠組み(フレームワーク)や既存の部品まで使わずに作るものだけをフルスクラッチと呼ぶ説明もあれば、自社サービス専用にプログラムを書く開発全般をフルスクラッチと呼ぶ会社もあります。現在のWebサービス開発では、枠組みや公開されている部品を一切使わずに作ることはまれで、提案書に書かれる「フルスクラッチ」は後者の意味であることが大半です。
言葉の定義を追いかけるより、提案を受けたときに「このサービスのうち、御社が書くのはどこで、外部のサービスや部品に任せるのはどこですか」と聞くほうが、費用の中身を理解する近道になります。
ノーコード・SaaS・フルスクラッチは、何が違う?
違いが大きく出るのは、自由度と初期費用に加えて「やめるとき・移るときに何を持ち出せるか」です。比べるときは、この3点を並べてください。
| 何の上に作るか | 自由に変えられる範囲 | 初期費用の傾向 | 他へ移るときに持ち出せるもの |
|---|---|---|---|
| SaaS・パッケージ | 他社が完成させたサービス | 設定と、用意された拡張の範囲 | 低い(月額中心) |
| ノーコード | ツール提供者の実行環境 | ツールが用意した部品の範囲 | 中くらい |
| フルスクラッチ | 自分のサービス専用のプログラム | 予算と時間が許す範囲 | 高い |
「持ち出せるもの」の差は、具体例で確認しておくと実感しやすくなります。ノーコードツールのBubbleは公式マニュアルで、Bubbleのアプリはプラットフォーム上でしか動かず、アプリをプログラムとして書き出す方法はないと説明しています。利用者のデータはCSV形式で書き出せ、APIでも取り出せるとしています。つまり、Bubbleで作ったサービスを別の環境へ移す場合、データは持ち出せても、画面や処理の仕組みは作り直すことになります。
これはノーコードが劣るという話ではありません。需要を確かめる段階では、作り直しになっても困らないほど早く安く作れることのほうが価値になる場面が多くあります。ノーコードで実現できる範囲の見極め方はノーコードだけで、どこまでの機能が実現できるかで詳しく扱っています。
フルスクラッチでも、外部から「借りる部分」はどこ?
ログイン、決済、メール送信、サーバーとデータベース、画面を作るための枠組みは、フルスクラッチの開発でも外部のサービスやオープンソースの部品を使うのが一般的です。自前で書くのは、そのサービスならではの画面の流れと判断のロジックです。
予約サービスを例に分けると、次のようになります。
| 層 | 例 | 自前で書くか、借りるか | 発注者が確認したいこと |
|---|---|---|---|
| 画面の流れ | 空き枠の見せ方、予約までの手順 | 自前で書く | 自分の業務に合った流れになっているか |
| 独自の判断ロジック | 施術時間と担当者の組み合わせから空き枠を出す計算 | 自前で書く | ルールを自分が言葉で説明できているか |
| ログイン認証 | メールアドレスやSNSアカウントでのログイン | 外部の認証サービスを使うことが多い | どのサービスか、利用者数に応じた料金か |
| 決済 | クレジットカードでの事前決済 | 決済代行サービスを使う | 手数料率、入金のタイミング、審査の有無 |
| メール送信 | 予約確認・前日のお知らせ | 送信サービスを使う | 送信数による料金、迷惑メール対策 |
| サーバー・データベース | 予約データの保存 | クラウドホスティングを借りる | 月額の目安、契約の名義 |
| 枠組み・部品 | 画面表示の仕組み、日付計算などの部品 | オープンソースを使う | ライセンス表記などの条件 |
決済やログインを外部に任せるのは、手抜きのためではありません。カード情報や認証の仕組みは、専門の事業者が対策を積み重ねている部分で、一から書くと費用が増えるうえに安全面の負担も大きくなります。予算の多くを自前で書く部分に回せるのは、この「借りる」判断があるからです。
一方で、借りる部分にはそれぞれ条件が付いてきます。外部サービスは月額料金や従量課金がかかり、料金体系や規約が変わることがあります。オープンソースの部品は無料で使えても、著作権表示やライセンス文の掲載といった条件があり、詳しくはバイブコーディングで組み込んだOSS、ライセンス表記を忘れると何が起きるかで整理しています。公開後に毎月かかる費用の内訳は個人開発サービスの月額運用費、内訳の目安が参考になります。
フルスクラッチで納品されたら、何が自分のものになる?
自前で書いた部分のプログラムの権利は、契約で決まります。借りた部分は各サービスの規約やライセンスに従って使い続けるもので、納品によって自分の所有物になるわけではありません。
情報処理推進機構(IPA)が公開している「情報システム・モデル取引・契約書(第二版)」では、納入物の著作権の帰属について、開発会社にすべて帰属させる案のほかに、「汎用的な利用が可能なプログラム等」の著作権は開発会社に残し、それ以外を発注者に帰属させる案などを並べています。開発会社が複数の案件で使い回している共通の部品は、発注者に譲らない取り決めがあり得るということです。
自分のサービスにとって大事なのは、次の3つが手元に残るかどうかです。
- 自前で書いた部分のソースコードと、それを使い続け・直し続けられる権利
- 外部サービスのアカウント(決済・メール送信・サーバー・ドメインなど)が、自分の名義になっていること
- データを、自分の判断で書き出せること
2つ目は見落とされやすい点です。開発会社の名義で外部サービスを契約したまま運用が始まると、開発会社を替えたいときに、決済の契約やサーバーの移管で手間取ります。著作権の取り決め方はソースコード著作権譲渡とは。外注時に契約書へ明記すべき3条項で扱っています。
個人の立ち上げで、フルスクラッチを選ぶ条件は?
「独自の判断ロジックや画面の流れがサービスの価値の中心にある」「ノーコードの制約に当たる見込みがある」「需要がある程度確かめられている」の3つがそろったとき、全体をフルスクラッチにする検討を始める時期です。
| 状況 | 向いている作り方の目安 |
|---|---|
| 需要がまだ分からず、まず使ってくれる人がいるか確かめたい | ノーコード、既存SaaSの組み合わせ、または画面のない手作業での提供 |
| 需要は見えてきたが、独自の計算や判断の部分だけがノーコードで再現できない | その部分だけを開発し、残りは既存の仕組みを使う |
| 独自の流れとロジックがサービスの中心で、利用者が増えてもノーコードの料金・性能・制約で困らないか不安がある | 全体のフルスクラッチを検討する |
全体をフルスクラッチにする判断が早すぎると、需要を確かめる前に予算の大半を使うことになります。「試作でどこまで確かめてから外注するか」はPoC・プロトタイプ・MVPの違い。個人の立ち上げで、どこまで作ってから外注するかで整理しています。
逆に、専門職の知識を判断ロジックにしたツールのように、そのロジックがサービスの差別化そのものである場合は、ノーコードで似たものを作っても肝心の部分が再現できないことがあります。その場合は、最初から「ロジックの部分だけ自前で書く」設計を相談先に伝えると、全体をフルスクラッチにするより費用を抑えた提案を受けやすくなります。
見積もりや提案で、何を聞けばいい?
「フルスクラッチで」と書かれた提案には、次の5つを質問として返すと、費用の中身と公開後の負担が見えるようになります。
- 自前で書く部分と、外部サービス・部品を使う部分の一覧をもらえますか(上の表のような粒度で)
- 使う外部サービスの名前と、公開後に毎月かかる費用の目安を教えてください(利用者が増えたときの増え方も)
- 外部サービスのアカウントは、誰の名義で契約しますか
- 納品物の著作権は、どの範囲がこちらに移りますか。御社の共通部品として残るものはありますか
- 将来、別の開発会社に引き継ぐ場合、何を渡してもらえますか(ソースコード、設定情報、データの書き出し方法)
複数の会社から提案を受けている場合は、この5つへの回答を横に並べると、金額の差がどこから来ているかを比べやすくなります。答えが曖昧な項目が多い提案は、契約前に書面で確認してから進めてください。
まとめ:言葉の意味より、「書く部分」と「借りる部分」の線引きを見る
フルスクラッチ開発は、自分のサービス専用のプログラムを書いて作る方式です。実際には外部のサービスや部品と組み合わせて作るため、確認すべきなのは「ゼロから作るかどうか」より、次の線引きです。
- 自前で書くのは、画面の流れと独自の判断ロジック。ここが自分のサービスの価値と合っているか
- 借りる部分には、月額費用・規約・ライセンス・契約名義が付いてくる
- 納品後に手元に残るものは、契約とアカウントの名義で決まる
次に提案書を受け取ったら、上の5つの質問のうち、まず1つ目の「書く部分と借りる部分の一覧」を依頼してみてください。それだけで、提案ごとの金額の差を説明してもらう手がかりになります。




