IBM Bobを使用した受注データ作成＋仕様書の作成（RPG III）

Last updated at 2026-09-14Posted at 2026-09-14

IBM RiSING2026 チーム成果物：受注データプログラム作成レポート

はじめに

こちらの内容は、IBM RiSING2026のチーム成果物として作成した内容となります。
今回は受注データプログラムを作成したケースを記載します。
併せて、プログラム内容から仕様書を作成してみます。

やりたいこと

IBM Bobを使用して、AGENTS.mdを指定したうえで一般的な受注プログラムを作成したい。
具体的な指示をしない場合、どのような成果物ができるか検証したい。

AGENTS.mdに関して

今回は【AGENTS.md】の内容に従ってプログラムの作成を実施していきます。
AGENTS.mdは、端的に言えば「AIプログラムの前提条件を記載した内容」となっており、
こちらの内容を読み込ませることで、以下のメリットが発生します。

他メンバーにおいても、同様の前提条件でAIプログラムの作成が可能
あらかじめ前提条件を渡すことで、後から条件を渡すことなくソースの出力が可能になる
各システムにおける禁止事項や出力形式を明言することで、出力プログラムの修正の手間がなくなる

今回は以下の内容をIBM Bobに取り込みさせることで対応しています。
IBM BobのAGENTS.mdの書き方や配置に関しては、次の記事をご確認ください。
https://qiita.com/Tadash/items/3b709ebcb6da72166503

# IBM i RPG III 開発・解析専用指示（AGENTS.md）

## 1. あなたの役割（ペルソナ）
- あなたはIBM i (AS/400) システムおよびRPG III (RPG400) に精通した、経験豊富なレガシーシステム刷新・保守専門のシニアエンジニアです。
- 固定形式の仕様、インジケータの挙動、データ・エリア、データ・キュー、およびCL（制御言語）との連携に深い知見を持っています。

## 2. 対象システム・開発環境
- **言語・バージョン**: RPG III (固定形式 / OPM)
- **環境**: IBM i (AS/400)
- **関連言語**: CL (Control Language), DDS (Data Description Specifications)

## 3. 回答およびコード生成の基本ルール
- **固定形式（カラム位置）の厳守**:
  - RPG IIIのコードを出力する際は、必ず定位置記入（F、E、I、C、O仕様書のカラム位置）を厳格に守って記述してください。
  - カラム位置がずれるとコンパイルエラーになるため、スペースの数に細心の注意を払ってください。
- **インジケータ（指標）の明示**:
  - 条件指標（例: `50`, `99` など）や改ページ指標（`LR`, `OF`）を使用する際は、そのインジケータが「何のために使われているか（例: *IN50 = レコード未検出）」を日本語のコメントで必ず補足してください。
- **解析・ドキュメント作成**:
  - 既存のRPG IIIソースの解析を依頼された場合は、サブルーチン（`EXSR`）ごとの役割、主ループの構造、使用しているファイル（F仕様書）の処理目的を構造化して日本語で分かりやすく解説してください。

## 4. プログラミング時の禁止・制約事項
- **RPG IV（ILE-RPG）やフリーフォーム（Free-Form）のコードは出力禁止**です。必ず従来のRPG III（固定形式）の文法（例: `Z-ADD`, `MULT`, `SETON`, `CABxx` など）を使用してください。
- 命名規則はIBM iの制約（フィールド名やファイル名は最大6文字〜10文字など）を考慮し、長すぎる変数名は使用しないでください。
- GOTO文（`TAG` / `GOTO`）の多用は避け、可能な限りサブルーチン（`BEGSR` / `ENDSR`）や論理指標で構造化してください（既存コードに存在する場合は意図を正確に読み解いてください）。

## 5. 出力形式の指定
- コードを提示する際は、仕様書の種類（F仕様書、C仕様書など）を明記し、行のイメージが伝わりやすいように等幅フォント（Code Block）で出力してください。
- 新規プログラムや修正案を提示する際は、事前に「処理フローの概要（Plan）」を日本語で提示し、ユーザーの確認を得てからコード生成に移ってください。

なお、指示内容としては 「一般的な受注プログラムを作成してください」 とだけ指示し、
特にテーブルや資料は読み込ませずに作成してもらうこととしました。

出力結果

指示の結果、受注データを全件読み込み、受注状態が「確定」のレコードについて税込合計金額を累計集計してレポートへ出力するPGMが作成されました。

以下、出力結果のソースとなります。

・DDSファイル

     A*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     A* ファイル名  : JUCHUPF
     A* 説明       : 受注物理ファイル（受注ヘッダ情報）
     A* 作成日     : 2025/07/01
     A* 備考       : IBM i / AS/400 DDS 固定形式
     A*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     A                                      UNIQUE
     A          R JUCHUR                    TEXT('受注レコード')
     A*
     A* ---- キーフィールド ----
     A            JUNO           8  0        TEXT('受注番号')
     A*
     A* ---- 受注基本情報 ----
     A            JUDT           8  0        TEXT('受注日 YYYYMMDD')
     A            NKDT           8  0        TEXT('納期日 YYYYMMDD')
     A*
     A* ---- 顧客情報 ----
     A            TOKCD         10A          TEXT('顧客コード')
     A            TOKNM         40A          TEXT('顧客名')
     A            TOKTN         15A          TEXT('顧客担当者名')
     A*
     A* ---- 商品情報 ----
     A            HINCD         10A          TEXT('商品コード')
     A            HINNM         40A          TEXT('商品名')
     A            SUURYO         7  0        TEXT('受注数量')
     A            TANKA          9  2        TEXT('単価（小数2桁）')
     A            KINGAK         11  2        TEXT('金額＝数量×単価')
     A            ZEIRTS          3  1        TEXT('消費税率（例:10.0）')
     A            ZEIGAK          9  2        TEXT('消費税額')
     A            GKINGK         11  2        TEXT('税込合計金額')
     A*
     A* ---- ステータス・区分 ----
     A            JUSTS           1A          TEXT('受注状態 0:未処理 1:確定 2:出荷済 9:取消')
     A            NYUKBN          1A          TEXT('入金区分 0:未入金 1:入金済')
     A            SIRKBN          1A          TEXT('仕入区分 0:未発注 1:発注済')
     A*
     A* ---- 担当者・部門 ----
     A            TANCD           6A          TEXT('担当者コード')
     A            TANNM         20A          TEXT('担当者名')
     A            BUMON           4A          TEXT('部門コード')
     A*
     A* ---- 備考・管理 ----
     A            BIKO           60A          TEXT('備考')
     A            INSDT           8  0        TEXT('登録日 YYYYMMDD')
     A            UPDDT           8  0        TEXT('更新日 YYYYMMDD')
     A*
     A* ---- キー定義 ----
     A          K JUNO

・RPGファイル

     H*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     H* プログラム名 : JUCHURPG
     H* 説明        : 受注ファイル(JUCHUPF)読込み RPG III テンプレート
     H* 作成日      : 2025/07/01
     H* 環境        : IBM i (AS/400) RPG III 固定形式 (OPM)
     H*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     H
     *
     *==================================================================
     * F仕様書（ファイル仕様書）
     *==================================================================
     FJUCHUPF IP  E           K        DISK
     *   ↑ JUCHUPF : 受注物理ファイル（入力・プライマリ・キー順）
     *
     *==================================================================
     * I仕様書（入力仕様書）
     *==================================================================
     IJUCHUR
     I                                        1   4 OJUNO
     I                                        5   8 OJUDT
     I                                        9  12 ONKDT
     I                                       13  22  TOKCD
     I                                       23  62  TOKNM
     I                                       63  77  TOKTN
     I                                       78  87  HINCD
     I                                       88 127  HINNM
     I                                      128 131 OSUURYO
     I                                      132 136 OTANKA
     I                                      137 142 OKINGAK
     I                                      143 144 OZEIRTS
     I                                      145 149 OZEIGAK
     I                                      150 155 OGKINGK
     I                                      156 156  JUSTS
     I                                      157 157  NYUKBN
     I                                      158 158  SIRKBN
     I                                      159 164  TANCD
     I                                      165 184  TANNM
     I                                      185 188  BUMON
     I                                      189 248  BIKO
     I                                      249 252 OINSDT
     I                                      253 256 OUPDDT
     *
     *==================================================================
     * C仕様書（演算仕様書）― 主ループ処理骨格
     *   インジケータ凡例:
     *     *IN50 = CHAIN失敗（レコード未検出）時にセット
     *     *IN99 = エラー発生時にセット
     *     *INLR = ラストレコード（ファイル終端）
     *==================================================================
     C                     EXSR  SRJUCH        メインサブルーチン呼出し
     *
     C           SRJUCH    BEGSR
     *
     C           JUSTS     IFEQ  '1'
     *   *IN70 = 受注確定レコードに対する処理中フラグ
     C                     SETON                     70
     C           TOTKGK    ADD   GKINGK    TOTKGK  112
     C                     END
     *
     C           JUSTS     IFEQ  '9'
     *   *IN80 = 受注取消レコードスキップフラグ
     C                     SETON                     80
     C                     END
     *
     C           SRJUCH    ENDSR
     *
     *==================================================================
     * O仕様書（出力仕様書）― ラストレコード時に集計を印刷する例
     *==================================================================
     OREPORT  LR        1  通常ページ送り(OF指標で改ページ)
     O                         TOTKGK   B  30  '税込合計金額累計'

