AIでスクラッチ開発とERP、どちらを選ぶべきか｜「作れる」提案を受けたときの5つの判断軸

「AIで作れば、パッケージより安く済むはずだ」

生成AIの話を聞いた経営者の多くが、まずこう考えます。

提案書の見積もりも、たしかに安く見えます。

ただ、その安さは「作り終えるまで」の安さです。

スクラッチ開発とは、既製の製品を使わず、自社の業務に合わせてシステムを一から作ることです。

生成AIで作る作業が速くなり、「御社専用のシステムを作れます」という提案が増えました。

答えの核は、「全部作る」か「全部買う」かの二択にしないことです。

会計・販売・在庫・購買の基幹業務はパッケージERPを軸にし、自社の強みそのものの業務は作ることを検討します。

では、目の前の1件をどちらに振り分ければよいのか。

その物差しが、この先の5つの判断軸です。

提案が増えた結果、社内のシステムが増えすぎるという別の論点もあります。

そちらはAIで「作れる」時代の落とし穴で扱っています。

この記事で分かること

• スクラッチ開発が向いているケースと、その見分け方
• 「作る」と「買う」を分ける5つの判断軸
• 業務ごとに「標準に合わせる／開発する／残す」を決める線の引き方
• 選定段階でよくある4つの判断ミス
• すでに作った会社が、いま決めておくこと

言葉の整理：ERP（Enterprise Resource Planning）は、会計・販売・在庫などの基幹業務をまとめて管理する仕組みです。

パッケージは、多くの会社が使えるように作られた既製の製品のことです。

「AIで作れます」という提案が増えている

なぜ、いま増えているのか

生成AIの登場で、コードを書く作業そのものが速くなりました。

以前なら数人がかりで数か月かかった規模のものが、少人数で形になります。

試作までなら、驚くほど短い期間で届きます。

これまで「予算的に無理」とされた自社専用のシステムが、選択肢に入ってきました。

選べる幅が広がったこと自体は、歓迎してよい変化です。

困るのは、選び方の物差しが追いついていないことです。

二択で決めると誤りやすい

「全部を作る」か「全部を買う」か。

この二択にすると、どちらかで無理が出ます。

現実的なのは、領域ごとに分けることです。

• 基幹業務（会計・販売・在庫・購買）：パッケージERPを使う
• 自社の競争力の源泉になっている業務：作ることを検討する

先に書いておく｜スクラッチが向いているケース

ERPを扱う立場から、作ったほうがよいケースを先に挙げます。

ここを曖昧にしたままでは、公平な材料になりません。

4つのケースを図にすると、次のとおりです。

その業務が、自社の競争力そのものである場合

他社と違うやり方をしているから勝てている。そういう業務があるはずです。

独自の配車ロジック、独自の見積もり算定、独自の品質判定。

こうした領域を標準の仕組みに合わせると、強みを手放すことになります。

作る価値がいちばん高いのは、ここです。

パッケージが存在しない領域である場合

業界が特殊で、そもそも該当する製品が市場にない。

この場合は、探し続けるより作るほうが早いことがあります。

影響範囲が小さく、業務として閉じている場合

一部門だけで完結し、他の業務とデータをやり取りしない。

こうした小さな業務なら、作って動かし、合わなければ捨てる進め方が成り立ちます。

生成AIの恩恵がいちばん出やすいのも、この規模です。

作った後を担える体制が、社内にある場合

4つの中で、いちばん外せない条件です。

作ることと、動かし続けることは別の仕事です。

後者を担える人と予算が社内にあるなら、作る選択は現実的になります。

どれかに当てはまるなら、ベンチャーネットは「作ってみてはいかがでしょうか」とお伝えします。

ERPを勧めることが仕事だとは考えていません。

「作る」と「買う」を分ける5つの判断軸

5つとも、技術の話ではありません。

経営として判断できる論点です。

軸1：初期コストの見え方｜安いのは「作り始め」だけ

何を見る軸か：最初の見積もりの額より、見積もりにどこまで入っているかを見ます。

スクラッチ開発の提案は、初期費用が安く見えることが多くあります。

見積もりの範囲が「動くものを作るまで」に限られているためです。

テスト環境の維持、障害対応、機能追加、担当者の引き継ぎの費用は入っていません。

パッケージの利用料には、これらの一部が最初から含まれています。

