AIでCOBOLを97.9％移行できても、刷新は終わらない——人材・計算資源・復旧をつなぐ「移行完了票」

古い業務システムを新しい言語へ移す仕事では、コードを書き換える工程が最も目立ちます。生成AIがCOBOLをJavaやPythonへ変換し、テストまで通せるなら、長年止まっていた刷新が一気に進むように見えます。

しかし、企業が移したいのはソースコードだけではありません。月末締めの順番、端数処理、障害時の戻し方、外部機関とのファイル交換、担当者が電話で補ってきた例外判断まで含む「仕事の継続」です。変換後のコードが動いても、翌月の請求、翌年の制度変更、担当交代、基盤障害を越えられなければ移行は終わっていません。

OpenAIは、COBOLから複数の現代的な言語へ移す独自評価で、推論量を増やしたモデルが最大97.9％の正解率に達したと公表しました。一方、GartnerのCIO調査では、AI案件が成功する確率は5件に1件のまま変わっていないと報告されています。性能の進歩と企業の完了率は、同じ数字ではありません。

本記事では、AIによるレガシー刷新を「変換できたコードの割合」ではなく、同じ仕事を安全に引き継ぎ、問題時に戻せるかで管理する「移行完了票」として整理します。

既存システムと新しい計算基盤をつなぐ電子回路

結論——97.9％は入口であり、完了条件ではありません

OpenAIの評価は重要な前進です。学習用のコードや文書が比較的少ないCOBOL、Fortran、Visual Basicなどでも、最新モデルが以前より高い精度で実装や移行を支援できる可能性を示しています。特に、COBOL特有の固定小数点演算を含む出力をバイト単位で比較した点は、単にコンパイルできるかを見る評価より厳格です。

それでも、最大97.9％をそのまま「自社システムの97.9％を無人で移せる」と読み替えてはいけません。評価用の問題集合と、企業で数十年使われた本番システムでは、次の条件が違います。

自社固有の業務規則とコメントに書かれていない前提
データベース、帳票、ジョブ、端末、外部機関との依存関係
制度改定日、休日、うるう年、端数、取消、再送などの例外
障害時にどの時点へ戻し、二重処理をどう防ぐか
誰が差分を説明し、承認し、移行後を保守するか
新旧基盤を並行稼働する期間の人件費と計算費

したがって、移行の主指標は「AIが変換した行数」ではなく、「新システムで受け入れられた業務単位」です。業務単位とは、例えば一件の振込、一回の保険料計算、一日の在庫締め、一つの自治体給付、一回の請求書発行です。入力から最終結果、記録、取消、再実行までを一組として閉じます。

以前の記事では、公開ベンチマークと実際の職場の間にある空白を「業務カバレッジ票」で整理しました。COBOL移行でも同じで、モデル評価が覆う能力と、自社の一件が要求する工程を分けて記録する必要があります。

OpenAIのCOBOL評価は、何を証明したのでしょうか

ITmedia NEWSの報道によると、OpenAIは学習資源の少ない言語を対象に二種類の評価を公開しました。

一つ目の「MultiLangBench」は、20言語のそれぞれでSQLite互換のデータベースエンジンをゼロから構築させる評価です。報道では、推論量を最大にしたモデルが20言語平均で87.4％のテスト合格率を達成した一方、COBOLは72.1％で、対象言語の中では引き続き難しかったとされています。

二つ目は、COBOLプログラムをC++、Java、Kotlin、Python、Rustのいずれかへ移し、元と同じ出力を維持できるかを見る評価です。全テストへの合格を成功条件とし、推論量を増やした場合に最大97.9％へ達したと報じられました。

ここから読み取れるのは、「AIは古い言語が一律に苦手」という前提を更新すべきだということです。小さな移行単位を作り、入力と期待出力を十分に用意できるなら、コード変換、テスト生成、差分説明の速度を上げられる余地があります。

同時に、OpenAI自身も、本番適用には専門家のレビューと、業務規則や依存関係に照らした試験が必要だとしています。独自評価で高い数値が出たことは、各社の給与、決済、税、在庫、医療、公共業務に対する保証ではありません。評価環境を再現できることと、自社の本番を安全に移せることの間には、業務知識と運用設計があります。

「同じ出力」は一つではなく、五段階に分けます

移行試験では、画面の数字が合ったことだけで合格にしません。同じ結果を少なくとも五段階へ分けます。

