RPGのソースが読めない問題を、AIはどこまで解決できるか

RPGのソースコードが読めない問題は、AIで「1本ずつ読んで日本語で説明する」ところまでは大きく改善できます。

ただし、システム全体の仕様をつかむには、AIだけでは足りません。

呼び出し関係の機械的な集計と、現場での確認を組み合わせる必要があります。

この記事では、AS/400（IBM i）のRPG資産を例に、AIに任せられる範囲と、資産全体を見える化する進め方を整理します。

「このプログラムが何をしているか、誰も説明できない」。

IBM i を長く使っている企業では、珍しくない状況です。

RPGが読めなくなる理由は、言語の特徴と、組織の事情の両方にあります。

• 桁の位置で意味が決まる固定形式：RPGⅢでは、何桁目に何を書くかで命令の意味が決まります。慣れていない人には、記号の羅列に見えます。
• RPGⅢとILE RPGの混在：同じシステムの中に、年代の違う書き方が混ざっています。改修のたびに書き方が変わり、読み手の負担が増えます。
• 処理が複数のメンバーに分かれている：/COPY（共通部品の取り込み）やCALL（別プログラムの呼び出し）で、1つの業務が多くのソースコードにまたがります。1本だけ読んでも全体は分かりません。
• 設計書がない、または古い：改修を重ねるうちに、設計書とソースコードが一致しなくなっています。結局、ソースコードを読むしかありません。
• 書ける人の退職・高齢化：ソースコードを読める人が限られ、問い合わせや改修がその人に集中します。

RPGとはどんな言語か

RPGは、IBMが提供する業務アプリケーション向けのプログラミング言語です。

IBM i（旧AS/400）で、販売・在庫・会計などの基幹業務を作るために広く使われてきました。

帳票やファイル処理を少ない記述で書ける点が特徴です。

世代によって書き方が大きく異なるため、主な違いを表にまとめます。

完全フリー形式は、IBM i 7.1・7.2 向けのPTFで追加されました（出典：IBM「Fully free-form RPG - new in 7.1 and 7.2」https://www.ibm.com/support/pages/node/1108095 ）。

RPGは帳票やファイル処理を少ない記述で書ける一方で、ほかの言語にはない独自の仕組みがあります。

• インジケーター：*IN01〜*IN99 などの番号付きのスイッチで、処理の分岐や画面の制御を行います。番号だけでは意味が分かりません。
• ラベルとGOTO：TAG で付けたラベルへ GOTO で飛ぶ書き方が残っていて、処理の流れを追いにくくします。
• RPGサイクル：ファイルを1件ずつ読む繰り返しを、言語が裏側で自動的に行います。ソースコードに書かれていない処理があるため、流れが見えにくくなります。

これらは人にとっても、AIにとっても、処理の流れを正しく読み取る難しさにつながります。

IBM BobのPremium Package for i に、インジケーターやRPGサイクル専用のスキルが用意されているのも、そのためと考えられます。

AIは、RPGを「読む」作業の多くを肩代わりできます。

ただし、どの作業でも、最後に人が確認する工程は残ります。

作業ごとに、AIに任せられる範囲と、人が確認することを整理しました。

IBM BobでRPGを読ませた例

当社では、IBMが提供するAIコーディングエージェント「IBM Bob」で、RPGの解析を検証しました。

IBM Bobは、標準でもRPGやCOBOLのソースコードを読めます。

PCに保存したソースコードを読ませるだけなら、無料トライアルでも試せます。

当社の検証では、コメントをすべて除いたRPGⅢ 10本と関連するDDSの解析が約1分で終わりました。

仕様書とフローチャートの作成までを含めても、約5分でした。

詳しくは「【IBM i ×AI】40年前のRPGも5分で解析？「IBM Bob」の可能性と活用法」（https://blog.mono-x.com/ibm-i-rpg-analysis-with-ibm-bob ）で紹介しています。

さらに、IBM i 向けの追加パッケージ「IBM Bob Premium Package for i」を使うと、IBM i 上のソースコードをPCにコピーせず、そのまま読ませることができます。

IBM i 向けのモード・スキル・知識ベース（RAG：資料を検索して回答に生かす仕組み）により、RPG・CL・DDS・COBOLなどへの対応も強化されます。

Premium Package for i を使った検証では、次のような日本語の依頼だけで解析が進みました。

図：メンバー一覧と処理概要を依頼した結果

