生成AIは固定長RPGLEを書けるのか？3つのAIでコンパイル・テストまで試してみた
はじめに
最近は生成AIにコードを書かせる機会もかなり増えてきました。
JavaやPythonのような言語であれば事例も多いですが、IBM iで使われている固定長RPGLEだとどこまで使えるのか気になったので、実際に試してみました。
今回使ったのは以下の3つです。
- ChatGPT
- GitHub Copilot
- IBM Bob
同じ仕様書を渡して、主に以下を見ています。
- 固定長RPGLEとして生成できるか
- 何回目でコンパイルできるか
- 仕様通りに動くか
- 生成されたソースが読みやすいか
- 実際に使ってみてどうだったか
今回は、これらを「コーディング」「保守性／可読性」「使いやすさ」の3つに分けて評価します。
評価基準
各生成AIを、以下の3項目で〇・△・×の3段階評価としました。
コーディング
正しくテストが通るまでに、何回やり取りが必要だったかを基準に評価します。
- 〇：3回以下
- △：6回以下
- ×：それ以上
単純にソースが生成できたかではなく、コンパイル・テストまで含めて、実際に使える状態になるまでのやり取り回数を見ています。
保守性／可読性
コメントの見やすさや、処理が無駄に複雑になっていないかを確認します。
こちらは数値化が難しいため、生成されたソースを実際に確認したうえで主観的に評価しています。
- 〇
- △
- ×
使いやすさ
こちらの意図をどの程度くみ取ってくれるか、修正指示に対して期待した回答が返ってくるかなど、実際に使ったときの使いやすさを評価します。
こちらも保守性／可読性と同様に、主観を含めた評価としています。
- 〇
- △
- ×
今回使用した仕様書
# 機能仕様書：日付⇒曜日変換プログラム
入力された日付（YYYYMMDD形式）の妥当性をチェックし、対応する曜日コードとエラーフラグを返却するプログラム。
## 1. インターフェース（パラメータ定義）
| パラメータ名 | 区分 | 型・桁数 | フォーマット / 値の定義 | 備考 |
| :--- | :--- | :--- | :--- | :--- |
| 日付 | 入力 | 半角文字 8桁 | YYYYMMDD （例：20260624） | 曜日を求めたい対象の日付 |
| 曜日 | 出力 | 半角文字 1桁 | 1～7（1:月、2:火、3:水、4:木、5:金、6:土、7:日） | エラー発生時の戻り値は任意（または空文字/初期値） |
| エラーフラグ | 出力 | 半角文字 1桁 | 0：エラーなし（正常終了） / 1：エラーあり（異常終了） | 処理が正常に完了したかを識別するフラグ |
## 2. 処理要件
### 2.1. バリデーションチェック（エラー要件）
入力された「日付」パラメータに対して、以下のチェックを順に実施します。
いずれかの条件に該当した場合は、即座にエラー処理（3.2）へ移行します。
・桁数・文字種チェック
- 入力値が半角8桁ではない場合（文字数が不足、または超過している場合）。
- （推奨追加仕様）数字以外の文字が含まれている場合。
・日付妥当性チェック
- 入力値がグレゴリオ暦において実在する有効な日付ではない場合。
- 例：13月（YYYY13DD）、32日（YYYYMM32）、0月、0日など。
- 注意：うるう年（2月29日）の判定も含みます。
### 2.2. 曜日算出処理
バリデーションチェックが正常に通過した場合、該当日の曜日を算出します。
・算出した曜日を定義に基づき「1（月）」～「7（日）」のコードに変換します。
## 3. 出力制御
### 3.1. 正常終了の場合
・エラーフラグ：0 を設定
・曜日：算出された曜日コード（1～7）を設定
### 3.2. 異常終了（エラー）の場合
・エラーフラグ：1 を設定
・曜日：値を設定しない（またはシステム既定の初期値を設定）
検証方法
各生成AIに同じプロンプトを提示して、固定長RPGLEでソースを作成してもらいました。
最初に提示したプロンプトは、以下のような内容です。
・添付したテキストファイルの仕様書をAS400の固定長RPGLEのPGMとして作成してほしい
・出力先はテキストファイル
・コメントも詳しく記載
生成されたソースをコンパイルし、エラーになった場合はその内容をAIに伝えて修正してもらいました。
併せて、テスト仕様書をもとにテストも実施しました。
テスト仕様書
| No. | 分類 | テスト内容 | 入力 | 期待結果 |
|---|---|---|---|---|
| 1 | 正常系 | うるう年の2/29 | 20240229 | 木曜日 |
| 2 | 正常系 | 400で割り切れる世紀年 | 20000229 | 火曜日 |
| 3 | 正常系 | 平年2月末日 | 20260228 | 土曜日 |
| 4 | 正常系 | 1月31日 | 20260131 | 土曜日 |
| 5 | 正常系 | 4月30日 | 20260430 | 木曜日 |
| 6 | 異常系 | 4月31日 | 20260431 | エラー |
| 7 | 異常系 | 2月30日 | 20260230 | エラー |
| 8 | 異常系 | 平年の2月29日 | 20260229 | エラー |
| 9 | 異常系 | 1900年2月29日 | 19000229 | エラー |
| 10 | 異常系 | 2100年2月29日 | 21000229 | エラー |
検証結果
ChatGPT
ChatGPTは3回目でコンパイルできました。
1回目
まず、仕様書を添付して以下のプロンプトを入力しました。
・添付したテキストファイルの仕様書をAS400の固定長RPGLEのPGMとして作成してほしい
・出力先はテキストファイル
・コメントも詳しく記載
1回目から固定長RPGLEとしてソースは生成されました。
RPGLEの処理自体はある程度理解しているように見えましたが、固定長特有の桁位置やコメントの書き方など、一部の形式に問題があり、そのままではコンパイルできませんでした。
2回目
1回目に生成されたソースを確認し、固定長RPGLEの形式に合わせるため、以下のプロンプトを追加しました。
・仕様書の先頭5桁は削除
・コメントアウトをする場合は仕様書に合わせる
H仕様ならH*
F仕様ならF*
他の仕様書についても同様
この修正によって、1回目よりも固定長RPGLEとしての形式はかなり改善されました。
ただし、再度コンパイルしたところ、C仕様のCHECK命令の桁位置がずれている箇所がありました。
3回目
そこで、問題となっていた箇所を具体的に指定して修正を依頼しました。
213行目のCHECKの位置がずれている
再度ソースを修正して
修正後のソースではCHECKの位置も正しくなり、3回目でコンパイルに成功しました。
今回試してみて、固定長RPGLEではロジックが合っていても、命令の位置が1桁ずれているだけでコンパイルできない点がかなり厄介だと感じました。
ChatGPTのテスト結果
コンパイル後に10ケース分を実施しました。
結果は10件すべて○でした。
うるう年や存在しない日付についても、問題なく判定できていました。
ChatGPTを使ってみた感想
思っていたよりRPGLEについて理解している印象でした。
最初から完璧ではありませんでしたが、問題になっている場所を具体的に伝えれば修正できています。
生成されたソースもそこまで複雑ではなく、コメントも入っていたので比較的読みやすかったです。
ただ、「固定長RPGLEで作成して」とだけ伝えるより、
先頭5桁を削除して
H仕様のコメントはH*にして
CHECKを正しい桁に配置して
のように、具体的に伝えたほうがうまくいきました。
AIの性能だけではなく、使う側の指示の出し方も重要だと思います。
IBM Bob
IBM Bobは4回目でコンパイルできました。
IBM i向けの生成AIということもあり、今回の中でも特に注目していたツールです。
実際に使ってみると、最初から固定長RPGLEを意識したソースが生成されており、IBM i向けのツールらしさを感じました。
1回目
ChatGPTと同じように、仕様書を添付して以下のプロンプトを入力しました。
・添付したテキストファイルの仕様書をAS400の固定長RPGLEのPGMとして作成してほしい
・出力先はテキストファイル
・コメントも詳しく記載
最初の生成時点から固定長RPGLEの構成を意識したソースになっていました。
特にコメントが細かく記載されており、生成された処理が何をしているのか確認しやすかったです。
一方で、固定長特有の形式については一部調整が必要でした。
2回目
コメントの書き方を固定長RPGLEの形式に合わせるため、以下の指示を追加しました。
・コメントで*を使用する場合は各仕様に合わせる
H仕様ならH*
F仕様ならF*
また、生成されたソースに含まれていた先頭5桁についても削除するように指示しました。
指摘した内容については修正されており、プロンプトを追加することで固定長RPGLEの形式に近づけることができました。
3回目
修正後のソースでは、配列の定義部分に問題がありました。
以下のように、各月の最大日数を保持するための配列が定義されていました。
D* 各月の最大日数テーブル（1月～12月）
D* ※2月（インデックス=2）はうるう年の別途判定があるため平年最大値28を格納
D* ※テーブルデータはソースの末尾（CTDATAセクション）に記載
D W_MAXDAY S 2 0 DIM(12) CTDATA
D*
一方で、ソース末尾の部分は以下のように生成されていました。
C* エラーフラグ を 1（エラーあり）にセットする
C EVAL P_ERRFLG = C_ERROR
C*
C* 曜日コードは空白（初期値）のまま変更しない
C* ※処理先頭で P_WKDAY = ' ' に初期化済み
C*
C ENDSR
C*
C*=======================================================================*
C* コンパイル時テーブルデータ（CTDATA） *
C* W_MAXDAY：各月の最大日数テーブル（DIM(12)、1月～12月） *
C* 添字 1 = 1月（31日） 添字 2 = 2月（28日 ※うるう年は別途判定） *
C* 添字 3 = 3月（31日） 添字 4 = 4月（30日） *
C* 添字 5 = 5月（31日） 添字 6 = 6月（30日） *
C* 添字 7 = 7月（31日） 添字 8 = 8月（31日） *
C* 添字 9 = 9月（30日） 添字10 =10月（31日） *
C* 添字11 =11月（30日） 添字12 =12月（31日） *
C* データは2桁ずつ連続して記述する（計12要素 × 2桁 = 24文字） *
C*=======================================================================*
**
31283130313031303131303100
DIM(12)で12要素の配列を定義しているにもかかわらず、データが1行にまとめて記載されていたため、以下のように修正を依頼しました。
配列のデータがDIM(12)になっているのに1行になっているから
12行分に分けて
配列を使用して月ごとの最大日数を管理する考え方自体は分かりやすく、コメントも細かく書かれていました。
その一方で、固定長RPGLEとして実際にコンパイルするためには、配列の記述方法を調整する必要がありました。
4回目
上記の修正後、最終的にコンパイルできる状態になりました。
修正回数だけを見るとChatGPTより1回多くなりましたが、生成されたソースにはコメントが多く、IBM iやRPGLEを意識して作ろうとしている点は分かりやすかったです。
また、問題になっている箇所を具体的に伝えることで修正できており、やり取りを重ねながら完成度を上げることができました。
IBM Bobのテスト結果
ChatGPTと同じ10ケース分を実施しました。
結果は10件すべて○でした。
正常系だけでなく、うるう年や存在しない日付などの異常系についても問題なく判定できています。
IBM Bobを使ってみた感想
IBM i向けの生成AIということもあり、RPGLEを意識したコードやコメントを生成してくれる点は良かったです。
今回生成されたソースでは配列を使って各月の日数を管理しており、ChatGPTとは違う実装方法になっていたのも面白い点でした。
特にコメントはかなり細かく書かれていて、処理の意図を確認しながらソースを読むことができました。
最初からそのままコンパイルできたわけではありませんが、問題点を具体的に伝えると修正でき、最終的にはテストケースもすべて通っています。
今回の結果だけを見るとChatGPTのほうが少ない回数でコンパイルできましたが、IBM iやRPGLEに寄せた回答をしてくれる点はBobの強みだと感じました。
VS Code上でそのまま利用できる点も含め、IBM i開発の中で使い込んでいくと活用できる場面は多そうです。
GitHub Copilot
GitHub Copilotも同じように試しましたが、今回はコンパイルできるところまで持っていけませんでした。
何度かプロンプトを変えて試しましたが、固定長RPGLE特有の桁位置の不整合が多かったです。
そのため、今回はテストまでは実施していません。
ただ、処理の考え方やサンプルコードを出してもらう用途では参考になる部分もありました。
完成した固定長RPGLEをそのまま作ってもらうより、補助的に使うほうが向いていそうです。
3つを比較
結果をまとめると以下のようになりました。
| 比較項目 | ChatGPT | IBM Bob | GitHub Copilot |
|---|---|---|---|
| コーディング | ○ | △ | × |
| 保守性・可読性 | △ | ○ | × |
| 使いやすさ | ○ | ○ | △ |
| コンパイルまで | 3回 | 4回 | 到達できず |
| テスト | 10/10 ○ | 10/10 ○ | 未実施 |
コーディングについては、最初に決めた評価基準に沿って、3回で完了したChatGPTを「○」、4回だったIBM Bobを「△」としています。
今回の条件では、ChatGPTが一番少ないやり取りでコンパイルまで進めることができました。
一方でIBM Bobは、コメントの細かさやIBM i・RPGLEを意識したソース生成など、IBM i向けのツールならではの特徴も見られました。
今回の仕様書やプロンプトで試した結果なので、これだけでAI自体の優劣を決めるものではありません。
検証していて気になったこと！？
固定長RPGLEと生成AIは相性があまり良くない？
今回一番気になったのは、やはり桁位置です。
JavaやPythonではあまり意識しませんが、固定長RPGでは書く位置そのものに意味があります。
今回も、
CHECKの位置が1桁ずれている
だけでコンパイルできませんでした。
ロジック自体は合っていても、固定長として正しく配置されていないと動かないので、この部分は生成AIが苦手そうに感じました。
フリーフォーマットのRPGで同じことをやれば、かなり結果が変わりそうです。
移送命令はEVALしかない
もう1つ気になったのが、生成されたソースでは、値の移送にMOVELではなくEVALが使われていた点です。
既存の固定長RPGではMOVELを使用しているソースも多く見かけますが、今回生成されたソースでは、ほとんどがEVALで記述されていました。
EVALは、
変数 = 値
という一般的なプログラミング言語の代入処理に近い書き方です。
そのため、JavaやPythonなどのオープン系言語を多く学習している生成AIにとっては、MOVELよりもEVALのほうが生成しやすいのかもしれません。
一方で、既存ソースでMOVELを多用している環境では、既存コードとの書き方に差が出る点は意識しておく必要がありそうです。
まとめ
今回の結果は以下の通りでした。
- ChatGPT：3回目でコンパイル成功、テスト10件すべて○
- IBM Bob：4回目でコンパイル成功、テスト10件すべて○
- GitHub Copilot：今回はコンパイルまで到達できず
実際に試してみると、生成AIはRPGLEのロジック自体はある程度理解していました。
ChatGPTは少ない修正回数でコンパイルまで進められた点が良く、IBM BobはIBM iやRPGLEを意識したコードや細かいコメントを生成してくれる点が印象に残りました。
一方で、どの生成AIでも固定長特有の桁位置については注意が必要そうです。
そのため、生成されたソースをそのまま使用するというよりも、人が内容を確認しながら修正していく使い方が現実的だと思います。
また、固定長RPGLEの新規作成だけでなく、
- 既存ソースの解析
- 処理内容の説明
- 仕様書作成
- 保守作業の補助
といった用途でも活用できそうです。
今度は同じ仕様書を使って、フリーフォーマットRPGでも試してみたいと思います。
当記事の著作権はIBMに帰属します。詳細はこちらをご参照ください。