段階	比較する対象	見落としやすい差
計算一致	金額、税、利率、数量、日付	丸め、切り捨て、符号、文字コード
記録一致	台帳、監査ログ、更新順、識別子	書き込み順、欠番、時刻、再送
連携一致	ファイル、API、帳票、外部端末	桁幅、改行、圧縮、送受信時刻
例外一致	取消、訂正、重複、期限超過	正常系だけでは出ない手作業
復旧一致	再開位置、ロールバック、代替手順	二重処理、途中状態、担当不在

「同じ出力」を一つの列にすると、正常系の数値が合っただけで移行済みに見えます。しかし、業務事故は例外と復旧で起きやすいものです。新システムが速くても、障害後にどこから再開するか分からなければ、旧システムより停止時間が長くなります。

AIには、既存コードの説明、入出力候補の抽出、境界値テストの下書き、旧新差分の分類を任せられます。一方、どの差が許容され、どの差が顧客、法令、会計、契約へ影響するかは、業務所有者が決めます。技術担当だけで合格にせず、実際に結果を受け取る部署を受入者へ含めます。

変換対象を「一つの巨大システム」にしません

レガシー刷新が長期化する理由の一つは、対象を大きな製品名や基幹システム名で数えることです。「勘定系を移行する」「販売管理を刷新する」という単位では、完了条件が遠すぎます。

最初に、業務を小さな完了単位へ分けます。

誰が、どの出来事をきっかけに始めるかを決めます。
必要な入力、参照、計算、承認、出力を並べます。
正常、取消、訂正、重複、遅延、障害の例を集めます。
旧システムの結果と、新システムの期待結果を保存します。
外部連携と担当者の手作業を同じ図へ置きます。
一件だけを新旧で再現し、差分の所有者を決めます。

例えば「請求機能」ではなく、「月途中で契約内容を変更した顧客の翌月請求を計算し、明細を発行し、会計へ渡し、問い合わせ時に根拠を再表示できる」と書きます。ここまで具体化すれば、AIが作った変換コードを何で試すかが明確になります。

大きな一括移行より、小さな業務単位を繰り返す方が、97.9％に入らない残りを発見しやすくなります。失敗した一件を隠して平均へ吸収せず、未移行のまま残し、人が扱うか、設計を直すか、旧機能を廃止するかを選べます。

人材は減らす前に、役割を組み替えます

AIでコード作成が速くなれば、開発者をすぐ減らせるという期待が生まれます。しかし、ITmedia エンタープライズが紹介したGartner調査では、回答者の40％が2027年にIT部門の人員を増やすと見込んでいます。AIで技術を作る費用と労力が下がる一方、技術関連の仕事への需要全体が増え、特にサイバーセキュリティやデータ分析で増員が見込まれるという説明です。

同じ調査では、AIから大きな価値または変革的な価値を得たとするCIOは13％で、AI案件の成功確率は5件に1件のままだと報告されています。また、人とAIが共に働く役割再設計の明確な計画を持つCIOは4％にとどまったとされています。

COBOL移行で必要なのは、古い言語の担当者をAIへ置き換えることではありません。役割を次のように移します。

従来の役割	移行中に増える役割	移行後に残す知識
COBOL実装	AI変換の差分説明、境界値の選定	業務規則と例外の由来
ジョブ運用	新旧並行監視、再実行判断	締め時刻と依存順序
問い合わせ対応	実例から受入試験を作る	顧客が困る失敗の形
基盤運用	計算費、モデル、権限、ログの管理	手動への縮退経路
監査・法務	変更理由と承認記録の確認	保存期間と説明責任

古いシステムを知る人が退職する前に、コードの説明だけでなく「なぜこの例外があるのか」を残します。AIへ質問して得た説明は仮説として扱い、担当者、帳票、事故記録、規程で照合します。コメントのない処理を、AIが自然な物語へ補っただけかもしれないからです。

AI生成コードを四つの関門で扱う方法で整理したように、生成時のテストだけでなく、安全性、構成変更、本番監視を分ける必要があります。移行案件では、そこへ業務受入と旧系復旧を加えます。

移行後の役割と受入条件を話し合うチーム

計算資源は速さではなく、移行期間の総額で見ます

AIによるコード解析とテスト生成を大規模に回すと、モデル利用料、推論基盤、保存、ログ、ネットワーク、人の確認時間が増えます。変換単価が下がっても、試す対象と再試行が増えれば総額は上がります。

Gartner調査では、CIOの58％がAIによるコスト改善を求める圧力が強まった一方、51％はAIによって技術ソリューションの総所有コストが増えると予想したと報じられています。レガシー刷新では、AI費用と旧システム維持費が並行して発生します。移行が一年延びれば、二重運用の費用も一年延びます。

