COBOL資産からAIの知識ファイルを自動生成する ― CardDemoで検証した結果(30/30・正答率100%)

Posted at 2026-09-22

COBOL資産からAIの知識ファイルを自動生成する ― CardDemoで検証した結果(30/30・正答率100%)

はじめに

COBOLで書かれた基幹システムには、仕様書が存在しない、あるいは存在しても読解に専門知識が必要というケースが少なくありません。改修のたびに、現行ソースコードを読み解くところから始めることになり、これがレガシーマイグレーションの大きなコスト要因になっています。

今回、COBOLソースをAIで解析することで、自然言語でDBに照会できるAIシステム「ESI(Elementum Secure Insight)」用の知識ファイルを、追加のコード開発なしで自動生成できるかを検証しました。本記事はその結果のまとめです。

検証の様子は動画にもまとめています。

▶ https://youtu.be/FWBU9CT6drQ

検証の目的

COBOL基幹システムに対して、以下を仮説として検証しました。

COBOLソースをAIで構文解析すれば、業務ロジック・テーブル定義・コード値を自動で構造化できるのではないか
それができれば、追加のコード開発なしで、自然言語によるDB照会を実現できるのではないか

ESIとは

ESIは、SQLを知らない人でも日本語の質問だけで業務データを参照できるAIシステムです。中核となるのは2種類の知識ファイルです。

知識ファイル	内容
`matching.json`	テーブル・カラムの対応表。コード値の意味(例: `Y`=有効、`N`=無効)も含む
`business_rules.md`	業務ルールと計算ロジック

適用範囲はIBM i / Db2、PostgreSQL、Oracleなど、COBOL基幹システム全般です。仕様書が揃っていれば、5〜6週間程度で実用可能な状態を目指せます。

システム構成

検証したアーキテクチャは大きく2段階に分かれます。

① 知識ファイルの生成(一回限りのセットアップ)

COBOLソース (.cbl / .cpy / JCL / BMS)
        │
        ▼
   Claude Code による構文解析
   (業務ロジック抽出・依存関係マッピング)
        │
        ▼
   仕様書の自動生成 (Markdown, 日本語)
        │
        ▼
   2つの知識ファイル
   (matching.json / business_rules.md)

② 照会実行フロー

ユーザー(ブラウザ)
    │ 自然言語での質問
    ▼
ESI Flask API (NLPSQLEngine)
    │ 知識ファイルを参照してプロンプト構築
    ▼
Azure gpt-5.4-mini (AI Foundry, Japan East)
    │ SQL生成
    ▼
MCP Server (@modelcontextprotocol/server-postgres)
    │
    ▼
PostgreSQL (carddemoスキーマ: 口座・顧客・カード等)
    │ クエリ結果
    ▼
ESI Flask API → JSON整形 → ユーザーへ結果表示

安全面では、実行するのはSELECT文のみです。更新系のSQLは実行しません。知識ファイルを差し替えれば、別のアプリケーションにも同じ仕組みを展開できます。

検証環境 ― AWS CardDemo

検証には、AWS公式のメインフレームモダナイゼーション用サンプルアプリケーション「CardDemo」を使用しました。COBOL・JCL・CICS・BMS・Copybookが揃った、クレジットカード管理業務を模したアプリケーションです。

テーブル数: 10個
サンプルデータ: 口座・顧客・カード各50件
ESI側の実装: Flask (Python) + PostgreSQL
LLM: Azure gpt-5.4-mini

2つの知識ファイルは、このCardDemoのCOBOLソースから自動生成したものです。

知識ファイルの自動生成プロセス

Claude CodeがCOBOLソースを構文解析し、業務ロジックと依存関係を抽出して、プログラムごとに日本語の仕様書(Markdown)を生成します。それをmatching.jsonとbusiness_rules.mdに変換します。テーブル定義・コード値・業務ロジックを自動で構造化できることが、この検証の核心部分です。

整合性テスト結果

3つの業務質問について、10回ずつ・合計30回の自然言語照会テストを実施しました。単なる検索ではなく、いずれも業務ルールを適用しないと正しい答えにならない質問を選んでいます。

質問	内容	正答率
Q1	無効口座の取引転記判定 → バッチ(CBTRN02C)の業務ルールを適用した実データ抽出(正解16件)	10/10
Q2	与信グループ別の月次利息計算 → ZEROAPR(金利ゼログループ)除外ルールを適用した実額算出(上位5件の金額)	10/10
Q3	無効カードの取引転記判定 → Q1と同様のロジックを適用した実データ抽出(正解18件)	10/10

結果: 30/30、正答率100%、SQLエラー0件。

判定の厳しさについて

この検証で最もこだわったのは「判定の厳しさ」です。正解は、DB上で正しい判定式(当該サイクルのdebit・creditに取引金額を加算した値が与信限度額以内、かつ有効期限が取引日以降)から算出した取引IDと金額そのものです。AIが返した結果が、これと完全に一致した場合だけを正解としています。業務ルールを適用していないSQLや、値を定数で代替しただけのSQLは不正解として扱っています。

あわせて、テストデータには与信超過や期限切れのケースを意図的に混入させ、ルールの適用有無が結果件数の差として明確に表れるようにしています。

実環境への適用にあたっての考慮事項

100%という結果は、あくまでCardDemoという条件下のものです。実際の基幹システムでは、そのまま成立しない点があります。

今回の検証が成立した条件

COBOLソースとCopybookが揃っている
使用テーブルが4つと限定的
アセンブラの呼び出しやJCL変数への動的依存がない
SQLで直接参照できる標準的なテーブル構造

実際の基幹システムにありがちな追加要素

COBOLからアセンブラルーチンへのCALL(アセンブラ側のロジックは自動解析できない)
JCL SYMBOLや環境変数による動的制御
DBに存在せず、VSAMや区分データセット(PDS)上にのみ存在するコード値
数百〜数千テーブル規模の複雑なスキーマ

知識ファイルのカバレッジが、そのまま回答の適切さを左右します。ソースコード以外の資産も段階的に知識化していくことで、精度を上げていくアプローチが現実的です。

補足: 実案件(IBM i)での確認

今回の30/30・100%はCardDemoという公開サンプルでの検証結果ですが、同じ3つの知識ファイルの手法を、実際の顧客のIBM i基幹システムでも試しています。業務ルールを適用しない場合は50〜60%程度だった回答の適切性が、適用後には100%まで改善した実績があります。公開サンプルでの実証に加え、実案件でも同様の改善を確認しており、手法としての再現性が確認できています。

まとめ

今回実証したのは次の3点です。

COBOLソースから2つの知識ファイルを自動生成できたこと
DB上の正解データと完全一致する形で30/30を達成したこと
複数段階のSQL実行でもエラーがなかったこと

一方で、実システムではCOBOLソースだけでは100%に至らない場合があります。それでも、アセンブラ資産・環境変数・外部コード値まで段階的に知識として整備していくことで、実用に耐える回答の適切さを確保できると考えています。

「すべてのシステムで常に100%」とは言えませんが、知識ファイルを適切に整備することで、COBOL資産を起点とした、追加コード開発ゼロの自然言語照会を実用レベルで実現できることを、本検証で確認できました。

検証の詳細・実行画面のデモは、こちらの動画でもご覧いただけます。

▶ https://youtu.be/FWBU9CT6drQ

タグ案: COBOL レガシーマイグレーション IBMi AS400 生成AI ClaudeCode MCP 自然言語処理 PostgreSQL Azure

You get articles that match your needs
You can efficiently read back useful information
You can use dark theme

What you can do with signing up