SAPアドオン開発とは？標準機能との違い・開発手法・注意点を解説

SAPアドオン開発は、標準機能では対応できない業務要件を実現するための拡張開発です。
しかし、ECC時代に「何でもアドオンで対応」してきた結果、数百〜数千本のZプログラムを抱え、アップグレード困難・保守負担増大・ブラックボックス化に直面している企業は少なくありません。

S/4HANAやクラウドへの移行が進む2026年現在、SAPはClean Core Extensibility 4レベルモデルを体系化し、ABAP CloudやBTP拡張を前提とした設計思想への転換を推進しています。
本記事では、SAPアドオン開発の基本から実装手法、標準機能との使い分け、2026年最新の設計指針・費用構造まで、実務で押さえるべきポイントを体系的に整理します。

SAPアドオン開発とは

SAPアドオン開発とは、SAPの標準機能だけでは実現できない業務要件に対応するため、追加で実装するカスタム開発全般を指します。
SAPでは「Z開発」「カスタム開発」「拡張開発」などとも呼ばれ、標準のトランザクションコード・テーブル・プログラムに対して、独自の機能を追加する形で実装されます。

カスタマイズとの違い

SAPの「カスタマイズ」と「アドオン開発」は混同されやすいポイントです。両者の違いを整理します。

観点	カスタマイズ（コンフィグレーション）	アドオン開発
作業内容	標準機能のパラメータ設定・テーブル調整	独自プログラムの新規開発
技術レベル	ノーコード（設定画面で完結）	ABAPやBTPでのプログラミング
アップグレード影響	原則として影響なし	影響調査・改修が必要
代表例	勘定コード体系の設定、承認階層の定義	独自帳票、外部システム連携、業務ロジック追加

カスタマイズはSAPが想定した設定範囲内での調整であり、アップグレード時にも影響を受けにくいのが特徴です。一方、アドオン開発はSAPが想定していない要件を独自に実装するため、将来の保守・アップグレードに影響する可能性があります。実務ではまずカスタマイズで実現できないかを検討し、それでも対応できない場合にアドオン開発を検討するのが基本方針です。

代表的な開発対象

アドオン開発でカバーする領域は幅広く、代表的な例として次のようなものがあります。

• 帳票・レポート出力
  標準では用意されていない形式の請求書、納品書、分析レポートなど
  
  

• 画面・入力フォームの追加
  業務特有の入力項目や承認フローを組み込んだ独自画面
  
  

• データ連携・インターフェース
  SAPと外部システム（EDI、EC、CRM、MESなど）とのデータ授受
  
  

• 業務ロジックの追加・変更
  在庫引当ロジック、価格決定ロジック、承認ワークフローなど、標準では対応できない独自ルール
  
  

• バッチ処理・自動化
  夜間の集計処理、定期的なマスタ更新、データクレンジングなど
  
  

これらを、SAPの内部（ABAPプログラム）や外部基盤（SAP BTP、外部API連携など）を使って実装するのがアドオン開発です。

必要になる理由

SAPは業種・業務を問わず利用できる汎用ERPですが、個別企業の業務プロセスや商習慣をすべて標準機能でカバーすることはできません。
そのため、次のような理由でアドオン開発が発生します。

• 業界固有・企業固有の業務ルール
  業種特有の取引形態、独自の在庫管理方法、特殊な価格決定ロジックなど
  
  

• 既存業務プロセスとのギャップ
  長年運用してきた業務フローを、そのままSAP標準に置き換えるのが難しい場合
  
  

• 法規制・コンプライアンス対応
  国・地域ごとの会計基準、税制、商取引法など、標準機能では対応しきれない要件
  
  

• 外部システムとの連携要件
  既存の生産管理システム、Webサイト、EDIネットワークなど、SAPの外にある資産との接続
  
  

このように、アドオン開発は**「SAPを自社の業務に適合させるための必要な手段」**として位置付けられます。

メリットとデメリット

一方で、アドオン開発には明確なトレードオフがあります。

メリット

• 標準機能では実現できない業務要件をカバーできる
• 既存の業務プロセスをそのまま維持しやすい
• 競合優位性につながる独自機能を実装できる

