Claude Code・Codex のセキュリティ対策｜ダウンロードフォルダでの乗っ取りの仕組みと、今日やる設定

Claude Code・Codexのセキュリティ対策で、今日先に確認したいのは起動するフォルダ、そこに置かれた指示ファイル、実行を許可する設定の3つです。ダウンロードフォルダを作業場所にせず、見覚えのない設定変更を承認しないことから始められます。

2026年10月、保存されたAGENTS.mdやCLAUDE.mdを通じて、AIエージェントの動作を誘導する報告が公開されました。Xでも日本語の注意喚起が相次ぎましたが、Markdownファイルを保存しただけで、すべてのPCが同じ被害に遭うという話ではありません。

まず通常のターミナルとエディターで環境を確認し、その後にClaude Codeのpermissionsとサンドボックス、Codexの承認モードを見直します。設定例は2026年10月28日に確認した公式ドキュメントに基づく出発点です。既存の業務設定を残しながら、必要な項目だけを取り込んでください。

何が起きたのか：ダウンロードフォルダの AGENTS.md・CLAUDE.md で乗っ取られる仕組み

問題になるのは、外から届いた文章が、エージェントにとって作業指示として扱われることです。ファイルの保存、指示の読み込み、権限を伴う操作という順に分けると、どこを確認すればよいかが見えてきます。

ブラウザは文書ファイルを確認なしで保存する

ブラウザでは設定や操作によって、保存先を毎回尋ねずにファイルがダウンロードされます。人がダブルクリックしていない文書も、ダウンロードフォルダには残るため、「開いていないから作業環境とは無関係」とは判断できません。

Forever Securityが10月22日に公開した報告の出発点は、顧客のダウンロードフォルダにあった不審なAGENTS.mdです。Codexが不正なnpmパッケージfunction-colorを入れようとしたところを検知し、コードが動く前に止めたとしています。Forever Securityの報告

ただし、その顧客環境へファイルが届いた経路は分かっていません。Webページから保存させる流れは研究者が別に示した実証であり、実際の侵入経路として確認された事実とは区別が必要です。

日々の対策では、ブラウザが使う保存先と、エージェントへ任せる作業場所を分けます。画像やPDFを整理させる場合も、必要な資料だけを専用フォルダへ移せば、同じ場所に紛れた設定ファイルまで渡す範囲を狭められます。

エージェントは起動したフォルダの指示ファイルを読む

AGENTS.mdやCLAUDE.mdは、開発手順や文章のルールを共有するための文書です。実行ファイルではなくても、エージェントが内容を作業指示として読み、その後に設定を書き換えたりコマンドを動かしたりする入口になります。

報告のCodex側では、信頼済みの作業場所で指示を読み、MCPの設定変更と不正パッケージの実行へ進む流れが使われました。Claude Code側は研究者が作ったCLAUDE.mdでAPIの接続先を変えさせ、ログイン用トークンが研究者側へ送られる例です。試験の詳細

一方、どの文書を読むかは製品・版・起動場所によって異なります。現行のClaude Codeは、対応版では条件によりAGENTS.mdも読みます。「CodexだからCLAUDE.mdは確認不要」「ClaudeだからAGENTS.mdは無関係」とファイル名だけで確認を終えないほうがよいでしょう。Claude Codeの指示ファイル仕様

文書に「社内の必須設定」「テストのため」と書かれていても、それだけでは組織の承認を意味しません。接続先や権限を変える理由は、その文章を置いた相手とは別の、管理者や既知の手順書で確かめます。

報告された成功率は報告元の試験条件での値

報告ではCodexが9割超、Claude Codeが約5割という結果が示されています。いずれも報告元の試験条件での値であり、利用者全体の被害率や、現在の手元の環境が乗っ取られる確率ではありません。報告された試験結果

Claude Codeの説明には、保護された設定への書き込みで人の承認が必要になり、拒否される場合もあったと記されています。両製品で誘導した操作も異なるため、この数字をそのまま製品の安全性の順位に置き換えるのは適切ではありません。

また、「設計上の性質で、修正するバグではない」という説明は報告元の見解です。AnthropicやOpenAIが対策不能と公式に認めた、という意味にはなりません。記事で扱う権限設定や隔離機能は、それぞれの公式資料で仕様を確認した対策です。

