AIエージェントの無人運用で最初に決めるべきは「人間がどこで承認ボタンを押すか」ではありません。「既定で何を通し、何を機械のゲートで止め、何だけを人間に残すか」です。私はSNS運用と記事公開をエージェントに任せていますが、通常フローに人間の承認ゲートはひとつもありません。それでも運用が壊れないのは、承認の代わりに境界を設計したからです。この記事では、その判断と実際の構成を解説します。
承認ボタンを挟むほど、無人運用は形骸化していく
エージェントに作業を任せるとき、素直に考えると「公開前に人間が確認する」を挟みたくなります。ただ、日次で複数の定時実行が回る運用でこれをやると、確認待ちの行列が毎日できます。そして毎日届く「承認してください」を人間が真面目に読み続けられるかというと、読めません。数日で「とりあえず承認」になるのが目に見えていました。
承認ボタンの問題は、止める力が人間の注意力に依存することです。注意力は消耗品なので、頻度が上がるほどゲートとしての強度が下がります。つまり「人間の承認を挟んでいるから安全」は、承認の頻度が低いときしか成立しません。無人運用を設計するなら、この前提から考え直す必要があります。
業界の既定値が、同じ方向に動いている
この設計問題への答えは、エージェントを提供する側の直近のアップデートに表れています。2026年9月前後に、承認まわりの「既定値」の変更が2つ続きました。
ひとつはClaude Codeです。2.1.257のchangelogで、自動承認モードにContainment Escapeルールが入りました。クラウドのメタデータ資格情報の取得、ネットワーク境界の回避、クロステナント到達といった操作は、既定で自動承認されなくなりました。あわせて、作業ディレクトリ外の初回読み取りには一度だけの確認が入り、設定で常時ブロックもできるようになっています。「自動で通す」モードの内側に、通さない領域が既定で切られた形です。
もうひとつはGitHub Copilotです。コードレビューがプルリクエストを承認できるようになりましたが、その設計が示唆的でした。
GitHub Changelog: Copilot code review can now approve pull requestsCopilot now tells you when a pull request is ready to approve, and admins can authorize it to sign off on approval. The ability for Copilot to approve is off…github.blog
承認機能は既定でOFF。有効化は企業・組織・リポジトリの3層で制御でき、ファイルパス単位で承認できる範囲を絞れます。そして一度出た承認も、新しいpushで失効します。「AIに承認させるか」を人間がその都度判断するのではなく、通してよい範囲と失効条件を先に宣言する作りです。
2つに共通するのは、安全を人間の注意力に頼らず、既定値と境界で設計する方向です。エージェントの能力が上がるほど承認リクエストの数は増えるので、都度承認モデルは構造的にスケールしません。提供側がそれを分かって既定値側に手を入れている、と私は読んでいます。
「誰が押すか」ではなく「何が既定で通るか」
ここで冒頭の結論に戻ります。ヒューマンインザループというと「重要な操作の前に人間を挟む」形が思い浮かびますが、無人運用で実際に効くのは、ループの位置ではなく境界の設計です。設計の問いはこう置き換わります。
- 既定で通る操作はどれか。その一覧を自分は言えるか
- 機械的に止めるゲートはどこで、判定基準は何のファイルにあるか
- 失敗が続いたとき、誰も見ていなくても運用は続くか
- 最後まで人間に残す操作はどれか
この問いに答えられれば、承認ボタンがなくても統制は作れます。逆にここが曖昧なまま承認ボタンだけ置くと、形骸化した瞬間に統制がゼロになります。
人間の承認ゲートをゼロにするために置いた4つの境界
私の運用の実装を具体的に書きます。SNS投稿とブログ記事の作成・公開を、日次の定時実行エージェントに任せている構成です。運用の指示書には「通常の定時実行に人間の承認ゲートはない」と明記していて、その代わりに4つの境界を置いています。
1つ目は、機械の審査ゲートです。 公開される原稿は、執筆したエージェントとは別の読み取り専用エージェントが審査し、PASSしたものだけが公開工程へ進めます。判定基準は審査用のルーブリックファイルに固定してあり、審査側はファイルを変更できません。人間の承認をなくす代わりに、公開の手前に「人間より確実に毎回読む」ゲートを置いた形です。この層分けの設計は別記事に書いています。
AIエージェントの公開前チェックは2層に分ける｜決定的ルールとLLM審査の設計AIエージェントに公開作業を任せるときのチェック機構を「決定的に落とす層」と「LLMに判断させる層」の2層に分けて運用している実装記録。GitHubがalt textチェックで公開した同じ層分けの設計と突き合わせ、誤検知で審査が信用を失わないための逃げ道の作り方、PASSを床として扱う考え方をまとめます。www.tentspace.net
2つ目は、回数の上限をサーバー側に置くことです。 公開系の操作は自作のMCPサーバーを経由させ、全チャネル合算で60分に3件、プラットフォーム別の日次上限（Threadsは3、記事は2など）をサーバー側のストレージで数えています。エージェントのプロンプトにいくら「投稿しすぎるな」と書いても、指示は破られる前提で設計します。上限がサーバーにあれば、エージェントがどう暴走しても超えられません。
自作MCPサーバーに「投稿し過ぎない」制限を実装した記録｜制限はプロンプトではなくサーバーに置くAIエージェントに投稿ツールを渡すと放っておくと公開し過ぎます。その制限をプロンプトではなく自作MCPサーバー側（Cloudflare WorkersのKV）に置いた実装記録。単純なカウントではなくreserve→commit/releaseの二段階にした理由と、失敗時に枠を戻す設計まで解説します。www.tentspace.net
3つ目は、自己承認・自己マージの既定禁止と、例外の文書化です。 エージェントは自分のプルリクエストを承認できません。例外は記事公開の固定フローだけで、差分が記事ディレクトリに閉じ、審査PASS済みのものに限って自動マージを許しています。一方で、審査ルーブリックや権限設定といった統制側のファイルは、変更の提案までは許可し、マージは必ず人間が行います。Copilotの「ファイルパス単位で承認範囲を絞る」と同じ発想で、通してよい範囲を先に宣言しておく形です。
4つ目は、失効・隔離の条件を先に書くことです。 審査にFAILした原稿の自動修正は2回まで。それでも通らなければ対象を隔離ステータスへ移し、通知だけ送って、人間の対応を待たずに次の作業へ進みます。ここを「人間が直すまで待つ」にすると、無人運用は人間の応答速度で止まります。隔離という出口を作っておけば、失敗があっても運用自体は流れ続けます。
承認を「状態」に紐づける
Copilotの仕様でもう一つ持ち帰るべきなのは、pushで承認が失効する点です。承認は「この内容なら通してよい」という判断なので、内容が変われば無効になるのが正しい。当たり前に聞こえますが、人間の運用ではよく壊れます。一度レビューが通った後の「ちょっとした修正」が素通りするのは、承認が状態ではなく人に紐づいているからです。
エージェント運用でも同じで、私の構成では審査PASSは対象の原稿1つに紐づきます。修正が入れば再審査です。審査済みフラグを使い回さない。地味ですが、無人運用の統制はこういう紐づけの積み重ねでできています。
無人運用を設計するときのチェックリスト
最後に、これから無人運用を設計する人向けに、先に書き出しておくべきものをまとめます。
- 既定で通る操作の一覧——列挙できないなら、まだ無人にする段階ではありません
- 機械ゲートの判定基準ファイル——基準はプロンプトの中ではなく、独立したファイルに置いて審査側から分離する
- サーバー側の上限——回数・頻度の制限は、エージェントの指示ではなく通り道に置く
- 失効条件と隔離先——承認や審査結果を何に紐づけ、何が起きたら無効にするか。失敗の隔離先と、その後も運用が続く経路
- 人間に残すマージ点——統制そのもの（審査基準・権限・上限の実装）の変更だけは人間に残す
人間の承認ゲートをゼロにする、というと乱暴に聞こえます。ただ実際にやってみると、必要だったのは承認の廃止ではなく、承認が担っていた仕事の再配置でした。毎回の判断は機械のゲートへ、範囲の宣言は既定値へ、最終防衛線は統制ファイルの人間マージへ。ヒューマンインザループは、ボタンではなく境界で作る。それが無人運用を毎日回している構成から言える結論です。