本ブログでは、 ローンチブログ で紹介した各ユースケースをさらに詳しく掘り下げます。パートナーやお客様が SAP モダナイゼーションプロジェクトにおいて Kiro ベースのサンプルエージェントを使って達成した成果の一部もご紹介します。これらのサンプルエージェントは こちら からダウンロードできます。ローンチブログで取り上げた主なユースケースを振り返ります。 SAP S/4HANA 準拠に向けた ABAP コードのアップグレード クリーンコアに向けた ABAP のリファクタリング SAP PI/PO から SAP BTP へのモダナイゼーション SAP Business Warehouse（BW）から Business Data Cloud（BDC）の SAP Datasphere へのモダナイゼーション 機能仕様書と技術仕様書の生成 単体テストの自動化 本ドキュメントに記載するベンチマークは、すべて AWS の社内開発環境で実施したものです。ベンチマークで使用した Kiro クレジットは、 Kiro Pro サブスクリプションの範囲内に十分収まっています。 1. SAP S/4HANA 準拠に向けた ABAP コードのアップグレード 最初のユースケースは、レガシーなカスタム SAP ECC ABAP コードを SAP S/4HANA に準拠した標準コードに変換することです。数千（あるいは数万）のカスタム ABAP プログラムを持つエンタープライズにとって、このエージェントは最も労働集約的な改修作業を自動化します。コードを変換する前に、エージェントは機能仕様書、技術設計書、単体テストクラスを作成します。変換中には、定義されたエンタープライズ標準に準拠するようコードを改善します。これを実現するため、パフォーマンス標準、コーディング標準、セキュリティ標準、ドキュメント標準、コードの重複回避をカバーする、80を超えるサンプルルールとベストプラクティスを完全に構成可能なセットとして提供しています。変換後、エージェントは単体テストを実行してビジネスロジックの整合性を確認します。 ベンチマーク： AWS の社内ベンチマークでは、88オブジェクト（5,854行のコード）からなる SAP ECC パッケージ全体を4.5時間で完全に SAP S/4HANA 準拠のコードに変換し、生成されたすべての単体テストに合格して、工数を87%削減しました。このベンチマークで使用した Kiro クレジットは377でした。 NTT Data Global Solutions（GSL）は、お客様の SAP S/4HANA への移行を加速するために ABAP エージェントを活用しています。GSL の新しい移行サービス Neo i-KOU! は、ABAP の改修フェーズを最大95%短縮します。製品テストでは、従来は変換に4人月以上を要していた ABAP コードを、わずか0.21人月の工数で変換しました。 2. クリーンコアに向けた ABAP のリファクタリング このユースケースでは、Clean Core Extensibility Model への準拠に向けてカスタム ABAP コードを評価・改修します。このモデルでは、各カスタマイズが SAP S/4HANA のコアシステムの外側にどれだけクリーンに配置されているかに基づき、A から D の等級で評価します。カスタマイズを最高レベルの A と B に保つことで、お客様はカスタムコードを壊すことなく迅速にアップグレードして SAP の新しいコア機能を採用できるため、より速くモダナイズしてコストを削減できます。AWS は、既存の ABAP カスタマイズをこれらの基準に照らして評価し、基準に満たないコードを改修することで、お客様がそこに到達できるよう支援します。 ベンチマーク： 社内ベンチマークでは、エージェントが143オブジェクト（10,200行のコード）にわたって116件の「Extensibility Level D」の ABAP 指摘事項を特定しました。55分の実行時間で、Level D の指摘事項を100%改修しました。エージェントは、非標準のコードを適切な SAP リリース済みオブジェクトに置き換えるか、クリーンコアの原則に従ってそれらを拡張しました。重要な点として、クリーンコアの自動改修は、SAP が標準オブジェクトをリリースしているオブジェクトに限定されます。ほとんどのお客様では、リリース済みオブジェクトが利用できないカスタムコードが一定の割合で存在すると想定しておくべきです。それらのオブジェクトについては、手作業でのレビューと、クリーンコアの選択肢（サイドバイサイドへの変換、現状維持、Fit-to-Standard の採用など）に関する判断が必要です。ベストプラクティスとして、まずエージェントを使ってすべてのカスタムコードを分析し、ABAP オブジェクトごとの現在の Extensibility Level（A、B、C、D）を示すレポートを作成して、自動改修の対象となるものを特定することをお勧めします。 3. SAP PI/PO から SAP BTP Integration Suite への移行 このユースケースでは、SAP PI/PO のインターフェースを SAP Business Technology Platform Integration Suite（BTP IS）に変換することに焦点を当てます。SAP のミドルウェアプラットフォームである SAP PI/PO は、2027年12月に標準メンテナンスの終了を迎えます。お客様は数十から数百のインターフェースを BTP IS に移行する必要があり、単一のインターフェースを手作業で変換するには、その複雑さに応じて数日から数週間かかることがあります。この課題に対処するため、私たちはモダナイゼーションエージェントを開発しました。単一のプロンプトで、エージェントは既存の PI/PO 構成を調査し、機能仕様書と技術設計書を作成し、PI/PO のアーティファクトを BTP 対応の形式に変換し、その結果を BTP IS にデプロイすることで、大幅な時間とコストの削減を実現します。SAP PI/PO の移行に加えて、エージェントは要件定義書から直接、新規の BTP IS インターフェースを開発することもできます。 ベンチマーク： 社内ベンチマークでは、エージェントが22の SAP PI/PO インターフェースを約2時間で SAP BTP Integration Suite に変換しました。これらのインターフェースには25のメッセージマッピングが含まれており、IDOC、SOAP、REST、同期・非同期など、さまざまなインターフェースタイプにまたがっていました。エージェントは、ソースの通信チャネル、アグリーメント、共有関数ライブラリを読み取り、各ターゲットアダプターを決定してマッピングロジックを再現しました。その後、SAP BTP IS のインターフェースを作成し、稼働中のテナントにデプロイし、ソースのルールに照らして単体レベルのデータで各マッピングをテストしました。エージェントは、ルーティング、ファンアウト、マルチキャスト、値マッピング、IDOC セグメントマップ、ステートフルなオーケストレーション（ccBPM）といった複雑な要件にも対応しました。セキュリティ上の理由から、パスワードや証明書などの認証情報は移行しないため、エンドツーエンドのテストの前に手作業のステップが必要です。このベンチマークで使用した Kiro クレジットは約220でした。 4. SAP BW から Datasphere へのモダナイゼーションエージェント このユースケースは、SAP BW のモダナイゼーションを加速し、作業をエンドツーエンドで自動化するものです。エージェントはまず既存のすべての SAP BW のデータパイプラインとデータモデルを読み取り、それぞれについて機能仕様書と技術仕様書を作成し、クラウドネイティブな SAP Datasphere の同等物に変換します。SAP BW Private Cloud Edition（PCE）の道を選ぶお客様は、エージェントを Data Product Generator や Query Template Generator などの SAP ツールと組み合わせて使用できます。 これは、同じ期限を迎えるもう1つのワークロードに対処するものです。数千の企業が利用するエンタープライズデータウェアハウスプラットフォームである SAP BW も、2027年12月に標準メンテナンスの終了を迎えます。SAP はお客様に SAP Datasphere への移行を推奨しており、そこに至る道は2つあります。SAP Datasphere に直接移行するか、まず暫定的なプラットフォームである SAP BW Private Cloud Edition（PCE）に移行するかです。後者の場合、2027年以降も SAP BW を稼働させ続け、自社のペースで Datasphere を採用できます。 SAP BW 向けのエージェントは Kiro Specs 上に構築されたガイド付きワークフローであり、アーキテクトや開発者があらゆるステップで主導権を保てます。データフローを発見し、それらを SAP BDC の Data Products にマッピングし、設計書を作成し、変換済みの Datasphere オブジェクトを生成・デプロイします。その過程で、組織独自のベストプラクティスとデータ戦略が適用されます。 ベンチマーク： 社内ベンチマークでは、このエージェントが販売管理（Sales and Distribution）のコンテンツを含むレガシーな SAP BW 環境を2.2時間で SAP Datasphere に変換しました。SAP BW 環境は Layered Scalable Architecture（LSA++）アーキテクチャに基づいており、32の Data Store Object、13の Transformation、6つの Composite Provider、1,273のフィールドで構成されていました。最終的な SAP Datasphere 環境には、32の Local Table、13の Data Flow、6つの Analytic Model が含まれていました。このベンチマークで使用した Kiro クレジットは856でした。 AWS パートナーである DXC と Kyndryl は、お客様の SAP BDC へのジャーニーを加速するために SAP BW エージェントを活用しています。DXC は、Kiro と Modernization Agents を「DXC Fast BDC」と組み合わせることで、複雑なアセスメントを自動化し、AI を活用したビジネスインサイトを実現し、最短10週間でビジネス価値を提供するデジタルトランスフォーメーションを加速しています。Kyndryl の SAP US Data Lead である Poshan Ponnamreddy 氏は次のように述べています。「 AWS の Modernization Agents、Kiro、そして Kyndryl の Agentic AI Framework の組み合わせは、お客様の SAP モダナイゼーションの期間短縮に貢献しています。AI を活用した変換機能がコードの分析と変換を自動化し、品質を向上させながら手作業の工数を最大80%削減します。これらのイノベーションが一体となって移行の成果を加速し、価値実現までの時間を大幅に短縮します。 」 5. 機能仕様書と技術仕様書の生成 「何十年も前に」書かれたコードにドキュメントがなく、業務の専門家もとうの昔に組織を去ってしまった、という話をよく耳にします。AI を使ってコードを分析しドキュメントを生成することは、SAP ABAP、PI/PO、BW など幅広い SAP プラットフォームで効果が実証されたユースケースです。多くの SAP プロジェクトの最初のステップは、レガシーコードを分析・文書化して、現状（As-Is）の機能仕様と技術仕様を理解することから始まります。 Kiro のサンプルコードを使って構築したモダナイゼーションエージェントは、希望する形式で、かつ自社のドキュメント標準に従ってドキュメントを生成するための機能を提供できます。また、未使用のコードを特定することもでき、不要なコードのモダナイゼーション作業を回避できます。 Toyota Chile は SAP ECC から SAP S/4HANA への移行を進めていますが、数百のレガシー SAP ABAP オブジェクトについてドキュメントや理解が不足していました。シニアソフトウェアエンジニアの Rolando Sabatino 氏は、次のように体験を語っています。「 Kiro と AWS の Modernization Agents for SAP on AWS により、プロジェクトの工数を簡素化・削減できています。Kiro を使って未使用のコードや陳腐化したテーブルを特定し、移行範囲から除外しました。また、ビジネスユーザー向けの機能ドキュメントと開発者向けの技術仕様書も生成しました。ドキュメントは数時間で生成され、数か月分の手作業を回避できました。 」 6. 単体テストの自動化 単体テストは、あまり知られてはいないものの機能を確認するうえで効果の大きいアプローチであり、AI によるコード変換を高精度で信頼性の高いものにしている要因です。コードのモダナイゼーション中の AI のハルシネーションを大幅に最小化するため、結果が信頼できるものになります。ベストプラクティスとして、AWS はモダナイズの前にレガシーコードの単体テストを生成することを推奨しています。これにより、AI エージェントは変換後のコードを検証するための明確な成功基準を得られます。 これがなぜそれほど重要なのか、もう少し詳しく説明します。Kiro や Claude Code などの AI コーディングツールは、よりエージェント的な機能を備えるよう成熟するにつれて、人間の作業方法を模倣するかたちで自律的に反復しながら問題を解決するようになりました。人間がコードを書いてバグを見つけると、バグが解決されるまで分析・編集・再テストのサイクルを続けます。エージェント型ツールはこれと同じループを実行し、問題が修正されたことを確認するために単体テストを使用します。言い換えれば、単体テストは成功がどのようなものかをエージェントに伝え、エラーがなくなるまで分析・編集・再テストを繰り返せるようにします。自動単体テストを組み込んでいることは、私たちのモダナイゼーションエージェントが前述の高品質なベンチマークを達成できた主な理由の1つです。 正確で高品質なコードのためのセーフガード 業界でよく聞かれる正当な懸念の1つが、AI が生成するコードの正確性と品質です。お客様からは「 エンタープライズは、SAP のような最も重要なワークロードにどうすれば自信を持って AI を適用できるのか？ 」と頻繁に質問されます。ABAP ではコードが他の ABAP オブジェクトに格納されたロジックやライブラリを頻繁に参照するため、正確性と品質のリスクが増幅されます。ほとんどの AI コーディングアシスタントは、そうした外部の依存コードを取得できず、それがしばしばハルシネーションの原因となります。AWS は正確性と品質を重視しており、これらのサンプルエージェントに独自のセーフガードを組み込んでいます。 第一に、これらのサンプルエージェントを活用して構築したエージェントは、依存するすべてのコードとライブラリを取り込み、Kiro が完全なコンテキストを持てるようにします。これは、変換時に正確なコードを生成しビジネスロジックを維持するうえで不可欠です。第二に、カスタマイズ可能なステアリングファイルにより、独自のコーディング・パフォーマンス・セキュリティ・ドキュメントの標準を定義できます。サンプルエージェントには、すぐに始められるよう80以上のルールを含むサンプルのステアリングファイルが付属しています。第三に、単体テストに対する独自のアプローチにより、変換前にコードを作成してテストし、変換後にまったく同じビジネスロジックを再テストすることで、品質を大幅に向上させ、時間を節約します。 監査可能性も重要なセーフガードの1つです。これらの Kiro ベースのサンプルエージェントを使って構築したモダナイゼーションエージェントは、会話履歴を保存し意思決定をログに記録できるため、デバッグや微調整に役立ちます。特筆すべきことに、2社のお客様が自社の AI 自動化のアプローチを内部統制チームおよび監査チームとともにレビューしました。予想に反して、監査担当者は意思決定ログの透明性を好みました。それが、ほとんどの従業員が手作業で維持しているドキュメントを上回っていたためです。 これらのエージェントはソフトウェア開発ライフサイクルの多くの部分を自動化しますが、本番環境に移行する前に、お客様が引き続きエンドツーエンドの徹底したテストとビジネス検証を実施することが重要です。 まとめ SAP のモダナイゼーションは、エンタープライズ IT において今なお最も複雑でリソース集約的な取り組みの1つです。サンプルエージェントを共有することで、私たちはお客様とパートナーに、より速く、より手頃なモダナイゼーションへの道を提供することを目指しています。これらのサンプルエージェントは こちら からダウンロードでき、詳細は こちら でご覧いただけます。 本ブログの翻訳は Amazon Quick による自動翻訳を行い、パートナー SA 松本がレビューしました。原文は こちら です。

