構造化出力：AIモデルから想定どおりのJSONを得る方法

AIアプリに構造化された出力が必要なのはなぜですか？

AIアプリには構造化された出力が必要です。ソフトウェアは親しみやすい文章を安定して読み取れるわけではなく、毎回、同じ名前と型の同じ項目を必要とするからです。余分な文が一つ入ったり、項目が一つ欠けたりするだけで、アプリの次の処理が動かなくなることがあります。

架空の従業員12人の物流スタートアップ、Parcelwiseを想像してください。開発者のサナは、顧客のメールを読み、注文番号、希望日、新しい住所、返金希望の有無を配送変更フォームに入力するツールを作っています。よくあるメールは次のようなものです。'こんにちは。注文PW-88213ですが、木曜は不在なので、代わりに土曜に届けてもらえますか？または14番の家に預けてください。無理ならキャンセルして返金をお願いします。' 最初のバージョンでは、モデルに'JSONで回答してください'と指示しています。ほとんどの回答は解析できますが、'はい、こちらがJSONです'で始まるものや、フィールド名が'requested_date'ではなく'date'になっているものがあり、日付を'土曜日'と返した回答もあります。

JSONスキーマとは何ですか？なぜ役に立つのですか？

JSONスキーマは、想定するデータを形式的に記述したものです。どの項目が存在し、何が必須で、各項目がどの型で、どの値を許容するかを定めます。モデルにスキーマを与えると、「JSONで回答してください」という依頼が、コードで検証できる契約になります。

サナのスキーマでは、order_referenceは必須の文字列、requested_dateは日付形式の必須の文字列で、日付が指定されていなければnull、new_addressは文字列またはnull、refund_requestedは必須の真偽値と定めています。それ以外の項目は認めません。この最後のルールにより、モデルが解説用の項目を追加するのを防ぎます。

モデルのAPIは、構造化された出力にどのように対応していますか？

主要なモデルのAPIでは、リクエストとともにJSONスキーマを渡すことができ、モデルの出力はそのスキーマに一致するよう制約されます。

それでも検証と再試行が必要なのはなぜですか？

スキーマが制御するのはデータの形式であって、値の正しさではないため、検証は引き続き必要です。形式が完全に正しい応答でも、日付の誤り、架空の注文参照番号、顧客が求めていない返金フラグが含まれることがあります。

2段階で検証します。まず、PythonのPydanticやJavaScriptのZodなどのスキーマライブラリで構造を確認します。OpenAI、Anthropic、Googleのドキュメントはいずれも、こうした方法を例で示しています。次に、業務ルールを確認します。注文参照番号が所定の形式に合い、システム内に存在するか、日付が将来の日付で配送可能日か、住所が配送区域内かを確認します。また、各提供元が説明しているケースにも対応してください。スキーマに従わない可能性がある回答拒否と、最大トークン数の上限によって回答が途切れ、JSONが不完全になるケースです。

再試行は慎重に行います。チェックに失敗した場合は、「requested_dateは日付である必要があります。メールには土曜日と書かれており、注文日は14 Octoberです」のように、具体的なエラーを含めて1回再試行します。再試行は1回か2回までとし、それでも失敗する場合はメールを担当者に回します。

構造化出力には、不十分な例と安定して使える例でどのような違いがありますか？

不十分な実装：プロンプトには「詳細を抽出し、JSONで返してください。」とだけ書かれています。アプリは返された内容をそのまま読み取ります。上記のメールの場合、orderとdateというフィールド、日付の値「土曜日」、返金の値trueを受け取ります。モデルが「そうでなければキャンセルで」を確定した依頼として扱ったためです。フォームに誤った内容が入力され、顧客が望んでいない返金が行われてしまいます。

堅牢な構成では、リクエストにサナが作成したスキーマを含め、厳格モードを有効にします。プロンプトでは、「refund_requestedがtrueになるのは、顧客が無条件で返金を求めている場合のみです」という説明も含め、各フィールドを説明します。モデルは、order_referenceにPW-88213、requested_dateに次の土曜日の日付、new_addressにnull、refund_requestedにfalseを返します。また、サナがまさにこのケースのためにスキーマに追加したconditional_requestには、「土曜日の配達も近隣住民への預け入れもできない場合は返金」と設定します。検証により、注文が存在し、土曜日が配達可能日であることを確認します。メールに条件付きの依頼が含まれているため、ルールに従って担当者に回し、最終判断を任せます。

構造化出力でよくある間違いは何ですか？

最も多い間違いは、形式が正しいJSONならデータも正しいと信じることです。ほかにも、APIにスキーマを強制する機能があるのに指示文だけに頼る、説明のない曖昧なフィールド名を使う、正直な答えがnullである場合にも値を無理に入れさせる、回答の拒否や途中で切れた応答を無視する、何が間違っていたかをモデルに伝えずに再試行する、といった間違いがあります。

構造化出力はTosheo.aiの講座一覧のどこに位置づけられていますか?

構造化出力は、「AIアプリの開発」カテゴリーにある「AIアプリを作る」コースのコード演習レッスンです。スキーマを定義し、APIを呼び出し、応答を検証して再試行を追加する、コード付きの実践版は、登録後にコード演習コースで受講できます。各手順について、採点基準に沿ったフィードバックが提供されます。

出典と対象範囲

OpenAIのAPIドキュメント、構造化出力ガイド、JSONモードとの比較、応答拒否（19 October 2026確認） ↗

Anthropic Claudeドキュメント、構造化出力と厳格なツール使用（確認日：19 October 2026） ↗

Google Gemini APIドキュメント、構造化出力と検証に関する助言（19 October 2026確認） ↗