こんにちは。株式会社タイミーのバックエンドエンジニアの神山( @ dak2 )です。 2026/4/22 から 24 まで函館で開催された RubyKaigi 2026 に参加し、Day 2 に登壇しました。 タイミーでは、世界中で開催される技術系カンファレンスに無制限で参加できる「 Kaigi Pass 」という制度を活用し、8名が現地でカンファレンスに参加してきました。 登壇内容や参加セッションで得た学びは各レポートにまとめています。気になった方はご覧いただけると幸いです。読者の皆様の今後の学びの参考になれば嬉しいです。 tech.timee.co.jp tech.timee.co.jp tech.timee.co.jp Road To RubyKaigi 2026 地震や飛行機の遅延などもありましたね。皆様の中にも、移動に戸惑った方いらっしゃったのではないでしょうか。 色々大変でしたが、参加者の方々が無事到着されたのを X（旧Twitter）で見て、一安心したのを覚えています。 印象に残ったセッション A Faster FFI rubykaigi.org 自分が作っている gem で Ruby と Rust を使っており、FFI 周りが気になっていたので聞きました。 FFIは、引数の数の確認や型変換（アンボックス）を実行時に行う必要があるため、C拡張に比べてオーバーヘッドが大きいようです。また、ピュアなRubyで書かれたJITコンパイラのFJITはC拡張より速いものの、CRubyの内部データ構造に強く依存していました。そのため仕様変更に弱く、実用的ではなかったとのことです。 FJIT これですね。 fjit.rb · GitHub これに加え、アーロンは hacks gem というものを作っていて、そこから CRuby の 構造体を引っ張ってきて FJIT で使っているみたい。AST をダンプして構造体の名前を元にデータ構造を抽出、メモリのレイアウト情報を計算して Ruby のハッシュに格納して返してるみたいですね。 面白いなー。すごい力技だw FJIT はこのハッシュに依存しているから実用的ではなかったとのこと。 新たな解決策として ffx という gem を作ったみたいです。 Ruby の値を C に変換してネイティブ関数を呼ぶ impl 関数と、実際のコードへジャンプするトランポリン関数を生成。トランポリン関数を生成する際に、アセンブリに impl 関数への jump 命令を書いておき、その次のメモリ領域にマジックマーカーや型情報、パラメータなどのメタデータを書き込んでおく。 通常の実行時には impl 関数へ jump するので、型情報などは読み込まれないけど、ZJIT でのコンパイル時にはマジックマーカーを検知してメタデータを読み取って最適化に使うとのこと。 このハックは単純にすごいなと思いました。感心しながら聞いていたのを覚えています。勉強になります。個人的に印象に残るセッションでした。 Lightning-Fast Method Calls with Ruby 4.1 ZJIT rubykaigi.org speakerdeck.com 行く末が気になる ZJIT ですね。速さは正義ということで、とても期待しています。そこで、このセッションを聞きに行きました。 今の ZJIT はメソッド呼び出し時に全てのパラメータを一度メモリにロードしてしまう課題があるみたいですね。 バックトレースや例外処理、ローカル変数読み込みなどでスタック上に正確なメタデータを残しておく必要があるためとのこと。 これに対し、 Lightweight Frames が提案されていました。 メタデータの書き込みを遅延させ、書き込むフィールドを「JIT Return」の1つなど最小限に限定しつつ、メソッドコール時のメモリライトを削減すると。ただ、ローカル変数の処理や例外時の longjmp などをどうにかしていかないといけないみたいですね。帰ってきてから ZJIT の内部を読んでみています。 Matz Keynote なんか Matz が一番楽しそうだったなあと思う Keynote でした。Ruby という言語を作ってなお、まだ作りたいものがある。AI と一緒に作った Spinel を発表している Matz が楽しそうだった。AI Slop とか色々ありますが、作りたいものを作るって最高ですよね。最高にクールでした。非常にインスピレーションを受けた Keynote でした。 matz リツイート 登壇 登壇時の写真 special thanks to @ginkouno rubykaigi.org speakerdeck.com AI 時代の Ruby では、NoMethodError を静的に解析できたら良いのではないか、という内容で登壇しました。登壇は想像していた何倍も得るものがありました。 きっかけは「日常の疑問」だった このトークの種は、普段の業務で感じた引っかかりでした。型アノテーション付きの Ruby とそうでない Ruby を行き来していると、どうしても型チェックの遅さが気になります。一方で、AI Agent のコーディング能力が一気に上がったことで、「そもそも型をちゃんと書いていく ROI ってどうなんだっけ？」という疑問が、頭の片隅から離れませんでした。 この「気になり」を寝かせていたところ、CFP が1週間延長になった当日、サウナで急に像を結びました。よく「サウナで整うと閃く」と言いますが、実際は逆で、 普段から問題意識を温めていたからこそ、たまたま緩んだ瞬間に繋がったのかな と思っています。整うどころではなくなり、速攻で帰りました。その後、寝る間も惜しんでアイディアを形にし、CFP を提出したのが懐かしいです。 「型ありの Ruby と型なしの Ruby、両方を日常的に書いている自分だからこそ立てられる問い」だと思えたことが、提出のモチベーションになりました。自分の業務の中の違和感は、思っている以上にトークの種になるんだなと。 gem を作って「持論」を形にした セッション内で発表した Method-Ray という gem は、コアロジックに Rust を用いています。命名は X-Ray から着想を得ていて、個人的にも気に入っています。「こうすればできるのでは」という仮説をもとに設計し、最小限で動くものを形にし、gem として公開しました。僕の持論やスタンスを gem に込めた上で CFP を提出しました。 株式会社mov の @pjocprac さんが型関連のセッション内容をまとめてくださっており、僕の発表内容にも触れてくださっているので、詳細に興味があればぜひご覧ください。 RubyKaigiで型まわりの内容をまとめたブログ書きました！ RubyKaigi 2026 型まわり4セッション聴講メモ — AI コーディング時代の Ruby の型 #RubyKaigi https://t.co/HZB5PJW7z0 — Takeshi Watanabe (@pjocprac) 2026年4月27日 登壇して初めて得られた3つのもの 発表後、いろんな方に声をかけていただきました。「ここの型解析どうしてる？」「なんでそう思ったんですか？」「英語話せるんですか？」などたくさんお声がけいただき嬉しかったです。 自分の盲点を埋めるフィードバック 質問内容を受けて「自分の gem もこう直さないといけないな」と気づきが連鎖的に出てきました。一人だと気づきにくい視点に気づかせてくれるというのは良い機会だなと。 自分のスタンスを認識する 今回はスタンスを取った発表をしたのですが、それに対していろんな意見をもらえました。賛否両論あると思いますし、いろんな意見があると思いますが、同時に自分の立ち位置もはっきりしました。スタンスを取った発表をして良かったなと思っています。 アイデアの昇華 @okuramasafumi さんとは、いわゆる廊下の話で、「テストが十分速ければ AI が PDCA を回しやすくなって、それは型解析の近似になっているのでは」という方向性を議論しました。登壇内容を、登壇の外で次のテーマへと押し進めてもらえる感覚があり、これは登壇したからこそ発生した会話なんだと思うと、良い機会に恵まれたなと嬉しく思いました。 次にやりたいこと 今後は、 Method-Ray の解析範囲を広げたいのと、RBS の Rust crate の利便性を高めたいですね。自分の gem で RBS のロードを Rust crate から行いたいなと思っています。また、廊下での会話の流れもあって、高速化にも気持ちが出てきています。登壇を経て、自分の中の「次にやること」のリストが、行く前より大きくなっています。 終わりに 今年の Kaigi も最高でした。運営の方々、本当に素敵な機会をありがとうございました。いろんな方と知り合えましたし、思考を深められました。ぼんやりと次にやりたいことが見えてきました。 次の RubyKaigi は宮崎 ですね。次も楽しんで行きましょう！（帰りに青森、秋田に旅行したんですが、それ含め諸々個人ブログで感情を書こうと思います）

