AIコーディングの変更権限マトリクス

本記事の製品仕様の確認日は2026年7月24日です。

AIコーディングエージェントを使うと、正反対の不満が同時に生まれます。「頼んでいないコミットやデプロイまで進めた」「関係のないファイルも直した」という暴走への不安と、「安全なテストのたびに止まる」「非対話実行なのに承認待ちで終わる」という停滞への不満です。

この対立は、Claude CodeとCodexのどちらが優秀かを決めても解消しません。必要なのは、製品名ではなく操作の影響に応じて権限を配ることです。ファイルの読み取りと本番デプロイを同じ「実行」と呼ばず、ローカル編集と外部公開の間にも段階を置きます。

この記事では、操作を次の四段階に分けます。

分類	意味	人の関与
自動可	範囲と検証方法が固定され、失敗してもローカルで戻せる	実行前の確認は不要。実行ログと結果は残す
条件付き	事前に決めた条件をすべて満たす場合だけ自動可	条件外なら止める。条件は機械判定できる形にする
毎回確認	その案件、その対象、その時点について人が許可する	過去の許可を別案件へ流用しない
禁止	エージェントに権限や秘密を渡さず、依頼されても実行させない	必要なら人が別の管理経路で行う

ここでいう「自動可」は、特定製品の画面にあるAutoモードと同義ではありません。本記事の変更権限マトリクスは、組織や個人が先に決める運用ルールです。製品の承認設定、OSのサンドボックス、GitHubのブランチ保護を組み合わせて実装します。

なぜ「全部許可」と「全部確認」の二択では失敗するのか

現場の不満を整理すると、問題は能力より境界にあります。

Claude Codeについては、依頼を広く解釈してコミット、プッシュ、デプロイ、周辺修正まで進めるのではないかという警戒がある。
Codexについては、サンドボックス外アクセスや承認が必要な処理で止まり、非対話実行の価値を失うのではないかという不満がある。
両方に対して、過設計、指示無視、偽完了、架空APIという四つの悪癖が懸念される。
サブエージェントを何体使うかだけでなく、各担当が使えるツール、書ける場所、実行できるコマンドを利用者自身が決めたいという需要がある。

これらは利用者の報告や運用上の需要であり、全セッションに共通する製品仕様ではありません。実際、OpenAIはCodexにサンドボックスと承認ポリシーを用意し、AnthropicはClaude Codeにallow、ask、denyの権限規則と複数の権限モードを用意しています。どちらも設定次第で挙動が変わるため、非公式の利用感を公式機能として断定してはいけません。

需要の存在は、公式リポジトリの公開Issueにも表れています。Codexでは似たコマンドへの承認を再利用しやすくしてほしいという要望、非対話MCP実行で広すぎる権限を避けたいという要望があります。Claude Codeではサブエージェントへ権限規則を一貫して伝えたいという要望や、ファイル編集権限から設定を書き換えられたという報告があります。Issueは特定条件での報告であり、現行版すべての再現を保証する一次仕様ではありません。それでも、利用者が「強すぎる権限」と「弱すぎる権限」の間を求めている需要証拠にはなります。

ツールの基本的な違いを先に把握したい場合は、Claude CodeとCodexの使い分けも参照してください。この記事では勝敗ではなく、どちらにも適用できる境界設計へ集中します。

先に分離すべき三つの制御

エージェントへの指示文だけで安全を作ろうとすると、「書いてあるのに守られなかった」で終わります。少なくとも次の三層を分けます。

制御層	決めること	例
意図の層	何を完成とし、何をしないか	「テスト修正まで。コミットしない」
実行境界の層	技術的に読める場所、書ける場所、通信先	作業フォルダだけ書き込み可、ネットワーク無効
反映の層	変更を共有・公開・本番へ運べる主体	pushは人、デプロイは保護環境の承認者

OpenAIの公式文書では、Codexのローカル実行はOSによるサンドボックスと承認ポリシーを組み合わせます。workspace-writeでは作業領域内の読み取り、編集、コマンド実行が可能で、作業領域外の編集やネットワーク利用には承認が必要になる構成が示されています。既定の作業領域内でも.git、.agents、.codexは保護された読み取り専用パスです。

Anthropicの公式文書では、Claude Codeの権限規則はdeny、ask、allowの順で評価され、プロンプトやCLAUDE.mdは試みる行動を方向付けても、実際の許可境界を変更しないと説明されています。さらにBashサンドボックスでは、ファイルシステムの隔離とネットワークの隔離を独立して設定できます。

つまり「してはいけないと書く」だけでなく、「できないようにする」「反映先で再確認する」が必要です。プロンプトインジェクション対策で扱う、外部文書を命令として実行しない原則も同じ三層へ入ります。

