ターミナル型のAIコーディングツールを初めて使う前に決める権限と確認の設定

1. 起動前に決める4つの線

許可範囲は「ツール名」ではなく「操作の種類」で考えると決めやすくなります。次の表は編集上の提案で、初回向けの初期値です。

• ファイルの読み取り、初回の初期値：作業フォルダの中だけ許可、理由：読むだけなら元に戻す必要がなく、AIが状況を理解する土台になる
• ファイルの変更、初回の初期値：1回ごとに差分を見て承認、理由：変更の粒度と内容を、自分の目で覚える
• コマンド実行、初回の初期値：1回ごとに承認(「今後も常に許可」は選ばない)、理由：何のコマンドが提案されるか、傾向を知る
• ネットワーク通信・削除・Git操作、初回の初期値：許可しない、理由：影響が作業フォルダの外や共有リポジトリに及びうる

この表で一番注意したいのは、「作業フォルダの中だけ」という線が、ツールによって強さが違う点です。Claude Codeのセキュリティ解説によると、手動確認モードでは起動したフォルダの外へのファイルツールによる読み書きは確認が出ますが、これはあくまで許可の確認画面です。自分が承認したBashコマンドは、ユーザーアカウントが書き込める場所ならどこにでも書けてしまう、と説明されています。OSレベルで制限したい場合はサンドボックスを使う、という位置づけです。つまり「フォルダ内に限定した」と思っていても、承認したコマンドの中身を見ないと、その線は守られません。

2. 起動前の準備:捨てても困らない場所で始める

初回は、本番のリポジトリではなく練習用のフォルダを使います。

1. 新しいフォルダを作り、git initでGit管理にする(変更をgit diffで見られ、戻せる状態にするため)
2. 小さなファイルを2〜3個置く(説明用の例は後述)
3. パスワード、APIキー、顧客データ、.envファイルは置かない。必要なら架空の値に置き換える
4. 他のフォルダに重要なものがあるなら、そこでは起動しない

Claude Codeでは、ホームディレクトリで起動すると信頼の確認が毎回出る仕様もあります。プロジェクト用のサブフォルダから起動する方が、設定も保存され扱いやすくなります。

3. 起動時の権限モードを確認する

ここが見落としやすいポイントです。ツールの既定が、あなたの想像より広い可能性があります。

Claude Codeの場合

公式の権限モードのページでは、モードとしてdefault(Manual)、acceptEdits、plan、auto、dontAsk、bypassPermissionsが挙げられています。同ページによると、Claude Code v2.1.283以降の対話型ターミナルとVS Codeの組み込み開始モードはAutoです。それより前のバージョンでも、Pro、Max、TeamプランではAutoが標準の場合があります。Autoでは分類器モデルが行動を審査するため、初期状態が「毎回自分に聞く」とは限りません。

そこで、初回は開始時にモードを指定します。

# 計画だけ作らせる。ファイル編集はあなたが承認するまでブロックされる
claude --permission-mode plan

# 毎回確認する通常の手動モードで始める場合
claude --permission-mode default

セッション中はShift+Tabでモードを切り替えられます。標準のサイクルはauto → default → acceptEdits → planで、利用可能な任意モードがplanの後に入る場合があります。うっかりacceptEditsで止まると、ファイル編集に加えてmkdir、mv、cp、rm、sedなども自動で通ります。初回は避けてください。

手動モードの挙動は、権限設定のページの表で次のように整理されています。読み取り(作業ディレクトリと追加ディレクトリ内)は確認なし、Bashコマンドは組み込みの読み取り専用コマンド(ls、cat、git statusなど)を除いて確認あり、ファイル変更は確認あり、Web検索も確認ありです。

承認画面の「今後は聞かない」系の選択肢には注意が必要です。同じ表では、Bashコマンドの場合は「リポジトリとコマンドごとに恒久的」、ファイル変更の場合は「セッション終了まで」とされています。初回は、Bashについては「今回だけ」の選択肢を選びます。

ネットワークに出るコマンドを明示的に止めたいときは、設定ファイルのpermissions.denyが使えます。セキュリティ解説はcurlやwgetが既定では自動承認されないこと、拒否ルールの例としてBash(curl *)を挙げています。ただし拒否ルールはコマンドを書かれたとおりに照合するため、通信そのものを確実に止めるにはサンドボックスのネットワーク分離が必要とも説明されています。設定例は次のとおりです(.claude/settings.json)。

{
  "permissions": {
    "defaultMode": "plan",
    "deny": ["Bash(curl *)", "Bash(wget *)"]
  }
}

defaultModeの項目とpermissions.deny、Bash(curl *)という書式は公式ページの記載に沿っています。wgetの行は同じ書式を当てはめた私の編集で、この設定ファイル自体を実行して試したわけではありません。

Codex CLIの場合

