Codexは、コードや資料を読み、調査、修正案、テスト、レビュー、ドキュメント更新を支援するOpenAIのコーディングエージェントです。 AS400 / IBM iの現場では、RPG/CLの処理整理、呼び出し関係、影響調査、ジョブログ要約、単体テスト観点の作成に使えます。
一方で、本番データ更新、業務判断、リラン可否、顧客情報を含むデータの取り扱いを任せきりにする道具ではありません。人が対象環境と結果を確認できる範囲から始めます。
AS400保守でCodexが向いている作業
| 作業 | Codexに頼めること | 人が確認すること |
|---|---|---|
| RPG/CL読解 | 処理概要、入出力、CALL関係を整理する | 業務仕様、参照先、更新条件 |
| 影響調査 | 変更項目が使われる処理候補を洗い出す | 実環境のオブジェクト、動的呼び出し |
| ジョブログ | メッセージの時系列と確認候補を整理する | 実際の原因、返信・再実行判断 |
| 単体テスト | 正常系、境界値、異常系、再実行を列挙する | 期待結果、実行環境、証跡 |
| コンパイル | エラーや警告の要点をまとめる | ライブラリ、オプション、作成物 |
| 文書化 | 調査メモ、手順書、引き継ぎ資料を下書きする | 機密情報、現場固有の表現、承認 |
最初は読み取りと整理から始める
- 検証用またはマスキング済みの資料を用意する
- 対象プログラム、目的、見てほしい観点を伝える
- 処理概要と不明点を出させる
- 人がソース・ジョブログ・ファイル定義と照合する
- 次に確認するコマンドやテスト観点を整理する
- 確認結果を調査メモとして残す
「このソースを直して」から始めるより、「このプログラムの入出力と更新ファイルを整理し、不明点を質問してください」と依頼する方が、誤った前提に気づきやすくなります。
RPG/CL解析の依頼例
このRPG/CLの処理を調査してください。
1. 入力パラメーター
2. 参照・更新ファイル
3. 呼び出すプログラムとサブルーチン
4. エラー処理とMONMSG
5. 修正時の影響候補
6. 単体テスト観点
分からない点は推測で断定せず、確認質問として分けてください。ジョブログ調査の依頼例
マスキング済みのジョブログを時系列で整理してください。
最初の原因メッセージ、後続エラー、対象プログラム、対象ファイル、
次に確認するコマンドを分けてください。
返信や再実行の可否は断定せず、人が判断する確認項目を出してください。ジョブログの読み方自体は AS400ジョブログ確認手順、CPFの切り分けは CPFエラーの調べ方 で確認できます。
単体テストとレビューで使う
Codexは、最大桁、境界値、ゼロ、空白、件数増加、DB更新、帳票、CSV、再実行の観点を並べる作業と相性があります。ただし、テスト観点を出したことと、実行して仕様通りだったことは別です。
- 期待結果は仕様書と業務担当者の確認を使う
- コンパイルが通っても業務ロジックをレビューする
- DB更新前後、帳票、ジョブログを証跡として残す
- エビデンス取得後に直したら再テストする
具体的な観点は AS400のフル桁入力・境界値テスト確認表 にまとめています。
実際に使って効いたのは、調査の速さと資料の生成
運営者が実際にAS400保守でCodexを使ってみて、はっきり効果を感じたのは次の2つです。
- 調査が早くて正確になった
- 資料の生成もしてくれる
なぜ調査が正確になるのか
ここは仕組みを理解しておく価値があります。正確になるのは、AIがAS400に詳しいからではありません。手元のソースを渡して、それを読ませているからです。一般論として「RPGとはこういうものです」と答えさせるのと、実際のソースを読んで「このプログラムはこのファイルをこう更新しています」と答えさせるのとでは、精度がまったく違います。
裏を返すと、ソースを渡さずに聞いた内容は精度が落ちます。使い方としては、調べたい対象のソースを渡し、その範囲で答えさせるのが基本です。そして出てきた答えは、最終的にソースで裏を取ります。AIの要約を鵜呑みにして本番へ進むのは、資料を鵜呑みにするのと同じです。
資料の生成が、実はいちばん大きい
AS400の現場では、設計書や運用資料が実態と合っていないことがよくあります。改修のたびに資料まで直すのは現実には続かないからです。この問題は何十年も解決していません。
ソースから資料を生成できるようになると、この前提が変わります。資料を「維持し続けるもの」から「必要になった時にソースから起こすもの」へ切り替えられるからです。ソースは常に実態そのものなので、そこから作った資料は、少なくとも作った時点では実態と一致します。
| これまで | ソースから生成する場合 |
|---|---|
| 改修のたびに資料を手で直す | 必要になった時にソースから起こす |
| 直し漏れが積み重なり、実態とズレる | 作った時点の実態と一致する |
| ズレているかどうかが分からない | 元がソースなので根拠をたどれる |
| 資料の維持がコストとして残り続ける | 使う時だけコストがかかる |
引き継ぎ、外部への説明、影響調査の記録など、資料が必要になる場面は決まっています。その都度ソースから起こすほうが、使われない資料を維持し続けるより現実的です。
生成した資料をそのまま正式文書にはしないでください。ソースの読み取りが正しいかを担当者が確認し、業務上の意図や運用ルールなどソースには書かれていない情報を人が足す。この一手間までがセットです。
Codexへ渡さない情報
| 渡さないもの | 代わりに行うこと |
|---|---|
| パスワード、APIキー、Cookie、トークン | 削除し、設定名だけに置き換える |
| 顧客名、個人情報、取引データ | 架空値・項目名・件数へ置き換える |
| 本番接続情報 | 検証用の説明と仮のホスト名を使う |
| ソース全文を無条件に外部へ出すこと | 社内規程と契約を確認し、必要範囲だけ扱う |
| 未確認の復旧SQLや本番コマンド | 案としてレビューし、承認手順を通す |
自分が判断できない領域を任せるのは危ない
Codexの限界として、運営者がはっきり感じているのがここです。完全に自分の知らない知見の領域をやってもらうのは厳しいということです。
理由は単純で、Codexが行う作業を見て、その動きが正しいかどうかは人間が見極める必要があるからです。出てきたコードや説明が妥当かを判断できないまま進めると、バグだらけのアプリができます。動いているように見えて、条件が変わった時に壊れる、という形で後から出てきます。
つまりCodexは、判断を代わりにやってくれる道具ではありません。判断できる人の作業を速くする道具です。前の章で書いた「調査が早くて正確」も、正しさを見極められる人が使った場合の話です。
| 領域 | 任せてよいか | 理由 |
|---|---|---|
| 読めば正しいか分かる範囲 | 任せてよい | 出力を検証できるので、速さの恩恵だけ受けられる |
| 知識はないが、動かして確かめられる範囲 | 条件つき | テスト環境で確認できるなら可。本番でいきなり試さない |
| 判断材料を自分が持っていない領域 | 任せない | 合っているかどうかが分からない。先に自分が理解する |
初心者にとっての意味もはっきりしています。AIがあるから勉強しなくてよい、にはなりません。むしろソースを読めること、業務を理解していることの価値が上がります。読めない人が使うと事故が速くなるだけだからです。
Codexに任せない判断
- 本番データを更新するか
- ジョブを終了・再実行するか
- MSGWへ何を返信するか
- 締め、出荷、請求、EDIを続行するか
- 顧客や利用部門へ何を説明するか
Codexは判断材料を整理できますが、業務影響と責任を引き受けるわけではありません。最終判断は、環境、権限、業務、戻し方を確認できる人が行います。
若手とベテランで使い方を変える
若手は、用語の説明、調査順、確認質問、テスト観点を整理する使い方から始めます。ベテランは、複雑な呼び出し関係、差分レビュー、調査メモの標準化へ使うと効果が出やすいです。どちらも、結果を鵜呑みにせず元資料と照合します。
法人で使う場合はルールと研修をそろえる
個人ごとに入力範囲やレビュー方法が違うと、AI活用そのものが新しい属人化になります。対象業務、入力禁止情報、承認者、ログ、テスト、戻し方を決め、同じ題材で練習できる状態を作ります。既存RPG/CLを題材に現場の確認順まで扱う支援は、AS400 / IBM i Codex研修の内容・料金 で確認できます。
参考
まとめ
CodexはRPG/CLの読解、影響調査、ジョブログ整理、テスト観点、文書化を速くする補助役です。本番操作や業務判断は任せず、機密情報を除いた範囲で使い、最後は人が元資料と照合します。
