AIの操作承認は実行する対象と引数に結び付ける
「実行してよい」という会話だけでなく、承認した操作・宛先・金額・対象のバージョン・有効期限を記録する。実行側はその範囲と現在の認可を検証し、変更された操作に承認を使い回さない。
用語
- Human-in-the-loop
- 人の承認や判断を処理の途中に組み込む方式。承認の対象と範囲を明示する必要がある。
- 承認記録
- 誰がどの操作・引数・条件を許したかを、実行側で検証できる形で保持した記録。
- 楽観的ロック
- 読んだ時点のバージョンなどを更新条件に使い、その後の変更との競合を検出する方法。
図と例
対象・引数・前提を提示 → 承認内容と期限を保存 → 実行直前に権限を確認し操作を承認内容と照合 → 条件付き実行と結果記録
仮定の例：担当者が「注文42に3,000円返金」を承認した後、モデルが注文43への返金を提案した。ツールの名前が同じでも承認した対象は違うため止める。注文42でも承認の前提となる状態が更新されていれば、条件付き実行を失敗させて再確認する。
実際のサービス・製品では
LangChain
LangChainのHuman-in-the-loopミドルウェアは、ツール呼び出しを止め、提案された引数のまま承認するか、編集・拒否するかを扱う。対象のバージョンや業務上の承認範囲の検証はアプリ側にも必要。
資料を読む
解説
顧客の業務責任者と、個別承認が必要な操作と事前に許可できる範囲を決める。担当者が対象・引数・根拠を確認できる画面を用意し、承認者が不在のときは保留や代理承認の規程に従う。承認範囲外の変更、期限切れ、状態変更を実行側が止めることを導入試験で確かめる。
Human-in-the-loopは人を処理の判断に組み込む方式。人が確認した時点と実行時点の間で、モデルの再計画や対象データの更新が起こり得る。承認記録を正規化した操作内容と結び付け、承認者・操作ID・重要な引数・必要な状態条件・期限をサーバー側で保持する。モデルが返した「承認済み」の文字列を証拠にしない。楽観的ロックなどの条件付き更新を使い、確認したバージョンが変わったら失敗させる。承認を得ても認可は省略せず、同じ承認を二重に使うことも操作IDや冪等性の仕組みで防ぐ。
トレードオフ
- 個別の操作内容を確定してから承認する
- 得るもの：人が実際の対象と変更を確認できる
- 払うもの：変更があると再承認が必要になり、待ち時間が増える
- 事前に限定した範囲を承認し範囲内を自動実行する
- 得るもの：定型操作の確認回数を減らせる
- 払うもの：対象・金額・期間などの範囲を機械的に検証し、範囲外を止める設計が要る
さらに学ぶ
チェック
注文42への返金を承認した後、モデルが注文43への返金を提案した。正しい扱いは？
- 同じ返金ツールなので承認を流用する
- 対象が承認範囲外なので実行を止め、変更した内容の承認を得る
- モデルに承認済みと言わせて実行する
解答と解説
対象が承認範囲外なので実行を止め、変更した内容の承認を得る
承認は注文42への操作に結び付いており、注文43には適用できない。実行側が保存した内容と提案を照合する。ツール名の一致やモデルの自己申告は、変更された対象への承認の証明にならない。