AIエージェント停止後の運用手順とは？承認・再開・手動切替を決めるRunbook設計【2026年版】

AIエージェントを安全に止められるようになっても、それだけでは本番運用は完成しません。 本当に難しいのは、止まった後です。誰が確認するのか。何を根拠に承認・却下するのか。いつ再開してよいのか。どの条件なら人手処理へ切り替えるのか。ここが曖昧なままだと、「AIは止められたが、業務は動かない」という状態に陥ります。

承認依頼は飛んでくる。しかし、誰が開くべきかが決まっていない。開いたとしても、ログは読めず、判断基準もない。Slackには「これ誰判断ですか？」「一旦保留で」と流れ、処理はそこで止まる。AIエージェントは安全に停止したはずなのに、今度は業務そのものが止まってしまうのです。

Guardrails / Human Review は、AIエージェントをどこで止め、どこで人に渡すかを設計する領域です。一方で本記事が扱うのは、その後の実務です。停止・保留・例外状態になったAIエージェントを、誰が裁定し、どう再開・却下・手動切替するかを、運用手順として落とし込むことです。

本記事は、AIエージェント統制シリーズの最後を締める「停止後の実務テンプレート」です。概念としての安全設計ではなく、現場で使える Approval Policy と Runbook の作り方を整理します。

 

何が問題なのか

AIエージェント運用で本当に詰まるのは、止めることよりも「止まった後に誰も判断できないこと」です。

Guardrails を入れれば、AIエージェントを止められるようになります。Human Review を入れれば、人間の判断を挟めるようになります。しかし、それだけで本番運用が回るわけではありません。

現場で起きるのは、もっと泥臭い問題です。承認依頼が来たが、誰が見るべきかわからない。ログはあるが、何を根拠に承認してよいかわからない。却下した後に、AIに再実行させるのか、人手に切り替えるのかが決まっていない。業務責任者と技術担当のあいだで、判断が宙に浮く。

結果として、AIエージェントは止まったが、業務も一緒に止まってしまうのです。
止めることは入口です。けれど、本番運用で重要なのは、止めた後に業務を安全に再開できることです。

運用はどこで詰まるのか

運用が詰まりやすいのは、判断責任が曖昧な場面です。AI運用担当は技術的には判断できても、顧客影響や金額影響までは背負えない。業務責任者は判断権限を持っていても、AIがなぜその操作をしようとしたのかが見えなければ判断できない。セキュリティ担当は権限逸脱の有無を確認できても、業務上の例外対応までは決められない。

この隙間を埋めるのが、Approval Policy と Runbook です。

実装と統制の全体像は、2026年、AIエージェント「実装元年」へ、本番運用の見取り図は「デモで動く」から「本番で稼ぐ」へ。LLMOps完全ガイドと合わせて読むと整理しやすくなります。

Approval Policyとは何か

Approval Policyとは、AIエージェントが保留・停止したときに、誰が何を根拠に承認・却下・差し戻しするかを決める方針です。

Approval Policy は、「人が見る」という曖昧な確認工程ではありません。AIエージェントが高リスク操作に進もうとしたとき、誰が、どの条件で、承認・却下・差し戻しを判断するかを定める方針です。

重要なのは、承認者を単なる役職名で決めないことです。部長だから承認する、PMだから承認する、エンジニアだから確認する、という決め方では実務に耐えません。承認者は、その操作がもたらす業務影響を引き受けられる責任範囲で決める必要があります。

承認・却下・差し戻しの違い

Approval Policy では、少なくとも3つの判断を分けます。

第一に承認です。リスクを確認したうえで、そのまま処理を進めてよいと判断することです。

第二に却下です。処理を進めるべきではないと判断し、AIエージェントの操作を中止することです。

第三に差し戻しです。これは単なるやり直しではありません。AIエージェントに判断根拠・参照情報・tool call履歴・停止理由を再提示させることで、人間が責任を持って承認・却下できる材料をそろえるプロセスです。単なる再実行ではなく、判断を成立させるための準備工程として位置づけてください。

この3つを分けないと、Approval Policy は「承認するかしないか」だけの粗い仕組みになります。しかし実務では、完全に承認できないが、直ちに却下するほどでもないケースが多くあります。だからこそ、差し戻しという選択肢が重要になります。

操作のリスク度で承認ルートを変える

Approval Policy は、すべての操作に同じ承認ルートを適用するものではありません。軽微な再実行と、顧客データ更新、権限変更、高額処理では、判断者も確認すべき情報も違います。

表1：操作リスク別のApproval Policy例

