目次
#1.はじめに
#2.AmazonBedrockの推論方式について
#3.クロスリージョン推論の動作の仕組みや制約
#4.地理的観点でのモデル選定ケース
#5.クロスリージョン推論が前提となっている背景の考察
#6.まとめ
1.はじめに
先日AmazonBedrockの地理的要件に対応するためのクロスリージョン推論や推論プロファイルについて検証を行いました。
上記検証の中で、AmazonBedrockの推論の仕組みや設計におけるモデル選定の観点が分かってきたので、今回は推論の種別をまとめ、地理的観点でのモデル選択の考え方を整理しようと思います。
2.AmazonBedrockの推論方式について
AmazonBedrockでは大きく分けて以下2つの推論方式があります。
- オンデマンド推論(On-Demand Inference)
- バッチ推論(Batch Inference)
オンデマンド推論は同期処理で、リアルタイムシステムに利用されます。
バッチ推論は非同期処理で、大量のプロンプトをジョブ的に処理するときに利用されます。
今回はオンデマンド推論の利用を前提にモデルを選定していきます。バッチ推論に関する詳細は以下AmazonBedrockのドキュメントをご確認ください。
オンデマンド推論を地理的観点で考えると、さらに以下の3パターンの推論方式に分かれます。
- 単一リージョン推論
- 地理的クロスリージョン推論
- グローバルクロスリージョン推論
まず、単一リージョン推論は 公式ドキュメント上で正確な名称は見つけられなかったのですが、シンプルに指定したリージョンで動作する推論です。
例えば東京リージョンのみで推論できるのがこの方式です。
次に地理的クロスリージョン推論はデータ処理を指定された地理的境界 (米国、欧州、APAC など) 内に維持し、複数のリージョンをまたいで動作する推論です。
例えば日本国内といいう地理的境界内に維持する場合は、東京リージョンと大阪リージョンのみで推論できるのがこの方式です。
詳細は以下ドキュメントに記載があります。
最後にグローバルクロスリージョン推論は地理的クロスリージョン推論よりもさらに広い範囲で、地理的境界を超えてクロスリージョン推論を拡張する推論方式です。
例えば日本国内に限らず、複数の国のリージョンで推論できるのがこの方式です。
基本的な動きは地理的クロスリージョン推論と同様です。
動作可能なリージョンが増えるためスループットの観点で行くと以下順序で優れています。
グローバルクロスリージョン推論 > 地理的クロスリージョン推論 > 単一リージョン推論
以下はLambdaで実行確認したサンプルコードとなりますが、モデルの呼び出し方は以下のような違いがあります。
単一リージョン推論:モデルIDを指定
クロスリージョン推論:推論プロファイルとモデルIDを組み合わせて指定
以下コードの地理的クロスリージョン推論では推論プロファイル「JP Anthropic Claude Sonnet 4.5」を指定するために「jp」と記載し、
クロスリージョン推論では推論プロファイル「Global Claude Sonnet 4.5」を指定するために「global」を記載しています。
import boto3
import json
client = boto3.client("bedrock-runtime", region_name="ap-northeast-1")
def lambda_handler(event, context):
response = client.converse(
#単一リージョン推論でClaude 3.5 Sonnetを使用
#modelId="anthropic.claude-3-5-sonnet-20240620-v1:0",
#地理的クロスリージョン推論でClaude Sonnet 4.5を推論プロファイル「JP Anthropic Claude Sonnet 4.5」で使用
#modelId="jp.anthropic.claude-sonnet-4-5-20250929-v1:0",
#グローバルクロスリージョン推論でClaude Sonnet 4.5を推論プロファイル「Global Claude Sonnet 4.5」で使用
modelId="global.anthropic.claude-sonnet-4-5-20250929-v1:0",
messages=[
{
"role": "user",
"content": [{"text": "こんにちは"}]
}
]
)
# Claudeの返答テキストを抽出
answer = response["output"]["message"]["content"][0]["text"]
return {
"statusCode": 200,
"body": json.dumps(
{
"reply": answer
},
ensure_ascii=False
)
}
※ロールに「"Action": "bedrock:InvokeModel",」の許可が必要となるのでご注意ください
3.クロスリージョン推論の動作の仕組みや制約
クロスリージョン推論では、プライマリリージョン(例:東京リージョン)でキャパシティが不足した場合に、
推論プロファイルで指定された他のリージョン(例:大阪リージョン)へ自動フォールバックされます。
ただし、このフォールバックはユーザー側で制御できず、どのリージョンで実際に推論が実行されたかをCloudTrailで確認する方法は現状ありません。
また、推論プロファイルで対象となるリージョンの指定はAWS側で用意されているプロファイルに準拠しているため、ユーザ側で自由に使用するリージョンを指定したり、既存の推論プロファイルで指定されているリージョンから減らすことはできません。
ユーザが作成する推論プロファイルとしてアプリケーション推論プロファイルがありますが、これはコストとモデルの使用状況を追跡するためにユーザーが作成するもので、既存の推論プロファイルをベースにする必要があり、リージョンを自由に選択することはできません。
https://docs.aws.amazon.com/ja_jp/bedrock/latest/userguide/inference-profiles.html
4.地理的観点でのモデル選定ケース
ケース1「特定のリージョン内で推論を行う必要がある」
本ケースは、データ越境が明確に禁止されているシステムを想定します。
代表例としては金融、公共、医療系システムなどが挙げられます。
採用方式
- 単一リージョン推論
モデル例
- Claude 3.5 Sonnet
メリット
- データが物理的に単一リージョン内に限定される
- 監査対応や顧客説明が明確
- 実行リージョンが確定するため、ガバナンス設計が容易
特にクロスリージョン推論では実際にどのリージョンで推論が実行されたかをユーザーが確認できない点を考慮すると、監査証跡が厳格に求められるシステムでは単一リージョン推論の方が説明可能性が高いと言えます。
デメリット
- ピーク時のキャパシティ不足リスク
- 単一リージョンで災害発生した場合のリスク
- 現状最新モデルが利用できない
近年のモデルはクロスリージョン前提で提供されるケースが増えており、
単一リージョン対応モデルは将来的に縮小していく可能性があります。
ケース2「特定の地理的境界内で推論を行う必要がある」
本ケースは、輸出に厳格なシステムを想定します。
代表例としては防衛・軍事関連、エネルギー、研究系のシステムなどが挙げられます。
採用方式
- 地理的クロスリージョン推論
モデル例
- Claude Sonnet 4.5
メリット
- データが地理的境界内に限定される
- 輸出管理が不要
デメリット
- 地理的境界内で災害が発生するリスク
- 要件にあった地理的境界内で動作する推論プロファイルの存在が前提
「Claude 3.7 Sonnet」や「Claude Sonnet 4」はクロスリージョン推論のモデルですが、日本国内に閉じたクロスリージョンができませんでした。
しかし、「Claude Sonnet 4.5」ではリリースと同時に日本国内に閉じた推論プロファイルが提供されており、今後はこの方式がスタンダードになっていくものと想定されます。
ケース3「特に地理的制約がない」
このケースは地理的観点ではどの推論方式のモデルを選んでも問題ありません。
その他の要件(料金、モデルの性能等)でモデルを選択することになりますが、スループットや冗長性を高いレベルで担保したい場合は、グローバルクロスリージョン推論が利用できるモデルを選択します。
5.クロスリージョン推論が前提となっている背景の考察
先日公開された「Claude Sonnet 4.6」も含め、最近よく利用されているモデルはクロスリージョン推論が前提となっています。
あくまで私の推測となりますが、生成AIの需要が増加し続けている現状で、単一リージョン推論を前提としてしまうと、ピークタイミングで運用が耐え切れなくなってしまうため、基盤的にリージョンをまたぐことを前提にしたいのかなと考えています。
ただし、輸出管理やデータガバナンスの観点で地理的境界内での推論を行う要件があり、複数パターンの推論プロファイルが登場していっているものと思われます。
個人的には今後はユーザが任意に利用するリージョンを選択することができれば、もっと自由度が高まると思いますので、推論プロファイルを任意に作成できるようになってほしいです。
6.まとめ
今回は地理的観点からAmazonBedrockのモデル選定方法を検討してみました。
実際のモデル選定ではモデルの特性、コストなどほかにも要件を考慮する必要がありますが、
誰かの参考になれば嬉しいです。