【2026年版】スクラッチ開発とは?費用・期間・保守で比べる5分類と、作らない判断の基準

「開発会社から『スクラッチになります』と言われたが、何がどこまで自由で、いくらかかるのか分からない」——システムの入れ替えを検討している方から、こうした相談をよく受けます。パッケージとの違いは何か、フルスクラッチとスクラッチは別物なのか、いまどきゼロから作るのは時代遅れではないのか。言葉の定義があいまいなまま見積もりを3社から取ると、金額だけが並んで比べられない、という状態になりがちです。

結論から言うと、スクラッチ開発とは、既製のパッケージやSaaSを前提とせず、要件に合わせてシステムを設計・実装する作り方のことです。そして実務では、フルスクラッチ、ハーフスクラッチ、パッケージ、SaaS、ノーコード/ローコードという5つの選択肢を、初期費用・期間・柔軟性・保守の4つの軸で比べて選びます。スクラッチが正解になるのは、差別化に直結する業務、既製品に合わない業務フロー、拡張の予定、重いデータ量や性能要件のいずれかがある場合に限られます。

この判断を初期費用だけで下すと、ほぼ間違えます。作る側にとって本当の勝負は、リリースした後です。保守費は毎年かかり続け、作った瞬間から技術的負債の管理が始まります。逆に、SaaSの月額はユーザー数と年数で積み上がります。だから比べるべきは5年総額と、「誰が10年面倒を見るか」の2つです。

本記事では、スクラッチ開発の定義とフルスクラッチとの言葉の違い、5つの作り方を4軸で比べた表、向かない条件4つと向く条件4つ、費用と期間の目安・保守と技術的負債、2026年の論点(SaaS普及とAI活用で「作らない判断」が増えたこと)、当社の位置づけ、よくある質問の順に解説します。費用の数字はすべて出典と時点を明記しました。

私は人材業界の出身で、2018年からホーチミンでベトナムオフショア開発の体制づくりに携わり、約100社の相談に乗ってきました。相談で最も多い失敗は2つあり、どちらも「作るかどうか」ではなく「作った後」に原因があります。この記事を読み終えるころには、自社が作るべきか、作るならどの範囲かを判断できるはずです。

スクラッチ開発とは——既製品を前提にせず要件に合わせて作ること。5つの作り方の位置づけ

スクラッチ開発という言葉は、見積書にも提案書にも当たり前のように出てきますが、実際には会社によって指す範囲が少しずつ違います。まず定義をそろえ、そのうえで実務の選択肢が全部でいくつあるのかを並べます。ここを飛ばして金額だけを比べると、同じ言葉で違うものを見積もった3社の数字を並べることになり、判断できません。

定義: 「ゼロから作る」はフレームワークもクラウドも使わないという意味ではない

スクラッチ開発とは、既製のパッケージソフトやテンプレートを前提とせず、要件に合わせてシステムを新規に設計・実装する開発手法です。scratchは英語で「最初から」という意味で、白紙の状態から組み上げることを指します。

ここで誤解が生まれやすいのが、「ゼロから」の範囲です。当社が発注相談で用いている定義では、フレームワークやライブラリなどの既存部品を活用しながら開発することも含めてスクラッチ開発と呼びます。「何も利用せずにすべてを作る」という意味ではありません。実際、認証やデータベース、クラウドの基盤サービスまで自作する案件は、現在ほとんどありません。作るのは、自社の業務ロジックと画面と連携の部分です。

言い換えると、スクラッチ開発で「ゼロから作る」のは、既製品では代替できない自社固有の部分だけです。土台まで自作することではありません。ここを取り違えると、見積もりが実態より大きく見えたり、逆に「フレームワークを使うならスクラッチではないのでは」という不毛な議論になったりします。

フルスクラッチとハーフスクラッチ——言葉の揺れと、見積もり前にそろえるべき定義

もう一つ混乱しやすいのが、「フルスクラッチ」との関係です。実務での使われ方は次の2通りに分かれます。

つまり、フルスクラッチとスクラッチは厳密には濃度の違いですが、実務ではほぼ同義で使われているのが実情です。問題は、どちらの意味で使っているかが会社ごとに違うことです。言葉の使い方は組織やベンダーで異なるため、当社が見積もりの相談を受けるときも、まず「どこまでを独自開発とするか」をすり合わせます。発注前にここを確認しておくと、後の認識違いを防げます。

