ブログ

メインフレームモダナイゼーション企業比較:AWS Transform vs Codegiant

AWS Transform for mainframeとCodegiantを詳細比較し、ベンチマークで検証。AWS自身のCardDemoを両製品で変換し、ランタイム、データ、バッチ、AI、コストを比較します。

公開日
読了時間
33分

CodegiantチームはAWS Transform for mainframeを詳しく調査し、実際にコードを変換しました。モダナイゼーション製品を理解する最も早い方法は、実際のメインフレームコードを処理させることだからです。使用したのはAWS自身が公開するオープンソースのCardDemoアプリケーションであり、都合よく選んだコードベースに基づく比較ではありません。本記事では、宣伝上の説明ではなく、実際の動作が分かるように調査結果をまとめています。

これは同じ条件での比較です。AWS Transform for mainframeはCOBOLをJavaに変換し、Codegiantも同じCOBOLをJavaに変換しました。ここが公平に比較できる共通点です。CodegiantはJava以外にも変換でき、対応するターゲットフレームワークも今後増える予定です。つまりJavaは両製品の接点であり、Codegiantの対応範囲の上限ではありません。

以下のすべての論点は、ある一つの事実に行き着きます。AWS Transform for mainframeは、利用者をAWSのランタイムに縛り付けます。納品されるコードは単独では動作せず、データもバッチもそのランタイムなしでは読み取りや実行ができません。稼働を続けるには、CPUコアごとに時間単位の料金を支払い続ける必要があります。Codegiantはその逆です。ベンダーのランタイムも独自エンジンも不要で、変換成果物を完全に自社所有できます。

メインフレームモダナイゼーション企業を選定している場合や、メインフレームアプリケーションのモダナイゼーション手法を比較している場合、以下の論点が、変換成果物を借りるのか、所有するのかを左右します。どのベンダーにも求めるべき要件としてご覧ください。まず調査結果の要約と検証に用いたアプリケーションを示し、次に2分で把握できる概要比較表、最後に各項目の根拠を掘り下げた詳細比較を掲載します。

要約

  • ランタイム。AWS Transform for mainframeが生成するJavaは同社のランタイムをインポートしています。これを取り除くとコンパイルできません。Codegiantの出力は純粋なJavaで、最初から最後まで利用者自身のコードなので、常にコンパイルできます。
  • データ。AWS Transformはフィールドをベンダー独自のオブジェクト内にメインフレームのバイト列として保存するため、テーブルに対する通常のクエリは機能しません。Codegiantは実際のカラムとインデックスを持つPostgreSQLテーブルと、開発者が初日から理解できる一般的なJava型を生成します。
  • バッチ。AWS Transformはジョブを独自のスクリプト言語に書き換えるため、そのランタイムでしか実行できません。Codegiantは標準的なJavaジョブを生成し、既存のスケジューラーで起動できます。
  • コスト。AWS Transformはサーバー費用に加えて、CPUコアごとに時間単位で継続的に課金します。また、ランタイムのドキュメントが想定する実行環境はAWSのみです。Codegiantには、ライセンス取得や料金の支払いが必要なランタイムがありません。
  • 同等性。AWS Transformの比較ツールはファイルとテーブルの差分を検出しますが、設定と実行は利用者が行います。CodegiantはJavaと元のCOBOLを同じ入力で実行し、すべての出力ファイル、リターンコード、ファイルステータスをバイト単位で自動比較します。コントロールトータルの一致も必須です。
  • デッドコード。AWS Transformにはデッドコードのチェックがありません。Codegiantはソースを本番環境で実際に動いているものと照合します。本番環境に置かれたコードの30–40%は実行されないため、変換せずに識別してフラグを付けます。
  • 満たした要件。両製品を、ベンダーのランタイムなしでコンパイルできるか、通常のSQLでデータを読めるかなど、同じ46要件で評価しました。AWS Transform for mainframeは46項目中3項目、Codegiantは46項目中46項目を満たしています。


