Grok 4.7とは？Amazon Bedrockでの利用条件・機能・企業向けPoCの始め方

Grok 4.7は、コーディング、エージェントタスク、ナレッジワーク向けに位置付けられているモデルです。Amazon Bedrockのモデルカードでは、500Kトークンのコンテキスト、テキスト・画像入力、テキスト出力、low／medium／high／xhighのreasoning effort、構造化出力、Guardrails、応答ストリーミングへの対応が案内されています。Bedrock Runtimeで利用する場合は、単一リージョン推論ではなく、US GeoまたはGlobalのクロスリージョン推論プロファイルをモデル名として指定します。Amazon BedrockのGrok 4.7モデルカード

ただし、コンテキスト長やreasoningの設定だけで、特定の業務に適しているとは判断できません。データをどこで処理できるか、出力の誤りを誰が確認するか、推論にかかる時間とトークン費用をどこまで許容するかを、PoCの開始前に決める必要があります。本記事のPoC手順、評価項目、判断基準はMojiによる実務上の提案です。モデル、入力データ、評価件数、許容できない失敗によって結論は変わります。

Grok 4.7の要点

AWSの2026年9月28日の公開告知は「SpaceXAI Grok 4.7」と表記しています。一方、Amazon Bedrockのモデルカードは提供者をxAI、モデルIDをxai.grok-4.7と表記しています。本記事では、両者の組織関係を推測せず、Bedrockの利用時に必要となるモデルIDと、各公式資料の表記をそのまま扱います。AWSの公開告知 AWSのモデルカード

Amazon Bedrockで利用する際の条件

1. Grok 4.7はクロスリージョン推論プロファイルで呼び出す

Bedrock RuntimeでGrok 4.7を呼び出す場合は、us.xai.grok-4.7（US Geo）またはglobal.xai.grok-4.7（Global）を指定します。モデルカードでは、xai.grok-4.7のIn-Region endpointは「Not supported」とされており、同エンドポイントでの単一リージョン推論は利用できません。Grok 4.7モデルカード

Geoクロスリージョン推論では、指定した地理的範囲内の商用AWSリージョンへリクエストがルーティングされます。Globalクロスリージョン推論では、対応する商用AWSリージョンのどこでも処理される可能性があります。データ所在地の要件がある場合は、料金だけでGlobalを選ばず、処理可能な地理的範囲と組織の要件を照合してください。AWSのクロスリージョン推論ガイド

また、推論プロファイルの接頭辞だけで実際の宛先リージョンを確定させるのではなく、利用する送信元リージョンからGetInferenceProfileを実行し、応答のmodelsに含まれるモデルARNから宛先リージョンを確認します。これは、データ所在地や組織のSCPを検討する際に必要な確認です。推論プロファイルの対応リージョンと確認方法

2. IAM、EULA、SCPをPoC前に確認する

Grok 4.7のモデルカードでは、クロスリージョン推論プロファイルへの呼び出しに加え、アカウントのdefault projectに対するbedrock:InvokeModel権限が必要と案内されています。実行ロールには、必要なAPIを呼び出すための最小権限を付与してください。モデルカードのプログラマティックアクセス

第三者モデルを利用または呼び出すことは、該当するEULAへの同意を伴います。利用開始前に、適用されるライセンス条件を法務・購買・情報セキュリティの確認手順に通してください。また、AWSは、モデル利用を開始時点から止めるには、bedrock:InvokeModelに対するDenyを組織のSCPまたはIAMで適用する方法を案内しています。PoCで許可するモデル、実行ロール、送信元リージョンをあらかじめ限定すると、検証範囲を管理しやすくなります。Amazon Bedrockのモデルアクセス要件

• PoC用の実行ロールと、本番用の実行ロールを分ける
• PoC用ロールには、本番データストアの更新、デプロイ、外部送信、削除に関する権限を与えない
• 利用する送信元リージョンと推論プロファイルの宛先リージョンを確認する
• SCPがクロスリージョン推論の宛先リージョンを拒否していないか確認する
• 適用される第三者モデルのEULAを確認する

3. 「Bedrock経由」と「入力可能な情報」は分けて確認する

AWSは、Amazon Bedrockに送信した入力・出力をAmazon Nova、Amazon Titan、第三者モデルの学習に使用しないと説明しています。また、ユーザーの入力とモデル出力はモデル提供者と共有しないと案内しています。Amazon BedrockのモデルデプロイアカウントはAWSのサービスチームが運用し、モデル提供者はそのアカウント、Bedrockログ、顧客プロンプト、補完結果へアクセスしないとも説明されています。Amazon Bedrock FAQ Amazon Bedrockのデータ保護資料

