「Claude APIを使っていたら、なんか料金が高くなっている気がする」「inference_geoって何？設定しないといけないの？」そんな疑問を持ったことはありませんか？
実はこれ、Anthropicが2026年2月にClaude Opus 4.6とともに正式に導入したUS-only inference（米国限定推論）という機能が関係しています。データがどこで処理されるかを制御できる非常に重要な機能なのに、日本語での解説がまだ少なく、気づかないうちに余計なコストを払っているケースも少なくありません。
この記事では、US-only inferenceの仕組み・料金・使うべき場面・注意点を、初心者でも理解できるようにゼロから解説します。
- ClaudeのUS-only inferenceとは、APIリクエストのデータ処理場所を米国内に限定する機能で、inference_geo: “us”というパラメータで制御する仕組みのこと。
- この機能を使うと全トークン料金に1.1倍（10%増）の価格乗数が適用されるが、金融・医療・法務などデータ規制が厳しい業界では導入必須となる場合がある。
- Claude Opus 4.6以降の新モデルにのみ適用される新仕様で、旧モデルでは設定しても料金変動は発生しない重要な仕様差がある。
- そもそもClaudeはデータをどこで処理しているの？
- US-only inferenceの仕組みを技術的に理解する
- 料金の詳細と計算方法を徹底解説！
- どんな企業が使うべき機能なのか？
- AWS BedrockやGoogle Vertex AIとの違いは？
- EU・日本企業はどう対応すべき？
- 「なんか請求が高い」の犯人を特定する！コスト監視の実践術
- プロンプトキャッシュとUS-only inferenceを組み合わせたときの本当のコスト
- Claudeだからできる！実務で使えるプロンプト集
- 現場でよくある「困った」体験と解決策
- 2026年3月時点の最新動向とこれから
- ぶっちゃけこうした方がいい！
- US-only inferenceに関するよくある質問
- まとめ
そもそもClaudeはデータをどこで処理しているの？
AIのイメージ
Claudeを普通に使うとき、あなたが送ったプロンプト（入力）はAnthropicのサーバーで処理されます。では、そのサーバーはどこにあるのでしょうか？
Anthropicの公式情報によると、デフォルト設定（グローバルルーティング）では、米国・欧州・アジア・オーストラリアなど複数の地域にリクエストが振り分けられる可能性があります。これは「負荷分散」と呼ばれる仕組みで、世界中のサーバーをうまく使い回すことでレスポンスを速くするための設計です。
一般的なユーザーにとって、これはまったく問題ありません。でも企業の立場で考えると、話が変わってきます。
たとえば、医療情報・法律文書・金融データなどを扱う企業では、「このデータは必ず米国内だけで処理しなければならない」という内部規定や法的要件があります。そのような企業が「処理場所が欧州やアジアになることもある」グローバルルーティングを使うのは、コンプライアンス上のリスクになる可能性があるわけです。
US-only inferenceは、このような企業向けに「すべての処理を米国内のインフラだけで行うことを保証する」機能として提供されています。
US-only inferenceの仕組みを技術的に理解する
inference_geoパラメータとは何か？
Anthropicの公式ドキュメントによると、US-only inferenceはAPIリクエストにinference_geoというパラメータを追加することで制御できます。Claude Opus 4.6以降の新しいモデルで使える機能です。
このパラメータには2つの値を設定できます。“us”を指定すると処理が米国内のみに制限され、“global”または省略した場合はデフォルトのグローバルルーティングが適用されます。設定はリクエスト単位でも行えますし、ワークスペース全体のデフォルト設定としても適用できます。
「ワークスペース設定」とは、AnthropicのコンソールでAPI全体のデフォルト動作を管理する仕組みです。たとえばdefault_inference_geo: “us”を設定しておけば、すべてのAPIリクエストで自動的に米国限定処理が適用されます。逆にallowed_inference_geosで許可する地域を制限することもでき、たとえば米国のみを許可すれば、誰かが誤って”global”を指定しても拒否されます。
データの保存場所（Workspace geo）との違い
US-only inferenceを理解する上で混同しがちなのが、「処理場所（inference geo）」と「保存場所（workspace geo）」は別の設定だということです。
| 設定の種類 | 制御対象 | 設定方法 |
|---|---|---|
| inference_geo（推論ジオ） | モデルがデータを処理する場所 | APIリクエストごと、またはワークスペースのデフォルト |
| workspace_geo（ワークスペースジオ） | データが保存される場所、画像変換・コード実行などの処理場所 | ワークスペース作成時に設定（後から変更不可） |
workspace_geoは後から変更できません。これは非常に重要なポイントです。米国内でのデータ保存を義務付けているコンプライアンス要件がある場合、ワークスペースを作成するタイミングで「us」を選ぶ必要があります。後から「やっぱり米国にしたい」となっても変更できないため、エンタープライズ利用の際は最初の設定に注意が必要です。
料金の詳細と計算方法を徹底解説！
1.1倍ってどのくらい実際に影響する？
US-only inferenceを有効にすると、すべてのトークンカテゴリに1.1倍の価格乗数が適用されます。具体的には、入力トークン・出力トークン・キャッシュ書き込み・キャッシュ読み込みのすべてが対象です。
Claude Opus 4.6の標準料金は入力が100万トークンあたり5ドル、出力が25ドルです。US-only inferenceを使うと入力5.5ドル、出力27.5ドルになります。一見小さな差に見えますが、大量のトークンを処理するエンタープライズ用途では月間コストに無視できない影響が出てきます。
重要なのは、この料金乗数はClaude Opus 4.6以降の新モデルにのみ適用されるという点です。それ以前の旧モデル（Opus 4.1やClaude 3系列など）では、inference_geoパラメータを指定しても料金変動は発生しません。
他の料金乗数との組み合わせに注意！
US-only inferenceの料金乗数は、他の料金修飾子とスタック（重複適用）されます。これが思わぬコスト増の原因になることがあります。
たとえばClaude Opus 4.6で1Mトークン超のコンテキスト（ベータ版）を使いながら、US-only inferenceも有効にした場合、長文コンテキストのプレミアム料金（入力10ドル/出力37.5ドル）にさらに1.1倍が掛かります。つまり入力11ドル、出力41.25ドルになる計算です。
また、超高速処理が可能なFastモード（研究プレビュー）を使う場合、標準料金の6倍という価格に対してさらにUS-only inferenceの1.1倍が重なります。このような組み合わせを使う前に、必ずコスト試算を行うことを強く推奨します。
どんな企業が使うべき機能なのか？
US-only inferenceが「必須」になるシーン
この機能が必要かどうかは、扱うデータの性質と業界規制によって決まります。以下のような状況に当てはまる場合は、積極的に導入を検討すべきです。
まず金融業界では、SEC（米証券取引委員会）やFINRA（金融業規制機構）の規制により、特定の金融データを米国内で処理・保管することが求められる場合があります。顧客の投資情報や取引データをClaude APIに渡してレポート生成などを行う際、処理場所の管理は法的リスクに直結します。
医療・ヘルスケア業界では、HIPAA（医療情報の保護に関する米国法）への対応が必要です。患者データや診療記録を含むプロンプトをAnthropicのAPIに送る場合、データが米国外で処理されることはHIPAAの要件と相容れない可能性があります。
法律事務所・コンサルティングでも、クライアントの機密情報を扱う際に処理地の管理が求められることがあります。特に米国の顧客を持つ法律事務所では、データが予期せず海外のサーバーで処理されることへの懸念が強いです。
US-only inferenceが「不要」な一般的なケース
一方で、個人開発者・スタートアップ・非規制業種の一般的なアプリケーション開発においては、US-only inferenceを使う理由はほとんどありません。グローバルルーティングのほうがパフォーマンスが良く、コストも10%低く抑えられます。
「なんとなく安心だから」という理由だけでUS-only inferenceを有効にしてしまうと、毎月の請求額が確実に増えます。本当に法的・社内規定上の必要性がある場合にのみ使う機能だと理解してください。
AWS BedrockやGoogle Vertex AIとの違いは？
Claudeはアンソロピック直接のAPIだけでなく、AWS Bedrock・Google Vertex AI・Microsoft Foundry経由でも利用できます。これらのプラットフォームにもリージョン設定機能がありますが、Anthropic直接APIのinference_geoとは仕組みが異なります。
AWS BedrockやGoogle Vertex AIでは、リージョンエンドポイントを使うことでデータの処理地を制御できます。ただし、Anthropicの公式情報によると、これらのプラットフォームでのリージョン指定エンドポイントを使うと、グローバルエンドポイントに比べて10%のプレミアム料金がかかる場合があります。
また、US-only inferenceはAnthropicの直接API（1P）にのみ適用される機能です。AWSやGoogleを経由する場合は、各プラットフォーム側のリージョン設定を使うことになり、料金体系も各プラットフォームのものが適用されます。どのプラットフォームを使うかによってコンプライアンス対応の方法が変わる点は、事前によく確認しておく必要があります。
EU・日本企業はどう対応すべき？
欧州のGDPR対応とUS-only inferenceの関係
EU圏の企業にとって、US-only inferenceは「使えば解決」とはなりません。むしろ逆です。EUのGDPR（一般データ保護規則）では、欧州市民の個人データを欧州外（特に米国）に移転することに厳しい制限があります。
つまり、EU企業がGDPR対応でデータを欧州内に留めたい場合、US-only inferenceを使うとデータが米国で処理されることが確定してしまい、GDPRに抵触する可能性があります。EUデータを扱う場合は、AWS BedrockやGoogle Vertex AIの欧州リージョンを利用するほうが適切です。
日本企業にとっての現実的な判断軸
日本企業の場合、日本にはGDPRほど厳格な「処理地域指定義務」はありません。ただし、業界によっては金融庁・厚生労働省・個人情報保護委員会のガイドラインに従う必要があります。
日本の金融機関や医療機関でClaudeのAPIを業務利用する場合、まずは社内のコンプライアンス担当や法務部門に「処理地の制御が必要かどうか」を確認してから、US-only inferenceの導入を判断することをお勧めします。個人情報や機密業務データを含まない一般的なアプリケーション開発であれば、追加コストが発生するUS-only inferenceを使う必要性は低いと言えます。
「なんか請求が高い」の犯人を特定する！コスト監視の実践術
AIのイメージ
Usage APIで地域別コストを可視化する方法
US-only inferenceを導入した後、最もよくある「あれ、思ったより高い…」という体験は、自分のAPIがどのgeo設定でどれだけ呼ばれているのかを把握していないことから来ます。これはかなりあるあるな話で、複数の開発者が同じワークスペースを使っていたり、サービスが自動的にAPIを叩いていたりすると、気づかないうちにinference_geo: “us”のリクエストが積み重なっていることがあります。
AnthropicはUsage APIとCost APIという2つの管理用エンドポイントを提供しています。これらはAdmin APIキー（sk-ant-admin…で始まるもの）が必要な特別なエンドポイントで、組織全体のトークン使用量をinference_geoごとに集計して確認できます。
たとえばinference_geoの内訳を確認したい場合、Usage APIにgroup_by[]=inference_geoというパラメータを追加してリクエストすると、usとglobalそれぞれで何トークン消費されているかが日別・モデル別に分かります。ここで予想外にusの割合が多かった場合、どこかのコードでinference_geo: “us”がハードコードされていないか確認するサインです。
なお、Claude Opus 4.6より前の旧モデルではinference_geoの情報が”not_available”として返ってくるため、旧モデルのトラッキングとは別に管理する必要があります。この仕様を知らないと「なんでnot_availableが大量に出るんだ？」と混乱するので覚えておいてください。
Priority Tier（優先枠）ユーザーへの追加注意点
Anthropicには高トラフィック向けのPriority Tier（事前コミット型のTPM確保）という契約形態があります。このPriority TierでUS-only inferenceを使うと、1.1倍の料金乗数が「コミット済みTPMの消費速度」にも影響するという少し複雑な仕様があります。
具体的には、inference_geo: “us”で1トークン消費すると、Priority Tierのバケツから1.1トークン分が引かれる計算になります。つまり同じTPM契約をしていても、US-only inferenceを多用するほど実際に処理できるリクエスト数が減ります。大量のAPIリクエストを処理する本番環境でこの仕様を見落とすと、レート制限（429エラー）の頻度が増えて「なぜか最近エラーが増えた」という状況に陥ることがあります。
プロンプトキャッシュとUS-only inferenceを組み合わせたときの本当のコスト
キャッシュを使えば1.1倍のコスト増をほぼ相殺できる
「US-only inferenceで10%コストが増えるなら、プロンプトキャッシュと組み合わせてコストを抑えられないか？」これは非常に賢い発想で、実際に組み合わせの効果は絶大です。
Claudeのプロンプトキャッシュ機能は、キャッシュヒット時のトークン読み込みコストが通常の10分の1（90%オフ）になります。つまり50,000トークンのシステムプロンプトを毎回送る設計のアプリケーションがあったとして、キャッシュなしではそのたびに通常の入力コストがかかるのに対し、キャッシュを使うと2回目以降は10%のコストで済みます。
| 設定パターン | 入力トークンコスト（Opus 4.6、1Mあたり） | 特徴 |
|---|---|---|
| グローバル＋キャッシュなし | $5.00 | 基準値 |
| US-only＋キャッシュなし | $5.50（1.1倍） | 10%増 |
| グローバル＋キャッシュヒット | $0.50（90%オフ） | 大幅節約 |
| US-only＋キャッシュヒット | $0.55（1.1倍×10%） | グローバル+キャッシュより10%増だが、依然として大幅節約 |
ご覧の通り、US-only inferenceとプロンプトキャッシュを組み合わせても、キャッシュなし・グローバルの約11%というコストで運用できます。コンプライアンス要件でUS-only inferenceが必要な企業でも、適切なキャッシュ設計をすれば実質的なコスト増を最小限に抑えられます。
ただし一点注意があります。2026年2月5日以降、Anthropicのプロンプトキャッシュはワークスペース単位の分離に変更されました。つまり同じ組織内でも複数のワークスペースを使っている場合、ワークスペースをまたいでキャッシュは共有されません。US-only用のワークスペースを別に作っている場合は、そのワークスペース内でのキャッシュ戦略を独立して設計する必要があります。
Claudeだからできる！実務で使えるプロンプト集
コンプライアンス担当者向けUS-only inference導入可否を判断するためのプロンプト
「うちの会社でUS-only inferenceが必要かどうか、Claudeに相談してみた」という体験談をよく聞くようになりました。実際、Claudeはコンプライアンスの判断フローを整理するのが非常に得意です。以下のプロンプトをそのまま使えます。
【プロンプト例①業界別コンプライアンス要件の確認】
「私は日本の[金融機関/医療機関/IT企業]のシステム担当者です。Claude APIを使って[顧客への自動メール返信/社内ドキュメント検索/コードレビュー]システムを構築しようとしています。処理するデータには[個人情報/機微情報/公開情報のみ]が含まれます。日本の個人情報保護法や業界規制の観点から、AnthropicのUS-only inferenceを設定すべきかどうか、判断材料をまとめてください。また、US-only inferenceが必要だった場合と不要だった場合のそれぞれで、月間1億トークン処理した場合のコスト試算も出してください（モデルはClaude Opus 4.6を想定）。」
このプロンプトを使うと、Claudeは個人情報保護法の観点からの整理、コスト比較表、さらに「こういう場合はこうすべき」という具体的な判断フローまで出してくれます。
【プロンプト例②inference_geoの設定漏れを防ぐコードレビュー依頼】
「以下のPython/Node.jsコードは、AnthropicのClaude APIを呼び出す関数です。[コードを貼り付ける]。このコードについて以下を確認してください。1）inference_geoパラメータが設定されているか。2）設定されている場合、意図通りの値（us または global）になっているか。3）コスト最適化の観点でプロンプトキャッシュを活用できる箇所があるか。4）US-only inferenceとキャッシュを組み合わせた場合の月間推定コストを計算してください（月間リクエスト数[X]件、平均入力トークン[Y]、平均出力トークン[Z]で計算）。」
この手の「コードレビュー＋コスト試算」はClaudeが特に得意とする複合タスクで、一度のリクエストで複数の観点をまとめてチェックしてもらえます。
【プロンプト例③ワークスペース設定の最適構成を考えてもらう】
「AnthropicのClaude APIを使う開発チームです。以下の条件に合わせて、ワークスペースの最適な構成を提案してください。条件開発環境では処理地の制約なし、ステージング環境では動作確認のためUS-only、本番環境では[厳格なコンプライアンス要件あり/なし]。それぞれのワークスペースのallowed_inference_geosとdefault_inference_geoの設定値と、その理由を教えてください。また、誤ってglobal設定のままAPIが本番で呼ばれないようにするための実装上の工夫も一緒に提案してください。」
現場でよくある「困った」体験と解決策
体験①「請求書を見たら先月より15%高くなっていた」
これは開発チームが新しいマイクロサービスを追加した際に、そのサービスのコードにinference_geo: “us”がデフォルトで書かれていた、というケースがとても多いです。特に、セキュリティ意識の高いシニアエンジニアが「念のためUS-only」と書いたコードがそのまま本番に入ってしまうパターンです。
解決策は2つあります。ひとつはワークスペースレベルでallowed_inference_geosを使って許可するgeoを制限すること。たとえば本番環境のワークスペースに対して「us」だけを許可するか、「global」だけを許可するかをコンソールで明示的に設定しておけば、個別のコードで誤ったgeoを指定してもエラーになります。もうひとつはCost APIでinference_geoごとのコストを週次でSlackに通知する簡単なモニタリングスクリプトを作っておくことです。
体験②「OpenAI SDKの互換エンドポイント経由でClaude使ったらinference_geoが効かない」
AnthropicはOpenAI互換のAPIエンドポイントを提供しており、既存のOpenAI SDKコードをほぼそのままClaudeに移行できます。ただしOpenAI SDKの互換エンドポイントではinference_geoパラメータが使えないという制限があります。これは公式ドキュメントに明記されていますが、実際に試してみるまで気づかないエンジニアが多いです。
US-only inferenceを使いたい場合は、OpenAI互換エンドポイントではなくAnthropicネイティブのSDK（Pythonのanthropicライブラリ、またはNode.jsの@anthropic-ai/sdkライブラリ）を使う必要があります。既存のコードをOpenAI互換から移行する場合、この点を先にチームで共有しておくと、「なぜか設定が効かない」という時間の無駄を防げます。
体験③「Batch APIでUS-only inferenceを使えると思っていなかった」
大量の非同期処理を50%引きで実行できるBatch APIと、US-only inferenceは組み合わせて使えます。これを知らずに「Batch APIを使うコンプライアンス対応のバッチ処理はどうすれば？」と悩んでいるエンジニアが意外と多いです。
Batch APIへのリクエストは個別のリクエストそれぞれにinference_geoを指定でき、バッチ内のリクエストごとに異なるgeoを設定することも可能です。たとえばコンプライアンスが必要なデータは”us”、そうでないデータは”global”として同じバッチに混在させることもできます。Batch APIの50%割引にUS-only inferenceの1.1倍乗数が加わるため、最終的なコストはBatch API基準の55%（標準価格の半分＋10%）になります。
2026年3月時点の最新動向とこれから
今後追加される可能性がある地域設定
Anthropicの公式ドキュメントには「追加のリージョンは今後追加予定」と記載されています。2026年3月現在、inference_geoで選べる値は”us”と”global”の2択のみです。EUのGDPR対応を求める声は世界中の企業から強く上がっており、今後”eu”などのリージョン指定が追加されることが期待されています。
特に注目すべきはEU企業向けの対応状況です。現時点でEUのデータを扱う企業がClaudeのAnthropicダイレクトAPIを使う場合、EU域内での処理を保証する方法はなく、AWS BedrockやGoogle Vertex AIのEUリージョンエンドポイントを使うのが現実的な選択肢です。これが2026年後半に変わる可能性があり、企業のコンプライアンス担当者はAnthropicのリリースノートを定期チェックしておくことをお勧めします。
workspace_geoの拡張も期待される
現時点ではworkspace_geo（データ保存場所）として選べるのは”us”のみです。これも今後、欧州やアジアのデータセンターが選択肢に加わる可能性があります。ただし前述の通りworkspace_geoはワークスペース作成後に変更できないため、将来の拡張を見越してワークスペースの設計を柔軟にしておくことが賢明です。たとえば「将来EU対応が必要になるかもしれないデータ」と「US-onlyで確定のデータ」を最初から別ワークスペースに分けておけば、新しいgeoオプションが追加されたときにスムーズに移行できます。
ぶっちゃけこうした方がいい！
ここまで丁寧に解説してきましたが、個人的には「まず使わない前提でスタートして、本当に必要になったときだけ有効にする」が一番楽で効率的だと思っています。
理由はシンプルで、US-only inferenceが「本当に必要かどうか」の判断は、ほとんどのケースでコンプライアンス担当者・法務・経営層を巻き込む意思決定になります。エンジニアが「なんとなく安全そう」という理由で勝手に有効にすると、月のコストが確実に増えるのに、その判断の根拠を後から求められたときに答えられない、という状況になりがちです。
実際の現場で起きていることをぶっちゃけると、「よく分からないからとりあえずUS-only」で設定したまま忘れているプロジェクトが想像以上に多いです。これはAPIキーを複数人で使い回しているスタートアップや、コードレビューが甘いプロジェクトでよく見かけます。
だからこそ逆に、US-only inferenceを使う必要があると正式に決まったら、ワークスペースレベルでdefault_inference_geo: “us”とallowed_inference_geos: [“us”]を設定して「強制的にUS-only」にする方が管理が楽です。個別のリクエストに毎回inference_geoを書くよりも、ワークスペース設定で縛ってしまえばコードの書き漏れによるコンプライアンス違反リスクをゼロにできます。
コスト面で言えば、プロンプトキャッシュの設計を先に最適化しておけば、US-only inference分の10%コスト増はほぼ吸収できるので、コンプライアンス要件のある企業でもコスト面で過度に怖がる必要はありません。「処理地の保証」という価値に対して10%というのは、エンタープライズのコンプライアンスコスト感覚からすれば十分に安いものです。
結論として、「設定するかどうかの判断は丁寧に、でも一度決めたらワークスペース設定で自動化する」というアプローチが、最も効率的でミスが少ない運用方法です。難しく考えすぎず、まずはAnthropicのコンソール（platform.claude.com）のワークスペース設定画面を開いて、現在の設定状態を確認するところから始めてみてください。
US-only inferenceに関するよくある質問
inference_geoを設定しないと何が起きる？
何も設定しない場合、Anthropicのデフォルト（グローバルルーティング）が適用されます。これはリクエストが最も近い・空いているサーバーに自動的に振り分けられる設定で、通常はパフォーマンスが良く、料金も標準です。特別なコンプライアンス要件がなければ、何も設定しないのが最もコスト効率の良い選択です。
旧モデルでinference_geoを指定したらどうなる？
Claude Opus 4.6より前のモデルでは、inference_geoパラメータを指定しても料金変動は発生しません。Anthropicの公式ドキュメントでも「旧モデルはinference_geo設定の影響を受けない」と明記されています。ただし、実際に処理地が制御されるかどうかも保証されないため、旧モデルで処理地保証が必要な場合は別途確認が必要です。
キャッシュ機能とUS-only inferenceを組み合わせるとどうなる？
プロンプトキャッシュ機能（よく使うプロンプトを事前にキャッシュしてコスト削減する機能）を使っている場合でも、US-only inferenceを有効にするとキャッシュ書き込み・キャッシュ読み込みの両方に1.1倍の乗数が適用されます。キャッシュを大量に活用しているユースケースでは、コスト増の影響が無視できなくなることがあります。設計段階でしっかりコスト試算をしておきましょう。
Zero Data Retention（ZDR）との違いは？
US-only inferenceと混同されがちなのがZDR（ゼロデータリテンション）モードです。ZDRは「データを処理後すぐに削除し、ログとして保存しない」という機能で、主に医療・金融のエンタープライズ向けです。一方、US-only inferenceは「どこで処理するか」を制御する機能です。両者は独立した設定であり、ZDRを使っても処理地は制御されず、US-only inferenceを使ってもデータが保存される期間は変わりません。真にセキュアなエンタープライズ利用には、両方の設定を組み合わせることが推奨されます。
まとめ
ClaudeのUS-only inferenceとは、APIリクエストのデータ処理を米国内のインフラに限定する機能です。金融・医療・法務など、データ処理地の管理が法的に求められる業界にとっては非常に重要な機能ですが、一般的な開発用途では不要なコスト増につながる可能性もあります。
最も大切なポイントをまとめると、Claude Opus 4.6以降の新モデルにのみ適用される新機能であること、有効にすると全トークンカテゴリに1.1倍の料金乗数がかかること、そして本当に必要かどうかはコンプライアンス要件を確認してから判断することが重要です。
APIを使い始めたばかりの方は、まずグローバルルーティング（デフォルト）でコストを抑えながら開発を進め、規制業界での本番運用を検討する段階になったときに、社内の法務・コンプライアンス担当とともにUS-only inferenceの必要性を改めて評価することをお勧めします。データの処理地を正しく管理することは、AIの安全・安心な業務活用の第一歩です。
コメント