コーディングエージェントの権限システムの多くは許可リスト方式です。ファイルの読み取りは可、書き込みは可、テストの実行は可、その他はすべて確認する、というものです。この方法は、確認プロンプトを止めるためにエージェントを「完全な信頼」に設定し、そのエージェントが金曜日に git push --force を実行してしまうまでは機能します。
私たちの立場は、4つのカテゴリのアクションは、エージェントやリクエストした人がどれほど信頼されていようと、毎回必ず人間の判断で止まるべきであるというものです。信頼レベルが決めるのは、それ以外のアクションのうちどれだけの承認が必要かです。これら4つが勝手に実行されることはありません。
4つのアクション
1. 共有ブランチへのプッシュ。 フィーチャーブランチへのコミットは提案に過ぎません。しかし main や release へのプッシュはチーム全体が引き継ぐ決定であり、デプロイが紐付いていることもよくあります。事前に確認するコストは低く、元に戻すコストは高大です。
2. 削除。 ファイル、ブランチ、テーブル、バケット、リソース。削除は、意図を取り違えたときに次の判断で元に戻せない唯一の操作です。エージェントは自信満々に行動します。そして自信満々の削除によってバックアップが試されることになるのです。
3. 課金。 有料APIの呼び出し、リソースのプロビジョニング、ドメインの購入、キャンペーンの送信。リクエストした本人はコストがかかることを知らないかもしれません。しかし、支払う人間は知っておく必要があります。
4. クレデンシャルへのアクセス。 秘密鍵ファイルの読み取り、環境変数のエクスポート、サービスへのログイン、2要素認証の完了。ここに含まれるものはすべてアイデンティティに関わるものであり、アイデンティティはルームにいる誰かではなく、マシンのオーナーに属しています。
なぜ「完全な信頼」でもここで止めるべきなのか
権限モードは、エージェントとその人の関係性を定義します。読み取り専用、編集はできるがプッシュは不可、完全な信頼、などです。これは、エージェントがセッション中に行う数百回もの通常の呼び出しに対しては適切な粒度です。しかし上記4つのアクションに対しては不適切な粒度です。これらは稀で、不可逆またはコストが高く、その負担がリクエストした人以外の誰かにかかるためです。
したがって、muti のルールはシンプルです。いかなる権限テンプレートも、これら4つを通知なしで実行するように設定することはできません。「完全な信頼」モードであっても処理は停止し、タイムライン上で強調表示されます。プロンプトが表示される頻度は煩わしくない程度に低く、カテゴリが明確であるため、大抵の場合は判断に迷いません。
Claude Code の権限モードとの対応関係
Claude Code にはすでに段階的なラダーが存在します。plan（読み取り専用）、default（編集とコマンド実行の前に確認）、acceptEdits（編集は実行、コマンドは確認）、そして bypassPermissions（確認なし）です。これらのモードは、エージェントがあなたにどれだけ確認するかを定義します。一方、4つのアクションは、他人がリクエストしているときに、何がオーナーへの確認を必須とするかを定義します。これらは積み重なって機能します。
最後の列はルームによる追加機能であり、どの行でも同じです。権限モードの解説 をご覧ください。
誰に確認すべきか
ここが多くの設計で見落とされる部分です。共有エージェントが人間を必要とするとき、どの人間に確認すべきでしょうか？
- クレデンシャルはオーナーに届く。 ログイン、2要素認証コード、鍵へのアクセスはオーナーのアイデンティティに関わります。誰がタスクを開始したかにかかわらず、これらはオーナーにルーティングされます。リクエストした側には操作が引き継がれたことが表示され、シークレットそのものは見えません。
- 意図の確認はリクエストした人に届く。 「ステージングのデータベースのことですか？」といった質問は、その人が何を望んでいたかに関わるものです。これはリクエストした本人にルーティングされます。
- 双方が同じタイムラインを見る。 どちらかが相手にコンテキストを伝える必要はありません。質問とその回答は、作業と同じスレッドにそのまま残ります。
クレデンシャルや危険なアクションのプロンプトはオーナーにルーティングされ、意図の確認はリクエストした人にルーティングされます。やり取りは双方が閲覧できます。
優れた承認カードの構造
人間が5秒で判断できる承認カードには、5つの要素があります。
ボタンは3つ用意します。Approve、Decline、そして読み取り専用で続行するボタンです。3つ目は軽視されがちですが、リスクのあるステップを待たせたまま、残りの作業を進められる便利な選択肢です。
オーナーが普段いる場所ならどこからでも承認に回答できるようにします。コンソール、スマートフォン、あるいはチャットプラットフォームのカードなどです。1箇所で判断すれば、すべての場所に反映される必要があります。放置されたカードが1週間後に実行されてしまわないよう、有効期限を設定してください。
最大の敵は承認疲れ
表示されるプロンプトのすべてが、それを見る人間を条件づけます。多すぎれば、ユーザーはそれを無効化する設定を探すようになります。4つのルールを緩めることなく確認頻度を低く保つには、3つのポイントがあります。
- エージェントのスコープを絞る。 エージェントごとに作業ディレクトリを1つに限定すれば、触れる可能性のあるファイルが減り、アクセスに伴うプロンプトの回数も減ります。
- 通常の呼び出しには通常のモードを使う。 調査には読み取り専用、大半の作業にはプッシュ不可の編集モードを使います。「完全な信頼」は、普段自分のキーボードを直接叩かせるような相手にだけ限定します。
- デフォルトのテンプレートを実用的なものにする。 読み取り専用、編集はできるがプッシュは不可、完全な信頼、を名前付きのプリセットとしてあらかじめ提供します。これにより、誰もがゼロからポリシーを作成して間違えるのを防ぎます。
監査ログの1行
すべてのリクエストとすべての承認は、オーナーがエクスポートできる1行のログとして記録されるべきです。誰がリクエストし、誰が判断し、いつ、どのルールで、何が起き、何が使われたか。これを毎日読む人がいるからではなく、問題が起きた当日はロギングを始めるべきタイミングではないからです。
よくある質問
毎回確認するとエージェントの速度が落ちませんか？ 影響を受けるのはこれら4つのカテゴリだけであり、通常のセッションでは滅多に発生しません。一時停止によるコストは数秒ですが、ミスのコストは数時間、あるいは金額で測られることになります。
オーナーが自分自身のエージェントを使う場合はどうなりますか？ オーナー自身がエージェントを使う場合、権限モードの制限は受けません。ただし、完全な履歴を残すために、4つのアクションは引き続きタイムラインに記録されます。
リクエストした人が自分で承認することはできますか？ できません。承認権限はマシンのオーナーにあります。リクエストした側ができるのは、キャンセル、再試行、またはコンテキストの追加です。
muti のルームは、これらのルールが最初から有効になっており、オフにすることはできません。これが適切なデフォルトだと感じられたなら、ぜひエージェントにルームを用意してみてください。
公開日 · 更新日