AIの出力形式はどう選ぶ？JSON・項目の型・原文との一致を分ける

01

返答を人が読むのか、項目として受け取るのか

人が読んで直す下書きなら、まず文章で希望の形式を伝えることから始められます。一方、アプリが人数や開始時刻を項目として受け取るなら、項目名と型、未定の値の扱いを先に定めます。JSONを出してもらうだけで受取条件が決まるわけではありません。

回答そのものを決まった項目で受け取る場合と、アプリ側の関数へ渡す引数を作る場合も分けます。後者は「どの操作へ渡すための引数か」という接続先を持ちます。引数が届いたことと、その操作を実行したことは別です。

ここでのAPIの説明は、2026年10月13日に確認したOpenAI公式文書のResponses APIを対象にします。比較用のモデルは、文書に対応が示される固定名 gpt-4o-2024-08-06 です。最新モデルの推奨や利用者のアカウントでの提供確認ではありません。実装時には使うAPI・モデル・設定をあらためて固定してください。Structured Outputsの公式ガイド、モデルの公式ページ

02

同じ打合せメモから、四つの受取項目を決める

元メモの全文は次の一文です。

10月20日に6人で社内打合せ。開始時刻と部屋は未定。

日付を勝手に年月日へ変えず、元の表記を残します。年とタイムゾーンは書かれていません。人数は整数の6、開始時刻と会議室は未定なので、この教材では null を使います。

{"希望日表記":"10月20日","人数":6,"開始時刻":null,"会議室":null}

このデータは、原文に沿う四項目の見本です。打合せが正式に決まったことや会議室を確保したことの証拠にはなりません。「希望日表記」として保持することで、確定日時との混同を避けます。

03

JSONの文法、項目の型、原文の値を別々に見る

三つの確認を一つの合否にまとめると、どこが違うか分からなくなります。次の候補はすべて記事編集で作った比較例です。人数以外の三項目は上の見本と同じです。

文字列の "6" と整数の 6 は、JSON上で別の型です。見た目に同じ数字でも受取条件を満たすとは限りません。逆に整数の8は型条件を満たしますが、原文にない人数です。型が合うという理由だけで保存や予約へ進めないようにします。

未定の開始時刻や会議室も、空欄を嫌って0や仮の部屋名へ埋めません。必要な項目が存在することと、その値が確定していることを分けます。誰が決める情報なのかを確認し、決まるまでは未定として残します。

{"希望日表記":"10月20日""人数":6,"開始時刻":null,"会議室":null}

{"希望日表記":"10月20日","人数":"6","開始時刻":null,"会議室":null}

{"希望日表記":"10月20日","人数":8,"開始時刻":null,"会議室":null}

{"希望日表記":"10月20日","人数":6,"開始時刻":null,"会議室":null}

PC原寸画像を開くスマートフォン原寸画像を開く

図の内容を文字で読む

10月20日に6人で社内打合せ。開始時刻と部屋は未定。

編集した候補	JSON文法	項目の型	原票の値
カンマを一つ抜く	文法：不可	型：未判定	原票：未判定
人数が文字の「6」	文法：可	整数条件：不一致	型を直して原票へ
人数が整数8	文法：可	型：一致	原票6人：不一致
人数6・未定はnull	文法：可	型：一致	四項目：一致／予約は別

架空の教材。編集した比較例であり、実AI応答・実API試験ではありません。年とタイムゾーンは原票に記載なし。開始時刻・会議室は未定。予約の承認と会議室確保は未実施です。

04

四つの方式を、用途と残る確認で比べる

Responses APIのJSON modeは text.format.type に json_object を指定する方式です。JSONの出力を明示して使いますが、希望のスキーマに合うことまでは保証しません。回答のStructured Outputsは text.format の json_schema と strict: true で形式を定めます。対応スキーマには制限があり、拒否や未完了などの扱いも残ります。形に沿う回答でも内容の誤りはあり得るため、元メモとの照合を省きません。公式ガイドのJSON mode・スキーマ制限・例外の説明

