AIエージェントの承認フロー（Human-in-the-Loop）｜承認を増やさずに安全にする3つの型と、承認者不在時の既定動作

この記事は、AIエージェントに何らかの操作を任せるにあたり、人の確認をどこに何回入れるかを決めたい中小企業のAI推進担当と管理部門に向けたものです。この領域の解説記事は質が高く、リスク階層表や金額別の承認レベル表といった具体的な道具がすでに公開されました。ただしそのほとんどが、承認者が複数いること、専任の運用担当が承認画面を日常的に見ること、そして自社でエージェントを開発できることを前提にしています。

人の確認をどこに何回入れるかを決める設計は、Human-in-the-Loop（HITL）と呼ばれます。関与の度合いは、ループの内側で都度承認する形、外側から監視だけを行う形、関与せず事後に監査する形の3つに呼び分けられ、この記事で扱う3つの型もいずれかに当たります。

この記事では、承認できる人が社長1人しかいない会社を前提に、承認の型と不在時の扱いを扱います。開発フレームワークの比較は扱いません。

結論

承認フローの設計は、承認を増やす作業ではありません。実行前承認・実行後確認・例外時エスカレーションの3つに分け、実行前承認を取り消せない操作だけに絞る。しきい値は既存の稟議規程から持ってくる。ここまでで大半は決まります。そして承認者が1人しかいないなら、不在時の既定動作を先に決めます。決めていないと、現場が独自の回避策を作ります。

承認を増やすほど危険になる

安全にしたいという動機から、承認箇所を増やしたくなります。しかし承認は増やすほど形骸化します。件数が増えると、内容を読まずに承認するようになります。承認待ちが業務を止めるため、現場が承認の要らない使い方へ回避する。全部に承認があると、本当に重要な1件が他の99件に埋もれます。

形骸化した承認は、承認がない状態より悪くなります。「確認した」という記録だけが残り、実際には誰も見ていない状態になるためです。責任の所在が曖昧になります。したがって設計の目標は、承認を増やすことではなく、承認件数を減らしたうえで残った件を確実に見ることです。

承認件数を減らす3つの置き方

実行前に承認する／実行後に確認する、という分け方そのものは新しいものではありません。この記事の主張は、実行前承認を取り消せない操作だけに絞り、残りを3番目の置き方へ寄せることです。分類することが目的ではなく、承認の件数を減らすことが目的です。

型	内容	対象にする操作	業務の例	人の負担
実行前承認	人が承認するまで実行しない	取り消せない操作、社外へ影響する操作	新規取引先への発注、社外への請求書送付	高い
実行後確認	実行はする。人が後から確認する	取り消せる操作、社内にとどまる操作	社内の日報要約、社内向け資料の下書き	低い
例外時エスカレーション	通常は自動。条件に当たった時だけ人へ回す	件数が多く、まれに例外がある操作	定型の見積作成、問い合わせの一次返信	非常に低い

多くの業務は3番目で十分です。「金額が一定を超えたら」「宛先が社外なら」「過去に例のない相手なら」という条件を1つ決めるだけで、承認件数は大きく減ります。

どの操作にどの型を置くか

判定は「元に戻せるか」と「影響が社外に及ぶか」の2つで決まります。この振り分け自体は権限を決める作業なので、AIエージェントの権限設計で扱っています。操作ごとの対応表はそちらにあります。

ここで押さえておくのは1点です。戻せず、かつ社外に及ぶ操作は、承認を置いても任せません。承認する人が内容を十分に確認できない量が流れてくれば、承認は形式になります。この場合は人が自分で実行します。

しきい値は既存の稟議規程から持ってくる

「いくら以上を承認対象にするか」を新しく決める必要はありません。多くの会社には、すでに決裁や稟議の金額ラインがあります。そのラインをそのまま流用します。理由は3つあります。社内で説明する必要がありません。既に合意された基準だからです。人が実行する場合とAIが実行する場合で基準が食い違わない。根拠を聞かれたときに答えられます。

