- Claudeの全モデルがBedrockの両エンドポイントで構造化出力に対応
- 制約付きデコーディングでトークン生成時にスキーマ違反を防ぐ
- 初回はスキーマのコンパイルで遅延、文法は24時間キャッシュ
何が発表されたか
AWSは、Amazon Bedrock上でAnthropicのClaudeモデルを利用する際に、構造化出力(Structured outputs)を全モデルで使えるようにしたと発表しました。対象はbedrock-runtimeとbedrock-mantleの両エンドポイントで、モデルが利用可能なリージョンが対象とされています。Boto3経由でもMessages API経由でも、あらかじめ定義したJSONスキーマに適合するJSON応答を受け取れるようになります。
これまではJSON形式で返すよう指示しても、出力が崩れた場合に備えてパース処理やリトライ、後処理を実装する必要がありました。構造化出力では、そうした追加コードが不要になるとしています。AWSは用途として、決算資料やコンプライアンス文書からの項目抽出、臨床メモの電子カルテ(EHR)への変換、商品カタログの整備、契約書の解析、サポートチケットの振り分けなどを挙げています。
生成時にスキーマを強制
構造化出力の中心にあるのは、制約付きデコーディング(constrained decoding)と呼ばれる手法です。モデルがトークンを生成する各段階でスキーマに違反する候補を排除するため、生成後に検証するのではなく、そもそも違反する出力が生成されません。AWSはこれを、出力形式が「確率的から決定的に変わる」と説明しています。
処理は4段階で進みます。まずBedrockがスキーマをJSON Schema Draft 2020-12のサポート対象サブセットに照らして検証し、新しいスキーマであれば文法(grammar)をコンパイルします。コンパイル結果はアカウント単位で24時間キャッシュされ、同じスキーマを使う2回目以降のリクエストは最小限のオーバーヘッドで実行できます。
フィールドの型は強制され、必須フィールドは必ず含まれます。加えて、スキーマに定義したフィールドだけが出力されるため出力トークン数が減り、大量のリクエストを処理するワークロードでは推論コストの低減につながる可能性があるとしています。
2つのエンドポイント
bedrock-runtimeではInvokeModel APIを使い、Anthropicネイティブのリクエストボディにoutput_config.formatとしてスキーマをJSONオブジェクトで渡します。バッチ推論に対応し、bedrock-runtimeではクロスリージョン推論も追加設定なしで使えるとされています。リアルタイム用途では、構造化された応答を型付きイベントとしてストリーミングできます。
bedrock-mantleは、サーバー側ツールやバックグラウンド推論、状態を持つ会話などエージェント用途を想定したエンドポイントです。こちらではツール定義にstrict: trueを付けることで、ツールの引数が入力スキーマに完全に一致することが保証されます。モデルがスキーマ外のフィールドを追加できないため、多段のエージェント処理で入力不正による失敗を抑えられます。
実装時の注意点
スキーマには守るべき条件があります。すべてのオブジェクトにadditionalProperties: falseを指定しないと、スキーマが受け付けられません。フィールド名と説明は具体的に書き、値の候補が限られる場合はenumで制約することが推奨されています。まずは最小限の必須フィールドから始め、段階的に複雑さを加える方が、コンパイルが速くデバッグも容易だとしています。
スキーマの構造を変えるとキャッシュが無効になり、再コンパイルが発生します。名前や説明だけの変更であればキャッシュは維持されます。また、応答がスキーマに従わないケースとして、安全性の理由による拒否(refusal)とmax_tokensへの到達の2つが挙げられており、どちらもstop_reasonを確認して処理する必要があります。
| 項目 | bedrock-runtime | bedrock-mantle |
|---|---|---|
| 主な呼び出し方法 | Boto3・InvokeModel API | Messages API |
| スキーマ指定の例 | output_config.format にJSONオブジェクトで指定 | ツール定義に strict: true と input_schema を指定 |
| クロスリージョン推論 | 対応(追加設定不要) | 記事に記載なし |
| 記事で示された例 | 問い合わせメールからの項目抽出、チケット分類 | 天気取得ツールの呼び出し |
Structured outputs use constrained decoding to enforce your JSON schema during token generation, not after the fact. The model doesn't produce tokens that would violate your schema.
構造化出力は制約付きデコーディングを使い、生成後の事後処理ではなくトークン生成の最中にJSONスキーマを強制します。モデルはスキーマに違反するトークンを生成しません。
今後の見通し
構造化出力は、LLMの応答をアプリケーションのデータモデルに直接つなぐための基盤になります。今後は、対応するJSON Schemaのサブセットが広がるのか、スキーマのコンパイルやキャッシュに関する課金や制限がどうなるのかが判断材料になりそうです。日本企業にとっては、日本語の文書抽出やチケット分類でどこまで精度が出るかが実用性を左右します。具体的なリージョンごとの提供状況と、日本語データでの検証結果が公開されれば、導入判断がしやすくなるとみられます。
日本の開発者・IT企業にとっての意味
LLMの出力をJSONで受け取り、アプリケーションに取り込む実装では、これまでパース失敗や項目欠落への備えが不可欠でした。構造化出力はその備えの多くを不要にするため、PoCで終わりがちだった抽出・分類処理を本番運用に移すハードルを下げると考えられます。日本のIT企業では、請求書や契約書、問い合わせメールなど日本語文書の処理を社内システムに組み込む際に、リトライや後処理のコードを減らせる可能性があります。エージェント用途ではツール引数の不整合がワークフロー全体の失敗につながるため、strict指定の効果は小さくありません。一方でスキーマ設計の巧拙が品質を左右し、additionalPropertiesの指定漏れやstop_reasonの扱いなど、実装側で押さえるべき点は残ります。
気になる点
- 日本のリージョンでも使えますか
- 原文は「モデルが利用可能なリージョン」で使えるとしているだけで、国・リージョンの一覧は示していません。bedrock-runtimeではクロスリージョン推論に追加設定なしで対応するとされているため、モデルが提供されているリージョンを選べば利用できる可能性があります。最新の対応表はAWSのドキュメントで確認が必要です。
- コストは下がりますか
- スキーマに定義したフィールドだけが出力されるため出力トークン数が減り、大量処理では推論コストの低減につながる可能性があると記載されています。一方、具体的な料金や、スキーマのコンパイル・キャッシュに追加課金があるかは原文に記載がなく、現時点では公表されていないとみられます。
- 既存のプロンプトでJSON指定している実装から移行できますか
- スキーマをoutput_config.formatに渡す形へ変更する必要があります。移行時の注意点として、すべてのオブジェクトにadditionalProperties: falseを付けること、stop_reasonを確認して拒否とmax_tokens超過を処理することが挙げられています。スキーマの構造を変えるとキャッシュが無効になり再コンパイルが走ります。
用語解説
- 構造化出力
- モデルの応答を、あらかじめ定義したJSONスキーマに沿った形式で返させる機能。
- 制約付きデコーディング
- トークン生成の各段階でスキーマ違反となる候補を除外し、適合する出力だけを生成させる手法。
- JSONスキーマ
- JSONデータの構造や型、必須項目を定義する仕様。今回はDraft 2020-12のサブセットが対象。
- 文法コンパイル
- スキーマを生成時の制約として使える形に変換する処理。初回リクエストで発生する。
- stop_reason
- モデルが生成を止めた理由を示す値。拒否やmax_tokens超過の検知に使う。
出典
Structured outputs for Anthropic Claude models on Amazon Bedrock
AI導入も顧問も、お任せください
何から手をつけるか、どこまでAIに任せるか。自社の業務に合わせて整理し、導入から運用まで伴走します。相談だけでも構いません。
AI導入について相談する