AWSはBedrockの両エンドポイントでClaudeのJSON Schema出力と厳密なツール引数を提供しました。モデルが利用できる環境で対応します。 形式の保証と内容の正しさは別の検証対象です。新しいスキーマの初回処理や、応答が打ち切られた場合の扱いも設計する必要があります。 生成時に応答の構造を制約する仕組み AWSは2026年10月19日、Amazon BedrockのClaudeモデル向け構造化出力を紹介しました。対象モデルが利用できる環境で、bedrock-runtimeとbedrock-mantleの両方に対応します。生成の後で形式を直すのではなく、生成中にJSON Schemaへ従うよう制約する仕組みです。応答本文の構造を指定する方法と、ツールに渡す引数を厳密に扱う方法を用意しています。背景には、文章として正しく見えても、必須項目の欠落や型の違いでアプリ連携が失敗する問題があります。構造のずれに対する再試行や後処理を減らすことを狙います。形式を確定しやすくする変更であり、抽出内容の事実性まで自動で保証する機能とは分けて理解する必要があります。 文書抽出とツール連携で確認する対象が変わる 影響を受けるのは、文書から情報を抽出する処理や、問い合わせを振り分けるシステム、ツールを使うエージェントの開発担当者と見られます。アプリが期待する項目と型を明示できれば、下流へ渡すデータの扱いを揃えやすくなります。一方、文字列として有効な商品名でも、参照元と違えば業務上は誤りです。開発側は形式の検証を減らした分だけ、原文との一致や業務の条件を確認する仕組みへ重点を移すことが論点になります。原文のサンプルも応答の終了理由を確認し、長さの上限で打ち切られた場合を分けています。通信の成功だけで処理を確定せず、結果を受け取れる条件を定める必要があると見られます。複数段の自動処理では、どの値を外部データと照合し、どの操作を人へ回すかも、出力の構造と合わせて設計する対象です。 スキーマの変更と初回の遅延を運用へ反映 新しいスキーマは最初の要求で文法へ変換されるため、初回の処理が長くなる場合があります。変換結果はアカウント単位で二四時間保存され、構造を変えると再変換が必要になると説明しています。導入時には通常の応答時間だけでなく、スキーマを更新した直後の挙動を確認することが論点です。また、対応するJSON Schemaは一部に限られるため、既存の定義がそのまま使えるかの確認が必要になります。実務では定義の版と利用するモデルを記録し、更新時の試験対象を明確にする方法が考えられます。出力項目を絞ることでトークン削減につながる可能性はありますが、費用の効果は文書量や要求数で異なります。失敗時の処理を含めた測定を行い、形式の安定が実際にどれだけ手戻りを減らすかを評価することが、採用判断の材料になると見られます。