blog
開発メモAIにどこまで任せるか——戻せる作業は任せ、本番反映は自分で止める
コードを書くAIエージェント(ここでは Claude Code)に受託の実務を任せ始めて、最初に頭を悩ませたのは、その賢さでも速さでもありませんでした。困ったのは「どこまで勝手に進めさせていいか」です。
一つひとつ「これで進めていいですか」と確認させれば、往復ばかりで前に進まない。逆に何でも自走させると、本番サーバーを触る仕事では事故が怖い。この記事は、その中間に線を引くために、CLAUDE.md(=AIエージェントに毎回読ませておく指示書。プロジェクトの作法や禁止事項を書いておくと、作業の頭で読んでくれる)を、痛みが出るたびに書き足してきた記録です。
先に断っておきます。これは「こう書くのが正解」という話ではありません。うちは受託で、本番サーバーがあって、複数の案件を複数のPCで触る。その現場の都合から出てきた、一つのやり方の報告だと思って読んでください。
なぜ線引きが要るのか
AIエージェントは驚くほど賢いのに、その現場の当たり前を知りません。人間の新人なら「本番はうかつに触らない」「消す前に一声かける」を空気で覚えていきますが、エージェントは指示がなければ最短距離を素直に進みます。うちの運用でも、放っておくと必ずどちらかに転びました。丁寧すぎて手が止まるか、気を利かせすぎて戻せないところまで進むか、です。
そこで判断の物差しにしたのが「元に戻せるか」でした。作業の難しさで決めるのをやめて、間違えたときにどれだけ楽に戻せるかで決める。これが今の運用の背骨になっています。
痛みが先、ルールが後
この指示書、あるべき論で先に書いた行はほとんど残っていません。たいていは一度困ってから足したものです。いくつか紹介します。
① 「戻せるか」で自走ラインを引く
最初は律儀に、作業ひとつごとに確認を取らせていました。これがとにかく進まない。複数のエージェントに同時に頼めば並列で片づくと思っていたのに、実際は各エージェントが数分おきに承認を求めてくるので、私のほうが画面に貼り付いて依頼を見張る羽目になる。任せて別の仕事をする、ができなかったんです。効率化しているつもりで、いちばん詰まっていたのは人間側でした。