・CLファイル

/*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*/
/* プログラム名 : JUCHUCL                                           */
/* 説明        : 受注物理ファイル（JUCHUPF）作成用 CLコマンド集     */
/* 対象環境    : IBM i (AS/400)                                     */
/* 作成日      : 2025/07/01                                         */
/*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*/
PGM

/*------------------------------------------------------------------*/
/* ステップ1: DDSソースメンバの登録                                 */
/*------------------------------------------------------------------*/
ADDPFM FILE(MYLIB/QDDSSRC) MBR(JUCHUPF) +
        SRCTYPE(PF) +
        TEXT('受注物理ファイル DDS定義')

/*------------------------------------------------------------------*/
/* ステップ2: 物理ファイルの作成                                    */
/*------------------------------------------------------------------*/
CRTPF    FILE(MYLIB/JUCHUPF) +
          SRCFILE(MYLIB/QDDSSRC) +
          SRCMBR(JUCHUPF) +
          MAXMBRS(*NOMAX) +
          SIZE(10000 1000 3) +
          AUT(*CHANGE) +
          TEXT('受注物理ファイル')

/*------------------------------------------------------------------*/
/* ステップ3: ジャーナル登録（推奨）                                */
/*------------------------------------------------------------------*/
STRJRNPF FILE(MYLIB/JUCHUPF) +
          JRN(MYLIB/MYJRN)

/*------------------------------------------------------------------*/
/* ステップ4: 権限設定                                              */
/*------------------------------------------------------------------*/
GRTOBJAUT OBJ(MYLIB/JUCHUPF) +
           OBJTYPE(*FILE) +
           USER(APPUSR) +
           AUT(*CHANGE)

ENDPGM

・テスト用データ

*------------------------------------------------------------------------
* ファイル名  : JUCHUDT.txt
* 説明       : JUCHUPF サンプルデータ（5レコード）
*------------------------------------------------------------------------

* ---- レコード 1 ----
* JUNO   = 20250001   受注番号
* JUDT   = 20250701   受注日
* NKDT   = 20250715   納期日
* TOKCD  = T001       顧客コード
* TOKNM  = 株式会社サンプル商事
* TOKTN  = 山田 太郎
* HINCD  = H001
* HINNM  = ノートパソコン ProBook 14
* SUURYO = 5
* TANKA  = 98000.00
* KINGAK = 490000.00
* ZEIRTS = 10.0
* ZEIGAK = 49000.00
* GKINGK = 539000.00
* JUSTS  = 1          受注状態：確定
* NYUKBN = 0          入金区分：未入金
* SIRKBN = 1          仕入区分：発注済
* TANCD  = S001
* TANNM  = 鈴木 一郎
* BUMON  = 0101
* BIKO   = 納期厳守。分割納品不可。
* INSDT  = 20250701
* UPDDT  = 20250701

* ---- レコード 2 ----
* JUNO   = 20250002
* JUDT   = 20250701
* NKDT   = 20250720
* TOKCD  = T002
* TOKNM  = 有限会社田中工業
* TOKTN  = 田中 花子
* HINCD  = H002
* HINNM  = 業務用プリンタ LX-500
* SUURYO = 2
* TANKA  = 75000.00
* KINGAK = 150000.00
* ZEIRTS = 10.0
* ZEIGAK = 15000.00
* GKINGK = 165000.00
* JUSTS  = 1
* NYUKBN = 1          入金区分：入金済
* SIRKBN = 0          仕入区分：未発注
* TANCD  = S002
* TANNM  = 佐藤 次郎
* BUMON  = 0102
* BIKO   = 請求書送付済み。
* INSDT  = 20250701
* UPDDT  = 20250702

* ---- レコード 3 ----
* JUNO   = 20250003
* JUDT   = 20250702
* NKDT   = 20250725
* TOKCD  = T003
* TOKNM  = 東西システムズ株式会社
* TOKTN  = 伊藤 健一
* HINCD  = H003
* HINNM  = 外付けSSD 2TB
* SUURYO = 20
* TANKA  = 12000.00
* KINGAK = 240000.00
* ZEIRTS = 10.0
* ZEIGAK = 24000.00
* GKINGK = 264000.00
* JUSTS  = 0          受注状態：未処理
* NYUKBN = 0
* SIRKBN = 0
* TANCD  = S001
* TANNM  = 鈴木 一郎
* BUMON  = 0101
* BIKO   =
* INSDT  = 20250702
* UPDDT  = 20250702

* ---- レコード 4 ----
* JUNO   = 20250004
* JUDT   = 20250703
* NKDT   = 20250710
* TOKCD  = T004
* TOKNM  = 北海道物産株式会社
* TOKTN  = 高橋 誠
* HINCD  = H004
* HINNM  = 無線LANルータ WX-300
* SUURYO = 10
* TANKA  = 8500.00
* KINGAK = 85000.00
* ZEIRTS = 10.0
* ZEIGAK = 8500.00
* GKINGK = 93500.00
* JUSTS  = 2          受注状態：出荷済
* NYUKBN = 1
* SIRKBN = 1
* TANCD  = S003
* TANNM  = 中村 三郎
* BUMON  = 0201
* BIKO   = 出荷伝票番号：SH-2025-0041
* INSDT  = 20250703
* UPDDT  = 20250705

* ---- レコード 5 ----
* JUNO   = 20250005
* JUDT   = 20250704
* NKDT   = 20250730
* TOKCD  = T001
* TOKNM  = 株式会社サンプル商事
* TOKTN  = 山田 太郎
* HINCD  = H005
* HINNM  = オフィスチェア ER-200
* SUURYO = 3
* TANKA  = 35000.00
* KINGAK = 105000.00
* ZEIRTS = 10.0
* ZEIGAK = 10500.00
* GKINGK = 115500.00
* JUSTS  = 9          受注状態：取消
* NYUKBN = 0
* SIRKBN = 0
* TANCD  = S002
* TANNM  = 佐藤 次郎
* BUMON  = 0102
* BIKO   = 顧客都合による取消。返金処理不要。
* INSDT  = 20250704
* UPDDT  = 20250706

コードレビュー

IBM Bobで生成されたコードに対して、『Copilot』と『Premium Package for i』によるレビューを実施しました。

Copilot

【DDSレビュー】

判定: 文法○ / コンパイル○ / 実運用△

致命的問題:

なし

修正推奨:

日付項目を数値(8,0)で保持している
金額項目(11,2)は業務によっては桁不足の可能性
ステータス値の妥当性チェックがない
UNIQUEキー(JUNO)の採番管理が必要

総評:
DDSは比較的完成度が高く、そのままCRTPF可能。

【RPGレビュー】

判定: 文法△ / コンパイル×寄り / 実行△

致命的問題:

OREPORTを使用しているがFREPORT定義なし
外部記述ファイル(E指定)なのにI仕様で項目を再定義
固定形式RPGとして桁位置崩れの可能性

警告:

TOTKGKの初期化なし
*IN70, *IN80をOFFしていない
出力仕様が未完成

推奨修正:

FREPORT追加またはOREPORT削除
I仕様見直し
初期化処理追加

【CLレビュー】

判定: 文法△ / コンパイル△ / 実行×

致命的問題:

コメント形式がCLプログラムとして不適切
ADDPFMは再実行時に失敗する可能性
QDDSSRC存在前提
CRTPF再実行時エラー対策なし
ジャーナル(MYJRN)作成処理なし

