AS400保守でCodexはどこまで使えるのか？調査・コンパイル・単体テストまで現場目線で解説

AS400 / IBM i の保守現場で、CodexのようなAI開発支援ツールはどこまで使えるのか。これは、これからのAS400エンジニアにとってかなり大事なテーマになると思っています。

私は2000年からAS400 / IBM i に関わり、流通業界の販売管理システムを中心に、開発、保守、追加要望対応、本番対応を経験してきました。その立場から見ると、CodexはAS400保守でもかなり使えます。

特に、チャットで「TEST001Rを調査して」と依頼して調査の入口を作る、FTP経由で検証環境に反映する、コンパイルリストを見ながらエラーを直す、単体テストのシナリオやエビデンスを整理する、といった使い方は現場でも効果があります。

ただし、本番環境や顧客情報をAIに触らせるべきではありません。便利だからこそ、どこまで任せて、どこから人間が責任を持つのかを決めておく必要があります。

AS400保守でAIやCodexに任せやすい作業

私が実際にAIやCodexを使っているのは、主に本番環境から切り離した範囲の作業です。たとえば、単体テストデータの作成、簡単な外部サブルーチン、サブルーチンを起動するためのドライバー作成などです。

単体テストでは、正常系だけでなく、境界値、異常値、ゼロ件、最大件数に近いパターンなどを用意する必要があります。こういうテストデータのたたき台を作る作業は、AIと相性が良いと感じています。

また、RPGやCLのソースを解析してもらい、機械的にバグの可能性を検知させる使い方もしています。たとえば、配列の指標エラーになりそうな箇所、条件分岐の抜け、サブルーチン呼び出しの整合性などです。

AIに任せる範囲と任せない範囲

逆に、AIに任せたくない作業もはっきりしています。まず、本番環境を触ること全般です。本番ライブラリー、本番ファイル、本番データ更新、本番障害時のリカバリー作業は、AIに直接やらせるべきではありません。

もう一つは、顧客情報が載っているDBを触らせることです。顧客名、取引情報、個人情報、社内固有のコードなどをそのままAIに読ませるのは危険です。便利だからといって、本番データや機密情報を貼り付けるのは避けるべきです。

私はそこを工夫して、名称がないDBをわざと作成し、コードだけのマスターを作ってAIに読ませるようにしています。実データではなく、構造やロジックを確認できる形にして渡すイメージです。

AIに渡す前の考え方

1. 本番データは渡さない
2. 顧客名や会社名は消す
3. ライブラリー名は検証用に置き換える
4. ファイル名も必要に応じて置き換える
5. ロジック確認に必要な最小情報だけ渡す

RPGやCLのソースをAIに見せるなら何に使うか

RPGやCLのソースをAIに見せる場合、今のところ私の使い方は「単純なバグ発見器」に近いです。

たとえば、配列の指標エラーが起きそうな処理、初期化漏れ、条件の組み合わせ、サブルーチンの呼び出し順、項目名の整合性などを確認させます。人間が見ると流してしまうような機械的な不整合を、AIに拾わせるイメージです。

ただし、AIの指摘をそのまま正解にしてはいけません。AS400の現場では、古い仕様、例外的な運用、過去の経緯で残っている処理が普通にあります。AIが「不要そう」と判断した処理でも、実は業務上必要なことがあります。

そのため、AIにはまず疑い出しをしてもらい、最終的には人間が仕様、データ、ジョブログ、運用を見て判断するのが安全です。

AS400現場でAIを使う時に一番怖いミス

一番怖いのは、指示したライブラリー、ファイル、環境以外にアクセスされることです。今のところ私の環境ではそういうことは起きていませんが、考え方としては常に警戒しています。

AS400 / IBM i では、ライブラリーリストや同名オブジェクトの扱いが重要です。画面上は同じように見えても、実際に参照しているライブラリーが違えば、結果はまったく変わります。

これは人間が作業する場合も同じです。テスト環境のつもりで本番環境を触る。本番のつもりで検証環境を見てしまう。こういう環境取り違えは、AS400保守では特に注意が必要です。

若手AS400エンジニアがAIを使うなら守るべきこと

若手エンジニアに「AIを使うならここだけは守れ」と言うなら、人間が作業する時と基本は同じです。特に気をつけるべきなのは環境面です。

どの環境の話をしているのか。どのライブラリーを見ているのか。どのファイルを更新する想定なのか。AIに質問する前に、まず自分の中で整理する必要があります。

AIに聞くと、それらしい回答がすぐ返ってきます。だからこそ、前提が間違っていると危険です。前提が間違っていれば、回答も間違った方向にきれいに整ってしまいます。

• 本番情報をそのまま貼らない
• ライブラリー名、ファイル名、会社名、顧客名は必要に応じて置き換える
• AIの回答をそのまま本番に使わない
• 作成したソースは必ず単体テストする
• 不安な箇所はメンバーや上司にレビューしてもらう
• 最終判断は自分たち人間が行う

AS400現場にAIが入ることをどう見るか

私は、AS400の現場にAIが入ってくることを大歓迎しています。早いし、品質も良くなるし、ソースもきれいになりやすいと感じています。

特に、単純なミスの検出、テストデータ作成、処理概要の整理、コメント作成、影響調査の補助には向いています。昔なら時間をかけて人間が見ていた確認作業の一部を、AIが先に洗い出してくれるのは大きいです。

一方で、普段からバグばかり出している人、確認を省いてしまう人、仕様を理解せずに作業している人にとっては、怖い存在になるかもしれません。AIを使うことで、雑な作業や確認不足が見えやすくなるからです。

AIは、できる人をさらに楽にする道具だと思います。逆に、責任を持たずに作業する人の代わりにはなりません。

