私は普段、ClaudeとCodexをCursor使用していますが、最近プロンプトインジェクションなど、AIを狙った攻撃の記事を目にする機会が増えました。
ClaudeやCodexは、ファイルの編集やコマンドの実行だけでなく、Web検索や外部サービスとの連携もできます。便利な一方で、どこまで操作を任せるかは事前に考えておく必要があります。
ハーネス設定と安全面で最近設定を見直したので、今回この記事では、Codexを使い始めるときに確認したい安全設定と、普段の運用で気をつけたいことをまとめます。
まず、何を守りたいか決める
最初に考えたいのは、次の2点です。
-
.envや秘密鍵など、AIに扱わせる情報と扱わせない情報を決める - 削除、公開、外部送信、データ変更など、事前確認が必要な操作を決める
この2つを意識すると、必要な設定を選びやすくなります。
「操作できる範囲」と「確認」
Codexの安全設定を考えるとき、まずは「どこまで操作できるか」と「どの操作を確認に回すか」を分けて考えます。
- sandbox：Codexがそのまま操作できる範囲を決める仕組み
- approval：確認が必要な操作を、人またはレビュー用AIに回す仕組み
普段の作業をどこまで任せ、どの操作を確認に回すかを、それぞれ分けて設定できます。
設定は~/.codex/config.tomlへ記述します。
approval_policy = "on-request"
approvals_reviewer = "auto_review"
default_permissions = "example-profile"
[permissions.example-profile]
extends = ":workspace"
[permissions.example-profile.filesystem]
"<読み取りだけを許可する場所>" = "read"
"<読み書きを許可する場所>" = "write"
"<アクセスを拒否する場所>" = "deny"
[permissions.example-profile.network]
enabled = false
default_permissionsで通常使用するプロファイルを選び、extends = ":workspace"でワークスペース向けの操作範囲を土台にします。そのうえで、必要な場所ごとにアクセス範囲を追加します。
この設定例は仕組みを説明するためのもので、そのまま使用する設定ではありません。<>の部分は、自分の環境に合わせて置き換えます。
-
approval_policy：どの操作を確認に回すかを決める -
approvals_reviewer：確認を人とレビュー用AIのどちらに任せるかを決める -
default_permissions：通常使用するプロファイルを選ぶ -
extends = ":workspace"：ワークスペース向けの操作範囲を土台にする -
read：読み取りだけを許可する -
write：読み取りと書き込みを許可する -
deny：読み取りと書き込みを拒否する -
enabled = false：ローカルで実行するコマンドの外部通信を無効にする
実際に指定する場所は、利用しているOS、ツール、プロジェクト構成によって異なります。公開記事では特定のファイル配置を前提にせず、自分の環境を確認して設定します。
permission profilesは、執筆時点ではBeta（試験提供中）です。仕様が変わる可能性があるため、利用時は最新の公式ドキュメントを確認してください。
permission profilesは、従来のsandbox_modeや[sandbox_workspace_write]と重ねて適用されません。既存の設定から切り替える場合は従来の項目を外し、必要な内容をpermission profiles側へ設定します。
permission profilesが制限するのは、主にローカルで実行されるコマンドです。Web検索やMCPなどは、別の権限や承認設定を確認します。
AGENTS.mdで作業上の約束を伝える
sandboxで操作範囲を制限しても、「今回は調査だけしてほしい」「この値は勝手に決めないでほしい」といった作業の意図までは伝えられません。
こうした判断基準は、AGENTS.mdへ書きます。例えば、次のような内容です。
- 調査依頼ではファイルを変更しない
- 曖昧な「反映して」をcommitやpushと解釈しない
- 削除、外部送信、公開は実行前に確認する
- 指示された範囲だけ変更する
- 設定値や既存データを推測で決めない
- 完了報告前に必要な検証を行う
全プロジェクトに共通する内容と、そのプロジェクトだけのルールは分けておくと管理しやすくなります。
ただし、AGENTS.mdはCodexへの指示であり、OSレベルで操作を止める機能ではありません。必ず守らせたい操作範囲は、sandboxなどの設定と組み合わせます。
必要に応じてrulesとHooksを追加する
基本設定だけでは足りなくなったら、rulesやHooksを追加します。rulesは執筆時点では試験的な機能のため、利用する場合は最新の公式ドキュメントを確認してください。
rulesでは、コマンドごとに「許可する」「確認する」「禁止する」を分けられます。例えば、次のような使い方です。
-
git commitやgit pushは実行前に確認する - 管理者権限を使うコマンドは禁止する
- 外部公開やデプロイは無確認で許可しない
広い範囲のコマンドをまとめて許可すると、意図していない操作まで通る可能性があります。必要なコマンドだけに絞り、設定後はrules自体もテストします。
Hooksは、コマンドなどが実行される前後に内容を確認する仕組みです。例えば、rm -rfのような危険な削除を実行前に止められます。
ただし、Hooksですべての操作を検査できるわけではありません。sandboxの代わりではなく、追加の安全策として使います。
長い作業には停止条件を入れる
Codexに同じ作業を繰り返してもらう場合、「終わるまで続けて」と任せるだけでは、必要以上に処理を続ける可能性があります。
実行前に、次の3つを決めておきます。
- 何ができたら完了か
- 何回失敗したら止めるか
- どの操作でユーザーに確認するか
私は、削除、push、デプロイ、外部送信など、影響の大きい操作はループの中で自動実行させないようにします。
(完全に自動化してループをするなら実行させるべきたと思いますが、まだ信用しきれてないのでpushまでは基本止めて自分でするか許可して行ってもらうかをしています。)
Skillsとメモリ
繰り返し行う確認作業はSkillsとしてまとめられ、メモリは過去の訂正や失敗を思い出す補助に使えます。ただし、どちらも安全機能ではないため、codexを使用する上では設定した方が便利ですが、安全のためを目的とするならば別の考えが必要です。
設定を考える順番
最初からすべての機能を使うのではなく、必要な範囲から順に確認します。
- Codexに任せる作業範囲と、確認したい操作を決める
- permission profilesで、読み取り、書き込み、拒否する範囲を決める
-
AGENTS.mdへ、変更範囲や確認が必要な操作を書く - コマンド単位で制御したい場合は、rulesやHooksを検討する
まとめ
AIをコーディング以外でも使用する頻度が増えましたが、AIは便利だが信用しすぎないで大切なのは、AIの判断だけに頼らず、操作できる範囲を仕組みで制限しておくことが大切だと思いました。