警告:

MYLIBはサンプル名
APPUSRはサンプル名
エラー処理なし

総合評価:

ファイル	スコア
DDS	80点
RPG	40点
CL	50点

結論:
DDSはそのまま利用可能。
RPGとCLは教材・サンプルレベルであり、IBM i投入前に修正が必要。

Premium Package for i

対象ファイル一覧

ファイル名	種別	説明
JUCHUPF.dds	DDS 物理ファイル	受注物理ファイル定義
JUCHURPG.rpg	RPG III プログラム	受注ファイル読込み処理
JUCHUCL.clp	CL プログラム	ファイル作成・環境設定
JUCHUDT.txt	テストデータ	サンプルレコード 5 件

1. JUCHUPF.dds — DDS 物理ファイル

✅ 良い点

UNIQUE キー制約 — UNIQUE キーワードが正しく定義されており、受注番号の重複を防止している
キー定義 — K JUNO によるキー順アクセスが明確に定義されている
フィールドコメント — 全フィールドに TEXT() キーワードが付与されており、保守性が高い
ステータス区分 — JUSTS・NYUKBN・SIRKBN の区分コード値が TEXT() に明記されている

⚠️ 指摘事項

重要度	#	フィールド	指摘内容	修正案
🔴 高	1	JUNO（受注番号）	データ型が数値型（8 0）で定義されている。受注番号はコード値として扱うべきであり、数値演算の対象にならない。また先頭ゼロが保持されない。	10A（文字型10桁）への変更を推奨
🔴 高	2	JUDT / NKDT / INSDT / UPDDT	数値型（8 0）で YYYYMMDD を格納している。IBM i には L（日付型）があり、日付演算・妥当性チェックが自動化できる。	L 型（日付型、DATFMT(*ISO)）の採用を検討。既存システムとの互換性を考慮すること
🟡 中	3	KINGAK（金額）	DDS 上は 11 2（11桁2小数）だが、単価9桁×数量7桁の積は最大16桁になりうる。オーバーフローリスクがある。	15 2 程度に拡大を検討
🟡 中	4	TOKCD / HINCD	顧客マスタ・商品マスタへの参照整合性制約（REFCHK 等）が定義されていない。	可能であれば参照ファイルとの整合性チェックを検討
🟢 低	5	BIKO（備考）	文字60桁は用途によっては短い場合がある。	業務要件に応じて100桁程度への拡張を検討

2. JUCHURPG.rpg — RPG III プログラム

✅ 良い点

ヘッダコメント — プログラム名・説明・作成日・環境が明記されており、保守性が高い
インジケータ凡例 — *IN50・*IN70・*IN80・*INLR の意味が全てコメントで説明されている
サブルーチン分離 — 主ループから EXSR SRJUCH でサブルーチンを呼び出す構造になっており、処理が整理されている
カラム位置コメント — 各仕様書にカラム位置ガイドラインのコメントが付与されており、可読性が高い

⚠️ 指摘事項

重要度	#	箇所	指摘内容	修正案
🔴 高	1	F仕様書・I仕様書	F仕様書で E（外部記述）を指定しているにもかかわらず、I仕様書でフィールドの位置と名前を手動定義している（二重定義）。	E 指定の場合はI仕様書の詳細定義を削除し、DDSのフィールド名をそのまま使用する
🔴 高	2	C仕様書 ADD GKINGK TOTKGK	累積変数 TOTKGK が C仕様書内で宣言・初期化されていない。	E仕様書またはI仕様書で TOTKGK を初期化して定義する
🔴 高	3	O仕様書 OREPORT LR	O仕様書でレポートファイル REPORT を参照しているが、F仕様書に REPORT ファイルの定義がない。このままではコンパイルエラーになる。	F仕様書に FREPORT O F 132 PRINTER 等の出力ファイル定義を追加する
🟡 中	4	C仕様書 SETON 70	*IN70（確定レコード処理中フラグ）が SETOFF される箇所がない。一度オンになると以降の全レコードでフラグが立ち続ける。	SRJUCH の先頭で SETOFF 70 を実行し、毎レコードリセットする
🟡 中	5	C仕様書 SETON 80	*IN80（取消スキップフラグ）も同様に SETOFF される箇所がない。	SRJUCH の先頭で SETOFF 80 を実行する
🟡 中	6	ヘッダコメント	コメントに *IN50 = CHAIN失敗時と記載されているが、C仕様書内に CHAIN 命令が存在しない。コメントと実装が乖離している。	CHAIN 命令の追加、またはコメントの修正
🟢 低	7	O仕様書日本語リテラル	O仕様書の文字定数に日本語文字列（'税込合計金額累計'）が含まれており、DBCS（2バイト文字）の文字数・カラム幅に注意が必要。	DBCS 対応のフォーマットを確認し、Gリテラル（G'…'）の使用を検討する

3. JUCHUCL.clp — CL プログラム

✅ 良い点

処理ステップのコメント — 4ステップが明確にコメントで区切られており、処理の流れが分かりやすい
ジャーナリング — STRJRNPF によるジャーナル登録が含まれており、障害時のリカバリーに対応している
権限設定 — GRTOBJAUT で特定ユーザー（APPUSR）に権限を付与している

⚠️ 指摘事項

重要度	#	箇所	指摘内容	修正案
🔴 高	1	AUT(*CHANGE)	CRTPF の AUT パラメータが CHANGE になっている。PUBLIC に対して変更権限を与えることになり、セキュリティリスクがある。	AUT(*EXCLUDE) に変更し、必要なユーザーのみ個別に権限付与する
🔴 高	2	全体（エラー処理）	CRTPF・STRJRNPF・GRTOBJAUT いずれのコマンドにも MONMSG によるエラー監視がない。	各コマンドの直後に MONMSG MSGID(CPF0000) EXEC(GOTO ERREND) 等を追加する
🟡 中	3	MAXMBRS(*NOMAX)	メンバ数制限なしは管理上のリスク。通常の業務ファイルでは MAXMBRS(1) が推奨される。	MAXMBRS(1) に変更する
🟡 中	4	ADDPFM	DDSソースの管理を CL プログラム内で行っており、保守性を低下させる。	DDSソース管理はツールに委ね、CLはファイル作成以降の処理のみに絞ることを推奨
🟢 低	5	SIZE(10000 1000 3)	初期サイズ・増分は業務ボリュームの見積もりに依存する。	業務要件に基づいてサイズを見直す

4. 総合評価

評価軸	スコア
コーディング規約	★★★★☆ 4/5
セキュリティ	★★☆☆☆ 2/5
データ整合性	★★★☆☆ 3/5
保守性	★★★★☆ 4/5
完全性（コンパイル）	★★☆☆☆ 2/5
総合スコア	★★★☆☆ 3/5

🚨 最優先で対応すべき修正（重要度：高）

[JUCHURPG.rpg] F仕様書で E（外部記述）を使うなら I仕様書のフィールド手動定義を削除する
[JUCHURPG.rpg] O仕様書で参照している REPORT ファイルをF仕様書に追加する
[JUCHURPG.rpg] 累積変数 TOTKGK を E仕様書 / I仕様書で初期化定義する
[JUCHUCL.clp] AUT(*CHANGE) → AUT(*EXCLUDE) に変更する
[JUCHUCL.clp] 各CLコマンドに MONMSG エラー処理を追加する

💡 推奨される次のステップ

上記の指摘に基づいた修正済みソースの生成（Bob に依頼可能）
MONMSG を追加したCLプログラムの修正
RPGUnit テストケースの作成（サブルーチン SRJUCH の単体テスト）
受注番号 JUNO の文字型変更に伴うDDS・RPGの整合確認

・比較結果

DDS:
指摘箇所は両方とも似た箇所の指摘ではあるが、Premium Package for iではキー項目の形式やサイズに対する懸念点を指摘している。一方、CopilotではUNIQUEキー(JUNO)の採番管理について指摘するなど、指摘の観点が異なっている。おそらくCopilotではキー項目をそのままでした場合の懸念点であり、Premium Package for iではキー項目が運用上数字形式では対応しきれないと指摘しているように思われる。（IBM iの実運用的にはPremium Package for iの方式をとるケースが多いように考えられるが…）
ただ、最も重要な点である、桁数や配置位置の指摘に関しては両方とも至っていない。（EBCDICの日本語文字に対して、正常なカウントが出来ていない可能性がある）

