みなさん、こんにちは。AWS ソリューションアーキテクトの野間です。最近1週間の生成 AI を巡っては、Anthropic Claude Opus 4.7 の Amazon Bedrock 対応や、東京リージョンでの提供開始をはじめとして、「より強いモデルを、より現場に近い場所で動かす」ためのアップデートが相次ぎました。また4月20日〜24日に開催された Hannover messe では、AI技術による生産プロセスの最適化、効率化、そして企業の競争力向上と持続可能性が主要なテーマとなっていました 。データ分析中心のAIから「物理世界で自律的に動くフィジカルAI」への移行の加速が進んでいます。そして、AWS界隈も目が離せません。 それでは 4月 20 日週の生成 AI with AWS界隈のニュースを見ていきましょう。 さまざまなニュース ブログ記事「 富士通株式会社様との AI-DLC Unicorn Gym で見えた開発の未来 」 AWSが提唱するAI駆動開発ライフサイクル（AI-DLC）を実践的に学ぶプログラム「Unicorn Gym」に、富士通株式会社が参加した際の取り組みを紹介するブログです。7チーム40名弱が3日間、Amazon Bedrock AgentCoreやAmazon Connectなどを活用しながら、COBOLからJavaへの移行、ペーパーレス化システム、AIエージェントプラットフォーム、自動架電システムといった実課題に取り組んだ内容がまとめられています。記事では、COBOLからJavaへの移行で約4,300行のコードを自動生成した事例など、生成AIを活用した開発の具体的な成果が数字とともに語られています。あわせて、SE（システムエンジニア）の役割が「コードを書く力」から「仕様を策定する力」や「AIが生成した成果物をレビューする力」へとシフトしていく点にも触れられており、生成AIを使った開発プロセスを組織に取り入れたいユーザーにとって導入のヒントになる内容です。 ブログ記事「 【開催報告 & 資料公開】お試しから卒業！Kiro の仕様駆動開発を本格活用 in 大阪 」 2026年3月17日にアマゾン ウェブ サービス ジャパン 大阪オフィスで開催された「AWS Business Innovation Series – West Japan」第1回の開催報告ブログです。18社37名が参加し、AWSが提供するIDE「Kiro」を使った仕様駆動開発を、座学・ハンズオン・ハッカソンの3ステップで体験する内容が実施されました。参加者の約85%がIT部門、15%が事業部門で、開発経験者は全体の約10%と少数だった点が特徴で、普段コードを書かない参加者でも半日で動作するプロトタイプまで作れたという反応が紹介されています。「Vibe Coding」と「Specモード」の体験を通じて、要件定義から実装までの流れを掴める構成になっており、生成AIを使った開発に興味はあるが何から始めればよいか迷っているユーザーにとって、社内での取り組みを検討する際の参考になる内容です。 ブログ記事「 AUMOVIO が Amazon Bedrock 搭載のエージェント型コーディングアシスタントでソフトウェア開発を強化 」 自動車部品サプライヤーのAUMOVIO社が、AWSと協業してエージェント型のコーディングアシスタントを開発した事例を紹介するブログです。Amazon BedrockやAmazon SageMaker、AWS Lambdaなどを組み合わせ、自動車特有のコードベース（約7,000関数）でモデルをファインチューニングし、オープンソースの「Cline」を活用したエージェントとして実装されています。自動車業界のようにAUTOSARやMISRA-C/C++といった業界標準への準拠が求められる領域でも、ドメインに特化したファインチューニングとエージェント型のアプローチを組み合わせることで、コーディング支援の実用性を高められる点が特徴です。記事内ではシニア開発者が5日間かけていたバグ修正が数分で完了した例や、冗長なコードを削除してファイルサイズを半減させた事例も紹介されており、業界固有のルールを持つ組織で生成AIによる開発支援を検討しているユーザーにとって参考になる内容です。 ブログ記事「 AI for Science – AI がもたらす研究新時代 」 創薬・ゲノミクス・材料科学・気候科学・物理学といった科学研究の領域で、AI活用が実用段階に入りつつあるという「AI for Science」の潮流を解説したブログです。Amazon Bedrock、Amazon SageMaker AI、Amazon Textract、Amazon Comprehendなどを組み合わせた研究基盤の構成や、Genomics England、Allen Institute、LILA Sciences、アリゾナ大学といった海外の先進事例が紹介されています。文部科学省が推進する「SPReAD」事業の開始タイミングにあわせて、大学や研究機関の研究者に向けて書かれている点が特徴で、8〜12週間の小規模なPoC（概念実証）から始める段階的な進め方が示されています。研究データが基盤モデルの学習に利用されない仕組みなど、知的財産や個人情報に関するデータ保護の考え方にも触れられており、AI活用を検討している研究機関やそれを支援する立場のユーザーにとって参考になる内容です。 ブログ記事「 EngineLab AI: AWSで実現するスタジオとクリエイター向け本番制作AI環境 」 EngineLab社が提供するマネージドデプロイメントプラットフォーム「EngineLab AI」を、Amazon EC2のGPUインスタンスやAWS Deadline Cloud上で活用する方法を紹介するブログです。映像・メディア制作の現場でよく使われるComfyUIなどの生成AIアプリケーションを、本番環境で安定して運用するための構成が解説されています。顧客自身のAWSアカウント内にデプロイされるためデータがプラットフォーム外に出ず、知的財産（IP）を社内に留められる点や、必要なときだけGPUリソースを使うオンデマンド型の構成でオンプレミスの固定費を抑えられる点が特徴です。ノードベースの操作に慣れた上級者向けのUIと、技術知識のないクリエイター向けのArtist UIを両立している点にも触れられており、スタジオやクリエイター組織で生成AIを制作ワークフローに組み込みたいと考えているユーザーにとって、実装イメージをつかめる内容です。 ブログ記事「 開発現場から全社展開へ：Amazon Bedrock で Claude Cowork を動かす 」 Anthropic社が提供するデスクトップアプリ「Claude Cowork」を、Amazon Bedrockをバックエンドとして動かす方法を紹介するブログです。ドキュメントの読み取りや複数ステップのリサーチ、ファイル処理などをアプリ上で行いつつ、データを自社のAWSアカウント内に保持したまま利用できる構成が解説されています。Claude Codeのような開発者向けツールから一歩進んで、プロダクトマネージャー、オペレーションマネージャー、ファイナンスアナリストなど、社内のナレッジワーカー全体に生成AIの活用を広げていく展開イメージが示されている点が特徴です。MDM（モバイルデバイス管理）による一元的な設定配布や、シートライセンス不要の従量課金モデルにも触れられており、開発チームで始めた生成AI活用を組織全体にスケールさせたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 AI 駆動の業務変革手法：『課題は何ですか？』と聞くのをやめた日 」 AWSが開発した業務変革プログラム「AI BPR（AI-driven Business Process Re-Engineering）」について、試行錯誤の過程とともに紹介するブログです。初期の「課題解決型」アプローチが機能しなかった経験から、組織心理学の理論（Appreciative Inquiryなど）を取り入れて再設計し、Observe・Shift・Simulate・Forecastという4段階のフレームワークに行き着いた経緯が解説されています。生成AIの導入は技術的な問題よりも、組織が変化を受け入れる「適応課題」である点に焦点を当てている点が特徴で、AI活用を進めたいがなかなか現場が動かないと感じているユーザーにとって、アプローチを見直すヒントになる内容です。 ブログ記事「 IAM プリンシパルベースのコスト配分で Amazon Bedrock のコストを呼び出し元ごとに追跡する 」 Amazon Bedrockの利用コストを、呼び出し元のIAMユーザーやIAMロール単位で追跡できる新機能を紹介するブログです。Bedrock APIの呼び出しごとにIAMプリンシパルのIDが自動的に記録され、AWS Cost and Usage Report（CUR 2.0）やAWS Cost Explorerでプリンシパル単位のコストを可視化できるようになります。これまではBedrockの利用料金が単一の明細にまとまって表示されていたため、どのチームやプロジェクトがどれだけ使っているかを把握するにはAWS CloudTrailのログと突き合わせる必要がありました。この機能により、チャージバック（社内費用配賦）が正確に行えるようになり、複数チームで生成AIを活用している組織のコスト管理の負荷を下げられます。API Gateway経由でBedrockを呼び出す構成では中間ロールにコストが集約されるため、セッションタグでの動的な帰属が推奨されるといった実装上の注意点にも触れられています。 ブログ記事「 VPC 内のプライベートサービスに AWS DevOps Agent をセキュアに接続する方法 」 AWS DevOps Agentから、Amazon VPC内に閉じたプライベートなサービスに安全にアクセスする構成方法を紹介するブログです。Amazon VPC Latticeのリソースゲートウェイを経由して接続を確立し、セキュリティグループでトラフィックを制御する構成が解説されています。パブリックインターネットに公開することなく、エージェントから社内のプライベートなサービスにアクセスできる点がポイントで、具体例としてセルフホスト型Grafanaへの接続手順が紹介されています。これによりエージェントがオブザーバビリティ（システムの可視化）データを参照できるようになり、インシデント対応時の調査を自動化しやすくなります。AWS CLIとマネジメントコンソールの両方で設定手順が記載されているため、運用環境へのAWS DevOps Agent導入を検討しているユーザーにとって参考になる内容です。 ブログ記事「 Amazon Bedrock での Anthropic の Claude Opus 4.7 モデルのご紹介 」 Anthropic社の最新モデル「Claude Opus 4.7」がAmazon Bedrockで利用できるようになったことを紹介するブログです。米国東部（バージニア北部）、アジアパシフィック（東京）、欧州（アイルランド）、欧州（ストックホルム）の各リージョンで提供され、最大100万トークンのコンテキストウィンドウに対応しています。自律的にコーディングを進めるエージェンティックな用途での性能が向上しており、SWE-Bench Proで64.3%、Finance Agent v1.1で64.4%といったベンチマーク結果が紹介されています。Converse API、Invoke API、Messages APIといった複数の呼び出し方法に対応しているほか、新しい推論エンジンによる動的なキャパシティ割り当てやリクエスト数のスケールにも触れられており、長いドキュメントを扱う業務や、複数ステップにわたるコーディング・分析タスクにClaudeを組み込みたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 Opus 4.7 が Kiro で利用可能になりました 」 Anthropic の最新モデル Claude Opus 4.7 が Kiro IDE および CLI に順次展開されました。Opus 4.6 の直接アップグレード版として、複雑で長時間にわたるタスクでのコーディング性能が向上し、複数ファイル・ツールにまたがるマルチステップ実装や自己検証機能を備えています。Kiro の仕様駆動開発との親和性も高く、大規模コードベースでの高忠実度な実装を実現します。 ブログ記事「 Kiro CLI をプログラムから実行する：ヘッドレスモードの紹介 」 Kiro CLIを、ブラウザを介さずにプログラムから実行できる「ヘッドレスモード」を紹介しています。APIキーを発行して環境変数に設定するだけで、CI/CDパイプラインやcronジョブなど無人の自動化環境でKiroを動かせるようになります。具体例として、GitHub Actionsと組み合わせてプルリクエストに自動でコードレビューを行う実装方法が紹介されています。コードレビュー以外にも、ドキュメント生成、依存関係の監査、マイグレーション支援など幅広い用途に応用できる点が特徴で、開発者の手元だけでなく、CIパイプラインの中に生成AIを組み込んでいきたいと考えているユーザーにとって参考になる内容です。 ブログ記事「 Kiro でビルドする：コミュニティハブと Kiro Labs の紹介 」 Kiroのエコシステム拡張として、「Kiro Community（コミュニティハブ）」と「Kiro Labs」の2つが発表されました。コミュニティハブは開発者の実験的なプロジェクトの共有や、Discord・イベントを通じた情報交換の場として機能し、Kiro Labsはアマゾン社員が構築したオープンソースプロジェクト群を公開する場として位置づけられています。Kiro Labsではカスタムワークフロー、UI、生産性向上ツールなどが「as-is」で提供され、アクティブ・メンテナンス・アーカイブの3段階のステータスが付与されるほか、Amazonのオープンソース基準に沿ったセキュリティレビューも行われます。Kiroをすでに使っているユーザーにとっては、他の開発者の実装例を参照してワークフローを組み立てたり、プルリクエストで貢献したりといった形で活用できるリソースが増える内容です。 サービスアップデート Claude Platform on AWSが近日公開 Anthropic社が提供するネイティブのClaudeプラットフォームを、AWSの認証情報と請求の仕組みでそのまま利用できる「Claude Platform on AWS」が近日公開として発表されました。Anthropic本家のプラットフォームと同じAPIや機能にアクセスできるため、Claudeの最新機能をいち早く利用できるのが特徴です。利用にあたっては、別途Anthropicとの契約や認証情報を用意する必要はなく、既存のAWSアカウントとIAMポリシーをそのまま使えます。APIコールはAWS CloudTrailに記録されるため、ほかのAWSサービスと同じように監査ログを一元的に管理でき、利用料金もAWSの請求書にまとめられます。Amazon Bedrockが「AWSの基盤上でClaudeを動かし、データをAWS内で処理・保持する」位置づけなのに対し、Claude Platform on AWSは「Anthropic側のプラットフォームをAWSの認証・請求で使う」という選択肢を提供する形で、ユースケースに応じて使い分けられる点がポイントです。 Amazon Bedrock AgentCoreが新機能を追加しエージェント開発を加速 Amazon Bedrock AgentCoreに、エージェント開発を加速するための新機能が追加されました。モデル・システムプロンプト・ツールを指定するだけで即座にエージェントを動かせる「マネージドハーネス（プレビュー）」、AWS CDK対応でコードベースのガバナンスを実現する「AgentCore CLI」、コーディング支援ツール向けの事前構築スキル「AgentCore Skills」の3つが提供されます。オーケストレーションコードを書かずにアイデアからプロトタイプまでを素早く立ち上げられる点が特徴で、プロトタイプの進化に合わせて評価・メモリ・ツールを段階的に追加していくこともできます。AgentCore SkillsはまずKiroから利用でき、Claude Code・Codex・Cursorにも順次対応予定です。マネージドハーネスは米国西部（オレゴン）、米国東部（バージニア北部）、欧州（フランクフルト）、アジアパシフィック（シドニー）の4リージョンでプレビュー提供されています。 Amazon QuickがVisierのVeeエージェントと統合し、ワークフォースインテリジェンス機能を提供 Amazon Quickが、Visier社の人材分析プラットフォームのAIアシスタント「Vee」とMCP（Model Context Protocol）経由で統合されました。これにより、Amazon Quickのワークスペース内から、Visierが管理する人員数・離職率・勤続年数・求人情報などのワークフォースデータに自然言語でアクセスできるようになります。人事・財務・オペレーション部門の担当者が、ツールを切り替えることなく組織の人材データを参照できるようになる点が特徴で、定期的なワークフォースレビューやドキュメント作成をQuick Flowsで自動化する使い方も想定されています。Amazon Quickがサポートする全リージョンで利用でき、組織全体の予算やポリシーデータと合わせて意思決定に活用したいユーザーにとって参考になる内容です。 Amazon Bedrock AgentCore GatewayとIdentityがVPC egress に対応 Amazon Bedrock AgentCore GatewayとAmazon Bedrock AgentCore Identityが、VPC egress（VPC内のプライベートリソースへの接続）に対応しました。マネージド型のVPC egressと、自己管理型のAmazon VPC Latticeリソースの両方から構成を選択でき、東京リージョンを含む14のAWSリージョンで利用可能です。これにより、Amazon EKS上でホストしているMCPサーバーや、社内ネットワーク内のプライベートなアイデンティティプロバイダー（IdP）、プライベートDNSで名前解決するリソースなどに、AgentCoreから直接アクセスできるようになります。エージェントからプライベートなエンタープライズシステムに安全に接続したいユーザーにとって、構成の選択肢が広がる内容です。 Amazon SageMaker HyperPodが自動Slurmトポロジー管理に対応 Amazon SageMaker HyperPodが、ネットワークトポロジーを自動で選択・最適化する機能に対応しました。GPUインスタンスタイプに応じてツリートポロジー（階層的な相互接続）とブロックトポロジー（均一な高帯域幅）を自動で選び、クラスターのスケール変更やノード置換の際にも継続的に最適化されます。これまでSlurm設定ファイルやトポロジーファイルを手動で管理していた運用から解放され、GPU間通信（NCCL集約通信）の効率を保ったまま分散学習を進められる点が特徴です。機能はデフォルトで有効化されており設定不要なため、大規模な分散学習を行うユーザーにとって運用負荷の軽減につながる内容です。 Amazon SageMakerがIAM Identity Centerドメインでノートブックとデータエージェントに対応 Amazon SageMaker Unified Studioで、これまでIAMドメインでのみ利用できたサーバーレスノートブックと組み込みのデータエージェントが、AWS IAM Identity Center（IdC）ドメインでも利用できるようになりました。Amazon Athena for Apache Sparkと連携し、SQL・Python・自然言語を単一の対話型ワークスペース上で組み合わせて扱えます。AWS IAM Identity Centerで認証・アクセス管理を一元化している組織でも、IAMドメインと同等の分析・機械学習機能が使えるようになる点がポイントで、AIデータエージェントが自然言語のプロンプトからコードを生成する機能や、ペタバイト規模のデータ処理にも対応しています。シングルサインオン環境を維持したままデータ分析基盤を整備したいユーザーにとって参考になる内容です。 Amazon QuickがSharePointとGoogle Driveを対象としたナレッジベースで複数所有者機能をサポート Amazon Quickで、Microsoft SharePointとGoogle Driveを対象とした管理者管理型のナレッジベースに、複数の所有者を追加できるようになりました。所有者には「オーナー」と「ビューアー」の2種類があり、オーナーは編集・同期・共有・削除を含む管理権限を、ビューアーはクエリのみの権限を持ちます。これまでナレッジベースが単一の所有者に依存していた運用から、チーム単位での共同管理が可能になる点が特徴で、既存のデータソース接続をそのまま再利用できるため、認証情報を再入力する必要もありません。東京リージョンを含む7つのAWSリージョンで利用でき、複数メンバーで社内ナレッジの整備を担当しているユーザーにとって運用がしやすくなる内容です。 Amazon QuickがACL対応ナレッジベースの権限検証機能をサポート Amazon QuickのACL（アクセス制御リスト）対応の知識ベースで、特定のユーザーが特定のドキュメントにアクセスできるかを検証するPermission Checker機能が追加されました。管理者は「Sync reports」タブからメールアドレスを入力することで、アクセス可否や、対象ドキュメントにアクセス可能なユーザー・グループ一覧を確認できます。これまではデータソース側の権限継承を手作業で追いかける必要があり、権限設定のトラブルシューティングに手間がかかっていました。機密情報が想定外のユーザーに参照されていないかを体系的にチェックできるようになるため、社内ナレッジを扱う知識ベース運用のセキュリティ確認を効率化したいユーザーにとって役立つ内容です。東京リージョンを含む7つのAWSリージョンで利用できます。 Amazon SageMaker Unified StudioがIAMドメインのプロジェクト内で複数コードスペースに対応 Amazon SageMaker Unified Studioで、IAMドメインの単一プロジェクト内に複数のコードスペース（個別に設定できる開発環境）を作成・管理できるようになりました。従来はプロジェクトあたりJupyterLabスペース1つとCode Editorスペース1つに限られていましたが、それぞれ独立したAmazon EBSボリュームを持つ複数のスペースを用意できます。長時間のデータ変換ジョブを動かしながら別スペースでモデル学習を進めるといった並行作業がしやすくなる点が特徴で、スペースごとに計算リソースやストレージをスケールさせたり、一時停止・再開したりできます。ブラウザからもローカルIDEからも接続でき、Amazon Q有料版にも対応しているため、1つのプロジェクト内で複数のワークストリームを回しているデータサイエンティストにとって作業効率の向上につながる内容です。 Amazon SageMaker AIがQwen3.5モデルのサーバーレスモデルカスタマイズに対応 Amazon SageMaker AIで、Alibaba Cloudが提供するQwen3.5モデル（4B・9B・27Bパラメータ版）に対するサーバーレスのファインチューニングがサポートされました。教師ありファインチューニング（SFT）と強化学習ファインチューニング（RFT）の両方に対応し、クラスター管理を行わずにモデルカスタマイズを実行できます。自社の独自データでモデルを調整して業界特有の用語や品質基準に適応させたい場合でも、インフラの構築や運用はAmazon SageMaker AI側が担うため、データや評価設計に集中できる点が特徴です。利用した分だけの従量課金モデルで、東京リージョンを含む4つのAWSリージョン（米国東部（バージニア北部）、米国西部（オレゴン）、アジアパシフィック（東京）、欧州（アイルランド））で提供開始されており、Qwen3.5を自社ユースケース向けに特化させたいユーザーにとって選択肢の一つになります。 Amazon SageMaker AIが生成AI推論レコメンデーション機能を提供開始 Amazon SageMaker AIに、生成AIモデルの推論環境を自動でベンチマークし、最適な構成を提案する「推論レコメンデーション」機能が追加されました。ユーザーがモデルとトラフィックパターン、性能目標（コスト最適化・レイテンシー最小化・スループット最大化のいずれか）を指定すると、システムが複数のインスタンスタイプを評価し、検証済みのメトリクスとともにデプロイ可能な構成を返します。初回応答時間（TTFT）、トークン間レイテンシー、スループット、コスト予測といった指標が一度にまとめて得られるため、手動でベンチマークを組んで比較する手間を省ける点が特徴です。東京リージョンを含む7つのAWSリージョンで利用でき、生成AIモデルを本番展開する際のインスタンス選定に悩んでいるユーザーにとって参考になる内容です。 Amazon SageMaker JumpStartで5つの新しいQwenモデルが利用可能に Amazon SageMaker JumpStartで、Alibabaが提供するQwenシリーズの新しい5つのモデルが利用できるようになりました。ツール利用や実行失敗からの復旧に対応する「Qwen3-Coder-Next」、思考モードの切り替えに対応した「Qwen3-30B-A3B」、数学・科学・コーディングの推論に特化した「Qwen3-30B-A3B-Thinking-2507」、エージェント型コーディング向けの「Qwen3-Coder-30B-A3B-Instruct」、マルチモーダルに対応する軽量モデル「Qwen3.5-4B」の5種類です。数クリックでデプロイできるJumpStartの特性を活かして、コーディングエージェントや多言語アプリケーション、軽量モデルでのコスト最適化された推論など、用途に応じたモデルを選択しやすくなっています。Qwenシリーズを自社のユースケースで試したいユーザーにとって、選択肢が広がる内容です。 Amazon EC2 G7eインスタンスがAWS Local Zonesロサンゼルスで利用可能に Amazon EC2のG7eインスタンスが、AWS Local Zonesのロサンゼルス（us-west-2-lax-1b）で利用できるようになりました。NVIDIA RTX PRO 6000 Blackwell Server Edition GPUと第5世代Intel Xeon Scalableプロセッサを搭載しており、VFXや色補正などのクリエイティブ制作から、大規模言語モデルの推論といったAIワークロードまで幅広く対応します。ロサンゼルス周辺でスタジオワークステーションやポストプロダクション、エッジでのAI推論といった低レイテンシーが求められる用途に、地理的に近い場所からGPUリソースを利用できる点がポイントです。オンデマンドとSavings Plansの両方で購入でき、メディア・エンタテインメント業界やエッジAIの導入を検討しているユーザーにとって選択肢の一つになる内容です。 「 AWS ジャパン生成 AI 実用化推進プログラム 」も引き続き実施中ですので検討してみてください。 今週は以上です。それでは、また来週お会いしましょう！ 著者について 野間 愛一郎 (Aiichiro Noma) AWS Japan のソリューションアーキテクトとして、製造業のお客様を中心に日々クラウド活用の技術支援を行なっています。データベースやデータ分析など、データを扱う領域が好きです。最近天ぷらを(食べるのではなく)揚げるほうにハマってます。

