室谷代表取締役これはデータの扱いを最優先にしてきた現場にとって、かなり大きいニュースなんですよね。AWSが、Amazon BedrockでAnthropicのClaudeモデルを、韓国・ソウルとシンガポールのリージョン内推論で使えるようにしたと発表しました。
対象はソウルがClaude Opus 5とClaude Sonnet 5、シンガポールがClaude Sonnet 5です。
対象はソウルがClaude Opus 5とClaude Sonnet 5、シンガポールがClaude Sonnet 5です。
テキトー教師DotAI 認定講師これ、単に「対応リージョンが増えました」という話じゃないんですよ。AWSの説明で効いているのは、推論リクエストもデータも、呼び出したリージョン内で処理され、そのリージョンの外に出ていかないという点です。
韓国やシンガポールでローカルのデータ処理要件を抱えている現場、たとえば金融サービス、医療、公共部門でも、これらのAnthropicモデルをスケールで使えるようになった、と。
韓国やシンガポールでローカルのデータ処理要件を抱えている現場、たとえば金融サービス、医療、公共部門でも、これらのAnthropicモデルをスケールで使えるようになった、と。
室谷代表取締役そこなんですよね。MYUUUでも「モデルは使いたい、でもデータを国外に出せない」という相談は本当に多くて、これまでは要件の確認と選択肢のすり合わせから設計が始まっていたんです。
それが「ソウルのリージョン内で完結する」という前提で組めるようになると、提案の出発点そのものが変わるんですよ。
それが「ソウルのリージョン内で完結する」という前提で組めるようになると、提案の出発点そのものが変わるんですよ。
テキトー教師DotAI 認定講師講座でも受講生さんから「クラウドのリージョンって、どこまで気にすればいいんですか」とよく聞かれます。今回の話はそのど真ん中で、リージョンを選ぶことが、そのままデータの扱いを決めるという構造になっています。
室谷代表取締役しかも今回はコンソールから試せて、APIからも呼べる。PoC（検証）のハードルが下がっているのも良いところですよね。
リージョン内推論とは？クロスリージョン推論プロファイルとの違いを整理
リージョン内推論 vs クロスリージョン推論プロファイル
| 観点 | リージョン内推論 | クロスリージョン推論プロファイル |
|---|---|---|
| ルーティング層 | なし（指定リージョン単独で処理） | あり（複数リージョンに振り分け） |
| データの扱い | ライフサイクル全体で同一リージョンに留まる | 別リージョンにデータが渡り得る |
| スループット | そのリージョンのキャパシティに縛られる | 可用性・スループットを高めやすい |
| 監視 | クォータ・メトリクス・ログが同一リージョンにスコープ | 送信元と送信先の区別を考慮する必要がある |
テキトー教師DotAI 認定講師ここで用語を整理しておきたいんですよ。リージョン内推論とクロスリージョン推論プロファイルは、名前は似ていますが仕組みがはっきり違います。
室谷代表取締役そうですね、まず並べて見たほうが早い。整理するとこうです。
| 観点 | リージョン内推論 | クロスリージョン推論プロファイル |
|---|---|---|
| ルーティング層 | なし。指定したリージョン単独で処理 | あり。複数リージョンに処理を振り分け |
| データの扱い | 入力プロンプトと出力結果がリクエストのライフサイクル全体を通じて同一リージョンに留まる | 別のリージョンにデータが渡り得る |
| スループット | そのリージョンのキャパシティに縛られる | 可用性やスループットを高めやすい |
| 監視 | クォータ消費、CloudWatchメトリクス、CloudTrailログが同一リージョンにスコープ | 送信元と送信先の区別を考慮する必要がある |
室谷代表取締役これ、いちばん実務で効くのは最後の行なんですよね。監視のときに「送信元と送信先の区別を考えなくていい」というのは、運用設計がかなりシンプルになるということなので。
テキトー教師DotAI 認定講師逆にトレードオフもはっきりしています。スループットがそのリージョンのキャパシティに縛られ、リクエストはリージョンごとのサービスクォータの対象になります。
クロスリージョン推論プロファイルのように複数リージョンへ逃がして可用性を稼ぐ、という設計はできないわけです。
クロスリージョン推論プロファイルのように複数リージョンへ逃がして可用性を稼ぐ、という設計はできないわけです。
室谷代表取締役だから「常にリージョン内推論が正解」ではなくて、単一リージョンでの厳格なデータ処理が必要な案件で使う、というのがAWSの説明の立て方なんですよ。データレジデンシーが最優先のワークロードか、可用性とスループットが最優先のワークロードか。
そこを最初に切り分けることになります。
そこを最初に切り分けることになります。
テキトー教師DotAI 認定講師単に「新しい選択肢ができた」話じゃないんですよね。選び分けの基準が一つ増えた、というのが正確な理解だと思います。
対象となるClaudeモデルと利用リージョン——ソウルはOpus 5とSonnet 5、シンガポールはSonnet 5
リージョン別に利用できるClaudeモデル
| リージョン | アジアパシフィック（ソウル） | アジアパシフィック（シンガポール） |
|---|---|---|
| リージョンコード | ap-northeast-2 | ap-southeast-1 |
| Claude Opus 5 | ○ | × |
| Claude Sonnet 5 | ○ | ○ |
室谷代表取締役対象を整理しておきますね。ソウルとシンガポールで、使えるモデルが違うんですよ。
テキトー教師DotAI 認定講師ええ、表にするとこうです。
| リージョン | リージョンコード | 対象モデル |
|---|---|---|
| アジアパシフィック（ソウル） | ap-northeast-2 | Claude Opus 5、Claude Sonnet 5 |
| アジアパシフィック（シンガポール） | ap-southeast-1 | Claude Sonnet 5 |
室谷代表取締役シンガポールはSonnet 5のみ、ソウルはそれに加えてOpus 5も使える、という構成なんです。なので「ソウルで試してからシンガポールに展開する」ときに、モデルの選択肢が変わる点は頭に入れておいたほうがいいですよね。
テキトー教師DotAI 認定講師呼び出し方は、bedrock-runtimeエンドポイントに対して直接モデルIDを指定します。たとえば
AWSは新しいアプリケーションにはbedrock-runtimeエンドポイントを推奨しています。
anthropic.claude-opus-5、anthropic.claude-sonnet-5 といった形です。AWSは新しいアプリケーションにはbedrock-runtimeエンドポイントを推奨しています。
室谷代表取締役ここ、地味に大事なポイントで。認証やエンドポイントの設計を後から変えるのは手間なので、新規で作るなら素直にbedrock-runtimeで組んでおくのがいいですね。
なぜ金融・医療・公共部門で重要か——データが域外に出ないことの意味
データ所在を説明できるかが導入検討の分岐点
プロンプトと結果がリクエストのライフサイクル全体を通じてそのリージョンに留まる、と言い切れるか
YES ／ 言い切れる
- データ所在を説明できる
- 導入の前提条件を満たす
- 監査に耐える形で「どこで処理されたか」を示せる
- 稟議が通りやすい／検討のテーブルに乗る
NO ／ 言い切れない
- データ所在を説明できない
- そもそも検討のテーブルに乗らない
- モデルの精度が良くても要件を満たさない
テキトー教師DotAI 認定講師なぜ金融、医療、公共部門でこの発表が重いのか。理由はシンプルで、データを域外に出せないという制約が、AI導入の最初の壁になるからです。
どれだけモデルが良くても、データの所在が説明できなければ、そもそも検討のテーブルに乗らない。
どれだけモデルが良くても、データの所在が説明できなければ、そもそも検討のテーブルに乗らない。
室谷代表取締役まさにそこです。MYUUUでも、要件として先に来るのは精度の話ではなくデータの所在なんですよね。
「プロンプトと結果がリクエストのライフサイクル全体を通じてそのリージョンに留まる」と言い切れるかどうかで、稟議の通り方が変わるんですよ。
「プロンプトと結果がリクエストのライフサイクル全体を通じてそのリージョンに留まる」と言い切れるかどうかで、稟議の通り方が変わるんですよ。
テキトー教師DotAI 認定講師AWSの説明でも、厳格な単一リージョンのデータ処理が必要なときにこれを使う、という位置づけになっています。データレジデンシー要件を満たすための手段として提供されている、というのが公式の言い方です。
室谷代表取締役しかも今回は「スケールで使える」という言い方なんですよね。PoCだけではなく、本番の業務フローに載せていく前提の話になっている。
ここが発表の温度感として大きいと思います。
ここが発表の温度感として大きいと思います。
テキトー教師DotAI 認定講師個人向けツールの進化も速いですが、法人の要件はまた別の話です。その違いはChatGPT長期記憶のすべて：進化、使い方、注意点をプロが解説でも触れているような「便利さの話」とはレイヤーが違っていて、法人は便利さの前に説明責任を求められますからね。
室谷代表取締役そうそう。監査に耐える形で「どこで処理されたか」を言えることが、導入の前提条件になる。
今回のアップデートは、その前提条件を満たす選択肢がソウルとシンガポールに増えた、という理解でいいと思います。
今回のアップデートは、その前提条件を満たす選択肢がソウルとシンガポールに増えた、という理解でいいと思います。
使い方：BedrockコンソールとAPI（Converse・InvokeModel・Anthropic Messages）で始める手順
テキトー教師DotAI 認定講師では始め方です。まずコンソールから、コードもSDKのセットアップもなしで試せます。
手順はこうです。
手順はこうです。
室谷代表取締役整理するとこうですね。
- 使いたいリージョンをソースとしてAmazon Bedrockコンソールを開く
- ナビゲーションペインのTestの下にあるPlaygroundを選ぶ
- ページ中央の「Select model」を選ぶ
anthropic.claude-opus-5を検索し、InferenceでOn-Demandを選んでApplyを押す- プロンプトを入力してRunを選ぶと応答が生成される
テキトー教師DotAI 認定講師テキストプレイグラウンドなので、プロンプトを送って推論パラメータを調整し、バリアントを切り替えて各モデルの感触を確かめてからAPI連携に進む、という流れが取れます。
室谷代表取締役コードを書く前にまず触ってみる、という順番は本当に大事で。この「まず触って理解する」流れは、NotebookLMで読書が変わる？ AIと深く読む新しい方法で紹介しているような、ツールを手で確かめてから業務に落とす進め方と同じなんですよね。
テキトー教師DotAI 認定講師API側では、Amazon Bedrock Converse API、InvokeModel API、そしてAnthropicのMessages APIが使えます。つまりAnthropicのMessages APIの書き方を持ち込みたいチームも、BedrockのネイティブAPIで揃えたいチームも、どちらでも組めるということです。
室谷代表取締役ここは実装チームによって好みが分かれるところなので、両方サポートされているのは助かりますよね。既存のAnthropic向けコードを活かしつつ、Bedrockの機能を足していく、という現実的な移行も取りやすい。
テキトー教師DotAI 認定講師あわせて、Amazon Bedrock Guardrailsやintelligent prompt routingといったBedrock側の機能も組み合わせられる、と案内されています。ガバナンスを効かせたい金融・公共の案件では、ここが効いてきます。
bedrock-runtimeエンドポイントの仕組みと押さえるべき制約・注意点
室谷代表取締役最後に、押さえておくべき制約を整理しておきたいんですよね。仕組みとしては、bedrock-runtimeに対して直接モデルIDで呼び出す。
ルーティング層がないので、ソウル（ap-northeast-2）やシンガポール（ap-southeast-1）に送ったリクエストは、そのリージョン単独で処理されます。
ルーティング層がないので、ソウル（ap-northeast-2）やシンガポール（ap-southeast-1）に送ったリクエストは、そのリージョン単独で処理されます。
テキトー教師DotAI 認定講師その代わりに、という条件がいくつか付きます。箇条書きにするとこうです。
- スループットはそのリージョンのキャパシティに縛られる
- リクエストはリージョンごとのサービスクォータの対象になる
- 課金は呼び出したリージョンの標準のオンデマンド料金に従う
- クォータ消費、CloudWatchメトリクス、CloudTrailログはすべて同一リージョンにスコープされる
- 監視において送信元と送信先の区別を考慮する必要がない
室谷代表取締役クォータとキャパシティの話は、本番設計では必ず効いてきます。クロスリージョン推論プロファイルなら複数リージョンに逃がせた処理を、単一リージョンに閉じ込めるわけですから、ピーク時の余力をどう見積もるかは最初に検討しておくべきなんですよね。
テキトー教師DotAI 認定講師逆に、監視がシンプルになるのは運用チームにとっては大きな利点です。メトリクスもログも同じリージョンに揃うので、ダッシュボードやアラートの設計がそのまま素直に作れます。
室谷代表取締役あと、こういう制御系の話になると必ず出てくるのが、ポリシーと警告の扱いです。AI利用時の警告やアカウント制限まわりはChatGPT警告の種類と対処法 – プロンプトブロックからアカウント停止まででも整理していますが、法人利用では「何を検知して、どう記録するか」を先に決めておく必要があります。
Guardrailsが使えるなら、そこは設計に組み込んでおきたいところです。
Guardrailsが使えるなら、そこは設計に組み込んでおきたいところです。
テキトー教師DotAI 認定講師まとめると、リージョン内推論は「データの所在を最優先にする」ための選択肢で、代わりにスループットとクォータが単一リージョンの範囲に収まる。このトレードオフを理解したうえで、ワークロードごとにリージョン内推論とクロスリージョン推論プロファイルを使い分ける、というのが現実的な落としどころですね。
室谷代表取締役そうなんですよね。ソウルとシンガポールでClaudeがリージョン内推論に対応したことで、データを域外に出せない現場に選択肢が増えた。
まずはコンソールのPlaygroundで触って、対象モデルとリージョンの違いを確かめてから、本番の設計に進むのがおすすめです。
まずはコンソールのPlaygroundで触って、対象モデルとリージョンの違いを確かめてから、本番の設計に進むのがおすすめです。
よくある質問
Q. ソウルとシンガポールで使えるモデルは同じですか？
同じではありません。ソウル（ap-northeast-2）はClaude Opus 5とClaude Sonnet 5、シンガポール（ap-southeast-1）はClaude Sonnet 5が対象です。
Q. リージョン内推論とクロスリージョン推論プロファイルはどう使い分けますか？
厳格な単一リージョンでのデータ処理が必要な場合はリージョン内推論を使います。ルーティング層がなく、リクエストは指定したリージョン単独で処理され、入力プロンプトと出力結果はリクエストのライフサイクル全体を通じてそのリージョンに留まります。一方で、スループットはそのリージョンのキャパシティに縛られ、リクエストはリージョンごとのサービスクォータの対象になります。
Q. データが域外に出ないとは、どこまで保証されますか？
AWSの説明では、Amazon Bedrockは推論リクエストとデータを呼び出したリージョン内で処理し、その処理はリージョンから出ません。ルーティング層を介さず、入力プロンプトと出力結果がリクエストのライフサイクル全体を通じて同一リージョンに留まる、という整理です。
Q. 料金はどうなりますか？
課金は、呼び出したリージョンの標準のオンデマンド料金に従うと説明されています。個別の価格水準については、現時点のこの発表では明らかにされていません。
Q. どのAPIで呼び出せますか？
bedrock-runtimeエンドポイントに対して、直接モデルIDを指定して呼び出します。AnthropicのMessages API、Amazon BedrockのInvokeModel API、Converse APIに対応しています。あわせてAmazon Bedrock Guardrailsやintelligent prompt routingといった機能も組み合わせられます。
Q. コンソールから試すのにコーディングは必要ですか？
必要ありません。Amazon Bedrockコンソールのテキストプレイグラウンドで、プロンプトの送信、推論パラメータの調整、バリアントの切り替えができます。SDKのセットアップも不要です。
Q. 監視の設計は変わりますか？
クォータ消費、Amazon CloudWatchメトリクス、AWS CloudTrailのログエントリは、いずれも同じリージョンにスコープされます。監視において送信元と送信先の区別を考慮する必要がないため、クロスリージョン推論プロファイルを使う場合と比べて構成がシンプルになります。
