AIの自動モードが怖い｜通信先をコマンド単位で許可する

「AIに自動で作業させたいが、勝手に外のサーバーへ通信されるのが怖い」「一度『はい』を押したら、そのあと何に繋がれても分からない」——AIエージェントに仕事を任せようとするとき、多くの人がここで手を止めます。

結論から言うと、この怖さの正体は「任せるかどうか」ではなく許可の「単位」が大きすぎることです。単位がセッション全体なら、一度の承認が最後まで効き続けます。単位がコマンド1本なら、承認はその1本で終わります。単位が小さくなるほど、むしろ安心して任せられる範囲は広がります。

株式会社Fyveは中小企業のAI活用を伴走支援しており、自社でも人が見ていない時間帯にAIのジョブを毎日走らせています。この記事では、2026年9月に入った「通信許可をコマンド単位にする」変更と、それと対になる「下請けに指示書を読ませない」設定を、私が一次情報で確認した内容だけで解説します。

結論｜決めるのは「任せる／任せない」ではなく、開ける単位

AIエージェントの安全設計は、つい「自動で走らせる」か「毎回確認する」かの二択で考えがちです。しかし実際に無人で回してみると、この二択はどちらも破綻します。

毎回確認する運用は、人が張り付いていないと止まります。かといって全部自動にすると、承認の範囲が見えません。現実的な着地点は二択の間ではなく、別の軸にあります。それが「どの単位で開けるか」です。

AIに開けるものは、大きく2方向あります。

• 外へ何を開けるか——どのサーバー・どのホストへ通信してよいか
• 中へ何を入れるか——どの指示書・どのルールを読ませるか

この2つはこれまで、どちらも「セッション単位」「全部読ませる」という粗い単位でしか決められませんでした。2026年9月に配布された版で、その両方に細かい単位が入りました。以下、順に見ていきます。

これまでの通信許可は「セッション単位」だった

まず、変更前がどうだったかを正確に押さえます。ここを飛ばすと「何が良くなったのか」が分かりません。

公式ドキュメントのサンドボックス解説は、ネットワーク制限の挙動をこう書いています（2026年9月16日時点・筆者訳）。

ドメイン制限：Claude Code は既定ではどのドメインも事前許可しません。コマンドが新しいドメインを必要とした最初の1回、Claude Code は承認を求めます（自動モードでは分類器に判断を送ります）。プロンプトで「はい」を選ぶと、Claude Code はそのホストを現在のセッションの残りの間ずっと許可し、以降そのホストへの接続では二度と確認しません。

原文は "If you choose Yes when prompted, Claude Code allows the host for the rest of the current session and doesn't prompt again for later connections to the same host." です。

つまり、承認の有効範囲は「このコマンド」ではなく「このセッション」でした。ビルドを通すために一度パッケージ配布元への通信を許可したら、その後そのセッションで走るすべてのコマンドが、同じ配布元へ自由に通信できます。

なぜこれが無人運用で特に効くのか

人が画面を見ている作業なら、この粗さはさほど問題になりません。せいぜい数十分でセッションが終わりますし、何が起きたかを目で追えます。

問題は、人が見ていない時間に長時間走るジョブです。1回のセッションが数時間続き、その中で何十本ものコマンドが走る。冒頭で1回押した「はい」が、最後の1本まで効き続けます。しかも、それが妥当だったかどうかを判断する人が、その場にいません。

「許可の範囲がどこまで及ぶか」を読み違える問題そのものについては、別記事で承認画面の読み方を詳しく扱っています。

Claude CodeClaude Codeの許可ダイアログ｜権限の範囲を読む

読者特典・無料ダウンロードClaudeのこの5つの設定、今すぐ見直した方がいい無料でダウンロード →↓

2026年9月の版で、通信許可が「コマンド単位」になった

この粗さに対する変更が、バージョン 2.1.271 に入りました。変更履歴の原文はこの1行です。

Added per-command allowed_domains to Bash, PowerShell and Monitor in auto mode with sandboxing: the hosts a command needs are reviewed with it and opened for it alone; other hosts are refused

