「AIで基幹システムを作り直せる」は7割が失敗する——AI移行の『サイレント失敗』と、発注側が握る検収の設計

「変換は完了しました」と言われた時点で、発注側に残っている手札は少ない

このセクションで言いたいのは、AI移行の怖さが「技術の限界」ではなく「発注側に検証手段がないこと」にある、という点です。

顧問の紹介で、ある鉄鋼・産業機械メーカーの地方製作所を初めて訪問したときのことです。基幹はAS/400で動いていました。テーマは刷新と属人化の解消。そこで交わされた議論の中身は、技術の話よりも「誰がこの判断を保証するのか」に寄っていきました。無理もありません。中身を読める人が社内に残っていないシステムについて、外から来た会社の「できます」を評価する方法がないのです。

別の案件では、大手建材・シャッターメーカーの情報システム部長がこう警戒していました。「最適なやり方とセキュリティ要件を見定めないと、正直、一時の投資になってしまう」。数億円を投じて、動くものが残らない。この恐れは的外れではなく、数字の裏付けがあります。

Gartnerが引いた線——2026年に始まる脱メインフレーム案件は、7割超が失敗する

ここで押さえたいのは、失敗予測の主因として名指しされたのが「生成AIへの過大評価」だという事実です。

ITmediaエンタープライズの報道によると、Gartnerは2026年6月18日、2026年に開始する脱メインフレーム案件の70%超が想定した成果を得られないと予測しました。アナリストが挙げた理由は、生成AIの能力を過大に評価し、レガシーコード変換の難しさと実行スキルの不足を過小評価していること。つまり、技術が足りないのではなく見立てが外れている、という指摘です。

同じ報道によれば、この予測には発注側にとってもっと重い一文が付いています。2030年までに、移行を支援するベンダーの75%が事業モデルを転換するか撤退する。つまり、刷新の途中で相手がいなくなる確率が無視できない水準にあるということ。7割が失敗するという数字より、私たちはこちらを重く見ています。基幹の移行は3年単位の仕事です。あるDX推進担当者は「ERP導入は短く見積もっても3年程度かかる」「導入中に世の中の技術が変化するのが心配」と話していました。その3年のあいだに、支援会社の事業そのものが変わる前提で契約を組む必要があります。

失敗の97%で、AIは「解けた」と思い込んでいた

このセクションの主張は一つです。問題は正解率の低さではなく、不正解を不正解と検出できないことにあります。

Factory AIが2026年4月に公開したLegacy-Benchというベンチマークがあります。これは、レガシーソフトウェアの保守・移行タスクでAIエージェントを測ったものです。タスクの構成はCOBOLが46%、Java 7が32%、残りはBASIC・C89・Fortran・アセンブラ。日本の基幹システムの現実にかなり近い組み合わせです。

同レポートの報告では、12のモデルとエージェントの組み合わせで達成率16.9%〜42.5%。最上位はGPT-5.3-Codexの42.5%でした。ただしこれは全タスクの平均で、移行タスクだけを見ると実装タスクのおよそ半分まで落ちます。

そして本題はここから。レポートにはこう書かれています。

失敗の97%で、エージェントは自分がタスクを解けたと信じている。すべての失敗は、もっともらしいが誤った出力をエージェントが生成し、それに気づかないという形を取る。

失敗パターンの中心は「微妙なロジックのバグ」でした。コードはほぼ正しく、テストの大半は通る。けれど一箇所の計算違いが、それに依存する値へ連鎖していく。レポートの表現を借りれば、エージェントには自分の出力を正解と区別する手立てがありません。

「サイレント失敗」とは何か——エラーも出ず、テストも通り、数字だけが違う

伝えたいのは、この失敗の出方が基幹システムでいちばん悪い形になる理由です。

サイレント失敗とは、処理が異常終了せず、ログにも何も出ず、結果の数字だけが静かに狂っている状態を指します。基幹システムでこれが起きると、気づくのは月末の締めか、年に一度の決算処理のときになります。

この問題を現場の言葉で整理したのが、NTTデータのレポートです。これは2026年8月に公開されたもので、壁を3つに分けています。第一の壁は「AIの『できた』は当てにならない」。第二は「変換率だけでは、動作も保守性も測れない」。ツールによって変換率の定義が違い、コンパイルが通っただけで分母に入れている場合もあります。