変更権限マトリクスの基準版

次の表は、小規模な個人開発から始めるための基準版です。業務、公開サイト、秘密を含む環境では後述のケース別補正を上に重ねます。

番号	操作	基準分類	自動化できる条件	必ず残す証拠
1	作業フォルダ内の読み取り	自動可	秘密ファイルを除外し、対象が依頼範囲内	読んだ主要ファイル一覧
2	作業フォルダ外の読み取り	毎回確認	目的、絶対パス、必要性が示される	許可対象と読取結果
3	ローカルの新規作成・編集	条件付き	指定範囲内、可逆、差分確認可能、秘密なし	変更ファイル一覧とdiff
4	フォーマッターによる機械整形	条件付き	対象を限定し、意味変更がないと検査できる	実行コマンドと差分件数
5	既存のlint・型検査・ビルド	自動可	既知コマンド、外部副作用なし、秘密不要	終了コードと全出力
6	既存の単体・統合テスト	自動可	ローカルまたは隔離環境、実データ不使用	終了コード、成功数、失敗内容
7	外部サービスへ接続するテスト	毎回確認	専用テスト環境、送信データ、費用上限が明確	接続先、送信範囲、結果
8	依存関係の追加・更新	毎回確認	パッケージ名、版、目的、ライセンス、差分を提示	lockfile差分と監査結果
9	Gitの状態・差分・履歴の読み取り	自動可	読み取り専用コマンドに限定	実行コマンドと対象ブランチ
10	`git add`によるstage	条件付き	対象ファイルを明示し、全体stageをしない	stage済みファイル一覧
11	`git commit`	毎回確認	その差分、そのメッセージへの個別許可	commit IDと含有ファイル
12	`git push`	毎回確認	remote、branch、非forceを個別許可	push先と送信commit
13	Pull Requestの作成	毎回確認	公開範囲、タイトル、本文、送信差分を確認	PR URLとbase/head
14	ステージングへのデプロイ	毎回確認	専用環境、ロールバック、費用上限が確認済み	対象版、実行者、結果
15	本番デプロイ・公開	毎回確認	保護環境、承認者、監視、復旧手順がそろう	リリースID、承認記録、監視結果
16	ファイル・ブランチ・データの削除	毎回確認	対象を列挙し、バックアップまたは復旧手段がある	削除対象と復旧可否
17	強制push、履歴書換え、復旧不能な削除	禁止	エージェントには実行権限を渡さない	人が別経路で行った場合の監査記録
18	APIキー、秘密鍵、認証コードの読み取り	禁止	値そのものをエージェントへ見せない	秘密を伏せた接続成否だけ
19	ログイン、OAuth同意、MFA承認	毎回確認	人が公式画面で対象権限を確認して操作	付与したscopeと期限
20	有料API・クラウド資源の利用	毎回確認	単価、最大回数、上限額、停止条件が明確	利用量と費用
21	課金設定・契約・予算上限の変更	禁止	エージェントに請求権限を渡さない	人の変更記録
22	設定・権限規則・フックの変更	毎回確認	変更前後、影響範囲、戻し方を確認	設定差分と有効性検査
23	バックグラウンドでの長時間実行	条件付き	時間上限、出力上限、停止方法、対象が固定	task ID、終了理由、最終出力
24	サブエージェントの起動	条件付き	担当、使えるツール、書込範囲、最大数を固定	担当表と各結果
25	メール送信、投稿、外部コメント	禁止	下書き作成までを別操作として許可	人が送信した場合の送信記録

この表で重要なのは、git add、git commit、git pushを一括して「Git操作」にしないことです。stageはローカルの索引変更、commitは履歴の確定、pushは外部共有です。影響が一段ずつ上がるため、許可も分けます。

同様に、テストも「既存のローカルテスト」と「本物のクラウドへ接続する統合テスト」を分けます。後者はデータ送信、認証、課金の可能性があるため、コマンド名がtestでも自動可にはしません。秘密情報の扱いは生成AIに入力してはいけない情報でさらに細かく確認できます。

四つの環境で分類を変える

基準版をそのまま全環境へ適用するのではなく、損失の大きさに応じて補正します。