検証対象

本比較では、両製品で同じアプリケーションを変換しました。それがCardDemoです。AWSが自社のメインフレームモダナイゼーションツールを紹介するためにGitHubで公開している、クレジットカード管理アプリケーションです。Apache 2.0ライセンスのオープンソースであり、AWS自身がAWS Transform for mainframeの実演に使用しています。

重要なのは、検証対象がCodegiantのものではなく、AWSのものだという点です。自社の変換ツールに都合のよいコードベースを選んだわけではありません。リポジトリも公開されているため、両製品に何を入力したかを確認できます。両製品には同じソース、同じコピーブック、同じファイル定義、同じJCLを渡し、どちらのためにも前処理、修正、特別な準備は行っていません。

以下の各行は、自社で運用できるモダナイゼーションの要件です。納品されたシステムが、ベンダーのランタイムも、ベンダーの再対応も、コア単位の課金も不要な場合にのみ、要件を満たしたと判定します。ただし、利用者自身が設定して実行する仕組みを備えている3項目、同等性、テストデータ、移行計画については、AWSに部分的な評価を与えています。


AWSに対するCodegiantの評価

AWS Transform for mainframe

Codegiant

46項目中3項目

46項目中46項目 ✅


AWS Transform for mainframeとCodegiant:概要比較

どちらもCOBOLをJavaに変換します。一方はメインフレームをベンダーのランタイムに置き換え、もう一方はJavaに置き換えます。各項目をクリックすると、詳細比較に移動できます。


AWS Transform for mainframe

Codegiant

1. 変換後のコード

7項目中0項目

7項目中7項目

ランタイム

生成コードは同社のランタイムをインポートします。削除するとコンパイルできません

独自ランタイムはありません。標準Javaなので、どこでもコンパイルできます

データフィールド

データはAWS独自のカスタムクラスに格納され、そのランタイムしか解釈できません

データには、どの開発者も読める一般的なJava型を使用します

プログラム構造

COBOLの各段落が個別のメソッドになるため、コードの読み心地はCOBOLのままです

メソッドにはpostTransaction()のように、業務上の処理を表す名前が付きます

AWS Reforge

変換後にAIによる書き換えで修正し、変換できない部分は利用者に残されます

Javaは最初から適切に構造化され、採用前にすべての部分が検証されます

内部に残るメインフレーム

アプリケーション内部はメインフレームのように動き、メモリ内でもメインフレームのEBCDIC文字コードを使用します

メモリ内は通常のJavaです。メインフレームの文字コードはファイルの入出力部分だけで処理します

後からの変更

COBOLはまず同社エンジン専用の言語に書き換えられ、それをJavaに変換できるのはそのエンジンだけです

すべての工程は自社のコードで実装されており、独自のバイナリやエンジンがないため、後から簡単に更新や変更ができます

コード外の設定

数値処理や文字コードなどは同社ランタイムのプロパティとして手動で設定します

同じCOBOLでも企業ごとに動作が異なるため、顧客のファイルからすべてを読み取り、通常のJavaに組み込みます

2. データ

3項目中0項目

3項目中3項目

VSAM

各レコードは、データベース内にそのままでは読めない生のバイト列として格納されます

レコードは、実際のカラムとインデックスを持つデータベーステーブルになります

データの利用

残高を直接クエリできません。同社のランタイムだけが読めるblobの中に埋め込まれています

任意のレポートツールや新しいサービスからデータを直接読み取れます

書き込みの安全性

更新はまとめられ、約1秒後に書き込まれます

すべての書き込みが即座にデータベースに到達します

3. DB2

4項目中0項目

4項目中4項目

SQLの処理

SQLは検索用ファイルに切り出され、同社のランタイムでしか実行できません

SQLは、生成クラス内の通常のデータベース処理コードに変換されます

ファイルとテーブルの統一モデル

