AIエージェントの権限を広げる5工程｜承認を挟む運用の設計

「試しにAIエージェントを動かしてみたが、どこまで任せてよいのか社内で決まらない」「勝手に送信されたら困るという声が出て、そこから話が進んでいない」——導入の入口で足踏みしている会社は少なくありません。ここでつまずく理由は、AIの性能が足りないからではありません。任せる範囲と、人が承認する場所を、業務の流れの上に置いていないからです。この記事では、実際の業務の流れを追いながら、どこで人が挟まるのかを5工程で整理します。

「全部任せる」か「使わない」かで止まる

社内の議論は、たいてい二択になります。推進する側は「任せればこれだけ速くなる」と言い、慎重な側は「勝手に動いて顧客に迷惑がかかったらどうする」と言う。どちらも業務をひとつの塊として見ているので、主張が近づくことがありません。会議のたびに同じ心配が蒸し返され、半年たっても検証環境から出られない、という状態になります。

しかし実際の業務は、いくつもの工程でできています。ウェビナーの集客なら、対象の洗い出し、案内文の作成、配信先の絞り込み、送信、反応の集計、次の打ち手の判断。工程ごとに、間違えたときの取り返しやすさがまったく違います。送信してしまったメールは取り消せませんが、案内文の下書きは何度でも捨てて書き直せます。同じ「集客業務」という名前で呼んでいるだけで、中身の危うさは別物です。

だから決めるべきは「任せるか」ではなく、どの工程を、どの段階まで任せるかです。この粒度まで下ろすと、慎重な側も納得できる範囲が必ず見つかります。実際、反対している人が本当に止めたいのは業務全体ではなく、そのうちの1つか2つの工程であることがほとんどです。議論が動かないときは、たいてい話している単位が粗すぎるだけだと考えてよいでしょう。

まずウェビナー集客の1か月を工程に割る

具体的な業務で見ていきます。開催の1か月前から当日までに、担当者が実際に踏む工程を書き出すと、おおよそ次のようになります。ここでは工程の細かさをそろえることより、外に出る動作をひとつずつ独立させることを優先します。後で線を引くときに、この分け方が効いてきます。

1. 過去の参加者と休眠顧客の名簿を洗い出す
2. 今回の案内を送る対象を絞る条件を決める
3. 案内文と申込ページの文面を作る
4. 件名と配信の時間帯の案を複数出す
5. 条件に合う配信先の一覧を作る
6. 配信する
7. 開封数と申込数を集計する
8. 追加の案内を出すか、内容を変えるかを判断する

書き出してみると、性質の違いがはっきりします。洗い出し、案の作成、集計、要約は作業寄りの工程です。手を動かせば誰がやっても似た結果になり、間違えても作り直せます。一方、誰に送るか、何と言うか、追加で送るかどうかは判断寄りの工程です。その会社の事情や、相手との関係の履歴が入ってこないと決められません。この線が、ひとまずの目安になります。

ただし作業寄りに見えても、外に出るものは別扱いにします。6番目の「配信する」は、作業としては単純な操作ですが、一度出たものは取り消せず、届く相手も広い。工程表を作る目的は、この「性質が違う工程」を同じ箱に入れないことにあります。逆に、ここで一緒くたにしてしまうと、この後どれだけ丁寧に設計しても危ない工程が紛れ込んだまま進むことになります。

工程を仕分ける3つの軸

工程が並んだら、次は仕分けです。公開されている権限設計の考え方では、不可逆性（取り消せるか）、影響範囲（どこまで届くか）、機密度（何を扱うか）の3つを組み合わせて評価します。3つとも高い工程は自動で動かさない、というのが基本的な整理です。たとえばデータの削除は、この3軸すべてで最も高い区分に置かれます。

先ほどの集客業務に当てはめてみます。「議事録から過去に出た質問を拾う」は、やり直せて、届く先は自分だけで、扱うのは社内情報。3軸とも低いので、任せてよい工程です。「配信先の一覧を作る」は、作り直せはしますが対象が数千件になることもあり、顧客の連絡先という守るべき情報を扱います。影響範囲と機密度が上がるので、人の確認を挟む側に置きます。この2つを並べると、同じ「準備作業」でも扱いが変わる理由が伝わります。

