Claude Code --restrictedモード解説:AIエージェントのCI/CDリスクとAnthropicの回答
- CI/CDパイプラインでClaude Codeを活用しているDevOpsエンジニア・SREの方
- AIエージェントの本番環境導入を検討しているセキュリティ担当者・アーキテクト
- —dangerously-skip-permissionsは怖いが、承認プロンプトなしで自動化したい開発者
- 企業でClaude Codeの利用ポリシーを策定中の管理者・CTO
「GitHubのIssueを1件作っただけで、CIランナーの秘密鍵が丸ごと抜き取れる」。2026年8月5日、Las VegasのBlack Hat USA 2026でセキュリティ企業Novee Securityが披露したデモは、AIコーディングエージェントをCI/CDに組み込む危険性を具体的に突きつけた(出典:The Hacker News「Claude Code and Gemini CLI Flaws Let a GitHub Issue Reach CI Workflow Secrets」、2026年8月7日)。Claude Code固有の脆弱性CVE-2026-54316も同時に公開され、バージョン2.1.163未満を使っていた組織は直ちに影響を受けた。
発表直後、Cloud Security Alliance(CSA)はリサーチノートで「外部ユーザーがトリガーできるCI/CDワークフローにAIコーディングエージェントを接続することは、現時点では高リスクとみなすべき」と警告した(出典:CSA「Three AI Coding Agents, One GitHub Issue: CI/CD Secrets Exposed」、2026年8月8日)。
この動きに呼応するように、Anthropicは2026年8月、Claude Codeに**—restrictedフラグ**を追加した。承認プロンプトを増やすのではなく、危険なツール自体を取り除く発想の転換だ。
Claude Code 2026年8月追加の—restrictedモードは、コマンド実行・WebFetchを無効化し、ファイル操作をワーキングディレクトリ内に限定する最小権限モード。環境変数CLAUDE_CODE_RESTRICTED=1でも有効化できる。外部ユーザーがトリガーできるCI/CDワークフローには原則これを使う。ただしプロンプトインジェクション攻撃を完全には防げないため、入力検証・ワークスペース分離との組み合わせが必須だ。
Black Hat 2026が明かした、AIエージェント×CI/CDの攻撃面
Novee SecurityはBlack Hat USA 2026で「Comment and Control」と名付けた攻撃手法を発表した。攻撃の手順は単純だ。リポジトリに書き込み権限を持たない外部アカウントが、GitHubのIssueにプロンプトインジェクション用テキストを仕込む。Claude CodeやGemini CLIが動くCIワークフローがそのIssueを読み込むと、AIエージェントが攻撃者の指示に従ってCI環境の秘密鍵を外部に送信する(出典:Cloud Security Alliance リサーチノート、2026年8月)。
Claude Code固有のCVE-2026-54316はさらに狡猾だった。Hugging Faceの公開ダウンロードカウンターをサイドチャネルとして利用し、APIキーを1文字ずつ外部に送信する手法だ。バージョン0.2.54から2.1.163未満が影響を受けた(出典:The Hacker News、2026年8月7日)。この修正は2.1.163で対応済みだが、問題は脆弱性のパッチだけで解決する話ではない。
構造的な問題は「エージェントがCI環境で過剰な権限を持っている」ことにある。外部からのテキスト入力をトリガーにできるワークフローで、AIエージェントがbashを実行しネットワークにアクセスできる状態は、攻撃面が広すぎる。Hacker Newsのスレッドでは「デフォルト設定のClaude CodeをCI/CDに突っ込むのは、sudoをパスワードなしで全員に与えるのと変わらない」というコメントが多くの支持を集めた(Hacker News、2026年8月)。
—restrictedモードとは何か:4つの制限の中身
Anthropicが2026年8月に追加した--restrictedフラグは、4点の制限を一括で適用する(出典:Anthropic Claude Code更新情報)。
1. コマンド実行ツールの無効化:bashやシェル実行ツールを削除する。--toolsで明示的に指定しない限り、WebFetchも無効になる。Claude Codeがシステムコマンドを実行することは物理的に不可能になる。
2. ファイル操作範囲の制限:ファイル読み書きツールはワーキングディレクトリ内に限定される。CI環境で/etc/secretsや~/.sshに触れることはできなくなる。
3. bypassPermissionsの拒否:--dangerously-skip-permissionsをはじめとする権限バイパスフラグを無視する。ワークフロー設定に紛れ込んだ権限昇格の試みをブロックする。
4. 設定ファイルの無視:ユーザー設定・プロジェクト設定・ローカル設定を読み込まない。CLAUDE.md経由で埋め込まれたプロンプトインジェクション(悪意ある設定ファイルを使った攻撃)を遮断する効果もある。
起動方法は2通りある。
# フラグとして渡す
claude --restricted "PRのテストカバレッジを確認して"
# 環境変数で設定(CI/CD向け)
export CLAUDE_CODE_RESTRICTED=1
claude "PRのテストカバレッジを確認して"
環境変数方式はCI/CDパイプラインのジョブ定義に直接書けるため、ワークフロー全体に一括適用しやすい。
3つのモードを整理:何を選べばいいか
Claude Codeには現在、セキュリティ哲学の異なる3つのモードが存在する。
| モード | 承認プロンプト | コマンド実行 | 主な用途 |
|---|---|---|---|
| デフォルト(manual) | あり | 可能 | ローカル開発、探索的作業 |
| auto mode | AI分類器が判定 | 可能 | 長時間の自律タスク |
| restricted | なし(ツール自体がない) | 不可 | CI/CD、信頼できない入力がある環境 |
auto modeが8月14日にデフォルト化されたことで、「承認プロンプトがなければ安全でないのでは」という誤解が広がった。だがauto modeとrestrictedは設計思想が根本的に異なる。auto modeはAI分類器が「これは安全か」を判定して承認プロンプトを省略する仕組みだ。コマンド実行自体は可能なままで、分類器の判定精度がセキュリティの土台になる。
restrictedはそもそもコマンド実行ツールが存在しない。「AIが危険な行動を取らないように祈る」必要がなく、物理的に取れない。この違いは大きい。CI/CDでは「AI分類器の判定精度に安全性を委ねる」より、「コマンド実行がそもそもできない」状態を選ぶべきだ。
実際の活用パターン:3つのユースケース
GitHub Actions でのPRレビュー自動化:外部コントリビューターのPRコメントをトリガーにClaude Codeが動作する場合、restrictedが必須だ。外部アカウントからの入力が直接エージェントのコンテキストに入るため、プロンプトインジェクションのリスクが最も高い環境の一つだ。
- name: Claude Code review
env:
CLAUDE_CODE_RESTRICTED: "1"
ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
run: claude "このPRの変更を確認してください"
コードスキャン・レポート生成:脆弱性スキャンツールの出力をClaude Codeで要約しSlackに投稿するような用途では、コマンド実行は不要だ。restrictedモードで十分動作する。
マルチエージェントワークフローのサブエージェント:メインエージェントからサブエージェントを起動する際、サブエージェント側にrestrictedをかけることで「サブエージェントが暴走しても被害を限定できる」レイヤーを作れる。Claude Opus 4.8以降のDynamic Workflowsでサブエージェント数が増えるほど、このレイヤーが重要になる。
影の部分:restrictedモードが防げないこと
率直に書く。restrictedモードは「AIエージェントのCI/CD問題を解決する」わけではない。
ファイル操作経由の攻撃は残る:コマンド実行は無効だが、ファイルの読み書きはワーキングディレクトリ内で引き続き可能だ。悪意あるGitHub Issueが「テストファイルをこう書き換えて」という指示を含んでいた場合、Claude Codeはその変更を実行できてしまう。悪意あるコミットが入る可能性は残る。
プロンプトインジェクションの根絶ではない:Agentjacking問題で示されたように、外部ソースから悪意ある指示がコンテキストに混入する攻撃は、restrictedモードでは防げない。実行できる操作の範囲が狭まるだけで、操作を誤誘導されるリスクは残存する。
設定の抜け穴:--toolsオプションで特定のツールを明示的に追加した場合、そのツールはrestrictedモードでも使用可能になる。ツールを追加する際は必要最小限にとどめるべきだ。
現実的な評価:restrictedモードはCI/CDに組み込むための「最低ライン」だ。これがあれば完全に安全、ではなく、これがなければCI/CDに投入すべきでない、という基準として捉えるのが正確だ。
CSAは2026年8月のリサーチノートで、AI×CI/CDの最低限の安全設計として「エージェントの権限を最小化、外部入力の検証、実行ログの保存」を挙げている。restrictedモードは「権限の最小化」の一端を担うが、残り二つ、入力検証とログは別途実装が必要だ。VSCode拡張機能の直近の脆弱性報告が示すように、AIツールのセキュリティは単一の設定で完結するものではない。
Claude Codeのセキュリティ設定を一から整理する
auto modeのデフォルト化、restrictedモード、managed settingsの組み合わせ方を解説した公式ドキュメントで設計を確認できます。
関連記事
- Agentjacking完全解説|偽SentryエラーがClaude CodeとCursorを乗っ取る仕組み
- Claude Code Auto Mode完全ガイド|1日47回の承認地獄から解放される新機能
- Claude Code auto modeが8月14日デフォルト化|manualに戻す設定
- VS Code拡張機能の脆弱性解説(2026年)
免責事項: 本記事は2026年8月28日時点の公開情報をもとに作成しています。セキュリティ情報は随時更新されるため、最新情報はAnthropic公式セキュリティページおよび各CVEのアドバイザリを必ず確認してください。本記事の内容は情報提供を目的としており、特定の設定や対策の完全な安全性を保証するものではありません。