ファイルとデータベーステーブルは、同社ランタイム内の別々の仕組みで処理されます

すべてのファイル呼び出しとデータベース呼び出しが、同じ種類の結果を返します

一つのデータベース、一つのコミット

VSAMデータとDB2データは、依然として別々の世界にあります

両方がPostgreSQLに格納されるため、ファイル更新とテーブル更新を同時にコミットできます

すべてのSQL呼び出しを追跡

元のコードとの呼び出し単位の照合はありません

すべてのSQL呼び出しに識別子があり、Javaと照合されます

4. バッチ

3項目中0項目

3項目中3項目

ジョブ

バッチジョブは、同社のランタイムでしか動かないスクリプトになります

変換出力に高スループットのジョブキューイングが組み込まれた標準Javaジョブで、既存のスケジューラーから起動できます

ユーティリティステップ

ソートやファイル管理のステップはテキストとして貼り付けられ、同社のランタイムが解釈します

これらの処理は、メインフレームと同じ結果を返す通常のバッチステップになります

再開

再開処理は同社のランタイムに依存します

チェックポイントはデータと同じコミットで保存されるため、再実行しても二重計上されません

5. 実行環境とコスト

5項目中0項目

5項目中5項目

実行できる環境

ドキュメントに記載されているのはAWSサーバーのみです

7種類のクラウド、オンプレミス、Kubernetesのいずれでも実行できます

ランタイム料金

サーバー費用に加えて、CPUコアあたり1時間$0.31が継続的にかかります

純粋なJavaを出力します。ライセンス取得や料金の支払いが必要なランタイムはありません

AWSによる方針変更

AWSはすでに、自社のメインフレームランタイム製品2つについて新規顧客の受け入れを終了しています

システム内にベンダーのロードマップに依存するものはありません

必要なツール

複数の別々のツールを個別にダウンロードし、設定する必要があります

分析からデプロイまで、一つのプラットフォームで対応します

速度

変換後のジョブが元と同じ速さで動くかを検証する仕組みはありません

すべてのジョブをメインフレームのバッチウィンドウと比較して計測し、遅い場合は不合格にします

6. 両製品のAI活用方法

3項目中0項目

3項目中3項目

パイプライン内でのAIの役割

ルールエンジンがCOBOLの構造をコピーし、必要に応じてクラス全体をAIで書き換えます。失敗した部分は利用者に残されます

正解が一つに定まる処理はすべてルールが担当します。AIは固定されたスケルトン内の判断ロジックだけを記述します

AIが関与する前にルールが決めること

ルールエンジンがCOBOLの構造をコピーし、残りはAIによる書き換えに任せます

パーサーで抽出した事実、技術分析、データクラス、アクセスクラス、スキーマ、ジョブ計画、機能スライス、スケルトン、名前、変数マップまで、すべてをAIなしで生成します

すべての行が満たすべき検証

元のコードとの行単位の照合も、書き換えで架空の内容が追加されていないかの確認もありません

コンパイル、実在するメソッド、許可された構文、全フィールドへの書き込み、条件の向き、すべての数値とソースの対応を検証します。修復は2回までで、それでも失敗するものは保留します

7. 変換前

7項目中1項目

7項目中7項目

AIを使わない分析

ドキュメントと業務ルールはAIが生成します

コードそのものから完全な技術文書を作成し、すべての事実をソース行にひも付けます。AIは使いません

文単位の事実

なし

すべてのCOBOL文を、実際のオペランドとともに記録します

事実に基づく業務ロジック

なし

AIは証明済みの事実だけを説明し、別の判定器が逸脱を検出します

出力から導く業務機能

なし

各機能を、プログラムが実際に生成する出力から逆向きに追跡します

ソース行の根拠を持つシステム全体グラフ

AWS Transformはグラフとドメインを提供します

リンクをクリックすると、根拠となるソース行と、それに基づく変換判断を確認できます

計算としての移行計画

ドメイン分割とウェーブ計画

