xAIのGrok4.3がAmazon Bedrockに登場

本記事は、xAI（SpaceXAI）の Eric Jiang 氏との共著です。

xAI の「Grok 4.3」が Amazon Bedrock で一般利用可能になりました。これにより、エージェントや AI ワークフローを構築するチームは、長い入力に対しても確実な推論が可能になるモデルを利用できるようになります。今回のリリースで xAI は、Amazon Bedrock のモデルプロバイダーとして加わりました。

Grok 4.3 は、推論の強度をユーザーが設定できるのが特徴です。エージェント構築には強力なツール利用機能と指示従順性を持ち、大量の推論処理にはトークン効率の高さを備えています。テキストと画像の入力に対応し、100 万トークンのコンテキストウィンドウ（文脈窓）を持つため、長文ドキュメントや複数回の対話セッションもスムーズに扱えます。このモデルは、Amazon Bedrock の次世代推論エンジン「Mantle」上で動作します。

本記事では、Grok 4.3 がなぜエージェントワークロードやエンタープライズ用途に適しているのか、Amazon Bedrock を通じたアクセス方法、そして多くのチームが最初に活用する機能の使い方について解説します。具体的には、基本的なチャットリクエスト、推論強度のカスタマイズ、ツール呼び出し、構造化出力、画像入力、状態を保持した複数回の対話（ステートフル・マルチターン会話）などです。

なぜ Grok 4.3 はエージェント型・推論タスクに最適なのか

xAI によれば、Grok 4.3 は精度が求められるエンタープライズ用途のために設計されています。モデル発表当時の独自ベンチマークでは、業界標準を凌駕する結果を示しました。

特に注目すべきは、AI 分析サイト「Artificial Analysis」のオムニシェンス（Omniscience）ベンチマークで、比較対象となった最先端モデルの中で最も低い幻覚率（ハルシネーション率）を記録し、1 位を獲得した点です。また、カスタマーサポートにおけるツール呼び出し能力では「Tau2 Telecom」ベンチメントで 1 位に輝き、ドキュメント理解の分野でも「Vals AI Case Law」および「Corporate Finance」ベンチメントで首位となりました。

さらに xAI は、このモデルを「知能対コストのパレートフロンティア（最適解の境界線）」上に位置づけています。これは、他の最先端モデルと比較して、1 ドルあたりの知能が 2 倍から 10 倍高いことを意味します。

Grok 4.3 では、各リクエストごとに「思考の深さ」を調整する effort レベルを設定できます。none（なし）、low（低）、medium（中）、high（高）から選べるため、1 つのモデルで幅広いタスクをカバー可能です。

例えば、レイテンシが重要な分類処理には none を設定し、契約書分析や判例調査など、回答の質が時間より優先されるタスクには high を指定できます。Grok 4.3 はテキストと画像を入力として受け付け、テキストで応答します。100 万トークンという広大なコンテキストウィンドウにより、長文ドキュメントや多段階の対話セッションもスムーズに処理可能です。

ツール呼び出しや指示の忠実な実行にも優れており、関数呼び出しを通じてアクションを実行するエージェントの実装に適しています。契約レビュー、与信条件書の分析、金融文書への質問応答といったユースケースで威力を発揮します。これらのタスクでは、長文の入力に対して推論を行い、その結果をレコードシステム（記録管理システム）へ連携させることが可能です。

Amazon Bedrock での Grok 4.3 アクセス方法

Grok 4.3 は Mantle プラットフォーム上で動作します。Amazon Bedrock Runtime API を利用する他のモデルとはアクセス方法が異なります。Mantle では OpenAI と互換性のある API が採用されています。

したがって、Grok 4.3 の呼び出しは、OpenAI SDK を使用するか、Chat Completions API または Responses API に対して直接 HTTPS リクエストを送信することで実行できます。

Mantle のエンドポイント URL はリージョン固有であり、以下のパターンに従います：

例えば、us-west-2 リージョンにおける基本 URL は https://bedrock-mantle.us-west-2.api.aws/openai/v1 です。Mantle エンドポイントでは、Responses API の URL ルートが Runtime エンドポイント（/v1/responses）とはわずかに異なり、/openai/v1/ となっています。

Grok 4.3 を SDK で設定する際は、前述のセクションで説明した通り、適切なリージョンとパスを含む基本 URL を指定してください。

Grok を利用する際、コンテキストウィンドウは 100 万トークンである点に留意してください。また、デフォルト値が標準的な OpenAI の仕様とは以下の 3 つの点で異なります。

• temperature は 1.0 ではなく 0.7 がデフォルトです。
• top_p は 1.0 ではなく 0.95 がデフォルトです。
• max_completion_tokens は 131072 に設定されています。

