AI & CYBERSECURITY / OCTOBER 2026
AIエージェントに社員と同じ権限を渡す前に。読み取り・変更・送信を分ける
Microsoftの10月発表を手掛かりに、小さな会社でも始められるAIの委任台帳を作る。
資料確認 2026-10-26 / 2026年10月特集
SONAEの提案 / 01
業務名だけでなく、許す操作を書く
「経理を手伝うAI」では、閲覧、下書き、承認、送信のどこまでか分かりません。SONAEの提案は、使うデータ、許可する操作、承認者、期限を組にした委任票です。架空例なら、請求書の項目抽出は許可、振込先変更と支払実行は対象外と記録します。担当者が使える権限をすべてAIへ渡す必要はありません。
SONAEの提案 / 02
承認は実行する内容と結び付ける
承認画面に表示した宛先と、実際に送る宛先が一致するかを受入の問いにします。承認後に内容や参照対象が変わったら、再確認へ戻す条件を決めます。会話上で「よろしく」と言った記録だけを、重大な変更への恒久的な許可にはしません。操作の危険度に応じて確認を設け、通常の読み取りまで一律に止めない設計を検討します。
AIへ渡すのは、業務に必要な操作だけ
図の内容を文章で読む
業務の依頼 → 操作の承認 → 限定した実行。内容・対象・期限を固定。変わった依頼は再承認へ。概念図であり、実測ではありません。
SONAEの提案 / 03
止める担当と、止まった証拠を持つ
停止ボタンの存在だけでは、進行中の処理や定期実行まで止まるかは分かりません。架空環境の受入案では、停止後に新しい変更が行われないか、保留中の処理を誰が判断するか、再開に必要な承認を確認します。AI自身が監視を解除できない権限の分離も、設計担当へ依頼する事項に含めます。
SONAEの提案 / 04
導入の判断材料を、一枚ずつ増やす
台帳、承認の記録、停止試験、残課題がそろうと、次に許す業務を判断できます。SONAEの点検・改善支援で目指す成果物もこの判断材料です。すべてを自動化できるとは約束せず、未確認の機能は保留にします。相談では対象業務を一つ選び、読み取りから始める段階案と、変更を許すための受入を整理します。
SONAEの提案 / 05
承認が多いと使いにくくならない？
読むだけの仕事と、送信・削除・支払いなどの結果を残す仕事では、必要な確認を分けます。承認の回数を増やすこと自体を目標にせず、何が承認済みなのかを実行対象と一致させます。範囲内の反復処理と、対象や内容が変わった処理を分けると、責任と操作性を両立する設計を検討できます。
受入条件を考える二つの例
SONAEの未実行の計画例です。診断の合格実績ではありません。
- 対象の変更
- 条件：承認後に送信先が変わる架空例
期待する扱い：元の承認を使わず再確認へ戻す - 停止
- 条件：停止後に定期実行が残る架空例
期待する扱い：新しい変更が進まないことを受入の条件にする
社内で使う確認票
記入例はすべて架空です。秘密鍵、認証コード、個人情報の値は記入しないでください。
- 業務
- 架空：請求書の項目抽出
- 許可
- 読取と下書き／支払は対象外
- 承認
- 対象・内容・期限／変更時は再確認
- 停止
- 担当・保留処理・再開条件