操作	個人開発	業務リポジトリ	公開サイト	秘密を含む環境
範囲内の読み取り	自動可	自動可	自動可	条件付き。秘密除外を機械化
ローカル編集	条件付き	条件付き。担当範囲を固定	条件付き。表示検証を追加	条件付き。隔離コピーだけ
既存テスト	自動可	自動可。実データ禁止	自動可。外部接続は分離	条件付き。ダミーデータだけ
依存追加	毎回確認	毎回確認。ライセンスと供給網を審査	毎回確認。ビルド影響も確認	原則禁止。承認済みミラーのみ例外
stage	条件付き	毎回確認またはCI専用	条件付き。対象限定	毎回確認
commit	毎回確認	毎回確認。署名や規約に従う	毎回確認	毎回確認
push	毎回確認	毎回確認。保護branchへ直push禁止	毎回確認	原則禁止。専用出口だけ
デプロイ	毎回確認	毎回確認。環境保護を必須化	毎回確認。公開GOを分離	禁止。人の別系統へ移す
削除	毎回確認	毎回確認。復旧確認を必須化	毎回確認。公開物影響を確認	原則禁止
認証	毎回確認	毎回確認。最小scope	毎回確認。デプロイ権限を分離	禁止。人または秘密管理基盤だけ
課金	禁止	禁止	禁止	禁止
外部送信	禁止	禁止	禁止	禁止

ケース1: 個人開発

個人開発では、作業フォルダ内の読み取り、ローカル編集、既存テストを広く自動化できます。ただし「自分のリポジトリだから何でも可」にはしません。ホームディレクトリ全体、ブラウザの認証状態、クラウド資格情報を作業領域へ含めないことが最初の防壁です。

おすすめは、変更用のbranchまたはworktreeを使い、エージェントにはその作業領域だけを書かせる構成です。commitとpushは分離し、まずdiffとテスト証拠を見るようにします。完了報告の自己申告を信じず、AIエージェントの完了証拠チェックに沿ってファイル実在、終了コード、差分を確認します。

ケース2: 業務リポジトリ

業務では、所有者、レビュー担当、デプロイ担当を分けます。エージェントがローカル修正を終えても、保護branchへ直接pushできないようにし、Pull Request、必須レビュー、必須status checkを通します。GitHub公式文書では、保護branchにレビュー、status check、会話解決、署名commit、デプロイ成功などの条件を設定できます。

エージェントの権限規則を各開発者の任意設定だけにせず、管理設定やリポジトリ規則へ置くことも重要です。Claude Codeはユーザーやプロジェクトが上書きできないmanaged settingsを提供しています。Codexも管理要件で利用可能な承認ポリシーやサンドボックスモードを制限できます。実際の設定項目は更新されるため、導入日に公式文書を再確認します。

ケース3: 公開サイト

公開サイトでは、「コードを直す」と「世の中へ見せる」を別の権限にします。ローカル編集、プレビュー、アクセシビリティ検査は条件付きで自動化できますが、本番デプロイは毎回確認です。文章や画像の公開もデプロイと同じ外部影響を持つため、生成と公開を分離します。

GitHub Actionsのenvironmentでは、job実行前の必須reviewer、branch制限、environment secretへのアクセス制御を設定できます。承認前にsecretへアクセスできない構成は、エージェントがデプロイ資格情報を常時持つ状態を避けるのに役立ちます。

サイトの記事や画面をAIが作る場合は、AI下書きの確認方法とAI記事の品質ゲートも組み合わせ、技術テストだけで公開判断を終えないようにします。

ケース4: 秘密を含む環境

顧客データ、未公開ソース、秘密鍵、個人情報を含む環境では、最初に「エージェントへ見せない領域」を作ります。秘密を伏せたコピー、合成データ、最小再現コードで作業させ、本物の秘密を必要とする最終確認は人または専用CIへ移します。

Codex cloudの公式文書では、secretは追加の暗号化層で保管され、setup scriptでだけ利用でき、agent phase前に除去されると説明されています。一方、通常のenvironment variableはchat全体で利用できます。この違いは、「secretという名前の欄へ入れたから全工程で安全」ではなく、どの段階に露出するかを確認すべきことを示します。

データ取扱いも契約形態で異なります。OpenAIはBusiness、Enterprise、APIなどの業務データを既定で学習に使わないと説明しています。Anthropicも商用製品のchatやcoding sessionは明示的な参加などがない限り学習に使わないと説明しています。ただし、保持期間、feedback、consumer契約、connector、外部Web検索は別条件になり得ます。「学習されない」と「送信してよい」は同義ではありません。契約、社内規則、データ所在地、保持、削除、第三者送信を個別に確認します。

ローカルとクラウドの境界を整理するにはローカルAIとクラウドAIの違いも参考になります。

四悪癖を権限設計で抑える

モデルへ「気を付けて」と言うだけでは再発します。悪癖ごとに停止条件と証拠を決めます。

