Claude Codeを安全に使い倒すための、実行環境の隔離 はじめの一歩

Claude Codeを安全に使い倒すための、実行環境の隔離 はじめの一歩

なぜ実行環境の隔離が必要なのかまずご説明し、次に具体的な隔離手法を3つご紹介。最後にはじめの一歩もご提案します。
2026.09.08

製造ビジネステクノロジー部のかずえです。

2026年9月1日に開催されたClaude Codeセミナー AI駆動開発セキュリティ編 ~設定だけでは防げないリスクと、実行環境の隔離という次の一歩~にて、「Claude Codeを安全に使い倒すための、実行環境の隔離 はじめの一歩」というタイトルで登壇いたしました。お越しくださった皆様、ありがとうございました。

本記事はその登壇内容をブログ向けに再構成したものです。なお内容は2026年9月時点のものです。特にClaude Code on the Webはリサーチプレビュー段階の機能であり、今後仕様が変わり得る点にご注意ください。

お話しすること

  1. 実行環境隔離の目的: 対処するリスクを決める
    • なぜ実行環境の隔離が必要なのか、その目的をまずお伝えします。
  2. 3つの隔離手法の紹介と、はじめの一歩
    • 具体的な隔離を3つ紹介します。その後はじめの一歩もご提案します。

まずは隔離の目的からです。

実行環境隔離の目的: 対処するリスクを決める

先に結論から書きます。今回、サプライチェーン攻撃による情報漏洩の被害範囲を極小化することを目的に、実行環境の隔離について考えました。

purpose.png

「えらい目的狭いやん」「Claude Codeとあまり関係なさそうやん」と思われるかもしれませんが、それはゆくゆくご説明します。

まず、対処するリスクを1つに絞る

AIコーディングエージェントの利用には、様々なリスクが考えられます。

  • 機密情報漏洩
  • AIコーディングエージェントツールの高額利用
  • クラウドやSaaSの意図せぬ高額利用
  • 脆弱性のあるコードの生成
  • 既存リソースの削除
  • 認知的負債の増加
  • など

これらに一度に対処するのは難しいので、まず対処するリスクを絞る必要があると考えました。

弊部(製造ビジネステクノロジー部)は製造業のお客様を中心にご支援するクライアントワークを行っており、お客様企業の機密情報を扱う機会が多々あります。こういった機密情報を漏洩してしまうことが、お客様の信頼を最も損なうと考え、機密情報漏洩を最優先で対処すべきリスクとしました。

次に、対処する経路を1つに絞る

情報漏洩の経路も複数考えられます。

  • 開発者の人為的ミス(ツールの設定ミスなど)
  • AIの誤動作
  • サプライチェーン攻撃(マルウェアのインストールによる端末侵害)
  • など

こちらも一度に全ての経路に対処するのは難しいので、どれを防ぐか絞り込みます。今回はサプライチェーン攻撃を選びました。

サプライチェーン攻撃とは

サプライチェーン攻撃とは、ソフトウェアが利用者に届くまでの過程(サプライチェーン)を悪用し、正規のソフトウェアに悪意あるコードを混入させる攻撃です。開発者にとって特に身近な経路は、npmやPyPIなどで公開されているOSSパッケージです。

典型的な流れはこうです。

supply-chain-attack.png

  1. 攻撃者がメンテナのアカウントを乗っ取る
  2. マルウェアを混入した新しいバージョンを公開する
  3. それをインストールした開発者の端末に、インストール時に自動実行されるスクリプト経由でマルウェアが入り込む
  4. 端末が侵害され、情報漏洩などの被害を受ける

サプライチェーン攻撃に対処するべき理由

理由は2つあります。

  1. AI駆動開発によって、OSSパッケージのインストール回数が桁違いに増えたから
  2. 大規模な攻撃事案が近年頻発しているから

順に説明します。

理由①: OSSパッケージのインストール回数が桁違いに増えた

AIエージェントが開発する今は、人間が開発していた頃と比べ、タスクの数が増え、並列実行も普通になり、その1つ1つでnpm installnpx が走ります。そして、何が入ったかを人間はもう見ていません。直接使っているOSSパッケージだけならまだ確認できるかもしれませんが、そのOSSパッケージが内部で使っている別のOSSパッケージまで含めると、人間が全てを追いきるのは現実的ではなくなっています。

インストール回数が増えれば、被害の件数も増えます。

理由②: 大規模な攻撃事案が頻発している