筆者訳：自動モード＋サンドボックス時の Bash・PowerShell・Monitor に、コマンドごとの allowed_domains を追加した。そのコマンドが必要とするホストは、そのコマンドと一緒に審査され、そのコマンドのためだけに開かれる。それ以外のホストは拒否される。

何が変わるのか

変化は「審査の単位」と「有効範囲の単位」が、どちらもコマンド1本に揃ったことです。

実務的に言えば、1本の curl を許しても、次のコマンドの通信は広がりません。「ビルドのためにパッケージ配布元を開けたら、そのセッションのあいだ全部のコマンドがそこへ繋げる」という状態が消えます。

使える前提条件は2つ揃っていること

ここは取り違えやすいので明確にします。この機能が効くのは、変更履歴の原文にあるとおり "in auto mode with sandboxing"、つまり以下の2つが両方成立しているときです。

• 自動モードで動いている（各ツール呼び出しを分類器が審査する状態）
• サンドボックスが有効になっている（OSレベルでファイルとネットワークの境界が効いている状態）

公式ドキュメントは、この2つが別々の層であることを明記しています。「サンドボックスの auto-allow モードは自動モードとは別物で、auto-allow はサンドボックスの境界が封じ込めているからBashコマンドを承認する。一方の自動モードは分類器が動作を審査する。この2つは独立して働き、組み合わせることができる」という趣旨です。名前が似ているだけで、別の層です。

また対象ツールは Bash・PowerShell・Monitor の3つと明記されています。WebFetch のような本体側のツールは、従来どおり自分の権限ルールに従います。

版と日付を実測で確定する

変更履歴には日付が書かれていないため、配布元のレジストリで公開時刻を直接確認しました（2026年9月16日 06:08 JST 時点・筆者実測）。

「9月14日のリリース」と書かれている記事を見かけますが、それは協定世界時での話です。日本時間では9月15日未明の配布になります。数時間の差ですが、社内で「いつから使えるようになったのか」を詰めるときに効いてきます。

配布タグの状態も同時刻に実測しました。latest と next がともに 2.1.273、stable は 2.1.267 です。つまり安定版として配られている版は、最新版より6版ぶん後ろにいます。手元がどのタグを追っているかで、この機能が使えるかどうかは変わります。

似た名前が4つある｜取り違えると「設定したのに効かない」

ここがこの記事でいちばんお伝えしたい落とし穴です。ネットワークの許可まわりには、名前がよく似ていて、役割がまったく違う設定が4つ存在します。

私は今回、公式ドキュメント206ページを全文取得して横断検索しました。その結果を表にまとめます（2026年9月16日時点・筆者実測）。

③と④は綴りが同じで、機能がまったく違う

③と④は、どちらも allowed_domains という同じ綴りです。しかし片方は通信を開ける権限設定、もう片方は検索結果を絞る表示オプションで、安全性への寄与はまるで違います。

ドキュメントのWebSearchの項には、こう書かれています。「Claude は allowed_domains で結果を特定のホストだけに絞り込むか、blocked_domains で除外できる。この2つのリストを1回の呼び出しで併用することはできない」——「結果を絞る」であって「通信を止める」ではありません。

ここが実害になるのは、読者がドキュメントを allowed_domains で検索したときです。検索して最初に当たるのは④のほうで、③は出てきません。④の説明を読んで「ドメインを制限できるのか」と理解し、実際にはWebSearchの結果が絞られているだけで通信の権限は何も変わっていない、という取り違えが起こり得ます。

③は変更履歴にしか載っていない（実測）

206ページを横断検索した結果、③のコマンド単位の allowed_domains は、変更履歴のページ以外のどこにも記載がありませんでした。サンドボックス解説にも、設定リファレンスにも、権限モード解説にも、ツールリファレンスにもありません。

さらに言えば、前の章で引用したサンドボックス解説の「はい を押すとセッションの残りの間ずっと許可される」という記述は、本記事執筆時点でもそのまま残っています。つまり公式ドキュメントは、この点についてまだ旧来の挙動を説明している状態です。

