SpaceXAIのGrok 4.7が、複数のプロバイダーの基盤モデル(FM)を選べるAmazon Bedrockで利用可能になりました。SpaceXAIによると、Grok 4.7はより難しいタスクにより長く取り組むよう訓練されており、自分の作業をいつ確認すべきかを把握しています。これは、多くのステップを通じてタスクを進め、途中で見つけたことを検証しなければならないエージェントにとって特に重要です。このように動くエージェントは、情報を調べるだけでは足りません。候補となる回答を作り、学んだ内容と照らして確認し、適合するまで磨き上げる必要があります。
Grok 4.7は、各応答の前にどれだけ熟考するかを制御する推論の強度(reasoning effort)の設定を公開しており、エージェントのワークロードではどのレベルで実行するかが実務上の問いになります。そこで、Grok 4.7上にツール呼び出しエージェントを構築し、アラートからの2サービス障害の診断、相互に影響する制約下でのメンテナンスのスケジューリング、予算内での最適なマイグレーション集合の選択という、ルックアップではなく探索を要する3つのタスクで評価しました。これら3つのタスクにはそれぞれ正解がちょうど1つあり、ブルートフォースで検証されています。これら3つのタスクすべてを推論の強度ごとに各6回、合計72回のエージェント実行として行い、エージェントは67回正解しました。このエージェントは、3つのタスク計18回の実行のうち、`xhigh` ではすべて正解し、`low` では15回正解しましたが、出力トークンは `xhigh` の約8分の1で済みました。リクエストごとに調整できる明確なトレードオフがあります。
Grok 4.7の訓練内容とベンチマーク結果
SpaceXAIは、Grok 4.7が自分の作業の検証と、より長いコンテキストの管理に優れていると報告しています。また同社によると、Grok 4.7はGrok 4.6より大きなベースモデルを使い、完了に何時間もかかる問題に重みが置かれている、より難しいタスクの組み合わせで、より長い強化学習(reinforcement learning)を行って訓練されました。公表されたベンチマーク結果では、Grok 4.6に対する最大の向上は、単発の回答ではなく持続的な作業を測るカテゴリに現れています。Grok 4.6からGrok 4.7への変化は、Terminal-Bench 4.0(数時間にわたるターミナル作業)が20.3%から37.6%、EEBench(電気工学)が53.0%から64.0%、Harvey Legal Agent Benchmark(法務業務)が15.8%から19.6%、CursorBench 4.0(より長時間のコーディング)が40.4%から46.3%、HealthBench Professional(臨床推論)が48.5%から56.7%、AA Briefcase v1.1(数時間にわたるオフィス業務)が1,546から1,657です。筆者らはコストを通貨ではなくトークン数で一貫して報告しています。トークン価格は変わる一方で、利用者自身のコストはトークン数から導かれるため、トークンで表した測定値は有効であり続けるからです。
| ベンチマーク | Category | Grok 4.6 | Grok 4.7 |
|---|---|---|---|
| Terminal-Bench 4.0 | Multi-hour terminal work | 20.3% | 37.6% |
| EEBench | Electrical engineering | 53.0% | 64.0% |
| Harvey Legal Agent Benchmark | Legal work | 15.8% | 19.6% |
| CursorBench 4.0 | Longer-running coding | 40.4% | 46.3% |
| HealthBench Professional | Clinical reasoning | 48.5% | 56.7% |
| AA Briefcase v1.1 | Multi-hour office work | 1,546 | 1,657 |
元記事の表を転載しています(見出しは日本語にしています。値は原文のままです)。出典: 元記事
推論プロファイル、対応API、前提条件
Grok 4.7はAmazon Bedrockの`bedrock-runtime`エンドポイントで動作し、クロスリージョン推論プロファイル経由でアクセスします。利用できる推論プロファイルは2つあります。クロスリージョン推論(Cross-Region inference)は複数のAWSリージョンにリクエストをルーティングし、リージョンごとにキャパシティを管理しなくても高いスループットが得られます。リクエストでは単体のモデルIDではなく、いずれかの推論プロファイルを指定します。Converse APIを使う場合、推論(reasoning)は`text`ブロックと並んで`reasoningContent`ブロックとして返されます。
US プロファイルである`us.xai.grok-4.7`は、リクエストを米国の地理的範囲内でルーティングします。米国のデータレジデンシー要件がある場合にこれを使用します。Global プロファイルである`global.xai.grok-4.7`は、商用AWSリージョンでルーティングを行います。レジデンシーの制約がなく、最も広いキャパシティを求める場合にこれを使用します。
Grok 4.7は、OpenAI互換のChat CompletionsおよびResponses APIと、Amazon Bedrock Converse APIをサポートします。Amazon BedrockでGrok 4.7を使うには、前提条件として、Amazon Bedrockにアクセスできて、Grok 4.7のモデルアクセスが有効なAWSアカウントが必要です。また、Python 3.9以降と、インストール済みの`openai`、`boto3`、`aws-bedrock-token-generator`が必要です。さらに、環境にAWSの認証情報を設定しておく必要があります。Grok 4.7をConverse APIで使う場合、`inferenceConfig`では`maxTokens`のみを設定し、推論の強度などのモデル固有のパラメータは`additionalModelRequestFields`に入れます。対応リージョン、ティア、およびトークン価格の最新情報は、Amazon Bedrock User GuideのGrok 4.7モデルカードとAmazon Bedrockの料金ページ(https://aws.amazon.com/bedrock/pricing/)で確認できます。
ベンチマークの出典は、SpaceXAIの「Introducing Grok 4.7」(https://x.ai/news/grok-4-7)で、スコアはモデル公開時にSpaceXAIが公表したものです。SpaceXAIによれば、Grok 4.7のコンテキストウィンドウは50万トークンで、入力はテキストと画像、出力はテキストです。Amazon Bedrock上のGrok 4.7は、設定可能な推論の強度、ツール呼び出し、構造化出力(structured output)をサポートします。ベンチマークは標準的なタスク全般でのモデルの性能を示します。自分のワークロードについては、自分のタスクに似た形のタスクで測ることが有用な次の一歩です。
IAM権限と推論トークンの扱い
AWS Identity and Access Management(IAM)のIDには、推論プロファイルとアカウントのデフォルトプロジェクトの両方に対する`bedrock:InvokeModel`が必要です。リソースは`arn:aws:bedrock:{region}::inference-profile/us.xai.grok-4.7`(または`global.`版)と`arn:aws:bedrock:{region}:{account-id}:project/default`であり、IAMポリシーのステートメントにはこれら両方のリソースを含める必要があります。本番環境で使う場合は、既存のAWS認証情報から短期のベアラートークンを生成することが推奨されます。これにより、認証がIAMのIDに結び付いたままになり、長期間有効なシークレットを保存しなくて済みます。長期のAmazon Bedrock APIキーを生成した場合は、取り消すまで有効なので、使い終えたらAmazon Bedrockコンソールで削除してください。IAM認証情報から生成した短期トークンは自動的に失効します。推論トークン(reasoning tokens)は出力トークンとして数えられ、回答テキストが生成される前に`max_completion_tokens`を消費します。そのため、上限は推論と回答の両方に余裕を持てるサイズにする必要があります。推論の途中で上限に達すると、回答テキストのないレスポンスが返ります。エージェントのコードでは空のcontentを確認し、見つかった場合は上限を引き上げてください。著者らの実行では`max_completion_tokens`の上限として32,768トークンを使い、すべての推論の強度で余裕がありました。Grok 4.7は`low`、`medium`、`high`、`xhigh`の4つの推論の強度をサポートしますが、強度はモデルのバージョン間で変わりうるため、リストをハードコードせずサービスに照らして確認することが望ましいです。多くのエージェント評価は、レコードを読む・絞り込む・合計するといった丹念さを試すタスクであり、そうしたタスクにも価値はあるものの、推論の強度が何に寄与するかを見るには、答えがデータから読み取れず、提案してから検証しなければならない探索を要するタスクが必要です。
評価の設計と推論の強度ごとの結果
評価用に、7つのツールを通じて公開される20のサービスからなる合成環境を作り、その上に3つのタスクを構築しました。各タスクは正解がちょうど1つで、簡易なヒューリスティクスでは正解にたどり着けないように作られています。また、各タスクには答えが1つだけあることを証明するため、環境が列挙できるほど小さいことから、何かを実行する前にすべての候補解を確認しました。各プロンプトは、エージェントに `FINAL: auth, checkout` のような最終行で終えるよう求めます。採点者はその行だけを読むため、推論の説明の中で他の候補に言及する応答も、結論で採点されます。形式は正誤とは別に追跡され、最終行がないことは不正解とは別の種類のシグナルとなります。この実行では、72件すべての応答に採点可能なFINAL行が含まれていました。評価では実行を繰り返し、各構成がどれだけ一貫しているかを確認します。
この測定は、1つのモデルバージョン、1つのリージョン、タスクごとに1つのプロンプトに限られます。同じタスクでも言い回しが変われば結果が変わる可能性があり、すべてのルールを明示することが重要な理由の一つになっています。採点者が依拠するルールはすべてプロンプトに明記する必要があります。プロンプトがエッジケースを未定義のままにすると、妥当な答えが不正解と採点されうるため、その場合、評価はモデルではなく仕様を測ることになります。このような測定を信頼できるものにする4つの実践があり、これらはほとんどのエージェント評価に当てはまります。たとえば診断タスクのプロンプトには、停止したサービスは自分ではアラートを出さないことが明記されています。
評価に使ったタスクは特定の種類の難しさを軸に設計されており、各推論の強度がそれらをどう扱ったかを見ると、追加の推論がどんなときに価値を持つかが分かります。有効な値が分かっているツールパラメータには`enum`で制約をかけ、すべてのツール呼び出しが実在するリソースを対象にするようにします。システムプロンプトは意図的に短くしてあり、エージェントに回答を出す前に確認することを求めています。実行をレビューするとき、エージェントの推論を追いやすくなるため、システムプロンプトでエージェントに答えの検証を求めておく価値はあります。既知の正解がある場合は自動採点と組み合わせ、トランスクリプトとは独立に品質を測定します。エージェントループは標準的なツール呼び出しのループです。`reasoning_effort`を設定してモデルを呼び出し、返された各ツール呼び出しを実行し、結果を`tool_call_id`をキーにして追加することを、モデルがツールを要求しなくなるまで繰り返します。ループ全体で`prompt_tokens`と`completion_tokens`を追跡して、報告するトークン数を得ています。各タスク・各レベルの実行は6回ずつなので、レベル間の差は統計的に確定的ではなく示唆にとどまりますが、傾向の向きは3つのタスクすべてで一致していました。仮説検証のタスクである診断タスクでは、候補のペアを両方向から確認する必要があり、すべてのアラートが説明され、かつ沈黙したままだったすべてのサービスが答えと矛盾しないことが求められます。medium以上では、18回すべての実行で正しいペアを特定しました。最適化のタスクである移行タスクでは、選択肢を1つずつ順位づけするのではなく組み合わせを検討することが報われ、個別の比率が最良の候補を選ぶと妥当な答えにはなるものの最適解に9ポイント届きませんが、medium以上ではエージェントは全18回の実行で最適な組み合わせを見つけました。制約充足のタスクであるスケジューリングタスクは、列挙された10個の制約に、参照して得られる所有者データに依存するチームルールを組み合わせたもので、xhighはすべての実行で有効なスケジュールを出し、最高レベルの差が最もはっきり表れたタスクでした。two_fault_diagnosis、maintenance_schedule、migration_budgetの各6回の成功数は、lowで5/6・5/6・5/6(合計18回中15回)、mediumで6/6・5/6・6/6(合計18回中17回)、highで6/6・5/6・6/6(合計18回中17回)、xhighで3タスクとも6回中6回(合計18回中18回)で、lowを基準とした出力トークンの比率はlowが1.0倍、mediumが5.4倍、highが5.7倍、xhighが7.7倍でした。
本番環境では、採点の基準となる既知の正解はありませんが、各実行が使った出力トークン数とツール呼び出し数は分かります。これらの数値は運用上の有用なシグナルになります。品質の測定と並べて運用上のシグナルを得るため、reasoning effortのレベルごとに出力トークン数とツール呼び出し数を監視します。各推論の強度において、正しい実行は推論量の明確な下限を上回っています。`medium` 以上の正しい実行はすべて出力トークンを少なくとも1,739使っており、典型的な実行は数千の出力トークンでした。ツール呼び出しが一度もない実行や、その水準の通常より出力が大幅に少ない実行は、レビューのためにフラグを立てる価値があります。ベースラインは、採点済みの実行からタスクごと・推論の強度ごとに較正し、その後、採点していない実行に適用します。フラグは、調べるか再実行するきっかけとして扱います。推論の強度が `low` ではどの実行も短いため、出力量のシグナルは弱くなります。そのため、スポットチェックと組み合わせます。ツール呼び出しはどの推論の強度でも1回の実行あたり17.2〜18.7回でほぼ一定で、エージェントは強度に関わらず同じ事実を収集しており、変わったのは推論の量で、出力トークンはlowの1,184からxhighの9,147へ増えました。
| 実行ごと | low | medium | high | xhigh |
|---|---|---|---|---|
| 平均出力トークン | 1,184 | 6,430 | 6,778 | 9,147 |
| Output tokens relative to low | 1.0x | 5.4x | 5.7x | 7.7x |
| 平均ツール呼び出し数 | 17.2 | 18.7 | 17.8 | 18.1 |
| 経過時間の中央値 | 18s | 98s | 89s | 106s |
元記事の表を転載しています(見出しは日本語にしています。値は原文のままです)。出典: 元記事
推論の強度の選び方、測定の限界、運用とコスト
推論の強度はタスクの種類に合わせる必要があります。探索・最適化・仮説の検証を伴うタスクは `medium` 以上で最も恩恵を受けます。一方で、単一の経路をたどるタスクや、答えが下流でレビューされるタスクは、`low` で効率よく実行できます。推論の強度はエージェント単位ではなくリクエスト単位で設定します。これにより、計画や検証のステップは高い強度で、ツール結果の整形のような機械的なステップは `low` で実行することができ、高い強度の信頼性の多くを低いトークンコストで得られます。3つのタスクに共通するパターンとして、追加の推論は、エージェントが1本の道筋をたどって結果に至るのではなく、複数の候補の答えを比較検討しなければならない場面で最も価値が高くなります。やや低い完了率が許容できる場合や回答が下流で確認される場合はlowが効率的な選択肢で、毎回最初から正しい回答が必要な場合はより高いレベルのほうが安全なデフォルトです。
この測定では、タスクと推論の強度の組み合わせごとに6回の実行を行いました。この結果は3つのタスクにわたって一貫した方向性を示すには十分ですが、信頼区間を出すには足りないため、強度間の差は目安として扱います。xhighでは3つのタスクの全18回の実行が正解でmediumとhighはそれぞれ18回中17回正解でしたが、各タスク・各レベルの実行は6回ずつなのでレベル間の差は統計的に確定的というより示唆的なものにとどまり、一方でその傾向は3つのタスクすべてで一貫していました。
この測定は合成環境で行われました。この環境では、ツールがコードで生成したデータを読み込むことで、各タスクの答えがちょうど1つであることの証明と自動採点を可能にしています。実際のツールには遅延・部分的な結果・エラーが加わりますが、ここではそれらをテストしていません。
実行時間の中央値は、推論の強度のlowで18秒からxhighで106秒まででした。この数値は長期の作業を縮小した代替であり、手法は転用できますが、絶対的な数値は転用できません。3タスク(各6回、計18回)の成功数はlowが15/18、mediumが17/18、highが17/18、xhighが18/18で、実行時間の中央値はlowが18秒、mediumが98秒、highが89秒、xhighが106秒でした。
自分のタスクで、繰り返しを含めて測定を行います。設定ごとに1回の実行では観測が1つにしかならず、各構成を何度か繰り返すと一貫性が分かります。推論量を監視します。推論の強度別に追跡した、実行ごとの出力トークンとツール呼び出しは、結果が使われる前に実行をレビューする早期のシグナルになります。推論量を大規模に監視する場合、Amazon CloudWatch のメトリクスでトークン使用量の集計ビューが得られ、これによりレベルごとのベースラインを対象にアラームを設定できるようになります。
この測定で示したのはトークン数であり、コストではありません。通貨に換算するには、Amazon Bedrockの料金ページにある、使用する推論プロファイルとティアの現行料金を適用する必要があります。GlobalとUS Geoのプロファイルは料金が異なり、FlexとPriorityのティアには乗数が適用されます。
大量の呼び出しを行うエージェントでは、リトライを設計の一部として扱うべきです。リクエストのタイムアウトを設定し、ジッターつきの指数バックオフを使い、`Retry-After` ヘッダーが返されたらそれに従い、リトライ可能なエラーだけを再試行します。オンデマンドのスループットは時間とともにスケールアップするため、大量の呼び出しを行う新しいワークロードは最初から全速で始めず、徐々に立ち上げる必要があります。モデル呼び出しログ(Model invocation logging)を使用すると、リクエストとレスポンスのデータが Amazon Simple Storage Service (Amazon S3) または Amazon CloudWatch Logs に書き込まれ、事後に実行の全トランスクリプトを確認できます。テスト中に Amazon S3 へのモデル呼び出しログを有効にした場合は、不要になったオブジェクトを削除してください。
AWS Cost Explorer と AWS Cost and Usage Report のコスト明細は、使用量をモデルごとに分けて示します。タスクごとのトークン数と組み合わせると、単位あたりの経済性と請求総額の両方が分かります。サービスのティアはリクエストごとに設定するため、1つのデプロイメントから、夜間の分析は Flex ティア、対話型のリクエストは Priority ティアで送ることができます。高い推論の強度で動くワークロードでは、ティアの選択がコストに対するさらなる調整手段になります。ブログ記事に掲載されているコード例を実行しても、リクエストごとのトークン使用量を除き、課金対象の AWS リソースは作成されません。クロスリージョン推論は、長時間の実行が利用できる容量プールを広げます。Global プロファイルは、選択した商用 AWS リージョンから提供され、通常はジオグラフィックルーティングよりトークンあたりの価格が低いです。US プロファイルは処理を米国内に保ちます。選択はコストだけでなく、データレジデンシー要件にも基づいて行います。
探索を必要とする3つのタスクでは、エージェントは72回の実行のうち67回で正解し、`xhigh` ではすべての実行が正解でした。推論の強度はリクエストごとに設定できるため、各ステップにおける徹底度とトークンコストのトレードオフ上の位置を自由に選べます。3つのタスク合計の正解数は、lowが18回中15回、mediumが18回中17回、highが18回中17回、xhighが18回中18回でした。