SAP 2027年問題、難所は「20年分のアドオン」——作り直す前に仕分ける3つの箱

「もう後戻りできない」と言われた時点で、何が決まってしまったのか

先に結論を書きます。基幹刷新で投資額が決まるのは、ベンダーを選んだ瞬間ではありません。どのアドオンを残すと決めた瞬間です。

冒頭の案件では、要件定義が終わっていました。つまり「今の業務をそのまま動かすために何を作り直すか」のリストが固まっていた。この時点で、移行の工数はほぼ確定します。後から「ここは標準機能で我慢します」と言い出すには、固めた要件を一度ほどく必要があり、それは現場との再交渉を意味する。だから後戻りできない、という言葉が出てきます。

誤解のないように申し上げると、この判断が甘かったわけではありません。基幹刷新は情報システム部門だけでは決められず、各事業部の合意が要る。合意を取るために「今できていることは維持します」と約束する——私たちが見てきた案件では、これがいちばん早い道でした。その約束の集積が、そのまま見積もりになります。

別の製造業のDX推進担当者は、もっと手前の不安を口にしていました。「ERP導入は短く見積もっても3年程度かかる」「ERP導入中に世の中の技術が変化するのが心配」。3年のプロジェクトで、初年度に固めた要件が最終年度にも最適である保証はどこにもありません。実際、ここ1年でAIエージェント（人間の代わりに判断・行動するAIプログラム）の実装コストは目に見えて下がりました。3年前の要件定義に、その選択肢は入っていないはずです。

2027年末と2030年末——SAPが引いた線を、まず正確に押さえる

判断の前に、事実関係だけ正確にしておきます。ここを曖昧にしたまま社内で議論すると、期限の認識が人によってずれます。

対象は SAP Business Suite 7 の中核アプリケーション群です。SAP ERP 6.0、SAP CRM 7.0、SAP SCM 7.0、SAP SRM 7.0 などが含まれます。これらのメインストリームメンテナンスは2027年末まで。その後は任意の延長保守が2028年初から2030年末までの3年間用意され、保守料率に2パーセントポイントのプレミアムが上乗せされます。延長保守を選ばない場合、または延長保守が終わった後は、customer-specific maintenance（顧客個別保守）という扱いに移ります。

以上はSAP公式の保守方針に明記されている内容です（URLは記事末尾の参考リンク）。同じ文書は一方で、移行先の SAP S/4HANA について2040年末まで常に少なくとも1つのリリースを保守対象とする Innovation Commitment を示しています。つまりSAPは「2027年で終わる側」と「2040年まで続く側」を明示したうえで、乗り換えの期限を引いたことになります。

ここで押さえておきたいのは、2030年末は猶予ではなく有料のオプションだという点です。延長保守は3年間の時間を買う契約であり、買った時間に何をするかは別に決めなければならない。私たちが現場で見てきた限り、延長保守を選んだ会社の半分くらいは、買った3年のうち最初の1年半を「どうするか決める会議」に使っています。期限が後ろにずれると、判断も同じ幅だけ後ろにずれる。これは人間の自然な反応だと思います。

国内295社の調査が示した「5億円超が半数以上」という相場

では実際、いくらかかるのか。ここは推測ではなく調査データで押さえます。

電通総研が2025年12月に公表した「SAPユーザー意識調査結果2025年度版」の調査を見ます。これは国内295社からの有効回答をまとめたものです。内訳は SAP ECC 6.0 ユーザー165社、SAP S/4HANA ユーザー130社。この調査で、S/4HANAへの移行費用が5億円以上と回答した企業が全体の半数以上を占めました。さらにECCからの移行方式では、既存システムをそのまま変換する「ストレートコンバージョン」（ブラウンフィールド方式）が47.6%（60社）で最多。S/4HANAを新規導入したと答えた企業を上回っています。

この2つの数字を並べると、構造が見えてきます。いちばん多く選ばれている方式は、今の作り込みを引き継ぐブラウンフィールドです。そして費用は半数以上で5億円を超える。引き継ぐ量が多いほど、変換して検証する対象が増えるのだから、当然そうなります。

中堅企業にとって5億円は、情報システム部門の年間予算を何年分かまとめたような金額です。それを数年かけて払って、終わった後に手元に残るのは「今までと同じ業務が、新しい基盤で動いている状態」。そこに新しい競争力が足されているわけではありません。ある大手建材メーカーで情報システムを統括する方は、複数システムを別々に作る方針について「よろしくない。最適なやり方とセキュリティ要件を見定めないと、正直、一時の投資になってしまう」と警戒していました。基幹刷新こそ、この「一時の投資」になりやすい領域です。