OpenAIの承認とセキュリティのページ(旧developers.openai.com側から転送されます)では、サンドボックスにread-only、workspace-write、danger-full-accessがあります。承認ポリシーはon-requestなどです。ページによると、Gitで管理されたフォルダで起動するとworkspace-writeとon-requestの組み合わせ(Autoモード)が推奨され、Git管理外では読み取り専用が既定です。workspace-writeではコマンドのネットワークアクセスは既定でオフです。ワークスペースには現在のディレクトリと/tmpなどの一時ディレクトリが含まれ、書き込み可能なルート内にも保護されたパスがあります。

初回に最も狭く始める起動は、公式の例にある次の形です。

codex --sandbox read-only --ask-for-approval on-request

--dangerously-bypass-approvals-and-sandboxは名前のとおり承認とサンドボックスをどちらも外すオプションなので、初回には使いません。

他のツールでも、確認する項目は同じです。「起動時のモードは何か」「書き込み範囲はどこまでか」「通信は既定でオンかオフか」「確認を省略する選択肢は何を永続化するか」の4点を、ドキュメントか設定画面で見てから使い始めてください。

4. 最初の一回:3段階で進める作業例

以下は説明用の例で、実際に実行した結果ではありません。練習フォルダに次のような小さなPythonプロジェクトがある想定です。

practice/
  utils.py        # 文字列を整える関数が2つ
  tests/test_utils.py
  README.md

ステップ1:読むだけ(変更なし)

このフォルダの構成を読んで、utils.pyの各関数が何をするか日本語で3行以内で説明してください。
ファイルの変更、コマンド実行、ネットワークアクセスはしないでください。

確認すること:承認画面がほぼ出ずに答えが返るか。出たなら、何を要求されたかを読みます。読み取り中心の依頼で書き込みや通信を要求されたら、その時点で一度止めて理由を尋ねます。

ステップ2:計画だけ作らせる

utils.pyのtrim_spaces関数に、日本語の全角スペースも除去する処理を追加したいです。
変更するファイル、変更内容の要点、確認用に実行するコマンドを、実行せずに箇条書きで出してください。

確認すること:変更対象がutils.pyとtests/test_utils.py程度に収まっているか。想定外のファイル(設定ファイル、.git配下、ホームディレクトリのファイル)が入っていたら計画を差し戻します。

ステップ3:1ファイルを変更し、テストを1回実行する

先ほどの計画のうち、utils.pyの変更だけを実施してください。
変更後に実行するコマンドは「python -m pytest tests/test_utils.py」の1つだけです。
それ以外のコマンドが必要になったら、実行せずに理由を説明して止まってください。

承認画面では次の順に見ます。

1. 差分:依頼した関数以外が変わっていないか
2. コマンド文字列:依頼したテストコマンドと一致しているか。&&や;で別のコマンドが連結されていないか
3. 対象パス:練習フォルダの外を指していないか
4. 選択肢:「今回だけ」を選ぶ

終わったら、git diffで実際の変更を自分で確認します。AIの「変更しました」という報告だけで済ませないでください。

5. 許可範囲の決め方メモ(コピー用)

初回が終わったら、次のメモを埋めます。チームで使うなら、共有の設定ファイルを決める前の合意メモとしても使えます。

【AIコーディングツール 許可範囲メモ】日付:____  ツール/バージョン:____

■ 使う場所
- 作業フォルダ:____(Git管理 はい/いいえ)
- 置かないもの:鍵・.env・顧客データ・____

■ 起動時のモード
- 初回:____(例:plan/read-only)
- 通常:____

■ 許可してよいもの(今回確認済みのもの)
- 読み取り:____の配下
- コマンド:____(例:テストの実行のみ)

■ 毎回確認するもの
- ファイル変更、新規コマンド、____

■ 許可しないもの
- ネットワーク通信、削除、git push、作業フォルダ外への書き込み

■ 広げる条件
- 同じ種類の承認を ___ 回、内容を読んだうえで問題なく承認できた
- 広げる範囲は1項目ずつ。広げた日付と理由を記録する

「広げる条件」の回数は、決まった正解がないので、自分で数字を決めてください。ここで大事なのは、一度に1項目だけ広げることです。たとえば、テスト実行コマンドを常時許可にして、ファイル変更の確認は残す、という順です。

6. 次の段階に進む前の判断基準

• 承認画面の内容を毎回読んで理解できている、判断：繰り返し出る安全なコマンド1つを許可に追加してよい
• 承認画面を読まずに押している、判断：範囲を広げず、いったん止める。許可を広げても疲れが増えるだけです
• 想定外のファイルやパスが提案された、判断：許可は広げず、依頼文に「変更してよいファイルはこれだけ」と書き足す
• 通信や削除、Git操作が必要な作業になった、判断：練習フォルダではなく、別の隔離環境(コンテナなど)や、内容を読んだうえでの個別承認を検討する

承認操作を減らす目的でAutoモードや承認の自動化を使うのは、その後の選択肢です。どのツールの公式ドキュメントも、自動化は人の確認を別の仕組みに置き換えるものだと位置づけています。何が自動で通るのかを説明できる状態になってから使ってください。