生成AI比較検証のまとめと総括：IBM i（RPG）開発における生成AIの適材適所とハイブリッド活用
1. はじめに
IBM i（RPG）開発における生成AIの活用可能性を探るため、「IBM Bob」「Copilot」「Claude Code」の3ツールを対象に、共通仕様（受注管理システム）を用いた実装・検証を行いました。
IBM iの開発現場では、
- DDSの固定位置形式
- RPGⅢ（固定形式）とILE-RPG（フリーフォーム形式）の仕様差
- ソース間の参照関係
- コンパイル順序
など固有の制約が多く存在します。
本研究では、
「仕様書だけを渡してどこまで作れるのか」
という初期検証から出発し、
- ルール設定
- 過去資産・引き継ぎ情報の活用
- 自動チェックツール（Linter）の導入
といったアプローチを段階的に検証しました。
本稿では、各ツールの強み・弱みと得意なシチュエーションを明確にし、実際の現場でどう組み合わせて開発を進めるべきかをまとめます。
2. 徹底比較：各AIツールの特徴と得意なシチュエーション
3つのAIは設計思想が大きく異なり、それぞれ明確な「向き・不向き」があります。
| 比較項目 | IBM Bob | Copilot | Claude Code |
|---|---|---|---|
| コアコンセプト |
ルール資産化・統合型 （Rules/Skillsで仕様・標準を定義） |
プロンプト即応・対話型 （その場の指示でピンポイント生成） |
自律エージェント型 （CLI連携で作成〜テストまで自律実行） |
| 得意なこと（強み） | ・PF/LF/DSPF/RPGなど関連資産の一括生成 ・社内固有ルールをファイル化してチーム共有 |
・導入の手軽さと部分修正 ・5要素プロンプトによる出力形式の固定化 |
・複雑なロジック生成と自己修正能力 ・既存資産・引き継ぎメモを活かした高速改修 |
| 苦手なこと（弱み） | ・自然言語のみでの厳密な桁位置制御 | ・複数ファイル間の整合性維持 ・毎回プロンプトによる形式拘束が必要 |
・初期ルールの厳密さによる初回エラー増加（U字カーブ） ・メモの記述への過剰適合 |
| 最適なシチュエーション | 「チーム全体で標準化・複数資産を一括構築したい場面」 | 「個人作業で特定モジュールを素早く作成・修正したい場面」 | 「既存コードの大規模改修や自律的ビルド・テストを行いたい場面」 |
どのAIがどんな場面に向いているか？
-
IBM Bob が向いている場面
- 新規機能・システム全体の立ち上げ: DB定義（PF/LF）から画面（DSPF）、ビジネスロジック（RPG）、制御（CL）まで一貫した設計で一括生成したいとき。
-
チーム標準の資産化: プロンプトの属人化を防ぎ、社内開発標準や独自ライブラリ規則を
Rules/Skillsとして定着させたいとき。
-
Copilot が向いている場面
- 日常的なコーディング・ピンポイント修正: エディタ（VS Code等）上で既存ソースの特定サブルーチン追加や関数修正をサクッと行いたいとき。
- 単発のPoC・プロトタイピング: ルールファイルの準備なしに、「5つの要素（ロール/形式/禁止/品質/順序）」をプロンプトに指定して手軽にコードを得たいとき。
-
Claude Code が向いている場面
- 既存資産のリファクタリング・仕様改修: 過去の動いたコード（お手本）と仕様変更メモを渡し、高精度にロジックを追従・書き換えさせたいとき。
- E2Eでの自律開発・自動化: CLI環境からファイルの作成・配置・コンパイル・テスト・エラー修正までをエージェントに自律実行させ、作業工数を極小化したいとき。
3. 検証から得られた共通課題と対策（要約）
どのAIを活用する場合でも、IBM i環境特有の以下の3つのポイントを押さえる必要があります。
-
「動くコード」と「社内標準コード」のギャップ
- 対策: RPG Ⅲ固定形式や社内命名規約を守らせるため、「5要素（ロール/形式/禁止事項/品質条件/出力順序）」で生成前に厳格に出力形式を固定する。
-
厳密な桁位置・バイト数計算のブレ
- 対策: 自然言語の指示だけで完璧を目指さず、Python等の外部Linterを実行させて自己修正させる仕組みを併用する。
-
ルール導入初期の工数増加（U字カーブ現象）
- 対策: ゼロからルールだけで作らせるのではなく、「一度動いた過去資産（お手本）」＋「直すべき課題を明記した引き継ぎメモ」をセットで与えることで劇的に改修工数を削減する。
4. 総括：実際の開発現場では「ハイブリッド」が最適解
今回の検証から導き出された結論は、どれか単一のAIに絞るのではなく、開発フェーズや対象作業に応じて最適なAIを使い分ける『ハイブリッド開発』こそが最も効果的であるということです。
おすすめのハイブリッド開発フロー
【フェーズ1：基盤・全体設計】 ── IBM Bob
・仕様書作成と標準ルールの定義（AGENTS.md / rules / Skills）
・PF / LF / DSPF / CL / RPG の雛形・基本骨格を一括生成
│
▼
【フェーズ2：詳細実装・単体調整】 ── Copilot ＆ Claude Code
・画面の細かなロジックや個別サブルーチンの作り込み（Copilot）
・複雑なビジネスロジックの書き換え・過去資産からの移植（Claude Code）
│
▼
【フェーズ3：ビルド・テスト・検証自動化】 ── Claude Code ＆ IBM Bob
・IBM i環境への自動ソース配置とコンパイル実行
・エラー発生時のコンパイルエラー（RNF/CPFメッセージ）自動フィードバック＆自己修復
・テスト仕様書のExcel出力、画面キャプチャ自動取得によるエビデンス作成
│
▼
【フェーズ4：知見の資産化・フィードバック】 ── IBM Bob / チーム共通
・開発中に発生したエラーパターンや修正プロンプトを「ルール・Skills」へフィードバック
・チーム全体の共通ルール（rules/）を更新し、次期開発の初期精度を向上
生成AIは単なるコード生成ツールではありません。
適切なルールとフィードバックループを与えることで、IBM iレガシー資産の保守・近代化を強力に支援するパートナーとなります。
IBM iと生成AIを組み合わせた可能性は非常に大きく、今後の開発現場を大きく変えていく重要な技術要素になると考えています。
ご意見や活用事例がありましたら、ぜひコメントでお知らせください。
IBM i × 生成AIの知見を今後も共有していきたいと思います。