目次
「AIで直します」と言われた方へ
不具合の修正や改修をAI前提で提案されていて、どこまで任せてよいか決めかねている方に向けて書いています。
危ないのは、AIが直したところではありません。頼んでいないのに変わったところです。
直したところ以外が変わっています
AWSが2026年3月に公開した分析に、この現象の中身が書かれています（バグ修正のパラドックス、原文は2026年2月19日公開）。
バグ修正を頼むと、エージェントはヘルパー関数を3つリファクタリングし、防御的なnullチェックを足し、すでに通っているエッジケースに何十ものテストを書く。そして正常に動いていた部分まで変えてしまう。
数字が1つ挙がっています。エージェントは人間の約2倍の確率で、ガード節や防御的なエラーハンドリングを追加する。人なら「なぜnullなのか」と問うところを、エージェントはif (x == null)を足して先へ進みます。
記事はこれを「メスを求めたのに、スレッジハンマーが返ってきた」と表現しています。
問題は精度ではありません
原因の指摘が正確です。
あなたとエージェントが、何を直すべきかと何をそのままにすべきかの境界を共有していない。ここが本質だとされています。
モデルを賢くしても解けません。境界は、モデルの中ではなく指示の側にあるからです。
境界が暗黙だと、3つのことが起きます
経験のあるエンジニアは全員この境界を考えていますが、たいてい暗黙のままです。明示されていないと何が起きるかが整理されています。
| 起きること | 中身 |
|---|---|
| 境界から逸脱する | 境界の永続的な記録がないため、各ステップで境界をゼロから解釈し直す |
| 境界を独自に作る | 曖昧な部分を推測で埋める。人と違うのは、その推測を明示しないこと |
| 守ったか確認できない | 明示された境界がなければ、他が壊れていないことを体系的に確かめられない |
2つ目が厄介です。レビューで食い違いに気づいたときには、パッチはすでにその推測を前提に組み上がっています。
直す条件と、直さない条件を先に書く
AWSが示している方法はproperty-aware code evolution（プロパティ指向コード進化）と呼ばれています。やることは単純です。
まずバグ条件Cを書く。バグが出るトリガーを特定し、入力空間を2つに割ります。次に事後条件Pを書く。「直った」とはどういう状態かを定義します。Pがないと、エージェントはtry/exceptで例外を握りつぶして「修正済み」と判断してしまう、という指摘つきです。
この2つから、テストできる主張が2本出てきます。
修正前のコードが仕様になります
手順で効いているのは、テストを書く順序です。
保持テストは、修正前のコードに対して先に実行して、通ることを確かめてから残します。修正前の実際の動きを記録して、それを主張にする。そのうえで修正を当て、同じテストがまだ通ることを確認します。
つまり修正前のコードが仕様として機能します。これはレガシー改修で使われる特性テストと同じ発想で、正しいかどうかを問わず現在の動きを固定する考え方です。
判定の読み方も決まっています。バグ条件テストが通らなければ、原因の仮説が間違っていた。保持テストが落ちたなら、修正に副作用がある。どちらも次にやることが決まる、という設計です。
1行の修正に、5経路の保持テスト
規模の感覚が分かる例が載っています。Apache RocketMQ のメモリリークです。
登録時のキーにはグループ名が前置されるのに、削除時のキーには付いていない。だから一致せず、登録解除が毎回何もしない操作になっていた。修正は1行、削除側のキーにグループ名を足すだけです。
ところが、同じリスナーを通るコードパスが5つありました。引数がnullの場合、想定した型でない場合、複数グループの登録、といった具合です。その全部に個別の保持テストを書き、修正を当てる前に通ることを確かめています。
変えた行数と、変えていないことを確かめる仕掛けの量が、ここまで釣り合いません。
効かない範囲も書いてあります
この方法が万能ではないことも明記されています。
効くのはロジックの誤り、エッジケース、実行時例外、データ処理の不具合。一方で性能や競合状態のような非機能の関心事は、非決定的で時間的な推論が要るため、プロパティとして表現しにくい。未解決の課題だとしています。
自社の手法の限界を先に書いてあるので、効く範囲のほうも信用して読めます。
提案を受けたときに確認すること
AIによる改修の提案で確かめる4つの質問
-
変えない範囲はどこですか。提案書に範囲として書かれていますか
-
変えていないことをどう示しますか。修正前の動きを記録したテストがありますか
-
そのテストはいつ書きますか。修正の後に書くなら、変わった後の動きを固定することになります
-
直ったの定義は何ですか。例外を握りつぶしても「直った」に見えない基準がありますか
改修見積もりのレビュー、ベンダー比較の評価シートにそのまま転記して使えます
範囲は、契約書に書ける粒度です
AIが作ったコードを人が見る理由は以前まとめました。今回はその手前の話です。見る前に、見るべき範囲を決められる。
レガシー刷新でも同じ形が出てきます。2年が2日になった案件で速さの正体だったのは、渡す前に業務を9つへ割ってあったことでした。渡す範囲を決めるのは人の仕事で、そこは短縮されていません。
改修も同じです。どこを直し、どこを直さないか。この線引きは、発注時点で文章にできます。
自社の改修でどこまでをAIに任せるか、範囲の書き方から整理する段階でしたら、お問い合わせからご相談ください。
出典
- バグ修正のパラドックス：AI エージェントが正常なコードを壊してしまう理由（Amazon Web Services ブログ、2026年3月5日。原文は Jatin Arora による 2026年2月19日公開の記事）