グループ内のどの要素も外部から書き込まれないように、グループを形成します

デッドコードのチェック

なし

ソースを本番環境で実際に動くものと照合します。デッドコードは変換せず、フラグを付けます

8. 変換後

6項目中2項目

6項目中6項目

同等性

比較ツールでファイルとテーブルの差分を検出します。設定と実行は利用者が行います

Javaと元のCOBOLを同じ入力で実行し、バイト単位で自動比較します

テストデータ

生成されたスクリプトをメインフレームで実行し、データを収集します

実際の本番入出力を取得して再現し、コピーブックから生成した境界ケースも使用します

業務集計値

コントロールトータルのチェックはありません

レコード件数と残高が、COBOLがすでに計算している値と一致する必要があります

ハルシネーション

AIによる書き換えには、架空の内容が追加されていないかのチェックがありません

COBOLに根拠のないJavaの内容にはフラグを付けます

既知のバグパターン

なし

チェッカーが典型的な変換ミスを検出します

切り替え

利用者のAWSアカウント内のテスト環境です

切り替える前に、実際のトラフィックで新旧システムを並行稼働させます

9. プラットフォーム

8項目中0項目

8項目中8項目

ワンクリックデプロイ

デプロイ先はAWSのみです

AWS、Google Cloud、Azure、Oracle Cloud、DigitalOcean、Cloudflare、Fly.io、オンプレミス、または自社運用の任意のKubernetes基盤へワンクリックでデプロイできます

データベース

データは同社独自のストアに置かれ、ランタイムにひも付きます

テーブルは自社のマネージドデータベースに格納され、アプリケーションとともにデプロイされます

DevSecOps

AWS Transformはテンプレートを渡し、残りは利用者自身が構築します

ツールチェーン全体が含まれており、組み立てる必要はありません

本番稼働後

コードを納品した時点で提供範囲は終了します

AI運用アシスタントがシステムを24時間監視し、障害を修復してコストを最適化します

連携

なし

Codegiant独自のLLMであるKronos Automateは3,000以上のサービスと接続し、モダナイゼーション後のシステム上に自動化やワークフローを構築できます。各アプリケーションには専用の自動化テナントが割り当てられ、月間数億件のイベントに対応するエンタープライズグレードのエンジンが稼働します

構築

なし

変換後のコード上に新しいアプリケーション、エージェント、ワークフローを構築できます。アプリビルダー、ワークフロービルダー、自動化エンジンが含まれます

ガバナンス

なし

ロールベースおよび属性ベースのアクセス制御、監査証跡、ポリシー適用に対応します

専用モデル

なし

Kronos modelsはメインフレームのモダナイゼーションと自動化に特化しており、安全性をさらに高めるために、自社のセキュリティ境界内でセルフホストできます


1. 変換後のコード

ランタイム

AWS Transform: Javaの97%が同社のランタイムをインポートしています。これを取り除くと、コードはコンパイルすらできません。


Codegiant: 出力は純粋なJavaで、最初から最後まで利用者自身のコードです。下層に独自の仕組みがないため、常にコンパイルできます。

データフィールド

AWS Transform: 口座残高がnew Elementary(root, new ZonedType(10,2,...))という、メインフレームのバイト列を包むベンダー独自のオブジェクトになります。単一のカウンターですら、クラス一つになります。


Codegiant: 残高はBigDecimal、日付は日付型、名前はStringです。どの開発者も初日から読める、通常のJavaです。

プログラム構造

AWS Transform: COBOLの段落ごとに一つのメソッドが作られ、DataUtils.compare("00", status)によるチェックがあり、コメントにはLegacy: 0000-DALYTRAN-OPENのようなラベルが残ります。


Codegiant: メソッドは業務上の処理にちなんで命名されます。例えばpostTransaction()のような名前を使い、_2000Post()のような名前にはしません。COBOLを装ったものではなく、本物のJavaです。

