AWS、Amazon Bedrock（ベッドロック）のClaude（クロード）全モデルで構造化出力を一般提供JSONスキーマ出力と厳密なツール利用、ただしbedrock-mantleの扱いはブログと技術文書で食い違い

AWSは2026年10月19日（米国太平洋時間15時32分、日本時間20日8時台）、Amazon Bedrock（アマゾン ベッドロック）で、Anthropic Claude（クロード）の全モデルが構造化出力に対応し、一般提供になったと機械学習ブログで発表しました。JSONスキーマに沿った応答を返す「JSON Schema output format」と、ツールの引数をスキーマで縛る「strict tool use」の2つが対象で、AWSは bedrock-runtime と bedrock-mantle の両エンドポイントで使えると説明しています。ただし同日に取得した技術文書には、bedrock-mantle の Messages API では出力形式の指定が400エラーになるという記述があり、ブログと食い違っています。

3行まとめ

1. AWSは2026年10月19日、Amazon BedrockのClaude全モデルで、JSONスキーマ出力と厳密なツール利用（strict: true）を一般提供と発表
2. AWSによると、制約付きデコーディングで生成中にスキーマを強制し、文法のコンパイル結果は24時間キャッシュ。新しいスキーマの最初のリクエストは遅くなりうる
3. ブログは「両エンドポイント対応」、技術文書は「bedrock-mantleのMessages APIでは output_config.format が400エラー」と書き、食い違いが残る

本記事の内容は、日本時間2026年10月20日8時台に公式ページで確認したものです。

何ができるようになったのか

AWSのブログによると、構造化出力は制約付きデコーディング（constrained decoding）で、トークンを生成している最中にJSONスキーマを強制します。「出力のあとで直す」のではなく、スキーマに違反するトークンをモデルがそもそも出さない作りで、ブログはこれを「出力の整形が確率的なものから決定的なものに変わる」と説明しています。

使える仕組みは2つです。

技術文書によると、2つは単独でも、同じリクエストの中で組み合わせても使えます。

ブログが挙げる効果は次のとおりです（いずれもAWSの説明です）。

• 応答は常に有効なJSONで、JSON.parse() のエラーが起きない
• フィールドの型が強制され、必須フィールドは必ず入る
• スキーマ違反のためのリトライが要らない
• 出力がスキーマにあるフィールドだけに絞られるため、出力トークン数が減り、大量処理では推論コストが下がりうる

使い道としてブログは、決算書やコンプライアンス文書からの項目抽出、診療記録の電子カルテ（EHR）への変換、商品カタログの整形、契約書の主要条項の分析、サポートチケットの振り分けなどを挙げています。

使い方とリクエストの形

ブログの例では、InvokeModel API（bedrock-runtime）にAnthropic形式のリクエスト本文を渡し、スキーマを output_config.format にJSONオブジェクトとして入れます（JSON文字列ではありません）。種類は "type": "json_schema" です。技術文書は、APIごとの指定場所を次のように書いています。

ブログのコード例では、顧客メールから氏名・メールアドレス・関心のあるプラン・デモ希望の有無を取り出すスキーマを定義し、モデルIDに global.anthropic.claude-sonnet-5-5 を指定しています。2つ目の例は global.anthropic.claude-haiku-5-5 で、サポートチケットを category・priority・sentiment・escalate・reason に分類します。ブログはClaude Haiku 5.5について、要約、コンパクション、データベースへの問い合わせ、分類のような素早さが要る繰り返しの多い処理を確実にこなすと説明しています。

どちらの例も、解析の前に stop_reason を確かめる書き方です。

スキーマを書くときの条件

ブログと技術文書が挙げる条件は次の点です。

• すべてのオブジェクトに additionalProperties: false を付ける。ブログは「必須で、ないとスキーマが受け付けられない」と書いています
• 対応するのはJSON Schema Draft 2020-12のサブセット
• 対応しない機能を含むスキーマは、技術文書によると400エラーで即座に拒否される（ただし次の節のとおり、ブログはAPIが受け付けて強制しないキーワードもあると書いています）