確認する際は、成功率よりも、起動場所、読み込まれる指示、設定変更の承認、アクセスできる情報を見ます。同じ文章を読んでも、許される操作が違えば影響は変わるためです。更新を続けることと、日常の作業範囲を絞ることを併せて進めます。

自分の環境が当てはまるかを 5 分で確認する

最初の5分は、被害がないことを証明する調査ではなく、利用を止めて詳しく調べるべき兆候があるかの確認です。以下は疑わしいフォルダでエージェントを起動せず、通常のターミナルやエディターから行います。

ダウンロードフォルダで起動していないか

まず、普段Claude CodeやCodexを起動するターミナルの現在地を確認します。macOSでは次のコマンド、WindowsのPowerShellではその下のコマンドを使います。どちらも場所を表示するだけで、ファイルは変更しません。

pwd

Get-Location

表示されたパスがDownloadsなら、そこでの新しい依頼を止めます。ホームフォルダ全体や、用途の違う資料を集めた共有フォルダから始めている場合も、プロジェクトごとの場所に切り替える対象です。

ターミナルだけでなく、IDEで開いているフォルダや、アプリのプロジェクト設定も見ます。普段使うショートカットや起動スクリプトが毎回同じ場所へ移動していれば、ターミナルで一度移動するだけでは次回また戻ってしまいます。

作業場所を確認できたら、その場所を信頼してよい根拠を一つ確かめます。自分で作った空のフォルダか、内容を確認済みのリポジトリか、外部から受け取ったばかりの一式かで、次に必要な確認が変わります。

場所の表示が問題なくても、読み取り対象や追加ディレクトリにダウンロードフォルダを広く渡していれば、資料との接点は残ります。起動場所と、今回の依頼でアクセスを認めた範囲をセットで記録しておくと、設定を見直すときに判断しやすくなります。

身に覚えのない AGENTS.md・CLAUDE.md を探す

macOSでは、標準のダウンロードフォルダを次のコマンドで検索できます。見つけたファイルのパスだけを表示し、内容の実行や削除は行いません。保存先を変えている場合は$HOME/Downloadsの部分を実際のパスに置き換えます。

find "$HOME/Downloads" -type f \( \
  -iname 'AGENTS.md' -o \
  -iname 'AGENTS.override.md' -o \
  -iname 'CLAUDE.md' -o \
  -iname 'CLAUDE.local.md' \
\) -print

WindowsではPowerShellで次を使います。OneDriveや別ドライブへ保存先を移している場合は、$downloadDirを実際の場所に変更してください。

$downloadDir = Join-Path $env:USERPROFILE 'Downloads'
$instructionNames = @(
  'AGENTS.md', 'AGENTS.override.md',
  'CLAUDE.md', 'CLAUDE.local.md'
)
Get-ChildItem -LiteralPath $downloadDir -File -Recurse -Force |
  Where-Object { $_.Name -in $instructionNames } |
  Select-Object -ExpandProperty FullName

結果が出たら、エディターで文章を読み、入手元と照合します。パッケージの導入、認証先の変更、権限確認の解除、別のエージェントの起動を求める箇所は、通常の開発ルールに混ざっていても確認が必要です。

自分で置いたファイルが見つかることもあります。ファイル名だけで不正と決めず、知らないものがあれば場所と更新日時を控え、読み込ませる前に管理者へ相談します。

表示が空でも、検索先の誤りやアクセス拒否があれば確認は完了していません。この検索は代表的な指示ファイル名を探すもので、すべての設定やマルウェアを検査するものでもありません。次の接続設定の確認まで進めます。

設定ファイルに知らない MCP サーバーがないか

MCPはエージェントに外部の道具を接続する仕組みです。接続の中にはローカルのプログラムを起動するものもあるため、名前だけでなく、実行コマンド、引数、接続URL、渡す環境変数を確認します。

対象	主な確認先	先に見る内容
Claude Codeの共有接続	プロジェクトの.mcp.json	知らないサーバー、コマンド、URL
Claude Codeの個人・ローカル接続	~/.claude.json	mcpServersとプロジェクト別の接続
Claude Codeの動作設定	~/.claude/settings.json、プロジェクトの.claude/settings.jsonとsettings.local.json	env、hooks、権限を緩める設定
Codexの設定	~/.codex/config.toml、プロジェクトの.codex/config.toml	mcp_servers、接続先、承認・サンドボックス設定

