IBM BobによるRPG開発支援の検証

IBM BobはRPG開発をどこまで支援できるのか？ルールと自動チェックを組み合わせた検証

はじめに

「IBM i RiSING 2026」の活動の一環として、AI開発支援ツール「IBM Bob」（以下、Bob）を使ったRPG開発に取り組みました。

生成AIによる開発支援というと、仕様を伝えるだけで、すぐに利用できるプログラムが完成する姿を想像するかもしれません。しかし、IBM iの開発には、DDSの固定位置形式やファイル間の定義、コンパイル順序など、IBM i固有の制約があります。

Bobはこうした制約を踏まえ、RPG開発のどこまでを支援できるのでしょうか。

今回は受注管理システムを題材に、次の3段階で検証しました。

1. AIで作成した仕様書だけを渡してコードを生成する
2. 仕様書作成ルールと開発ルールを追加する
3. 生成したソースを機械的に確認するチェック用プログラムを利用する

検証から見えてきたのは、AIに正しいコードを書かせるには、プロンプトの工夫だけでは不十分だということです。

重要なのは、次の3つを組み合わせることです。

• 仕様書で「何を作るか」を明確にする
• ルールで「どのように作るか」を統一する
• チェック用プログラムで「基準を満たしているか」を確認する

本記事では、各段階でBobのコード生成がどのように変化したのかを紹介します。

---

Bobで生成したもの

検証対象は、受注管理システムです。
システムの仕様書をBobに読み込ませ、次の資産を生成しました。

• 物理ファイル
• 論理ファイル
• 画面ファイル
• RPGプログラム
• CLプログラム

Bobは仕様書の内容を解析し、データベースや画面の定義を含む、システムを構成する複数のソースをまとめて生成しました。

単一のプログラムではなく、システムを構成する複数のファイルを生成できた点は、今回の検証で確認できた大きな成果です。

一方、生成したソースをIBM iに配置してコンパイルすると、さまざまなエラーが発生しました。

そこで、エラーをその場で修正するだけでなく、原因を整理し、次のコード生成に反映しながら検証を進めました。

---

検証1：仕様書だけでコードを生成する

ルールを与えずに試す

最初の検証では、IBM i向けの開発ルールやコーディングルールを設定せず、受注管理システムの仕様書を添付し、Bobに次の指示を与えました。

IBM iのRPGプログラムを作りたい。
仕様書を参照して、プログラムソースを作成して。

この指示に対して、Bobは仕様書を解析し、複数のDDS、RPG、CLソースを生成しました。

仕様書から必要な資産を読み取り、システムを構成する複数種類のソースを生成できたことから、Bobがコード作成の初期段階を支援できることが確認できました。

しかし、生成したソースをそのままコンパイルすると、IBM i固有の記述形式に起因するエラーが発生しました。

発生したエラーの分類

エラーを整理すると、主に次の問題がありました。

• DDSの記述位置が正しくない
• DDSキーワードの記述順序が異なる
• フィールド名やファイル名が一致していない
• 桁数やデータ型が一致していない
• 入力項目や参照項目が不足している
• RPGとDDSの定義が一致していない
• コンパイル順序が考慮されていない
• ライブラリやソースファイルの配置が想定と異なる

特に問題となったのが、DDSの固定位置形式です。

DDSでは、内容が正しくても、開始位置や桁位置がずれているだけでコンパイルエラーになります。画面上では正しく見えていても、IBM iが解釈する位置と一致していないケースがありました。

つまり、プログラムとして意味が通ることと、IBM i上で正しくコンパイルできることは別の問題です。

Bobは仕様書から必要な処理を読み取ることはできましたが、IBM i固有の細かな制約を最初から安定して反映することはできませんでした。

エラーを一件ずつ修正する方法の限界

コンパイルエラーが発生した場合、エラーメッセージをBobに渡して修正を依頼できます。

しかし、この方法を繰り返すうちに、次の課題が見えてきました。

• 修正のたびに指示内容が変わる
• 以前修正した箇所が再び元に戻ることがある
• あるエラーを修正すると、別のエラーが発生する
• 同じ種類のエラーでも、修正方法が一定しない
• コンパイルとエラー結果の取得は人が行う必要がある