デメリット

• アップグレード時に影響調査・改修が必要になる
• 保守・運用の負担が増大し、ブラックボックス化しやすい
• クラウド移行やS/4HANA化の際に、そのまま持ち込めない場合がある

特に、オンプレミスのECC時代に**「標準機能をカスタマイズするのではなく、何でもアドオンで実装する」**という方針で進めてきた企業では、数百〜数千本のZプログラムを抱え、将来の刷新プロジェクトで大きな負担となるケースが少なくありません。

そのため、S/4HANAやクラウド時代においては、**「アドオンをどう作るか」だけでなく、「そもそもアドオンを作るべきか」**を含めて判断する設計思想が求められています。

SAPアドオン開発の主な実装手法

SAPアドオン開発には、複数の実装アプローチがあります。ここでは、代表的な開発手法とその使い分けを整理します。

ABAP開発によるSAP内部での拡張

ABAP（Advanced Business Application Programming）は、SAP専用のプログラミング言語で、SAPシステムの内部で動作するアドオンを開発するための主要な手段です。

ABAP開発では、SAP標準テーブルへのデータ追加・更新、独自トランザクションコード（Zトランザクション）の作成、カスタムテーブル（Zテーブル）の定義、帳票出力（ALV、Adobe Forms、Smart Formsなど）、バッチ処理・ジョブスケジューリング、ユーザーExit・BAdI・Enhancementといった標準拡張ポイントの活用が可能です。

以下の表でABAP開発の特徴を整理しました。

観点	内容
開発環境	SAP GUI、Eclipse（ABAP Development Tools）
実行環境	SAPシステム内部（アプリケーションサーバー上）
学習コスト	SAP特有の言語・概念を習得する必要があり、初学者には敷居が高い
標準機能との統合	SAPの標準テーブル・ロジックに深く統合できる
保守性	アップグレード時に影響を受けやすく、改修コストが発生しやすい

ABAP開発は、SAP内部で完結する処理や、標準機能との深い統合が必要な場合に適しています。

SAP BTPを使った拡張

SAP BTPは、クラウド上でSAPの拡張アプリケーションを開発・実行するためのプラットフォームです。
S/4HANA CloudやRISE with SAPなど、クラウド前提の環境では**「コアERPはクリーンに保ち、拡張はside-by-sideで実装する」**設計思想の有力な選択肢がBTPです。S/4HANA Cloud Public Editionにもin-app拡張（key user extensibility・developer extensibility）はありますが、コアと分離して柔軟に開発したい場合にBTPが適しています。

BTP拡張では、ローコード／ノーコード開発（SAP Build Apps、SAP Build Process Automationなど）、Node.js・Java・Pythonなどの汎用言語を使ったカスタムアプリ開発、SAP Fioriアプリの拡張・独自画面の作成、SAP外部サービス（Salesforce、Microsoft 365など）とのAPI連携、データ統合・分析基盤（SAP Datasphere、SAP Analytics Cloud）との接続が可能です。

以下の表でBTP拡張の特徴を整理しました。

観点	内容
開発環境	クラウドベースの開発ツール（SAP Business Application Studioなど）
実行環境	BTPクラウド基盤上（SAPコアシステムとは分離）
学習コスト	汎用言語・Webフレームワークの知識があれば参入しやすい
標準機能との統合	APIやOData経由での連携が中心。コア側のテーブルには直接触れない
保守性	コアシステムと分離されているため、アップグレードの影響を受けにくい

BTPは、SAPコアと分離したside-by-side拡張や、外部サービスとの連携が中心の場合に適した選択肢です。S/4HANA Cloud Public Editionでもdeveloper extensibilityによるin-app開発は可能なため、要件に応じてin-appとside-by-sideを使い分けます。

外部システム連携による拡張

SAPとは別に外部システム側でロジックを実装し、API・ファイル連携・RFC（Remote Function Call）などでSAPとデータをやり取りする方法もあります。