そこで指示書に、こんな二段の線を引きました(実物はもっと細かいですが、骨はこれです)。
– ファイルの編集・新規作成
– ローカルのテスト / lint / ビルド / 読み取り系コマンド
– 後戻りが容易な範囲の自発リファクタ
# 必ず確認する(不可逆・外向き)
– 本番サーバーへの直接操作・公開
– 削除 / 上書き / force 系の破壊的操作
– 外部への送信・投稿、課金が発生する操作
振り分けの基準は、さきほどの「戻せるか」そのままです。難しくても戻せるなら任せるし、簡単でも戻せないなら止める。物差しを可逆性に一本化したら、任せてよい範囲がくっきりしました。
② エージェントは「ローカルが最新」と無邪気に信じる
受託でいちばん怖いのは本番の上書きです。本番サーバーは、管理画面から直接直されたり緊急対応が入ったりして、手元の複製と知らぬ間にズレていきます。ところがエージェントは、言わなければ自分の手元が最新だと素直に思い込み、そのまま本番へ持っていこうとします。
なので指示書に「本番とローカルは常にズレている前提で動く。触る前に本番から現物を取り、差分を見てから作業に入る」と前提を書き、本番へ上げるときは変更したファイルだけにする(テーマ一式まるごとの転送は禁止)と決めました。
ただ、指示書に書いただけでは「必ず」にはなりません。CLAUDE.md はあくまで「こう振る舞ってほしい」という方針であって、AIがそれに反しないという保証はないからです。これは公式ドキュメントも同じことを言っていて、CLAUDE.md は振る舞いを導くもので強制の層ではない、確実に止めたいならフックや許可設定の側で止めよ、とはっきり書かれています(Claude Code 公式ドキュメント「Claude があなたのプロジェクトを記憶する方法」)。だから本番反映や削除のような戻せない操作は、指示書の方針とは別に、許可制御——人間に確認を飛ばす ask、そもそも禁じる deny——の側でも止まるようにしています。方針と強制の二枚重ね、という言い方が近いです。
③ 同じ指摘は二度まで。三度目は仕組みに落とす
同じ注意を繰り返している自分に気づいたら、それは指示書か自動化の合図だと決めています。二度言ったら、まず指示書に足す。それでも三度目が来たら、心がけをやめて仕組みにします。
たとえば、スタイルシート(SCSS)を編集するたびに「これは整形してから保存して」と言い続けていた時期がありました。毎回言うのが馬鹿らしくなって、ファイルを編集した直後に整形が自動で走る小さな仕掛け(フック)に移しました。以来その指摘は一度もしていません。うちの経験では、人の注意力を当てにした運用はどこかで抜けます。抜けたら仕組みの出番、という順番でやっています。
④ 速くしたいほど、危ない操作には許可を広げない
作業を速くしようと許可の範囲を広げていくと、今度は危ない操作までノールックで通りかねません。ここは意識して非対称にしています。
調べ物系のコマンドのような、よく打つし失敗しても痛くない操作は、まとめて許可して確認を省きました。その一方で、削除・強制上書き・本番への反映といった戻せない操作は、どれだけ頻度が高くても承認の後ろに残しています。速さのために安全網まで緩める、はやらない。ここが最後の一線です。
効いてきたこと
いちばんはっきりしたのは、さっきの貼り付きから解放されたことです。可逆な作業を任せられるようになった分、人間は戻せない判断だけを見ていればよくなりました。体感では、画面に張り付いていた時間の八割方が消えた感覚です(自社の制作時点の実感で、計測した数字ではありません)。おかげで、エージェントを何本か並行して走らせながら、自分は別の仕事に手をつけられるようになりました。
やってみて意外だったこともあります。戻せない操作の手前で必ず止まる作りにしておくと、肝を冷やす場面そのものが減りました。②で書いた二枚重ね(方針+許可制御)のおかげで、本番反映や削除は人間の確認を通らないと進みません。今のところ「やられた」と青くなった場面はありません。派手さはありませんが、事故が起きてから慌てるのでなく起きる前で止まるのが、地味にいちばん効いています。
人間に残った仕事
ここまで任せて、では人間は何をする人になったのか。残ったのは、AIには代わりに背負えないところでした。
- 最終的な判断とGOサイン。とくに本番へのデプロイは、最後に人間が「出す」と言う。
- 方向性を決めることと、提案された戦略を吟味すること。エージェントは案をいくらでも出しますが、どれを採るかの責任までは持てません。
- 一次体験を差し込むこと。実際に見て、触って、迷った経験。これはAIには生み出せません。この記事でいえば、画面に貼り付いていた話も、まだ事故がないという話も、私が通ってきたからこそ書けます。
手を動かす時間が減ったぶん、決めることと、自分にしか出せないものを差し込むことに、時間が回るようになりました。うちにとっては、これがいちばんの変化だったかもしれません。
まだ迷っていること
正直な迷いも残しておきます。可逆性で線を引くと、「戻せはするが、戻すのが面倒」な作業——大きめのリファクタなど——の扱いがぼやけます。ここは今も、その都度カンで拾っているのが実態です。それに指示書は育つほど長くなり、ルールが増えすぎて逆に読み負担になるという別の問題も見えてきました。この記事も途中経過で、答えを配れているわけではありません。
持ち帰ってもらえるとしたら
もし一つだけ持ち帰るなら、AIに任せるかどうかは賢さより「戻せるか」で決める、という物差しです。そしてルールは、先回りして立派に書くより、困った順に足すほうが現場に馴染みました。少なくともうちでは、そうやって足した行だけが生き残っています。どこに線を引くかは現場ごとに変わるので、そこは実際に一度困ってから決めても間に合います。
なお、この記事で扱った「任せ方の線引き」は、受託の現場でClaude Codeを運用するときの一領域です。権限の設計・環境トラブルの切り分け・本番反映の作法まで含めた全体像は「Claude Code実務運用ガイド」にまとめています。
CLAUDE.md(作法・禁止事項・承認の基準を記述)。許可制御=設定ファイルの allow / ask / deny(公式ドキュメント「権限を設定する」)。運用文脈:受託制作/本番サーバーあり/複数案件を複数PCで作業。
方針:戻せる作業=自走して事後報告、戻せない操作(本番反映・削除・上書き・外部送信・課金)=方針と許可制御の二枚重ねで人間の承認を通す。本文の「八割方」は制作時点の体感で、計測値ではありません。
※本記事の記述と引用先ドキュメントの内容は2026年7月時点のものです。