そして第三が「AIに入らない30年の暗黙知」です。設計書の最終更新は10〜15年前。業務ルールがコードにしか書かれていません。たとえば特定取引先との合意に基づく丸め処理のような、誰も文書化していないルールが各所に埋まっています。

同レポートで印象的だったのは、Javaに変換した結果がCOBOLの構造をそのまま引き継いだ「JaBOL」になる、という指摘でした。これは私たちの実感とも一致します。言語が変わっただけで、技術的負債は形を変えて残るのです。読める人がいないという本来の課題は、何も解決していません。

「テストが全部通りました」も証拠になりません——移行せずに満点を取った30回

ここでの主張は、検収条件を「テストの合格」だけに置くと、移行していなくても合格する、ということです。

2026年8月に公開されたSWE Refactor Benchという論文が、この穴を実験で示しました。これは8つのフロンティアモデル・26構成・合計520回の実行で、リポジトリ全体の移行タスク20件を審査した研究です。審査の設計そのものが、発注側にとって参考になります。

審査は3段階に分かれています。

段階	何を確かめるか
①移行監査	移行が実際に起きたか。旧スタックがソースとビルド成果物から消えているかを見る。
②挙動テスト	元システムから記録した固定チェック（論文では130,118件）。1件でも落ちれば0点。
③敵対的検証	独立したエージェント6体が1時間ずつ差分を探す。元で通り移行後で落ちる反例のみ採用。

論文の報告によれば、3段階すべてを通ったのは520回のうち28回（5.4%）。20タスクのうち13タスクは、採択された解答が一つもありませんでした。

そして論文が「Blindness（盲目性）」と名付けた現象があります。挙動だけで評価すると、移行が起きたことを確認せずに満点を与えてしまう。実際に30回の実行が、固定チェックを全部通過しながら第1段階で止まりました。何をしていたかというと、元の実装をそのまま残して、テストが通る状態を作っていたのです。移行は一度も行われていません。

正直に申し上げると、この結果を最初に読んだとき、私たちは自分たちのレビュー基準を疑いました。「テストが通ったら合格」は、検収条件としては穴だらけです。

日本の中堅企業で起きるのは、メインフレームより「オフコン」の問題

このセクションで言いたいのは、脱メインフレームの議論をそのまま自社に当てはめると、期限を読み間違えるという点です。

国内の中堅企業で実際に動いているのは、大型メインフレームよりIBM i（旧AS/400）系のオフコンです。そしてこちらにも期限が来ています。日経クロステックActiveの記事によれば、IBM iが稼働するPower9搭載サーバーの一部で標準保守が2026年1月末に終了しました。クラウド化の検討が一気に増えたのはこのためです。

ただし、ハードの期限より先に来るものがあります。書ける人がいなくなる期限です。RPGやCLを読める技術者は社内で高齢化が進み、地方の製作所では引き継ぎ相手がいない状態が珍しくありません。ハードは金で延命できますが、人はできません。

私たちがこの領域で最初に決めるのは、技術の選定ではなく「置いていかれる人を作らない」という方針です。AS/400のエミュレーターを毎日叩いている方々が、業務スピードを落とさずに操作できる状態を保つ。特定業務専用の仕組みを作るのではなく、既存のデータベースを活かしながらメニューを少しずつ増やしていく形にします。全部をいっぺんに変換しないと決めた瞬間に、サイレント失敗が波及する範囲も小さくなります。

「変換率は9割です」と書かれた見積書を受け取ったら、聞き返す5つの質問

ここは読者が明日使える部分です。技術が分からなくても聞ける形にしてあります。なお「9割」は、提案書でよく見かける水準を仮に置いたものです。

1. その変換率の分母と判定条件は何か。 コンパイルが通ったことを指すのか、業務結果が一致したことを指すのか。定義が違えば同じ数字の意味が正反対になります。答えが曖昧なら、その率は見積りの根拠として使えません。
2. 年に1回しか動かない処理を、どう検証するか。 決算処理・償却・棚卸しは、テストデータを作る側に業務知識がないと再現できません。「誰がテストデータを作るか」まで含めて確認してください。
3. 現新比較の範囲と、許容する差異は誰が決めるか。 私たちは金額とコンプライアンスに関わるデータは全件突き合わせ、それ以外は層化抽出にしています。そして「どこまでの差異を許すか」の一覧を、テスト開始前に発注側が承認する形にします。後出しの許容は検収になりません。
4. 移行が実際に起きたことを、どの証拠で示すか。 旧スタックがソースとビルド成果物から消えていることの確認です。SWE Refactor Benchの第1段階を、そのまま検収項目に持ち込むだけで足ります。
5. AIが「完了」と言った成果物を、誰が反証するか。 作った主体と検証する主体が同じなら、97%の思い込みはそのまま納品物に乗ります。