国内では、Preferred NetworksとTenstorrentによるプロセッサ共同開発が発表されました。PFNは高いメモリ帯域幅を持つ次世代「L1000」について、70B規模のモデルで毎秒500〜1000トークン程度という目標を掲げています。ただし、提供予定は当初の2026年から2027年へ修正されています。性能値は企業側の目標であり、実際の提供時期、価格、対応ソフト、保守を別に確かめる必要があります。

海外の計算基盤にも費用の境界があります。The VergeのCoreWeave分析は、同社が2026年第2四半期時点で350億ドル超の債務を抱え、上半期に10億ドル超の損失を計上したと伝えています。一方で、残存履行義務は1037億ドルで、その約40％が2028年に予定されるとも報じています。これは直ちにサービス停止を意味しませんが、計算能力の供給を「必要なときに同じ条件で買える」と固定しない理由になります。

移行計画では、クラウドか国産基盤かを先に争うより、次の四つを記録します。

一業務単位を解析、変換、試験、再試験する計算量と費用
利用モデルや基盤を替えたとき、同じ試験を再現できるか
契約変更、値上げ、提供延期、障害時の代替経路
ソースコード、業務データ、ログをどこまで外部へ送れるか

モデル、半導体、クラウドは入れ替わります。受入試験と期待結果を自社で保持すれば、基盤を替えても同じ完了条件を再利用できます。

十欄の「移行完了票」を一件ごとに作ります

移行完了票は、モデル名や変換率を記念する資料ではありません。次の担当者が、一件の状態と残る危険を短時間で説明できるための表です。

欄	記録する内容
業務単位	誰の、どの用事を、どこまで終えるか
旧系根拠	コード、帳票、規程、担当者説明、過去事例
入出力	正常、境界、例外、取消、再送の例
変換範囲	AI、人、既存製品が変更した部分
差分	計算、記録、連携、例外、復旧の違い
受入者	技術、業務、監査、外部連携先の責任者
計算条件	モデル、版、設定、費用、実行日時
停止条件	差分、費用、期間、障害、説明不能の上限
復旧経路	旧系へ戻す条件、再開位置、二重処理防止
廃止証拠	旧系停止、データ保存、権限削除、保守引継ぎ

「変換完了」と「移行完了」を別の日付にします。変換完了は、AIまたは人が新しい実装を作り、技術試験へ渡せる状態です。移行完了は、業務受入、例外、復旧、運用、旧系廃止まで閉じた状態です。

旧系を止める前には、未完了票がゼロである必要はありません。廃止する機能、人が継続する例外、別製品へ移す機能があっても構いません。ただし、どこへ行ったか分からない機能を残しません。平均の変換率を上げるために、難しい例外を母数から外さないことが重要です。

AIに任せる範囲は、戻しやすさで広げます

最初から本番コードの置換まで自動化する必要はありません。AIの役割を四段階で広げます。

読み取りと説明

既存コードの呼び出し関係、入出力、データ項目、重複処理を整理させます。出力は事実ではなく、調査候補です。根拠となる行、ファイル、実行記録を添えられない説明は、設計判断へ使いません。

試験候補の作成

境界値、異常値、日付、端数、取消、重複、再送の試験候補を作らせます。過去の障害票や問い合わせ記録から、実際に起きた失敗を優先します。生成件数ではなく、旧系の未知の挙動を発見した件数を評価します。

小さな変換

副作用の少ない計算、帳票整形、ファイル変換などから新言語へ移します。旧新へ同じ入力を与え、出力だけでなく記録と処理順も比較します。差が出たら、人が理由を分類するまで自動修正を繰り返しません。

限定した本番移行

対象顧客、拠点、商品、期間を限定し、新旧を並行して動かします。問題時に旧系へ戻せる時間を決め、復旧訓練を先に実施します。全件切替は、限定運用で例外と問い合わせを受け入れた後です。

AIの能力が上がるほど、一段を速く通過できます。しかし、受入者と停止条件を省けるわけではありません。速く作れることと、速く責任を引き受けられることは別です。

停止ルールを、失敗ではなく刷新の機能にします

Gartner調査では、AIの試行を本番へ移さない判断基準を持つ組織のCIOは、持たない組織より「先駆者」に該当する割合が2.3倍高く、本番の低価値案件を止める基準では2.6倍高かったと報じられています。一方、その慣行を導入している回答は、試行段階で31％、本番段階で17％にとどまりました。

レガシー刷新では、「ここまで費用を使ったから止められない」が大きな危険です。停止条件を開始前に置きます。