見積もりを膨らませている本体は、20年分積み上がった「アドオン」

アドオンとは、パッケージの標準機能では足りない部分を個別開発で足した追加機能です。帳票の様式、承認の経路、他システムとの連携、独自の原価計算——日本企業のERPには、これが何百本も入っています。

アドオンが移行費を押し上げるのは、単に「作り直すから」ではありません。移行後も毎回コストを呼び続けるからです。標準機能ならSAPがバージョンアップのたびに整合性を担保しますが、アドオンは自社の責任です。定期バージョンアップごとに影響調査とテストが必要になり、担当者が異動すれば仕様を知る人がいなくなる。初回の開発費は一度ですが、保守の負荷は毎年続きます。

その逆の実例が、日本郵船の会計基幹システム刷新です。これは本社と国内外の子会社約350社を対象に、クラウド版の SAP S/4HANA Cloud Public Edition へ移行した事例。2025年7月から稼働しています。SAP Japan の公式発表には「標準機能にあわせて、複雑化かつ属人化していた業務を標準化する Fit to Standard を徹底」したとあります。その結果が、従来約450件あったアドオン開発による機能を約1割まで縮小という数字です。定期バージョンアップも最小限の工数で対応可能になり、稼働直後の2025年8月のグローバルバージョンアップは円滑に完了したと記されています。

450件から約45件へ。この数字を、私たちは「アドオンを9割減らせた成功例」としてだけ読むべきではないと考えています。もっと重要な示唆は、稼働の翌月にグローバルバージョンアップを通せたという後半部分にあります。アドオンを削る本当の見返りは初期費用ではなく、その後の身軽さです。逆に言えば、アドオンを400件抱えたまま移行した会社は、移行が終わった瞬間から毎年のバージョンアップに人を張り続けることになります。

「標準に寄せろ」が現場で折れる、3つの理由

Fit to Standard（業務を標準機能に合わせる進め方）は、理屈としては完全に正しい。それでも日本の現場で頻繁に折れます。私たちは、理由を3つに整理しています。

1つ目は、事業ごとに業務が本当に違うこと。 ある大手化学メーカーの生産DXグループリーダーは、こう話していました。「基本、システムではつながっていない。繋げようとしても縦割りが強く、事業ごとに顧客も機能も全然違う。一つのシステムでは使いづらい」。これは縦割りという組織の問題に見えて、実は事業特性の問題でもあります。素材を売る事業と装置を売る事業で、受注から出荷までの流れが同じになるはずがありません。

2つ目は、「秘伝のタレ」が競争力と不可分なこと。 ある合成樹脂・産業資材メーカーでは、社内でそう呼ばれる工賃表がありました。営業側の責任者の言葉です。「細かすぎて、どこに何が書いてあってどのケースはどの工賃を使うのかを理解した人じゃないと使えない。新入社員に渡して『これで検索して』と言っても、使いこなすのに時間がかかる」。業務側の担当者は原価表について「中身は7割くらいブラックボックス化していて、Excelで配信されるので各担当がそれぞれカスタマイズしてしまう。部材を一つ変えるにも全シートのセルを一個一個探して変える。二重で計上していた箇所もあった」と明かしました。

この工賃表を「標準に寄せます」と言うのは、値付けのロジックを捨てますと言うのに近い。現場が抵抗するのは当然です。

3つ目は、置いていかれる人が出ること。 私たちがレガシー刷新に入るとき、欠かさず確認するのがここです。「AS/400のエミュレーターを使っている方々が置いていかれず、業務スピードを落とさず操作できるようにしたい」——これは私たち自身が案件で掲げている方針です。標準機能は理想形で設計されているので、現行の操作に20年慣れた人にとっては遅くなることがあります。1日あたり数分の遅れでも、人数と日数をかけると現場は反対に回ります。

正直に申し上げると、私たちもSaaS導入が全盛だった時期に、この「フィットトゥスタンダードによる現場の不満」を何度も見てきました。だから標準化そのものに反対はしません。ただ、標準に寄せるべきものと、寄せたら競争力が落ちるものを混ぜて議論するのが最大の無駄だと考えています。

アドオンを3つの箱に仕分ける——標準に寄せる／外に出す／捨てる

