こんにちは、クロスイノベーション本部リーディングエッジテクノロジーセンターの山下です。 最近は、gpt-ossやQwen3.5といったローカルLLM（Local Large Language Model）も注目されており、これらを活用したプロジェクトも増えてきています。 今回の記事では、ローカルLLMのベンチマークソフトウェアである GuideLLM について紹介します。LLMの性能には様々な観点がありますが、GuideLLMはLLMサーバ自体の応答速度などを測るためのベンチマークソフトウェアです。 GuideLLMでは、以下のような観点でLLMサーバの性能を評価します。 レイテンシー（応答時間） スループット（処理能力） 同時リクエスト数に対する性能の変化 エラー率や安定性 GuideLLMは、LLMサーバに対して様々な負荷をかけることで、これらの観点で性能を評価します。例えば、同時に複数のリクエストを送ることで、スループットやレイテンシーの変化を測定します。また、長時間の負荷テストを行うことで、安定性やエラー率も評価します。 LLMサーバの評価項目 LLMサーバの評価には、TTFT（Time To First Token）、ITL（Inter Token Latency）やThroughputなどの指標が用いられます。 TTFT（Time To First Token） : LLMが最初のトークンを生成するまでの時間を測定します。これは、ユーザーが応答を受け取るまでの待ち時間を示す重要な指標です。 ITL（Inter Token Latency） : トークン間の生成時間を測定します。これにより、LLMの応答速度や処理能力を評価できます。 Throughput : 一定時間内に処理できるリクエストの数を測定します。これは、LLMサーバの処理能力を示す指標です。 Latency（レイテンシー） : LLMサーバがリクエストに対して応答するまでの時間を測定します。これはトークンごとではなくすべての生成が完了するまでの時間になります。 同時リクエスト数に対する性能の変化 : 同時に複数のリクエストを送ることで、LLMサーバの性能がどのように変化するかを評価します。これにより、サーバのスケーラビリティや負荷耐性を測定できます。 エラー率や安定性 : 長時間の負荷テストを行うことで、LLMサーバの安定性やエラー率を評価します。 通常のWebサーバのベンチマークソフトウェアは、HTTPリクエストの処理能力や応答時間を測定することが一般的です。しかし、LLMサーバは応答を作成するための時間が長く、しかも生成された結果をリアルタイムに返す仕組みになっています。このため、通常のWebサーバの指標に加えてTTFTやITLといったLLM特有の指標が重要になります。特にTTFTはユーザーが最初の応答を受け取るまでの待ち時間を示し、ITLは1つのトークンが生成されてから次のトークンが生成されるまでの時間になります。これらがユーザーエクスペリエンスに直結する重要な指標となります。 ChatGPTなどのサービスを利用している際に、最初の一文字が出るまでの時間が長いと感じることがあるかもしれませんが、これはTTFTが長いことを意味しています。TTFTが短いほど、ユーザーは迅速に応答を受け取ることができ、より快適な体験を提供できます。 GuideLLMは実際にLLMサーバに対して負荷をかけることで、これらの指標を測定し、LLMサーバの性能を評価します。これにより、LLMサーバの性能を定量的に評価し、改善点を特定することができます。 GuideLLMの使用方法 GuideLLMは、Pythonで実装されたベンチマークソフトウェアです。以下のコマンドでインストールできます。 他のインストール方法については、公式の GitHubリポジトリ を参照してください。 pip install guidellm[recommended] インストール後、例えば以下のコマンドでベンチマークを実行できます。 guidellm benchmark run\ --target "http://<LLMサーバのアドレス:ポート>" \ --profile sweep \ --max-seconds 30 \ --data "prompt_tokens=256,output_tokens=128" ここでは --target オプションでLLMサーバのアドレスとポートを指定します。 --profile オプションでは、ベンチマークのプロファイルを指定します。 sweep プロファイルは、様々な負荷条件でベンチマークを実行するためのプロファイルです。 --max-seconds オプションでは、ベンチマークの最大実行時間を指定します。 --data オプションでは、ベンチマークに使用するデータを指定します。ここでは、プロンプトトークン数と出力トークン数を指定しています。 --profile として今回は sweep を指定しています。これの動作は以下のようなものになっています。 まずは1並列でのベンチマークを行い、ベースラインのレイテンシーを測定します。これにより、LLMサーバが単一リクエストに対してどれくらいの応答時間があるかを把握します。 次に並列アクセスを行い(デフォルトでは512並列)LLMサーバの最大スループットを測定します。これにより、LLMサーバがどれくらいのリクエストを同時に処理できるかを把握します。 2つのベンチマークでベースとなる性能と最大スループットがわかりました。次に、ベースラインのレイテンシーと最大スループットの間の設定でベンチマークを試します。これにより、LLMサーバが異なる負荷条件でどのように性能が変化するかを把握します。 --profile には他にも色々なプロファイルが用意されているので、目的に応じて選択することができます。 公式のページ を参考にしてください。 実行例 ここでは、実際にGuideLLMを使用してベンチマークを実行した例を紹介します。今回は、ローカルで動作しているLLMサーバに対してベンチマークを実行しました。 通信するLLMサーバはDGX Sparkで動作しているvLLMサーバでgpt-oss-120b を使用しています。 以下のコマンドでベンチマークを実行しました。 GUIDELLM__MAX_CONCURRENCY は、guidLLMがベンチマークを実行する際の最大並列数です。 今回の接続先がDGX Sparkなのでそこまで多くの接続はしない想定なので128並列を指定してみました。 また、 --processor オプションで、ベンチマークで使用するデータを生成するために使用するプロセッサを指定しています。ここでは、gpt-oss-120bが接続先になるので、 openai/gpt-oss-120b を指定しています。 export GUIDELLM__MAX_CONCURRENCY=128 guidellm benchmark --target "LLMサーバのアドレス:ポート" \ --output-dir ./output-dir/ \ --profile sweep \ --max-seconds 300 \ --data "prompt_tokens=256,output_tokens=128" \ --processor "openai/gpt-oss-120b" ベンチマークの結果は以下のようになりました。 すべての結果を載せると長すぎるので、ベンチマーク結果のサマリの部分を抜粋しています。 サマリを見てみると全体の数字の傾向として、同時リクエスト数が増えるにつれて、レイテンシー(Lat)が増加し、スループット(Tok gen/s)も増加していることがわかります。 また、TTFTやITLも同様に増加しています。つまりリクエスト数が増えると応答速度が遅くなっていることがわかります。 一方でTTFTは最悪でも500ms程度で、ITLも131ms程度なので、同時リクエスト数が増えても応答速度はまだ許容可能な範囲に収まっていることがわかります。 特に throughput@128 の行を見ると、スループットが約5.1 req/sに達していることがわかります。さらに、123.2並列まで問題なく処理できていることがわかります。この場合でも、TTFTは1506.7ms、ITLは177.3msなので、同時リクエスト数が増えても応答速度はまだ許容可能な範囲と言えるのではないでしょうか。 複数ある constant@数字 の結果は、ベースラインのレイテンシーと最大スループットの間の設定でベンチマークを試した結果になります。 @ の右側の数字はリクエストの頻度になります。 これらの結果から、TTFTがどの程度までなら許容できるのかを基準にして許容可能なリクエスト頻度を決めることもできます。例えば、TTFTで900ms以下に応答してほしいという場合であるなら constant@1.49 、 constant@2.09 の結果が参考になるかもしれません。 constant@1.49 ではTTFTが786.1ms、 constant@2.09 ではTTFTが943.2msとなっています。つまり、1.49リクエスト/秒程度であれば、TTFTが900ms以下に収まる可能性があることがわかります。 利用してみて気が付いた点 ベンチマークの出力形式としては、JSONやCSVに加えてHTMLも選択できます。しかし、今回HTML形式で出力したものを確認したところ、うまく表示されませんでした。生成されているHTMLに問題がありそうですが原因は不明です。JSONやCSV形式で出力したものは問題なく利用できたので今回はそちらを使用しました。 まとめ 今回は、ローカルLLMのベンチマークソフトウェアであるGuideLLMについて紹介しました。GuideLLMは、LLMサーバの性能を様々な観点で評価するためのベンチマークソフトウェアです。GuideLLMを使用することで、LLMサーバの性能を定量的に評価し、改善点を特定することができます。 ローカルLLMを活用したプロジェクトを進める際には、LLMサーバの性能を評価して最適な設定を見つけることが重要です。ぜひ、GuideLLMを活用して、ローカルLLMの性能を評価して最適な設定を見つけてください。 私たちは一緒に働いてくれる仲間を募集しています！ 電通総研 キャリア採用サイト 電通総研 新卒採用サイト 執筆： @yamashita.tsuyoshi レビュー： @sato.taichi （ Shodo で執筆されました ）