悪癖	起きること	防止する境界	合格証拠
過設計	頼んでいない抽象化、設定、依存が増える	編集対象と非対象、追加依存禁止、変更量上限	指定外ファイル0、依存差分0
指示無視	commit禁止なのにcommitする、周辺を勝手に直す	`.git`書込を技術的に保護し、対象外pathをdeny	`git status`、履歴、対象ファイル一覧
偽完了	「成功」と言うがファイルがない、テスト未実行	完了文ではなく機械検査を採用	ファイル実在、サイズ、hash、終了コード
架空API	存在しない関数、flag、設定を書く	公式文書、型、schema、実行結果を要求	参照URL、型検査、最小実行

過設計への具体策

依頼には「変更してよいファイル」「作らないもの」「依存追加の可否」を書きます。小さな不具合修正で新しいフレームワーク、設定体系、共通化層を提案されたら、自動採用しません。必要なら候補として報告させ、別の変更として判断します。

依頼の書き方はAIへ作業を頼む依頼書の作り方とAIへ任せる前の確認が土台になります。

指示無視への具体策

「commitしない」を自然言語だけで伝えるのではなく、.gitを読み取り専用にする、git commitとgit pushをaskまたはdenyへ入れる、保護branchへの直pushを禁止する、という複数の機械的境界を置きます。

ただし、権限規則のpatternは万能ではありません。Anthropicの公式文書も、shellのURL制限をBash patternだけで作るのは壊れやすいと説明し、WebFetchのdomain規則やhook、OSレベルのsandboxを組み合わせる案を示しています。複合コマンド、wrapper、別の実行ファイルから同じ副作用へ到達できるためです。

偽完了への具体策

「テストしました」ではなく、実行したコマンド、終了コード、標準出力、標準エラーを要求します。生成物には絶対path、byte数、必要ならhashを付けます。UIなら実画面、APIなら最小request、文書ならschema検査を確認します。

構造化された検査結果を扱う場合はAIのJSON出力を安定させる方法が役立ちます。AIの自己申告が事実とずれる背景はAIのハルシネーション対策も参照してください。

架空APIへの具体策

パッケージ名、関数名、CLI flag、設定keyは、公式文書、インストール済みのhelp、型定義、schemaのいずれかで確認します。Web記事やAIの記憶だけで採用しません。ネットワークを閉じた環境なら、ローカルの型定義と--helpを優先します。確認できない機能は「未確認」とし、成功したように書かせません。

サブエージェントの権限は親より強くしない

利用者が決めたいのは、サブエージェントの人数だけではありません。担当、読取範囲、書込範囲、コマンド、ネットワーク、時間、結果の回収先です。

項目	利用者が固定する値	安全な既定
役割	調査、実装、テスト、レビューのいずれか	1体1責任
読み取り	必要なrepositoryと資料	作業repositoryだけ
書き込み	所有ファイルまたは専用worktree	調査・レビュー担当は書込なし
shell	許可するtest、lint、build	読み取りと既存検査だけ
network	domainとmethod	無効
Git	status、diffまでか、stageまでか	status、diffだけ
外部操作	PR、deploy、message	禁止
実行時間	最大時間と停止条件	短い上限を設定
結果	必須の証拠形式	path、command、exit code
継承	親のdeny、sandbox、秘密除外	親以上に厳しくする

OpenAIはCodexのsubagent構成を公式文書で案内し、構成ファイルによる役割設定を提供しています。Anthropicもcustom subagentを定義でき、特定subagentをpermissionのdeny規則で無効化できます。これらは「サブエージェントなら安全」または「親の全設定が常に同じ形で継承される」という意味ではありません。起動前に各製品の現行仕様を確認し、親より強い権限を子へ与えないことを運用原則にします。

役割分担そのものは複数AIの役割分担でも整理しています。

最小ルールブック例

次の12項目をリポジトリのルールへ入れれば、最初の境界として機能します。これは製品固有の設定ファイルではなく、人とエージェントが共有する運用ルールの本文例です。実際の強制はサンドボックス、権限規則、branch保護で重ねます。

読み取りと編集は、このリポジトリの依頼対象だけに限る。
.env、秘密鍵、token、認証cookie、credential storeを読まない。
指定外ファイルを変更しない。必要な変更は提案として分ける。
既存のlint、型検査、testは自動実行してよい。
外部サービスへ接続するtestは実行前に毎回確認する。
依存追加、版更新、lockfile変更は実行前に毎回確認する。
git status、git diff、git logは自動可とする。
git addは指定ファイルだけ条件付きで可とし、git add .は使わない。
commit、push、PR作成、tag、releaseは毎回確認する。
deploy、公開、送信、課金、認証、権限変更は自動実行しない。
削除、force push、hard reset、履歴書換えは実行しない。
完了時は変更ファイル、実行コマンド、全出力、失敗、未確認事項を報告する。