ただし、これだけで全ての情報を無条件に入力してよいとはいえません。Bedrockのデータ保持は、アカウントまたはプロジェクトの設定と、モデル側が許容・要求する保持モードによって決まります。AWSの資料では、defaultモードの実際の保持はモデルに依存し、AWSが安全性・不正利用防止の目的でデータを保持する場合があると説明されています。Grok 4.7を使うアカウントでは、実行前に有効な保持モードと当該モデルの利用条件を確認してください。Amazon Bedrockのデータ保持

モデル呼び出しログも別途確認が必要です。Bedrock Runtimeのモデル呼び出しログは既定で無効ですが、有効化すると、設定した対象モダリティのリクエスト・レスポンスをAmazon S3、CloudWatch Logs、または両方へ出力できます。ログは設定を削除するまで保存されます。入力・出力を含むログを有効にするPoCでは、保存先、暗号化、閲覧権限、保持期間、削除手順を決めてください。モデル呼び出しログの仕様

機能から見る、Grok 4.7を検証候補にしやすい業務

AWSはGrok 4.7をコーディング、エージェントタスク、ナレッジワーク向けのモデルとして案内しています。xAIの発表では、Grok 4.6より大きなベースモデル、長時間を要するタスクを重視した強化学習、自己検証、長いコンテキストの扱いを改善点として説明しています。これらは提供者によるモデルの説明であり、自社業務における正確性、所要時間、費用を保証するものではありません。PoCでは、同じ入力、同じ制約、同じ評価基準で比較してください。AWSの公開告知 xAIのGrok 4.7発表

上表はMojiによる設計例です。たとえば、正解が一意に定まる抽出業務と、複数案に価値がある企画業務では、同じ指標では比較できません。AIエージェントへ委任する操作、人の承認、停止条件の決め方は、AIエージェントはどこまで任せるべきかを参照してください。エージェントと固定ワークフローの使い分けは、AIエージェントとは？で解説しています。

料金の見方：単価だけでなく、出力量とservice tierを含めて比較する

Grok 4.7のStandard tierにおけるオンデマンド料金は、Geo CRISが入力100万トークンあたり2.20米ドル、出力100万トークンあたり6.60米ドル、キャッシュ読み取り100万トークンあたり0.55米ドルです。Global CRISは、それぞれ2.00米ドル、6.00米ドル、0.50米ドルです。PriorityはStandardの1.75倍、Flexは0.5倍の単価です。料金・提供条件は更新されるため、発注や本番化の前にモデルカードを確認してください。Grok 4.7モデルカードの料金

Mojiによる試算テンプレート：1リクエストの概算費用は、（入力トークン ÷ 1,000,000 × 入力単価）＋（出力トークン ÷ 1,000,000 × 出力単価）＋（キャッシュ読み取りトークン ÷ 1,000,000 × キャッシュ単価）です。PriorityまたはFlexを使う場合は、この金額に該当する係数を掛けます。

reasoning effortを上げる場合は、品質だけでなく、1件の成果物を完了するまでに使う入出力トークン、待ち時間、再試行回数、人の修正時間を記録してください。100万トークン単価だけでなく、業務1件あたりの総費用と確認作業を含む総時間で比較することが重要です。

最初のAPI呼び出し：OpenAI互換SDKまたはAWS SDKを使う

Bedrock Runtimeでは、Responses APIとChat Completions APIをOpenAI互換エンドポイントとして利用できます。その場合、OpenAI Python SDKをクライアントとして使えますが、リクエストはOpenAIへ送られるのではなく、Amazon Bedrock上のxAIモデルへ送られます。AWS SDKを使う場合は、Converse APIで呼び出せます。AWS公式のGrok 4.7呼び出し例

以下は架空の例です。実運用では、長期APIキーをソースコードや共有ドキュメントへ保存せず、組織の認証・シークレット管理方針に従ってください。

from openai import OpenAI

# 架空の例: 環境変数にBedrock APIキーとBase URLを設定済みとする
client = OpenAI(
    base_url="https://bedrock-runtime.us-east-1.amazonaws.com/openai/v1"
)

response = client.responses.create(
    model="us.xai.grok-4.7",
    reasoning={"effort": "medium"},
    input="架空の例: 次の仕様書から、未決定事項だけをJSONで抽出してください。"
)

print(response.output_text)

Grok 4.7ではreasoningが既定で有効です。Responses APIでは、暗号化されたreasoning contentを含める指定を行い、後続ターンへ渡せます。Chat Completions APIはreasoning tokenを返しません。推論設定を比較する場合は、使用APIとreasoning effortを記録に残してください。Grok 4.7のreasoning仕様