相見積もりを取る前に、次の3点だけは文面でそろえてください。使用するフレームワークとクラウドサービスを指定するのか任せるのか、認証・決済・帳票などの機能に外部サービスを使ってよいのか、既存システムとの連携は何本を範囲に含むのか。この3点がそろっていない見積もりの比較は、失敗のもとです。

5つの作り方の比較表(初期費用・期間・柔軟性・保守と改修・撤退のしやすさ)

システムを手に入れる方法は、スクラッチとパッケージの2択ではありません。実務では次の5つから選びます。

比較軸は、当社が発注相談で用いている実務上の整理(初期費用・期間・柔軟性・保守と改修・撤退のしやすさ)に、BOSS DESIGN(フルスクラッチ/パッケージ/SaaSの3分類)を突き合わせたものです。数字そのものは次章以降で扱います。

この表で注目してほしいのは、初期費用と柔軟性が逆方向に並んでいるのに対し、「保守と改修」の列だけは単純な高低ではない点です。SaaSは保守の負担が小さい代わりに、機能の決定権を持てません。スクラッチは決定権を持てる代わりに、保守の担い手を自分で用意する必要があります。ここが、後半で扱う判断の中心になります。

5分類は「業務を製品に合わせるか、製品を業務に合わせるか」の一本の軸に並ぶ

5つの選択肢は、バラバラの手法ではありません。「業務を製品に合わせる」か「製品を業務に合わせる」かという一本の軸の上に並んでいます。SaaSは前者の極で、フルスクラッチは後者の極です。パッケージ、ノーコード、ハーフスクラッチはその間にあります。

製品に業務を合わせるほど、初期費用と期間は小さくなります。標準化された業務であれば、これは損ではなく得です。会計、勤怠、経費精算のように成熟した製品がある領域では、自社の運用を製品に寄せたほうが、結果的に業務も整理されます。

逆に、業務のほうがそもそも他社と違い、その違いが売上や原価に直結しているなら、製品に合わせた瞬間に強みを捨てることになります。この場合だけ、費用と期間と保守責任を引き受けてでも作る価値が出ます。つまりスクラッチを選ぶかどうかは、技術の問題ではなく、「自社の業務のどこが他社と違うのか」という事業の問題です。次章では、この問いを向かない条件と向く条件の形に落として、確かめられるようにします。

スクラッチが向く条件4つと、向かない条件4つ——先に向かない条件から確かめる

判断の順番は、向く条件からではなく、向かない条件からです。作るという決定は、いったん動き出すと取り消しにくく、途中で「やはり既製品でよかった」と気づいたときの損失が大きいためです。まず4つの除外条件で落とし、残った案件だけを向く条件で確かめてください。

向かない条件4つ: 標準業務、短期利用、予算と期間が動かせない、社内に判断役がいない

次の4つのどれかに当てはまるなら、スクラッチは選ばないほうが賢明です。

とくに4つ目を軽く見ないでください。要件定義の精度がそのまま成果物の質になるのがスクラッチです。当社が相談を受けた案件でも、決める人が定まらないまま仕様の伝達がずれて実装まで進んだケースほど、手戻りが大きくなっています。決める人がいない状態で始めると、作り直しの費用は要件定義をやり直す費用よりはるかに高くつきます。要注意です。

向く条件4つ: 差別化に直結する業務、既製品に合わない業務フロー、拡張の予定、データ量と性能の要件

上の4つに当てはまらなかった案件を、次の4条件で確かめます。1つでも強く当てはまれば、スクラッチが選択肢に入ります。

BOSS DESIGNは、フルスクラッチを選ぶべきケースとして「既存のSaaSやパッケージを複数試したが業務フローに合うものがなかった」「業界特有のルールや独自の業務ロジックがある」「複数システムとのデータ連携が必要」「長期的に使い続け、外部サービスへの依存を避けたい」の4点を挙げています。4条件はこれと概ね一致します。