だから額面が大きく見えます。

たとえばNetSuiteは、ミニマム構成で月額20万円〜が出発点です。

モジュール・ユーザー数・オプションの構成で変わり、数百万円規模になることもあります。

パッケージを入れる場合も、費用の大半を決めるのは導入の中身です。

NetSuite認定パートナー（Solution Provider）であるベンチャーネットは、差を生む要因を4つに分けて見ています。

機能範囲、開発（特に外部システムとの連携）、社内の体制、ユーザー数です。

情報システムの担当が少ない会社では、支援を厚くする分、期間も延びやすくなります。

2つ目の「開発」は、スクラッチ開発と同じ性質の費用です。

パッケージに足す開発が増えるほど、作る場合と同じ負担が戻ってきます。

判断のポイント：比べるのは、初期費用ではなく5年分の総額です。

この考え方をTCO（Total Cost of Ownership：総保有コスト）と呼びます。

何をTCOに含めるかはNetSuiteのライセンスは高い？で、相場感はクラウドERPの費用・料金相場で扱っています。

軸2：5年後の保守責任｜誰が直し続けるのか

何を見る軸か：システムが動かなくなったとき、誰が責任を持って直すのかを見ます。

基幹システムは、止まると業務が止まります。

受注も出荷も請求も止まります。

パッケージでは、製品そのものの不具合は提供元が直します。

設定や周辺はパートナーが担うのが一般的で、範囲は契約で決められます。

作った場合、責任は自社に残ります。

開発を委託していても、その会社が5年後も同じ体制とは限りません。

判断のポイント：「誰が直すのか」を、契約書に書かれた言葉で確認してください。

口頭の「もちろん対応します」は、担当者が変われば消えます。

軸3：法改正への追随｜変更は必ずやってくる

何を見る軸か：制度が変わったとき、誰がどのくらいの費用で対応するかを見ます。

会計や税務の制度は、数年ごとに変わります。

インボイス制度（2023年10月開始）では、請求書に登録番号などの記載が求められました。

電子帳簿保存法では、2024年1月以降の電子取引データの保存の方法が定められています（出典：国税庁、2026年9月確認）。

どちらも、システム側で記載の項目や保存の仕方を合わせる必要がありました。

パッケージでは、多くが提供元のアップデートや日本向けの機能で対応されます。

ただし、標準の範囲と、追加の設定や費用がかかる範囲は製品ごとに違います。

作った場合は、そのたびに改修の見積もりを取り、予算を確保し、テストをします。

判断のポイント：法改正は必ず起きる定期費用です。

計算から外すと、比較そのものが成り立ちません。

軸4：AI機能の進化への追随｜止まっているものは古くなる

何を見る軸か：新しい技術が出たとき、自社のシステムが追いつけるかを見ます。

AIをめぐる状況は、いま非常に速く動いています。

パッケージERPの側でも、AI機能の実装が続いています。

NetSuiteも「#1 AI Cloud ERP」を掲げています（出典：Oracle NetSuite公式サイト、2026年9月確認）。

年2回の製品リリースが、自動のアップデートですべての利用者に届けられます（出典：Oracle NetSuite公式サイト、2026年9月確認）。

作ったシステムは、作った時点の設計のまま止まります。

新しい機能を取り込むには、そのつど開発が要ります。

いま最新の技術で作っても、2年後には自分で追いかけることになります。

判断のポイント：その領域の技術が、この先も速く変わり続けるかを考えてください。

変化が速い領域ほど、追随してくれる側に乗るほうが有利です。

技術がほぼ枯れている領域なら、作っても古くなりにくい。

ERPに組み込まれたAIと外部のAIをつなぐ仕組みの違いは、NetSuiteの純正AIと外部AI連携の違いで扱っています。

軸5：属人化｜作った人がいなくなった後

何を見る軸か：作った本人が抜けたとき、そのシステムを扱える人が残るかを見ます。

AIを使って作ったシステムでも、設計の意図までは残りません。

「なぜこの処理がこうなっているのか」を説明できるのは、作った本人だけです。

その人が退職や異動でいなくなると、誰も触れないシステムが残ります。

ブラックボックスの作り直しです。

パッケージなら、扱える人は市場にいます。

ドキュメントも公式に整備されています。