AWS Reforge

AWS Transform: 上の問題に対してAWS自身が用意した対策は、変換後のプログラムクラスをAIで書き換えることです。データクラスは依然として同社のランタイムに依存し、コンパイルできないファイルは利用者に残されます。また、AWSは動作が維持されるとは表明していません。


Codegiant: Javaは最初から適切な形になっており、採用前にすべての部分を検証します。後から手直しする必要はありません。

内部に残るメインフレーム

AWS Transform: アプリケーションはLegacySystem.ZOSとして設定され、メモリ内でEBCDICコードページを使用します。つまり、Javaの内部でメインフレームをエミュレートしています。


Codegiant: メモリ内は通常のJavaです。メインフレームの文字コードが登場するのは、ファイルの入出力部分だけです。

後からの変更

AWS Transform: COBOLはまず同社エンジン専用の言語に書き換えられ、それをJavaにできるのはそのエンジンだけです。


Codegiant: すべての工程が通常のコードで実装されており、ベンダーロックインはありません。新しいパターンへの対応は、ルールを変更して再変換するだけです。ベンダーのリリースを待つ必要はありません。

コード外の設定

AWS Transform: 数値処理や文字コードなどは、同社ランタイムのプロパティとして、構成ファイル内で手動設定します。


Codegiant: 同じCOBOLでも、企業によって動作が異なります。コンパイラー設定、実行時設定、JCLが挙動を変えるためです。これらをすべて顧客自身のファイルから読み取り、通常のJavaに組み込みます。設定するものも、ランタイム内に隠されたものもありません。

2. データ

VSAM

AWS Transform: Blusamは各レコードをメインフレームの生のバイト列としてPostgreSQL内に保存します。CICS層であるJICSも、同じランタイム上でエミュレートされます。


Codegiant: 本物のPostgreSQLです。実際のテーブルとカラム、通常のキーとインデックスを備え、プログラムが依存している箇所では元のレコード順も維持します。

データの利用

AWS Transform: SELECT balance FROM accountsは機能しません。残高が、同社ランタイムだけが読めるblob内のバイト列だからです。


Codegiant: 任意のSQLツール、レポート、ダッシュボード、新しいサービスから直接読み取れます。AWS Transformには、そのまま読めるデータがありません。

書き込みの安全性

AWS Transform: 同社のドキュメントによれば、更新はまとめられ、約1秒後に書き込まれます。


Codegiant: すべての書き込みが即座にデータベースに到達し、安全な単位でコミットされます。

3. DB2

SQLの処理

AWS Transform: SQLテキストは検索用ファイル(COBTUPDT_1=INSERT INTO ...)に切り出され、同社のランタイムがキーを使って実行します。


Codegiant: SQLは、生成されるデータアクセスクラス内でPostgreSQL向けに変換されます。適切に移行された銀行も、Javaで構築された銀行も採用している方法です。

ファイルとテーブルの統一モデル

AWS Transform: ファイルとDB2は、異なる二つのランタイム機構で処理されます。


Codegiant: すべてのDB2呼び出しとファイル呼び出しが、同じ種類の型付き結果を返します。

一つのデータベース、一つのコミット

AWS Transform: VSAMデータとDB2データは、依然として別々の世界にあります。


Codegiant: 両方がPostgreSQLに格納されるため、プログラムのファイル更新とテーブル更新を同時にコミットできます。これはメインフレームではできなかったことです。

すべてのSQL呼び出しを追跡

AWS Transform: 元のコードとの呼び出し単位の照合はありません。


Codegiant: すべてのSQL呼び出しに識別子があり、Javaと照合されます。欠落も、架空の追加もありません。

4. バッチ

ジョブ

AWS Transform: JCLは、同社のランタイムでしか実行できないGroovyスクリプトになります。


Codegiant: JCLは、標準Javaバッチフレームワーク上のジョブになります。ジョブ記録と再開機能を備え、顧客が既に使用しているスケジューラーで起動します。AWS Transformには標準Javaバッチがありません。