ここが本題です。アドオンを「残す／作り直す」の二択で見ると、全部残す方向に倒れます。私たちは3つに分けます。

箱	見分け方	2027年までの打ち手	持ち主
① 標準に寄せる	法令・会計基準・業界慣行で決まる処理。他社と違う理由を説明できない	Fit to Standard。システムではなく運用ルールを変える	ERP本体・移行ベンダー
② 外に出す	自社の競争力そのもの。頻繁に変わる。現場が毎日触る	ERPの外に業務アプリとして内製。基幹はマスターと実績の正本に徹する	自社（内製）＋FDE伴走
③ 捨てる	作った目的を誰も説明できない。年に数回しか動かない。代替手段がある	棚卸しして停止。利用ログで実績を確認してから止める	情報システム部門

分け方のコツは、機能の中身で分類しないことです。「帳票だから」「連携だから」では分かれません。問いは3つだけです。(1) それは法律や会計基準で決まっているか。(2) それは1年以内に変わる見込みがあるか。(3) それは直近12か月で何回動いたか。

3つ目の問いが、実務では一番効きます。アドオンの利用ログを取ると、驚くほど動いていないものが出てきます。担当者が「使っているはずです」と答える機能が、年に2回しか起動していない。この種の発見は会議では出ず、ログを見た瞬間に出ます。

ただし例外があります。年に1回しか動かないが、動かないと決算が締まらない機能。これは③ではなく①です。回数ではなく、止まったときの影響で判定します。

「外に出す」が現実的な選択肢になった理由

②の箱——ERPの外に出す——は、5年前なら現実的ではありませんでした。外に出した業務アプリを作るコストが高く、作った後の保守も重かった。それが変わったのは、自然言語でAIに指示しながら開発するVibeCoding（バイブコーディング）で、従来の10分の1程度のコストでオーダーメイドのシステムが作れるようになったからです。

技術的な置き方は単純です。私たちは顧客データを「硬いデータ」と「柔らかいデータ」に分けて考えます。硬いデータは基幹システムが持つマスターと実績の正本。柔らかいデータは、AIが判断に使ったり現場が日々更新したりする情報です。そして基幹システムの横にデータ空間を設け、バッチでコピーする——社内では仮想のブロックエリア方式と呼んでいます。基幹側は読むだけ、書き込みは決まった経路だけ。これなら移行プロジェクトと並行して進めても、基幹の移行スケジュールを揺らしません。

セキュリティが下がるのではないか、という質問は毎回いただきます。実感は逆です。レガシー基幹の現場で、こんな経験をしました。「IDとパスワードしかないのに、社内VPNの総当たりで基幹システムに入って取れてしまった。VPNを切っているから安全、というのに依存しすぎだと思う」。裏のデータベースはそのまま使いつつ、権限制御を細かく組みやすいモダンなアプリ側で入口を作り直したほうが、セキュリティ水準はむしろ上がります。機能単位の権限分離、操作履歴、本番とトレーニング環境の分離——こうした統制は、20年前の基盤の上に後から足すより、外側の新しいアプリに実装するほうがはるかに簡単です。

この考え方は、基幹をSAPのまま正とする案件でも使えます。実際に私たちが入っているある合成樹脂・産業資材メーカーでは、基幹のSAPを正としたまま、見積計算をAPI化し、「秘伝のタレ」と呼ばれていた属人的な工賃表のマスター化から着手しています。SAPを置き換える話ではありません。SAPに作り込まずに済ませる話です。

外に出したアドオンは、誰が保守するのか

ここを決めずに②の箱を選ぶと、数年後に同じ問題が再発します。アドオンをERPの外に移しただけでは、保守の重さは消えません。

ある大手化学メーカーの執行役員が率直に言っていました。「一度作ったら、メンテナンスはさすがにできない。ある程度は内製化していかないと世の中の力についていけない」。同じ会社の別の担当者は、社内開発の停滞をこう振り返っています。「個別にプログラミングで作ったシステムの運用・管理が昔からの課題」「『内製できます』と謳いつつ実際は難しい」。

だから私たちは、外に出す判断と内製化の体制づくりをセットで設計します。やり方は泥臭いものです。顧客の内製担当者に渡すガードレールは、最初はこの2本だけにします。

• データベースを直接いじらない。 「DBをいじると、もう後戻りできない。自分のブランチをどんだけ汚そうが、DBさえ直接いじらなければ大丈夫」という線引きです。
• 本流に直接反映せず、まずPRを上げる。 変更の提案をいったん別の場所に出し、AIが中身をレビューして妥当性を判定してから取り込む。人の目はその後に入ります。

