メインフレーム基幹系システムの AWS 移行を真剣にご検討中のお客様向けのイベント「AWS Mainframe Modernization Day Tokyo 2026」を 2026 年 9 月 17 日(木) に開催しました。本ブログでその概要を紹介します。
本イベントは以下の三部で構成しました。

• Part 1: AWS セッション
• Part 2: お客様セッション
• Part 3: お客様同士の交流会

Part 1: AWS セッション

冒頭のオープニングは、アマゾンウェブサービスジャパン合同会社 (以下、AWS) WWSO EAMM シニアマネージャーの Shajan Miah からウェルカムメッセージと全体の流れの案内がありました。

(1)a. 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ: AWS データセンター

アマゾンデータサービスジャパン合同会社 (以下、ADS) のデータセンターエンジニアリングオペレーション部門シニアマネージャー 中台拓也は、AWS クラウドサービスを支える物理インフラの全体像を紹介しました。日本には東京・大阪の 2 つのリージョンがあり、各リージョンは最低 3 つのアベイラビリティゾーン (AZ) で構成され、低遅延レプリケーションと災害リスク分散を両立するよう 100km 以内に配置されています。データセンターの建物はグローバル共通のモジュラー型ブロック設計を採用し、ラック密度の将来的な増加に備えた構造耐荷重マージンや、ベンダー依存を排した自社開発のバックアップ電源制御ロジック、大型 UPS を廃止したラックレベルの小型 UPS / バッテリーモジュールによる障害影響範囲の最小化など、独自の垂直統合技術が特徴です。物理セキュリティは境界・インフラ・データの 3 層モデルで構成されています。運用面では、事前構成済みラックの搬入から自動プロビジョニングまでの完了や、障害対応に目標時間を設定しています。すべてのハードウェア作業を ADS 社員が直接担当することで継続的なプロセス改善を実現しています。

(1)b. 基幹系システムを支える AWS のコアテクノロジーとインフラストラクチャ: メインフレーム技術者のための AWS Nitro System 入門

AWS ソリューションアーキテクト 阿部純一郎は、メインフレームの知見を持つエンジニアを対象に、メインフレームとクラウドインフラの設計思想を両者の共通点と違いに着目して紹介しました。AWS Nitro System とメインフレームアーキテクチャは、仮想化と I/O 処理を汎用プロセッサからオフロードするという同一の設計哲学に収斂していると考えられます。2017 年以前にリリースされた Amazon EC2 インスタンスは Xen ハイパーバイザーを採用しており、リソース競合や機能リリースの遅延等の課題に直面していました。これを Nitro Cards (IBM Z のチャネルサブシステムに相当)、Nitro Hypervisor (PR/SM に相当)、Nitro Security Chip の 3 つのコンポーネントで解決しました。性能面では NVMe / TCP/IP 標準インタフェースによる OS 互換性の維持や最大 200 Gbps の帯域幅、独自の Scalable Reliable Datagram (SRD) プロトコルによるマルチパス分散を紹介し、セキュリティ面ではオペレーターアクセスの排除、API ベースの監査可能な運用、Nitro Enclaves による機密処理の隔離、Instance Attestation による改ざん検証といった二重の保護ドメインを説明しました。講演の締め括りでは、IBM Z の主要概念と Nitro System の対応関係を対比的に一覧表で示し、メインフレームエンジニアが AWS の設計を直観的に理解できるよう提示しました。

(2) セキュリティ ~ 「なんとなく不安」の正体を、ご一緒に