近年、大規模なサプライチェーン攻撃が数か月おきに発生しています。主なものを時系列で挙げます。

  • 2025年8月 Nx「s1ngularity」: AIコーディングエージェントを武器化した初の攻撃(SnykGitGuardian)
  • 2025年9月 chalk / debug侵害: 合計で週20億ダウンロード超のパッケージ群にマルウェア混入(Wiz)
  • 2025年9月 Shai-Hulud: 初の自己増殖型npmワーム、500超のパッケージに感染(CISA)
  • 2025年11月 Shai-Hulud 2.0: 数百パッケージ規模で再来(Microsoft Security Blog)
  • 2026年3月 axios侵害: 週1億ダウンロードの定番パッケージが侵害(Wiz)
  • 2026年4〜6月 Mini Shai-Hulud / Miasma: AIエージェントの設定・認証情報を標的に(vorlon.ioMicrosoft Security Blog)
  • 2026年5月 TanStackほか侵害: npm / PyPIあわせて170超のパッケージが侵害(Orca Security)

もはや珍しい出来事ではなく、明らかに開発者の端末が狙われていると言える状況です。ここから2つの事例を紹介します。

事例①: axios侵害 — 普通に使うものが汚染される

2026年3月31日、週間約1億ダウンロードのHTTPクライアントaxiosで発生した事案です。メンテナーのnpmアカウントが乗っ取られ、悪意あるバージョンが公開されました。install時に自動実行されるスクリプト(postinstall)経由で、遠隔操作マルウェア(RAT)が端末に常駐する仕組みです。axios公式のpostmortemによると、悪意あるバージョンが公開されていたのは約3時間で、その間にインストールした端末は侵害されました(axios公式postmortemWiz)。

npm installしただけで端末が乗っ取られる、という事例です。

事例②: AIエージェントがマルウェアの「武器」になった

2025年8月のNx「s1ngularity」です。npmパッケージNxにマルウェアが混入し、postinstallが端末の認証情報を窃取しました。その際、端末にインストール済みのClaude Code / Gemini CLI / Amazon QなどのAIツールを安全機構無効化フラグ付きで起動し、AI自身に機密ファイルを探させるという手口が使われました。

GitGuardianの一次データによると、1,079件のリポジトリから2,349件の認証情報が検出されています(GitGuardianSnyk)。

ログイン済みのエージェントは、攻撃者から見れば「認証済みで何でもできる道具」になってしまう、という事例です。

対策の2分類: 予防と隔離

対策は大きく2つに分けられます。

  • 予防(事前対策): マルウェアを入れない。公開直後のパッケージを入れない設定(npmのmin-release-ageなど)や、マルウェアチェックツール(Takumi Guard, Safe Chain)など、世の中に広く公開されているやり方があり、有効です。まだ実施していなければぜひやっていただきたいです。
  • 隔離(事後対策): マルウェアに入られても被害を小さくする。予防をすり抜けられた場合の最後の砦です

予防は有効ですが、すり抜けられる前提で次の策を考える必要があります。それが隔離です。

弊部のようなクライアントワークをしていると、複数のお客様の情報が1つの端末上に混在している場合があります。そうした端末のとあるお客様プロジェクトにてサプライチェーン攻撃を受けて侵害されると、他のお客様の情報も根こそぎ持っていかれてしまいます。これは避けたいので、被害範囲を極小化すること、つまり侵害されても、失うのはそのプロジェクトの情報だけにとどめることを目指します。

情報漏洩の成立条件と「壁」という考え方

3つの隔離手法を紹介する前に、情報漏洩の成立条件を整理します。

情報漏洩が成立するには、2つの要素が必要です。

fta-information-leak-1.drawio.png

  1. マルウェアが機密情報に到達できること
  2. その機密情報をマルウェアが外部へ送り出せること

今回の実行環境の隔離で狙うのは1つ目、「到達できる」の範囲を狭めることです。この記事では、これをと呼びます。

fta-information-leak-2.drawio.png

なお、後述する各隔離手法は補足的に2つ目の「外部へ送り出せる」の部分にも対応できることがあるので、それについても触れていきます。

fta-information-leak-3.drawio.png

3つの壁: どこに立てるか

今回は、壁をどこに立てるかが異なる3つの手法を紹介します。壁を立てる場所で3レイヤーに分類できます(内側→外側)。

