Agentic OS 技術スタックを下から読む 第30回：外では「あると思われた権限」が会社を縛る ―― 表見の権限と、責任の所在

Agentic OS 技術スタックを下から読む 第30回：外では「あると思われた権限」が会社を縛る ―― 表見の権限と、責任の所在

検証室を出ると、出力の重さが変わります

前回までは、出力をどう測るかを見てきました。

判定を別の仕組みに任せるだけでは足りませんでした。
その判定を人の判断につなぎ留め、ずれたら直す必要がありました。

そこまでは、検証室の中の話でした。

検証室では、出力はまず試料として扱われます。
良いか悪いかを見ます。
基準に合うかを見ます。
人の判定とどれくらい合うかを見ます。

しかし、外の世界では出力は試料ではありません。

相手が読みます。
相手が信じます。
相手が次の行動を取ります。

たとえば、取引先に条件を送ります。
相手はその条件で準備を始めます。
在庫を押さえます。
社内の承認を回します。
別の候補を断ります。

このとき、相手にとって重要なのは、画面の向こうが人かどうかではありません。
会社の窓口から条件が来たように見えるかどうかです。

ここで問題が変わります。

検証室では「出力は正しいか」が中心でした。
外では「その出力は会社の約束として受け取られるか」が中心になります。

これは同じ問題ではありません。

正しい文章でも、会社がまだ約束していないことを約束したように見えれば危険です。
少し曖昧な文章でも、外の相手が公式な回答として扱えば重くなります。

外の世界に出すとは、文章を公開することではありません。
相手の判断と行動を動かす場所に置くことです。

権限には二つあります

ここで、権限を二つに分けて考える必要があります。

一つは、内側で与えた権限です。

これは会社の中で決めたものです。
このエージェントは何を読めるのか。
どの処理を実行できるのか。
どの金額まで扱えるのか。
どの相手に返事を出せるのか。

これは前に見た技術的な許可の話とつながっています。
ファイル、命令、通信の通り道を狭める話です。
内側の仕組みで、できることを小さくします。

もう一つは、外の相手が「あるはずだ」と思う権限です。

相手は内部の設定を見られません。
どの命令が止められているかを知りません。
どの金額で警告が出るかも知りません。
どの文言から人の承認が要るかも知りません。

相手が見られるのは、表に出ているものだけです。

どんな名前で名乗っているか。
どんな役割だと書かれているか。
会社の正式な窓口に見えるか。
文面が社外向けの正式な体裁か。
金額や期限をどれくらいはっきり書いているか。

相手はそこから推し量ります。

この窓口なら、ここまでは約束できるはずだ。
この文面なら、社内で通った条件のはずだ。
この表示なら、会社を代表しているはずだ。

内側で与えた権限は、会社の中の事実です。
外から見える権限は、相手の側で生まれる受け取り方です。

この二つは、よくずれます。

外では、あると思われた権限が効きます

厄介なのは、外の世界では、あると思われた権限のほうが効いてしまう場面があることです。

たとえば、会社の中ではこう決めていたとします。

このエージェントは見積もりを出してよい。
ただし、契約を結んではいけない。
最終条件は人が確認する。
納期の確約もしてはいけない。

内側では、線引きがあります。

しかし、外の相手から見ると違います。
会社の正式な窓口のような画面から返事が来ます。
会社名の入った体裁で、金額、数量、納期、支払い条件が並んでいます。
文章の最後に、手続きを進めます、と書かれています。

相手はこれを見て、会社が条件を示したと受け取ります。

ここで後から、社内では契約権限を与えていませんでした、と言っても通りにくくなります。
相手は内部の線引きを知らなかったからです。
そして、知らないことには理由があります。
その線引きは外に示されていなかったからです。

外の相手は、見えるものだけで判断します。

だから、外向きの権限は内部設定だけでは閉じません。
表に出る名前、肩書き、文面、画面、送信元、言い切り方が、相手の側に権限を作ります。

検証室では、実際にできることだけが効きます。
外の世界では、できると思われたことが会社を縛ります。

ここが決定的な違いです。

名乗り方は飾りではありません

外向きの名乗り方は、画面の飾りではありません。
責任の設計です。

同じ文章でも、名乗り方によって受け取られ方が変わります。

「参考情報を返す補助係」と名乗る場合と、「正式な取引窓口」と名乗る場合では、相手の構えが変わります。
前者なら、相手は確認が必要だと考えます。
後者なら、相手は会社の回答だと考えます。

だから、名乗り方は細かく決める必要があります。

何のための窓口なのか。
どこまで答えられるのか。
どこから先は人が確認するのか。
提示した条件は提案なのか。
それとも確定した約束なのか。

この区別を、相手が読む場所に出さなければなりません。

たとえば見積もりを出すなら、見積もりであると書きます。
契約の成立ではないと書きます。
期限、在庫、特別な条件は、人の確認後に確定すると書きます。
支払い条件や納期を出すなら、それが仮の条件なのか、承認済みの条件なのかを分けます。

これは丁寧な説明ではありません。
相手の側に過大な権限が生まれるのを防ぐ表示です。

曖昧にすれば、相手は広いほうに受け取ります。
それは相手が悪いからではありません。
会社の印をまとった窓口から、断りのない具体的な条件が届いたからです。

