Google Cloud、AI主導の移行パスでメインフレームのビッグバン移行を退ける

Google Cloudは、リスクの高いメインフレーム移行に代わる4段階のアプローチを示した。AIによる分析、コード生成、データ変換、そして切り替え前の並行検証を活用する。

この提案は、よく知られた二者択一に異を唱えるものだ。企業は老朽化したシステムを維持し続けるか、着手後になって初めて依存関係が明らかになる大規模移行を試みるかを迫られる。Googleは、どちらの選択肢も最も難しい問題、すなわち既存システムが実際に何をしているのかを理解するという課題に対処していないと主張する。

同社の回答は、Mainframe Assessment Tool、Gemini CLI、Mainframe Connector、Dual Runを一つの連続したプロセスに結び付けるものだ。チームはまず業務ルールと依存関係を復元する。その後、レビュー済みの要件に基づいてクラウドアプリケーションを構築し、関連データを移行し、実際のワークロードの下で両環境を比較する。

この一連の流れにより、これは単なるコード変換の発表にとどまらない。主な対立軸は、クラウドインフラとメインフレームハードウェアの比較ではなく、反復的な刷新とビッグバン移行の比較である。

Googleは既存の有力な選択肢とも競合する。IBMはIBM Zを中心的な位置に据えつつAIを適用している。AWSは、生成した要件とコードをメインフレームのソースにまで追跡できるエージェント型サービスを推進している。どのベンダーも、コード生成だけでは代替システムが正しいかどうかを判断できないことを認識している。

したがって重要な問いは、GeminiがCOBOLを翻訳できるかどうかではない。Googleの連携ワークフローが、企業に管理可能な単位での刷新を可能にしながら、数十年にわたって蓄積された隠れた業務上の振る舞いを維持できるかどうかだ。

Google Cloud、4つのツールを1つの移行パスに統合

重要な変化は、アセスメント、生成、データ移動、本番検証の間をつなぐ点にある。

Googleのモダナイゼーションフレームワークは、リバースエンジニアリングから始まる。Mainframe Assessment Toolは、ソースコード、データベース構造、トランザクションモニター、スケジューラー設定、アセット間の関係を調査する。

COBOLプログラム、コピー句、JCLジョブ、プロシージャ、インクルード、および関連アーティファクトをサポートする。このツールはGeminiを使用し、それらの資料から要約、技術仕様、推定される業務ルールを生成する。

業務ルールとは、適格性の条件、利息計算、トランザクションのルーティング判断など、アプリケーション内部に埋め込まれたポリシーを指す。古いプログラムの観測可能な振る舞いは、現存するドキュメントの範囲を超えることが多いため、これらは重要である。

Googleによれば、チームは抽出されたルールをエクスポートする前にレビュー、フィルタリング、検証できる。この人間によるチェックポイントは、すべての行をJavaや別のモダン言語に翻訳するだけの指示とは、この提案を隔てている。

アセスメントでは、資産群を業務ドメインと、より小さな移行可能ユニットに分割することもできる。移行可能ユニットとは、隣接サービスを壊さずにまとめて移行できる、プログラム、データ、依存関係から成る境界の定まった集合だ。

この分割は、反復的なプログラムの基盤を生み出す。銀行は、決済承認に手を付ける前に、あるレポーティングフローを切り出せるかもしれない。保険会社は、保険金支払いの精算をメインフレームに残したまま、文書処理サービスを移行できるかもしれない。

アセスメントの後、Gemini CLIがフォワードエンジニアリングを支援する。これは、古いコードベースをターゲット設計として扱うのではなく、チームが検証済みの要件を用いてターゲットアーキテクチャを計画し、新しいコードを生成することを意味する。

このワークフローは、Cloud Run、Google Kubernetes Engine、Compute Engine、BigQuery、Spanner、AlloyDB、Cloud SQLをまたぐデータモデルとサービスを提案できる。ただし、生成された提案は運用上の意思決定ではないため、依然としてアーキテクチャレビューが必要だ。

