見出し画像

IBM Bob で COBOL の設計書を作ってみた ― レガシー分析を支援する生成 AI の使いどころ

※本記事の内容は LinkedIn にも投稿しています。 LinkedIn では実務視点での気づきを中心に、本記事では 技術的な背景や検証の狙い、実装イメージを補足しています。

IBM BobでCOBOLの設計書を作ってみた

背景(Why)

最近担当している案件で、基幹システムに残っている COBOL バッチ処理を短期間で把握・分析する必要が出てきました。

よくある話ですが、

  • 設計書は古い/存在しない

  • 実際の仕様はコードを読まないと分からない

  • しかし、COBOL が読める人は限られている

という状況です。

正直に言うと、私は COBOL をほとんど読めません
かといって、都度 CO​​BOL 有識者をアサインして詳細調査を依頼すると、それなりの時間とコストがかかります。

そこで、

IBM Bob を使えば、COBOL を深く知らなくても
「分析に必要な情報」を整理できるのではないか?

という仮説を立て、軽い技術検証として試してみました。


検証内容(What / How)

使用した COBOL コード

今回は、業務コードではなく 公開されているサンプルコードを使用しています。

  • 銀行システム向け COBOL サンプル(約 1,500 Step)
    https://github.com/Elyz04/SPD9999SET

GitHub からコード一式を取得し、そのまま IBM Bob に読み込ませました。


Bob に与えた指示

指示は非常にシンプルです。

このフォルダにある COBOL の設計書をマークダウンで作成

構成やフォーマットの細かい指定はせず、
「コードから設計情報を整理する」ことだけを意図として伝えています。


技術的なポイント(Key Findings)

1. 数分で「読むための設計書」が生成される

生成された設計書は、

  • プログラム構成の整理

  • 処理概要の要約

  • プログラム間の関連性

  • データ構造の説明(ER 図相当の情報)

といった内容が Markdown 形式で構造化されていました。

「正確性の保証が必要な正式ドキュメント」として使うにはレビューが前提ですが、
影響範囲を把握するための一次資料としては十分に実用的だと感じました。


2. レガシー言語でも「読解支援」として機能する

個人的に意外だったのは、

  • Java / Python のようなモダン言語だけでなく

  • COBOL というレガシー言語でも、構造を理解しようとするアウトプットが出てくる

点です。

「コードを完全に理解している」わけではありませんが、
人が理解するための足場を作ってくれるという意味では非常に価値があります。


3. 設計とコードの乖離問題へのアプローチ

レガシー案件ではよく、

「設計書と実装が合っていない」

という課題が挙げられます。

今回の検証を通じて、

  • コードを正とし、設計を再生成する

  • 設計書を「メンテナンス対象」から「生成物」に位置づけ直す

というアプローチは、今後現実的な選択肢になり得ると感じました。


人が判断すべき点 / AI に任せやすい点

人が判断すべきこと

  • 生成された設計書の妥当性・正確性

  • 業務仕様として採用してよいかの判断

  • 影響範囲の最終確認

  • 本番改修につなげてよいかどうか

特に COBOL 有識者のレビューは不可欠です。


AI に任せやすいこと

  • 大量コードの一次解析

  • プログラム構造の整理

  • 関連性の可視化

  • 「どこを重点的に人が見ればよいか」の当たり付け

AI は 判断の代替ではなく、判断材料の整理役として使うのが現実的だと感じました。


実務での使いどころ・注意点(So What)

使いどころ

  • 短期間での影響調査・現状把握

  • レガシー資産の棚卸し

  • モダナイゼーション前の事前分析

  • 「COBOL が読めないメンバー」が全体像を掴むための補助


注意点

  • 生成結果をそのまま鵜呑みにしない

  • 正式成果物として使う場合は必ずレビューを入れる

  • 業務知識・暗黙知まではカバーできない前提で使う


次に試してみたいこと

今回の手応えを踏まえ、次は以下を検証したいと考えています。

  • GnuCOBOL を使った修正・テスト支援

  • COBOL → Java へのポーティング支援

  • 旧 COBOL と新 Java 実装の差分比較(設計・処理フロー)

レガシー領域でも、生成 AI が 「使えるフェーズ」に入りつつあることを実感しています。


まとめ

IBM Bob を使った今回の検証から得られた示唆はシンプルです。

  • AI は「COBOL を理解する代わり」にはならない

  • しかし 「人が理解するための入口」を作る力は非常に強い

  • レガシー分析の初動コストを大きく下げられる

IT 開発・設計に携わる立場として、
AI をどう置き換えるかではなく、どこを補助させるかを考えることが重要だと改めて感じました。


English follow

Summary for global readers

This article shares an experiment using IBM Bob to generate design documentation from COBOL source code.

The goal was not to fully automate understanding of legacy systems, but to support engineers—especially those unfamiliar with COBOL—in quickly grasping system structure and impact areas.

The key takeaway is that AI works best as an analysis assistant:
it organizes code, highlights structure, and helps humans focus their judgment where it matters most—while final validation and responsibility remain with engineers.


1. 指示したプロンプト
2. IBM Bobのタスク完了画面
3. 設計書の抜粋 - 目次
4. 設計書の抜粋 - プログラム構成
5. 設計書の抜粋 - データベース設計
6. 設計書の抜粋 - ER図
7. 設計書の抜粋 - 詳細設計
8. 設計書の抜粋 - 処理フロー


いいなと思ったら応援しよう!