COBOLにおけるGPT-6.1 Sol：86.6%対5.4%、そして2つのテストのうち再実行できるのは1つだけ

に2026年10月19日、O​penAIは低リソース言語向けのコーディング評価を2件公開しました。そして見出しの数字はGPT-6.1 Solのものです：COBOL移行タスクの86.6%が低い推論エフォートで合格し、対してGPT-5.6 Solは同じ設定で5.4%でした。推論エフォートを上げると97.9%に上昇します。2つ目の評価であるMultiLangBenchは別のモデルの話です — GPT-6 Astraは最大推論エフォートで20言語にわたり平均87.4%を記録しました — しかしこれはこのリリースのより有用な半分です。なぜならO​penAIがハーネスをApache-2.0の下でGitHubに公開しており、今日の午後には自分で実行できるからです。86.6%を載せている方のCOBOL移行評価は別問題です。そのテストは非公開で、合格基準はO​penAI外部の誰も見たことのないケースに対するバイト単位の出力一致であり、第三者による再現はありません。この非対称性こそがすべてであり、どちらかの数字が移行のビジネスケースで引用される前に、はっきり述べておく価値があります。 このようなリリースの背景にある、記録されたAIの失敗やエージェントのインシデントは、the OrcaRouter AI Incident Archive に集められており、各エントリには独自の情報源、重大度、信頼度グレード、異議ありフラグが付いています。

混同してはいけない日付が1つある。GPT-6.1 Sol自体は2026年9月29日のものだ——これはローンチではなく、ここにあるものでモデルの重み、価格、料金表が変わることはない。10月19日に起きたのは、O​penAIが、これまで文書化したことのなかったカテゴリーにおいてモデルが何をできるかに関する証拠を公開し、誰でも再実行できるベンチマークを発表したことだ。本稿が扱うのはこの出来事である。

実際に何が公開されたのか、そしてそれぞれの半分が何のためのものなのか

この2つの評価は異なる問いに答えており、OpenAI自身の枠組みでも両者は分けて扱われている。MultiLangBenchは、モデルが構築できるか、つまり、誰も学習しない言語で、20のプログラミング言語の1つを使ってSQLite 3.40.1をゼロから実装し、その後データベース適合性テストスイートに合格できるか、を問う。COBOL移行評価は、モデルが移行できるか、つまり、何か、具体的にはCOBOLプログラムをC++、Java、Kotlin、Python、Rustへと、観測可能な振る舞いを正確に保ちながら翻訳できるか、を問う。

最初のものは能力の下限を測るテストだ。二つ目は企業が実際に気にかけるものだ。なぜなら、COBOLはベンチマーク上の珍しい対象ではなく、IBMの長年の推計によれば、オンラインバンキングシステムの40%超とATM取引の約95%がCOBOLに支えられており、そのコードは補充されない労働力によって保守されているからだ。

• MultiLangBench、最大限の取り組み — GPT-6 Astra 87.4%、GPT-6 Luna 40.3%、GPT-5.6 Sol 26.8%。Astraは20言語中19言語で83%をクリアし、COBOLが最も弱く72.1%で、GPT-5.6 Solの10.9%と対照的でした。これは、このセットで最も難しい言語が依然として最も古いツール群を持つ言語であることを示しています。

• COBOL移行、低労力 — GPT-6.1 Sol 86.6%、GPT-5.6 Sol 5.4%、評価実行時の旧モデルのAPIコストの推定61%、すなわち39%の削減。

• COBOL移行、より高い工数 — GPT-6.1 Sol 97.9%、OpenAIはこれを飽和に近い状態だと説明しています。

• 言語別の詳細をOpenAIは公開した — FortranではAstraが83.5%、GPT-5.6 Solが21.4%。Visual Basicでは89.4%対27.5%。OCamlでは85.8%対25.6%。GPT-6 LunaはCOBOLで17.1%、Fortranで31.4%、OCamlで34.1%、Visual Basicで41.6%。

• MultiLangBenchにおけるサンプルあたりのコスト — GPT-6 Lunaの推定$0.77に対し、GPT-5.6 Solは$3.48で、およそ78%低い。この数字こそが、ボード上で最弱のモデルをビルド生成パイプラインにとって興味深い存在にしている.

再実行できる評価：MultiLangBench が実際に求めているもの

リポジトリはgithub.com/openai/MultiLangBenchで、Apache-2.0 であり、ハーネスを読むことはリーダーボードを読むよりも情報量が多い。タスクは十分に具体的なので、モデルがごまかすことはできない。データベースのパスをコマンドライン引数として受け取り、stdin から SQL クエリを読み取り、SQLite 3.40.1 のように振る舞う実行可能ファイルを作成する。テストは SQLite 自体の TCL スイートに由来し、合計約51,000件のテストのうち、約24,000件がハーネスで使用される三つ組に変換された。初期データベース、ユーザークエリ、検証クエリである。テスト名はこれらの構成要素の SHA-256 ハッシュなので、スイートを名前で丸暗記することはできない。