外向きの設計では、できることを隠してはいけません。
できないことも隠してはいけません。
境目をその場で見せる必要があります。

規則は文書だけでは止まりません

多くの組織は、ここで文書を書いて安心します。

このエージェントは契約を結ばない。
一定額を超える支出はしない。
特別な値引きはしない。
相手の秘密情報を別の相手に出さない。

方針としては必要です。
しかし、文書は実行を止めません。

エージェントが外の相手に返事を書く瞬間、文書は横から手を伸ばして止めてくれません。
止めるのは、実際に効く仕組みです。

金額に上限を置きます。
上限を超えたら、文章を送れないようにします。
納期の確約を禁じるなら、確約を含む文面を検出した時点で止めます。
契約の成立を示す言葉を使えないようにします。
特定の条件を出すときは、人の承認を待たせます。

触れてはいけない情報も同じです。

社外に出せない項目は、返答を作る前に渡さないようにします。
渡してから「書かないで」と頼むのでは弱いです。
返答の直前にも、出てはいけない情報が混じっていないかを調べます。
混じっていれば送信を止めます。

さらに、全体を止める手段も要ります。

異常な返答が続いたとき。
想定していない相手から大量の依頼が来たとき。
境界を突く依頼が増えたとき。
その場で外向きの送信を止められなければなりません。

方針書の言葉ではなく、実行時に効く仕組みだけが暴走を止めます。

名前の付いた責任者が要ります

外に出すエージェントには、責任を負う人が必要です。

これは、精神論ではありません。
運用のための宛先です。

何かが起きたとき、外の相手は会社に問います。
その返答は誰の管轄なのか。
その条件は誰が認めたのか。
その範囲は誰が決めたのか。
止める判断は誰がするのか。

ここが空白だと、社内で問題が宙に浮きます。

開発した人は、運用の判断は担当外だと言います。
現場の人は、仕組みの中身は知らないと言います。
管理する人は、どの範囲で使われていたかを知らないと言います。

その間にも、外の相手は回答を待っています。

だから、外に出す前に、責任者を一人結びつけます。
部署名だけでは弱いです。
会議体だけでも弱いです。
日々の停止、承認、範囲変更を判断する人が必要です。

同時に、任務の範囲も具体的に決めます。

問い合わせの分類だけをするのか。
見積もりの下書きまで作るのか。
相手に直接送るのか。
値引きに触れてよいのか。
納期に触れてよいのか。
謝罪や補償に触れてよいのか。

範囲が決まっていて初めて、後から問えます。

これは範囲内だったのか。
それとも外れていたのか。
外れていたなら、表示が悪かったのか。
止める仕組みが足りなかったのか。
責任者の見直しが遅れたのか。

責任者と範囲は、外向きの運用の最低条件です。

範囲内であることは証拠で示します

範囲を決めても、それだけでは足りません。

使われ方は変わります。
相手の依頼も変わります。
最初は想定していなかった質問が来ます。
現場の人も、便利な使い方を見つけます。

その結果、エージェントは少しずつ外へ出ます。

最初は見積もりの下書きだけだったものが、相手への直接送信に近づきます。
最初は一般的な案内だけだったものが、個別の条件に踏み込みます。
最初は過去の資料を探すだけだったものが、判断の理由まで作り始めます。

だから、軌跡を残します。

いつ、誰から、何を受け取ったのか。
どの情報を使ったのか。
何を判断したのか。
どの文面を外へ出したのか。
どこで人が承認したのか。
どこで止めたのか。

これを後から追える形で残します。

記録は、責任を押しつけるためだけのものではありません。
範囲内で動いていると示すためのものです。
また、範囲外に出始めたと気づくためのものです。

点検には二つの方向があります。

一つは、境界を攻める試験です。
わざと約束してはいけないことを頼みます。
確定していない納期を確約させようとします。
出してはいけない情報を聞き出そうとします。
担当外の判断をさせようとします。

もう一つは、ふだんの記録を見る点検です。
外へ出した返答を並べます。
判断の重心が変わっていないかを見ます。
断るべき場面で断れているかを見ます。
人の承認が必要な場面で止まっているかを見ます。

証拠がなければ、範囲内だったとは言えません。
証拠がなければ、外れたことにも気づけません。

内の許可と外の権限を同時に設計します

エージェントの権限には、内と外の二面があります。

内側の許可は、実際にできる操作を狭めます。
触れる場所を狭めます。
通る経路を狭めます。
これは前に見た話です。

外側の権限は、相手があると思う範囲です。
こちらは、名乗り方で扱います。
責任者の明示で扱います。
方針を実行時に効く仕組みに落とすことで扱います。
範囲内である証拠を残すことで扱います。

失敗が許されない現場では、この二つが両方要ります。

内側だけを固めても、外で広い権限を持つように見えれば、会社は相手の信頼に縛られます。
外向きの表示だけを整えても、内側の仕組みが止めなければ、実際の暴走は止まりません。

検証室では、できることを見れば足りました。
外の世界では、できると思われることも見なければなりません。
そして、実際に止められることも見なければなりません。

次回も、外の世界で動かす話を続けます。

今度は、失敗の重さそのものを見ます。
直せる失敗と、取り返しのつかない失敗は同じではありません。
やり直せる操作と、戻せない操作も同じではありません。
可逆性と費用の非対称を、次の層として見ていきます。