JSON5 から JSONC まで：より柔軟な JSON フォーマット体験を手に入れる
厳格な JSON のせいで カンマ一つ が原因のデバッグに深夜まで付き合わされた経験はありませんか？ そろそろ、もっと寛容な仲間たち — JSON5 と JSON with Comments (JSONC) — に出会うときかもしれません。
なぜ「寛容な」JSON が必要なのか
- 可読性の壁：標準 JSON ではコメント、末尾カンマ、シングルクォートなどが禁止されており、設定ファイルやデモでの意図の伝達が困難です。
- チーム開発の課題：巨大な JSON ファイルにインラインコメントが一切書けないと、メンテナンスが難しくなり、ちょっとした編集でファイル全体が壊れることも。
- DevOps の現実：Kubernetes や CI/CD パイプラインでは JSON の動的なマージや生成が日常的。寛容な構文なら手動修正の手間を大幅に削減できます。
JSON5 vs. JSONC 比較表
| 特徴 | JSON（厳格） | JSON5 | JSONC |
|---|---|---|---|
// 単行コメント | 不可 | 可 | 可 |
/* */ 複数行コメント | 不可 | 可 | 可 |
| 末尾カンマ | 不可 | 可 | 可 |
| シングルクォート文字列 | 不可 | 可 | 不可 |
| クォートなしのキー | 不可 | 可 | 不可 |
数値の符号 + / - | 不可 | 可 | 不可 |
| 16 進数/2 進数リテラル | 不可 | 可 | 不可 |
| 仕様策定者 | ECMA | コミュニティ (A. Rauschmayer) | Microsoft / VS Code |
一言でまとめると：JSON5 は JavaScript のオブジェクトリテラルに近い書き心地、JSONC は標準 JSON にコメント機能を追加しただけのものです。
構文の例
標準 JSON（厳格）
{
"name": "Go Tools",
"features": ["Base64", "JSON Formatter"]
}JSON5 の例
// プロジェクト設定
{
name: 'Go Tools', // シングルクォート & クォートなしキー
features: [
'Base64',
'JSON Formatter', // 末尾カンマ
],
version: 1.0, // 文字列以外の数値もOK
}JSONC の例
{
// プロジェクト名
"name": "Go Tools",
// 機能一覧
"features": [
"Base64",
"JSON Formatter", // 末尾カンマ
]
}フォーマット・パースのツールサポート
| 利用場面 | JSON5 | JSONC | 推奨ライブラリ/ツール |
|---|---|---|---|
| ブラウザ | JSON5.parse() polyfill、Prettier 内蔵 json5 パーサー (>= v1.13) | VS Code settings.json ネイティブ対応 | — |
| Node.js | json5 npm パッケージ | comment-json, jsonc-parser | CLI フォーマット & AST パース対応 |
| IDE | VS Code、WebStorm 拡張 | VS Code ネイティブ、WebStorm プラグイン | Prettier でフォーマット統一 |
| CI / Lint | eslint-plugin-json5 | eslint-plugin-jsonc | Husky & lint-staged と連携 |
| オンラインツール | Go Tools JSON Formatter（JSON5/JSONC の整形 & バリデーション） | 同左 | JSON フォーマッター |
VS Code でのフォーマット設定
settings.json に以下を追加します：
"[jsonc]": {
"editor.defaultFormatter": "esbenp.prettier-vscode"
}あとは Alt + Shift + F で JSONC ファイルを一発整形できます。
実践的なヒントと注意点
1. 本番環境にデプロイする前に変換する
- ブラウザの
JSON.parseは依然として厳格な JSON しか受け付けません。 - ビルドステップで
rollup-plugin-json5やカスタムスクリプトを使い、JSON5/JSONC を純粋な JSON に変換しましょう。
2. セキュリティと信頼性
- 寛容な構文は不正なフィールドを見逃すリスクがあります。API をリリースする前に JSON Schema や
zodで必ずバリデーションしましょう。
3. チームの規約を定める
- README やコントリビューションガイドで「
*.json5は設定ファイル専用、リリースパッケージは厳格な.jsonを使う」と明記します。 - Prettier のルールを統一して、フォーマットの違いによる無意味な diff を防ぎましょう。
4. パフォーマンス
- JSON5/JSONC のパースには追加の依存関係とわずかなオーバーヘッドが発生します。CLI や開発ツールでは問題ありませんが、本番環境では計測を行いましょう。
まとめ
可読性と厳密性のバランスを取ることは、開発者にとって永遠のテーマです。JSON5 と JSONC は記述体験を大幅に改善してくれます。適切なビルドパイプラインとバリデーション機構を組み合わせれば、「寛容な JSON」のメリットを安全に享受できます。