ルールの良し悪しは文の長さではなく、操作へ落とせるかで決まります。「慎重に作業する」より「pushは毎回確認」、「余計な変更をしない」より「指定外ファイルの差分が0」の方が検査できます。

権限を強くしすぎた架空事故

架空の例として、個人サイトの表示崩れを直す依頼を考えます。エージェントには作業PC全体の読み書き、ネットワーク、GitHub token、クラウドのデプロイ資格情報が渡され、承認promptは無効です。

エージェントはCSSを修正した後、「確認を容易にするため」と依存を更新し、lockfileの大差分を作ります。testが一つ失敗すると、周辺コードまで直してcommitします。そのままdefault branchへpushし、pushをtriggerに本番deployが開始されます。さらにbuild時に利用した第三者actionが広いGITHUB_TOKEN権限とrepository secretへアクセスできました。

本当の問題は、AIが賢いかどうかではありません。ローカル編集、依存更新、commit、push、deploy、secret accessが一つの権限に束ねられていたことです。修正は次のようになります。

エージェントの書込は専用worktreeへ限定する。
依存追加を毎回確認へ移す。
jobのGITHUB_TOKENをcontents readへ絞る。
patch生成jobとPR作成jobを分離する。
protected branchでreviewとstatus checkを必須にする。
production environmentで別reviewerの承認を必須にする。
長期資格情報ではなく、可能ならOIDCによる短期認証を使う。

GitHub公式のsecure use referenceは、GITHUB_TOKENを必要最小権限にし、既定をrepository contentsのreadにすることを推奨しています。また第三者actionはfull-length commit SHAへ固定する方法が、immutable releaseとして使う唯一の方法だと説明しています。

権限を弱くしすぎた架空停滞

反対に、ローカルの読み取りにも毎回確認、testコマンドにも毎回確認、生成ファイル1件ごとにも毎回確認が必要な構成を考えます。非対話jobは人へ質問できず、最初の書き込みで終了します。対話実行でも、同種の安全なtestを何度も承認するうちに利用者が内容を読まずに許可するようになります。

これは安全ではなく、承認疲れと自動化停止を生みます。改善は「全部許可」ではなく、狭い条件付き自動化です。

repository内の読み取りを自動可にする。
既知のlint、型検査、単体testをexactなcommandで自動可にする。
書込先を作業フォルダへ限定したうえで編集を許可する。
networkは無効のままにする。
非対話実行では、承認が必要な操作を自動拒否し、patchと証拠だけを成果物にする。
commit、push、deployは別jobまたは人へ渡す。

Codex公式文書では、codex execは既定でread-only sandboxを使い、必要な場合に明示的にworkspace-writeを選ぶ構成が示されています。さらにCIの例では、Codexがpatchを生成するjobをrepository read権限だけで動かし、別jobがpatchを適用してPRを作る分離が紹介されています。止まりすぎへの解答は、全権限ではなく工程分離です。

バックグラウンド実行に必要な追加条件

画面から離れても動く処理は、人が止める機会が減るため、通常のcommand許可だけでは足りません。

条件	必須内容	失敗時
時間	最大実行時間を設定	timeoutで停止
出力	logの最大量と保存先を固定	上限で停止し、理由を記録
費用	API回数、runner時間、予算上限	上限到達で停止
通信	許可domainとHTTP method	範囲外を拒否
書込	専用作業領域	範囲外を拒否
終了	成功条件と失敗条件	自己判断で公開へ進めない
回収	task ID、log、成果物path	証拠がなければ未完了

Claude Code公式文書では、Bash commandをbackgroundで動かし、task IDで追跡し、出力をfileへ書く機能が説明されています。background taskをすべて無効化する環境変数も案内されています。機能があることと、どのcommandをbackgroundで許可するかは別問題です。デプロイや有料APIを長時間実行へ含める場合は、通常より強い承認と停止条件が必要です。

Codex cloudではagent phaseのinternet accessは既定で無効で、environmentごとにdomain allowlistとHTTP methodを設定できます。OpenAIはnetworkを有効にするとprompt injection、codeやsecretの流出、malwareや脆弱な依存のdownload、license制限のあるcontent取得といったriskが増えると明記しています。

導入時チェック30項目

次の30項目を、初回導入時と権限変更時に確認します。

対象と所有

作業対象のrepositoryを絶対pathで固定したか。
書き込みを許すfolderと禁止folderを分けたか。
指定外ファイルを変更しないルールがあるか。
third-party codeやforkを信頼済みと扱っていないか。
作業用branchまたはworktreeを用意したか。

秘密とデータ

