構造化出力はAI英会話の採点をどう成立させているのか。JSONスキーマに従わせる仕組みと上限を公式仕様から分解した

AI英会話のアプリが採点の内訳を整った表で出せるのは、AIの返事が構造化出力という形で受け取られているからだ。

画面に並んでいるスコアや指摘は、AIが書いた文章を人が読みやすく整形したものではない。

項目名と値の位置があらかじめ決まったJSONが、そのまま返ってきている。

この形を保証する仕掛けを、OpenAI の開発者向けドキュメントは Structured Outputs と呼んでいる。

公式の定義は、渡したJSONスキーマに必ず従う返事を生成させる機能、というものだ。

必須のキーが抜け落ちることも、列挙に無い値がでっち上げられることも心配しなくてよい、と続けて書かれている。

この記事では、Structured model outputs の本文だけを材料に、採点が画面に並ぶまでに何が保証され、何が保証されていないのかを開けていく。

サービスの順位づけはしない。

仕組みの話だけをする。

【結論】AI英会話の構造化出力は、AIの自由を「型」で縛る仕組み

結論から置く。

公式ドキュメントが冒頭に並べている利点は3つだ。

公式が挙げる利点	書かれている中身	学習アプリでの意味
型の安全	形式が崩れた返事を検証し直したり、やり直させたりする必要がない	採点が抜けた画面が出ない
拒否が明示される	安全上の理由による拒否を、コードから判定できる	断られたことを黙って空欄にせずに済む
指示文が単純になる	形式を守らせるために強い言葉を並べる必要がない	プロンプトの調整より設計で解く

⇒ 構造化出力がやっているのは、答えの中身を良くすることではなく、答えの入れ物を決めることだ。

だから採点項目が増えても、画面のレイアウトは壊れない。

そしてこの切り分けは、あとで見るように「入れ物は正しいが中身は違う」という事故も同時に生む。

AI英会話の構造化出力①｜JSONが出ることと、型どおりに出ることは別

公式は、旧来の JSON mode と並べた比較表を置いている。

どちらも、出力が壊れていないJSONになることは保証する。

ただし、こちらが渡した型のとおりに埋まることを保証するのは構造化出力だけだと、表にはっきり書かれている。

観点	構造化出力	JSON mode
有効なJSONになるか	なる	なる
スキーマに従うか	従う	従わない
有効にする書き方	text.format を json_schema にして strict を立てる	text.format を json_object にする

古いほうの落とし穴も、具体的に書かれている。

会話のどこかでJSONを出すよう明示しないと、モデルが空白を延々と吐き続け、トークンの上限に達するまで要求が走り続けることがある、という内容だ。

言い忘れを防ぐために、文脈のどこにも JSON という文字列が見当たらなければ、API側がエラーを返す保険まで用意されている。

⇒ 「JSONで返してね」と頼むのと、型を渡して従わせるのは、別の機能だ。

AI英会話の構造化出力②｜置き場所は2つある。道具の側か、返事の側か

同じ機能でも、載せる場所が2通りある。

公式ドキュメントが挙げているのは、関数呼び出しに付ける形と、応答形式そのものに付ける形だ。

公式が例に出しているのは数学の個別指導アプリだ。

決めたスキーマで返させて、出力の各部分を別々の見せ方でUIに描く、という話が書かれている。

英語学習に置き換えれば、総合スコアと指摘の一覧と言い換え例を、画面の別々の場所に出すのが後者にあたる。

ドキュメントには、手順を段階に分けて答えさせる書き方や、非構造の文章から項目を抜き出す書き方、分類して違反の有無を返す書き方の例も並んでいる。

AI英会話の構造化出力③｜使える型と制約は、公式が列挙している

受け付けるのは、JSON Schema の全部ではなく一部だ。

型として並んでいるのは、文字列・数値・真偽・整数・オブジェクト・配列・列挙・anyOf の8つになる。

型に加えて、値の範囲を縛る制約も指定できる。

対象	指定できる制約	採点での使いどころ
文字列	pattern（正規表現）と format（date・email・uuid など）	学習者IDや日付の形を固定する
数値	minimum・maximum・exclusiveMinimum・exclusiveMaximum・multipleOf	スコアが範囲の外へ出ないようにする
配列	minItems・maxItems	指摘の件数を決め打ちにする

公式が載せている実例は天気の取得で、気温の値に下限と上限を置いた書き方が示されている。

発音の点数を0から100で返させたいなら、指示文で頼むのではなく、ここに数字を書くのが仕様に沿ったやり方になる。

一方で、まだ対応していない書き方も名指しで並んでいる。

組み立て系の allOf・not・if・then・else などがそれにあたり、未対応のスキーマに strict を立てて呼ぶとエラーが返ると明記されている。

AI英会話の構造化出力④｜全項目が必須。任意の項目はnullで作る

これは設計に直接効く決まりだ。

構造化出力を使うなら、すべての項目、あるいは関数の全引数を必須として指定しなければならない、と書かれている。

モデルはどの項目にも値を返してくる。

では「無いときは無いでいい項目」をどう表すかというと、型に null を混ぜた共用体で代用する手が示されている。

もう1つ必ず要るのが、additionalProperties を false にしておくことだ。

定義していないキーを勝手に足させないという宣言で、これを入れて初めて構造化出力に入れる、という扱いになっている。

