OpenAIは20言語でのデータベース構築と、既存COBOLの動作を保つ移行を評価しました。最新モデルで精度と推定API費用の改善を報告しています。 既存システムの刷新では、新規コードの生成力だけでなく元の動作の保存が焦点になります。評価の成績を自社の移行成功率へそのまま当てはめることはできません。 新しく作る能力と既存の動作を残す能力 OpenAIは2026年10月19日、学習に使えるコードや文書が比較的少ない言語での能力向上を報告しました。COBOL、Fortran、Visual Basicなどが対象です。背景には、古いシステムの文書が不足し、元の開発者が離れ、業務の規則がコードにしか残っていないという課題があります。同社は二つの評価を用意しました。MultiLangBenchは二〇の言語でSQLite互換のデータベースを作る課題です。もう一つは、既存のCOBOLを別の言語へ移し、動作を保てるかを調べます。新規構築と移行を分け、コードを書けることと既存の仕様を引き継げることを別々に測る構成です。 保守担当者には実際の入出力で比べる材料 MultiLangBenchではGPT-6 Astraの平均テスト通過率が八七・四％となり、GPT-5.6 Solから改善したと報告しています。COBOL移行ではGPT-6.1 Solが低い推論設定で八六・六％、高い設定で九七・九％の精度を示しました。原文は精度だけでなく推定API費用も比較しています。影響を受けるのは、長く使われる基幹ソフトウェアの保守担当や、移行を計画する開発組織と見られます。データベースの評価は同じ初期状態と問い合わせを与え、参照実装の結果と比べる形です。実際の業務でも、出力や状態の変化を比較できる試験を用意する考え方が参考になります。ただし、限定した課題の成績は、外部接続や運用手順まで含むシステム全体の移行成功を保証しません。モデル間の比較も、推論設定や測定条件を揃えて読む必要があります。 移行の費用には回帰確認と切り戻しも含める 導入判断では、まず何を元の動作として残すかを定めることが論点になると見られます。資料に書かれていない例外処理や、長年の運用で受け入れられてきた入出力は、単純な書き換えでは失われる可能性があります。AIへ任せる範囲を決める際には、既存の実行結果を残し、変更前後を照合する体制が必要です。費用もAPI利用料だけでなく、人の確認、試験用データの整備、障害時の切り戻しまで含めて評価することが考えられます。推論を増やすほど評価上の精度が上がっても、応答時間や確認負担との釣り合いは業務ごとに異なります。小さな処理から比較可能な範囲を定め、未解決の差分を管理することが実務上の焦点です。原文の数値は候補モデルを絞る材料とし、自社のコードでどの振る舞いを維持できたかを別途確認する必要があります。試験にない例外の扱いも確認点になると見られます。