AIを使うと、コードは一気に書けます。これまで数日かかっていた実装が、数時間で終わることもあります。
しかし、AIが書いたコードを人間が一行ずつ読み、細かなロジックまで確認していたら、そこで作業が止まります。コードを書く速度だけ上がっても、レビューが追いつかなければ意味がありません。
AI時代の品質は、コードを全部読むことではなく、安全に試して、問題があればすぐ戻せる仕組みで守る。
この記事で伝えたいことは、これだけです。
人間がコードを全部読む方法には限界がある
コードレビューは必要です。認証や決済のように、間違えたときの影響が大きい処理は、人間がしっかり見るべきです。
ただし、画面の文言修正から決済処理の変更まで、すべてを同じ細かさで確認する必要はありません。AIが作るコードの量が増えれば、人間がすべてを読み切るのは難しくなります。
急いで読めば見落とします。丁寧に読めばリリースが遅れます。しかも、レビューを通ったコードでも本番で不具合は起きます。
だから、品質をコードレビューだけで守ろうとしない。安全に試して、問題があればすぐ戻せるようにします。
実装する前に「成功」と「失敗」を決める
例えば、AIにログイン機能を修正させるとします。「ログインできた」だけでは、確認として不十分です。
- 正しい情報ならログインできる
- パスワードが違えば拒否される
- ログイン中の利用者に影響が出ない
- エラーや応答時間が悪化していない
このように、何ができたら成功なのかを先に決めます。同時に、エラー率が一定の値を超えたら失敗と判断する、といった停止条件も決めます。
AIにはコードだけでなく、テストも作らせます。「テストしました」という報告ではなく、CIの結果やログなど、人間があとから確認できるものを残します。
コードを全部読む代わりに、成功と失敗を判断できるようにする。これが最初の一歩です。
新しいコードをいきなり全員に使わせない
テスト環境で問題がなくても、本番では失敗することがあります。データ量、通信状況、外部サービスなど、本番にしかない条件があるためです。
そこで、新しいコードを一部の利用者だけに公開します。エラー率や応答時間を見ながら、問題がなければ少しずつ対象を広げます。問題があれば、その場で公開を止めます。
新機能なら、Feature Flagで機能をオフにできるようにしておく方法があります。一部のアクセスだけを新しい版へ流す、カナリアリリースも使えます。
小さく試して、問題が広がる前に止める。これならAIの速さを生かしながら、失敗の影響を小さくできます。
ブルー・グリーンデプロイで、すぐ戻せるようにする
ブルー・グリーンデプロイでは、現在動いている環境を残したまま、別の環境へ新しいコードを入れます。
現在の環境をブルー、新しい環境をグリーンとします。まずグリーンで動作を確認し、問題がなければアクセス先を切り替えます。切り替えたあとにエラーが増えたら、ブルーへ戻します。
この流れはAIとも相性がよいと思います。AIにグリーンへの配置、テスト、エラー率の確認まで実行させます。基準を満たせば切り替え、超えたら自動でブルーへ戻します。全利用者への切り替えだけ人間が承認する、といった運用もできます。
AIに速くリリースさせるなら、AIに失敗を見つけさせ、すぐ元へ戻せるようにもしておく。
ただし、データベースの変更には注意が必要です。アプリを前の版へ戻しても、書き換えたデータまで元に戻るとは限りません。新旧どちらの版でも扱えるように少しずつ変更し、バックアップと復元手順を用意しておく必要があります。
人間は「どこまでAIに任せるか」を決める
AIに自由な本番操作をさせる必要はありません。人間が先にルールを決めます。
- どのテストを通せばリリースできるか
- どの数値を超えたら止めるか
- どの操作に人間の承認が必要か
- 問題が起きたら、どこまで自動で戻すか
AIは、その範囲の中で作業します。人間はすべてのコードを監視するのではなく、AIが安全に動ける範囲を決めます。
まとめ
AIが大量のコードを書く時代に、人間がすべてを細部まで読む方法だけでは追いつけません。
だから、実装前に成功と失敗の条件を決めます。新しいコードは小さく試します。エラーが増えたら止めます。そして、問題があればすぐ前の状態へ戻します。
AI時代の品質は、コードを全部読むことではなく、安全に試して、問題があればすぐ戻せる仕組みで守る。
この仕組みがあれば、AIの速さを殺さずに、システムの品質を守れます。
コメント