Mainframe Connectorは、しばしば過小評価される別の問題を扱う。EBCDICでエンコードされたレコードを含むメインフレームデータをコピーし、Googleサービスが使用できる形式に変換する。

EBCDICは、IBMメインフレーム環境に関連する文字エンコーディングだ。レコードにはパック10進数、コピー句のレイアウト、アプリケーション固有の規約が含まれる可能性があるため、正しく変換するにはテキスト表現を変えるだけでは不十分である。

Dual Runが提案されたループを完成させる。既存のメインフレーム環境とクラウド環境でワークロードを実行し、本番切り替え前にその結果を比較する。

この連携プロセスは、チームがどこに信頼を置くかを変える。一度きりの変換を信頼するのではなく、発見、ルールレビュー、実装、データテスト、並行実行を通じて証拠を積み上げる。

これが今回の中心的な主張だ。Googleはモダナイゼーションを、単一の変革プロジェクトではなく、管理された証拠の体系として提示している。

メインフレーム刷新がコード翻訳作業ではない理由

構文的に正しい変換でも、誤った業務システムを再現しかねない。

大規模なメインフレーム資産群は、整然とした独立アプリケーションの集まりのように振る舞うことはめったにない。夜間バッチジョブが、翌朝のオンライン取引で利用されるデータを更新する場合がある。共有コピー句が、複数の事業部門で使われるレコードの形を決めている場合もある。

依存関係の一部はコード内に存在する。別のものは、スケジューラー、データベースの規約、運用ランブック、あるいは数十年にわたってワークロードを維持してきた従業員の知識の中にある。

そのため、直接的なコード翻訳は不完全なモデルとなる。言語モデルはCOBOLルーチンからもっともらしいJavaを生成できても、そのルーチンが別のジョブの後に実行される理由を見落とす可能性がある。また、事業側がもはや望んでいないロジックをそのまま保持することもある。

逆方向のリスクも同様に深刻だ。生成された代替システムは、冗長に見えても、まれな規制上の例外を処理している振る舞いを簡略化するかもしれない。その失敗は、まれな取引や四半期末の処理でしか現れない可能性がある。

Googleのアセスメント先行設計は、こうした関係を検査可能にしようとするものだ。同社のドキュメントによると、このツールは呼び出しツリー、依存関係レポート、業務ルールの要約、提案される移行可能ユニットを生成する。

アセスメントシステムは、MCPサーバーもサポートしており、AIエージェントはModel Context Protocolを介してアセスメントデータを照会できる。MCPは、モデルを外部ツールおよび構造化コンテキストに接続するための標準インターフェースだ。

このアーキテクチャにより、Geminiは単なるソースファイルのフォルダー以上のものを利用できる。発見された関係、レビュー済みの仕様、特定のアプリケーションドメインに結び付けられた業務ルールを扱える。

ただし、より豊富なコンテキストが正確な解釈を保証するわけではない。生成された仕様はエッジケースを省く可能性があり、静的解析ではランタイム構成や外部運用によって生じるすべての依存関係を観測できない。

したがって、人間によるレビューは依然として仕組みの一部だ。対象領域の専門家は、提案された業務ルールが有効か、陳腐化しているか、不完全か、あるいは誤解されているかを判断しなければならない。

これは、人材の減少に直面する企業にとって実務上の制約となる。このワークフローが最も経験豊富な運用担当者を必要とするのは、その知識を置き換えるのが最も難しい時期だからだ。AIはレビューを整理できるが、失われた組織的記憶を後から補うことはできない。

Googleのアプローチは、レガシーコードの目的も変える。チームは各ステートメントを保持すべき対象として扱うのではなく、資産群を意図された業務上の振る舞いに関する証拠として扱える。

