AIをコーディングに使うときの線引き——任せる範囲・自分で読む範囲・テストで守る範囲

AIにコードを書いてもらうときの線引きは、「任せる」「自分で読む」「テストで守る」の3つに分けておくと迷いが減ります。全部をAIに任せるか、全部を自分で書き直すかの二択にすると、どちらに転んでも疲れます。私は小さな案件を一人で回すことが多く、最近は実装の多くをAIと一緒に進めていますが、事故が起きにくくなったのは「どこを人が持つか」を先に決めるようになってからです。

前提として、ツールの提供元自身も人の確認を求めています。GitHubはCopilotの責任ある利用に関するページで、提案を受け入れる前にレビューして検証する責任は利用者にあること、もっともらしく見えても正しくないコードが出る場合があることを説明しています。この前提に立ったうえで、どう分けているかを書きます。

任せる範囲：やり直しが安いもの

AIにまるごと任せているのは、間違っていてもすぐ気づけて、すぐ戻せるものです。

• 既存コンポーネントと同じ形の新しいコンポーネント
• 一覧ページの雛形、フォームのマークアップ
• 一度きりのデータ変換スクリプト
• ファイル名や変数名の一括リネーム

共通しているのは、画面を見れば正誤がわかり、Gitで差分を捨てれば元に戻る点です。ここで細かく口を出すと、AIを使う意味が薄れます。指示には「何のために」「どの既存ファイルに合わせて」の2点だけを書くようにしています。

逆に、任せる前に書いておく必要があるのは、コードを読んでもわからない事情です。Claude Codeのベストプラクティスでも、デプロイの手順や触ってはいけないファイルのように、リポジトリから読み取れない情報を伝えることが要点として挙げられています。私の場合は、本番の環境変数の扱い、外部サービスの契約上の制限、クライアントとの合意事項がそれにあたります。

自分で読む範囲：壊れたときに気づきにくいもの

差分を自分の目で一行ずつ読むのは、間違っていても画面上は動いて見えるものです。

領域	読む理由
認証・権限	見えてはいけない人に見えても、自分の画面では気づけない
決済・金額計算	端数や税の扱いは、表示が出ていれば正しく見えてしまう
個人情報の送信先	どこに何が送られているかは、画面に出ない
データの削除・上書き	一度実行すると戻せないことがある

ここは「AIが書いたから」ではなく、人が書いても読む場所だと考えています。読むときは、コードの書き方の良し悪しより「この変更で誰に何が届くようになったか」を追います。読み切れない量の差分になっていたら、それ自体を差し戻しの理由にして、AIに小さく分けて出し直してもらいます。

テストで守る範囲：毎回確かめたいもの

3つめは、人が毎回読むには手間がかかりすぎるけれど、壊れたら困るものです。ここはテストや型チェックに任せます。

前述のClaude Codeのドキュメントには、作業が本当に終わったかを確かめる手段がないと、AIは「終わったように見える」ところで止まってしまう、という趣旨の説明があります。あわせて、「テストが通った」という報告だけでなく、実行したコマンドとその出力を証拠として出してもらうよう勧めています。私もこれに近い運用で、AIに頼むときは次のどれかを必ず指示に入れています。

• このテストを実行して、通るまで直してから報告する
• 型チェックとビルドの出力を貼ってから報告する
• 不具合の再現テストを先に書き、失敗を確認してから修正する

また同じドキュメントでは、毎回例外なく守らせたいルールは、指示文ではなくフック（決まったタイミングで自動実行される仕組み）や拒否ルールで強制するよう説明されています。「本番に勝手にデプロイしない」「特定のフォルダは編集しない」といったルールは、私も指示文に書くだけでは済ませず、設定のほうで止めるようにしています。

3つの境界は案件の最初に決める

この線引きは、作業の途中で決めるとぶれます。私は案件の最初に、リポジトリのREADMEや作業メモへ次の3行を書いておきます。

1. 任せる：画面と差分で確認できるもの（例：UIの雛形、リネーム）
2. 読む：認証・金額・個人情報・削除に触れる変更
3. テストで守る：ビルド・型チェック・主要フローのテスト

チームで開発しているなら、2に該当する変更はプルリクエストで誰が承認するかもあわせて決めておくと安心です（流れはディレクターが知っておくGitの範囲にまとめています）。

明日から試せる一手

いま進めている案件で、直近にAIへ頼んだ変更を3つ選び、「任せる・読む・テストで守る」のどれに当たるかを書き出してみてください。「読む」に入るはずなのに読まずに取り込んだものがあれば、そこが次に線を引く場所です。そのうえで、テストで守る範囲について「このコマンドを実行して、出力を貼ってから報告して」と指示に一行足す。それだけでも、AIからの「できました」をそのまま信じる回数が減っていきます。