AWS シニアスペシャリストソリューションアーキテクト 松崎博昭は、聴講者自身がクラウドセキュリティを客観的に評価できるエビデンスベースのフレームワークを提供することを目的として解説しました。顧客が抱える 3 つの不安——「AWS スタッフにデータを見られないか」「監査証跡の可視性が失われないか」「セキュリティ対応範囲が増えないか」——に対し、データの暗号化に加え、規則ではなく仕組みで守る設計、AWS CloudTrail による不変の操作ログ (最低 90 日間削除不可)、そして責任共有モデルにより、修正適用などの手作業は AWS 側に移り、顧客の手元には運用判断が残ること(変わるのは「見張る」部分で、そこは自動で回る)を、それぞれ before / after 形式で解説しました。さらに、外部監査人により年間 2,600 項目以上の監査を実施しており、 SOC 2、ISO 27001、ISMAP のレポートは顧客が AWS コンソールから直接ダウンロードできます。また、公に報じられたクラウドのセキュリティ事故についても、基盤そのものが破られたのではなく、アクセス許可や公開設定といった「鍵の掛け方」が問われた事例を挙げ、守るべき対象と守り方は移行後も変わらないという文脈で共有責任の境界を示しました。最小権限・アクセス制御・ログ・鍵分離といった既存のセキュリティ原則は、そのまま AWS に移行可能です。暗号化・Amazon GuardDuty・IAM の権限点検といった備え付けの機能を示したうえで、判断は顧客自身が行うものであり、疑問点は担当のアカウントチームや社内のクラウド推進組織に持ち込めること、つまり「一人にはしない」と締め括りました。

(3) 安定稼働を実現する AWS のアプローチ: レジリエンシー

AWS 部長 兼 シニアソリューションアーキテクト 大村幸敬は、AWS におけるレジリエンシーの全体像を概説しました。メインフレームがハードウェア冗長による故障防止 (フォールトトレランス) を志向するのに対し、障害は起こり得るものとして迅速な復旧を設計するのがレジリエンスの考え方です。大手証券会社のシステム障害を契機に、日本の金融庁が「止まってはならない」方針からレジリエンス志向へ舵を切った実例がこの考え方を裏付けています。AWS のインフラは汎用 IA サーバーを基盤としつつ、マルチ AZ 配置 (単一リージョン内の約 100km 以内の 3 拠点) や責任共有モデルによるアーキテクチャ設計で高可用性を実現しています。ディザスターリカバリー (DR) については、バックアップ&リストアからマルチサイトアクティブ/アクティブまでの 4 パターンを、コストと RTO-RPO のトレードオフとともに提示しました。高額な待機ハードウェアを購入しておく必要が無く、DR 環境を常時稼働させずにコストを抑制することができます。さらに、システム外のレジリエンスとして、AWS Professional Services、Business Support+ / Enterprise Support、2025 年 12 月リリースの AWS Unified Operations により、日本語対応した専門支援体制を提供しています。

(4) 安定稼働を実現する AWS のアプローチ: 運用の高度化

続いて、大村幸敬は、メインフレームやオンプレミス環境での常識とは異なる、運用に関する新たな考え方を提示しました。第一のテーマとして、AWS を単なるインフラではなく IT のツールボックスと位置づけ、Amazon Connect 等のマネージドサービスによるハードウェアコストの削減と運用負荷の軽減、AWS CloudTrail / AWS Config による自動監査証跡を紹介しました。一方で、ツールは変わってもインフラ/ネットワークエンジニアの必要性が変わらない点も重要です。第二のテーマでは、AWS の大規模な冗長サーバー/ストレージプールを活かしたスナップショットによる環境の即時クローン、Infrastructure-as-Code (AWS CloudFormation) による 30 分以内の環境再構築、AI 支援テスト自動化や新たな AWS Security Agent (設計レビュー・コードレビュー・自動ペネトレーションテスト) を、メインフレーム環境ではコスト制約の大きいテスト環境拡張の代替手段として提示しました。第三のテーマでは、従来型モニタリングからオブザーバビリティへの転換を掲げ、人間の直感では対応困難な未知の障害の根本原因を AI で診断するアプローチを紹介しました。AWS・マルチクラウド・オンプレミス環境を横断してインシデント対応・予防・サイト信頼性エンジニアリング (SRE) タスクを自律的に実行するサービスとして新たにリリースされた AWS DevOps Agent は、既に日本の複数の顧客に採用されています。

