本文へスキップ
AI Advance株式会社
AIエージェント AI Advance
公開日: AIエージェントAI導入

AIエージェントの権限設計|業務停止を防ぐ発注前の⁠要⁠点

執筆: 今村 龍太郎(取締役COO・AIエンジニ⁠ア⁠)

AIエージェントの権限設計とは、AIにどの操作までを自分の判断で実行させ、どこから先を人間の承認が必要な操作にするかを、業務ごとに線引きしておくことです。導入で心配される事故のほとんどは、この線引きを発注の段階で決めておけば防げま⁠す⁠。

「AIに任せて、間違ったことをされたらどうするのか」。AIエージェントの構築を検討し始めた経営者の方から、必ず出る質問です。構築を請ける側から言えば、これは正しい心配です。ただ、心配する場所が少しずれていることが多い。この記事では、当社が提案の場で実際に説明している3つのこと、つまり業務が止まる経路、権限の分け方、発注前に開発会社へ確認する項目を、発注する側が使える形で書きます。扱うのは「発注するときに何を確認すればいいか」だけで、設定手順や技術的な仕組みには触れませ⁠ん⁠。

なお、AIエージェントそのもの(チャットAIとの違いや仕組み、エージェントの型)は「AIエージェントとは何か」に譲ります。ここでは「目標を与えると、完了まで自分で仕事を進めるAI」とだけ押さえて先に進みま⁠す⁠。

AIエージェントのリスクの正体——「間違える」ではなく「間違えたまま実行でき⁠る⁠」

AIエージェント導入の最大のリスクは、AIが間違った答えを出すことではありません。間違った判断を、止める人がいないまま実行できる権限を持つことです。AIが間違えることは、前提として設計します。設計で消せるのは、間違いが業務に到達するまでの経路のほうで⁠す⁠。

先に語の範囲を決めておきます。この記事でいう権限は、AIにどの情報を見せるか(誰が何を閲覧できるか)ではなく、AIが自分の判断でどの操作までを実行してよいかの範囲です。社内情報の見せ方の設計とは、別の話として読んでくださ⁠い⁠。

チャットAIとの違いは、この一点に集約できます。ChatGPTのようなチャットAIに間違った回答をされても、業務は壊れません。人が画面を読んで、使うかどうかを決めるからです。チャットAIの安全性は、人間の確認が構造上どうしても挟まるところから来ています。AIエージェントは、この確認を挟まずにシステムを操作できます。だから速い。同じ理由で、間違いもそのまま実行されま⁠す⁠。

この前提は、AIを提供する側の規約にも書かれています。主要なAIモデル提供各社の法人向け利用規約は、出力が不正確・不完全な場合があることを明記し、その出力が自社の用途に適しているかを確認する責任は利用者側にあると定めています(たとえばAnthropicの商用利用規約は、出力の正確性・完全性を保証しないと定めるとともに、出力に含まれる事実の記述は独立して正確性を確認せずに依拠すべきではない旨を利用者に周知する責任を顧客に課しています)。主要な各社に共通するのは、検証は使う側の仕事という建付けです。ならば、その検証を人の気合いではなく仕組みとして業務に組み込むしかない。それが権限設計で⁠す⁠。

業務が止まる典型的な経路——「修正のため一回ドロップしましょ⁠う⁠」

業務が止まるのは、たいてい進め方が速すぎたときです。AIの性能不足が原因ではありません。要件定義から実装までAIが一気に進み、テストと設計が薄いまま本番で動き始めたときが、いちばん危な⁠い⁠。

当社では、次の4段階を「危険なシナリオ」として社内で共有しています。長年システム開発に携わってきた当社の経営メンバーが、経験から示した想定経路です。実際に起きた事故の記録ではありません。逆に言えば、こうなることが分かっているから提案段階で潰していま⁠す⁠。

  1. AIが要件定義から実装まで一気に進む。数日で動くものが出てくるため、関係者の期待も一気に上がりま⁠す⁠。
  2. テストと設計が薄いまま本番で動き始める。急いだ分だけ、確かめていない挙動が残りま⁠す⁠。
  3. 不具合が出たとき、AIが「修正のため一回ドロップしましょう」と判断する。ドロップとは、動いているものを一度壊して作り直すことで⁠す⁠。
  4. 元の状態に戻せず、業務が止ま⁠る⁠。
