SAP導入の費用は何で決まるか ─ 見積もりが会社ごとに割れる理由と、比べ方

同じ依頼書を3社に渡して見積もりを取ったのに、金額がまったくそろわない。SAPの導入を検討する会社が最初に突き当たるのが、この状態です。

SAP FIの導入に会計の側から関わってきた立場で見ると、割れる主な原因は、単価より前提にあります。移すデータは何年分か、テストのシナリオは誰が作るか、標準機能で足りない部分はいくつあるか。依頼書に書かれた前提の粒度が粗いと、各社はその空白をそれぞれの仮定で埋め、返ってくる金額は「各社が想像した別々のプロジェクト」の値段になります。比べる前にやるべきことは、値引きの交渉より、前提をそろえることです。

公開されている「相場」は、自社の予算づくりには使えない

SAP導入費用の目安を調べると、下限と上限が大きく離れた相場が紹介されています。SAPは、販売・購買・生産・在庫・会計・管理会計といった会社の基幹業務を一つの基盤でつなぐERPです。どこまでを一度に載せるかで、プロジェクトの大きさはまるで変わります。対象の会社は1社か、グループ10社か。会計だけか、販売から生産までか。利用者は50人か、2,000人か。この違いを横に並べた数字は、自社の予算の根拠になりません。

規模は、予算どおりに終わる確率も変えます。日本情報システム・ユーザー協会（JUAS）は「企業IT動向調査報告書2026」（2025年度調査）で、システム開発の予算がどれだけ守られたかをプロジェクトの規模別に集計しています。

SAPに限った調査ではありませんが、500人月以上のプロジェクトでは4割を超えるプロジェクトが予算を超過しています。規模が大きいほど、最初の見積額はそのまま最終の支払額になりにくいのです。

SAP導入費用の目安は、大企業か中堅企業かでは決まらない

筆者は、大企業か中堅企業かという分け方では、予算を立てられないと考えています。目安にできるのは、金額そのものより、金額を動かす項目のほうです。対象の会社数、業務範囲、利用者数と利用区分、アドオンの量。これを自社の数字で埋めれば、他社の金額を借りなくても、概算を頼める状態になります。

費用は4つの支払いと、見積書に載らない社内の時間でできている

まずライセンス（利用料）です。オンプレミスなら購入費に毎年の保守料が乗り、クラウドなら期間ごとの利用料になります。支払い方が違うので、比べるときは同じ年数の総額で並べます。

次に導入作業の費用です。含まれるのは次の作業です。

• コンサルタントによる要件定義と設定
• 標準機能で足りない部分の追加開発（アドオン）
• 周辺システムとの連携と帳票
• データ移行
• テストと教育

人数と期間と単価の掛け算で決まります。筆者の見るところ、前提しだいで最も大きく動き、見積もりが割れやすいのもこの費目です。

あとは基盤と運用保守です。基盤は、オンプレミスならサーバーなどのハードウェアとデータベース、クラウドなら利用料に含まれない追加分を指します。どこまでが利用料に含まれるかは契約ごとに違うので、見積書の前提として確かめてください。運用保守には、本番稼働後の問い合わせ対応、法改正への対応、アドオンの保守、SAPへの保守料が入ります。いまSAP ERP 6.0を使っている会社は、移行しない場合の保守の条件も比較の対象です。延長保守の範囲と料金の考え方は、SAP 2027年問題の記事で整理しています。

この4つとは別に、見積書に載らない費用があります。社内で「導入コスト」と言うときは、これを入れるかどうかを先に決めておきます。まず、経理・購買・販売・生産の担当者が要件定義とテストに割く時間です。業務を知っている社員が週に何時間出られるかで、外部のコンサルタントが肩代わりする作業量が変わり、社内の時間を惜しんだ分はベンダーの工数として請求書に載ります。総額は思ったほど下がらない、と筆者は見ています。連携先の周辺システム側の改修費と、旧システムを並行して動かす期間の費用も、SAPの見積書の外に出やすい費用です。

費用は見積書に載る4つと、載りにくい3つ。筆者の見立てでは、最も大きく動くのは導入作業

見積書に載る費用4つの支払い

1ライセンス（利用料）

中身

