S/4HANAアドオン変換に「1本6万円」の単価が出た｜基幹システム刷新の見積もりを分解する視点

結論：刷新の見積もりが高いのではなく、自社が積み上げてきたカスタマイズの量が見えていない

TISI（TISとインテックの合併により2026年7月に発足）が2026年7月24日、「SAP S/4HANA アドオン クリーンコアコンバージョンサービス」の提供を開始しました。既存のアドオン（独自に作り込まれた追加プログラム）を、SAPが定める「クリーンコア レベルB」に適合する形へ自動変換するというものです。SAPはクリーンコアの水準をA〜Dの4段階で定義しており、そのうちAとBがクリーンコアとされています。つまりレベルBは、クリーンコアと認められる範囲の下限にあたります。

技術的な特徴として、AIによる推論ではなくルールベースの機械的な変換を採用している点が挙げられています。生成AIによる変換で懸念される「もっともらしいが誤った変換」のリスクを避け、変換結果の説明可能性を確保する狙いです。適合の検証にはSAP公式のABAP Test Cockpitを用いるとされています。2030年度までに約20社での採用を目標としています。

そして、本記事が注目するのは技術ではなく価格です。公表された価格は次のとおりです。

• アセスメント（全アドオンの分析）：500万円（税抜）
• 実装（変換とテスト）：基本700万円（税抜）＋アドオンプログラム1本あたり6万円（税抜）

この「1本6万円」という単価が、基幹システム刷新を検討している経営者にとって、これまでになく実用的な意味を持ちます。刷新費用を、初めて掛け算で捉えられるようになるからです。

アドオンが100本なら、変換部分だけで基本700万円＋600万円。500本なら700万円＋3,000万円。この計算が成り立つということは、逆に言えば、アドオンを減らせば費用が落ちるということでもあります。

3行サマリー（先に結論）

• TISIがS/4HANAのアドオンをクリーンコア準拠へ機械変換するサービスを発表（2026年7月24日）。アセスメント500万円、実装は基本700万円＋1本あたり6万円。
• この単価の公表により、基幹システム刷新の費用を「アドオン本数×単価」という形で概算できるようになった。
• したがって、刷新の見積もりを取る前にやるべきは相見積もりではなく、アドオンの棚卸しと廃止判断である。使われていないものを移行しないだけで、費用は下がる。

要点表：サービスの概要

※価格・サービス内容の詳細は、提供元の公式発表でご確認ください。

「クリーンコア」とは何を言っているのか

聞き慣れない言葉なので、経営者向けに整理します。

基幹システムのパッケージ製品は、標準の機能を持っています。しかし多くの企業は、自社の業務に合わせて追加のプログラムを作り込みます。「うちの承認フローは3段階だから」「この帳票の様式は取引先の指定だから」「この計算ロジックは創業以来の商習慣だから」。こうして積み上がったものがアドオンです。

アドオンには実利があります。業務を変えずにシステムを導入でき、現場の抵抗も少ない。導入プロジェクトを短期間で終わらせるには、有効な手段です。

問題は、その後に起きます。

• パッケージのバージョンアップのたびに、アドオンが動くか検証する必要がある。
• 検証と修正に費用がかかるため、バージョンアップが見送られる。
• 見送りが続くと、サポート期限に追い詰められる。
• そのころには、アドオンを作った担当者もベンダーの担当者も入れ替わっている。
• 何のために作ったのか誰も説明できないアドオンが、大量に残る。

「クリーンコア」という考え方は、この悪循環を断つために出てきたものです。製品の中核部分（コア）に手を入れず、拡張は決められた作法に沿って外側で行う。そうすれば、バージョンアップのたびに全部を検証し直す必要がなくなります。

今回のサービスは、既に作り込まれてしまったアドオンを、その作法に沿った形へ機械的に書き換えるものです。裏を返せば、それだけの需要があるほど、多くの企業が作法から外れたアドオンを抱えているということです。

自社の刷新費用を概算してみる

公表された単価を使って、簡易な概算をしてみます。あくまで一つの目安であり、実際の見積もりとは異なりますが、議論の出発点にはなります。

