はじめに
AIによるコード生成はとても便利です。
しかし同時に
「動いていたコードが壊れた」
「意味が変わっている」
「微妙なバグが混入した」
という経験をした人も多いはずです。
なぜ AI はコードを壊すことがあるのでしょうか。
これはモデルの欠陥というより、AIがコードをどう理解しているかに原因があります。
AIはコードを「意味」ではなく「パターン」で扱う
AIはプログラムを実行も理解もしません。
AIが見ているのは
・トークン列
・構文パターン
・過去の類似コード
です。
そのため
「意味が違うが見た目が似ている」コードを平気で置き換えます。
人間にとっての「意味の違い」は、AIにとっては「確率の違い」でしかありません。
なぜ壊れるのか
コンテキストが切れる
モデルは一定量の文脈しか保持できません。
長いファイルやプロジェクトになると
・冒頭の仕様を忘れる
・前の設計方針を忘れる
・重要な制約を落とす
ということが起きます。
その結果、後半で一貫性が壊れます。
局所最適化が入る
AIは
「その行をそれっぽく直す」
のが得意です。
しかしそれが
・全体の設計
・非機能要件
・パフォーマンス要件
と衝突することがあります。
部分最適の積み重ねが全体破壊になります。
未定義動作を平気で作る
AIは
・スレッド安全性
・メモリ可視性
・例外安全
・競合状態
といった非局所的な性質を正しく追跡できません。
そのため「見た目が正しいが実際は危険」なコードを作ります。
エラーメッセージに過剰適応する
コンパイルエラーや警告を貼ると、AIは
「このエラーを消すこと」
を最優先にします。
意味を変えてでもエラーが消えれば成功と判断します。
それが意図しない動作変更を生みます。
仮想のAPIを発明する
存在しない関数やオプションを、それっぽく生成することがあります。
人間がレビューしないと、架空の世界のコードが混入します。
なぜレビューが必須なのか
AIの出力は
・コンパイルが通る
・テストが通る
・見た目が綺麗
でも
・仕様を満たしていない
・境界条件が壊れている
・性能が劣化している
ことがあります。
人間のレビューは
「意味」を見る工程です。
安全に使うための指針
小さく頼む
関数単位、差分単位で使う。
仕様を先に書く
コードではなく仕様を渡す。
差分レビューを必ずする
丸ごと置換は禁止。
テストを先に書く
AIが壊したらテストが落ちるようにしておく。
まとめ
AIは優秀な補助輪ですが、自律走行はまだできません。
・AIは意味を理解していない
・確率的にそれっぽいものを出しているだけ
・だから壊れることがある
壊れないために必要なのは、制限とレビューとテストです。
人間が責任を持つ限り、AIはとても強力な道具になります。