「パッケージで済むのか、スクラッチで作るべきか」
社内システムの刷新を検討するとき、多くの担当者がこの問いに直面します。スクラッチ開発とは、既存のパッケージソフトを使わずゼロから構築する手法で、自由度が高い反面、セキュリティ基準の策定や脆弱性診断を含む運用責任のすべてが自社にかかります。
本記事では、スクラッチ開発の基本からメリット・注意点、セキュリティ対策まで整理します。脆弱性診断の進め方で迷っている場合は、無料相談もご活用ください。
「スクラッチ開発」という言葉は広く使われますが、「フルスクラッチ」や「パッケージ開発」との違いがよくわからないまま話が進むことも多いです。まずここで用語の意味を整理しておきましょう。
スクラッチ開発とは、既存のソフトウェアをベースにするのではなく、一から新しく開発する手法です。フレームワークやライブラリは活用しつつ、自社の要件に合わせてゼロから設計・構築していきます。
この2つは現場では同じ意味で使われることも多いですが、厳密には少し違います。スクラッチ開発はフレームワークやライブラリを活用しながら新規に開発する手法。一方のフルスクラッチは、フレームワークや業務パッケージといった既存の部品にできるだけ頼らず、業務ロジックを独自に実装していくアプローチです。
つまり、フルスクラッチはスクラッチ開発の中でもとくに制約が厳しいケースです。実際の業務システム開発でフルスクラッチが選ばれることはあまり多くなく、ふつう「スクラッチ開発」と言えばフレームワークを使った新規開発を指すことがほとんどです。
パッケージ開発は、すでに完成しているソフトウェアをカスタマイズしてシステムを仕上げる手法です。スクラッチ開発との最大の違いのひとつが、セキュリティ管理をどちらが担うかという点です。
| 比較軸 | スクラッチ開発 | パッケージ開発 |
|---|---|---|
| 自由度 | 業務フローに完全適合可能 | パッケージ仕様の範囲内 |
| 初期コスト | 高い（全工程を新規構築） | 低〜中（設計・製造工数が少ない） |
| 開発期間 | 長い（数ヶ月〜数年規模） | 短い（数週間〜数ヶ月） |
| セキュリティ管理責任 | 自社（または委託先）が全面的に担う | パッケージ提供元が主体的に対応 |
| 拡張性 | 設計次第で柔軟に対応可能 | 提供元のロードマップに依存 |
| 脆弱性の検知 | 自社で能動的に把握する必要がある | 提供元の情報公開に依存できる |
| パッチ・修正の提供 | 自社（委託先）が都度実装 | 提供元が提供。ただし適用は利用側の責任 |
| 依存部品の管理 | フレームワーク／ライブラリの脆弱性管理が必要 | 提供元の管理範囲に含まれることが多い |
とくにセキュリティ管理の差は、運用フェーズのコストに直接影響します。パッケージならベンダーが脆弱性パッチを出してくれますが、スクラッチは新しい脅威が見つかるたびに自社で判断・対応しなければなりません。
コストも期間もかかるのに、なぜスクラッチ開発が選ばれるのか。パッケージでは「だいたい合っている」止まりになってしまう場面で、自社の業務やセキュリティ要件を設計にそのまま落とし込めることが大きな理由です。
スクラッチ開発の一番の強みは、自社の業務プロセスをそのまま形にできることです。パッケージでも設定変更やカスタマイズはできますが、どうしても対応できる範囲に限りがあります。独自の承認フローや複雑な料金計算ロジックなど、「うちの業務はパッケージに合わせられない」という場合に、スクラッチ開発が現実的な選択肢になります。
逆に、業務フローをシステム側に寄せることができるなら、このメリットはあまり活きません。「自社の業務は変えられるかどうか」がまず最初の判断ポイントです。
金融・医療・官公庁向けのシステムなど、業種ならではの厳しいセキュリティ要件がある場合、スクラッチ開発には明確な強みがあります。認証方式、アクセス制御、データ暗号化の細かさといった要件を、設計の段階から最初に組み込んでおけるからです。
パッケージは提供元の仕様に縛られるため、「この認証方式を変えたい」「ログの取得範囲を調整したい」といった細かい要望に対応できないことがあります。スクラッチなら、自社のセキュリティポリシーをシステムの設計そのものに織り込めます。大事なのは後付けでなく、最初から設計に入れること。セキュリティは実装後に足すより、最初から考えておくほうが品質も工数も段違いです。
ただし、自由に設計できることは「自前で正しく実装する責任を負う」ことの裏返しでもあります。とりわけ認証・セッション管理・暗号化といった領域は、独自実装すると深刻な脆弱性を作り込みやすい部分です。スクラッチ開発の強みは「ゼロからすべてを書くこと」ではなく、信頼できる部品を自社のセキュリティポリシーに合わせて適切に組み合わせ・配置できることにあると捉えるのが適切です。
スクラッチで作ったシステムは、パッケージベンダーのサービス終了や値上げに振り回されません。将来の機能追加や他システムとの連携も、設計次第で柔軟に対応できます。ただし、これは「継続して改修できる体制がある」ことが前提です。社内にエンジニアがいる、または信頼できる外部ベンダーと保守契約を結んでいないと、リリース直後から老朽化が進みます。長く使えるメリットは、保守体制の整備とセットで考えましょう。
なお、スクラッチ開発でも陳腐化しないわけではありません。採用したフレームワークや言語のバージョンにはサポート期限（EOL）があり、放置すればセキュリティパッチが提供されなくなります。長く使うには、依存部品のアップデート追従を含めた保守計画が欠かせません。
メリットが大きい分、スクラッチ開発にはそれなりのコストとリスクが伴います。「コスト・期間が膨らむ」「ベンダー選びが難しい」はよく言われますが、見落とされがちなのがセキュリティリスクを自社で抱えることです。この3点をあらかじめ把握しておくと、導入判断がしやすくなります。
それぞれのポイントを見ていきましょう。
コストも期間もかかるのは、要件定義・設計・製造・テストのすべてを新規に行うからです。パッケージなら設計や製造の多くはテンプレートで進みますが、スクラッチは本当に白紙からのスタートです。
スピードが重要な事業や、半年以内にリリースしたい案件には向きません。「予算と時間に余裕がある」ことを前提に検討するのが現実的です。
スクラッチ開発の出来栄えは、担当する技術者・ベンダーの力量に大きく左右されます。
この3つの軸でしっかり見極めることが大切です。
契約の面でも気をつけたいことがあります。スクラッチ開発で作ったシステムの著作権は、契約書に書いておかないと開発会社側のものになります。「著作権の帰属」を明記して自社に移転する条文を盛り込んでおきましょう。発注してから気づいても、後から交渉するのはなかなか難しいです。
パッケージを使っている場合、脆弱性のパッチ対応はベンダーがやってくれます。でもスクラッチ開発では、新しい脆弱性が見つかっても誰も自動で対応してくれません。脆弱性への対処・セキュリティ基準の策定・診断の実施まで、すべて自社（または委託先）が判断して動く必要があります。
セキュリティ対策が不十分なままリリースされることも、実際には起こり得ます。Webアプリケーションを狙った攻撃は継続的に発生しており、SQLインジェクションやクロスサイト・スクリプティングといった脆弱性は、スクラッチ開発のシステムでも作り込まれてしまうことがあります。重要なのは、脆弱性は「見つかってから対応する」よりも「そもそも作り込まない」ことです。SQLインジェクションやクロスサイト・スクリプティングの多くは、設計・実装段階のセキュアコーディング（プレースホルダによるクエリ発行、出力時のエスケープ処理など）で防げます。スクラッチ開発では、こうした開発工程でのセキュリティ施策と、リリース前の脆弱性診断をプロセスに組み込んでおくことが、結果的に費用対効果の高い対策になります。
スクラッチ開発を選ぶなら、セキュリティ対策のコストを最初の見積もりに含めておくことが欠かせません。
ここまでのメリット・注意点を踏まえて、「自社の案件はどちらが向いているか」を判断するための軸を整理します。選び方を間違えると後からコストが膨らむので、ここはじっくり確認してください。
| 判断軸 | スクラッチが向くケース | パッケージが向くケース |
|---|---|---|
| 業務フロー | 独自性が高く、変更が難しい | 標準的で、パッケージ仕様に合わせられる |
| セキュリティ要件 | 業種固有の厳格な要件がある | 一般的な要件で対応可能 |
| 予算・期間 | 比較的余裕がある | 制約が強い |
| 機能追加の見込み | 頻繁な機能追加が想定される | リリース後の変更が少ない |
| 開発・保守体制 | 社内または信頼できるベンダーがある | 保守体制を持ちにくい |
| セキュリティ責任 | 自社で対策・運用を担える体制がある | 提供元に委ねたい／自社で抱えたくない |
なお、最近はローコード開発プラットフォームも現実的な選択肢のひとつです。画面操作やテンプレートを活用しながら、複雑な部分だけコードで実装できるため、スクラッチのメリットを残しつつコストや期間を抑えられる場面があります。「フルスクラッチでなくても実現できるかも」という視点で、ローコードも候補に入れて検討してみてください。
ただしローコードを選ぶ際は、セキュリティ責任の所在に注意が必要です。プラットフォーム基盤の脆弱性対応は提供元が担う一方、画面・データの権限設定やアクセス制御は利用側の責任になることが多く、設定の不備がそのまま情報漏えいにつながります。また、業種固有の厳格なセキュリティ要件がある場合は、プラットフォームの仕様で実現できる範囲に限界があり、結局スクラッチが適することもあります。ローコードは「要件を満たせる範囲かどうか」を見極めたうえで候補に入れるのが現実的です。
スクラッチ開発は基本的に5つの工程で進みます。各工程でどんな判断が必要かをあらかじめ知っておくと、ベンダーへの説明や社内調整がずっとスムーズになります。
| 工程 | 内容 | ポイント |
|---|---|---|
| ① 要件定義 | システムに必要な機能・性能・制約を整理する | セキュリティ要件（認証方式・アクセス制御・データ保護方針）もこの段階で決める。要件定義の精度がその後の品質をほぼ決める |
| ② 基本設計・詳細設計 | 要件をもとにシステムの構造を設計する | アーキテクチャ、データベース、画面、外部システムとの接続方法などを確定させる。認証・認可やデータ保護の方式もここで具体化し、どこにどんな脅威が想定されるかを洗い出しておくと、後工程での手戻りを防げる |
| ③ プログラミング | 設計書をもとに実際のコードを書く | 並行開発する場合は、コードレビューやブランチ管理のルールをきちんと決めておくことが品質に直結する。あわせて、SQLインジェクションやXSSを防ぐセキュアコーディング規約を定め、レビュー観点に含めておく |
| ④ テスト | 単体・結合・システム・ユーザー受け入れの順でテストを行う | このフェーズに脆弱性診断を組み込んでおくと、外部公開前にセキュリティ上の問題を見つけられる（詳しくは次章） |
| ⑤ リリース・運用保守 | 本番環境に展開し、継続的に運用・改修を行う | 新機能追加やインフラ変更のたびにセキュリティの状態を確認する体制が必要。リリースは「終わり」ではなく、セキュリティ管理が本格的に始まるタイミング |
スクラッチ開発において、セキュリティ対策は「あとで考えればいいもの」ではありません。パッケージと違い、セキュリティ基準の策定から脆弱性診断の実施まで、自社が主体的に動かなければならない領域です。ここをあいまいにしたまま進めると、リリース後に思わぬリスクに直面することがあります。
パッケージ製品なら、ベンダーが定期的にセキュリティパッチを出してくれます。利用者は適用するだけでよく、脆弱性の「発見」も「対応」もベンダーが主体です。
スクラッチ開発では、この構造がまったく変わります。自社のシステムに脆弱性があっても、誰かが勝手に見つけて直してくれることはありません。発見・評価・修正の判断から診断の手配まで、すべてが自社の仕事になります。
Webアプリケーションへの脆弱性の届出は継続的に発生しており、クロスサイト・スクリプティングやSQLインジェクションといった脆弱性はスクラッチ開発のシステムにも入り込んでしまうことがあります。
「作って終わり」ではセキュリティは守れない。そういう前提でプロジェクトを設計することが必要です。
※参考：IPA｜ソフトウェア等の脆弱性関連情報に関する届出状況〔2025年第4四半期〕
脆弱性診断とは、システムに疑似的な攻撃を仕掛けてセキュリティ上の問題を見つけ出す検査です。代表的な手法のひとつが動的アプリケーションセキュリティテスト（DAST）で、システムを実際に動かした状態で外部からリクエストを送り、脆弱性を検出します。
診断の観点として広く参照されているのが、OWASP（オープンウェブアプリケーションセキュリティプロジェクト）が定めたOWASP Top 10です。これはWebアプリケーションで重大とされるリスクをカテゴリ別に整理した文書で、インジェクション・認証の不備・アクセス制御の欠陥などが代表的な項目です。数年ごとに改訂されるため、参照する際は最新版を確認するとよいでしょう。
スクラッチ開発では、こうした観点を漏れなくカバーできる診断の設計が重要です。
診断の方法には、ツールによる自動検査と、専門家が手動で確認するコンサルティング型の2種類があります。ツール診断はコストを抑えつつ広い範囲をカバーでき、コンサルティング型はツールでは見つけにくいビジネスロジック上の脆弱性にも対応できます。スクラッチ開発のシステムは独自ロジックを持つことが多いので、状況によっては両方を組み合わせるのが有効です。
「一度診断を受ければ大丈夫」という考え方は、現実には通用しません。スクラッチ開発のシステムで脆弱性診断が必要なタイミングは、大きく3つあります。
1つ目は設計・実装フェーズ（シフトレフト）です。
最近では、テスト工程にまとめて診断するのではなく、設計レビューや実装中のコードチェックなど、上流工程からセキュリティ対策を組み込む「シフトレフト」の考え方が広まっています。スクラッチ開発はゼロから設計できる分、最初から脆弱性を作り込まない設計が可能で、シフトレフトとの相性が良い手法です。後工程で見つかるほど修正コストが大きくなるため、早い段階で潰せる脆弱性は早く潰すのが理想です。
2つ目はリリース前（外部公開の直前）です。
テストフェーズの後半、本番公開の前に診断を実施して残った脆弱性を潰します。シフトレフトで上流から手を打っていたとしても、最終的な仕上がりの確認として、このタイミングでの診断は欠かせません。公開後に問題が発覚するリスクを大きく下げられます。
3つ目は運用フェーズでの定期診断です。
新機能の追加、外部APIとの連携拡張、インフラ構成の変更といったタイミングで、新たな脆弱性が生まれることがあります。機能追加の頻度が高いシステムなら、変更のたびに診断する体制が理想です。スクラッチ開発の拡張しやすさはメリットですが、それはつまり「変更のたびにセキュリティ状態が変わる可能性がある」ということでもあります。
スクラッチ開発は、自社の業務フローに完全に合わせたい場面や、独自のセキュリティ要件がある場合に力を発揮する選択肢です。ただし、自由度が高い分、設計・開発・運用のすべてにわたる責任が自社にのしかかります。なかでもセキュリティ管理は、パッケージとは根本的に異なる自社主体の動きが必要です。
採用を判断するときに確認したいのは3つです。
この3点が揃わない場合は、ローコード開発やパッケージ導入も視野に入れて再検討してみてください。
スクラッチ開発を進めるなら、設計フェーズから脆弱性を作り込まない「シフトレフト」の発想と、リリース前・運用中の継続的な脆弱性診断を組み合わせて計画に組み込むことが大切です。開発手法を決めるのと同じタイミングで、セキュリティ対応の計画も具体化しておくのが、スクラッチ開発をうまく進めるためのシンプルで確実な一歩です。
「どの手法が自社に合っているかわからない」という段階でも、 2007年設立のセキュリティ専門企業、ユービーセキュアでは、Webアプリケーション脆弱性検査ツール「Vex」、専門家による脆弱性診断サービス、内製化支援を組み合わせて提供しており、無料相談から気軽に始めることができます。お気軽にお問合せください。