AIエージェントの承認ゲート｜送信・公開・削除で止める仕組み

AIエージェントに何を任せるかを決めても、送信・公開・削除の直前で止まらなければ境界線は機能しません。本記事は、承認ゲートに置くべき操作の線引きと、実際に止める仕組みへの落とし込み方を、運用中の実例4つと公式ドキュメント5件から整理します。

01結論：AIエージェントの承認ゲートは、取り消せない操作の直前に置く壁

Anthropicは、エージェントが処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。同じ文書は、暴走を防ぐ手段として最大反復回数などの停止条件を組み込むことも一般的だと述べています（出典: Anthropic公式）。

承認ゲートは、この「立ち止まる場所」を、対外的に確定してしまう操作の直前に固定する設計です。WEBMARKSは現在、この壁をhook2種・CLI1種・運用ルール1種の計4種類で実装しています（2026-07-28時点）。中身は本記事の後半で実例とともに示します。

結論は3点です。

1. 承認ゲートに置くべきかどうかは、送信・公開・削除・決済/契約の4カテゴリで判定します。
2. 実装する層はhook・CLI/ワークフロー・運用ルールの3つに分かれ、強制力と証跡の残り方が異なります。
3. 承認ゲートは書いただけでは機能せず、実際に発火するかを動作確認して初めて壁になります。

AIエージェントそのものの定義は『AIエージェントとは｜そう呼べる3条件と、呼べない境界』で扱っています。本記事は、任せると決めた後に「どこで止めるか」だけに絞ります。

02承認ゲートに置くべき操作の線引き｜4カテゴリで判定する

線引きの軸は2つです。取り消せるか（可逆性）と、社外・第三者に届くか（対外性）です。この2軸がどちらも低いときだけ、承認ゲートなしで進めてよい操作になります。

Anthropicは、高リスクな用途では隔離環境での十分なテストと、適切なガードレールの併用を推奨しています（出典: Anthropic公式）。ガードレールとテストは事前の備えであり、承認ゲートは実行の瞬間に効く最後の壁という位置づけです。

4カテゴリに共通するのは、実行後に人が気づいても操作そのものは戻らないという点です。決済・契約は技術的な取り消し手段が存在しないケースが多く、他の3カテゴリよりも慎重な線引きが要ります。

境界線上の操作もあります。社内向けの下書き保存や、開発環境でのファイル編集は4カテゴリのどれにも該当しません。判断に迷う操作は、いったんaskに倒し、様子を見てからallowへ動かすほうが安全です。

1件なら取り消せる操作でも、まとめて実行すると別カテゴリに変わることがあります。複数ファイルの一括変更・一括削除は、1件ごとの可逆性ではなく、後戻りにかかる時間で判定します。数十件を人が1件ずつ差し戻すコストは、1件の削除とは別物として扱います。

03承認ゲートを誰が動かせるか｜AIを承認者にしない設計

線引きだけでは、まだ壁になりません。誰がその承認を下せるのかを決めて初めて、ゲートは機能します。WEBMARKSの成果物ライフサイクルルールは、社内正式採用への昇格について「原則としてAI名は承認者になれない」と定めています。例外は、案件単位で明示的に委任された場合だけです。

委任にも境界があります。公開・外部送信・公開判定・公開後の状態は、この委任の対象外で、必ず人間承認を要すると定められています。委任できるのは社内での格上げなど、対外的に確定しない範囲に限られます。

委任には期限もあります。案件が完了扱いになった後は、新しい委任操作を始められません。範囲と期限をセットで決めておかないと、委任のつもりが恒久的な権限移譲になってしまいます。

承認した事実は、次の4項目で記録します。

4項目のうち、見落とされやすいのはcanonical_sha256です。承認は「そのときの中身」に対して下されるものであり、後から差し替わったファイルにまで有効ではありません。

04承認ゲートを実装する3つの層｜hookとCLIと運用ルールの違い

同じ承認ゲートでも、実装する層によって強制力が変わります。

hook層は最も強制力が強く、実行の直前でプロセスごと止められます。WEBMARKSのファイル保護フックは、CLAUDE.mdや00-rules配下への書き込みを検出すると、判定処理が例外で落ちた場合も含めてdenyを返す設計です。

def main():
    try:
        data = json.load(sys.stdin)
    except Exception:
        _deny("入力JSONを検証できません")
        return
    # 保護対象のパス判定（省略）
    ...

try:
    main()
except Exception:
    _deny("保護対象の判定に失敗しました")

「判定に失敗したらdeny」がfail-closedの中身です。逆にfail-openは、判定できないときに素通りさせる設計です。

OpenAI Agents SDKのガードレールは、入力または出力が条件に反するとトリップワイヤーが発火し、専用の例外を送出します。例外が送出されると、その場でエージェントの実行が止まります（出典: OpenAI公式ドキュメント）。Claude CodeのPreToolUseフックが呼び出し前に止めるのに対し、こちらは評価が終わった時点で例外により止める設計です。同じ「実行を止める」でも、止めるタイミングが違えば、後始末すべき対象の範囲も変わります。