外部連携の代表例として、IDoc・RFC・OData・REST APIなどを使った他システムとのデータ授受（EDI・データ連携基盤）、SAPからデータを抽出してTableau・Power BI・Lookerなどで可視化するBI・分析ツール連携、SAP GUIの操作を自動化したり承認プロセスを外部ワークフローツールで実装するRPA・ワークフロー自動化があります。

以下の表で外部連携の特徴を整理しました。

観点	内容
開発環境	外部システム側の環境（ETLツール、BIツール、RPAツールなど）
実行環境	SAP外部
学習コスト	SAP特有の知識は限定的。連携方式（API、IDocなど）の理解が必要
標準機能との統合	データレベルでの連携が中心。SAP内部ロジックへの介入は限定的
保守性	SAP側の変更影響を受けにくいが、インターフェース仕様の維持が必要

外部連携は、SAPをデータソースとして活用し、分析・可視化・他システム連携を外部で行う場合に適しています。

実装手法の使い分け

それぞれの手法をどう使い分けるかは、次のような観点で判断します。

要件の性質	推奨される実装手法
SAP標準機能との深い統合が必要	ABAP開発（ユーザーExit、BAdIなど）
独自の入力画面・承認フローを作りたい	BTP拡張（SAP Fiori、Build Apps）
外部クラウドサービスと連携したい	BTP拡張 or 外部連携
SAPをデータソースとして分析したい	外部連携（BI・分析ツール）
クラウド移行を見据えてクリーンに保ちたい	BTP拡張

S/4HANA Cloud環境では、key user extensibility（ノーコード）・developer extensibility（ABAP Cloud）・side-by-side extensibility（BTP）の3系統を要件に応じて使い分けます。Public Editionでもdeveloper extensibilityによるABAP Cloud開発が可能ですが、クラシックABAPの自由度とは異なるため、要件によってはPrivate EditionやBTP ABAP Environmentの検討が必要です。

SAP標準機能とアドオンの使い分け

アドオン開発は「何でも実装できる」反面、過度に依存すると将来の保守負担・アップグレードコストが膨らみます。
ここでは、標準機能とアドオンをどう使い分けるべきかの基本的な考え方を整理します。

「標準機能で対応できないか」を最優先で検討する

アドオン開発を検討する前に、まず**「本当に標準機能では実現できないのか」**を確認することが重要です。

標準機能の見落としパターンとして、コンフィグレーション（カスタマイジング）のテーブル設定・パラメータ調整で実現できるのにアドオン開発してしまうケース、ゼロからZプログラムを作るのではなく標準が用意した拡張ポイント（Enhancement、BAdI）を使えば済むケース、FIモジュールだけでなくSDやMMの標準機能・SAP BWなど周辺ツールで対応できる場合があります。

特に、SAPコンサルタントやベンダーが標準機能を十分に把握していないと、「できない」と判断してアドオンに走ってしまうリスクがあります。

アドオン開発を検討すべきケース

一方で、次のような場合は標準機能だけでは対応が難しく、アドオン開発が正当化されます。

• 業界・企業固有の業務ロジック
  標準では想定されていない独自の在庫引当ルール、価格決定ロジック、承認フローなど
  
  

• 外部システムとの連携
  既存の生産管理システム、ECサイト、EDIネットワークとのデータ授受
  
  

• 帳票・レポートの独自フォーマット
  法定帳票や取引先指定の帳票など、標準出力では対応できない形式
  
  

• 法規制・コンプライアンス対応
  国・地域固有の税制、会計基準、商取引法への対応
  
  

ポイントは、「標準機能で我慢できる範囲」と「業務上どうしても譲れない部分」を明確に切り分けることです。

SAPアドオン開発の判断基準

実務では、次のような判断基準を設けてアドオン開発の可否を決めるケースが多くあります。

判断軸	アドオン開発を避けるべき例	アドオン開発を検討する例
業務への影響度	「あったら便利」レベルの機能	業務継続に不可欠な機能
標準機能との代替可能性	標準機能を少し工夫すれば実現可能	標準機能では絶対に実現できない
将来の保守負担	頻繁に変更が発生しそうな要件	一度作れば長期間安定して使える要件
グローバル展開の有無	拠点ごとに異なるローカル要件	全社・全拠点で共通化できる要件
クラウド移行の見通し	S/4HANA Cloudに持ち込めない可能性が高い機能	クラウド環境でも継続利用できる設計が可能な機能