難しさはルールの中にあり、それぞれのルールが近道を塞ぐ：

• インターネット接続がなく、環境内のどこにも SQLite は存在しません。 ハーネスは、まず SQLite の痕跡をすべて取り除くよう指示しています。モデルは実際のエンジンをシェル経由で呼び出すことはできず、実装を取得することもできません。

• 検証は実際の SQLite 3.40.1 に対して実行されます。あなたの実装がデータベースを変更し、ハーネスがそれを抽出して本物の SQLite でチェックします。近似した挙動では失敗します。

• テスト1回につき60秒、そして言語を間違えた回答は0点です。 言語を混ぜると失敗し、ハーネスは、実際にどの言語で書いたかを確認するために別のモデルが使われる可能性があると注記しています。最後のルールがあるのは、明らかなカンニング——Pythonで書いて包むこと——を、有能なモデルが最初に試すからです。

• クイック実行は272件のテストであり、24,000件ではありません。 READMEでは、比較可能な数値が必要な場合、名前が00、01または02で始まるテストのみを実行することを推奨しています。OpenAIのスコアとご自身のスコアを比較する前に留意すべきはこの点です。フルスイート実行とクイック実行は同じ測定ではなく、READMEにもそう明記されています。

それは実際に検証可能なベンチマークです。また、報道が伝えていないことも分かります。つまり、87.4%という見出しの数字は、自分のモデルに適用して試せるスイートで測定されたものだということです。これは十分に珍しいので、ダウンロードする価値があります。

再実行できない評価と、それが自動的にスキャンダルではない理由

COBOL移行評価はOpenAIが設計し、OpenAIが実行し、OpenAIが採点しており、そのテストケースは公開されていない。合格基準は正確に示されている——移行が認められるのは、すべての非公開テストがバイト単位で同一の観測可能な出力を生成した場合のみである——そして、その正確さこそが、結果を外部から検証不能にしている。86.6%は、OpenAI自身の非公開ケースに対するOpenAIの測定値である。リリースに含まれる2つの評価のうち、読者が再現できるのは1つだけである。

移行テストを公開しないことは、擁護できないことではない。そのコーパスはおそらく実際のレガシープログラムから取られたものであり、公開すれば顧客のコードが漏洩したり、将来のモデルに訓練用データセットを渡してしまったりする可能性がある。バイト単位の完全一致もまた、真に保守的な基準であり、ほとんどのベンダー評価よりも厳格だ。単に近いだけの翻訳を評価することはないからだ。

しかし、この基準は実務上の問題が始まる場所でもあり、OpenAI自身の注意書きもそこを指摘している。移行の出力は、本番投入前に専門家によるレビューと、業務ルールやシステム依存関係に対するテストが依然として必要だ。またバイト単位の一致は、まさにCOBOLが難しいところで難しい。この言語は固定小数点演算を、ほとんどの対象言語がしない形で切り捨てたり丸めたりするため、翻訳が正しく見え、「十分近い」ことを確認するテストスイートに通っても、残高が1セント動いてしまうことがある。厳密な等価性を要求する隠れたテストスイートならそれを扱えるが、自分のレビュープロセスでも扱わなければならない。モデルのスコアはあなたのプログラムについての表明ではないからだ。

コストの数字にも同じ注意が必要だ。39%の削減は評価実行、つまりベンチマークに出入りするトークンに関する推計であり、本番システムを置き換えるコストではない。後者の大半を占めるのは、現状調査、専門家レビュー、統合テスト、そしてどの評価でもサンプルされない、文書化されていない長年の挙動である。

意思決定において、86.6%と97.9%は何を変えるべきか

率直に読めば、その意味するところは見出しよりも狭く、しかも見出しより役に立つ。5.4%というベースラインは、半分だけ機能するモデルではない。振る舞いを保持する翻訳をほとんど生み出さないモデルであり、つまり旧世代はそもそもこの作業の候補ですらなかった。86.6%のGPT-6.1 Solは、経済性が逆転する範囲にある。翻訳の大半を下書きし、確認をレビュー担当者に委ねるツールは、使えるものを何も生み出さないツールとは別の製品だ。

より高いエフォート設定での97.9%こそが疑ってかかるべき数字だ。それが間違っているからではなく、飽和しているからだ。ベンチマークは天井に近づくと、モデル間を識別するのをやめ、スイート自体を測るようになる。O​penAIもそう述べている。計画策定では、低エフォート時の86.6%を安価な運用点として扱い、97.9%はこの評価が示し得る上限として扱うこと——あなたのコードベースに対する精度の約束としてではない。

また、実施する価値のあるクロスチェックもあり、それは誇張とは逆の方向を示している。ビルドテストでは、COBOLはGPT-6 Astraの最も弱い言語のままで72.1%だった。Astraは総合では平均87.4%とより強いモデルであるにもかかわらずだ。この言語は双方向に難しい。隠れた評価でCOBOLの移行がうまくいくモデルが、それによってCOBOLが得意になるわけではない。そのモデルは評価がサンプルするパターンが得意なのだ。

