Claude Code v2.1.314——外部パス書き込みブロック追加と企業ゲートウェイに影響する変更点

この記事で分かること：

• permissions.blockWritesOutsideWorkingDirectoriesの仕組みと設定方法
• IdPグループを使ったゲートウェイ上流のルーティング制限の追加
• forceRemoteSettingsRefreshバグ修正が企業環境で意味すること

対象読者：企業でClaude Codeのゲートウェイや管理ポリシーを運用している担当者。v2.1.314は2026年10月30日にリリースされた。バグ修正が中心のリリースだが、セキュリティ設定の追加と、見落とすとポリシーが効いていない状態で運用し続けるリスクがある修正を含んでいる。

出典：https://github.com/anthropics/claude-code/releases/tag/v2.1.314（2026-10-30 公開）

workingDirectory外への書き込みを全パーミッションモードで拒否できるようになった

今回追加された機能のうち、セキュリティ設定として最も注目しているのがこれだ。

{
  "permissions": {
    "blockWritesOutsideWorkingDirectories": true
  }
}

この設定をtrueにすると、Write・Edit・NotebookEditの3ツールが、設定されたworkingDirectory以外のパスへの書き込みを全パーミッションモードで拒否する。

「全パーミッションモードで」という部分を見落としやすい。これは、自動承認（auto mode）や信頼済みのユーザーが操作している場合でも、設定が有効なら外部パスへの書き込みは拒否される。ゲートウェイ経由でClaude Codeを多人数で使っている環境で、意図しない場所への書き込みを防ぐ用途に使える。

この設定が無かったときに何が起きていたか

正直なところ、この設定が追加されるまで「workingDirectory外に書き込まれていた可能性がある」とは意識していなかった。

タスクの指示が「ファイルAを編集して」と書いてあっても、Claudeがそれに関連する設定ファイルを上位ディレクトリに置こうとする場面は実際にある。明示的な禁止設定がなければ、その書き込みを止める手段は「承認を求めるパーミッション設定になっているか」に依存していた。

設定を検討する際の注意点：

• workingDirectoriesに複数のパスを設定している場合、それらの外がすべて対象になる
• 既存のタスクで外部パスへの書き込みが必要なものがあれば、workingDirectoriesの設定を先に見直す必要がある
• リリースノートには「every permission mode」と明記されているので、auto modeでも効く

デフォルトはfalseなので、何もしなければ従来の振る舞いのままである。 まずは自分の環境でClaude Codeがどのディレクトリに書き込んでいるかを確認してからtrueに切り替える形が安全だ。

IdPグループによるゲートウェイ上流のルーティング制限が追加された

Claude apps gatewayの設定で、上流（upstream）ごとにIdPグループのリストを指定できるようになった。

upstreams:
  - name: prod-model
    groups:
      - ai-approved-users
  - name: dev-model
    # groups未指定 = 全ユーザー

指定したIdPグループのメンバーだけが、そのgroupsで指定された上流にルーティングされる。フェイルオーバー（上流が応答しない場合の代替ルーティング）でも同じグループルールが適用される。

これまで「誰でも全ての上流を使える」か「上流を完全に切り替える」かの2択だった部分に、グループベースの制御が入った。

具体的な用途：

• 本番用モデル（コストが高い）と開発用モデルを組織の役割で分けたい
• 特定のプロジェクトチームだけ特定の上流を使わせたい
• 試験的な上流を限定ユーザーに展開したい

コスト管理の視点からも、高コストの上流へのアクセスを承認が必要なグループに限定する运用がしやすくなる。

Bedrock上流にguardrail_traceが追加された

Amazon Bedrockのguardrailを使っている環境向けの変更だ。

upstreams:
  - name: bedrock-prod
    guardrail_trace: enabled

guardrail_traceを設定すると、Amazon Bedrockのguardrailがリクエストをフィルタリングした際にどのguardrailが発動したかをログに記録する。ただし、フィルタリングされたテキスト（マッチした内容そのもの）は記録されない。

これは監査対応やデバッグで役立つ。「なぜここでブロックされたのか」をあとから調べられるようになる。

