AIにどこまで任せるか。誤った操作を本番に届かせない四つの設計

AIに公開原稿の修正を任せたとします。承認したのはキャンペーン告知の第3版です。その後、エージェントが古い一覧を参照し、同じ名前の別ページを公開対象に選びました。ここで業務責任者が確かめたいのは、AIがルールを説明できるかと、実際の公開先で何が起きるかの二点です。後者は、公開処理がどの対象を受け付け、結果をどこから確認できるかで決まります。

判断のずれが業務の損失になるまで

「必要な箇所だけ直す」は、人によって必要の範囲が変わります。「今日中に完了」と「本番変更は承認後」が同居すると、完了を急ぐ過程で承認待ちが障害物として扱われることがあります。長い案件では、会話の要約に残った目的を引き継いでも、予算や対象版を落とす場合があります。調査で読んだWebページに操作指示が書かれていれば、資料の一節が次の行動を誘導する場合もあります。

ここまでの四つは、判断がずれる経路です。五つ目の過大な権限は、その判断を実際の変更につなげる条件です。たとえば集計担当が送信もできる資格情報を持てば、調査用テキストに誘導された操作が外部への送信に届きます。モデルの指示階層に関するOpenAIの研究は優先順位付けを改善する方法を扱い、OWASPは外部入力による誘導と過大な実行能力を別のリスクとして整理しています。この記事の五つの観点は、業務の失敗経路を確認するために使います。 OpenAI · OWASP Prompt Injection · OWASP Excessive Agency

一件の公開を四つの責任に分ける

公開予約を登録した後に応答が途切れる場合を考えます。再び同じ文面を送れば、予約が二重に入る可能性があります。実行先の予約IDや元の操作IDで状態を読み、予約が1件だけ成立していると確かめられれば、その時点で作業を進められます。確認できない間は当該の公開操作だけ保留し、資料の校正など独立した作業を進めます。送信や課金でも、公開URLの代わりに配信履歴や課金側の取引記録を使えます。

課金を任せる場面では、契約内の利用枠と契約外の従量課金を契約で分けます。従量課金を許可するなら、請求先、最大額、通貨、有効期間、使い切ったときの停止条件を先に決めます。上限を強制できる経路を使い、送信前に利用可能額を確保します。結果の照会では予約額と請求側に記録された額を分け、予約が有効な間の並行処理も考慮します。上限を確認できない場合、課金を伴う操作を保留します。

試験で見えた境界

公開版ARC 1.0.1の模擬試験では、承認時に記録された宣言を変えた3ケースが不一致で拒否されました。架空ツールの定義だけを変え、宣言を維持したケースでは、宣言検査がPASSを返し、実行許可の値は false でした。ARCは、渡された契約や宣言の整合性を確かめます。その契約を使って実際の操作を許可する責任は、実行側が持ちます。 ARCの再現手順と結果

今回の隔離試験では、SQLiteに下書きと保護対象を用意しました。同じ下書き用の宣言を置いたまま書き込み先を変更すると、書き込み直前の照合を外した比較対照では保護対象が変わり、照合ありでは変更が0件でした。応答喪失を模擬したケースでは、別の読み取り接続から書き込み1件を確認できました。アプリから照会できないケースでは処理を保留しました。架空データと単一プロセスの試験で確認した範囲です。本番では、実行者と確認者の資格情報や権限、操作先の永続記録を使った検証が必要です。

この6ケースは、再現用Python（統合済みARC PR #118の固定コミット）と期待結果TSVで公開されています。Pythonの標準ライブラリだけで試せます。アプリ側とテスト側は一つのプロセスと読み取り関数を共有し、照会不能はフラグで再現します。ネットワーク0件と再送0件は構成上の固定値です。実サービス、資格情報の分離、クラッシュ後の復旧、重複操作の分岐は検証していません。ARC PR #118はmainに統合済みです。本番での効果確認は別工程です。

導入時に最初に決めること

運用中の操作を一つ選び、四つの質問に担当と確認先を割り当てます。何を承認したか。操作先で何を照合するか。結果をどこから確認するか。確認できなければ何を止めるか。次に、許可済みの正常操作と、承認後に対象が変わった場合の両方を試します。拒否の文言と操作先の状態を別々に記録すると、どこまで安心して委任できるかを判断できます。