人の確認をどこに入れるか：承認・差し戻し・監査ログの設計｜AIエージェントと業務自動化 第6回

承認をはさむ基準：操作の重さで決める

承認を入れる場所は、図1のように、AIエージェントが行う操作の重さで決めるのが基本です。

「社内のシステムに書き込む」操作は、一律に承認を入れるとAIの効果が薄れるため、しきい値を決めます。たとえば「顧客情報の更新は1回に10件まで自動、それを超えたら承認」「発注の準備は合計5万円未満なら担当者の確認だけ、5万円以上は上長の承認」のように、数字で決めておくと判断がぶれません。

しきい値は、最初は低め（承認が多め）に設定し、運用の記録を見ながら少しずつ上げていくのが安全です。第1回で学んだ「自律性の段階」を、操作の種類ごとに一段ずつ上げていくイメージです。

承認依頼の作り方：承認者が10秒で判断できるように

承認の仕組みを作っても、承認する人が中身を理解できなければ、関所として機能しません。承認依頼には、図2の5つの項目を載せるのが基本です。

1. 何をするか：「A社に見積書のメールを送信します」のように、実行する操作を具体的に
2. なぜそうするか：「A社から11月10日に見積もりの依頼があったため」
3. 根拠となる情報：参照した問い合わせ、使った料金表、過去の取引の記録など。承認者がすぐ確認できるようにリンクをつける
4. 影響の範囲：「送信先：A社の担当者1名」「金額：合計48万円」など
5. 承認しない場合どうなるか：差し戻すと誰に戻るのか、保留するといつまで待つのか

特に大切なのは3の「根拠」です。AIの判断の根拠が示されていれば、承認者はその根拠が正しいかを確かめるだけで済みます。根拠が示されていないと、承認者は一から調べ直すか、よく分からないまま承認するかのどちらかになってしまいます。

たとえば、チャットに届く承認依頼は、次のような形にすると判断しやすくなります。

【承認依頼】A社への見積書の送信
内容：A社の佐藤様（購買部）に、見積書（合計48万円・税別）をメールで送信します。
理由：11月10日のお問い合わせで、20名分の見積もりのご依頼がありました。
根拠：お問い合わせメール／料金表（2026年10月版）／A社との前回の取引（2025年度）
承認しない場合：営業部の山田さんに戻ります。保留した場合は、翌日17時に再通知します。
［承認する］［差し戻す（理由を選ぶ）］［保留］

ボタンを押すだけで承認・差し戻しができ、根拠をクリックすれば中身を確かめられる形にしておくと、承認者の負担が減り、承認の質も保ちやすくなります（例の人名・社名は架空です）。

よくある誤解：「承認を入れておけば安全」

承認の仕組みを入れれば安全だと考えがちですが、実はそうとは限りません。承認の依頼が多すぎると、承認する人はやがて中身をよく見ずに承認ボタンを押すようになります。これを「承認疲れ」と呼ぶことがあります。承認疲れが起きると、関所は形だけになり、本当に止めるべき操作も通ってしまいます。

承認疲れを防ぐには、次の工夫が有効です。

• 承認は重い操作に絞る：図1の基準で、本当に必要なところにだけ入れる
• まとめて承認できるようにする：同じ種類の軽い操作は、1日分をまとめて一覧で確認する
• 承認の数と差し戻しの割合を記録する：差し戻しがほとんどない承認は、しきい値を上げる候補。差し戻しが多い承認は、AIの手順や指示を見直す候補

差し戻しの設計：「なぜダメか」をAIの改善につなげる

承認者がAIの提案を差し戻したとき、その理由を記録しておくと、AIエージェントを改善する貴重な材料になります。図4は、差し戻しを改善につなげる流れです。

差し戻しの理由は、自由記述だけでなく、選択肢から選べるようにしておくと集計しやすくなります。たとえば次のような選択肢です。

• 事実の誤り（金額・日付・名前など）
• 参照した情報が古い
• 言葉づかいや表現が不適切
• そもそもこの操作は不要
• その他（自由記述）

月に一度、差し戻しの理由を集計すると、「参照した情報が古い」が多ければマニュアルを更新する、「言葉づかい」が多ければAIへの指示に表現のルールを追加する、といった具体的な改善策が見えてきます。

また、差し戻されたあとの流れも決めておきます。AIに理由を伝えて作り直させるのか、担当者が手で直すのか。作り直しの回数に上限を設け、上限に達したら人が引き取るようにしておくと、同じやりとりが延々と続くのを防げます。

監査ログ：あとから「何が起きたか」をたどれるように

