別記事「APIとは？非エンジニアにもわかるビジネス活用のポイント」「REST APIとは？6つの原則・HTTPメソッド・設計の考え方を実務目線で解説」に続くシリーズの3本目として、今回はREST APIのやり取りで実際に目にする機会が多いデータ形式「JSON」そのものを解説します。

Contents
  1. JSONとは何か：策定の経緯と正式な標準規格
  2. JSONの基本文法
  3. JSONとXMLの違い
  4. JSONとCSVの違い：階層構造の有無
  5. JSONとYAMLの違い：設定ファイルという用途
  6. JSON利用時によくあるトラブル
  7. セキュリティ上の注意点：JSONインジェクション
  8. 非エンジニアが実務でJSONを読む場面
  9. 国内の公的機関でのJSON活用実例
  10. よくある質問
  11. 参考にした主な調査・資料
  12. まとめ

JSONとは何か：策定の経緯と正式な標準規格

JSON（JavaScript Object Notation）は、Douglas Crockford氏が2001年頃に提唱したデータ記述形式です。2002年に仕様公開サイト「json.org」が立ち上げられ、2006年にはIETFのRFC 4627として公開されました。その後、2013年にECMA International（ECMA-404）として初めて正式な標準規格になり、2017年にはIETFのRFC 8259（インターネット標準STD 90）として現行の仕様が確定しています。名前に「JavaScript」とついていますが、現在では特定のプログラミング言語に依存しない、汎用的なデータ交換形式として、ほぼ全てのプログラミング言語・APIで扱えるようになっています。

JSONの基本文法

JSONは、次のようなごくシンプルな構造で表現されます。

{
  "会社名": "株式会社サンプル",
  "従業員数": 42,
  "上場している": false,
  "所在地": {
    "都道府県": "東京都",
    "市区町村": "千代田区"
  },
  "事業拠点": ["東京", "大阪", "福岡"],
  "備考": null
}

波括弧{}で囲まれた部分を「オブジェクト」、角括弧[]で囲まれた部分を「配列」と呼びます。値として使えるのは、文字列（ダブルクォートで囲む）・数値・真偽値（true/false）・null（値がないことを示す）・オブジェクト・配列の6種類のみです。

RFC 8259の仕様上、次のような点でつまずきやすいので注意が必要です。

  • コメントを書く機能が仕様上存在しない：プログラムのソースコードのように//や/* */で説明書きを添えることはできません
  • 配列やオブジェクトの最後の項目にカンマを付けられない（末尾カンマ不可）：["東京", "大阪", "福岡",]のように最後にカンマが残っているとエラーになります
  • キーの重複は仕様上「推奨されない」扱い：完全に禁止されているわけではありませんが、同じキーが複数あった場合の扱いは実装依存となり、システム間でのやり取りでは避けるべきとされています

JSONとXMLの違い

API連携の文脈では、JSONの前によく使われていたデータ形式として「XML」が挙げられます。XMLは<company>株式会社サンプル</company>のように、開始タグと終了タグでデータを囲む形式で、厳密なスキーマ（データ構造の定義）によるバリデーションができる点に強みがあります。一方JSONは、タグを使わずキーと値のペアで表現するため記述量が少なく、プログラム側での読み込み（パース）処理も軽い傾向があります。現在の新しいWeb APIの多くがJSONを採用しているのは、この「軽さ」と「扱いやすさ」が主な理由です。とはいえ、金融・行政分野の一部のシステムでは、厳密なバリデーションが求められる場面でXMLが今も使われ続けています。

JSONとCSVの違い：階層構造の有無

もう一つ、実務でよく比較されるのが「CSV」です。CSVは表計算ソフトとの相性がよく、行と列だけのシンプルな表形式データですが、JSONのように「所在地の中に都道府県と市区町村がある」といった入れ子（階層）構造を表現することができません。前述のサンプルのようなデータをCSVで表現しようとすると、列を無理に増やしたり、別の表に分割したりする必要が出てきます。どちらが優れているというより、「表形式で完結するデータ（Excelでそのまま扱いたい）ならCSV」「階層構造を含む複雑なデータ（APIのレスポンス等）ならJSON」という使い分けが実務的な判断基準になります。

JSONとYAMLの違い：設定ファイルという用途

もう一つ、実務でよく並べて語られるのが「YAML」です。YAML 1.2はJSONの厳密なスーパーセットとして定義されており、正しいJSONはそのまま正しいYAMLとしても扱えます。大きな違いは、YAMLがインデントで階層を表すことと、コメントを書けることです。JSONにはコメントの構文がないため、設定ファイルにはYAMLが選ばれることが多くなっています。一方でYAMLは、国コードの「NO」が false と解釈されるなど暗黙の型変換による落とし穴もあります。詳しくは YAMLとは？JSONとの違いと設定ファイルでの落とし穴 をご覧ください。

JSON利用時によくあるトラブル

