自社データを外に出せない会社のClaude Code｜接続経路（直接・Bedrock・Vertex）を情シス目線で選ぶ

「すでにAWSを契約している会社なら、Claude CodeもAWS経由にすることで社内の承認を得やすくなりますか」

情報システム部門との打ち合わせでは、こうした問いから検討が始まることが少なくありません。考え方の方向性は合っていますが、決定前に押さえたい点があります。どこを経由して接続するかによって、利用可能な機能まで変化するということです。特に使えなくなるものには、導入後に必要性が見えてくる機能が多く含まれます。

この差を説明している検索記事は、決して多くありません。検索上位の解説を確認すると、主題の多くは環境変数の設定方法、または料金・データの所在・ガバナンス・機能という4観点から直接接続と単一クラウドを比較する内容でした。13,000字ほどを費やした詳しい記事でも比較対象は2経路にとどまり、経路ごとに手放す機能を横並びで確認できる資料は見つけられませんでした。

そこで本記事では、その空白を補います。対象は、データを置く地域や社内統制の事情を踏まえ、接続経路を決定する情シス・セキュリティ・購買部門の方です。公式情報を根拠に、選定で使える判断材料として整理しました。

掲載している仕様は、Claude Code公式のエンタープライズデプロイメント概要、機能の利用可能性、Amazon Bedrock、Google Cloud の Agent Platform、データ使用をもとに、2026年8月20日時点で確認したものです。クラウドの対応範囲や対象リージョン、利用可能なモデルは更新されやすいため、社内向け資料に引用する際は必ず公式情報の最新版もお確かめください。各サービスの料金比較はここでは取り上げず、料金と法人プランの選び方で解説しています。外部の解説記事にある数値は転載していません。

「外に出せない」が指している3つの別々の要件

相談時に最もよく耳にするのは、「自社データを社外へ出せない」という表現です。しかし、具体的な意味を掘り下げると、企業ごとに求めていることが大きく異なります。要件を切り分けずに接続先を決めれば、過剰な構成を用意しかねません。

要件A：学習に使われたくない

最も一般的なのは、送信した情報をモデル改善へ利用されたくないという条件です。接続ルートを変えても、この問題の解決にはなりません。適用される契約条件によって決まるためです。

公式のデータ使用に関する説明では、商用条件でClaude Codeへ送ったコードおよびプロンプトは、生成モデルの学習に用いないとされています。ただし、顧客が明示的に提供を選択したケースは除きます（2026年8月20日確認）。求める条件がAのみであれば、クラウド経由へ移す必然性はありません。

要件B：データが保存される場所を指定したい

次に挙がるのは、保存地域や暗号鍵の管理方式を指定したいケースです。この条件には接続経路の違いが影響します。

保存データの暗号化について、公式資料はプロバイダー別に方式を示しています。Anthropic APIではインフラのディスクをAES-256で暗号化し、Amazon BedrockではAWS管理キーによるAES-256に加えてKMS経由の顧客管理キーを利用できます。Google Cloudの基盤はGoogle管理キーを採用し、CMEKにも対応すると記載されています（2026年8月20日確認）。暗号鍵を自社で保持する必要がある場合は、経路を選び分ける明確な根拠になります。

要件C：既存の統制・調達の枠内で処理したい

最後は技術そのものではなく、社内プロセス上の制約です。取引先を新たに増やさず、既存クラウドの契約に請求を集約したい、あるいは認証やアクセス制御を現在の基盤に統一したいという要望が該当します。この場合も経路選びに意味があります。ただし得られるのは調達や審査の進めやすさであり、それだけで安全性が高まるわけではありません。

選べる経路の全体像

条件を特定できたら、候補を整理します。公式のエンタープライズデプロイメント概要では、比較対象として次の6種類が掲載されています（2026年8月20日確認）。

Claude for Teams / Claude for Enterprise

公式資料で「ほとんどの組織に最適」と説明される選択肢です。claude.aiのSSOまたはメールで認証し、使用状況ダッシュボードからコストを確認します。EnterpriseにはSSO、ドメインキャプチャ、ロールに基づく権限、コンプライアンスAPIへのアクセスに加え、全社へClaude Codeの設定を展開する管理ポリシー機能も含まれると案内されています。

Anthropic Console

APIキーで認証する、個々のユーザー向けの方式です。利用コストは使用状況ダッシュボードで追跡できます。

Amazon Bedrock

