ハーネスエンジニアリングのプラクティス P15. 権限は「能力」ではなく「取り消し可能性」で設計する 🎯 ポイント 問うべきは「Xできるか」ではなく「Xを取り消せるか」です。可逆性こそ、自律性と安全性のトレードオフを切る正しい軸です。 📝 概要 可逆な行為（ブランチへのコミット、ファイル編集。gitが戻せます）は自由に許し、不可逆な行為（force-push、本番書き込み、外部メール送信、送金）だけをゲートします。可逆性が権限設計の基準です。 🔍 解説 多くの権限設計は「この操作は危険か？」という直感で行われますが、直感はしばしば間違います。ファイル編集は「危険」に見えますが、gitで即座に取り消せるため実際のリスクは低いです。一方、外部APIへのリクエストは「些細」に見えますが、送信後に取り消せないため実際のリスクは高いです。取り消し可能性を基準にすると、自律性と安全性の最適なバランスが自然に導かれます。可逆な操作にまで承認ダイアログを出すと「ゲート疲労」（AP8）が発生し、人間は反射で承認を押すようになり、本当に危険な操作も見逃してしまいます。 🛠 実践方法 ・エージェントが実行可能な全操作をリストアップし、各操作を「可逆」「不可逆」「条件付き可逆」に分類します ・可逆な操作（ブランチへのコミット、ファイル編集、サンドボックス内の実行等）は承認なしで許可します ・不可逆な操作（force-push、本番書き込み、外部API呼び出し、メール送信等）は承認ゲートを必須にします ・影響の連鎖を考慮します（コミット→CI→自動デプロイという間接的な不可逆性に注意） 💼 ユースケース ・issue-to-PRエージェントで、ブランチへのコミットは自由、でもforce-pushは禁止する場面 ・インシデント対応で、診断（読み取り）は自律、是正（本番書き込み）は人間承認必須の場面 ・プロトタイピングで、サンドボックス内の操作は自由、外部ネットワークアクセスだけをゲートする場面 ⚠ 落とし穴 「可逆」の判断は単純ではありません。ブランチへのコミットは可逆ですが、そのブランチが自動的にCIを起動し、CIがデプロイをトリガーするなら、間接的に不可逆な影響を持ちます。影響の連鎖全体を考慮して可逆性を判断する必要があります。また、「取り消せるから大丈夫」と安全を過信するのも危険で、取り消しコストの大小も考慮すべきです。 #HarnessEngineering# #AIAgent#