はじめに
当チームでは、ファイルレイアウト定義だけを素材にして、同一の共通プロンプトを6種類のAIに投げ、どれだけ使える仕様書が出力されるか検証しました。
本章では「どのAIがどんな特性を持つか」「どのシーンに向くか」を整理することを目的としています。
AIを使って仕様書を作ろうとしている方の参考となれば幸いです。
対象読者：IBM i（AS/400）の保守・開発に携わる方、または生成AIを使って設計工程を効率化したい方
本検証は2026年6月に行っています。
お題 受注入力プログラムの仕様書作成
対象システム
| 項目 | 内容 |
|---|---|
| 環境 | IBM i（AS/400） |
| 言語 | RPG III（RPG/400） |
| PGM概要 | 得意先コードを入力 → 受注明細（品目コード・単価・数量）を最大5行入力 → 受注ファイルへ登録 |
| 画面構成 | 2画面構成（入力画面：得意先選択 ／ 明細画面：サブファイル5行） |
使用したAI
| AI | 出力形式(今回出力させた形式) |
|---|---|
| IBM Bob | Markdown |
| Claude | Word / Excel / Markdown |
| ChatGPT | Excel |
| Microsoft 365 Copilot | Excel |
| Gemini | Excel |
| Gemini Notebook | チャット(出力内容をExcelに整形) |
以降、IBM Bobを「Bob」、Microsoft 365 Copilotを「Copilot」と表記します。
AIに渡した素材
用意した素材はファイルレイアウト定義()のみ。
| ファイルID | ファイル名 | レコードID | 役割 |
|---|---|---|---|
| JHEDRP | 受注ファイル（ヘッダー） | JHEDRR | 受注ヘッダー登録 |
| JDETLP | 受注ファイル（明細） | JDETLR | 受注明細登録 |
| TOKMEP | 得意先マスター | TOKMER | 得意先コード照会 |
| HINMEP | 品目マスター | HINMER | 品目情報照会 |
Markdownファイル:シンプルな記号を使って文字の装飾や構造を表現できる、中身が文字だけのテキストファイル
使用した共通プロンプト
以下のプロンプトをすべてのAIに投げました。ファイルレイアウトのMarkdownファイルを添付（またはテキストで貼り付け）し、同一条件で比較しています。
IBMiのRPGⅢで受注入力プログラムを作成したい
下記仕様を基に仕様書を作成して
使用するファイルは以下を参照すること
"参照先パス(各々で指定)\ファイルレイアウト定義.md"
◆仕様
・画面遷移
第一画面(指示画面)⇒第二画面(明細画面)
・第一画面
得意先コードを入力する
実行キーで第二画面へ遷移
・第二画面
サブファイルを5行書き出し、品目コード、販売単価、数量を入力する
実行キーで品目名や仕入先、金額(販売単価×数量)を表示
※品目コード、販売単価、数量は常に変更可能で、実行キーを押下するたびに品目名や仕入先、
金額(販売売価×数量)を再表示
F5キーで入力値に問題がなければ受注ファイル(ヘッダーと明細)にデータを登録
※実行キーとF5キーはどちらもバリデーションチェックを行なう
各AIの生成結果
各AI比較表
| AI | 出力ボリューム | 形式 | 強み | 特徴 | 課題 |
|---|---|---|---|---|---|
| Bob | 約1,580行 | Markdown | フロー図、テスト仕様、DDS骨格、非機能要件 | RPG詳細設計レベルまで網羅 | レイアウト精度に課題、過剰補完あり |
| Claude | 15～20頁 | Word/Excel/MD | RPG技術仕様、Mermaid図、画面イメージ | 項目定義・処理フローの精度が高い | テスト仕様は省略傾向 |
| ChatGPT | 10～15頁 | Excel | バランス型、表形式、入力チェック | 登録処理を分かりやすく整理 | 一部項目が未記載 |
| Copilot | 10～15頁 | Excel | 項目定義、データ構造整理 | Excel向け仕様整理が得意 | 技術詳細は少なめ |
| Gemini | 10～15頁 | Excel | ファイル設計、入力チェック | チェック項目の網羅性が高い | フロー・DDS出力は弱い |
| Gemini Notebook | 5～8頁 | Excel | 資料要約、確認事項抽出 | レビュー観点の抽出が得意 | 仕様書生成量は少ない |
出力ボリューム:BobはMarkdown換算、それ以外はExcel換算
Claudeの評価は Opus の出力を対象としています（Sonnetの出力は4-2-2を参照）
各AIの課題
① Bob — 画面項目IDの不統一（過剰補完）
取引先マスターの項目IDを、ファイル定義と異なる名前で補完してしまった
✅ 元のファイルレイアウト定義（取引先マスター TOKMEP / TOKMER）
| 項目ID | 項目名 | 型・桁 |
|---|---|---|
| TOTKCD | 取引先コード | CHAR(6) |
| TOTKNM | 取引先名 | CHAR(40) |
| TOTKNK | 取引先名カナ | CHAR(40) |
| TOADRS | 住所 | CHAR(60) |
| TODLFL | 削除フラグ | CHAR(1) |
❌ Bob が出力した画面項目定義（第一画面 入力・出力項目）
| 項目名 | 項目ID | 行 | 列 |
|---|---|---|---|
| 得意先コード |
|
5 | 21 |
| 得意先名 |
|
7 | 21 |
⚠️ 何が問題か
ファイルの正式IDは TOTKCD / TOTKNM だが、Bobは TOKCD / TOKNM という存在しない短縮IDを独自に命名してしまった。
RPG III の CHAIN 命令でこのIDをそのままコピペすると、フィールド名不一致でコンパイルエラーになる。
② Bob — 受注番号採番を未定義サブルーチンで過剰補完
ファイルレイアウト定義には採番ロジックの記載なし → AIが GETONO を勝手に補完
✅ 元のファイルレイアウト定義（受注ファイルヘッダー JHEDRP / JHEDRR）
| 項目ID | 項目名 | 型・桁 |
|---|---|---|
| JHBANG | 受注番号 | CHAR(8) |
| JHJYDT | 受注日 | NUMERIC(8,0) |
| JHTOKC | 取引先コード | CHAR(6) |
JHBANG は CHAR(8) と型・桁のみ定義。採番方式（連番／年+連番／別モジュール呼び出し）は一切記載なし。
❌ Bobが出力した演算仕様（主要演算 C仕様イメージより）
* --- F5 登録 ---
C （バリデーションOK後）
C CALL 'GETONO' ★受注番号採番
C WRITE JHEDRR （ヘッダー）
C DO 5 RRN1
C RRN1 CHAIN SFL01
C WRITE JDETLR （明細）
C ENDDO
⚠️ 何が問題か
GETONO というサブプログラムはどこにも定義されていない。
仕様が不明な箇所をAIが「それらしい名前」で埋めた典型例。
実装者が気づかずに採用するとリンクエラーになる。
③ Claude Sonnet — W-項目化による項目IDの改変
ファイルIDをそのまま使わず、先頭に「W」を付けて作業域名に改変してしまった
✅ 元のファイルレイアウト定義（取引先マスター TOKMEP / TOKMER）
| 項目ID | 項目名 | 型・桁 |
|---|---|---|
| TOTKCD | 取引先コード | CHAR(6) |
| TOTKNM | 取引先名 | CHAR(40) |
❌ Claude Sonnet が出力した入力項目定義（第一画面 3.1.3 入力項目）
| 項目名 | 項目ID | 型・桁 | 必須 |
|---|---|---|---|
| 取引先コード |
|
CHAR(6) | ○ |
| 取引先名 |
|
CHAR(40) | - |
⚠️ 何が問題か
RPG III では「W」始まりは作業域（Work field）の慣習。
ファイルの物理項目IDは TOTKCD なのに、画面定義で WTOKCD という別名を勝手に作ってしまった。
DDS／RPGソース生成時に CHAIN の引数とずれる。
④ Claude Sonnet — 受注番号の形式を独自発明（J2401001形式）
CHAR(8)の型だけ定義されている受注番号に、勝手な形式ルールを作ってしまった
✅ 元のファイルレイアウト定義
| 項目ID | 項目名 | 型・桁 |
|---|---|---|
| JHBANG | 受注番号 | CHAR(8) |
→ 採番形式の記載はなし
❌ Claude Sonnet が出力した採番ロジック
受注番号形式：JYYYYMMM（例：J2401001）
J ：固定文字
YYYY ：西暦年（4桁）
MMM ：当日の連番（3桁、001～999）
採番方法：
・受注ヘッダーから当日の最大受注番号を取得
・連番部分を+1して採番
・当日の受注がない場合は001から開始
⚠️何が問題か
「J+4桁年+3桁連番」は CHAR(8) にぴったり収まるため型的には破綻しない。
しかし採番方式は業務要件であり、AIが独自に決めてよいものではない。
実際には既存の採番ファイルや採番ルールが存在する可能性が高く、
このまま実装すると既存データと競合する恐れがある。
⑤ Claude Opus — DDS骨格は出るが必須キーワードが不完全
サブファイル制御の DDS キーワードが不完全（SFLCLR・インジケーター番号が欠落）
✅ Bob が出力した完全な DDS（画面レイアウト定義.md より）
A R JUCCTL SFLCTL(JUCSFLR)
A SFLSIZ(0005)
A SFLPAG(0005)
A 91 SFLDSP ← インジケーター番号付き
A 91 SFLDSPCTL ← インジケーター番号付き
A 92 SFLCLR ← サブファイルクリア
A 93 SFLEND(*MORE)
A CF03(03 '終了')
A CF05(05 '登録')
A CF12(12 '前画面')
❌ Claude Opus が出力したサブファイル制御キーワード
SFLCTL01 制御：
SFLPAG(5) SFLSIZ(5)
SFLDSP SFLDSPCTL SFLEND ← インジケーター番号なし
OVERLAY
★SFLCLR が丸ごと欠落
⚠️ 何が問題か
SFLDSP / SFLDSPCTL / SFLCLR はインジケーター番号とセットで指定しなければならない（例：A 91 SFLDSP）。
番号なしで書いたままでは DDS コンパイルエラーになる。
また SFLCLR が完全に抜けており、サブファイルのクリア処理が定義されない。
⑥ Claude Sonnet — 仕入先コードがサブファイルから消えた
プロンプトで「仕入先を表示する」と明記されているのにサブファイル項目から漏れた
✅ プロンプトの仕様（要求）
実行キーで品目名や仕入先、金額（販売単価×数量）を表示
※品目コード、販売単価、数量は常に変更可能
品目マスターには HISICD（仕入先コード） が存在する。
❌ Claude Sonnet のサブファイル項目定義
| 項目名 | 項目ID | 型・桁 | 入力/表示 |
|---|---|---|---|
| 品目コード | WHNCD | CHAR(8) | 入力 |
| 品目名 | WHNMN | CHAR(40) | 表示 |
| ← 定義なし | - | - | |
| 販売単価 | WTNKA | NUMERIC(9,0) | 入力 |
| 数量 | WSRYO | NUMERIC(7,0) | 入力 |
| 金額 | WKNGA | NUMERIC(11,0) | 表示 |
⚠️ 何が問題か
プロンプトで「仕入先を表示」と明示されているにも関わらず、サブファイル項目に 仕入先コード が定義されていない。
画面レイアウト（アスキーアート）にも仕入先列がない。
後から追加しようとすると列位置の再調整が発生する。
まとめ：AI別「外し方」の傾向
| AI | 外し方の種別 | 具体的な問題 | 影響度 |
|---|---|---|---|
| Bob | 過剰補完 | 存在しない項目IDを独自命名・未定義サブルーチン(GETONO)を生成 | 🔴 高（コンパイルエラー） |
| Claude Sonnet | 項目ID改変・項目漏れ | W-項目への変換、仕入先コード欠落、採番形式を独自発明 | 🔴 高（設計不整合） |
| Claude Opus | DDS不完全 | SFLCLR欠落、インジケーター番号なし | 🟡 中（DDS構文エラー） |
| ChatGPT | RPG固有仕様の欠落 | CHAIN/SETLL等の命令記載なし、インジケーター定義なし | 🟡 中（実装時に要補完） |
| Copilot | 技術詳細全般の欠落 | DDS・インジケーター・RPG固有仕様がすべて未記載 | 🟡 中（叩き台レベル） |
| Gemini | フロー・DDS未出力 | 処理フロー図・DDS定義が出力されない | 🟡 中（後追いで要作成） |
| Gemini Notebook | 生成量不足 | 設計書として完結せず確認事項抽出に留まる | 🟢 低（用途が異なる） |
Bobのみ、フロー図、画面レイアウト定義、プログラム仕様書の3種類出力
プログラム処理フロー図
Bobの出力:第一画面から受注ファイル登録までの処理フロー図
画面レイアウト定義
Bobの出力:画面レイアウト定義
受注入力プログラム仕様書
Bobの出力:受注入力プログラム仕様書（1/3）
Bobの出力:受注入力プログラム仕様書（2/3）
Bobの出力:受注入力プログラム仕様書（3/3）
以降、添付画像は画面仕様の部分
Claude
Claudeは2モデルで検証しています。
①Opus
複雑で長い思考が必要なタスク向け
②Sonnet
同じ対象に対して、生成 → 確認 → 修正 を短いサイクルで繰り返すなど反復回数が多い作業向け
Opus
Opusの出力:画面仕様（1/2）
Opusの出力:画面仕様（2/2）
Sonnet
Sonnetの出力:画面仕様（1/2）
Sonnetの出力:画面仕様（2/2）
ChatGPT
ChatGPTの出力:画面仕様
Copilot
Copilotの出力:画面仕様（1/2）
Copilotの出力:画面仕様（2/2）
Gemini
Geminiの出力:画面仕様（1/2）
Geminiの出力:画面仕様（2/2）
Gemini NoteBook
Gemini NoteBookの出力:画面仕様
各生成AIの比較:何が書けて何が書けなかったのか
凡例
- ◎ : 詳細に記載
- △ : 概要レベルで記載
- × : 記載なし
| 確認項目 | Bob | Claude | ChatGPT | Copilot | Gemini | Gemini Notebook |
|---|---|---|---|---|---|---|
| PGMID・名称 | ◎ | ◎ | ◎ | ◎ | ◎ | ◎ |
| 目的・機能概要 | ◎ | ◎ | ◎ | ◎ | ◎ | ◎ |
| 作成日・言語 | ◎ | ◎ | △ | △ | △ | × |
| ファイル一覧 | ◎ | ◎ | ◎ | ◎ | ◎ | ◎ |
| 項目詳細定義 | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| アクセス方法 | ◎ | ◎ | △ | △ | △ | × |
| 画面レイアウト | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| 入力項目定義 | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| SBFILE仕様 | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| DDS定義記述 | ◎ | △ | × | × | × | × |
| インジケーター | ◎ | △ | × | × | × | × |
| 処理フロー | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| バリデーション | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| 登録処理詳細 | ◎ | ◎ | ◎ | ◎ | ◎ | △ |
| RPG固有仕様 | ◎ | ◎ | △ | × | △ | × |
| テストケース | ◎ | △ | × | × | × | × |
| 異常系テスト | ◎ | △ | × | × | × | × |
- SBFILE = サブファイル
- RPG固有仕様 = CHAIN、SETLL、MOVE等、RPG固有の命令等
- Claudeの評価は Opus の出力を対象としています（Sonnetの出力は4-2-2を参照）
総評 各AIの評価
総合スコアリング（100点満点）
| AI | 正確性 | 詳細度 | 実用性 | 総合 |
|---|---|---|---|---|
| 👑Bob | 95 | 95 | 90 | 93 |
| Claude | 80 | 75 | 85 | 80 |
| ChatGPT | 75 | 70 | 85 | 77 |
| Gemini | 72 | 70 | 78 | 73 |
| Copilot | 70 | 70 | 80 | 73 |
| Gemini Notebook | 68 | 50 | 70 | 63 |
推奨用途
| AI | 推奨用途 |
|---|---|
| Bob | 本格的な仕様書・テスト仕様書作成 |
| Claude | 高品質な技術文書作成 |
| Gemini | 入力チェック仕様の洗い出し |
| ChatGPT | 叩き台作成・Excel活用 |
| Copilot | 項目定義整理・Microsoft連携 |
| Gemini Notebook | 資料分析・確認事項抽出 |
本章のまとめ
結論
今回検証したAIの中では、IBM Bob が最も網羅性が高く、正式な仕様書の出発点として適しているという結果になりました（総合93点）。
ただし、Bob を含めどのAIも「そのまま実装工程に渡せる仕様書」には至っていません。差がついたのは文書としての体裁や読みやすさではなく、RPG III / IBM i 固有の領域をどこまで書けるかでした。
差がついたのは「実装に直結する部分」
比較表を縦に見ると、傾向がはっきり出ています。
| 層 | 結果 |
|---|---|
| PGMID・目的・ファイル一覧・項目詳細定義・画面レイアウト・処理フロー・バリデーション・登録処理 | 内容に差はあるものの、ほぼ全AIが書けていた |
| DDS定義記述・インジケーター・テストケース・異常系テスト | Bobのみ記載あり（Claudeが少量記載、他AIは記載なし） |
つまり、仕様書の「骨格」は汎用AIでも十分に書けます。落ちるのは DDS キーワード、インジケーター番号、CHAIN / SETLL といった IBM i 特有の知識が必要になる層で、ここから先は急激に精度が下がります。
逆に言えば、汎用AIを使う場合は「骨格はAI、RPG固有部分と試験仕様は人間」という分担を最初から前提に組んだ方が、手戻りは少なくなります。
AIの「外し方」から見えた3つの教訓
① 網羅性が高いAIほど、もっともらしく間違える
実務上いちばん重要だったのはこれです。
- 記載なし（×）はレビューで気づける ── 埋めるべき穴として目に見える
-
それらしく補完された誤りは気づけない ──
TOKCD、GETONO、J2401001形式は、いずれも一見すると正しく見える
Bob は網羅性が最も高い一方で、存在しない項目IDや未定義サブプログラムを自然な文脈で混ぜてきました。網羅性の高さとレビューの容易さは必ずしも比例しないという点は、AI選定の際に意識しておく必要があります。
「書かれていない」よりも「もっともらしく書かれている」方が危険。
② 素材に無いものは、必ず何かで埋められる
受注番号 JHBANG は CHAR(8) という型・桁のみの定義で、採番ルールの記載はありませんでした。結果として、Bob は GETONO というサブプログラム呼び出しを、Claude Sonnet は「J＋西暦4桁＋連番3桁」という形式を、それぞれ独自に補完しています。
採番方式・端数処理・権限といった業務ルールは、仕様の空白としては残らず、AIが何らかの形で決めてしまいます。対策としては、
- 素材側に「採番は既存モジュールを使用」等を明記しておく
- 「不明な点は推測せず『要確認』と記載する」ようプロンプトで指示する
の2点が有効でした。
一方で、AIが補完した箇所は「まだ決まっていない事項の一覧」でもあります。補完箇所を洗い出す作業そのものがレビュー観点の抽出として機能するため、この用途では生成量の少ない Gemini Notebook にも十分な価値がありました。
③ プロンプトに明記した要求でも落ちる
「実行キーで品目名や仕入先、金額を表示」とプロンプトに明記していたにも関わらず、Claude Sonnet のサブファイル項目定義から仕入先コードが欠落していました。
出力の確認は「AIが書いたものを読む」のではなく、プロンプトの要求を1つずつ逆引きで照合する必要があります。
レビュー観点チェックリスト
AIが生成した仕様書を受け取ったら、最低限この6点は確認することをおすすめします。
- 項目IDがファイルレイアウト定義と一字一句一致しているか（短縮・W付与・独自命名がないか）
- 呼び出しているサブプログラム・ファイルが実在するか（
GETONO型の架空定義） - 素材に無い業務ルール（採番・端数処理・権限）を勝手に決めていないか
- プロンプトの要求項目が漏れなく反映されているか
- DDS のインジケーター番号、
SFLDSP/SFLDSPCTL/SFLCLR/SFLENDの過不足 - テストケース（特に異常系）は自前で補う前提になっていないか
本検証の前提と限界
結果の解釈にあたっては、以下の条件を前提としてご覧ください。
- 対象は受注入力プログラム1本、プロンプトは1回投げた結果（再質問・修正指示なし）
- 検証時期は2026年6月。モデルの更新により結果は変わり得ます
- スコアは当チームによる評価であり、各AIの絶対的な優劣を示すものではありません
どのAIを使う場合でも人によるレビューは必須です。
また、業務データや社内定義を外部AIに入力する際、各サービスの利用規約と社内規程（情報セキュリティポリシー）を必ず確認してください。
次章に向けて
次章では、この IBM Bobで作成した仕様書 を入力としてソースコードを生成し、仕様書の品質が実装にどこまで反映されるかを確認します。
当記事の著作権はIBMに帰属します。詳細はこちらを参照ください。