特に、**「クラウド移行やS/4HANA化を見据えた場合に持ち込めるか」**は、今後のアドオン開発判断で極めて重要な観点になります。

「Fit to Standard」の考え方

近年、SAP導入プロジェクトでは**「Fit to Standard（標準に業務を合わせる）」**という設計思想が強調されています。

これは、標準機能をベースに業務プロセスを再設計し、アドオンは最小限に抑えて標準のアップデート恩恵を受けやすくし、「業務を標準に合わせる」ことでグローバル展開やベストプラクティス導入を加速させるという考え方です。

ただし、すべてを標準に合わせることが正解とは限りません。
「競合優位性につながる独自プロセス」や「法規制で譲れない部分」については、適切にアドオンで実装する――この判断ができるかどうかが、プロジェクト成否の分かれ目になります。

SAPアドオン設計思想の変化

SAPを取り巻く環境は、オンプレミスのECC時代からS/4HANA・クラウド時代へと大きく変化しています。
それに伴い、アドオン開発の在り方も根本的に見直す必要が生まれています。

ECC時代のアドオン開発とその課題

オンプレミスのECC時代には、次のようなアドオン開発が一般的でした。

• 標準機能の不足を補うため、画面・帳票・ロジック・連携をすべてABAPで実装
• 標準テーブルに項目を追加したり、標準プログラムを直接修正（Modification）したりすることも珍しくなかった
• バージョンアップ時に全アドオンの影響調査・改修が発生し、膨大なコストと時間がかかる

この結果、アドオンが肥大化してシステム全体がブラックボックス化し、アップグレードのたびに大規模な改修プロジェクトが必要になるなど、多くの企業で深刻な課題が顕在化しました。開発者が退職すると誰も触れない「負の遺産」になり、S/4HANAやクラウドへの移行時にそのまま持ち込めないアドオンが大量に発生しています。

S/4HANA・クラウド時代の新しい設計思想

S/4HANA、特にS/4HANA CloudやRISE with SAPといったクラウド環境では、次のような設計思想が求められます。

コアはクリーンに保ち、拡張は外側で実装する

Clean Coreという考え方が強調されています。S/4HANA本体には極力手を入れず標準のまま保ち、拡張が必要な場合はSAP BTPなど外部基盤で実装します。ABAP開発が必要な場合も、標準の拡張ポイント（BAdI、Enhancement）を活用し、コア部分の改変は避けます。これにより、SAP側のアップデートを継続的に受け入れやすくなり、最新機能やセキュリティパッチを取り込みやすくなります。

継続アップデート前提の設計

クラウド環境では、年に数回のアップデートが標準で提供されます。アドオンも「一度作って終わり」ではなく、アップデートサイクルに合わせて継続的にメンテナンスする前提で設計する必要があります。そのためには、アドオンの数を絞り込んで保守可能な範囲に抑え、ドキュメント整備・テスト自動化など継続運用を支える仕組みも合わせて構築することが重要です。

API・OData経由の疎結合な連携

従来はABAPで直接標準テーブルを読み書きすることが一般的でしたが、S/4HANA・BTP時代ではAPI・OData経由での疎結合な連携が推奨されます。SAPが公開するAPIやODataサービスを使ってデータを取得・更新し、BTP側のアプリケーションはSAPのテーブル構造に直接依存しない設計にします。これにより、SAP側のテーブル構造が変わっても、API仕様が維持されていれば影響を受けにくくなります。

S/4HANA Cloud環境でのアドオン制約

S/4HANA Cloud**（Public Edition）**では、key user extensibility・developer extensibility・side-by-side extensibilityの3系統が用意されています。ただし、クラシックABAPに比べると自由度に制限があります。カスタムテーブル（Zテーブル）の作成は可能ですが、標準テーブルへの項目追加はできません。標準プログラムの直接修正（Modification）は不可で、使えるABAP命令・オブジェクトにもABAP Cloud開発モデルの制約があります。