この区別は、クラウドネイティブな再設計を支える。マネージドサービスが同じレビュー済み要件を満たせるなら、トランザクションモニターに文字どおりの対応物は必要ない。タイミングと一貫性の制約が許せば、バッチプロセスはイベント駆動型サービスになる可能性がある。

しかし、再設計は検証の負担を広げる。ターゲットアーキテクチャが元の実装から離れるほど、行ごとの比較は役に立たなくなる。

チームは、結果、副作用、タイミング、データ整合性、障害復旧を比較しなければならない。これが、Googleの説明においてDual Runが任意ではなく中核となる理由だ。

約束されているのは完璧な翻訳ではない。レガシーの証拠から、レビュー済みルール、生成された実装、測定された同等性へと至る追跡可能な連鎖である。

真の競争は反復的な刷新とビッグバンの間にある

Googleの最も強力な論点は組織面にある。より小さな移行ユニットは、不確実性がもたらす影響を抑える。

ビッグバン移行では、多くの仮定が一度の切り替えに集中する。チームは、広い範囲にわたり、依存関係を理解し、コードを変換し、データを移行し、インターフェースをテストし、運用担当者を訓練し、ロールバック手順を準備しなければならない。

一つの誤った依存関係が、プログラム全体を遅延させる可能性がある。さらに悪いことに、障害は、元の環境を復元することが難しくなった後で初めて本番に到達するかもしれない。

反復的な刷新は、その影響範囲を縮小する。チームは境界の定まったドメインを選び、その関係を文書化し、ターゲット実装を構築し、隣接するワークロードを変更しないまま検証できる。

これはモダナイゼーションを簡単にするものではない。失敗の現れ方を変えるのだ。

ある移行ユニットで見つかった問題は、次のユニットに向けたアセスメントルールの改善につながる。テストの不一致は、企業がより広範な切り替えを決断する前に、文書化されていない振る舞いを明らかにできる。

Dual Runは運用上の橋渡しを提供する。Googleの以前の並行テストモデルでは、メインフレームをプライマリシステムとして維持しながら、クラウドのコピーがセカンダリシステムとして同じワークロードを実行する。

その後、クラウド出力を確立済みの結果と比較できる。繰り返し生じる差異は、変換されたロジック、データ変換、または環境に関する仮定の不具合を明らかにする。

これは、トランザクション量の多いシステムで特に重要だ。ユニットテストは既知の計算を検証できるが、実際の入力パターン、スケジューリング条件、下流統合の間にあるすべての相互作用を再現することはできない。

並行実行は、新システムに直ちに本番権限を与えることなく、より広範な証拠を提供する。チームは受け入れ基準を設定し、差異を調査し、責任を切り替える前にテストを繰り返せる。

その代償は、共存期間の長期化だ。2つの環境を運用するには、同期、監視、重複処理の制御、そして各出力をどちらのシステムが所有するかについての明確な判断が必要になる。

移行期間中はコストも重複する可能性がある。Googleはこうした運用負担をなくすわけではない。その負担が、オール・オア・ナッシングのイベントから離れるためのより安全な道をもたらすと主張している。

この段階的モデルは、ガバナンス上の課題も持ち込む。チームには、移行ユニットを選ぶルールと、アプリケーションが十分な同等性を示したと判断する基準が必要だ。

どの業務ルールが受け入れられ、誰が承認し、どのテスト証拠がそれを裏付け、検証後に何が変わったのかを追跡しなければならない。その記録がなければ、反復的な作業は断片化したハイブリッド資産群を生みかねない。

ここではアーキテクチャの規律が重要になる。孤立したクラウドプロジェクトを連ねると、新たなサービス、キュー、データベース、文書化されていないインターフェースを通じて、メインフレームの複雑さを再現しかねない。

Googleのツールはアーティファクトをマッピングし生成できるが、企業には依然として一貫したターゲットアーキテクチャが必要だ。また、クラウドに置き換えられるすべてのメインフレームコンポーネントについて、廃止計画も必要になる。

