Amazon Bedrock での Grok の提供開始
xAI の Grok 4.3 が Amazon Bedrock で一般利用可能になりました。構成可能な推論努力、強力なツール使用と指示追従、100万トークンのコンテキストウィンドウを備え、エージェントやエンタープライズワークロードに適しています。この記事では、その特徴、アクセス方法、基本的な使い方を紹介します。
xAI の Grok 4.3 が Amazon Bedrock 上で一般提供を開始し、AI エージェントやワークフローを構築するチームに、長い入力を確実に推論できるモデルを提供します。このリリースにより、xAI は Amazon Bedrock のモデルプロバイダーに加わりました。Grok 4.3 は構成可能な推論努力を備え、エージェント構築のための強力なツール使用と指示追従、高スループット推論のためのトークン効率を提供します。テキストと画像の入力を受け付け、100万トークンのコンテキストウィンドウで長文書やマルチターンセッションを処理します。モデルは Amazon Bedrock の次世代推論エンジン Mantle 上で動作します。
Grok 4.3 がエージェントおよび推論ワークロードに最適な理由
xAI によると、Grok 4.3 は精度が重要なエンタープライズ作業向けに構築されています。モデル発表時の独自ベンチマークにおいて、xAI は複数の業界ベンチマークを上回ったと報告しています。Grok 4.3 は Artificial Analysis Omniscience ベンチマークで1位を獲得し、比較されたフロンティアモデルの中で最も低い幻覚率を示しました。また、カスタマーサポートシナリオにおけるツール呼び出しの Artificial Analysis Tau2 Telecom ベンチマーク、Vals AI Case Law および Corporate Finance ベンチマークでも1位を獲得しました。xAI はこのモデルをインテリジェンス対コストのパレートフロンティアに位置づけ、他のフロンティアモデルと比較して1ドルあたり2~10倍のインテリジェンスを提供すると述べています。
Grok 4.3 では、各リクエストごとにモデルが回答前にどれだけ思考するかを effort レベルで制御できます。effort レベル(none、low、medium、high)をリクエストごとに設定し、1つのモデルで幅広い作業に対応できます。分類呼び出しは low に設定してレイテンシを低く抑え、契約分析や判例法のタスクは high に設定して応答時間より深さを優先できます。Grok 4.3 はテキストと画像の入力を受け付け、テキストを返します。100万トークンのコンテキストウィンドウは長文書や拡張マルチターンセッションに十分な余裕を提供します。モデルはツール呼び出しと指示追従に優れており、関数呼び出しに依存してアクションを実行するエージェントに実用的です。これらの特性は、契約レビュー、与信契約分析、財務文書の質問応答などのユースケースに適しています。
Amazon Bedrock での Grok 4.3 へのアクセス方法
Grok 4.3 は Mantle 上で動作し、Amazon Bedrock Runtime API を使用するモデルとはアクセス方法が異なります。Mantle は OpenAI 互換の API を使用します。OpenAI SDK または Chat Completions API / Responses API への直接 HTTPS リクエストのいずれかで Grok 4.3 を呼び出すことができます。
Mantle エンドポイント URL はリージョン固有であり、特定のパターンに従います。たとえば、us-west-2 のベース URL は https://bedrock-mantle.us-west-2.api.aws/openai/v1 です。Mantle エンドポイントの Responses API URL ルートは Runtime エンドポイントと若干異なります。
Grok 4.3 で SDK を設定するには、前述の説明に従って適切なリージョンとパスでベース URL を設定します。Grok を使用する際は、コンテキストウィンドウが100万トークンであり、デフォルトが標準の OpenAI 仕様から3つの点で異なることに注意してください:temperature のデフォルトは 0.7、top_p は 0.95、max_completion_tokens は 131072 です。アプリケーションで異なる動作が必要な場合は、これらを明示的に設定してください。
認証と最初のリクエストの実行
Mantle エンドポイントに対する認証方法は2つあり、どちらも同じ OpenAI SDK で機能します。本番環境では、IAM 資格情報から生成された短期のベアラートークンを推奨します。これらは自動的に期限切れになり、アクセスを IAM ID に結びつけます。クイックな探索や入門には長期の Amazon Bedrock API キーを使用します。長期キーはその目的に限定し、本番アプリケーションに埋め込まないでください。
次の例は、長期の Amazon Bedrock API キーで認証してモデルにアクセスする方法を示しています。これは探索専用の資格情報として扱ってください。Amazon Bedrock コンソールからキーを生成し、OpenAI SDK をインストールします。クライアントをリージョナル Mantle エンドポイントに向け、API キーで認証します。モデル ID は xai.grok-4.3 です。
より高いセキュリティ要件で Amazon Bedrock をアプリケーションに組み込む準備ができたら、短期資格情報の使用をお勧めします。Amazon Bedrock トークンジェネレーターを使用して、既存の AWS 資格情報からリクエスト時に短期ベアラートークンを生成できます。これにより、認証が IAM ID に結びつけられ、長期間有効なシークレットを回避できます。
推論出力の構成
Responses API の reasoning パラメータを通じて、モデルが費やす推論努力の量を制御できます。努力レベルは none(推論を無効)、low(デフォルト)、medium、high です。高い努力は、迅速な回答が間違っている可能性がある多段階問題に役立ちますが、より多くの出力トークンを消費します。
Chat Completions API は推論トレースを返しません。モデルの推論を複数ターンにわたって利用したい場合は、Responses API を使用します。デフォルトのステートフルパターンでは、store=True を設定し previous_response_id でチェーンすることで、サービスが各ターンの推論を保持し自動的にフィードバックするため、自分で管理する必要はありません。暗号化された推論はステートレスな場合に使用します。store=False を設定した場合(たとえば、ターンをサーバー側で永続化しないワークロードの場合)、include=["reasoning.encrypted_content"] で推論を要求します。次のリクエストの入力でそれを渡し、モデル自身の以前の推論をコンテキストとして提供します。
実用的なパターンは、分類、抽出、短い事実確認には none または low を使用し、高い努力は計画ステップ、数学、単一の初期のミスがタスク全体を崩すチェーンに予約することです。
Grok 4.3 でのツール呼び出し
ツール呼び出しはエージェントワークロードの中心であり、Grok 4.3 は同じ OpenAI 互換インターフェースを通じてサポートします。利用可能なツールを記述し、モデルがいつ呼び出すかを決定し、コードが実行してフィードバックする構造化リクエストを返します。Grok 4.3 は標準の OpenAI ツール呼び出し形式に従うため、各ツールのパラメータを JSON Schema で定義します。
次の例は、get_weather ツールを提供し、それをトリガーする質問をします。モデルは質問から都市を解析し、スキーマに一致する有効な引数オブジェクトを生成します。その後、独自のコードで関数を実行し、ツールロールメッセージで結果を追加し、モデルを再度呼び出してデータを自然言語応答に組み込みます。これが Grok 4.3 でのマルチステップエージェントの構成要素です。
構造化出力
モデルにコードが直接解析できるデータを返させる必要がある場合は、JSON Schema を使用した構造化出力を使用します。Grok 4.3 は strict モードで json_schema 応答形式をサポートしているため、応答は提供されたスキーマに準拠し、自由形式のテキストではありません。strict を True に、additionalProperties を False に設定すると、応答が要求したキーに制限され、下流システムが固定レコード形式を期待する場合にツール呼び出しと組み合わせるのに適しています。テストでの運用上の注意:無害な入力でも、リクエストが自動コンテンツセーフティチェックから400エラーを返すことがあるため、プロダクションコールには短いリトライを組み込んでください。
画像入力
Grok 4.3 は画像を入力として受け付け、テキストを返します。文書理解、チャート読み取り、視覚的質問応答をカバーします。画像は、OpenAI Chat Completions API と同じパターンで、base64 エンコードされたバイトを含む data: URL または公開画像 URL として content パートに渡します。テキストと画像パーツは同じ content 配列に配置され、モデルが質問と画像を同時に認識します。テストでは、モデルは生成されたテスト画像を正しく読み取り、主要な色を正しく識別しました。PNG や JPEG などのサポートされている画像形式を使用し、エンコーディングをクリーンに保ってください。不正な形式や切り詰められた画像ペイロードは検証エラーを返します。