本記事は 2026/04/15 に公開された “ Accelerating physical AI with AWS and NVIDIA: building production-ready applications with simulation and real-world learning ” を翻訳したものです。 フィジカル AI をデジタルインテリジェンスを超えて定義する フィジカル AI は純粋な計算システムを超えて、物理世界を直接知覚、推論、相互作用する知的エージェントへと進化しています。チャットボットやレコメンデーションエンジンなどのデジタル領域で情報を処理する従来の AI システムとは異なり、フィジカル AI はセンサーとアクチュエータを備えたシステムにインテリジェンスを組み込み、実世界の環境で意味のある、適応的な、自律的な行動を取ることを可能にします。 ロボティクスはフィジカル AI の最も高度な応用例で、機械が複雑な操作、ナビゲーション、組立作業を行います。しかし、フィジカル AI は自律車両が動的な交通状況をナビゲートする、ドローンがインフラ点検を行う、スマート製造資産（パッケージの詰まりを防ぐために速度を自律的に調整するコンベアなど）など、多様な領域に拡がります。各アプリケーションは環境条件を感知し、リアルタイムで物理データを処理する能力を共有します。また、適応的な応答を実行する能力も共通の要件です。 この新興分野は、Morgan Stanley が 2050 年までに $5 兆ドル に達すると予測する市場機会を表しています。この成長は、AI ヒューマノイドのゼロショット製造能力によって推進されています。これらのヒューマノイドは人間のように自律的かつ直感的に働き、世界の労働コストのうち 30-40% を自動化する可能性があります。しかし、これらのヒューマノイドが自己バランスなどの基本的な能力を訓練されたとしても、特定の実世界のアプリケーションにはフィジカル AI のチューニングが必要です。ロボットアームやヒューマノイドを製造業務に導入する組織は、フィジカル AI を使用して実際のビジネス問題を解決するための実用的な方法を必要としています。 開発から導入への課題 DHL Supply Chain の 最近の研究 は、倉庫にロボティクスを統合する際の実装と管理の課題を強調しています。44% の組織がすでにロボティクスを導入していますが、サプライチェーン幹部の 34% のみが、自社の技術導入が適切に機能していると考えています。これは、フィジカル AI モデルの実世界でのデプロイメント、モニタリング、配布、ガバナンスが成功したパフォーマンスとビジネス成果に不可欠であることを強化しています。 Amazon Web Services (AWS) は、Amazon の倉庫やサプライチェーン全体でフィジカル AI を備えたロボティクスを広範に導入することで、これらの分野で実証された能力を示しています。 従来のフィジカル AI 開発には、自律システムの構築に多額の資本投資が必要でした。また、試行錯誤の学習中には安全上の懸念が生じ、反復速度が制限されるという重大な障壁がありました。このプロセスは、物理学と環境ベースのシミュレーションに置き換えることができます。これにより、並列で幅広いシナリオに対してトレーニングを行うことができます。しかし、シミュレーションだけでは、摩擦の変化、材料の変形、センサーノイズ、環境の予測不可能性など、実世界の物理の完全な複雑さを捉えることはできません。 このブログでは、シミュレーションから現実へのギャップを埋める包括的なリファレンスアーキテクチャを提示します。シミュレーションベースのトレーニングの速度と安全性、および実世界の学習の忠実性を組み合わせています。AWS インフラストラクチャと NVIDIA Isaac （オープンなロボティクス開発プラットフォーム）に基づいて構築されたこのアプローチにより、組織はフィジカル AI アプリケーションの開発、デプロイメント、継続的な改善を大規模に促進することができます。 シミュレーションと実世界学習を組み合わせた二段階アプローチ シミュレーションはスケールで迅速かつ安全な実験を可能にします。しかし、実世界のデプロイメントでは、予測不可能な物理条件を処理できるシステムが必要です。NVIDIA Isaac は、組織が物理的に正確な仮想環境でロボットポリシーを訓練およびテストし、エッジデプロイメントの成功に向けて準備することを可能にします。 NVIDIA Isaac は、 NVIDIA Isaac Sim や NVIDIA Isaac Lab などのオープンモデル、ライブラリ、オープンソースフレームワークで構成されています。Isaac Sim は NVIDIA Omniverse ライブラリに基づいて構築されたオープンソースのロボティクスシミュレーションリファレンスフレームワークであり、AI 駆動ロボットのための物理的に正確な、GPU アクセラレーション対応の仮想環境を提供し、設計、テスト、合成トレーニングデータの生成を行います。NVIDIA Isaac Lab は Isaac Sim に基づいて構築されたオープンソースの統合ロボット学習フレームワークであり、強化学習や模倣学習方法を使用して高度なロボットポリシーを訓練します。 Isaac Sim は物理的に正確なシミュレーション環境を提供し、Isaac Lab はその環境を数千の並列トレーニングシナリオにスケールします。これらが一緒になって、実世界のデプロイメントの前に迅速なポリシー開発を可能にします。 シミュレーションベースのトレーニングの力 シミュレーションはフィジカル AI 開発の効率的な出発点を提供します。Isaac Sim を使用することで、チームはロボットシステムと運用環境の デジタルツイン を作成できます。これにより、複数の物理プロトタイプを構築するコストと時間を省き、迅速な実験が可能になります。AWS インフラストラクチャ上で Isaac Sim を実行することで、フィジカル AI 開発者にいくつかの重要な利点がもたらされます： 迅速な反復とコスト効率： エンジニアは高価なハードウェアを危険にさらすことなく、何千ものシナリオを並列でテストできます。複数の物理プロトタイプを構築する代わりに、チームは仮想的に設計の代替案を評価します。壊れやすい物体を把持することを学ぶロボットアームは、シミュレーションで追加コストなしで何度も失敗できます。 物理シミュレーションによる学習の拡大： シミュレーションは初期のポリシー学習に十分な物理理解を提供します。膨大な並列トレーニングが可能になり、何百もの仮想環境を同時に実行することで、物理ロボットの学習時間を数週間から数時間に圧縮します。物理パラメータがトレーニング中に体系的に変化するドメインランダム化などの技術は、モデルが実世界の条件に一般化するのを助けます。 実世界の検証の必要性 シミュレーションの利点にもかかわらず、生産準備が整ったフィジカル AI アプリケーションには実世界のデプロイメントが不可欠です。sim-to-real のギャップは、シミュレートされた物理と実際の物理の違いを表し、パフォーマンス、安全性、信頼性、運用効果に大きな影響を与える可能性があります。 物理の忠実度と環境の複雑さ： 実際のセンサーは、シミュレーションでは近似しきれない微妙な違いを捉えます。表面のテクスチャの変化、照明条件、材料のコンプライアンス、動的な環境要因などが含まれます。また、生産環境では予測不可能なシナリオが発生します。 継続的な改善： システムが生産で動作するにつれて、モデルの改良に情報を提供する新しい状況に遭遇します。運用データは、モデルの改善を導くエッジケースとパフォーマンスギャップを明らかにします。包括的なセンサーフィードバック（力センサー、ジョイントエンコーダ、カメラ、加速度計）を備えた実世界のテストは、モデルの有効性を検証します。ミリ秒のデータストリーミングにより、継続的なパフォーマンスモニタリングが可能になります。 エンドツーエンドアーキテクチャの概要 以下のアーキテクチャガイダンスは、シミュレーションベースと実世界の強化学習の 2 つの補完的な経路を通じて、フィジカル AI ロボティクスアプリケーションの開発を可能にします。このソリューションは、NVIDIA Isaac または力、視覚、位置、動作センサーなどの実世界のインテリジェントセンサーデータを通じて物理を管理します。シミュレーションパスでは、実世界の実装前に仮想環境でモデルをトレーニングします。一方、実世界パスでは、センサーデータを通じて実際の物理的相互作用をキャプチャします。トレーニングされたモデルは、エッジデバイスにデプロイされ、推論ベースの制御ポリシーを実装し、反復学習のためにリアルタイムのセンサーデータを摂取します。これにより、人間のような知性を模倣し、指定されたタスクを自律的に実行するシステムが可能になります。 この リファレンスアーキテクチャ には、並行して動作する 2 つの補完的な学習ループが実装されています。 図 1: このガイダンスアーキテクチャは、AWS 上で高度な AI 機能を物理ロボティクスシステムと統合する方法を示しており、実世界の環境で自律的な操作を可能にします シミュレーショントレーニングループ – 構築と学習 GPU 搭載の Amazon Elastic Compute Cloud (Amazon EC2) インスタンス上でコンテナで実行される Isaac Sim から始まります。エンジニアはシステムの運動学をモデル化し、物理制約を定義し、運用シナリオを表す仮想環境を作成します。Isaac Lab は、物理パラメータ、環境条件、タスクの複雑さのバリエーションをテストしながら、トレーニングを複数の並列シナリオにわたってスケールします。 AWS Batch はシミュレーションワークロードを調整し、 Amazon EC2 自動スケーリング グループで GPU コンピューティングリソースを動的にプロビジョニングします。トレーニングの需要が変動するにつれて、インフラストラクチャは自動的にスケールし、集中的なフェーズでは追加のインスタンスを起動し、アイドル期間中はスケールダウンして、コスト効率を最適化します。トレーニングされたモデルと関連するポリシーは、 Amazon Simple Storage Service (Amazon S3) に保存されます。Amazon S3 は耐久性のあるバージョン管理されたストレージを提供します。 Amazon Elastic Container Registry (Amazon ECR) は、環境間での一貫したデプロイメントのためにコンテナイメージを管理します。 実世界の学習ループ – デプロイと監視 シミュレーショントレーニングで候補モデルが生成されると、エンジニアはそれを AWS IoT Greengrass が実行されているエッジインフラストラクチャにデプロイします。 NVIDIA Jetson Thor などの物理ロボットコントローラーでリアルタイムの推論を行います。これらのエッジデバイスは二重の目的を果たし、リアルタイム制御のための ML 推論を実行し、包括的なセンサーデータを収集します。 AWS IoT Greengrass コンポーネントは複数のセンサータイプからのリアルタイムフィードバックを処理します。 マルチモーダルデータは 2 つの経路で処理されます。時系列テレメトリを含む MQTT メッセージ形式の構造化センサーデータは、 AWS IoT Core と Amazon Data Firehose を経由して Amazon S3 データレイクに送られます。カメラからのビデオストリームは&nbsp; Amazon Kinesis Video Streams を介してキャプチャされます。 AWS Glue クローラーは運用データをカタログ化し、 Amazon Athena を通じてクエリ可能にし、 AWS Lake Formation を介して管理可能にします。 Amazon SageMaker AI は、実世界の運用データのバッチを処理してモデルを再トレーニングおよび最適化し、sim-to-real へのギャップを明示的に埋めます。 洗練されたモデルは AWS IoT Greengrass を介してエッジデバイスにデプロイされ、動作が改善されます。モニタリングレイヤーはパフォーマンスメトリクスを継続的に追跡し、モデルドリフトを検出します。パフォーマンスが低下すると、再トレーニングワークフローがトリガーされます。これにより、システムが運用データを生成し、モデルが実世界のパフォーマンスに基づいて洗練され、改善されたモデルが再デプロイされ、サイクルが繰り返される継続的な改善が実現します。 組み立て製造における実世界のアプリケーション 電子機器製造、自動車組立、精密工学で必要とされる、歯車部品を厳密な公差で挿入するような接触が豊富な操作タスクを含む一般的な産業の課題を考えてみましょう。これらのタスクには、リアルタイムで接触力に応答する高度な制御戦略が必要です。 Universal Robots (UR) は、Isaac ライブラリの統合を通じてこの機能を示しています。彼らのロボットアームは、適応的な力フィードバックと制御戦略を使用して、穴にペグをミクロンレベルの精度で挿入します。 シミュレーションフェーズ: シミュレーションフェーズでは、エンジニアは Isaac Sim で UR ロボットアーム、ワークピースの形状、組立フィクスチャをモデル化します。また、材料特性、摩擦係数、接触力学を含む物理パラメータを定義します。Isaac Lab で強化学習を使用して、システムはドメインランダム化、挿入角度、初期位置、摩擦パラメータ、部品公差の変化を含む何千ものシナリオでトレーニングします。これにより、力制御挿入の初期ポリシーが開発され、ロボットが接触を感知し、アプローチ角度を調整し、適切な力を適用するように教えます。 導入と改良: 導入と改良では、トレーニングされたポリシーモデルは、ロボットコントローラー上の AWS IoT Greengrass を介してデプロイされます。生産テスト中、力センサー、ジョイントエンコーダ、位置センサーは AWS にリアルタイムデータをストリームします。これにより、sim-to-real へのギャップが明らかになります。例えば、実際の摩擦がシミュレーション値を超えたり、実際の部品公差がモデル化された値よりも大きく変化したりします。 Amazon SageMaker は運用データを処理します。そして、実世界の物理を考慮したモデルを再トレーニングします。エンジニアは挿入の失敗が特定の力プロファイルと相関していることを発見し、ターゲットを絞った改善を可能にします。洗練されたモデルはエッジに再デプロイされ、成功率を向上させます。この反復プロセスは、ロボットが新しいバリエーションに遭遇するにつれて継続します。モニタリングシステムは主要なパフォーマンス指標を追跡し、メトリクスが許容範囲外にドリフトしたときに再トレーニングをトリガーします。 図 2: ロボットアームギアアセンブリ デュアルパスアーキテクチャは多様なフィジカル AI アプリケーションに適用されます。組織は医薬品取り扱いのための器用な操作システム、動的な倉庫ナビゲーションのためのモバイルロボット、物流施設の人型ロボットの開発時にこれらの原則を適用できます。 成功のためのベストプラクティス 堅牢なシミュレーションから始める: &nbsp;実際のプロトタイプに基づいた物理モデルの定義に投資することが重要です。ユーザーは、強化学習のための適切な報酬関数を開発します。シミュレーションループ内で物理パラメータを反復的に調整し、プロトタイプで精度を検証することで、最良の結果が得られます。実世界へのデプロイメントの前にドメインランダム化を適用することも、堅牢なトレーニング結果をサポートする別の方法です。複数のシミュレーション反復は、物理テストよりもはるかに安価です。 段階的にデプロイする: 完全な生産の前に、制御された環境で実世界のテストを開始します。初期データでシミュレーションの仮定を検証し、重要なギャップを特定します。 包括的に計装する: 多様なセンサーをデプロイしてマルチモーダルデータをキャプチャし、物理的な検証を行います。より豊かな実世界のフィードバックにより、より効果的なモデル改良と自動再トレーニングトリガーによる継続的なモニタリングが可能になります。 シミュレーション-リアルのパリティを維持する: 実世界のデータが物理の洞察を明らかにするにつれて、シミュレーションモデルを更新して将来のトレーニングを改善します。これにより、各ドメインが他方を情報提供する美徳のサイクルを生成します。 フィジカル AI の実務への展開 ロボティクスやその他の自律システムにおける物理 AI は、研究環境から生産使用に移行しました。このリファレンスアーキテクチャは、組織が製造、物流、ヘルスケアなどを超えて実際のビジネス問題を解決する自律システムを開発するための実用的でスケーラブルな道筋を提供します。 シミュレーションベースのトレーニングの速度と安全性を実世界の学習の忠実度と組み合わせることで、組織は開発サイクルを加速し、コストを削減できます。また、運用経験を通じて継続的に改善するシステムをデプロイできます。シミュレーション優先と実世界優先の両アプローチに対応するアーキテクチャの柔軟性は、多様なユースケースと組織の準備レベルに対応します。 フィジカル AI の採用が加速するにつれて、シミュレーションと現実を効果的に橋渡しし、それぞれの強みを使用してアプリケーションを構築する組織が成功するでしょう。AWS のスケーラブルなインフラストラクチャと NVIDIA の物理シミュレーションプラットフォームにより、その未来は今日利用可能です。 始める準備はできましたか？ AWS Guidance for Physical AI for Robotics でリファレンスアーキテクチャにアクセスしてください。追加リソースについては、以下をご覧ください。物理ベースの仮想環境でのシミュレーション、テスト、合成データ生成のための NVIDIA Isaac Sim ドキュメント、エッジデプロイメントのための AWS IoT Greengrass ドキュメント、モデル開発と継続的な改良のための Amazon SageMaker AI ドキュメント、および GPU アクセラレーテッドコンピュートのための AWS Batch ドキュメントがあります。 <!-- '"` --> Srinivas Nidamarthi Dr. Srinivas Nidamarthi は、AWS の自動車および製造業ビジネスユニットにおけるフィジカル AI、ロボティクス、およびソフトウェア定義ファクトリーの GTM 製品のグローバルヘッドおよび技術ビジネス開発リードです。彼は顧客の製造業の課題を解決することに焦点を当てた製品開発をリードしています。以前、Srinivas は ABB ロボティックシステムズの CTO を務め、多様な顧客と地域にわたって高度な製造自動化ソリューションを構築しました。彼は英国ケンブリッジ大学で博士号を取得しており、デジタルファクトリーの課題に取り組むため、彼の研究と専門知識を応用しています。 Alex Mevec Alex Mevec は NVIDIA のクラウドサービスプロバイダーチームのソリューションアーキテクトであり、顧客が ML および AI ソリューションを採用するのを支援しています。彼はロボティクスとフィジカル AI を専門としています。 Ali Shahrokni Ali Shahrokni は NVIDIA のシニア開発者リレーションズマネージャーで、Amazon および AWS チームとの戦略的技術コラボレーションをリードし、高度なロボティクス、AI、およびコンピュータビジョンソリューションを構築しています。彼はスイス EPFL でコンピュータビジョンの博士号を取得しています。Amazon、eBay、Magic Leap、およびオックスフォード大学で AI、3D 再構築、シーン理解、および拡張現実のイニシアチブを推進し、最先端の研究をスケーラブルな産業アプリケーションにもたらす重要なリーダーシップおよび技術的役割を担ってきました。 Brian Kreitzer Brian Kreitzer は Amazon Web Services (AWS) のパートナーソリューションアーキテクトです。彼はパートナーと協力して、AWS 顧客向けのアクセラレータとソリューションを作成し、技術的な共同販売機会にも取り組んでいます。 Raja GT Raja GT は Amazon Web Services (AWS) のワールドワイドシニアソリューションアーキテクトです。彼は製造パートナーや顧客と緊密に協力し、技術戦略を提供し、戦略的パートナーが AWS 顧客向けの業界ソリューションを構築およびスケールアップできるようにしています。彼は AWS 製造技術フィールドコミュニティのコアメンバーであり、製造クラウド採用に関する技術ガイダンスとソートリーダーシップを提供しています。彼は航空宇宙、自動車、ヘルスケア、エネルギー産業で 20 年以上の経験があり、クラウド上の製品ライフサイクル管理、サプライチェーン、スマート製造、産業データ/AI アプリケーションを専門としています。

