ひまネタNEWS(^o^) | スキマ時間にちょっとしたネタを提供

AWSは、AIコーディングエージェント「Kiro」をベースにしたサンプルエージェントによる、SAPモダナイゼーションのユースケースとそのベンチマーク結果を公開した。ABAPコードの変換では工数を87％削減したという。

» 2026年10月29日 12時45分公開

[＠IT]

この記事は会員限定です。会員登録（無料）すると全てご覧いただけます。

　「SAP ERP 6.0」（EHP6以降）の標準メンテナンスが2027年末に終了する「SAPの2027年問題」が迫る中、「SAP S/4HANA」への移行を検討する企業にとって、既存のカスタムコードの分析や改修、テストにかかる工数をどう抑えるかが課題となっている。

　こうした移行作業をAIでどこまで効率化できるのか。Amazon Web Services（AWS）は2026年10月1日、AIコーディングエージェント「Kiro」をベースにしたサンプルエージェント「Modernization Agents for SAP on AWS」のユースケースとベンチマーク結果を公開した。AWSの社内ベンチマークでは、「SAP ECC」（SAP ERP Central Component）のABAP（Advanced Business Application Programming：SAPが開発したプログラミング言語、SAPシステムのカスタマイズやアドオン開発に使用する）コードを、SAP S/4HANAに準拠したコードに変換する工数を87％削減したという。

　ベンチマークは全てAWSの社内開発環境で実施した。使用したKiroのクレジット（AI処理の利用量の単位）は、「Kiro Pro」サブスクリプションの範囲内に十分収まっているとしている。

SAPモダナイゼーションのどの作業をエージェントに任せられる？

　AWSが紹介したユースケースとベンチマークの結果は以下の通りだ。

1．SAP S/4HANA準拠に向けたABAPコードのアップグレード

　SAP ECC向けにカスタマイズされたレガシーなABAPコードを、SAP S/4HANAに準拠した標準コードに変換する。

　エージェントは変換の前に機能仕様書、技術設計書、単体テストクラスを作成し、変換中は企業が定義した標準に準拠するようコードを改善する。変換後は単体テストを実行し、ビジネスロジックの整合性を確認する。

　パフォーマンス標準、コーディング標準、セキュリティ標準、ドキュメント標準、コードの重複回避をカバーする、80を超えるサンプルルールとベストプラクティスを用意している。

　AWSの社内ベンチマークでは、88オブジェクト（5854行のコード）から成るSAP ECCのパッケージ全体を4.5時間でSAP S/4HANAに準拠したコードに変換し、生成した全ての単体テストに合格した。工数は87％削減し、使用したクレジットは377だったという。

2．クリーンコアに向けたABAPのリファクタリング

　カスタムABAPコードを、「Clean Core Extensibility Model」に準拠するよう評価、改修する。このモデルは、各カスタマイズがSAP S/4HANAのコアシステムの外側にどれだけクリーンに配置されているかを、A～Dの等級で評価するものだ。上位のAとBに保てば、カスタムコードの機能を維持して迅速にアップグレードでき、SAPの新しいコア機能も採用できる。

　AWS社内ベンチマークでは、143オブジェクト（1万200行のコード）で116件の「Extensibility Level D」の指摘事項を特定し、指摘された問題を55分で全て修正したという。非標準のコードを、SAPがリリースした適切なオブジェクトに置き換えるか、クリーンコアの原則に従って拡張した。ただし自動改修の対象は、SAPが標準オブジェクトをリリースしているものに限られる。

3．SAP PI/POからSAP BTP Integration Suiteへの移行

　SAPのミドルウェア「SAP PI/PO」（SAP Process Integration／SAP Process Orchestration）のインタフェースを、「SAP Business Technology Platform Integration Suite」（BTP IS）に変換する。BTP ISは、SAPシステムと非SAPシステムをシームレスに接続するiPaaS（Integration Platform as a Service）だ。

　SAP PI/POは2027年12月に標準メンテナンスの終了を迎えるので、顧客によっては数十から数百のインタフェースを移行する必要がある。1つのインタフェースを手作業で変換するには、複雑さによって数日から数週間かかることがある。

　エージェントは1つのプロンプトで、既存のPI/POの構成を調べて機能仕様書と技術設計書を作成し、PI/POのアーティファクトをBTP向けの形式に変換して、BTP ISにデプロイする。要件定義書から新しいBTP ISのインタフェースを開発することもできる。

　AWS社内ベンチマークによると、25のメッセージマッピングを含む22のインタフェースを、約2時間でBTP ISに変換したという。インタフェースはIDoc（SAP独自の中間データフォーマット）、SOAP（Simple Object Access Protocol：XMLベースのWebサービス通信プロトコル）、REST（Representational State Transfer：現代の標準的なWeb APIアーキテクチャスタイル）、同期／非同期など、さまざまなタイプにまたがっていた。

　エージェントは変換元の通信チャネル、アグリーメント、共有関数ライブラリを読み取って変換先のアダプターを決め、マッピングのロジックを再現した上で、稼働中のテナントにデプロイして各マッピングをテストした。

　ルーティング、ファンアウト（1件のメッセージを分割して複数の宛先に送る処理）、マルチキャスト、値マッピング、IDocセグメントマップ、ステートフルなオーケストレーション（ccBPM：Cross-Component Business Process Management）といった複雑な要件にも対応した。使用したクレジットは約220だったという。パスワードや証明書などの認証情報はセキュリティ上の理由から移行しないので、エンドツーエンドのテストの前に手作業が必要になる。

