ClaudeのUSオンリー推論とは？メリット・料金・設定方法を完全解説！

「データをアメリカ国内だけで処理したい」「コンプライアンス上、推論場所を制御しなければならない」――そんな悩みを抱えるエンジニアや企業の担当者が、2026年に入って急増しています。AnthropicがClaude Opus 4.6のリリースと同時に正式提供を開始したUSオンリー推論（US-only inference）は、まさにその悩みに直接応える機能です。しかし「1.1倍の料金がかかる」「どんな場合に使うべきか」「具体的にどう設定するのか」といった疑問に、わかりやすく答えてくれる情報がまだ少ないのが現状です。

この記事では、Claude APIのUSオンリー推論が何者なのか、どんな企業・開発者に本当に必要なのかを、最新の公式情報と実用的な視点から徹底的に解説します。読み終わったあとには「自分のプロジェクトに必要かどうか」が明確に判断できるようになるはずです。

USオンリー推論が登場した背景――なぜ今なのか？

AIを業務に組み込む企業が急増する一方で、「推論がどこで実行されるかわからない」という不安が、特に規制産業の現場で強まっています。Anthropicがこれまで提供していたグローバルルーティングは、リクエストを世界中のインフラに分散させることでコストと安定性を最適化する仕組みでした。これ自体は優れた設計なのですが、金融機関や医療機関、政府系プロジェクトにとっては「データがどこで処理されるか保証できない」という点が導入の壁になっていたのです。

2026年2月、AnthropicはClaude Opus 4.6のリリースと合わせてデータレジデンシー制御を刷新しました。inference_geoパラメータという新しい仕組みにより、開発者はAPIリクエストごとに「アメリカ国内のみ」か「グローバル」かを選択できるようになりました。これは従来の組織レベルの一括設定から、リクエストレベルの細粒度制御への大きな進化を意味しています。

重要なのは、この機能が「エンタープライズ向けのオプション機能」という位置づけではなく、Claude API（1P）のすべての利用者が使える機能だという点です。AWS BedrockやGoogle Vertex AI経由の場合はエンドポイントURLや推論プロファイルで管理する仕組みになるため対象外ですが、Anthropicの直接APIを使っている開発者であれば、追加申請なしに利用を開始できます。

USオンリー推論の具体的なメリットを整理する

メリット①データ処理場所をアメリカ国内に限定できる

最も直接的なメリットは、推論がどこで実行されるかを明示的に制御できる点です。通常のグローバルルーティングでは、Anthropicのインフラが最適なリージョンを自動選択するため、リクエストがどの国のサーバーで処理されているかをAPIの利用者側が把握することは難しい状況でした。

inference_geoパラメータに「us」を指定すると、APIレスポンスのusageオブジェクトにinference_geoフィールドが含まれ、実際に推論が行われた場所を確認できます。これは単なる設定の問題ではなく、監査証跡（オーディットトレイル）の観点からも重要です。「この処理はアメリカ国内で行われた」という事実をAPIレスポンスで確認できるため、コンプライアンス担当者への説明責任を果たしやすくなります。

メリット②規制産業特有のコンプライアンス要件を満たせる

医療分野のHIPAA、金融分野の各種データ保護規制、政府調達における情報セキュリティ要件――これらの規制に共通するのは「個人情報や機密データの処理場所を管理・証明できること」という要求です。

Anthropicの公式ドキュメントでも、inference_geoパラメータが「ヘルスケア・金融・政府機関向けのデータレジデンシー要件を満たすために設計されている」と明記されています。これまでClaudeの導入を検討しながらコンプライアンス上の懸念で断念していた企業にとって、実質的な導入障壁が取り除かれたことを意味します。

メリット③ワークスペース全体のポリシーとして適用できる

個々のリクエストにinference_geoを指定するだけでなく、AnthropicコンソールのWorkspace設定でdefault_inference_geoとallowed_inference_geosを設定できます。これにより、ワークスペース内のすべてのAPIキーに対してUSオンリー推論をデフォルトとして強制したり、US以外のgeoを指定したリクエストをエラーとして弾いたりすることが可能です。

特にチームで複数の開発者がAPIを利用している場合、個人の設定ミスによるデータの予期しない海外処理を防ぐ「フェイルセーフ」として機能します。従来はAnthropicに申請してグローバルルーティングからオプトアウトする組織レベルの設定しか選択肢がなかったところ、より細かい粒度で管理できるようになったのは大きな進歩です。