層を分けるだけでなく、対象を区切ることでも承認しやすくなります。GitHub Copilot coding agentは、1タスクにつき1ブランチ・1プルリクエストに絞り、最長59分で作業を区切ります（出典: GitHub公式ドキュメント）。変更が小さく区切られているほど、人はレビューで判断しやすくなります。

ただし、マージするかどうかの最終判断はリポジトリ側のルールに委ねられており、エージェント自身がその判断を代行するわけではありません。区切りの粒度そのものが、承認ゲートの負荷を左右する設計変数です。

止める場所の詳しい実装は『Claude CodeのPreToolUseフック｜危険コマンド遮断のコード例』で扱っています。判定ルールの書き方は『Claude Codeの権限設定｜allow・ask・denyの配分と設定例』にまとめています。

05AIエージェントの承認ゲート運用一覧｜4つの実例で見る強制力の差

線引きと層の話を、実際に動いている4つの実例で確認します。

4つのうち、技術的に最も強いのは上の2つです。下の2つは、書かれた手順に人が従う前提の設計であり、それ自体は悪いことではありません。すべてを技術的な壁にすると、判断が必要な例外まで機械的にブロックしてしまうためです。

台帳の人間ゲート欄は、状態を「人間ゲート待ち」にしたうえで、承認してほしい内容を1〜2行で書く運用です。技術的な強制力はありませんが、送信・公開のように毎回パターンが異なる操作では、hookだけでは判定しきれない部分をここが埋めています。

06人間ゲートを技術的な壁に変える5つの手順

線引きと層の設計を、実際の手順に落とし込みます。

1. 対象操作を列挙する：入力はCLAUDE.mdや業務ルールの明文規定、出力は4カテゴリに分類した操作リストです。
2. 実装する層を選ぶ：入力は操作の発生経路（Bashコマンドか、CLI経由か、人が直接行うか）、出力はhook・CLI・運用ルールのどれに置くかの割り当てです。
3. 既定動作をfail-closedにするか決める：入力は判定できない場合にどちらへ倒すかの方針、出力は例外処理のコードまたは明文の既定値です。
4. 承認証跡の記録項目を決める：入力は台帳やMANIFESTのフォーマット、出力はapproved_by等の必須フィールドです。
5. 実際に発火させて確認する：入力は対象操作の実行、出力はブロックまたは確認ダイアログが出たという事実です。

5番目を省略すると、書いただけで安心してしまいます。設定を書いた事実と動いている事実は別に数えます。WEBMARKSは常駐ジョブの稼働をlaunchctlで毎回実測しており、2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちだと把握しています。設計と稼働は別物だという教訓は、承認ゲートにもそのまま当てはまります。

任せてよい業務かどうかの判定基準は『AIエージェントにできること｜任せる・任せないの判断基準』の4条件で先に決めます。本記事の手順は、その4条件のうち影響範囲が閉じている条件を満たさない業務に対して使う手順です。

07承認ゲートが機能しない3つの原因｜設計はしたが止まらないパターン

承認ゲートを書いても、次の3つの原因で機能しないことがあります。

原因1：判定ロジックが対象操作の全経路をカバーしていない。Claude Code公式ドキュメントは、Bash向けのワイルドカードだけで宛先を制限する設計は壊れやすいと明記しています（出典: Claude Code公式ドキュメント）。抜け穴の具体例は、権限ルールの配分を扱った前掲記事にまとめています。

原因2：ゲートを書いたのに、実際には読み込まれていない。設定ファイルのパス指定を誤ったり、構文が崩れていたりすると、hookはそもそも発火しません。WEBMARKSも、常駐ジョブの稼働をlaunchctlで毎回実測しており、2026-07-28時点で稼働中は1本、残り7本は定義済みで検証待ちだと把握しています。設定を書いた事実と、実際に稼働している事実は別に確認する必要があります。

原因3：判定の代理指標が弱く、無関係な処理まで巻き込む。WEBMARKSの旧・社内格上げゲートは、ファイルの更新時刻（mtime）から担当セッションを推定していました。別セッションが偶然同じファイルに触れただけで誤って発火し、3日間で233回の誤爆が起きました。原因の特定後、thread・case・ハッシュを明示して記録する方式へ作り直し、誤爆は解消しています。

3つの原因は逆方向です。原因1・2は止めるべきときに止まらない失敗、原因3は止めなくていいときに止まる失敗です。どちらも承認ゲートへの信頼を失わせるため、動作確認には両方向のテストを含めます。

08承認ゲートを整備するチェックリスト

• 送信・公開・削除・決済/契約に該当する操作を、業務単位で1つずつ列挙したか
• 可逆性と対外性の2軸で、承認ゲートが要る操作とそうでない操作を仕分けたか
• 実装する層（hook・CLI・運用ルール）を、操作の発生経路に合わせて選んだか
• 判定できない例外の既定動作を、fail-closedかfail-openかで明文化したか
• approved_by・approved_at・approval_evidenceなど、承認の証跡フィールドを決めたか
• AI自身が承認者にならない設計になっているか、委任する場合は範囲と期限を明記したか
• 実際に対象操作を実行し、ブロックまたは確認が発火することを確認したか
• 誤検知を防ぐため、判定ロジックが弱い代理指標に依存していないか確認したか

09FAQ