AWSは2026年10月20日、Amazon Bedrockで提供されているAnthropicのClaudeモデルにおいて、構造化出力をサポートしたと発表しました。Amazon BedrockにおけるClaudeモデルの構造化出力対応に関するAWS公式発表によると、bedrock-runtimeとbedrock-mantleのエンドポイントで、定義したスキーマに適合するJSON形式の応答を受け取れるようになり、独自のテキスト解析や再試行処理を減らせるとしています。

スキーマ指定とモデルごとの対応条件

これまでAIモデルの出力を業務システムで利用する場合、プロンプトでJSON出力を指示していても、余計な説明文が混ざったり、必要な項目が欠落したりする例外への対処が必要でした。今回の構造化出力では、出力させたいデータ構造をJSON Schemaで指定することで、型に沿った必須項目の確実な出力を目指せます。

実装の補足仕様をまとめたBedrockにおけるClaudeモデルの構造化出力公式ドキュメントによると、機能の利用形態には主に2つの方式があります。1つはデータ抽出やレポート作成向けに回答形式全体をスキーマで制約するJSON Schema出力形式です。もう1つは、エージェント機能や外部関数呼び出し向けに、ツール定義へstrict: trueを追加して引数の形式をスキーマ通りに制限するStrict tool useです。これらは個別にも併用しても利用できます。

ただし、利用にあたっては前提条件の確認が必要です。発表では幅広いモデルの対応がうたわれていますが、公式ドキュメントにはモデルやエンドポイントごとに対応状況が異なると明記されています。bedrock-runtimeのみ対応しているモデルや、bedrock-mantleにも対応しているモデルがあるため、自社で利用予定のモデルとリージョンが求める接続方式に対応しているか、事前の確認が欠かせません。

応答完了の判定とトークン上限への備え

構造化出力を利用する場合でも、AIの出力をそのまま無条件で確定データとして保存することは避けるべきです。公式ドキュメントに掲載されているInvokeModelのコード例では、応答の終了理由（stop_reason）に応じた分岐処理が示されています。

具体的には、stop_reasonが通常終了を示すend_turnである場合にのみJSONを解析します。トークン上限に達したことを示すmax_tokensの場合は「応答が打ち切られたため、max_tokensの値を増やして再試行する」旨の案内を表示する処理にとどまる構成です。上限を変更して再試行する処理自体は、接続側で別途実装する必要があります。スキーマに沿った形式で生成が始まっても、出力が途中で途切れてしまえば完全なデータとしては扱えません。業務システムへ連携する前段階で、終了理由を検証し、未完了のデータを誤って登録しない設計を組み込む必要があります。

問い合わせメールから顧客管理へ連携する設計案

「安全な登録連携の設計案」の図。原文、構造化候補、完了判定、原文照合、保存APIの順に矢印で接続され、自動登録を行わない流れを示すイラスト

公式資料では、請求書やメール、文字起こしなどから項目を抽出し、データベースやCRM（顧客管理システム）へ取り込む用途が挙げられています。国内の法人向けサービス企業が、問い合わせメールから顧客管理の登録候補を作成する業務を例に、具体的な接続の分担を考えてみます。

この仮定の業務では、届いたメールの本文から会社名、担当者名、相談種別、希望日程などをAIで抽出する想定です。そのうえで、顧客管理画面に新規登録の候補値として初期表示させる運用が考えられます。スキーマに適合することと、抽出内容が原文に忠実であることは別だという視点が重要です。例えば、問い合わせ本文に希望日程が書かれていない場合、スキーマの制約を満たすためにAIが架空の値を補ってしまうリスクが考えられます。原文での情報不足をスキーマ上でどう表現するかや、保存先の入力条件とどう整合させるかは、個別に設計しておく必要があります。

そのため、いきなり顧客管理のデータベースへ自動保存するのではなく、まずはJSON Schemaで既存システムの項目に合わせた入力候補を作成し、画面上で問い合わせ原文と候補値を並べて担当者が確認する設計が現実的です。原文に記載がない項目は要確認として扱い、人が確認ボタンを押した段階で既存の保存APIを呼び出す構成にすることで、誤った情報の登録抑制や入力負担の軽減を狙えます。ただし、確認作業を含めて実際にどの程度誤りを防ぎ工数を減らせるかは、過去のサンプルメールなどを用いて事前に評価・検証しておくことが欠かせません。

社内で進める整理と連携開発の相談

社内でこの仕組みを検討する場合、まずは現在の顧客管理で使われている項目名、データ型、必須条件を洗い出す作業から着手できます。あわせて、過去のサンプルメールを用意し、本文に含まれている情報と不足しがちな情報を分類しておくと、どのようなスキーマ定義や確認画面が必要になるかを具体的に見極めやすくなります。

入力候補の形式設計から、問い合わせ原文との照合手順、既存の顧客管理システムや社内ツールと連携するAPIの実装まで、業務に合わせた仕組みの具体化には専門的な検討が必要な場面もあります。デノフのサービス案内では、AIを活用する業務の整理やツール選定、顧客管理をはじめとする業務システムの設計・開発を一貫して案内しています。AIの出力形式を既存システムへどう安全につなぎ込むかお悩みの際は、デノフへの相談窓口よりお気軽にご相談ください。