AWSを中心に構成したい組織向けです。認証にはAPIキーかAWS認証情報を使い、費用はAWS Cost Explorerで確認します。管理手段としてIAMポリシーとCloudTrailが示されており、すでに運用しているAWSの統制へ組み込めることが最大の強みです。

Google Cloud の Agent Platform（旧 Vertex AI）

GCPを基盤とする場合の経路です。GCP認証情報を認証に用い、GCP Billingで料金を把握します。統制にはIAMロールとCloud Audit Logsを利用します。

Microsoft Foundry

Azure環境に適した方式で、APIキーまたはMicrosoft Entra IDによる認証に対応します。費用管理はAzure Cost Management、統制はRBACポリシーとAzure Monitorが担当します。もっとも、この経路には後ほど説明する重要な注意点があります。

Claude Platform on AWS

AWSマーケットプレイスから購入し、実際のリクエストはAnthropic APIへ送る方式です。AWSに請求をまとめながら、IAMポリシーとCloudTrailを統制に使えるとされています。AWS経由で調達しつつ、機能面の制約は避けたい組織の候補です。

公式がまず薦めているのはクラウド経由ではない

検索上位の記事だけを読むと誤解しやすいため、この点は明確にしておきます。

公式の記載

エンタープライズデプロイメント概要の冒頭では、多くの組織に最良の利用体験を提供するのはClaude for TeamsまたはClaude for Enterpriseであると説明されています（2026年8月20日確認）。単一契約に支払いをまとめられ、新たなインフラ構築が要らないことに加え、Claude CodeとWeb版Claudeの双方を利用できる点が理由です。

続いて、特有のインフラ要件を持つ組織に対して、各オプションを比較するよう案内しています。クラウド経由は、固有の条件を満たすために検討する位置づけだと読み取れます。

なぜ逆に受け取られやすいか

背景には、クラウド接続の解説が充実していることがあると考えられます。準備手順が多い経路ほど記事の題材になりやすく、「法人利用ならクラウドが基本」という印象につながります。

選定時は、反対の順で考えることを推奨します。初めに標準経路で社内要件を満たせるか調べ、満たせない条件が判明した場合に限ってクラウド接続を候補にする。こう進めれば、必要のない構築や運用の費用を避けられます。

決める順番は5問で固定する

選定に時間を要する企業では、検討軸を広げすぎている場合があります。質問する順序を定めれば、多くは1〜2回の会議で結論を出せます。

問1：暗号鍵を自社で管理する要件があるか

要件がある場合、顧客管理キーを使えるルートが候補です。求められていなければ、この質問だけでは選択肢は減りません。

問2：請求と契約を既存のクラウドに寄せる必要があるか

購買部門の方針で支払先が決まっており、この条件だけで事実上の接続先が定まる企業も珍しくありません。システム面の検討より前に存在する制約なので、早めに確認しましょう。

問3：既存のIAM・監査基盤に統合する必要があるか

現在のロール設計に沿って利用権限を付与したい、APIアクセスの履歴を既存のログ基盤へ集約したい、といった条件です。必須条件に指定されているなら、該当するクラウドルートが有力候補になります。

問4：使う予定の機能が、その経路で提供されているか

本記事で最も重視する確認事項です。次の章で機能差をまとめます。問1から問3までで候補を絞ったうえで、問4によって選定結果に問題がないか確かめます。この確認を後回しにすると、導入後に不足機能が発覚します。

問5：それを維持できる担当者がいるか

締めくくりは運用体制の確認です。クラウド接続では、モデルアクセスの申請やリージョンの決定、モデル版の維持、認証情報の更新を継続して行います。担当者を置けない組織にとっては、複雑な構成自体が将来の負担になります。

経路を変えると失う機能の一覧

公式サイトには認証方式別の対応状況を示す「機能の利用可能性」ページがあります（2026年8月20日確認）。その内容から、経路選定に影響する項目を取り上げます。

どの経路でも変わらないもの

はじめに、接続先の影響を受けない範囲を確認します。公式によると、Claude Code CLIをはじめ、端末内で処理される機能は全プロバイダーで同様に利用可能です。対象にはCLIとAgent SDK、VS CodeおよびJetBrains拡張、サブエージェント・フック・コマンド・スキル、CLAUDE.mdのメモリ、プラグイン、MCPサーバー、チェックポイント、サンドボックス、ワークフロー、OpenTelemetryメトリクス、さらに管理設定ファイルが含まれます。

つまり、CLAUDE.md、権限設定、フック、管理設定ファイルを用いて社内方針を適用する仕組みは、接続経路を問わず利用できます。企業利用の土台となる部分に、経路ごとの差はありません。