オンプレミスは購入費と毎年の保守料。クラウドは期間ごとの利用料

比べ方

支払い方が違うので、同じ年数の総額で並べる

2導入作業

中身

要件定義と設定、アドオン、周辺システムとの連携と帳票、データ移行、テストと教育

決まり方

人数×期間×単価

前提しだいで最も大きく動き、見積もりが割れやすい（筆者の見立て）

3基盤

中身

オンプレミスはサーバーなどのハードウェアとデータベース。クラウドは利用料に含まれない追加分

注意

どこまで利用料に含まれるかは、契約ごとに違う

4運用保守

中身

稼働後の問い合わせ対応、法改正への対応、アドオンの保守、SAPへの保守料

注意

SAP ERP 6.0を使っているなら、移行しない場合の保守の条件も比べる

足りない分は導入作業の工数に

見積書の外に出やすい費用SAPの見積書には載りにくい

社内の時間

中身

経理・購買・販売・生産の担当者が、要件定義とテストに割く時間

惜しんだ分は、ベンダーの工数として請求書に載る

周辺システム側の改修費

中身

連携先のシステムを直す費用

旧システムの並行稼働

中身

旧システムを並行して動かす期間の費用

比べるときは

やること

3つともSAPの見積書の外に出やすい。総額を比べるときは、この3つを別に見込んでおく

効き方

社内の時間が足りないと、その分はベンダーの工数になる。総額は思ったほど下がらない、と筆者は見ている

総額4つの支払いに、見積書の外の費用を足したもの。各社の見積もりは、同じ年数と同じ範囲にそろえてから並べる。

見積書の総額だけを比べると、社内の時間と見積書の外の費用が抜け落ちる。前提をそろえるなら、動きやすい導入作業からそろえる。

見積もりが割れるのは、同じ一行を各社が違う前提で読むから

導入作業の見積もりは、たとえばデータ移行で割れます。ある会社は「期首の残高だけを移す」と読み、別の会社は「過去3年分の明細を移す」と読みます。移すデータの量も、移したあとの突き合わせの手間も、まるで違う作業です。同じ「データ移行」の一行でも、中身は別物です。

テストも同じです。テストのシナリオは、発注側の担当者が書くのか、ベンダーが書くのか。本番と同じ量のデータで処理時間を確かめるテストまで含むのか。依頼書に書かれていなければ、各社がそれぞれの経験で決めます。

アドオンの本数は、さらに差が出やすい項目です。依頼書に標準機能で足りない要件の一覧が載っていなければ、各社は「この業種ならこのくらい」と想定本数を置きます。想定が10本の会社と50本の会社では、開発もテストも保守も、見積もりの前提がまるごと変わります。想定本数の差は、そのまま金額の差になります。

体制の組み方でも金額は動きます。導入パートナーの規模や方針によって、上位のコンサルタントと実作業の担当者の配分が違い、同じ作業量でも単価の構成が変わるからです。パートナーを選定するときは、提案書に書かれた担当者の構成と、それぞれが何か月関わるのかまで比べてください。

依頼書の同じ一行を、3社が別々の前提で読む。単価が同じでも見積額は割れる

依頼書の一行と、各社の読み（例示）

依頼書の一行A社の読みB社の読みC社の読み金額への効き方

データ移行

A社期首の残高だけを移す

B社過去3年分の明細を移す

C社過去1年分の明細と、未決済の残高を移す

効き方移すデータの量と、移したあとの突き合わせの手間

テスト

A社シナリオは発注側が書く

B社シナリオはベンダーが書く

C社ベンダーが書き、本番と同じ量で処理時間も確かめる

効き方テストの工数と、発注側の作業量

アドオンさらに差が出やすい

A社想定10本

B社想定30本

C社想定50本

効き方開発もテストも保守も、前提がまるごと変わる

利用区分利用者200人

A社全員advanced
200FUE

B社advanced 30人＋core 170人
64FUE

C社advanced 30人＋core 110人＋self-service 60人
54FUE

効き方ライセンスの必要量が数倍ずれる

単価

A社3社とも同じ

B社同じ

C社同じ

効き方差はここから出ていない

