AIを使ったCOBOLのJava変換、「百害あって一利なし」 AI活用の“落とし穴”を考察：SIerはどこから来て、どこへ行くのか

「AIがあればCOBOLをJavaに変換できる」という期待に対し、PM歴40年の筆者は「極めて安易で危険」と断じる。レガシーシステムの刷新プロジェクトにおけるAI活用に期待する筆者が、COBOLからJavaへの変換での利用に懸念を示す理由とは。

[室脇慶彦，SCSK株式会社]

この連載について

　ユーザー企業にとって、SIerはITシステムの導入から運用、故障時の対応や更新などに欠かせない存在です。

　しかし、その関係性はと言うと、対等なパートナーと言うよりも、ユーザー企業はSIerに対して丸投げしがちで、SIerも「お客さまであるユーザー企業の要望は断りづらい」ために、ユーザー企業のITシステム全体の最適化よりも、その場その場のニーズへの対応を重視しがちな「御用聞き体質」が指摘されてきました。

　こうした中、DX案件の増加やIT人材の慢性的な不足、ユーザー企業の内製化志向などのさまざまな環境変化によって、ユーザー企業とSIerとの関係は変わらざるを得なくなりつつあります。

　この連載を通じて、SIビジネスを取り巻く構造的な問題を掘り下げ、ユーザー企業とSIerが目指すべき関係の在り方を探っていきます。

　前回は、2026年2月に起きたソフトウェア株急落のきっかけとされる2つの見方のうち、「AIエージェントの普及でSaaSが衰退する」という“SaaSの死”を巡る見立てを取り上げた。SaaSがユーザー企業に提供する3つの価値はAIエージェント時代にも目減りしない、というのが筆者が出した結論だ。

　今回は、もう一つの見方である「AIがあればCOBOLで書かれたレガシーシステムをJavaなどに自動変換できる」という期待について考察する。この期待が市場に広がるきっかけとなったのが、2026年2月23日（現地時間）に米Anthropic社が公開したブログ記事だ。同社はAIコーディングツール「Claude Code」を使えば、COBOLで構築されたシステムのモダナイゼーションを支援できると説明した。市場はこれを、レガシーシステムの保守と刷新を主力事業とするIBMへの直接的な脅威と受け止め、IBM株は同日13％超下落した（注1）。1日の下落率としては2000年以来の大きさだった。

　COBOL技術者の減少に悩む日本企業にとっても、「AIが自動で変換してくれる」というシナリオは魅力的に響くだろう。しかし、老朽化したITシステムを多数抱える日本企業の場合、COBOLのロジックをそのままJavaに置き換える「単純な変換」は極めて安易で危険な方法だと筆者は考えている。

　なぜ危険なのか。筆者自身が目にした、あるコンバージョンプロジェクトの結末から考察し、概要設計フェーズの本題である業務フローに言及したい。

COBOLのロジックをそのままJavaへ　あるコンバージョンプロジェクトの結末

　筆者はかつて、他のプロジェクトをレビューした際に、COBOLからJavaへのコンバージョンプロジェクトを目にしたことがある。筆者自身が率いたプロジェクトではないが、その結末はよく覚えている。

　このプロジェクトの最大の問題は、COBOLのロジックをそのままJavaで作り直したことだった。しかも対象には、Javaが苦手とするバッチシステムが多く含まれていた。

　そもそもCOBOLは手続き型の言語で、現状の手作業をITシステム化するには極めて優秀な言語だ。COBOLは、プログラム冒頭の「DATA DIVISION」（データ部）と呼ばれる区分で扱うデータを最初に定義する。COBOLで扱うデータのまとまりは「レコード」と呼ばれ、多くのデータ項目から構成されている。データ部では個々のデータ項目について、データの長さ（必要な情報量）、種類（テキストか数値かなど）、項目名、位置を定義する。

　簡単に言えば、手作業で使っていた伝票や大福帳の代わりだ。伝票がトランザクションファイル（日々発生する取引データ）であり、大福帳がマスターファイル（データベース）に当たる。当時はマスターファイルをバッチで更新するのが主流だった。