状態	一次判断者	判断基準	次の処理
軽微な形式エラー	AI運用担当	再入力・再実行で解消可能か	差し戻し、または再実行
顧客影響あり	業務責任者	顧客通知や手動確認が必要か	承認、却下、手動処理
権限逸脱疑い	セキュリティ担当	不正操作・権限外操作の有無	停止継続、調査、却下
高額処理	部門責任者	金額・契約・予算影響	上位承認、却下、手動切替
※ 重要なのは「誰が見るか」ではなく、「誰がその判断責任を引き受けられるか」で承認ルートを設計すること

Runbookとは何か：AI運用手順・インシデント対応の中核

Runbookとは、停止後に誰が、どの順番で、何を確認し、どう再開・却下・手動切替するかを定めた実行手順です。

Approval Policy が「判断方針」だとすれば、Runbook は「実行手順」です。何を承認するかを決めるのが Approval Policy、実際に止まった後にどの順番で確認し、誰へ回し、何を記録し、どう処理を再開または手動切替するかを決めるのが Runbook です。

これは、インシデント対応手順に近い考え方です。障害対応で「誰が一次受けし、どのログを見て、どの条件ならエスカレーションし、いつ復旧完了とみなすか」を決めるのと同じように、AIエージェント運用でも停止後の手順を明文化する必要があります。言い換えればRunbookは、AI運用手順であり、承認フロー設計であり、AIガバナンス運用を現場で回すための基盤です。

Approval PolicyとRunbookの違い

両者を混同すると、承認方針はあるのに現場が動けない、あるいは手順はあるのに判断責任が曖昧という状態になります。役割は明確に分けるべきです。

表2：Approval PolicyとRunbookの違い

項目	Approval Policy	Runbook
役割	判断方針	実行手順
主な問い	誰が何を承認・却下するか	どう確認し、どう処理するか
成果物	承認基準・責任分界	手順書・チェックリスト
対象	判断ルール	現場オペレーション

Runbookには証跡が必要

Runbookで重要なのは、手順だけではありません。判断の根拠となる証跡も必要です。AIエージェントが何を入力として受け取り、どの tool call を実行しようとし、どの Guardrails によって停止し、どの判断者が何を根拠に承認・却下したのか。これらが残っていなければ、後から説明できません。

Runbookは、単なるテキストの手順書ではありません。MCP経由のツール実行コンテキスト、参照したデータソース、引用元、tool call履歴、承認者の判断理由——これらを後から確認できる状態にして初めて、Runbookとして機能します。

証跡設計は、AIエージェントObservabilityやAIエージェントのゼロトラスト設計と密接に関係します。Runbookは、ログや監査証跡があることを前提に初めて機能します。

Guardrails / Human Reviewとの違い

Guardrails / Human Reviewは「止める・人に渡す」設計であり、Approval Policy / Runbookは「渡された後にどう裁くか」の設計です。

この違いを明確にしておかないと、Guardrails記事とRunbook記事はすぐに重なります。Guardrails は、入力・出力・ツール挙動に対して業務ルールを実行時に適用する仕組みです。Human Review は、高リスク操作の直前で人間判断へ渡す仕組みです。

一方で Approval Policy / Runbook は、渡された後にどうするかを扱います。誰が判断するのか。何を見て承認・却下するのか。却下した場合はどうするのか。差し戻すのか。手動処理へ切り替えるのか。再開してよい条件は何か。ここが主題です。

5つのレイヤーで見る役割分担

シリーズ全体では、次のように切り分けると整理しやすくなります。

表3：AIエージェント統制における各レイヤーの役割

領域	主な問い	出力
Observability	本番で何を見続けるか	ログ、トレース、tool call、状態遷移
Failure Detection	何を異常と判断するか	アラート、異常ラベル、エスカレーション条件
Guardrails	どこで自動停止するか	自動停止、入力・出力・tool制御
Human Review	どこで人に渡すか	保留、承認待ち、判断依頼
Approval Policy / Runbook	誰が裁定し、どう再開・却下・手動切替するか	承認基準、再開条件、手動切替手順、証跡

Guardrails / Human Review の詳細は、AIエージェントのGuardrailsとは？Human Review・承認フロー・停止条件の設計実務で整理しています。本記事では、その後段である停止後の運用手順に焦点を当てます。

誰が裁定するのか

裁定者は役職名ではなく、業務影響・セキュリティ影響・金額影響を引き受けられる責任範囲で決めます。

AIエージェントが停止した後、誰が裁定するべきでしょうか。

よくある失敗は3つです。PMに回すと責任が集中して詰まります。情シスに回すと業務判断ができません。業務部門に回すと技術的な原因や再実行可否が判断できません。いずれも「とりあえず」で振った結果、判断責任が宙に浮くことが共通しています。だからこそ、裁定者は役職名ではなく、影響範囲と責任範囲で決める必要があります。

裁定者は、操作の種類と影響範囲で決めるべきです。顧客影響があるなら業務責任者、権限逸脱の疑いがあるならセキュリティ担当、金額や契約に関わるなら部門責任者、技術的な再実行可否ならAI運用担当が関与する。こうした分担をあらかじめ決めておく必要があります。

