第5章：Rules 設計（allow / prompt / forbidden）
この章で扱うこと
- 許可する操作/承認が必要な操作/禁止する操作の線引き
- 例外時の承認フロー（誰が/どこで/何を残す）
Rules の役割
Rules は、エージェントの実行境界（権限・操作・変更範囲）を 運用ルールとして固定 する仕組みです。 目的は「早くする」ことではなく、事故（Secrets 漏えい、破壊的操作、権限逸脱、監査性の毀損）を抑止することです。
allow / prompt / forbidden の線引き
最小構成として、操作を 3 区分に分けます。
- allow：事前承認なしで実行してよい（低リスク/可逆/監査容易）
- prompt：人間承認が必要（影響が大きい、または Secrets/権限が絡む）
- forbidden：禁止（原則実行しない。代替案を提示する）
線引きの判断軸（例）：
- 影響範囲（本番/データ/供給網/セキュリティ）
- 可逆性（revert 可能か、復旧が容易か）
- 監査性（証跡が残るか、説明可能か）
- 変動性（外部仕様/料金/UI など、一次情報参照が必要か）
ミニ例：コマンドポリシー（断片）
分類は組織/権限/実行環境で変わります。ここでは「典型例」を示します（要確認）。
## allow（低リスク・可逆・監査容易）
- `rg` / `ls` / `cat`（読み取り）
- `npm test`（品質ゲート）
## prompt（影響が大きい、または外部/権限に触れる）
- 依存取得を伴うコマンド（例: `npm install`）
- 変更の公開/配布に関わる操作（例: `git push`、release 作成）
## forbidden（原則禁止。代替案を提示する）
- 破壊的操作（例: `rm -rf /`）
- 監査性を損なう操作（例: force push）
- 外部スクリプトの直接実行（例: `curl ... | sh`）
prompt の承認フロー（最小）
prompt に分類した操作は、実行前に「説明と承認」を挟みます。
- エージェントが「目的/変更内容/影響/ロールバック/実行コマンド」を提示
- 人間が承認/却下（判断理由を Issue/PR に残す）
- 実行後、証跡（差分、結果、ロールバック）を PR に残す
承認ログ（最小）例：
[承認] prompt 実行: npm install
理由: 依存更新の検証に必要
影響: lockfile が更新され得る。差分は PR に残す
ロールバック: revert / lockfile の復元
例外運用と監査
- 例外で prompt を省略する場合でも、事後に「理由/影響/証跡」を記録します。
- 例外を恒久化せず、Rules の見直しに反映して再発防止します。
Companion 資産（参照先）
Companion repo: itdojp/GitHub-AgentOps-companion
rules/command-policy.md
章末チェックリスト（ドラフト）
- allow/prompt/forbidden の運用ポリシーが文書化されている
- セキュリティ章（第10章）と整合している