2026年2月23日、IBMの株価は1日で13%下落し、2000年10月以来最大の1日下落率を記録した。きっかけは、COBOLを最新化できると主張するAI研究所の発表だった。メインフレームを保有する経営陣はこの発表を読み、AIによってCOBOLを変換し、メインフレームを停止できるのかと疑問を呈した。同日に発表されたIBMの回答は的確だった。変換では、データアーキテクチャ、ランタイムの置き換え、トランザクションの整合性、プラットフォームに組み込まれた非機能要件といった真の複雑さをほとんど捉えることができない。市場は2つの異なる問題を混同し、一方の問題に対する解決策を両方の問題に対する解決策であるかのように評価してしまったのだ。
2つの課題は、理解と翻訳です。これらは同じ活動の異なる段階ではなく、AIがそれぞれ異なる能力とリスクで対処する、真に異なる技術的課題です。AIによってCOBOL環境の理解コストは劇的に低下しましたが、置き換えコストは劇的に低下したわけではありません。この違いが重要なのは、近代化投資の意思決定を行う組織は、どの課題を解決するために費用を支払っているのか、AIがそれぞれの課題に対して実際にどのような成果をもたらすのか、そしてAIツールに関係なく残る検証作業が、理解と翻訳のコスト削減によって捻出された予算をどこで消費するのかを知る必要があるからです。
市場が間違っていたという区別
理解と翻訳は同じ問題ではない。
理解とは、コードが何をするのか、なぜそうするのかを理解し、技術的な実装からビジネス上の意図を抽出する学問です。COBOLの文脈では、理解とは、このプログラムがどのようなビジネスルールをエンコードしているのか、各実行パスはどのような条件によって制御されているのか、どのようなデータを読み書きするのか、どの下流システムがその出力に依存しているのか、ビジネスアナリストがこのプログラムの代替仕様を作成するためにどのような情報を必要とするのか、といったことを意味します。理解とは、構文ではなく、意味論、つまりセマンティクスに関するものです。
翻訳とは、コードの動作を維持しながら、ある言語から別の言語へコードに変換する技術です。COBOLの文脈では、翻訳とは、あらゆる入力、あらゆる条件下で、出力を使用する下流システムにとって十分な数値的等価性を備えた、COBOLと同じ動作をするJava（またはPython、Go）コードを生成することを意味します。翻訳は構造的および動作的な等価性に関するものであり、新しいコードは、元の開発者が考慮したものの、あなたが存在を知らなかった可能性のあるエッジケースのテストを含め、元のコードが合格したであろうすべてのテストに合格する必要があります。
| 次元 | 理解 | インタビュー |
|---|---|---|
| 質問への回答 | このコードは何を意味しますか？ | このコードは具体的に何をするのですか？ |
| 出力タイプ | 自然言語、ドキュメント | 実行可能コード |
| エラーの結果 | 人間のレビューによって修正可能 | 制作上の問題 |
| AI機能 | 優秀なLLM取得者は文章表現に長けている | 弱点、決定論が必要 |
| スケール制約 | コンテキストウィンドウで管理可能 | ポートフォリオ規模の失敗はコンテキスト制限を超えている |
| リスクプロファイル | 低レベル、エラーはレビュー可能 | 高いエラーは、発火するまで目に見えない。 |
| 人間の役割 | 検証者およびエンリッチャー | レビュー担当者および証明者 |
これらの問題は関連しており、適切な翻訳を行うにはある程度の理解が必要ですが、同じ問題ではなく、AIの能力には大きな差があります。COBOLコードのAIによる理解は実に素晴らしいものです。しかし、COBOLコードを本番環境で使用可能なJavaコードにAIで変換するのは非常に難しく、市場がこの2つを混同していることが、Gartnerが2026年に開始されたメインフレームからの移行プロジェクトの70%以上が期待された効果を生み出せないと予測した理由です。
AIによる理解が実際に成果を上げる場所
理解問題には、AIが適している特性があります。それは、出力が自然言語であり、自然言語生成は大規模言語モデルが得意とする分野であるということです。AIがCOBOLプログラムを読み込み、プログラムの動作説明、ビジネスルールの説明、データフローの列挙といったドキュメントを生成する場合、出力はテキストです。このテキストに含まれるエラーは修正可能です。人間のレビュー担当者が誤って記述されたビジネスルールを見つけて修正すれば、後続の技術的な影響は一切発生しません。理解エラーのコストはドキュメントの修正であり、本番環境でのインシデントではありません。
ビジネスルールの文書化。COBOL EVALUATE ブロックで提示される大規模な言語モデル（数十年にわたる規制変更によって蓄積された数百もの WHEN 条件を含む）は、各条件がビジネス用語で何を意味するのかを構造的に記述することができます。元の文書が存在しない、あるいはそもそも存在しないプログラムにとって、これは非常に価値があります。63 の管轄区域にわたる税額計算ロジックを実装する COBOL プログラムでは、管轄区域のルールが EVALUATE 構造にエンコードされています。AI は、手動プロセスよりもはるかに速く、これらのルールを抽出して文書化できます。生成されたものはドメインエキスパートによって検証されるべきですが、エキスパートは知識をゼロから再構築するのではなく、AI の出力を検証するため、はるかに高速なプロセスとなります。
AIによる理解が実際にどのように行われるかを見てみましょう。以下のCOBOLソースコードが与えられた場合：
COBOL
EVALUATE TRUE
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'CA'
COMPUTE TAX-AMT = GROSS-AMT * 0.0725
WHEN CUST-COUNTRY = 'US' AND CUST-STATE = 'TX'
COMPUTE TAX-AMT = GROSS-AMT * 0.0825
WHEN CUST-COUNTRY = 'UK'
COMPUTE TAX-AMT = GROSS-AMT * 0.20
WHEN CUST-COUNTRY = 'DE'
COMPUTE TAX-AMT = GROSS-AMT * 0.19
WHEN OTHER
MOVE ZERO TO TAX-AMT
END-EVALUATE.
適切な指導を受けたLLMは、以下のような成果を生み出す。
Business Rule: Tax Calculation
This paragraph applies jurisdiction-specific tax rates to GROSS-AMT:
- US/California: 7.25% (CA state sales tax)
- US/Texas: 8.25% (TX state sales tax)
- United Kingdom: 20% (UK VAT standard rate)
- Germany: 19% (DE MwSt standard rate)
- All other countries: tax-exempt (TAX-AMT = 0)
Note: No rate exists for other US states. Orders from NY, FL, IL
will be tax-exempt under current logic -- likely a gap requiring review.その出力は非常に価値のあるものです。4つのビジネスルールを文書化し、潜在的なギャップ（明示的な税率が記載されていない米国の州）を特定し、しかもそれを数時間で完了します。ドメインエキスパートがそれをレビューし、ギャップを確認してテストケースに追加します。理解タスクは正しく完了しました。
依存関係の説明。静的解析ツールは、どのプログラムがどのプログラムを呼び出しているか、どのコピーブックが共有されているか、どのデータセットがプログラム間でやり取りされているかを示す依存関係グラフを生成します。AI はこのグラフから自然言語による説明を生成できます。「CUSTPROC は 14 のプログラムから呼び出され、主に夜間バッチ処理の時間帯に呼び出されます。CUSTMSTR は 47 のプログラムと共有され、CUST-REPORT-FILE に出力されます。この出力は規制報告ワークフローで使用されます。」この説明は、依存関係グラフ単体よりも導入やアーキテクチャレビューに役立ちます。また、AI は構造化された依存関係データからわずか数秒でこれを生成できます。
理解した動作に基づくテストケース生成。AIがプログラムの動作を文書化すると、文書化された実行パスを網羅するテストケースを生成できます。これは動作の等価性を証明することとは異なります。テストケースはAIが理解したパスを網羅するため、理解していないパスを見落とす可能性があります。しかし、AI生成テストで実行パスの60%を網羅することは、多くの既存プログラムが現在0%しか網羅していない現状よりも優れており、動作の等価性検証に必要な手動テストによる補強の出発点となります。
類似プログラム間のパターン認識。大規模なCOBOLポートフォリオには、構造的に類似したプログラムが多数含まれていることがよくあります。同じ処理パターンが異なるエンティティに適用されていたり、同じ規制計算が異なるパラメータで実装されていたりします。AIは、数千ものプログラムにわたるこれらの類似点を識別し、パターンタイプごとにクラスタリングすることで、各プログラムを個別のものとして扱うのではなく、各パターンに一度対処し、ソリューションを体系的に適用する移行戦略を可能にします。
共通点は、AIによる読解の出力はテキストであり、そのテキストは人間がレビュー可能であり、人間のレビューによって技術的な影響が出る前にエラーが発見されるということである。AIによる読解のリスクは十分に低く、それによってもたらされる価値は本物であり、発生するエラーも管理可能な範囲内にある。
AI翻訳が過剰な約束をする場所
翻訳には、AIにとって理解よりも根本的に難しい特性があります。それは、出力が実行可能なコードであり、実行可能なコードは完全に正確でなければならないということです。95%の精度で翻訳されたプログラムでも、入力の5%でエラーが発生します。金融取引処理システムでは、これは規制報告のエラー、残高計算の不一致、またはコンプライアンス違反につながる可能性があります。翻訳エラーのコストは、文書の修正ではなく、本番環境における重大な問題です。
数値精度の不具合。 COBOLのパック10進数演算（COMP-3）は正確な10進数の結果を生成します。Javaの double そしてPythonの float IEEE 754バイナリ浮動小数点を使用しますが、これはほとんどの10進数を正確に表現できません。COBOLプログラムは、 0.1 + 0.2 COMP-3を使用すると正確に 0.3Javaでの同じ計算 double 生産する 0.30000000000000004金融機関では、この計算が規制当局への提出書類全体で毎晩 10 万回実行されるため、累積誤差は浮動小数点演算の奇妙な現象ではなく、財務報告の不一致となります。COMP-3 から BigDecimal へのマッピングを明示的に処理せずに Java を生成する AI 翻訳は、このエラーを体系的に導入し、AI が翻訳するすべてのフィールドでこのエラーが発生します。 double ではなく BigDecimal.
コードの違いは微妙だが、その結果はそうではない。
COBOL
* COBOL: COMP-3 packed decimal -- exact arithmetic
77 UNIT-PRICE PIC S9(7)V99 COMP-3.
77 QUANTITY PIC S9(5) COMP-3.
77 LINE-TOTAL PIC S9(11)V99 COMP-3.
COMPUTE LINE-TOTAL = UNIT-PRICE * QUANTITY.
* UNIT-PRICE = 19.99, QUANTITY = 3
* LINE-TOTAL = exactly 59.97 -- no rounding error
ジャワ
// Java: naive AI translation uses double -- introduces error
double unitPrice = 19.99;
int quantity = 3;
double lineTotal = unitPrice * quantity;
// lineTotal = 59.96999999999999... not 59.97
// Correct translation requires BigDecimal:
// BigDecimal lineTotal = new BigDecimal("19.99").multiply(new BigDecimal(3));1件の取引ではこのエラーは目に見えない。しかし、毎晩1000万件の取引が規制資本報告書に集計されると、重大な差異となる。COMP-3フィールドを明示的に考慮しないAI翻訳では、毎回この誤りが発生する。
コンパイラオプションの依存性。同一のCOBOLソースコードでも、コンパイラオプションが異なると動作が異なる場合があります。NUMPROC(MIG)とNUMPROC(NOPFD)では、数値例外の処理方法が変わります。RMODE、AMODE、DATAオプションはアドレッシングに影響します。使用されているコンパイラオプションを認識せずにCOBOLソースを翻訳するAIは、プログラムのソースを翻訳するだけで、プログラムの動作を翻訳するわけではありません。翻訳されたJavaコードはソースコードと一致するかもしれませんが、実際の動作とは異なる場合があります。
大規模な幻覚問題。研究によると、GPT-4クラスのモデルは、一般的なコード変換タスクにおいて33～60%の幻覚率を示し、ソースコードには存在しない動作を追加または削除するもっともらしいコードを生成する。847個のEVALUATE条件を持つプログラムの場合、5%の幻覚率は、約42個の条件が誤って翻訳されることを意味する。これらの42個の条件は、翻訳によって知らず知らずのうちに破られたビジネスルールを表している。すべての条件を網羅した完全なテストコーパスがなければ、これらの破綻は、それらをトリガーする特定の入力の組み合わせが本番環境に到達するまで検出できない。
数字がもたらす重大性：
Error Type | Detection Point | Cost Range
--------------------|--------------------|------------------
Comprehension error | Human review | Hours to fix
Translation error | Test suite | Days to isolate
Translation error | Production | $10K-$500K+ incident
Equivalence gap | Regulatory audit | $50K-$5M+ penalty非対称性：理解の誤りは技術的な影響を及ぼす前に発見される。一方、翻訳の誤りはレビューをすり抜け、本番環境で、あるいはさらに悪いことに、規制当局への提出書類の段階で問題となる。
コンテキストウィンドウの限界。IBMのwatsonx Code Assistant for Zは、コンテキストウィンドウ内の個々のプログラムについて、COBOLからJavaへの変換で80%以上の構造的精度を達成します。5万行のCOBOLポートフォリオは数千のプログラムで構成され、プログラム間の依存関係により、すべてのプログラムを同時に同じコンテキストウィンドウに含めることはできません。呼び出し元のプログラムの想定とは異なるインターフェースをAIが変換したサブルーチンを呼び出すプログラムは、どちらの変換でも明らかにならないインターフェースの不一致を生み出します。ポートフォリオ規模の変換には、プログラム内だけでなく、プログラム間の理解が必要です。
文脈に依存しない翻訳の問題。特定の業務イベントを処理するCOBOLプログラムは、その実行タイミングを決定するバッチスケジュール、開始時に利用可能でなければならないデータセット、レコードの処理順序、実行前に出力を読み取る下流プログラムなど、周囲のシステムに埋め込まれた文脈に基づいて処理を行います。この文脈を理解せずにプログラムを翻訳するAIは、ソースコードは翻訳しますが、役割は翻訳しません。翻訳されたJavaコードは内部的には正しくても、実行タイミングや実行順序が間違っていたり、COBOLの前身プログラムが依存していたデータ要件が満たされていなかったりするため、運用上失敗する可能性があります。
行動等価性のギャップ
理解AIも翻訳AIも解決できない最も重要な問題は、行動等価性の証明、つまり、最新化されたシステムが、企業とその規制当局にとって重要なすべての入力に対して、従来のシステムと同じ出力を生成することを証明することです。
動作の等価性は、一般的な意味でのテスト問題ではありません。それは「新しいシステムはテストスイートに合格するか？」という問いではありません。なぜなら、従来のCOBOLシステムのテストスイートは存在しないか、プログラムの実行パスのごく一部しかカバーしていないことが多いからです。ここで問われているのは、本番システムがこれまで受け取ったすべての入力に対して、近代化されたシステムは同じ出力を生成するか、そして、稀な市場状況、規制報告期間、特定の顧客状況などでのみ発生するエッジケースを含め、本番システムが将来受け取る可能性のあるすべての入力に対して、近代化されたシステムは同等の結果を生成するか、ということです。
この質問に答えるには、実際の運用実行から得られた既存システムの動作特性（ドキュメントやソースコードのみに基づくものではない）、その動作の全範囲を網羅するテストコーパス、および表現方法が異なる出力（EBCDICとUTF-8、パック10進数とBigDecimal、バッチファイルとデータベースレコードなど）について「同等」の意味を判断できる比較フレームワークが必要です。
これらはいずれも、AI翻訳ツールが提供するものではありません。IBMの評価は明確です。翻訳では、近代化の真の複雑さをほとんど捉えることができません。動作等価性検証、並行実行、調整フレームワーク、規制当局の承認といった部分にコストとリスクが集中し、AIがプログラム全体のコストに与える影響は最小限に抑えられます。AIは近代化プロジェクトの初期段階、つまり理解と初期翻訳を効率化しますが、後工程、つまり検証、等価性テスト、並行検証は効率化しません。
正しいモデル：静的解析基盤、AIセマンティックレイヤー
最も効果的なAI理解能力は、AI単体ではなく、静的解析が提供する構造的基盤の上に動作するAIです。AI理解の限界（コンテキストウィンドウの制限、複雑なプログラム間ロジックにおける錯覚、決定論的ではなく確率論的な解析）は、静的解析によって克服されます。静的解析の限界（構造的事実は生成するが意味論的記述は生成しない）は、AIによって克服されます。
適切な役割分担：静的解析は構造的な確実性（決定論的、完全、錯覚なし）を提供し、AIは意味的な豊かさ（自然言語による記述、パターン認識、テスト生成）を提供する。どちらか一方だけでは不十分であり、両者を組み合わせることで完全な理解要件を満たすことができる。
静的解析が提供する構造的基盤：
完全なプログラム一覧。ドキュメントに記載漏れがあったプログラムや、AIのコンテキストウィンドウでは同時に処理できないプログラムも含め、ポートフォリオ内のすべてのプログラムを対象とします。静的解析は、コンテキストの制限なしにポートフォリオ全体を処理します。
正確な依存関係グラフ。すべてのCALL関係、すべてのCOPY関係、プログラム間のすべてのデータフローは、トレーニングデータから確率的にではなく、ソースから決定論的に導出される必要があります。AI理解ツールがプログラムの依存関係を記述する場合、その記述は、プログラムが通常何に依存しているかというAIの確率的な記憶に基づくのではなく、静的解析によって生成された依存関係グラフに基づいている必要があります。
デッドコードの特定。本番環境の実行パスから到達できないプログラムは、近代化の対象外です。静的解析はこれらのプログラムを確実に特定できますが、AIは静的解析だけではライブコードとデッドコードを区別するために必要なランタイム実行トレースを持たないため、特定できません。
データスキーマのインベントリ。すべてのFDエントリ、すべてのコピーブック、すべてのCOMP-3フィールドとその精度仕様は、COBOLフィールド定義が通常どのようなものかというAIのトレーニングデータメモリから再構築するのではなく、ソースアーティファクトから抽出されます。
この構造的な基盤の上に、AIによる理解は意味論的なレイヤーを追加します。各プログラムの動作を自然言語で記述した情報、ビジネスルールのドキュメント、プログラム間のデータフローの説明、類似プログラムをクラスタリングするパターン認識などが含まれます。静的解析による決定論的な構造精度と、AIによる自然言語による意味論的な豊かさというこの組み合わせこそが、近代化チームが実際に信頼できる理解結果を生み出すモデルなのです。
これがあなたの近代化プログラムに意味すること
この分析に基づいた、AI投資の実践的な配分：
AIによる理解力向上に投資しましょう。ドキュメント生成、ビジネスルール抽出、依存関係の説明、ドキュメント化された動作からのテストケース生成など、これらはAIの高価値かつ低リスクな活用方法であり、従来手作業で行われていた最もコストのかかる近代化フェーズを効率化します。翻訳作業の前に、まずこれらの作業に着手してください。なぜなら、理解力はその後のあらゆる意思決定の基盤となるからです。
AI翻訳は、最終化ツールではなく、あくまでもドラフト生成ツールとして使用してください。AI翻訳は、開発者がレビュー、修正、検証を行うJavaまたはPythonの出発点となるコードを生成するものであり、人間のレビューなしでデプロイできる本番環境対応コードを生成するものではありません。AI翻訳の出力をドラフトとして扱うことで、翻訳コストを削減しつつ、同等性検証に必要な人間の責任体制を維持できます。
AI翻訳によるコスト削減分を検証コストに含めてはいけません。AIは翻訳プログラムの作成時間を短縮しますが、翻訳プログラムがオリジナルと同等であることを証明する時間を短縮するわけではありません。翻訳速度が向上しても検証範囲が縮小するわけではないため、検証フェーズの予算はAI翻訳によるコスト削減分とは別に計上してください。
まずは構造的な基盤を構築しましょう。構造的な基盤、正確な依存関係グラフ、完全なプログラムインベントリ、データスキーマインベントリが欠如したAI理解ツールは、コードが最も複雑な部分で不完全な理解しか得られません。AIによる理解を最も必要とするプログラムは、一般的に最も複雑で、複数のプログラムに依存しており、ソースコードのみからAIが正確に分析できる範囲を超える可能性が高いものです。
認定条件 SMART TS XL AIによるCOBOL理解機能をサポート
SMART TS XL COBOLポートフォリオに対するAIの理解を確率的なものではなく、より正確なものにするための構造分析の基盤を提供する。
静的コード解析機能は、AI理解ツールが必要とするプログラムレベルの構造データを生成します。具体的には、列挙されたすべてのEVALUATE条件、抽出されたすべてのCOMPUTE式、および特徴付けられたすべてのデータアクセスパターンが含まれます。AIドキュメントツールがこの構造データをコンテキストとしてソースコードを処理すると、類似したプログラムの一般的な動作ではなく、コードが実際に何を含んでいるかに基づいた説明が生成されます。
アプリケーション依存関係マッピングは、 AIコンテキストウィンドウでは同時に保持できない、プログラム間のコンテキストを提供します。CUSTPROCの14個の呼び出し元、47個のコピーブック共有元、および3つのデータフロー出力を示す依存関係グラフにより、AI理解ツールは、依存するすべてのプログラムが同時に同じコンテキストウィンドウにある必要なく、ポートフォリオにおけるプログラムの役割を完全に把握できます。
レガシーシステムの近代化分析では、AIによるコード理解だけでは確実に生成できない、デッドコードのインベントリと複雑性の分布が得られます。具体的には、本番環境からアクセスできないプログラム（分析対象から除外されるプログラム）、複雑性が最も高いプログラム（コード理解エラーのコストが最も高くなるプログラム）、そしてドキュメントではなく実際のFDエントリから導き出されるデータ移行の範囲などが明らかになります。
エンタープライズ検索機能により、構造インベントリをクエリ可能にし、AI支援による理解をサポートします。特定のパターンを実装するすべてのプログラム、N個以上の条件を持つすべてのEVALUATEブロック、特定のデータセットにアクセスするすべてのプログラムなどを検索できます。これにより、トレーニングデータの確率ではなく、構造的な証拠に基づいてAIの理解を行うクエリを実行できます。
AIが近代化ツールチェーンの一部となっている組織にとって、 SMART TS XLの構造分析は、ポートフォリオ規模でのAIの理解精度を高めるレイヤーであり、コンテキストウィンドウの制限、プログラム間ロジックにおける幻覚リスク、構造分析と確率的生成を隔てる決定論的ギャップに対処します。
AIは理解にかかるコストを変えた。証明にかかるコストは変えていない。
2026年に変化したのは、理解にかかるコストです。AIの登場により、COBOLプログラムの動作を理解し、ビジネスルールを文書化し、その挙動を特徴づけ、ポートフォリオ内での位置づけを説明することが、劇的に安価かつ迅速になりました。これは、近代化経済への真に重要な貢献です。以前は理解段階で専門家が何週間も費やしていたプログラムでも、AIを使えば、専門家がゼロから構築するのではなく、数時間で理解の草案を作成し、それをレビューして洗練させることができます。
変わらなかったのは、証明にかかるコストだ。動作等価性の検証、並列実行、規制当局の承認、データ移行の検証といった作業は、AI導入以前と変わらず、理解と翻訳のフェーズがどれだけ速く完了しても、近代化予算の40～50%を消費する。IBMは2026年2月23日に正しかった。翻訳では、実際の複雑さはほとんど捉えられない。真の複雑さは動作等価性の検証にあり、翻訳が速くなってもその複雑さは軽減されないのだ。
COBOLの近代化においてAIを効果的に活用している組織は、AIが真に優れた能力を発揮するAI理解に投資し、AIによる翻訳を、展開準備が整った完成品としてではなく、人間のレビューの出発点として捉えています。彼らは、プロジェクトの初期段階のコスト削減が、プロジェクトの後期段階のコスト削減につながるわけではないことを理解しています。そして、最も重要な理解作業が行われるポートフォリオ規模において、AI理解の精度を確保するために必要な構造分析の基盤を構築しています。
