4 分類と拒否リストで、承認と禁止をコードに固定する
背景
プロアクティブ型のエージェントを自前で作ると、最初に詰まるのはモデルの選定ではなく「どこまで許可するか」の設計です。何を確認なしで実行させ、何を毎回止めて人に聞き、何を承認があっても実行させないのか。この三つを決めないまま実装すると、あとから設定を足すことになり、設定は外せるので禁止になりません。
Anthropic の Claude Duet は 2026 年 10 月 21 日に研究プレビューを開始し、米国の Pro／Max 購読者にウェイトリストで順次招待しています。この製品は承認ルールと禁止事項を公式文書でかなり具体的に書いているため、権限設計の参照実装として読めます。以下では、公開されている仕様を「権限表」の形に整理し、自前のエージェントに写すときの実装メモとしてまとめます。
前提
| 項目 | 内容 |
|---|---|
| 対象 | Claude Duet 研究プレビュー（2026 年 10 月 21 日開始） |
| 提供範囲 | 米国の Pro／Max 購読者、ウェイトリスト招待制（Team／Enterprise は対象外） |
| 参照した一次資料 | 発表記事、安全性・プライバシー・セキュリティ文書、製品ページ、ヘルプセンター（いずれも 2026 年 10 月 26 日閲覧） |
| 検証範囲 | 公式の公開資料に記載された仕様（プレビューは米国の招待対象者に限定） |
| コード | Python 3.11 の構文による設計用の擬似コード |
権限の 4 分類
公開仕様を読むと、操作は次の四つに分かれます。分類の境目は「取り消せるか」ではなく「取り返しがつくか」です。
| 分類 | 例 | 承認 | 補足 |
|---|---|---|---|
| 1. 読むだけ | 受信トレイの要約、問い合わせの下書き、カレンダーの確認 | 不要 | 外部への送信を含まないもの |
| 2. 取り消せる操作 | 下書きの作成、社内メモの整理、検索 | 不要 | 実行ログは残す |
| 3. 取り返しがつかない操作 | メッセージ送信、支払い、署名、削除、アカウント作成 | 毎回必要 | 承認カードに「操作・対象・内容・宛先すべて」を表示 |
| 4. 恒久禁止 | 有価証券の売買、口座間の送金、他人のアカウントへのアクセス | 承認しても不可 | 設定で解除できない |
この表で実務上いちばん重要なのは 4 行目です。公式文書には、支払い・送金・注文の削除・アカウント作成について「今後は確認しない」設定が存在しないと明記されています。つまり禁止事項は制御ではなく仕様として固定されている。自前実装でここを設定ファイルに置くと、誰かが一行消した瞬間に禁止が消えます。
実装メモ
権限表をコードに落とすとき、判定を三つの関数に分けると見通しが良くなります。
# 設計用の擬似コード（Python 3.11 の構文）。
IRREVERSIBLE = {"send_message", "pay", "sign", "delete", "create_account"}
# 分類 4: 承認があっても実行しない。設定ファイルではなくコードに固定する。
DENY_ALWAYS = {
"trade_securities",
"transfer_between_accounts",
"access_third_party_account",
}
def classify(action: str) -> str:
if action in DENY_ALWAYS:
return "denied" # 恒久禁止
if action in IRREVERSIBLE:
return "needs_approval" # 毎回確認
return "allowed" # 読むだけ／取り消せる操作
def approval_card(action, target, content, recipients) -> dict:
# 宛先を必ず含める。あとから「誰に送ったか」を説明できるようにするため。
return {
"action": action,
"target": target,
"content": content,
"recipients": list(recipients),
}
DENY_ALWAYS を環境変数やデータベースに置きたくなる気持ちは分かりますが、置くと「運用で回避できる禁止」になります。禁止は定数、承認はフラグ、記録は追記専用ログ、と役割を分けておくと事故が減ります。
実装後の確認
権限表は書いた時点では正しさを保証しません。稼働後に見るべき数字を三つ決めておくと、表が機能しているかを判断できます。
| 見る数字 | 何が分かるか | 異常の例 |
|---|---|---|
| 承認までの時間 | 内容を読んでいるか | 中央値が数秒（読まずに押している） |
| 却下率 | 提案の質 | ほぼ 0%（確認が形骸化）または 50% 超（提案が雑） |
| 分類 3 の発生回数 | 運用負荷 | 1 日数十件（分類 2 に寄せられないか再検討） |
却下率が極端に低い状態は、制御が効いている証拠ではなく、確認が読まれていない可能性を示します。ここを測らずに「承認制にしたので安全」と結論づけるのが、いちばんよくある間違いです。
つまずきやすい点
承認の回数を減らしすぎる。 公式文書は、承認を求める頻度の調整に多くの時間をかけたと書いています。理由は承認疲れで、確認が多すぎると利用者が内容を読まずに承認するからです。つまり承認の回数は UX の都合ではなく制御の強度そのものです。自前実装で「面倒だから確認をまとめる」と決めると、まとめた瞬間に制御が弱くなります。
承認カードに宛先を入れない。 操作・対象・内容だけだと、送信後に「誰に届いたか」を説明できません。ログと承認の両方に宛先の配列を持たせます。
重複検知をタイムスタンプでやる。 定期実行型のエージェントは、同じ案件を毎回見つけます。既読の管理を時刻でやると、次回のスキャンで時刻が変わるため重複が消えません。対象 ID と内容ハッシュの組を鍵にします。
拒否リストを後から足す。 分類 4 は最初に決めておかないと、あとから追加した項目が既存の自動化を止めます。逆向き（最初に厳しく、必要なら分類 3 に移す）の方が安全です。
まとめ
- 権限は「読むだけ／取り消せる／取り返しがつかない／恒久禁止」の 4 分類で書き、4 行目だけは設定ではなくコードに固定します。
- 承認カードには操作・対象・内容・宛先の 4 項目を必ず入れ、宛先はログにも残します。
- 承認の頻度は制御の強度です。まとめると制御が弱くなります。
公開資料の範囲では、承認が実際に読まれているかどうかは分かりません。ここは自前実装でも同じで、承認の品質を測る仕組み（承認までの時間、却下率、内容のスクロール量など）を別途用意しないと、制御が機能しているかは判断できません。
参考資料：Anthropic の発表記事、Claude Duet の安全性・プライバシー・セキュリティ文書、製品ページ、ヘルプセンター（2026 年 10 月 26 日閲覧）。複数のモデル提供元を一つの製品にまとめる場合、鍵とモデル名をコードに散らさず一つのゲートウェイに寄せる構成が一般的で、Crazyrouter はその選択肢の一つです。採否は呼び出し量と社内の規約で決めてください。