これにアセスメントの500万円が加わり、さらに移行そのものの費用、データ移行、テスト、教育、並行稼働の費用が乗ります。つまり変換部分は全体の一部にすぎません。

それでも、この表には価値があります。「うちのアドオンは何本ありますか」という質問が、金額に直結する質問になるからです。

そして多くの企業で、この質問には答えられません。「たくさんあります」「情シスに聞かないと分かりません」「ベンダーが管理しています」。この状態のまま刷新の見積もりを取ると、総額の妥当性を検証する術がありません。

見積もりの前にやるべきこと：アドオンの棚卸し

刷新を検討している企業に、まず提案したいのは相見積もりではありません。アドオンの棚卸しです。

手順1：一覧を出してもらう 現在のシステムベンダー、または保守委託先に、アドオンの一覧を依頼します。プログラム名、作成時期、担当した部署、概要が分かる形が理想です。「そんな資料はない」と言われることもありますが、システム上は抽出できることが多いので、粘って依頼してください。

手順2：使用状況を調べる 各アドオンが、直近1年でどれくらい使われているかを調べます。実行回数のログが取れる場合はそれを、取れない場合は所管部署へのヒアリングで補います。ここで、まったく使われていないアドオンが相当数見つかるのが通例です。

手順3：4象限に分類する

右下の「廃止候補」に入ったものは、移行しないという選択が可能です。ここに入る本数が多いほど、刷新費用は下がります。

手順4：廃止の合意を取る ここが最も難しく、最も価値のある工程です。「使っていないから廃止しましょう」と提案すると、必ず「いつか使うかもしれない」という反応が返ってきます。この議論を、刷新プロジェクトが始まってから行うと、期限に追われて全部移行という結論になりがちです。だから、見積もりを取る前の、時間に余裕がある段階でやるべきです。

廃止の合意を取る際の実務的なコツを一つ挙げます。「廃止」ではなく「今回は移行しない。必要になったら改めて作る」という言い方にすると、合意が得やすくなります。実際、必要になることはほとんどありません。

この考え方はSAP以外にも使える

ここまでSAPを例に説明してきましたが、構造は他のシステムでも同じです。

• 国産のERPパッケージ（奉行、GRANDIT、OBIC等）でも、カスタマイズの積み上げは起きます。
• 独自開発（スクラッチ）の基幹システムでは、機能追加の履歴がそのままアドオンに相当します。
• 業務パッケージやSaaSでも、独自の設定・カスタム項目・連携処理が同じ役割を果たします。

したがって、次の問いはシステムの種類を問わず有効です。

現在のシステムに、標準機能ではない独自の作り込みが何箇所あり、そのうち直近1年で実際に使われているのは何箇所か。

この問いに答えられる会社は、刷新の見積もりを検証できます。答えられない会社は、提示された総額を受け入れるしかありません。

移行方式によって、費用の構造が変わる

アドオンの扱い方には、大きく3つの方式があります。それぞれ費用の発生の仕方が違うため、見積もりを読むときの前提として押さえてください。

方式1：変換する（コンバージョン）

既存のアドオンを、新しい環境で動く形へ機械的または半自動で書き換える方式です。今回のサービスはこの類型に当たります。

• 費用の構造：本数に比例する。本数が多いほど直線的に増えます。
• 期間：比較的短い。
• 利点：現行の業務をほぼそのまま継続できる。現場の抵抗が小さい。
• 欠点：過去の負債もそのまま引き継ぐ。「なぜこの処理があるのか」は解決されない。

方式2：標準機能に寄せる（再構築）

アドオンを廃止し、パッケージの標準機能で業務を回す方式です。

• 費用の構造：業務変更の範囲に比例する。本数より、変える業務の数と関係部署の多さで決まります。
• 期間：長い。業務の合意形成に時間がかかります。
• 利点：将来のバージョンアップが軽くなる。負債が減る。
• 欠点：現場の業務が変わるため、抵抗と教育コストが発生する。

方式3：外側に作り直す（拡張の分離）

アドオンの機能を、パッケージの外側に別のアプリケーションとして作り直す方式です。

