Codexのフルアクセスは危険？許可していい作業・止めるべき作業

先に結論：Codexのフルアクセスは「常に許可」ではなく「範囲を決めて一時的に使う」

Codexのフルアクセスは、それ自体が即危険というより、「何をしてよいか決めないまま常用する」と危険です。記事本文の文言修正、CSS調整、1ページだけのSEO改善のように範囲を決めた作業なら使いやすい一方で、.env、APIキー、削除、本番反映、push、deploy、MCP追加まで無確認で任せるのは避けるべきです。

迷ったら、最初は「読み取り中心」「対象ファイルを限定」「削除禁止」「秘密情報表示禁止」「buildとdiff確認まで」にしてください。危険なのはAIそのものではなく、作業範囲を決めないまま広い権限を渡すことです。

この記事でいう「フルアクセス」とは

ここでは「フルアクセス」を、リポジトリ内のファイルを広く読み書きできる、コマンド実行を許可する、必要に応じて外部ツールやGit操作まで進められる状態として扱います。実際の画面名や権限名は、利用中のCodex / Claude Code / エディタ環境によって異なります。

危険なのはファイル削除だけではない

AIコーディングの危険というと、ファイル削除や本番反映が目立ちます。しかし、リサーチエージェントやMCP、ブラウザ操作、web retrievalを使う時代には、外部検索クエリに秘密情報が混ざるリスクも見ます。

Hugging Face / ServiceNowのMosaicLeaksは、deep research agentsがprivate local documentsとexternal toolsを組み合わせるとき、外部クエリにsensitive informationが漏れる可能性を示した研究発表です。これは「AIが勝手に悪意を持つ」という話ではなく、検索語句、ツール接続、ログ、外部送信の設計問題です。

リサーチエージェントは検索クエリで情報を漏らすことがある

たとえば、ローカル文書に未公開の顧客名、契約条件、社内メモ、未公開記事案、APIキーの断片が含まれているとします。エージェントがその内容をもとに外部検索を行うと、答えを探すための検索語句に、文書内の固有名詞や数値が混ざることがあります。

MosaicLeaksは、private informationとpublic informationを組み合わせるmulti-hop questionsを使い、エージェントが公開情報を探す過程で秘密の断片を持ち出す問題を測っています。AI開発横丁としては、PA-DRなどの研究手法の詳細よりも、個人開発者が外部検索許可と秘密情報の分離をどう設計するかに落とし込みます。

外部ツールを使う前に確認すること

• web検索やブラウザ操作を許可する前に、検索語句に秘密情報が入らないか確認する
• MCPサーバーが何を読み、何を外部へ送れるか確認する
• ローカルファイルの全文を外部サービスへ送らない
• 社内メモ、顧客情報、未公開記事案は要約版や匿名化版にする
• ログにAPIキー、Cookie、個人情報、顧客名が残らないようにする

個人開発者向けの秘密情報分離ルール

個人開発でも、秘密情報は意外と混ざります。アフィリエイトID、広告タグ、APIキー、未公開記事、クライアント名、Google Driveのメモ、GitHub issue、作業ログ。AIに読ませる資料と外部検索してよい資料を分けておくと、事故をかなり減らせます。

## 外部送信ルール

- .env、APIキー、個人情報、顧客情報、未公開の契約情報を外部検索クエリに含めない
- web検索やMCPを使う前に、検索語句に秘密情報が混ざっていないか確認する
- ローカルファイルの内容をそのまま外部サービスに送信しない
- 必要な場合は、匿名化・要約・伏せ字にしてから使う

Codexのフルアクセスで危険になりやすい操作

許可してもよい作業・止めるべき作業

.env・APIキー・トークンを触らせないルール

.env、APIキー、トークン、Cookie、秘密鍵は、存在確認や変数名の整理までに留めます。値そのものをチャット、ログ、コミット、生成HTML、スクリーンショットに出さないことが基本です。

• .envの中身を表示しない。必要なら変数名だけ確認する
• APIキーの実値を貼らない。相談には伏せ字やダミー値を使う
• ログ、記事本文、生成HTML、コミットメッセージに秘密情報を残さない
• 秘密情報に触れそうな差分が出たら、commitやpushの前に止まる

push・deploy・本番反映はどこまで任せる？

このサイトのように、運用ルール、秘密情報スキャン、build、diff確認が決まっているプロジェクトでは、AIにpushまで任せる場合があります。ただし一般読者向けには、AIに自動で本番反映させず、人間が最終確認する運用の方が安全です。

現実的には、「commitまではAI」「pushまではAI」「deployは人間」のように段階を分けます。commitやpushを任せる場合でも、git status、git diff、build結果、秘密情報の混入確認を通してからにしてください。

MCPや外部ツール連携で増えるリスク

MCPは便利ですが、AIが読めるもの、書けるもの、送信できるものが増えます。最初は読み取り専用から始め、出所不明のMCPサーバーや、権限範囲を説明できない連携は避けてください。

Windows個人開発でありがちな危険パターン

Windowsでは、Documents、Downloads、Desktop、同期ドライブ、公開用upload、.env、ローカルアプリ設定が近い場所に並びがちです。Codexに作業を頼むときは、対象リポジトリと対象フォルダを明示し、作業フォルダ外は触らないルールにします。