レイヤー 壁の場所 端末を家に例えると 具体的な手法
① プロセス単位 AIが実行するコマンドの周り AIが作業する机の周りだけ柵で囲う Claude CodeのBash sandbox
② 開発環境単位 プロジェクトの開発環境ごと 部屋ごとに区切る Dev Container
③ 端末の外 実行環境そのものを端末の外へ 家の外の作業場を借りる Claude Code on the Web

外側の壁ほど守れる範囲が広くなります。そして、この3つに共通する原則が1つあります。

壁が守れるのは、壁の外に置いたものだけです。壁の中に持ち込んだものも、送れる先を絞れば被害を減らせる可能性はありますが、盗まれる前提で扱うほうが安全です。壁の中にできるだけ不必要なものを持ち込まない、というのが大事なポイントになります。

壁①: Bash sandbox — AIのコマンド実行を守る

Claude Code標準のOSレベルサンドボックスです。/sandboxから設定でき、Claudeが実行するコマンドとその全子孫プロセスに境界を強制します。書き込み先とネットワークアクセス(送れる先)を制限できるため、npm installのpostinstallで実行されるマルウェアも壁の内側に閉じ込められる可能性があります(Configure the sandboxed Bash tool - Claude Docs)。

ただしデフォルト設定には穴が残るので、より硬い設定に詰める必要があります。代表的なものが迂回経路です。サンドボックスによってコマンドが失敗すると、Claude CodeはdangerouslyDisableSandboxパラメータを付けてサンドボックス外で再試行することがあり、これがデフォルトで有効になっています。sandbox.allowUnsandboxedCommands: falseにすれば無効化できます。

簡単に使い始めることのできるBash sandboxですが、サプライチェーン攻撃の対策、という観点で考えるとやや物足りないというのが正直な所です。それは守れるのはAIがコマンドを叩くときだけという点です。それ以外、例えば人間が自分のターミナルでnpm run devする、IDEがnode_modulesを読み込む、といった「人間が動かす段階」は壁の外になるので、無防備です。そしてそういった「人間が動かす段階」にて発動するマルウェアも存在します。

そういったタイミングも含めて隔離する手法として、次の壁をご紹介します。

壁②: Dev Container — 開発環境ごと閉じ込める

プロジェクトごとにコンテナ内へ開発環境を閉じ込める手法です。VS CodeやClaude Codeから透過的に使え、盗まれ得るものを「そのコンテナに持ち込んだものだけ」に限定できます。IDE拡張やアプリ起動、テスト実行など、Bash sandboxでは守れなかった「人間が動かす段階」も壁の内側に含められるのが利点です。

https://dev.classmethod.jp/articles/setup-claude-code-in-devcontainer/

注意点は3つあります。

  • マウントしたディレクトリや渡した環境変数は守れないので、コンテナに持ち込むものを最小にする設計が重要です
  • デフォルトではネットワークは素通しです。送れる先を絞る自前実装が必要で、Anthropicが参考実装(init-firewall.sh)をGitHub上で公開しているので、参考にできます
  • 壁が破られる可能性があります。破られた先には他のお客様の機密情報がある、という点で考えるとやや脆弱といえます。「壁が破られる」の例は以下です。
    • カーネル/コンテナランタイムの脆弱性を悪用(runc の CVE-2019-5736、CVE-2024-21626 など)しコンテナから脱出する手法が過去にありました。
    • 設定ミス。
      (VSCode Extensionの)DevContainerではデフォルトでローカル端末のGit認証情報をコンテナ内から使えるようになっています。ですのでコンテナが侵害されるとGit認証情報を悪用されるおそれがあります。
      また、DevContainer内で別のコンテナを使いたくなった場合(例: コンテナとして提供されているMCPサーバーを使いたい)、所謂 DooD(Docker outside of Docker)構成を採ると実質DevContainerにローカル端末(ホスト端末)全域へのアクセス権を与えてしまうことになります。

壁③: Claude Code on the Web

実行環境そのものを端末の外に出す手法です。Anthropic管理のクラウドVM上でClaude Codeを実行するため、手元の端末では最初の指示を出すだけで実体は何も動きません。サプライチェーン攻撃を受けても、侵害されるのはクラウド上のその環境だけです(Use Claude Code on the web - Claude Docs)。

Dev Containerでは自前実装が必要だった「送れる先を絞る」設定も、標準で備わっています。ドメインリスト形式で、UI上で4段階(None / Trusted / Full / Custom)から選ぶだけの簡単な設定です。デフォルトはTrustedで、各種パッケージレジストリやGitHubなど、開発に必要なものだけが許可されています(Configure cloud environments - Claude Docs)。つまりデフォルトの状態で使っても、ある程度のセキュリティが担保されていると言えます。