• 費用の構造：機能の複雑さに比例する。単純な処理は安く、複雑なものは高くなります。
• 期間：中程度。
• 利点：パッケージ本体を汚さない。将来の入れ替えが容易。
• 欠点：管理する対象が増える。連携の設計が必要。

実際の案件では、この3方式を組み合わせます。「業務上重要で複雑なものは方式3、単純なものは方式1、使われていないものは廃止」といった振り分けです。

**そして、この振り分けを決めるための材料が、前節の棚卸し結果です。**棚卸しをせずに方式を選ぶと、全部を方式1（変換）で処理することになり、費用が最大化します。

棚卸しの記録テンプレート

実務でそのまま使える記録項目を示します。表計算ソフトで作れば十分です。

最後の行を必ず入れてください。移行プロジェクトが進むと「なぜこれを廃止したのか」という議論が必ず蒸し返されます。誰がいつ判断したかが記録されていれば、その議論に時間を取られずに済みます。

廃止の合意形成——最も難しい工程をどう進めるか

技術的には簡単でも、組織的には最も難しいのが「使っていないアドオンを移行しない」という合意です。実務的な進め方を示します。

進め方1：データを先に出す

議論の前に、実行回数の実測値を出します。「使っていますか」と聞くと「使っています」と返ってきますが、「直近12ヶ月で3回です」というデータがあれば、議論の質が変わります。

進め方2：廃止ではなく「今回は移行しない」と表現する

言葉の問題ですが、効果があります。「廃止」は永久の削除を連想させ、抵抗を招きます。「今回の移行対象から外す。必要になったら改めて検討する」という言い方なら、合意が得やすくなります。

進め方3：判断の期限を切る

「検討します」のまま止まるのを防ぐため、判断の期限を設定します。期限までに移行が必要という判断が出なければ、対象外とする——という運用を、プロジェクト開始時に合意しておきます。

進め方4：経営が方針を出す

「原則として、直近12ヶ月に使用実績のないものは移行対象外とする。例外は個別に申請する」という方針を、経営として先に出します。方針がないと、すべての判断が個別の交渉になり、時間が足りなくなります。

進め方5：費用を見せる

「このアドオンを移行すると、変換だけで◯万円かかります」という数字を示すと、判断が変わることがあります。無料だと思われているものに値札が付くと、必要性の議論が現実的になります。

今回のサービスが単価を公表したことの実務的な意義は、まさにここにあります。値札を付けられるようになったということです。

ベンダー提案の読み方：「クリーンコア対応」の中身を聞く

今後、刷新の提案書に「クリーンコア対応」「標準機能を最大限活用」といった表現が増えると予想されます。この表現を見たとき、確認すべき点を挙げます。

確認1：どの水準を目指すのか クリーンコアには段階があります。今回のサービスが目指すのはレベルBとされています。提案が「クリーンコア対応」とだけ書いてある場合、どの水準を、どの範囲で目指すのかを聞いてください。

確認2：既存アドオンをどう扱うのか 全て変換するのか、一部は作り直すのか、廃止を前提とするのか。方針によって費用も期間も大きく変わります。

確認3：標準機能に合わせるための業務変更はあるか 「標準機能を活用する」とは、多くの場合「業務のやり方を標準に合わせる」ことを意味します。どの業務が、どう変わるのかを具体的に示してもらってください。ここが曖昧なまま契約すると、稼働直前に現場が反発します。

確認4：変換の品質をどう保証するのか 機械変換にせよ手作業にせよ、変換後に同じ結果が出ることをどう確認するのか。テストの範囲と、その費用が見積もりに含まれているかを確認します。

確認5：見積もりの内訳 アドオンの変換、データ移行、テスト、教育、並行稼働、移行後の保守。それぞれの金額を分けて示してもらってください。総額だけの見積もりは、比較も交渉もできません。

刷新を「先送りする」判断について

最後に、公平のために書いておきます。刷新は常に正解ではありません。次の条件が揃っているなら、延命を選ぶ判断も合理的です。

• 現行システムの保守が確実に受けられる期間が、まだ数年ある。
• 業務の変化が少なく、システムが事業の足を引っ張っていない。
• 刷新に投じる資金を、より収益に直結する投資に回したい。
• 数年以内に事業構造の変更（M&A、業態転換等）が予定されており、そのあとに刷新したほうが合理的。