developer extensibilityで対応できない要件（クラシックABAPへの依存が大きい場合など）は、Private Editionや SAP BTP ABAP Environmentといった選択肢を検討することになります。

SAPアドオン開発の2026年最新動向

2026年に入り、SAPアドオン開発をめぐる環境はさらに進化しています。ここでは、2026年時点で押さえておくべき最新の開発指針とツールを整理します。

Clean Core Extensibility 4レベルモデル

SAPは従来の拡張性ガイドラインを発展させ、Clean Core Extensibility 4レベルモデルを体系化しています。このモデルでは、拡張のアーキテクチャ品質・アップグレード安全性・Clean Core準拠度に基づいて、拡張をA〜Dの4段階に分類します。

以下の表で各レベルの特徴を整理しました。

レベル	分類	概要
Level A	完全準拠	公開済みかつ安定したSAP APIのみを使用。BTPでのサイドバイサイド拡張、またはABAP Cloudモデルでのオンスタック拡張
Level B	準拠	SAPのクラシックAPIやテクノロジーも使用。十分に文書化された安定的なインターフェースを利用
Level C	部分準拠	SAP内部オブジェクトへのアクセスを許容。レガシーシナリオ向けで柔軟性は高いが、アップグレードリスクあり
Level D	非準拠	SAP標準の直接修正（Modification）を含む。Clean Core原則に反し、最もリスクが高い

2026年の新規アドオン開発ではLevel AまたはLevel Bを目標とし、既存のLevel C・Dの拡張は段階的にLevel A・Bへ是正していくことが推奨されています。是正の手段はBTPへのside-by-side化だけでなく、未使用コードの廃止、ABAP Cloud準拠への書き換え、wrapper化など複数のアプローチを要件に応じて使い分けます。SAPはLevel C拡張について、SAP内部オブジェクトの変更履歴（Changelog）を提供し、アップグレード影響の早期把握を支援する仕組みを整備しています。

さらに、RISE with SAPのダッシュボードにはClean Core Extensibility KPIが追加され、自社の拡張がどのレベルに分布しているかを可視化できるようになっています。各拡張にコンプライアンスレベルを割り当てることで、「どこにクリーンアップの投資を集中すべきか」を共通の指標で判断できます。

ABAP Cloudの成熟とVS Code対応

ABAP Cloud開発モデルは2026年に入り成熟度が高まっています。SAP BuildのABAP Cloud環境では、オンスタック（S/4HANA内部）とサイドバイサイド（BTP上）の両方でClean Core準拠の開発が可能になり、構文チェックやライフサイクルサポートを通じてClean Core原則の遵守が自動的に強制されます。

さらに、SAPinsiderによると、ABAP Cloud Extension for VS CodeがQ2 2026に一般提供予定です。ABAP Language Server・ABAP MCP Server・Joule for Developers（AIコーディング支援）が統合され、Eclipse ADT中心だったABAP開発のワークフローが大きく変わります。初期スコープはRAP UIサービス開発ですが、ABAP Cloud開発モデル全般への対応が計画されています。

ABAP AI・Custom Code Migrationの本格化

2026年のSAPアドオン開発で最も注目すべきトピックが、**AI駆動のCustom Code Migration（CCM）**です。これはレガシーABAPコードのS/4HANA移行を支援する機能で、Joule for DevelopersのABAP AI機能が中核を担います。

CCMのAIアシスタントが公式に提供する機能は次の通りです。

• ATC findings（ABAP Test Cockpit検出事項）の詳細説明
  S/4HANAの簡素化リストに基づく検出事項について、原因と対応方法をAIが解説
  
  

• Simplification itemsの説明
  S/4HANA移行に伴う簡素化項目の影響範囲と対応方針をAIが支援
  
  

• ABAPプログラム解説
  レガシーコードのビジネスロジックや処理内容をAIが自然言語で説明し、ブラックボックス化したアドオンの理解を支援
  
  

SAPの公式発表によると、Joule for DevelopersのABAP AI機能は280社以上の顧客、470社以上のパートナー、6,500人以上の社内ABAP開発者に利用されています。ABAP AIのLLMは2億5,000万行以上のABAPコード、3,000万行以上のCDSコードで訓練されており、Q2 2026に一般提供が予定されています。