エラーが起きるたびに個別の指示を追加する方法では、修正内容が会話の流れに依存します。また、確認する人によってBobへの伝え方も変わるため、修正方法の標準化も困難です。

そこで、同じエラーを繰り返さないよう、検証1で発生したエラーをもとに、Bobが事前に参照するルールを整備しました。

---

検証2：仕様書作成ルールと開発ルールを与える

エラーを「次に生かせるルール」に変える

検証1で発生したエラーを確認すると、個々のプログラムロジックよりも、IBM i固有の形式やプロジェクトの前提条件が、Bobに十分伝わっていないことが主な原因でした。

例えば、DDSの記述位置や命名規則、ファイル間で統一すべき定義、ソースの生成順序などです。

これらを会話のたびに説明するのではなく、Bobが常に参照できるルールとして整理することにしました。

作成したのは、次の2種類です。

• 仕様書作成ルール
• 開発ルール

仕様書作成ルールは、コード生成に必要な情報を仕様書へ漏れなく記載するためのものです。

開発ルールは、Bobがソースを生成する際に守るべき記述方法や命名規則、IBM i固有の制約をまとめたものです。

実際のコンパイルエラーからルールを作る

チームで検証1の生成物をコンパイルし、発生したエラーとその原因を整理しました。

その内容をルール作成材料.xlsxにまとめ、Bobに添付して次のように指示しました。今回は、RPGプログラムをFFRPGで記述することを前提としています。

添付のコンパイルエラーの内容をもとに、
開発ルールと仕様書作成ルールを作成してください。

プログラムは、FFRPGで記述することを前提としてください。

参照ファイル：ルール作成材料.xlsx

実際に発生したエラーを材料とすることで、一般的な注意事項ではなく、今回の開発で必要となる具体的なルールを作成できました。

ルールによって改善したこと

ルールを設定したことで、Bobが守るべき前提条件を明示できるようになりました。

DDSの記述位置や命名規則、FFRPGでの記述、ソースの生成順序など、共通して守るべき内容を会話のたびに説明する必要がなくなりました。

また、修正時も担当者ごとに異なる言葉で説明するのではなく、ルールを共通の判断基準として利用できます。

このように、ルールにはコード生成の品質を高めるだけでなく、Bobへの指示方法を統一する効果もありました。

ルールを用意してもエラーはなくならない

一方、ルールの適用後も、コンパイルエラーが残るケースがありました。

ルールは自然言語で記述されているため、その解釈や生成コードへの反映はBobの判断に依存します。

また、エラーが発生した際に、Bobが原因を特定できないこともありました。

ルールは「正しい書き方」を伝えるためには有効です。しかし、生成されたソースが本当にルールを満たしているかを保証するものではありません。

そこで次の検証では、自然言語のルールを参照させるだけでなく、生成したソースをプログラムで機械的に確認する仕組みを追加しました。

---

検証3：生成したソースをプログラムでチェックする

Bobの判断だけに依存しない仕組みを作る

検証2では、仕様書作成ルールと開発ルールをBobに与え、ルールを参照しながらソースを生成させました。

しかし、Bobがルールを理解することと、生成したソースが実際にルールを満たしていることは別の問題です。

そこで検証3では、生成したソースをIBM iに配置する前に、形式上の問題を機械的に確認するコンパイル前チェック用プログラムを用意しました。

Bobから実行できるようにしたのが、Python版のibmi_lint.py、PowerShell版のibmi_lint.psです。利用環境に応じて、いずれかのチェック用プログラムを使用できます。

どちらもBobが生成したソースをチェックし、検出した問題を実行結果として返します。Bobはその結果をもとにソースを修正し、再度チェックを実行します。

Bobへの指示を統一する

検証3では、Bobへの指示を次のように統一しました。

ソースを生成した後、利用環境に応じて
ibmi_lint.pyまたはibmi_lint.psを実行し、
コンパイル前チェックを行ってください。

エラーが検出された場合は、
チェック結果をもとにソースを修正してください。