解説記事に載っている金額表は、その会社の規模を前提にした例です。自社の決裁ラインと合わないまま採用すると、実態に対して厳しすぎるか、緩すぎるかのどちらかになります。金額以外の条件も、既存の運用から持ってこられます。「新規取引先への発注は誰の確認が要るか」「社外文書の発信は誰が最終確認するか」。すでに決まっているはずです。

金額の階層そのものを、この記事では断定しません。解説記事が示す1万円・10万円・100万円といった階層はいずれも出典の表記がなく、各社の運用上の目安であって公的な基準ではないためです。公表されている具体的な金額としては、後述するCopilot Studio の条件分岐の例に出てくる5,000ドルがありますが、これは製品ドキュメントが設定方法を説明するために置いた値で、市場の相場ではありません。自社の決裁ラインという、すでに社内で合意された数字のほうが根拠として強くなります。

承認者が1人しかいない会社の設計

解説記事には「100万円以上は複数人承認」といった記述がありますが、承認できる人が社長1人という会社では成立しません。後述する「製品の承認機能で、どこまでできるか」で触れる既知の制限、つまり同じ承認者を異なるステージへ割り当てられないという記載が、それを製品の側から裏づけています。承認者が1人の会社では、運用を工夫する以前に、多段階の承認を機能として構成できません。複数人にできない前提で組みます。

承認者を増やせないなら、対象を減らす

人を増やせない以上、1人が見られる件数まで対象を絞るしかありません。目安として、1日に承認する件数が5件を超えたら設計を見直します。件数が増えるほど、承認は内容を読まずに通す作業へ変わっていきます。

実行前承認の対象を、取り消せない操作だけに限定します。件数の多い操作は例外時エスカレーションへ移す。それでも多い場合は、そもそもAIに任せる範囲を狭めます。

代理を1名決める

承認者が1人でも、代理は決められます。役職は問いません。「社長が終日不在のとき、この人が判断する」を1名決め、その人が判断できる範囲（金額の上限など）も決めます。代理が判断できない範囲については、次章の既定動作に従います。

承認者が不在のときの既定動作

この設計が抜けていると、現場は必ず承認を回避する運用を編み出します。出張中、深夜、休日に何が起きるかを先に決めます。選択肢は3つです。

既定動作	内容	向いている操作	副作用
保留	承認されるまで実行せず待つ	急がない操作	処理が溜まる
条件付き自動実行	限度額や条件の範囲内なら実行し、後で報告	件数が多く、影響が小さい操作	限度額の設定を誤ると事故になる
自動却下	承認がなければ実行せず、破棄する	再実行が容易な操作	取りこぼしが出る

操作ごとにどれを既定にするかを決め、文書にします。決めていない状態が最も危険です。実装によっては、承認待ちのまま無期限に動き続けるものもあります。

あわせて保留が溜まったときの上限も決めます。「保留が10件を超えたら、その業務は一旦止める」といった上限がないと、休み明けに大量の承認待ちを一気に処理することになり、そこで形骸化します。

承認の仕組みをどう用意するか

解説記事の多くは、開発フレームワークに承認処理を実装する前提で書かれています。SaaSを購入して使う側の会社には、そもそも実装するという選択肢がありません。用意できる手段は次の3つです。

手段	内容	確認しておくこと
製品の標準機能	実行前に承認を挟む設定が製品側にあるか	対象操作を選べるか。既定で有効か
権限で代替する	承認が必要な操作をそもそも実行できない権限にする	人が手動で実行する運用に切り替えられるか
業務手順で代替する	AIは下書きまで、実行は人が行うと決める	手順書に書き、抜け道がないか

製品に承認機能がない場合、無理に作る必要はありません。2番目の「権限で代替する」が最も確実です。実行できない権限にしておけば、承認の運用そのものが不要になります。