マッチしたテキストが記録されない設計になっているのは、センシティブなコンテンツが誤ってログに残ることを避けるためと読める。個人情報・機密情報を含むリクエストがガードレールで止まった場合にも、その内容はログに出てこない。

forceRemoteSettingsRefreshのバグ修正——ポリシー未適用で起動していた可能性

今回のリリースで一番注目している修正がこれだ。

リリースノートの該当箇所：

Fixed forceRemoteSettingsRefresh set only in remote managed settings no longer applying once the stored copy had expired, which let sessions start without policy when the server could not be reached.

訳すと：リモートのmanaged settingsにforceRemoteSettingsRefreshだけを設定していた場合、キャッシュが期限切れになると、以降のセッションはポリシーなしで起動する可能性があった。

組織のポリシーサーバーが一時的に応答しない場面（ネットワーク障害・メンテナンス中）でセッションを開始したときに、意図しないポリシー未適用状態になっていた可能性がある。

確認しておきたいこと：

• forceRemoteSettingsRefreshをリモートのmanaged settingsだけに設定している環境
• ポリシーサーバーが短時間でも応答しない時間帯がある環境

今回の修正でこの振る舞いは解消された。ポリシーサーバーが応答できない場合、セッションはキャッシュ済みポリシーかフェイルセーフなデフォルトを使う形に修正されている。

無人実行環境にも関係するバグ：「自動継続が3回以上続く」バグ修正

もう一つ見ておきたいのが次の修正だ。

Fixed "Continue automatically at usage limit" continuing more than three times without a prompt from you when a task restarted itself between waits (a /goal check-in, a background or scheduled task).

/goalのチェックイン・バックグラウンドタスク・スケジュールタスクがタスクを再起動する場合に、「利用上限到達時に自動で続ける」の設定が3回以上続いてしまうバグがあった。

深夜の無人実行でClaude Codeがスケジュールタスクとして動いている場合、利用上限に達したあとも意図以上に継続していたケースがあったかもしれない。今回修正され、自動継続は3回で止まるようになった。

その他のバグ修正（ゲートウェイ経由環境向け）

以下の4件も適宜確認してほしい。

• tool_referenceブロックの拒否と再試行：tool searchのtool_referenceブロックを受け付けないゲートウェイで、それを除いたリクエストを再送信するようになった。セッション内で記憶される
• Microsoft Foundryでデフォルトモデルが未デプロイの場合のフォールバック：Sonnet・Opus・Haikuのデフォルトモデルがデプロイされていない場合、同じファミリーの古いモデルに自動フォールバックするようになった
• managed settingsのモデルピン故障の改善：managed settingsでモデルをピンしている場合、自分の--plugin-dirのプラグインが壊れていてもモデル切り替えが拒否されなくなった
• クラウドセッションの機能制御：組織のポリシーでクラウドセッションやリモートコントロールを無効にしている場合、関連のティップや通知が出なくなった

今回確認できたことと、まだ展開できていないこと

blockWritesOutsideWorkingDirectoriesの設定が、複数のworkingDirectoriesを指定したときのパスの部分一致・シンボリックリンクを含む場合などの具体的な挙動は、動かしてみないと分からない部分がある。自社環境で使う前に、小さなテストから確認することをすすめる。

forceRemoteSettingsRefreshのバグは過去のセッションに遡って影響するものではないが、「接続できなかった時間帯にポリシー未適用で動いていたか」を確認する手段はない。継続的な監査ログと組み合わせて運用するのが現実的だろう。

IdPグループルーティングは、既存の設定を変えることなく追加できる。試験的な上流を限定ユーザーに展開したい場面があれば、検討する価値はある。

V2.1.316との関係について

v2.1.316（2026-10-31）も同じ週にリリースされており、こちらは別記事にまとめている。v2.1.314はその直前版で、セキュリティ設定の追加とポリシー適用のバグ修正が中心。継続的に運用している環境では両バージョンの変更点を合わせて確認してほしい。

関連記事（note）：
https://note.com/light_tern636/n/n804f3de88a14