なお、セキュリティを理由に挙げる企業もあります。金融・医療・行政のようにデータの保管場所や権限設計を自社で完全に管理したい領域では、これは正当な理由です。ただし「スクラッチだから安全」ではなく、設計と運用で決まります。作り方を選んだだけで安全になるわけではない、という点は誤解されやすいところです。

判断を数で確かめる——カバー率、連携本数、SaaSの年額、利用年数

条件は言葉だけだと社内で揉めます。稟議に載せるなら、次の4つの数字で確かめてください。

• 既製品のカバー率: 候補のSaaSやパッケージを実際に試し、業務プロセスの何割を標準機能で回せるかを数える。当社は「現場が毎日使う業務のうち、標準機能では回せないものがどれだけ残るか」を見ています。残る業務が多いほど、作る側に傾きます
• 連携の本数: 既存システムや外部サービスと何本つなぐ必要があるか。標準コネクタで足りない連携が複数あるほど、作る側に傾きます
• SaaSの年額合計: 現在使っている、または使う予定のSaaSのライセンス費を年額で合計する。ユーザー数が増えるほど積み上がるので、想定利用年数分を掛けて、スクラッチの初期費用と保守費の総額と並べてください
• 想定利用年数: 3年で捨てるのか、10年使うのか。利用年数が長いほど、初期費用の差は相対的に小さくなります

この4つを数えると、「なんとなく作りたい」なのか「作らないと成立しない」なのかが、社内の誰にでも見える形になります。

私が見てきた失敗に共通する2つ——既製品で足りる業務まで作った、保守要員を決めずにリリースした

私は2018年からホーチミンで約100社の開発体制の相談に乗ってきましたが、スクラッチで後悔した相談には共通点が2つあります。1つ目は「既製品で足りる業務まで作ってしまった」ケースです。独自の受発注ロジックを作るところまではよかったのに、ついでに勤怠と経費精算も同じシステムに入れてしまい、機能の8割が市販のSaaSと同じものになった。保守対象だけが増え、差別化には1円も寄与しません。

2つ目は「保守要員を決めずにリリースした」ケースです。作るところまでは予算が付いたが、リリース後の改修体制を決めないまま開発会社との契約が終わり、半年後に法改正対応が必要になって慌てて相談に来られる。見積もりは、継続契約していた場合の何倍にもなります。作る判断そのものより、作った後に誰が面倒を見るかの設計で失敗が決まる、というのが私の実感です。次章では、その「作った後」の費用と体制を具体的に見ていきます。

費用と期間の目安、保守と改修、技術的負債——「作った後」で判断が決まる

ここからは数字の話です。ただし、初期費用だけを見て決めると判断を誤ります。スクラッチで手に入るのは完成品ではなく、保守と改修を続ける前提の資産だからです。まず金額が決まる仕組みを押さえ、次に保守費と技術的負債、最後に契約形態の選び方を見ていきます。

規模別の費用と期間——金額が決まる仕組みと前提のそろえ方

規模別の費用と期間について、公開された一次統計は存在しません。他社のオウンドメディアが独自に集計した相場は出所をたどれないため、本記事では金額の目安を示しません。代わりに、金額が決まる仕組みと、前提のそろえ方を示します。

「中規模」と言っても、画面数で区切るか業務の複雑さで区切るかで金額は変わります。見積もりを取るときは、金額より先に「何画面・何連携・非機能要件はどこまで」という前提をそろえてください。前提が違う見積もりは、安いほうが安いとは限りません。

費用の大部分は人件費(人月)です。したがって、体制の人数と期間が決まれば費用はおおよそ決まります。この構造を理解しておくと、「なぜ相見積もりで2倍違うのか」も説明がつきます。人月単価と、想定している工数の前提がどちらも違うからです。

保守費は毎年かかり続ける——初期費用ではなく5年総額で比べる

スクラッチで作ったシステムは、リリースした日から保守が始まります。バグ修正、OSやライブラリのセキュリティ更新、法改正対応、軽微な機能追加。ノーコード総合研究所(2026年6月)は、運用後に月額数万円〜数十万円の保守費が発生すると説明しています。金額は保守の範囲(監視の有無、対応時間、機能追加の枠を含むか)で大きく変わるため、契約前に範囲と年額を見積書に書き出させてください。