この3軸は、社内を説得するときにも効きます。「なんとなく怖い」という反対意見に対して、「この工程は数分で戻せて、届く範囲は担当者ひとりです」と返せるからです。反対している理由が3軸のどれに当たるのかを聞くだけで、議論の中身が具体的になります。取り消せないことが心配なのか、顧客に届くことが心配なのか、情報の中身が心配なのかで、打つ手はまったく違います。反対の理由を3軸のどれかに置き換えられた時点で、話は設計の議論に変わります。

任せてよい工程と、人が握る工程

3軸で仕分けた結果を、実務の言葉に置き換えると次のようになります。任せる側に寄せられるのは、材料を集めて形にするところまで。人が握るのは、外に対して意味を持ってしまうところです。公開されている整理でも、文書の検索や読み取りは自動で回してよい区分、メールの送信や実行を伴う操作は事前の承認が必要な区分に置かれています。

工程の性質	具体例	扱い方
下調べ・収集	過去の質問の洗い出し、競合の公開情報の整理	任せてよい。出どころを併記させる
分類・要約	問い合わせの仕分け、議事録の要点整理	任せてよい。判断の言葉は入れさせない
案の作成	件名案、構成案、配信時間の案	任せてよい。採用は人が決める
書き込み・更新	管理表への転記、下書きの保存	任せてよいが、実行後に通知を出す
外に出る動作	送信、公開、申込ページの差し替え	人が承認して実行する
調子と文脈	ブランドの言い回し、時期への配慮	人が握る。任せない
最終の意思決定	誰に何をいくらで案内するか	人が握る。任せない

「調子と文脈」を人が握る理由は、AIの文章力が足りないからではありません。世の中の空気や、その時期に触れてはいけない話題は、社内の誰かの頭の中にある情報であって、文章の巧拙とは別の問題だからです。災害が起きた直後に明るい件名のメールを出してしまう類の事故は、文章の性能をいくら上げても防げません。防げるのは、その週に何が起きたかを知っている人の目だけです。

炎上のおそれがある表現の見極めも同じです。何が問題になるかは、その業界と時期の文脈で決まります。AIに文面の危うい箇所を洗い出させること自体は有効で、見落としを拾う用途では十分に働きます。ただし、出てきた指摘を採用するかどうかは人が決めますし、指摘がなかったことは、問題がないことの証明にはなりません。ここを取り違えると、確認したつもりだけが残ります。

任せる範囲を決める5工程

ここまでの整理を、実際に進める手順にまとめます。順番そのものが重要で、特に4番目を後回しにすると、後から足すのがほぼ不可能になります。先に走らせてから安全装置を付けようとすると、止めたときに中途半端に残る処理をどう扱うかが決まっておらず、結局は全体を落とすしかなくなるからです。

この5工程は一度きりの作業ではありません。5番目まで来たら1番目に戻り、工程の割り方そのものが正しかったかを見直します。実際に動かすと、想定していなかった工程が必ず出てきます。「案内文を作る前に、過去の類似回の結果を見に行っていた」といった暗黙の手順が、記録を眺めているうちに浮かび上がってくるためです。最初の工程表は仮のものだと割り切り、2周目で精度を上げるくらいの構えでちょうどよいでしょう。

第1工程：工程に割るときの粒度

最初のつまずきは、粒度が粗すぎることです。「案内メールの作成」でひとくくりにすると、下書きを作る工程と送信する工程が同じ扱いになり、せっかくの仕分けが機能しません。1つの工程は1つの成果物、または1つの外向きの動作まで割ります。細かすぎて困ることは、実務ではほとんど起きません。

並べ替えの基準は、取り消しやすさを時間で測ることです。数分で戻せる、半日あれば戻せる、戻せない、の3つに分けます。曖昧に「リスクが高い」と書くより、「戻すのに半日」と書くほうが、判断する人にとって具体的だからです。この「戻せない」に入った工程が、最後まで人が握り続ける前提の工程になります。顧客に届いたメール、公開した資料、外部に送った申込データが代表例です。

工程表そのものは表計算のシート1枚で足ります。ここで管理ツールを導入すると、ツールの設定作業が目的にすり替わり、肝心の線引きが進みません。列は、工程名、成果物、戻すのにかかる時間、届く範囲、扱う情報、の5つで十分です。最初の1枚は30分ほどで書き上げ、動かしながら直していくくらいのつもりで構いません。書けない列があったら、そこは業務そのものが言語化されていない箇所なので、先にその工程を担当している人に聞きに行きます。

第2工程：権限を3段階で広げる