業務が止まる典型的な経路 1 要件定義〜実装を AIが一気に進む 速さが先行 2 テスト・設計が薄い まま本番稼働 検証不足 3 AIが作り直し (ドロップ)を判断 破壊的な判断 4 元に戻せず 業務停止 復旧不能
図1 業務が止まる典型的な経路(当社が社内で共有している想定シナリオ。実際に起きた事故の記録ではありませ⁠ん⁠)

3番目が、この経路の急所です。まだ誰も使っていない新しいシステムなら、作り直しは有効な選択肢です。ところが、すでに毎日の受注や請求が乗っている既存システムでは、データを全部捨てて作り直すことが事実上できません。稼働中のシステムは、動かしながら直すしかない——これが新規開発と既存業務への組み込みを分ける、いちばん大きな難度差です。作り直しという最短の解決策が使えない前提でどう直すかを決めておかないまま、作り直せる速さでシステムを作ってしまうのが、この経路の怖さで⁠す⁠。

だから当社は、既存の稼働システムにAIエージェントを組み込む提案では、後述する3点(免責・業務停止リスク・リカバリ範囲)を提案段階で必ず明示します。速く作れることと、業務を止めずに作れることは、別のコストがかかる別の話だからで⁠す⁠。

対策の原則は権限分離——破壊的な操作の前に人間の承認を⁠挟⁠む

対策の原則はひとつです。読む・下書きするまではAIに任せ、削除・更新・送信といった取り返しのつかない操作の前には、必ず人間の承認を挟みます。これを権限分離と呼びます。当社では、この分離を最初から標準の設計に入れていま⁠す⁠。

任せる範囲は、次の4段階で考えると発注側でも判断できま⁠す⁠。

権限レベルAIに任せる操作の例人間の関与
レベル1 読む資料を探す・集計する・要約する承認不要(結果を使うとき人が見る)
レベル2 下書きする返信文・見積の下書き・レポート案を作る送る前に人が確認して送信
レベル3 実行する予約確定・データ登録・定型の送信範囲を限定して自動。定期的に人が点検
レベル4 変える・消すデータの更新・削除・システム変更実行前に必ず人間の承認(デフォルトで自動化しない)

大事なのは量感です。日々の業務のほとんどはレベル1とレベル2に入ります。調べる、集計する、下書きする。ここは素通しでよく、承認を求める必要がありません。承認を挟むのは、間違えたときに元へ戻せないレベル4だけです。「全部に承認が必要なら自動化の意味がない」という心配は、承認の対象を絞れば解けま⁠す⁠。

そのうえで、この線引きには正解がないことも書いておきます。人間の承認を間に挟めば、そこが処理の詰まりどころ(ボトルネック)になります。逆に外せば、誰も途中を見ていない状態、つまりブラックボックスになります。当社の経営メンバーは、この二択を設計上の判断だと捉えています。どちらかが常に正しいのではなく、業務ごとに「止まる痛み」と「見えない怖さ」のどちらが大きいかを見て置き場所を決める。発注のときに「どの操作に承認を置きましたか、なぜそこですか」と聞けば、その判断をどう置いたのかが分かりま⁠す⁠。

権限は「役割」から導く——新人に任せる範囲と同じ考⁠え⁠方

どこまで権限を渡すかは、技術の問題ではなく役割の問題です。新人を一人採用したとき、初日から会社の実印は預けないはずです。AIエージェントもそれと同じで、役割が決まらないうちは権限も決められません

役割そのものの決め方は「AIエージェントとは何か」に譲ります。AIを道具ではなく担当者として迎えると、何を任せたいかが言葉になる、という話です。ここで扱うのは、その次の一手だけです。決まった役割に、表1のどのレベルまでを渡す⁠か⁠。

