Copilotでの対策‐IBM iソース生成は「出力形式を先に縛る」が重要

Last updated at 2026-09-10Posted at 2026-09-10

Copilotでの対策

IBM iソース生成は「出力形式を先に縛る」が重要

CopilotにIBM iのRPGソース生成を依頼したところ、指定しないとILE-RPG（フリーフォーム形式）で出力されました。
一方で、現場によってはRPG Ⅲ固定形式が標準であり、そのままでは利用できないケースも少なくありません。

本記事では、実際の検証を通じて見えてきた「出力形式を先に縛る重要性」と、品質向上・工数削減につながったプロンプト設計について紹介します。

はじめに

Copilotを利用してIBM i向けのプログラムを生成する際、次のような依頼をしたことはないでしょうか。

受注照会プログラムをRPGで作成してください。

すると、多くの場合は以下のようなILE-RPG（フリーフォーム形式）が生成されます。

ctl-opt dftactgrp(*no);

dcl*f ORDERS usage(*input);

dcl-s OrderNo packed(7);

chain OrderNo ORDERS;

if %found(ORDERS);

   // 処理

endif;

現在のIBM i開発では一般的なスタイルですが、

RPG Ⅲ
RPG/400
固定形式（固定桁）
C仕様主体
サブルーチン構成

のシステムを保守している現場では、そのまま利用できないことがあります。

現場が期待しているのは、むしろ次のようなコードかもしれません。

FORDERS   IF   E           K DISK

C     ORDERNO       CHAIN ORDERS
C                   IF   %FOUND

つまり、

「RPGを作ってほしい」

と

「RPG Ⅲ固定形式で作ってほしい」

は、Copilotにとって全く異なる指示なのです。

発生した問題

当初は、

Copilotの生成精度が低い

と感じていました。

しかし実際には、ロジックそのものが間違っているケースよりも、

ILE-RPGで生成される
DCL-Sが使われる
CTL-OPTが出力される
サブプロシージャ構成になる

など、

開発標準との不一致

が問題でした。

つまり、

品質が悪いのではなく、期待する出力形式になっていない

ことが本質的な課題だったのです。

なぜILE-RPGが生成されるのか

Copilotは社内標準やプロジェクト標準を知りません。

学習データとして一般的な、

ILE-RPG
フリーフォーム
SQLRPGLE
サブプロシージャ

を優先して生成します。

そのため、

RPGで作成してください

だけでは情報が足りません。

人間であれば

IBM i案件だから固定形式かな？

と推測できても、Copilotは推測してくれません。

解決策は「出力形式を先に縛る」

今回の検証で最も効果があったのは、

生成後に修正するのではなく、生成前に出力形式を固定すること

でした。

例えば、

受注照会プログラムを作成してください。

条件:
・RPG Ⅲ固定形式
・固定桁形式
・C仕様主体
・サブルーチン構成
・フリーフォーム禁止
・DCL-S禁止
・CTL-OPT禁止

と記載するだけで、生成結果が大きく変わりました。
では、具体的にどのような情報をプロンプトへ与えれば良いのでしょうか。

検証の結果、特に有効だったものを整理すると、以下の5要素に集約できました。

良いプロンプトは「5つの要素」で構成する

検証を通して分かったのは、

プロンプトは長さよりも何を指定するかが重要だということです。

特にIBM iのRPG生成では、以下の5要素を含めると結果が安定しました。

① ロールを与える

まずはAIに役割を与えます。

指定なし

RPGを作成してください

指定あり

あなたはIBM i保守エンジニアです。

20年以上運用されている
RPG Ⅲシステムを保守しています。

効果

レガシー資産を前提に考える
保守性を優先する
モダン化を勝手に進めなくなる

② 出力形式を指定する

本記事の最重要ポイントです。

指定なし

RPGで作成してください

指定あり

RPG Ⅲ固定形式

固定桁形式