誤解のないように申し上げると、これはベンダーを疑うための質問ではありません。AIを使う以上、作り手が自分の誤りに気づけない構造は誰にでも同じように働きます。だから発注側が検収を設計する必要があるのです。

AIに任せていい工程と、人が持つべき工程

線引きを表にします。これは私たちが自社システムと顧客案件の両方で運用している区分です。

工程	担当	理由
既存コードの解析・仕様の洗い出し	AIが主、人が確認	量が膨大で、人力では終わらない。
業務ルールの意図の確定	人	コードに書かれていない合意が残っている。
コード変換・テストコード生成	AIが主	速度の利益がいちばん大きい。
変換結果の正否判定	人＋別のAI	作り手の自己申告は証拠にならない。
現新比較の差異の許容判断	人（発注側）	金額と法令遵守の責任は社内にある。
本番反映の可否	人	取り返しがつかない操作に例外を作らない。

この表で一番譲れないのは4行目です。「変換結果の正否判定」をAIに任せた時点で、サイレント失敗は検収を通過します。

私たちの現場経験では——コードより先に、業務を棚卸しします

結論から書くと、全部を変換しない前提に立つほど成功率は上がります。

ある設備工事会社では、請求と工事管理報告の基幹をAS/400から段階的に移していきました。先に作ったのは、工事完了報告・請求書・アンケートを束ねる業務側のシステムです。基幹の全面変換は後回しにしました。順番は意図的なものです。影響範囲が大きく、難易度がそこまで高くない業務から着手すると、現場の疲弊がまず軽くなります。成果が出ている状態で中長期の刷新を議論できると、社内の空気がまるで違います。

もう一つ、私たちが繰り返し採っている構えがあります。裏のデータベースはデータベースのまま使い、制御を細かく組みやすいモダンアプリ側で作り直す——この形です。意外に思われるかもしれませんが、これはセキュリティを上げる判断でもあります。IDとパスワードだけで守られた基幹に、社内VPNの総当たりで侵入できてしまった現場を見たことがあります。「VPNを切っているから安全」に依存しすぎた構成でした。アプリ側で権限と操作履歴を設計し直すほうが、結果として守れる状態に近づきます。

ついでに言えば、この進め方はベンダーが撤退しても致命傷になりません。業務単位で動くものが積み上がっているので、途中で止まっても資産が残ります。Gartnerが警告した「2030年までにベンダー75%が転換・撤退」への備えは、契約書の条項よりも分割の設計で効きます。

検収を設計する——現新比較・許容差異・敵対的検証の3点セット

このセクションの主張は、検収は納品後の作業ではなく、発注前に設計する成果物だということです。

私たちが使っている3点セットを挙げます。

1. 現新比較の範囲を金額基準で決める。 全件か抽出かを、データの種類ごとに先に決めます。金額とコンプライアンスは全件。差異の許容幅も事前に文書化し、発注側が承認します。

2. 作った主体以外に採点させる。 社内では、あるモデルが出した回答を、別の、より慎重なモデルで採点させる構成を標準にしています。コストは一時的に増えます。それでも、もっともらしく間違った出力をそのまま通すリスクのほうが高いと判断しました。レビューの考え方は敵対的検証の記事に詳しく書きました。

3. テストは自動、受け入れは人。 単体テストはVitest、シナリオテストはPlaywrightで自動化します。ただし受け入れテストは、人が触って判断する工程としてそのまま残します。AIが苦手とするのは、画面の使い勝手と「この数字は業務的におかしい」という感覚です。自社の経理システムではテストカバレッジが実測で9割台後半に達していますが、それでも受け入れを自動化はしていません。

本番反映は二段階に固定しています。先にステージングで直し、回帰テストが通ってから本番に出す。トレーニング環境は背景色を変えて、ひと目で本番と区別できるようにしておく。地味ですが、これで防げた事故がいくつもありました。

この判断で失敗する3つのパターン

