安全に使う設定
安全設定の基本は、「全部オフにして楽をする」ではなく「理解した分だけ任せる」ことです。承認モードの既定は smart で、初期状態でも低リスクのコマンドは自動承認されます。だからこそこの章では、「何が自動で通り、何が止まるのか」という仕組みの理解と、任せるときの安全網の張り方を身につけます。
まず確認する初期値
安全性の設定画面で、次の初期値になっていることを確認してください。多くはそのままが推奨です。
| 設定 | 製品既定 | 推奨 |
|---|---|---|
| 承認モード | smart | smart。挙動を学ぶ間は manual |
| 承認タイムアウト | 300秒 | 300秒 |
| シークレットを伏せる | オン | オン |
| プライベート URL を許可 | オフ | オフ |
| ファイルチェックポイント | オフ | コード編集ではオン |
承認タイムアウトは確認待ちの秒数で、時間内に応答しなければ拒否扱いになります(フェイルクローズ)。
承認モードの3段階
承認モードは、エージェントの操作をどこまで人が確認するかを決めます。Manual → Smart → Off の順に人の関与が減り、その分だけ仕組みへの理解が求められます。
| モード | 動作 | 位置づけ |
|---|---|---|
| Manual | 承認対象コマンドをすべて人が確認する | 挙動を学ぶための観察モード |
| Smart | LLM レビュアーがコマンドを審査し、低リスクだけ自動承認する | 製品既定。日常利用の標準 |
| Off | 承認プロンプトを省略する | 隔離された使い捨て環境のみ |
smart では、危険パターンに一致したコマンドを、会話本体とは別の LLM レビュアー(補助モデル)が独立に審査します。低リスクなら自動承認、明確に危険なら自動拒否、判定に迷う場合だけ従来どおり人に確認が届きます。判定はそのコマンド1回限りで、同じパターンに一致する後続のコマンドも毎回審査し直されます。一度何かが通ったからといって、以後の類似コマンドが素通りになるわけではありません。
offでも、致命的な破壊操作のハードブロックや後述のapprovals.denyなど一部の防御は残ります。しかし人による確認を失うので、offは「安全」と同義ではありません。手元の常用端末では使わないでください。
学び方 ─ まず manual で観察し、理解できたら smart に戻す
既定の smart のまま使い始めても構いません。ただし入門のあいだは、「どんなコマンドが承認対象になり、何が自動で通るのか」を一度自分の目で見ておくことを勧めます。
- 前提: 第5章までのセットアップが済んでいて、設定の「安全性」画面を開ける。
- 操作と進め方:
- 承認モードを
manualに切り替えます。設定の「安全性」のほか、ステータスバーの承認モードメニュー(手動 / スマート / オフ)からも切り替えられます。 - 数回のセッションで普段どおり作業し、どんなコマンドで確認が出るか、自分ならどう判断するかを観察します。
- 傾向が読めたら、
smart(既定)に戻します。 offは、使い捨てのサンドボックス・最小限の資格情報・限定したネットワーク・成果物のレビュー体制がすべて揃う自動化のときだけ検討します。便利だからという理由で常用環境に使わないでください。
- 承認モードを
- 期待結果:
manualの間は、承認対象コマンドごとに確認が表示されます。smartに戻すと、低リスクのコマンドは確認なしで通り、判定に迷うものだけ確認が届くようになります。 - 失敗時: 切り替えたのに挙動が変わらない場合は、操作したプロファイルと会話中のプロファイルが一致しているかを確認してください(デスクトップの承認モードはプロファイル単位で保持されます)。詳細は 安全性 を参照してください。
Manual → Smart → Off と、一段ずつ「理解した分だけ」任せるという原則は変わりません。挙動がまだ読めないうちは、いつでも manual に戻して観察し直してよいのです。
smart の安全網 ─ approvals.deny
「万一、危険なコマンドが低リスクと誤判定されたら」という不安には、無条件拒否ルール approvals.deny で備えます。絶対に実行させたくないコマンドのパターンを書いておくと、承認モードに関係なく ─ off でも ─ 実行前に無条件でブロックされます。
設定画面には項目がなく、設定ファイル ~/.hermes/config.yaml に直接書きます。
approvals: deny: - "git push --force*" - "*curl*|*sh*"パターンは大文字小文字を区別しないグロブ(* などのワイルドカード)で、YAML では各パターンを必ずクォートします。最初は「force push」「パイプ経由のスクリプト実行」のような、自分の環境で絶対に越えたくない一線を 2〜3 個書けば十分です。書式の詳細と注意点は 無条件拒否ルール(approvals.deny) を参照してください。
その他の安全設定
コマンド許可リスト
特定のコマンドを将来のセッションでも自動承認させる一覧です。rm、sudo、パッケージ公開、クラウド変更など範囲の広いパターンは登録しないでください。登録するなら頻用する低リスク操作だけに絞ります。
シークレットを伏せる
APIキーやトークンに見えるパターンを、ツール出力が会話やログに入る前に可能な範囲で伏せます。オンのままにしてください。ただし完全な漏えい防止ではないので、ログやファイルに平文の秘密値を置かない運用も併せて必要です。
プライベート URL
localhost やLAN、社内ネットワーク、クラウドのメタデータなどへのアクセスに関わります。「プライベート URL を許可」の既定はオフです。ローカル開発サーバーを操作するときだけ、必要な範囲で有効にしてください。
ファイルチェックポイント
ファイル変更前にスナップショットを残す機能です。コード編集が多いならオンにすると、戻す手段が一つ増えます。ただしGitコミットやバックアップの代わりにはなりません。
安全チェックリスト
設定を一度通しで点検したいときは、安全に設定するための確認事項のチェックリストが便利です。初期設定では特に次を確認します。
- 作業ディレクトリを専用プロジェクトに限定した
- 承認モードを理解して選んでいる(既定は
smart。挙動を学ぶ間はmanual) - 絶対に実行させたくないコマンドを
approvals.denyに書いた(smartやoffを使うなら特に推奨) - シークレットを伏せる設定がオン
- プライベート URL は必要になるまでオフ
- ファイルチェックポイントを有効化した(コード編集時)
問題が起きたら
危ない操作が始まった、設定を変えたら様子がおかしい、というときは次の順で対応します。
- 実行中の操作を停止する(コンポーザーで
Esc)。 - リモートゲートウェイを使っているならローカルへ戻す。
- 直前に追加したMCP・キー・プライベートURL許可を無効化する。
- ログとエラー表示を確認する。
- 設定の書き出しと現在値を比較する。
次の一歩
安全の土台ができたら、能力を広げる仕組みに進みます。MCPで能力を広げる(入門)では、外部ツールを接続する利点と、その前に知っておくべき危険性を扱います。
関連リファレンス: 安全性 / 安全に設定するための確認事項 / 推奨設定プリセット
© 2026 Hermes Desktop ガイド(非公式)。引用・部分転載は、出典として本ページへのリンクを添えていただければ歓迎します。記事全文の無断複製・転載はご遠慮ください。