権限は、いきなり自動にせず段階を踏みます。推奨だけは、AIが案を出すものの実行はせず、人が採用か却下かを決める段階。承認して実行は、AIが実行の直前まで用意し、人が押して初めて動く段階。条件付きで自動は、先に決めた条件の内側だけ人を通さずに動き、条件の外に出たら必ず承認に戻る段階です。3段階しかない代わりに、どの工程がどこにいるかを全員が言えるようになります。

公開されている設計例では、導入初期はすべての動作に承認を必須にし、しばらく経ってから定型の動作だけを自動承認に移し、さらに金額の上限のような明確な線を引いて自動の範囲を広げ、最後は記録だけを残す形にする、という広げ方が紹介されています。そこに書かれている期間はあくまで一例で、扱う金額や顧客との距離によって、適切な速さは変わります。

大事なのは、上げる条件を先に決めておくことです。「慣れてきたから」で上げてしまうと、判断した人が異動した瞬間に誰も理由を説明できなくなります。差し戻しが直近20件のうち1件以下なら次の段階へのように、自社で数えられる形にしておきます。条件を先に書いておけば、上げる判断そのものを会議で揉める必要がなくなります。数字が満たされたら上げる、それだけの話になるからです。反対に、条件を書かないまま進めると、段階を上げる提案が出るたびに最初の議論をやり直すことになります。

第3工程：承認する人が見る材料

承認を挟むと決めても、画面に結果だけが出てくるなら、承認は押すだけの作業になります。必要な材料は3つ。根拠（どの情報をもとにしたか）、確からしさ（どのくらい迷った判断か）、影響の範囲（何件に届くか、取り消せるか）です。監督の実装でも、点数だけでなく根拠や主要因を出力に含めることが挙げられています。

とくに根拠は外せません。答えだけでなく、参照した社内の資料や数字を併記させます。根拠を書けない出力は、承認する人の手元に判断材料がない状態であり、そのまま通せば承認の形をした素通りになります。根拠の欄が空なら差し戻す、という運用を最初に決めておくと、AI側の作りも自然と根拠を出す方向に寄っていきます。

承認そのものの記録も残します。誰が、いつ、どの材料を見て承認したか。これがないと、問題が起きたときにAIの出力が悪かったのか、承認する人に材料が届いていなかったのかを切り分けられません。切り分けられないと、対策が「以後気をつける」で終わり、同じことが繰り返されます。承認画面での修正内容も、あわせて残しておきます。

第4工程：止める仕組みと記録を先に作る

異常時に止められる仕組みは、後から足すのが極端に難しい部分です。動き始めてから「止め方を決めよう」となると、止めたときに中途半端に残る処理の扱いが決まっておらず、結局は全体を落とすしかなくなります。監督の設計でも、停止の手段を用意し、止めた後が安全な側に落ちるようにしておくことが柱のひとつに挙げられています。

用意しておくのは3つです。全体を止める手段、工程単位で止める手段、そして止めた瞬間の既定の動きです。送信待ちの列は破棄するのか保留にするのか、書きかけの下書きは残すのか消すのか。迷ったら実行しない側に倒すのが原則です。止める合図を出せる人も、担当者ひとりに限定しないでおきます。

記録は、AIの動作だけでなく人が上書きした内容も残します。人がどこを直したかが集まると、任せてよい範囲を見直すための一次資料になります。毎回同じ箇所を直しているなら、原因は指示の書き方か、工程の割り方にあります。見落としやすいのは、人が直した内容が、後続の工程にきちんと反映されているかの確認です。承認画面で直したのに、次の工程が元の案のまま動いていた、という抜けは実際に起こります。

第5工程：段階を上げる条件と、下げる条件

段階を上げる条件は、数字にします。「直近1か月で、承認画面での差し戻しが20件中1件以下」「顧客に届く内容の誤りが0件」といった、自社で数えられる形にしておくのが肝心です。数えられない条件は、結局その場の雰囲気で判断されます。工程ごとに条件を変えて構いませんし、外に出る工程だけ厳しくするのが自然です。

同時に、下げる条件も決めます。一度でも顧客に誤った情報が出た工程は、承認ありに戻す。ここで大事なのは、段階を下げることを担当者への罰にしないことです。罰として扱うと、小さな失敗が報告されなくなり、記録そのものが実態を映さなくなります。下げるのは仕組みの調整であって、人の評価ではないと最初に宣言しておきます。