ただし、延命を選ぶ場合でも、アドオンの棚卸しだけはやっておくべきです。理由は3つあります。第一に、いつか必ず刷新の判断が必要になり、そのとき棚卸しの結果が効きます。第二に、棚卸しの過程で「使われていない処理が毎晩動いている」といった無駄が見つかります。第三に、システムを理解している人が退職する前に、記録として残せます。

FAQ

Q1. アドオンの本数はどうやって数えますか。 A. システムベンダーに一覧の抽出を依頼するのが確実です。プログラム単位で数えるのか、機能単位で数えるのかによって数字が変わるため、数え方も合わせて確認してください。

Q2. 「1本6万円」は安いのですか、高いのですか。 A. 単価の妥当性は、変換の難易度と品質保証の範囲によります。判断すべきは単価の高低より、この単価を基準に自社の総額を概算できること、そして本数を減らせば総額が下がると分かることです。

Q3. うちはSAPを使っていません。関係ありますか。 A. サービス自体は関係ありませんが、「独自の作り込みが刷新費用を押し上げる」という構造は共通です。棚卸しの手順はそのまま使えます。

Q4. アドオンを減らすと、業務が回らなくなりませんか。 A. だからこそ使用頻度と重要度の両面で見ます。使われていないものを減らすのであって、必要なものを削るわけではありません。判断は現場を交えて行ってください。

Q5. 棚卸しにはどれくらいの期間がかかりますか。 A. 規模によりますが、一覧の抽出に数週間、使用状況の調査と分類に1〜2ヶ月、廃止の合意形成にさらに1〜2ヶ月というのが目安です。刷新の検討開始より前に始めるべき理由がここにあります。

Q6. ベンダーが一覧を出してくれません。 A. 保守契約の範囲外だと言われる場合があります。その場合でも、有償での抽出を依頼する価値はあります。この一覧がないまま刷新を進めるほうが、はるかに高くつきます。

Q7. 生成AIで変換すればもっと安くなりませんか。 A. 今回のサービスがあえてルールベースを選んでいる点が示唆的です。変換結果の正しさを説明できることが、基幹システムでは重視されます。安さだけで方式を選ぶと、検証の費用が増えて逆転する可能性があります。

GXOに相談すべきタイミング

次のいずれかに当てはまるなら、見積もりを取る前の整理をおすすめします。

• 基幹システムの刷新を検討しているが、提示された金額の妥当性を判断できない。
• 現行システムにどれだけのカスタマイズがあるか、社内で誰も把握していない。
• 複数社から見積もりを取ったが、前提が違いすぎて比較できない。
• 刷新すべきか延命すべきか、判断の材料が足りない。

GXOは特定のERPパッケージを販売する立場ではないため、「刷新しない」という結論も含めて中立に整理できます。基幹システムの棚卸しと刷新計画、見積もりの第三者点検はシステム開発・DXの相談、刷新後を見据えたデータ活用の設計はデータ基盤・データ活用の相談、AI活用まで含めた投資判断の整理はAI導入診断、現状の把握から始めたい場合はDX成熟度診断が入口です。アドオンの棚卸しの進め方からご相談いただけます。窓口はお問い合わせです。

刷新の見積もりが1億円だったとして、その内訳のかなりの部分は、過去10年に自社が作り込んできたものの引っ越し代です。引っ越す荷物を減らす作業は、見積もりを取る前にしかできません。

参考文献

• TISI「TISI、SAP S/4HANAアドオンのclean core化を支援する新サービスを提供開始」（一次・公式リリース、2026年7月24日。価格・水準定義・目標社数・今後の予定はここで確認）: https://www.tisi.jp/news/2026/tisi_news/20260724_1.html
• IT Leaders「TISI、S/4HANAのアドオンを"クリーン"に」（二次・報道）: https://it.impress.co.jp/articles/-/29619

※サービスの内容、価格、クリーンコアの水準定義については、提供元およびSAPの公式情報を一次情報としてご確認ください。本稿に示した概算は議論の出発点を示すためのものであり、実際の見積もり額を保証するものではありません。執筆時点は2026年7月24日です。