AIに任せてよい作業・任せない作業をどう決める？三つの基準

最初は、難しそうな作業ほど任せていました。自分がやると時間がかかるからです。逆に簡単な作業は自分でやっていました。

これは順番が逆でした。難しい作業ほど、出てきたものが正しいかを確かめるのに時間がかかります。簡単な作業は、間違っていてもすぐ分かります。判断にかかる時間まで含めると、得をしていませんでした。

いまは難易度を見ていません。代わりに3つを見ます。元に戻せるか。影響がどこまで届くか。正解が外にあるか。次の3節で順に書きます。

一番強い基準です。間違いが起きる前提で考えると、大事なのは間違えないことではなく、間違えたときに戻せることでした。

コードの編集は戻せます。履歴が残っているので、気に入らなければ捨てられます。だから任せます。一方、外部のサービスへ送信する操作は戻せません。メールは送ったら取り消せませんし、公開したものは消しても誰かが見たあとです。

私はこの線を、承認を分ける形にしています。コードの編集はまとめて任せ、コミットとプッシュはそれぞれ別に承認します。このサイトは特定のブランチへの反映がそのまま本番公開になるので、最後の一押しだけは必ず自分で行います。

分けておくと、途中で止められます。変更は全部できているけれど、やっぱり今日は出さない、という判断ができる。ひとまとめに任せていたころは、気づいたときには公開されていました。戻す作業のほうが、確認する手間よりずっと重かった。

戻せるかどうかは、作業の名前では決まりません。同じ「設定を変える」でも、手元のファイルなら戻せて、外部サービスの管理画面なら戻せないことがあります。どこに保存されるかで見ると間違えません。

この基準で一番気をつけているのが削除です。削除は戻せる操作に見えます。ゴミ箱があるから、履歴があるから、と思いがちですが、道具によってはその場で消えます。だから私は、削除だけは作業の大小に関係なく、何が消えるのかを一覧で出させてから自分で実行しています。

同じ「ファイルを1つ直す」でも、影響の届く先が違えば扱いを変えます。

その画面だけで完結するものは任せます。一方、複数の場所から読まれている設定を触るときは、先に何が読んでいるかを調べさせてから決めます。範囲が見えないまま直すと、直した場所は正しくて、別の場所が壊れます。

実際にありました。共有カードの設定を1ページに書き足したところ、親から引き継いでいた設定ごと置き換わって、他のページから画像が消えたことがあります。触ったファイルは1つでしたが、影響は広かった。触る量ではなく、届く範囲で見るようになったのはこの一件からです。

厄介なのは、影響範囲が広い変更ほど、作業としては小さく見えることです。設定を1行変えるだけ、共通のファイルを少し直すだけ。小さいので気軽に渡してしまい、返ってきたものも小さいので、そのまま通してしまう。

いまは、共通の場所を触る依頼には「どこから読まれているかを先に調べて、一覧で見せて」を付けています。調べる作業自体は任せられるので、手間はほとんど増えません。増えるのは、こちらが見る時間だけです。

調べさせる依頼は、具体的に書くほど使えるものが返ってきます。「影響を調べて」だと要約が返ってきますが、「このファイルを import している場所を、パスと行番号で全部並べて」だと一覧が返ってきます。要約ではなく一覧を求めると、こちらが判断できる形になります。

3つ目は、その作業の正解が外にあるか、自分の頭の中にしかないか、です。

外にあるものは任せられます。仕様書に書いてある、公式ドキュメントに載っている、既存のコードにその書き方がある。こういう作業は、裏を取らせることまで含めて渡せます。出どころを書かせておけば、あとから自分で確かめ直せます。

ここで注意がいるのは、外にあるように見えて、実は無い場合です。たとえば「このアプリの画面をどう説明するか」は、一見すると既存の文章から引けそうですが、どこまで踏み込むかは決まっていません。渡すと、それらしい文章がすぐ出てきます。速いぶん、判断していないことに気づきにくい。

頭の中にしかないものは、渡しても決まりません。どの機能を削るか、どの言い回しを選ぶか、何を作らないか。材料を集めてもらうことはできますが、選ぶのはこちらです。案を出させて選ぶ形にすると速くなりますが、それは選択肢を作る作業を任せているだけで、判断を任せているわけではありません。