たとえば「見積の下書きを作る役割」なら、社内の過去案件を読む(レベル1)と下書きを作る(レベル2)で足ります。顧客台帳を書き換える権限は、この役割の外です。ここで「台帳の更新までやってほしい」と欲が出た瞬間に、話はレベル4に移り、承認をどこに置くかを決める設計の問題になります。役割を一段広げるたびに、権限も一段上がっていないかを確かめる——実務ではこの順番で見ていきま⁠す⁠。

期間の考え方も採用と同じです。最初は下書きまで(レベル2)に留め、数週間から数ヶ月の実績を見てから実行(レベル3)まで広げる。試用期間の置き方を含めて、役割を決めてから実際に社内で立ち上げるまでの手順は「AI社員の作り方|中小企業が会社として導入する手順」に5ステップで整理しているので、そちらをご覧くださ⁠い⁠。

なお、任せたい仕事が「今はベテランの頭の中にしかない」場合は、権限設計の前に手順を言葉にする作業が入ります。この順序の話は「属人化の解消はAIで変わる|仕組みで回る会社の作り方」と「技能伝承×AI|中小企業の現実的な進め方と費用」に譲りま⁠す⁠。

発注前に確認する3点セット——免責・業務停止リスク・リカバリ⁠範⁠囲

発注前に開発会社へ確認することは3つです。①免責事項(AIの処理結果をどこまで保証するか)②業務停止リスク(止まる可能性と、止まったときの影響範囲)③リカバリ範囲(どこまで戻して、どれだけの時間で再開できるか)。当社は既存の稼働システムへ組み込む提案では、この3点を提案段階で必ず明示します。聞かれてから答える項目ではなく、提案書に書いておく項目だと考えていま⁠す⁠。

この3点には、費用の記事でも一度触れています(「AIエージェント導入の費用相場と進め方」の「見積・提案の見極め方——誠実な開発会社は『リスク』を先に話す」)。そちらは提案書の読み方としての紹介でした。ここでは同じ3点を、発注前にそのまま口に出せる質問文まで開きま⁠す⁠。

  • 免責事項——「AIが生成した処理の結果は、どこまで保証してもらえますか。保証の外になるのはどの部分です⁠か⁠」
  • 業務停止リスク——「この仕組みが止まったとき、業務のどこまでが影響を受けますか。手作業で回せる期間はあります⁠か⁠」
  • リカバリ範囲——「この仕組みが止まったとき、何時間で・どの状態まで戻せます⁠か⁠」

答える側はどう答えるのか。参考に、当社が提案の場で実際に伝えている説明の型を書いておきま⁠す⁠。

「AIで速く作れる部分はありますが、お客様の業務を止めないように作るのは別物のコストがかかります。○○までは保証しますが、AIが生成したロジックの動作は保証外とさせていただきます。万一止まった場合は△△まで戻して再開する想定で⁠す⁠」

当社はこの趣旨を、聞かれる前に提案書へ書くようにしています。保証する範囲と保証外になる範囲を先に文字にしておかないと、稼働後に認識が食い違ってお互いに損をするからで⁠す⁠。

3つのうち、答えの質がいちばん分かれるのは③のリカバリ範囲です。ここは経験の量がそのまま出ます。システム開発を長く経験してきた技術者は、「どこで破綻したらどこまで戻ればいいか」を経験的に判断できます。そしてこの判断は、動くものを速く作る力とは別の能力です。だから当社は、長年システム開発に携わってきた者による破綻パターンの最終チェックを工程の中に組み込んでいます。若手だけでAI開発を完結させる体制はとりませ⁠ん⁠。

見積そのものの読み方(初期費用と運用費の2階建て・隠れコスト)も同記事にまとめています。開発会社のタイプ分けや選定プロセス全般は「AIエージェント開発会社の選び方|費用と見極めの要点」へ。この記事は、その選定の中の「リスクと権限をどう確認するか」という一点を深掘りしたもので⁠す⁠。

全自動にしない範囲を決める——判断はAIに渡さ⁠な⁠い

権限設計の最後は、AIに渡さない領域を決めることです。定型業務はAIに任せ、経営判断の舵取りは人間に残します。これは技術的にできないからではなく、渡すべきでないから残す、という決め方で⁠す⁠。