メリット④Batch APIとの組み合わせで大量処理にも対応

USオンリー推論はBatch APIでも利用できます。つまり、数千件から数万件のリクエストを一括処理する際にも、各リクエストごとに推論場所を指定できます。バッチ内の異なるリクエストで異なるinference_geo値を混在させることも可能で、「機密情報を含むリクエストはUS、そうでないものはグローバル」という柔軟な設計が実現できます。

これはAmazon BedrockでBatch InferenceとStructured Outputsを組み合わせて大量の記事要約処理を効率化している企業事例と組み合わせることで、さらに強力なパイプラインを構築できる可能性を示しています。

料金体系を正確に理解する――1.1倍とは具体的にどういう意味か？

USオンリー推論を利用すると、すべてのトークンカテゴリに1.1倍の料金乗数が適用されます。対象となるのは入力トークン・出力トークン・キャッシュ書き込み・キャッシュ読み込みの4つです。

実際の金額で考えると、Claude Opus 4.6（標準価格入力$5/Mトークン、出力$25/Mトークン）をUSオンリー推論で利用した場合は、入力$5.5/Mトークン、出力$27.5/Mトークンとなります。10%増という数字は一見小さく見えますが、大規模な本番ワークロードでは積み上がると無視できないコスト差になります。

利用条件	入力（/1Mトークン）	出力（/1Mトークン）
グローバルルーティング（デフォルト）	$5.00	$25.00
USオンリー推論（inference_geo: “us”）	$5.50	$27.50
Sonnet 4.6グローバル	$3.00	$15.00
Sonnet 4.6 USオンリー推論	$3.30	$16.50

注意点として、この1.1倍乗数は他の料金乗数と重複して適用されます。たとえばPriority Tier（優先利用枠）を使っている場合、USオンリー推論で消費したトークンはコミット済みTPMから1.1トークン分として消化されます。Fast Mode（6倍課金）と組み合わせた場合は、Fast ModeにさらにUSオンリー推論の1.1倍が乗算される形になるため、コスト計算は慎重に行う必要があります。

また、この料金体系はClaude API（1P）専用です。AWS BedrockやGoogle Vertex AI経由でClaudeを使っている場合は、それぞれのプラットフォームが独自のリージョン課金体系を持つため、inference_geoパラメータは対象外です。

設定方法――実際のAPIコードでどう書くのか

基本的なリクエストへの追加方法

既存のAPIコードへの追加は非常にシンプルです。POST /v1/messagesのリクエストボディにinference_geoフィールドを加えるだけです。値は「us」（USオンリー推論）または「global」（グローバルルーティング）の2択です。

重要な制約として、inference_geoパラメータはClaude Opus 4.6以降の新モデルにのみ対応しています。それより古いモデル（Claude 3系やOpus 4.1など）に対してこのパラメータを指定すると、APIは400エラーを返します。既存のコードベースでモデルをアップグレードする際は、この点に注意が必要です。

ワークスペースレベルでの一括設定

個々のリクエストではなく、ワークスペース全体でUSオンリー推論を強制したい場合は、AnthropicコンソールでWorkspace設定を変更します。allowed_inference_geosを「[“us”]」に設定すれば、そのワークスペース内では「global」を指定したリクエストがエラーになり、default_inference_geoを「us」に設定すれば、パラメータを省略したリクエストも自動的にUSオンリーで処理されます。

以前、Anthropicへの申請でグローバルルーティングからオプトアウトしていた組織の場合、コード変更なしで自動的にallowed_inference_geos: [“us”]とdefault_inference_geo: “us”が設定された状態に移行されています。既存の処理フローはそのまま維持されるため、移行作業は最小限で済みます。

OpenAI互換エンドポイントは対象外

Anthropic APIにはOpenAI SDK互換のエンドポイントが用意されていますが、inference_geoパラメータはこの互換エンドポイントでは利用できません。USオンリー推論を使いたい場合は、Anthropic純正のSDKまたは直接のHTTPリクエストを使う必要があります。OpenAI SDKからClaudeに移行しつつUSオンリー推論も使いたいという場合は、API呼び出し部分の書き直しが必要になります。

どんなユースケースに向いているのか？――使うべき場面と避けるべき場面