FUEは1FUEあたりadvanced useが1人、core useが5人、self-service useが30人（サービス利用記述書2022年9月版）。A〜C社のFUEは、いずれもこの比率で数えた例。

発注側が渡したもの同じ依頼書前提の粒度が粗く、空白が残っている

→

各社が空白を埋めた結果3つの別々のプロジェクト各社がそれぞれの経験で仮定を置く

→

返ってくるもの見積額が割れる比べているのは、各社が想像したプロジェクトの違い

比べる前に空白を発注側が先に埋める。12項目の前提を依頼書に書いてから、見積もりを取る。

見積額の差は、主に単価より前提の差から生まれる。比べる前にやることは、値引きの交渉より前提をそろえること。

S/4HANAのライセンス価格のもとになる必要量は、利用者の区分で数倍動く

ライセンスも、前提の置き方で大きく割れます。RISE with SAPでS/4HANAをクラウド契約する場合の数え方を、SAPの公式資料で確認しておきます。サービス利用記述書（2022年9月版）は、利用量の単位を「Full Usage Equivalent（FUE）」と定めています。1FUEで割り当てられる利用者は、使える機能の広さによって違います。

たとえば利用者が200人の会社で、全員をadvancedとして数えれば200FUEです。実際に幅広い機能を使うのは30人で、残る170人は定型業務だけだと整理できれば、30＋170÷5＝64FUEで済みます。差は136FUE。同じ200人でも、区分を実態に合わせるだけで必要量は約3分の1になります。

だから、利用区分の前提をそろえずに各社から見積もりを取ると、ライセンスだけで大きな差が出ます。区分の定義や比率は契約時点の版で変わることがあるので、最終的には提示された契約書類で確かめてください。

要件定義の前の金額は、そもそも確定額ではない

ずれは、見積もりの時期そのものからも生まれます。情報処理推進機構（IPA）が経済産業省と整備した「情報システム・モデル取引・契約書」は、多段階契約と再見積もりの考え方を採っています。工程が進むにつれて見積もりの精度を「試算」「概算」「確定」と上げていき、工程ごとに見積もり直すという考え方です。IPAの例では、要件定義を頼む前の見積もりが「試算」、外部設計を頼む前が「概算」、外部設計を終えてソフトウェアの開発を頼む前が「確定」と置かれています。要件定義の前に出てくる金額は、まだ試算の段階です。確定していない金額どうしを並べて安い方を選んでも、比べたことにはならないのです。

前掲のJUASの調査は、システム開発の品質・予算・工期の悪化に影響している傾向も尋ねています。予算について最も多かったのは「システム影響範囲の拡大」の43.8%で、「要件定義の難易度上昇」40.4%、「IT人材の新規確保の困難化」36.8%が続きました。上位の2つは、どちらも範囲と要件に関わる項目です。

見積もりを取る前に、この12項目をそろえる

前提をそろえる作業は、各社が仮定で埋めてしまう空白を、先に発注側が埋めておく作業です。対象、方式、量、分担、契約の順に並べると次のようになります。

このうち1、4、5、8の4つは、経営の判断が要る項目です。範囲をどこまで広げるか、標準に業務を合わせるのか、過去のデータを何年分持つのか。情報システム部門が事業部門とCFOを巻き込んで方針を決めておけば、見積もりの前提は一本になります。ここを空けたまま依頼すると、各社はそれぞれの経験で埋めてきます。

見積書が届いたら、金額を並べる前に、各社が置いた前提を同じ表に書き写してください。前提が違う行が見つかれば、その差が金額の差の説明になります。含まれない作業の一覧や、工程別の人月と単価、予備費、稼働後の費用が書かれていない見積書は、まずそれを書いてもらうところから始めます。

外部設計を終えるまで、金額は確定しない

SAP導入は、おおむね次の流れで進みます。

1. 構想・計画：目的、範囲、予算の枠、体制を決める
2. 要件定義：標準の業務プロセスを実機で見ながら、自社の業務との差分を洗い出す（Fit to Standard）
3. 外部設計：画面、帳票、連携など、外から見える仕様を固める
4. 構築：設定、アドオン開発、連携、帳票をつくる
5. テスト：単体から結合、本番を想定した総合テストまで
6. データ移行・本番切替：旧システムからデータを移し、切り替える
7. 運用・保守：稼働後の定着と改善

