AIの構造化出力とは？「形式が正しい」と「内容が正しい」の違い

回答の形をあらかじめ決める

人が読む要約なら、多少表現が違っても意味を理解できます。一方、システムが「問い合わせ種別」という項目を探す場面で、回答のたびに項目名や構成が変わると、そのまま処理しにくくなります。

構造化出力は、AIの応答を決めた構造に合わせるための機能です。たとえば、項目名、文字列や数値といった値の型、必須項目などをスキーマとして指定します。JSONは、そのようなデータを表す形式の一つです。

AnthropicのStructured outputsの公式資料では、Claude APIでJSONの出力形式を指定する機能と、ツールの入力をスキーマに合わせる機能が説明されています。ここで扱う製品仕様は、同APIのものです。他の製品では対応範囲が異なります。

問い合わせを三つの項目に分ける例

仮に、問い合わせ文から「種別」「希望日」「確認が必要か」を取り出すとします。後続の処理は、その結果をもとに担当者の確認画面を作る想定です。

「来週あたりに相談したいです」という文に対し、AIが具体的な日付を埋めれば見た目は整います。しかし、送信日時や曜日の希望が分からなければ、その日付を確定情報として扱えません。

そこで、最初に空欄や不明の扱いを決めます。これは公式資料の推奨構成を再現したものではなく、誤った確定を避けるための設計例です。

分類を増やす前に、判断できない問い合わせをどこへ送るかを決めておくと、無理にどれかへ当てはめる必要が減ります。確認対象の内容を、人が読める状態で残すことも大切です。

正しいJSONでも、誤った判断は入り得る

構造の検査で分かるのは、主にデータの形です。「希望日が文字列である」ことを確かめても、その日が問い合わせ者の希望と一致するかまでは分かりません。

同じように、選択肢に含まれる種別が返ってきても、分類が適切とは限りません。形式の検査と、元の文章との照合は、それぞれ必要です。

担当者の確認を省いて自動実行へつなぐほど、この区別が重要になります。予約を確定するなら空き状況、数量を登録するなら許容範囲など、業務側で満たすべき条件を別に検査します。

まず確認画面への入力補助として使い、どの種類の問い合わせで修正が多いかを見る進め方もあります。評価用の具体例を用意する方法は、AIの回答を評価するための基本で説明しています。

応答を受け取れない場合も決めておく

構造化出力を使えば、どんな応答も常に指定どおりに完成する、と考えるのは早計です。前掲のClaude公式資料では、拒否による応答や、出力上限で途中終了した場合などの例外が説明されています。

システム側では、正常に完了したか、必要な項目がそろったかを確認し、不完全な応答を通常の結果として登録しないようにします。

再試行する場合も、同じ依頼を何度も実行してよいかを分けて考えます。分類のやり直しと、外部システムへの登録のやり直しでは、重複実行の影響が違うためです。

実装を担当する人には、成功した例に加えて「不明」「拒否」「途中終了」のときに画面や処理がどうなるかを確認すると、運用のイメージが具体的になります。

形をそろえた先に、確認の基準を置く

構造化出力は、AIの回答をシステムが扱える形へそろえる助けになります。内容の正しさや業務上の実行可否まで保証する機能ではありません。

取り出す項目を少数に絞り、不明の扱いと人が確認する条件を先に決める。そこから始めると、整ったデータをそのまま信じてしまう失敗を避けやすくなります。