これを5年総額に置き換えると、判断は変わります。初期費用に毎年の保守費が5年分積み上がるからです。一方でSaaSは初期がほぼ0でも、月額が5年間積み上がります。どちらが安いかは、ユーザー数と利用年数と、既製品でカバーできない業務の量で決まります。初期費用の比較だけで結論を出すのは、失敗のもとです。

なお、保守費を削ると短期的には安く見えますが、更新が止まったライブラリは数年後にまとめて跳ね返ります。削ってよいのは機能追加の枠であって、セキュリティ更新の枠ではありません。

技術的負債とは何か——放置すると改修費が上がり、作り直しが視野に入る

技術的負債とは、その場をしのぐ設計や実装を選んだ結果、あとから支払うことになる追加コストのことです。納期に追われて場当たり的に分岐を足す、ドキュメントを残さない、テストを書かない、古いバージョンのまま更新しない。どれも短期的には速く、長期的には改修のたびに時間を食います。

スクラッチで負債が積み上がる典型は、次の3つです。

負債は避けられませんが、管理はできます。管理していないシステムは、5年目あたりで「改修より作り直しのほうが安い」という結論に到達しがちです。そうならないために、保守を「あとで考えること」にしないでください。

契約形態で保守は変わる——請負で作り切るか、準委任で持ち続けるか

保守の担い手は、契約形態で実質的に決まります。請負契約は成果物に対価を払う形なので、完成して検収したら関係はいったん終わります。要件が固まっていて、リリース後の改修が少ない案件には合います。

一方、準委任契約は稼働に対価を払う形なので、要件が動くことを前提に、優先順位を見直しながら開発と保守を続けられます。スクラッチのように「作って終わりではない」作り方には、こちらが構造的に合います。契約の違いそのものは「準委任 請負 違い」の記事で詳しく扱っていますが、ここでは「作る前に、作った後の契約形態まで決めておく」とだけ覚えてください。あなたのシステムは、1年後に誰が直すことになっているでしょうか。

2026年の論点——SaaS普及とAI活用で「作らない判断」が増えた。それでもスクラッチが選ばれる理由

「スクラッチ開発はもう時代遅れではないか」。社内で作る提案をすると、必ずこの反論が出ます。結論を先に言えば、時代遅れではありません。ただし、この批判には正確な観察が含まれています。減ったのは事実で、減った領域がはっきりしている、というのが2026年の実態です。

汎用業務のスクラッチが減った4つの理由

汎用業務のスクラッチが減っている理由は、当社が受ける相談の傾向から4つに整理できます。

つまり、減ったのは「汎用業務を最初からスクラッチで作る」という選択です。差別化に関係のない業務まで作っていた時代が終わった、と言い換えたほうが実態に近いでしょう。

AI活用で変わったこと・変わらないこと——速くなったのは実装、変わらないのは決める仕事

2026年のもう一つの変化が、生成AIによるコーディング支援です。定型的なコードの記述が自動化され、スクラッチの最大の弱点だった「遅い・高い」が縮小しました。当社もAIを活用した開発体制を標準にしており、実装工程にかかる時間は明らかに短くなっています。

一方で、変わっていないこともあります。何を作るかを決める仕事、要件を言語化する仕事、設計の良し悪しを判断する仕事です。実装が速くなったぶん、上流の判断がボトルネックとして前面に出てきた、というのが現場の感覚です。同じ記事も「アーキテクチャ設計や要件定義の品質がますます重要になっており、開発会社の技術力の差が開く傾向にある」と書いています。

したがって、「AIで安くなったから作ろう」は半分だけ正しい判断です。実装の費用は下がりましたが、決める負担は下がっていません。前章の「向かない条件4つ」のうち、社内に判断役を置けないケースが依然として除外条件のままなのは、このためです。

それでもスクラッチが選ばれる4領域と、「コア=スクラッチ、周辺=SaaS」の現実解

減った領域がある一方で、スクラッチの重要性が増した領域もあります。整理すると次の4つです。

• 競争優位の核になるシステム。競合と同じSaaSを使っている限り、システム面での差別化はできません
• 複雑な業務ロジックと、標準APIでは対応できない複数システムとの連携
• データの保管場所や権限設計を自社で管理する必要がある領域(金融・医療・行政など)
• 長期運用が確実で、SaaSの月額が積み上がるほど総額で不利になる規模