採点結果の項目が毎回同じ順で並ぶのは、モデルの気まぐれではなく、この決まりの結果ということになる。

AI英会話の構造化出力⑤｜スキーマの大きさにも上限がある

採点項目を増やしていくと、いつかは上限に当たる。

何の上限か	公式に書かれている値
オブジェクトのプロパティ総数	5,000個まで
入れ子の深さ	10段まで
プロパティ名・定義名・列挙値・const値の文字数合計	120,000文字まで
列挙の値の総数	1,000個まで
列挙が250個を超える場合の、その1項目の文字数合計	15,000文字まで

文字数の上限が、値だけでなくキーの名前や定義の名前まで合算して数えられている点は見落としやすい。

語彙リストをそのまま列挙にするような設計は、真っ先にこの上限へ届く。

なお、同じスキーマを使い回すこと自体にも意味がある。

あるスキーマでの最初の1回だけは、API側がそれを処理するぶんの待ち時間が余分にかかり、同じスキーマでの2回目以降にはその待ちが乗らない、と注記されている。

出力そのものを短く保てという助言は、待ち時間を詰めるためのガイドにもある。

関数名を短くする、名前つき引数を省く、パラメータをまとめる、といった形で記法を最小にせよ、という書き方だ。

AI英会話の構造化出力⑥｜型に従っていても、中身が正しいとは限らない

この記事でいちばん大事なのはここだ。

構造化出力を使っていても誤りは混じりうる、と公式が自分で書いている。

さらに踏み込んだ注意もある。

モデルはどんなときも渡された型に合わせようとするので、入力が型とまったく無関係だった場合、その努力が作り話につながることがある、という説明だ。

対策として示されているのは、課題に合わない入力が来たときは空の項目を返すか、決めておいた1文を返すよう、指示文の側に書いておくことだ。

⇒ 採点欄が全部埋まっていることは、採点が当たっていることの証明にならない。

誤りが目立つときの手も3つ挙がっていて、指示を調整する、システム側の指示に例を入れる、課題をもっと小さく割る、という順に並んでいる。

キーの名前を分かりやすく付け、大事なキーには説明を添え、評価の仕組みを作って比べよ、という助言も別に置かれている。

AI英会話の構造化出力⑦｜断りと打ち切りは、型の外側から返る

型どおりの返事が返らない場合も、公式は2通りに分けている。

1つは、安全上の理由でモデルが答えることを断った場合だ。

もう1つは、出力トークンの上限に達して返事が途中で終わった場合になる。

起きたこと	応答のどこに出るか	アプリ側の受け方
安全上の拒否	中身の種類が refusal になり、専用の項目に断りの文が入る	断られたことを画面に出す分岐を書く
出力の打ち切り	応答の状態が incomplete になり、理由に max_output_tokens が入る	未完成として扱い、そのまま表示しない
未対応スキーマ	strict を立てた呼び出しがエラーになる	スキーマ側を直す

断りがスキーマに従うとは限らないため、専用の項目が別に用意されている、という説明が添えられている。

出力の上限は、返事の長さだけの問題でもない。

レート制限のドキュメントには、上限の計算が、指定した最大トークン数と、要求の文字数から見積もった数の大きいほうで行われると書かれている。

採点スキーマを大きく取るほど、1回の採点が枠を食うということになる。

AI英会話の構造化出力が、学習者の画面に出てくる場面

仕様の話を、学習者の側に置き換えておく。

どれも英語力の判定そのものではなく、アプリの設計で決まっている部分だ。

途中まで出て止まった採点を「厳しい評価」と読んでしまうと、判断を間違える。

なお、返事が全部そろうのを待たずに、生成の途中から構造として読み進める使い方も用意されている。

AI英会話の構造化出力｜よくある質問

Q. 採点の項目が抜けることはあるのか。 A. 公式ドキュメントは、全項目を必須として指定する決まりだと書いている。値を入れない代わりに null を返す設計にすることはできる。

Q. 欄が全部埋まっていれば、採点は信用してよいのか。 A. よくない。

構造化出力でも誤りは残りうると明記されており、入力が型と無関係なときに作り話が出る可能性まで書かれている。

Q. JSONで返ってきていれば構造化出力なのか。 A. 違う。

JSON mode も有効なJSONは返すが、スキーマに従うことは保証しないと表に書かれている。

Q. 採点項目はいくらでも増やせるのか。 A. 増やせない。

プロパティの総数や入れ子の深さ、名前と列挙値の文字数合計に上限が置かれている。

Q. 途中で切れた採点はどう見分けるのか。 A. 応答の状態が未完了になり、理由の欄に出力トークンの上限が入る。

アプリ側でそこを見て分岐する前提で説明されている。

まとめ｜AI英会話の構造化出力は「入れ物」を保証し、中身は保証しない

もう一度、要点だけ並べる。

⇒ AI英会話の採点画面を見るときは、「きれいに並んでいるか」ではなく「どこまでが型の保証で、どこからが中身の判断か」で線を引く。

そこが分かっていれば、欄が埋まっているだけの採点に振り回されずに済む。

※本記事の一次ソースは、各公式ドキュメントを2026-09-20に取得した生テキストで確認した。

仕様は更新されるため、最新は各公式ドキュメントで確認してほしい。