API連携やデータ受け渡しでJSONを扱う際、実務上よくあるトラブルには次のようなものがあります。

  • 構文エラー：カンマの付け忘れ・付けすぎ、ダブルクォートの閉じ忘れなど、些細なミスでデータ全体が読み込めなくなります
  • 文字コードの不一致：JSON自体は原則UTF-8での扱いが前提とされていますが、送信側・受信側で文字コードの想定がずれていると、日本語部分が文字化けすることがあります（文字化けの仕組みと見分け方）
  • 日付形式に標準がない：意外と見落とされがちですが、JSONの仕様自体には「日付」を表す専用の型が存在しません。そのため、JavaScript系のシステムでは2026-07-15T10:00:00ZのようなISO 8601形式を使う一方、.NET系のシステムでは/Date(1234567890)/のような独自形式を使うなど、システムによって表現がバラバラです。異なるベンダーのシステム同士を連携させる際は、日付データの形式が食い違っていないかを事前に確認しておくことをおすすめします（日時がずれる原因と正しい書き方）

セキュリティ上の注意点：JSONインジェクション

JSONを扱う際のセキュリティリスクとして、「JSONインジェクション」と呼ばれる問題が知られています。これは、外部から入力された文字列をそのままJSONデータの一部として組み込んでしまうと、本来意図していなかった構造にデータが書き換えられてしまう可能性がある、というリスクです。例えば、ユーザーが入力したテキストの中にダブルクォートや波括弧が含まれていた場合、それをそのままJSON文字列に埋め込んでしまうと、JSONの構造自体が壊れたり、意図しないデータが追加されたりする恐れがあります。自社でシステムを開発する際は、JSONを組み立てる際に標準のライブラリ（エスケープ処理を自動的に行ってくれる機能）を使い、文字列を手動で連結してJSONを作らないようにすることが基本的な対策になります。

非エンジニアが実務でJSONを読む場面

実際の業務では、自分でJSONを書く機会は少なくても、ベンダーから届いたAPIのレスポンス例や、システムのエラーログの中にJSONが含まれている場面に出会うことがあります。そうした際は、次の点だけ押さえておけば大まかな内容を読み取れます。

  • 波括弧{}の中の「キー」（ダブルクォートで囲まれた項目名）が、何のデータを表しているかを確認する
  • 角括弧[]が出てきたら、「同じ種類のデータが複数並んでいる」ことを意味すると理解する
  • 入れ子になっている（波括弧の中にさらに波括弧がある）場合は、そのデータが階層構造を持っていることを意味すると理解する

ベンダーとのトラブルシューティングの際、「レスポンスのこのキーの値がnullになっている」といった形で具体的に指摘できると、原因の切り分けがスムーズになります。

国内の公的機関でのJSON活用実例

日本国内でも、行政のオープンデータ推進においてJSONは標準的な形式として位置づけられています。デジタル庁の「オープンデータ基本指針」では、機械判読が可能な形式としてCSV・JSON・XML・RDF等を推奨形式に挙げ、構造化されたデータでの公開を原則としています。具体例として、総務省統計局が提供する政府統計の総合窓口「e-Stat」のAPIは、XML・JSON・JSONP・CSVの4形式でデータを提供しており、利用目的に応じて形式を選べるようになっています。

よくある質問

Q. JSONファイルはどんなソフトで開けますか？

中身はテキストファイルなので、メモ帳やテキストエディタで開くことができます。ただし、階層が深いデータは見づらいため、JSONの構造を色分け表示してくれる専用のビューアや、ブラウザの拡張機能を使うと読みやすくなります。

Q. ExcelでJSONデータを扱うことはできますか？

近年のExcelには、JSON形式のデータをインポートし、表形式に自動展開する機能（Power Query等）が搭載されています。ただし、階層が複雑なJSONの場合、意図した通りの表に展開されるとは限らないため、事前に構造を確認しておくとよいでしょう。

Q. JSONとJSONPは何が違うのですか？

JSONPは、JSON形式のデータを関数呼び出しの形で包んだ、やや古い時代の技術的な工夫です。現在の主流のAPIでは使われる機会は減っていますが、前述のe-Stat APIのように、互換性維持のために今も提供している事例があります。

Q. 構文エラーの原因を早く見つけるにはどうすればよいですか？

インターネット上には、JSONの構文を整形・検証してくれる「JSON整形ツール」「JSONフォーマッター」が数多く公開されており、貼り付けるだけでエラー箇所を教えてくれます。ただし、こうしたオンラインツールに顧客情報や社内の機密データを含むJSONをそのまま貼り付けるのは避けるべきです。エラー箇所の特定だけが目的であれば、実際のデータを簡略化したサンプルに置き換えてから使う、あるいは自社のエディタ・開発ツールに搭載されている構文チェック機能を使うことをおすすめします。

参考にした主な調査・資料

まとめ

JSONは、Douglas Crockford氏が提唱し、現在はRFC 8259として標準化されている、シンプルながらも階層構造を表現できるデータ形式です。コメントが書けない・末尾カンマが使えないといった仕様上の制約や、日付形式に標準がないという実務上の注意点を知っておくと、ベンダーとのAPI連携やデータ受け渡しの場面で役立ちます。APIやREST APIの基礎については、別記事「APIとは？非エンジニアにもわかるビジネス活用のポイント」「REST APIとは？」もあわせてご覧ください。

Post Views: 249
API API・データ形式 JSON クラウド 中小企業DX 技術解説