そして2026年の現実解は、全部作るか全部借りるかの二択ではありません。競争優位を生む部分だけをスクラッチで作り、汎用的な部分はSaaSと連携させる、という組み合わせです。当社の相談でも、「基幹はSaaSのまま、独自の受発注と在庫連動だけを作る」という形が増えています。

言い換えると、2026年に問われているのは「作るか作らないか」ではなく、「どこまでを作るか」です。この線引きができる会社を選ぶことが、技術力そのものより効く場合があります。

当社の位置づけ——ラボ型(準委任)でスクラッチの継続開発を担う

ここまでの整理を踏まえて、当社がどこを担う会社なのかを書いておきます。当社TALENTBASE VIETNAMは、ベトナム・ホーチミンを拠点に、月額固定で専属チームを持つラボ型(準委任)の開発体制を提供しています。スクラッチは作って終わりではないため、優先順位を毎週見直しながら開発と保守を続ける形と構造的に相性がよい、というのが当社の立ち位置です。

実績: ヘッドレスCMSのWebサイト、求人プラットフォーム(ATS)、決済アプリ

スクラッチに該当する当社の実績を挙げます。ヘッドレスCMSを用いたWebサイトの構築、採用管理(ATS)を備えた求人プラットフォーム、Stripe連携・二要素認証・ウォレット・PDF出力を備えた決済アプリ。決済アプリは新規開発からそのまま週次の保守に移行しています。ほかに、LLMを用いた24時間対応のAIチャットボットも手がけています。

継続開発の例として分かりやすいのが、介護記録SaaS「CareViewer」です。日本語対応のブリッジSE1名とフルスタックエンジニア2名の体制で、要件が動き続けるSaaSを週次の優先順位判断で開発しており、コストは従来の半分以下になりました。「想像以上にエンジニアのレベルが高い」という評価をいただいています。いずれも、前章までに書いた「差別化に直結する」「拡張の予定がある」に当たる案件です。

体制・単価・最小構成と、品質を仕組みで担保する3点

当社は2,000名以上のIT人財データベース(日本語N1〜N2相当を含む)から直接アサインします。協力会社や紹介を経由しないため、仲介マージンが乗りません。公開単価は、実務3年目安で1,500USD(約22.5万円)、5年で2,000USD、10年・ブリッジSEで3,000USDです(1USD=150円換算目安)。当社調べで市場相場の約1/2にあたります。

体制はパターンA(日本人PM/ブリッジSE+エンジニア・推奨)とパターンB(エンジニアのみ)の2つで、1名から契約できます。最小構成は日本人PMをフロントに置いて2〜3人月、月額約80万円からです。開始は最短2週間、増員は約1週間、縮小と交代は1か月単位で調整します。契約と支払いは日本国内法人・日本法準拠で、海外送金は不要です。

品質は人ではなく仕組みで担保します。日本人PMによる設計レビュー、Gitのプルリクエストによるコードレビューの標準化、リリース前のダブルチェックの3点です。前章で挙げた技術的負債のうち、設計の負債と属人化の負債は、この3点で抑えにいきます。AWS認定11冠のメンバーが在籍し、AIを活用した開発体制を標準にしています。

当社が向かないと判断する案件

正直に書きます。次のような案件では、当社は受けるより先に別の選択肢をお勧めしています。会計や勤怠のように既製のSaaSで足りる業務、数週間で作って捨てる検証用のツール、予算と納期が1円・1日も動かせない案件、そして社内に優先順位を判断する担当を置けない案件です。最後の1つは、体制側が日本人PMを立てても、事業上の優先順位までは代わりに決められないためです。

自社の案件がどこに当たるか、判断に迷っていませんか。

スクラッチ開発でよくある質問

スクラッチ開発について、相談の場で繰り返し聞かれる質問を5つにまとめました。社内での説明にもお使いください。

Q1. スクラッチ開発とフルスクラッチ開発は何が違いますか?