要件定義を終えるまでの金額は、試算か概算です。IPAのモデル契約の例では、確定の見積もりは外部設計を終えたあとに置かれています。同じ例は、構想と要件定義を準委任、外部設計を準委任か請負、ソフトウェアの開発を請負とする分け方を例に示しています。要件定義を先に別の契約で発注し、その成果をもとに構築を見積もり直す形です。

見積もりの精度は工程ごとに上がる。確定するのは、外部設計を終えたあと

← 図は横にスクロールできます →

1234567 工程 構想・計画 要件定義 外部設計 構築 テスト 移行・切替 運用・保守 工程の終わりに出る見積もり 試算 概算 確定 追加があれば、見積もり直す 契約の区切りIPAの例 準委任 準委任 準委任か請負 請負 並べてよいもの 試算と概算の金額は確定していない。並べて比べるのは各社の前提 外部設計を終えて、初めて確定の見積もりになる

試算：要件定義を頼む前概算：外部設計を頼む前確定：外部設計を終え、開発を頼む前契約を区切り、見積もり直す点

要件定義の前に出てくる見積額は試算。安い順に並べて1社に絞る前に、各社が置いた前提を並べる。

工程ごとに契約を分けると、それぞれの契約で約束されるのは、その工程の作業や成果物になります。野村ホールディングスと日本IBMのシステム開発をめぐる訴訟が、その例です。両社は工程ごとの個別契約だけを結んでおり、地裁・高裁とも、IBMがシステム全体を完成させる債務まで負っていたとは認めませんでした。SAPの事案ではありません。それでも、段階ごとに契約を結ぶなら、各段階で何を約束させるかを発注側が契約に書いておく必要があることが分かります。

アドオンを減らすには、要否を判定する人と場を先に決める

費用を下げる方法として、よく挙がるのが「標準機能に業務を合わせる」「アドオンを減らす」です。方針としては正しいのですが、方針を掲げただけではアドオンは減りません。

旭化成は、約20年の運用で2,400本まで増えていたアドオンを、SAP S/4HANAへの移行で1,100本まで減らしました。SAPジャパンの紹介記事によると、追加のアドオンはまずプロジェクトのリーダーが毎週集まる場で議題に上げました。最終的に判定したのは、会計・IT・経営企画室の部長が参加する毎月のアドオン審議会です。プロジェクトは2023年4月、計画どおりの予算と納期で本番稼働したと紹介されています。

Osaka Metroは、経理の基幹システムをSAP S/4HANAで刷新しました。その際に業務フローを見直し、提案依頼の段階で想定していたアドオンを80%削減しています。起点になったのは、その機能を本当に全員が使っているのか、あると何が良くなるのかという問い直しでした。

筆者は、2社の例から、アドオンの本数は要否を問い直す人と場があるかどうかで大きく変わると考えています。要望を出す部門と、認める部門を分けておく。旭化成のように、認める側に経理や経営企画が入っていると、要望は絞られやすいと考えます。本数が減れば、それに連動する開発・テスト・保守の費用もまとめて下がります。

そのほかに効く打ち手は、範囲を段階に分けること、利用区分を実態に合わせること、移行するデータの年数を決めることです。キーユーザーが設定とテストに深く関わり、稼働後の小さな変更を社内で回せるようにしておけば、外部の工数と保守の費用も抑えやすくなります。

会計の範囲でいえば、月次決算の手順や管理会計の粒度を先に決めておくと、帳票とアドオンの要望がまとまりやすくなります。決算の組み直し方については決算早期化の実装支援に整理しています。

見積もりの依頼より先に、4項目を経営会議で決める

見積もりの金額は、発注側が前提を書いた分だけ比べられるようになります。最初の一歩は、12項目のうち経営の判断が要る1、4、5、8の4つを、見積もりを依頼する前に経営会議で決めておくことです。そうすれば、届いた金額の差は「どの前提が違うか」として説明できるようになります。

