この記事でわかること
- AIに任せる範囲は、業務の領域ではなく「判断が要るか」で線を引く
- 新機能を作る許可は、作る時点で人が出す。印を付けたままにしない
- 判断が要ると分かった時点で、AIが手を止めて人に返す作りにする
夜のうちにAIが課題を読み、直せるものは直して朝までに人へ渡す。AIを使う開発会社から、こうした「夜間の自動開発」の話を聞くことが増えました。発注する側が確かめておきたいのは、速さよりも、何をAIに任せ、何を人が決めているかです。ここが曖昧なままだと、頼んでいない機能がいつの間にか出来上がり、他の変更と一緒に本番へ出ていく、ということが起こりえます。
弊社が開発・運営している「SkillPort」（エンジニアの経歴書を一か所で管理するサービス）でも、夜間にAIが開発を進める仕組みを動かしています。2026年11月、この仕組みが自動で手を付ける範囲を「答えが明確なバグ修正」だけに絞りました。そこに至るまでに、線を2回引き直しています。その判断から、AIに任せる範囲の決め方をお伝えします。
AIに任せる線は、領域ではなく「判断が要るか」で引く
2026年10月2日、SkillPortに夜間の仕組みを2つ入れました。使っているのは、Anthropic の開発用AI「Claude Code」を、決まった時刻にクラウド上で動かす機能（ルーティン）です。
- 深夜2時：未対応の課題を読み、効果と変更の大きさを評価して、設計案まで書く（コードは書かない）
- 深夜2時半：実装してよいと決まった課題を実装し、下書きの変更案として出す
出てきた変更案は、人が読み、指摘を直してから取り込むかを決めます。夜のうちに本番が変わることはありません。
最初は、決済・データベース・認証に関わる課題を、自動の実装の対象から外していました。翌10月3日、私の「変更案を出すところまでなのに、なぜ決済とデータベースを触らせないのか」という問いを受けて見直しました。調べると、この除外は仕組みを作ったときに安全側に倒して置いた初期設定で、事故や経営判断に基づくものではありませんでした。夜間の精査の側も、こうした領域に関わるというだけで「人の判断が要る」に振り分けていました。
出典：SkillPort 開発記録（2026年10月3日）
人が読む前提の下書きに、そこまでの制限をかけるのは過剰だと判断し、線の引き方を変えました。
- 「人の判断が要る」は、領域ではなく設計の判断が要るかで決める（仕様の選択肢が1つに定まらない、本番の設定・法務・料金などの変更が要る）
- データベースの変更は、検証用のデータベースに当てて確かめるところまで。それも「足すだけ」の変更に限り、消す・名前を変えるといった変更は、戻し方を添えた下書きまで
- 本番のデータベースへの適用は禁止。法務の文面や、自動チェックそのものの設定にも触らせない
新しい基準で30件を精査し直すと、26件が引き続き「人の判断が要る」になりました。中身は、法務、外部の手続き、目で見て確かめること、本番の設定、仕様の選択で、領域だけを理由にしたものはありませんでした。判断が要る課題は、実際にそれだけ多いということです。
新機能を作る許可は、作る時点で人が出す
自動の実装には、入口が2つありました。1つはバグの自動修正、もう1つは、私が課題に「新機能も作ってよい」という許可の印を付けたものです。
11月3日、私から次の見直しを求めました。夜間の自動実装の対象を、答えが明確で私の判断が要らないバグ修正に限りたい。印を付けたのを忘れているうちに新機能が実装され、他の変更と一緒に本番へ出てしまうことがある、というものです。
記録を確かめると、10月に作られた新機能の変更案13本は、すべて許可の印の入口から入っていました。印はいずれも私のアカウントで付けたものです。許可を出した時点と、実際に作られる時点が離れていると、作られる時点では誰もその判断を見直していない状態になりえます。
そこで、許可の印の入口を廃止しました。仕組みの名前も「夜間のバグ自動修正」に改め、入口は「バグの印が付き、精査が済み、精査の判定が着手可」の課題だけにしています。新機能・要人間判断・情報不足などの印が付いたものは除きます。出す変更はバグ修正だけで、変更案の冒頭には「夜間のバグ自動修正で作成した」と書かせています。
許可の印が付いたまま残っていた課題も、新しい入口では拾われません。新機能として進めるかは、改めて人が決めます。
判断が要ると分かったら、手を止めて人に返す
範囲を絞っても、着手してから判断が要ると分かる課題はあります。そこで、作業中に次のどれかに当たったら中止し、印を付けて人に返す決まりにしました。
- 新しい画面・項目・表が要る
- 仕様書やヘルプに書いてある動きを変える
- 直し方が一つに定まらない
- 文言・見た目など、私が決めるもの
- 1深夜2時、課題を精査する
- 2答えが明確なバグだけ着手する
- 3判断が要ると分かれば中止し、人に返す
- 4直せたものは下書きとして出し、人が読んで決める
止めて返す作りが働いた例もあります。10月、ある取り込み機能の課題では、事前に決めていた3点とは別に「取り込み先」「氏名からの自動の当て込み」「画面の置き場所」の3点が決まっていませんでした。夜間の実装は着手した後にここで中止し、私がその3点を決めてから進めています。
範囲を絞った分、対象の無い夜も出ます。対象かどうかを判定するためだけに無駄に動かさないように、という指摘も私からしました。対象かどうかは課題に付いた印だけで判定し、印で外れる課題はやり取りの記録まで読ませません。重い準備は、対象が1件以上あると決まってから行います。対象が無い夜は、約28秒で終わっていました。
AIを使う開発会社に頼むときに役立つ3つのこと
「AIに任せる範囲」を、判断の有無で聞いてください
「決済には触らせません」のように領域で答える会社もあると思います。それも一つの安全策ですが、確かめたいのは、仕様の選択や見た目など、判断が要る場面を誰が引き受けているかです。領域で区切るだけだと、判断が要らない作業まで人に回って遅くなる一方で、判断が要る作業がAIに残ることもあります。
「AIが止まる条件」を聞いてください
AIに任せる作業でも、途中で判断が要る場面は必ず出ます。そのときにAIが自分で決めて進むのか、手を止めて人に返すのか。止める条件が具体的に決まっているかを聞くと、その会社がAIの使い方をどこまで設計しているかが分かります。
新機能の「作ってよい」は、その都度、人が出します
新しい機能は、作ってよいと決めた時点と、実際に作る時点で状況が変わることがあります。私たちは、新しい機能を作る許可を出しっぱなしにせず、作る時点で人が中身を確かめてから進めます。ご相談いただく機能についても、何を作るかは一緒に決めます。