4．SAP BWからSAP Datasphereへのモダナイゼーション

　データウェアハウス（DWH）の「SAP BW」（SAP Business Warehouse）も、2027年12月に標準メンテナンスの終了を迎える。エージェントは、既存の全SAP BWのデータパイプラインとデータモデルを読み取ってそれぞれの機能仕様書と技術仕様書を作成し、クラウドネイティブな「SAP Datasphere」上の同等のオブジェクトに自動で作り替える。

　SAP BW向けのエージェントは「Kiro Specs」を基盤に構築したガイド付きのワークフローで、アーキテクトや開発者が全てのステップで主導権を保てる。データフローの把握から、「SAP Business Data Cloud」（BDC）のデータプロダクトへの対応付け、設計書作成、変換したオブジェクトの生成とデプロイまでを、組織独自のベストプラクティスとデータ戦略に沿って進める。

　AWS社内ベンチマークでは、販売管理のコンテンツを含むレガシーなSAP BWシステムを、2.2時間でSAP Datasphereに変換したという。

　変換元の環境は32のData Store Object、13のTransformation、6つのComposite Provider、1273のフィールドで構成されていた。変換後のSAP Datasphereシステムは、32のLocal Table、13のData Flow、6つのAnalytic Modelを含む。使用したクレジットは856だったという。

5．機能仕様書と技術仕様書の生成

　多くのSAPプロジェクトは、ドキュメントのないレガシーコードを分析、文書化して現状の機能仕様と技術仕様を理解することから始まる。エージェントは、希望する形式で、自社のドキュメント標準に沿ってドキュメントを生成できる。使われていないコードを特定し、不要なモダナイゼーション作業を避けることもできる。

6．単体テストの自動化

　AWSは、モダナイゼーションの前にレガシーコードの単体テストを生成するよう勧めている。単体テストはエージェントが変換後のコードを検証するための明確な成功基準になり、モダナイゼーション中のAIのハルシネーションを大幅に抑えられるという。

　Kiroや「Claude Code」などのエージェント型ツールは、分析、編集、再テストを繰り返しながら、問題が修正されたかどうかを単体テストで確認する。AWSは、自動の単体テストを組み込んだことが、前述のベンチマークで高品質な変換結果を得られた主な理由の一つだとしている。

依存するコードを全て取り込み、ハルシネーションを抑える

　ABAPではコードが他のABAPオブジェクトのロジックやライブラリを頻繁に参照する。ほとんどのAIコーディングアシスタントはこうした外部の依存コードを取得できず、ハルシネーションの原因になることが多い。AWSは、AIが生成するコードの正確性と品質を確保するために、サンプルエージェントに次のようなセーフガードを組み込んでいる。

依存する全てのコードとライブラリを取り込み、Kiroが完全なコンテキストを持てるようにする
カスタマイズ可能なステアリングファイルで、独自のコーディング、パフォーマンス、セキュリティ、ドキュメントの標準を定義できる
変換の前にコードの単体テストを作成して実行し、変換後に全く同じビジネスロジックを再テストする

　サンプルエージェントを基に構築したエージェントは、会話履歴を保存して意思決定をログに記録できるため、監査にも対応しやすい。2社の顧客が自動化のアプローチを内部統制チームや監査チームとレビューしたところ、監査担当者は、手作業で維持するドキュメントより意思決定ログの透明性を評価したという。ただしAWSは、本番環境への移行前に、顧客が徹底したエンドツーエンドのテストと業務面の検証を実施することが重要だとしている。

「COBOLを読める」と「移行できる」は別問題――AIでは越えられない“レガシーの壁”
AIは、長年使われてきたCOBOLのプログラムをどこまで理解できるのか。レガシーシステムの刷新にAIを活用する上で、その能力をどう評価すべきかは重要な課題だ。とはいえAIの読解力が高くても、システム全体を正しく理解できるとは言えない。AI活用の可能性を見極めるために、企業は何を検証すべきなのか。
「AIで数週間に短縮」のはずが進まない　コードモダナイゼーション、真のボトルネックと6ステップ
Anthropicは、AI駆動の大規模なコードモダナイゼーションプロジェクトに向けた準備の進め方をまとめたブログ記事を公開した。
COBOL、VMware、.NETまで――AWS「45億行に及ぶコード処理」で見えたAIレガシー刷新の現状
何年もかかっていたレガシーシステムの刷新が、AIによって「6週間」に――。COBOL、VMware、.NETなどのシステムをAIを活用して移行、刷新する1年間の取り組みの成果をAWSが公開した。
レガシー移行を「AIに丸投げ」してはいけない　標準RAGではダメな理由と「5分割」のアプローチ
SiemensとGoogle Cloudは、レガシーコードの理解とモダナイゼーションを自動化するAIシステム「Knowledge Fabric」を構築した。数億行規模の産業用ソフトウェアを複数の専門エージェントで分割処理し、開発工数を削減するという。
AIコーディングだけでは「塩漬けレガシーの刷新」がうまくいかないワケ
AIを活用することで、停滞してきたレガシーシステムの刷新を前進させられる可能性もあります。しかし単にAIコーディングツールを導入するだけでは、その効果が部分的にとどまるばかりか、コストや運用の破綻といった事態に陥るリスクもあります。先行事例も踏まえながら、効果的に進めるためのポイントを探ります。