アプリケーションの要件に応じて、これらのパラメータは明示的に指定してください。

認証と最初のリクエスト実行

Mantle エンドポイントへの認証には 2 つの方法があり、どちらも同じ OpenAI SDK で動作します。本番環境では、IAM クレデンシャルから生成した短期間のベアラートークンを利用することを推奨します。これは自動で期限切れとなり、アクセス権限を IAM アイデンティティに紐付けられるためです。一方、クイックな探索や入門用には、長期有効な Amazon Bedrock API キーを使用できます。ただし、長期キーはあくまでその目的に限定し、本番アプリケーションのコードに埋め込むことは避けてください。

以下の例は、長期有効な Amazon Bedrock API キーを使用してモデルにアクセスするための認証方法を示しています。このキーはあくまで探索目的の資格情報として扱ってください。

Amazon Bedrock コンソール から API キーを生成 した後、OpenAI SDK をインストールします。

pip install openai

クライアントをリージョンごとの Mantle エンドポイントに指向させ、API キーで認証を行います。モデル ID は xai.grok-4.3 です。

from openai import OpenAI

client = OpenAI(
    api_key="",
    base_url="https://bedrock-mantle.us-west-2.api.aws/openai/v1",
)

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[
        {"role": "user", "content": "Amazon Bedrock を一言で説明してください。"}
    ],
)
print(response.choices[0].message.content)

アプリケーションへの組み込みにおいて、より高いセキュリティ要件が求められる場合は、短期有効な資格情報の使用を推奨します。既存の AWS 認証情報を用いて、リクエスト時に Amazon Bedrock トークンジェネレーター で短期有効なベアラートークンを生成できます。これにより、認証を IAM アイデンティティに紐付け、長期秘密鍵の使用を防ぐことができます。

まずは aws-bedrock-token-generator パッケージをインストールしてください。

pip install aws-bedrock-token-generator

以下のコードのように、aws_bedrock_token_generator ライブラリから provide_token 関数を使用してトークンを取得します。

from aws_bedrock_token_generator import provide_token
from openai import OpenAI

client = OpenAI(
    api_key=provide_token(region="us-west-2"),
    base_url="https://bedrock-mantle.us-west-2.api.aws/openai/v1",
)

推論出力の設定

Responses API の reasoning パラメータを用いて、モデルが推論に費やすリソースの量を制御できます。設定できるレベルは以下の通りです。

• none: 推論機能を無効化します
• low（デフォルト）: 標準的な推論 effort
• medium: より深い推論
• high: 最も高い推論 effort

多段階の複雑な問題において、即座に答えを出すよりも正確性を重視する必要がある場合、より高いレベルの effort を設定すると効果的です。ただし、その分、出力トークンの消費量は増加します。

Chat Completions API では推論プロセス（思考の過程）は返されません。会話全体を通じてモデルの推論履歴を利用したい場合は、Responses API を使用してください。

デフォルトの状態維持パターンでは、store=True を設定し、previous_response_id を用いて呼び出しを連鎖させることで、各ターンでの推論結果が自動的に保持・再利用されます。そのため、ユーザー側で推論データを管理する必要はありません。

一方、状態を保持しない（ステートレス）ケースでは暗号化された推論データを利用します。サーバーサイドで会話履歴を保存したくない場合など、store=False を設定する場合は、include=["reasoning.encrypted_content"] を指定して推論データをリクエストに含めてください。取得した推論結果は、次のリクエストの入力としてモデルに渡すことで、過去の推論文脈として活用できます。

以下は、高レベルの推論 effort で古典的なトリック質問を実行する例です。

以下に、Amazon Bedrock で Grok を利用する際のコード例を示します。

response = client.responses.create(

model="xai.grok-4.3",

reasoning={"effort": "high"}, # none, low, medium, or high

include=["reasoning.encrypted_content"],

max_output_tokens=4096,

input=(

"A bat and ball cost $1.10. The bat costs $1 more than the ball. "

"How much is the ball? Answer with just the number."

),

)

print(response.output_text)

print(response.usage.output_tokens_details.reasoning_tokens)

このモデルは、直感的に導き出されやすい誤った答え（0.10 ドル）に飛びつくのではなく、代数的な計算プロセスを経て正解を導き出しました。また、使用状況のレポートには、内部で処理に要した推論トークンの数も含まれています。

もし推論の努力度を "none" に設定すると、同じフィールドには 0 という値が返されます。これは、単純なタスクやレイテンシ（応答遅延）を重視する呼び出しにおいて推奨される設定です。

response = client.responses.create(

model="xai.grok-4.3",

reasoning={"effort": "none"},

max_output_tokens=2048,

input="Say OK.",

)

print(response.output_text) # OK.

