# SAP 2027年問題とAI:移行を急ぐ前に、社内の知識を読めるようにする

> Source: https://netray.co/ja/sap-2027-ai
> Language: ja
> Publisher: Netray (netray.co)
> English version: https://netray.co/erp-ai/sap-ecc-ai-before-2027-migration

SAP ERP 6.0(ECC 6.0)の標準保守は2027年末に終了予定で、延長保守を使っても2030年までです。AIは移行そのものを代行しませんが、アドオンの棚卸し、仕様書の復元、移行後の問い合わせ対応では実務の工数を確実に減らせます。ソースや業務データを社外に出さないオンプレミス構成を前提にすれば、情報システム部門の説明もしやすくなります。

日本では、SAP ERP 6.0を長年使い続けてきた製造業が多く、2027年問題は経営会議の議題になりつつあります。標準保守の終了に加え、延長保守は追加費用がかかり、期限も限られます。一方で、S/4HANAへの移行は費用も期間も大きく、現行システムのアドオン(Z開発)が何をしているのか、誰も説明できないという相談が少なくありません。

ここで問題になるのは、システムそのものよりも「知識の消失」です。仕様書が古い、開発した担当者や外部ベンダーが既にいない、改修の理由が残っていない。この状態では、Fit to Standardの検討も、コンバージョンの工数見積りも、精度が上がりません。生成AIが得意なのは、まさにこの種の大量のコードや文書を読み、要約し、質問に答える作業です。

ただし、ABAPのソースや原価・調達データは機密性が高く、外部のクラウドAIに送ることを情報システム部門が認めないケースが一般的です。本ページでは、2027年問題の文脈で、オンプレミスや自社管理のクラウド内で動かす生成AIの使いどころと限界を、現場の視点で整理します。

## 2027年問題で現場が本当に困っていること

標準保守の終了日だけが注目されがちですが、実務で重いのは三つです。第一に、アドオンと帳票、インターフェースの数が多く、移行対象の棚卸しだけで数か月かかること。第二に、過去の改修経緯が人の記憶にしか残っていないこと。第三に、移行プロジェクトと日常の運用保守を同じ少人数のチームが担っていることです。

経済産業省のDXレポートで指摘された「2025年の崖」と同じ構造が、SAP ERPでも顕在化しています。つまり、期限そのものよりも、現行システムの中身を説明できないことがリスクです。AIの導入は、この説明可能性を取り戻す手段として位置づけると、投資対効果を示しやすくなります。

- Zプログラム、Zテーブル、ユーザー exit、BAdIの利用状況が把握できていない
- SAPクエリ、ALV出力、Smart Formsなどの帳票が部門ごとに乱立している
- 旧担当者の退職で、会計・購買・生産の設定理由が分からない
- 移行ベンダーの見積りが、棚卸し前提のため幅広く出る

## 生成AIで具体的にできること

代表的な用途は、ABAPコードの要約と仕様書の復元です。Zプログラム単位でソースを読み込ませ、入出力、参照テーブル(例えばEKKO、EKPO、MARA、VBAK、AFKOなど)、呼び出し元を日本語で説明させます。これを人間のレビューを前提に使えば、棚卸しの一次整理にかかる時間を大きく短縮できます。ただし、出力は必ず担当者が確認する運用が必要です。

二つ目は、移行判断の材料づくりです。使用実績(トランザクションの実行ログ、ST03Nなどの統計)とコード要約を突き合わせ、「使われていない」「標準機能で代替できそう」「作り直しが必要」の仮分類を作ります。三つ目は、移行後の問い合わせ対応です。画面や項目の違いに戸惑うエンドユーザーに対し、社内マニュアルと業務ルールを根拠に回答するアシスタントを置けます。

- Zプログラムと帳票の自動要約、重複・類似開発の検出
- 移行方式(ブラウンフィールド、グリーンフィールド、選択的移行)の検討資料の下書き
- 過去の障害対応メモや運用手順書からの検索型回答
- ERPray による、ERPデータへの自然言語での問い合わせ(読み取り専用、実行クエリを表示)