ユーティリティステップ

AWS Transform: SORTとIDCAMSの制御カードが文字列として貼り付けられ、同社のランタイムが解釈します。


Codegiant: ユーティリティステップは標準的なバッチステップ、つまりデータベース操作、ファイル処理、ソートになり、メインフレームと同じ結果を返します。

再開

AWS Transform: 再開処理は同社のランタイムに依存します。


Codegiant: チェックポイントはデータと同じコミットで保存されるため、再実行しても二重計上されません。この点はメインフレーム自体より優れています。

5. 実行環境とコスト

実行できる環境

AWS Transform: ドキュメントに記載されているのはAWSサーバーのみです。


Codegiant: 7種類のクラウド、オンプレミス、Kubernetesのいずれでも実行できます。JavaとPostgreSQLが動く場所なら、どこでも対応します。

ランタイム料金

AWS Transform: サーバー費用に加えて、CPUコアあたり1時間$0.31が継続的にかかります。


Codegiant: 純粋なJavaを出力します。ライセンス取得や料金の支払いが必要なランタイムはありません。

AWSによる方針変更

AWS Transform: AWSはすでに、自社のメインフレームランタイム製品2つについて新規顧客の受け入れを終了しています。


Codegiant: システム内に、いかなるベンダーのロードマップにも依存するものはありません。

必要なツール

AWS Transform: 個別にダウンロードするツール一式です。端末アプリ、管理コンソール、比較ツール、データ移行ツールなどが含まれます。


Codegiant: 分析からデプロイまで、一つのプラットフォームで対応します。

速度

AWS Transform: 速度の合否判定はありません。


Codegiant: すべてのジョブをメインフレームのバッチウィンドウと比較して計測し、遅い場合は不合格にします。絞り込みと集計だけを行うループは、一つのデータベース文になります。

6. CodegiantとAWSのAI活用の違い

パイプライン内でのAIの役割

AWS Transform: ルールエンジンがCOBOLの構造をコピーし、必要に応じてクラス全体をAIで書き換えます。失敗した部分は利用者に残されます。


Codegiant: 正解が一つに定まる処理はすべてルールが担当します。AIは固定されたスケルトン内で判断ロジックだけを記述し、すべての行が検証されます。

AIに渡されるのは、スケルトンで既に囲まれた小さなスライス一つと、そのスライスが扱うフィールドおよびファイルだけです。AIは判断ロジックを記述し、クラス、ファイル呼び出し、SQLを勝手に作り出すことはできません。

AIが関与する前にルールが決めること

AWS Transform: ルールエンジンがCOBOLの構造をコピーし、残りはクラス全体のAI書き換えに任せます。固定されたスケルトンはなく、書き換えた行がCOBOLと一致しているかの行単位の検証もありません。


Codegiant: 以下はすべて、AIが関与する前にルールによって生成されます。

  • 各文についてパーサーが抽出した事実
  • 技術分析
  • データクラス
  • ファイルおよびデータベースのアクセスクラス
  • データベーススキーマ
  • ジョブ計画
  • 業務機能のスライス
  • すべてのファイル呼び出しを配置済みのスケルトン
  • 名前
  • 変数マップ

すべての行が満たすべき検証

AWS Transform: 元のコードとの行単位の照合も、書き換えで架空の内容が追加されていないかの確認もありません。


Codegiant: 採用前に、すべての行について以下を検証します。

  • コンパイルできること
  • 実在するメソッドだけを呼び出すこと
  • 許可された要素だけを使用すること
  • COBOLが書き込むすべてのフィールドに書き込むこと
  • 条件の向きが正しいこと
  • すべての数値をソースまで追跡できること

修復は最大2回までです。それでも失敗するものは、理由を添えて保留します。

