よくある状態：「このプロジェクトはもともとテストコードがないから」で、今日も書かない。リファクタリングは「いつかやりたいね」のまま数年。
こうする
書き始める。 理由は単純で、書くのが難しくなくなったからです。AIが書いてくれます。
- 新しく触った箇所からでいい。全部にテストを付ける必要はない
- 「この変更にテストを書いて」とAIに頼むことを、作業の標準に組み込む
- テストが書きにくいコードに当たったら、それはリファクタリングの合図。それもAIにやらせる
もちろんコードベースによっては難しいものもあります（テスト基盤がない、DBに密結合している等）。それでも「書ける方向へ寄せていく」。基盤づくりそのものもAIに任せられます。諦めるのは早い。
なぜ
テストはAIに任せるための安全網だからです。
人間が全部レビューする前提なら、テストがなくても「自分の目」でカバーできた（できている気になれた）。
でもAIに任せて並列で回す働き方（軸B）では、変更が壊していないことを機械的に確認できる仕組みがないと、結局全部人間が見ることになり、手離れしません。
テストがあると：
- AI自身が「自分の変更が何かを壊していないか」を確認してから完了報告できる
- レビュー（AI・人間とも）が「動くかどうか」から解放され、設計や仕様の確認に集中できる
- 「AIに任せるのが不安」の大部分が、仕組みで潰れる（1）
リファクタリングも同じ
リファクタリングにもコストをかけたほうがいい。そして早く始めるほど良い。
理由はテストと同じ構造です。読みにくいコード・巨大な関数・暗黙の前提だらけの設計は、人間だけでなくAIの精度も下げます。AIが理解しやすいコードベースは、任せられる範囲が広いコードベースです。
改善は複利で効きます。汚い場所を1つきれいにすれば、以降そこに触るすべてのタスク（人間のもAIのも）が速く・正確になる。放置すれば、すべてのタスクが遅く・不正確なままです。
「テスト書く時間がない」——書くのはAIです。人間が払うコストは、テスト観点のレビューだけ。それも受け入れ条件の明文化ができていれば、そこから導けます。
お知らせ
この記事は、イデアライブ社内の「AI駆動開発の考え方」ドキュメント（全12本）をシリーズとして公開しているものです。