複数人でClaude Code（Anthropic製のAIコーディングエージェント）を導入しているチームのマネージャーやテックリードに向けた内容です。誰がどの経路でAPIに接続できるかを、組織側で制御する方法を整理します。
AI駆動開発を導入したチームで見落とされがちなのが、開発者ごとの接続経路の管理です。Claude Codeはローカル実行のAPIキーだけでなく、Bedrock（AWSのマネージドAIサービス）やVertex AI（Google Cloudの機械学習基盤）など複数の経路から呼び出せます。経路が増えるほど、どのメンバーがどの認証情報でアクセスしているか把握しづらくなります。
v2.1.285ではこの課題に対応するallowedProvidersという管理設定が追加されました。あわせて、リモートアクセスやプラグイン設定に関わる変更も入っています。Hacker Newsでは「Claude Codeの設定でリモートアクセスが静かに有効になっていないか確認して」という投稿が話題になりました。これは今回のリリースが扱う設定管理の重要性を裏付ける事例です。
前提条件
手順を試す前に、以下を確認しておきます。
- Claude Codeのバージョンが v2.1.285 以降であること（
claude --versionで確認） - チーム管理者権限、またはmanaged settings（管理設定ファイル）を編集できる立場であること
- 利用しているAPI経路（Anthropic API直接契約か、Bedrock/Vertex AI/Foundryなどの企業契約か）を事前に把握していること
管理設定ファイルはOSごとに配置場所が異なります。詳細な配置パスは公式ドキュメントの「managed settings」の項目で確認してください。
バージョン確認と更新
まず手元の環境が対象バージョンに達しているかを確認します。
claude --version古い場合は通常のアップデート手順（npm update -g @anthropic-ai/claude-codeなど、導入方法に応じたコマンド）で更新します。
allowedProvidersで接続経路を制限する
チームで許可したい経路だけをmanaged settingsに列挙します。対象になるのは、Anthropic API、カスタムエンドポイント、Bedrock、Mantle、Vertex AI、Foundry、AWS上のClaude Platform、Cloud gatewayの各経路です。
{
"allowedProviders": ["bedrock", "vertex-ai"]
}この設定を配布すると、マシン単位でどの経路が使えるかを組織側でコントロールできます。個人のAnthropic APIキーを勝手に使われるリスクを抑えたいチームには有効な選択肢です。
プラグインのMCPサーバー設定を install 時に固定する
チームでMCP（AIエージェントが外部ツールと連携するための共通プロトコル）サーバーをプラグイン経由で配布している場合、v2.1.285からは.mcpb形式のバンドルに対して、インストール時に個別設定を渡せるようになりました。
claude plugin install my-plugin --config server.apiKey=xxxx従来は/pluginメニューからConfigureを開いて手動設定する必要がありましたが、これでオンボーディング時に一括設定を流し込めます。新メンバーの環境構築を標準化したいチームには手間の削減になります。
プラグインの設定内容を棚卸しする
既存プラグインの設定状況を確認するコマンドも追加されています。
claude plugin configure my-pluginこれを実行すると、そのプラグインが持つオプション一覧と、未設定の項目が表示されます。棚卸しの定例作業に組み込んでおくと、設定漏れによる不具合を未然に防げます。
動作確認の方法
設定を配布したあとは、対象マシンで意図しない経路が塞がれているかを確認します。具体的には、許可していない経路向けの認証情報でセッションを開始し、エラーになることを確認する方法が確実です。
またclaude plugin configure <plugin>を実行し、未設定項目が想定通り埋まっているかをチェックします。CI環境やオンボーディングスクリプトに組み込んでおけば、設定の抜け漏れを継続的に検知できます。
ハマりやすいポイント
今回のリリースには、managed settingsファイルが読み込めない場合の挙動修正も含まれています。以前はOS側の権限でこのファイルが読めないとClaude Code自体が起動を拒否していましたが、v2.1.285以降は警告を出したうえでポリシーなしのまま起動するよう変わりました。
これは一見親切な修正に見えますが、チーム運用の観点では注意が必要です。ファイルが読めていないことに気づかず、allowedProvidersなどの制限が事実上無効化された状態で開発者が作業を続けてしまう可能性があります。ファイルのパーミッション設定を配布するタイミングでは、意図的に読み込みエラーを起こして警告メッセージが出るかを一度確認しておくと安心です。
見直しのチェックリスト
見直しの一歩として、次の3点を確認してみてください。
- 手元のClaude Codeが v2.1.285 以降か（
claude --version） - チームで許可したいAPI経路が
allowedProvidersに過不足なく反映されているか - 配布中のプラグインに未設定の項目が残っていないか（
claude plugin configureで棚卸し）
接続経路の管理は、開発速度を落とさずにガバナンスを効かせるための地味な作業です。定例の棚卸しに組み込んでおくと、後から経路の乱立に悩まされずに済みます。