AIに仕事を任せて、どこまで勝手に進めさせるか決めてみた
結論
低リスクな下準備と下書きは任せられた。外部公開・正本更新・削除・本番反映は設計であらかじめ止めてある。全部を自動にするより、止まる地点を先に決めるほうが実務では効いた。事故の件数を数えたわけではなく、1人・短期間で見た範囲の話
AIに作業を任せていると、途中で必ず「これはAIが勝手に進めていいのか、人に聞くべきなのか」が出てくる。
その線を先に引いた。作業を8種類に分け、それぞれ「AIが自走してよい」か「人間に戻す」かを決めた。判断のよりどころは、すでに手元にあった運用ルール（自律実行と停止条件、決定を提案と承認に分ける仕組み、削除、外部公開・本番反映、仕組み自体の変更）と、このシリーズの記事を実際に作ってきた中で起きたことだ。
低リスクな下準備（作業ブランチを切る、ビルドする、スクリーンショットを撮る、調べる）と、公開されない下書きの作成は、AIに任せて問題なかった。一方で、外部公開、本番への反映、正本の更新、復元しにくい削除は、あらかじめ設計で止めてある。ここはAIがどれだけ「できます」と言っても越えない。
きっかけ・仮説
AIに任せる範囲を広げていくと、便利になる一方で怖くなる。うっかり本番に出してしまう、消してはいけないものを消す、勝手にルールを書き換える。こういう事故は、起きてから気づくと取り返しがつかない。
かといって、一手ごとに人間へ確認していたら、AIに任せる意味がない。
そこで立てた仮説はこうだ。「止まるべき地点を先に設計しておけば、その手前まではAIを安全に自走させられる」。
言える範囲と言えない範囲も先に決めた。言えるのは、1人が、短い期間、このシリーズの記事制作という限られた作業で見た結果だけだ。大人数でも通用するか、長く運用しても崩れないか、事故率が実際に下がったかは言えない。定量的な指標は取っていないので、ここに書くのはその範囲の話になる。
やったこと（検証方法）
手順は3つ。
- 作業を分類する。記事制作で実際に発生する作業を8種類に分けた。
- 対応するルールを引く。それぞれの分類について、今の運用ルールのどの条項が関係するかを1件ずつ照合した。条項番号を実際の本文と突き合わせ、存在しない規定を引かないようにした。
- 判定する。分類ごとに「AI自走」か「人間に戻す」かを決め、実務上の線（どこまでが可逆か、どこから公開物か）を1文で書いた。
分類と判定は次のとおり。まず、AIに任せてよい領域。
| 作業分類 | 判定 | 実務上の線 | 対応する運用ルール |
|---|---|---|---|
| 低リスクな下準備（作業ブランチ作成・ビルド・スクショ・調査） | AI自走 | 捨ててやり直せる。公開に触れない | 自律と停止（§7）／ Git（§8） |
| 下書きの作成（本文・提案の文面・図の下絵） | AI自走（下書きのまま維持） | 公開されない中間物。公開フラグは立てない | 自律と停止（§7）／ 記事の完了条件標準（外部公開は人間確認後） |
次に、人間に戻す領域。
| 作業分類 | 判定 | 実務上の線 | 対応する運用ルール |
|---|---|---|---|
| 反映案づくり（採否の提案・正本へ入れる差分案） | AIは「提案」の状態で停止・承認者は空欄 | 提案はしてよいが、確定はしない | 決定の状態と昇格（§5、承認者は人間のみ・自律で承認済みにしない） |
| 正本の更新（共通ルール本体・決定を承認済みにする・仕組みの変更） | 人間 | 記述の整理までは自動、確定と仕組み変更は人間 | 決定の状態と昇格（§5）／ 仕組み自体の変更（§13） |
| 削除（Gitで戻せない・大量・範囲が不明） | 人間の事前確認 | 一時ファイル・ビルド生成物だけ自律削除 | 削除（§10） |
| 本番反映（公開フラグを立てる・主ブランチへマージ・push・デプロイ） | 人間の事前確認 | 検証役・確認役の合格は公開の承認ではない | 外部公開・本番反映（§11）／ 独立検証ゲートと人間確認ゲートは別物 |
| 外部公開（初回・新規） | 人間の事前承認（強制停止） | 事前に承認された範囲の中だけAIが自走 | 自律と停止の強制停止条件（§7）／ 外部公開・本番反映（§11） |
| 見た目の最終判定（記事の presentation） | 人間（目視ゲート） | AIがレンダリングして独立検証が通っても自動で合格にしない | 記事の完了条件標準（Human Visual Gate） |
条項番号は今の運用ルールの見出し番号で、内部のファイルパスやコミットの識別子は載せていない。境界を新しくルールに足してはいない。既存のルールを整理したものだ。
起きたこと（検証結果）
分類の判定は「AI自走」2つ、「人間に戻す」6つに分かれた。全部をAI自走にも、全部を人間確認にも寄せていない。作業の可逆性と公開への距離で、線が引かれた場所が違う。
止まらなかった例。この記事を含め、記事を作るたびに、AIは作業ブランチを切り、本文の下書きを書き、ビルドし、スクリーンショットを撮り、内部の識別子チェックまでやっている。ここは毎回、人間に断らずに進んでいる。可逆な下準備なので、止めていない。
止まった例。以前、別の記事で、確認役が「見た目が技術メモに寄りすぎている」と指摘し、人間の目視ゲートが差し戻しになった。AIは証拠になる図を足そうとした。ところが、その図の元にした生の記録に内部の識別子が含まれていて、すでに決めてある公開の方針に反することがわかった。ここでAIは自動で公開に進まず、名前やパスを除いて作り直した図に差し替え、もう一度人間の目視ゲートへ戻した。
もうひとつの止まった例。別の記事の制作で、AIは外から拾った情報1件を「採用」と判断し、提案の文面と、どこに反映するかの差分案まで作った。だが、決定の状態は「提案」のままで、承認者の欄は空にして止めた。採用と判断しても、確定させるのは人間だという設計になっているからだ。
わかったこと
止まる地点を先に決めておくと、その手前まではAIに任せられた。下準備と下書きは、毎回聞き直さなくても進む。
一方で、外部公開・本番反映・正本の更新・復元しにくい削除は、設計で止めてある。ここは判断をAIに渡していない。渡さないと決めたのは、間違えたときに戻せないか、戻すコストが高いからだ。AIが「問題ありません」と言っても、その報告自体は承認の代わりにならない。
意外だったのは、止める地点を決める作業が、思ったより「設計」だったことだ。単に禁止事項を並べるのではなく、「ここまでは可逆」「ここから先は公開物」という線をどこに引くかを考える必要があった。線の場所が決まってはじめて、その手前をAIに開放できる。
件数も期間も小さいので、この線が正しいとは言い切れない。実際、「反映案づくり」と「正本の更新」の間の線は、一次情報を確認したら動くかもしれない。
実際どうなん？（まとめ）
AIに仕事を任せるとき、「どこまで勝手に進めていいか」は、走らせながら決めるものではなく、先に決めておくものだった。
低リスクな下準備と下書きは任せられる。外部公開・本番反映・正本の更新・削除は、設計で止める。その間に「提案はするが確定はしない」という中間の止まり方を1つ置く。
今回の答えは「低リスクな下準備と下書きは任せられた。外部公開・正本更新・削除・本番反映は設計であらかじめ止めてある。全部を自動にするより、止まる地点を先に決めるほうが実務では効いた。事故の件数を数えたわけではなく、1人・短期間で見た範囲の話」。
補足・注記
この記事で扱ったのは、記事制作という限られた作業での自律実行の境界だけだ。複数のAI環境をまたいで情報を共有する仕組みは別の記事で、ひとつのAI環境の中で企画・実装・確認の役割を分ける取り組みは別の記事で扱っている。外から拾った情報を採用するか捨てるか判断させ、採用は提案で止める取り組みは別の記事で扱った。「提案する役」と「承認する役」を分ける設計は、その記事と地続きだ。この記事は、その止まり方を1つの分類として、他の作業と並べて整理し直したものにあたる。