はじめに
本記事は、RiSING活動を通して実施したIBM BobによるRPG IVからFF RPGへのコンバート検証についてまとめたものです。
本検証では、プロンプトによる補正効果ではなく、Bobが標準状態でどの程度RPG IVを理解し、FF RPGへ変換できるのかを確認することを目的としました。
なお、同じRiSING活動内では、プロンプトを工夫して変換精度向上を目指す調査も実施されています。本記事では対照的に、シンプルなプロンプトに固定した場合の挙動に焦点を当てています。
検証方針
シンプルなプロンプトを採用した理由
生成AIでは具体的な指示を与えることで出力品質の向上が期待できます。
- 社内コーディング規約を定義して規約の準拠を促す
- 使用を禁止したい命令や実装方法を指定する
- RPG IV固有の記述や注意点を事前に指示し、コンパイルエラーを減らす
しかし今回の検証では、あえて最小限のプロンプトのみを利用しました。
理由は大きく2つあります。
1. Bob本来の変換能力を確認したかったため
複雑なプロンプトを利用すると、AI自身のRPGの理解力とプロンプトによる補正効果を切り分けて評価することが難しくなります。
そのため、まずは最低限の指示のみを与えた場合、Bobがどの程度RPG IVを理解し、FF RPGへ変換できるのかを確認することにしました。
実際に業務でBobを活用する場合、プロンプトを工夫して、社内規約に合わせたり出力精度を向上させることは重要ですが、その前提として、Bob自身の得意な処理や苦手な処理を理解しておくことが重要だと考えたためです。
2. 利用コストとのバランスを考慮したため
Bobでは利用回数に応じてBobコインを消費します。
詳細なプロンプトを与えるほど、出力コード量や推論量が増加し、コイン消費も増える傾向が見られました。
そこで、なぜコイン消費が増加するのか生成結果や処理内容を確認したところ、Bobは与えた指示を守るために、独自解釈による改善やリファクタリングを行おうとしている様子が見られました。
今回のRiSING活動では月40コインという利用枠の中で検証を進める必要があったため、調査量と再現性を重視し、シンプルなプロンプトを採用しました。
検証方法
対象プログラム
RPG IVで作成された業務プログラム
使用プロンプト
@[プログラム名].rpg を別名ファイルとして FF RPG へ変換。
目的：RPG IV を同一動作のまま FF RPG 化すること。
#優先順位
1. コンパイル可能
2. 元ソースとの動作互換
3. フリーフォーム化
4. 可読性
#ルール
・推測でコードを変更しない
・参照できない定義は変更しない
・不明な箇所はTODOコメントを残す
・業務ロジックは変更しない
出力前に自己レビューし、変更理由を説明できない修正は削除すること。
個別のソースに応じて若干の調整は行いましたが、基本的にはシンプルな指示のみに統一しています。
1. コンパイル可能を最優先
検証開始当初、チームメンバーから「変換後にコンパイルが通らない」という報告が複数挙がっていました。
そのため、可読性やFF RPGらしい記法への置き換えよりも、「コンパイル可能であること」を優先事項として設定しました。
2. 動作互換を重視
業務システムでは見た目のきれいさよりも、既存処理を維持することが重要になります。
そのため、元ソースと同じ動作を維持できることを重視し、業務ロジックの変更は避ける方針としました。
3. 推測による変更を禁止
検証の過程で、詳細なプロンプトを与えた場合に、Bobが変換対象のコードへ独自解釈による修正や改善を加えるケースが見られていました。
場合によっては意図していない処理変更やコンパイルエラーにつながることもあったため、今回は推測による変更を行わないよう指示しました。
4. 不明箇所はTODOコメントを残すよう指示
無理に変換を行った結果として誤ったコードが生成されるよりも、変換できなかった箇所を明示した方がコンバート結果のレビューを行いやすいと考えました。
そのため、判断できない箇所についてはTODOコメントを残し、人間が確認できる状態にすることを優先しました。
5. 自己レビューを指示
こちらもコンパイル可能なコードを出力してもらうことが主な目的です。
変換後にもう一度内容を見直してもらうことで、不要な修正や整合性の取れない変換結果を減らせるのではないかと考え、自己レビューを指示しました。
検証結果
今回の検証では、コードの規模や特徴の異なる複数のRPG IVプログラムを対象にコンバートを実施しました。
| サンプル | コード行数 | 特徴 | コンパイル結果 | 消費Bobコイン |
|---|---|---|---|---|
| サンプルA | 68行 | 非常にシンプルなバッチPGM | ○ | 0.291 |
| サンプルB | 66行 | 標識などを多用したレガシー記述を多く含むバッチPGM | ○ | 0.337 |
| サンプルC | 935行 | 複雑な処理フローを持つバッチPGM | × | 0.605 |
| サンプルD | 205行 | 横持ちデータなど特殊な出力処理を持つバッチPGM | × | 0.139 |
- 小規模なプログラムは高い確率でコンパイルが通った
- RPG特有のレガシー記述も問題なく解釈し、FF RPGへ変換できた
- 処理フローが複雑になると構文変換エラーが発生した
- サンプル数は少ないものの、ソース規模よりも処理内容やロジックの複雑さが結果に影響する傾向が見られた
良好だった点
Bobは固定形式RPGの構文を比較的正しく解釈できており、以下のような変換は高い精度で実施できました。
- 基本的な演算処理
- IF系の条件分岐
- サブルーチン呼び出し
- 基本的なファイルアクセス処理
特に、固定長RPG特有の記述についても今回の検証では十分に理解していることを確認できました。
発生した問題
一方で、そのままではコンパイルできないケースも複数確認できました。
1. ループ構文の誤変換
文字列を1文字ずつ切り出しながら処理を行うロジックにおいて、ループ条件の変換エラーとなるケースが発生した。
【Bob変換後】
Do W@KETA;
// 切り出した文字列を処理する部分
...
EndDo;
【人手による修正後】
Dow W@KETA > 0;
// 切り出した文字列を処理する部分
...
// 桁数を減算して処理継続
W@KETA -= 1;
EndDo;
考察
Bobはループ回数を指定する DO を生成していましたが、実際の処理は「残桁数が0になるまで繰り返す」条件付きループでした。
そのため DOW W@KETA > 0 に修正し、ループ内で W@KETA を減算する処理を追加することで本来の処理意図を再現しました。
変換後のコードは一見すると正しく見えますが、処理フローを確認するとループ条件の解釈に誤りが含まれていました。
この事例から、BobはRPGの命令や構文を一定レベルで理解できる一方で、必ずしも正確に解釈できる訳ではなく、AI特有の推測や誤解釈による変換ミスが発生する可能性があることが分かりました。
従来の変換ツールが機械的に変換を行うのに対し、Bobはソースコードの意図を推測しながら変換を行うため、このような誤変換が発生すると考えられます。そのため、変換結果をそのまま採用するのではなく、処理内容を理解した上でレビューを行うことが重要だと感じました。
2. KLIST変換時の定義生成エラー
キーリストを利用したファイルアクセス処理において、変換元に存在しないレコードフォーマットを生成するケースが発生した。
【変換元のKLIST】
C SAMPLEKEY KLIST
C KFLD KEY1
C KFLD KEY2
C KFLD KEY3
【Bob変換後】
DCL-DS KEYMM LIKEREC(SAMPLEKEY : *KEY);
考察
このケースでは、BobはKLISTをキーリストとして認識できていたものの、FF RPG化する過程で LIKEREC(... : *KEY) を利用したデータ構造へ変換しようとしたように見受けられます。
変換元コードにはレコードフォーマットに関する定義は存在しておらず、SAMPLEKEY はキーリスト名でしかありません。
この事例は、Bobが単純に定義を見落としたというよりも、PF のキーとなるフィールド名から、存在しないレコードフォーマットがあるものとして変換が行われていると考えられます。
また、本検証では「推測でコード変更しない」という指示を与えていましたが、本来存在しないレコードフォーマットを前提としたコードが生成されていることから、このケースでは推測による補完が行われてしまった可能性があります。
このように、Bobは不足している情報を補完しようとする傾向があり、その結果として誤ったコードが生成される場合があることに注意が必要と感じました。
まとめ
今回の検証では、あえてシンプルなプロンプトを用いることで、IBM BobがどのようにRPGを解釈し、FF RPGへ変換するのかを確認しました。
検証の結果、Bobは固定形式RPGの構文やレガシーな記述を一定レベルで理解できており、単純な変換作業においては十分な支援効果が期待できることが分かりました。
一方で、処理フローの解釈や複数定義の関連付けが必要な場面では誤変換も確認されました。また、推測によるコード変更を抑制する指示を与えた場合でも、それらしい構造へ補完しようとする傾向が見られました。
FF RPGへの変換においては、人手によるレビューが必要な変換結果も確認されましたが、今回の検証はあくまでシンプルなプロンプトに限定した調査でした。
そのため、プロンプトの工夫や追加の指示によってどこまで改善できるのかについては、今後さらに検証の余地があると考えています。
少なくとも今回の検証を通して、Bobの得意 / 不得意、そしてレビュー時に注意すべきポイントを把握することができました。
本検証で得られた知見が、今後FF RPG化を検討する際の参考になれば幸いです。