出発点は同じでも、結果はCodegiantの方が優れています。AWSはCBTRN02Cを問題ゼロで変換します。Codegiantも同様ですが、その出力は実際のデータを扱う本物のJavaです。

7. 変換前:理解

AIを使わない分析

AWS Transform: ドキュメントと業務ルールの抽出結果はAIによって生成されます。


Codegiant: パーサーが抽出した事実から完全な技術文書を作成し、すべての事実をソース行にひも付けます。AIは使いません。AWS Transformには、行単位で信頼できる分析がありません。

文単位の事実

AWS Transform: ありません。


Codegiant: すべてのCOBOL文を実際のオペランドとともに記録します。ALTER、GO TOの分岐先、動的なCALLの候補も、明示的な事実として記録されます。

事実に基づく業務ロジック

AWS Transform: ありません。


Codegiant: AIは証明済みの事実だけを説明し、別の判定器が逸脱を検出します。

出力から導く業務機能

AWS Transform: ありません。


Codegiant: 各機能を、プログラムが実際に生成する出力から逆向きに追跡します。

ソース行の根拠を持つシステム全体グラフ

AWS Transform: グラフとドメインを提供します。


Codegiant: リンクをクリックすると、その根拠となった行と、それがどの変換判断につながったかを確認できます。AWS Transformでは、すべてのリンクがソースと判断にひも付いているわけではありません。

計算としての移行計画

AWS Transform: ドメイン分割とウェーブ計画です。したがって、各グループが閉じていると証明できるかという点に限って比較します。


Codegiant: グループ内のどの要素も外部から書き込まれないように、グループを形成します。

デッドコードのチェック

AWS Transform: ありません。


Codegiant: 渡されたソースを、本番環境で実際に動いているものと照合します。Codegiantが処理したシステム群では、本番環境に置かれたコードの30–40%は一度も実行されません。これはデッドコードであり、費用をかけて変換する理由はありません。同じチェックにより、渡されたライブラリから乖離したコードも検出するため、誤ったバージョンを完璧に変換してしまうこともありません。

8. 変換後:実証

同等性

AWS Transform: Compare Toolはファイルとテーブルの差分を検出します。比較の設定と実行は利用者自身が行います。


Codegiant: Javaと元のCOBOLを同じ入力で実行し、すべての出力ファイル、リターンコード、ファイルステータスをバイト単位で自動比較します。

テストデータ

AWS Transform: 生成されたスクリプトをメインフレーム上で実行し、データを収集します。


Codegiant: 実際の本番入出力を取得して再現し、コピーブックから直接生成した境界ケースのテストデータも使用します。

業務集計値

AWS Transform: コントロールトータルのチェックはありません。


Codegiant: レコード件数と残高は、COBOLがすでに計算している値と一致する必要があります。例えば、計上された取引件数と合計金額が同じであることを確認します。

ハルシネーション

AWS Transform: ReforgeのAIによる書き換えには、架空の内容が追加されていないかのチェックがありません。


Codegiant: COBOLに根拠のないJavaの内容にはフラグを付けます。AWS Transformはこれをチェックしません。

既知のバグパターン

AWS Transform: ありません。


Codegiant: Javaチェッカーが典型的な変換ミスを検出します。例えば、固定幅フィールドに対する.trim()の使用、誤った小数処理、短い読み取りを正常なファイル終端と見なす処理などです。

切り替え

AWS Transform: 利用者のAWSアカウント内のテスト環境です。


Codegiant: 切り替える前に、実際のトラフィックで新旧システムを並行稼働させます。

9. Codegiantプラットフォーム:変換後のすべてを担う場所

ワンクリックデプロイ

AWS Transform: デプロイ先はAWSのみです。


Codegiant: 変換後のアプリケーションは、顧客が選ぶAWS、Google Cloud、Azure、Oracle Cloud、DigitalOcean、Cloudflare、Fly.ioへワンクリックでデプロイできます。

データベース

AWS Transform: 同社のランタイム上のBlusamです。