このアプローチが成功するのは、反復が累積的な簡素化をもたらす場合だ。移行されたユニットごとに、レガシー資産群へ戻る恒久的な橋が新たに加わる場合には失敗する。

だからこそ、この競争はスピードと慎重さの対立ではない。急いだビッグバンは劇的に失敗し得る一方、終わりのない段階的プログラムは静かに失敗し得る。

意味のある指標は、完了したビジネス能力です。各移行ユニットは、検証済みの本番運用に到達し、対応するレガシーの責務を排除する必要があります。

Google CloudがIBMやAWSと異なる条件で競う理由

3社はいずれも現在AIを活用しているが、モダナイズしたワークロードをどこで稼働させるか、また等価性をどのように確立するかについては異なる。

IBMの立場は、メインフレームが持ち続ける価値から出発している。同社のwatsonx Code Assistant for Zは、IBM Zを重要な実行環境として維持しながら、検出、説明、リファクタリング、コード生成、最適化、変換を支援する。

IBMによると、このアシスタントはCOBOL、PL/I、REXX、Assembler、JCLを説明できる。また、選択したプログラムをモジュール型サービスへリファクタリングしたり、COBOLをオブジェクト指向Javaへ変換したりすることも可能だ。

同社のAIモダナイゼーションツールには、意味的等価性を確認する自動ユニットテストが含まれる。この用語は、構造が変わっても、新しいコードが元のコードと同じ意図された動作を生み出すべきことを意味する。

このアプローチは、すべてのワークロードをハイパースケールクラウドへ移すと決めることなく、開発プラクティスを改善したい企業に適している。また、プラットフォームを期限付きの課題として扱うのではなく、メインフレームを軸にモダナイゼーションを進めることも可能になる。

AWSはクラウドの移行先という点ではGoogleに近い立場を取るが、現在のメッセージではエージェント型の実行とトレーサビリティを重視している。AWS Transform for mainframeは、評価、ビジネスルールの抽出、要件定義、コード生成、テスト、デプロイをカバーする。

AWSによると、生成された各成果物は要件を通じて元のソースまで追跡できる。そのエージェント型ワークフローは、Kiroなどのコーディングエージェントや、オープンプロトコルを介した既存の開発環境とも統合される。

このトレーサビリティは、GoogleのDual Runと同じ信頼性の隔たりを対象としている。要件や生成コンポーネントがどこに由来するのかを示す監査経路を、レビュー担当者に提供する。

Googleの差別化は、コンテキストを踏まえた評価を、データ変換とワークロードレベルの並行検証に組み合わせている点にある。Geminiは理解と生成を支援し、Dual Runは記録上の正とされるオペレーティングシステムに対して動作をテストする。

これらは明確に分離された製品カテゴリではない。IBMも検出とテストを提供している。AWSも自動化された機能等価性検証をうたう。各ベンダーはライフサイクル全体へと機能を拡張している。

したがって、競争圧力は実装の証拠へと移る。購入者は、各ワークフローが自社環境内のどの言語、スケジューラ、データベース、トランザクションシステム、データ形式を扱えるのかを把握する必要がある。

また、製品の能力とサービス提供を区別する必要もある。メインフレームのプログラムには、システムインテグレーター、社内の専門家、ベンダーのスペシャリスト、そして長年にわたるアプリケーションの履歴が関与することが多い。

どのモデルも、その提供体制から独立して機能するわけではない。AIは手作業による分析を減らし、仕様の草案を作成し、コードを生成できるが、統合に関する判断は各環境に固有のものとして残る。

ベンダーロックインも別の考慮事項となる。生成されたアーキテクチャは、あるプロバイダーのデータベース、コンピュートプラットフォーム、監視システム、AIサービスを優先する可能性がある。