claude.aiのアカウントが前提になっているもの

一方、次の違いは選定上重要です。下記の機能について公式は、claude.aiアカウントでのログインが必要であり、Anthropic ConsoleのAPIキーや外部プロバイダー経由では使えないとしています。

• ブラウザ版、モバイル版、Slack版のClaude Code
• Claude Codeのデスクトップアプリ（後述する例外を除く）
• Routines（`/schedule`）、すなわちAnthropicのインフラ上で処理されるスケジュール実行
• UltraplanおよびUltrareview
• Team・EnterpriseプランのCode Review
• Remote Control、つまり離れた端末から実行途中のセッションを操作する機能
• Chrome拡張、Computer use（Pro・Max）、Artifacts、音声による入力

現時点では不要だと思える機能もあるでしょう。しかし、スケジュール実行やリモート操作は、導入から半年後ほどで現場から希望が上がりやすい領域です。実際の導入支援でも、その頃に接続方法の再検討を相談されることがあります。

Amazon Bedrockで使えないもの

公式のプロバイダー別一覧では、先ほどの項目に加えて、Web検索、Fast mode、Advisor、Channels、分析ダッシュボード、サーバー管理設定、`/design-sync` および `/radio` コマンドが非対応です。

業務への影響が特に大きいのはWeb検索でしょう。公式は代替策として、URLを明示して取得するWebFetchツールを案内しています。情報収集から要約までを任せる運用なら、導入前に必ず確認したい相違点です。

Google Cloud の Agent Platform で使えないもの

利用できない項目はFast mode、Advisor、Channels、分析ダッシュボード、サーバー管理設定、`/design-sync`、`/radio`です。一方、Claude 4以降のモデルではWeb検索に対応するとの注記があり、この点はBedrockと異なります。

Microsoft Foundry で使えないもの

これまで挙げた制限に加え、GitHub ActionsとGitLab CI/CDにも対応しないと公式に示されています。CI、すなわち変更を自動検証する仕組みへ組み込む予定なら、Foundryは要件を満たしません。

Claude Platform on AWS の位置づけ

この方式には特徴的な差があります。Bedrockでは非対応のWeb検索が、Claude Platform on AWSでは利用できると明記されている点です。AWSへ請求を集めながら機能制限を抑えたい場合に適合します。

部分的に制限されるもの

• Auto mode：クラウド経由では利用対象のモデルに制約があるとされています
• `/loop`（反復実行）：クラウド接続時は実行間隔を明記した場合に限り利用可能で、間隔を省略した際の動きが異なります
• Zero Data Retention：クラウド経由では各クラウド事業者と締結した契約が適用されます。Anthropicの設定ではなく契約条件で決まります

見落とされやすい3つの事実

続いて、比較表だけでは気付きにくいものの、判断を左右する3点を確認します。

事実1：Microsoft Foundry はAnthropic側のインフラへルーティングされる

公式の保存時暗号化に関する表では、Microsoft Foundryからのリクエストが、AES-256でディスクを暗号化したAnthropicのインフラへ転送されると説明されています（2026年8月20日確認）。

したがって、Azure経由なら処理がAzure内だけで完了すると想定して審査を進めると、途中で前提が成立しなくなります。同じページの説明も、Microsoft FoundryをAzure上でAnthropicが運営するものと表現しています。サービス名で判断せず、処理が実行される実際の場所をもとに審査資料を作成しなければなりません。

事実2：クラウド経由では、Anthropicへのテレメトリが既定でオフ

データ使用の公式説明によれば、Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry、Claude Platform on AWSを選ぶと、エラーレポート、テレメトリ、バグ報告は初期状態で無効になります（2026年8月20日確認）。

社内審査の説明材料として有用ですが、公式には2つの例外も記されています。セッション品質アンケートと、WebFetchで行われるドメイン安全確認は、接続プロバイダーを問わず動作します。そのため、クラウド経由ならAnthropicへの通信が完全になくなる、とは説明できません。

事実3：開発パートナープログラムはクラウド経由では対象外

モデル学習用データの提供を明示的に選ぶプログラムは、公式上、AnthropicのファーストパーティAPIだけが対象で、Amazon BedrockとGoogle CloudのAgent Platformからは参加できない仕組みです。利用者の意図に反して学習対象となる接続先が構造上存在しないことも、審査資料へ記載できる根拠になります。

監査の証跡はどこに出るか

社内審査では、操作や利用の履歴がどこに残るかを必ず確認されます。その保存先は接続ルートによって異なります。

