⟐ Claude Code/2026-07-25上級

strictAllowlist で Claude Code サンドボックスの外向き通信を締める

Claude Code v2.1.219 の sandbox.network.strictAllowlist を使い、自動化パイプラインの外向き通信を最小の許可リストで締める実践メモ。接続先を洗い出すスクリプトと運用の落とし穴まで。

Claude Code²⁰³ サンドボックス⁶ セキュリティ¹⁴ 自動化⁷¹ ネットワーク

✦ プレミアム記事

深夜に回している自動投稿パイプラインが、理由も告げずに途中で止まっていました。

ログには接続タイムアウトらしき痕跡だけ。回線を疑い、再実行すると通ることもある。よくある「たまに失敗するネットワーク」に見えました。けれど原因は回線ではありませんでした。許可リストに載せ忘れた一つのホストへの通信が、静かに拒否されていただけだったのです。

Claude Code v2.1.219（2026-07-24）で追加された sandbox.network.strictAllowlist を入れた直後のことでした。この記事は、その設定を個人開発の自動化に組み込んだときの実務メモです。設定を有効にする手順そのものよりも、有効にしたあとで何が壊れ、どう洗い出したかに紙幅を割きます。

「拒否」は障害の顔をしてやってくる

strictAllowlist の考え方はごく単純です。サンドボックス内で実行するコマンドに対して、許可リストにないホストへの外向き通信を拒む。自動化を安全側の既定で回すための、ちょうどよい締め方です。

ただ運用してみて分かったのは、拒否そのものより「拒否の見え方」が厄介だということでした。

許可リストから漏れたホストへの接続は、アプリケーションから見れば単なる接続失敗です。多くのツールはそこで「ネットワークが不調」と解釈し、リトライやタイムアウトのメッセージを出します。つまりポリシーによる意図的な遮断が、偶発的な回線障害と区別できない顔で現れる。ここが最初の落とし穴でした。この罠を回避するには、原因を推測する前に事実を観測することです。

そこで私が最初にやったのは、許可リストを書くことではなく、パイプラインが実際にどのホストへ出ていくのかを一度残らず観測することでした。

実際に触るホストを洗い出す

頭の中の「たぶんこのホストに繋ぐはず」は当てになりません。connect(2) をトレースして、宛先を事実として集めます。次のスクリプトは、任意のコマンドをラップして接続先ホスト名を吐き出します。

#!/usr/bin/env bash
# egress-recon.sh — コマンドが実際に接続するホストを洗い出す
# 使い方: ./egress-recon.sh <実行したいコマンド...>
#   例: ./egress-recon.sh bash deploy-pipeline.sh
set -euo pipefail
 
TRACE="$(mktemp)"
trap 'rm -f "$TRACE"' EXIT
 
# connect(2) だけを追い、宛先アドレスを記録する
# -f: 子プロセスも追跡（git や npm はサブプロセスを大量に生む）
strace -f -qq -e trace=connect -o "$TRACE" "$@" || true
 
# IPv4 の宛先を抽出（sin_addr=inet_addr("x.x.x.x")）
grep -oE 'inet_addr\("[0-9.]+"\)' "$TRACE" \
  | grep -oE '[0-9]+\.[0-9]+\.[0-9]+\.[0-9]+' \
  | sort -u > "$TRACE.ip"
 
echo "# 接続先ホスト（逆引き済み・重複排除）"
while read -r ip; do
  # ローカル/リンクローカルは除外
  case "$ip" in 127.*|0.0.0.0|169.254.*) continue;; esac
  host="$(getent hosts "$ip" | awk '{print $2}')"
  printf '%-24s %s\n' "${host:-"(逆引き不可)"}" "$ip"
done < "$TRACE.ip" | sort -u

ポイントは -f です。git push も npm install も、実処理は子プロセスに委ねます。親プロセスだけ見ていると、肝心の接続を丸ごと取りこぼします。逆引きが効かないIPは、そのIP自体を控えておき、後述のログから用途を突き合わせます。

私の環境でこれを一度回したところ、接続先は11ホストありました。事前に想定していたのは4つ。想定のおよそ2.7倍です。

✦

ここまでお読みいただきありがとうございます。

この記事の続きを読む

この先には、実装コードやベンチマーク結果など、実務でお役に立てる内容をご用意しています。このサイトは広告を掲載しておらず、サーバーや開発にかかる費用はメンバーの皆様のご支援で成り立っています。もしお役に立てていましたら、ご支援いただけますと大変ありがたいです。

この記事で得られること

✦パイプラインが実際に触るホストを connect(2) トレースで洗い出す実行可能なスクリプト

✦許可リストに一つのホスト名だけ載せても足りない理由と、私が踏んだ具体的な失敗

✦拒否された通信を観測可能にして、ネットワーク障害と切り分ける運用パターン

Stripe による安全な決済 · いつでもキャンセル可能

✦

この記事を購入する