~はホームフォルダを指します。設定用ディレクトリを変更している場合は、その保存先も調べます。Claude CodeではMCPのlocal設定と通常のlocal設定の場所が違い、Codexのプロジェクト設定は信頼済みのプロジェクトで読み込まれます。Claude CodeのMCP設定範囲、CodexのMCP設定

ANTHROPIC_BASE_URLやプロキシ設定は、正規の社内環境でも使われます。存在だけで不正とは判断せず、社内の承認済み接続先と一致するかを確かめます。見知らぬサーバーを確認するために起動したり、一覧コマンドから接続を試したりする前に、まず設定を文字として読みます。

設定ファイルには認証情報が含まれる場合があります。全文をチャットや公開Issueへ貼らず、相談時は秘密の値を伏せ、項目名と変更箇所が分かる範囲にとどめます。

見つけたときの対処：トークンと入ったパッケージを確認する

身に覚えのない指示や接続先を見つけたら、その作業場所でエージェントを再起動せず、実行済みの操作を確認します。不審なファイルが存在する場合と、コマンドが実行された場合、認証先まで変更された場合を分けると、対応する人へ状況を伝えやすくなります。

会社の端末では、ファイルのパス、発見時刻、セッション履歴、変更された設定名を残して情報システム・セキュリティ担当へ連絡します。疑わしい端末での一括削除や、エージェントへの「自動で直して」という依頼は、調査に必要な記録を失うおそれがあるため避けます。

不審な接続先へ認証情報が送られた可能性があれば、信頼できる別の端末から、対象サービスのセッション失効やトークンの取り消し・再発行を進めます。設定を戻しただけでは、すでに渡った認証情報の利用を止められません。会社の手順がある場合は、それに沿って対応順を決めます。

パッケージはpackage.jsonとロックファイル、導入履歴を確認します。function-colorという名前は調査の手掛かりですが、記載がないだけで影響なしとは言えず、依存関係以外の場所に設定変更が残る場合もあります。

調べる目的で不審なパッケージをインストールしたり、サンプルコードを実行したりする必要はありません。実行が疑われるときは担当者と端末の隔離や復旧方針を決め、設定だけを直して通常業務へ戻す判断を急がないようにします。

Claude Code の安全な設定

Claude Codeでは、どのツールを許可するかを決めるpermissionsと、実行したコマンドのアクセス先を制限するサンドボックスを併用します。以下は個人環境の開始例であり、組織が管理する設定がある場合はその方針を優先します。

作業用フォルダを分ける

資料の受け取り場所と、Claude Codeで作業する場所を分けます。macOSなら、次のようにホームフォルダの下へ専用の作業場所を作り、必要な資料だけを移してから使えます。

mkdir -p "$HOME/Projects/security-practice"
cd "$HOME/Projects/security-practice"
pwd

WindowsのPowerShellでも同じ考え方です。次の例は作業フォルダを用意して移動するだけで、ダウンロードしたファイルをまとめてコピーしません。

$workDir = Join-Path $env:USERPROFILE 'Projects\security-practice'
New-Item -ItemType Directory -Path $workDir -Force | Out-Null
Set-Location -LiteralPath $workDir
Get-Location

資料を移すときは、PDFや画像など必要なものを選びます。ZIPの中身を丸ごと移したり、隠しフォルダまで含めて同期したりすると、作業場所を分けても設定ファイルを一緒に持ち込むことになります。

たとえばClaudeを使う動画生成の作業なら、素材用と制作プロジェクト用のフォルダを分け、どの素材を読み込ませるかを依頼ごとに決めると管理しやすくなります。作業目的と必要なファイルの組み合わせを小さく保つのが基本です。

新しいフォルダへ移った後も、上位の指示や個人設定は残ります。フォルダを分ける対策は受け取る資料を整理するためのもので、設定や認証情報の確認を省略できる仕組みではありません。

permissions の allow・ask・deny の書き方

設定は主に~/.claude/settings.jsonへ置きます。プロジェクトで共有する設定は.claude/settings.json、個人のプロジェクト設定は.claude/settings.local.jsonです。既存ファイルがある場合は丸ごと置き換えず、同じキーの中へ統合します。設定ファイルと優先順位

