JSON

15 sec ver.

項目名と値を必ずセットで書く、データの並べ方のルールです。 自由には書けない分、プログラムには一切迷わず読み取れます。

60 sec ver.

先に言い切ります。JSONは、人間にとっては正直読みにくい形式です。 「人にも機械にも便利な書式」というイメージがあれば、それは誤解です。

たとえばこう書きます。

{"品目":"牛乳","価格":218}

外側の{ }でひとまとまりを表します。中では「品目」と「牛乳」 のように、項目名と値を:でつなぎ、,で区切って並べる、 これしか許されません。この{ }が1つでも欠けると、範囲が 分からなくなりエラーになります。ちょっとしたメモのように、 多少書き方が崩れても人間なら文脈で読める、という自由さは ないんです。

窮屈に見えますよね。でも、その窮屈さこそが正体です。「品目」の 次には必ず「牛乳」のような値が1つだけ来る。この1対1の対応が どこにも崩れないので、プログラムは迷わず読み取れます。 人間が読んで疲れる分だけ、機械にとっては誤読の余地がなくなるんです。

だから、AIには自由なメモ書きでのびのび考えさせて、他のシステムに 渡す最終形だけをこの窮屈な書き方に変換する。人にも機械にも 同時に優しい書式は無いという前提に立てば、迷いません。

記憶に残るたとえ話

宅配便の送り状を書く場面を想像してください。

送り主の欄、宛先の欄、品名の欄。それぞれ決められた枠にしか 書き込めませんよね。空いているところに自由にメモを 書き足す余地はありません。正直、窮屈で面倒です。

でも、この送り状を配送センターの仕分け機に通すとどうでしょう。 「宛先」の枠には必ず住所、「品名」の枠には必ず中身。この対応が どこにも崩れないので、機械は迷わず読み取れます。あっという間に 行き先別へ仕分けられます。

自分だけが読むメモなら、白紙に殴り書きで十分なはずです。 それでもわざわざ枠に沿って書くのは、この先読むのが人間では なく機械だからです。JSONも同じで、その先で機械が読む 前提のときだけ、この窮屈な書き方を選びます。

重要なポイント

だから、機械に読ませる前提かどうかで書き方を使い分けます。 お客さまリストや在庫のデータも、別のシステムに読み込ませるなら 表計算ソフトの一覧よりJSONのほうが正確に伝わります。人間が チェックする工程は自由なメモのままにして、機械に渡す直前だけ 変換する。それだけで手直しの手間が減ります。

間違えやすいポイント

✗「JSONは人間にも機械にも読みやすい、便利な書式だ」 → 逆です。人間には読みにくいからこそ、機械には正確に読める という、いいとこ取りではなくトレードオフの関係にあります。