生成AIの活用が進むにつれて、多くの企業で同じ悩みが出てきています。
「Claudeを使いたい」「でも、機密情報を外部のAIサービスに直接送られるのは困る」「とはいえ、Web検索や社内イントラ、社内ドキュメント検索まで使えなくなると、業務では使い物にならない」
これは非常に現実的な悩みです。生成AIを企業で使ううえで大事なのは、単に「使わせる」「禁止する」の二択ではありません。重要なのは、AIが何に接続し、どこへデータを送り、どの経路を管理者が統制できるかを整理することです。
その選択肢として注目したいのが、Claude DesktopをAmazon Bedrock経由で利用する構成です。
ポイントは「モデル」と「ツール」を分けて考えること
まず整理すべきなのは、Claude Desktopが行う通信には大きく2種類あるという点です。
1つ目は、ユーザーの入力をAIモデルに送り、回答を得るための「推論」の通信です（推論とは、AIが入力を受け取って回答を作り出す処理のこと）。2つ目は、Web検索、社内イントラ、ファイル、MCPサーバー（AIを外部のツールやデータとつなぐ接続口）、外部サービスなどにアクセスする「ツール」の通信です。この2つを混同すると、議論が一気に曖昧になります。
「AWSの外にデータを出したくない」という話は、主に推論先の問題です。つまり、ユーザーが入力したプロンプトや添付ファイル、AIの回答生成に使う情報を、どのモデル基盤に送るのかという話です。
一方で、「Web検索したい」「社内イントラを見たい」「SharePointや社内DBを検索したい」という話は、ツール接続の問題です。
推論先はAmazon Bedrockに固定しつつ、ツール接続は会社が許可したものだけ使えるようにする。
Bedrock経由にすると何が変わるのか
Claude DesktopをAmazon Bedrock経由で利用すると、Claudeの使い勝手を保ちながら、推論基盤を自社のAWS環境側に寄せることができます。
この構成では、利用者はClaude Desktopの画面から作業しますが、モデル推論はAmazon Bedrockを通じて行われます。企業側はAWSの権限管理（IAM）、操作履歴の記録（CloudTrail）、閉じた通信経路（VPCエンドポイント）、請求管理、リージョン管理（データを置く地域の指定）といった既存のAWSの統制の仕組みをそのまま活用できます。
ここで重要なのは、「Claudeを使うかどうか」ではなく、「Claudeをどの管理境界の中で使うか」です。同じClaudeモデルを使うとしても、個人がClaude.aiに直接ログインして使うのと、会社が管理するBedrock経由で使うのでは、統制のしやすさが大きく変わります。
ただし「AWSの外に一切出ない」とは言い切らない
ここは慎重に表現すべきです。Bedrock経由の推論については、プロンプトやファイル、ツール入出力、モデル応答をBedrock側で扱う構成になります。しかし、Claude Desktopというアプリ全体で見た場合、すべての通信が常にAWSだけに閉じるわけではありません。
たとえば、アプリの動作状況をメーカーに送る通信（テレメトリ）、アップデート、MCPサーバー接続、Web検索、外部コネクタ（Slackやドライブなど他サービスとの連携機能）などは、設定次第で別経路の通信が発生します。
「Bedrock経由にすることで、モデル推論の経路をAWS側に統制できる。ただし、MCPや外部コネクタ、Web検索などのツール接続は別途管理が必要」
セキュリティ説明で一番危ないのは、便利な構成を「完全に安全」と言い切ってしまうことです。推論・ツール・認証・端末・ネットワーク・ログを分けて管理する必要があります。
Bedrock以外のエンドポイントにされるリスク
企業にとって気になるのは、利用者が勝手にClaude Desktopの推論先を変更してしまうことです。会社としてはBedrock経由を前提にしているのに、利用者がAnthropicの直接利用や、別のLLMゲートウェイ（複数のAIサービスへの接続を仲介する窓口）、Vertex AI（Google）、Azure AI Foundry（Microsoft）などに向けてしまうと、せっかくの統制が崩れます。
このリスクに対しては、主に3つの対策があります。
- MDMでClaude Desktopの設定を管理配布する。 MacであればJamfなど、WindowsであればIntuneやGroup Policyを使い、推論先をBedrockに固定します。
企業が社員の端末（PC・スマホ・タブレット）を一括管理するための仕組みです。アプリのインストール制限、設定の強制配布、紛失時のリモートワイプなどができます。Claude Desktopの設定ファイルをMDMで全社員の端末に配布し、推論先をBedrockに強制固定する、といった使い方が可能です。
代表的なツール：Jamf（Mac向け）、Microsoft Intune（Windows/Mac対応）、Group Policy（Windows Active Directory環境）
- アプリ側でユーザーが推論先を変更できないようにする。 管理設定により、ログイン画面や推論プロバイダーの選択肢を制御する設計が可能です。
- ネットワーク側で不要なLLMエンドポイントへの通信を遮断する。 仮にアプリ設定を変更されても、通信自体が通らなければ利用できません。
アプリ設定だけで守るのではなく、端末管理とネットワーク管理を組み合わせるのが現実的です。
では、Web検索やイントラ検索はどうするのか
「Bedrock以外を遮断する」と聞くと、Web検索や社内イントラまで使えなくなるのではないかという懸念があります。しかし、推論先の制御と、情報取得先の制御は分けて考えられます。
- 推論はBedrockに固定する。
- Web検索は会社が許可した検索サービスだけ使わせる。
- 社内イントラは社内MCPや社内検索API経由で使わせる。
- 外部コネクタは原則禁止し、必要なものだけ管理者が許可する。
このように設計すれば、AIモデルへの送信経路は統制しつつ、業務に必要な検索機能は残せます。むしろ重要なのは、利用者が自由に外部コネクタを追加できる状態にしないことです。Slack、Google Drive、GitHub、Notion、Web検索などは便利ですが、便利な分だけ情報流出や権限逸脱のリスクがあります。
企業利用では、「何でもつなげる」のではなく、「管理者が許可したものだけつなげる」ことが基本になります。
現実的な企業向け構成
企業でClaude Desktopを利用するなら、次のような構成が現実的です。
- 推論先はAmazon Bedrockに固定する。
- 認証はIAM Identity CenterやIAMロール（AWSの利用者・権限を管理する仕組み）で管理する。
- Claude Desktopの設定はMDM（端末を一括管理する仕組み）で配布する。
- 利用できるMCPサーバーは会社が管理するものだけに限定する。
- Web検索は管理対象の検索MCPまたはプロキシ経由にする。
- 社内情報は社内RAG、社内検索API、SharePoint、社内DBなどを管理された経路で参照する。
- 監査ログはCloudTrailや社内ログ基盤に集約する。
- 不要な外部LLMサービスへの通信はプロキシやファイアウォールで遮断する。
この構成であれば、利用者にとっては「Claude Desktopで自然に作業できる」一方で、会社としては「どのモデルを使い、どのデータにアクセスし、どこへ通信しているか」を管理できます。
本質は「AIの利用禁止」ではなく「AIの通り道の設計」
生成AIのセキュリティを考えるとき、つい「使わせるか、禁止するか」という議論になりがちです。しかし、これからの企業AI活用では、その考え方だけでは限界があります。生成AIは、文書作成、調査、分析、コーディング、社内ナレッジ検索など、業務の中核に入り始めています。単純に禁止すれば、現場の生産性を下げるだけでなく、シャドーAIの利用を招く可能性もあります。
必要なのは、AIを止めることではありません。AIの通り道を設計することです。
- どのモデルを使うのか。
- どのデータにアクセスできるのか。
- どの外部サービスには接続できないのか。
- 誰が使えるのか。
- ログはどこに残るのか。
- 問題が起きたときに追跡できるのか。
これらを設計して初めて、企業は生成AIを安心して業務に組み込めます。
Claude DesktopをAmazon Bedrock経由で利用する構成は、そのための有力な選択肢です。ただし、Bedrockにしただけで全てが解決するわけではありません。推論先の固定、MCPの管理、外部コネクタの制御、Web検索の許可範囲、社内イントラ連携、端末管理、ネットワーク制御、監査ログまで含めて設計する必要があります。
生成AI活用の成否は、モデル選びだけでは決まりません。本当に重要なのは、AIを業務に入れるための「安全な導線」を作れるかどうかです。