IBMが組み込んだClaude、IBMを撃つ ── メインフレーム・モダナイゼーションは誰にも解けない

IBM株、一夜にして13%急落

2026年2月23日、IBM株が13%急落しました。 2000年10月以来、最大の下落幅です。

きっかけはAnthropicが公開したブログ記事 「How AI helps break the cost barrier to COBOL modernization」でした。 Claude Codeを使えば、 COBOLレガシーシステムの モダナイゼーションにおける 調査・分析作業を大幅に短縮できる という内容です。 従来は人間のアナリストが数か月かけていた 依存関係のマッピングやワークフローの文書化を、 AIが高速に処理できると主張しています。

日本の金融機関などはまだまだ メインフレームが残っていますが、 米国でも似たような状況のようです。 Anthropicのブログによれば 毎日数千億行のCOBOLが 本番環境で稼働しているそうです。

IBM Architecture Collectionなどを見ても、 IBMはメインフレーム （彼らは「IBM Z」と呼びますが）を 捨てたわけではありません。 また、メインフレームと メインフレーム・モダナイゼーションの コンサルティングも IBMの主要事業の1つです。 投資家はこの市場がAIによって ディスラプトされることを懸念しました。

ここまでなら「AIベンチャーが大手の牙城を脅かす」 というよくある構図です。 しかし今回の話には、もう一層の皮肉があります。

IBM自身が開発中のAIエージェント 「Project Bob」（以下「IBM Bob」）は、 AnthropicのClaudeをマルチモデル構成の 中核として採用しているのです。 自社のメインフレーム・モダナイゼーション ツールに組み込んだ相手のAIが、 自社の株価を叩き落とすという構図。 元IBM社員として、 複雑な感慨を覚えました。

Watson時代を知る者として

私がIBMに在籍していた当時、 Watson一色の時代がありました。 社内のあらゆるプレゼンテーションに Watsonのロゴが入り、営業資料にはWatsonの 事例が並び、「Cognitive（コグニティブ）」 という言葉が社内の共通語のように 使われていました。

2011年のJeopardy!でWatsonが勝利したとき、

IBMは「AIの会社」として 華々しく旗を掲げていました。 あの頃の熱狂を思い出すと、 隔世の感があります。 しかし生成AI時代になって 主導権を握ったのは OpenAIやAnthropicであり、 IBMのwatsonxとGraniteモデルは、 エンタープライズの現場では 外部モデルに頼る結果となりました。

IBM Bobが利用するAIモデルは Claude、Mistral、Graniteなど 複数で構成されており、 タスクに応じて自動振り分けされます。 watsonxというプラットフォームと Graniteという自社モデルを 持っていながら、 それだけでは最前線で戦えない。 この現実には、 やはり複雑なものを感じます。

ただし、これを単なる敗北と 読むべきではないとも思います。 IBMの強みは「AIモデルそのもの」ではなく、 エンタープライズ向けのガバナンス、 ハイブリッド環境への対応力、 そして仕様駆動開発という メソドロジーの側にあります。 モデルは最良のものを 外から持ってきて、 インテグレーションとガバナンスの レイヤーで勝負する。 これは割り切った戦略転換であり、 むしろ合理的な判断だと考えています。

IBM Bobの仕様駆動アプローチ

IBM Bobは汎用的なAI駆動開発ツールであり、 新規開発からフレームワーク移行、 セキュリティ修正まで幅広く対応します。 IBMが特に注力するのは 「仕様駆動開発」です。 AIにコードをいきなり書かせるのではなく、 まず仕様を文書化して唯一の基準とし、 AIが仕様に基づいてコードやテストケースを 生成する方式です。 いわゆるバイブコーディングとは 対極の設計思想にあります。

IBM社内では10,000人超の開発者が Bobを活用し、 平均45%の生産性改善を 実現したとされています。 2027年以降は顧客プロジェクト全体で 工数35%削減・期間30%短縮を目標に 掲げています。

このアプローチ自体は筋が悪くありません。 特にエンタープライズの重要システムでは、 仕様なき生成は許されないため、 仕様駆動という思想は理にかなっています。 しかしこの「45%の改善」という数字は、 仕様が明確に存在する前提での話です。 メインフレーム・モダナイゼーションの 現場で何が起きているかというと、 その前提自体が成り立ちません。

仕様書は残っていないケースが大半です。 コードを書いた人はとうに退職しています。 コード自体が唯一の仕様書であり、 しかもそのコードの意味を 正確に理解できる人間が もういないのです。

IBM Bobが「AIでコードから 仕様を逆抽出する」ことを 目指しているのは理解できます。 しかし抽出された仕様が正しいかどうかを 検証する人間がいなければ、 それは推測の域を出ません。

