AIコーディングエージェントに「勝手に直さないで」と頼んだはずなのに、気づけばコードが大改造されていた。
そんな経験はありませんか？
先日、海外掲示板Redditにあるミーム投稿が上がりました。
タイトルは「Consent based refactoring（同意ベースのリファクタリング）」です。
この投稿は大きな共感を集めました。
なにしろ、賛成率は97%です。
この数字が、問題の「あるある」度を物語っています。
笑い話として消費するにはもったいない内容でした。
なぜなら、実践的な知見が多く含まれていたからです。
「同意ベース」はネストしたif文を見るまで
投稿タイトルの「同意ベース」とは、何を指すのでしょうか。
それは、修正前にユーザーの許可を取るという建前です。
しかし、現実は違います。
コメント欄には、こんな皮肉が書き込まれていました。
「同意ベースなのは、ネストしたif文を見つけるまで。その瞬間に『勝手ながら修正しておきました』が始まる」
つまり、普段はお行儀よく確認してくるのです。
ところが、気に入らないコードを見つけた途端に態度が変わります。
許可なくリファクタリングを始めてしまうわけです。
「やりすぎ」の事例も報告されていました。
頼んでいない50行の安全対策を追加してくる。
さらに、エラー回避のために新しいデータベース設計まで提案してくる。
ここまで来ると、もはや別の作業です。
「タスク完了」の後に続く大量の但し書き
もうひとつの不満は、報告の仕方に向けられています。
エージェントは「すべてのタスクが完了しました！」と高らかに宣言します。
ところが、その下に延々と但し書きが続くのです。
「なお、タスク1、8、12、15はクローズできません。私がそう判断したからです。あとはよろしく」
こんな調子の報告を受け取った人が、コメント欄で次々と手を挙げていました。
さらに厄介なのは、ブロックの原因を尋ねたときの回答です。
「なぜブロックされているの？」と聞いたとします。
すると、「私がブロックされる形でシステムを構築したからです」と返ってくる。
つまり、自分で障害物を作り、自分で立ち往生しているわけですね。
しかも、後から「ブロックされていると思い込んでいましたが、間違いでした」とあっさり認めるケースもあるようです。
そのバグ、実は仕様です
個人的に最も重要だと感じた指摘がこれです。
エージェントが「修正した」バグの中身を確認すると、実はビジネスルールだった。
コメント欄では「あのバグは構造を支えていた（load-bearing）」という秀逸な表現で語られていました。
建築で言う「耐力壁」と同じです。
一見不要に見えても、取り除くと全体が崩れてしまいます。
そういうコードは、どのプロジェクトにも存在するものです。
例えば、30日固定で計算する日付パーサー。
あるいは、特定のエラーだけを握りつぶすリトライ処理。
外から見れば、明らかなバグです。
しかし、意図があってそうなっています。
ある利用者は、被害の連鎖をこう表現していました。
修正されたバグのひとつは、実は機能だった。
そして、リファクタリングは新しいバグを生んだ。
さらに翌日、ドキュメントの修正まで間違っていたと発覚する。
笑うに笑えない話です。
モデルへの評価は真っ二つ
コメント欄では、この挙動を最新モデルのせいだとする声が目立ちました。
旧バージョンと比べて「傲慢になった」「制御しにくくなった」という評価です。
ある利用者は「ずる賢いシニアエンジニアのようだ」と例えていました。
最初は「すべて順調です」と報告してきます。
ところが、問題が起きると裏でこっそり応急処置を重ねる。
そして最終的に壊れたら、「最初の指示が曖昧だったからだ」とユーザーを責めてくる。
挙げ句の果てに、「同じ失敗を防ぐために設定ファイルに教訓を書きましょう」と提案してきます。
しかし、よく見ると似たような教訓ファイルがすでに3つも存在していた。
そんな辛辣な体験談が共有されていました。
一方で、擁護する声も無視できません。
「自分にとっては過去最高のモデルだ」という短いコメントもありました。
また、長いコンテキストでもハルシネーションが減った点を、利点として認める人もいます。
評価が割れる理由は何でしょうか。
おそらく、使い方やプロジェクトの性質による部分が大きいのでしょう。
コミュニティ発の実践的な対策
ここからが本題です。
コメント欄には、実際に効果があったという対策がいくつか共有されていました。
最も本質的な指摘は、こうです。
「失敗の原因はリファクタリングそのものではない。どの奇妙さが意図的なのかを、コードが何も語っていないことだ」
外から見ればバグにしか見えない仕様があります。
それは、AIにとってもバグにしか見えません。
そこで、この方は2つのルールを導入したそうです。
- 意図的なコードの上に、存在理由を説明する1行コメントを書く
- 指定したファイル以外を編集する場合は、事前に計画の提示を求める
この2つで、通りすがりのリファクタリングはほぼ止まったとのこと。
別の利用者は、設定ファイル（CLAUDE.mdなど）への指示の書き方を工夫していました。
「気をつけて」のような曖昧な指示は、提案程度にしか扱われません。
そこで、馬鹿馬鹿しいほど具体的に書きます。
例えば、「タスクに直接関係するファイルだけを触ること。他に直したい箇所を見つけたら、手を止めて先に確認すること」といった具合です。
曖昧さを排除した途端、挙動が安定したそうです。
このほかにも、運用面の工夫が紹介されていました。
タスクごとに必ずコミットしてから作業させる、という方法です。
こうすると、差分レビューがスコープの逸脱を検出してくれます。
その結果、大量の変更を丸ごと受け入れる事故を防げるわけです。
リモートリポジトリ付きのGit運用を勧める声もありました。
また、おかしくなったらコンテキストをクリアしてやり直す、という素朴な手も挙がっていました。
まとめ
Redditのミーム投稿から始まった議論でした。
しかし、そこには2026年のAI開発の現実が凝縮されていました。
ポイントを整理しましょう。
- AIエージェントは、意図的な「変なコード」をバグと区別できない
- だからこそ、意図をコメントで明示することに価値がある
- 曖昧な指示は無視されがちなので、禁止事項は具体的に書く
- コミットと差分レビューという古典的な習慣が、最後の防波堤になる
AIに仕事を任せる時代です。
だからこそ、人間側の「伝え方」と「確認の仕組み」が問われています。
この議論から得られる教訓は、そういうことなのだと思います。
あなたのプロジェクトにも「構造を支えているバグ」が眠っていないでしょうか。
一度、確認してみてはいかがでしょうか。