実務ではほぼ同義で使われます。厳密には、フルスクラッチが既製部品の利用を極力避ける作り方、ハーフスクラッチがフレームワークや一部の既製部品を土台にする作り方を指し、その総称がスクラッチ開発です。会社ごとに使い方が違うため、見積もりの前に「どこまでを独自開発とするか」を文面でそろえてください。

Q2. スクラッチ開発は最低いくらから依頼できますか?

国内開発の金額は、公開された一次統計がないため本記事では示していません。当社のようなラボ型で継続的に開発する場合は、日本人PMフロント+2〜3人月の最小構成で月額約80万円からになります。要件が動く前提なら、総額ではなく月額で考えたほうが実態に合います。

Q3. 開発期間はどのくらいかかりますか?

期間は規模と、要件定義にかける時間で決まります。規模別の目安は本文の費用表に出典つきで挙げているので、自社の規模に当てはめてください。AIによるコーディング支援で実装工程は短縮されていますが、要件定義と設計にかかる時間はあまり変わりません。急ぐ場合は、機能を削るのではなく、リリースを分割して優先度の高い機能から出す進め方をお勧めします。

Q4. 作った後の保守は誰が担当するのですか?

契約で決めます。請負で作り切る場合は検収後に関係が終わるため、別途で保守契約を結ぶ必要があります。準委任(ラボ型)で継続する場合は、同じチームが改修と保守を続けます。保守費は契約に含める範囲で大きく変わるので、年額で見積書に書き出させてください。作る前に保守の担い手を決めておかないと、法改正や障害のたびにスポットの見積もりを取ることになります。

Q5. いま使っているSaaSからスクラッチに乗り換えられますか?

可能ですが、全面移行より部分移行をお勧めします。SaaSで足りている業務はそのまま残し、既製品では吸収できない独自の業務だけをスクラッチで作ってAPIでつなぐ形です。乗り換えの判断材料は、既製品のカバー率、連携の本数、SaaSの年額合計、想定利用年数の4つ。移行時に最も手間がかかるのは機能の再現ではなく、データ移行と権限設計。

まとめ: 言葉をそろえ、向かない条件から確かめ、作るなら保守まで含めた体制を先に決める

スクラッチ開発とは、既製のパッケージやSaaSを前提とせず、要件に合わせてシステムを設計・実装する作り方です。フレームワークやクラウドサービスは使うので、「すべてを自作する」という意味ではありません。フルスクラッチとスクラッチは実務ではほぼ同義で使われるため、相見積もりの前に「どこまでを独自開発とするか」を文面でそろえてください。実務の選択肢は、フルスクラッチ、ハーフスクラッチ、パッケージ、SaaS、ノーコード/ローコードの5つで、これらは「業務を製品に合わせるか、製品を業務に合わせるか」という一本の軸に並びます。

判断は、向く条件より先に向かない条件から確かめます。業務が標準的、利用期間が短い、予算と期間が動かせない、社内に優先順位を判断する担当を置けない——このどれかに当たるなら作らないほうが賢明です。残った案件を、差別化に直結する業務、既製品に合わない業務フロー、拡張の予定、データ量と性能の要件という4条件で確かめ、既製品のカバー率・連携の本数・SaaSの年額・想定利用年数の4つの数字で裏づけてください。費用と期間は規模で変わるため、本文に出典つきの目安を挙げています。自社の規模に当てはめたうえで、毎年かかり続ける保守費を上乗せしてください。初期費用ではなく5年総額で比べるのが実務です。

2026年の論点は「時代遅れかどうか」ではなく「どこまでを作るか」です。SaaSとローコードの成熟、AI活用による実装の高速化で、汎用業務を作る理由は確かに減りました。それでも差別化の核、複雑な連携、データ主権、長期運用の4領域では選ばれ続けています。当社はラボ型(準委任)で、ヘッドレスCMSのWebサイト、求人プラットフォーム(ATS)、決済アプリといったスクラッチの継続開発を担っています。1名から、日本人PMフロント+2〜3人月の最小構成で月額約80万円からです。開発体制の考え方はラボ型開発とは、内製と外注の比較はシステム開発は内製か外注かもあわせてご覧ください。現在の体制と要件をお聞かせいただければ、作るべきかどうかの判断と概算見積もりでお答えします。合わない案件にはその旨も率直にお伝えします。