AWSのBlu Ageはもっと危うい

メインフレーム・モダナイゼーションの 競合として、 AWSのBlu Ageにも触れておきます。 AWSはフランスのBlu Age社を買収し、 COBOLやPL/Iを自動的にJava/Spring Bootに 変換するソリューションを展開しています。 最新では「AWS Transform for mainframe」 というエージェント型AIサービスに 統合されました。

Transamericaでバッチ性能30%向上、 Vismaで年間コスト55%削減といった 実績が報告されており、 変換の自動化度は高いと言えます。

しかしこのアプローチには 構造的な弱点があります。 変換されたJavaコードは一見モダンですが、 Blu Ageの独自ランタイムライブラリが メインフレーム固有の機能を エミュレーションで提供しています。 COBOLのメモリレイアウト再現、 CICSトランザクション管理、 VSAMファイルアクセス、 JCLバッチ実行。 これらがすべて独自ランタイムに 依存しているため、 変換後のコードは純粋なJavaではありません。

つまり、メインフレームへの ベンダーロックインが、 AWSへのベンダーロックインに 置き換わっただけです。 確かにJavaコードになったことで ソースコードの可読性自体は向上し、 Java開発者による保守は可能になります。 しかし、ランタイム層の理解なしには 本質的な改修はできず、 「この処理は何をしているのか」が わからないという根本的な問題は 解消されていません。

個人的な評価としては、 仕様を基準に据えるIBMの方が まだましだと考えています。 少なくとも「何をしているのか」を 明らかにしようとする姿勢がある。 Blu Ageは「動けばいい」であり、 その先の保守性を 犠牲にしています。

誰も解けない本当の理由

Claude Code、IBM Bob、AWS Blu Age。 いずれのツールを使っても、 メインフレーム・モダナイゼーションの 本質的な問題は解けません。 なぜなら、これは技術の問題ではなく、 人と組織の問題だからです。

COBOLの基幹システムを書いた世代は 60代後半から70代で現役を退いています。 彼らが持っていたのは コーディングスキルだけではありません。 「この例外処理はあの税制改正で入れた」 「このフラグは特定の取引先との 契約条件で分岐する」 といった業務の文脈そのものでした。

AIがコードから仕様を 抽出できたとしましょう。 しかし、その仕様が正しいかどうかを 検証できる人間がいません。 ユーザー企業は情シス部門を縮小して ベンダーに丸投げしてきました。 SIer側は下請け構造の中で 業務知識が分散・属人化しました。 仕様を書いた人、コードを書いた人、 運用している人がバラバラで、 全体を通して理解している人が どこにもいない。

IBMが「経営層向けワークショップ」や 「成果コミット型パートナーシップ」を 打ち出しているのは、 この問題への間接的な回答です。 しかし結局のところ、 「御社の業務を一番わかっているのは 御社です」という当たり前の話に戻ります。 そしてその「御社」の中に、 もうわかる人がいないのです。

株価が映すもの

IBMの株価が一日で13%下がったことは、 市場がメインフレーム・モダナイゼーションの ディスラプトを織り込んだように見えます。 しかし実態はもう少し複雑です。

Claude Codeが得意なのは コードの探索と分析です。 数千行のCOBOLコードから 依存関係をマッピングし、 ワークフローを文書化し、 リスクを特定する。 これは確かに人間が数か月かけていた 作業を短縮できるでしょう。

しかし「分析できる」ことと 「移行できる」ことの間には、 深い溝があります。 コードの構造を理解することと、 そのコードが担っている 業務の意味を理解することは別物です。

AnthropicのCode Modernization Playbookは 優れた資料ですが、 あくまで「探索と分析のコスト障壁を 下げる」ことに焦点を当てています。 最終的に移行を完遂するには、 業務知識を持った人間の判断が不可欠です。 そしてその人間がいないことこそが、 メインフレーム・モダナイゼーションが 何十年も進まない理由なのです。

株価が映しているのは、 「AIがCOBOLを解決する」という 期待と恐怖です。 しかし現実には、 必要なのは業務知識の再構築への 地道な投資であり、 どんなに優秀なAIツールが登場しても、 その投資の代わりにはなりません。

IBM自身のツールにClaudeが 組み込まれているという事実は、 技術の世界に敵味方の区別がない ことを示しています。 本当の敵はツールの優劣ではなく、 長い年月をかけて失われた 業務知識という名の技術的負債です。 Anthropic、IBM、AWSのいずれであっても、 魔法のように解くことはできません。 それでも、この問題を直視し、 業務知識の再構築に地道に取り組む 組織だけが、次の時代のシステムを 手にするのだと思います。

References