見直す場も決めておきます。月に1回、記録を持ち寄って段階を動かす時間を取り、その場を回す担当者を1名決めます。全員の合議にすると誰も動かさなくなり、権限の段階が導入初期のまま何年も固定されます。止まったままの段階は、「安全側だから問題ない」ように見えて、実際には承認する人の時間を毎日削り続けている状態です。

承認が形だけになるとき

承認を挟んでも、内容を見ずに押すだけになれば効果はありません。AIの出力をそのまま受け入れてしまう傾向は自動化バイアスと呼ばれ、人による監督を設計するうえで注意すべき点として繰り返し挙げられています。承認欄があることと、監督が働いていることは別だという前提から始めます。

画面の作り方で防げる部分があります。選択の初期値を「承認」にしない、ひとつのボタンで通せる導線を作らない、根拠を開かないと承認できないようにする。指摘されている対策は、いずれもあえて手間をひとつ残すという方向です。効率化の途中で、この手間だけは削らないと決めておきます。画面を作る担当者に「押しやすくしてほしい」と伝えると、善意でこの手間が消えるので、残す理由まで含めて共有しておく必要があります。

承認の件数が多すぎるのも形骸化の原因です。1日に何十件も承認依頼が届くなら、それは段階の割り当てが粗いという合図で、数分で戻せる工程まで承認に回している可能性が高い。承認の対象を絞ると、1件あたりに使える時間が増え、本当に見るべき工程の中身を読めるようになります。件数を減らすことは、手を抜くことではありません。

実務仕様：期限・既定の動き・代理

運用に入る前に、細かいところを決めておきます。まず承認の期限です。期限内に承認されなかったときにどうするかを決めていないと、止まったまま誰も気づかない案件がたまり、「AIに任せたのに何も進んでいない」という評価につながります。既定は実行しない側に置き、期限が切れたら依頼者に差し戻す形にします。

次に代理承認です。担当者が不在のときに誰が承認できるのかを決めます。ただし「誰でも承認できる」にすると段階の意味が消えるので、代理を務める人を名前で指定しておきます。代理で承認した事実は記録に残す前提です。あわせて、エージェントに与えた権限と、操作する人自身の権限のどちらが優先されるかも決めておきます。

最後に通知の宛先です。個人宛だけにすると、休みや会議で止まります。チームで見える場所に流し、誰が拾ったかを残す形にします。承認の場所を、普段使っているチャットの中に可否のボタン付きで流すか、優先度で絞り込める専用の一覧画面にするかは、承認の件数で決めるとよいでしょう。件数が少ないうちはチャット、増えてきたら一覧画面のほうが見落としが減ります。承認は、探しに行く場所ではなく、目に入る場所に置くのが原則です。

• 承認の既定は「実行しない」。期限切れは自動実行ではなく差し戻しにする
• 代理承認は名前で指定し、代理で承認した事実を記録に残す
• 顧客の個人情報を扱う工程は、社内規程と関係する法令に沿って扱う
• 外部のサービスに業務データを渡す場合は、契約と社内の承認を先に取る

ミニ用語解説

社内で話を進めるとき、言葉の定義がずれていると議論が空回りします。とくに「監督」と「承認」は同じ意味で使われがちで、そのせいで実現できない運用を目指してしまうことがあります。この記事で使ってきた言葉を、短く並べておきます。社内の資料に貼って、定義をそろえるところから始めても構いません。

言葉	意味	設計での使いどころ
不可逆性	実行した後に取り消せるかどうか	工程を並べ替える最初の軸にする
影響範囲	その動作がどこまで届くか	承認を挟むかどうかの判断に使う
人による監督	人が監視し、必要なときに介入・停止できる状態	全件承認とは別物として扱う
自動化バイアス	AIの出力を無批判に受け入れてしまう傾向	承認画面の作り方で対策する
監査ログ	誰が何をいつ実行し、誰が承認したかの記録	原因の切り分けと段階の見直しに使う

「人による監督」を「全件を人が承認すること」と読み替えてしまうと、承認の件数が現実的でなくなり、結局は全員が中身を見ずに押す運用に落ちます。監督は、見えていること、介入できること、止められることの3点で成り立ちます。この3点が満たされていれば、すべての動作に承認欄を置かなくても、監督している状態は作れます。

制度の側から見た「人による監督」