実務的な運用パターンとしては、分類処理、情報抽出、短時間の事実確認などは "none" または "low" で実行し、計画立案や数学的計算、あるいは初期のミスがその後の連鎖全体を破綻させるような複雑なタスクに対してのみ、推論努力度を "high" に設定するのが効果的です。

Grok 4.3 でツールを呼び出す

エージェントワークロードにおいて、ツールの呼び出し機能は不可欠です。Grok 4.3 は OpenAI と互換性のある同じインターフェースを通じてこの機能をサポートしています。利用可能なツールを記述すると、モデルがいつツールを呼び出すかを判断し、構造化されたリクエストを返します。その後、あなたのコードがこのリクエストを実行して結果をフィードバックします。

Grok 4.3 は標準的な OpenAI のツール呼び出し形式に従っているため、各ツールのパラメータには JSON Schema を定義する必要があります。

以下の例では、単一の get_weather ツールを用意し、これをトリガーする質問を投げかけています。

tools = [
    {
        "type": "function",
        "function": {
            "name": "get_weather",
            "description": "Get the current weather for a city",
            "parameters": {
                "type": "object",
                "properties": {"city": {"type": "string"}},
                "required": ["city"],
            },
        },
    }
]

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[{"role": "user", "content": "What's the weather in Sydney? Use the tool."}],
    tools=tools,
    tool_choice="auto",  # let the model decide whether to call a tool
)

tool_call = response.choices[0].message.tool_calls[0]
print(tool_call.function.name, tool_call.function.arguments)
# get_weather {"city":"Sydney"}

モデルは質問から都市情報を抽出し、スキーマに合致する有効な引数オブジェクトを生成しました。次に、自社のコードでこの関数を呼び出し、結果を含むツール役のメッセージを追加してモデルを再度実行します。これにより、モデルはデータを自然な言語による回答として統合できます。これが Grok 4.3 における多段階エージェントの基礎となる仕組みです。

##構造化された出力

コードが直接解析できる形でデータを返す必要がある場合、JSON スキーマを用いた構造化出力を利用してください。Grok 4.3 は厳格モード付きの json_schema レスポンス形式をサポートしており、自由なテキストを生成するのではなく、指定したスキーマに厳密に従った回答を返します。

例えば、以下のコードは国に関する事実を取得し、回答の形式を制限しています:

import json

schema = {
    "type": "object",
    "properties": {
        "name": {"type": "string"},
        "capital": {"type": "string"},
        "population_millions": {"type": "number"},
    },
    "required": ["name", "capital", "population_millions"],
    "additionalProperties": False,
}

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[{"role": "user", "content": "Return facts about the country Australia."}],
    response_format={
        "type": "json_schema",
        "json_schema": {"name": "country_facts", "strict": True, "schema": schema},
    },
    max_completion_tokens=4096,
)

データ構造を確認するために、レスポンスのメッセージ内容を JSON パースし、結果を出力します。

data = json.loads(response.choices[0].message.content)
print(data)
# {'name': 'Australia', 'capital': 'Canberra', 'population_millions': 26.6}

strict を True に設定し、additionalProperties を False にすることで、レスポンスを指定したキーのみに制限できます。これは、後続システムが固定されたレコード形式を期待している場合のツール呼び出しと非常に相性が良い設定です。

ただし、運用上の注意点として、テストでは意図しない benign な入力に対しても、自動的なコンテンツ安全チェックにより 400 エラーが返されることがあります。本番環境では、このエラーに対応した簡易なリトライ処理を実装しておくことを推奨します。

画像入力のサポート

Grok 4.3 は画像を入力として受け付け、テキストで回答を返すことができます。ドキュメントの理解、チャートの読み取り、視覚的な質問への回答などが可能です。

OpenAI の Chat Completions API と同じパターンを使用します。画像は data: URL に base64 でエンコードされたバイト列を含むコンテンツパート、あるいは公開されている画像 URL として指定します。テキストと画像の両方を同一のコンテンツ配列に含めることで、モデルが質問と画像を同時に認識できるようになります。

import base64

with open("chart.png", "rb") as f:
    b64 = base64.b64encode(f.read()).decode()

response = client.chat.completions.create(
    model="xai.grok-4.3",
    messages=[
        {
            "role": "user",
            "content": [
                {"type": "text", "text": "Describe this image in one short sentence."},
                {
                    "type": "image_url",
                    "image_url": {"url": f"data:image/png;base64,{b64}"},
                },
            ],
        }
    ],
    max_completion_tokens=4096,
)
print(response.choices[0].message.content)

テストでは、生成された画像を読み込み、その主な色を正しく識別しました。使用する画像形式は PNG または JPEG などの対応フォーマットに絞り、エンコードもきれいに保つ必要があります。画像データが破損していたり切り捨てられていたりすると、推測で答えを出すのではなく「validation_error（検証エラー）」が返されます。