C仕様主体

サブルーチン構成

効果

RPG
 ↓
ILE-RPGになりやすい

RPG Ⅲ固定形式
 ↓
固定桁形式になりやすい

③ 禁止事項を明示する

経験上、「やること」より「やらないこと」を明示した方が効果があります。

例

禁止事項

・CTL-OPT
・DCL-S
・DCL-PR
・DCL-PI
・サブプロシージャ
・フリーフォーム構文

イメージ

指定なし
 ↓
自由解釈

禁止事項あり
 ↓
出力範囲を制限

④ 品質条件を与える

人間のレビュー観点を先に渡します。

例

品質条件

・コンパイル可能
・未定義変数禁止
・ファイル定義漏れ禁止
・コメント付与

イメージ

コード生成
 ↓
品質確認
 ↓
出力

⑤ 出力順序を指定する

成果物のばらつきを抑える効果があります。

例

出力順序

1.F仕様
2.I仕様
3.C仕様
4.サブルーチン

説明不要
コードのみ出力

指定なし

コード
↓
説明
↓
サンプル
↓
補足

指定あり

F仕様
↓
I仕様
↓
C仕様
↓
サブルーチン

実際に利用しているプロンプト例

あなたはIBM i保守エンジニアです。

以下の仕様を実装してください。

【出力形式】

・RPG Ⅲ固定形式
・固定桁形式
・C仕様主体
・サブルーチン構成

【禁止事項】

・CTL-OPT
・DCL-S
・DCL-PI
・DCL-PR
・サブプロシージャ
・フリーフォーム構文

【品質条件】

・コンパイル可能
・未定義変数禁止
・ファイル定義漏れ禁止
・コメント付与

【出力順序】

1.F仕様
2.I仕様
3.C仕様
4.サブルーチン

説明不要
コードのみ出力

CopilotとBobの違い

プロンプトで制御するか、ルールを資産化するか

ここまで紹介した内容は、主にGitHub Copilotに対するプロンプト設計の考え方です。

Copilotでは、

ロール指定
出力形式指定
禁止事項
品質条件
出力順序

といった情報を、その都度プロンプトとして与えることで出力品質を向上させます。

例えば、今回紹介したような

RPG Ⅲ固定形式
固定桁形式
DCL-S禁止
CTL-OPT禁止

といった条件を毎回記述することで、期待する成果物へ近づけます。

一方、IBM Bobでは少し異なるアプローチを取ることができます。

Bobでは、

コーディング規約
命名規則
帳票レイアウト
定数定義
IBM i開発ルール

などをファイル化し、AIへ事前に認識させる考え方があります。

社内で実施しているIBM i向けAI活用検討でも、

プロンプト設計の標準化
コーディングルールのファイル化
スキルファイルによる知識共有

といった取り組みが検討されています。

またIBM Bobには Skills（スキル） の仕組みがあり、

Db2 for i
DDS
CL
パフォーマンスチューニング
セキュリティ

などの知識を体系化して活用する考え方も紹介されています。

考え方の違い

Copilot

プロンプト

↓
毎回ルールを書く

↓
コード生成

IBM Bob

ルールファイル
＋
スキル
＋
プロンプト

↓
コード生成

RPG生成で比較すると

Copilot

受注照会プログラムを作成してください。

条件:
・RPG Ⅲ固定形式
・固定桁形式
・DCL-S禁止
・CTL-OPT禁止
・サブルーチン構成

プロジェクトの規約を毎回プロンプトで伝えるイメージです。

IBM Bob

受注照会プログラムを作成してください。

事前に

・RPG Ⅲコーディング規約
・命名規則
・帳票レイアウトルール
・定数定義
・IBM i開発標準

などをルールファイルやスキルとして整備しておけば、その内容を前提とした生成が期待できます。

イメージ図

比較してみる

