「どのAPIを叩いてよいか」を組織が決められるようになった

Claude Code v2.1.285（2026年9月29日）に allowedProviders という管理設定が入った。changelog の記述はこうである。

allowedProviders 管理設定を追加。マシンが使ってよい API プロバイダを制限する（Anthropic API、カスタムエンドポイント、Bedrock、Mantle、Vertex AI、Foundry、AWS 上の Claude Platform、Cloud ゲートウェイ）。

なぜこれが要るのか

企業で生成AIを入れるとき、契約しているのは特定の経路である。 Bedrock 経由で契約し、データ処理条項もそこに紐づいている、という構成はよくある。

ところが開発者の手元では、環境変数ひとつで別のプロバイダに向けられる。契約の外を通った通信は、監査の対象にも入らない。

allowedProviders は、そこを管理側で閉じる。

同じ版で、もう1つ閉じている

CLAUDE_CODE_DISABLE_ATTACHMENTS を変更し、リポジトリの .claude/settings.json や .claude/settings.local.json からは設定できなくした。 シェル・ユーザー・管理設定からは引き続き設定できる。

こちらは設定の優先順位の整理である。リポジトリに置いた設定ファイルは、そのリポジトリを開いた全員に効く。つまりリポジトリに書ける設定は、リポジトリを触れる人なら誰でも変えられる。

添付の無効化のような安全側の設定が、リポジトリ側から上書きできる状態は望ましくない。

で、SEの実務ではどう使うか

この2つは同じ方向を向いている。「どこで決めた設定が勝つか」を整理する動きである。

社内で配るときに確認することが3つある。

管理設定がどこから来るか。 allowedProviders は管理設定なので、端末管理の仕組みで配る必要がある。MDM で配るのか、イメージに焼くのか、手順書で頼むのか。 最後のものは守られない前提で設計する。

リポジトリ側の設定をどこまで信じるか。 .claude/settings.json は便利だが、そこに書けるということは誰でも書き換えられるということでもある。外部から来たリポジトリを開く運用があるなら、ここは前提を疑う場所になる。

契約している経路と、実際に通っている経路が一致しているか。 契約は Bedrock、実際は個人の Anthropic API キー、という状態は起こりうる。allowedProviders はそれを機械的に止める手段になるが、止める前に現状を測っておかないと、止めた瞬間に業務が止まる。 shadow で観測してから閉じる順序になる。

稟議やセキュリティレビューに書くなら「使ってよい API プロバイダを管理側で固定できる」の一行が通る。経路が固定できるかどうかは、データ処理条項の実効性に直結する。

記述はすべて Claude Code の changelog に記載されているものである。