「全部AIにやらせてほしい」というご相談には、当社は必ずこの問いを添えています。「競合も同じAIを入れたら、御社に残る強みは何ですか」。同じ道具は誰でも買えます。何を仕入れるか、どの客に注力するか、いくらで売るか。その判断は、会社ごとに違う情報と責任の上に成り立っています。判断まで自動化してしまうと、速くはなりますが、他社との違いが残りませ⁠ん⁠。

目的の置き方も、ここで確認しておきたいところです。当社が提案するのは、今の人数でできることを増やす方向です。調べる・集計する・下書きするという時間のかかる作業をAIに寄せて、人は判断と顧客との対話に時間を使う。この配分なら、レベル4の操作を無条件でAIに渡す必要は、ほとんど出てきませ⁠ん⁠。

よくある⁠質⁠問

Q. AIエージェントが起こした損害は、誰の責任になりますか。 最終的には契約の免責事項でどう定めたかによって決まります。だからこそ、発注前に免責・業務停止リスク・リカバリ範囲の3点を確認し、提案書と契約書に書き残しておくことが実務上の備えになります。損害賠償や責任範囲の条項をどう書くかは法律の判断が入りますので、具体的な文言は顧問弁護士にご確認ください。当社としては、保証する範囲と保証外になる範囲を提案段階で明示する形をとっていま⁠す⁠。

Q. 承認を挟むと、自動化の効果が減りませんか。 効果を決めるのは承認の有無ではなく、承認の回数と、承認待ちで止まる時間です。同じ操作でも、1件ごとに実行前の承認を求める形と、AIが実行して結果を翌朝まとめて点検する形では、現場の負担がまるで違います。前者は件数が増えるほど人の手間も増え、後者は件数が増えても点検の手間はさほど増えません。発注のときに「承認が必要な操作は1日あたり何件くらい出ますか」「承認する担当者が不在の日、その処理はどうなりますか(待ち続けるのか、期限を切って止まるのか)」まで詰めておくと、動かし始めてから詰まりませ⁠ん⁠。

Q. SaaSに付いているAI機能でも、権限設計は必要ですか。 必要です。自社で構築する場合と違い、承認をどこに置くかは製品の設定として最初から用意されていることが多いのですが、その初期設定が自社の業務に合っているかは別問題です。どの操作まで自動で実行させるかは、契約している会社側の判断になります。導入時に、自動実行の対象になっている操作を一覧で確認し、取り返しのつかない操作が含まれていないかを見てくださ⁠い⁠。

Q. 小さく試すなら、どこから始めればいいですか。 読む・下書きするまでの権限(レベル1〜2)に限って、1つの業務から始めるのが安全です。この範囲なら、AIが間違えても業務は壊れません。数週間動かして精度と使い勝手を確かめ、そのうえで実行まで広げるかを判断します。最初の業務の選び方と立ち上げの手順は「AI社員の作り方|中小企業が会社として導入する手順」をご覧くださ⁠い⁠。

ご相談くだ⁠さ⁠い

AI Advanceは、甲府を拠点に、中小企業のAIエージェント構築・運用を経営とシステムの両面から支援しています。構築サービスの全体像は「AIエージェント構築・運用」にまとめています。当社では、破壊的な操作の前に人間の承認を挟む権限分離を標準の設計に入れ、免責・業務停止リスク・リカバリ範囲の3点を提案段階で明示していま⁠す⁠。

「どこまで任せて、どこに承認を挟むか」——その設計からご一緒できます。今ある業務のどれをどのレベルまでAIに渡せるかの見立てだけでも、お役に立てるはずです。初回相談は無料ですので、お気軽にお問い合わせくださ⁠い⁠。

Newslett⁠e⁠r

経営者のためのAI実践通信、隔週水曜にお⁠届⁠け

AIに任せてみた現場の実話を2〜3分で。登録無料・配信内容はこちら

AI導入の第一歩は、
課題の整理か⁠ら⁠。

「何から始めればいいか分からない」という段階のご相談こそ歓迎です。経営メンバーが直接お話を伺い、課題を整理して貴社に合った進め方をご提案します。初回相談は無料で⁠す⁠。

お急ぎの場合は info@ai-advance.co.jp へ直接ご連絡くだ⁠さ⁠い