RACIで責任分界を明確にする

実務では、RACI表を使うと整理しやすくなります。RACIとは、Responsible（実行責任）、Accountable（説明責任）、Consulted（相談先）、Informed（共有先）を分ける考え方です。

表4：AIエージェント停止後のRACI例

作業	AI運用担当	業務責任者	セキュリティ担当	PM
一次確認	R	C	C	A
再開判断	C	A	C	R
権限逸脱調査	C	C	A	R
事後レビュー	R	A	C	I
R：実行責任、A：説明責任、C：相談先、I：共有先。事後レビューはAI運用担当が実施責任を持ち、PMは結果確認先として扱う想定です。

最終判断者を曖昧にしない

AIエージェント停止後の判断では、複数部門が関与します。しかし、複数人が関与することと、誰が最終判断者かが曖昧であることは別です。最終判断者が曖昧だと、誰も責任を取れず、停止状態が長引きます。

Runbookには、少なくとも「一次確認者」「最終判断者」「相談先」「通知先」を明記しておくべきです。

再開・却下・手動切替の条件をどう決めるか

停止後の選択肢は「再開」だけではありません。却下、差し戻し、手動切替、停止継続を含めて判断条件を設計します。

AIエージェントが止まった後、すぐ再開するとは限りません。場合によっては、却下すべきです。人手処理へ切り替えるべきです。追加情報が必要なら差し戻すべきです。権限逸脱や顧客影響が疑われるなら、停止を継続して調査すべきです。

Runbookでは、この分岐を事前に決めます。判断者の経験や勘だけに任せると、同じようなケースでも処理がばらつきます。ばらつきは、AIエージェント運用において大きなリスクです。

判断マトリクスを作る

次のような判断マトリクスを用意しておくと、停止後の処理が安定します。

表5：停止後の判断マトリクス例

状態	判断	次の処理
軽微な形式不備	差し戻し	入力修正後に再実行
顧客影響なし	再開	通常処理へ戻す
顧客影響あり	手動切替	業務担当が処理
権限逸脱疑い	停止継続	セキュリティ確認
金額影響あり	上位承認	部門責任者が判断

再開が常に正解ではない

AI運用で最も多い誤りは、「止まったらすぐ再開すること」です。しかし実務では、再開よりも「止め続ける判断」のほうが重要な場面があります。権限逸脱、顧客影響、金額影響、契約影響が疑われる場合、早く戻すことよりも、戻してよい理由を説明できることが優先されます。

重要なのは、再開の速さではなく、再開してよい理由を説明できることです。

Runbookテンプレート

Runbookは、発生条件・確認者・判断基準・再開条件・記録すべき証跡を1枚で確認できる形にします。

ここからは、実務で使いやすいテンプレートとして整理します。最初から細かく作り込みすぎる必要はありません。まずは、AIエージェントが停止したときに、現場が迷わず動ける最低限の項目を押さえることが重要です。

基本テンプレート

1. 発生条件
2. 自動停止理由
3. 一次確認者
4. 確認すべき情報
5. 承認条件
6. 却下条件
7. 差し戻し条件
8. 手動切替条件
9. 再開条件
10. 記録すべき証跡
11. Evals / Failure Detectionへのフィードバック

記入例：顧客データ更新エージェント

対象業務：
顧客データ更新エージェント

1. 発生条件：
承認フラグが false のまま、顧客データ更新APIを実行しようとした場合

2. 自動停止理由：
承認前の顧客データ変更は業務ルール違反であるため

3. 一次確認者：
AI運用担当

4. 確認すべき情報：
・対象顧客ID
・変更予定項目
・AIが参照した入力情報
・呼び出そうとしたAPI
・停止したGuardrails条件
・直前のtool call履歴

5. 承認条件：
業務責任者が変更内容を確認し、顧客影響がないと判断した場合

6. 却下条件：
入力情報が不足している、変更対象が不明確、または顧客影響が大きい場合

7. 差し戻し条件：
追加確認、入力修正、または再分類が必要な場合

8. 手動切替条件：
顧客影響がある、またはAIによる再実行が不適切な場合

9. 再開条件：
承認者が変更内容と影響範囲を確認し、処理再開を明示した場合

10. 記録すべき証跡：
承認者、判断時刻、判断理由、参照ログ、実行結果

11. Evals / Failure Detectionへのフィードバック：
同様の停止が3回以上発生した場合、評価データセットとFailure Detection条件を見直す

テンプレート化する意味

テンプレート化の目的は、現場を縛ることではありません。判断のばらつきを減らし、再現可能な運用にすることです。Runbookがあると、属人的な判断を減らせます。監査にも説明しやすくなります。EvalsやFailure Detectionへのフィードバックもしやすくなります。