数百〜数千本のレガシーアドオンを抱える企業にとって、CCMのAIアシスタントはATC検出事項の対応方針策定やレガシーコードの理解を効率化する手段です。S/4HANA移行プロジェクトにおけるカスタムコード分析の工数削減に寄与するため、移行計画の策定時には活用を検討すべきです。

SAP Build・Jouleによるローコード拡張の加速

SAP Build Apps・SAP Build Process Automationに加え、SAP Business AIのJouleがSAP Build Codeに統合されたことで、AIアシスタントを活用したコード生成やUIアプリケーション自動生成が可能になっています。自然言語の指示からデータモデル・ビジネスロジック・UIコンポーネントを一括生成できるため、プロトタイピングの速度が大幅に向上しています。

ITスキルが限定的なビジネスユーザーでもSAP Build Appsを通じて拡張開発に参加しやすくなり、「業務部門が要件を定義→SAP Buildでプロトタイプ作成→IT部門がレビュー・本番化」という協業フローが現実的になっています。

SAPアドオン開発のガバナンスと運用

アドオン開発は、「作って終わり」ではなく、長期的な保守・運用を見据えたガバナンスが不可欠です。
ここでは、実務で押さえるべき管理のポイントを整理します。

アドオン開発のガバナンス体制

無秩序にアドオンが増殖するのを防ぐため、次のような体制・ルールを設けることが重要です。

アドオン開発の承認プロセス

新規アドオン開発はIT部門・業務部門を含めた承認が必要です。「標準機能で対応できないか」「既存アドオンを流用できないか」を必ず確認し、開発コスト・保守コストを含めたTCO試算を行い費用対効果を判断します。

アドオン台帳の整備と可視化

全アドオンをリスト化し、用途・開発者・保守担当・最終更新日などを記録します。「誰も使っていないアドオン」「ブラックボックス化したアドオン」を定期的に棚卸しし、S/4HANA移行時などの大規模プロジェクトでは、アドオン台帳が最重要インプットになります。

コーディング規約・命名規則の統一

Zテーブル・Zプログラムの命名規則を統一し、誰が見ても用途が分かるようにします。コメント記述・ドキュメント作成のルールを整備し、レビュープロセスを組み込んで属人化を防ぎます。

アドオンのライフサイクル管理

アドオンも「開発→テスト→本番移行→保守→廃棄」というライフサイクルを持ちます。

開発フェーズでは、開発環境・品質環境・本番環境の3層構成を基本とし、トランスポート管理を徹底して変更履歴を追跡可能にします。単体テスト・結合テストのテストケースを文書化することも重要です。

保守・運用フェーズでは、SAPのアップグレード・サポートパック適用時に全アドオンの影響調査を実施し、定期的な動作確認・性能モニタリングで劣化を早期検知します。使われなくなったアドオンは積極的に廃止し、システムをスリムに保ちます。

廃棄フェーズでは、S/4HANA移行時などに「持ち込まない」と判断したアドオンは業務側と合意のうえで廃止し、廃止の経緯・理由をドキュメント化して将来の参考資料とします。

ドキュメント整備と知識の継承

アドオンがブラックボックス化する最大の原因は、ドキュメント不足と属人化です。

必須ドキュメントとして、要件定義書・設計書（なぜそのアドオンが必要だったのか、どういう仕様なのかを記録）、ソースコードコメント（後任者が理解できるよう記述）、運用手順書（ジョブスケジュール・エラー対応・再実行方法など）、テスト仕様書（どのようなテストを行い、何を確認したかを記録）を整備します。

知識継承の仕組みとして、アドオン開発者が退職・異動する前に後任者への引き継ぎ期間を設け、定期的な勉強会・レビュー会を開催してチーム全体でアドオンの知識を共有します。ナレッジベース・FAQを整備し、過去のトラブル事例や対処法を蓄積することも有効です。

セキュリティ・権限管理