対応する機能は、基本の型（object・array・string・integer・number・boolean・null）、enum（文字列・数値・真偽値・nullのみ）、const、anyOf・allOf（制限あり）、内部参照の $ref・$def・definitions、文字列フォーマット（date-time・time・date・duration・email・hostname・uri・ipv4・ipv6・uuid）、minItems（0と1のみ）です。

「強制されない」ものがある──スキーマの限界

ブログは「Not supported」の見出しで、次のキーワードは「APIに受け付けられるが、生成時には強制されない」と書いています。リクエストは成功し、モデルがその制約に違反する値を返すこともあるため、アプリ側で検証するよう求めています。

• 再帰的なスキーマ
• 外部への $ref
• 数値の制約（minimum・maximum・multipleOf）
• 文字列の制約（minLength・maxLength）
• additionalProperties を false 以外にすること

ただし技術文書は、同じ5項目を「not supported」として挙げたうえで、対応しない機能を含むスキーマは400エラーで即座に拒否されると書いており、ブログの「受け付けられる」とは説明が異なります。どちらの説明でも、これらの制約が生成時に守られる前提にはできません。たとえば年齢に minimum: 0 を付けても、ブログの説明では生成時には効きません。

また、スキーマに沿わない応答が出る場面として、ブログは次の2つを挙げています。

1. 拒否（安全上の理由でモデルが断った場合）
2. max_tokens に達して、書き終える前に打ち切られた場合

どちらも stop_reason で見分けて処理するよう、ブログは「全レスポンスで確認する」ことを推奨しています。技術文書には、引用（citations）との併用は非互換で400エラーになる、という注意もあります。

最初のリクエストが遅い理由と24時間キャッシュ

ブログによると、新しいスキーマの最初のリクエストでは、Amazon Bedrockが文法の成果物（grammar artifact）をコンパイルしてから生成を始めるため、時間がかかることがあります。コンパイル済みの文法はアカウント単位で、最初のアクセスから24時間キャッシュされます。スキーマの構造を変えるとキャッシュは無効になり、name や description だけを変えた場合はキャッシュが残ると書かれています。

この所要時間の書き方も、2つのページで温度差があります。

実際の所要時間の測定値は、どちらのページにもありません。ブログは、基本的なスキーマほど早くコンパイルできるとして、最小の構成から足していくこと、リクエストをまたいで同じスキーマを使い回すことを勧めています。技術文書によると、キャッシュされた文法はAWS管理キーで暗号化されます。

どのAPI・どのエンドポイントで使えるのか

技術文書の対応表では、次のとおりです。

ブログも、バッチ推論に対応し、bedrock-runtime ではクロスリージョン推論にも対応し、リアルタイムが必要なら型付きイベントとしてストリーミングできると書いています。

ブログと技術文書の食い違い

ここが今回の発表で最も読み違えやすい点です。

• ブログ冒頭: 「Amazon Bedrock now supports structured outputs for all Anthropic Claude models, on both the bedrock-runtime and bedrock-mantle endpoints, where the model is available.」（Amazon Bedrockは、モデルが提供されている場合、bedrock-runtime と bedrock-mantle の両方のエンドポイントで、すべてのAnthropic Claudeモデルの構造化出力に対応しました。）
• 技術文書（Structured outputs のページ）: bedrock-mantle の Messages API は「No」で、「The output_config.format parameter is rejected with a 400 error.」（output_config.format パラメータは400エラーで拒否される）。Claudeで構造化出力を使うには、bedrock-runtime のConverse APIまたはInvokeModel APIを使うこと
• 技術文書（Endpoints のページ）: 同じ趣旨の注意書きがあり、「structured outputs … are not supported on bedrock-mantle」（bedrock-mantle では対応していない）と書く

ブログ側のstrict tool useの例は、AnthropicBedrockMantle クライアントで bedrock-mantle を呼び、ツール定義に "strict": True を付ける形です。一方で、技術文書の注意書きが400エラーとして名指ししているのは output_config.format で、strict tool use を個別に挙げた記述は今回取得した2ページにはありませんでした。ただし Structured outputs のページの対応表は、2つの仕組みを含む「構造化出力」全体について bedrock-mantle の Messages API を「No」とし、Claudeで使うなら bedrock-runtime を使うよう案内しています。strict tool use も含めて、ブログ（使える）と技術文書（対応しない）の記載が割れている状態です。文書側がブログ公開後に更新される可能性もあります。bedrock-mantle で使うつもりの人は、実際に小さなリクエストを送って確かめるのが確実です。