クラウド経由の場合

公式比較によると、Amazon BedrockはIAMポリシーとCloudTrail、Google CloudはIAMロールとCloud Audit Logs、Microsoft FoundryはRBACポリシーとAzure Monitorを利用します。現在使っている監査基盤へ記録を直接まとめられることこそ、クラウド経由を採用する実務上の大きな利点です。

標準の経路の場合

Claude for TeamsとEnterpriseでは利用状況ダッシュボードを使用でき、EnterpriseにはさらにコンプライアンスAPIへのアクセスが提供されます。対して、分析用のダッシュボードとAPIはクラウド事業者経由では非対応と明示されています。

要するに、どちらを選んでも証跡は得られる一方、格納先とデータ形式が異なります。有無だけを問うのではなく、どの監査環境に統合する必要があるかを選定基準にしましょう。

どちらの経路でも取れるもの

OpenTelemetryメトリクスと管理設定ファイルは、公式上、全プロバイダーで使える機能に分類されています。メトリクスを社内の監視システムへ送る設計なら、接続先が変わっても共通化できます。

閉域ネットワークで最初に詰まる場所

次の論点は接続経路そのものよりも、現場での利用を止める原因になりがちです。

WebFetch のドメイン安全チェック

公式のデータ使用資料によると、WebFetchはURLへアクセスする前に、対象ホスト名を `api.anthropic.com` へ送り、安全性ブロックリストとの照合を行います。送信対象はホスト名だけで、URL全体や取得ページの中身は含まれません。また、判定結果はホスト名単位で5分間保持されます（2026年8月20日確認）。

注意すべきなのは、この照合が選択したモデルプロバイダーにかかわらず行われ、`api.anthropic.com` への通信をネットワーク側で遮断するとWebFetchが失敗することです。無効にする設定もありますが、その場合はブロックリストを確認せず任意のURLへ接続を試みるため、公式は権限ルールも併せて設定するよう推奨しています。

クラウド事業者を介すのでAnthropicへは通信しないと考えて遮断すると、この機能を使えなくなります。閉域ネットワークを採用する企業は、設計の段階で扱いを決めておきましょう。

企業プロキシとLLMゲートウェイ

公式によれば、すべての外向き通信をプロキシへ通す場合は`HTTPS_PROXY` または `HTTP_PROXY`を設定し、認証とルーティングを一元化する場合はプロバイダーごとのベースURL環境変数を使います。反映状態は`/status`で確かめられ、プロキシ設定時にはそのURLを示す行も出ると説明されています。

この確認方法を知らないまま、原因調査に時間を費やすケースがあります。構成変更後は最初に `/status` を開いて設定値を確認する流れを、社内手順に加えておくと効率的です。

移行で踏む落とし穴6つ

公式ページに注意事項として掲載された内容を、業務への影響が大きいものから順に説明します。

落とし穴1：モデルを固定しないと、請求が上振れし得る

金銭的な影響が最も大きい注意点です。Amazon BedrockとGoogle Cloudの公式ページには、共通する警告があります。OpusはSonnetよりもトークン単価が高く、主モデルを固定していない環境をv2.1.207以降へ更新するとOpusの料率が適用されるという内容です（2026年8月20日確認）。

複数ユーザーへ展開する際は、公式も使用するモデルのバージョンを明示して固定するよう勧めています。未固定のエイリアスは組み込み既定値へ解決されるため、最新版より古かったり、利用アカウントでまだ有効化されていなかったりする可能性もあります。全社配布する設定には、モデル固定を必ず含めましょう。

落とし穴2：モデルの利用申請に待ち時間がある

Amazon Bedrockを初めて使う場合、モデル呼び出しの前に用途の詳細を提出する必要があり、アカウント単位で1回実施するとされています。AWS Organizations環境では、管理アカウントから1度提出すれば、承認内容が子アカウントにも自動展開されます。

Google Cloudの場合は、Model Gardenからモデル利用を申請し、承認されるまで待つ必要があり、24〜48時間を要することがあると説明されています。検証着手日から逆算してアクセス申請を行うよう、導入日程へ組み込んでください。

落とし穴3：SSOとTLS検査プロキシの組み合わせで認証がループする

AWS SSOで認証用のブラウザタブが何度も開く事象について、公式のトラブルシューティングは、社内VPNまたはTLS検査プロキシがSSOのブラウザ処理を中断すると発生する場合があると説明しています。途切れた接続が認証エラーと判定され、更新処理が再び走り続ける仕組みです。

