「承認して、って毎回書けば安全？」
Tomoya先に答えます。
安全側は、依頼文で止めどころを明示しつつ、SettingsのAsk firstを既知の操作にNarrowに置くことです。
全部自動でも、毎回のお願い文だけでも足りません。
読む時間は約10分です。
ポイントは次の3つです
- 依頼文の境界とAsk firstは別レイヤです。承認は提案中のアクションに効き、完了済みは巻き戻しません（xAI Approvals）。
- Ask firstは常に止め、Allow automaticallyは他理由が無いときだけ進み、衝突時はAsk firstが勝ちます。ルールは既知アクション＋スコープに狭く書きます。
- Auto-reviewは補完です。読取・下書きから始め、送信・公開・購入・削除・本番は承認の後ろ。Botを分けてもセキュリティ境界にはなりません。
| よくある質問 | 答え |
|---|---|
| Ask firstとAllow automaticallyは？ | Ask firstは常に止める。Allowは他理由が無いときのみ |
| 何を止めるか？ | 送信・公開・削除・購入・本番など、既知操作にNarrow |
| 承認は未実行のみ？ | 提案アクションのみ。完了済みは戻らない |
| Bot分離は境界？ | ならない。クラウドPCはアカウント共有 |
Ask firstと依頼文の境界の関係
xAI公式は、依頼文で「できること」と「止めどころ」を明示せよ、と書きます。
例として、照合と予算変更案までは作るが、キャンペーン変更や代理店連絡はするな、案を見せてから承認を求めよ、という書き方です。
承認はその提案アクションを許可／拒否するもので、すでに終わった作業は取り消しません。
Cursorのセキュリティ説明も、最も強い境界はリクエスト自体にある、と繰り返します。
Auto Reviewはその後ろの独立レビュー層で、shell・plugin・computer use・automation書き込み・Cloud Agentなどのリスクある行動を、実行前に評価します。
| レイヤ | 役割 | 例 |
|---|---|---|
| 依頼文の境界 | その仕事の止めどころを文章で固定 | 「下書きまで。外部送信するな」 |
| Ask first（Auto-review） | 一致する操作は常に人間確認 | 「外部メール送信の前はAsk first」 |
| Allow automatically | 他理由が無いときだけ自動進行 | 特定パスの git status など |
わかりやすく言うと
依頼文が「今日の仕事の看板」なら、Ask firstは「特定のドアにだけ鍵をかけるルール」です。
看板が無いと鍵の意味が薄く、鍵が無いと看板だけでは漏れます。
FAQは、要承認はツール・リスク・Auto-review次第だと書き、各Bot説明に常設境界を置き、送信・公開・削除・購入・本番変更などへNarrowなAsk firstを足せ、と案内します。
| 条件 | 行動 |
|---|---|
| 今日だけの例外 | 依頼文に止めどころを書く |
| 何度も同じ危険操作 | NarrowなAsk firstをSettingsに足す |
| 対象が読めない承認カード | 許可しない。平文で説明させるか下書きに戻す |
週次振り返りや朝の優先で「承認を挟む」話の手順そのものは、ここでは再説しません。
NarrowなAsk firstルールの置き方
公式例は、既知のアクションとスコープに狭く書くことです。
- 外部メールを送る前はAsk first
- 本番ダッシュボードを変える前はAsk first
/workspace/reportsでgit statusを走らせるときはAllow automatically、など
避けるべきは、「ブラウザですべて許可」のような広いルールです。
サイトやツールの挙動は変わる、とApprovalsページは注意します。
Tomoya手順は次の3つです。
- 自分が怖い操作を3つまで名前で書く（例: 外部メール、公開、本番設定変更）。
- それぞれ「操作＋対象の範囲」までNarrowにしたAsk firstを1本ずつ足す。
- Testや実作業のあとに、止まった／止まらなかったを見て、広すぎる文言だけ直す。
ソロ向けの「Ask first推奨リスト」の公式完成版はありません。上の3つはあなたが自分の運用から選ぶ事実です。
| 条件 | 行動 |
|---|---|
| ルールが「全部」「なんでも」を含む | 書き直して狭くする |
| 同じ操作で何度も止まって疲れる | 対象を絞ったAllowを検討（Ask firstと衝突させない） |
| チーム強制のAuto-reviewがある | 自分のルールはより厳しくする方向だけ（公式） |
Enterpriseの長い統制画面の解説は、この記事の主軸にしません。
日々のTodoに関して「承認プロセス」を作り一呼吸置く事を行っています。
これによって余計な作業で間違った完了になる事を防げます。何をやるのかを報告してもらう事で優先順位をつけて緊急の要件を把握できBot側でできるなら作業を依頼し、できない要件は今日のTodoとして予定します。
least-privilege。読取・下書きから、送信等は後ろ
Auto-reviewは、すべての副作用を見るわけではありません。
Cursor公式は、メモリ書き込みや多くの設定変更などを例に挙げ、明示境界とleast-privilege（最小権限）の補完だと書きます。ネットワーク方針や都度承認など、モデル判断に依存しない層と一緒に使え、ともあります。
ソロ運営で先にやる安全側は次です。
- つなぐコネクタは、その週次や定例に必要なものだけ。
- 最初の仕事は読取と下書きに限る。
- 送信・公開・購入・削除・本番変更は、依頼文でもAsk firstでも後ろに置く。
Botを増やしても、クラウドPC上のファイルやブラウザセッションはアカウント共有です。
FAQもApprovalsも、「別Bot＝セキュリティ境界」ではない、と明記します。
共有リンクでBotを渡すときも、設定はコピーされますがPCやログインは渡りません。秘密をBot設定に書かない、は別の話として残ります。
| 条件 | 行動 |
|---|---|
| 新しい定例を足す | まず読取・下書きだけで試す |
| 対外アクションが必要 | 承認カードの対象を読んでから許可 |
| もう使わないログイン | サインアウトとコネクタ解除を忘れない |
料金の数字や、役割マップ・学習モード・最初の課金の本論は扱いません。
ここで迷いやすい点
- 依頼文の「承認して」だけで、SettingsのAsk firstを省略しない。
- 「ブラウザ全部許可」で楽をしない。
- 承認カードの対象が読めないのにAllowしない。
- Botを分けただけで権限が分かれたと思わない。
まとめと次の行動
- 依頼文の境界とAsk firstはセット
- Ask firstは既知操作にNarrow
- 読取・下書きから始め、送信等は後ろ
次の行動は2つです。
Go1：怖い操作を3つ名前で書く。
Go2：そのうち1つだけNarrowなAsk firstを足して、実際に一度止めてみる。
※本記事は xAI Approvals／FAQ と Cursor Grok Bot security に基づきます。Enterprise専用の長い統制は主軸にしていません。製品文言は変わり得ます。
コメント