なお、技術文書のEndpointsのページは、多くの新規アプリには bedrock-runtime を勧め、サーバー側ツール（Web検索など）、バックグラウンド推論、Projects、Workspaces が必要なときに bedrock-mantle を使うよう案内しています。トークン単価は同じモデルなら両エンドポイントで同一とも書かれています。

対応モデルと地域・日本での使い方

ブログは「全Anthropic Claudeモデル」と書く一方、技術文書は対応モデルの一覧を持たず、「models at a glance」でモデルごとに確認するよう案内しています。今回取得したページにモデルの一覧表はありません。さらに技術文書には次の例外が載っています。

Some Geographic cross-Region inference profiles don't support structured outputs for every model. For example, structured outputs aren't supported for Claude Haiku 4.5 through the India (in.anthropic) inference profile.

（一部の地域別クロスリージョン推論プロファイルは、すべてのモデルで構造化出力に対応していません。たとえばClaude Haiku 4.5は、インド（in.anthropic）の推論プロファイル経由では未対応です。）

日本のリージョンや日本語での扱いについて、今回取得した3ページには記載がありませんでした（「Tokyo」「Japan」「ap-northeast」で3ページを検索して、該当なし）。日本から使うときにどのプロファイルで使えるかは、モデルカードで個別に確認する必要があります。ブログのコード例は us-east-1 を指定しています。

料金は

構造化出力そのものの追加料金は、今回確認した3ページには書かれていませんでした（「price」「pricing」「charge」を検索）。書かれているのは次の2点です。

• ブログ: スキーマで定義したフィールドだけに出力が絞られ、出力トークン数が減って、大量処理では推論コストが下がりうる
• 技術文書: 同じモデルのトークン単価は bedrock-runtime と bedrock-mantle で同一。最新の料金はAmazon Bedrockの料金ページを参照

リクエスト本文のスキーマはConverse APIのペイロードサイズに数えられる、とブログは書いています。

筆者が公式ページで確認して気づいたこと

この記事は、検知した日本時間2026年10月20日8時37分に、ブログと技術文書2ページを取得して読み比べて書いています。ブログだけを読むと「両エンドポイントで使える」と読めますが、同じ時刻に取得した技術文書2ページには、bedrock-mantle で output_config.format が拒否されるという注意書きが別々に載っていました。文書が古いのか、ブログの書き方が広いのかは、取得したページからは判断できません。筆者はBedrockでこの機能を実際に動かしてはおらず、どちらが現在の挙動かも確かめていません。

今回の発表から言えないこと

• 実際の成功率や遅延: ブログに、スキーマ準拠率や初回コンパイルの秒数などの測定値はありません。「常に有効なJSON」はAWSの説明です
• 内容の正しさ: 型や必須項目が守られることと、抽出した値が正しいことは別です。ブログの用途例（決算書、診療記録、契約書）でも、値の検証をどうするかは書かれていません
• 対応モデルの全体像: 一覧は別ページで、今回は取得していません
• bedrock-mantle での最終的な挙動: 上記のとおり、ブログと技術文書で記載が割れています

AWSのBedrock関連では、同じ日に動画言語モデルがタイムスタンプ付きJSONを返す提供も出ています。構造化した返答を前提にしたい場合は、TwelveLabsのPegasus 1.5のBedrock提供の記事もあわせてどうぞ。

出典と確認時刻

• Structured outputs for Anthropic Claude models on Amazon Bedrock（AWS Machine Learning Blog）（公開表示 2026-10-19 15:32 -08:00、日本時間2026年10月20日8時37分に取得）
• Get validated JSON results from models（Amazon Bedrock User Guide）（日本時間2026年10月20日8時37分に取得）
• Inference endpoints supported by Amazon Bedrock（Amazon Bedrock User Guide）（日本時間2026年10月20日8時37分に取得）

本記事は続報があり次第更新します。特に bedrock-mantle の扱いは、AWSが文書かブログを直した時点で書き換えます。