AIエージェントに外部向けの操作まで任せたら、メールを1回誤送信して冷や汗をかきました。原因は「どこまで自動でやらせるか」の線引きを決めずに走らせたこと。そこから安全装置を組み込み直したところ、誤操作はゼロ、承認作業は1日たった5分で回るようになりました。
この記事は、個人で運用しているAIエージェントの一次情報をもとに、「暴走を防ぎつつ自動化を止めない」ための設計パターンをアンチパターン→改善パターンの形でまとめたものです。コピペで使える台帳の書式・ディレクトリ構成・シェルも載せています。企業導入の不安どころとほぼ重なる話なので、ストックして必要なときに引いてください。
まず全体像: 安全設計は「5層」で考える
個別のテクニックの前に、AIエージェントの安全設計は5つの層に分けると抜け漏れがありません。上から順に「そもそも止められるか」「何を許すか」「外に出す前に人が見るか」「後から追えるか」「本番前に試すか」です。
| 層 | 安全装置 | 役割 | 効くリスク |
|---|---|---|---|
| 1 | キルスイッチ | 全体を即時停止 | 想定外の連続実行・暴走 |
| 2 | 権限レベル | 操作ごとに自動/確認/禁止を定義 | 権限の与えすぎ |
| 3 | 承認キュー | 外部アクションを人が承認してから実行 | 誤送信・誤操作 |
| 4 | 監査ログ | 誰が何をしたか全記録 | 事後追跡・原因究明 |
| 5 | ドライラン | 本番反映せず結果だけ確認 | 破壊的操作の巻き戻し不能 |
この5層は独立して効くので、1つずつ足していけばいいのがポイントです。以下、層ごとに実装を見ていきます。
パターン1: 権限レベルを3段階で定義する
アンチパターンは「エージェントに全部の操作を自動で許す」設定です。読み取りも書き込みも外部送信も一律に自動化すると、便利な一方で、たった一度の判断ミスが本番に直結します。私の誤送信もこれが原因でした。
改善パターンは、操作をread-only / draft / executeの3段階に分けることです。判断基準はシンプルで、「取り返しがつくか」で切ります。
| 権限レベル | 対象操作 | 挙動 | 例 |
|---|---|---|---|
| read-only | 参照のみ | 常に自動 | ログ閲覧・DB参照・コード読解 |
| execute | 内部の書き込み | 閾値内は自動 | ファイル更新・タスク登録 |
| draft | 外部向けアクション | 必ず承認キュー経由 | メール送信・SNS投稿・本番デプロイ |
「内部操作は自動、外部操作は承認必須」——この線引きが、安全性と効率を両立させる現実的なラインでした。read-onlyの操作をいくら自動化しても事故は起きないので、まずは参照系を全部自動化してしまうと体感速度が一気に上がります。
パターン2: 外部アクションは承認キューに通す
権限レベルで draft に分類した操作は、直接実行させず承認キューを挟みます。私が誤送信の後に組んだのは、次の4ステップです。
- ドラフト生成: エージェントが下書きを作る（まだ送らない）
- キュー格納: 承認待ちとして台帳に積む
- 人間承認: 中身を見てOK/NGを判断する
- 実行: 承認されたものだけ実際に送る
この仕組みにしてから誤送信・誤操作はゼロになりました。承認作業自体は1日5分程度なので、安全性のために効率を大きく犠牲にすることもありません。
承認キューは大げさなシステムを組む必要はなく、Markdownの台帳1枚で十分回ります。コピペで使える書式がこちらです。
# 承認キュー（approval-queue.md）
## APR-2026-0712-01 ← 受付ID（日付+連番）
- 種別: email
- 状態: pending # pending / approved / rejected / done
- 起票: agent-cs
- 概要: 問い合わせ返信ドラフト（顧客A宛）
- 本文: drafts/reply-APR-...-01.md
- 起票日時: 2026-07-12T09:30
- 承認者: # 承認時に記入
- 実行日時: # 実行後に記入
状態を pending → approved → done と手で書き換えるだけ。「実行前に必ず人の目を1回通す」構造さえ守れれば、道具は何でもいいというのが実感です。
パターン3: キルスイッチで全体を即時停止する
承認キューがあっても、「暴走に気づいてから止める手段」が別に要ります。アンチパターンはプロセスを探して kill する運用。慌てているときほど誤爆します。
改善パターンは、マーカーファイル1つで全体を止めるキルスイッチです。特定のファイルが存在したら、状態を変える操作をすべて拒否する。ファイルを1個 touch するだけで「休暇モード（読み取り専用）」に落とせます。
#!/bin/bash
# 状態変更ツールの実行前フックで呼ぶ（PreToolUse等）
PAUSED_FILE=".company/secretary/PAUSED"
if [ -f "$PAUSED_FILE" ]; then
echo "🛑 PAUSED: 状態変更操作はブロックされました（読み取りは可）" >&2
exit 1 # 非ゼロで終了 → 操作をブロック
fi
exit 0
touch .company/secretary/PAUSED # 全停止（休暇モードに入る）
rm .company/secretary/PAUSED # 再開
重要なのは、これを運用ルール（お願いベース）ではなくフックで機械的に強制することです。「止めてね」とプロンプトに書くだけでは、モデルがうっかり無視する余地が残ります。仕組みで止まる形にして初めて、安心して自動化に任せられます。
パターン4: ドライランで破壊的操作を試し打ちする
本番のデータやスキーマを変える操作は、巻き戻せるかが生命線です。以前、30以上のテーブルに影響するDBスキーマ変更をやったとき、いきなり本番に当てるのが怖くて、まず変更後スキーマとの差分からマイグレーションとロールバックの両方を生成させ、ステージングで試しました。結果、32テーブル分を2時間で安全に流し切れました。
これを一般化したのがドライランです。エージェントには「本番反映せず、実行したら何が起きるかだけ出す」モードを持たせます。DRY_RUNマーカーがあれば、書き込み系は差分の表示だけで止める、という作りです。
if [ -f ".company/secretary/DRY_RUN" ]; then
echo "[DRY-RUN] 本来ここで実行: $ACTION" # 実行はせず内容だけ表示
exit 0
fi
# 通常時はここで本当に実行
破壊的操作にはロールバック手順をセットで用意する——この習慣をエージェントの標準動作に組み込んでおくと、事故ったときの復旧が段違いに楽になります。
パターン5: 監査ログで「誰が何をしたか」を残す
自動化が進むほど、後から「これ、いつ誰の判断で実行された？」を追えることが効いてきます。アンチパターンはログを取らない、あるいは取っても構造がバラバラで検索できない状態です。
改善パターンは、状態を変える操作を1行ずつ追記ログに残すこと。実際、あるトラブルで過去24時間分のエラーログ（約5,000行）と関連コードをエージェントに読ませたら、3日間特定できなかったレースコンディションを15分で突き止められました。ログは「貯めておけば、AIが読む」資産になります。
2026-07-12T09:31 | agent-cs | draft | email APR-...-01 をキュー投入
2026-07-12T09:45 | human | approve | APR-...-01 を承認
2026-07-12T09:45 | system | execute | email 送信完了
日時 | 実行主体 | 操作種別 | 対象 の4カラムに揃えておくと、後からgrep一発で追えます。監査ログは書くのは地味だが、読むときに救われる典型です。
パターン6: エージェントを分割して権限も分ける
安全設計は1体のエージェントに全部背負わせると破綻します。以前、1つのエージェントに全業務を任せたらコンテキストが肥大化し、レスポンスが遅く的外れな回答も増えました。そこで役割別にエージェントを分割し、受付役がルーティングする構成に変えたところ、応答精度が約40%向上、処理速度も平均2倍になりました。
これは安全面でも効きます。エージェントごとに持てる権限を絞れるからです。参照専門のエージェントには read-only しか与えない、外部送信は特定のエージェントだけに許す——という具合に、最小権限の原則をエージェント単位で適用できます。人間の組織で「経理と承認者を分ける（職務分掌）」のと同じ発想です。
パターン7: read-onlyタスクから自動化を広げる
最後は攻めの話です。事故が怖くて自動化に踏み出せないなら、まず read-only の領域から始めるのが安全かつ効果的です。参照だけなら壊しようがありません。
- ドキュメント生成: 散在していた80本のAPIエンドポイント仕様を、コードから逆生成して2日で整備
- セキュリティスキャン: 約3万行のアプリにOWASP観点のチェックをかけ、12箇所の潜在脆弱性（うち3箇所は悪用可能なSQLインジェクション）を検出。外部診断だと**100万円〜**かかる一次スクリーニングをコストゼロで実施
いずれも「読むだけ」なので承認キルスイッチも要らず、失敗のリスクがありません。read-onlyで信頼を貯めてから、execute → draft と段階的に任せる範囲を広げるのが、暴走させずに自動化を伸ばす王道です。
まとめ: 安全装置は「引き算」ではなく「土台」
AIエージェントの安全設計は、自動化にブレーキをかけるための我慢ではありません。止められる・許可を絞れる・人が最後に見る・後から追える・試し打ちできる——この5層があるからこそ、安心してアクセルを踏めます。
導入順のおすすめは次の通りです。
- read-only を洗い出して全部自動化（すぐ効く・リスクゼロ）
- 外部操作を承認キューに通す（誤送信を止める）
- キルスイッチをフックで機械強制する（保険をかける）
- 監査ログとドライランを足す（追跡と巻き戻しを担保）
「どこまで任せるか」を構造で定義すれば、AIエージェントは怖い道具ではなく頼れる同僚になります。まずは参照系の自動化から、1層ずつ積み上げてみてください。
この記事が参考になったら、いいね・ストック していただけると励みになります。
Claude Code・AIエージェント・業務自動化の実装Tipsを継続的に発信しています。フォロー しておくと新着が届きます。
みなさんはAIエージェントに「ここまでは自動、ここからは承認」の線をどこで引いていますか？ ぜひコメントで教えてください。
関連記事