IBMの株価を急落させたClaude Codeが激変させたCOBOLのリプレイス（モダナイゼーション）とは

AIによるCOBOLのモダナイゼーション──Anthropicの主張とIBMの反論

Anthropic: 「理解コスト」の壁をAIが壊す / IBM: 価値はコードではなくプラットフォームにある

COBOLは米国ATM取引の推定95%を処理し、数千億行が本番稼働中です。しかし理解できる人材は退職し、ドキュメントは実態と乖離しています。従来はコンサルタントの大軍が何年もかけてワークフローをマッピングしていました。この「理解コスト」こそが、COBOLモダナイゼーションの最大の障壁だったと言えます。

Anthropicの主張はシンプルです。Claude Codeがコードベース全体を自律的に探索・分析し、年単位の作業を四半期単位に短縮できる、というものです。

これに対し、IBMのRob Thomasが即座に反論しました。メインフレームの価値はCOBOLではなくプラットフォーム（z/OS垂直統合スタック）にある。データ移行、業務プロセス再設計、テスト、運用体制まで含めれば、コード変換だけでは終わらない──そう主張しています。

Anthropic: 狙いは「全自動リプレイス」ではなく「分析作業の自動化」

ここで見落とされがちな点があります。Anthropicは実はブログの中で「人間の判断が不可欠」と繰り返し強調していました。

狙いは「全自動リプレイス」ではありません。コンサルタントの大軍が何年もかけていた分析作業の自動化です。モダナイゼーションの「全部」ではなく、「最もコストがかかる初期フェーズ」を変えるという話になります。

4フェーズ（自動探索→リスク分析→戦略計画→段階的実装）のうち、第3フェーズの戦略計画は人間が担うと明記されています。つまりAnthropicは最初から、AIが全部やるとは一言も言っていません。

IBM反論: そもそも議論の前提が異なる

IBMの反論はさらに踏み込んだものでした。COBOLの約40%はメインフレーム以外で稼働しており、AI×COBOLの議論とメインフレームの議論が混同されている、と指摘しています。メインフレーム事業の価値は数十年のハードウェア・ソフトウェア統合にあり、コード変換では複製できない。この指摘には説得力があります。

ただし、そもそもAnthropicのブログにはIBMのメインフレームへの直接的な言及が一切ありません。COBOL一般の話として書かれています。つまり、IBMは「自社のメインフレームは安泰だ」と言い、Anthropicは「COBOLの理解コストをAIで下げる」と言っている。両者は、そもそも違う土俵で話をしているようにも言えます。

それでも市場は売った──sell first, ask questions later

しかし、その両社の論点のすれ違いは、市場にとっては関係がありませんでした。

IBMの収益構造──ハードウェア販売、保守契約、コンサルティング──がまるごと脅かされるという懸念が走りました。IBMの株価は1月中旬からすでに下落トレンドにありましたが、2月23日のブログが「決定打」を加えた形です。

Wedbushは過剰反応と評価しましたが、動揺はTCS、Infosys、WiproなどインドIT大手にも波及しました。市場がこれほど激しく動いたこと自体が、COBOLモダナイゼーションという領域のインパクトの大きさを物語っているのではないでしょうか。

現状のAIによる仕様理解はどこまで可能なのか

Anthropicが公式に示したCOBOLモダナイゼーションのデモ

あまり語られてはいませんが、Anthropicは2025年12月に自社の公式YouTubeで「Claude Code modernizes a legacy COBOL codebase」を公開しています（YouTube動画）。つまりAnthropicは2026年2月のブログで突然COBOLに言及したわけではなく、少なくとも2025年末からこのテーマを発信してきています。

この動画で、Claude Codeがレガシーなメインフレームのコードベースをどのように解析・モダナイズするかの実演をみることができます。

COBOLよりも難しい条件で検証した実例

Anthropicのデモだけでは実用性に疑問を持つ方もいらっしゃるかもしれません。そこで、あえてCOBOLよりも難しい条件で検証した当社の実例をご紹介します。

検証に使ったのはIBM i RPG3言語です。COBOLはGitHub上に大量のサンプルがあり、LLMの学習データとしても豊富にあります。RPG3はそうではありません。より難易度が高いRPG3で「どこまでできるか」がわかれば、COBOLに対しても説得力が増すと考えました。

GitHubの公開RPGプログラムをClaude Codeに読み込ませて検証した結果は、noteの記事「AIはAS/400 (IBM i) RPG言語を理解して仕様書を書けるのか？」にまとめています。COBOLよりも学習データが少ない言語で、実用十分な精度が得られています。COBOLであれば、さらに高い精度が期待できるのではないでしょうか。

いまAIにできること、見えてきた可能性

できること──仕様理解の自動化

AnthropicのデモとRPG3での検証が示したのは、AIがレガシーコードを自律的に探索し、業務ロジックを抽出して仕様書レベルのドキュメントを生成できるという事実です。COBOLよりも学習データが少ないRPG3でも実用精度が得られており、COBOL対応ではさらに高い精度が見込めます。

見えてきた可能性──仕様理解の先にあるもの

仕様が読み解ければ、次はプログラムの生成です。いま「vibe coding」と呼ばれるAI主導のコード生成が急速に広がっています。プログラミング経験のない個人が、AIとの対話だけで複雑なiPhoneアプリを開発し、App Storeでリリースする事例が次々と生まれています。新規開発ですらこの状況です。仕様が明確になった既存システムのコード変換であれば、AIにとってはさらに取り組みやすい領域といえるのではないでしょうか。

テストケースの自動生成やデータ移行計画の策定支援も、仕様理解という土台があって初めて現実味を帯びる領域です。一方で、業務プロセスの再設計や移行の最終判断は依然として人間の領域ですが、そもそも仕様がわからないから検討すら始められなかったという膠着状態に、確実に突破口が開きつつあります。

AIの導入は「するかしないか」ではなく「いつ始めるか」

IBM株急落は、AIがレガシーシステムのモダナイゼーション市場を構造的に変え始めたことを示す象徴的な出来事でした。

「コード変換＝モダナイゼーション」ではありません。IBMの指摘は正しいと考えています。一方で、最大のボトルネックだった「理解コスト」が下がりつつあるのも事実です。

もちろん、AIにも限界はあります。データ移行や業務プロセスの再設計は、依然として人間の判断が必要な領域です。しかし、仕様理解という最初のハードルが下がることで、これまで動けなかった現場が一歩を踏み出せるようになるかもしれません。

「AIを使うべきかどうか」という問いよりも、「いつ、どのように始めるか」を考える段階に来ているのかもしれません。