詳しい解説 · 読了目安 5 分
OpenAI、学習資料の少ないプログラミング言語で評価結果を公表
SQLite の実装と、動作を維持する COBOL 移行を対象にした、OpenAI による評価です。
- 原典の公開日
- 当サイトの公開日
- 出典確認日
OpenAI は10月19日、COBOL、Fortran、Visual Basic など、学習資料が比較的少ない言語のプログラミング評価を公開しました。対象は特定の開発課題であり、既存システムを自動移行できるという保証ではありません。
ニュースを聴く
この記事を読み上げるか、ニュースを続けて聴けます。
読み上げを準備中…
端末の音声
読み上げはブラウザーまたは端末が処理します。AISubHub は文章を音声 API に送りません。利用できる音声やロック画面での再生は端末によって異なります。
再開時に短い部分を繰り返す場合があります。
要点
- MultiLangBench は20言語で SQLite 互換のデータベースエンジンを構築する課題です。OpenAI によると、推論の強度を最大にした GPT-6 Astra の平均テスト合格率は87.4%、GPT-5.6 Sol は26.8%でした。
- 別の COBOL 移行評価では、書き換え後も観測可能な動作を維持できるかを確認します。非公開テストをすべて通過した場合だけ、移行成功と判定します。
二つの評価が測る能力
10月19日の発表は、AIのコーディング能力として一括りにされがちな二つの課題を分けています。MultiLangBenchはデータベースの新しい機能をどれだけ実装できるか、COBOL移行は書き直した後も既存の動作を保てるかを測ります。本站は、単一の高い割合よりこの区別が重要だと考えます。もっともらしいコードを書けても、両方に失敗する可能性があります。移行チームは必要な能力と、導入前に失敗を発見できる証拠を明確にする必要があります。
SQLiteの機能を検証する仕組み
MultiLangBenchでは候補プログラムに初期データベースとSQL要求を渡し、変更結果を本物のSQLiteで確認します。公開READMEはSQLite 3.40.1を指定し、初期データベース、候補のクエリ、参照用の検証クエリを区別します。約51,000件のTCLテストから約24,000件を変換し、既定の評価は272件です。より大きいテスト集合を使った場合は明示が必要です。本站の解釈では、言語間で観測可能な機能を比べる形式であり、見出しの数値が元の全SQLiteテストを網羅するという意味ではありません。
数値と実行条件を合わせて読む
OpenAIによると最大推論強度のGPT-6 Astraは平均87.4%、GPT-5.6 Solは26.8%のテストを通過しました。COBOLは10.9%から72.1%に上がりましたが、他の対象言語より難しいままです。GPT-6 Lunaは40.3%で、推定API費用はサンプル当たり0.77ドル、旧Solは3.48ドルです。精度と費用の選択が異なる結果です。本站は、呼び出し単価だけでなく、失敗した試行やレビューも含む合格結果当たりの費用を比較すべきだと考えます。
移行では動作保存が欠かせない
別の評価はCOBOLをC++、Java、Kotlin、Python、Rustへ移行し、観測可能な出力がバイト単位で一致することを非公開テストで確認します。全件通過が成功条件です。発表の具体例では、COBOLの固定小数点演算は明示指定がなければ余分な桁を切り捨てます。書き直したコードが丸めれば、実行できても金融計算の結果が変わり得ます。OpenAIの報告は低強度GPT-6.1 Solが86.6%、同設定の旧Solが5.4%、API費用は39%減で、より高い強度では97.9%です。
再現には環境条件も必要
公開リポジトリは、モデル環境から既存のSQLite実装を取り除き、インターネット接続を禁止するよう求めています。指定外の言語や複数言語の混在は不合格で、結果不一致、クラッシュ、60秒超のテストも失敗です。既存エンジンの利用を自作実装と混同しないための条件です。本站は文書を読んだだけで、この評価を実行していません。再現時はモデル、推論強度、テスト集合、環境、費用を記録し、条件の変更を隠して同じ実験と扱わないことが重要です。
実務では限定した試行から始める
本站は、重要度の低い一つのモジュールを対象に、書き換え前の代表入力と期待出力を保存する試行を提案します。丸め、欠損レコード、そのモジュールの実際の依存関係を追加テストにします。これは本站の検証案で、発表が実施した事例ではありません。業務責任者が差分を確認し、元に戻せる状態を保つべきです。公式発表はAPIでの実験を案内しますが、ChatGPTの会員契約に新しいAPI予算を与えるものではありません。高得点は調査の理由であり、本番の合格基準や専門家の責任の代わりにはなりません。
注目する理由
古いソフトウェアを保守するチームは、公開された評価設定を確認し、自社の業務ルールを使って検証できます。モデル選定では、テスト範囲、推論設定、実際の API 費用を合わせて比較することが役立ちます。
制約と提供状況
数値は提供元の報告で、AISubHub は独立に再現していません。ベンチマークの成功は本番環境の安全性を保証せず、専門家の確認と業務ルール・依存関係のテストが必要です。
出典と根拠
原典の公開日: 2026/10/19 · 出典確認日: 2026/10/20
補足資料
出典確認日: 2026/10/20
AI を活用した編集記事を、記載した一次情報で確認しています。企業の主張は出典を明示し、掲載は推奨を意味しません。