DevOpsグループCREチームのy.s.です。 2026年3月25日に開催された CRE Camp #5 現場でつくるユーザー信頼性 ー LTと対話のセッション ー に参加してきました。 CRE Campは、Customer Reliability Engineering（CRE）やCustomer Support/Successに関わるエンジニアが集まり、プロダクトの信頼性向上やユーザー体験の改善について事例共有・対話するMeetupです。今回の会場は弁護士ドットコム株式会社（六本木）。LTと対話セッション、そして後半にはアンカンファレンスという構成でした。 なお、2025年10月の

この記事は、”Reimagine your mainframe applications with Agentic AI and AWS Transform” を翻訳したものです。 本ブログでは、reimagine パターンによってメインフレームのレガシーアプリケーションをモダナイズする AWS のアプローチの概要を説明し、組織がレガシー COBOL アプリケーションをモダンなクラウドネイティブアーキテクチャに変換する方法を紹介します。 人材不足、コスト増加、ビジネスアジリティの制約により、組織はレガシーメインフレームアプリケーションをモダナイズする喫緊の課題に直面しています。 AWS は、メインフレームアプリケーションをモダナイズするための複数のアプローチをサポートしています。Reimagine パターンにより、組織はカスタマーエクスペリエンスを再構想 (reimagine) し、ビジネスプロセスフローを最適化し、新機能を導入することで、モダンなアプリケーションに機能的な変化をもたらすことができます。このプロセスで、メインフレームアプリケーションをモダナイズすることができます。この過程は、モダンなアーキテクチャとテクノロジースタックを使った、アーキテクチャの再設計 (rearchitecting) と、アプリケーションのリライト (rewriting) を伴います。トランスフォーメーションジャーニーを加速させるため、エージェンティック AI を活用したツール一式によって、メインフレームのモダナイゼーションの reimagine パターンがサポートされています。 メインフレームアプリケーションを再構想するときの戦略的課題 AWS は、メインフレームモダナイゼーションの特効薬が無いことを認識しています。戦術的アプローチは既存システムの拡張と維持に重点を置いていますが、戦略的モダナイゼーションには リプラットフォーム (replatform)、リファクタリング (refactor)、リプレース (replace)、reimagine という明確な道筋があります。Reimagine は最も変革的なアプローチを代表しており、組織はマイクロサービスやバッチプロセスからリアルタイム機能への移行などのモダンなパターンを使って、アプリケーションアーキテクチャを全面的に見直します。 ほとんどのお客様は、reimagine 戦略を検討する際に 80:20 の原則に従います。Reimagine は、ビジネスでアプリケーションの機能強化が必要な場合に適しています。お客様は、メインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、モダンな UI、リアルタイム機能、またはより高速なバッチ処理が望まれている可能性があります。また、現行のモノリス化したアプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標をお客様が持っている場合もあります。お客様は、自社のメインフレームアプリケーションの 20% が技術的な制約のせいでビジネスレベルの変更から真に恩恵を受けられない一方で、残り 80% は機能変更を必要としていないことに気付くかもしれません。ただし、一部の組織では、短期的な移行効率よりも長期的なビジネス変革を優先しており、パターンの選択は機能変更を必要とするアプリケーションの割合だけではなく、戦略的目標にも依存していることが実証されています。この洞察は AWS のマルチパターン戦略を推進する要素の 1 つです。AWS は複数の移行パターンをサポートしているので、お客様は各ワークロードに最適なモダナイゼーションアプローチを選択できるようになっています。 参考 5 AWS の reimagine 戦略の中心にあるのが AWS Transform for mainframe です。これは、エージェンティック AI を活用して、メインフレームアプリケーションのモダナイゼーションを加速するサービスです。このサービスにより、お客様は COBOL などの言語で記述されたモノリシックアプリケーションを、マイクロサービスのような、よりモダンなアーキテクチャスタイルに変換できます。AWS の reimagine 戦略の中心は、「Human in the Loop」原則に基づく検証です。この原則では、AI が生成したアプリケーション仕様とコードは、各分野の専門家によって継続的に検証される必要があります。AWS Transform for mainframe は強力なリバースエンジニアリングを提供し、Kiro はマイクロサービス仕様を生成します。ただし、プロセス全体を通して、人間の専門知識は依然として不可欠です。ビジネスロジックの解釈を検証し、アーキテクチャの境界を確認し、アプリケーションがすべての要件を満たしていることを検証するには、専門家が必要です。AI の機能と人間の判断によるこの協調的なアプローチは、AI を活用したモダナイゼーションのスピード上の利点を維持しながら、トランスフォーメーションのリスクを大幅に軽減します。 Strangler fig パターン: 進歩的なモダナイゼーションを可能にする手法 企業のお客様が、すべてのアプリケーションをメインフレームから同時に一括移行するようなビッグバンアプローチの大規模なモダナイゼーションを追求することはめったにないと認識されています。Strangler Fig アプリケーションパターンは、漸次的なモダナイゼーションの手法として実証済の選択肢です。このパターンは、トランスフォーメーション、共存、排除という 3 つの段階を経て、メインフレームアプリケーションをモダナイズするための安全なアプローチとなります。 Strangler fig パターンは、漸次的なモダナイゼーションアプローチです。これにより、組織は元のアプリケーションを実行したまま、モノリシックアプリケーションを徐々にマイクロサービスに置き換えることができます。このアプローチは、モノリスから機能を段階的に抽出することで機能します。抽出された機能は、既存のシステムを中心とした新しいマイクロサービスに変換されます。その後、統合パターンにより、新しいマイクロサービスとレガシーアプリケーションの間の接続が可能になります。 共存フェーズでは、メインフレームと AWS 上の新しいシステムの両方が同時に動作し、システム間の連携が行われます。連携パターンは、アプリケーション間の連携、アプリケーションからデータに対する連携、データ間の連携の 3 種類の統合をサポートします。 参考 4 このような連携アーキテクチャを構築し、共存に適した統合パターンを選択するには、お客様はハイブリッド環境全体におけるデータの一貫性、トランザクション管理、パフォーマンスに特に注意を払う必要があります。 メインフレームモダナイゼーションのためのマイクロサービスアーキテクチャの理解 マイクロサービスアーキテクチャーでは、従来のメインフレームのモノリシックなアーキテクチャーとは対照的に、システムを独立した小さなサービスに分割し、個別に開発、デプロイ、拡張できるようにすることを重視しています。メインフレームモダナイゼーションという文脈において、マイクロサービスには、明確なコンテキスト、独立したデプロイ、テクノロジーの多様性、スケーラビリティなど、重要な価値ある特徴があります。 マイクロサービスとイベント駆動型アーキテクチャを組み合わせると、バッチ処理からリアルタイム処理に移行する際に特に強力になり、変更に対してシステムが非同期で反応できるようになります。 マイクロサービスには大きなメリットがありますが、普遍的に最適なソリューションというわけではありません。データの一貫性やトランザクション性が必要な場合は、モジュラーモノリスやマクロサービスなどの代替アプローチの方が適している場合があります。重要なのは、現在のニーズと将来の願望の両方に適合するアーキテクチャを選択することです。 Reimagine パターンにおける 3 フェーズのモダナイゼーションアプローチ Reimagine パターンでは、3 フェーズの方法論を通じて、現行のメインフレームアプリケーションをクラウドネイティブなマイクロサービスに変換します。 リバースエンジニアリング : AWS Transform for mainframe を使用してリバースエンジニアリングを行い、既存の COBOL / JCL コードからビジネスロジックとルールを抽出します フォワードエンジニアリング : AI エージェント / Kiro を使ってマイクロサービス仕様とソースコードの両方を生成します デプロイとテスト : 生成されたマイクロサービスを Infrastructure as Code (IaC) を使って AWS にデプロイしてテストし、モダナイズしたアプリケーションの機能をテストします Reimagine パターンにおける 3 フェーズのモダナイゼーションアプローチ フェーズ 1: リバースエンジニアリング AWS Transform for mainframe を使ったリバースエンジニアリングのスコープを以下の図に示します。 AWS Transform を使ったリバースエンジニアリング モダナイゼーションを成功させるための基礎は、レガシーアプリケーションを深く理解することから始まります。AWS Transform は、メインフレームのソースコードと運用データ (スケジューラープラン、モニタリングデータ) など、複数のソースからの情報を組み合わせて分析します。このフェーズでは、次のような重要なアウトプットが得られます。 技術文書 : AWS Transform はソースコードを自動的に分析して、アプリケーションプログラムの詳細な文書を作成します。このドキュメントには、レガシーシステム内のプログラムロジック、フロー、連携、依存関係についての説明が含まれています。レガシーシステムに関する重要な知識を維持することで、退職するメインフレーム専門家への依存を減らすのに役立ちます。また、これまで分析や計画に費やされていたプロジェクト時間も短縮されます。 ビジネスロジックの抽出 : ビジネスロジックの抽出は、複雑なモノリシックアプリケーションをその構成要素であるビジネス機能に分解する、メインフレームのモダナイゼーションにおいて不可欠な機能です。AWS Transform は COBOL ソースコードを自動的に分析します。この分析は、レガシーアプリケーションに組み込まれているプロセスフローやビジネスロジックなど、重要なビジネス要素を特定して文書化するのに役立ちます。この分解プロセスは、モノリス化したメインフレームアプリケーションをより小さく、より管理しやすいビジネス機能に分解するための基本です。これらの機能は、reimagine の取り組みにおける後半の工程でマイクロサービスのスコープと境界を特定するための基礎となります。この機能は、技術ユーザーとビジネスユーザーの両方が理解できるエクスポート可能な自然言語で仕様を提供することで、モダナイゼーションの取り組みにおける複数のステークホルダーに役立ちます。 メインフレームデータモデル : AWS Transform には、データリネージ分析やデータディクショナリの自動生成など、メインフレームのモダナイゼーションを成功させるために不可欠な高度なデータ分析機能が備わっています。これらの機能が連携して、メインフレームデータの「場所」(使用法と関係) に付随する「内容」(構造と意味) を定義します。組織はデータ環境を完全に可視化できるようになり、情報に基づいたモダナイゼーションの意思決定が可能になります。技術チームは、重要なビジネスロジックとデータ間の関連性を維持しながら、自信を持ってデータアーキテクチャを再設計できます。 稼働分析 : システム管理機能 (SMF) を介してメインフレームから収集された実行時データによって、静的コード分析を補完することができます。SMF は z/OS サブシステム上のアクティビティデータを収集するための中心的なメカニズムです。これらの記録に含まれる情報は、モダナイゼーションの計画、優先順位付け、実行に不可欠です。AWS Transform は SMF データ (バッチ処理ではレコードタイプ 30、CICS トランザクションではレコードタイプ 110) を分析して、アクティブなバッチジョブと CICS トランザクションを識別できます。使用済み/未使用のトランザクション/バッチを検出し、トランザクション/バッチの MIPS 使用量を測定することで、組織は未使用のプログラムと消費量の多いリソースを特定できます。これにより、何を移行し、何を廃止するかについてデータ主導の意思決定が可能になり、メインフレームのリソース使用率をかつてないほど可視化できます。 フェーズ 2: フォワードエンジニアリング フォワードエンジニアリングは、抽出されたビジネスロジックをマクロサービス/マイクロサービスのアーキテクチャに変換することを目的としています。 AWS は、お客様組織内の多様なニーズを認識し、パートナー主導型およびお客様主導型の柔軟なコード生成アプローチを採用しています。AWS は、既存の開発者ツールと競合するのではなく、リバースエンジニアリングで得られた豊富な理解を 促進 することに重点を置いています。これにより、既存のコードを複数の方法でモダンなアプリケーションに正確に変換できるようになります。 Kiro やその他のコーディングアシスタントなどの好みの開発ツールを使用した、お客様主導またはパートナー主導の開発 AI を活用したコーディングアシスタントとしての Kiro や AI エージェントの活用 AWS Transform は Kiro のような AI を活用したコーディングアシスタントと連携して、仕様駆動型の開発をサポートします。これらのツールは互いに補完し合っています。AWS Transform が提供するアウトプットは、Kiro がマイクロサービス仕様とソースコードの両方を生成するためのインプットになります。 Kiro と AI エージェントのアプローチについて詳しく見ていきましょう。このアプローチは 3 つの異なるステップで構成されており、正しさと品質を Human in the Loop で 検証 します。 以下の図は、 Kiro または AI エージェントを使ったフォワードエンジニアリングのスコープを示しています。 Kiro / AI エージェントを使ったフォワードエンジニアリング ステップ 1: マイクロサービス仕様の生成 このステップでは、ビジネスロジックの抽出を入力として、AI エージェントまたは Kiro を使い、各マイクロサービスの詳細な仕様を作成します。Kiro の仕様駆動型のアプローチにより、アーキテクトはマイクロサービスを設計して正式な仕様を作成し、実装を開始する前に、アプリケーションの対象分野の専門家が各仕様を確認して改良することができます。プロジェクト固有のステアリング文書を作成することで、Kiro はインプット (ビジネスロジック、データ分析、非機能要件など) と要件についての理解を深めることができます。このステップでは、トレーサビリティとビジネスルールの包括的な適用範囲を検証する必要があります。これにより、特定されたすべてのビジネスロジックが適切に分析され、関連するマイクロサービス仕様に組み込まれたかどうかを追跡できます。 Kiro にマイクロサービス仕様の生成を依頼するステアリングファイルのサンプルを次に示します。 マイクロサービス仕様を生成するためのステアリングファイルのサンプル 【参考】日本語訳 ## Role: あなたはソフトウェア設計、特にドメイン駆動設計、マイクロサービスアーキテクチャ、システムモダナイゼーションの分野で 20 年以上の経験を持つシニアソフトウェアアーキテクトです。エンタープライズアプリケーションのモノリスからマイクロサービスへのトランスフォーメーションを何十回も成功させてきました。あなたは、境界コンテキストの特定、クリーンなドメインモデルの設計、効果的なサービス境界の構築に関する専門家です。ソフトウェア設計パターン、API 設計、イベント駆動型アーキテクチャ、フロントエンド統合戦略に関する深い知識を有します。 ## Action: … `input/bre_output` フォルダーとサブフォルダー内の提供された HTML ファイルと JSON ファイルを分析して、現在のビジネスロジック、データ構造、および暗黙的なドメインモデルを理解してください。追加のコンテキストが必要な場合のみ、`input/source-code` フォルダーとサブフォルダーのソースコードを参照してください。 `input/bre_output` フォルダーとサブフォルダー内の HTML ファイルと JSON ファイルにあるビジネスロジックに基づいて、主要なビジネスドメイン、サブドメイン、潜在的な境界コンテキストを特定します。追加のコンテキストが必要な場合のみ、`input/source-code` フォルダーとサブフォルダーのソースコードを参照してください。 ドメイン駆動設計の原則を適用して、独自のユビキタス言語、集合ルート、エンティティ、バリューオブジェクト、ドメインイベントを使用して明確な境界のあるコンテキストを定義します。 特定された境界コンテキストに基づいてマイクロサービスアーキテクチャを設計し、各マイクロサービスが単一の責務を担い、独自のデータを管理するようにします。 ステップ 2: ターゲットデータベースの生成 データベースのモダナイゼーションは、メインフレームトランスフォーメーションプロジェクトにおける極めて重要な課題です。レガシーメインフレームデータベースは、IMS/DB や IDMS などの階層型データベースやネットワーク型データベース、または Db2 などのリレーショナルデータベースを使って構成されています。これらのデータベースには、ビジネス上の重要なデータが何十年にもわたって蓄積されていますが、今となっては時代遅れのデータモデルに従って構造化されているものもあります。ターゲットデータベースの生成フェーズでは、これらのレガシーデータ構造を、データの整合性とビジネスルールを維持しながらマイクロサービスアーキテクチャをサポートするモダンなクラウドネイティブなデータベーススキーマに変換します。AWS Transform のデータ分析機能により、レガシーデータベース構造を包括的に理解できます。Kiro は、このデータ分析結果をターゲットアプリケーションの仕様と組み合わせてインプットとして使用し、ターゲットのモダナイズされたデータベースを作成します。 ステップ 3: ソースコード生成と Infrastructure as Code の生成 仕様を検証した後、Kiro は実装フェーズに移行し、本番環境ですぐに使えるマイクロサービスコードと Infrastructure as Code を生成します。実装プロセスは、要件定義、設計、実装タスクという Kiro の 3 フェーズのワークフローに従います。このフェーズでは、Kiro は実装タスクを自律的に実行できます。一方、開発者は生成されたコードのレビュー、フィードバックの提供、要件に対する実装の検証に集中できます。このプロセスにはステアリングファイルが不可欠です。これによって Kiro はプロジェクトの規約、ライブラリ、標準に関する永続的な知識を得ることができ、確立されたアーキテクチャガイドラインやコーディング標準に準拠することができます。この構造化されたアプローチにより、チームは実装戦略を見直し、改良することができます。また、品質保証活動のための包括的なテストケースとテストデータの生成にも役立ちます。 Kiro にマイクロサービスのターゲットソースコードの生成を依頼するステアリングファイルのサンプルを次に示します。 ターゲットソースコードの生成のためのステアリングファイルの例 【参考】日本語訳 ## Action: まず microservices-specs フォルダーから提供されたマイクロサービス仕様を分析し、必要な各マイクロサービス、その責務、データモデル、連携ポイントを特定します。 以下を含む customer-management-service マイクロサービスシステムの全体的なアーキテクチャを設計します。 サービスの境界と責任 データの所有権と共有のアプローチ 通信パターン (同期 vs 非同期) 各コンポーネントの AWS サービスの選択 仕様書に記載されている customer-service マイクロサービスの場合: 適切な Maven/Gradle 構成で Spring Boot プロジェクト構造を作成する データモデルフォルダの下にある顧客の DynamoDB テーブル定義をマッピングするデータモデルを実装する REST のベストプラクティスに従って RESTful API コントローラーを開発する サービス層のビジネスロジックを指定どおりに実装する 適切な例外処理、検証、ロギングを追加する AWS サービスインテグレーション (必要に応じて DynamoDB、SQS、SNS など) を設定する サービスのユニットテストを書く 以下は、マイクロサービスを実装するためのプロンプトとステアリングファイルから Kiro によって生成されたタスクファイルのサンプルです。 マイクロサービスを実装するタスクファイルの例 【参考】日本語訳 [x] 1. 顧客管理サービスのプロジェクト構造を設定する Maven のディレクトリ構成で Spring Boot プロジェクトを作成する マルチモジュールプロジェクト構造 (domain, application, infrastructure, web) を設定する さまざまな環境 (dev, staging, prod) に合わせてアプリケーションプロパティを設定する 重要な依存関係 (Spring Boot, Spring Data, AWS SDK, validation, testing) を追加する _要件: 1.1、2.1_ [x] 2. コアドメインモデルとバリューオブジェクトを実装する [x] 2.1 ドメインロジックによる顧客集約ルートを作成する すべての必須フィールドとビジネスメソッドを含む Customer エンティティを実装する バージョンフィールドによるオプティミスティックロックを追加する ドメイン検証ルールを実装する _必要条件:5.1、5.5_ [x] 2.2 データの一貫性を実現するためのバリューオブジェクトを実装する ID が 9 文字であることのチェックも含めて CustomerID バリューオブジェクトを実装する フォーマット検証と暗号化をサポートする SSN バリューオブジェクトを作成する 電話番号のフォーマット (XXX-XXX-XXXX) のチェックを含む PhoneNumber バリューオブジェクトを作成する 値の範囲が 300 ～ 850 になるチェックを含む FICoScore バリューオブジェクトを作成する _必要条件:5.3_ フェーズ 3: デプロイとテスト 最後のフェーズでは、生成されたマイクロサービスを、さまざまなコンピューティングオプションとストレージオプションを使用して AWS クラウドネイティブアーキテクチャにデプロイします。お客様は、コンピューティングサービスとして Amazon Elastic Container Service (ECS)、Amazon Elastic Kubernetes Service (EKS)、AWS Lambda、AWS Fargate の中から選択できます。データベースオプションには、NoSQL ワークロード用の Amazon DynamoDB、リレーショナルデータベース用の Amazon Aurora、またはその他の AWS データベースサービスが含まれます。デプロイでは、AWS CloudFormation、AWS Cloud Development Kit (CDK)、Terraform などの Infrastructure as Code ツールを使って AWS リソースのモデル化とプロビジョニングを行います。 以下は、AWS CloudFormation テンプレートを使って新しいマイクロサービスアーキテクチャを AWS クラウドにデプロイするように生成された Infrastructure as Code のサンプルです。 生成された Infrastructure-as-Code の例 再構想 (reimagine) された新しいアプリケーションは、この新しい AWS クラウドネイティブアーキテクチャでテストされ、すべてのコンポーネントが期待どおりに動作することを検証します。 以下の図は、新しく作り直されたアプリケーションをデプロイするための一般的な AWS クラウドネイティブアーキテクチャを示しています。 新しく reimagine されたアプリケーションのデプロイとテスト Reimagine パターンのための AI 駆動アプローチの主な利点 ディスカバリーと分析の加速 AWS Transform の AI エージェントは、複雑な COBOL コードベースを数時間または数日で分析し、アプリケーションドメインとビジネスロジックパターンを自動的に識別できます。組織はメインフレーム環境全体を分析するか、もしくは、特定のビジネスプロセスを対象として分析するか、選択することができます。 インテリジェントなマイクロサービス設計 AI を活用したアプローチでは、ドメイン駆動設計 (Domain-Driven Design: DDD) の原則を適用して、レガシーアプリケーション内の自然な境界のあるコンテキストを識別します。DDD は、中核となるビジネスドメインの理解、技術チームとビジネスチームの間に共通のユビキタス言語の構築、複雑なドメインを明確に境界付けられたコンテキストに分割することに重点を置いています。 高品質なコード生成 Kiro は、適切な階層型アーキテクチャ、REST API 設計、クラウドネイティブパターンなど、最新の開発標準に従った、本番環境に対応したマイクロサービスを生成します。 Infrastructure as Code このアプローチでは、アプリケーションコードと、マイクロサービスを AWS クラウドにデプロイして実行するために必要なインフラストラクチャ全体の両方が生成されます。さらに、この Infrastructure as Code アプローチは AWS Well-Architected Framework の原則に沿ったものであり、自動化され繰り返し可能なデプロイによって運用上の卓越性を促進し、生成されたすべてのインフラストラクチャコンポーネントにセキュリティ、信頼性、パフォーマンス効率、コスト最適化、ベストプラクティスを一貫して適用できるようにしています。 AWS メインフレームモダナイゼーションの専門知識とパートナーエコシステム メインフレームアプリケーションを reimagine するための AWS のアプローチは、AWS の AI 駆動の機能を活用し、パートナーの専門知識とスケールを補完するものです。AWS は、Global System Integrators (GSI) と専門技術パートナーの専門知識を組み合わせて、メインフレームモダナイゼーションプロジェクトに内在する複雑さに対処する強固なパートナーエコシステムを構築しました。 GSI パートナーは、さまざまな業界の大規模なメインフレームモダナイゼーションで成功を収めていることが実証済です。 AWS の戦略は、データ移行ユーティリティ、テストフレームワーク、言語変換ツールなどの AWS ネイティブ機能を補完する専用のモダナイゼーションツールを提供するテクノロジーパートナーに依存しています。 このような協業アプローチにより、お客様は AWS のクラウドネイティブ機能を活用しながら、複雑なモダナイゼーションの課題に対応する専門知識と実証済の方法論を活用できます。 まとめ AWS がメインフレームモダナイゼーションを再構想 (reimagine) するために進めているのは、お客様のトランスフォーメーションジャーニーを加速させる包括的な AI 駆動のアプローチです。AWS Transform は、レガシーソースコードに対する深い理解と柔軟なコード生成を組み合わせることで、組織がリスクを最小限に抑え、ビジネス価値を最大化しながらメインフレームアプリケーションを変革できるようにします。 メインフレーム向けの AWS Transform と Kiro に関するその他の参考情報 インタラクティブデモを試す AWS Transform for mainframe の詳細 入門ガイドを読む メインフレームから AWS への移行途中の過渡期に於ける両環境併存のための連携アーキテクチャ メインフレームアプリケーションのモダナイゼーションに関する包括的な視点と配置戦略 著者 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 Cheryl du Preez Cheryl du Preez は、メインフレームとレガシーモダナイゼーションに関する AWS の World Wide Senior Specialist Solutions Architect です。Cheryl は、世界中のお客様を対象としたメインフレームのモダナイゼーションとトランスフォーメーションの取り組みにおいて、20 年以上にわたって技術的リーダーシップを発揮してきました。現在の役職では、AWS 独自の方法で生成 AI を活用したメインフレームのモダナイゼーションについて、お客様やパートナーに対して助言を提供しています。 Chris Poole Chris は Senior Partner Solutions Architect であり、メインフレームモダナイゼーションが大好きです! 彼は現在、EMEA 地域の AWS メインフレームパートナー戦略を推進していますが、以前はエッジコンピューティングテクノロジーに取り組む Principal Engineer の称号を持っていました。当時は、コミュニティや開発者支援の取り組みをリードし、クラウドセキュリティ製品のソリューションアーキテクトチームを率いたり、高スループットの金融取引処理システムにおける非同期 API を設計/開発したりしてきました。彼は理論物理学の博士号を取得しています。余暇には、香取神道流の武道やカリ (Kali) 等の格闘技を楽しんでいます。 Rao Panchomarthi グローバルのメインフレームモダナイゼーション組織のリーダー。Rao は、IBM メインフレーム、分散システム、クラウドテクノロジーにまたがる 20 年以上の経験を持つ経験豊富な IT プロフェッショナルです。Rao は大規模なビジネストランスフォーメーションをリードし、メインフレームアプリケーションのクラウドテクノロジーへの移行や、モダナイズするための戦略を策定しています。AWS に入社する前は、JPMorgan Chase のクレジットカード事業でアーキテクチャ責任者を務め、複数のトランスフォーメーションプロジェクトをリードしていました。 Souma Suvra Ghosh Souma は AWS でメインフレームモダナイゼーションを担当する Senior Specialist Solutions Architect です。AWS へのモダナイゼーションに関する複数の記事やソリューションガイドを発表し、AWS re:Invent や AWS Summit などのカンファレンスで発表を行ってきました。現在の役職では、メインフレームとレガシーシステムのモダナイゼーションに AWS のバリュープロポジションと生成 AI 機能を最大限に活用する方法について、お客様やパートナーに助言しています。 Subhajit Maitra Subhajit は AWS の Worldwide Mainframe Partner Solution Architect であり、メインフレームモダナイゼーションコンピテンシープログラムの構築を支援しました。また、IBM MQ 連携に寄与する AWS Mainframe Modernization サービスのビルダーでもあります。彼の専門分野には、メインフレームモダナイゼーション、メッセージ指向ミドルウェア、分散型イベントストリーミングプラットフォーム、マイクロサービスなどがあります。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。