結果は次のとおりです。

• メンバー一覧が、説明と行数付きの表で返ってきました。
• 使用ファイルや処理の流れまで説明され、5250画面を開かずにソースコードの内容をつかめました。
• エディタで範囲を選んで「Explain Code」を実行すると、処理フローの図と解説も返ってきました。

図：Explain Code で返ってきた処理フローの図と解説

検証の詳細は「【第2部】IBM Bob Premium Package for i 導入ガイド｜動作確認編」（https://blog.mono-x.com/ibm-bob-premium-package-for-i-install-guide-2 ）で紹介しています。

導入の手順は「IBM Bobの始め方｜導入から最初のRPG解析までの手順」https://blog.mono-x.com/ibm-bob-setup-guideをご覧ください。

AIは1本のソースコードを読むのは得意です。

しかし、AIだけでシステム全体を理解できるわけではありません。

ここを押さえておかないと、AIの説明を過信して判断を誤ります。

• 数本のソースコードを貼るだけでは、全体は分からない：チャットAIに数ファイルを貼っても、CALL先・/COPYの中身・ファイル定義（DDS）がなければ、推測で補った説明になります。
• 件数や呼び出し関係は、ツールで機械的に集計する：プログラム数や、どのプログラムがどれを呼んでいるかは、ツールで正確に数えられます。AIの推測と事実を区別するため、集計はツールで行います。
• 業務上の意味は、現場へのヒアリングで補う：「このフラグが1なら返品扱い」といった業務の約束事は、ソースコードだけでは分からないことがあります。
• ソースコードを社外に出すときのルールと権限：クラウドのAIサービスにソースコードを送る場合は、社内の情報管理ルールに沿っているかを確認します。誰がどの範囲をAIに読ませてよいかも決めておきます。
• AIをつなぐのは検証用の環境から：AIに書き換えや実行まで任せる場合は、本番環境や日々の開発業務で使っている開発環境に直接つながず、検証用の環境を別に用意して試します。当社では、AIエージェントの検証を安全に行えるサンドボックス環境「PVS One for AIエージェント」を提供しています。

IBM Bobのような開発ツールは、1本ずつ読んで直す作業には強い道具です。

一方で、「資産全体で何本あり、どうつながっているか」を一度に描くことは、別の取り組みになります。

AIにRPGを読ませる方法は、大きく2つあります。

手元のPCにソースコードをコピーして読ませる方法と、IBM i 上のソースコードに直接アクセスできるツールを使う方法です。

QSYS（ライブラリの中のソースファイル）やIFS（IBM i 上のファイルシステム）に直接アクセスできれば、コピーの手間がなくなります。

一方で、数本を試すだけなら、汎用ツールで十分な場合もあります。

汎用ツールでも、MCPやJDBC・ODBCを使った外部ツールを利用するか、自社で仕組みを作り込めば、IBM i とつなぐことはできます。

ただし、つなぐ機能だけでなく、IBM Bobで提供されているような「ガードレールと監査」（変更を適用する前の承認や、監査への対応など）への考慮も必要です。

詳しい比較はまた後日ブログでご紹介したいと考えています。

1本のRPGを読めるようになっても、それは入口にすぎません。

数千本規模の資産全体をつかむには、順番が大切です。

次の5つのステップで進めます。

1. 棚卸し（件数の把握）：ソースメンバー・ファイル・画面の数を、ライブラリごとに数えます。
2. 呼び出し関係の集計：どのプログラムがどれを呼び、どのファイルを読み書きしているかを、ツールで機械的に集計します。
3. AIで各プログラムの説明と仕様書を作成：集計結果を前提に、1本ずつ説明と仕様書の下書きを作ります。
4. メニューフロー・業務フロー・ER図にまとめる：個々の説明をつなぎ、業務の流れとデータの関係を図にします。
5. 現場へのヒアリングで補正：図と説明を現場の担当者に見てもらい、業務上の意味を補います。

自社で進める場合は、集計ツールの準備と、AI・確認の段取りを自分たちで組む必要があります。

当社の「AI資産分析アセット」は、この流れをまとめて行うサービスです。

お預かりするのは、IBM i のソースコード（SAVF）と、貴社ホームページの情報、ヒアリングの内容の3つです。

当社のAI解析ツールで現行の業務システムを一括で解析します。

解析と分析の結果に加えて、見えてきた課題と改善の提案までをお届けします。