結論：生成AIは「移行の自動化装置」ではなく、刷新の判断と発注設計が成否を分ける
Gartnerは2026年6月18日、2026年に着手されるメインフレーム離脱（mainframe exit）プロジェクトの70%超が、意図した成果を生み出せずに終わると予測しました（出典：Gartner プレスリリース、2026年6月18日／国内報道：ITmedia エンタープライズ、2026年6月25日）。主因は、生成AIによるレガシーコード変換能力の過大評価です。
ここで読むべきは「AIではレガシー刷新ができない」という話ではありません。Gartnerが指摘するのは、生成AIを「メインフレームからの離脱を一気に自動化する手段」と位置づけた発注が失敗する、という構造です。逆に、生成AIを既存環境内の近代化（modernization in place）を支援する道具として使い、移行は適用範囲を絞って人とAIで伴走しながら段階的に進める設計であれば、勝ち筋は残ります。発注の前提をどう置くかが、そのまま成否を分けます。
この記事は、情報システム部門の責任者、DX推進の担当役員、そして刷新予算を承認する経営層に向けて、なぜ失敗するのかを出典の範囲で構造化し、失敗リスクを抑える発注のチェックポイントまで落とし込みます。
FREE CONSULTATION
この記事の内容について、専門家に相談できます
AI・DX・セキュリティに関するご質問やお見積もりなど、お気軽にお問い合わせください。
何が公表されたのか：数値と射程を正確に押さえる
Gartnerの予測の要点を、一次情報の表現に沿って整理します。
| 項目 | 内容 |
|---|---|
| 予測の主旨 | 2026年に着手するメインフレーム離脱プロジェクトの70%超が、意図した成果を生み出せず失敗する |
| 主因 | 生成AIによるレガシーコードの自動変換・移行能力の過大評価 |
| ベンダー側の予測 | 2030年までに、メインフレーム離脱市場のベンダーの75%が事業モデルの転換または撤退に至る |
| 推奨スタンス | 多くの利用企業にとって、生成AIは「離脱の加速」より「既存環境内での近代化（modernization in place）」の支援に有効 |
| 公表日・出典 | 2026年6月18日、Gartner プレスリリース。担当アナリストは VP Analyst の Alessandro Galimberti 氏ほか |
注意したいのは射程です。これは「2026年に着手する」プロジェクトを対象にした予測であり、メインフレーム移行そのものを全否定したものではありません。また「失敗」とは、当初意図した便益（コスト削減・俊敏性向上など）を生み出せないことを指す表現として報じられています。数値は予測値であり、確定した実績ではない点も前提に置いてください。
なぜ生成AIによる離脱は崩れるのか：3つの構造
Gartnerが挙げる論点を、発注者の視点で3つに分解します。いずれも出典の指摘から導けるものです。
-
レガシーコードの自動変換に技術的な限界がある。生成AIは、複雑な業務ロジックが長年積み上がったコードの自動変換・移行において、宣伝される能力と実力の差が広がっている、とGartnerは指摘しています。COBOLや独自バッチに埋め込まれた暗黙の業務仕様は、コードだけを読んでも復元しきれません。
-
メインフレーム固有の非機能要件が引き継がれない。Gartnerは、生成AIが「移行後に同等の性能やスループットを確保する」といったメインフレーム固有の価値を考慮しない、と述べています。つまり、機能としては動くコードに変換できても、トランザクション量・応答時間・可用性という非機能の世界が抜け落ちる危険があります。
-
ベンダー側のインセンティブが歪んでいる。投資家からの圧力により、成果改善への寄与が明確でなくても自社製品に生成AIを組み込む動きが起きている、とGartnerは指摘します。発注側が「AI搭載＝速くて安い」を額面どおり受け取ると、検証されていない自動化に賭けることになります。2030年までにベンダーの75%が転換・撤退するという予測は、画一的な「全自動移行」への需要が冷えることの裏返しでもあります。
独自の示唆：失敗の本質は「翻訳問題」ではなく「仕様の発掘問題」
ここから、出典の指摘を踏まえた当社なりの示唆を一つ提示します。生成AIによる離脱が崩れる根因は、コードを別の言語へ「翻訳」する精度の問題に見えて、実際は「業務仕様を発掘・再定義」する工程が省かれることにあります。Gartnerが性能・スループットという非機能を強調しているのは、表面的なコード変換では拾えない要件が成果を左右するからです。
この読み替えが効くのは、発注の打ち手が変わるためです。「翻訳問題」だと捉えると、より高性能なAI変換ツールを探す方向に走ります。しかし「仕様の発掘問題」だと捉えれば、現行業務を理解する人材と、変換を支援するAIを組み合わせ、対象範囲を絞って段階的に検証する設計に投資すべきだと分かります。Gartnerが「離脱の加速」より「既存環境内での近代化」を勧めるのも、この発掘工程を飛ばさせない現実解として整合します。
自社への翻訳：失敗リスクを抑える刷新の発注チェックリスト
予測を自社の意思決定に変換します。RFPや稟議の前に、次の観点を満たしているか確認してください。
- ゴールを「離脱」自体でなく、得たい便益（コスト・俊敏性・人材リスク低減）で定義しているか
- 全面一括移行ではなく、適用範囲を絞った段階移行の計画になっているか
- 生成AIの役割を「全自動変換」ではなく「人の作業を支援する伴走ツール」として位置づけているか
- 現行業務の暗黙仕様を発掘する人材（業務有識者・既存システム熟知者）を体制に組み込んでいるか
- 機能要件だけでなく、性能・スループット・可用性などの非機能要件を移行後の合格基準に明記しているか
- 「modernization in place（既存環境内での近代化）」を選択肢として比較検討したか
- ベンダーの「AI搭載で速い・安い」の主張に、検証可能な実績や小規模PoCの裏付けを求めているか
- 撤退・縮小リスクのあるベンダーへの依存度を、契約・データ・運用の観点で点検したか
このチェックリストの狙いは、Gartnerの予測する失敗パターン（過大評価・全自動前提・非機能の欠落）を、発注の段階で潰すことにあります。とくに非機能要件の合格基準を先に決めておくことは、移行後に「動くが遅い」という最悪の手戻りを防ぎます。
いつGXOに相談すべきか
次のような状況にあるなら、構想の早い段階で外部の知見を入れる価値があります。
- メインフレームやオフコンの刷新を検討しているが、全面移行と現状維持の二択で止まっている
- ベンダーから「AIで自動変換できる」と提案されたが、自社で妥当性を判断しきれない
- 現行システムを理解する人材が退職・高齢化し、業務仕様の発掘自体が難しくなっている
- 補助金や予算承認のタイミングが迫り、適用範囲と段階計画を急いで詰める必要がある
GXOは、レガシー刷新を全自動の置き換えではなく、業務仕様の発掘と段階移行を前提に設計します。現行システムの棚卸しから移行範囲の見極め、非機能要件の定義までを伴走するのがレガシー刷新の要件定義です。生成AIをどこまで・どの工程で使えるかを実装まで一緒に見極めたい場合は、成果まで併走するFDE+による実装伴走が選択肢になります。「そもそもAIを刷新のどこに使えるのか」を客観評価したい段階なら、AI導入可否のアセスメントから始めるのが安全です。
レガシー刷新は、着手前の発注設計でほぼ勝敗が決まります。自社の状況に合わせた段階移行の進め方を相談したい方は、レガシー刷新の要件定義からお問い合わせください。
FAQ
Q. 生成AIをメインフレーム刷新に使うのは間違いなのですか。 A. いいえ。Gartnerが警告しているのは「離脱を全自動化する手段」としての過大評価です。コード理解の補助や既存環境内での近代化支援など、人の作業を助ける用途では有効とされています（出典：Gartner、2026年6月18日）。
Q. 「70%が失敗」とは、移行が技術的に頓挫するという意味ですか。 A. 報道によれば「意図した成果を生み出せない」ことを指す表現です。動かないという意味に限らず、期待したコスト削減や俊敏性が得られないケースを含みます。確定実績ではなく予測値である点にも留意してください。
Q. 全面移行を避けるなら、何から始めればよいですか。 A. まず得たい便益を定義し、適用範囲を絞った段階移行か、既存環境内での近代化かを比較します。並行して、移行後の性能・スループットなど非機能の合格基準を先に決めておくと、手戻りを抑えられます。