AIエージェントの運用では、止まった事実そのものが改善データになります。Runbookは、その改善データを現場から回収するための器でもあります。

実務ではどこから始めるか

最初から全業務にRunbookを作るのではなく、止まる意味が明確な高リスク操作から始めます。

Runbook設計は、最初から全業務に広げる必要はありません。むしろ、最初から広げすぎると、作るだけで終わります。最初は、停止する意味が明確で、かつ業務影響が大きい操作から始めるのが現実的です。

おすすめは、以下のような操作です。

• 顧客データ更新
• 外部送信
• 金額確定
• 権限変更
• 契約関連アクション
• 対外的な通知や回答確定

まず1業務1Runbookから始める。その後、停止パターンが増えてきたら、共通テンプレート化して横展開する。この順番が現実的です。

一次情報からどこまで言えるか

一次情報から言えるのは、AIエージェント運用では停止・保留・承認・状態管理を、実行時の状態遷移として扱う必要があることです。

このテーマでは、一次情報と実務解釈を分けて考える必要があります。OpenAIの関連ドキュメントでは、Guardrails、approvals、results、state といった概念を通じて、エージェントの実行途中に停止・承認・状態管理を組み込む考え方が示されています。

一方で、Approval Policy や Runbook という言葉は、各社ドキュメントの用語そのものというより、実務運用へ落とし込むための設計概念として扱うのが自然です。一次情報から直接言えるのは「停止・承認・状態管理が実行時設計として重要であること」です。そこから先の「誰が裁定し、どう再開するか」は、企業側が自社の業務責任・監査要件・セキュリティ要件に合わせて設計すべき領域です。

一次情報

OpenAIの Guardrails and approvals では、input、output、tool behavior に guardrails を適用し、人間またはポリシーによる approval を組み合わせる考え方が説明されています。Results and state では、エージェント実行の結果や状態管理を扱う前提が示されています。Integrations and observability では、実行時の trace や tool call を観測可能にする考え方が示されています。

Anthropicは、AI agents の評価において、最終発話だけではなく、環境の最終状態や途中過程を評価対象に含める必要性を説明しています。これはRunbookそのものの資料ではありませんが、停止後の判断において「AIが何を変えようとしたのか」「環境がどう変化したのか」を確認する重要性を補強します。

解釈

ここから言えるのは、AIエージェントの本番運用では、停止・承認・再開を場当たり的な人間作業にしてはいけないということです。停止した後に、誰が、何を見て、どの条件で再開・却下・手動切替するか。ここまでをRunbookとして定義して初めて、AIエージェントは本番運用の対象になります。

Arpableとしては、Approval Policy / Runbook を「止めた後に業務を安全に再開するための運用OS」として捉えるのが適切だと考えます。

まとめ

AIエージェントを止められることと、止めた後に業務を再開できることは別問題です。

結論を再整理すると、Guardrailsで止めるだけでは不十分です。Human Reviewで人に渡すだけでも不十分です。そこから先に、誰が裁定し、どう再開・却下・手動切替するかを決めて初めて、AIエージェントは本番運用に耐えうる設計になります。

Approval Policy は、誰が何を根拠に承認・却下・差し戻しするかを決める方針です。Runbook は、停止後に誰が、どの順番で、何を確認し、どう処理するかを定めた手順です。

AIに賢く振る舞わせるのは技術の仕事です。しかし、AIが止まった理由を読み解き、失敗を次の改善へ変え、事業を前へ進めるのはリーダーの仕事です。

AIエージェントを本番で使うとは、AIを自由に動かすことではありません。止めるべきときに止め、止まった後に人間が責任を持って裁定し、業務を安全に再開できる状態を作ることです。

まずは、自社で最も影響の大きいAIエージェント操作を1つ選び、その停止後Runbookを1枚で作ってみてください。それが、AIエージェント統制を概念から実務へ移す最初の一歩になります。

参考文献 / 出典

次に読むならこの6本

補足Q&A

Q1. Approval Policyとは何ですか？

A1. Approval Policyとは、AIエージェントが停止・保留・例外状態になったとき、誰が何を根拠に承認・却下・差し戻しを判断するかを定めた方針です。

Q2. Runbookとは何ですか？

A2. Runbookとは、停止後に誰が、どの順番で、何を確認し、どう再開・却下・手動切替するかを定めた実行手順書です。

Q3. Guardrails / Human Reviewとの違いは何ですか？

A3. Guardrails / Human Reviewは、どこで止め、どこで人に渡すかを設計します。Approval Policy / Runbookは、渡された後に誰が裁定し、どう再開・却下・手動切替するかを設計します。

Q4. 最初に作るべきRunbookはどれですか？

A4. 顧客データ更新、外部送信、金額確定、権限変更のように、止まった後の判断が業務影響に直結する高リスク操作から始めるのが現実的です。

更新履歴