AIエージェントの仕組みでは、人がすべての操作を見ているわけではありません。だからこそ、何が起きたかをあとからたどれる記録（監査ログ）が重要になります。問題が起きたときの原因調査だけでなく、改善の材料にも、社内外への説明にも使います。

監査ログには、図5の項目を残すのが基本です。

• いつ：日時
• 誰の依頼か：どの利用者の依頼、またはどのトリガーで始まったか
• AIの判断と根拠：AIが何を判断し、何を根拠にしたか
• 使った道具と入力：どの道具を、どんな入力で呼び出したか
• 結果：成功・失敗、エラーの内容
• 承認の記録：誰が、いつ承認・差し戻ししたか、その理由
• AIへの指示の版：そのときに使っていた指示やルールのどの版か

最後の「指示の版」は見落とされがちですが重要です。AIへの指示やマニュアルは運用中に何度も改善されます。どの版の指示で動いたかが分からないと、「なぜこのときだけおかしな判断をしたのか」を調べられません。指示を書き換えるときは、日付と変更内容を残しておきましょう。

あわせて、監査ログ自体の扱いも決めておきます。監査ログには顧客情報が含まれることも多いため、誰が見られるか、どれくらいの期間保存するか、いつ消すかを、社内の情報管理のルールに沿って決めます。

この記事の監修者に相談できます

監修者の田中磨生が代表を務める株式会社Abinで、ご相談をお受けしています。

相談無料ツギノテ編集部に相談する→

止めるための仕組み：「非常停止ボタン」を用意する

最後に、承認とは別に、AIエージェントをすぐに止める手段を用意しておきます。たとえば、AIエージェントが同じ処理を繰り返して大量のメールの下書きを作り続けている、想定外の操作を試みている、といった異常に気づいたとき、すぐに止められなければ被害が広がります。

• 誰が止められるか（管理者、担当部署の責任者など）
• どうやって止めるか（ワークフローの無効化、AIエージェントの権限の停止など）
• 止めたあと、どう業務を続けるか（人の手作業に戻す手順）

この3つを、運用を始める前に決めて、関係者に共有しておきます。止める手順は、一度実際に試しておくと安心です。

実務ではこう使う：運用開始前のチェックリスト

AIエージェントの仕組みを本番で動かす前に、次のチェックリストで確認しましょう。

• [ ] 操作の種類ごとに、確認の厚さ（不要・確認・しきい値つき承認・必ず承認）を決めた
• [ ] しきい値（件数・金額など）を数字で決めた
• [ ] 承認依頼に「何を・なぜ・根拠・影響範囲・承認しない場合」が載る
• [ ] 承認者と、その人が不在のときの代わりの人を決めた
• [ ] 差し戻しの理由を選択肢で記録できる
• [ ] 監査ログに必要な項目が残り、閲覧権限と保存期間を決めた
• [ ] 非常停止の手順を決め、一度試した

社内でこうした仕組みづくりを進める人材の育成を考えている場合は、AI研修おすすめ比較も参考になります。AIの社内ルール全体の作り方は、ビジネスで使う生成AI入門 第7回とあわせて読むと整理しやすくなります。

この回のまとめ

• 取り返しのつかない操作の前に人が確認する仕組みは、MCPの仕様やOWASPのリスク一覧などでも共通して求められている
• 確認の厚さは操作の重さで決める。読む＜下書き＜社内への書き込み（しきい値）＜社外送信・支払い・削除（必ず承認）
• 承認依頼には「何を・なぜ・根拠・影響範囲・承認しない場合」を載せる。承認が多すぎると承認疲れで形だけになる
• 差し戻しの理由を選択肢で記録・集計し、指示やマニュアルの改善につなげる
• 監査ログには、いつ・誰の依頼・AIの判断と根拠・道具と入力・結果・承認・指示の版を残し、非常停止の手順も用意する

確認テスト

次回予告

第7回は「セキュリティと権限」です。AIエージェントならではのリスクである「プロンプトインジェクション」（外部の文章に紛れ込んだ指示にだまされる攻撃）と、権限の与えすぎによる「やりすぎ」を防ぐ方法を、具体的な対策とともに学びます。

参考資料

• Model Context Protocol「Specification（2025-11-25）」Security and Trust & Safety https://modelcontextprotocol.io/specification/2025-11-25 （確認日：2026年11月12日）
• OWASP GenAI Security Project「LLM06:2025 Excessive Agency」 https://genai.owasp.org/llmrisk/llm062025-excessive-agency/ （確認日：2026年11月12日）
• Anthropic「Building effective agents」（2024年12月19日） https://www.anthropic.com/research/building-effective-agents （確認日：2026年11月12日）