「使いたい。でも、情報が国外に出るのは困る」
当事務所も常に意識してきた問題意識であり、多くの企業との会話でも、データのレジデンシー(所在地)の問題がよく話題に挙がります。
「Claude(クロード)やChatGPTが便利なのは分かった。社内でも検討は始めている。でも、入力した情報がどこのサーバーに行くのかと考えると、業務での本格活用に踏み切れない」
このような問題は、生成AIアプリの開発企業から、活用したいと考える中小企業・大企業まで、幅広い層で認識されている問題意識になります。
通常、Claude.aiやChatGPTのウェブ版・アプリ版を使うと、入力したテキストは提供元(Anthropic、OpenAI)のサーバーに送信されます。両社とも米国企業ですから、データは原則として米国側のインフラを経由することになります。
「学習に使わないと規約に書いてある」「セキュリティ認証も取っている」「法人プランでDPAも確認している」――しかし、それでも海外情報を送信しているという理由でなかなか本格化できないという課題もあります。
生成AIに注力している立場から言えば、「データが海外に送信されるから生成AIは使えない」という批判にどう応えるかは、いまの企業法務における重要論点の一つです。
本記事では、その悩みを技術的に解消する一つの構成――Amazon Web Services(AWS)の「Bedrock」を経由してClaudeを日本国内のリージョンで完結させる方法――について、技術的な細部には立ち入らず、法的論点との関係を中心に整理します。
これまで「国内完結で生成AIを使う」のは現実的な選択肢ではなかった
これまでも、「国内に閉じた環境で生成AIを使いたい」というニーズはありました。代表的だったのが、Microsoft AzureのOpenAI Service(Azure OpenAI)を東日本リージョンで利用する構成です。
しかし、これには実務上の大きなハードルがありました。Azure OpenAIは、特に高性能モデルを利用するためにクォータ(利用枠)申請が必要で、中小企業や個人事業規模の組織ではこの申請がなかなか通らない、というケースが頻発していました。
私自身も数年前、当事務所として申請を試みた経緯がありますが、個人法律事務所という属性もあってか、何度申請しても却下されました。「制度上は使える」けれど「実際には使えない」というものをまさに体感した状態です。
結果として、これまで国内完結の生成AI活用は、大企業や、専門の情報システム部門を持つ組織にしか現実的に開かれていなかったというのが正直なところです。
2026年4月、状況が一変した──Claude Cowork in Amazon Bedrock
ここに大きな変化が起きたのが、2026年4月です。
4月16日、Anthropicは最新の最高峰モデル「Claude Opus 4.7」を正式リリースしました。同時にAmazon Bedrock、Google Cloud Vertex AI、Microsoft Foundryで利用可能になり、東京リージョン(ap-northeast-1)でも即日対応しています。
そして4月21日、AWSは「Claude Cowork in Amazon Bedrock」の提供開始を発表しました。AWSの公式ブログによれば、これは「組織内のすべてのナレッジワーカーに AI 活用を広げる」ためのデスクトップアプリケーションで、ドキュメントの読み取り、複数ステップのリサーチ、ファイル処理、レポート生成といった業務をClaudeに委任できる構成です。
ここで重要なのは、Claude Cowork は別アプリではなく、いつものClaude Desktopアプリで動作する点です。
組織側がデバイス管理システム(Jamf、Microsoft Intune、グループポリシー等)を通じて「推論モード」をプッシュ設定することで、社員のClaude DesktopからのモデルアクセスがすべてAWS Bedrockに向かう仕組みになります。
法務・コンプライアンス的に意味があるのは、AWS公式ブログが明記している以下の点です。
- モデル推論は設定したAWSリージョンのAmazon Bedrockに送信される(つまりデータレジデンシーをAWS側で制御できる)
- Bedrockはプロンプト、ファイル、ツールの入出力、モデルの応答を保存せず、基盤モデルのトレーニングにも使用しない
- ClaudeモデルはAWSにホストされており、Anthropic側から顧客データを閲覧することはできない
- Anthropicが受信するのは集計されたテレメトリデータ(トークン数、モデルID、エラーコード、匿名デバイス識別子)のみで、設定オプションで無効化できる
- 料金は既存のAWS契約と請求を通じた従量課金制で、Anthropicからのシートライセンスは不要
▶ 出典:AWS公式ブログ「開発現場から全社展開へ:Amazon Bedrock で Claude Cowork を動かす」(2026年4月22日)
さらに注目すべきは、Claude CoworkがAnthropicホスト型推論を必要とする機能(Chatタブ、Computer Use、Skills Marketplaceなど)を含まない設計になっていることです。これは一見すると機能制限に見えますが、「Bedrockを経由しない経路をそもそも作らない」というアーキテクチャになっており、データの抜け道を構造的に塞いでいるとも評価できます。
つまり、これまで「Claude DesktopをBedrockに繋ぐ」ために必要だった個別の設定作業が、組織展開可能な公式パッケージとして整備されたのが、2026年4月のアップデートの核心です。
中小企業・専門職組織にとって、国内完結・全社展開・運用管理を同時に成立させる有力な選択肢が一つ増えたと言えます。
「Bedrock経由」の構造を、最低限だけ
Amazon Bedrockは、AWSが提供する生成AIの基盤サービスです。AnthropicのClaudeをはじめ、複数社のAIモデルをAWSのインフラ上で呼び出すことができます。
AWSは日本国内に東京リージョン(ap-northeast-1)と大阪リージョン(ap-northeast-3)の2つのデータセンターを持っており、Bedrockをこれらのリージョンで利用すれば、データは物理的に日本国内のサーバー上で処理されます。
さらに2025年10月以降、Bedrockには「日本国内クロスリージョン推論プロファイル」(通称:JP Geo推論プロファイル)という仕組みが用意されました。
AWSの公式ブログによれば、このプロファイルを使うと、推論リクエストが日本国内の東京・大阪リージョンのいずれかにルーティングされる構造で、データレジデンシー要件を満たせるとされています。
ポイントは、「運用上、なるべく国内で処理するように気をつけている」というレベルの話ではなく、アーキテクチャ上、送信先が日本国内に限定される点です。
個人情報保護法28条のボトルネックの解消
ここからが、法務担当者の方に最も読んでいただきたいパートです。
個人情報保護法28条は、外国にある第三者への個人データの提供には、原則として本人の同意が必要と定めています。
生成AIに個人データを入力する行為が「外国にある第三者への提供」に該当する場合、利用者は本人同意を取り直さなければなりません。
そのため、これまで生成AIの法人利用を検討する場面では、法人プランを利用したうえで、データ処理契約(DPA)等によって28条の例外要件を満たすという方向での検討が、主に進められてきました。
具体的には、個人情報保護法第4章第2節(個人情報取扱事業者等の義務)に相当する措置を継続的に講ずるために必要な体制が整備されている――この基準適合体制(個情法28条1項本文・施行規則16条)の要件を、提供先AI事業者との契約(DPA)によって満たす、というアプローチです。
このアプローチは法的には有効ですが、実務上は次のような難点を抱えていました。
- DPAの内容を一つ一つ精査する必要がある――事業者ごとに条項の構成が違い、基準適合性の判定にコストがかかる
- 基準適合体制の継続性を担保する責任が利用者側にも残る――締結後も提供先の運用を確認し続ける負担がある
- そもそもDPAで対応できる粒度には限界がある――契約上の措置である以上、技術的・物理的な担保とは性質が異なる
ところが、Bedrock経由・JP Geo推論プロファイルを使った構成では、データの処理が日本国内に閉じます。
「外国にある第三者への提供」という構成自体が成立しないため、28条の論点をそもそも回避できることになります。DPAで例外要件を満たすという積み上げ式の対応ではなく、地理的にそもそも28条の射程外に出る――この差は、設計上の意味として大きく異なります。
社内のプライバシーポリシーや、外部に開示するデータ取扱方針を整備するうえでも、説明が大幅に簡素化されます。
処理の監督が、日本の法制度・規制機関の枠組みの中で完結する
個情法28条の論点と関連しつつ、独立した重要な論点がもう一つあります。それは、データの処理が、米国などの海外法令の影響を抑えた形で、日本の法制度の枠組みの中に収まるということです。
通常のClaude.aiやAnthropic APIを直接利用する構成では、データは米国側のインフラに渡ります。データが米国にある以上、そのデータには米国の法律が当然に関与してくることになります。これは、機微情報を扱う組織にとって無視できない論点です。
これに対し、Bedrock経由・国内完結の構成(およびClaude Cowork in Amazon Bedrock)では、
- データは物理的に日本国内のリージョンで処理される
- 契約相手はAWS(日本法人を通じた契約も可能)で、日本法準拠・日本国内の裁判管轄を選択できる
- 個人情報保護委員会をはじめ、日本の監督機関の実効的な監督が及ぶ範囲でデータが処理される
という構成が成立します。処理の監督が、日本の法制度・規制機関の枠組みの中で完結する――これにより、米国などの海外法令がデータに及ぼす影響を抑えることができるわけです。
もちろん、AWS自体は米国企業ですから、海外法令の影響を完全にゼロにできるわけではありません。
ただし、「データの所在」「契約相手」「監督機関」という3つのレイヤーをすべて日本国内に揃えることで、海外法令の影響を構造的に低減できる――この相対的な差は、特に金融・医療・士業など規制密度の高い業種にとっては、極めて重要な意味を持ちます。
守秘義務・秘密保持義務は、別の論点として整理する
他方で、「個情法28条をクリアできる」「監督が国内に揃う」ということが「守秘義務やNDAの問題もクリアできる」わけではありません。
弁護士法・医師法等の業法上の守秘義務、あるいはNDAや業務委託契約上の秘密保持義務は、いずれも「第三者に開示しない」ことを内容とする義務です。
ここで論点になるのは、そもそも生成AIサービスにデータを送って処理させる行為が「開示」に該当するかという問題であり、提供先が国内か外国かは、義務そのものの構造には関係しません。
個人情報保護法は「外国第三者提供」という独自の枠組みを置いていますが、守秘義務・秘密保持義務にはそうした地理的基準がありません。
この違いは、社内ルールを設計するうえで明確に意識する必要があります。「日本国内のサーバーで処理されているから秘密保持義務はクリア」とは、論理的に言えません。
もっとも、Bedrock経由・国内完結の構成には、守秘義務・秘密保持の文脈でも補強材料としての価値があります。
第一に、データ通信が日本国内で完結することで、技術的に見た漏洩リスク(経路上のリスク)が低下すると評価できます。これは「義務違反のリスクが法的にゼロになる」という話ではありませんが、合理的な情報管理措置を講じている、と説明する材料になります。
第二に、社内で監督すべき契約書類の構造がシンプルになることです。Claude.aiやAnthropic APIを直接使う場合は、Anthropic(米国法人)との利用規約・データ取扱方針が直接の根拠になります。
一方、Bedrock経由の場合は、すでに社内で利用しているAWSとの既存契約の枠組みの中で、新たなデータ処理を扱えます。データ処理契約(DPA)の取り扱いや、契約管理台帳の整備という点で、契約管理上のメリットがあります。
実装・運用面での注意点
注意点その1:MCP・エージェント連携で「国内完結」が崩れる可能性
近年、生成AIの活用は単独利用にとどまらず、MCP(Model Context Protocol)やエージェント機能を介して、外部ツール・SaaS・社内システムと連携する形が主流になりつつあります。
Claude Coworkも、Anthropic公式ブログによれば、各種MCPサーバーを接続することで、最新ドキュメント、ウェブ検索、その他のツールにアクセスできる前提で設計されています。
Claude本体(Bedrock経由)は国内完結で動いていても、接続先のMCPサーバーや外部サービスが海外のサーバーで動いている場合、結局のところデータは国境を越えて流れます。
「Claudeは国内です」と言えても、「Claudeが連携している先は海外です」では、せっかくの設計が台無しです。前述の「監督レイヤーを国内に揃える」効果も、連携先のサービスが海外法令の射程下にあれば、その範囲で揺らぎます。
社内でMCP・エージェント連携を活用する場合は、連携先のサービスごとにデータ処理場所を確認し、必要に応じて連携を制限する運用ルールを整備する必要があります。
AWS公式ブログでも、Claude Coworkのアウトバウンドパス(モデル推論／MCPサーバー接続／Anthropicへのテレメトリ)はそれぞれ顧客側で制御できると明示されており、承認済みエンドポイントの管理は組織側の責任範囲として設計されています。
「全部国内で完結する」という構成は、生成AI単体の話ではなく、関連するサービス全体でとらえるべきものとして検討することが望ましいでしょう。
注意点その2:API管理体制の整備が前提となる
一方で、中小企業においては負担が増加する面も指摘されます。
Bedrock経由の構成(Claude Coworkを含む)は、AWSのアカウントと、そこから発行するAPIキー(短期Bearer Token)または IAM 認証を介して使います。これは、Claude.aiのウェブ版にメールアドレスでログインする利用形態とは、運用の前提が大きく異なります。
具体的には、最低限以下のような管理体制が必要になります。
APIキーの発行権限の明確化――誰がキーを発行できるか、どの用途のキーをいつまで使うか、ルール化しておく必要があります。「とりあえず誰かが発行して、社内で使い回す」という運用は、漏洩時のリスクと、退職者経由のリスクが膨らみます。
AWSにおけるログの記録・管理――誰が、いつ、どんな利用をしたかを記録・保存する体制が必要です。インシデント発生時の調査、内部監査、そして士業であれば事件管理との突き合わせなど、後から「使われ方を追える状態」を作っておく必要があります。
最小権限の徹底――AWSのルートアカウント(最上位の管理者権限)でAIを使うのは禁物で、Bedrockの利用に必要な権限だけを付与した専用ユーザーで運用します。これは漏洩時のダメージコントロールの基本動作ですが、AWSに不慣れな組織ほど、最初にここでつまずきます。
これらは、情報システム部門を持つ大企業にとっては当たり前の話ですが、情シスを持たない中小企業や個人事業の事務所では、ITリテラシーの底上げそのものが導入のハードルになります。
このようなことから導入時は、外部の専門家(AWSパートナー、情報セキュリティ専門家、そして必要に応じて法務)と連携して、初期設計だけは整えることが推奨されます。
法務・コンプライアンス的に押さえる「3つの基本」
最後に、この構成を組むときに法務・セキュリティの観点から押さえておきたいポイントを3つにまとめると次のようになります。
① データの所在を限定する――JP Geo推論プロファイルを必ず使うこと。
② アクセス権限を最小にする――専用の作業用IAMユーザーを作成し、Bedrockの利用に必要な権限だけを付与する。
③ 認証情報の有効期限を短くする――AWSのBedrockには有効期限12時間の短期APIキー(Bearer Token)の仕組みがあります。長期キーに比べて、漏洩時のリスクが構造的に低くなります。
まとめ──「使えるか・使えないか」から「どう設計するか」へ
整理すると、2026年4月時点で、Bedrock経由・JP Geo推論プロファイルを使った構成(およびその全社展開版であるClaude Cowork in Amazon Bedrock)は、
- 個人情報保護法28条のボトルネックを、設計段階で回避できる
- 処理の監督が日本の法制度・規制機関の枠組みの中で完結し、米国など海外法令の影響を抑えられる
- 守秘義務・秘密保持義務の論点は別途検討が必要だが、漏洩リスクの低減・契約管理のシンプル化という補強材料が得られる
- これまで大企業・情シスを持つ組織にしか現実的でなかった「国内完結」の選択肢が、Claude Coworkの登場により中堅・中小組織でも組織展開可能になった
という意味で、生成AIの本格活用を検討する組織にとって、検討に値する選択肢になっています。
一方で、
- MCP・エージェント連携の管理
- API管理体制の整備とITリテラシーの底上げ
といった運用面の課題があり、ここを軽視すると、せっかくの「国内完結」が形骸化します。
技術的な問題と、法的な問題と、運用の問題を、それぞれの専門家と一緒に整理しながら設計することが重要です。
※本記事は2026年4月時点のAWSおよびAnthropicの公開情報、および日本の関連法令の解釈に基づいています。Amazon Bedrockのリージョン対応、推論プロファイル、モデルラインナップ、Claude Coworkの提供条件は継続的にアップデートされており、最新の状況はAWS公式ドキュメント、Claude Cowork公式ドキュメント等でご確認ください。なお、本記事は一般的な情報提供であり、個別の事案に関する法的助言ではありません。
主な参考公開情報
- AWS公式ブログ「開発現場から全社展開へ:Amazon Bedrock で Claude Cowork を動かす」(2026年4月22日)
- AWS公式ブログ「Amazon Bedrock で日本国内に閉じた Anthropic Claude 4.5 の推論が可能に!日本国内クロスリージョン推論のご紹介」
- Anthropic公式「Introducing Claude Opus 4.7」(2026年4月16日)