Codegiant: PostgreSQLテーブルは顧客のマネージドデータベースに格納され、アプリケーションとともにデプロイされます。

DevSecOps

AWS Transform: インフラストラクチャのテンプレートが提供され、残りは利用者が組み立てます。


Codegiant: 独自のツールチェーンがあり、接続作業は不要です。Git、CI/CD、Terraform、オブザーバビリティ、エラーおよびパフォーマンス監視、稼働監視、ステータスページ、ドキュメント、コードレビューが含まれます。

本番稼働後

AWS Transform: 提供範囲はコードとテンプレートまでです。


Codegiant: AI SREが24時間365日対応します。稼働中のシステムを監視し、障害を修復してコストとスケーリングを最適化し、セキュリティ設定の逸脱を検知してランブックを最新に保ちます。

連携

AWS Transform: ありません。


Codegiant: Codegiant独自のLLMであるKronos Automateは3,000以上のサービスと接続し、モダナイゼーション後のシステム上に自動化やワークフローを構築できます。各アプリケーションには専用の自動化テナントが割り当てられ、月間数億件のイベントに対応するエンタープライズグレードのエンジンが稼働します。

構築

AWS Transform: ありません。


Codegiant: 変換後のコード上に新しいアプリケーション、エージェント、ワークフローを構築できます。アプリビルダー、エージェント向けワークフロービルダー、自動化エンジンがすべて含まれており、アドオンも追加の組み込み作業も不要です。

ガバナンス

AWS Transform: ありません。


Codegiant: すべてを対象に、ロールベースおよび属性ベースのアクセス制御、監査証跡、ポリシー適用を提供します。

専用モデル

AWS Transform: ありません。


Codegiant: Kronos modelsはメインフレームのモダナイゼーションと自動化に特化しており、安全性をさらに高めるために、自社のセキュリティ境界内でセルフホストできます。

結論

AWS Transform for mainframeは、メインフレームをJavaに置き換えるのではありません。同社のランタイムに置き換えます。独自の型、blobストレージ、Groovyバッチ、メモリ内EBCDICエミュレーション、コア単位の課金、そして同社のロードマップに依存する形です。Codegiantは、実際のPostgreSQLを使い、どこでも動く通常のJavaを生成し、同等性を自動的に証明します。稼働を続けるために永続的な料金を請求することもありません。これが、借りる変換成果物と、所有するシステムの違いです。

関連記事


CodegiantのエンタープライズAIプラットフォームを今すぐお試しください

Codegiantは、コードを完全に管理できるエンタープライズAIプラットフォームです。変換で得られたものは、すべて利用者自身のものです。ベンダーのランタイムも、独自のバイナリも、下層のエンジンもありません。コードを読み、変更し、好きな場所で実行できます。

後から追加で組み込む必要はありません。DevSecOpsツールチェーン、CI/CD、Terraform、オブザーバビリティ、稼働監視、AI SREが変換とともに提供されます。完成したアプリケーションは、AWS、Google Cloud、Azure、Oracle Cloud、DigitalOcean、Cloudflare、Fly.io、オンプレミス、または自社運用の任意のKubernetes基盤へワンクリックでデプロイできます。

自社のLLMであるKronos Automateは、モダナイゼーション後のシステムを3,000以上のサービスと接続し、その上に自動化やワークフローを構築できるようにします。各アプリケーションには専用の自動化テナントが割り当てられ、月間数億件のイベントに対応するエンタープライズグレードのエンジンが稼働します。これこそが厳格なモダナイゼーション要件で求められるものであり、多くのプラットフォームが提供しきれていない部分です。自社ポリシーが許すあらゆる実行先を選べ、ツールチェーン全体を自分の手で管理でき、次のプロジェクトにバイナリもランタイムもロックインも持ち越しません。


今日から構築を始めましょう。

エンタープライズグレードのAIと数千のコネクターの力を活用し、次に必要なものを構築できます。