「TEST001Rを調査して」からコンパイル確認まで進められる便利さ

Codexを使っていて特に便利だと感じるのは、チャットで「TEST001Rを調査して」と伝えるだけで、調査の入口を自動で作ってくれるところです。

人間が手でやる場合は、対象プログラムを探し、ソースメンバーを確認し、関連するCL、外部サブルーチン、参照ファイル、呼び出し関係を順番に見ていきます。慣れている人なら当たり前にできますが、地味に時間がかかる作業です。

Codexに依頼すると、まず対象ソースを確認し、処理概要、入出力ファイル、CALL先、サブルーチン、気になる箇所を整理してくれます。ここまでが「調査」の段階です。若手が最初にどこを見ればよいか迷う場面では、かなり助けになります。

チャットでの依頼例

TEST001Rを調査して

調査段階でCodexに期待すること
1. 対象ソースを確認する
2. 処理概要を整理する
3. 入出力ファイルを洗い出す
4. CALL先やサブルーチンを確認する
5. バグになりそうな箇所を指摘する
6. テスト観点を作る
7. 必要なら修正案を出す

さらに修正が必要な場合は、FTP経由でAS400側へソースを反映し、コンパイルを実行し、コンパイルリストを確認する流れまで進められます。つまり、調査で終わらず、修正、反映、コンパイル、エラー解析、再修正という作業サイクルをCodexに手伝ってもらえるわけです。

修正からコンパイル確認までの流れ

1. 調査結果をもとに修正案を作る
2. 人間が修正内容を確認する
3. FTP経由でAS400へ反映する
4. 開発環境または検証環境でコンパイルする
5. コンパイルリストを確認する
6. エラー原因を解析する
7. 必要に応じて修正して再コンパイルする
8. コンパイルが通った後、単体テストへ進む

RPGやCLでは、コンパイルエラーの内容、行番号、項目名、未定義の変数、桁数不一致、CALLパラメータの不整合などを見ながら直す場面があります。コンパイルリストをAIに読ませると、どこを直せばよいかの当たりを付けるのが早くなります。

ただし、これは安全な開発環境や検証環境で行う前提です。本番環境に直接つないでAIに自由に作業させるような使い方はおすすめしません。FTP接続先、ライブラリー、ソースファイル、メンバー名、権限は人間が管理し、AIには決められた範囲だけを扱わせるべきです。

また、実際の現場ではプログラム名、ライブラリー名、ファイル名、顧客固有の名称などをそのまま出せない場合があります。その場合は、検証用の名前に置き換えてから依頼します。たとえば、ライブラリー名はTESTLIB、プログラム名はTEST001Rのようにして、構造やロジックだけを見せる形にします。

AIの調査結果や修正案は、あくまで作業を速くするための入口です。最終的には、人間が実際の仕様、運用、ジョブログ、コンパイル結果、テスト結果を見て判断します。「Codexがそう言ったから正しい」ではなく、「Codexが出した観点を使って、人間が確認する」という使い方が安全です。

単体テストのシナリオ作成とエビデンス整理にも使う

Codexは、単体テストのシナリオ作成にも使えます。仕様やソースの内容をもとに、正常系、異常系、境界値、ゼロ件、複数件、最大件数に近いケースなどを洗い出してもらう使い方です。

AS400の保守では、修正そのものよりも、どこまで確認したかを説明できることが大事です。単体テストの観点が薄いと、後で障害が出た時に「なぜそのケースを見ていなかったのか」となります。AIにテスト観点を出してもらうと、確認漏れを減らしやすくなります。

さらに、実行結果のエビデンス整理にも使えます。テスト前データ、実行コマンド、実行後データ、ジョブログ、確認結果をまとめ、レビューしやすい形に整える作業は、AIと相性が良いです。

ただし、ここでも注意点は同じです。エビデンスに顧客名、実データ、個人情報、社内固有情報が含まれる場合は、そのままAIに渡してはいけません。必要に応じてマスクし、検証用データに置き換え、公開しても問題ない形にしてから扱うべきです。

Codexを使うほど、人間のレビューが重要になる

Codexで調査できる、コンパイルまで回せる、単体テストシナリオを作れる、エビデンスまで整理できる。ここまでできると、かなり強力です。ただし、便利になるほど人間のレビューは重要になります。

コンパイルが通ったから正しいとは限りません。単体テストが通ったから本番で安全とも限りません。AS400の業務システムでは、過去の運用、例外処理、締め処理、月次処理、外部連携など、ソースだけでは判断できない事情があります。

AIを使って開発して、不具合が発生した時に「AIが作ったので」と言い訳する人は、使わない方が良いと思います。最終的に責任を持つのは人間です。

私がCodexに期待しているのは、作業を速くすること、確認漏れを減らすこと、機械的なミスを拾うことです。一方で、業務判断、リリース判断、本番反映判断は人間が持つべきだと考えています。

まとめ

AS400 / IBM i の保守現場でも、AIやCodexは十分に使えると思います。特に、単体テストデータ作成、簡単なサブルーチン、ドライバー作成、ソース解析、機械的なバグ検知には向いています。

一方で、本番環境を触る作業や、顧客情報を含むDBの扱いは慎重に分けるべきです。必要なら、名称を消した検証用DBや、コードだけのマスターを用意して、AIには安全な範囲だけ読ませる工夫が必要です。

AIを使う時こそ、環境確認、ライブラリー確認、レビュー、単体テストが大事になります。AIの出した答えを使うのは人間です。最後に責任を持つのも人間です。

AS400の基本操作から順番に確認したい方は、AS400学習ロードマップもあわせて確認してみてください。本番対応の考え方は、AS400の本番対応で初心者がやってはいけないことにもまとめています。