エージェントの提案と組織の決定を分ける

要約

IETFの個人草案は、エージェントの提案が組織の決定になるには、権限を持つ主体と明示された採用規則が必要だとする。有効な認証情報は道具を使う資格を示すが、会社の決裁そのものではない。
委任の際には目的、制限、重要な文脈、決定への参照、証拠の種類、責任者を残す。道具への要求、実際の行為、確認された結果も混ぜてはいけない。

提案書は着いた。決裁席は空席だ

あるエージェントが取引先の変更を勧める。次のエージェントが作業を引き取り、道具が成功を返し、報告書には「変更完了」と並ぶ。速い流れである。だが会社が変更を決めた瞬間はどこか。提案を採用したのは誰か。道具の応答の先で、取引先や契約は本当に変わったのか。エージェントの委任と引き継ぎを扱う新しい個人草案は、提案、決定、行為、結果を四つの事実として扱う。取引先の話はこの区別を試すための仮定であり、実在の企業の事例ではない。

IETF Datatrackerによると、文書は2026年10月19日付の個人Internet-Draft第00版で、IETFの承認やRFCの経路はない。著者が示すのは組織内の意味を引き継ぐための要件である。新しい通信方式を定めたわけではない。それでも欠落箇所は実務的だ。機械同士が正しく認証され、呼び出しがすべて成功しても、誰が会社を拘束する判断を下したかは別途示さなければならない。

まず技術的な許可と組織の権限を区別する。APIの資格情報は、ある呼び出しを許す。組織の権限は、何の目的で、どの範囲を除き、誰のために判断や行動をしてよいかを定める。草案は委任者の身元、目的、制限を次の主体へ渡し、委任者が持つ権限の一部だけを継がせるよう求める。会議室の鍵で扉は開く。席に座って会社の契約を決める権利は、その鍵に刻まれていない。

次に、採用の地点がある。提案は進路を示す言葉であり、決定は認められた主体が規則に従って行う組織の約束だ。会社のために行為をするなら、その行為は承認の根拠となった決定、あるいは個別の決定を要しないと定めた明示的な規則を参照しなければならない。提案そのものを決定欄に貼り付けても空欄は埋まらない。低リスクの作業を自動化するなら、あらかじめ会社が認めた規則の範囲と責任者を残す必要がある。

「成功」の通知で契約は変わらない

草案は決定の後も細かい。道具への呼び出しは要求であり、行為は現実に起きた介入であり、結果はその後に観測される変化だ。権限を欠く行為も、起きた以上は行為として記録する。発生と正当性は別々に調べる。APIが成功を返しても事業上の結果までは証明しない。エージェントの自己報告も、行為が起きた証拠として単独では足りない。

証拠を混ぜないため、文書は少なくとも三種類を挙げる。エージェントの自己報告、プラットフォームや実行環境の記録、外から検証できる資料だ。最初のものはエージェントの説明を示す。二番目は道具への要求と応答を示せる。三番目はその外で何が変化したかを確かめる。危険度の高い状況で自己報告だけを採用すれば、当事者に自分の仕事の検収印を押させることになる。

引き継ぎでは文脈も落ちやすい。最初のエージェントが「この地域だけ」「候補を調べるだけ」「契約はしない」と知っていても、次の主体に短い命令と有効なトークンしか届かないかもしれない。解釈、許可、危険の評価を変える情報を草案は重要な文脈と呼び、引き継ぎの際に残すよう求める。前の主体への信頼を次の主体へ自動で譲ることもできない。受け取る側の状況で、頼ってよい理由を確かめ直す。

後から得た証拠は過去の決定時点を塗り替えない。新情報で次の判断を変えることはできるが、前の判断で利用できた情報の記録は残る。著者は設計上の適合と運用上の適合も分ける。概念図が正しくても、実際の引き継ぎで四つの区別が守られた証拠がなければ現場の評価はできない。必要なのは華やかな完成報告より、時間順に検証できる記録だ。