Claude Code on the Webのもう1つの良さは、開発者体験です。セキュリティのために我慢する道具ではないという印象を持っています。

  • セッションを始めるとき: リポジトリを選ぶだけです。手元にリポジトリをクローンしたり、環境構築をしたりする必要がありません
  • 走らせている間: PCを閉じても作業は続行されます。並列にたくさんのセッションを走らせても、その全てがクラウド上のVMで実行されるので、手元のPCの負荷が上がることもありません。作業状況をスマホから確認したり、そこから指示を出したりもできます
  • 終わったあと: 成果はプルリクエストで受け取ります。セッションごとにブランチを切ってコミットを積み、GitHubリポジトリにプッシュしてプルリクエストを作るところまで自動でやってくれます。そのプルリクエストにレビューコメントを付けると、Claudeがそれを拾って修正対応まで進めてくれます

一方で、使う前に確認しておくべき前提条件もあります。

  • リサーチプレビュー段階の機能であり、今後仕様が変わる可能性があります
  • Amazon BedrockやGoogle Vertex AI経由では使えません
  • お客様案件で使う前に、契約上コードを外部クラウドに置けるかを確認する必要があります
  • clone / PR 作成は GitHub 前提
  • 相性が悪い開発: 実機接続・社内ネットワーク・重い環境構築が必要なもの
  • ユーザースコープの設定など、一部の設定は持ち込めない

3つの壁の使い分け

① Bash sandbox ② Dev Container ③ Claude Code on the Web
守れる範囲 AIのコマンド実行のみ その案件の開発作業全体 端末そのもの(何も残らない)
導入ハードル 最小(/sandboxと打つだけ) 中(devcontainer.json整備) 小(ただし開発スタイルが変わる)
向いている場面 今日から全員 手元での開発が必要な案件 GitHub完結で任せられるタスク

一押しは③のClaude Code on the Webです。端末の外に出せる作業はどんどん出していき、残る作業をBash sandboxやDev Containerで守っていく、という使い分けがよいと考えています。

はじめの一歩: Claude Code on the Webに1タスク流してみる

原則は1つです。壁が守れるのは壁の外に置いたものだけなので、持ち込む量を減らし、できれば端末の外で実行しましょう。

はじめの一歩として、まずClaude Code on the Webに1タスク流してみることを提案します。手順は次の通りです(Get started with Claude Code on the web - Claude Docs)。

  1. claude.ai/codeにアクセスしてログインする
  2. GitHubアカウントとの連携を行う
  3. 環境を作成する(ネットワークアクセスなど、VMの設定を行う)
  4. 作成した環境を選び、セッションを開始する ↓ start.png

あとはプロンプトを入力して実行するだけで始められます。ぜひ一度試してみてください。

まとめ

  • 実行環境隔離の目的は、サプライチェーン攻撃による情報漏洩の被害範囲を極小化すること。AIコーディングエージェントには様々なリスクがあるので、まず対処するリスクと経路を絞ることが出発点になる
    • ※ 「実行環境の隔離」は、プロンプトインジェクションなど他のリスクの被害極小化にも有用になり得ます。が、一度に沢山のリスクを扱うと話がややこしくなるため、今回はサプライチェーン攻撃による情報漏洩というリスクに絞って書いています。
  • 情報漏洩の成立には「到達できる」「送り出せる」の2条件が必要で、実行環境の隔離は「到達できる」範囲を絞る壁にあたる
  • 壁は3つ紹介した。①Bash sandbox(AIのコマンド実行を守る)、②Dev Container(開発環境ごと閉じ込める)、③Claude Code on the Web(実行環境そのものを端末の外に出す)
  • 原則は1つ。壁が守れるのは壁の外に置いたものだけ。持ち込む量を減らし、できれば端末の外へ
  • まずはClaude Code on the Webに1タスク流してみるところから始めてみてください

参考


Claudeならクラスメソッドにお任せください

クラスメソッドは、Anthropic社とリセラー契約を締結しています。各種製品ガイドから、業種別の活用法、フェーズごとのお悩み解決などサービス支援ページにまとめております。まずはご覧いただき、お気軽にご相談ください。

サービス詳細を見る

この記事をシェアする

AI白書

関連記事