CodexでCOBOLを修正して、そのままコンパイルまで確認する方法
Codexは公式にも「コードを読み、編集し、実行できる」コーディングエージェントとして説明されています。今回は、その特徴をCOBOL修正・コンパイル確認にどう活かすか、実務寄りに整理します。
結論：修正だけでなく、コンパイル確認までAIに流れを渡すと強い
VS CodeとCodexを使ったCOBOL開発の応用として、今回は修正後にそのままコンパイルまで確認する方法を整理します。
AIにソースを読ませて修正案を出してもらうだけでも便利です。しかし、実務では「修正して終わり」ではありません。
修正する。コンパイルする。エラーを見る。原因を直す。もう一度コンパイルする。必要ならテストする。
ここまでできて、ようやく現場で使える修正に近づきます。
AIがコードを直してくれたとしても、コンパイルが通らなければ意味がありません。見た目は立派な刀でも、鞘から抜けなければ戦えません。
チャットだけだと手間が残る
ChatGPTやCopilotのチャットだけでも、COBOLの修正案を出すことはできます。
ただし、チャット形式だけだと、どうしても人間側の作業が残ります。
- AIから修正案をもらう
- 自分でソースへ反映する
- 自分でコンパイルする
- エラーをコピーする
- またAIに貼り付ける
- 再修正する
1回だけなら問題ありません。しかし、何度も繰り返すと、かなり手間です。
気づくと、AIを使っているはずなのに、自分がコピー＆ペースト職人になっています。これは少しもったいないです。
コンパイル用シェルを用意する
やり方自体はシンプルです。対象ファイルをコンパイルするためのシェルを用意しておけばよいです。
たとえば、実際のコンパイルコマンドは会社や環境によって違いますが、考え方としては以下のような形です。
#!/bin/bash
set -e
TARGET="sample.cob"
LOG="compile.log"
echo "=== COBOL compile start ===" | tee "$LOG"
# 実際の現場のコンパイルコマンドに置き換える
# 例：cobc -x "$TARGET" -o sample
# 例：社内ビルドコマンド "$TARGET"
cobc -x "$TARGET" -o sample 2>&1 | tee -a "$LOG"
echo "=== COBOL compile success ===" | tee -a "$LOG"ポイントは、Codexが実行しやすい形でコマンドをまとめておくことです。
毎回、人間が長いコマンドを打つのではなく、次のように実行できる状態にします。
./build_cobol.shこれだけでコンパイルできるようにしておくと、Codexに依頼しやすくなります。
Codexに任せる流れ
VS Codeで対象プロジェクトを開き、Codexに次のように依頼します。
対象のCOBOLソースを確認してください。
修正後、build_cobol.sh を実行してコンパイル結果を確認してください。
コンパイルエラーが出た場合は、原因を調査して再修正してください。こうしておくと、Codexは次の流れで作業できます。
- 対象ソースを確認する
- 関連ファイルを確認する
- 修正する
- コンパイルシェルを実行する
- エラー内容を確認する
- 必要なら再修正する
- 再度コンパイルする
この流れが作れると、人間は「修正作業者」から「レビュー担当」に近づきます。
もちろん、最終確認は人間が必要です。特にCOBOLの既存システムでは、コンパイルが通っても業務仕様として正しいとは限りません。
コンパイル成功はゴールではなく、最低ラインです。
シェル作成時の注意点
コンパイルシェルを作るときは、いくつか注意点があります。
まず、対象ファイルを明確にすること。どのCOBOLソースをビルドするのか分からないと、Codexも迷います。
次に、ログを残すこと。エラー内容を compile.log のようなファイルに出しておくと、後から確認しやすくなります。
さらに、失敗時に終了コードを返すこと。コンパイルに失敗しているのに正常終了扱いになると、AIも人間も判断を誤ります。
また、本番環境に影響するコマンドは絶対に入れないこと。AIに実行させるシェルは、ローカルまたは検証用の安全な範囲に限定すべきです。
ビルド用シェルは便利ですが、強い道具です。刀と同じで、置き場所と使い方を間違えると危ないです。
CI/CDと組み合わせるとさらに強い
ローカルでコンパイルできるようになったら、次はCI/CDとの連携も考えられます。
たとえば、GitHub Actionsや社内CI環境で、以下を自動実行します。
- COBOLコンパイル
- 静的チェック
- 単体テスト
- 差分確認
- 成果物作成
これができると、Codexが修正した内容を、人間が確認する前に自動で検証できます。
AIが修正する。シェルでコンパイルする。CI/CDで確認する。人間がレビューする。
この流れができると、AI活用はかなり実務向きになります。
まとめ
CodexでCOBOLを修正するなら、修正案を出して終わりにするのはもったいないです。
対象ファイルをコンパイルするシェルを用意しておけば、Codexに修正後のコンパイル確認まで依頼できます。
修正する。コンパイルする。エラーを見る。再修正する。再ビルドする。
この流れをAIと一緒に回せるようになると、COBOL保守の生産性はかなり上がります。
ただし、コンパイルが通ったからといって、業務的に正しいとは限りません。
最終的には、SEが業務仕様、影響範囲、テスト結果を確認する必要があります。
AIには作業を速くしてもらう。人間は判断する。
この役割分担が、Codex + VS CodeをCOBOL保守で安全に使うための現実的な形だと思います。
この記事は、AIが書いたコードをSEはどこまで信用してよいのか？ の実践編として読むと自然です。