これは批判ではなく、運用上の前提として押さえるべき事実です。ドキュメントの更新は、配布物の更新より遅れることがあります。新機能の可否を判断するときは、ドキュメントだけを根拠にしないほうが安全です。

なお、対になるもう1つの新設定（後述する omitClaudeMd）は、同じ版で入ったにもかかわらずドキュメントに反映済みでした。同じリリースでも、記載の有無は機能ごとに割れます。

手順｜自動モードに任せる前にやる4つのこと

ここまでを踏まえ、実際に手を動かす順番に落とします。

手順1：自動モードは必ずサンドボックス付きで使う

前述のとおり、コマンド単位の通信許可は自動モードとサンドボックスが両方成立しているときにだけ働きます。自動モードだけを有効にしてサンドボックスを切っていると、この粒度は手に入りません。

公式ドキュメントは、この2層を分けて使うことの意味も明記しています。「実効的なサンドボックス化には、ファイルシステムとネットワークの両方の隔離が必要である。ネットワーク隔離がなければ、乗っ取られたエージェントは秘密鍵のような機微なファイルを外部へ持ち出せてしまう」という趣旨です。片側だけ締めても、もう片側から抜けます。

手順2：常に必要な接続先だけを「事前許可」に置く

毎回の作業で必ず要る接続先——パッケージ配布元、ソース管理のホスト、社内APIなど——は、①の sandbox.network.allowedDomains に書いて事前許可にします。ここに書いたものは確認を求められません。

逆に言えば、ここに書くのは「毎回要るもの」だけにします。「たぶん使うかも」で足していくと、事前許可のリストが実質的なフリーパスになり、単位を細かくした意味が消えます。

手順3：残りは「聞く」ではなく「拒否」に倒す

既定では、許可リストに無いホストはその都度確認されます。これは人が見ている作業なら妥当ですが、無人運用では確認に答える人がいません。

そこで sandbox.network.strictAllowlist を true にすると、許可リストの外のホストは確認ではなく拒否になります。公式ドキュメントによれば、この設定はユーザー設定・管理設定・CLIの --settings でのみ有効で、リポジトリ側の設定ファイルに書いても効きません（v2.1.219以降）。

「リポジトリに置いたのに効かない」は、この手の設定でいちばん起きやすい失敗です。どこに書けば効くかは、設定ごとに違います。

手順4：広げたい接続先は「そのコマンド」に足す

ここが今回の変更の使いどころです。特定の作業だけに必要な接続先は、事前許可リストを太らせるのではなく、そのコマンドに書いて、そのコマンドのためだけに開きます。作業が終われば、その許可も終わります。

加えて、広いワイルドカードを許可しつつ特定のホストだけを落としたい場合は sandbox.network.deniedDomains が使えます。組織として個人が許可を広げられないようにするなら sandbox.network.allowManagedDomainsOnly（管理設定でのみ指定可）があります。

もう1つの単位｜下請けに「何を読ませるか」

ここまでは「外へ何を開けるか」の話でした。同じ版に、もう1つの単位——「中へ何を入れるか」——の設定が入っています。

変更履歴の原文はこうです。

Added omitClaudeMd to agent frontmatter and --agents JSON, letting custom and plugin subagents run without user, project and local CLAUDE.md files; managed policy files still load

筆者訳：エージェントの先頭定義と --agents JSON に omitClaudeMd を追加した。これにより、自作およびプラグインのサブエージェントを、ユーザー・プロジェクト・ローカルの CLAUDE.md ファイル無しで起動できる。管理ポリシーのファイルは引き続き読み込まれる。

組み込みのものは、すでにそうなっていた

ドキュメントを読むと、これはまったく新しい発想ではなく、既存の挙動を自作にも開放したものだと分かります。