今週起きたもう一つのこと：推論トレースの主張

10月21日に広く共有された投稿は、GPT-6.1 Solの推論トレースが「完全に判読可能で、心配することは何もない」と述べていた。OpenAIの10月19日の公開資料にも、モデル自身のドキュメントページにも、それがAPIの返す内容の変更であることを裏付けるものは何もない。OpenAIの推論ガイドは、生の推論トークンは公開されず、推論項目は不透明なままであること、そして要求できるのは要約であり、それは推論のsummaryパラメータを通じて得られるものであり、暗号化された推論内容はターン間で再生されることを明言している。GPT-6.1 Solは、その再生のall_turns形式をサポートする。summaryチャネルは判読可能なトレースではなく、この二つを同じものとして扱うことこそが、スクリーンショットによって安全性の主張がなされる所以である。

測定可能なものは隣接しており、エージェントを監査する誰にとってもより興味深い。Sonarが10月9日に実施したGPT-6.1 Solの評価では、GPT-6 Solを中程度のエフォートで4,444件のJavaタスクにわたって実行し、推論トークンが51.4%減少（2.64Mから1.28M）した一方、出力に占める推論の割合は41.8%から19.5%に低下し、出力は増加し、機能合格率は83.09%から85.29%に改善したことが判明した。同じ実行では、脆弱性密度が32.4%低下した一方、クリティカル重大度の信頼性所見が21件から46件に増加し、並行性バグが196件で最大のカテゴリだった。それはレビュアーが行動に移せるトレードオフだ。「トレースは判読可能だ」はそうではない。なぜなら、返されているのはトレースではないからだ。

移行プロジェクトでは、これは一つの具体的な意味で重要です。監査証跡は差分とテスト出力であり、モデルの語りではありません。それに応じてレビュー能力を見積もってください — 生成コードが39.4%増えると総検出件数が9,859件から12,982件になったというSonarの調査結果は、ベンチマークスコアの背後に隠れるコストの形です。

両方のアームを自分で運営する

このような比較の実用的な問題は、ベースラインのアームと新しいアームが通常は2つの契約、2つのキー、2つの請求関係になることです。その摩擦が大きすぎて、誰もベースラインを実行しません。両モデルは当社のカタログ上、1つのキーの背後にあります：openai/gpt-6.1-solとopenai/gpt-5.6-sol、OpenAIの定価でマークアップ0%、つまりベンダーに支払うのと同じく入力100万トークンあたり$2.00、出力100万トークンあたり$10.00で、キャッシュ入力は$0.10、キャッシュ書き込みは$2.50、272K超の階層は$4.00、$0.20、$5.00、$15.00でそのまま適用されます。ベンダーの料金変更は、次の契約レビュー時ではなく、公開されたその日にここで反映されます。

そのパススルーがあるからこそ、当日ベンチマークを低コストで実行できる。MultiLangBench のクイック スイートを両方のモデルに向け、それぞれに定価を支払えば、OpenAI の数値ではなく、自分のツールチェーンに関する数値が得られる。議論のもう半分は自動フェイルオーバーだ。新しいモデルが実行中に性能低下したり、ルートがレート制限されたりしても、リクエストはそれに巻き込まれて失敗しない。だからこそ、自分で証拠を得る前に、実績のないモデルを移行パイプラインの前に置けるのだ。

MultiLangBench のハーネスは公開されているが、COBOL 移行のケースは公開されていない。だから 86.6% を誠実に検証する唯一の方法は、自分で構築するテストだ。自分の COBOL プログラムを数百本サンプリングし、それを翻訳し、出力を元の動作とバイト単位で比較する。それには 1 週間かかるが、ベンダーの表よりも価値がある。

次に見るもの

この状況を変える要素は三つあり、まだどれも起きていない。OpenAIがCOBOL移行ケースを公開するか、独立系ラボがそれを再実行すれば、ベンダーが出した数字が測定結果になる。第三者がMultiLangBenchの言語別表を再現すれば、COBOLの72.1%が言語自体の性質なのか、テストスイートの性質なのかが分かる。そして、モデルの独立系ベンチマークでの記録――Artificial Analysisは現在、GPT-6.1 Solをインテリジェンス指数52、214モデル中12位、毎秒55.2出力トークン、指数タスクあたり0.72ドルと評価している――は、OpenAI自身の評価にまったく依存しない検証である。

それまでの有用な要約は短い。GPT-6.1 Sol は9月29日時点のモデルで、そのレガシーコード能力は10月19日に、実行できる評価と実行できない評価の2つで文書化された。実行できる方は、新しい世代が低リソース言語で別格であると示している。実行できない方は、COBOL移行が今やパイロットに値すると示している。そのどちらを判断に変えられるのは、あなた自身のコードベースだけだ。