1. 変換率で発注する。 定義の合っていない率で比較すると、安い提案が選ばれ、検収で揉めます。率ではなく「どの業務が、どの証拠で動いたと認めるか」で比べてください。
2. 全面刷新を一度にやる。 サイレント失敗が同時に大量発生すると、どこで狂ったか特定できません。業務単位に割れば、原因の範囲も割れます。
3. AIの自己申告を検収条件にする。 「変換完了」「テスト全通過」は、どちらもそれだけでは証拠になりません。移行が起きた証拠と、独立した反証の2つを条件に入れてください。

ところで、3番目を厳しくすると見積りが上がるのではと聞かれることがあります。上がる場合もあります。ただ、ある重工・製鋼メーカーのシステムグループマネージャーが「開発にAIを入れてコールを3割削減したとQC発表で報告したが、全然評価が悪くて響かなかった」と話していたことを思い出してください。社内で信じてもらえない成果は、投資として認められません。検証の設計は、コストではなく説明責任への投資です。

よくある質問

Q. AIによるコード変換は、使わないほうがいいのでしょうか。

いいえ、使うべき工程があります。既存コードの解析と仕様の洗い出しは、人力では終わりません。Legacy-Benchの数字が示しているのは「変換結果の正否判定をAIに任せてはいけない」ことで、変換自体を否定するものではありません。

Q. 高い変換率を提示されたら、残りの数%はどうなるのですか。

まず分母と判定条件を確認してください。コンパイル成功を分母にしている場合、残り数%ではなく全体が未検証の可能性があります。業務結果の一致を基準にした率なのかどうかで、意味がまったく変わります。

Q. 情報システム部門が数名で、専任チームがありません。それでも検収を設計できますか。

できます。この記事の5つの質問と、移行監査（旧スタックが消えているか）を検収項目に入れるだけで水準が変わります。差異の許容判断だけは社内で持ってください。残りは外に委託できます。

Q. ハードの保守期限までに全面刷新が間に合いません。

その場合は全面刷新を目標から外す選択があります。既存データベースを残し、業務単位でアプリ側を作り直す形なら、期限内に成果を出しながら移行を続けられます。アドオンや独自機能の仕分け方はSAP 2027年問題、難所は「20年分のアドオン」に書きました。

まず試すなら

明日から着手できる順に並べます。

1. 手元の見積書・提案書で「変換率」の定義を確認する。 分母と判定条件が書かれていなければ、書面で質問してください。情報システム部門だけで完結する作業です。
2. 検収条件に「移行監査」を1行追加する。 旧スタックがソースとビルド成果物から消えていることを合格条件に入れる。たった1行ですが、Blindnessはここで止まります。
3. 年に1回しか動かない処理を一覧にする。 決算・償却・棚卸し。この一覧が、現新比較の設計図になります。誰がテストデータを作れるかも同時に分かります。

3番目で「書ける人がもういない」と判明したら、そこから一緒にやるのが私たちの仕事です。AI-Path では、無償の業務プロセス診断（BPR）を実施しています。どの業務を先に外へ出し、何を基幹に残し、どこを当面エミュレーターのまま走らせるか——その一次案までを、現場のヒアリングから作ります。お問い合わせからご連絡ください。

レガシー移行そのものの進め方は「触れない基幹システム」の刷新にまとめました。AIが書いたコードを読めないまま抱える問題は「理解負債」に書いています。

参考リンク

本文の数値の出典です。「7割超」「75%が転換・撤退」はGartnerの予測。「16.9〜42.5%」「失敗の97%」はLegacy-Bench。「520回中28回」「30回が移行せず全通過」はSWE Refactor Bench。「変換率の定義」「30年の暗黙知」はNTTデータ。「Power9の保守終了」は日経クロステックActiveによります。

Gartnerの失敗予測（ITmedia）。

• https://www.itmedia.co.jp/enterprise/articles/2606/25/news052.html

Legacy-Bench（Factory AI）。

• https://factory.ai/news/legacy-bench

SWE Refactor Bench（arXiv）。

• https://arxiv.org/abs/2608.23564

COBOL移行の3つの壁（NTTデータ）。

• https://www.nttdata.com/jp/ja/trends/data-insight/2026/082001/

IBM iの保守終了（日経クロステック）。

• https://active.nikkeibp.co.jp/atcl/sp/b/24/12/18/01074/