AIエージェントの権限設計｜発注・送信を任せる前に決めること

こんにちは。LegalAgent 代表弁護士の朝戸です。

AIエージェントを業務システムに組み込むときは、性能の高さよりも先に、どこまでの行為をAIに実行させ、どこで人の承認を挟むかという線引きを決めます。この線引きを後回しにしたまま発注や顧客対応の自動化を先行させると、誤発注や誤送信が起きた段階で、社内の誰にも止められる場所がなかったという状態に行き着きます。

AIエージェントは民法上の代理人ではない

企業がAIエージェントに発注や契約締結の実行を任せたいと考えるとき、頭のどこかで「AIを自社の代理人にする」というイメージを持つことがあります。しかし、民法が定める代理の制度は、代理人が「人」であることを前提に組み立てられています。

民法99条1項は、代理人がその権限内において本人のためにすることを示してした意思表示は、本人に対して直接にその効力を生じると定めています。同条2項は、相手方が代理人に対してした意思表示についても同様に扱うとしています。ここでいう代理人は、本人から独立した意思表示の主体として行為をする者を指しており、少なくとも権利義務の主体となり得る者であることを前提としています。実際、民法111条は代理権の消滅事由として代理人の死亡や後見開始の審判を挙げており、代理人が権利義務の主体となり得る人であることを前提にした制度設計になっています。

AIエージェントは、本人とは別の権利義務の主体として位置づけられていません。AIエージェントが発注メールを送信し、見積を承諾し、システム上のボタンを押した場合、その行為は利用者が設定・運用するシステムを通じてされたものとして、利用者側に効果が帰属するかが問題となります。少なくとも、AIだけを独立した法的主体とみて、その行為を利用者から切り離す整理は採りにくいと考えられます。AIの法的地位そのものについて確立した判例や立法はなく、AIを独立した意思決定主体として扱えるかという点は学説上も議論の途上にあります。ただし、現行の民法が前提とする代理制度をそのままAIに当てはめることはできず、「AIが判断して実行したのだから、AIの独立した行為だ」という理解は、現時点の法制度とは整合しないと考えられます。

この整理を踏まえると、「AIに代理権を与えられるか」を問うより、「AIの操作結果を自社の行為として引き受ける範囲をどう線引きするか」に向き合うことになります。権限設計は、代理制度の応用問題というより、社内の業務プロセスと承認フローの設計問題です。

実行させてよい行為の範囲を先に決める

権限設計の出発点は、AIエージェントが単独で実行してよい行為と、人の承認を経てから実行する行為を分けることです。この区分は、機能の名称ではなく、行為がもたらす法的・経済的な効果を基準に行います。

発注業務であれば、既存の取引先に対する定型的な追加発注と、新規取引先との契約締結では、誤りが生じたときの影響がまったく異なります。顧客対応であれば、定型的な問い合わせへの回答と、返金や契約条件の変更を伴う回答とでは、対外的な効果の重さが違います。この違いを踏まえずに「AIエージェントに発注業務を任せる」という粗い決め方をすると、想定していなかった高額発注や条件変更まで自動実行の対象に入り込みます。

実行範囲を決める際には、次の観点で行為を仕分けます。この仕分けが、自動実行と承認待ちの境界になります。

• 対外的な意思表示を伴う行為か、社内的な情報整理にとどまる行為か
• 取消し・撤回が容易な行為か、実行後に原状回復が難しい行為か
• 既存の取引条件の範囲内の行為か、新たな条件を設定する行為か

この仕分けをせずに「効率化のため自動化する」という理由だけで実行範囲を広げると、AIエージェントが得意な定型処理と、人が判断すべき例外処理が混在したまま自動化が進み、事故が起きたときにどの段階で止めるべきだったかを説明できなくなります。

発注先が取適法上の中小受託事業者や、フリーランス法上の特定受託事業者に当たる場合には、AIエージェントを介した発注であっても、取引条件の明示や支払期日の管理を省略することはできません。発注者と受注者の規模、取引の類型、受注者が従業員を使用しているかなどを確認したうえで、個別発注時に必要事項を書面または電磁的方法で明示し、法定の期間内に代金や報酬を支払える状態を整えることが求められます。金額閾値を下回ってもこれらの義務は残るため、法定項目が欠けた発注は実行前にシステム側で止める設計にしておくことが重要です。

金額の閾値と承認ポイントの設計

実行範囲を行為の性質で仕分けたら、次は金額や件数の閾値を具体的に決めます。「高額な発注は人が確認する」という抽象的なルールでは、担当者ごとに高額の基準が異なり、閾値のない自動化と変わらない運用になります。

閾値は、少なくとも次の3種類を組み合わせて設定するのが実務的です。

• 1件あたりの金額閾値(例:通常取引の平均単価の一定倍を超える発注は自動実行しない)
• 累積金額閾値(同一取引先・同一期間内の合計額が一定額を超えたら承認を挟む)
• 対象範囲の閾値(新規取引先、契約条件の変更、支払条件の変更を伴う場合は金額にかかわらず承認を挟む)

閾値を設定した後は、閾値を超えた場合にAIエージェントの処理を自動的に停止し、担当者の承認を待つ状態に遷移させる仕組みが必要です。閾値の判定自体をAIの出力に委ねると、閾値超過の判定を誤ったときに歯止めが効かなくなるため、閾値判定と承認待ちへの遷移は、AIエージェントの外側にあるシステム制御として組み込むのが適切です。

