Transformation Cockpit (デモ環境での実行例)
大企業・官公庁・自治体でのエンタープライズ対応
※1 2025年3月トラフィック分析ツール（Similarweb）による推定値に基づく自社調査。AI総合研究所の運営・分析実績に基づく継続的な改善・検証による知見蓄積。
ERP 刷新プロジェクトで必ず起きること
刷新を止める、6つの壁
期限が動かない
ECCの標準保守は2027年、延長しても2030年で終わる
工程を圧縮して、期限内に収める
SAPの2027年問題を詳しく見る現行が見えない
何が動いていて、何が使われていないかが分からない
AIが現行を構造化して可視化
古いアドオンに触れない
作った担当者はもういない、仕様書と実物もずれている
実際のコードから挙動と影響範囲を読む
棚卸しが人海戦術
カスタム開発と連携の調査に数ヶ月、担当者の記憶頼み
スキャン結果から移行計画を生成
動かせる人がいない
ABAPが分かる担当者は限られ、外部の確保も年々難しい
実装とテストをAIが担い、人はレビューへ
移行後も重い
回帰テストと証跡づくりが、Go-Live後の保守を圧迫する
テストと証跡を継続的に積み上げ
AI Transformation Hub の仕組み
AIが理解・計画・実行し、人が承認する
刷新プロジェクトの工程を、AIが担う部分と人が判断する部分に切り分けます。工程ごとに区切り、1つずつ終わらせてから次に進むため、どこまで進んだかが常に分かります。
STEP 1 / CONNECT
接続
既存のSAP環境とリポジトリに読み取りで接続します。既存システムへの改修は行いません。
AIが実行
STEP 2 / SCAN
現行解析
カスタム開発・依存関係・インターフェース・利用状況を読み取り、構造化します。
AIが実行
STEP 3 / PLAN
移行計画
オブジェクトごとの扱いを判定し、実行順(Wave)と開発タスクに分解します。
AIが実行
STEP 4 / BUILD
実装
Coding Agent が計画に沿って、隔離環境の中でコードを変更します。
AIが実行
STEP 5 / TEST / VERIFY
検証
テストを実行し、失敗した場合は原因を読んで自分で修正し、再実行します。
AIが実行
STEP 6 / EVIDENCE / APPROVE
承認
差分・テスト結果・判断の根拠を人がレビューし、承認して初めて反映されます。
人が判断
一度にまとめて変換しない
刷新をAIに丸ごと投げても、結果を検証できなければ使えません。対象を小さい単位に割り、1単位ずつ最後まで終わらせてから次に進みます。
- 対象は一度に広げず、オブジェクト単位・タスク単位に割る
- 1タスクごとに 実装 → テスト → 証跡 → 承認 まで完了させる
- 承認が済んだものだけを、次の実行順(Wave)に積み上げる
- 途中で止めても、完了済みの単位はそのまま残る
最終判断は必ず人が行います。AIに承認まで任せる設計にはしていません。
SCAN - 現行解析
棚卸しをExcelで始める前に、現行を構造化する
カスタム開発の一覧、呼び出し関係、外部連携、直近の利用状況を読み取り、刷新の判断材料になる形に組み直します。担当者の記憶と設計書の差分を埋めるところから始められます。
読み取る対象
- カスタムオブジェクト (ABAP・帳票・拡張)
- オブジェクト間の依存関係
- 外部インターフェース
- 直近の利用状況・未使用オブジェクト
- 業務プロセスとの紐づけ
- 移行先アーキテクチャの前提
- 既存テストの有無
解析結果
デモ環境での実行例6
カスタムオブジェクト
18
依存関係
3
外部インターフェース
1
未使用
2
高リスク
現行の構造 (Digital Twin 依存グラフ)
業務プロセス・カスタムオブジェクト・インターフェース・外部システムの関係を1枚に。刷新の影響範囲がここで見えます。
Transformation Cockpit - Digital Twin 依存グラフ
赤枠は高リスク、破線は未使用のオブジェクト。線は呼出・書込などの依存を表します。
デモ環境は実在企業のデータではない架空のLandscapeです。実機接続は検証環境から段階的に行います。
PLAN - 移行計画
維持・再構築・置換・廃止・SAP外へ移管に仕分ける
解析結果をもとに、カスタムオブジェクトを5つの扱いに仕分けます。判断の理由と影響範囲が併記されるため、そのまま社内の合意形成に使えます。
KEEP
維持
現行のロジックを移行先でも継続利用できる
ZFI_RECON_REPORT
REFACTOR
再構築
密結合・テスト不足のため構造を整理して移行する
ZSD_ORDER_EXPORT
REPLACE
置換
旧式の連携方式を標準機能・新APIへ置き換える
ZMM_STOCK_RFC
RETIRE
廃止
利用実績がなく、移行対象から外せる
ZLEGACY_UNUSED
MOVE OUTSIDE SAP
SAP外へ移管
基幹の外側の連携基盤へ切り出す
ZBATCH_EXPORT
小さく確実に効くもの
使われていないオブジェクトの廃止から着手し、移行対象そのものを減らします。
中核の作り直し
業務ロジックと入出力が絡み合った箇所を整理し、テストできる形にします。
連携の刷新
旧式のインターフェースを標準機能・新APIへ置き換えます。
計画は、レポートで終わらない
仕分けた結果はそのまま開発タスクになります。対象オブジェクト・判定・優先度・実行するエージェントまでが1枚のタスクとして生成され、次の工程に渡ります。
- 対象
- ZSD_ORDER_EXPORT
- 判定
- 再構築 (REFACTOR)
- 優先度
- 高
- 実行
- Coding Agent
AI Transformation Hub 相談
刷新の対象をどこから絞るか、まずは整理しませんか？
構想段階でも構いません。現行システムの状況を伺い、現行スキャンから始める進め方をご提案します。
BUILD - 実装と検証
計画が、そのまま実行タスクになる
AIがコードを変更し、テストを実行します。落ちたら原因を読んで直し、通ってから人のレビューに回します。この1タスク分の流れが、そのまま証跡として残ります。
タスクに渡される指示 (抜粋)
- 外部出力の処理と業務ロジックを分離する
- テストできる構造に変更する
- 現行の挙動は変えない
- 変更後にテストを実行し、失敗を修正する
実行の流れ
変更ファイル
4
テスト
5 / 5 通過
リスク
低
デモ環境での実行例
コードを書くところまでではなく、テスト結果を読んで直すところまでを担います。人はレビューから始められます。
EVIDENCE - 承認の材料
AIが行った変更を、根拠つきで承認する
変更のたびに、何を根拠に、どのモデルが、どの指示で、何を変えたかが記録されます。監査や内部統制の説明にそのまま使える形で残ります。
変更ごとに残る記録
01
変更前のコード
着手時点の状態
02
判定と理由
なぜその扱いにしたか
03
エージェントの実行ログ
実際に行われた手順
04
使用モデルと指示
どのモデルに何を指示したか
05
変更ファイルと差分
どこがどう変わったか
06
テスト結果
通過・失敗と修正の経緯
07
承認者と承認日時
誰がいつ承認したか
差し戻しも記録に残り、次の実行の材料になります
データの扱い
顧客固有の情報と、製品として蓄積する知識をはっきり分けています。
顧客環境から持ち出さないもの
- ソースコード
- 業務ルール
- 業務データ
- 接続情報・資格情報
- 顧客固有のマッピング
製品として再利用するもの
- 汎用の解析処理
- オブジェクトの分類体系
- 一般化された移行パターン
- テスト観点
- 突合アルゴリズム
進捗の共有
関係者は、同じ画面で進捗と判断を追える
実行と承認は開発側の画面で行い、プロジェクト管理や業務部門には閲覧専用のポータルを用意します。進捗を聞いて回らなくても、いま何がどこまで進んでいるかが分かります。
PM ポータル (閲覧専用)
PM ポータル (閲覧専用・デモ環境での実行例)
タスクの状態
実行中・実行待ち・レビュー待ちが一覧で分かります。
判定と適用レシピ
オブジェクトごとの扱いと、適用した移行パターンが並びます。
確度とリスク
判定の確からしさとリスクの高さを添えて表示します。
判断の理由
なぜその扱いにしたのかが、そのまま読める形で残ります。
閲覧専用のため、この画面から実行や承認は行えません。操作は開発側の画面に限定しています。
AI 開発ワークスペース
刷新で整えた開発基盤は、Go-Live後も残る
Coding Agent を業務システム開発に持ち込むには、隔離環境・接続・テスト・承認の仕組みが要ります。刷新のために整えたこの基盤は、稼働後の保守でもそのまま使えます。
エディタと Coding Agent
VS Code 上で Claude Code・Codex などのエージェントを使います。
隔離されたサンドボックス
エージェントの実行は隔離環境の中に閉じます。本番へ直接は触れません。
Git と CI/CD
変更はすべてブランチとPRを経由し、履歴として残ります。
基幹システムへの接続
開発ツールへの接続を通じて、コードとオブジェクトを参照します。
資格情報とネットワーク制御
接続情報の管理と通信範囲の制限を前提に構成します。
テスト基盤
単体テストと回帰テストを、変更のたびに実行できる状態にします。
監査と承認
誰が何を承認したかを記録し、後から追跡できるようにします。
コーディング規約
エージェントへの指示と社内規約を揃え、出力のばらつきを抑えます。
稼働後は、この流れで保守が回る
2つの製品の関係
基幹を「変える」AIと、基幹を「使う」AI
刷新そのものを進める製品と、整った基幹データを業務で活かす製品を分けています。どちらから始めても、もう一方につながります。
基幹システムを変えるAI
刷新・移行・開発・テスト・保守を対象にします。主に情報システム部門と開発チームが使います。
このページの製品
進め方
小さく試してから、範囲を広げる
はじめから全体を対象にはしません。限定した範囲で現行解析を行い、出てきた結果を見てから次の判断をします。
現行スキャン
対象を絞って読み取り、何が見えるかを確認します。
現状診断と刷新計画
仕分け結果・実行順・リスク・自動化の余地を整理します。
刷新プロジェクト
計画をタスクに落とし、実装・テスト・証跡まで回します。
稼働後の保守
変更要求への対応を、同じ基盤で継続します。
対象範囲によって進め方も期間も変わります。現状を伺ったうえでご提案します。
FAQs
よくある質問
AI Agent Hubに関する よくある質問とその回答
SAP・ERP 刷新の AI 活用は、まずは無料相談から。