3番目は最も手軽ですが、手順を守るかどうかが人に依存します。急いでいるときに省略されやすいため、影響の大きい操作には使いません。

製品の承認機能で、どこまでできるか

1番目の「製品の標準機能」がどこまで届くかは、製品の公式ドキュメントを読むと分かります。Microsoft Copilot Studio のエージェント フローでは、人が承認する手動承認ステージ、AIが判定するAI承認ステージ、そして条件を組み合わせたマルチステージ承認を構成できます。条件分岐の公式な例としては、費用額が5,000ドルを超える場合はマネージャーの承認まで進み、5,000ドル未満でAI段階が承認した場合はマネージャーの承認を経ずに自動的に承認されたまま終了する、という組み方が示されています（Microsoft Copilot Studio ドキュメント　2026年9月5日確認）。

ただし同じドキュメントには、これらの機能はすべてプレビュー段階であり、プレビュー機能は運用環境での使用を想定しておらず機能が制限される可能性がある、と明記されています。将来こう組める、という検討材料にはなりますが、いま業務の本番で使える前提の機能としては数えないでください。

既知の制限として、同じ承認者を異なるステージに割り当てることはできないと記載されています。設定手順の側にも、同じ承認者を複数の段階へ割り当てるとフローが失敗する、という注記も付きます。承認できる人が1人しかいない会社は、この時点で多段階の承認を製品の機能としては組めない、ということになります。

承認による遅延も費用として数える

承認を挟むと処理が遅くなります。この遅延は費用です。判断に含めます。

承認を待つあいだ、後続の業務が止まる時間。承認する人が確認に使う時間。1件あたり数分でも、件数を掛けると効いてきます。承認漏れを追いかける連絡の手間もあります。

この3つを足した時間が、AIによる削減時間を上回っていないかを確認します。上回っているなら、承認を減らすか、その業務を任せないかのどちらかです。承認を維持したまま導入を続ける理由はありません。

惰性承認を防ぐ

承認件数を絞っても、同じ内容が続くと読まずに承認するようになります。AI事業者ガイドライン（第1.2版）は、人間の判断や意思決定において、自動化されたシステムや技術への過度の信頼や依存が生じる現象を自動化バイアスと定義しています。同ガイドラインは対策として、AIの評価や判断等を人間が承認する際には、人間自身が承認する理由や根拠を独自に考えてから承認すべきである、という提案を紹介します。次に挙げる「承認画面に必ず表示する3項目」は、承認する理由を承認者が自分で組み立てられるようにするための、この対策そのものです。もう1つの月1回の見直しと合わせ、次の2つで抑えます。

1｜承認画面に必ず表示する3項目

何に対して実行するか。宛先、対象データ、金額です。なぜ承認が必要になったか。どの条件に当たったかを示します。承認しなかった場合にどうなるかも書きます。

2番目があると、判断が速くなります。「金額が上限を超えたため」なのか「新規の宛先のため」なのかで、見るべき箇所が変わるためです。

2｜月1回、承認済みの数件を見直す

承認した内容から数件を無作為に選び、後から見直します。10分で終わります。読まずに承認していれば、この見直しで気付きます。気付いたら、承認対象が多すぎるということです。

承認の記録

承認したこと自体を記録します。問題が起きたときに「なぜ承認したか」を説明できる必要があります。記録するのは4項目です。

いつ、誰が承認したか。何に対する承認か、つまり対象と金額。どの条件で承認対象になったか。却下した場合は、その理由を1行でよいので残します。

却下の記録が最も価値を持ちます。却下が続いている条件があれば、その操作はそもそもAIに任せるべきでない、という判断材料になります。

国内法の義務ではありませんが、設計の参照点としてEU AI Act第14条を挙げておきます。同条は高リスクAIについて、システムの出力を無視し、上書きし、あるいは取り消す能力と、停止ボタンなどの手段で動作に介入し中断する能力を、人が持てるように設計し運用することを求めています。承認の記録に、通した事実だけでなく却下と取り消しを残すのは、この「通さない」「戻す」という判断が実際に行われたことを後から示せるようにするためです。適用の時期については一次資料で確認できなかったため、ここでは触れません。