## データを社外に出さない構成

Netrayが提案するのは、オープンウェイトのモデル(Llama、Qwen、Mistral、Gemma、gpt-oss系など)をvLLMやOllamaで、お客様のGPUサーバーまたは国内の閉域・プライベート環境に配置する構成です。ABAPソースや文書は社内ネットワークの中で検索(RAG)され、外部のAPIには送信されません。

SAPへの接続は、読み取り中心の設計にします。RFCやOData、DBレプリカなど既存の方式から必要な範囲だけを取り込み、SAPの権限(ロール)をAI側でも尊重します。書き込みを伴う処理は、必ず人間の承認を挟みます。なお、2027年問題の最中にSAP本体の構成が変わる場合でも、接続層を分離しておけば、AI側の作り直しを最小限にできます。

## コンプライアンスと社内説明のポイント

個人情報(従業員マスタ、取引先担当者)を含む場合は個人情報保護法、技術情報や原価情報は不正競争防止法上の営業秘密として管理されているかが論点になります。防衛・航空宇宙関連では、取引先から求められる情報セキュリティ要件や、外為法に基づく技術提供の管理も確認が必要です。Netray自身が特定の認証を保有していると主張するものではなく、お客様の要件を満たす構成をどう取れるかを一緒に設計する、という立場です。

監査対応(J-SOXなど)の観点では、AIが参照したデータ、生成したクエリ、利用者のログを残せることが重要です。ERPrayは実行したクエリを表示する設計のため、「AIがどの数字を根拠に答えたか」を追跡できます。

## 進め方と、AIが向かないケース

進め方の例は次のとおりです。まず2〜3週間のアセスメントで、対象範囲(コード、文書、データ)と情報の機密区分を整理します。次に、アドオン一部モジュール(例えば購買か生産)に絞ったパイロットを行い、要約の正確さ、レビュー工数の削減幅、誤りの傾向を実測します。結果が出たら、移行プロジェクト全体に広げるかどうかを判断します。

正直に言えば、AIが向かないケースもあります。アドオンがごく少なく標準に近い運用であれば、移行ベンダーのツールだけで足ります。また、SAP公式のツール(Readiness Check、Custom Code Migrationなど)で十分な部分は、そちらを使うべきです。AIは、それらの結果を読み解き、現場に説明する層で効果が出ます。

## FAQ

### SAP 2027年問題とは何ですか。

SAP ERP 6.0(ECC 6.0)の標準保守が2027年末に終了予定であることを指す通称です。延長保守を選べば2030年まで利用できますが、追加費用が発生します。いずれの場合も、S/4HANAなどへの移行計画が必要になります。

### 生成AIでS/4HANAへの移行を自動化できますか。

いいえ。移行そのものの自動化ではなく、アドオンの棚卸し、仕様の復元、移行後の問い合わせ対応といった周辺作業の効率化が現実的な範囲です。出力は担当者のレビューが前提です。

### ABAPのソースコードを外部のAIに渡しても大丈夫ですか。

多くの企業では、機密情報の観点から外部送信を認めていません。そのため、社内サーバーや閉域環境でオープンウェイトのモデルを動かし、コードを社外に出さない構成を取ります。

### SAP純正のAI(Jouleなど)で十分ではありませんか。

SAPのクラウド製品の範囲で使う場合は、純正AIで足りることがあります。一方、ECCのオンプレミス環境、他システムとの横断的な検索、データを社外に出せない要件がある場合は、自社管理のAIが選択肢になります。

### どのくらいの規模から効果が出ますか。

Zプログラムが数百本以上、または担当者の退職で仕様が不明な領域が多い場合に効果が出やすいです。アドオンが少ない場合は、AIよりも標準機能への寄せを優先する方が合理的です。

### まず何から始めればよいですか。

無料のアセスメントで、対象範囲、機密区分、利用できるGPUや閉域環境を確認し、小さなパイロットの範囲を決めるのが一般的な出発点です。