## Responses API を使った状態維持型会話

Responses API では、会話の状態をサービス側で保持できるため、毎回すべてのメッセージ履歴を送信する必要はありません。会話の 1 トーン（やり取り）を保存するには、store=True を指定して呼び出し、返された response ID を取得しておき、次の呼び出しで previous_response_id にその ID を渡します。すると、モデルは過去のやり取りを文脈として扱います。

first = client.responses.create(
    model="xai.grok-4.3",
    input="Remember the number 42. Just acknowledge.",
    store=True,
    max_output_tokens=2048,
)

second = client.responses.create(
    model="xai.grok-4.3",
    previous_response_id=first.id,
    input="What number did I ask you to remember?",
    max_output_tokens=2048,
)
print(second.output_text)  # 42

コード例の 2 つ目の `client.responses.create` 呼び出しでは、`previous_response_id` 以外にメッセージは送信されていません。サービスが各会話履歴を保存しているため、モデルの過去の推論プロセスも自動的に次の呼び出しへ引き継がれます。これにより、会話内容とモデルの思考過程を両方とも文脈として維持しつつ、手動で状態管理を行う必要がありません。

ただし、この機能を有効にする前に知っておくべき点があります。会話履歴を保存するということは、サービス側がそのデータを保持することになるからです。保存されたデータのセキュリティやプライバシーについては、[Amazon Bedrock のデータ保護](https://docs.aws.amazon.com/bedrock/latest/userguide/data-protection.html) に関するドキュメントで確認してください。必要に応じて保持機能を無効化する方法についても記載されています。

## サービスティアとリージョン対応状況

Amazon Bedrock では、ワークロードごとにコストとスループットを最適化できるよう、複数のサービスティアが用意されています。Standard ティアのオンデマンド推論は、利用したトークン数に応じた従量課金で、契約不要です。Priority ティアは、1 トークンあたりの料金は高くなりますが、処理キューでの優先処理が受けられます。一方、Flex ティアは、時間制約のないワークロード向けに低コストなアクセスを提供します。Grok 4.3 は、Standard、Priority、Flex のすべてのティアで利用可能です。詳細については、[推論用のサービスティア](https://docs.aws.amazon.com/bedrock/latest/userguide/service-tiers-inference.html) をご覧ください。

Grok 4.3 では、リージョン内での推論（in-Region inference）のみがサポートされています。そのため、モデルが利用可能なリージョンにクライアントを固定し、Mantle のベース URL もそれに合わせて設定する必要があります。このモデルのローンチ時点では、地理的な制約を超えたクロスリージョン推論やグローバルなクロスリージョン推論は提供されていません。本記事の例では us-west-2 を使用しています。現在サポートされているリージョンの一覧については [リージョン対応状況](https://docs.aws.amazon.com/bedrock/latest/userguide/models-region-compatibility.html) のドキュメントを、各ティアごとの料金については [Amazon Bedrock の価格設定](https://aws.amazon.com/bedrock/pricing/) ページをご確認ください。

## 結論

Amazon Bedrock で利用可能な Grok 4.3 は、推論を最優先に設計されたモデルです。必要に応じて推論の強度を調整可能で、ネイティブなツール呼び出し機能や厳格な構造化出力、画像理解能力、サーバーサイドでの会話状態管理など、多様な機能を備えています。

このモデルへのアクセスは、Bedrock の Mantle エンドポイントを指す OpenAI SDK を使用して行います。本記事で紹介する例では、リクエストごとのトークン利用以外に課金対象となる AWS リソースは作成されません。ただし、探索目的で長期有効な Amazon Bedrock API キーを発行した場合は、使い終わったら必ずコンソールから削除してください。長期キーは恒久的な認証情報となるため、不要になったものを削除しておくことで、アカウントの攻撃対象範囲を最小限に抑えることができます。

開発を始めるには、まず現在のリージョン一覧とパラメータの詳細を確認できる [Grok 4.3 モデルカード](https://docs.aws.amazon.com/bedrock/latest/userguide/model-cards.html) を参照し、トークン単価については [Amazon Bedrock の価格ページ](https://aws.amazon.com/bedrock/pricing/) で確認してください。その上で、以下の方向性を検討することをお勧めします。

- 返された関数を実行し、その結果をフィードバックしてツール呼び出しのループをエンドツーエンドで実装する
- 応答間で暗号化された推論内容を継承させ、長時間稼働するエージェントが思考の一貫性を保てるようにする
- 自社のワークロードに対して推論レベルをベンチマークし、推論強度を上げてもトークンコストに見合わないポイントを見極める