書くものについては、この線をはっきり引いています。下書きは作らせますが、題材を決めることと、出すかどうかを決めることはしません。

外にあるかどうかの判定に迷ったら、「どこに書いてあるか言える？」と聞くのが早いです。出どころを示せるなら外にあります。示せずに答えだけ返ってくるなら、それは外から引いたものではありません。この一手で、確かめられるものと確かめられないものが分かれます。

3つは独立していません。実際の判断では重ねて見ます。

たとえば「リンク切れを全ページから洗い出す」は、戻せる・影響は調べるだけ・正解は外にある、で3つとも通ります。迷わず任せます。「価格の表示を変える」は、戻せますが、影響が法務の文面まで届き、いくらにするかは頭の中にしかありません。だから調べさせるところまでで止めます。

迷ったときは、一番厳しい基準に合わせます。3つのうち1つでも引っかかれば、そこで区切って人が入ります。

⚠️ 区切る場所は、作業の途中でも構いません。全部を任せるか全部を自分でやるかの二択にすると、判断が雑になります。調べるところまでは渡して、決めるところで受け取り、直すところをまた渡す。こうすると、任せられる量はむしろ増えました。

実際の区切り方を1つ書いておきます。記事を公開するときは、本文を書くところと、検査を通すところと、コミットするところと、プッシュするところの4つに分けています。前の3つは任せて、最後だけ自分で押す。4つのうち3つは任せられているので、一番戻しにくい1つを手元に置いても、全体の手間はほとんど変わりません。

毎回の判断に頼らない方法もあります。作業ごとに、使える道具を先に絞っておくやり方です。私は繰り返す手順をファイルにまとめていて、それぞれに使ってよいコマンドを書いています。下書きを作るための手順には、公開するための道具を渡していません。うっかり公開される経路が、そもそも無い状態にしておきます。

決まりを文章で守らせる話はAIにコードを書かせる前に決めるべき5つと、その置き場所に、ツール側の仕組みはClaude Codeとは？できること・始め方・任せない作業にまとめています。

AIに任せると品質が落ちませんか？

落ちるかどうかは、確かめる方法を持っているかで決まります。正解を機械で確かめられる作業（型チェックが通る、検査が通る）なら、人がやるより見落としが減ることもあります。確かめる方法が無い作業を渡すと、良くなったか悪くなったかも分かりません。

どこまで自動で任せていいですか？

元に戻せる範囲までが目安です。ファイルの編集は履歴が残るので戻せます。コミット、プッシュ、外部への送信、削除は戻しにくいので、自動で許さない設定にしておくと安全です。

出てきたものをどう確かめますか？

「できました」という報告ではなく、成果物そのものを見ます。公開したと言われたら実際のURLを開く、直したと言われたら検査を通す。これを挟むだけで取りこぼしはかなり減りました。公開前後に何を確認するかはアプリ公開前チェックリスト。全部通したのに問題が出た六つにまとめています。

一人開発でもレビューは必要ですか？

人が読むレビューの代わりに、機械が止める検査を置いています。一人だと、誰も見ていないので確認を省いても怒られません。省いた確認は公開後に返ってきます。私の場合、返ってきたのは利用者からではなく、検索エンジンの管理画面と、数週間後に読み返した自分からでした。

設計そのものをAIに任せられますか？

案を出させることはできますが、選ぶのはこちらです。どの機能を削るかは正解が外に無いので、渡しても決まりません。材料が増えると選びやすくはなりますが、それは選択肢を作る作業を任せているだけです。

任せる範囲を広げるタイミングは？

仕組みを足したあとです。戻せない作業でも、戻せる形に変えれば任せられます。間違いを機械が止めてくれるなら、影響範囲が広くても任せられます。順番を逆にして、任せてみて問題が起きたから仕組みを足す、では遅いです。

3つの基準は固定ではありません。線を引くのは今の能力に対してではなく、今の備えに対してです。備えが無いまま範囲だけ広げると、静かに壊れます。私は一度それをやって、画面には何も出ないまま設定が食い違った状態を作りました。

だから、仕組みを足したぶんだけ任せる、の順にしています。こうすると、事故が起きる前に範囲が決まります。

そして、どれだけ備えても最後に残るものがあります。何を作るか、何を出さないか。ここは範囲の話ではなく、私がやる理由そのものなので、広げる対象に入れていません。