回避方法として示されているのは、自動更新に任せず、Claude Codeの起動前に手作業でログインを完了する手順です。ネットワーク構成を変更せずに対応できるため、検証時に把握しておくと役立ちます。

落とし穴4：ゲートウェイがストリーミングを変換すると失敗する

Bedrockの公式説明には、中継するゲートウェイまたはプロキシがストリーミング応答を変換すると、処理が失敗する旨が記載されています。レスポンス本文とContent-Typeヘッダーを改変せず転送する構成が求められ、代表例としてAPI Gatewayが挙げられています。

原因はネットワーク側の設計にあるため、Claude Code内の設定変更では直せません。ゲートウェイを経由させるなら、構成を決める時点で担当者にこの制約を伝える必要があります。

落とし穴5：リージョンとモデルの可用性が一致しない

どちらのクラウドも、選択リージョンによって提供モデルが変わると案内しています。Google Cloudはグローバル、マルチリージョン、地域単位のエンドポイントを提供しますが、すべての接続先が既定モデルに対応するとは限らない点に注意が必要です。公式資料には、モデル不検出を示す404や429エラーへの対応もまとめられています。

データ保存地域の制約が強い企業ほど、地域を限定することでモデル候補も少なくなります。Bの要件を優先した結果、利用可能モデルが変わる可能性を選定資料に明記しましょう。

落とし穴6：小さな挙動差を見落とす

一見小さくても、利用者を混乱させる違いがあります。Amazon BedrockではAWS認証情報を用いるため`/logout` が無効となり、Converse APIではなくInvoke APIを使用することが明記されています。Google Cloud経由でも、同じく `/logout` は使えません。

両方の公式ガイドは、コスト管理と権限制御を分かりやすくするため、専用アカウントまたは専用プロジェクトを用意するよう推奨しています。運用開始後に切り離すより、初期構築から分けるほうが安全です。

当社が直接接続を選んでいる理由

検討の参考になるよう、当社で採用した方式と判断の背景を紹介します。

選んだ経路

当社が運用しているのは、クラウド事業者を間に挟まない標準接続です。決め手は3点ありました。

第1に、A・B・Cのうち該当した条件がAだけだったためです。自社で暗号鍵を管理する必要も、既存クラウドの請求へ一本化する必要もありませんでした。

第2に、クラウド経由では提供されない機能を実際の業務で利用していたことが挙げられます。毎日のスケジュール実行と、社外から進行中のセッションを操作する手順を業務フローに含めており、前者ではAnthropicのインフラ上での実行、後者では遠隔操作機能を利用しています。

第3の理由は、継続運用を担える人員規模です。モデルのバージョンやリージョンを管理し、認証情報を定期更新する担当者がいなければ、高度な仕組みほど維持負担へ変わります。

ただし、記録が残ることは承知のうえで運用している

遠隔操作を有効にすると、接続している間の会話履歴がサーバーにも記録されることは公式資料に明示されています。当社ではその条件を理解したうえで機能を有効化し、社内ルールにも事実を記載しています。利用していないと扱うより、条件を把握して採用したと説明できるほうが適切だと判断しているからです。

他社に同じ判断を勧めているわけではない

この結論は、当社がAの条件しか持たなかったために成り立ちます。BまたはCが必須の企業であれば、クラウド接続を選ぶべきです。同じ結論に合わせることより、自社の制約がA・B・Cのどこに該当するかを最初に特定する手順が重要です。

稟議・審査で聞かれること

選んだ接続経路は、稟議書やセキュリティ審査の説明にも直結します。質問されやすい形に沿って回答のポイントをまとめます。

「なぜこの経路を選んだのか」

A・B・Cのどの条件が判断に影響したかを記載します。単にAWSを契約済みだからとせず、自社管理の暗号鍵が必要、既存監査基盤へログを統合しなければならない、と具体化することで追加の確認を減らせます。

「その経路で失う機能は把握しているか」

第5章の整理を回答に活用できます。不要な機能をすべて列記せず、機能差を確認した結果、現在必要な機能に欠落はないと示せれば足ります。将来の追加要望に備え、選定時の記録は保存しておくことを推奨します。

「学習に使われないことをどう確認したか」

公式のデータ使用方針から該当箇所を引用し、確認した日付も添えます。第三者による要約ではなく、公式URLと確認日を記録する方法が確実です。認証取得企業でも、そのまま審査資料に利用しやすい形式です。詳しくはISMS・Pマーク企業の導入でも整理しています。