修正後は再度チェック用プログラムを実行し、
エラーが解消されていることを確認してください。

これにより、ソースを生成して終わるのではなく、チェック、修正、再チェックまでを一連の流れとして実行させました。

処理の流れは、次のようになります。

仕様書と開発ルールを読み込む
  ↓
Bobがソースを生成する
  ↓
利用環境に応じたチェック用プログラムを実行する
  ↓
チェック結果を確認する
  ↓
Bobがソースを修正する
  ↓
チェック用プログラムを再実行する
  ↓
エラーが解消されたことを確認する

チェック用プログラムで確認する内容

Python版のibmi_lint.pyとPowerShell版のibmi_lint.psでは、DDSとRPGを対象に、次の項目をチェックします。

DDS（.pf / .lf / .dspf）

チェック項目	内容
DDSの行種別に応じた記述位置	コメント行、空行などの対象外行を除き、仕様タイプを示す位置がAでない行をエラーとして検出
各行の開始位置	コメント行を除外し、それ以外の行の開始桁を検査
フィールド名の長さ	10文字を超えるフィールド名をエラーとして検出
画面項目の行位置と開始桁位置	1行1桁目への配置、同一行の重複や近接をエラーまたは警告として検出
1行の上限桁数	今回の開発環境で上限としている80バイトを超える行をエラーとして検出
固定文字の終了引用符	継続行を結合してから引用符の対応を検査し、閉じていない場合にエラーを検出
定義形式（SFL／SFLCTL）	定義順序、参照関係、行範囲の重なりを検査し、エラーを検出

RPG（.rpgle / .sqlrpgle）

チェック項目	内容
ファイル先頭の形式	1行目が**FREEでない場合にエラーを検出
固定桁仕様行の混在	旧形式の固定桁による仕様行が混在している場合にエラーを検出
文の終端（セミコロン）	セミコロンの欠落をエラーとして検出
タブ文字	コード行にタブ文字が含まれている場合にエラーを検出
コード部分の全角文字	文字列リテラルとコメント以外のコード部分に含まれる全角文字、全角空白、全角記号をエラーとして検出
引用符の対応	文字列リテラルの終了引用符が閉じられていない場合にエラーを検出
開発ルール違反	可読性を保つため、1行に複数の文が記述されている場合は警告として検出

DDSは固定位置形式のため、目視だけでは桁位置のずれに気づきにくい場合があります。また、日本語を含むソースでは、半角文字と全角文字で使用するバイト数が異なります。そのため、単純な文字数ではなく、IBM iで使用する文字コードを考慮したバイト幅で確認する必要があります。

RPGについても、FFRPGの形式や文法、プログラム構造など、一定の条件で判定できる項目をチェック対象としました。

このように機械的に判定できる項目は、人が一行ずつ確認するよりも、プログラムによるチェックに適しています。Python版のibmi_lint.pyとPowerShell版のibmi_lint.psを用意したことで、利用環境に応じて、これまで目視で確認していた内容の一部を機械的に判定できるようになりました。

3つの検証でBobはどう変わったか

3つの検証結果を整理すると、次のようになります。

#	検証	Bobに渡したもの	生成・確認の進め方	確認できたこと
1	ルールなし	仕様書、コンパイルエラー	Bobがソースを生成し、人がIBM i上でコンパイルを実施。発生したエラーをBobに伝え、修正を依頼	複数種類のソースを生成できたが、エラーごとの個別対応では修正が安定せず、同様のエラーが繰り返し発生した
2	ルールあり	仕様書、仕様書作成ルール、開発ルール	Bobがルールを参照してソースを生成・修正し、人がIBM i上でコンパイル結果を確認	前提条件や修正時の判断基準を統一できたが、生成結果がルールを満たしているかの確認はBobの判断に依存した
3	ルール＋チェック用プログラム	仕様書、仕様書作成ルール、開発ルール、チェック用プログラム	Bobがソース生成後にチェック用プログラムを実行し、検出結果をもとに修正・再チェック	問題の検出、修正、再チェックを一定の手順で進められるようになった

検証1では、仕様書からPF、LF、DSPF、RPG、CLなど、複数種類のソースを生成できることを確認しました。