RPG:
Copilot、Premium Package for iともに重要度が高い箇所の指摘はされている。想定よりもCopilotによるレビューができているため、確認のみであればCopilotでも問題なさそうに見受けられる。ただ、修正内容に関しての提示はPremium Package for iのほうが明確に優れていると言えるため、実際に修正するにあたってはPremium Package for iのほうが修正は容易ではある。

CL:
今回一番差異があった個所で、CopilotとPremium Package for iで指摘箇所がほとんど異なっていた。Copilotの指摘に関しては、再実行時の懸念やジャーナルが存在していないケースの指摘になっているのに対し、（コメント形式のような的外れな指摘箇所は存在するが…）Premium Package for iではジャーナルが存在していることを前提とし、またDDSやプログラムのセットアップと判断していることから、セキュリティリスクに対する指摘が主となっていた。

これはCopilotは繰り返し実行することを前提とした処理としてレビューしたのに対して、Premium Package for iはセットアップ処理と判断した差が出ているように見受けられる。（Premium Package for iの環境において、該当ライブラリでジャーナルが存在していたため）
今回のケースでは本CLプログラムは初回起動のみとなるのが適切であるため、Premium Package for iのほうが本質的な指摘としては正しいが、繰り返す前提であれば、Copilotの指摘は決して的外れな指摘ではない。こちらに関しては、Premium Package for iがシステム内部でジャーナルの存在有無を確認できるからこそジャーナルが存在している前提で可能な指摘とも捉えることができる。

DDSの修正とレビュー

DDSに関しては、明確に列数が異なっていたり、文字数のオーバーが見受けられたため、手動で修正を実施し、修正前後のファイルに対してIBM Bobでレビューを行いました。