「利用者ごとの権限はどう制御するか」

回答は2層に分けます。ひとつはIAMやRBACなど接続経路側のアクセス制御、もうひとつは権限設定、フック、管理設定ファイルといったClaude Code側の制御です。後者はどの接続ルートでも同じように利用できるため、経路とは独立して設計可能です。具体例は権限設計の実例をご参照ください。

よくある質問

あとから経路を変更できますか

設定を変更すること自体は可能です。ただし、接続先を切り替えると利用可能な機能も変化します。すでに運用へ組み込んだ機能が停止しないか、事前に調べてください。特にスケジュール実行とリモート操作を業務利用している場合は影響を受けます。

クラウド経由のほうが安全ですか

何をもって安全とするかで回答は変わります。既存ガバナンスへ統合できる点では利点がありますが、モデル学習への利用可否は契約条件で決まり、経路変更では変わりません。安全性そのものを高めるというより、社内へ説明しやすい構成になると捉えるのが適切です。

小さな会社でもクラウド経由にすべきですか

BとCのいずれも条件に含まれないなら、クラウド経由は必須ではありません。保守担当者がいないのにクラウド接続を選択すると、モデル更新や利用申請が止まり、運用がかえって不安定になるおそれがあります。公式が標準経路を推す背景にも、この運用負担があります。

複数の経路を併用できますか

Amazon Bedrockでは、2種類のエンドポイントを同時に有効化し、モデルIDの形式に応じて振り分ける方法が公式に案内されています。ただし、管理すべき構成が複雑になるので、併用する明確な必要性がある場合だけ採用するのが現実的です。

設定が正しく効いているか、どう確かめますか

Claude Code上で`/status`を実行してください。公式説明では、使用中のプロバイダー、ベースURL、リージョン、認証状況、プロキシURLを確認できます。問題調査で最初に行う確認として、手順書の冒頭へ記載しておきましょう。

まとめ

最後に、判断の要点を10項目へ整理します。

• 最初に「外へ出せない」という言葉を3要件へ分解しましょう。学習利用を避けたいA、保管地域や鍵管理を指定するB、既存の統制・購買手続きに合わせるCです。Aだけなら接続ルートを変更する必要はありません
• 公式の第一候補はクラウド経由ではありません。多くの組織にはTeamsまたはEnterpriseが適すると説明されており、クラウド接続は固有要件がある場合の候補です
• 5つの質問を決まった順番で確認します。鍵管理、請求先、IAM連携、必要機能、保守担当者の順です。機能差の検証を導入後へ先送りしてはいけません
• 社内ポリシーを適用する機能は、接続先に左右されません。CLAUDE.md、アクセス権限、フック、管理設定ファイル、MCPは、どのプロバイダーでも利用可能です
• 利用にclaude.aiアカウントを求める機能も存在します。ブラウザ、モバイル、Slack、デスクトップ、スケジュール実行、遠隔操作、コードレビューなどはクラウド経由の対象外です
• 利用できない機能はプロバイダーごとに異なります。BedrockではWeb検索が使えず、Google Cloudは条件付きで対応し、FoundryはCI連携が非対応、Claude Platform on AWSではWeb検索が利用可能です
• Microsoft Foundryの処理はAnthropicのインフラへ転送されます。Azureだけで完結すると仮定した審査説明は成立しません
• クラウド接続ではAnthropic向けテレメトリが初期状態で停止します。もっとも2つの例外があるため、通信がまったく発生しないとは表現できません
• 閉域ネットワークではWebFetchのドメイン照合を先に検討してください。どのプロバイダーでも実行され、通信を遮ると機能しなくなります
• 利用者へ設定を配る前にモデル版を固定しましょう。固定しない構成では、予測を超える単価が適用される可能性を公式が警告しています

本日着手できることは、「外に出せない」と発言している社内関係者へ、A・B・Cのどの意味で使っているかを確認することです。同じ表現を使いながら、部署ごとに異なる制約を想定しているケースは少なくありません。認識をそろえるだけでも、接続先を決める話し合いは大幅に短縮できます。

当社は法人向けに、Claude Code導入を支援しています。接続ルートの比較、制限される機能の確認、審査提出資料の構成、権限設定、展開手順まで、情シス部門の実務に沿ってサポートします。あわせて情シスのための導入設計と情報の線引きもご覧ください。初回相談とお見積りに費用はかかりません。

接続先の比較検討から、社内審査用の資料作成までお手伝いします
初回のご相談・お見積りは無料です

無料相談を申し込む →