USオンリー推論が本当に価値を発揮するのは、以下のような場面です。医療機関でのPHI（保護された医療情報）を含む処理、金融機関での顧客情報を含む分析・要約タスク、政府・行政機関向けシステムでの機密文書処理、そして「データはアメリカ国内で処理される」とエンドユーザーや規制当局に証明する必要がある製品開発の場面です。

一方で、コンプライアンス上の制約がなく、コストを最小化したいユースケースでは、グローバルルーティングを使い続けることが合理的な選択です。特に、Claude Opus 4.6の1Mトークンコンテキストを活用した大規模ドキュメント処理や、長時間のエージェントワークフローを頻繁に実行する場合は、追加の10%コストが積み重なりやすいため、必要性を慎重に検討しましょう。

EUや日本からの利用――グローバルな規制要件との関係

USオンリー推論はその名のとおり「アメリカ国内での処理を保証する」機能です。裏を返せば、EUのGDPRが要求するような「EU域内での処理」は、現在のAnthropicの直接APIではinference_geoパラメータでは実現できません。2026年3月時点で、inference_geoに指定できる値は「us」と「global」の2つのみで、EU専用のオプションは存在しません。

EUのデータレジデンシー要件を満たす必要がある場合は、AWS BedrockのEU推論プロファイルやGoogle Vertex AIのEUリージョンエンドポイントを経由してClaudeを利用するのが現時点での現実的な選択肢です。これらのプラットフォームでは、EU域内でのデータ処理とストレージを保証するエンドポイントが提供されており、プラットフォーム側のDPA（データ処理契約）がGDPR対応の根拠になります。

日本国内の企業が国内規制に対応するためにClaudeを使う場合、現状では「グローバルルーティング（デフォルト）」か「USオンリー推論」のどちらかを選ぶことになります。日本の個人情報保護法（個人情報保護法第三者提供規制）の観点では、利用する個人情報の種類と用途に応じて法務担当者と連携した判断が必要です。

「Workspace geo」と「Inference geo」は別物――混同すると設計が崩れる

ここは多くの開発者が最初につまずくポイントです。Anthropicのデータレジデンシー設定には、実は2つの独立した制御軸が存在しています。記事の前半で解説したinference_geoは「推論をどこで実行するか」を制御する軸ですが、もうひとつWorkspace geoという設定があります。

Workspace geoは「データを静止状態でどこに保存するか」「画像トランスコーディングやコード実行などのエンドポイント処理をどこで行うか」を制御します。こちらはAPIリクエストごとではなく、Workspace作成時に一度だけ設定するもので、作成後に変更できないという重要な制約があります。2026年3月時点では「us」のみが選択可能です。

つまり正確に言えば、ClaudeのデータレジデンシーはこのようなLayered Architectureになっています。

これを混同したまま設計を進めると、「Workspace geoをusに設定したからデータは全部アメリカで処理されていると思っていたら、inference_geoを指定していなかったのでグローバルルーティングで推論が行われていた」という事態が起きます。コンプライアンス上の証跡を求められた際に、「推論場所」と「データ保存場所」の区別が明確でなければ説明責任を果たせません。

ゼロデータリテンション（ZDR）との関係も把握しておく必要があります。ZDR契約を締結している組織では、inference_geoで指定したUS推論も対象となり、APIレスポンスが返された後にデータが保存されません。医療・金融分野での最高水準のプライバシー保護が必要な場合は、USオンリー推論とZDR契約の組み合わせが現時点で最も強力な設定です。

現場でよく起きる困りごとと、その実際の対処法

困りごと①429エラーが出て作業が止まる――これ、原因が2種類あるって知ってた？

Claude APIを使っていると、必ず一度は遭遇するのがHTTP 429「Too Many Requests」エラーです。「レート制限に引っかかった」とひとことで言っても、実は原因が2種類あって、対処法がまったく違います。

ひとつ目はRPM（リクエスト毎分）・ITPM（入力トークン毎分）・OTPM（出力トークン毎分）の上限超過です。Tier1では入力トークンが毎分4万トークン、Tier4では400万トークンと大きな差があります。ふたつ目はアクセラレーション制限です。普段は余裕があるはずなのに急に429が出る場合、短時間での急激なリクエスト増加に対する制限が発動しています。

現場で多く見られるのは後者のパターンです。夜間バッチ処理を一気に開始したり、並列でリクエストを大量に送り始めたタイミングで発生します。