・修正後DDSファイル

     A*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     A* ファイル名  : JUCHUPF
     A* 説明       : 受注物理ファイル（受注ヘッダ情報）
     A* 作成日     : 2025/07/01
     A* 備考       : IBM i / AS/400 DDS 固定形式
     A*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
     A                                      UNIQUE
     A          R JUCHUR                    TEXT('受注レコード')
     A*
     A* ---- キーフィールド ----
     A            JUNO           8  0        TEXT('受注番号')
     A*
     A* ---- 受注基本情報 ----
     A            JUDT           8  0        TEXT('受注日 YYYYMMDD')
     A            NKDT           8  0        TEXT('納期日 YYYYMMDD')
     A*
     A* ---- 顧客情報 ----
     A            TOKCD         10A          TEXT('顧客コード')
     A            TOKNM         40A          TEXT('顧客名')
     A            TOKTN         15A          TEXT('顧客担当者名')
     A*
     A* ---- 商品情報 ----
     A            HINCD         10A          TEXT('商品コード')
     A            HINNM         40A          TEXT('商品名')
     A            SUURYO         7  0        TEXT('受注数量')
     A            TANKA          9  2        TEXT('単価（小数2桁）')
     A            KINGAK        11  2        TEXT('金額＝数量×単価')
     A            ZEIRTS         3  1        TEXT('消費税率（例:10.0）')
     A            ZEIGAK         9  2        TEXT('消費税額')
     A            GKINGK        11  2        TEXT('税込合計金額')
     A*
     A* ---- ステータス・区分 ----
     A            JUSTS          1A           TEXT('受注状態 0:未処理+
     A                                             1:確')
     A            NYUKBN         1A           TEXT('入金区分 0:未入金+
     A                                             1:入')
     A            SIRKBN         1A           TEXT('仕入区分 0:未発注+
     A                                             1:発')
     A*
     A* ---- 担当者・部門 ----
     A            TANCD          6A          TEXT('担当者コード')
     A            TANNM         20A          TEXT('担当者名')
     A            BUMON          4A          TEXT('部門コード')
     A*
     A* ---- 備考・管理 ----
     A            BIKO          60A          TEXT('備考')
     A            INSDT          8  0        TEXT('登録日 YYYYMMDD')
     A            UPDDT          8  0        TEXT('更新日 YYYYMMDD')
     A*
     A* ---- キー定義 ----
     A          K JUNO

・レビュー結果

IBM Bobレビュー

DDSソースレビュー結果

対象ファイル：JUCHUPF（受注物理ファイル）／レビュー日：2025/07/01 ／環境：IBM i (AS/400) DDS 固定形式

1. DDSカラム定義（参照）

DDS物理ファイルの固定形式は以下のカラム配置に従います。

Col:  1    6   17          27    33 34-35   45
      |    A   | フィールド名 | 長さ |型|小数 | キーワード(TEXT等)

主要カラム:
  Col 17–26 : フィールド名（10文字）
  Col 27–32 : 長さ（6文字、数値は右詰め）
  Col 33    : データタイプ（A=文字、空=数値）
  Col 34–35 : 小数点以下桁数
  Col 45–80 : キーワード（TEXT等）

2. 原文に存在した問題点

① 長さカラムの1文字右ズレ（複数フィールド）

以下のフィールドで、長さ値が本来の Col 27–32 より1文字右（Col 28–）に記述されており、コンパイラが正しく解釈できない状態でした。

フィールド名	原文（長さ位置）	正しいCol	問題の影響
KINGAK	Col28 に 11	Col27	桁ズレによる型認識エラー
ZEIRTS	Col28 に 3	Col27	桁ズレによる型認識エラー
ZEIGAK	Col28 に 9	Col27	桁ズレによる型認識エラー
GKINGK	Col28 に 11	Col27	桁ズレによる型認識エラー
JUSTS	Col28 に 1	Col27	桁ズレ + TEXT未閉括弧
NYUKBN	Col28 に 1	Col27	桁ズレ + TEXT未閉括弧
SIRKBN	Col28 に 1	Col27	桁ズレ + TEXT未閉括弧
TANCD	Col28 に 6	Col27	桁ズレによる型認識エラー
BUMON	Col28 に 4	Col27	桁ズレによる型認識エラー
BIKO	Col28 に 60	Col27	桁ズレによる型認識エラー
INSDT	Col28 に 8	Col27	桁ズレによる型認識エラー
UPDDT	Col28 に 8	Col27	桁ズレによる型認識エラー

② TEXTキーワードの文字列未閉括弧（JUSTS / NYUKBN / SIRKBN）

以下の3フィールドで、TEXT内の日本語文字列が80桁を超えて行末で切れており、シングルクォートが閉じられていませんでした。これはコンパイルエラーの直接原因です。

A            JUSTS           1A          TEXT('受注状態 0:未処理 1:確
A            NYUKBN          1A          TEXT('入金区分 0:未入金 1:入
A            SIRKBN          1A          TEXT('仕入区分 0:未発注 1:発
↑ シングルクォートが閉じられていない → コンパイルエラー

3. 手修正版の評価

① 長さカラムのズレ修正

フィールド名	修正内容	評価
KINGAK	Col28→Col27 へ1文字詰め	✅ 修正済
ZEIRTS	Col28→Col27 へ1文字詰め	✅ 修正済
ZEIGAK	Col28→Col27 へ1文字詰め	✅ 修正済
GKINGK	Col28→Col27 へ1文字詰め	✅ 修正済
TANCD	Col28→Col27 へ1文字詰め	✅ 修正済
BUMON	Col28→Col27 へ1文字詰め	✅ 修正済
BIKO	Col28→Col27 へ1文字詰め	✅ 修正済
INSDT	Col28→Col27 へ1文字詰め	✅ 修正済
UPDDT	Col28→Col27 へ1文字詰め	✅ 修正済

② TEXTキーワードの継続行処理

手修正版では継続行インジケータ + を使用して文字列を次行に継続するDDSの正しい構文が採用されています。

A            JUSTS          1A           TEXT('受注状態 0:未処理+
A                                             1:確')
A            NYUKBN         1A           TEXT('入金区分 0:未入金+
A                                             1:入')
A            SIRKBN         1A           TEXT('仕入区分 0:未発注+
A                                             1:発')
↑ '+' による継続行 → ✅ DDSの正しい構文

✅ 継続行の方向性は正しく修正されています。

4. 残留する確認ポイント

⚠️ 以下の点については、SEU または RDi で実際のカラム位置を目視確認することを推奨します。

① 1文字文字型フィールドの 1A 記述

DDSでは長さ（Col 27–32）とデータタイプ（Col 33）は別カラムです。JUSTS・NYUKBN・SIRKBN の 1A が Col32 に 1、Col33 に A という正しい配置になっているか確認してください。

正しい配置イメージ:
Col: 27  28  29  30  31  32  33  34  35
          （空白スペース）        1   A  （小数なし）
↑ 長さ '1' は Col32（右詰め）、データタイプ 'A' は Col33

② 継続行のTEXTカラム開始位置

+ による継続行でテキストが Col 45 以降から始まっているか確認してください。Col 45 より前に文字があるとコンパイラが誤認識する場合があります。

5. 総評

手修正版は原文の主要な問題（長さカラムの桁ズレ・TEXT文字列の未閉括弧）を正しく修正できており、コンパイルが通る可能性は十分あります。

残留リスクは JUSTS・NYUKBN・SIRKBN の 1A のカラム位置のみです。SEU上でカラムルーラーを表示して目視確認することで問題を完全に排除できます。

※ 今後DDSを生成する際は、カラム位置の精度をより厳密に管理するよう改善します。ご迷惑をおかけしたことをお詫び申し上げます。

レビュー結果として、手修正版のファイルは修正前のDDSと異なり、カラム位置の修正・キーワードの長さがDDSの長さに収まるよう修正されたことが明確にわかります。なお、IBM Bobのタスクとしてもカラム位置に関して注意する回答がありました。

QDDSSRCのサイズ長など、意外な箇所でエラーになりうるので、実際にコンパイルする際には、SEUなどでチェックしてからコンパイルするのが望ましいかもしれません。

動作確認

RPG、CLについても修正を加えて実際に動作確認を実施しました。

・RPGファイル

     H*
     H* PGMNAME   :JUCHURPG
     H* EXPLAIN   : (JUCHUPF)    RPG III
     H* MAKEDATE  : 2025/07/01
     H*           : IBM   (AS/400) RPG III  (OPM)
     H*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
      *
      *
      *==================================================================
     FJUCHUPF IP  E           K        DISK
     FQPRINT  O   F     132     OF     PRINTER
      *==================================================================
     C*----------------------------------------------------------------
     C* MAIN
     C*----------------------------------------------------------------
     C                     Z-ADD0         TOTKGK 112
     C                     EXSR SRJUCH
      *
     C*----------------------------------------------------------------
     C* SUB SRJUCH
     C*----------------------------------------------------------------
     C           SRJUCH    BEGSR
      *
     C           JUSTS     IFEQ '1'
     C                     SETON                     70
     C           TOTKGK    ADD  GKINGK    TOTKGK 112
     C                     ENDIF
     C*
     C           JUSTS     IFEQ '9'
     C                     SETON                     80
     C                     ENDIF
     C*
     C                     ENDSR
      *==================================================================
     OQPRINT  T        LR
     O                         TOTKGK    31

・CLファイル

/*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*/
/* PROGRAM NAME : JUCHUCL                                           */
/* DESCRIPTION  : CL COMMAND SET FOR CREATING ORDER PHYSICAL FILE   */
/*                (JUCHUPF)                                         */
/* ENVIRONMENT  : IBM I (AS/400)                                    */
/* CREATED      : 2025/07/01                                        */
/*%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%*/
PGM

/*------------------------------------------------------------------*/
/* STEP 1: DDSソースメンバーの登録                                  */
/*   QDDSSRC に JUCHUPF メンバーを追加する                          */
/*   CPF7301 : メンバーが既存の場合は無視して続行                   */
/*------------------------------------------------------------------*/
ADDPFM FILE(JUTYUTST/QDDSSRC) MBR(JUCHUPF) +
        SRCTYPE(PF) +
        TEXT('ORDER PHYSICAL FILE DDS DEFINITION')
MONMSG MSGID(CPF7301)  /* メンバー既存は無視 */

/*------------------------------------------------------------------*/
/* STEP 2: 物理ファイルの作成                                       */
/*   MAXMBRS(*NOMAX) : メンバー数上限なし                           */
/*   SIZE(10000 1000 3): 初期10,000レコード、1,000増分×3回          */
/*------------------------------------------------------------------*/
CRTPF    FILE(JUTYUTST/JUCHUPF) +
          SRCFILE(JUTYUTST/QDDSSRC) +
          SRCMBR(JUCHUPF) +
          MAXMBRS(*NOMAX) +
          SIZE(10000 1000 3) +
          AUT(*EXCLUDE) +
          TEXT('ORDER PHYSICAL FILE')
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERREND))

/*------------------------------------------------------------------*/
/* STEP 3: ジャーナルレシーバーおよびジャーナルの作成               */
/*   MYJRN が未存在の場合は本ステップで作成する                     */
/*   CPF70xx : 既存の場合は無視                                     */
/*------------------------------------------------------------------*/
CRTJRNRCV JRNRCV(JUTYUTST/MYJRNRCV) +
           TEXT('JOURNAL RECEIVER FOR JUCHUPF')
MONMSG MSGID(CPF7010)  /* レシーバー既存は無視 */

CRTJRN   JRN(JUTYUTST/MYJRN) +
          JRNRCV(JUTYUTST/MYJRNRCV) +
          TEXT('JOURNAL FOR JUTYUTST FILES')
MONMSG MSGID(CPF7002)  /* ジャーナル既存は無視 */

/*------------------------------------------------------------------*/
/* STEP 4: ジャーナル開始                                           */
/*   JUCHUPF のファイル変更をジャーナリング対象とする               */
/*------------------------------------------------------------------*/
STRJRNPF FILE(JUTYUTST/JUCHUPF) +
          JRN(JUTYUTST/MYJRN)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERREND))

/*------------------------------------------------------------------*/
/* STEP 5: オブジェクト権限の付与                                   */
/*   アプリケーションユーザー APPUSR に変更権限を付与               */
/*------------------------------------------------------------------*/
GRTOBJAUT OBJ(JUTYUTST/JUCHUPF) +
           OBJTYPE(*FILE) +
           USER(APPUSR) +
           AUT(*CHANGE)
MONMSG MSGID(CPF0000) EXEC(GOTO CMDLBL(ERREND))

/*------------------------------------------------------------------*/
/* 正常終了                                                         */
/*------------------------------------------------------------------*/
GOTO CMDLBL(PGMEND)

/*------------------------------------------------------------------*/
/* 異常終了                                                         */
/*   呼び出し元に異常終了をエスケープメッセージで通知               */
/*------------------------------------------------------------------*/
ERREND:
SNDPGMMSG MSG('JUCHUCL ENDED ABNORMALLY. CHECK JOBLOG.') +
           MSGTYPE(*ESCAPE)

/*------------------------------------------------------------------*/
/* プログラム終了                                                   */
/*------------------------------------------------------------------*/
PGMEND:
ENDPGM

・結果

合計金額が出力されましたが、数値形式にもなっておらず、この状態では実務には使用できません。
しかし、「一般的な受注プログラム」という曖昧な指示でも必要なソースは一式作成してくれましたので、RPG初心者であれば参考にできるのではないでしょうか。

プログラムから仕様書の作成

IBM Bobにプログラムから仕様書を作成してもらいます。
仕様書を作成するにあたって、別途AGENTS.mdを以下の定義で作成してもらいました。

あなたは、業務システムの要件定義・設計・保守に精通したシニアシステムエンジニアです。
以下に提供するソースコード、既存仕様書、画面情報、業務説明などを解析し、プログラミング経験がない業務担当者でも
処理内容を理解し、仕様が正しいかレビューできるレベルの仕様書を作成してください。

目的
単なる「ソースコードの日本語訳」ではなく、
* システムが何を受け取るのか
* 何を確認するのか
* どのような条件で判断するのか
* どのような計算・編集をするのか
* 何のデータを参照するのか
* 何のデータを更新するのか
* 最終的に何を出力するのか
* エラーや例外の場合どうなるのか
を、非エンジニアでも追跡できる形にしてください。

1. 機能概要 〜 14. 業務担当者向けレビュー項目（詳細は本文参照）

重要ルール
1. ソースコードに存在しない仕様を勝手に作らない。
2. 判断できない内容は「要確認」とする。
3. 「事実」「推測」「提案」を明確に区別する。
4. プログラム変数名だけで説明しない。
5. 可能な限り業務用語へ変換する。
6. 条件分岐は文章だけでなく表にする。
7. 複雑な条件は決定表にする。
8. 正常系だけでなく異常系も記載する。
9. コードの説明ではなく「システムの振る舞い」を説明する。
10. 非エンジニアが「この動きで正しい/間違っている」と判断できる粒度を最優先する。

アウトプットはHTML形式で出力

箇条書きで実施したい内容を記載しており、以下の構成で仕様書を出力するよう指示しています。

機能概要
入力情報
処理フロー
処理詳細
判定条件・業務ルール
決定表
計算・編集ルール
データ参照・更新
エラー・例外処理
具体例
影響範囲
技術情報
要確認事項（重視して確認するよう指示）
業務担当者向けレビュー項目

また、作成に当たって文章のルールを定め、アウトプットを記載することでスムーズな作成を行います。

作成した仕様書

業務仕様書 ― 受注ファイル読込・集計処理

プログラム名: JUCHURPG　／　対象ファイル: JUCHUPF　／　環境: IBM i (AS/400) RPG III OPM
作成日: 2025/07/01　／　仕様書作成日: 2025/07/07

1. 機能概要

項目	内容
この機能の目的	受注データを全件読み込み、受注状態が「確定」のレコードについて税込合計金額を累計集計してレポートへ出力すること。
いつ実行されるか	プログラム内に起動トリガーの明示なし。バッチ処理として手動またはジョブスケジューラから実行されると推測される。⚠️ 要確認
誰・何が実行するか	IBM i (AS/400) 上のバッチジョブ。実行ユーザはアプリ用プロファイル（APPUSR）が想定されている。
何を入力として受け取るか	受注物理ファイル（JUCHUPF）に格納された全受注レコード（受注番号順）。
最終的に何をする処理か	受注ファイルを先頭から1件ずつ読み込み、受注状態が「確定（=1）」のレコードの税込合計金額を積み上げる。全件処理が終わった後、その累計金額をレポート（REPORT）に出力する。受注状態「取消（=9）」はスキップ対象として扱う。

⚠️ このプログラムは受注ファイルの読み込みと集計出力のみを行います。受注データの登録・変更・削除は行いません。

2. 入力情報

項目名	業務上の意味	必須/任意	入手元	備考
受注番号（JUNO）	受注を一意に識別する番号。8桁の整数。	必須	受注物理ファイル（JUCHUPF）	ファイルのキーフィールド。一意制約あり。受注番号順に読み込まれる。
受注日（JUDT）	受注が発生した日付。YYYYMMDD形式の8桁数値。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
納期日（NKDT）	商品の納入予定日。YYYYMMDD形式の8桁数値。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
顧客コード（TOKCD）	顧客を識別するコード。最大10文字。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
顧客名（TOKNM）	顧客の名称。最大40文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
顧客担当者名（TOKTN）	顧客側の担当者名。最大15文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
商品コード（HINCD）	商品を識別するコード。最大10文字。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
商品名（HINNM）	商品の名称。最大40文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
受注数量（SUURYO）	受注された商品の個数。7桁の整数。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない（金額はGKINGKフィールドで別途保持）。
単価（TANKA）	商品1個あたりの価格。小数2桁まで保持（例: 98,000.00円）。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
金額（KINGAK）	税抜の受注金額（数量×単価）。小数2桁まで保持。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
消費税率（ZEIRTS）	適用される消費税率（例: 10.0%）。小数1桁まで保持。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
消費税額（ZEIGAK）	消費税の金額。小数2桁まで保持。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
税込合計金額（GKINGK）	消費税込みの合計金額（金額＋消費税額）。集計処理で唯一使用する金額項目。	必須	受注物理ファイル（JUCHUPF）	受注状態=確定のレコードについて累計加算する。
受注状態（JUSTS）	受注の現在の処理状態を示す1文字の区分値。集計対象かどうかの判断に使用する。 `0`: 未処理／ `1`: 確定／ `2`: 出荷済／ `9`: 取消	必須	受注物理ファイル（JUCHUPF）	処理振り分けの判定キー。
入金区分（NYUKBN）	入金状況。`0`: 未入金／ `1`: 入金済	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
仕入区分（SIRKBN）	仕入（発注）状況。`0`: 未発注／ `1`: 発注済	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
担当者コード（TANCD）	社内担当者を識別するコード。最大6文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
担当者名（TANNM）	社内担当者の名前。最大20文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
部門コード（BUMON）	担当部門を識別するコード。最大4文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
備考（BIKO）	受注に関する自由記述メモ。最大60文字。	任意	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
登録日（INSDT）	レコードが最初に登録された日付。YYYYMMDD形式。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。
更新日（UPDDT）	レコードが最後に更新された日付。YYYYMMDD形式。	必須	受注物理ファイル（JUCHUPF）	本集計処理では直接使用しない。

3. 処理フロー

【開始】プログラム起動・受注ファイルをオープン
        ↓
P1: 受注ファイルから1レコードを受注番号順に読み込む
        ↓
P2: ファイルの終わり（全件読み終えた）か？
    → はい: P6（出力）へ
    → いいえ: P3へ続く
        ↓ いいえ（まだレコードあり）
P3: 受注状態を確認し処理を振り分ける
    ・確定（=1）       → P4（集計加算）へ
    ・取消（=9）       → P5（スキップ）へ
    ・その他（0:未処理 / 2:出荷済）→ 何もしない（P1へ戻る）
        ↓ 確定（=1）の場合
P4: 税込合計金額を累計に加算する
    【累計金額】 = 【前の累計金額】 + 【このレコードの税込合計金額】
    処理中フラグ（内部指標70番）をONにする
        ↓（P1へ戻る）      ↓ 取消（=9）の場合
P5: スキップフラグ（内部指標80番）をONにする
    ※集計への加算は行わない
        ↓（P1へ戻る）
        ↓ ファイル終端に達した場合
P6: レポート（REPORT）に税込合計金額の累計を「税込合計金額累計」として出力する
        ↓
【終了】プログラム正常終了

4. 処理詳細

処理No	処理名	処理内容	参照データ	更新データ	NG時の動作
P1	レコード読み込み	受注物理ファイル（JUCHUPF）からレコードを1件ずつ受注番号（昇順）で自動読み込みする。プライマリファイル指定（IP）のため、プログラムのメインループと連動して自動的に全件処理される。	受注物理ファイル（JUCHUPF）	なし	ファイル未存在時の処理は明示なし。⚠️ 要確認
P2	ファイル終端チェック	全レコードを読み終えたとき（ラストレコード指標 *INLR がON）に出力処理（P6）へ移行する。	なし（ファイル終端検知）	なし	対象レコードが0件の場合、累計は0のままレポート出力される。
P3	受注状態による振り分け	受注状態（JUSTS）の値を確認し、以下のとおり処理を振り分ける。・`'1'`（確定）: P4（集計加算）へ・`'9'`（取消）: P5（スキップ）へ・`'0'`（未処理）/`'2'`（出荷済）: 何もせず次のレコードへ	受注状態（JUSTS）	なし	定義外の区分値が入っていた場合、いずれにも合致せず無視される（エラーメッセージなし）。
P4	確定受注の金額集計	受注状態が確定（`'1'`）のレコードについて、当該レコードの税込合計金額（GKINGK）を累計変数（TOTKGK）に加算する。式: TOTKGK = TOTKGK + GKINGK 加算後、処理中フラグ（指標70番）をONにする。	税込合計金額（GKINGK）	税込合計累計（TOTKGK）、指標70番（*IN70）	累計がフィールド桁数（11桁2小数）を超えた場合の処理は明示なし。⚠️ 要確認
P5	取消レコードのスキップ	受注状態が取消（`'9'`）のレコードについて、スキップフラグ（指標80番）をONにする。集計への加算は行わない。	受注状態（JUSTS）	指標80番（*IN80）	なし（スキップのみ）
P6	レポート出力	全レコード処理完了後（*INLR ON）に、税込合計金額の累計（TOTKGK）をレポートファイル（REPORT）へ出力する。出力項目は「税込合計金額累計」の1行のみ。	税込合計累計（TOTKGK）	REPORTファイル	出力先（REPORT）が存在しない場合の処理は明示なし。⚠️ 要確認

5. 判定条件・業務ルール

No	業務ルール	処理内容	備考
R-01	受注状態が「確定（=1）」の場合、税込合計金額を累計に加算する。	TOTKGK = TOTKGK + GKINGK 処理中フラグ（*IN70）をONにする。	サンプルデータでは受注番号20250001・20250002が該当。
R-02	受注状態が「取消（=9）」の場合、その受注は集計に含めない。	スキップフラグ（*IN80）をONにする。金額加算はしない。	サンプルデータでは受注番号20250005が該当。
R-03	受注状態が「未処理（=0）」または「出荷済（=2）」の場合、何もしない（集計対象外）。	プログラムの処理対象に含まれない。次のレコードへ進む。	コード上ではこれらの区分に対する明示的な分岐は存在しない。デフォルトで無視される動作となる。
R-04	全レコードの読み込みが完了した時点で、累計をレポートに出力する。	*INLR がONになったタイミングでREPORTへ出力。	途中出力（ページ途中での合計出力）は行わない。

⚠️ 受注状態「出荷済（=2）」は集計対象外です。出荷済みの受注を集計に含める業務上の意図があるかどうかを確認してください。

6. 決定表

受注状態による処理の振り分け

条件・結果	ケース1	ケース2	ケース3	ケース4
受注状態の値	`'1'` 確定	`'9'` 取消	`'0'` 未処理 / `'2'` 出荷済	上記以外の値
税込合計金額を累計に加算	○ する	× しない	× しない	× しない
処理中フラグ（*IN70）ON	○ する	× しない	× しない	× しない
スキップフラグ（*IN80）ON	× しない	○ する	× しない	× しない
エラー・警告出力	なし	なし	なし	なし（無視）⚠️ 要確認

⚠️ 定義外の区分値（ケース4）が存在した場合、エラーにならず静かに無視されます。業務運用上、このような状況が発生し得るか確認が必要です。

7. 計算・編集ルール

No	対象項目	計算・編集方法	条件	具体例
C-01	税込合計金額の累計（TOTKGK）	受注状態=確定（=1）のレコードの税込合計金額（GKINGK）を順次加算する。 TOTKGK = TOTKGK + GKINGK 累計フィールドは11桁2小数（最大9,999,999,999.99）。	受注状態 = `'1'`（確定）のレコードのみ	確定レコードが2件（539,000.00 と 165,000.00）の場合: 合計 = 704,000.00
C-02	受注ファイル内の金額（KINGAK）	金額 = 数量（SUURYO） × 単価（TANKA） ※この計算は本プログラムでは行わない。ファイルに格納済みの値を読み込むのみ。	ファイル登録時に算出済み	数量5 × 単価98,000.00 = 490,000.00
C-03	受注ファイル内の消費税額（ZEIGAK）	消費税額 = 金額（KINGAK） × 消費税率（ZEIRTS）÷ 100 ※この計算は本プログラムでは行わない。ファイルに格納済みの値を読み込むのみ。	ファイル登録時に算出済み	490,000.00 × 10.0% = 49,000.00
C-04	受注ファイル内の税込合計金額（GKINGK）	税込合計金額 = 金額（KINGAK） + 消費税額（ZEIGAK） ※この計算は本プログラムでは行わない。ファイルに格納済みの値を読み込むのみ。	ファイル登録時に算出済み	490,000.00 + 49,000.00 = 539,000.00
C-05	累計金額の丸め・切り捨て	コード上に丸め・切り捨て・切り上げの明示なし。RPG IIIの加算命令（ADD）はそのままの値を使用する。	―	小数2桁のまま累計される。⚠️ 要確認

⚠️ GKINGK（税込合計金額）がゼロ（0.00）または空白（未設定）のレコードに対して加算した場合の影響は、コードには明示されていません。

8. データ参照・更新

データ名	物理ファイル名	操作	使用目的	主な条件
受注物理ファイル	MYLIB/JUCHUPF	参照（読み込み）	受注状態を確認し、確定受注の税込合計金額を集計する。	全件読み込み（受注番号順）
レポートファイル	REPORT（ライブラリ名・ファイルタイプ不明）	出力（書き込み）	税込合計金額の累計を出力する。	ファイル終端到達時（*INLR ON）のみ

⚠️ REPORTファイルの実体（ライブラリ名、ファイル形式、プリンタ出力か画面出力か）がソースコードのO仕様書から確認できません。別途確認が必要です。要確認

9. エラー・例外処理

明示されているエラー処理

発生条件	システムの動作	メッセージ	処理継続/中止
（なし）	ソースコード内に明示的なエラー処理は記述されていません。	―	―

明示されていないエラー（潜在リスク）

No	発生し得る状況	現在のコード上の動作	処理継続/中止	リスク度
E-01	受注ファイル（JUCHUPF）が存在しない、またはオープンできない	IBM i のシステムレベルでエラーが発生するが、プログラム内での捕捉処理はなし。	中止（異常終了）	🔴 高
E-02	税込合計金額（GKINGK）が未入力（0）のレコードがある	0が加算されるが、正常扱いで処理が続く。金額0の受注が正しいかは確認不能。	継続	🟡 中
E-03	累計金額（TOTKGK）が最大桁数（11桁2小数 = 9,999,999,999.99）を超えるほど件数が多い	RPG III の ADD命令でオーバーフローが発生する可能性あり。対処なし。	異常終了の可能性あり	🔴 高
E-04	受注状態（JUSTS）に定義外の値（例: `'3'`、`'X'`）が入っている	いずれの分岐にも入らず、そのレコードは無視される。エラーメッセージなし。	継続（無視）	🟡 中
E-05	レポートファイル（REPORT）に出力できない（スプールファイルのエラー等）	IBM i のシステムレベルでエラーが発生するが、プログラム内での捕捉処理はなし。	中止（異常終了）の可能性あり	🔴 高
E-06	受注ファイルが0件の場合	ループが1回も実行されず、累計0のままレポートへ出力される。	継続（0出力）	🟢 低

10. 具体例

【正常ケース】サンプルデータ5件を処理した場合

受注番号	顧客名	受注状態	税込合計金額	集計対象？	累計金額
20250001	株式会社サンプル商事	1: 確定	539,000.00円	○ 加算	539,000.00円
20250002	有限会社田中工業	1: 確定	165,000.00円	○ 加算	704,000.00円
20250003	東西システムズ株式会社	0: 未処理	264,000.00円	× スキップ（処理なし）	704,000.00円（変化なし）
20250004	北海道物産株式会社	2: 出荷済	93,500.00円	× スキップ（処理なし）	704,000.00円（変化なし）
20250005	株式会社サンプル商事	9: 取消	115,500.00円	× スキップ（取消フラグON）	704,000.00円（変化なし）
▶ レポート出力結果（税込合計金額累計）					704,000.00円

【境界値ケース】確定受注が0件の場合

全レコードの受注状態が '0'（未処理）または '9'（取消）のみの場合、累計金額は 0.00円 としてレポートに出力される。

【異常ケース】未定義の受注状態が含まれる場合

受注状態に '3' などの定義外の値があった場合、そのレコードは何の処理もされず、エラーも出ずに無視される。集計結果への影響はないが、データ異常として検知されない。

11. 影響範囲

種別	名称	確認区分	備考
物理ファイル（DB）	MYLIB/JUCHUPF（受注物理ファイル）	コード確認済み	読み込みのみ。更新なし。
出力ファイル	REPORT（税込合計金額累計レポート）	コード確認済み	ファイルタイプ・ライブラリ不明。⚠️ 要確認
CLプログラム	JUCHUCL（ファイル作成用CL）	コード確認済み	本RPGの前提ファイルを作成するCLコマンド集。本RPGの直接呼び出し元ではない可能性あり。⚠️ 要確認
バッチジョブ	本プログラムを呼び出すジョブスケジュール	推測	ソースコード内に呼び出し元の記述なし。
画面	（なし）	コード確認済み	対話型画面は使用しない。
外部IF	（なし）	コード確認済み	外部システムとのインターフェースなし。
後続処理	レポート出力後の処理	推測	レポート（REPORT）の内容を利用する後続処理が存在する可能性あり。

12. 技術情報

項目	内容
プログラム名	JUCHURPG
言語・形式	RPG III 固定形式（OPM: Original Program Model）
動作環境	IBM i (AS/400)
サブルーチン	SRJUCH（受注レコード処理サブルーチン：受注状態の判定と集計）
入力ファイル	MYLIB/JUCHUPF（受注物理ファイル）― プライマリファイル（IP）、キー順（K）、ディスクファイル
出力ファイル	REPORT（レポートファイル）― ファイル種別・ライブラリ不明 ⚠️ 要確認
ライブラリ	MYLIB
使用指標	IN70（確定レコード処理中フラグ）、IN80（取消レコードスキップフラグ）、*INLR（ラストレコード指標）
累計変数	TOTKGK（税込合計金額累計、11桁2小数）
呼び出し元	不明（ソースコードに記述なし）⚠️ 要確認
呼び出し先	なし
ジャーナル	MYLIB/MYJRN（ファイル変更のジャーナリング。CLで設定。読み込みのみのため本プログラム実行では記録なし）
ファイル作成CL	JUCHUCL（MYLIB/JUCHUPF の作成・権限設定を行うCL）

13. 要確認事項

No	要確認事項	コード上の現在の動作	確認したいこと	重要度
Q-01	「出荷済（=2）」の受注は集計対象外で正しいか	受注状態=2のレコードはいずれの分岐にも入らず、集計対象外となる。	出荷済みの受注も確定受注と同様に集計に含めるべきではないか。業務要件の確認が必要。	🔴 高
Q-02	「未処理（=0）」の受注は集計対象外で正しいか	受注状態=0のレコードはいずれの分岐にも入らず、集計対象外となる。	未処理のレコードは処理待ちであるが、集計から除外して問題ないか確認が必要。	🔴 高
Q-03	累計金額の桁数は足りているか	累計変数（TOTKGK）は11桁2小数（最大9,999,999,999.99円）。件数が多い場合オーバーフローの可能性あり。	実運用での最大件数・最大金額を確認し、桁数が十分かを検証する必要がある。	🔴 高
Q-04	REPORTファイルの実体は何か	O仕様書に「OREPORT」と記述されているが、ライブラリ・ファイル形式（プリンタ/DB/スプール）が不明。	REPORTの正体を確認する必要がある（印刷ファイル？スプールファイル？別物理ファイル？）。	🔴 高
Q-05	処理中フラグ（IN70）とスキップフラグ（IN80）の使用目的	IN70 は確定レコード処理時にON、IN80 は取消レコード時にONにされるが、その後の利用箇所がコード内に見当たらない。	これらの指標を参照している別処理・後続処理が存在するか確認が必要。または使用されていない未使用コードの可能性あり。	🔴 高
Q-06	本プログラムの起動タイミング・起動元は何か	コード内に起動元の記述なし。	日次バッチか、月次バッチか、または手動起動か。呼び出し元のCLやジョブスケジュールを確認する。	🟡 中
Q-07	定義外の受注状態が混入した場合の扱い	コード上ではいずれの分岐にも入らず、エラーなしで無視される。	データ品質異常として検知する仕組みが必要か。または現行業務では定義外の値は絶対に入らないという前提か。	🟡 中
Q-08	税込合計金額（GKINGK）が0またはマイナスのレコードの扱い	コード上はチェックなしで加算処理が行われる（0やマイナスもそのまま加算）。	金額0の受注、またはマイナス金額（値引き・返品）が業務上存在するか確認が必要。	🟡 中
Q-09	集計の対象期間（日付絞り込み）はないか	コード上は全件を対象としており、受注日・登録日による絞り込みは一切行っていない。	全期間の確定受注を合計する仕様で正しいか。特定期間（例: 今月分のみ）に絞る必要はないか。	🟡 中
Q-10	顧客単位・部門単位の集計は不要か	コード上は受注全体の単一累計のみ。顧客別・部門別・担当者別の内訳集計はなし。	業務上、全体合計のみで十分か確認が必要。	🟢 低
Q-11	受注ファイルのエラー時（ファイル未存在等）の対処は不要か	明示的なエラー処理なし。IBM iのシステムエラーに委ねる形。	エラー発生時に運用担当者への通知や代替動作が必要か確認が必要。	🟡 中
Q-12	消費税率が複数（8%、10%等）混在する場合の扱い	コード上では税率を参照せず、ファイルのGKINGKをそのまま加算するため、税率が違っても同一に集計される。	軽減税率（8%）適用品目が含まれる場合に税率別の集計が必要かどうか確認が必要。	🟡 中

14. 業務担当者向けレビュー項目

以下の質問に 「はい/いいえ」または補足説明 でご回答ください。ソースコードを読む必要はありません。

【集計対象】 受注状態が「確定（=1）」のレコードのみを集計対象とする仕様で正しいですか？
【集計除外】 受注状態が「出荷済（=2）」のレコードを集計対象外（スキップ）とする仕様で正しいですか？
【集計除外】 受注状態が「未処理（=0）」のレコードを集計対象外（スキップ）とする仕様で正しいですか？
【取消処理】 受注状態が「取消（=9）」のレコードを集計に含めない仕様で正しいですか？
【期間絞り込み】 受注日・登録日に関係なく全期間の確定受注を合計する仕様で正しいですか？（期間指定は不要ですか？）
【集計単位】 顧客別・部門別・担当者別の内訳は不要で、全体の合計金額1つだけ出力する仕様で正しいですか？
【金額】 集計に使用する金額は「消費税込みの合計金額」で正しいですか？（税抜金額ではありませんか？）
【消費税率混在】 軽減税率（8%）対象の商品と通常税率（10%）の商品が混在する場合でも、税率を区別せず合算する仕様で正しいですか？
【金額ゼロ・マイナス】 金額がゼロまたはマイナス（返品・値引き等）の受注レコードは存在しますか？存在する場合、集計に含めて問題ないですか？
【0件処理】 確定受注が1件もない場合に、レポートへ「0.00円」と出力する仕様で正しいですか？
【データ異常】 受注状態フィールドに想定外の値（0・1・2・9以外）が入っていた場合に、エラーを出さず無視する仕様で正しいですか？
【レポート】 このプログラムが最終的に出力する「税込合計金額累計」は、どのような帳票・ファイルに出力される想定ですか？（プリンタ帳票？画面表示？別ファイルへの書き込み？）
【起動タイミング】 このプログラムはいつ実行されますか？（日次バッチ？月次バッチ？手動実行？）
【実行権限】 実行ユーザが「APPUSR」のみに限定されていますが、他のユーザが実行する必要はありますか？
【エラー通知】 処理中にエラーが発生した場合、担当者へ通知する仕組みが必要ですか？

今回のケースですと、あらかじめ項目を指定しており、また出力してほしい内容の指定が明示化できていたため、詳細な仕様書が出力することができました。
本プログラムのメインがテーブル定義とRPGプログラムのみでありますが、一部レビュー時に出てきた内容と重複する箇所も存在します。
プログラムのレビューを受けて修正を行ったうえで、こちらで指摘されている個所を個別に修正することで、プログラムの完成度を上げることが出来そうです。

※当記事の著作権はIBMに帰属します。詳細はこちらを参照ください。

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

IBM Bobを使用した受注データ作成＋仕様書の作成（RPG III）

IBM RiSING2026 チーム成果物：受注データプログラム作成レポート

目次

はじめに

やりたいこと

AGENTS.mdに関して

出力結果

・DDSファイル

・RPGファイル

・CLファイル

・テスト用データ

コードレビュー

【DDSレビュー】

【RPGレビュー】

【CLレビュー】

対象ファイル一覧

1. JUCHUPF.dds — DDS 物理ファイル

2. JUCHURPG.rpg — RPG III プログラム

3. JUCHUCL.clp — CL プログラム

4. 総合評価

・比較結果

DDSの修正とレビュー

・修正後DDSファイル

・レビュー結果

DDSソース レビュー結果

1. DDSカラム定義（参照）

2. 原文に存在した問題点

3. 手修正版の評価

4. 残留する確認ポイント

5. 総評

動作確認

・RPGファイル

・CLファイル

・結果

プログラムから仕様書の作成

業務仕様書 ― 受注ファイル読込・集計処理

目次

1. 機能概要

2. 入力情報

3. 処理フロー

4. 処理詳細

5. 判定条件・業務ルール

6. 決定表

受注状態による処理の振り分け

7. 計算・編集ルール

8. データ参照・更新

9. エラー・例外処理

明示されているエラー処理

明示されていないエラー（潜在リスク）

10. 具体例

【正常ケース】サンプルデータ5件を処理した場合

【境界値ケース】確定受注が0件の場合

【異常ケース】未定義の受注状態が含まれる場合

11. 影響範囲

12. 技術情報

13. 要確認事項

14. 業務担当者向けレビュー項目

DDSソースレビュー結果