JSON とは？
JSON（JavaScript Object Notation）は、一般的なデータ交換形式です。キーと値の組でデータを整理するため、人にも読みやすく、プログラムでも解析しやすいという特徴があります。
{
"name": "John",
"age": 30,
"isStudent": false,
"grades": [90, 85, 88],
"address": {
"city": "New York",
"zipcode": "10001"
}
}
この例は、ある人の名前、年齢、学生かどうか、成績、住所を表しています。
JSON の値には、文字列、数値、真偽値、null、配列、オブジェクトを使用できます。主要なプログラミング言語の多くが JSON を処理するツールを備えているため、システム間のデータ交換によく使われます。
しかし、なぜモデルに JSON を出力させるのでしょうか？
例を見てみましょう。
先生の悩み
私が小学校の教師だとします。新学期の初日に、クラスの児童へ自己紹介を書いてもらい、その情報を児童管理システムへ登録したいと考えています。
児童によって、書き方は当然異なります。
私の名前は張三です。9 歳で、幸福団地に住んでいます。母は教師で、父は医師です。絵を描くことと歌うことが好きです。
私は小美、8 歳です。梧桐花園に住んでいます。ダンスが一番好きです。父は毎日悪者を捕まえていて、母は家で私の世話をしています。
モデルを使って、名前、年齢、両親の仕事、住所、趣味を抽出できます。
張三の文章には、両親の職業が明確に書かれています。一方、小美の文章にある「毎日悪者を捕まえている」という表現だけでは、父親が警察官だと確実には言えません。「家で私の世話をしている」という表現から、母親の職業が専業主婦だと断定することもできません。
ある解釈がもっともらしく聞こえるからといって、推測を事実として書いてはいけません。
そのため、明示されていないフィールドは空欄にするほうが安全です。
名前：小美
年齢：8 歳
父親の仕事：情報なし
母親の仕事：情報なし
住所：梧桐花園
趣味：ダンス
これなら問題がなさそうです。
しかし、このデータを児童管理システムに登録するとしたら、どうすればよいでしょうか？
児童が二人だけなら、手作業で入力できます。
100 人いたらどうでしょうか？
先生は大変な思いをするでしょう。
そこで、モデルが抽出した結果を一括でシステムに取り込むプログラムを書きます。
ここで問題が起きます。上の結果は、複数行の文章にすぎません。名前を取得するプログラムは 1 行目を、年齢なら 2 行目を読むかもしれません。
新しく「性別」フィールドを追加するとします。
名前：小美
性別：女
年齢：8 歳
父親の仕事：情報なし
母親の仕事：情報なし
住所：梧桐花園
趣味：ダンス
これまで 2 行目にあった年齢が性別に変わり、コードが誤動作する可能性があります。
「行番号ではなく、『年齢：』を検索すればよい」と考える人もいるでしょう。
では、父親と母親の年齢も追加したらどうでしょうか？
名前：小美
年齢：8 歳
父親の仕事：情報なし
父親の年齢：情報なし
母親の仕事：情報なし
母親の年齢：情報なし
住所：梧桐花園
趣味：ダンス
フィールドが増え、階層も複雑になります。行番号や文字列の切り出しに頼り続けるほど、プログラムの保守は難しくなります。
根本的な原因は何でしょうか？
このデータに、安定した明確な構造がないことです。
JSON で階層を表す
同じ情報を次のように書けます。
{
"name": "小美",
"age": 8,
"father": {
"job": null,
"age": null
},
"mother": {
"job": null,
"age": null
},
"address": "梧桐花園",
"hobby": ["ダンス"]
}
これでプログラムは、name、age、father.job を直接読み取れます。何行目にあるかを推測する必要はありません。
JSON は、すべてのタスクで必須の形式ではありません。結果を人だけが読むのであれば、通常の文章や Markdown のほうが自然なことも多くあります。構造化データが特に役立つのは、結果をプログラムでさらに処理する場合です。
モデルに JSON 出力を求めるには？
<student></student> 内の文章から児童の情報を抽出し、一つの JSON オブジェクトだけを出力してください。
フィールド：
- name：文字列または null
- age：数値または null
- father_job：文字列または null
- mother_job：文字列または null
- address：文字列または null
- hobby：文字列の配列
ルール：
- 元の文章に明示された情報だけを抽出する。
- 説明から職業を推測しない。
- 情報がない単一値フィールドは null にする。
- JSON 以外の説明文を出力しない。
<student>
{{児童の自己紹介}}
</student>
ここで重要なのは、「JSON を返す」という指示だけではありません。
フィールド、型、欠損値、推測してはいけない境界も説明しています。
モデルが「これは JSON」と言えば、そのまま使えるのか？
必ずしも使えるとは限りません。
説明文を追加したり、フィールドを欠落させたり、誤った型を使ったり、構文として無効な JSON を生成したりする可能性があります。構文が正しくても、内容が業務ルールに合わないこともあります。
そのため、プログラムでは少なくとも次の二点を確認します。
- 出力を JSON parser（JSON パーサー）で解析できるか。
- フィールド、型、許容値、業務ルールが正しいか。
プラットフォームが Structured Outputs（構造化出力）や JSON Schema（JSON スキーマ）に対応している場合は、その構造制約を優先して利用できます。ただし、具体的な対応範囲は変化するため、利用する API の公式ドキュメントを確認してください。
注意： 上の児童情報は、すべて架空の例です。練習のために、実在する子どもの住所、本人確認情報、健康情報、その他の機密データをモデルへ送信しないでください。
JSON を使えば、結果をプログラムへ渡しやすくなります。しかし、本当の信頼性は、フィールドの定義を明確にすること、不明な値を推測しないこと、プログラムで検証すること、例外を人が処理することから生まれます。
次の章： XML タグを活用する
Independent product builder · AI, agents and real workflows.