重要な知識として、キャッシュ済みのトークンはITPMカウントに含まれません。Prompt Cachingを適切に設計するだけで、実効的なスループットが大幅に改善します。特にシステムプロンプトが大きい用途（タグ分類でCSVを数万トークン分含む場合など）では、キャッシュの活用が最初の対策として最も費用対効果が高いです。

レスポンスヘッダーの確認も実務上の重要テクニックです。Claude APIのレスポンスには、現在のレート制限状況を示すヘッダーが含まれており、これを監視することで429エラーが発生する前にスロットリングをかけることができます。429が来てから対処するのではなく、ヘッダーを読んで「そろそろ限界に近い」と事前に検知する実装が、本番環境での安定稼働には不可欠です。

困りごと②「USオンリーにしたはずなのにグローバルで処理されている」というミス

inference_geoを設定したつもりなのに、レスポンスのusageオブジェクトを確認したら「global」と返ってきた――これが起きる主な原因は以下の3つです。

まず、OpenAI SDK互換エンドポイントを使っているケースです。移植コストを下げるためにOpenAI互換エンドポイント経由でClaudeを呼んでいる実装は意外と多いのですが、このエンドポイントではinference_geoパラメータが無効です。Anthropic純正SDKへの移行が必要です。

次に、旧モデルにinference_geoを指定してしまっているケースです。Claude Opus 4.5以前のモデルではこのパラメータがサポートされておらず、正しく指定できていないことに気づかないまま本番稼働しているというケースが報告されています。

3つ目はWorkspace設定のdefault_inference_geoを変更していないパターンです。個別リクエストでは指定しているが、バッチ処理やサブシステムが独自にAPIを呼んでいる部分でパラメータが漏れていることがあります。Workspace全体にデフォルト設定を入れておくことで、この種の設定漏れを防ぐことができます。

困りごと③コンプライアンス担当者に「本当にUSで処理されているの？」と聞かれたとき

エンジニアとしては設定が正しいと分かっていても、コンプライアンス担当者や法務チームに証跡を示す場面が必ず来ます。このとき役立つのが、APIレスポンスのusageオブジェクトに含まれるinference_geoフィールドです。

このフィールドは実際に推論が行われた場所を返すため、アプリケーション側でログに記録しておくことで「いつ、どのリクエストがどこで処理されたか」の証跡を作れます。コンプライアンスチームには「APIレスポンスごとに処理場所が記録されており、監査時に提出できます」と説明できるため、口頭での説明よりもずっと強い根拠になります。

AWS BedrockのCloudTrailログと組み合わせると、さらに強力な証跡管理が実現できます。CloudTrailのイベントデータにはawsRegion（リクエスト発信元）とinferenceRegion（実際の処理リージョン）の両方が記録されるため、SQLクエリで期間を指定して「この期間のすべての推論がUS内で処理されていた」ことを証明するレポートを生成できます。

実際に使えるClaudeプロンプト集――USオンリー推論の設計・運用に活かせるもの

ここでは、USオンリー推論を導入・運用するうえで、Claudeに問い合わせることで実際に役立つプロンプト例を紹介します。これらはClaudeの推論力を活かした、実務的な使い方です。

【プロンプト1コンプライアンス要件の整理と設定方針の策定】

「私たちは医療系SaaSを開発している日本の企業です。顧客の診断補助に使う記録の一部を、Claude APIを使って要約・構造化しようとしています。適用される可能性がある規制要件（HIPAA、日本の個人情報保護法、医療情報システムの安全管理に関するガイドライン）を踏まえ、Claude APIのinference_geoとWorkspace geoをどう設定すべきか、また追加で検討すべきコンプライアンス対策をリストアップしてください。前提として、Anthropic Claude API（1P）を直接使う予定です。」

このプロンプトを使うことで、Claudeは規制の組み合わせを整理したうえで、具体的な設定方針と注意事項を体系的に提示してくれます。コンプライアンス担当者との会議準備に即座に活用できます。

【プロンプト2429エラー対策コードのレビューと改善】

「以下のPythonコードはClaude APIを呼び出す処理ですが、本番環境で429エラーが頻発しています。レート制限ヘッダーの解析・エクスポネンシャルバックオフの実装・Prompt Cachingの活用という3つの観点から、コードを改善してください。また、inference_geo: ‘us’を指定した場合のTPMカウントへの影響（1.1倍として消費されること）を考慮したスロットリング計算ロジックも追加してください。（コードをここに貼る）」