この2本だけで、非エンジニアの担当者が壊せる範囲はかなり小さくなります。そして本番反映は二段階にします。先にステージング（本番と同じ構成の検証環境）で直して回帰テストが通ってから本番に出す。トレーニング環境は背景色を黄色にして、ひと目で本番と区別できるようにする。地味ですが、この種の運用設計があるかどうかで、1年後に内製が続いているかが決まります。

私たちの現場経験では——「秘伝のタレ」から手をつけるのが早い

②の箱に入れたアドオンのうち、どれから着手するか。私たちの答えは、現場が一番困っていて、かつ基幹の移行判断を待たなくていいものです。7割以上の案件でそれは、Excelで配信されている属人的な計算ロジックでした。

理由は3つあります。1つ目は、効果が出たことを現場がすぐ実感できる。2つ目は、ERP本体に触らないので移行プロジェクトと競合しない。3つ目は、ここを言語化しておくと、移行の要件定義そのものが軽くなるからです。原価計算の判断基準が整理されていれば、「SAPに原価計算のアドオンを作る」という要件は小さくできます。

進め方は動くものを先に見せる形をとります。ヒアリングで聞いた内容を、1日で動くプロトタイプにして持っていく。資料で合意形成をしません。私たちの商談の成約率が9割を超えているのは、営業がうまいからではなく、動くものを見せているからです。基幹刷新の現場でも同じで、「思っていたのと違う」という最悪の結末を避ける手段がこれしかないと考えています。

正直に言うと、この進め方には弱点もあります。動くものを早く見せると、現場の要望が一気に増えます。だから並行して「今回はここまで」という線を引く作業が必要になる。ここは私たちも毎回苦労していて、イシュー（課題票）を管理しやすい単位で切って順番に検証する運用で凌いでいます。AIで議事録からまとめて起票すると、全部が自分の名前の大きな課題になってしまい、何が残っているか分からなくなるためです。

数億円のRFPを出す前に、この5問に答えられるか

社内で使える自己診断を置いておきます。RFP（提案依頼書）を出す前に、情報システム部門だけでなく事業部の責任者と一緒に答えてみてください。

1. アドオンの本数と、直近12か月の起動回数を一覧で出せますか。 出せない場合、見積もりはぶれます。
2. 法令・会計基準で決まっているアドオンは、全体の何割ですか。 ここが①の箱の上限です。
3. 「これを標準に寄せたら競争力が落ちる」と事業部が言える機能を、3つ挙げられますか。 3つより多い場合は、まだ仕分けが終わっていません。
4. 外に出す候補の業務について、現場の誰が毎日触っているか分かりますか。 名前が出てこない業務は、③の箱かもしれません。
5. 移行後1年目に、バージョンアップ対応へ何人日を見込んでいますか。 答えがない場合、アドオンの維持費が見積もりから抜けています。

5問のうち2問以上で答えが出ないなら、ベンダー選定より先に棚卸しをするほうが安く済みます。私たちの経験では、この棚卸しに要する期間は数週間です。数億円の判断の前に置くコストとしては小さい。

この判断で失敗する3つのパターン

成功例だけ並べても判断材料にならないので、私たちが見てきた失敗も書いておきます。

1つ目は、全部を外に出そうとすること。 ②の箱が魅力的に見えるのは分かります。ただ、会計基準で決まっている処理を自前で持つと、法改正のたびに自社で対応することになります。ここは標準に乗ったほうが、長い目で見て手間が少なくて済みます。外出しは「自社でルールを決められる領域」に限る。この線を越えると、数年後に新しいアドオン地獄を自分で作ることになります。

2つ目は、棚卸しを移行ベンダーに丸投げすること。 移行の見積もりを出す会社が仕分けの判断も握ると、構造的に「残す」方向へ寄ります。悪意の話ではありません。残すと決めれば工数が確定し、提案の確実性が上がるからです。仕分けは発注側が持つべき判断で、第三者の視点を入れるならベンダー選定の前に入れるのが筋だと考えています。