同じ業務単位で説明できない差分が一定数を超えた場合
旧系の期待結果を作れる担当者が確保できない場合
例外処理や外部連携の所有者が決まらない場合
一件当たりの確認時間や計算費が基準を超えた場合
復旧試験で二重処理や記録欠落が起きた場合
モデル、基盤、委託先を替えると試験を再現できない場合

停止には三種類あります。一件だけを止める、工程を前段へ戻す、案件全体を終了する、です。止めた理由と再開条件を移行完了票へ残します。これにより、担当者が替わっても、同じ失敗を最初から繰り返さずに済みます。

移行を支えるサーバーとネットワーク基盤

90日で始めるなら、行数より一件の再現からです

最初の30日は、重要だが範囲を限定できる業務を三件選びます。既存コードを読む前に、利用者、入力、出力、例外、復旧を聞き取ります。過去一年の問い合わせ、障害、手作業の訂正を集め、旧系で期待結果を再現します。この期間は本番コードを置き換えません。

31日目から60日目は、AIに説明、試験候補、小さな変換を作らせます。モデル名、版、設定、費用、実行日時を保存し、新旧差分を五段階で分類します。AIが直した回数ではなく、人が差分理由を説明できた割合を見ます。モデルを一度替え、同じ受入試験を再現できるかも確かめます。

61日目から90日目は、影響を限定して並行稼働します。新系の結果をすぐ本番へ反映せず、旧系と比較する期間を置きます。次に、担当者不在、モデル停止、基盤障害、外部連携失敗を一つずつ起こし、旧系または手作業へ戻します。復旧後に、途中の取引が重複していないことまで確認します。

90日後に並べる指標は次の通りです。

業務単位の総数、受入済み、未着手、廃止、保留
正常、例外、復旧の試験数と合格率
AI生成時間、人の確認時間、再試行時間
一件当たりのモデル費、基盤費、人件費、二重運用費
説明不能な差分の件数と滞留日数
担当交代後に再現できた業務単位の割合
旧系へ戻すまでの時間と重複処理の件数
モデルまたは基盤変更後も再現できた割合

変換行数が多くても、例外と復旧が未完了なら切替を急ぎません。逆に、行数が少なくても、一つの業務単位を旧系から新系へ安全に閉じられたなら、次へ使える移行能力が残ります。

調達ではモデル名より、試験資産の所有を決めます

AIモデル、移行製品、クラウド、半導体を選ぶとき、性能表だけで比較すると、契約終了時に受入条件まで失うことがあります。自社が保持すべきなのは、少なくとも次の資産です。

業務単位ごとの入力、期待出力、例外、復旧例
変換前後の差分と、人が承認した理由
モデル、設定、ツール、依存ライブラリの記録
移行中に見つかった暗黙の業務規則
本番切替、停止、旧系復帰の手順
委託先がいなくても再実行できる最小環境

ベンダーが独自の変換率を示す場合は、成功の分母、対象言語、コード規模、外部連携、例外、非公開テストの有無を聞きます。自社コードを渡す前に、保存場所、学習利用、再委託、ログ、削除、国外移転も確認します。

特定モデルの高得点は、候補を絞る材料になります。しかし、移行完了票と受入試験を自社が持てば、翌年に別のモデルが優れたときも比較できます。モデルを選ぶ仕事と、仕事の正しさを定義する仕事を分離することが、長い刷新を一社の製品寿命から守ります。

まとめ——古い言語を捨てるのではなく、仕事を引き継ぎます

COBOL移行で最大97.9％というOpenAIの公表値は、古い言語の刷新を「人が一行ずつ書き直すしかない仕事」から変える可能性を示しました。コードの説明、変換、試験候補、差分整理をAIが速めれば、これまで費用や人材不足で止まっていた業務にも着手しやすくなります。

一方、Gartner調査が示すのは、AI案件の数が増えても成功確率が自動では上がらず、人材の役割再設計、停止ルール、総所有コストの管理が残るという現実です。PFNとTenstorrentの共同開発や海外の計算基盤投資は選択肢を増やしますが、提供時期、価格、契約、再現性を一つの供給先へ預けない設計が必要です。

日本企業が移すべきなのは、COBOLという文字列ではありません。顧客のお金、行政の給付、工場の在庫、会社の会計を、例外と復旧を含めて次の担当者へ渡せる状態です。

あなたの組織で「移行済み」と呼んでいるのは、コードが変換された日でしょうか。それとも、担当者が替わり、AIや計算基盤が止まり、例外が起きても、一件の仕事を最後まで閉じられた日でしょうか。後者を移行完了票へ書けるなら、97.9％は宣伝の終点ではなく、安全な刷新を始めるための入口になります。