検証2では、実際に発生したエラーをもとにルールを整備し、Bobに伝える前提条件を統一しました。

検証3では、ルールを参照させるだけでなく、生成したソースをプログラムで機械的にチェックする仕組みを追加しました。

3つの検証を通して、仕様書、ルール、チェック用プログラムには、それぞれ異なる役割があることが分かりました。

仕様書は「何を作るか」を定める。
ルールは「どのように作るか」をそろえる。
チェック用プログラムは「生成結果が基準を満たしているか」を確認する。

検証から分かった4つのこと

1．仕様書には実装上の制約まで記載する

AIに「受注管理システムを作成する」と指示するだけでは、ファイル名、データ型、桁数、画面位置、コンパイル順序など、多くの判断がAIに委ねられます。

IBM iでは、こうした定義の違いが、コンパイルエラーやソース間の不整合につながります。

そのため、AIが参照する仕様書には、実現したい機能だけでなく、実装上の制約も具体的に記載する必要があります。

2．ルールによってコード生成の判断基準をそろえる

仕様書作成ルールと開発ルールを用意することで、Bobに守ってほしい内容をあらかじめ共有できました。

これにより、会話のたびに同じ内容を説明する必要がなくなり、コード生成や修正の判断基準をそろえやすくなりました。

3．生成結果を機械的に確認する仕組みが必要

AIに正しいコードを書かせることだけでなく、生成結果を客観的に確認できる仕組みを用意することも重要です。

今回の検証では、Python版のibmi_lint.pyとPowerShell版のibmi_lint.psを用意し、利用環境に応じて使用できるようにしました。

4．コンパイル前チェックの通過は開発完了ではない

チェック用プログラムでエラーが検出されなかったとしても、IBM i上でのコンパイル成功を保証するものではありません。

チェック用プログラムで確認できるのは、あらかじめチェック項目として実装した内容に限られます。そのため、チェック対象に含まれていない構文エラーや、複数のソース間の参照関係に起因する問題は、IBM i上で実際にコンパイルして初めて見つかる場合があります。

また、コンパイルに成功しても、プログラムが仕様どおりに動作するとは限りません。画面遷移やデータ更新、エラー処理、プログラム間の連携などは、実際にプログラムを動かして確認する必要があります。

Bobによるコード生成、チェック用プログラムによる確認、IBM i上でのコンパイルとテスト、人によるレビューを組み合わせることで、生成したコードを段階的に確認できます。

今後の課題

ルールの適用範囲を明確にする

生成品質をさらに高めるためには、ルールの適用範囲を明確にする必要があります。今回作成したルールには、IBM i共通の制約とプロジェクト固有の制約が混在しています。

今後は、次のように分けて管理することで、ほかの開発でも再利用しやすくなります。

• IBM i共通ルール
• RPG、DDS、CLごとの言語ルール
• プロジェクト共通ルール
• システム固有ルール
• 開発環境に関する設定

チェック用プログラムを拡張する

チェック用プログラムはチェック対象や検出項目を拡張する余地があります。

• DDSとRPG間のフィールド定義の整合性チェック
• プログラム間のパラメータ整合性チェック
• 仕様書と生成したソースの整合性チェック
• ファイル名や変数名の命名規則チェック
• チェック結果に応じた修正方針の標準化

コンパイルやテストを含む工程へ展開する

コンパイル前の形式確認に加え、IBM i上でのコンパイルやテストを含む工程への展開も今後の課題です。

• IBM i上で発生したコンパイルメッセージの整理
• コンパイルエラーの原因特定
• 単体テスト仕様書の生成
• テストデータの生成
• コンパイル後の動作確認
• 正常系・異常系のテスト実行

---

さいごに

今回は、BobによるRPG開発支援について検証しました。

検証を通して、BobでRPGのコードを生成できることを確認しました。一方で、より適切なコードを生成するには、使い方を工夫することが重要だと分かりました。

AIにすべてを任せるのではなく、仕様書、ルール、チェックの仕組みを整えることが、BobをRPG開発で活用するポイントだと感じています。