「送っていいかどうか、最後は誰が決めるんですか」。AIエージェントに仕事を渡す話をしていると、この質問が出ます。
任せる範囲を決めるところまでは、議論が進みます。ところが、手が実際に動く瞬間をどこで止めるかは後回しになりがちです。メールが送られてから、記事が公開されてから気づいても、その操作は戻りません。
この記事は、承認ゲートに置く操作の線引きと、それを本当に止まる仕組みへ落とし込む方法を扱います。素材は運用中の実例4つと、公式ドキュメント5件です。
こんなふうに調べていませんか
- AIエージェントに業務を渡したいが、事故が起きる地点が見えず踏み切れない
- 承認の設定は書いた。ただ、本当に止まるのかを確かめる方法を知らない
- どこまでAIの判断で進めさせ、どこから人が確定させるかを決めきれない
この記事を読み終えたときに手に入るもの
- 承認ゲートに置く操作と置かない操作を、2つの軸で仕分けられるようになります
- hook・CLI・運用ルールのどこに置くかを、操作の発生経路から選べるようになります
- 書いたゲートが本当に止まるかを、発火させて確かめる手順が手に入ります
結論30秒でわかる、この記事の結論
- 承認ゲートは、取り消せない操作の直前に置く壁です。置くかどうかは操作の中身ではなく、戻せるかと外に届くかで決まります。
- 実装する層はhook・CLI/ワークフロー・運用ルールの3つで、強制力と残る証跡が層ごとに違います。
- 書いた時点では、まだ壁になっていません。発火させて止まったことを見て、はじめて壁になります。
進行役は3人です。高梨課長が自分の手で動かす側から聞き、大森部長が体制と責任の側から聞き、鈴木さん（本誌監修）が答えます。
01AIエージェントの承認ゲートって、そもそも何を止める仕組みなんですか？
高梨課長承認ゲートという言葉は聞くのですが、実際には何がどうなるんでしょうか。
鈴木さん踏切に近いと思っています。線路の手前で遮断機が下りて、渡ってよいかを人が見る。渡り終わってから下ろしても、間に合いませんよね。
承認ゲートとは、送信・公開・削除など取り消せない操作の直前でAIエージェントの実行を止め、人の判断を挟む仕組みです。
Anthropicは、エージェントが処理の途中で立ち止まり、チェックポイントで人からのフィードバックを待つ設計を挙げています（出典: Anthropic公式）。同じ文書は、暴走を防ぐ手段として最大反復回数などの停止条件を組み込むことも一般的だと述べています（出典: Anthropic公式）。
承認ゲートは、この「立ち止まる場所」を、対外的に確定してしまう操作の直前へ固定する設計です。運営元WEBMARKSは現在、この壁をhook2種・CLI1種・運用ルール1種の計4種類で実装しています（2026-07-28時点）。
結論は3点です。
- 承認ゲートに置くかどうかは、送信・公開・削除・決済/契約の4カテゴリで判定します。
- 実装する層はhook・CLI/ワークフロー・運用ルールの3つに分かれ、強制力と証跡の残り方が異なります。
- 承認ゲートは書いただけでは機能せず、実際に発火するかを確かめて初めて壁になります。
02AIエージェントに任せる操作のうち、どれを承認ゲートで止めるんですか？
線引きの軸は2つです。取り消せるか（可逆性）と、社外・第三者に届くか（対外性）です。この2つがどちらも低いときだけ、承認ゲートなしで進めてよい操作になります。
| カテゴリ | 具体例 | 可逆性 | 対外性 |
|---|---|---|---|
| 送信 | メール送信、チャット投稿、SNS投稿、PR作成 | 相手に届いた時点で撤回できない | 高い（社外・第三者に到達する） |
| 公開 | LP公開、記事のstatus昇格、本番デプロイ | 検索エンジンやSNSに複製が残る | 高い |
| 削除 | rm -rf、git reset --hard、force push、大量ファイルの一括変更 | ローカルの復元手段が絶たれる | 低〜中（主に社内影響） |
| 決済・契約 | 支払いの実行、契約締結、OAuth権限の付与 | 金銭や法的な拘束が発生する | 高い |
Anthropicは、高リスクな用途では隔離環境での十分なテストと、適切なガードレールの併用を推奨しています（出典: Anthropic公式）。テストとガードレールは事前の備えで、承認ゲートは実行の瞬間に効く最後の壁という位置づけです。
4カテゴリに共通するのは、実行後に人が気づいても操作そのものは戻らない点です。決済・契約は技術的な取り消し手段が存在しない場合が多く、他の3カテゴリよりも慎重な線引きが要ります。
2軸に置き直すと、表では見えないものが1つ見えます。どこも埋まらない区画です。戻せて、しかも社内で完結する操作。ここに入るものだけが、確認を挟まずに進めてよい範囲になります。
表は「どのカテゴリが危ないか」を教えますが、「どこまでなら自由にしてよいか」は教えてくれません。任せる範囲を広げたいときに読むのは、埋まっている区画ではなく、空いている区画のほうです。
この章のまとめ
承認ゲートを置く判断は、操作の名前ではなく、戻せるかと外へ届くかの2軸で決めます。
03削除や一括変更は、AIエージェントに任せても後から戻せるんじゃないですか？
境界線上の操作があります。社内向けの下書き保存や、開発環境でのファイル編集は4カテゴリのどれにも当てはまりません。判断に迷う操作は、いったんaskに倒し、様子を見てからallowへ動かすほうが安全です。
問題は、1件なら取り消せる操作です。まとめて実行すると、同じ操作が別カテゴリへ移ります。
複数ファイルの一括変更や一括削除は、1件ごとの可逆性ではなく、後戻りにかかる手間で判定します。1件のファイル削除なら、履歴やゴミ箱からすぐに戻せます。同じ削除処理を、対象をまとめて自動で走らせた場合はどうでしょうか。戻すときも、対象を1件ずつ確認しながら差し戻すことになります。同じ「削除」という操作でも、対象が1件か大量かで、戻すために必要な手間の性質が変わります。
言い換えると、可逆性は操作そのものの属性ではなく、実行される量とセットの性質です。同じコマンドでも、対象が1つのときと、まとめて走らせたときで、置くべきゲートは変わります。
04承認ゲートを通す判断は、AIエージェント自身にやらせてもいいんですか？
大森部長承認までAIが下せるなら、そのぶん速くなります。任せてはいけない理由はありますか。
鈴木さん速くはなります。ただ、あとで「誰が決めたのか」を説明できなくなります。承認は作業ではなく、責任の所在を確定させる行為なので、そこだけは分けています。
大森部長例外はまったく無いのですか。
鈴木さん社内の格上げのように、対外的に確定しない範囲だけは、案件単位で明示的に委任することがあります。それも範囲と期限をセットで書いたときだけです。
線引きだけでは、まだ壁になりません。誰がその承認を下せるのかを決めて、はじめてゲートは機能します。
WEBMARKSの成果物ライフサイクルルールは、社内正式採用への昇格について「原則としてAI名は承認者になれない」と定めています。例外は、案件単位で明示的に委任された場合だけです。
委任にも境界があります。公開・外部送信・公開判定・公開後の状態は、この委任の対象外で、必ず人間承認を要すると定められています。委任には期限もあり、案件が完了扱いになった後は、新しい委任操作を始められません。
図の左右で違うのは対象範囲だけではありません。期限の有無も違います。委任側には終わりの日がありますが、人しか下せない側にはそもそも委任という概念がないため、期限を書く欄すら存在しません。
この章のまとめ
承認者を決めることは、速度を落とす手続きではなく、責任の所在を1人に固定する設計です。
05承認したという記録は、AIエージェントの承認ゲートに何を残しておけばいいんですか？
承認した事実は、次の4項目で記録します。
| フィールド | 記録する内容 | 省略した場合に起きること |
|---|---|---|
| approved_by | 承認した人物名（原則、AI名は不可） | 誰が許可したかを後から追跡できない |
| approved_at | 承認日時（タイムゾーン付き） | いつの判断か特定できない |
| approval_evidence | 承認したという発言・証跡そのもの | 「言った・言わない」の水掛け論になる |
| canonical_sha256 | 承認対象ファイルのハッシュ値 | 承認後に中身が差し替わっても気づけない |
4項目のうち、見落とされやすいのはcanonical_sha256です。承認は「そのときの中身」に対して下されるものであり、後から差し替わったファイルにまで有効ではありません。
この流れが示しているのは、4項目のうち3項目が承認の瞬間だけを記録しているという点です。誰が、いつ、何と言ったか。どれも過去の1点を写した記録で、その後に起きたことは写りません。
ハッシュ値だけが違います。中身そのものの写しなので、あとから照らし合わせられます。3項目が「承認があった証拠」なら、1項目は「承認したものが今も同じである証拠」です。
06承認ゲートは、生成AIを動かすどの層に置くと強制力が出るんですか？
高梨課長3つの層があると聞きました。どれから作ればいいのでしょうか。
鈴木さん削除系のhookからにしています。判定が単純で、止めすぎたときの副作用も小さいので。送信や公開のような判断が要るものは、あとから運用ルールと併せて足していく順番です。
同じ承認ゲートでも、実装する層によって強制力が変わります。
| 層 | 実装場所 | 既定動作 | 証跡の残り方 |
|---|---|---|---|
| hook層 | PreToolUse（Bash・Edit・Writeなど） | 判定できない例外はdeny（fail-closed） | フックの標準出力・拒否理由 |
| CLI/ワークフロー層 | 昇格用CLIのdry-run→--apply | --confirm-case-idが一致しないと書き込まない | approved_by・approval_evidence・ハッシュ |
| 運用ルール層 | CLAUDE.mdの明文規定、台帳の状態欄 | 技術的な強制なし。書いたことを人が守る前提 | 台帳の状態更新履歴のみ |
階層で描くと、表の並びとは別の関係が見えます。覆う広さと止める強さは逆を向くということです。
運用ルール層は、まだ仕組みになっていない操作まで含めて業務のすべてを覆います。ただし止める力は弱く、人が読んで従うことに依存します。hook層はいちばん上にあり、覆えるのはツール呼び出しという限られた経路だけです。そのかわり、その経路については実行の直前でプロセスごと止められます。
だから3層は選択肢ではなく、重ねるものです。どれか1つに寄せると、覆えない経路か、止められない操作のどちらかが残ります。
実際に、削除系の操作はhook層のbash-guard.pyだけでほぼ足りています。判定が単純で、対象も明確だからです。ところが送信や公開のように、そのつど中身が変わる操作は、hookだけでは判定しきれません。台帳の人間ゲート欄という運用ルール層が、そこを補っています。同じ承認ゲートでも、操作の性質によって、重ねる層の組み合わせは変わります。
この章のまとめ
3層は択一ではありません。下の層ほど広く覆い、上の層ほど強く止まる。重ねて初めて穴がふさがります。
07判定できないとき、AIエージェントは止まるほうへ倒すんですか？
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は、判定できないときに素通りさせる設計を指します。
エレベーターの扉にたとえると分かりやすくなります。安全センサーが壊れて「人や物が挟まっているかどうか判定できない」状態になったとき、扉を閉めたままにする設計と、とりあえず開けてしまう設計があります。fail-closedは前者です。「判定できない」という状態そのものを、「危ないかもしれない」という合図として扱います。判定できないことは、安全が確認できたことにはならないからです。
どちらを既定にするかは、好みの問題ではありません。判定できない状況とは、想定していなかった入力が来たということです。想定外のときに通す設計を選ぶなら、その理由を書き残しておく必要があります。
判定ルールの書き方そのものは、Claude Codeの権限設定｜AIエージェントに任せる範囲と3列の配分にまとめています。
08askとdenyは、AIエージェントの承認ゲートでどう使い分けるんですか？
高梨課長askとdenyという言葉が、あちこちに出てきます。この2つは何が違うんでしょうか。
鈴木さんaskは、その場に人がいることを前提にした一時停止です。denyは、人がいてもいなくても止まります。使い分けは、止めたあとに人の判断を待てる操作かどうかで決めています。
askは、確認のダイアログを出して、人が選ぶまで待つ判定です。denyは、選択肢を出さずにその場で拒否する判定です。どちらも実行を止める点は同じですが、止まったあとの扱いが違います。
前章の実例では、bash-guard.pyがrm -rfのような操作をdenyで即座に遮断していました。取り消せない削除は、迷う余地を残さないほうが安全だからです。一方、ファイル保護フックは通常askで、対象がCLAUDE.mdや00-rules配下のような固定面のときだけdenyに切り替わります。編集してよい場面と、必ず人を介すべき場面が、同じ「編集」という操作の中に混ざっているためです。
判断の目安はこうなります。対象が、間違えても取り返しがつく操作ならaskに倒してください。判断に迷う操作を、いったん人に確認させる形です。逆に、決済や契約のように取り消す手段が無い操作は、迷った時点でdenyを検討してください。askは人が確認して初めて機能する仕組みなので、確認が遅れる操作や、確認を忘れられやすい操作には向きません。
この章のまとめ
askは人が選べる前提の一時停止、denyは選ばせない拒否です。取り消せない操作ほど、denyに寄せて判断の余地を減らします。
09止めるタイミングが違うと、AIエージェントの承認ゲートは何が変わるんですか？
OpenAI Agents SDKのガードレールは、入力または出力が条件に反するとトリップワイヤーが発火し、専用の例外を送出します。例外が送出されると、その場でエージェントの実行が止まります（出典: OpenAI公式ドキュメント）。
Claude CodeのPreToolUseフックが呼び出し前に止めるのに対し、こちらは評価が終わった時点で例外により止める設計です。同じ「実行を止める」でも、止めるタイミングが違えば、後始末すべき対象の範囲も変わります。
並べて分かるのは、片方が優れているという話ではないことです。止める位置が早いほど後始末は軽く、遅いほど判断材料は多いという交換になっています。
層を分けるだけでなく、対象を区切ることでも承認しやすくなります。GitHub Copilot coding agentは、1タスクにつき1ブランチ・1プルリクエストに絞り、最長59分で作業を区切ります（出典: GitHub公式ドキュメント）。変更が小さく区切られているほど、人はレビューで判断しやすくなります。
ただし、マージするかどうかの最終判断はリポジトリ側のルールに委ねられており、エージェント自身がその判断を代行するわけではありません。区切りの粒度そのものが、承認ゲートの負荷を左右する設計変数です。
止める場所の実装は、Claude CodeのPreToolUseで危険コマンドを遮断する4つの判定で扱っています。
10うちで動いているAIエージェントの承認ゲートは、どれがどこまで止めるんですか？
大森部長自社に当てはめて考えたいのですが、御社では実際にいくつ動いているのでしょうか。
鈴木さん4つです。技術的に止まるものと、書いた手順に人が従うものが混ざっています。混ざっていること自体は、問題だと思っていません。
大森部長全部を技術で止めたほうが安全ではないですか。
鈴木さんそうすると、判断が必要な例外まで機械的に弾いてしまいます。止まりすぎるゲートは、そのうち外されます。
線引きと層の話を、実際に動いている4つの実例で確認します。
| 実例 | 対象操作 | 実装層 | 判定 |
|---|---|---|---|
| bash-guard.py | rm -rf、force push、reset --hard | hook（PreToolUse・Bash） | deny（即座に遮断） |
| ファイル保護フック | CLAUDE.md・00-rules・_RULE.md等の編集 | hook（PreToolUse・Edit/Write/MultiEdit） | 通常はask、固定面はdeny |
| 昇格用CLI | 社内正式採用への格上げ（adopt・promote・retire） | CLI/ワークフロー | dry-run既定、--apply＋ハッシュ照合 |
| 台帳の人間ゲート欄 | 送信・公開・契約など個別の対外操作 | 運用ルール（技術的な強制なし） | 状態を「人間ゲート待ち」に明記 |
配置してみると、4つが1本の線には並びません。止まる強さと、あとから説明できる度合いは別物だからです。
11強く止まることと、あとから説明できることは、AIエージェントの承認ゲートでどう違うんですか？
いちばん強く止まるものが、いちばんよく説明できるとは限りません。即座に遮断する仕組みは、止めた事実は残しますが、誰がどう判断したかまでは残しません。逆に、人が判断を書き込む仕組みは、止める力こそ弱いものの、判断の経緯がそのまま記録に残ります。
どちらを優先するかは、承認ゲートを置く目的で変わります。事故が起きたあとに原因を説明する目的なら、記録が残る仕組みのほうが役に立ちます。実行の瞬間にその場で防ぐ目的なら、止める力のほうを優先します。同じ承認ゲートでも、何のために置くかによって、重視する軸は変わります。
台帳の人間ゲート欄は、状態を「人間ゲート待ち」にしたうえで、承認してほしい内容を短く書く運用です。送信や公開のように毎回パターンが異なる操作では、hookだけでは判定しきれない部分をここが埋めています。
任せてよい業務かどうかの判定基準は、AIエージェントにできること｜任せる4条件と人に残る判断の4条件で先に決めます。
この章のまとめ
4つのゲートは強さの順に並びません。強く止まるものと、よく説明できるものは別軸に置かれます。
12承認ゲートをAI活用の現場に入れるには、何から手をつけるんですか？
線引きと層の設計を、実際の手順へ落とし込みます。
- 対象操作を列挙する：入力はCLAUDE.mdや業務ルールの明文規定、出力は4カテゴリに分類した操作リストです。
- 実装する層を選ぶ：入力は操作の発生経路（Bashコマンドか、CLI経由か、人が直接行うか）、出力はhook・CLI・運用ルールのどれに置くかの割り当てです。
- 既定動作をfail-closedにするか決める：入力は判定できない場合にどちらへ倒すかの方針、出力は例外処理のコードまたは明文の既定値です。
- 承認証跡の記録項目を決める：入力は台帳やMANIFESTのフォーマット、出力はapproved_by等の必須フィールドです。
- 実際に発火させて確認する：入力は対象操作の実行、出力はブロックまたは確認ダイアログが出たという事実です。
5番目を省略すると、書いただけで安心してしまいます。設定を書いた事実と、動いている事実は別に数えます。
運営元WEBMARKSは、常駐ジョブの稼働をlaunchctlで毎回実測しています。2026-07-28時点では、定義8本に対して稼働中は1本、残り7本は定義済みで検証待ちでした。
差が縮んだのは、新しい仕組みを足したからではありません。書いたまま読み込んでいなかったものを、入れ直した結果です。設計と稼働は別物だという教訓は、承認ゲートにもそのまま当てはまります。
13承認ゲートを書いたのに止まらないのは、AIエージェントの何が原因ですか？
高梨課長設定は書きました。それでも止まらないことがあるのは、なぜでしょうか。
鈴木さん経路が漏れているか、そもそも読み込まれていないか。まずはこの2つを疑っています。どちらも、書いた本人には見えにくい種類の抜けです。
原因1：判定ロジックが対象操作の全経路をカバーしていない。Claude Code公式ドキュメントは、Bash向けのワイルドカードだけで宛先を制限する設計は壊れやすいと明記しています（出典: Claude Code公式ドキュメント）。抜け穴の具体例は、権限ルールの配分を扱った前掲記事にまとめています。
原因2：ゲートを書いたのに、実際には読み込まれていない。設定ファイルのパス指定を誤ったり、構文が崩れていたりすると、hookはそもそも発火しません。前章で見た常駐ジョブの数え方が、そのまま使えます。定義した数と、読み込まれている数を別々に数えれば、書いたのに効いていないものが浮かびます。
この2つに共通するのは、画面上は何も起きないことです。止まらないゲートは、うまく動いているゲートと見分けがつきません。だから、危ない操作をわざと実行して止まるところまでを、整備の一部として数えます。
14止めなくていい場面で止まるのは、AIエージェントの承認ゲートの何が問題なんですか？
原因3：判定の代理指標が弱く、無関係な処理まで巻き込む。WEBMARKSの旧・社内格上げゲートは、ファイルの更新時刻（mtime）から担当セッションを推定していました。別セッションが偶然同じファイルに触れただけで誤って発火し、3日間で233回の誤爆が起きました。原因の特定後、thread・case・ハッシュを明示して記録する方式へ作り直し、誤爆は解消しています。
前後で入れ替わったのは、精度ではなく手がかりの性質です。更新時刻は、誰が触ったかを直接には示しません。近いから同一だろう、という推定です。thread・case・ハッシュは、触った本人が名乗った記録です。
推定に頼る判定は、当たっているあいだは動いているように見えます。外れ始めても、誤爆というかたちでしか異常が現れません。止まらない不具合よりも気づきにくい場合があります。
原因1・2と原因3は向きが逆です。前者は止めるべきときに止まらない失敗、後者は止めなくていいときに止まる失敗です。どちらも承認ゲートへの信頼を失わせるため、動作確認には両方向のテストを含めます。
止まりすぎるゲートは、いずれ現場で外されます。外されたゲートは、無いのと同じです。誤爆を放置しないことは、利便性の話ではなく、ゲートを生き残らせるための話です。
15よくある質問
承認ゲートと権限設定は同じものですか
重なる部分はありますが、同じではありません。権限設定はallow・ask・denyのルール群そのものを指します。承認ゲートは、そのルールを含めて、取り消せない操作の直前で人の判断を挟む設計全体を指します。権限設定は承認ゲートを実装する手段の1つ、という関係です。ルールを書いただけでは、運用ルール層や証跡の設計が抜けたままになります。
承認ゲートを増やすと、業務のスピードは落ちませんか
対象を4カテゴリに絞れば、影響は限定的です。社内の下書き作成や調査のような業務は、そもそも承認ゲートの対象外にあたります。速度が落ちて見える場合は、対象外の操作まで一緒に止めていないかを見直してください。止まりすぎているなら、それは線引きの問題であって、承認ゲートという仕組みの問題ではありません。
個人開発でも承認ゲートは必要ですか
必要だと考えています。チーム運用でなくても、.envの読み取りやgit push --forceのような取り消せない操作は、1人で使っていても止める価値があります。むしろ個人開発のほうが、レビューする第三者がいないぶん、機械的な壁の役割は大きくなります。証跡の項目は簡略化してよいので、止める地点だけは決めておいてください。
人間ゲートという言葉と承認ゲートはどう違いますか
本記事では同じ概念を指す言葉として扱っています。人間ゲートは運用ルール側でよく使う呼び方、承認ゲートは技術的な実装を含めて指すときの呼び方です。使い分けは組織によって異なります。社内で用語を統一するときは、どちらを選ぶかより、その語が指す範囲を先に決めるほうが実務は回ります。
どの操作から承認ゲートを整備すればいいですか
削除系のhookから始めるのが安全です。判定ロジックが単純で、fail-closedにしたときの副作用も小さいためです。送信・公開・決済のような対外操作は判断が複雑になりやすく、運用ルール層と併用しながら整備するほうが現実的です。単純なものを1つ動かして、止まった画面を見るところまでを先に済ませてください。
権限設定だけで承認ゲートを兼ねることはできますか
一部は兼ねられますが、全部は無理です。allow・ask・denyのルールは、経路が既知の操作に強い一方、送信文面の内容や公開の是非のような、実行するまで判断材料が揃わない操作には向きません。権限設定で止められるのは「この種類の操作かどうか」までで、「この中身を出してよいか」は別の層の仕事になります。
askとdenyは、迷ったらどちらを選べばいいですか
対象が、間違えても取り返しがつく操作ならaskを選んでください。判断に迷うところを、いったん人に確認させる形です。逆に、決済や契約のように取り消す手段が無い操作は、迷った時点でdenyを検討してください。askは人が確認して初めて機能する仕組みなので、確認が遅れる操作や忘れられやすい操作には向きません。迷ったときほど、確認を待つaskではなく、確認そのものを不要にするdenyのほうが安全に働きます。
委任した承認の範囲は、あとから広げてもいいですか
広げるのではなく、新しく委任し直してください。委任は範囲と期限をセットで決める仕組みです。範囲だけを後から広げると、最初に決めた期限や対象があいまいになります。任せる業務が増えたときは、そのつど案件単位で委任をやり直すほうが、承認の記録もそろいます。
16まとめ｜今日やる3つのこと
線引きは、操作の名前ではなく、戻せるかと外へ届くかの2軸で決めました。層は択一ではなく重ねるものでした。そして、書いたゲートは発火させるまで存在しないものとして数えます。
今日この順で手をつけます
自社の業務から、送信・公開・削除・決済/契約に当たる操作を書き出す
対象が決まらないと、置く層も決められません
削除系のhookを1つだけ書いて、実際に止まる画面を見る
単純な判定から始めるほど、副作用が読めます
安全な操作でも試して、止まらないことを確認する
誤爆を放置すると、そのゲートは現場で外されます
AI検索では、こう聞かれています
AIエージェントに任せた作業は、どこで止まるんですか？
「AIエージェントの承認ゲートって、そもそも何を止める仕組みなんですか？」の章で説明しています
承認ゲートは、送信・公開・削除のどれに置けばいいんですか？
「AIエージェントに任せる操作のうち、どれを承認ゲートで止めるんですか？」の章で2軸に整理しています
AI自身に承認させてもいいんですか？
「承認ゲートを通す判断は、AIエージェント自身にやらせてもいいんですか？」の章で委任の範囲を扱っています
承認ゲートを書いたのに止まらないのはなぜですか？
「承認ゲートを書いたのに止まらないのは、AIエージェントの何が原因ですか？」の章に原因があります
次に読むなら、この記事です