アドオン開発では、SAPの内部データに直接アクセスできるため、セキュリティリスクにも注意が必要です。アドオン開発権限（開発者キー、トランスポート権限）は必要最小限に絞り、本番環境での直接開発は原則禁止して必ずトランスポート経由で移行します。個人情報・機密情報を扱うアドオンは、アクセスログ・監査証跡を取得します。

業務部門とIT部門の協働体制

アドオン開発は、IT部門だけで完結するものではありません。業務部門が「本当に必要な要件」を明確に定義し、IT部門が「標準機能とアドオンの使い分け」を技術的に判断し、双方が対話しながら「業務とシステムの最適なバランス」を見つける体制が必要です。

この協働がうまく機能しないと、「IT部門が作ったが業務側が使わない」「業務側が要求したが保守不能なシステムになる」といった事態に陥ります。SAP Build Appsの登場により、業務部門がプロトタイプを作成しIT部門がレビュー・本番化する協業フローも選択肢に入ってきています。

外部パートナーの選定と協業

SAPアドオン開発は専門性が高く、社内リソースだけでは対応しきれない場合も多くあります。パートナーの力を借りる際は、次の点を重視します。

• Clean Core・ABAP Cloudの設計思想を理解しているか
  S/4HANA・BTP時代の設計思想を理解していないベンダーに依頼すると、旧来のECC型アドオンをそのまま作られてしまうリスクがある
  
  

• 丸投げではなく社内にも知識を残す体制か
  開発ドキュメント・テスト仕様書の共有、ナレッジトランスファー期間の設定を契約に含める
  
  

• 継続的な保守・改善まで視野に入れているか
  年に一度の全アドオン棚卸し、不要アドオンの廃止、標準機能への置き換え検討を含めたライフサイクル全体をカバーできるパートナーが望ましい
  
  

SAPアドオン開発の費用とコスト構造

アドオン開発の意思決定では、開発時の初期コストだけでなく、保守・運用を含めた**TCO（総保有コスト）**の視点が欠かせません。ここでは、アドオン開発にかかるコストの目安と、コスト最適化のポイントを整理します。

開発コストの目安

SAPアドオン開発のコストは、開発人材の単価と工数で大きく変動します。2026年時点のフリーランス・ベンダー市場における目安を以下に示します。

職種・レベル	人月単価の目安
ABAP開発者（一般）	90〜130万円/月
SAPコンサルタント	120〜200万円/月
上流設計・アーキテクト（5年以上）	200〜400万円/月

上記は国内市場の目安であり、プロジェクトの複雑性・期間・リモート可否によって変動します。オフショア開発（ベトナム・インドなど）を活用すれば開発単価を抑えられますが、SAP固有の業務知識やコミュニケーション体制の構築が課題になります。

アドオン1本あたりの開発コストは要件の規模によって大きく異なりますが、設計・開発・テスト・移行を含めると1人月（100万円前後）〜数十人月規模に及ぶケースもあります。帳票追加のような小規模なものは数日〜数週間、外部連携や複雑な業務ロジックの実装は数ヶ月かかることも珍しくありません。

保守・運用コストと「隠れたコスト」

アドオン開発で見落とされやすいのが、保守・運用フェーズで発生する継続コストです。

• アップグレード対応コスト
  SAPのサポートパック適用やバージョンアップのたびに、全アドオンの影響調査・改修が必要。アドオン本数に比例して工数が膨らむ
  
  

• 属人化リスクのコスト
  開発者が退職・異動した場合、コードの解読・引き継ぎに数ヶ月を要することがある。ドキュメントが不十分なアドオンほど引き継ぎコストが高い
  
  

• S/4HANA移行時の棚卸しコスト
  レガシーアドオンの分析・廃止・移行判断は、移行プロジェクトの中でも最も工数がかかる領域の一つ
  
  

実際に、NTTアドバンステクノロジはSAP ECC 6.0からS/4HANA Cloud Public Editionへの移行で800本超のアドオンを廃止し、Fit to Standardの徹底により6ヶ月での短期導入を実現しています（SAP Japan事例）。また、日立ハイテクは2018年から2023年にかけて9,000超のアドオンを843本に縮減し、2-Tierモデル（国内: Private Edition、海外: Public Edition）でのクラウドシフトを完了しています。