　いずれにしても、COBOLは手作業をITシステム化するには極めて重宝する言語だったが、Javaのようなオブジェクト指向言語とはそもそも設計思想が全く異なる。そのため、Javaを手続き型のCOBOLのように使うのは極めて効率が悪い。そもそもJavaは、バッチシステムへの適用を想定していない。

再構築したにもかかわらず、跳ね上がった維持コスト

　該当プロジェクトは、COBOLに無理やり合わせてJavaで作ったことで想定規模より大きくなり、難航した。一番の問題は複雑度が増し、保守の生産性が大きく損なわれたことにある。再構築したにもかかわらず維持コストが跳ね上がり、当然、対応までの時間も長期化した。JavaでCOBOLを再現したためにCOBOL以上にステップ数が増え、複雑度もさらに大きくなった。まさに「百害あって一利なし」である。

　こうしたケースに対し、「COBOL技術者がいないのだから仕方ない」という声もある。しかし、COBOL自体は自然言語に近く、理解しやすい言語だ。学習すればすぐに習得できる。ところが出来上がったJavaは、言語のプロでも理解しがたいものになっていた。

　例えるのであれば、これは「日本語で書かれた、極めて難解な文書を理解できるか」という問題に近い。

　法律文書や保険契約の約款など専門性が高い文書は、普通の日本人にはなかなか理解できない。専門性が求められない文書であっても、「そうではなく、かつその反対で、さらにその反対……」といったこんがらがった文章であれば、やはり理解しがたい。

　老朽化したITシステムのプログラムはこんがらがっているだけでなく、使われていない、意味のないコードが散在している。そのため、一見矛盾している処理が多く含まれている可能性が大きい。

　昔、筆者の同僚で面白い人がいた。彼が普段日本語でしゃべっているときは、何を言っているのか理解するのが難しいのだが、外国人に向けて英語で説明しているのを聞くと、英語に堪能ではない筆者にも理解できる。彼の日本語より英語の方が分かるのだ。英語は主語を明確にせざるを得ないため、話が分かりやすくなる。すなわち、彼の日本語はいつも主語がはっきりしないのだ。

　自然言語と同じく、プログラミング言語にもそれぞれ得手不得手があり、それはその時代に主流となっている技術によって自然と規定されていく。メインフレームが主流だった当時はバッチ処理が中心であり、COBOLが言語として優れていたということだ。

変換によって先送りされる「負債」

　だからこそ、既存システムが前提とする技術のまま言語だけを単純に翻訳することは、極めて危険な作業だと認識する必要がある。そもそも現状の老朽化したシステムは、個別最適な修正を重ねたために複雑度が高まっており、そのためにさまざまな問題や課題が発生している。そのままのロジックを全て持っていくことは、現状の問題を先送りにしているにすぎない。さらに、Java本来の活用をせずにJavaに置き換えることで、複雑度はさらに増す。

　すなわち、開発を終了した時点で現状よりさらに技術的負債化が進み、ITシステムの寿命が限界に達するのではないかというのが筆者の見立てだ。

　AIを活用したCOBOLの翻訳は、技術的には可能だろう。だが、適切でないAI活用が、適切でない状況を生むのは当然だ。AIは魔法の杖ではなく、あくまで技術であり、活用方法を間違えれば良い結果が出ないのは当たり前である。

　過去にも、本来使える技術を、使用するための制約条件を無視して活用したために失敗し、その責任を技術の問題にした例があった。AIがそのような評価を得ないことを心から望む。

　「ITシステムは思ったようには動かない。作ったようにしか動かない」のだ。だから、われわれは正しく作るほかない。どうやって正しく作るかが技術者の基本であり、外してはいけない原理原則だ。AI適用を巡る最近の過熱ぶりは、少々違った方向に向かっているように思う。この辺りについては、今後またお話しすることにしたい。

本題：概要設計の「業務フロー」はどこまで使えるか

　ここで本題に戻る。第14回では、概要設計フェーズで最も重要な設計情報として、業務フロー、画面遷移図、状態遷移図、データフローダイアグラム（DFD）の4つの形態を挙げた。今回から、マイクロサービスアーキテクチャ（MSA）を意識しつつ、これらを順に取り上げていく。まずは業務フローだ。

業務フローが向く業務、画面遷移図が向く業務