自社のルールを作るとき、公的な整理を下敷きにすると社内の合意が取りやすくなります。自社だけで決めた基準は「厳しすぎる」「緩すぎる」の水掛け論になりますが、公的な整理を引けば、議論の出発点をそろえられます。国内では、総務省と経済産業省がAI事業者ガイドラインを公表しており、第1.1版が2025年3月28日に出ています。AIの提供や運営は、技術的な作り込みだけでなく、人によるモニタリングなどの取り組みと連携した形で行うことが求められる、という考え方が示されています。指針の詳細は改訂されていくため、最新版を公式の公表資料で確かめてください。

欧州のAI法では、高リスクに区分される用途について人による監督が定められています。附属書に定める高リスクの区分に関する条項は、導入する側に対して2026年8月2日から適用されるとされ、義務に違反した場合の制裁金には、1,500万ユーロと全世界の年間売上高の3%のうち高いほうを上限とする区分があります。生体情報を使った識別のように、2人の承認を必須とする用途が個別に定められているものもあります。

ここで押さえておきたいのは、条文が求めているのが全件を人が承認することではないという点です。求められているのは、挙動が見えること、承認や却下や修正で介入できること、安全に停止できること、そして介入の記録が残ること。日本国内のマーケ業務の多くは高リスクの区分には当たりませんが、欧州向けに製品やサービスを出す場合は話が別です。適用範囲も金額も見直されうるため、自社が対象になるかどうかは公式の条文と公表資料で確かめてください。

設計前のチェックリスト

最初の設計に入る前に、次の項目が埋まっているかを確かめます。埋まらない項目があるなら、そこが議論の残っている場所です。全部を埋めてから始める必要はありませんが、埋まっていないことを自覚したうえで動かすのと、気づかずに動かすのとでは、事故が起きたときの回復の速さが変わります。

• 対象の業務を工程に割り、それぞれ何分で戻せるかを書いたか
• 戻せない工程を洗い出し、人が握ると決めたか
• 工程ごとに、推奨だけ・承認して実行・条件付きで自動のどれかを割り当てたか
• 承認画面に、根拠と確からしさと影響範囲を出す設計になっているか
• 止める合図を出せる人と、止めた瞬間の既定の動きを決めたか
• 人が上書きした内容まで記録に残り、後続の工程に反映される形になっているか
• 段階を上げる条件と下げる条件を、数字で書いたか
• 月に1回見直す場と、その場を回す担当者を決めたか

この8項目のうち、抜けやすいのは5番目と7番目です。止め方と、段階を動かす条件。どちらも動かす前は必要性を感じにくく、必要になったときにはもう手遅れになっている項目です。逆にいえば、この2つが書いてあるだけで、運用の質はかなり違ってきます。書けない項目があるなら、それは決めていないという事実の記録なので、空欄のまま残し、いつ誰が決めるかだけを添えておくと後で拾えます。

よくある失敗

実際に相談を受ける中で、繰り返し見かける進め方を挙げておきます。どれも悪意なく、むしろ慎重に進めようとした結果として起きています。慎重さの向け先が、工程の線引きではなく「使わせない」ほうに向いてしまうと、次のような形になります。

• 業務まるごとで可否を決める：工程に割らないため、危ない工程1つのせいで全部が止まる
• 承認欄だけ作って材料を出さない：根拠が見えず、押すだけの承認になる
• 止め方を後回しにする：異常時に全体を落とすしかなくなり、業務ごと停止する
• 成果が出た工程から順に自動化する：取り消せるかを見ずに広げ、外に出る工程まで自動になる
• 段階を下げることを担当者の失点にする：小さな失敗が報告されなくなり、記録が使えなくなる

裏返すと、うまく進んでいる会社の共通点は単純です。工程表があり、承認の材料が決まっていて、止め方が書いてある。この3つがそろっていれば、どの工程から任せ始めても大きくは崩れません。逆に、この3つがないまま範囲だけ広げていくと、一度の事故で全部を止める判断に追い込まれます。

まとめ

AIに任せる範囲を決めるうえでの要点は、業務ではなく工程で線を引き、承認を挟む場所を業務の流れの上に置くことです。取り消しやすさで工程を並べ、推奨だけから始めて、条件を満たした工程だけ段階を上げる。止める仕組みと記録は、任せ始める前に組み込む。調子や文脈の見極め、最終の意思決定は人が握り続ける。まずは自社の業務をひとつ選び、工程に割って、戻せない工程がどこにあるかを書き出すところから始めてみてください。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。