2026年7月29日から 2 日間にわたって、 アマゾンウェブサービスジャパン合同会社はパシフィコ横浜で開催された KubeCon + CloudNativeCon Japan 2026 においてスポンサーとしてブースを出展しており、たくさんの方にご来場いただきました。（ご来場いただいた皆様、有難うございました！）   AWS ブースでは、2日間で 12 のデモセッションを行い、多くのご来場者にご視聴いただきました。その際にセッション資料をシェアしてほしいとのご要望をいくつか頂いたことを受け、こちらのブログ で各セッションの資料を公開させて頂きます。デモセッションの内容について、EKS Auto Mode・AI エージェント・セキュリティ・コスト最適化など、Amazon EKS の最新機能と運用自動化を実演する内容となり、詳細は以下に記載させて頂いています。ご参考いただけますと幸いです。   7/29(水) 11:00-11:15 | AWS DevOps Agent による EKS 上のインシデント対応の迅速化 （Japanese） >>> セッション資料 フロンティアエージェントの一つである DevOps Agent は、従来のシステム運用を根本的に変革するサービスです。本セッションでは、DevOps Agent の概要を紹介し、EKS 上で稼働するシステムのインシデントをどのように調査するかをデモします。   [Speaker] Yuya Hirooka – Partner SA   7/29(水) 12:00-12:15 | トレーニングと推論のためのモデルロード高速化 （Japanese） >>> セッション資料 大規模モデルのトレーニングおよび推論ワークロードは、数十〜数百ギガバイトに及ぶコンテナイメージの取得とモデルウェイトの読み込みによるコールドスタートの問題を抱えています。本セッションでは、EKS Auto Mode 上で SOCI パラレルプル、Mountpoint for Amazon S3 によるストリーミング、Run:ai Model Streamer による GPU への直接ロードの 3 つの手法を紹介し、起動時間の短縮と手法の選び方を解説します。   [Speaker] Kosuke Sobue – ISV/SaaS Solutions Architect   7/29(水) 13:00-13:15 | モデルからエージェントへ — Amazon EKS Auto Mode で LLM 駆動 AI アプリケーションを稼働させる （English） >>> セッション資料 AI が推論エンドポイントからエージェント型アプリケーションへと進化する中、Kubernetes 上で LLM を稼働させるには新たな課題が生じます。本セッションでは、Amazon EKS Auto Mode が LLM 駆動のエージェント AI を大規模にデプロイ・運用する方法を、オープンソース LLM のライブデプロイと、推論と外部アクションを連携するエージェントアプリケーションを通じて紹介します。GPU コンピューティングは Ray と vLLM により自動管理されます。   [Speaker] Sai Vennam – Prin. WW Spec. SA, Containers   7/29(水) 13:40-13:55 | EKS セキュリティ：Admin & Advanced Network Policies （Japanese） >>> セッション資料 マイクロサービスが拡大するにつれ、セキュリティと開発スピードの両立が課題となります。本セッションでは、Amazon EKS Network Policies がサービスメッシュなしで多層防御を実現する方法を紹介します。Admin ポリシーがクラスター全体のベースラインを強制し、Advanced ポリシーが L7 FQDN ベースの Egress 制御を追加します。いずれも EKS Auto Mode 上の VPC CNI の eBPF エンジンで動作します。   [Speaker] Toshikazu Ichikawa – Snr Partner SA   7/29(水) 15:25-15:40 | EKS でのプラットフォームエンジニアリング：開発者セルフサービス GitOps ゴールデンパス（ArgoCD、ACK、KRO） （Japanese） >>> セッション資料   マネージド EKS の機能群（ArgoCD、ACK、KRO）を活用した GitOps ベースのプラットフォームで、ワークロードレベルのゴールデンパスを提供します。一例として LLM 推論を取り上げ、開発者が単一の InferenceEndpoint を宣言して git push するだけで、GPU のプロビジョニング、モデル提供（Ray Serve + vLLM）、セルフサービスでの公開までをプラットフォームが自動で行います。   [Speaker] Yuji Matsuoka – Solutions Architect, TELCO   7/29(水) 16:30-16:45 | AWS Neuron による動的リソース割り当て （Japanese） >>> セッション資料 Dynamic Resource Allocation（DRA）が Kubernetes 1.36 で GA となり、GPU などのハードウェアデバイスをより柔軟に割り当てられるようになりました。本デモでは、DRA の仕組みと使い方を説明し、AWS 固有のトピックとして Trainium での DRA 利用についても紹介します。   [Speaker] Kenta Goto – ISV/SaaS Solutions Architect   7/29(水) 17:50-18:05 | Kubernetes 上のマルチテナント AI トレーニングのための DRA ベースカスタム GPU スケジューラー （English）   組織が Kubernetes 上で AI ワークロードをスケールさせる際、チーム間での GPU 管理はフラグメンテーション、リソース競合、マルチノード間の調整失敗といった課題を生みます。本セッションでは、Kubernetes の DRA フレームワーク上に構築したカスタム GPU スケジューラーを紹介します。NVIDIA ResourceSlices を評価して共有モードを考慮した配置を行い、フラグメンテーションのないビンパッキングを適用し、クォータ管理、ギャングスケジューリング、デッドラインを考慮したバックフィルを含むマルチテナントポリシーを強制します。   [Speaker] Youngjoon Jeong – Sr. GTM SSA Containers Korea   7/30(木) 11:00-11:15 | AI によるシフトレフト：PR から本番までの K8s マニフェスト自動レビュー （Japanese） >>> セッション資料 経験豊富なレビュアーでも、特権コンテナ、平文シークレット、リソースリミットの未設定といった Kubernetes マニフェストの重大な問題を見落とすことがあります。本セッションでは、Amazon Bedrock 上の Claude を活用してレビューをシフトレフトする方法を紹介します。プルリクエストごとにセキュリティ、コスト、信頼性を分析し、インラインで修正提案を投稿し、堅牢化された YAML を自動コミットします。マージ後は ArgoCD があるべき状態を強制し、ドリフトを検知します。   [Speaker] Kyosuke Konishi – Associate Solutions Architect   7/30(木) 12:00-12:15 | AI エージェントのためのインフラ：AI エージェントワークロード向け Kro テンプレート （Japanese） >>> セッション資料 Kro と ACK を使い、AI エージェントのインフラ（複数の Kubernetes リソース + AWS リソース）を単一のカスタムリソースとしてテンプレート化します。AI エージェントワークロードを簡単にデプロイする方法をデモします。   [Speaker] Shota Suzuki – Solutions Architect   7/30(木) 13:00-13:15 | Amazon EKS Auto Mode による Kubernetes コスト最適化：Spot、統合、ゼロコンフィグ （English）   Kubernetes のコスト最適化には通常、Spot の専門知識、ノードグループのチューニング、キャパシティプランニングが必要です。EKS Auto Mode は、自動 Spot 統合、インテリジェントなインスタンス選択、低トラフィック時の継続的な統合、サブミニッツのバーストスケーリングにより、この運用負荷を解消します。Karpenter が手動設定なしでコスト効率を実現する様子をご覧ください。   [Speaker] Alex Kestner – Principal PMT-ES, Kubernetes   7/30(木) 13:40-13:55 | もう後戻りできない？そんな時代は終わり — EKS バージョンロールバックと恐れ知らずの Kubernetes アップグレード新時代 （Japanese） >>> セッション資料 Kubernetes のアップグレードは常に一方通行であり、チームはアップグレードを先延ばしにしたり、サポート切れのバージョンを使い続けたりしてきました。2026 年 7 月、Amazon EKS はバージョンロールバックを提供開始し、etcd データとワークロードを保持したまま 7 日以内に前のマイナーバージョンへ戻せるようになりました。本セッションでは、その仕組みと、ロールバックパスがアップグレード戦略をどう変えるかを解説します。   [Speaker] Ryota Yamada – Solutions Architect   7/30(木) 15:25-15:40 | EKS 向け Agent Skills：AI エージェントにスペシャリストレベルのアップグレード＆運用知識を （English） >>> セッション資料 EKS のアップグレードやクラスターヘルスレビューは、専門知識の不足から先送りされがちな Day-2 タスクです。本デモでは、シニア AWS スペシャリストの知見をエンコードしたキュレーション済み Agent Skills を紹介し、Claude Code や Kiro などのコーディングエージェントに読み込ませます。非推奨 API やアドオンの競合をスコア付き Go/No-Go レポートで検出し、優先度付きの運用レビューを実行する様子をご覧ください。オープンソースの APEX コレクションは Agent Skills 標準に準拠し、数分でスペシャリストレベルのアウトプットを提供します。   [Speaker] Eng-Hwa Tan – Prin. GTM SSA Containers ASEAN / Masatoshi Hayashi – Sr. GTM SSA Containers Japan  

こんにちは、株式会社ジーニー技術広報担当です！ GENIEE Tech Blogでは、日々の開発で得た技術的な知見や、生成AIの活用事例、プロダクト開発の裏側など、エンジニアによるさまざまな情報を発信しています。 今回は、直近1年間（2025年9月〜2026年9月）の閲覧データをもとに、特によく読まれた注目の記事を3本ピックアップしてご紹介します！ 「GENIEE Tech Blogを初めて読む」という方も、ぜひ気になる記事からチェックしてみてください。 Claude Code にAWSのコスト調査をさせたら数千万円分の改善ポイントが見つかった 記事を読む｜Claude Code に