USオンリー推論では1.1倍でTPMが消費されることを考慮したスロットリング計算は、多くのコードレビューで見落とされている盲点です。このプロンプトでClaudeに明示的に依頼することで、この計算が組み込まれた改善コードが得られます。

【プロンプト3Workspace geoとInference geoの設計判断を整理するフレームワーク作成】

「私のチームは複数のプロダクト（BtoB SaaS・内部ツール・R&Dプロジェクト）でClaude APIを使います。それぞれのプロダクトで扱うデータの機密性・規制要件・コスト感度が異なります。Anthropic ConsoleのWorkspace設計（何個のWorkspaceを作るべきか、それぞれにどういうInference geoポリシーを設定すべきか）を判断するためのフレームワークを、意思決定フローチャートの形で提示してください。」

複数チームでClaude APIを使い始めると、Workspaceの設計が後から変えられない（特にWorkspace geo）だけに、最初の設計判断が非常に重要になります。Claudeにフレームワークを作ってもらい、チーム内の合意形成資料として使う方法です。

「グローバルルーティングよりUSオンリーの方がレイテンシが低い」は本当か？

「データをUSで処理するなら、日本から使う場合はグローバルより遅くなるのでは？」という疑問は非常に合理的です。この点について、正確に理解しておく必要があります。

結論から言えば、必ずしもUSオンリーが遅いとは限らないのが実情です。グローバルルーティングは理論上、最も近いリージョンに自動で振り分けるため有利に思えますが、実際には需要の集中によるスロットリングや混雑が発生することがあります。一方、USオンリーに固定することで、インフラが予測可能な状態になります。

Anthropic自身の公式ドキュメントにはUSオンリーとグローバルの具体的なレイテンシ比較データは公開されていません。しかし、AWS Bedrockの事例を参考にすると、地理的な推論プロファイルとグローバルプロファイルのレイテンシ差は、ワークロードのパターン（バースト性が高いかどうか）と時間帯によって大きく変わることがわかっています。

実務上の判断として、レイテンシ要件が厳しい本番ワークロードではまず両方を比較計測することを強くおすすめします。「コンプライアンスのためにUSオンリーにしたら遅くなった」という状況であれば、Anthropicが別途提供しているFast Mode（ベータ、標準料金の6倍）を組み合わせることで、USオンリー推論のレイテンシ課題を緩和できる可能性があります。

費用対効果を最大化するハイブリッド設計のパターン

「全リクエストをUSオンリーにすべきか、必要な部分だけにすべきか」という設計判断は、実際のプロダクション環境では非常に重要です。

現場でよく見られる賢い設計パターンは、データの機密度に応じてinference_geoを動的に切り替える方法です。たとえば、以下のような分類が実用的です。

データの種類	推奨設定	理由
個人情報・医療情報・財務情報を含むリクエスト	inference_geo: “us”	コンプライアンス要件への対応・監査証跡の確保
公開情報の要約・翻訳・コード補完（機密情報なし）	inference_geo: “global”（省略）	コスト最適化・レイテンシの安定性
大量バッチ処理（機密情報の有無が混在）	リクエスト単位でフラグを持ち動的切り替え	コスト効率とコンプライアンスの両立

この設計を実装する際の実務的なアドバイスとして、inference_geoの判定ロジックはAPIコール層ではなくビジネスロジック層に置くことをおすすめします。「このリクエストは機密データを含むか？」という判断は、アプリケーションの上位層で行われるべきで、APIクライアントが知るべき情報ではありません。依存性注入やファクトリパターンを使って、外部から設定を注入できる設計にしておくと、後からポリシーを変更しやすくなります。

ぶっちゃけこうした方がいい！

正直なことを言うと、「とりあえず全部USオンリーにしておけば安全」という発想は、中長期的に見ると賢くない選択です。

理由は3つあります。まず、1.1倍のコストは小さく見えても、大規模なプロダクションでは月に数十万円規模の差になりえます。次に、Anthropicの公式ドキュメントで明言されているように「レート制限はgeoをまたいで共有されている」ため、USオンリーにしたからといってスループットが増えるわけではありません。そして3つ目、コンプライアンスに本気で取り組むなら、inference_geoだけでは不十分で、Workspace geoの設定・ZDR契約・APIレスポンスのinference_geoフィールドを記録するログ設計がセットで必要です。

