記事一覧 / 自動化・開発 · 042

APIの前にJSONを読む：名前と値の組を理解する

連携データの形を読み、文字列・数値・真偽値を区別します。

公式資料確認資料確認：2026年10月3日。JSON例と業務ルールは説明用の提案です。特定API・CMSへ送信する仕様ではありません。

APIの説明に出てくるJSONを読めると、「どの項目を、どの型で渡すか」を確認しやすくなります。この記事では、架空の記事データを使い、構文・型・業務上の条件を分けて点検する型を作ります。

公式資料から分かること：JSONはデータを表す形式

MDNはJSONを構造化データのテキスト形式として説明しています。文字列・数値・真偽値・null・配列・オブジェクトを表せます。文字列とオブジェクトの項目名には二重引用符を使い、コメントや末尾の余分なカンマは使いません。JavaScript専用ではなく、APIがすべてJSONを使うという意味でもありません。

コピーして使える架空の記事データ

{
  "article_id": "042",
  "title": "問い合わせ対応の型",
  "revision": 1,
  "published": false,
  "tags": ["業務改善", "入門"],
  "published_at": null
}

article_idとtitleは文字列、revisionは数値、publishedは真偽値、tagsは文字列の配列です。published_atはnullですが、「未公開なので日時なし」という意味は、この例で決めた業務ルールです。null、空文字、項目そのものがない状態を同じ扱いにするかはAPI側の仕様で確認します。

仕事の具体例：先頭のゼロと真偽値を守る

架空の記事管理で、記事IDの「042」を数値42へ変えると表記が変わります。計算しない識別子は文字列として扱う案です。また、falseと文字列の「false」は異なる型です。見た目が似ていても、公開状態の判定へ同じように渡せるとは限りません。

コピーして使える項目確認メモ

対象API／仕様URL／確認日：
項目 | 必須か | 型 | 許可する値 | 空・null・欠落の扱い
article_id | この例では必須 | 文字列 | 3桁の識別子 | 不可
revision | この例では必須 | 数値 | 1以上の整数 | 不可
published | この例では必須 | 真偽値 | true／false | 不可
published_at | この例では必須 | 文字列またはnull | 日時／未公開時null | 仕様を定義
業務条件：公開時には有効な公開日時を求める
確認結果：構文／型／業務条件を別々に記録

結果の確認ポイント

構文：JSONとして読み取れるか確認する。末尾カンマやコメントは構文エラーになる。
型と項目：必須項目と期待する型を照合する。文字列の「false」でもJSONとしては読み取れるため、構文確認だけでは不足する。
業務条件：公開済みなのに公開日時がnullなどの矛盾を確認する。これも構文だけでは判定できない。

練習は架空データをローカルの確認手段で行い、実際の顧客情報やAPIキーを外部のJSON検証サイトへ貼り付けないでください。実際のAPIに送る場合は、そのAPIの項目名・型・日時形式を優先します。

今日試すこと

例のtitleとtagsだけを書き換え、型を保てているか確認してください。次に、publishedをtrueにした場合に必要な変更を項目確認メモへ書くと、書式と意味の違いが見えてきます。

参考資料

MDN｜Working with JSON：JSONの型・構文・読み取り。

記事一覧へ戻る