次は通常の確認を残しつつ、npm関連と送信操作を確認対象にする例です。allowは範囲を狭くし、資格情報の読み取りや管理者権限の利用はdenyへ置いています。

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status)"
    ],
    "ask": [
      "Bash(npm *)",
      "Bash(npx *)",
      "Bash(git push *)"
    ],
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(~/.ssh/**)",
      "Read(~/.aws/**)",
      "Edit(./.claude/**)",
      "Bash(sudo *)"
    ]
  }
}

設定	この例で防ぎたいこと
defaultMode	通常の承認確認を省略した運用
allow	無条件の許可が広がること。ここでは状態確認だけを指定
ask	依存関係の操作やGit送信を、内容を見ずに進めること
Readのdeny	指定した秘密ファイルを、対象の読み取り操作で開くこと
Editのdeny	作業中にプロジェクトのClaude設定を書き換えること
Bash(sudo *)	該当するBashコマンドで管理者権限を使うこと

判定はdeny、ask、allowの順で、許可に書けば拒否を上書きできるわけではありません。また、これはコマンド文字列やツールに対するルールで、あらゆる別名・スクリプト経由の操作を網羅するものではありません。権限ルールの仕様

設定後は/permissionsで有効なルールと出所を確認します。.envの読み取り拒否だけで任意のプログラムからのアクセスまで封じたと考えず、次のサンドボックスも設定してください。設定自身の編集を拒否した部分は、人がエディターで管理します。

全開モード（bypass）を常用しない

権限確認を省くbypassPermissionsや--dangerously-skip-permissionsは、普段の作業を速めるための定番設定にしないほうがよいでしょう。出所を確認していない文書やリポジトリを扱う場面では、承認画面が必要な変更を見直す機会になります。

ただし、承認画面が出れば自動的に安全になるわけでもありません。「環境の修復」などの説明だけで判断せず、実際に変わるファイル、導入するパッケージ、送信先、今回の依頼との関係を確認します。理由が分からない変更はいったん拒否し、人が別の経路で調べます。

個人設定でbypassモードを使わせない場合は、既存のpermissionsへ次のキーを追加できます。新規ファイルならこのJSONが最小例です。組織で強制する場合は、後述するmanaged settingsから配布します。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

このキーはbypassモードの利用を制限するもので、ネットワークやファイルの隔離を有効にする設定ではありません。また、autoモードの自動判定と、bypassによる確認省略は別の仕組みです。権限モードの公式説明

承認が多い場合は、毎回同じ安全な操作だけを狭く許可します。「面倒なのでBash全体を許可する」と広げる前に、確認が必要になっている操作と、その頻度を整理するほうが、後から理由を追いやすくなります。

サンドボックスとネットワークの制限

サンドボックスは、コマンドとその子プロセスが使えるファイルや通信をOS側で制限します。Claude CodeではmacOS・Linux・WSL2で利用でき、ネイティブWindowsでは同じ機能は動きません。まず/sandboxで対応状況と有効状態を確認します。

以下は対応環境向けに、隔離を有効にし、隔離外での再実行を止める例です。個人の~/.claude/settings.jsonに統合します。failIfUnavailableを有効にすると、必要な機能が使えない環境では起動が止まるため、Windows利用者へ一律配布しないでください。

{
  "sandbox": {
    "enabled": true,
    "autoAllowBashIfSandboxed": false,
    "allowUnsandboxedCommands": false,
    "failIfUnavailable": true,
    "filesystem": {
      "denyRead": ["~/.ssh", "~/.aws"]
    },
    "network": {
      "allowedDomains": [
        "github.com",
        "api.github.com",
        "registry.npmjs.org"
      ],
      "strictAllowlist": true
    }
  }
}

設定	この例で防ぎたいこと
enabled	コマンドを隔離なしで実行すること
autoAllowBashIfSandboxed: false	隔離内という理由だけで通常の権限確認を省くこと
allowUnsandboxedCommands: false	失敗後に隔離を外して再実行すること
failIfUnavailable	隔離を使えないまま起動を続けること
filesystem.denyRead	隔離内のコマンドが指定した認証用フォルダを読むこと
allowedDomainsとstrictAllowlist	許可されていない宛先へ隔離内から通信すること

ドメインは作業に必要なものへ絞り、既存の許可や例外も併せて確認します。npmのレジストリを許可しても、そこにあるすべてのパッケージを安全と判断したことにはなりません。導入する名前と内容の確認は残ります。

excludedCommandsなどの例外があると、隔離外で動く経路が残ります。また、このネットワーク制限はMCP、Hooks、Claude Code自身の認証通信を一括して閉じるものではありません。/sandboxで有効な設定を確認し、接続設定の点検と併用します。サンドボックスの仕様と例外

Hooks で危険なコマンドを止める

Hooksは、ツールの実行前などに決まった処理を動かす機能です。たとえば、別のエージェントを権限確認なしで起動しようとする文字列を検出し、そこで止める補助線を用意できます。次はNode.jsが入っている環境向けの小さな例です。

.claude/hooks/check-command.cjsを人が作成し、次を保存します。このコードは入力されたコマンドを文字として調べるだけで、そのコマンドを実行しません。

const fs = require('node:fs');

function block(reason) {
  process.stderr.write(reason + '\n');
  process.exit(2);
}

let input;
try {
  input = JSON.parse(fs.readFileSync(0, 'utf8'));
} catch {
  block('確認用の入力を読めないため、実行を止めました。');
}

const command = input.tool_input?.command;
if (typeof command !== 'string') {
  block('コマンドを確認できないため、実行を止めました。');
}

const blockedFlags = [
  '--dangerously-skip-permissions',
  '--dangerously-bypass-approvals-and-sandbox'
];
if (blockedFlags.some(flag => command.includes(flag))) {
  block('権限確認を省く起動オプションが含まれています。');
}
process.exit(0);

続いて、プロジェクトの.claude/settings.jsonのhooksへ次を統合します。onFailureはClaude Code v2.1.295以降の項目です。使用中の版をclaude --versionで確かめ、対応していない版のまま同じ保護が働くとは考えないでください。

{
  "hooks": {
    "PreToolUse": [
      {
        "matcher": "Bash|PowerShell",
        "hooks": [
          {
            "type": "command",
            "command": "node",
            "args": [
              "${CLAUDE_PROJECT_DIR}/.claude/hooks/check-command.cjs"
            ],
            "onFailure": "block"
          }
        ]
      }
    ]
  }
}

PreToolUseは実行前に確認し、matcherは対象のツールを指定します。argsはスクリプトのパスを一つの引数として渡し、onFailureはスクリプト不在や失敗時に処理を通さないための指定です。スクリプトの終了コード2で該当ツールを止めます。Hooksの公式仕様

この例は既知の文字列を拾うだけで、別名や別のツールを使う操作までは止められません。Hooks自体も権限を持つプログラムなので、出所不明のものを追加せず、通常入力・拒否する入力・壊れた入力の3通りで確認してから使います。

Codex の安全な設定

Codexでも、承認のタイミングと、実行できる範囲は別々に設定します。「確認を求めない」と「制限なく実行できる」を同じものとして扱わず、作業に合う組み合わせを選びます。

承認モードとサンドボックス

内容を確認済みの作業フォルダで、最初は読み取り中心のセッションから始めるなら次のコマンドを使えます。これは未確認の設定を無害化するコマンドではないため、指示ファイルとMCPの点検は起動前に済ませます。

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

普段の編集を作業範囲内で認める場合は、~/.codex/config.tomlへ次を統合する方法があります。確認が必要な操作は人へ回し、サンドボックス内のコマンドのネットワークアクセスは無効にする例です。

approval_policy = "on-request"
approvals_reviewer = "user"
sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = false

設定	この例で防ぎたいこと
approval_policy	境界を越える操作を、確認の機会なく進めること
approvals_reviewer	必要な承認を、人の確認なしに自動レビューへ任せること
sandbox_mode	通常の編集範囲を作業領域より広げること
network_access	隔離内のコマンドから不要な外部通信を行うこと

on-requestでも、許された範囲のコマンドが毎回確認されるわけではありません。neverは承認を求めない指定で、それだけでサンドボックスを解除する意味でもありません。境界の外での実行を承認すれば影響範囲が変わるため、確認画面の要求を読む必要があります。承認とサンドボックスの公式説明

MCPやブラウザ、モデルとの通信には別の経路があります。この例を「Codex全体がオフラインになる設定」とは扱わず、起動時の状態表示で有効な権限を確認します。古い設定例にあるapproval_policy = "untrusted"は現行の明示指定として使えないため、そのままコピーしないでください。現行の設定リファレンス

AGENTS.md が読まれる範囲

Codexは、個人用の指示とプロジェクト側の指示を組み合わせます。標準の個人用設定場所は~/.codexで、AGENTS.override.mdがあればそれを優先し、なければAGENTS.mdを使います。設定場所を変更している場合は、その場所が確認先になります。

プロジェクト側は、通常Gitのルートから現在のディレクトリまでをたどります。各階層でAGENTS.override.md、AGENTS.md、設定された代替ファイル名の順に探し、一つの階層から読み込む指示ファイルは一つです。AGENTS.mdの読み込み仕様

Gitなどのプロジェクトルートが見つからない場合は、現在のディレクトリを確認します。「起動時にPC中のAGENTS.mdをすべて読む」という動きではありません。一方、作業中に別のファイルを読むことはあるため、最初の読み込み範囲だけを根拠に安全とは判断できません。

実務では、起動する場所までの指示と、個人用の指示を先に確認します。サブフォルダへ移って作業する場合は、その階層の追加ルールも見て、親のルールと矛盾する不自然な権限要求がないかを調べます。

AGENTS.mdに「秘密を読まない」と書くことは、作業方針の共有には役立ちます。ただし、OSのアクセス制限や承認設定を置き換えるものではありません。文章で依頼するルールと、実行を機械的に制限する設定を併せて管理します。

チームで使うときのルール

チームでは、各自が注意するだけでなく、共通設定の配布、例外の申請先、リポジトリを開く前の確認を決めます。誰が変更してよい設定なのかが明確なら、不明な指示を見つけたときに作業を止めやすくなります。

管理者がまとめて配る設定

Claude Codeのmanaged settingsは、利用者やリポジトリの設定より優先して組織の制約を配布する仕組みです。共有リポジトリの推奨JSONとは、変更できる範囲が異なります。

次はbypassモードを制限し、権限ルールとHooksの出所を管理側へ限定する例です。管理者が必要な許可やHooksも用意して配布します。

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  },
  "allowManagedPermissionRulesOnly": true,
  "allowManagedHooksOnly": true
}

allowManagedPermissionRulesOnlyは個人やプロジェクトが足した権限ルールへの依存を減らし、allowManagedHooksOnlyは管理外のHooksを動かさないための指定です。既存の開発用フックも対象になるので、小さなチームで動作を確認してから広げます。managed settingsの配布方法

Codexでは、管理者が配布するrequirements.tomlで選択可能な承認方式やサンドボックスを制限できます。次は管理者向けの例であり、個人のconfig.tomlへ貼り付ける設定ではありません。

allowed_approval_policies = ["untrusted", "on-request"]
allowed_approvals_reviewers = ["user"]
allowed_sandbox_modes = ["read-only", "workspace-write"]

1行目は承認方式、2行目は承認の担当、3行目は実行範囲の選択肢を絞ります。ここでのuntrustedは未信頼プロジェクトから導かれる厳しい扱いを許可リストに残すもので、個人設定へ同名の承認方式を明示指定する意味ではありません。Codexの管理設定

配布後は各環境で有効な設定を確認します。許可済みMCP、例外の担当者、更新日も記録します。

他人のリポジトリを開く前の確認

初めて使うリポジトリは、エージェントや自動タスクを動かす前に、Web上のコード表示や通常のエディターで設定を確認します。READMEが自然な文章で書かれていることや、所有者を知っていることだけで、現在の内容まで確認済みとは言えません。

確認するもの	見る点
AGENTS.md、CLAUDE.mdなど	依頼と関係のない導入・接続変更・確認省略の要求
.claude、.codex、MCP関連設定	起動時の処理、外部サーバー、実行コマンド
.vscode/tasks.jsonなど	フォルダを開いた際のタスクや自動実行
package.jsonとロックファイル	スクリプト、追加された依存関係、取得先

関連する別の調査として、JFrogは10月26日、testmetestに関連する活動で42件のGitHubリポジトリに実行用の仕掛けを確認したと報告しました。Claude Code・Gemini CLI・Cursor・VS Code向けの設定が対象に含まれます。Forever Securityの報告と同一の攻撃だと確認されたわけではありません。JFrogの一次報告

この例からチームの確認対象に加えたいのは、ソースコード以外の設定変更です。プルリクエストでHooksやMCP、IDEタスクが追加されたら、通常の機能変更とは別に、実行内容と必要な権限を担当者が確認します。

きゃらくるでClaude Code・Codexを使う手順のように、制作ツールや補助リポジトリを組み合わせる場合も同じです。導入前に配布元と設定を確認し、承認済みの版を記録しておくと、後から変わった箇所を追えます。

よくある質問

ここまでの設定で迷いやすい点を、実際に作業を再開するときの判断に沿って整理します。どの対策も単独で環境全体を保証するものではなく、確認する場所と効く範囲を把握して使うことが大切です。

AGENTS.mdやCLAUDE.mdは、見つけたら削除すればよいですか？

名前だけを理由に一括削除する必要はありません。自分やチームが作った正規の指示ファイルもあり、削除すると必要な開発手順や品質上の注意が失われる場合があります。まず入手元、更新日時、内容を確認します。

知らないものがあれば、エージェントに読ませる前に作業を止めます。会社の環境では担当者へ知らせ、調査に必要なコピーや記録を残したうえで、隔離・削除・復旧の手順を決めます。

すでに読み込まれた場合は、ファイルの削除だけで対応を終えないでください。実行履歴や接続設定まで確認し、認証情報が渡った可能性があれば、その情報を失効させる対応が別に必要になります。

反対に、ファイルが正規のものと確認できた場合は、その由来と管理者を記録して使えます。「存在するか」から一歩進めて、「誰が、何のために、どこまでの操作を指示しているか」を確認するのが判断の基準です。

ダウンロードフォルダを使ったことがあれば、もう被害に遭っていますか？

起動した経験だけでは、被害の有無は判断できません。いつ、どのファイルが置かれていて、何が読み込まれ、どの操作が許可されたかを確認する必要があります。不審なファイルがないことと、不審な操作がなかったことも同じではありません。

まず現在の指示ファイルと設定、分かる範囲のセッション履歴を確認します。知らないパッケージの導入や接続先の変更があれば、内容を控えて詳しい調査へ進みます。記録が残っていない場合は「確認できない」として扱い、推測で安全と結論づけません。

確認を進めている間は、専用の作業場所へ切り替えます。今後の作業範囲を整えることと、過去の影響を調べることを分ければ、すべての作業を同時に抱えずに進められます。

会社の情報や本番用の権限を扱っていた場合は、その点を先に担当者へ伝えます。端末にどの情報があったかが分かると、調べる対象や優先順位を決めやすくなります。

読み取り専用やplanモードなら、情報漏えいも防げますか？

読み取り中心のモードは、編集や実行の範囲を絞るために役立ちます。ただし、「書き換えられないこと」と「読み取った情報を外へ渡せないこと」は別の条件です。秘密のファイルを読む権限や、外部のツールへ送る経路があれば、それぞれの確認が必要になります。

そのため、確認用のセッションにも、本番の認証情報や業務資料を最初からまとめて渡さないほうがよいでしょう。まず内容を確認済みのファイルだけを置き、必要になったものを追加する進め方が扱いやすくなります。

また、モデルが生成する計画の内容と、クライアントが読み込む設定や接続は同じものではありません。計画を立てる依頼だから安全と判断せず、起動前の設定点検を行います。

モード名から保護範囲を推測する代わりに、編集できる場所、読める情報、通信できる相手を一つずつ確認します。その範囲を説明できれば、次にどの権限を追加してよいかも判断しやすくなります。

サンドボックスを入れれば、MCPもまとめて制限されますか？

この記事で扱うコマンド用のサンドボックスを有効にしても、接続済みのMCPを一括して同じ範囲へ閉じ込めたことにはなりません。MCPサーバーは別のプロセスや外部サービスとして動くことがあり、接続先ごとに権限と認証を確認する必要があります。

導入時には、何の操作を提供するサーバーか、どこで動くか、どの認証情報を渡すかを整理します。ローカルで動くものなら実行コマンドと配布元、外部サービスなら接続URLと許可するアカウントの範囲を見ます。

使わない接続は有効なまま残さず、必要な作業のときだけ利用する運用を検討します。設定名が分かりやすくても、その名前は実行内容の証明にはならないため、設定を変更したときには内容も再確認します。

接続できたことと、すべての操作を任せてよいことも別です。公開、削除、外部への送信などは、ツール側の権限と、人が確認する業務上の手順を組み合わせて管理します。

Windowsでは、同じ設定をそのまま使えますか？

JSONやTOMLの形式が共通でも、OSの隔離機能まで同じとは限りません。この記事のファイル検索はPowerShell用を載せていますが、Claude Codeのサンドボックス例はmacOS・Linux・WSL2を前提としています。

ネイティブWindowsでfailIfUnavailableを有効にすると、対応するサンドボックスが使えず起動が止まります。その場合に保護設定を外して済ませるのではなく、WSL2など対応環境で使うか、組織の実行環境へ移すかを決めます。

CodexのWindows対応はClaude Codeとは別に確認が必要です。一方の説明をそのまま他方へ当てはめず、利用中のクライアントと実行環境で、起動時にどの保護が有効になっているかを見ます。

WSL2を使う場合も、Windows側のファイルへどこまでアクセスを渡しているかを確認します。パス表記だけを置き換える作業と、実際に隔離が機能するかの確認を分けて進めてください。

設定を追加したらビルドが失敗します。制限を外してよいですか？

まず、何を拒否した結果なのかを確認します。依存関係の取得先へ通信できないのか、キャッシュの保存先へ書けないのか、必要なプログラムが入っていないのかで、直す場所が異なります。

必要性を確認できた通信先や保存先だけを追加すると、制限を広く外すより変更の理由を追いやすくなります。追加した例外には、用途と確認日を残しておくと、作業が終わった後に不要な許可を戻せます。

一方、エージェントが提案した「隔離外で再実行すれば直る」という説明だけでは、許可する根拠になりません。要求されたコマンド、書き込み先、通信先を見て、通常のビルド手順と一致するかを確かめます。

すぐに判断できない場合は、既知の手順を人が確認済みの環境で実行するか、管理者に例外を相談します。動くことだけを合格条件にせず、何を許可したため動いたのかを説明できる状態にします。

設定例は、既存のsettings.jsonへそのまま貼ればよいですか？

新規の設定ファイルなら、各例はJSONとして保存できます。既存ファイルへ追加する場合は、外側の波括弧ごと末尾へ貼るのではなく、既存のpermissions、sandbox、hooksへ項目を統合します。同じキーを二つ作ると、想定した内容が有効にならないおそれがあります。

編集前には、人が戻せる場所へ元の設定を保管します。認証情報を含む場合があるので、公開リポジトリへバックアップを追加したり、相談用に全文を送ったりしないようにします。

保存後は構文エラーがないことだけでなく、実際に有効なルールを確認します。Claude Codeなら/permissionsや/sandbox、Codexなら起動時の権限表示を見て、別の設定で上書きされていないかを確かめます。

コピーできることと、既存環境へ無調整で適用できることは別です。まず一つの作業用プロジェクトで試し、必要な作業と拒否したい操作の両方が期待どおりかを確認してから利用範囲を広げます。

トークンの再発行だけで、作業を再開してよいですか？

トークンの取り消し・再発行は、漏れた認証情報の利用を止めるための対応です。それだけで、端末に残った設定変更や不審なプログラムが取り除かれるわけではありません。原因が残った状態で新しい認証情報を入力すると、再び渡る可能性があります。

まず担当者と影響範囲を確認し、信頼できる環境から認証情報を扱います。復旧では、接続先や起動時の処理が元に戻っているか、追加されたパッケージや設定がないかを確認し、必要に応じて端末自体の復元も検討します。

同じ端末で使っていたすべてのサービスを、根拠なく同じ影響と決める必要はありません。ただし、どの資格情報へアクセスできたかが分からないときは、その不明点を残したまま対応の範囲を相談します。

再開の基準を「エラーが消えた」「ログインできた」だけにせず、不審な変更の原因と復旧内容を説明できる状態にします。会社の環境では、その確認を担当者と共有してから通常の作業へ戻します。

まとめ

Claude Code・Codexを安全に使うために、まずダウンロードフォルダから起動する習慣を見直し、知らない指示ファイルと接続設定がないかを確認します。通常の承認を残し、作業範囲と通信先を絞ることで、文書に書かれた要求がそのまま大きな操作へつながる機会を減らせます。

今日の確認は、起動場所、指示ファイル、MCPとAPIの接続先、実行履歴の順に進められます。異常があれば作業を止め、記録を残して相談し、設定の復旧と認証情報の失効をそれぞれ必要な範囲で行います。

設定は一度コピーして終わりにせず、新しいリポジトリやツールを導入するときに見直します。チームでは管理者が配る設定と例外の窓口を決め、何を任せたかを後から確認できる状態を保つことが大切です。

AgentSignalでは、AIツールを実際の業務で使う際の設定や手順を整理しています。新しい制作ツールを取り入れるときも、作業内容と必要な権限を一緒に確認してください。