判断のポイント：「作れる人が社内にいる」ではなく、「その人が抜けても続けられるか」で判断してください。

属人化が経営リスクになる理由は、キーマンが辞めても会社が止まらない仕組みで扱っています。

比較表と、判断の物差し

作る場合と買う場合

判断軸	スクラッチ開発（AI活用）	パッケージERP
1 初期コストの見え方	安く見えやすい。見積もりは「作るまで」が中心	高く見えやすい。運用・保守の一部が最初から含まれる
2 5年後の保守責任	自社に残る。委託先の体制が続く保証はない	契約で範囲を決められる。提供元とパートナーが分担
3 法改正への追随	そのつど改修の見積もり・予算・テストが要る	多くはアップデートで対応。範囲は製品ごとに違う
4 AI機能の進化	作った時点で止まる。取り込むには開発が要る	定期のアップデートで続けて追加される
5 属人化	設計の意図が個人に残りやすい	扱える人が市場にいる。公式の文書がある
AIとの親和性	最新のAIを自由に組み込める。データの整備と保守も自社で担う	標準のデータの形がそろい、組み込みのAIや外部のAIをつなぎやすい

選択肢は「作る」「NetSuite」だけではない

選択肢	合う条件
AIを使ったスクラッチ開発	自社の強みそのものの業務。作った後を担う体制がある
NetSuite	販売・在庫・会計を一つにし、拠点や海外に広げたい。IT担当が少ない
Odoo	必要な業務から小さく始め、自社で設定や拡張を続けたい
国産のERP・販売管理パッケージ	国内中心で、日本の帳票や商習慣に強く合わせたい
パッケージ＋一部を作る	基幹は標準に寄せ、差別化の業務だけ作ってつなぐ
いまは入れない	業務の棚卸しが先。対象の業務と責任者がまだ決まっていない

分かれ目は、差別化したい業務か止まってはいけない業務かです。

製品ごとの違いは、ERPを徹底比較で比べています。

「両方使う」という現実解｜標準に合わせる／開発する／残す

基幹は買い、差別化領域は作る

基幹業務は、他社と違うやり方をしても競争力になりません。

会計の処理が独特であることに、経営上の意味はほとんどない。

ここはパッケージに任せ、標準に合わせるほうが得です。

一方、自社の勝ち筋に直結する業務は、標準に合わせると強みが薄れます。

境界線の引き方

分け方に迷ったら、業務ごとに次の問いを立ててください。

「この業務のやり方が他社と同じになったら自社は困るか」

答えに応じて、業務を3つに振り分けます。

ベンチャーネットがERPの導入で使っている「標準に合わせる／開発する／残す」の型です。

• 標準に合わせる：困らない業務。会計・販売・在庫・購買の多くはここに入る
• 開発する：困る業務。パッケージに足すか、スクラッチで作ってつなぐ。5年後に直す人が決まっていることが条件
• 残す：すでに作った仕組みで、維持の責任者と改修の予算が決まっているもの。新しい仕組みに載せず使い続ける

「標準に合わせる」に入る業務が多いほど、アップデートの恩恵をそのまま受けられます。

「開発する」は、軸1で見たとおり費用を押し上げる側です。

だから、この箱に入れる業務は絞ります。

つなぐことを前提に設計する

両方を使うなら、データをどうつなぐかが論点になります。

つなぎ方を後から考えると、たいてい苦労します。

作る側の設計に、最初から連携の口を用意しておいてください。

これから選ぶ会社、すでに作った会社

これから選ぶ会社｜業務を小さく分けてから決める

提案を受け、まだ決めていない会社です。

次の状態が3つ以上あれば、パッケージを軸に検討する余地が大きい。

• 会計・販売・在庫の基幹業務が対象になっている
• 部門ごとにシステムが分かれ、数字の突き合わせに時間がかかっている
• IT担当者が少ない、または専任者がいない
• 制度変更の対応に、毎回まとまった費用がかかっている

逆に、対象業務が競争力に直結し、一部門で閉じ、運用の体制も社内にあるなら、作る方向で構いません。

その場合、ベンチャーネットに相談する必要もありません。

どちらとも言えなければ、業務を受注・在庫・請求・原価のように分けます。

単位を小さくすれば、5-2の問いに一つずつ答えられます。

すでに作った会社｜「残す」の条件を満たすか

