Grok 4.3がAmazon Bedrockに — OpenAI SDKをほぼそのまま寄せる移行と、reasoning effort・1Mコンテキストの使いどころ
xAIのreasoning-firstモデルGrok 4.3がAmazon Bedrockで利用可能になりました。OpenAI互換API(Chat Completions/Responses)を新エンジンMantle経由で呼べるため、既存のOpenAIコードはOPENAI_BASE_URLの差し替えでほぼそのまま寄せられます。一方でConverse/Invokeは非対応。reasoning effort×プロンプトキャッシュのコスト設計、GuardrailsをApplyGuardrailでラップする方法、モデルデプロイアカウント隔離によるデータの取り扱い、us-west-2のみ・日本未提供といった制約を、AWSフリーランス実務目線で整理します。料金やリージョンは公式の最新情報もご確認ください。
- #Grok
- #Amazon Bedrock
- #生成AI
- #OpenAI互換
- #LLM
- #reasoning
OpenAI の API で生成 AI アプリを書いてきたものの、業務データの取り扱いやコストの都合で AWS 側に寄せたい——そんな相談を受けることが増えました。2026年6月15日、その選択肢に関わる発表がありました。xAI の Grok 4.3 が Amazon Bedrock で利用できるようになった、というものです。Grok 4.3 は推論を中心に据えた reasoning-first（複雑な思考を要するタスクを得意とする設計）のモデルで、コンテキスト（一度に扱える文脈量）は最大100万トークンに対応します。
この記事では、既存の OpenAI コードをどれだけそのまま寄せられるのか、reasoning effort と100万トークンの長文をどう使い分けるのか、コスト設計とデータの取り扱い、そしてリージョンの制約まで、実装目線で整理してみましょう。性能の優劣やランキングは扱いません。なお現時点では us-west-2（オレゴン）のみで、東京・大阪などの日本リージョンでは提供されていません。煽らず、断定できないところは正直に「公式をご確認ください」と書きます。
背景：Bedrockのマルチモデル戦略とxAI参入
Amazon Bedrock は、複数の基盤モデルをひとつの基盤からまとめて使えるマルチモデルのサービスです。Anthropic の Claude や Meta の Llama などが選べるところに、今回 xAI の Grok が新しい選択肢として加わった、という位置づけです。
モデルは今後も増えます。だからこそ、特定のモデルに深く依存せず、用途やコスト、データ要件に応じて選び替えられる実装にしておくと実務で効いてきます。Grok 4.3 も「選択肢のひとつ」として、どんな時に向くのかを冷静に見ておきましょう。
Grok 4.3とは：1Mコンテキスト・reasoning effort・提供状況
まず仕様を押さえます。コンテキストは最大100万トークンで、長い文書をまとめて読ませる用途に向きます。入力はテキストと画像、出力はテキストです。
特徴的なのが reasoning effort（推論にどれだけ手間をかけるか、という強さの設定）です。推論は常時オンで、reasoning パラメータに none（無効）／low（デフォルト）／medium／high を指定して切り替えます。たとえば {"effort":"high"} のように渡します。effort を上げるほど思考の量が増え、後述するように出力コストに効いてきます。
提供状況も正確に。発表では「now available（利用可能）」とされ、ライフサイクルは「Active」、プレビュー表記はありません。一般提供として扱える状態だと読めます（プレビュー段階の AWS Blocks や FinOps Agent とは異なる点です）。ただし AWS が「generally available」の明示語を使っているかは断定せず、「2026年6月15日に利用可能として発表・ライフサイクル Active」という事実として捉えておくのが安全です。
OpenAI互換でBedrockに寄せる：MantleとOPENAI_BASE_URLの差し替え
ここが実装の本題のひとつです。Grok 4.3 は OpenAI 互換 の API（Chat Completions と Responses）で呼び出せます。OpenAI 互換とは、OpenAI の API と同じ形式でリクエストできる、という意味です。呼び出しは Bedrock の新しいエンジン Mantle（bedrock-mantle.{region}.api.aws/openai/v1 というエンドポイント）を経由します。モデル ID は xai.grok-4.3 です。
実装上のうれしさは、OpenAI Python SDK の OPENAI_BASE_URL と API キーを差し替えるだけで、既存コードをほぼそのまま寄せられる点です。ツール呼び出し・構造化出力・ストリーミングにも対応します。ただし既定パラメータが OpenAI 標準と一部違い、temperature=0.7／top_p=0.95／max_completion_tokens=131072 になっている点は確認しておきましょう。
API の選び方にも実装差があります。Responses API では include: ["reasoning.encrypted_content"] を渡すと、推論トークン（モデルが考える過程のトークン）を取得して次のターンに引き継げます。一方 Chat Completions API は推論トークンを返しません。コストの可視化や、マルチターンで推論の文脈を保ちたい場合は Responses API を選ぶ、という判断になります。
Converse非対応の落とし穴と、GuardrailsをApplyGuardrailで当てる
OpenAI 互換で楽に寄せられる反面、注意点があります。Bedrock 従来の Converse / Invoke というパスには非対応です。これらを前提にした Bedrock 標準の抽象（統一的なクロスリージョン推論や、Converse 統合のツール・ガードレールなど）は、そのままの形では使えません。何が使えて何は使い方が変わるのか、整理します。
| 機能・パス | Grok 4.3 で | 補足・代替 |
|---|---|---|
| OpenAI互換 API（Chat Completions / Responses） | 使える | Mantle 経由。OPENAI_BASE_URL 差し替えで移行 |
| ツール呼び出し・構造化出力・ストリーミング | 使える | OpenAI 互換の範囲で対応 |
Converse / Invoke | 使えない | OpenAI 互換パスへ寄せる必要がある |
| Converse統合（インライン）の Guardrails | 使えない | 代わりに ApplyGuardrail でラップ（下記） |
| 推論トークンの取得・引き継ぎ | Responses のみ | Chat Completions は返さない |
Guardrails について補足します。Guardrails は、入力や出力に有害表現や禁止トピックがないかを検査する安全機構です。Grok は Converse 非対応なので、呼び出しに guardrailConfig を埋め込むインライン統合は使えません。ただし、ApplyGuardrail という API は基盤モデルの呼び出しから完全に分離（decoupled）されていて、任意のテキストを単独で検査できます。つまり、Grok を呼ぶ前に入力を ApplyGuardrail で検査し、応答が返ってきたら出力を再び ApplyGuardrail で検査する、というように前後で自前にラップすれば、Guardrails を適用できます。「インライン統合は不可だが、ApplyGuardrail でラップすれば適用できる」と覚えておくとよいでしょう。エージェントの各ステップに軽量な検査を挟みたい場合は、リソース不要で呼べる Bedrock Guardrails の新API（InvokeGuardrailChecks） も選択肢になります。
コスト設計：reasoning effort × プロンプトキャッシュ
コストは、料金表の数字を眺めるより、2つのつまみで考えると設計しやすくなります。まず料金です（us-west-2・標準オンデマンド・2026年6月17日時点の参考値）。
| 項目 | 料金（100万トークンあたり） |
|---|---|
| 入力 | $1.25 |
| キャッシュ入力 | $0.20 |
| 出力 | $2.50 |
1つ目のつまみは reasoning effort です。effort を上げると推論トークンが増え、出力（$2.50）のコストに効きます。2つ目は プロンプトキャッシュです。これは繰り返し使う長文の文脈を一度キャッシュに乗せておき、次回以降は安いキャッシュ入力（$0.20）で再利用する仕組みで、標準入力（$1.25）のおよそ6分の1です。100万トークンの長文や、同じ前提を何ターンも使い回す対話で効いてきます。
骨子は「精度が要る所だけ effort を上げ、繰り返す長文の文脈はキャッシュに乗せる」です。月額は利用形態次第なので具体的な金額は断定せず、試算は前提を置いて幅で考えてください。料金は改定され得るので、必ず公式の最新料金ページでご確認ください。なお Priority・Flex・Batch といった他ティアの単価は、現時点では料金ページに標準オンデマンドのみ掲載で、それ以外は公式でのご確認が必要です。
モデルが増え続ける前提では、Grok を選ぶ／選ばないは「用途（推論の重さ・長文の有無）× コスト × コンテキスト長 × リージョン × データの取り扱い」で判断するのが現実的です。長文の推論を安定して回したい、OpenAI コードを寄せたい、という条件がそろうなら有力候補になります。
業務で使えるか：データの取り扱い・リージョン・採用判断
業務で使えるかを左右するのが、データの取り扱いです。ここは強めの事実があります。Bedrock には モデルデプロイアカウント隔離 という仕組みがあり、モデル提供元ごとの実行環境を AWS 側のアカウントで隔離して運用しています。この設計により、提供元である xAI は、顧客のプロンプトや出力、Bedrock のログにアクセスできません。推論は AWS 内で実行され、xAI の外部システムにリクエストが送られる構造ではありません。受託で顧客の生成 AI を AWS に載せる場面では、これは重要な判断材料になります。
ひとつ誠実にお伝えしておきます。上記の「提供元がアクセスできない」隔離は確認済みの事実ですが、Grok 個別の「顧客データを学習に使わない」といった条項は、AWS の第三者モデル規約ページに現時点では掲載されていません（Anthropic などは明記があります）。隔離による提供元アクセス不可は事実として書けますが、Grok 固有の学習利用に関する文言は、公式の追補をご確認ください。
リージョンと制約も整理します。現状は us-west-2 のみ・In-Region 限定（クロスリージョン推論は非対応）で、日本リージョンは未提供、拡大予定も未公表です。最大出力は既定で max_completion_tokens=131072 ですが、固定の上限値は公式に明示されておらず、アカウントやリージョンのクォータ（割り当て上限）に依存し、必要なら引き上げを申請する形になります。
まとめ
ポイントを3つに絞ります。
- Grok 4.3 は Bedrock で使える100万トークン・reasoning 系のモデルで、OpenAI 互換（Mantle 経由）により既存コードを
OPENAI_BASE_URL差し替えで寄せやすいのが実装上の利点です。ただしConverse/Invoke非対応は要注意で、Guardrails はApplyGuardrailでラップして当てます。 - コストは reasoning effort × プロンプトキャッシュの2つのつまみで設計します。精度が要る所だけ effort を上げ、再利用する長文はキャッシュ（$0.20）に乗せるのが骨子です。
- データは xAI から隔離される一方、現状は us-west-2 のみ・日本未提供で、Grok 固有の学習利用条項は公式の追補待ちです。採否は自分の要件で判断し、料金・リージョンは公式の最新情報をご確認ください。
Grok を実際にアプリへ組み込む際は、エージェントの基盤モデルとして据える Amazon Bedrock AgentCore や、Bedrock を下回りに使う AWS Blocks の Agent／KnowledgeBase とあわせて読むと、モデル選択肢としての位置づけが見えてきます。OpenAI から Bedrock への移行、reasoning のコスト設計、データガバナンスを一通り語れると、受託の生成 AI 案件で評価されやすい領域だと感じています。