公式のサブエージェント解説は「Explore と Plan は、調査を速く安く保つために、あなたの CLAUDE.md ファイルと親セッションの git 状態をスキップする。それ以外の組み込み・自作のサブエージェントは両方を読み込む——その定義が omitClaudeMd を設定していない限りは」という趣旨を書いています。

つまり「調査役には社内ルール一式を読ませない」という判断は、提供側がすでに組み込みの探索役で採用していたわけです。今回入ったのは、その判断を自分の下請けにも適用できるスイッチです。

自分のリポジトリで実際に測ってみた

「毎回読ませている指示書」がどれくらいの量になっているか、私は感覚で把握していただけでした。今回、実際に数えてみました（2026年9月16日時点・筆者実測）。

私は複数の事業を1つのリポジトリにまとめて管理しています。その中の指示書ファイルは以下のとおりでした。

つまり、1つのプロジェクトで作業を始めるたびに4万バイト超の指示書が毎回読み込まれていたことになります。これが、下請けに回す機械的な作業——ファイル名を揃える、定型のコードを書く、同じ変換を繰り返す——でもそのまま全部読まれていました。

指示書の中身は、事業ごとの方針、料金の扱い、記事の書き方、フォルダの役割といったものです。ファイル名を揃える作業に、事業方針は要りません。

なお、指示書そのものの書き方——何を書き、何を別ファイルに追い出すか——については別記事で詳しく扱っています。読ませる量を減らす前に、そもそも書きすぎていないかを見る順番のほうが先です。

Claude CodeCLAUDE.mdの書き方実践ガイド｜200行以下で最大効果を引き出す

外してよい作業と、外してはいけない作業

公式ドキュメントは使いどころを一言で書いています。「委任時の指示だけで必要なものがすべて揃うサブエージェントに使え」。この基準は実務でもそのまま使えます。

判定は1問で足ります。「この作業の指示文を読んだだけで、下請けは正しく終われるか」——終われるなら外してよい、終われないなら外してはいけない、です。

• 外してよい例：指定した書式への変換、渡したファイル群の検索・集計、テストの実行、定型のひな形生成。いずれも「何をするか」が指示文に完結しており、自社の方針を知らなくても正解が決まる作業
• 外してはいけない例：外部に出す文章を書く、料金や条件に触れる、顧客に関わる判断をする。これらは自社ルールを知らないともっともらしく間違えます。しかも間違いが表に出るまで気づきません

迷ったら外さないのが正解です。削減の効果は毎回少しずつですが、外し間違えたときの損失は一度で大きく出ます。

3つの注意点

ドキュメントの記述から、実務で引っかかりやすい点を3つ挙げます。

• 組織の管理ポリシーは外れない。変更履歴もドキュメントも「managed policy files still load」と明記しています。組織として守らせているルールは、この設定では抜けません（ただし管理者が配布したサブエージェントは例外と記載されています）
• 主役として起動したときは無視される。--agent やその設定でセッション本体のエージェントとして動かす場合、この指定は効きません。あくまで下請けとして呼ばれたときの設定です
• v2.1.271以降が必要。ドキュメントに版が明記されています。前述のとおり stable タグはこれより後ろにいることがあるので、手元の版を確認してください

もう1点、量の目安として参考になる記述があります。ドキュメントは「組み込み以外のサブエージェントの説明文の合計が15,000トークンを超えると、起動時に合計トークン数つきの警告が出る」としています。提供側も「下請けの定義は放っておくと膨らむ」前提で警告を用意しているということです。

別のベンダーでも、同じ形が出ている

「通信先を絞る」という考え方は、特定の製品に固有のものではありません。同じ形が複数のベンダーで同時期に出てきています。

OpenAI の Agents API では、エージェントを動かす環境のネットワーク設定を3択で指定します。外向き通信を許可する、遮断する、そして列挙したホストのみ許可する——この3つ目の指定に使うリストが、やはり allowed_domains という名前です。この内容は、私が2026年9月に公式ドキュメントを読んで整理した別記事に基づいています。

Agents APIとは｜OpenAIに預ける範囲の決め方