　業務フローは、業務処理が順番に実行されることを前提にしている。一般的には社内の事務処理が対象だ。一般の人がWebサイトにアクセスして会員登録をするといった用途のITシステムに、業務フローは適用できない。Webサイトにアクセスする人は、途中で操作を取りやめたり商品情報など他の情報を参照したり、場合によっては前の画面に戻ったりと、操作の順番が一定していないからだ。従ってWebサイトの場合は画面遷移図を作成すべきだ。ただ、Webサイトといっても社内の従業員向けで業務処理が一定方向に進むのであれば、業務フローを作成すべきである。第14回では画面遷移図を「Web型に適する」と整理した。ただしより正確には、Webかどうかといった利用技術ではなく、対象のITシステムの業務処理内容（処理の順序が一定かどうか）で表現方法を規定することが重要だ。

MSAでは記述ルールを事例から整理する

　MSを前提とすると、おそらく業務フロー作成の時点から、幾つかの処理パターンごとに記述方式が規定される可能性がある。例えば、内部・外部のサービスを利用する場合は形態ごとにAPI接続が想定されるので、API接続によって情報を取得するステップが入る可能性がある。また、新規会員登録などでは、顧客名、住所、電話番号などのデータがさまざまなマイクロサービスに隠ぺいされているため、データベースを更新する記述は大きく変わらざるを得ない。具体的な事例に適用しながら、どのような記述ルールにするのが最適なのかを整理していく必要がある。

　まずは既存の業務フローの記法で書いてみて、業務一つ一つの記述方式を見直し、具体的に整理していくことが重要だ。いずれにしても、具体的な記述を重ねるうちに自然と処理パターンが整理される。それを標準化につなげることが肝要だ。

設計情報は「データ化」する

　同時に、設計情報をデータ化することが非常に重要だ。設計情報をデータ化すれば、次工程の設計情報の一部をAIで作成することが可能になり、生産性と品質の向上に大いに役立つ。工程間の設計情報の矛盾点も確認できるようになるので、保守フェーズも含めて設計情報の品質向上につながる。

　ただし、工程ごとの設計情報は、記述する内容も粒度も量も異なる。上流の一つの記述が下流の複数の記述に展開されるように、工程間の設計情報は一対一では対応せず、工程が進むことに追加で情報が増加することになる。すなわち、情報量と内容が工程ごとに異なるのである。そのため、リアルタイムで整合性を取るべきではない。月に一度程度、あるいは必要な時点で整合性を確認すれば十分だ。

　逆に、次工程の成果物を全て自動生成しようとすることは、極めて危険である。トヨタの生産方式でいうところの半自動化という概念が重要だ。自動化と手作業の最適化が重要なのである。将来、業務知識・ITシステムの極めて優れた整合性の取れた知識を備えたAIが生まれれば可能になると思われる。しかし、誰がどのようにAIに知識を提供できるかが、最も大きな障害と現時点ではなっていると思う。

　また、標準化を推し進めるためには、設計情報の作成をツールなどの仕組みで実施することが必要だ。これにより、自然に標準化ルールが徹底されると同時に、設計情報のデータ化（リポジトリ化）を進めることが可能になる。

次回予告

　今回は、AIによるCOBOLからJavaへの単純な変換がなぜ危険なのかを、筆者がレビューしたプロジェクトの結末から論じ、概要設計フェーズの業務フローについて考察した。

　次回は、画面遷移図についてお話ししようと思う。

（注1）Claude Codeの新たな用途をアンソロピックが説明した直後、IBM株が暴落（Business Insider Japan）

著者紹介：室脇慶彦（SCSK顧問）

むろわき　よしひこ：大阪大学基礎工学部卒。野村コンピュータシステム（現野村総合研究所）執行役員金融システム事業本部副本部長等を経て常務執行役員品質・生産革新本部長、理事。独立行政法人　情報処理推進機構　参与。2019年より現職。専門はITプロジェクトマネジメント、IT生産技術、年金制度など。総務省・経産省・内閣府の各種委員等、情報サービス産業協会理事等歴任。著書に『SIer企業の進む道』（日経BP）、『プロフェッショナルPMの神髄』（日経BP）など。