観点	Copilot	IBM Bob
導入の手軽さ	◎	○
単発利用	◎	○
プロンプトによる制御	◎	○
ルールの再利用	△	◎
IBM i資産との親和性	○	◎
コーディング規約の継承	△	◎
長期運用	○	◎

※上記は筆者の検証・利用経験に基づく所感です。

なお、Bobでも適切なプロンプト設計は必要です。

ルールやスキルが存在していても、
利用者が意図を正しく伝えなければ期待通りの成果物になるとは限りません。

そのため、

Copilotはプロンプト中心
Bobはプロンプト＋ルール資産

という違いと考えるのが適切だと思います。

特色をどう生かすか

重要なのは優劣ではなく、

「ルールをどこで管理するか」

です。

Copilotでは、

ロール
＋
出力形式
＋
禁止事項
＋
品質条件
＋
出力順序

を毎回プロンプトに記述していきます。

一方Bobでは、

コーディング規約
命名規則
帳票ルール
定数定義

などを資産として整備し、それを継続的に利用する考え方ができます。

現時点での考え

今回の記事で紹介した

ロール
出力形式
禁止事項
品質条件
出力順序

という考え方は、

実はCopilotでもBobでも共通です。

違いは、

Copilotは「良いプロンプトを書く」ことで制御する

のに対し、

Bobは「良いルールやスキルを資産化する」ことで制御できる

点にあります。

そのため、

個人利用やPoC段階ではCopilot
チーム開発やIBM i保守開発ではBob

という使い分けも有効ではないかと考えています。

AI活用をどう評価するか

生成AIの評価は、
「生成できたかどうか」
だけでは不十分です。

今回の検証では以下の3軸で評価するようにしました。

① 精度（生成物の品質）

評価項目	内容
コンパイル到達	無修正でコンパイル可能か
修正量	コンパイル・実行までの修正行数
仕様の網羅	仕様項目の実装率
規約準拠	コーディング規約違反数
テスト通過	テストケース通過率

例

コンパイル到達：要修正

修正量：15行

仕様網羅：9/10項目

規約違反：2件

テスト通過：18/20ケース

② プロンプト（人間側の工数）

評価項目	内容
往復回数	完成までのプロンプト数
事前準備量	AGENTS.mdやルールファイル量
指示の粒度	丸投げ可能か
再現性	同じ結果が得られるか
学習コスト	利用開始までの準備時間

例

往復回数：4回

事前準備量：約500行

セットアップ：約2時間

③ トークン（利用コスト）

評価項目	内容
消費量	累計トークン数
単位効率	100行あたりの消費量
削減効果	ルール適用前後の差分

例

指定なし：約42,000トークン

ルール適用後：約28,000トークン

削減率：33%

出力形式が安定すると、再生成や修正依頼が減るため、結果的にトークン削減にもつながります。

まとめ

IBM iにおける生成AI活用では、
「何を作るか」よりも「どの形式で出力させるか」
を先に決めることが重要です。

✅ 良い例

❌ 悪い例

そして、そのために有効だったのが

👤 ロール
📄 出力形式
🚫 禁止事項
✅ 品質条件
📋 出力順序

という5つの要素でした。

これらを明示することで、生成結果は大きく安定し、修正工数やトークン消費の削減にもつながります。

今回の記事で紹介した

ロール
出力形式
禁止事項
品質条件
出力順序

という考え方は、

Copilot、Bobどちらも本質的には変わりません。

違いは、

Copilot
  ↓
プロンプトで制御する

Bob
  ↓
ルールを資産化して制御する

という点です。

生成AI活用において重要なのは、AIの性能そのものではなく、

期待する成果物へ導くためのルールをどのように管理するか

なのかもしれません。

CopilotはRPGを生成できます。

しかし、
「どのRPGを書かせるか」 を決めるのは人間の役割であり
「そのルールを資産として残すかどうか」 が、
CopilotとBobの大きな違いの一つだと感じています。

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