なお本記事の執筆時点（2026年9月16日）で、この仕様を書いた公式ページを再取得しようとしたところ、該当URLがドキュメント索引を返す状態で原文を確認できませんでした。細かい制約（指定できるホスト数の上限やワイルドカードの可否）は変わり得るため、実際に設定する際は公式ドキュメントで最新の記述を確認してください。

違いは単位です。あちらは環境（エージェントを動かす箱）に対して1回決める形で、こちらはコマンド1本に対して決める形です。どちらが優れているという話ではなく、粒度の選び方が製品によって違う、と理解するのが正確です。

導入を検討する立場で押さえるべきは、「どのベンダーも、任せる／任せないの二択ではなく、開ける範囲を宣言させる方向へ進んでいる」という点です。ベンダーを比較するときは、機能の有無ではなく宣言の単位を見ると違いが見えます。

私が無人運用でつまずいたところ

ここまでは仕組みの話でした。実際に人が見ていない時間にAIのジョブを回してみて、身をもって学んだことを2つ書きます。

一度広げた許可は、人が見ていないと戻らない

設定を広げるのは、たいてい「今それで詰まっているから」です。作業が止まっていて、原因が権限で、広げれば通る。だから広げます。

問題は、広げた許可を狭め直す用事が、その後一度も発生しないことです。広いままでも何も壊れないので、誰も気づきません。人が見ている作業なら、次に同じ画面を開いたときに「これ要らないな」と気づく機会がありますが、無人のジョブにはその機会がありません。

だから「あとで狭める」を前提にした運用は成立しないと考えるようになりました。狭める作業を人の記憶に任せず、最初から狭い単位で開くようにする。今回の変更が効くのは、まさにこの点です。コマンドが終われば許可も終わるので、狭め直す作業そのものが不要になります。

「そのコマンドのために用意されていないもの」は効かない

もう1つは、単位という考え方そのものを叩き込まれた失敗です。

無人で回しているジョブの中に、別のコマンドを子プロセスとして起動する処理がありました。あるとき、その子プロセスが認証情報を受け取れずに失敗し続けました。同じ失敗が25回連続で起きてから、ようやく原因に辿り着きました。

原因は単純で、親が持っていた認証情報が、子プロセスには渡っていなかったことです。親の環境では通っていたので、設定は正しく見えました。しかし子には渡っていない。それまでは別の仕組みが代わりに効いていて、それが期限切れで静かに止まった結果、露呈しました。

この失敗が厄介だったのは、エラーが派手に出なかった点です。処理は動き、結果だけが毎回「判定できません」になる。人が見ていれば1回目で気づいたはずですが、無人なので25回積み上がりました。

ここから学んだのは、権限も認証情報も「実行される単位」に紐づいているということです。親で通ることは、子で通ることを意味しません。セッションで許可されていることは、そのコマンドで許可されていることを意味しません。今回の変更は、この当たり前を製品の側が明示的に扱うようになったものだと受け止めています。

ドキュメントより先に、変更履歴に出る

最後に、この記事を書く過程で分かった運用上の教訓を共有します。自分が使っている道具は、告知なしに変わっていることがあります。

今回の2つの機能について、私が確認した範囲では次のような状態でした（2026年9月16日時点・筆者実測）。

• コマンド単位の allowed_domains：206ページの公式ドキュメントのうち、変更履歴のページにしか記載がない。サンドボックス解説は旧来の「セッション単位」の説明のまま
• omitClaudeMd：サブエージェント解説の一覧表に記載あり（必要な版も明記）
• 公式ドキュメントのURL：docs.claude.com 配下のアドレスは、現在 code.claude.com 配下へ301で転送される。ブックマークが古いままでも読めるが、参照先としてURLを書き残すなら転送先を見ておくほうが安全
• 配布タグ：latest と next が 2.1.273、stable は 2.1.267（6版ぶんの差）

この状態で「公式ドキュメントに書いてあるか」だけを基準にすると、入っている機能を見落とします。逆に、二次的なまとめ記事だけを基準にすると、機能の前提条件（自動モード＋サンドボックスの両立など）が落ちた形で伝わります。