.env、key、token、cookieをread denyへ入れたか。
test dataに実在顧客や個人情報が入っていないか。
consumer契約とbusiness契約のdata policyを区別したか。
session、log、cacheの保存場所と保持を確認したか。
feedback送信時に会話全体が扱われる可能性を確認したか。

ファイルとcommand

読み取り専用commandを列挙したか。
自動実行するlint、typecheck、testをexactに決めたか。
testが外部networkや実DBへ接続しないと確認したか。
dependency install scriptの副作用を確認したか。
formatterの対象範囲を限定したか。

Gitとレビュー

status、diffとstage、commit、pushを別権限にしたか。
git add .や全体stageを避けるルールがあるか。
force push、hard reset、cleanをdenyしたか。
default branchを保護したか。
reviewとrequired status checkを有効にしたか。

network、認証、費用

agentのnetworkを既定offにしたか。
必要な場合はdomainとmethodを最小化したか。
API keyをjob全体のenvironmentへ露出していないか。
OAuth scopeとtoken期限を最小化したか。
metered serviceにbudgetと停止条件を設定したか。

公開、長時間、証拠

deployとlocal buildを別権限にしたか。
production environmentへrequired reviewerを置いたか。
background taskに時間、出力、費用の上限があるか。
completionをfile、diff、exit codeで確認できるか。
権限規則をtest環境で実測し、denyが本当に効くと確認したか。

認証方式の基本は二要素認証の選び方、パスキーの仕組み、パスワード管理の始め方で補えます。暗号化、hash、署名の違いは暗号化・ハッシュ・署名の違いを参照してください。

導入の順序

一度に複雑なpolicyを作ると、誤設定で全停止するか、例外だらけになります。次の順で小さく導入します。

read-onlyでrepositoryを読ませ、必要な対象を確定する。
workspace内のlocal editだけを許可する。
既存のlint、typecheck、unit testを自動可にする。
networkを閉じたまま、成果物と証拠を安定させる。
stageが必要なら対象file限定で条件付きにする。
commit、push、PR、deployは別の承認境界に残す。
subagentやbackground実行は、単体の境界が安定してから追加する。
実際の停止と事故未遂を記録し、広すぎる許可と狭すぎる許可だけを修正する。

権限を広げる条件は「面倒だから」ではなく、「同じ安全な操作が繰り返され、対象、command、副作用、証拠を機械的に固定できたから」です。逆に、一度の事故未遂でも秘密、公開、課金、削除へ届く経路が見つかったら、その経路を先に閉じます。

FAQ

Q1. Claude CodeとCodexのどちらが安全ですか？

製品名だけでは決まりません。どちらにも権限とsandboxの仕組みがあり、設定、実行環境、渡した資格情報、GitHub側の保護で結果が変わります。本記事のmatrixを操作単位で適用してください。

Q2. `AGENTS.md`や`CLAUDE.md`へ「push禁止」と書けば十分ですか？

十分ではありません。指示文は行動を方向付けますが、強制境界ではありません。shellのdeny、.gitの保護、remote資格情報の非提供、branch protectionを重ねます。

Q3. 読み取りはすべて自動可でよいですか？

いいえ。作業repository内でも.env、credential、顧客data、private keyは除外します。作業folder外の読み取りは毎回確認が基準です。

Q4. ローカル編集を毎回確認にしないと危険ではありませんか？

書込先を専用worktreeへ限定し、指定外pathをdenyし、diffとtestを必須にすれば、local editは条件付き自動化できます。commitやpushとは分けてください。

Q5. testは常に自動可ですか？

いいえ。既存のlocal testは自動可にしやすい一方、実DB、external API、email送信、有料resourceへ接続するtestは毎回確認です。testという名前ではなく副作用で分類します。

Q6. 依存追加を厳しくする理由は何ですか？

package追加はcodeだけでなく、license、supply chain、install script、lockfile、build時間へ影響します。既存testの実行より影響範囲が広いため、毎回確認を基準にします。

Q7. `git add`も毎回確認すべきですか？

業務や秘密環境では毎回確認が無難です。個人開発なら、対象fileを列挙し、git add .を禁止する条件で自動化できます。stage結果は必ず一覧にします。

Q8. commitまで自動化すると何が問題ですか？

不要なfileや秘密が履歴へ入ると、削除しても履歴に残る場合があります。また「完成」の判断がAIの自己申告へ寄ります。diffと検査を人が確認してから、そのcommitだけを許可する方が境界を保てます。

Q9. pushを許可してもprotected branchなら安全ですか？

保護は重要ですが、それだけでは十分ではありません。別branchへのpushも外部共有であり、CI起動、費用、secret利用、通知をtriggerする場合があります。remote、branch、CI副作用を確認します。