こうした整合性はデプロイを簡素化できる。一方で、企業が後にクラウド戦略を変更したり、複数の環境にまたがってワークロードを維持したりする際には、切り替えコストを高める可能性もある。

そのため企業は、デモだけでなく成果物を評価すべきだ。エクスポート可能なルール、読みやすい仕様、移植可能なテスト、追跡可能な承認は、最初の変換後も重要になる。

市場はAI支援型モダナイゼーションへと収束しつつある。未解決の競争は、人間がどこで作業を検証するか、ベンダーが等価性をどう測定するか、そして結果をどのプラットフォームが所有するかを巡るものだ。

Google CloudのAIワークフローが依然として保証できないこと

このワークフローは特定の移行リスクを低減するが、生成されたビジネスルールやターゲットコードが正しいことを保証するものではない。

最初の不確実性は検出の段階で現れる。静的解析はソース間の関係や宣言された呼び出しを特定できるが、動的な挙動は実行時の値、運用者の選択、外部システムに依存する可能性がある。

AIが生成した要約も、その根拠が許す以上に確実であるように聞こえることがある。たとえまれな分岐を省略していても、読みやすい説明であるためにレビュー担当者が承認してしまう可能性がある。

これは、人々がシステムの推奨を過度に信頼する際に起こる自動化バイアスを生む。洗練された仕様は、基盤となる環境に存在する曖昧さを隠すため、このリスクを高める可能性がある。

Google自身のワークフローには、抽出されたルールのレビュー工程が残されている。企業はこの工程を事務的なチェックポイントではなく、統制として扱うべきだ。

レビューには、明確に指定された責任者、紐づく証拠、明示的な処置が必要となる。ルールが生成コードを導く前に、受理、却下、修正、未解決のいずれかとしてマークされるべきである。

セキュリティはさらに別の層を加える。Googleによると、Mainframe Assessment Toolは収集した評価データを、デプロイされた仮想マシン内に保持する。同社のドキュメントでは、ソースコードがGemini Enterprise Agent Platformにアップロードされることも記載されている。

同じドキュメントでは、モデルがそのコードから抽出された情報によって強化されることはないとされている。それでも組織は、自社ワークロードに関するリージョン制御、アクセス方針、保持の挙動、契約上の要件を検証する必要がある。

テストにも限界がある。Dual Runは観測された出力間の差異を検出できるが、等価性はカバレッジと比較品質に依存する。

両方の環境に一般的なトランザクションしか入力されなければ、まれなケースはテストされないままとなる。比較ロジックがタイミング、順序、下流への副作用を無視すれば、2つの出力は同じに見えても、システムの挙動は異なる可能性がある。

並行テストは、問題のあるレガシー動作も再現し得る。移行中にメインフレームと一致させることは有用だが、継承されたすべてのルールが望ましい、あるいは現行ポリシーに準拠していることを証明するものではない。

チームは2つの問いを分けなければならない。クラウド実装は元のシステムと同じように動作するのか、そして元の動作は存続すべきなのか。

2つ目の問いには、ビジネス、法務、セキュリティ、運用上の判断が必要となる。コード解析だけでは答えられない。

パフォーマンスに関する主張にも、本番に近い証拠が求められる。生成されたサービスは機能テストに合格しても、ピーク時の負荷で許容できないレイテンシ、インフラ消費、データベース競合を引き起こす可能性がある。

運用上の復旧にも同等の注意が必要だ。権限を移す前に、チームはリトライ、部分的な障害、遅延メッセージ、重複トランザクション、ロールバック手順をテストすべきである。

最後に、このワークフローはプログラムの完了を保証できない。企業は、メインフレームのワークロードを1つも廃止せずに、優れた評価とプロトタイプを生み出すことができる。

成功には、各移行ユニットの終了基準が必要だ。その基準には、機能上の証拠、運用準備、データ照合、セキュリティ承認、コスト見通し、実際のレガシー廃止を含めるべきである。