Never Redでは、SAP FI（財務会計）の導入・更改と経営管理の設計を、同じ担当者が通して見ます。会計の設計判断とSAPの設定を切り離さないためです。提案依頼書の前提づくりや、届いた見積もりの読み比べからご相談いただけます。支援の内容はSAP導入支援と事業紹介をご覧ください。移行の見積もりで金額を動かす前提は、S/4HANA移行支援にも書いています。

よくある質問

Q. SAPの導入費用の相場はいくらですか。 公開されている相場は幅が広く、そのままでは予算の根拠になりません。対象の会社数、業務範囲、利用者数、アドオンの量がそろっていない数字だからです。自社の予算は、上の12項目で前提を固めたうえで概算を出すのが確実です。

Q. SAPの導入費用は、大企業だと億の単位になりますか。 億の単位に届くかどうかは、大企業かどうかより、対象の会社数、業務範囲、利用者数、アドオンの量で分かれると筆者は考えています。会社の規模ごとの導入費用は、公表された数字が見当たらないので、この記事では金額を示していません。JUASの調査では、プロジェクトの規模が大きいほど予算を超過した割合が高く、500人月以上では42.2%でした。規模の大きい導入では、見積もり直す時点を契約に入れておきます。

Q. ライセンス費用は何で決まりますか。 RISE with SAPのクラウド契約では、利用者の人数と利用区分で決まります。サービス利用記述書（2022年9月版）では、1FUEあたりadvanced useが1人、core useが5人、self-service useが30人です。全員を上位の区分で数えるか、実態に合わせて分けるかで、必要な量は数倍変わります。

Q. 見積もりは何社から取ればよいですか。 社数より先に、全社に同じ前提を渡せるかどうかを確かめてください。前提がそろっていれば、比較の手間から見て3社前後が扱いやすいと筆者は考えています。前提がばらばらなら、何社から取っても比べられません。

Q. 費用を抑えるために、最初にやることは何ですか。 見積もりを頼む前に、対象範囲・利用区分・標準で足りない要件・移行データの4つを経営会議で決めることです。そのうえで、アドオンの要否を判定する場と人を置くと、見積もりの段階から金額を下げやすくなります。

Q. SAP ERP 6.0を延長保守で使い続けるのと、どちらが安いですか。 保守料の上乗せだけを比べると延長保守が安く見えますが、延長期間に何を進めるかで結論が変わります。条件と考え方はSAP 2027年問題の記事をご覧ください。

SAPの導入や移行の見積もりについてのご相談は、お問い合わせからお寄せください。

出典

1. プロジェクト規模別のシステム開発の予算遵守状況（2025年度、図表7-1-4）：一般社団法人日本情報システム・ユーザー協会「企業IT動向調査報告書2026」（2026年4月）。システム開発のQCD悪化に影響を与えているトレンド（予算）：同「企業IT動向調査2026（2025年度調査）」速報版（2026年4月）
2. Full Usage Equivalent（FUE）の定義と利用区分ごとの比率（1FUE＝advanced use 1、core use 5、self-service use 30）：SAP「RISE with SAP S/4HANA Cloud Service Use Descriptions」（2022年9月版）
3. 多段階契約と再見積もりの考え方、見積精度（試算・概算・確定）と、各見積もりを置く工程、工程ごとの契約類型（準委任・請負）：独立行政法人情報処理推進機構「システム開発の健全化に向けて ～『情報システム・モデル取引・契約書』から読み解く～」（2025年4月24日講演資料）、同「情報システム・モデル取引・契約書（第二版）」
4. 野村ホールディングス・野村證券と日本IBMの訴訟（東京地裁 2019年3月20日判決、東京高裁 2021年4月21日判決）の争点と判断：一般財団法人ソフトウェア情報センター（SOFTIC）判例ゼミ資料「野村HD対日本IBM」（2021年12月23日）
5. 旭化成のアドオン削減（2,400本から1,100本）、アドオン審議会、計画どおりの予算と納期での本番稼働：SAPジャパン「旭化成が SAP S/4HANA のビッグバン導入で目指す新たな成長基盤の再構築」（2023年11月22日）
6. Osaka Metroのアドオン削減（提案依頼段階の想定から80%削減）：SAPジャパン「民営化された Osaka Metro が SAP S/4HANA で経理基幹システムを刷新し、業務フローの見直しによってアドオンを 80 ％削減」（2024年10月4日）