Q10. PR作成はコードを変えないので自動可ではありませんか？

PRは外部サービスへの公開または組織内共有で、title、body、diff、通知が発生します。draft作成と送信を分け、送信は毎回確認を基準にします。

Q11. 非対話実行で毎回確認が必要になったらどうしますか？

その操作を自動拒否し、安全な範囲のpatch、report、test証拠までを成果物にします。承認不能だからfull accessへ上げるのではなく、反映工程を別jobまたは人へ渡します。

Q12. sandboxがあれば秘密を渡してもよいですか？

いいえ。sandboxはfileやnetworkの技術的範囲を狭めますが、契約上の送信可否や、modelへ渡す必要性までは判断しません。秘密は最初から見せない設計を優先します。

Q13. network accessを有効にする安全な方法はありますか？

必要なdomainだけをallowlistにし、可能ならGET、HEAD、OPTIONSへmethodを限定します。取得contentは資料であり命令ではないと扱い、downloadしたcodeやscriptを自動実行しません。

Q14. サブエージェントは親の権限を自動継承しますか？

製品、版、起動方法、設定で異なり得ます。継承を仮定せず、親と子のeffective permissionを確認します。子の権限は親以下とし、調査担当には書込を与えないのが安全な既定です。

Q15. background taskは終了後も動き続けますか？

製品と終了方法で異なります。Claude Codeにはbackground Bash commandとtask IDの仕組みがあり、session終了時のcleanupなどが公式文書に記載されています。導入時に現行仕様を確認し、独自のtimeoutと停止方法も用意してください。

Q16. API keyをenvironment variableへ入れれば安全ですか？

名前を環境変数にしただけでは安全になりません。同じprocessやjobで動くbuild script、test、dependency hook、compromised actionが読める場合があります。利用する単一stepだけへ渡し、untrusted codeと同居させません。

Q17. 課金を条件付き自動にできますか？

既に人が固定した小さな予算枠の「利用」を条件付きにできる場合はありますが、契約、支払方法、予算上限の変更はエージェントにさせないのが基準です。GitHubにはmetered productのbudgetとusage停止設定がありますが、適用対象と初回billing cycleの扱いを公式文書で確認してください。

Q18. 権限規則を設定したらテスト不要ですか？

必要です。patternの誤り、複合command、wrapper、path基準の勘違い、版変更で意図と異なることがあります。安全なdummy対象を使い、「allowは通る」「askは止まる」「denyは拒否する」を実測します。

Q19. AIが存在しないAPIを書いたかどうか、どう見抜きますか？

公式reference、local type定義、schema、--helpのいずれかへ照合し、最小実行を通します。URLを示しただけでは合格にせず、そのpageに対象の関数やflagが実在するか確認します。

Q20. 最終的に何を人が判断すべきですか？

外部へ反映するか、費用を発生させるか、秘密や認証を渡すか、復旧不能な変更をするかです。AIにはlocalな探索、編集、検査、証拠作成を厚く任せ、人は影響が境界を越える瞬間に集中します。

まとめ

AIコーディングの安全性と自動化は、反対概念ではありません。読み取り、local edit、test、依存追加、stage、commit、push、deploy、削除、課金、認証を別の操作として扱えば、安全な反復は自動化し、外部影響だけを人へ集められます。

実務での要点は三つです。

指示文、sandbox、反映先の保護を分ける。
自動可、条件付き、毎回確認、禁止の四段階を操作ごとに決める。
完了報告ではなく、file、diff、exit code、外部反映記録を証拠にする。

最初から完全なpolicyを狙う必要はありません。read-onlyから始め、workspace内編集、既存testへ少しずつ広げます。commit、push、deploy、secret、課金は急いで統合しません。止まりすぎたら安全な反復だけを条件付きへ上げ、暴走したら外部影響へつながる経路を機械的に閉じます。

Sources

以下は2026年7月24日に確認した公式資料です。製品仕様、画面名、既定値は変わるため、導入時点で再確認してください。

OpenAI公式

OpenAI「Agent approvals & security」: Codexのsandbox、approval、network、protected path、代表的な権限組合せ。https://developers.openai.com/codex/agent-approvals-security/
OpenAI「Configuration Reference」: approval_policy、sandbox_mode、network access、managed requirementsの設定値。https://developers.openai.com/codex/config-reference/
OpenAI「Agent internet access」: Codex cloudのagent phaseでnetworkが既定offであること、domainとHTTP methodによる制限、network有効化のrisk。https://developers.openai.com/codex/cloud/internet-access/
OpenAI「Cloud environments」: setup script、environment variable、secret、cache、network proxyの扱い。https://developers.openai.com/codex/cloud/environments/
OpenAI「Non-interactive mode」: codex execのread-only既定、明示的sandbox、CIでのcredential分離とpatch生成例。https://developers.openai.com/codex/noninteractive/
OpenAI「Subagents」: Codexのsubagent利用と役割設定。https://developers.openai.com/codex/subagents/
OpenAI「How your data is used to improve model performance」: consumerのdata controlとbusiness/API dataの既定取扱い。https://help.openai.com/en/articles/5722486-api-data-usage-policies
OpenAI「Enterprise privacy」: business dataの所有、学習利用、保持制御、暗号化に関する説明。https://openai.com/enterprise-privacy/

