Codexとは？AS400保守で使えるAI開発支援を現場目線で解説

AS400 / IBM i を使っている人の中で、Codexを知っている人はまだ少ないと思います。

AIやChatGPTという言葉は聞いたことがあっても、「Codexって何？」「AS400の保守に何の関係があるの？」と感じる人も多いはずです。

この記事では、AS400 / IBM i の保守担当者向けに、Codexとは何か、AS400の現場でどう使えるのか、逆に何を任せてはいけないのかを、現場目線で整理します。

Codexとは何か

Codexは、OpenAIが提供しているコーディング向けのAIエージェントです。公式には、コードを読んだり、修正したり、コマンドやテストを実行したりできる開発支援の仕組みとして説明されています。

普通のチャットAIとの違いは、単に質問に答えるだけではなく、開発作業の流れに入り込める点です。たとえば、ソースを読んで、修正案を作り、必要なコマンドを実行し、結果を見て、さらに直すという作業を手伝えます。

AS400の現場に置き換えると、「RPGやCLのソースを読み、処理概要を整理し、怪しい箇所を指摘し、テスト観点を作る補助者」と考えるとわかりやすいです。

AS400保守でCodexが向いている作業

AS400 / IBM i の保守では、ソースを読んで、影響範囲を確認し、ジョブログを追い、テストデータを作り、結果を整理する作業が多くあります。Codexは、このような調査と整理の作業に向いています。

特に、若手やAS400に慣れていない人にとっては、「どこから見ればよいか」を整理してくれるだけでも助かります。

「TEST001Rを調査して」で始められる世界

Codexの便利さは、チャットで自然に依頼できるところです。たとえば、次のように頼めます。

TEST001Rを調査して

これだけで、Codexは対象ソースを確認し、処理概要、入出力ファイル、CALL先、サブルーチン、気になる箇所を整理する入口を作れます。

もちろん、実際の現場では本物のプログラム名や顧客固有の名称をそのまま出せない場合があります。その場合は、TEST001Rのような検証用の名前に置き換えて、構造やロジックだけを見せる使い方が安全です。

現場目線で言うと、Codexは相棒か秘書に近い

AS400エンジニアにCodexを一言で説明するなら、今流行りの生成AIです。ただ、AS400との使い道で見ると、単なるチャットAIではなく、バグチェック、プログラム生成、テストデータ作成まで幅広く手助けしてくれる相棒や秘書に近い存在だと感じています。

実際に便利だと感じたのは、AS400内部DB向けのテストデータ作成、外部サブルーチンのたたき台作成、外部連携用のCSVテストデータ生成です。こういう作業は、手で作ると時間がかかりますし、パターン漏れも起きやすいです。

AS400の人が最初にCodexを使うなら、私はバグチェックから始めるのが良いと思います。いきなり本番作業や大きな改修に使うより、既存ソースを読ませて、配列、条件分岐、CALL関係、テスト観点の抜けを見てもらう方が安全です。

Codexはロトの剣。ただし使う人のレベルが必要

Codexを誤解しやすい点は、「AIだから何でもできる」と思ってしまうことです。これは大間違いです。使う人が、何を作らなければいけないのか、つまり仕様を理解していないと、ただの宝の持ち腐れになります。

たとえるなら、今まで棍棒で戦っていた人が、Codexというロトの剣を手に入れるようなものです。強い武器であることは間違いありません。ただし、レベル1の戦士がロトの剣を持っても使いこなせません。

AS400でも同じです。設計がわかる人、業務がわかる人、修正の影響範囲を考えられる人がCodexを使うと、かなり強いです。一方で、仕様を理解せず、言われた通りにプログラムを書くだけの使い方だと、AIの力を十分に活かせません。

若手とベテランでCodexの使い方は変わる

若手とベテランでは、Codexの使い方は変わると思います。若手は、ソースの読み方、CALL関係、テスト観点、調査メモの作り方を学ぶ補助として使うのが良いです。

一方で、ベテラン、特に設計が書けるSE以上の人にとっては、Codexはかなり強力な武器になります。業務要件を理解し、どこを直すべきか判断できる人が使えば、調査、実装、テスト準備の速度が大きく上がります。

逆に、業務を理解せずにプログラムだけを書いている人は、今後かなり厳しくなるかもしれません。単純な実装や機械的な修正は、AIがかなり手伝えるようになってきているからです。

結局、業務を理解している人がAIを使いこなす