最初の検証では、本番システムの書き込み権限やブラウザ操作を広く渡さず、まず入力・出力だけを扱う検証から始めます。次に社内の読み取り専用検索、最後に人の承認を挟んだ限定操作という順序にすると、モデル、プロンプト、ツール、権限のどこに原因があるかを分けて確認しやすくなります。生成AI API全体の比較軸は、生成AI APIとは？種類・選び方、料金の見方と開発手順を解説も参考にしてください。

企業向けPoCを始める5ステップ

ステップ1：業務を「成果物」と「許容できない失敗」で1つに絞る

「営業をAI化する」「開発を効率化する」のような広いテーマでは、PoCの成功・失敗を判定しにくくなります。最初は、対象者、入力、期待する成果物、禁止事項、人の確認者を1枚にまとめます。

• 対象業務：例）PR前の変更差分からテスト観点を下書きする
• 入力：サンプル化・匿名化済みの差分と仕様
• 成果物：テスト観点の下書き、根拠となるファイル・行の候補
• 許容できない失敗：本番環境への変更提案、秘密情報の出力、根拠のない断定
• 人の役割：レビュー、採否判断、マージ・送信・更新の実行

ステップ2：データ、リージョン、保持、ログの条件を先に決める

PoC用データを「投入してよい」「匿名化・マスキング後に投入する」「投入しない」に分けます。US内での処理が必要な場合はUS Geoを候補にし、実際の送信元リージョンから宛先リージョンを確認します。さらに、アカウントにおけるデータ保持モード、モデルの利用条件、モデル呼び出しログの有効・無効を確認してください。

Invocation loggingを使う場合は、入力・出力がログに記録されることを前提に、S3またはCloudWatch Logsの保存先、暗号化、閲覧者、保持期間、削除手順を決めます。ログを有効にしない場合も、障害調査や監査に必要な最小限のアプリケーションログを別途設計します。

ステップ3：ベースラインと評価データを作る

PoC前に、現行の人手プロセスで同じ仕事を数件処理し、時間、手戻り、品質を記録します。評価セットは成功例だけにせず、曖昧な依頼、欠損データ、矛盾する資料、回答や操作を拒否すべき依頼を含めます。評価中にプロンプトを調整した場合は、調整に使用していないホールドアウトケースで再評価します。

ステップ4：reasoning effortを固定してから比較する

初回比較でlow、medium、high、xhighを混在させると、モデル差、プロンプト差、推論設定の差を分けて判断しにくくなります。まずはmediumなど一つの設定に固定し、モデルまたはワークフローを比較します。その後、難しいケースだけでreasoning effortを上げる条件を追加します。

ステップ5：継続・拡大・中止の判断条件を開始前に合意する

PoC終了時に感想だけで判断しないよう、開始前に合格条件と停止条件を定義します。たとえば「重要誤りがないこと」だけではなく、重要誤りの定義、評価件数、品質の下限、1件あたりの上限費用、人の確認時間、インシデント時の停止権限を明文化します。本番化の移行ゲートは、AI PoCを本番化する進め方で詳しく解説しています。

PoC評価シート（Mojiによるテンプレート）

以下はMojiによる評価テンプレートです。業務の影響範囲、扱う情報、許容できない誤りに応じて、評価項目と合格基準を調整してください。

導入前チェックリスト

• Grok 4.7を選ぶ理由を、モデル名ではなく対象業務・成果物・失敗許容度で説明できる
• us.xai.grok-4.7またはglobal.xai.grok-4.7のどちらを使うか、データ所在地要件とともに決めた
• 送信元リージョンごとに、推論プロファイルの宛先リージョンを確認した
• 実行ロールに必要なbedrock:InvokeModel権限を限定して付与した
• 第三者モデルのEULAを組織の確認手順に通した
• 入力可能な情報、禁止情報、匿名化・マスキング方法を決めた
• アカウントのデータ保持モードと、モデル利用時の条件を確認した
• モデル呼び出しログの有効・無効、保存先、保持期間、閲覧権限を決めた
• PoCロールに、本番デプロイ・外部送信・データ削除などの権限を与えていない
• 評価セットに、正常系だけでなく曖昧・欠損・矛盾・拒否すべきケースを含めた
• 品質、費用、待ち時間、人の確認時間、停止条件を数値または判定ルールで合意した

まとめ

Grok 4.7をAmazon Bedrockで検証する際は、モデル性能だけで導入可否を決めないことが重要です。Bedrock Runtimeではクロスリージョン推論プロファイルを使うため、処理先リージョン、IAM・SCP、EULA、データ保持、ログ、トークン費用、人の承認を一体で確認する必要があります。

最初のPoCは、読み取り専用かつ可逆的な業務に限定し、同じ評価データで品質、総時間、総費用、安全性を測定してください。その結果を基に、継続、対象拡大、別モデルとの比較、中止を判断する方が、ベンチマークやトークン単価だけで採否を決めるよりも、対象業務に対する適合性を確認しやすくなります。