すでにスクラッチのシステムがあっても、すぐ捨てる必要はありません。

「残す」に入れてよいかを、次の3点で決めます。

• 今後5年間、誰の責任で維持するか決まっているか
• 作った人が抜けても、設計の意図を説明できる資料と人がいるか
• 次の法改正のとき、改修の予算と担当が決まっているか

3つとも答えが出るなら、そのまま使い続けて問題ありません。

出ない場合は、基幹部分から段階的に移すことを検討します。

保守期限が近い場合は、保守期限切れのリスクもご覧ください。

選定段階でよくある4つの判断ミス

どれも、条件がそろえば誰でも踏むものです。

ミス1：「作れる」と「持ち続けられる」を同じことだと考える

起きること：試作がうまく動き、そのまま導入が決まる。

「もう動いているのだから大丈夫」という空気になり、運用の予算が計上されない。

原因：試作は、条件が整った状態で動けば成功と見なされます。

本番では、例外処理も、繁忙期の負荷も、担当者の交代も起こります。

生成AIが速くしたのは作る作業です。

動かし続ける負担は変わっていません。

避け方：判断の場で、5年後これを誰が動かしているかを口に出してください。

答えられないなら、その計画はまだ完成していません。

ミス2：比較の期間が、双方でそろっていない

起きること：作る側は初期費用で語られ、買う側は5年分で語られる。

「作れば一度きり、買えば毎年かかる」という説明を受ける。

原因：作る側にも、保守・改修・人件費が毎年かかります。

それを除いて初期費用だけを並べれば、そちらが安く見えるのは当然です。

避け方：期間をそろえます。

5年、できれば7年で比べ、両方に同じ費目（開発費・運用の人件費・改修費・教育費）を入れます。

パッケージ側も、ライセンスだけでなく導入と追加開発まで入れてください。

ミス3：変更コストを「起きないもの」として外す

起きること：法改正への対応の費用が、見積もりに入っていない。

業務や組織が変わったときの影響も、計算に入っていない。

原因：制度も業務も、5年間まったく変わらないことはありません。

変更が起きる前提で計算しないと、後から想定外の支出が積み上がります。

避け方：過去5年間の改修の回数を数えてください。

同じくらいの回数が、これからの5年でも起きます。

それを見積もりに入れます。

ミス4：二択で決めて、使い分けを検討しない

起きること：会議の議題が「作るか、買うか」の一択になっている。

全社一括で方針を決めようとする。

原因：業務によって答えが違うのに、一つの答えを全体に当てはめているためです。

基幹まで独自に作るか、差別化の業務まで標準に合わせるか。

どちらかで無理が出ます。

避け方：議題をどこを作りどこを買うかに変えてください。

問いの立て方を変えるだけで、出てくる答えが変わります。

1件ずつの判断は正しくても、積み重なると社内のシステムが増えすぎます。

その構造はAIで「作れる」時代の落とし穴で扱っています。

ベンチャーネットならこう見る｜振り分けの前に、責任の分担を決める

ベンチャーネットは、NetSuite・Odoo・AIスクラッチ開発を扱い、SAPからのリプレイスにも対応しています。

作る側も買う側も扱うので、どちらかに寄せる理由がありません。

「標準に合わせる／開発する／残す」は、業務を見てから決める

提案書が「作る」前提で書かれていても、まず業務を分けます。

受注・在庫・請求・原価と分ければ、「困るか」の問いに答えられる単位になります。

振り分けを先に決めてから業務を見ると、要らない開発まで提案に入ったままになります。

誰が何を直すかを、先に紙に書く

軸2の「誰が直すか」は、パッケージを選んでも残る問いです。

NetSuiteの場合、分担は次のようになります。

担うこと	担う側
ライセンス・トレーニング・製品サポート	日本オラクル
要件定義・設定・カスタマイズ・アドオン開発	導入パートナー（ベンチャーネット）
稼働後の保守・プロジェクトの管理	導入パートナー（ベンチャーネット）

ベンチャーネットは請負契約に対応しています（準委任も相談可）。

作る部分を別の会社に任せる場合も、つなぎ目の責任をどちらが持つかを、この表の形で書き出します。

最初の打ち合わせで伺うのは、主に次の3つです。