3つ目は、AIの利用料を読まずに外出しを決めること。 先に紹介した建材メーカーで情報システムを統括する方は「AIの利用料はやり方によっては上がる可能性もゼロではない」と繰り返し気にしていました。この懸念は正しい。私たち自身も、開発環境では無料のライブラリが公開環境だと課金対象になり、本番リリース時に想定外の請求が出かかった経験があります。自前の実装に差し替えて消しました。外出しの試算には、運用1年目の推論コストと外部サービス費用を入れてください。

よくある質問

Q1. 延長保守で2030年まで延ばすのは、悪い選択ですか。

悪くはありません。問題は、延ばした3年に何をするかを同時に決めていない場合です。保守料率に2パーセントポイント上乗せして時間を買う契約だと理解したうえで、買った時間でアドオンの棚卸しと外出しの先行着手まで終わらせる計画なら、合理的な選択だと考えています。決めずに延ばすと、2030年に同じ会議をやることになります。

Q2. アドオンを外に出すと、監査やデータの整合性で問題になりませんか。

基幹システムをマスターと実績の正本に保ち、外側のアプリからは決まった経路でしか書き込ませない設計にすれば、整合性は保てます。むしろ機能単位の権限分離や操作履歴は、新しいアプリ側のほうが実装しやすい。私たちが案件で欠かさず入れるのは、全変更を履歴に残して安全に巻き戻せる仕組みです。監査対応はそこから出力します。

Q3. S/4HANA移行はブラウンフィールドが最多だと聞きました。それに合わせるべきですか。

電通総研の2025年度調査ではストレートコンバージョンが47.6%で最多でしたが、多数派であることと自社に適していることは別です。ブラウンフィールドは現行を引き継げる反面、引き継ぐ量がそのままコストと保守負荷になります。アドオンの棚卸しを先に済ませておけば、どの方式でも投資額は下がります。順番としては、方式の選定より棚卸しが先です。

Q4. 情報システム部門に人手がなく、棚卸しに着手できません。

その状態が普通だと思います。だから私たちは、業務の棚卸しから入る無償の業務プロセス診断（BPR：業務プロセスの見直し）を用意しています。代表が自作した業務整理ツールを使い、ヒアリングから業務フロー・改善案・投資回収の試算までをたたき台として一気に可視化します。数週間で、仕分けの一次案までは出せます。

Q5. SAPを使っていませんが、同じ考え方は使えますか。

使えます。国産ERPでも、AS/400などの自社開発資産でも、構造は同じです。実際に私たちが入っている案件では、設備工事会社の基幹システムをAS/400から段階的に移す仕事や、既存の基幹SaaSから自社の基幹システムへ移す仕事が進んでいます。保守切れという期限がない分、むしろ仕分けの順番を自由に組めます。

まず試すなら

明日から着手できる順に3つ挙げます。

1. アドオンの一覧と、直近12か月の起動回数を出す。 本数だけでは判断できません。起動回数が付いた一覧が、仕分けの出発点になります。情報システム部門だけで完結できる作業です。
2. 事業部の責任者に「標準に寄せたら競争力が落ちる機能」を3つ挙げてもらう。 挙がった3つが②の箱の中心になります。4つ以上出てきたら、なぜそれが競争力なのかを一つずつ言語化してください。
3. ②の箱の1本を、1日で動くプロトタイプにして現場に見せる。 資料ではなく動くものを見せると、議論の質が変わります。基幹の移行判断を待たずにできます。

3番目で手が止まるなら、そこから一緒にやるのが私たちの仕事です。AI-Path では、無償の業務プロセス診断（BPR）を実施しています。基幹刷新の前に、どの業務を標準に寄せ、どこをAIで外に出し、何を捨てるか——その一次案までを、現場のヒアリングから作ります。お問い合わせからご連絡ください。

刷新そのものの進め方は別記事に書きました。「触れない基幹システム」をAIエージェントで刷新するです。棚卸しの手順はAI導入より先にやるべきことにまとめています。SaaSに依存しない基盤の考え方は脱SaaSで「自社のAI OS」を持つという選択が参考になります。

参考リンク

保守期限の一次情報（本文「2027年末と2030年末」の出典）。

• SAP公式: Maintenance Strategy for SAP S/4HANA and SAP Business Suite 7

移行費用と移行方式の調査（本文「5億円超が半数以上」「47.6%」の出典）。

• 電通総研: 国内295社への独自調査「SAPユーザー意識調査結果2025年度版」を発表（2025年12月17日）

アドオン削減の実例（本文「約450件が約1割」の出典）。

• SAP Japan: 日本郵船、SAP S/4HANA Cloud Public Editionを国内最大規模で導入