関数側の strict: true は、引数をスキーマへ合わせる設定です。アプリが引数を受け取り、必要な許可を確認し、関数を実行して結果を返す工程は別にあります。この打合せ例でも、四項目の引数を受け取ることを「会議室の予約成功」へ読み替えません。Function callingの公式ガイド

どれを使っても、開始時刻や会議室が元メモにないことは変わりません。方式の比較では、同じ原票と同じ四項目を使うと、形式の違いと内容の違いを混ぜずに見られます。

PC原寸画像を開くスマートフォン原寸画像を開く

図の内容を文字で読む

10月20日に6人で社内打合せ。開始時刻と部屋は未定。

方式	そろえる範囲	残る確認
文章でJSONを頼む	AIへ文章で形式を指示	文法・型・原票の値を確認
JSON mode	JSONとして読める形式	項目と型・原票の値を確認
回答のStructured Outputs	対応するスキーマの回答	原票の値・例外・業務の採用可否
関数引数のstrict	関数へ渡す引数の形	原票の値・実行の許可・実行結果

架空の教材。編集した比較例であり、実AI応答・実API試験ではありません。年とタイムゾーンは原票に記載なし。開始時刻・会議室は未定。予約の承認と会議室確保は未実施です。

05

四項目を必須にし、未定はnullで残す

この教材で使うスキーマの見本は次のとおりです。四項目を必須にし、人数は整数または null、ほかは文字列または null にします。余分な項目は受け取らない条件です。

{
  "type": "object",
  "properties": {
    "希望日表記": {"type": ["string", "null"]},
    "人数": {"type": ["integer", "null"]},
    "開始時刻": {"type": ["string", "null"]},
    "会議室": {"type": ["string", "null"]}
  },
  "required": ["希望日表記", "人数", "開始時刻", "会議室"],
  "additionalProperties": false
}

required は項目を省かない条件です。null を許すことで、必要な項目を残しながら未定も表せます。additionalProperties: false は、定めた四項目以外を増やさない条件です。このスキーマだけで「人数は元メモと同じ6」とまでは判定しません。

公式文書では、対象のStructured Outputsで全項目を必須にし、オブジェクトの追加項目を許さない条件などを示しています。使えるのはJSON Schemaの対応範囲です。一般のJSON Schemaをそのまま全て使えるという説明にはしません。上の見本も、実APIへ送って受理や応答を確認したものではありません。Structured Outputsの対応範囲

06

同じ原票で試し、業務へ渡す前に照合する

採用までの順序は、受取条件を決める、利用するAPIとモデルで設定を確認する、同じ原票を使って試す、形式と原文を照合する、業務の許可と未定事項を確認する、です。実装前に、誰が何を確認するかも決めておきます。

形式の検査で止まったら、その原因を直してから原文を見ます。形式に合っても原文と違うなら、原票へ戻って値を確認します。原文に合っても、未定の項目や予約の許可が残るなら、そのまま業務完了にはしません。

本記事の比較は静的な教材です。実APIの応答、方式ごとの成功率、利用費用、処理時間、導入効果は測定していません。実装時の試験では入力と出力、設定した版、未定や例外の扱い、確認者と実行結果を別々に残してください。出力形式の見本と、実際の業務結果を同じ記録にしないことが大切です。

AIの出力形式は、返答の行き先と受取条件で選びます。JSONとして読めるか、型に合うか、元資料の値に合うかを分けて確認し、関数引数が届いても実行・承認の確認を残します。この打合せ例なら、まず四項目を決め、6人と未定の二項目を保ったまま、実装担当と業務責任者へ確認するところから進められます。

参照：OpenAI公式文書（2026年10月13日確認）。Structured Outputs／Function calling／GPT-4oの対応・固定版。