この業界に入ってから、上司には「プログラムも大事だけど、客の業務を覚えろ」と何度も言われてきました。今になって考えると、これは正解だったと思います。

AS400の現場では、プログラムだけを見ても本当の意味ではわからないことがあります。お客さんが何を求めているのか、現場でどう使われるのか、どの処理を止めてはいけないのか。そこを理解して、アプリに落とし込める人が強いです。

Codexは、そういう人をさらに助けてくれます。年齢を重ねても業務知識がある人、設計ができる人、影響範囲を考えられる人にとっては、かなりありがたい道具になるはずです。

技術だけを追い求めていたら、今の自分はいなかったと思います。業務を理解すること、相手が何を求めているかを考えること。その上でAIを使うからこそ、Codexは本当に役に立ちます。

CodexとAS400の相性が良い理由

AS400の保守は、派手な新規開発よりも、既存システムを理解して安全に直す作業が多いです。ここがCodexと相性の良いところだと思います。

• 既存ソースを読む作業が多い
• CALL関係やファイル参照を整理する必要がある
• ジョブログやコンパイルリストを見て原因を追う
• 修正よりも確認とレビューが重要
• 単体テストとエビデンス整理が大事

Codexは、こうした「読む」「整理する」「確認観点を出す」作業に向いています。AS400のように長く使われているシステムでは、ソースの背景や運用ルールを人間が理解しつつ、機械的な確認をAIに手伝わせる使い方が現実的です。

FTP、コンパイル、テストまで使える可能性

環境を整えれば、CodexからFTP経由でAS400側へソースを反映し、コンパイルし、コンパイルリストを確認して、エラーを直す流れまで手伝わせることもできます。

さらに、単体テストのシナリオを考えたり、テスト結果のエビデンスを整理したりすることもできます。AS400保守では「直したこと」だけでなく、「何を確認したか」を説明できることが大事なので、ここはかなり役に立ちます。

Codexで補助できる流れ

1. 対象プログラムを調査する
2. 修正案を作る
3. 人間が内容を確認する
4. 検証環境へ反映する
5. コンパイルする
6. コンパイルリストを確認する
7. 単体テスト観点を作る
8. 実行結果をエビデンス化する

Codexに任せてはいけないこと

便利だからといって、何でもCodexに任せてよいわけではありません。AS400の現場では、特に本番環境と顧客情報の扱いに注意が必要です。

• 本番環境を直接触らせない
• 顧客情報や個人情報を含むDBを読ませない
• 実会社名、顧客名、業務固有コードをそのまま貼らない
• ライブラリー名やファイル名を確認せずに更新しない
• AIの修正案をレビューなしで反映しない

私なら、AIに読ませる情報はできるだけ検証用に置き換えます。ライブラリー名はTESTLIB、プログラム名はTEST001Rのようにし、顧客情報を含まないコードだけのマスターを用意するなど、扱う情報を絞ります。

AS400エンジニアがCodexを使う時の考え方

Codexは、AS400エンジニアの代わりに責任を取ってくれるものではありません。あくまで、調査、整理、修正案、テスト観点、エビデンス作成を助ける道具です。

AIを使って不具合が出た時に「AIが作ったので」と言う人は、使わない方がよいと思います。最終的に責任を持つのは人間です。

逆に、責任を持ってレビューできる人にとっては、Codexはかなり強い相棒になります。調査の初動を速くし、確認漏れを減らし、単体テストや手順書の質を上げることができます。

少し乱暴に言えば、AS400の現場こそ「Ai使えや!!」と思っています。もちろん、何でもAI任せにするという意味ではありません。業務を理解している人が、調査、確認、テスト、エビデンス整理の速度を上げるために使うべきだ、という意味です。

まとめ

Codexは、OpenAIが提供するコーディング向けのAIエージェントです。AS400 / IBM i の保守現場では、RPGやCLのソース解析、CALL関係の整理、コンパイルリスト確認、単体テストシナリオ作成、エビデンス整理などに活用できます。

ただし、本番環境や顧客情報をそのまま扱わせるのは危険です。検証用の名前やデータに置き換え、人間がレビューし、最終判断を持つことが前提です。

実際にAS400保守でCodexをどう使うかは、AS400保守でCodexはどこまで使えるのか？ に詳しくまとめています。AS400の基本から順番に学びたい方は、AS400初心者向け学習ロードマップも確認してみてください。

Codexの公式情報は、OpenAI Codex公式ページや OpenAI PlatformのCodexドキュメント でも確認できます。