1. 提案の対象の業務は、どこからどこまでか
2. 作る業務について、5年後に誰が直すかを決められるか
3. 作る部分と買う部分のデータを、どこでつなぐか

作るべき領域があれば、そう申し上げます。

都合のよい比較だけをお見せすることはしません。

今日できること｜提案書を1時間で点検する

手元の提案書と、比較の相手の見積もりを並べ、次の表を埋めてください。

点検すること	作る提案	買う提案
比較の期間（5年か）
運用の人件費が入っているか
法改正の対応の費用が入っているか
5年後に誰が直すか、契約に書かれているか
担当が抜けたときの引き継ぎの方法

空欄が残るところが、提案者に聞き返す点です。

自社のシステムを過去5年で何回改修したかも数えておくと、比較の精度が上がります。

よくある質問

Q1. AIで作れるなら、そのほうが安いのではありませんか

作り始めまでは安いことが多いですが5年分で比べると順位が入れ替わることがあります。

動かし続ける費用、変更に対応する費用、人が抜けたときの費用。

これらを5年分足して比べてください。

安いか高いかの前に、どの期間で比べているかを見ます。

Q2. 内製はダメということですか

違います。

自社の競争力の源泉になっている業務は、作る価値があります。

業務によって答えが違う、というだけです。

全部を作るか全部を買うかの二択にしないでください。

Q3. すでにスクラッチで作ってしまった場合はどうすればよいですか

すぐ捨てる必要はありません。

今後5年間、誰の責任でどう維持するかを決めてください。

答えが出るなら、そのまま使い続けて問題ありません。

答えが出ない場合は、基幹部分から段階的に移すことを検討します（第6章6-2）。

Q4. パッケージだと、自社のやり方に合わないのではありませんか

基幹業務については合わせにいく価値があります。

会計や在庫の処理が他社と違うことに、経営上の意味はほとんどありません。

標準に寄せれば、採用も引き継ぎも楽になります。

合わせられない業務が本当にあるなら、それは差別化領域で、作る候補です。

Q5. 判断を急がされています。何から見ればよいですか

比べる期間・変更への対応費・保守の責任者の3つです。

• 比較の期間は、両方とも5年でそろっているか
• 法改正や業務変更の対応費用は、両方に入っているか
• 5年後に誰が保守するかを、契約に書いてあるか

この3つがそろっていない比較表は、判断材料として足りません。

導入そのものでつまずく原因は、ERP導入はなぜ失敗するのかで扱っています。

Q6. パッケージERPに、自社独自の機能を足すことはできますか

多くの製品で設定や追加の開発で補えます。

NetSuiteでも、標準の設定で足りない部分を開発で補うことがあります。

ただし足しすぎると、属人化や保守の負担というスクラッチと同じ課題が戻ってきます。

どこまで足すかも、「他社と同じになったら困るか」で決めてください。

まとめ｜決めるべきは「作るか買うか」ではない

• 生成AIで「作る」選択肢が広がったのは、歓迎してよい変化
• 比べるのは初期費用ではなく、5年分の総額
• 5つの軸：初期コスト・保守責任・法改正・AIの進化・属人化
• 業務ごとに「困るか」を問い、標準に合わせる／開発する／残すに振り分ける
• 作る部分と買う部分は、最初からつなぐ前提で設計する
• すでに作った仕組みは、5年後の責任者が決まるかで扱いを決める

「AIで作れば安い」かどうかは、見積もりの期間を5年にそろえた時点で答えが出ます。

その前に、業務を1枚の紙に分けて書き出してください。

振り分けの答えは、そこから出てきます。

関連記事

• AIで「作れる」時代の落とし穴｜増えるのはシステムではなく、動かし続けるコストです
• 【2026年版】ERPを徹底比較
• NetSuiteのライセンスは高い？──「見えないコスト」と経営判断
• クラウドERPの費用・料金相場

もう少し詳しく知りたい方へ

どこを作り、どこを買うか。その線引きを一緒に考えるところから、ご相談をお受けしています。

作るべきだと判断したときには、そのようにお伝えします。

• AIとERPの組み合わせを知りたい方へ：AIクラウドERP NetSuite導入支援
• パッケージで足りない部分を開発で補う方法を知りたい方へ：NetSuiteアドオン開発サービス「NetSuiteリブート」
• 自社の状況を整理するところから相談したい方へ：お問い合わせ