承認ポイントは、発注や送信の直前だけに置けば足りるものではありません。AIエージェントがどの情報を参照してその発注や回答案を組み立てたのか、担当者が承認前に確認できる状態になっているかも設計対象です。承認ボタンを押すだけで内容を確認していない運用が続くと、承認という手続だけが形式的に残り、実質的な人の判断は失われます。

ログに残すべき実行結果と紐づけ

権限設計と一体で決めておくべきなのが、実行結果のログです。ログ監査の設計思想そのものはAIエージェントのログ監査と責任分界のチェックポイントで扱っていますが、権限設計の文脈では、どの権限に基づいてその行為が実行されたのかを、個々のログに紐づけて残す必要があります。

具体的には、実行された発注や送信について、閾値判定の結果、承認者の有無、承認者が承認した時刻、承認時に提示されていた情報の内容を記録します。閾値以下として自動実行された場合には、その閾値の設定内容と、実行時点でその閾値が適用されていたことも記録に残します。閾値やルール自体を後から変更した場合は、変更前後でどの実行がどちらのルールに基づいていたのかを追跡できる状態にしておきます。

このログがなければ、誤発注や誤送信が起きたときに、閾値設定が甘かったのか、閾値は適切だったが承認者が確認を怠ったのか、閾値判定のシステムに不具合があったのかを切り分けられません。切り分けができない状態は、社内の再発防止だけでなく、取引先への説明でも不利に働きます。

誤作動が起きたときに「AIが勝手にやった」は通りにくい

権限設計を怠ったまま事故が起きたときに、企業側が最も陥りやすいのが、取引先に対して「AIが誤って実行したものであり、当社の意思表示ではない」と主張しようとする対応です。

この主張が対外的に通りにくい理由は、外形的に権限があるように見える行為について、相手方の信頼を保護する考え方が民法に組み込まれているためです。民法110条は、代理人が権限外の行為をした場合でも、相手方がその代理人に権限があると信ずべき正当な理由があるときは、本人が責任を負う旨を定めています。民法112条も、代理権が消滅した後に、その代理権の範囲内でされた行為について、消滅の事実を過失なく知らなかった相手方に対して本人が責任を負う仕組みを定めています。これらの規定はAIエージェントの利用を直接想定した規定ではありませんが、外形上正当な権限行使に見える行為について、相手方が抱いた信頼を保護する方向で制度が組み立てられているという基本構造は、AIエージェントの誤作動の場面を考える際にも参考になります。

AIエージェントは通常、企業のシステム、社員のアカウント、既存の取引チャネルを使って発注や送信を行います。取引先から見れば、これまでと同じ担当窓口・同じアカウントから届いた発注や連絡であり、それが人による操作かAIエージェントによる自動実行かを区別する手段を持ちません。この状況で企業側が「AIが勝手に実行した」と主張しても、相手方の信頼を覆すだけの事情を示せなければ、意思表示の効力を否定することは難しいと考えられます。

したがって、誤作動対策では、起きた後にAIの独断だったと主張する発想を避け、そもそも誤作動が対外的な効果を生まないように実行前の閾値と承認で止める設計を採用すべきです。事後の言い訳を用意する発想では、対外的な責任を免れることはできません。

取引先との契約でAIエージェント利用をどう扱うか

自社がAIエージェントを使って発注や顧客対応を行う場合だけでなく、取引先がAIエージェントを使って自社との取引を行う場合についても、契約上の手当てを検討する余地があります。

具体的には、相手方がAIエージェントを用いて行った発注、請求または契約変更の意思表示を相手方本人の行為として扱うことを確認する条項が考えられます。あわせて、誤作動による発注内容の誤りや条件の齟齬が判明した場合の訂正・撤回の手続と期限、AIエージェントが実行した処理に関する記録を必要な範囲で開示・提供する仕組みも検討対象になります。

これらの条項はAIエージェントの利用禁止を目的とせず、AIエージェントを使う場合の対外的な扱いをあらかじめ合意しておくために設けます。契約書に何も定めがない場合、AIエージェントが関与した意思表示も、通常の意思表示と同じ取引チャネルを通じて相手方に伝達されます。後から「AIが関与していたので無効だ」と相手方から主張されても、AIの関与だけで契約の効力が覆るとは考えにくいでしょう。だからこそ、誤りが生じた場合の訂正手続を契約書側に用意しておくことが、双方にとって実務的な備えになります。

権限設計を最初に固めておくべき理由

AIエージェントの導入検討では、どの業務を自動化できるか、どれだけ処理速度が上がるかという観点が先に語られがちです。しかし、対外的な行為を伴う業務にAIエージェントを使う以上、実行してよい行為の範囲、金額の閾値、承認を挟むポイント、ログの保存方法という権限設計を固めてからでなければ、自動化の範囲を安全に広げることはできません。

まず着手すべきは、現在AIエージェントに任せようとしている業務、あるいはすでに任せている業務を洗い出し、それぞれについて対外的な意思表示を伴うかどうかを仕分けることです。そのうえで、金額閾値と承認ポイントの案を作り、実際の取引規模に照らして閾値の水準が妥当かを社内で検討します。閾値や承認フローの設計に加えて、取引先との契約書にAIエージェント利用に関する条項を置くべきかどうかも、既存の取引基本契約や業務委託契約を確認しながら判断することになります。この設計を先に固めてから、AIエージェントの実行範囲を段階的に広げていく順序が、事故対応の観点からも合理的です。

AIエージェントを使った業務フロー全体の設計は、AIエージェントを法務業務に入れる前に決めるべきことでも扱っていますので、あわせてご参照ください。