「AIは最新技術より、枯れた技術のほうが得意らしい」
最近、こういう話をよく耳にします。jQueryは書けるのに最新のフロントエンドフレームワークで詰まる、Java 8のコードはスラスラ書くのに2025年リリースのライブラリを指示すると幻覚で嘘APIを呼び出す—体感として、心当たりのあるエンジニアは多いと思います。
ただ、この「AIは古いものが好き」説、調べてみたら半分当たりで半分外れ でした。それも、外れているほうが面白い。
今回はこのテーマを業界動向と数字で掘り下げていきます。結論から言うと、本当の分岐点は「古いか新しいか」ではなく、「仕様の安定性 × 公開コーパス量」 という2つの条件にあります。
Java 8・jQueryへの強さは確かに現実
まず「当たっている半分」から。
枯れた技術の代表格、Java 8 と jQuery に対するAIの強さは、エンプラ現場の数字で明確に裏付けられています。Amazon、富士通、日立、Morgan Stanleyといったエンプラ各社が、Java 8から17への移行やCOBOLからJavaへの変換で、工数を桁違いに圧縮した事例を続々と公表しています。
| 企業・ツール | 成果 |
|---|---|
| Amazon Q Developer Transformation | 5人のチームが1,000本のJavaアプリを2日でJava 8→17に移行。工数換算で4,500年分、年間約2.6億ドルのコスト削減（AWS発表） |
| 富士通 Application Transform（2026年3月発表） | 既存システムの設計書網羅性95%向上、移行工数97%削減 |
| 日立 | COBOL→Javaの機械変換率90%超、関連相談件数は前年度比1.5〜2倍 |
| Morgan Stanley DevGen.AI | 2025年1月以降で900万行のコードを処理、28万時間を節約、15,000人規模のエンジニアに展開 |
どれも「枯れた既存資産のモダナイゼーション」が主戦場です。市場規模で見ても、レガシーマイグレーション市場は2025年 $226.7億から2031年 $514.5億（CAGR 14.6%、MarketsandMarkets）まで伸びる予測。AIは古い技術の延命市場を食い始めている、というのはエンプラの現実として進行中です。
jQueryに至っては、2026年4月時点でも全サイトの69.9%、JSライブラリ内シェア88.3%（W3Techs）で現役。20年近く前のライブラリが、いまだに世界のウェブの7割で動いている。AIがこれらを得意なのは、学習データの分布から見れば妥当でしかありません。
ここまでなら、「AIは古いものが好き」は正しい。
ところがCOBOLでは、仮説が崩れる
ここからが「外れている半分」です。
AIスタートアップの bloop.ai が公開しているCOBOLEvalベンチマークでは、GPT-4のPass@1が 10.27%。同じGPT-4がJavaのHumanEvalでは 67% を叩き出すことを考えると、一気に6分の1以下まで落ちる。
ここで疑問が湧きます。COBOLは仕様がきわめて安定していて（1959年の初リリースから基本文法が変わっていない）、「枯れた技術」の極北とも言える言語のはず。なぜAIが弱いのか。
答えは学習データ側にあります。
GitHubの公開リポジトリを調べた研究（The Stack v2 等）では、COBOLは全言語中でも公開コーパス量が極端に少ない。推計で84リポジトリ、合計4GB程度。JavaやPythonの1万分の1以下のオーダーです。
さらに強烈な事例として、IBMiやAS/400の主力言語であるRPGでは、レガシーマイグレーション専業のFresche Solutionsが「我々は本当にRPGで苦労した」と公言し、RPG専用のLLM訓練で大きく苦戦していることが報じられています（IT Jungle）。
「AIは古いものが好き」は嘘だったわけです。正確には、古くても公開学習データが薄い言語には弱い。
本当の分岐点は「仕様安定性 × 公開コーパス量」
ここまでの現象をまとめると、AIが強い技術と弱い技術の線引きは、こう整理できます。
| 技術 | 仕様安定性 | 公開コーパス量 | AIの強さ |
|---|---|---|---|
| Java 8 | 高 | 非常に多い | 強い |
| jQuery | 高 | 非常に多い | 強い |
| SQL（標準） | 高 | 非常に多い | 強い |
| 最新ライブラリ（2026リリース） | 低（変更中） | 薄い | 弱い |
| COBOL（標準） | 高 | 極少 | 弱い |
| AS/400 RPG | 高 | ほぼ皆無 | 壊滅的 |
「古いか新しいか」は表面的な特徴で、本質は「仕様が安定しているか」×「公開コーパスが豊富か」の2条件。両方揃ってはじめて、AIは強い。どちらかが欠けると、途端に手が出なくなる。
これが、調べてみて一番面白かった発見でした。
COBOLに存在する「3層の欠落」
もう少しCOBOLに踏み込みます。なぜCOBOLの公開コーパスだけ、これほど薄いのか。理由は1つではなく、3層の欠落が重なっています。
1. 公開コーパスの絶対量が少ない
すでに書いたとおり、GitHubのCOBOLは84リポジトリ、4GB程度。これは「活発に学ばれ、書かれ、共有される言語」ではない、ということの直接的な証拠です。
2. 本番コードがひとつもGitHubに出てこない
ここが一番の核心だと思っています。世界で2,200〜8,000億行（Reuters 2017、The Stack 2022-23再推計）あるとされるCOBOLコードの大半は、銀行、保険、政府、社会保障、鉄道の本番システムに埋まっていて、1行たりとも外には出ていません。
そもそも業務アプリケーションのコードは、どの言語でも公開されないのが普通です。ただJavaやPythonなら、OSSライブラリ・フレームワーク・個人開発のリポジトリが潤沢にあるため、「本番コードは公開されなくても、言語自体の書き方のサンプルは山ほどある」 状態が成立している。COBOLにはそれがありません。60年分の現場知見が、学習データに1バイトも流れ込んでいない。
3. 「現場COBOL」は方言化している
仕様書や教科書にある標準COBOL（ANSI・ISO準拠）と、銀行や保険会社の本番で動いている現場のCOBOLは、事実上別の言語と言っていいくらい乖離しています。
| 領域 | 具体例 |
|---|---|
| 言語拡張・連携 | 富士通方言、MicroFocus拡張、IBM z/OS特有のJCL連携 |
| 設計規約 | COPY句（共通定義）の社内命名規則 |
| ビジネスロジック | 独自のエラーコード体系、独自の日付表現、独自のバッチ制御 |
| ドキュメント | 仕様書すら属人化して、退職したベテランしか全貌を知らない領域 |
つまり、「一般的COBOLが書ける」ことと「ある銀行の本番COBOLを読める／書き直せる」ことの間には、深い断絶がある。AIが教科書COBOLを書けても、現場には届かない。
だから各社が「専用モデル」を訓練している
この3層の欠落を埋めに来ているのが、エンプラ各社が投入している専用モデルです。
| 企業・モデル | 特化領域 |
|---|---|
| IBM watsonx Code Assistant for Z | z/OS COBOLに特化。顧客の社内コードで追加学習し、方言対応 |
| 富士通 tsuzumi for COBOL（t4C） | 富士通方言COBOLを含む日本語業務ドメインに特化 |
| Google Mainframe Assistant（Gemini） | メインフレームコードに特化したモデル |
| NTTデータ tsuzumi for COBOL | 日本の金融系SI現場向け |
共通しているのは、「汎用Claude・GPTでは越えられない壁を、顧客の社内コードまで取り込んだファインチューニングで埋める」 というアプローチ。汎用LLMの知識量で押し切るのではなく、コーパスそのものを社内で作り直すという設計です。
裏を返せば、汎用LLMだけでCOBOL現場のDXは成立しない、ということがこの業界構造から見えてきます。
でも、AIは学習して成長する
ここまでの話だけ読むと、「AIは公開コーパスが薄い領域には永遠に届かない」と受け取れるかもしれません。でも、ここ1〜2年のベンチマーク推移を見ていると、その前提は怪しくなってきています。
AIの「学習データにない新しい課題を解く能力」を測る指標として、代表的なものをいくつか並べてみます。ざっくり言うと、どの指標も公開時は一桁〜十数パーセントだったのが、ここ1〜2年で数十パーセント台まで一気に切り上がっている、という傾向が共通して見られます。
| ベンチマーク | 概要 | 推移 |
|---|---|---|
| Humanity’s Last Exam (HLE) | 専門家が作った新規難問3,000問 | 公開時 GPT-4o で 2.7% → 2026年4月時点 GPT-5.4 で 41.6%（15ヶ月で10倍以上） |
| FrontierMath | 数学者が作った未発表級の難問 | 公開当初 <2% → 2026年3月時点 GPT-5.4 Pro で Tier 1-3 50%、Tier 4 38% |
| ARC-AGI-2 | 抽象推論、記憶では解けない設計 | 2025年 Kaggle最高 27.64% → 2026年初 Gemini 3 Pro + refinement loop の Poetiq で 54%（1年で約2倍） |
| METR | AIが自律的に完了できるタスク長さの倍加周期 | 7ヶ月（2019-2024）→ 4ヶ月（2024-2025）に加速 |
これらの指標が示しているのは、「コーパスがない新規タスクでも、AIは解けるようになってきている」 という事実です。推論時の工夫（Chain-of-Thought、refinement loop、エージェントループ）、RAG、ドメイン特化の追加学習—手段は色々ですが、要は 「学習データの壁を、推論側や訓練側で埋められる」 構造が実証されてきています。
ただし、素直に「もう全部解ける」わけでもありません。ARC-AGI-3（2026年3月公開）のように、「新しく設計された、学習データには絶対に入っていない問題」に対しては、フロンティアAIでも正答率 0.26%という現実もあります。人間の正答率は100%。
つまり現在地は、「AIの弱点は消えないが、時間とともに切り上げられ続けている」。これが、専用モデル投資の話に繋がります。
専用モデル投資の正体
こう見ると、IBMや富士通やGoogleがやっている専用モデル投資は、単なる「汎用LLMの穴埋め」ではないのかもしれません。
構造を整理すると、こうなります。
– 汎用LLMも、時間をかければコーパスが薄い領域に対応するようになる（ベンチマーク史が示唆）
– ただし「時間」がどれくらいかは読めない。2年かも、5年かもしれない
– 金融・保険・政府の本番COBOLを抱える組織にとって、その待ち時間は経営リスク
– だから顧客コードを使ったファインチューニングで「時間を買う」
つまり専用モデル投資は、汎用LLMが将来自然に到達するであろう能力を、数年分前倒しで手に入れる戦略投資と捉えると筋が通ります。コーパス不足は放置すれば永遠の壁ではなく、誰かがお金と顧客データを入れれば崩せる壁。問題は「待つか、買うか」の選択にある、ということです。
まとめ: 「AIは古いものが好き」は、たぶん期限付き
– 「AIは古いものが好き」は 半分真実、半分誤解
– 現時点の本質は 「仕様の安定性 × 公開コーパス量」の2条件
– Java 8・jQuery は両方満たす → AIが強い
– COBOL・RPG は仕様は安定しているがコーパスが極小 → AIが弱い
– 最新ライブラリは両方不足 → AIが弱い
– ただし、新規課題を解く能力そのものはベンチマーク上で切り上げられ続けている（HLE 15ヶ月で10倍、ARC-AGI-2 一年で倍）
– 各社の専用モデル投資は、この成長曲線を数年分前倒しする「時間を買う」投資
この全体像から言えるのは、「今のAIは○○が苦手だから××できない」という前提で組まれた経営判断や見積もりは、2〜3年スパンで陳腐化するリスクが高い、ということです。逆に言えば、「今できないこと」を見て投資を見送る組織と、「数年後にできる前提」で手を動かし始める組織の差は、このあと大きく開いていく気がしています。
「AIは古いものが好き」というキャッチコピーは、2026年春時点のスナップショットとしては正しい。でも期限付きの真実です。
SIの見積もりがこの変化でどう壊れていくのかは、近々調べてみて気が向いたら別のジャーナルで書く予定です。
FAQ
AIはなぜCOBOLが苦手なのですか？
COBOL自体の仕様は安定していますが、GitHub等に公開されているCOBOLコードが極端に少ないためです。推計で84リポジトリ・4GB程度しか公開コーパスがなく、JavaやPythonの1万分の1以下。さらに銀行・保険・政府の本番COBOLはすべてプライベートで、学習データには流れ込んでいません。
では各社のCOBOL向けAI製品は何をしているのですか？
IBM watsonx、富士通 tsuzumi、Google Mainframe Assistantなどは、汎用LLMの上に 顧客の社内COBOLコードを追加学習 させることで、汎用では届かない方言・独自拡張をカバーしています。要は「コーパスそのものを作り直す」アプローチです。
jQueryやJava 8がAIで簡単に扱えるなら、SIの既存案件はどうなりますか？
短期的には「AIで工数が圧縮できる既存資産のモダナイゼーション」が巨大市場になっています。長期的には、見積もりの前提が変わります。「3人月」の根拠を発注側が問い始めると、従来の人月単価ビジネスのモデル自体が成り立たなくなる可能性があります。
汎用LLMだけで古い技術のリファクタリングを試してもよいですか？
Java 8 → 17 のような「仕様も公開コーパスも揃っている」領域なら、汎用LLMでもかなり戦えます。一方、本番COBOL、方言の強いレガシー、ドキュメントが外に出ていない商用製品は、汎用LLMで進めるとハルシネーションや非慣用コードが混入しやすいので、専用ツールの採用を検討する領域です。
参考ソース
– AWS “Transforming a legacy Java application using Amazon Q Developer”
– 富士通 “Application Transform” プレスリリース（2026年3月）
– 日立製作所 COBOL資産近代化サービス
– COBOLEvalベンチマーク論文 – bloop.ai
– IT Jungle “Fresche Rolls Out AI-Infused Development Platform”
– MarketsandMarkets “Application Modernization Services Market”
– W3Techs “Usage Statistics of JavaScript Libraries”
– The Stack v2 – BigCode Project
この記事が参考になったら
Share