xAIのGrok 4.3がAmazon Bedrockで一般提供を開始し、Bedrock経由で選べるモデル提供元にxAIが加わった。特徴は推論の努力量をnone/low/medium/highの4段階でリクエストごとに指定できる点で、簡単な処理は努力量を下げてコストと遅延を抑え、難しい処理だけ上げる運用が同一モデルで可能になる。テキストと画像を入力でき、文脈は最大100万トークン、モデルIDはxai.grok-4.3。すでにBedrockを使う組織は、既存の権限・課金・監視の枠組みを変えずに評価候補へ加えられる。

AWSが飲食店の電話注文を自動対応する音声AIの構築手法を、実装コードとともに公開した。前提となる数字は明快で、1店舗あたり1日平均150件の電話、うち約6割が注文・予約客。この6割がまさに定型対応の塊であり、自動化の対象になる。構成は音声対話モデルNova 2 Sonicとエージェント基盤AgentCoreの組み合わせで、挨拶から注文確定まで一連の会話を担う。電話網の音声はSIPゲートウェイ（電話回線とクラウドをつなぐ中継装置、ECSとFargate上で稼働）経由でAIへ渡し、メニューや注文などの店舗システムは標準手順MCPでツールとして接続する。これにより注文ロジックと通話チャネルが分離され、片方を差し替えても他方に波及しない設計になっている。

AWSパートナーのScienceSoftは、医療機関の電話予約を自動化するHIPAA準拠のAI音声予約システムをNova 2 Sonicで構築した。飲食店の注文対応と医療の予約受付は、業務も規制も異なるが、電話音声を受け取り→意図を理解し→バックエンドを操作して確定するという骨格は共通する。飲食側が公開している実装コードとSIP接続の考え方は、規制業種でも土台として流用できることが同日の2記事で示された。自社の電話業務のうち定型対応比率が高い窓口から検証を始める価値がある。

電話AIの体感品質を左右する無音・遅延にも手当てがある。飲食店の実装では通話ごとに独立した仮想環境（microVM）で会話を実行し、着信の呼び出し中にセッションを準備することで応答開始の無音を防ぐ。音声対話は「返答が遅い」と即座に不自然さが露呈するため、この呼び出し中のウォームアップ設計は、実際に顧客電話へ載せる際の必須検討事項になる。

GoogleのGemini Managed Agentsでは、1回のAPI呼び出しから自律型の金融アナリストを組める実例が示された。各エージェントに専用のLinux作業環境が付き、株価などの外部データ連携と公開スキルを組み合わせて分析まで自律実行する。AWS側のAgentCore＋Nova構成が「電話という入出力チャネル」に強いのに対し、Gemini側は「エージェントの起動と作業環境」を1コールに畳む方向で、両者は競合というより組む場面が分かれる。

AWSは複数アカウント・複数リージョンのSageMaker Pipelines実行状況を1つのCloudWatchダッシュボードに集約する構成例を公開した。ハブ・アンド・スポーク設計で、各アカウントの実行状況を中央に集める。モデルを増やしエージェントを本番投入するほど、どのパイプラインがどこで失敗したかを横断で追える基盤が効いてくる。今日の調達・実装ネタと合わせて、運用側の足場としてセットで押さえたい。

自社の電話窓口のうち定型対応比率が高い業務を、業務名・1日あたり件数・想定削減工数の3列で3件書き出す（選定基準＝1日あたり着信件数上位3業務）。飲食実装のSIPゲートウェイ＋MCP分離構成と医療のHIPAA準拠事例の2本を照合し、規制要件の有無を各行に付す。

Grok 4.3の努力量4段階（none/low/medium/high）を、自社のどのユースケースにどの段階を割り当てるかの対応表を作成する（列＝用途名・割当段階・許容遅延・想定コスト差）。既存Bedrock利用があるなら評価候補として1件を選び、比較の判定表を用意する。

自社の電話窓口件数と定型比率を、飲食の「1店舗1日150件・うち約6割が注文・予約」という比率を按分の起点にして試算し、自動化対象件数の月間見積もりを1枚のメモにまとめる。この数字を投資判断の分母として、実装者の3列表と突き合わせる。