はじめに
ClaudeCode、Codex、Copilot・・・
などなどエージェント型コーディングツールが登場してから開発生産性がグッと上がりました。
私も普段はClaudeCodeを使ってバイブコーディングをしているのですが、凄い...恐ろしい...！と思うくらい恩恵を授かっています。
日に日に精度も高くなっており、もう本当に任せっきりでいけるやん！と思っていたある日、事件は起きました。
余計なことをするAI
その日は新機能の実装を行なっていました。
いつもの通りにロジックを丁寧に定義したいい感じのプロンプトを書いてAIさんに実装を進めてもらいました。
実装が終わり、自身のローカル環境で動作確認…問題なし！完璧や！！
となりPRを作成し、レビューも通り、無事mainにマージされました。
しかしリリース後、別の機能が使えなくなってしまう不具合が発生していたのです。
実装時に不具合発生した機能の近くのコードを弄っていた記憶があり、まさかと思い見てみると、新機能に関係のない関数の引数のフラグが一つ逆転していたのです。
hogeFunction(false); // trueにしないと動かない
自分で触った記憶がありません。しかし、変更履歴を見ると私が変更しているのです。
そうです、AIが新規機能を実装するついでにこのフラグを逆転させていたのです。
なぜセルフレビューの時に気づけなかったのか、なぜレビューが通ってマージされてしまったのか・・・
振り返ってみると色々と問題が浮き彫りになりました
レビューで気づけなかった理由
結論、PRの変更差分が大きかったからです。
変更行数が400行くらいの大きめのPRでした。
しかも、レビューの対象は既存機能ではなく新規機能実装部分に目が行きがちです。
そのため、私もレビュアーのメンバーも見逃してしまいました。（レビュアーに非はありません・・・！🙏）
実際のローカル環境の画面で動作確認しようにも新機能とは全く関係のない機能のエッジケースの不具合であったため、そもそも動作確認の対象にすら挙がりませんした。
どうすれば防ぐことができたのか
テストを書く
当たり前体操ですが、今回の修正箇所の部分はたまたまテストが未実装の部分でした。（普段は基本的にテストを書く運用なのですが・・・）
フラグの指定を検知できるテストさえあればまず間違い無く防げていました。10打数10安打で動作を保証してくれるテストコードはやはり貴重です。
AIを活用することにより生産性が向上する一方で、しっかりとコードを守るという意味でもテストを実装する意味がより増してきているかと思います！
PRのレビューにAIも追加する
Github Copilotなどを活用し、人間だけでなくAIにもチェックさせましょう。
AIのレビューは結構不要な変更点などに [ask] で尋ねてくれるイメージがあります！
また実装に使ったAIエージェントのコンテキストを一旦リセットして、真っ新な頭でレビューさせるのも良いかと思います。（自分で作った実装に自分でケチつけてもらう
ただ、もちろんAIはAIなので見逃す可能性は十分にあります。
あくまで補助的な位置付けでレビューをしてもらい、安易にAIのレビューを信じすぎなようにするのが大事です。
PRの差分はなるべく小さくする
仕組みで解決できる部分があるとはいえ、最終的に確認するのは人間です。
今回のように差分が大きくなると、どうしても細かい変更点を見逃してしまうリスクがあります。
人に優しいPRを作るように心がけましょう
AIによる実装も細かい単位で進める
AIエージェントが実装を進める際に「**を@@に変更します。」のように変更履歴を残してくれますが、
当然この変更履歴の量が多くなると、細かい変更は見逃しがちです。
指示は雑だったり、複雑な実装になればなるほど、AIの実装時間は長くなり、気がついたらコンテキストが圧縮されており変更が追えなくなる。。。みたいなこともありがちです。
そのため、段階を踏んで少しずつ実装を進め、常に確認しやすい形を維持することが大事です。
結論、この一言に尽きる
AIが出力した情報は、情報が古かったり誤っている可能性もあります。AIが出力した情報をそのまま利用するのではなく、必ず人間が確認した上で活用しましょう。
終わりに
最後まで読んでいただきありがとうございました！
正直不具合を発生させてしまった時はもうAIの活用をやめてしまおうかと思うくらい、AI恐怖症になりかけたのですが、しっかりと振り返りを行い、改善策をじっくり考えることができました。
AIを活用することよって開発生産性は大きく向上しますが、100点を出すのはまだまだ難しいツールなんだなと痛感させられました。
AIの活用とともに自身の技術知識の向上も決して怠ってはいけない、と尻を叩かれたような出来事でした。