これらの事例が示すように、アドオンの削減・整理はS/4HANA移行の成否を左右する最大の変数です。

コスト最適化のポイント

アドオン開発のコストを最適化するには、次の観点が有効です。

• 「作らない」を最優先に検討する
  カスタマイズ（コンフィグレーション）や業務プロセスの見直しで対応できるケースは、開発コスト・保守コストともにゼロにできる
  
  

• Clean Coreレベルで設計段階からコストを制御する
  Level A・B準拠の拡張は、アップグレード時の影響調査・改修コストを大幅に削減できる。Level C・Dの拡張は初期開発コストが低くても、長期的な保守コストで逆転する
  
  

• BTP拡張とABAP開発の使い分けでTCOを最適化する
  BTP拡張はSAPコアと分離されているためアップグレード影響を受けにくく、長期的な保守コストが低い傾向にある。一方、ABAP開発はSAP標準との深い統合が必要な場合に適している
  
  

• Custom Code MigrationのAIアシスタントを活用する
  レガシーアドオンのATC検出事項の分析やコード理解にJoule for DevelopersのCCM機能を活用すれば、移行時の分析工数を削減できる
  
  

アドオンで作り込む前に、AIエージェントでの代替を検討する

経費精算・請求書処理・承認フローなど、定型的な判断と実行を繰り返すバックオフィス業務は、ABAPでアドオンを作り込むよりもAIエージェントに任せた方が、保守負荷を抑えつつ柔軟に変化へ対応できます。Clean Core時代の原則は「コアを汚さず、拡張は外出し」です。

AI Agent Hubは、SAP ConcurやDynamics 365と連携し、AIエージェントがバックオフィス業務を自動実行するエンタープライズAI基盤です。アドオン開発なしでSAPデータにFabric OneLake経由でアクセスし、Teamsから呼び出すだけで業務が完結します。自社Azureテナント内で動作するため、カスタムコードの保守リスクを増やすことなく業務の自動化を実現できます。

AI総合研究所は、SAP環境でのAIエージェント導入設計を支援しています。資料で、アドオンに頼らない業務自動化のアーキテクチャをご確認ください。

まとめ

SAPアドオン開発は、標準機能では実現できない業務要件をカバーするための手段ですが、無計画にアドオンを増やし続けると、将来のアップグレード・クラウド移行で大きな足かせとなります。本記事の内容を3点に集約します。

• 新規アドオンはClean Core Level A・Bで設計し、「作らない」選択肢を常に最優先にする
  カスタマイズ（コンフィグレーション）・業務プロセスの見直し・BTP拡張で対応できるケースは、開発コストも保守コストも大幅に抑えられる。NTTアドバンステクノロジの800本超廃止、日立ハイテクの9,000超→843本縮減が示すように、アドオン削減はS/4HANA移行の成否を左右する
  
  

• 2026年はABAP Cloud for VS Code・AI駆動CCMが本格化し、レガシーアドオンの移行を加速する好機
  Joule for DevelopersのCustom Code Migration AIアシスタントを活用すれば、ATC検出事項の分析やブラックボックス化したレガシーコードの理解をAIが支援できる。移行計画の策定段階で活用を検討すべき
  
  

• 開発コストだけでなく、保守・アップグレード・移行時の棚卸しを含めたTCO視点で判断する
  ABAP開発の人月単価は90〜200万円超。初期の開発コストよりも、アップグレード対応・属人化リスク・将来の移行コストが長期的にはるかに大きい。ガバナンス体制・アドオン台帳・ドキュメント整備を初日から設計に組み込むことが、TCOを最小化する鍵になる
  
  

まずは自社のアドオン台帳を棚卸しし、各アドオンをClean Core Extensibilityの4レベル（A〜D）に分類するところから始めてみてください。Level C・Dに該当するアドオンが多い場合は、S/4HANA移行計画と連動させて、廃止・ABAP Cloud化・wrapper化・BTP side-by-side化を使い分ける段階的な是正ロードマップを策定することが次のステップです。