JSON
読み: ジェイソン
JSONとはデータ連携の標準形式
JSONはJavaScript Object Notationの略で、データを人間にも機械にも読みやすい形で記述するための軽量フォーマットである。WebアプリケーションのAPI通信で事実上の標準となっており、LLMの構造化出力やシステム間のデータ連携に欠かせない存在になっている。
かんたんに言うと
データを「名前と値のペア」で整理して書き出すルールである。Excelの表をテキストファイルに変換するようなもので、ほぼ全てのプログラミング言語がこの形式を読み書きできる。
波括弧とコロンだけで構成されるJSONのシンプルな書き方
JSONの構文は拍子抜けするほど単純である。波括弧で囲み、「キー」と「値」をコロンで対にする。値には文字列、数値、真偽値、配列、入れ子のオブジェクトを入れられる。
たとえば顧客情報なら、名前、メールアドレス、購入履歴をひとまとめにして1つのJSONオブジェクトで表現できる。XMLのようにタグの開始と終了を書く必要がなく、データ量が少なくて済む。通信量が減れば、モバイル回線でのレスポンスも速くなる。
2001年にDouglas CrockfordがJavaScriptのオブジェクトリテラル記法をベースに仕様を整理したのが始まりで、2013年にECMA-404として国際標準化された。JavaScriptの名を冠しているが、Python、Java、Go、PHP、Rubyなど主要言語の全てがJSONのパースライブラリを標準搭載している。
API通信の標準フォーマットになった経緯
2000年代前半、Webサービス間のデータ交換はXMLが主流だった。SOAPプロトコルとの組み合わせが企業システムの定番で、厳密なスキーマ定義が売りだった。
ところが、XMLは冗長である。同じデータを表現するのにJSONの2倍から3倍のテキスト量が必要になる。Web2.0の時代にAjax通信が爆発的に普及すると、ブラウザとサーバーの間でやり取りするデータは軽ければ軽いほどよい、という流れが加速した。
TwitterやFacebookがREST APIでJSONを採用したことが決定打になった。開発者コミュニティがこぞってJSONに移行し、2010年代にはAPI通信のフォーマットといえばJSONという状況が定着した。XMLが消えたわけではないが、新規開発でXMLを第一選択にするケースは激減している。
LLMの構造化出力とJSONモード
大規模言語モデルの出力は、本来は自由形式のテキストである。「顧客の感情をポジティブかネガティブで判定して」と頼んでも、モデルによっては「ポジティブです。理由は…」と長々と説明を始める。プログラムで後続処理をするには都合が悪い。
そこでOpenAIのGPT-4やGoogleのGemini、AnthropicのClaudeは「JSONモード」を提供している。出力を必ずJSON形式に整えるよう制約をかける機能で、APIのレスポンスがそのまま他のシステムに流し込める。
実務では、問い合わせメールの自動分類、請求書からの金額抽出、アンケートの感情分析など、LLMの判定結果を構造化して次の処理に渡す場面で威力を発揮する。JSONスキーマを指定すれば、必要なフィールドが欠落した出力を防ぐこともできる。
XMLとの使い分けと実務上の判断基準
JSONが万能かというと、そうでもない。
XMLにはスキーマ定義言語が充実しており、データの構造を厳密に検証できる。金融機関の電文規格や行政のデータ連携では、今もXMLが指定されているケースがある。既存システムとの互換性を考えると、XMLを捨てられない場面は残る。
JSONが得意なのは、Webアプリケーションやマイクロサービス間の軽量な通信である。パースが速く、データ量が少なく、どの言語からでも扱いやすい。新規にAPIを設計するなら、特別な理由がない限りJSONを選ぶのが合理的である。
最近はYAMLやProtocol Buffersといった選択肢も存在する。設定ファイルにはYAML、大量データの高速通信にはProtocol Buffersが適しているが、汎用性ではJSONに分がある。
現場で気をつけるべきJSONの落とし穴
JSONはコメントを書けない。設定ファイルとして使うときに「この値はなぜこうなっているのか」をファイル内に残せないのは不便である。JSON5やJSONCといった拡張仕様がコメント対応しているが、標準のJSONパーサーでは読めない。
日付の扱いも曖昧である。JSONの仕様には日付型が存在しないため、文字列として「2026-03-26」と書くか、UNIXタイムスタンプの数値で渡すか、プロジェクトごとにルールを決める必要がある。ここを決めずに進むと、フロントエンドとバックエンドで日付のパースがずれて障害を起こす。
巨大なJSONファイルをメモリに一括読み込みするとアプリケーションが落ちるのも定番の落とし穴である。数GBのログデータをJSONで扱うなら、JSON Lines形式で1行1オブジェクトにして逐次処理する設計が現実的である。
当社の見解
当社はツール選定において実用性を第一方針にしている。カタログスペックやベンチマークスコアではなく、実務で1週間使い倒して初めて判断する。フレームワークを増やすほど管理コストが増える経験もした。フックを増やしすぎてAIが情報過多でパニックになったこともある。足し算だけでなく、引き算の判断が選定の質を決める。検証せずに導入したツールは、ほぼ例外なく3か月以内に使わなくなった。
同じ失敗を二度としないAIエージェント
今のAIは、聞けば何でも答えてくれます。
でも、セッションが切れた瞬間に前回の失敗を忘れます。
当社が開発しているAIは、過去の経緯を念頭に置いて、
聞かれる前に「それは前回うまくいきませんでした」と声をかけます。
人間にも同じ失敗をさせず、AI自身も繰り返しません。
古参の社員が横にいるように、黙っていても気づいてくれる。
それが、当社が考える本当のAI社員です。