確かめる順番

私は次の順番で見るようにしています。難しいことはしておらず、どれも公開されている情報です。

1. 変更履歴を見る。何が入ったかは、いちばん早くここに出ます
2. 配布元のレジストリで公開時刻とタグを見る。「いつから」「どのタグに」が事実として取れます
3. ドキュメントで前提条件と制約を確認する。変更履歴は1行なので、効く条件・書く場所・必要な版までは分かりません
4. 手元の版で実際に動かす。上の3つが揃っても、自分の環境で使えるとは限りません

この順番が効くのは、それぞれが答える問いが違うからです。変更履歴は「何が」、レジストリは「いつから」、ドキュメントは「どう使うか」、実機は「自分で使えるか」に答えます。どれか1つで済ませようとすると、必ずどこかが抜けます。

よくある3つの誤解

「サンドボックスを入れたのだから、通信も止まっているのでは？」

止まりません。サンドボックスはファイルとネットワークの境界を定義する枠組みであって、既定で通信を全面遮断するものではありません。ドキュメントは「Claude Code は既定ではどのドメインも事前許可しない」と書いていますが、これは「確認を求める」という意味であって「拒否する」ではありません。

確認ではなく拒否に倒すには、前述の strictAllowlist を明示的に設定する必要があります。入れただけでは、確認が増えるだけです。

「設定ファイルに書いておけば、どこに書いても同じでは？」

違います。前述のとおり strictAllowlist はリポジトリ側の設定ファイルに書いても効きません。allowManagedDomainsOnly は管理設定でのみ指定できます。設定ごとに「効く場所」が決まっています。

これは不便に見えて、実は理にかなっています。リポジトリの設定ファイルは、そのリポジトリを開く人が書き換えられます。そこに置いた制限は、制限として機能しません。「個人が緩められない層」を別に用意しているからこそ、組織としての制限が意味を持ちます。

「下請けに指示書を読ませないと、品質が落ちるのでは？」

落ちる作業と落ちない作業があります。前述の判定——「委任時の指示だけで正しく終われるか」——で分かれます。

注意すべきは、判断を逆にしたときの損失の非対称性です。読ませる必要のない作業に読ませても、無駄が出るだけで品質は落ちません。逆に、読ませるべき作業から外すと、もっともらしく間違った成果物が出てきます。迷ったら外さないが安全側です。

まとめ｜任せられる範囲は、単位を下げるほど広がる

この記事の要点を整理します。

• AIに自動で作業させることへの不安は、許可の「単位」が大きすぎることから来ています。二択で考えず、単位で考えるほうが実務に乗ります
• 2026年9月の版（2.1.271・日本時間9月15日未明の配布）で、通信の許可がセッション単位からコマンド単位へ下がりました。効くのは自動モードとサンドボックスが両方成立しているときです
• allowed_domains という同じ綴りが、通信の権限設定と、検索結果の絞り込みという別機能の両方で使われています。ドキュメント内を検索すると後者が先に当たるため、取り違えに注意してください
• 同じ版で、下請けに指示書を読ませない設定（omitClaudeMd）も入りました。判定基準は「委任時の指示だけで正しく終われるか」です
• 新機能はドキュメントより先に変更履歴に出ます。変更履歴・レジストリ・ドキュメント・実機の4つは、それぞれ別の問いに答えます

単位を細かくすることは、一見すると管理の手間が増えるように思えます。しかし実際には逆でした。単位が小さいほど、その場の判断で開けても後に残らないので、狭め直す作業そのものが消えます。人が見ていない時間に動かすものほど、この差は効いてきます。

株式会社Fyveでは、中小企業のAI導入を「どこまで任せるか」ではなく「どの単位で開けるか」から設計する形で伴走しています。自動モードを切ったまま使い続けている、あるいは怖くて一部の作業しか任せられていない、という状態であれば、たいていの場合ボトルネックは機能ではなく許可の単位の決め方にあります。