承認を通した処理が、想定と違う動きをすることがあります。動いているものを誰がどう止めるかはAIエージェントの止め方｜いま動いている処理を、誰が、どうやって止めるかで扱っています。

承認をどこに置くかは、責任の範囲から決まる

令和8年版情報通信白書は、AIの適用領域を検討・設計する際には、企業価値や競争力を最大化することにどれだけ寄与するかといった評価に加えて、人間が負うべき責任の範囲といったガバナンスの観点、またAIの技術的な特性も踏まえて総合的に検討することが求められる、と記載しています。

承認の置き場所は、作業の速さではなく責任の所在しだいです。誰が責任を負う操作なのかが決まっていれば、承認を置く場所は自動的に決まります。逆に責任が曖昧なまま承認だけを増やすと、確認する人が増えて速度だけが落ちます。

出典

• 総務省「令和8年版 情報通信白書」第Ⅰ部 AI導入・活用を効果的に進めていくために重要となる要素　2026年9月2日確認
• 総務省・経済産業省「AI事業者ガイドライン（第1.2版）」令和8年3月31日　PDF　2026年9月5日確認
• Microsoft「エージェント フローでのマルチステージと AI の承認」（Microsoft Copilot Studio ドキュメント）　2026年9月5日確認
• 欧州連合「Regulation (EU) 2024/1689（EU AI Act）」第14条　2026年9月5日確認

よくあるご質問

承認そのものを自動化してもよいですか

条件付きで可能です。金額や対象が明確に区切れて、逸脱を後から検出できる範囲に限ります。自動承認にする場合も、何を自動承認したかの記録は残します。記録がないと、問題が起きたときに範囲を特定できません。

承認の記録はどのくらい残すべきですか

自社の他の稟議記録と同じ期間に揃えるのが実務的です。AIの承認記録だけ別の期間にすると運用が続きません。取引先との契約で保存期間が定められている業務では、そちらが優先されます。

承認者を外部の委託先に任せられますか

業務内容の妥当性を判断する承認は社内に残します。外部に任せられるのは、技術的な設定変更の確認や、動作の検証です。判断の責任は委託できないため、外部の確認を受けたうえで社内の誰かが承認する形になります。

AIに一次承認をさせて、人が最終承認する形にしてよいですか

AIが一次承認を行う仕組みは、Microsoft Copilot Studio のAI承認ステージとして実在します。ただし同じドキュメントは、金融取引、法的判断、人事措置、コンプライアンス上重要なプロセスなど機密性の高い承認については、フローの中で人間の承認段階に到達させ、重要な決定を最終的に人間が管理できるようにするよう記載しています。指示の書き方にも注意が要り、承認基準か拒否基準のいずれか一方に注目し、どちらも書くことは避けるように、と公式の注意があります。500ドル未満は承認、300ドル超は却下という矛盾した指示のもとで400ドルの経費を通すと、AIが「分析に失敗しました」を返す失敗例が図付きで示されています。

承認が回っているかは何を見れば分かりますか

見る数字は3つです。1日あたりの承認件数、承認から実行までの所要時間、そして却下率です。件数が増え続けていれば承認の対象が広すぎ、所要時間が延び続けていれば承認者のところで詰まっています。却下率が0のまま続く場合は、承認の対象が広すぎて実質すべて通しているか、読まずに通しているかのどちらかです。却下率は、承認の記録に残す却下の理由から数えられます。

どの業務にどこまで任せてよいかはAIエージェントに任せてよい業務・任せてはいけない業務、承認工数を運用負担として費用へ算入する方法はAI導入の費用対効果をどう測る？で扱っています。

手順のどこで詰まるかは会社ごとに違います。お問い合わせから、現在の状況をお知らせください。