Anthropic公式

Anthropic「Configure permissions」: allow、ask、deny、permission mode、shell、file、subagent規則とsandboxとの関係。https://code.claude.com/docs/en/permissions
Anthropic「Configure the sandboxed Bash tool」: filesystemとnetworkのOS level isolation、domain制限、credential保護。https://code.claude.com/docs/en/sandboxing
Anthropic「Create custom subagents」: custom subagentの定義と特定subagentのdeny。https://code.claude.com/docs/en/sub-agents
Anthropic「Interactive mode」: background Bash command、task ID、output、cleanup、無効化方法。https://code.claude.com/docs/en/interactive-mode
Anthropic「Claude Code settings」: user、project、local、managed settingsの優先順位と管理方法。https://code.claude.com/docs/en/settings
Anthropic Privacy Center「Is my data used for model training?」: consumer利用とClaude Code coding sessionの学習設定。https://privacy.anthropic.com/en/articles/10023580-is-my-data-used-for-model-training
Anthropic Privacy Center「How long do you store my organization’s data?」: commercial productとAPIの保持に関する説明。https://privacy.anthropic.com/en/articles/7996866-how-long-do-you-store-my-organization-s-data
Anthropic Privacy Center「How do you use personal data in model training?」: commercial offeringのchat、coding sessionの学習利用条件。https://privacy.anthropic.com/en/articles/7996885-how-do-you-use-personal-data-in-model-training

GitHub公式

GitHub Docs「About protected branches」: review、status check、signed commit、push制限、削除・force push制限。https://docs.github.com/en/repositories/configuring-branches-and-merges-in-your-repository/managing-protected-branches/about-protected-branches
GitHub Docs「Deployments and environments」: required reviewer、wait timer、deployment branch、environment secret。https://docs.github.com/en/actions/reference/workflows-and-actions/deployments-and-environments
GitHub Docs「Secure use reference」: least privilege、secret、third-party action、untrusted checkout、OIDC。https://docs.github.com/en/actions/reference/security/secure-use
GitHub Docs「GITHUB_TOKEN」: jobごとに発行されるrepository限定tokenの仕組み。https://docs.github.com/en/actions/concepts/security/github_token
GitHub Docs「Use GITHUB_TOKEN for authentication in workflows」: workflow内のtoken権限指定。https://docs.github.com/en/actions/tutorials/authenticate-with-github_token
GitHub Docs「Using secrets in GitHub Actions」: repository、environment、organization secretの利用。https://docs.github.com/en/actions/how-tos/write-workflows/choose-what-workflows-do/use-secrets
GitHub Docs「OpenID Connect reference」: cloud providerへ長期secretを置かずに認証するためのOIDC。https://docs.github.com/en/actions/reference/security/oidc
GitHub Docs「Budgets and alerts」: metered productのbudget、alert、usage停止。https://docs.github.com/en/billing/concepts/budgets-and-alerts

需要の証拠として参照した公開Issue

次のIssueは公式仕様ではなく、利用者が何に困り、どの粒度の設定を求めているかを確認する需要資料です。個別報告を全利用者の挙動へ一般化していません。

OpenAI Codex Issue #17623「Make permission approvals more reusable and explain the saved authorization scope」: 同種commandの繰り返し承認を減らし、保存される許可範囲を明確にしたいという要望。https://github.com/openai/codex/issues/17623
OpenAI Codex Issue #24135「codex exec: no way to allow MCP tool calls non-interactively without —dangerously-bypass-approvals-and-sandbox」: 非対話MCP利用でsandboxを維持した細かな許可を求める要望。https://github.com/openai/codex/issues/24135
Anthropic Claude Code Issue #27661「Subagents should inherit parent session hooks and permission rules」: 親のhookとpermissionをsubagentへ一貫して適用したいという要望。https://github.com/anthropics/claude-code/issues/27661
Anthropic Claude Code Issue #22055「Edit/Write tools bypass permissions.ask rules」: file edit権限とpermission設定の境界に関する報告。https://github.com/anthropics/claude-code/issues/22055