個人的にこうしたほうがぶっちゃけ楽だし効率的だと思うのは、「機密度フラグを持つデータモデルを最初から設計して、inference_geoはそのフラグから自動決定させる」という設計です。

最初から全部USオンリーで走らせてコストを払い続けるより、「このデータは機密か？」という判断をビジネスロジックに組み込んで、機密なものだけUSオンリーにすればいい。それだけで余分なコストの大半がなくなります。しかも、後からポリシーが変わっても（たとえばEUリージョンが追加されたときや規制対象が変わったときも）、フラグの種類を増やしてinference_geo決定ロジックを書き換えるだけで対応できます。

コードレベルで言えば、「APIクライアントにinference_geoを直接書く」のではなく「リクエストオブジェクトにdata_classificationフィールドを持たせ、APIアダプター層でそれをinference_geoに変換する」という一段の抽象化が、保守性と柔軟性の両方を劇的に高めます。これは一見地味な設計判断ですが、半年後に「やっておいてよかった」と絶対に思える類の判断です。

USオンリー推論をただの「チェックボックス的なコンプライアンス対応」として使うか、「データの機密度に応じた動的なインフラ制御」として設計に組み込むか――その差が、長期的に見た開発コストとコンプライアンス品質の両方を決める、と個人的には確信しています。

USオンリー推論に関する疑問解決

旧モデルを使っている場合、inference_geoを設定したら自動的に新機能が使えるようになりますか？

いいえ。inference_geoパラメータはClaude Opus 4.6以降の新しいモデルにのみ対応しています。Claude Opus 4.5や3系のモデルに対してこのパラメータを指定すると、APIは400エラーを返します。USオンリー推論を利用するには、まずモデル自体をOpus 4.6または対応する新モデルにアップグレードする必要があります。なお、旧モデルは引き続きAnthropicの設定でUSのみの処理が維持されている場合、コードを変更しなくても既存の設定が引き継がれています。

Batch APIでリクエストごとに異なるinference_geoを指定できますか？

はい、できます。Batch APIでは各リクエストが独自のinference_geo値を持つことができます。これにより、同一バッチ内で「機密情報を含むリクエストはUS、そうでないリクエストはグローバル」という使い分けが可能です。大規模なバッチ処理でコスト最適化を図りながら、必要なリクエストだけUSオンリー推論を適用する柔軟な設計ができます。

Priority Tier（優先利用枠）との組み合わせではどう計算されますか？

Priority Tierを利用している場合、inference_geo: “us”を指定したリクエストは、コミット済みTPM（トークン毎分）から1.1トークン分として消費されます。たとえば1,000トークンのリクエストにUSオンリー推論を適用すると、TPMカウンター上は1,100トークン消費したものとして扱われます。これはPrompt Cachingの乗数が適用される場合と同じ考え方です。月次のTPMコミットメントを計画する際は、USオンリー推論の使用割合を考慮してバッファを設けることをおすすめします。

まとめ

ClaudeのUSオンリー推論は、単なる「データをアメリカ国内で処理する」という機能を超えた意味を持っています。それは、規制産業においてAIを本格導入するための信頼の基盤を提供するものです。

料金は標準の1.1倍という追加コストが発生しますが、医療・金融・政府機関での導入障壁が大幅に下がるというビジネス的メリットを考えれば、その価値は十分に正当化できます。特に、コンプライアンス担当者や規制当局への説明責任を果たすために「推論がどこで行われたかをAPIレスポンスで確認できる」という証跡管理の機能は、実務上の大きな差別化要因です。

一方で、コンプライアンス要件がなく純粋にコスト最適化を追求する開発者にとっては、グローバルルーティングのまま運用するのが合理的な判断です。また、EU域内での処理を必要とする場合は、現時点ではAWS BedrockやGoogle Vertex AIのEUリージョンエンドポイントを活用するアプローチが現実的です。

自分のプロジェクトにUSオンリー推論が必要かどうかを判断するシンプルな基準として覚えておいてほしいのは、「データの処理場所を第三者に証明する必要があるか？」という問いです。答えがYESであれば、追加10%のコストは十分に価値のある投資になります。