• 同期ドライブ上の作業では、意図しない同期や共有に注意する
• 公開用uploadと作業用distを混同しない
• DownloadsやDesktopに置いた一時ファイルを作業対象に含めない
• ローカルアプリの設定ファイルや秘密情報フォルダを対象外にする

Codexに渡す安全な依頼文テンプレート

以下の範囲だけを変更してください。

目的：
- [ここに目的を書く]

変更対象：
- src/data/enhancedArticles.js
- 必要な場合のみ関連するデータファイル

禁止：
- .env、APIキー、トークン、Cookie、秘密鍵を表示しない
- 対象リポジトリ外のファイルを変更しない
- 本番環境、deploy、upload反映は行わない
- npm packageの追加は事前に理由を説明して止まる
- 削除や一括置換は候補を出してから止まる

確認：
- git status
- git diff
- npm run build
- npm run check:static
- npm run check:sitemap
- npm run check:urls

報告：
- 変更ファイル一覧
- 変更理由
- 実行した確認コマンド
- 残った懸念

AGENTS.mdに書いておくと安全なルール例

- .env、APIキー、トークン、Cookie、秘密鍵を表示・編集・コミットしない
- 作業対象はこのリポジトリ内に限定する
- 削除・一括置換・npm install・push・deployは実行前に理由を説明する
- 変更後は git status / git diff / npm run build を確認する
- 公開前に主要ページのtitle、description、canonical、JSON-LDを確認する

やらかした時の確認手順

• git statusで、どのファイルが変わったか確認する
• git diffで、秘密情報や意図しない変更が出ていないか見る
• 削除や一括置換があった場合は、対象パスと差分を優先して確認する
• npm run buildなど、プロジェクトで決めた確認コマンドを実行する
• 生成HTMLや公開用フォルダにAPIキーやトークンが混ざっていないか確認する
• 本番やリモートへ送る前に、人間が最後の判断を持つ

git status
# どのファイルが変更されたかを見る

git diff
# 変更内容と秘密情報の混入を確認する

npm run build
# 構文エラーやビルドエラーがないか確認する

戻す必要があるときは、焦って追加変更を重ねるより、まず差分と秘密情報の有無を確認します。安全が確認できてから、最小の修正か復旧手順を選んでください。

まとめ：危険なのは、広い権限を無条件で渡すこと

Codexのフルアクセスは、使いどころを決めれば個人開発をかなり前に進めます。ただし、常用しない、対象を限定する、秘密情報を見せない、削除や本番反映は止める、差分とbuildで確認する。この線引きを先に作ることが、いちばん実用的な安全対策です。

AIが速いほど、危険な権限変更も速く増える

AIコーディングの危険は、AIそのものよりも、削除、外部送信、本番deploy、Secrets、DB、GitHub Actionsを広く触れる状態で走らせることにあります。速く作るほど、権限変更のレビューを省かない設計が重要です。

ZCodeのFull AccessとAlways Allowは信頼済み範囲だけに閉じる

ZCode公式は、Always AllowやFull Accessは将来の確認を減らすため、trusted operationだけに使う趣旨で説明しています。AIコーディングの危険な権限設定では、ZCodeも同じく最小権限から始めます。

AIの自信だけで危険権限を渡さない

MarketBenchのような自己評価研究から見ると、エージェントの成功見込みやtoken見積もりはそのまま運用判断に使えません。full access、外部送信、本番反映、DB操作は、AIの自信ではなく影響範囲、差分、ログ、人間確認で判断します。

2026年7月追記：権限モード名ではなく、実際に何ができるかを見る

Claude Codeをめぐる2026年7月の報道は、特定の真偽をここで断定する材料ではなく、AI coding agentの権限、通信、secret分離を見直す材料として扱います。Claude Code公式は/permissions、allow / ask / deny、permission modes、plan mode、bypassPermissions、WebFetch、Bash、MCP、hooksを説明し、Codex公式はsandbox、approval policy、read-only、workspace-write、danger-full-access、network accessを説明しています。

名前がread-onlyやplan modeでも、外部ツール、WebFetch、Bash、MCP、hooks、既存の認証済み環境が組み合わさると影響範囲は広がります。安全寄りに運用するなら、モード名ではなく、ファイル読み取り、書き込み、コマンド、ネット接続、secret到達性を別々に確認します。

知らないGitHubリポジトリをAIに実行させる前に

この記事は危険な権限設定の総論として維持し、初見repo、setup script、postinstall、外部URL、間接プロンプトインジェクションは新しい各論へ分けました。

危険な権限を渡す前に、戻せる状態を作る

削除、上書き、外部ツール連携、広いファイル権限をAIに渡す前は、権限を絞るだけでなく、戻せる状態を作ることも大切です。git管理外のファイルや生成物まで含めて外付けSSDなどへ退避しておくと、権限設定ミスの被害を小さくできます。

ChatGPT Work・新desktop appで増える権限面

plugins、connected apps、local files、built-in browser、Computer Use、Scheduled Tasks、multiple repositoriesは作業範囲を広げます。読む・書く・送る・公開する・削除するを分け、approval、sandbox、network、secretsをtaskごとに確認します。