Claude CodeのHTTP hookを許可リストで閉じる

結論：managed設定が読めない時に何も許可しない状態を検証する

根拠はClaude Code公式changelogの2.1.267と、公式Hooks文書、公式Settings文書です。changelogは今回のfail-closed修正を明記し、Hooksは実行イベントとHTTP hookの扱い、Settingsはmanaged settingsの優先順位とscopeを説明します。専用料金や安全性の絶対保証は公式情報から断定しません。

三つの許可リストを比較する

設定	守る境界	確認する証拠
allowedHttpHookUrls	HTTP hookの送信先	URL、所有者、TLS、環境別endpoint
httpHookAllowedEnvVars	HTTP hookへ渡す環境変数	変数名、秘密情報、用途、mask
allowedChannelPlugins	利用を許可するchannel plugin	pluginの出所、scope、権限、更新

URLを許可しても、送信するpayloadに機密情報が含まれていれば問題は残ります。環境変数を許可しても、hookの所有者や更新経路が不明なら管理できません。pluginを許可しても、hookやMCPが呼び出す外部先が別にあるかもしれません。三つを一枚のallowlistにまとめず、責任者と変更承認を分けます。

fail-closedは「設定エラーが出たら永遠に停止する」という意味ではありません。読み取り不能な設定を、許可済みとして扱わないという判断です。ネットワーク不調、JSON破損、権限不足、管理サーバーの一時停止を同じ現象として済ませず、原因を特定して承認済みrevisionへ戻します。

設定と障害を切り分ける7ステップ

1. claude --versionで2.1.267以降か確認し、端末、実行面、設定revision、発生時刻を記録します。
2. HTTP hook、channel plugin、環境変数の三つを台帳で分け、送信先、データ分類、所有者を一行ずつ書きます。
3. allowedHttpHookUrlsの正確なURL範囲と、本番・staging・開発のendpointを確認します。
4. httpHookAllowedEnvVarsは変数名だけを確認し、token、cookie、API keyなどの値をログやチケットへ出しません。
5. allowedChannelPluginsの出所、version、提供するhook、権限、更新承認を確認します。
6. 設定が読めないケースを安全な検証環境で再現し、外部送信、plugin利用、hook実行が許可されないことを確認します。
7. 設定を復旧し、同じ操作をread-onlyで再実行してから、承認者、変更差分、rollback、利用者への影響を記録します。

検証用のhookは、外部サービスへ実データを送らないendpointを使います。HTTP statusが200でも、意図したpayloadだけが届いたとは限りません。送信項目、認証方式、retry、timeout、保存期間、閲覧権限を受信側でも確認します。環境変数は値を表示せず、存在、名称、マスク、利用目的だけを比較します。

managed settingsとローカル設定の境界

managed settings変更の承認記事で扱うように、組織設定と個人・project設定の役割を分けます。ローカルで許可先を追加しても、managed settingsの優先順位で無効になることがあります。逆に、管理者が広いURL範囲を配ると、利用者側で安全に狭めたつもりでも組織の設定が優先する場合があります。

外部通信の判断はChannelsの安全運用、MCPの外部接続はMCPセキュリティと接続します。ただしHTTP hookのURL許可とMCP serverのtransport許可は別の検索意図です。設定を一つの「安全済み」ラベルで代用せず、データの入口、処理、外部送信、戻し先を図にします。

料金について、今回確認した公式changelog、Hooks、Settings文書はHTTP hook許可リストに専用料金を定めていません。Claude Codeの契約、APIやproviderの利用料、送信先サービスの費用、ログ保存費用は別々に見積もります。安全設定を広げる理由として費用削減を推測しないでください。

fail-closedで業務が停止した場合の第一対応は、許可を一時的に全開にすることではありません。設定の読み取りログ、revision、変更者、発生したhook、対象endpointを確認し、最後に承認された設定へ戻します。緊急例外を使うなら対象ユーザー、期限、送信データ、承認者、解除確認を残します。

チェックリスト：HTTP hookを有効化する前に

□versionを確認したか　□URLを環境別に分けたか　□URLの所有者とTLSを確認したか　□渡す環境変数を名前だけ列挙したか　□秘密情報を除外したか　□pluginの出所とversionを記録したか　□managedとlocalの優先順位を確認したか　□読めない時に拒否されることを試したか　□受信payloadと保持期間を確認したか　□期限付き例外とrollbackを用意したか

設定が反映されない時は、version、JSON形式、ファイル権限、管理設定の取得、scope、URL一致の順に切り分けます。原因が不明なまま別のURLを追加したり、秘密情報をデバッグログへ出したりしないでください。接続を戻すことと、許可範囲を広げることは別の判断です。

よくある質問

設定が読めない時はhookが危険なまま動きますか？

2.1.267の公式changelogは、対象のmanaged allowlistが読めない時に何でも許可せず、何も許可しない修正を説明しています。実環境のversionと設定scopeは別途確認します。

URLをallowlistに入れればpayloadも安全ですか？

安全とは限りません。URL、payload、環境変数、認証、受信側の保存と閲覧権限を別々に確認します。

停止を避けるためにallowlistを広くしてよいですか？

広さで解決しません。まず読み取りエラーを直し、承認済みendpointだけを期限付きで復旧します。例外は対象と期限を記録します。

公式情報と無料診断

修正内容は公式changelog、hook仕様は公式Hooks、設定scopeは公式Settingsを公開直前にreadbackしています。Miraigentの無料診断では、hook、plugin、送信先、秘密情報、承認、停止条件を一つの運用表へ整理できます。