この記事は、”Taking a comprehensive perspective to mainframe application modernization with a disposition strategy” を翻訳したものです。 はじめに メインフレームのお客様は、モダナイゼーションの選択肢が無数にあります。現在、多くの組織は、人材不足や、高額なコストとその上昇、レガシー環境ではビジネスアジリティに制限が掛かることで、モダナイゼーションが急務となっています。また、お客様自身も、モダナイゼーションの複数のパターン、ツール、戦略を自ずと模索しています。 配置戦略 (disposition strategy) には、メインフレームの複雑なモノリシックアプリケーションや大規模なコードベースへの対処に役立つ指針が含まれます。お客様は、レガシーアプリケーションを管理しやすい部分に分解し、ターゲットとなる移行パターンを開発し、移行の順序付けを行い、メインフレームに残るワークロードとの連携機能を構築します。この作業は、アプリケーションが密結合な状態から完全に切り離されるまで繰り返されます。 配置戦略とは、メインフレームモダナイゼーションに対する複数のパターンを複合的に組み合わせるアプローチです。ビジネス目標と IT 目標の優先順位とワークロードの特性に基づいて、個々のワークロードに適した適切なパターンが選択されます。配置戦略は、メインフレームモダナイゼーションを個々のプロジェクトとばらばらの移行フェーズの集まりと見なすのではなく、全体を包括的に見る視点を持つことを推奨します。これには、メインフレームからクラウドネイティブに至る長い道のりの最初から最後までの全行程を定義したロードマップが含まれます。このアプローチは、移行を加速し、リスクを軽減し、お客様が許容できる期間内にビジネス目標と技術目標を達成できるよう支援するのに役立ちます。 指針として目指す北極星を定義する メインフレーム資産は、地域、業界、顧客によってさまざまであり、まったく同じメインフレームアプリケーションは 2 つとありません。レガシーテクノロジー、ビジネス目標、将来の要件、リスクへの関心は、お客様によって非常に多様です。多くの大企業では、複数の事業部門がメインフレーム上で稼働するアプリケーションによってサポートされています。また、これらの事業部門には、メインフレーム処理に依存する多数のビジネスリーダー、アプリケーションオーナー、およびステークホルダーが組織全体に存在しています。このダイナミクスにより、組織がメインフレームの将来の状態に関する明確な戦略を欠いているというシナリオがしばしば生じます。モダナイゼーションの初期段階では、メインフレームのさまざまなステークホルダーが独自に活動し、それぞれ別個に戦略を導入または計画しているお客様をよく見かけます。その結果、モダナイゼーションへのアプローチがばらばらになります。このようなときのモダナイゼーションには、組織のモダナイゼーションの道しるべとなる北極星のようなビジョンが明確になっていない可能性があります。 メインフレームモダナイゼーションプログラム (※1) を成功させるための第一歩は、北極星 (North Star: 目指すべき指針) を定義することです。この北極星は、経営幹部、そして多くの場合、組織の取締役会にも共有されます。お客様は、メインフレームを使い続けることで増大するリスク、コスト、競争上の不利益を認識しています。レガシーアプリケーションのモダナイゼーションを経営幹部が指示することで、より迅速かつ緊急に職務を遂行し、成果を上げているお客様を我々は目にして来ました。明確なミッションが無いため、一連のばらばらで戦術的なモダナイゼーションプログラムに参加することになったお客様も見て来ました。ばらばらなプログラムでは、メインフレームプラットフォームのワークロードの移行には成功しても、モダナイゼーションのメリットを最大限に引き出すには苦労するかもしれません。場合によっては、メインフレームに課せられた制約が原因で MIPS の使用量が増加することさえあります。このような状況を避けるため、お客様には主に 3 つの質問に答えて北極星を定義することをおすすめします。 なぜ私たちはモダナイゼーションを進めているのか? 私たちはどこに向かっているのか? それはいつ実現するのか? これらの質問に答えることで、メインフレーム移行プログラムを成功させるための基礎を確立し、組織が共有する共通のビジネス目標と技術目標を定義しやすくなります。 (※1) 訳注: ここでのプログラムは、共通の戦略的目標を持つ複数の関連プロジェクトを統合・管理することにより、単独プロジェクトの成功を目指す部分最適では無く、全体最適による価値を創出する手法としてのプログラムマネジメントの文脈で使われています。レガシーコードのプログラムを指すものではありません。 モダナイゼーションのビジネス基準: ビジネス要件と技術的現実のバランス ビジネス目標は、組織内の部門によって大きく異なる場合があります。ビジネスユニットによっては、レガシーアプリケーションの機能を早急に変更しなければならない場合もあれば、確立されたプロセスやユーザーエクスペリエンスの変更に抵抗しているビジネスユニットもあります。大まかに言うと、ビジネスの優先事項は次の 2 つのカテゴリに分類されます。 カテゴリー 1: ビジネス機能は変わらないが、ビジネスの俊敏性にはテクノロジーのモダナイゼーションが不可欠 機能的な変化が望まれていない場合。 このシナリオでは、レガシーアプリケーションがサポートする既存のビジネス機能に、ビジネスユーザーはとても満足しています。現行のビジネス機能やワークフローは変更する必要がなく、ビジネスユーザーは機能変更という考えに反対しています。これは、ユーザーが端末エミュレーターの黒画面を操作しているお客様にも当てはまる可能性があります。端末エミュレーターを長年使い続けているユーザーは、操作に熟練しているので作業効率が非常に高く、最新の UX に置き換えると生産性が低下する可能性があります。 お客様はメインフレームワークロードの大部分が一般にこのカテゴリに入ると想定する必要があります。メインフレームアプリケーションは何十年も組織で使われてきました。これらのアプリケーションは、個別のビジネスロジックが何年にもわたって使われてきたビジネスに適しているかもしれません。大企業と各業界で差別化されたビジネスのやり方に合わせてカスタマイズされている可能性があります。すべてのアプリケーションに機能的なトランスフォーメーションが必要なわけではありません。安定性と予測可能性が最優先されるシステムの場合は、以下の選択肢を考慮することが重要です。 リファクタリング (Refactor) : レガシーアプリケーションを最新のプログラミング言語とリレーショナルデータベースに変換します。たとえば、 AWS Transform for mainframe を使うと、お客様は AWS の専門的な AI エージェントを使用して COBOL アプリケーションを AWS 上の Java にリファクタリングできます。 リプラットフォーム (Replatform) : 既存の機能を維持し、レガシーテクノロジースタックを維持しながら、よりモダンなインフラストラクチャに移行します。たとえば、AWS Mainframe Modernization には、クラウド内のメインフレーム互換ランタイムにリプラットフォームするためのオプションが用意されています。 これらのアプリケーションのモダナイゼーションでは、機能以外のモダナイゼーションのメリット (耐障害性、影響範囲の縮小、可用性、俊敏性) にフォーカスしてコミュニケーションします。 カテゴリー 2: 技術的な負債を取り除いたり、新しい機能を追加したり、モノリスを分解してプロダクトを調整したりするには、ビジネス機能の変更が必要 機能強化の要件がある場合。 ビジネス部門がアプリケーションの機能を強化する必要があるのはこの場合です。一般に、お客様はメインフレームワークロードの一部だけがこのカテゴリに該当すると予想しています。このような状況では、企業はモダンな UI、リアルタイム機能、またはより高速なバッチ処理を望んでいる可能性があります。また、お客様は、モノリス化した現行アプリケーションをプロダクトに合わせたビジネス機能に分割したいという目標を持っているかもしれません。このアプローチにより、マイクロサービスアーキテクチャを構築し、疎結合化することによってアジリティとイノベーションを促進されます。 ニアリアルタイムの機能に対するエンドカスタマーの期待の高まりに直面するお客様が増えています。メインフレーム上のモノリス化したアプリケーションにこのような機能を導入するのは困難です。さらに、新しい市場や業界への進出、あるいは顧客基盤の拡大を目指すお客様にも会うことがあります。成長目標を積極的に掲げているお客様は、メインフレームアプリケーションを維持することが、成長や新規ビジネスの獲得を阻害していると気付くことがよくあります。 成長の可能性 : モダナイズすることで、新しい収益源を開拓したり、事業拡大を支援したりできるアプリケーションはどれか? カスタマーエクスペリエンスへの影響 : 顧客とのやり取りや顧客満足度に直接影響するアプリケーションはどれか? 市場への対応力 : 現在、市場の変化への対応能力を制限しているのはどのシステムか? イノベーションの可能性 : 最新の開発手法や最先端技術との連携から最も恩恵を受けるのはどのアプリケーションか? 一般的に、強化すべき機能要件が明確に示されているビジネスユニットは、より優先されるはずです。新機能、ユーザーエクスペリエンスの向上、連携機能など、個々のニーズが具体的な目標を提示し、それによってモダナイゼーションの取り組みが推進され、目に見える価値が示されます。 Reimagine パターン とは、メインフレームアプリケーションのアーキテクチャを最新のテクノロジースタックに合わせて設計し直し、コードを書き直すことと定義されています。このモダナイゼーションの目標は、アプリケーションに機能的な変更を導入することです。ビジネスが新しい機能を必要とする場合、reimagine パターンが望ましいアプローチです。 モダナイゼーションのための技術的基準 メインフレームモダナイゼーションの配置戦略には、組織レベルとアプリケーションレベルの両方で評価された技術的基準も組み込む必要があります。 組織レベルでの技術的考慮事項の評価: データセンターから出て行くための戦略や緊急性が高い移行期限 データセンターの撤退を迫られている組織は、移行の期限が迫っているため、スピードとリスクの軽減を優先する必要があります。コードを変更せずにメインフレームのワークロードをパートナーが管理するデータセンターに移動することを意味するリホスト (rehost) パターンは、実践的な第一歩となる可能性があります。多くの場合、リホストアプローチは、他の移行パターンのように長いサイクルを通ることなく、数ヶ月で完了できます。リホストは事業継続につながります。また、将来のモダナイゼーションの基礎を築き、組織がより高度なパターンを徐々に適用するのにも役立ちます。これらのパターンは、時間とリソースの制約の中で、リファクタリングや reimagine などのモダナイゼーションのニーズに対応できます。 ニッチなメインフレーム技術: プログラミング言語、トランザクションモニター、データベース 既存のメインフレームアプリケーションで使用されている特定のプログラミング言語、トランザクションモニター、データベーステクノロジーは、モダナイゼーションの取り組みの実現可能性と複雑さに大きな影響を与えることがあります。これは、メインフレームモダナイゼーションの配置戦略を検討する際に、重要な技術的考慮事項です。 Natural/Adabas、IDMS などの特定のメインフレームテクノロジーは、リプラットフォームやリファクタリングなどの一部のモダナイゼーションパターンでは直接サポートされていなかったり、完全にはサポートされていない場合があります。これらのレガシーメインフレームテクノロジーの可用性と保守性のスキルも、考慮点の 1 つです。これにより、利用できるモダナイゼーションの選択肢が制限される可能性があり、実行可能な選択肢はリプレース (replace) (※2) や reimagine などのパターンだけかもしれません。 組織は、使用されているメインフレームのテクノロジースタックと、それがさまざまなモダナイゼーションアプローチの実現可能性や複雑さにどの程度合致するかを注意深く評価する必要があります。この技術的評価は、適切な配置戦略を決定するうえで重要なインプットとなります。 (※2) 訳注: 本ブログ内のリプレース (replace) は、パッケージソフトウェア製品の購入や SaaS のサブスクリプション契約等を指すリパーチェス (repurchase) と同義で使われています ベンダーによる更新のタイムライン メインフレームモダナイゼーションの配置戦略を評価する際、ベンダーの更新スケジュールは重要な技術的検討事項になり得ます。組織には、ソフトウェアライセンス契約が異なるさまざまなメインフレームベンダーが存在することがよくあります。契約条件の評価にあたっては、更新時期が迫ることでリスクが高まります。この場合、中には、それらのベンダーのテクノロジーからできるだけ早く撤退することが最も価値ある結果になると判断するお客様もいます。このタイムラインの速さは、選択するモダナイゼーションアプローチにも影響します。 たとえば、ライセンス契約の終了期限が迫っている場合は、リプレースアプローチや reimagine アプローチよりも、リファクタリングパターンの方が適している場合があります。リファクタリングは、コア機能を維持しながらアプリケーションをモダナイズするのに役立ちます。多くの場合、全面的な書き直し (full rewrite) や再実装 (reimplementation) よりも短時間で完了できます。 ただし、すべてのリファクタリングソリューションがすべてのメインフレームテクノロジーをサポートしているわけではない点に注意することが重要です。使用中の特定のテクノロジーに適したリファクタリングソリューションの評価を完了する必要があります。場合によっては、明白なリファクタリングソリューションや実証済のリファクタリングソリューションがないこともあります。必要な期限までにベンダーのテクノロジーから撤退するには、reimagine またはリプレースのアプローチしか実行できない場合があります。 最良のモダナイゼーション戦略を決定する際には、全体的な技術評価の一環として、メインフレームベンダーの契約と更新スケジュールを評価することが重要です。これにより、選択したアプローチを、特定のベンダーのテクノロジーから撤退する緊急性に合わせることができます。 動員可能なメインフレームスキルセット メインフレームのスキルセットに制約があるために企業が人材リスクに直面している場合、そのスキルへの依存度が低いメインフレームモダナイゼーションの選択肢を選ぶことが重要です。このような場合、メインフレームアプリケーションのリファクタリングや reimagine などの戦略が効果的なアプローチになり得ます。 逆に、組織内に有能なメインフレーム人材プールがある場合は、リプラットフォームアプローチがモダナイゼーションに適した戦略となり得ます。既存の専門知識を活用して、ワークロードをよりモダンなプラットフォームに移行することができます。 アプリケーション/ワークロードの技術的な複雑さと依存関係の評価 適切なパターンの選択は、ビジネス上の考慮事項と技術的要件の両方に基づいて行う必要があります。各ワークロードまたはアプリケーションの特定の特性を考慮する必要があります。 さまざまなアプリケーションやワークロードを徹底的に技術評価して、それぞれに最適なモダナイゼーションアプローチを決定することが重要です。この評価フェーズでは、以下の要素を考慮します。 移行元のテクノロジー : プログラミング言語と既存のソースコードの量を評価します。一部の言語とフレームワークは、他の言語とフレームワークよりも自動化されたトランスフォーメーションとモダナイゼーションに適しています。これは、特定のモダナイゼーションパターンの実現可能性と複雑さに影響する可能性があります。 データに関する考慮事項 : メインフレームで使われているデータストア技術 (Db2、IMS/DB、VSAM など) を評価します。データ量、データ構造の複雑さ、データエンティティ間の関係を評価します。データの性質と複雑さが、適切なモダナイゼーションアプローチに影響する可能性があります。 結合度 : さまざまなアプリケーションとワークロード間の結合レベルを特定します。たとえば、トランザクションコンテキストの伝播を含むアプリケーションは、密結合されている可能性があります。この場合、疎結合の場合やサービス境界が明確な場合よりも、モダナイゼーションの課題が大きくなります。モダナイゼーションの過程において、密結合された機能の相互依存関係に順次対処し、具体的に管理する必要があるためです。 連携の複雑さと依存関係 : アプリケーションとワークロードの間のさまざまな連携ポイントを評価します。共有リソース、データ依存関係、全体的な連携の複雑さを特定します。これにより、既存の連携を維持できる適切なモダナイゼーションパターンを判断したり、リスクを抑えて移行を行ったりするのに役立ちます。 外部インターフェース : 選択したモダナイゼーションパターンによっては、外部インターフェースを介してメインフレームにアクセスするメインフレームの外部のクライアントアプリケーションの一部が変更されることがあります。選択したパターンが、すべての外部接続ポイント、API 操作、および外部システムとのデータ交換メカニズムに必要なインターフェースをサポートしていることを確認します。 この詳細な技術評価では、次のような要素を考慮する必要があります。 読み取り/書き込みモードで同じデータにアクセスするアプリケーションをグループ化し、それらのグループに同じ移行パターンを選択する 結合度が高いワークロードには同じ移行パターンを選択する 移行元のプログラミング言語がさまざまな移行パターンの実現可能性に与える影響を考慮する 外部インターフェースや連携への変更を可能な限り最小限に抑える移行パターンを選択する アプリケーションとワークロードの分析は、全体的な配置戦略の重要なインプットです。ワークロード固有の技術的特徴と依存関係に基づいて、ワークロードに適したモダナイゼーションパターンとソリューションを追加できます。 移行戦略の策定 ビジネス成果駆動型プログラムの構築 モダナイゼーションを純粋に技術的な課題として扱うのではなく、次のようなプログラムを確立します。 組織の北極星から逆算して考える : 冒頭で述べたように、お客様はメインフレーム資産に関する組織的な戦略とアプローチを必要としています。成功するメインフレーム移行プロジェクトは、経営陣が設定した変動要素(予算や期間、体制等)の枠組みの中で実施されます。なぜモダナイゼーションを行っているのか、どこに向かっているのか、いつモダナイゼーションを実現するのか、といった点を見失わないようにします。 戦略的ビジネス目標との連動 : モダナイゼーションは、俊敏性の向上、カスタマーエクスペリエンスの向上、新しい機能など、特定のビジネス成果をサポートするものでなければなりません。 ポートフォリオ全体を最初から検討する : モダナイゼーションが段階的なアプローチとして定義されている場合でも、新しいテクノロジーのサイロ化を避けるため、計画はアプリケーション全体を対象とする必要があります。 戦術的な成果と戦略的目標のバランスを取る : 包括的なモダナイゼーションに向けて取り組みながら、段階的な価値をもたらすプログラムを設計します。 成功の明確な指標を確立する : ビジネス面と技術面の両方で、進捗状況をどのように測定するか定義します。 経営幹部レベルで戦略が設定されていないと、個々のチームが異なるアプローチを採用したり、「様子を見る」という考えに陥ったりする可能性があります。これにより、モダナイゼーションが遅れ、複雑さが増す可能性があります。 「すべてを再構築」という落とし穴の回避 私たちの経験から、80:20 の原則はメインフレーム資産にも一般的に当てはまることがわかっています。メインフレームアプリケーションの約 80% は機能変更を必要とせず、約 20% のアプリケーションでは reimagine が必要です。 お客様には、大幅な脱メインフレームを含むモダナイゼーションのアプローチを検討することをお勧めします。Transamerica や Goldman Sachs などのお客様は、リファクタリングやリプラットフォームパターンを利用して、ミッションクリティカルなメインフレームワークロードを AWS に移行することに成功しています。アプリケーションごとに個別のアプローチを取るだけだと時間がかかり過ぎて、ビジネス上の必要性を満たせない場合があります。ビジネス目標と技術目標に基づいて、複数のモダナイゼーションパターンを組み込むことを検討します。 大規模なリファクタリング : AWS Transform for mainframe には、レガシーアプリケーションをモダンな Java フレームワークにモダナイズするのに役立つリファクタリング機能が備わっています。このパターンは、決定論的ツールによってもたらされる移行スケジュールの短縮の恩恵を受けながら、レガシーテクノロジーへの依存を減らしたい場合に使用できます。 リプラットフォーム : リプラットフォームでは、エミュレーションテクノロジーを使用して、メインフレームアプリケーションをそのまま移行します。これはしばしば「COBOL から COBOL への移行」と呼ばれます。この場合、リプラットフォームパターンにより、COBOL の人材不足の状況に対処し、脱メインフレームを加速させることができます。 大規模なモダナイゼーションアプローチと戦略的な reimagine を組み合わせることで、お客様はプラットフォームからの撤退に向けて前進しながら、技術的成果とビジネス上の成果を一致させる機会を得ることができます。複数のパターンを社内の戦略で検討しているお客様は、組織内のより多様な目標に取り組むことができます。これは、同じ期間内に運用コスト削減目標を達成しながら行われます。 まとめ: 今こそ行動の時です 今日、メインフレームアプリケーションのモダナイゼーションが強く求められています。人材不足、ソフトウェアコストの上昇、組織の非効率性といったよく挙げられる課題のほかに、新たな要因が浮かび上がってきました。それは、生成 AI がソフトウェア開発に与える影響の増大です。生成 AI コーディングアシスタントがモダンな言語の生産性に革命をもたらすにつれ、モダンテクノロジーとメインフレームテクノロジーの間の開発スピードと生産性のギャップはさらに悪化するでしょう。COBOL や Assembler、PL/I 言語のアプリケーションを使用する組織は、価値創出のスピードという点で競争上の不利な点に直面するケースが増えています。同業他社が運用する基幹システムは、開発スピードがますます速くなるモダンなテクノロジーで書かれた基幹システムを運用しているかも知れません。 メインフレームモダナイゼーションに「特効薬」はありません。成功するには、具体的な成果に基づいて IT 目標とビジネス目標を一致させる、ビジネス駆動型のマルチパターンアプローチが必要です。自動化を行い、段階的に反復することで、コスト削減以外の価値に集中できます。 配置戦略は、各アプリケーションポートフォリオの微妙な違いを認識した、このジャーニーの枠組みとなります。このアプローチでメインフレームアプリケーションをモダナイズすることで、組織は数十年にわたって構築された貴重なビジネスロジックを維持しながら、将来のイノベーション需要に備えることができます。 Tim Gray Tim は AWS の Worldwide Go-to-market Specialist で、AWS Transform for mainframe のリードを担当しています。 Tim は、お客様が AWS Transform を活用して基幹システムを reimagine し、モダナイズすることによる AWS への移行を支援するべく、市場開拓戦略に注力しています。現在、Tim は、大規模なモダナイゼーションプログラムをこれまでにない時間枠で加速させる生成 AI およびエージェンティック AI サービスをデプロイするための再現可能なパターンの構築に注力しています。 Sunil Divvela Sunil Divvela は、AWS の Mainframe Modernization 担当 Worldwide Specialist Solutions Architect です。お客様やパートナーと緊密に連携して、生成 AI やエージェンティック AI を活用したポートフォリオ評価から移行後のサポートに至るまで、メインフレームモダナイゼーションの取り組みを革新し加速させています。AWS 入社前、Sunil は Infosys の Senior Technology Architect として、複数のメインフレームトランスフォーメーションプロジェクトをリードしていました。 Yann Kindelberger Yann Kindelberger は、Amazon Web Services の Principal Solution Architect です。Yann は 23 年以上メインフレームに携わり、IBM で 20 年以上メインフレームアーキテクトとして勤務しました。彼はメインフレームの AWS クラウドへの移行とモダナイゼーションに取り組んでいるワールドワイドなチームの一員です。彼は 2021 年に AWS に入社し、ソリューションアーキテクトとして、お客様のメインフレームの移行とモダナイゼーションを支援し、助言し、サポートしています。 この投稿の翻訳は Mainframe Modernization Specialist Solutions Architect の皆川が担当致しました。原文記事は こちら です。