引き継いだコードをAIに見せたら、指摘が四十いくつ返ってきた。全部もっともらしいけれど、全部直す時間はない。AIが得意なのは「気になる箇所を並べること」で、「直す価値があるか」を知っているのは、次にそこを触る予定があるあなたのほうです。順番の決め方を整理しました。

障害の報告を受けてログを開いたら、残っていたのは「エラーが発生しました」の1行だけ——調査の入口で止まってしまう、あの感じ。AIにログの不足を指摘させるときの前提の渡し方と、量を増やさずに追えるようにする順番を、たどる・わかる・出さないの3つで整理しました。

同じ登録が2件、同じメールが2通、同じ請求が2回。コードは間違っていないのに、リクエストが2回来ることを想定に入れていなかっただけ——ということがあります。AIに冪等性の設計を相談するときの前提の渡し方と、AIが素通りしやすい競合の穴を、決める・弾く・返すの順に整理しました。

上がってくるコードはきれいなのに、「なぜこうしたの？」に少し間が空く。AIで速くなったぶん、詰まって考える時間が減っただけかもしれません。誰も責めずに、チームの学習を止めないための線引き・問い方・記録の残し方を整理しました。

検証では動いた。でも本番に出す当日、リリースボタンの前で手が止まる——AI機能は「バグがある」から怖いのではなく、正解が決まっていないから怖いんですよね。分ける・細く出す・すぐ戻す、の順に整えれば、出す判断はずっと軽くなります。切り戻しの決め方まで整理しました。

「本番のログを見て原因を調べて」と頼みかけて、手が止まる。エージェントは調べるだけでなく実行までできるので、渡す鍵の重さがそのまま事故の大きさになります。渡さない・絞る・追える、の順で権限を整理する手順をまとめました。

バージョンを上げたらビルドが通らない。AIに投げると直してはくれるけれど、それが正しい直し方かは別の話です。破壊的変更のうち自分たちに効くものだけを選び、1つずつ上げて、自分の目で確かめる——手戻りしにくい進め方をまとめました。

「動きません」から始まる障害報告は、原因より先に情報が足りません。AIに原因を当てさせるのではなく、足りない情報を洗わせて再現手順の形に整える——集める・整える・削るの3ステップにまとめました。

AIに頼むと、リリース前チェックリストはすぐ出てきます。ただ、そのままだと「テストを実行する」のような、どの現場にも当てはまる代わりに今回の役には立たない行が並びがち。今回の差分から効く項目を出させる頼み方と、判定できる形への直し方を整理しました。

AIが書いたコードのエラー処理は、たいていきれいに整っています。ただ、失敗したことが誰にも伝わらないまま先へ進んでいることがある。捕まえる場所の決め方、握りつぶしの見つけ方、失敗経路の確かめ方を、明日ひとつ試せる形で整理しました。

AIに頼んだDockerfileは、たいていちゃんとビルドが通ります。ただ、動くことと、本番に置いていいことは別の話。イメージがなぜか重い、rootのまま動いている、ビルド時の鍵が履歴に残っている——受け取ったあとにどこを見ればいいかを、順番に整理しました。

AIが書いた日付の処理は、だいたい動きます。ただ、深夜と月末と海外だけ静かにズレる。時差の入れ方、日付の区切り、月末の扱いまで、レビューでどこを見ればいいかを順番に整理しました。