2025 年 8 月に、 AWS User Experience Customization (UXC) 機能を導入しました。これにより、お客様の特定のニーズに合わせてユーザーインターフェイス (UI) を調整し、タスクを効率的に完了できるようになりました。この機能を使用すると、アカウント管理者は AWS マネジメントコンソール の一部の UI コンポーネントをカスタマイズできます。例えば、 AWS アカウントに色を割り当て 識別しやすくすることが可能です。 2026 年 3 月 26 日、UXC に追加されたカスタマイズ機能を発表いたしました。これによりチームメンバー向けに、関連する AWS リージョンとサービスを選択的に表示できるようになりました。未使用のリージョンとサービスを非表示にすることで、認知的な負荷を軽減し、不要なクリックやスクロールを排除できるため、集中力を高め、作業時間を短縮できます。 今回のリリースにより、アカウントの色、リージョン、サービスの表示を一括してカスタマイズできるようになりました。 アカウントを色で分類 アカウントの色を設定して、視覚的に区別できます。開始するには、 AWS マネジメントコンソール にサインインして、ナビゲーションバーでアカウント名を選択します。アカウントの色はまだ設定されていません。色を設定するには、 [アカウント] を選択します。 [アカウント表示設定] で、希望するアカウントの色を選択し、 [更新] を選択します。選択した色がナビゲーションバーに表示されます。 アカウントの色を変更すると、アカウントの目的を明確に区別できます。例えば、開発アカウントにはオレンジ、テストアカウントには水色、本番稼働アカウントには赤を使用できます。 リージョンとサービスの可視性をカスタマイズ リージョンセレクターに表示する AWS リージョン、またはコンソールナビゲーションに表示する AWS サービスを制御できます。つまり、アカウントに関連するリージョンとサービスのみを表示するように設定できます。 はじめに、ナビゲーションバーの歯車アイコンを選択し、 [すべてのユーザー設定を表示] を選択します。管理者ロールの場合は、統合設定に新しい [アカウント設定] タブが表示されます。設定を行っていない場合、すべてのリージョンとサービスが表示されます。 表示されるリージョンを設定するには、 [表示されるリージョン] セクションの [編集] を選択します。表示されているリージョンを選択して [すべての利用可能なリージョン] または [リージョンを選択] を選択し、リストを設定します。 [変更を保存] をクリックします。 表示されるリージョン設定を設定すると、コンソールのナビゲーションバーのリージョンセレクターに選択したリージョンのみが表示されます。 同じ方法で、表示されるサービスを設定することもできます。カテゴリからサービスを検索または選択します。ここでは [人気のサービス] カテゴリを使用してお気に入りを選択しました。選択が終了したら、 [変更を保存] を選択します。 表示されるサービス設定を設定すると、ナビゲーションバーの [すべてのサービス] メニューに選択したサービスのみが表示されます。 検索バーでサービス名を検索する場合、選択できるのは選択されたサービスのみです。 リージョンとサービスの表示設定は、コンソールでのサービスとリージョンの表示のみを制御します。 AWS コマンドラインインターフェイス (AWS CLI) 、 AWS SDK 、AWS API、または Amazon Q Developer を通じたアクセスは制限されません。 新しい visibleServices パラメータおよび visibleRegions パラメータを使用して、これらのアカウントカスタマイズ設定をプログラムで管理することもできます。例えば、 AWS CloudFormation サンプルテンプレートを使用できます。 AWSTemplateFormatVersion: "2010-09-09" Description: Customize AWS Console appearance for this account Resources: AccountCustomization: Type: AWS::UXC::AccountCustomization Properties: AccountColor: red VisibleServices: - s3 - ec2 - lambda VisibleRegions: - us-east-1 - us-west-2 また、Cloudformation テンプレートをデプロイすることもできます。 $ aws cloudformation deploy \ --template-file account-customization.yaml \ --stack-name my-account-customization 詳細については、「 AWS ユーザーエクスペリエンスのカスタマイズ API リファレンス 」と「 AWS CloudFormation テンプレートリファレンス 」を参照してください。 今すぐ AWS マネジメントコンソール で試し、コンソールの下部にある フィードバック リンクを選択するか、 AWS マネジメントコンソールの AWS re:Post フォーラム に投稿するか、AWS サポートの連絡先にフィードバックをお寄せください。 – Channy 原文は こちら です。

この記事は、”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 の皆川が担当致しました。原文記事は こちら です。