Googleの戦略は、不確実性をより早い段階で可視化するため、より安全だ。AIが参加するからというだけで安全なのではない。

Google Cloudが手法から証拠へ移行する際に注目すべき点

次の試金石は、この段階的な手法が、より説得力のある生成コードではなく、再現可能な本番切り替えを生み出せるかどうかだ。

最初のシグナルは、完了した移行ユニットに結びつく顧客の証拠である。購入者は、並行テストを通過し、記録上の正とされるシステムの責任を移管した、名称が明らかな本番ワークロードを探すべきだ。

有用なケーススタディでは、対象範囲、サポートされた成果物、発見された依存関係、検証期間、不一致への対処、最終的に廃止されたメインフレームコンポーネントを説明するだろう。分析が高速化したという一般論から得られる情報は少ない。

繰り返し実施された切り替えは、このワークフローが慎重に選ばれたアプリケーションの範囲を超えて拡張可能だというGoogleの主張を強める。評価だけで本番廃止がなければ、その主張は弱まる。

2つ目のシグナルは、ツールチェーン全体にわたる、より深いトレーサビリティだ。Googleのリリース履歴は、ビジネスルール抽出、MCPアクセス、言語カバレッジ、大規模環境の分析に関する継続的な取り組みを示している。

重要な進展は、承認された各ルールをソースの証拠、生成コンポーネント、テスト、比較結果、人間による承認へと結びつけることだろう。その連鎖は、監査や後の保守におけるレビューを容易にする。

また、チームがプロセスのどこでエラーが入ったかを特定する助けにもなる。不一致が生じた場合、それを不正確な抽出、変更された要件、生成コード、変換されたデータ、または検証ハーネスまで遡れるようになる。

明確なトレーサビリティは、移行ユニットをまたいで知識が蓄積されるため、反復型モデルを強化する。断片化した成果物は、各ユニットを別個のプロジェクトのように感じさせるだろう。

3つ目のシグナルは、IBMとAWSが同等の検証証拠でどのように対応するかだ。機能一覧はすでに重なっているため、ベンダーは自社の手法が実際の依存関係や難しい切り替えをどう扱うかを示す必要がある。

IBMは、モダナイゼーションにIBM Zの放棄は必要ないと主張できる。AWSは、ソースから出力までのトレーサビリティと自動テストを強調できる。Googleは、コンテキストを踏まえた評価とDual Runの組み合わせが、より優れたリスク境界をもたらすことを証明しなければならない。

この競争は企業の購入者に利益をもたらすはずだ。議論を、生のコード生成デモから、証拠、ガバナンス、移植性、完了した成果へと移行させるからである。

テクノロジーリーダーにとって、当面の行動は環境全体にわたる移行を承認することではない。意味のある1つのドメインを選び、チェーン全体をテストすることだ。

そのドメインには、取り返しのつかない最初の一歩になることなく、現実の依存関係とビジネス上の影響が含まれているべきだ。その評価には、コード、データ、スケジュール、インターフェース、運用知識を含める必要がある。

チームは、抽出されたルールのうち何件で修正が必要になるか、並行結果がどの程度の頻度で乖離するか、各不一致の解決にどれだけ時間がかかるかを記録すべきだ。これらの指標は、生成コードの量よりも多くを明らかにする。

また、切り替えの成功後に何が終了するのかも決めるべきである。元のワークロード、ライセンス負担、運用プロセス、サポート責任がすべて残るなら、移行ユニットは未完了だ。

Google Cloudは企業に対し、終わりのない保守と危険なビッグバンの間にある道筋を提示している。この道筋が信頼できるのは、モダナイゼーションを発見、再構築、証明として扱っているからだ。

その価値は、顧客が恒久的なハイブリッドの迷路を生むことなく、複雑な環境全体でそのサイクルを繰り返せるかどうかにかかっている。次の本番切り替えは、次のAI生成デモよりも重要になる。