この先の内容をすべてお読みいただけます。一度のご購入で、いつでも何度でもアクセスできます。このサイトは広告を掲載しておらず、皆さまのご支援がサーバー費用などの運営を支えています。

または

メンバーシップなら全記事が読み放題 →

一つのホスト名では足りない

ここが、ドキュメントを眺めているだけでは掴めなかったところです。

私は素朴に「GitHub に push するなら github.com を、Anthropic の API を叩くなら api.anthropic.com を許可すれば足りる」と考えていました。ところが recon の結果は違いました。

論理的な操作	実際に接続したホスト
git push / fetch（HTTPS）	github.com と、資産取得時の codeload.github.com
npm install	registry.npmjs.org と、tarball 配信の別ホスト（CDN）
Claude API 呼び出し	api.anthropic.com
名前解決	そもそも DNS が通らなければ全て止まる

一つの「操作」が、複数のホストへ扇状に広がっていました。とりわけ npm の tarball が別ホストから配られる点、git が状況によって codeload.github.com を掴む点は、実際に接続を観測するまで気づけませんでした。

つまり「サービス一つにつきホスト一つ」という前提そのものが誤りだったのです。この思い込みのまま許可リストを書いていたら、あの深夜の停止は延々と再現していたはずです。

ワイルドカードという誘惑に負けない

漏れが出るたびにホストを足すのは面倒です。そこで *.amazonaws.com のような広いワイルドカードで済ませたくなります。

一度はそう書きかけました。けれど手が止まりました。CDN の tarball が載っているクラウドを丸ごと許可することは、無関係な無数のバケットやエンドポイントへの通り道を同時に開くことでもあります。strictAllowlist をわざわざ入れた目的が、その一行で薄まってしまう。

結論として私は、広いワイルドカードよりもたまの取りこぼしを受け入れる方を選びました。許可リストは具体的なホスト名で埋め、増えたら recon をもう一度回して差分を足す。安全側の既定という趣旨を、運用の楽さと引き換えにしない判断です。この方針を強く推奨します。

有効化までの三手順

慌てて設定を入れず、次の順で進めると事故が減りました。

パイプラインを一度、strictAllowlist なしで egress-recon.sh にかけて接続先を全て記録する
記録したホスト名を許可リストに落とし、strictAllowlist を有効化する
guard-run.sh で毎回の実行を監視し、想定外の接続が出たらはっきり失敗させる

この三手順を挟むだけで、「本番で静かに止まる」を「事前に一度だけ観測して潰す」に置き換えられます。

設定と、拒否を観測可能にする

洗い出したホストを設定に落とします。キー名はお使いのバージョンの設定スキーマに合わせて確認してください（strictAllowlist は新しい設定のため、細部は更新される可能性があります）。私はこの設定を .claude/settings.json に置いて運用しています。

// .claude/settings.json（設定例）
{
  "sandbox": {
    "network": {
      "strictAllowlist": true,
      "allow": [
        "api.anthropic.com",
        "github.com",
        "codeload.github.com",
        "registry.npmjs.org"
      ]
    }
  }
}

そのうえで、拒否をネットワーク障害と取り違えないための観測を足します。パイプラインを一段ラップし、想定外のホストへ出ていないかを実行のたびに記録する薄い仕掛けです。

#!/usr/bin/env bash
# guard-run.sh — 実行中に触れたホストを許可リストと突き合わせる
set -euo pipefail
ALLOW_FILE="${1:?allowlist ファイルを渡してください}"; shift
SEEN="$(mktemp)"; trap 'rm -f "$SEEN"' EXIT
 
# egress-recon.sh を内側で使い、接続先を集める
./egress-recon.sh "$@" | awk '{print $1}' | grep -vE '^\(' | sort -u > "$SEEN"
 
# 許可リストにない接続先だけを警告として出す
UNKNOWN="$(comm -23 "$SEEN" <(sort -u "$ALLOW_FILE") || true)"
if [ -n "$UNKNOWN" ]; then
  echo "⚠️ 許可リスト外への接続を検知しました:" >&2
  echo "$UNKNOWN" >&2
  # 自動化では「静かに失敗」より「はっきり失敗」を選ぶ
  exit 1
fi
echo "✅ 接続先はすべて許可リスト内でした"

これを入れてから、パイプラインの停止が「回線のせい」なのか「許可リストの漏れ」なのかを、ログの一行で言い切れるようになりました。原因のない再実行が消えたのが、いちばん体に効いた変化です。

運用で効いた判断

数週間回して残った、状況別の勘所を残しておきます。

場面	とった判断
新しいツールを導入する	まず recon を回し、増える接続先を許可リストへ反映してから本番に載せる
取りこぼしが怖い	ワイルドカードで広げず、guard-run で「はっきり失敗」させて差分を足す
逆引きできないIPが出た	そのIPを控え、直前後のログで用途を突き合わせてからホスト名を許可
DNS が怪しい	名前解決の経路が許可されているかを最初に確認する（ここが塞がると全滅する）