Mistral Vibe の自動承認:実行は任せて、記録は承認制に
Mistral Vibe の自動承認が実際に承認するもの、有効化の方法(エージェント、Shift+Tab、--auto-approve と --yolo)、それでも確認されるケース、安全な設定——そして誰も設定しないもう半分:実行の判断はどこに記録されるのか。

Mistral Vibe の「自動承認」は、一つのスイッチではありません。四段階のダイヤルであり、無人実行のためのフラグであり、質問をすべて止めたつもりでもなお確認してくる例外の集まりです。本ガイドは仕組みの全体をたどります——各設定が実際に何を承認するのか、有効化の方法、境界が残る場所——そして、設定画面では扱えないもう半分に進みます。エージェントが自由に走ったあと、その判断はどこに記録されるのか。
ダイヤルの四段階
Vibe では、有効なエージェントが何を自動承認するかを決めます。エージェントは設定の上書きであり——システムプロンプト、ツールの選択、承認ルールをひとまとめにできます——内蔵は四つです。
| エージェント | 自動承認するもの | なお確認されるもの |
|---|---|---|
ask | 何も | すべてのツール呼び出し |
accept-edits(デフォルト) | ファイル編集 | シェルコマンドとその他の機微なツール |
smart-approve | 分類モデルが安全と判断したツール呼び出し | リスクありと判断された呼び出し——リスクのある呼び出しは、あなたの確認なしには決して実行されません |
auto-approve | シェルコマンドを含む、すべてのツール実行 | ツール層では何も(ただし以下の例外は有効) |
極端な段階に手を伸ばす前に、知っておくべきことが二つあります。smart-approve は段階的に展開中であり、Mistral のドキュメントはその正体について率直です。これは分類器であって、サンドボックスではありません——安全と判断された呼び出しは、あなた自身のアカウントの完全な権限で実行されます。そして auto-approve には、ベンダー自身の警告ラベルが付いています。信頼できるサンドボックス環境でのみ使うこと。
有効化の方法
対話セッションでは、Shift+Tab でエージェントを循環させます——入力欄の枠にあるモード表示が、現在のエージェントを示します——あるいは、望むモードで起動します。
vibe --agent auto-approve
モードをデフォルトにするには、Vibe の設定で default_agent を指定します。プロンプトの場で一件ずつ処理することもできます。1/y は一回だけ許可、2 はそのセッションの間許可、3 は常に許可、4/n は拒否です。
プログラムモード(vibe --prompt …)ではルールが変わります。プロンプトに答える人がいないからです。Vibe はあなたのデフォルトエージェントを使い、承認が必要なツール呼び出しはそのまま拒否されます。無人実行ですべての呼び出しを承認するには:
vibe --prompt "…" --auto-approve
--yolo は同じフラグの別名です。制限は二つ。Mistral のドキュメントはこれにも同じ条件を付けています——サンドボックス環境でのみ。そして管理者が enable_auto_approve = false を設定している場合、Vibe は両フラグを完全に無視します。
それでも確認されるもの(そして遮断され続けるもの)
自動承認の範囲は広いですが、それが唯一の層ではありません。次の統制がエージェントのモードと並んで存在します。
- 作業ディレクトリの外側。 作業ディレクトリ(または
--add-dirで追加したディレクトリ)の外へ到達するツールは、すべての呼び出しが自動承認されていない限り、確認を発します。outside_workdir = "deny"と設定すれば、尋ねる代わりにそのまま拒否します。 .envファイル。 ツールが.envと.envrcを読んだり編集したりする前に、Vibe は必ず確認します——そのツールの権限がalwaysに設定されていてもです。ツールのallowlistにパスを入れることが、これらの確認を飛ばす、ドキュメントに明記された例外です——だからこそ allowlist そのものが、便宜ではなくセキュリティ上の判断になります。- ツールごとの権限。
config.tomlでは、各ツール——内蔵、MCP、コネクタ——を ask、always、never に設定できます。bashツールはさらに、コマンド接頭辞による allowlist と denylist を受け付けます。 - あなたの権限ルールが最初に適用されます。 どのエージェントモードでも、allowlist のコマンドは実行され、denylist のコマンドは遮断され続けます。
賢明な設定
Mistral 自身のガイダンスに、仕組みから導かれる当然の結論を加えたものです。
- 日常の仕事:
accept-editsに留まるか、届いていればsmart-approveを。MCP とコネクタのツール——外部システムに触れるものすべて——は、この段階でもpermission = "ask"を保ってください。 - 慣れないコード:
askに落とし、危ない実行の前にコミットして、git reset --hardをあなたの巻き戻しにしてください。 auto-approve: 使い捨ての環境——コンテナ、CI ランナー、一時的な VM——のために取っておくこと。SSH キー、クラウドの認証情報、本番アクセスを持つマシンでは決して使わない。この一文は Mistral のもので、私たちのものではありません。.vibe/設定をバージョン管理下に置くこと。チームの安全判断が、コードと同じようにレビューされ、再現できるように。
もう半分:実行は承認した——記録はどこにあるのか
Vibe における承認が統制するのは、ツールが実行されるその瞬間です。それは設計上、儚いものです。セッションの承認はリセットされ、分類はメモを残し、ターミナルを閉じれば残るのはコードの diff だけです。しかし、長時間の自動承認された実行が生むのは、コードだけではありません。判断も生みます——なぜこの移行の形なのか、どの回避策が受け入れられたのか、エージェントがあなたのシステムについて何を結論づけたのか。そして多くの設定では、それらはセッションとともに蒸発します。次の実行、あるいは次の同僚は、コードを前にして理由を再び推測することになります。
これは、私たちが Mistral Vibe 向けに作った知識ベースが中心に置く区別と、まったく同じものです。フォルダを信頼することと、その出力を承認することは別です。環境が安全に許す範囲で Vibe を自由に走らせてください——そして、その生んだものに行き先を与えてください。事実はレコードとして着地し、重みのあるものは diff を伴う変更リクエストとして人が受け入れるのを待ち、エージェントが次に従うべきルールは、行動の前に読むスキルとして存在する。Vibe は MCP 経由でその層に接続できます(接続ガイド)。キーストロークは自動化してよい。承認は記録の上に残してください。
よくある質問
--yolo は --auto-approve と違いますか。 いいえ。Mistral のドキュメントは --yolo を、プログラムモードにおける --auto-approve の別名として記載しています。どちらもすべてのツール呼び出しを承認し、管理者が自動承認を無効化している場合はどちらも無視されます。
自動承認にすれば、仕事のマシンで無人実行しても安全ですか。 いいえ——ドキュメント自体がそう言っています。自動承認が取り除くのはプロンプトであり、リスクではありません。呼び出しはあなたのアカウントの完全な権限で実行されます。無人実行は、サンドボックス化された使い捨て環境のものであり、破壊的な操作にはツールごとの denylist を組み合わせてください。
smart-approve を使えば、ツールごとの権限はもう要りませんか。 要ります。Smart approve は呼び出しを一件ずつ分類します。ツールごとの権限は、分類に先立って適用される常設のポリシーです。二つの層は合成されます——まずポリシー、次に判断——そして外部に面したツールについては、permission = "ask" が依然として正しい常設ポリシーです。