KM情報サービス　HP

お問い合わせ

KM情報サービス　HP

お問い合わせ

読み取り→プレビュー→確認→書き込みが安全な理由

,

読み取り→プレビュー→確認→書き込みが安全な理由

AIエージェントへ外部サービスの書き込み権限を渡す時、最も効果的な設計の一つが「考える」と「変更する」を分けることです。

四段階の流れ

“`text
Read
↓ 現在状態と対象IDを確認
Prepare
↓ 実行内容・差分・影響を表示
Confirm
↓ 人または明示的ポリシーが承認
Write
↓ 同じ内容だけを実行し監査
“`

Readでは対象を一意に特定します。Prepareでは外部状態を変えず、送信するpayload、変更前後、警告を表示します。Confirmでは人が内容を承認し、Writeではprepareと同一の内容だけを実行します。

なぜ確認ボタンだけでは足りないか

「実行しますか？」と尋ねても、その後にAIがpayloadを作り直せば、確認した内容と実行内容が違う可能性があります。確認コードやpayload hashを使い、内容が一文字でも変われば再確認を要求します。

さらに、prepare後に別の利用者が対象を変更する場合があります。ファイルならrevision、APIなら更新時刻やETagなどを使い、古い状態を前提に上書きしない楽観的ロックを検討します。

防御を重ねる

安全条件は一つに集約しません。

  • 書き込み機能の初期値を無効
  • 対象をallowlistで限定
  • 入力の型、日付、金額、件数を検証
  • prepareとwriteを別Toolにする
  • payload hashを確認
  • 直前状態のrevisionを確認
  • 成功・失敗を監査
  • 削除や高額処理は別の承認へ分ける

いずれか一つをすり抜けても、次の層で止める設計です。

自動実行ではどうするか

人がいないcronで、毎回手動承認はできません。その場合は、十分にテストした決定論的処理だけを自動承認し、対象と上限を狭くします。たとえば「前日の日次ノートの自動生成範囲だけ」を許可し、「任意ファイルを書き換える」は許可しません。

高リスク処理は、cronで下書きや候補まで作り、朝に人が承認して実行する二段階運用が現実的です。

まとめ

Human in the loopは、単に人へ聞くことではありません。人が確認した内容と、実際に実行される内容を技術的に結び付けることです。読み取りから書き込みまでの境界をTool設計へ落とし込みます。

参考にした一次情報

  • [MCP Tools—User Interaction Model](https://modelcontextprotocol.io/specification/2025-11-25/server/tools)
  • [Hermes Agent Security](https://hermes-agent.nousresearch.com/docs/user-guide/security/)
  • [OWASP Transaction Authorization Cheat Sheet](https://cheatsheetseries.owasp.org/cheatsheets/Transaction_Authorization_Cheat_Sheet.html)
Back to top