AIが書いたコードをSEはどこまで信用してよいのか？
1. AIコーディングは確実に広がっている
AIにコードを書かせることは、もう特別なことではなくなってきました。
簡単な関数、SQL、テストコード、エラー原因の調査、リファクタリング案。AIに依頼すると、かなりの速度でそれっぽいコードが返ってきます。
私自身も、ChatGPTやCodex、VS Codeを使いながら、コード解析や修正方針の整理を行うことがあります。特にレガシーシステムのように、設計書が頼りなく、ソースを読まないと分からない現場では、AIの力はかなり大きいです。
昔なら、ソースを読み、関連ファイルを探し、影響範囲を確認し、修正案を考えるだけでかなり時間がかかっていました。今はAIに補助してもらうことで、最初の理解までの時間をかなり短縮できます。
ただし、ここで勘違いしてはいけないことがあります。
AIがコードを書けることと、そのコードをそのまま信用してよいことは別です。
AIは速いです。でも、速いから正しいとは限りません。新幹線くらい速く間違えることもあります。
2. ただし、AIの出力は“正しそう”に見える
AIが怖いのは、間違っていても正しそうに見えることです。
コードの形は整っている。変数名もそれっぽい。コメントも丁寧。説明も自信満々。
見た目だけなら、かなり頼れる先輩のように見えます。
しかし、実際には条件が漏れていたり、既存仕様とズレていたり、例外ケースを考慮していなかったりします。
特に怖いのは、AIが「一般的には正しいコード」を出してくることです。しかし、現場で必要なのは「このシステムで正しいコード」です。
この差はかなり大きいです。
業務ルール、過去の暫定対応、顧客別の例外、古いデータの扱い。こうした現場固有の事情は、AIが知らないことも多いです。
つまり、AIのコードは、まず「たたき台」として見るべきです。完成品として扱うには、SE側の確認が必要です。
AIは優秀です。ただし、たまに「知らないのに知っている顔」をします。ここを見抜くのが、これからのSEの重要な仕事になります。
3. 現場SEが見るべきレビュー観点
AIが書いたコードを見るとき、現場SEは最低限、次の観点を確認した方がよいです。
まず、仕様を満たしているか。依頼した内容に対して、処理条件が正しく反映されているかを確認します。
次に、例外ケースです。データが存在しない場合、NULL、空文字、0件、重複、桁あふれ、権限不足などが考慮されているかを見ます。
さらに、既存のコーディング規約に合っているかも重要です。動くけれど、現場の書き方と違いすぎるコードは、後で保守しづらくなります。
そして、テストしやすいか。AIが書いたコードほど、テストで裏取りする必要があります。
レビューでは、こう考えるとよいです。
「このコードはきれいか」ではなく、
「この現場で安全に動かせるか」
ここが重要です。
現場SEが見るべき観点を整理すると、次のようになります。
・仕様を満たしているか
・例外ケースを考慮しているか
・既存の処理と整合しているか
・コーディング規約に合っているか
・テストしやすいか
・保守しやすいか
・処理性能に問題がないか
・セキュリティ上の問題がないか
・業務上の意味が正しいかAIが作ったコードを見て、「なんとなく良さそう」で通すのは危険です。なんとなく良さそうなコードは、なんとなく本番で牙をむくことがあります。
4. 既存システムでは影響範囲確認が必須
新規開発なら、AIが出したコードを比較的試しやすい場面もあります。
しかし、既存システム、特にレガシーシステムでは注意が必要です。
1つの修正が、画面、帳票、バッチ、外部連携、共通部品に影響することがあります。しかも、その影響が設計書に書かれていないこともあります。
そのため、AIに修正させる前に、影響範囲を確認する必要があります。
どこから呼ばれているのか。どのファイルを更新するのか。同じ項目を別処理で使っていないか。帳票や集計処理に影響しないか。テストすべきパターンは何か。
ここを見ずに修正すると、目の前のエラーは直っても、別の場所で問題が出ることがあります。
レガシーシステムは、古い城のようなものです。一つの壁を直したつもりが、なぜか別の部屋のふすまが開かなくなることがあります。
だからこそ、AIに任せる範囲と、人間が確認する範囲を分けることが大切です。
AIには、処理の整理、関連ファイルの候補出し、修正案の作成、テスト観点の洗い出しを任せる。SEは、業務仕様、影響範囲、品質、リリース可否を判断する。
この役割分担が現実的です。
5. AI時代にSEが伸ばすべき力
AI時代にSEが伸ばすべき力は、AIより速くコードを書く力だけではありません。
むしろ、次の力が重要になります。
AIに正しく指示する力。AIの出力をレビューする力。既存システムの影響範囲を読む力。テスト観点を出す力。業務仕様として正しいか判断する力。
AIがコードを書く時代になると、SEの役割は「手を動かす人」から「判断する人」に少しずつ変わっていきます。
もちろん、コードを書けなくてよいわけではありません。コードを読めないと、AIの出力を評価できません。
AIを使うほど、基礎力が必要になります。これは少し意外かもしれません。
AIがあるから勉強しなくてよいのではなく、AIを使いこなすために勉強が必要になります。
刀を持っていても、振り方を知らなければ危ないのと同じです。AIもかなり切れ味のある道具です。
これからのSEに必要なのは、AIに仕事を丸投げすることではありません。AIを使って調査や修正の速度を上げ、その結果を自分で判断できることです。
若手SEにとっては、AIは大きなチャンスです。ただし、AIが出した答えをそのまま信じるのではなく、レビューできる力をセットで育てる必要があります。
6. Codex + VS Codeで安全に使う方法
AIコーディングを実務で使うなら、チャット単体よりも、Codex + VS CodeのようなIDE連携が使いやすいと感じています。
チャットだけだと、コードを貼る、回答をもらう、自分で反映する、自分でテストする、また貼り直す、という流れになりがちです。1回ならよいですが、何度も繰り返すとかなり手間です。
VS Code上で対象プロジェクトを開き、Codexに関連ファイルを確認させながら進めると、作業の流れがかなり自然になります。
おすすめの進め方は次の通りです。
- まず処理概要を説明させる
- 関連ファイルを探させる
- 修正方針を出させる
- 影響範囲とリスクを洗い出させる
- 小さく修正させる
- テストやビルドで確認する
- 人間が最終レビューする
ここで大事なのは、いきなり「全部直して」ではなく、段階的に使うことです。
AIには、まず理解させる。次に、候補を出させる。その後、小さく修正させる。最後は人間が確認する。
この流れなら、AIの速度を活かしつつ、現場SEとしての安全確認もできます。
また、CI/CD環境を整えておくと、さらに安全に使いやすくなります。AIが修正した内容を、ビルド・テスト・静的解析で自動確認できるからです。
AIに作らせる。IDE上で確認する。テストで確認する。CI/CDで確認する。人間が最終判断する。
この流れを作れると、AIコーディングはかなり実務向きになります。
まとめ
AIが書いたコードは、かなり役に立ちます。しかし、そのまま信用してよいわけではありません。
AIの出力は、正しそうに見えます。だからこそ、SEがレビューする必要があります。
仕様を満たしているか。例外ケースは考慮されているか。既存システムへの影響はないか。テストで確認できるか。業務として正しいか。
これらを確認して初めて、AIのコードは現場で使えるコードになります。
AIは、SEの仕事を奪うものではなく、SEの判断力をより重要にするものだと思います。
これからのSEは、AIにコードを書かせる力と、AIが書いたコードを見極める力の両方が必要です。
AIを信じすぎず、怖がりすぎず、うまく使う。それが、AI時代の現場SEに求められる姿勢だと思います。
サイト内の関連記事
AIコーディングを安全に使うには、コード生成だけでなく、既存システムの読み解きや影響範囲確認も重要です。
関連記事として、以下のテーマと合わせて読むと理解しやすくなります。
Udemy講座への導線
AIをチャットの回答だけで終わらせるのではなく、実際の開発作業に組み込むには、VS CodeやCodexのような開発環境との組み合わせが重要です。
今後、VS Code + Codexを使った開発効率化講座では、次のような内容を扱う予定です。
- VS Codeでプロジェクトを開いてAIに解析させる方法
- Codexに修正方針を出させる方法
- AIが修正したコードをレビューする観点
- ビルド・テスト・CI/CDと組み合わせる方法
- レガシーシステムの解析にAIを使う方法
AIを使えるSEではなく、AIを安全に使えるSEを目指すための講座にしていきます。