(5) デモ: 今、生成 AI でメインフレーム何処まで何ができるのか?

AWS メインフレームモダナイゼーションスペシャリストソリューションアーキテクト 皆川元は、2 つのデモを実施しました。1 つ目のデモでは、Amazon Quick を用いた COBOL プログラム仕様書の自動生成と、データ項目に対する変更の影響調査を実演しました。後者は、従来の grep や RAG に基づく方式とは異なり、AWS Transform for mainframe によるデータリネージに基づいてデータの上流および下流を辿るアプローチを取りました。2 つ目のデモでは、AWS Transform によるレガシーコードのリバースエンジニアリングと、AI エージェント Kiro によるフォワードエンジニアリングを組み合わせた Reimagine アプローチを紹介しました。CardDemo アプリケーションの VSAM にアクセスするバッチ処理を S3 / DynamoDB / Java / Python による構成へ移行し、Kiro が CI/CD パイプラインまで自動生成する実例で、この手法の実用性を示しました。

(6) AWS セッションまとめ

これまでの AWS セッションの総括として、独自設計のデータセンターによる迅速な障害検知と復旧、AWS Nitro System による性能分離とセキュリティ、そしてセキュリティ、レジリエンシー、運用の高度化という 3 つの累積的メリットを振り返りました。メインフレームがこれまで 50 年にわたり支持されてきた信頼性・安全性・運用安定性を、AWS が最新のクラウドアーキテクチャで再現できることを示し、次の 50 年の安定稼働を支える信頼できるパートナーとしての AWS を位置づけて締め括りました。

Part 2: お客様セッション

王子イメージングメディア株式会社 神崎工場 事務部 グループマネージャーの野中伸恭氏は、現在実施中のモダナイゼーションに至った経緯と判断の過程を紹介しました。過去 2 回のメインフレーム刷新が現行システムのスパゲッティコード分析で頓挫した教訓から、3 回目は同じマイグレーション手法を避け、経営判断のもと業務そのものを刷新する方針に転換しました。オンプレミスでハードウェアの調達コストを試算したところ、社内承認を得るのが困難と判断し、AWS クラウドを採用しました。「小さく作って駄目なら作り直せる」柔軟性とアジャイル方式を武器に、現行メインフレームの契約更新時期である 2028 年から逆算した計画で構築を進めています。社内のコンセンサス確立を図るべく、現場メンバーの業務ノウハウを活かしつつ 70% の自動化を目指す方針を社内に示したところ、紙帳票の廃止や業務の断捨離を求める声がむしろ多いことがわかりました。2〜3 回の試行錯誤を経て、現在では全社が同じ方向を向いており、AWS Transform for mainframe による現行アプリケーションの仕様の確認や Kiro による AI 駆動開発も活用しながら、順調に前倒しで進行中とのことです。

Part 3: オフィスツアーとお客様同士の交流会

来場したお客様をフロア内でご案内し、麻布台ヒルズのオフィスのコンセプトを紹介しました。
続いて、交流会では、業種や業界を超えてお客様同士で共通の課題が話され、取り組みが共有されていました。
登壇したスピーカーも交えて、活発に質問や意見交換が行われました。セッションではカバーしきれなかった個別の技術相談やアイディアに、大いに盛り上がりました。

おわりに

本イベントでは、ミッションクリティカルワークロードの AWS 移行後の安定稼働にフォーカスした内容を提供しました。
メインフレームから AWS への移行は、お客様それぞれのゴールと課題があり、移行パターンや移行ソリューションも個々に異なります。AWS は、移行を推進するビルディングブロックとなるサービスを提供し、Professional Services (ProServe) による伴走型支援が可能です。更に、AWS 移行の実績を多く持つ経験豊富な AWS パートナーが end-to-end の移行ソリューションを提供しています。
AWS 移行に関するご相談は、担当営業もしくは AWS の担当者にお問い合わせください。