FormatArc YAML to JSON の変換結果FormatArc YAML to JSON の変換結果
公開日: 2026-03-17更新日: 2026-06-02

YAML JSON 変換ガイド — 8 つの落とし穴を回避 (Python / yq / ブラウザ)

YAMLをJSONに変換する方法を解説。Pythonワンライナー、yq CLI、ブラウザツール (アップロード不要)。Norway 問題 (NO → false)、マルチドキュメント、コメント消失など 8 つの落とし穴を実例で回避。NDJSON ストリーミング、Kubernetes ワークフロー、GitHub Actions / GitLab / Jenkins の CI/CD 自動化まで網羅。

TL;DR — 用途別ベスト方法 10 秒早見表

  • 今すぐ変換したい・インストール不要 → FormatArc YAML to JSON (ブラウザ完結、アップロード不要、行番号付きエラー)
  • CLI / ワンライナー → yq -o=json '.' file.yaml (DevOps の事実上の標準)
  • Python スクリプト・パイプライン → python3 -c 'import sys, yaml, json; json.dump(yaml.safe_load(sys.stdin), sys.stdout, indent=2)' < file.yaml
  • Node.js アプリ → js-yaml の yaml.load + JSON.stringify
  • Go サービス → gopkg.in/yaml.v3 + encoding/json
  • Kubernetes ラウンドトリップ → kubectl get ... -o json | yq -P '.' (YAML に戻す)
  • マルチドキュメント YAML (--- で区切られた複数文書) → yq -o=json '.' file.yaml (yq は標準で分割) または NDJSON 出力
方法 セットアップ マルチドキュメント アンカー コメント ストリーミング
FormatArc ブラウザ なし 最初の 1 件のみ 展開される 失われる (JSON 制約) なし
yq -o=json brew install yq 全件 (分割 or 配列化) 展開される 失われる あり
Python yaml.safe_load + json.dump pip install pyyaml 最初の 1 件 (safe_load) / 全件 (safe_load_all) 展開される 失われる 手書きループ
Node js-yaml yaml.load npm install js-yaml 最初の 1 件 (load) / 全件 (loadAll) 展開される 失われる 手書き
Go yaml.Unmarshal go get gopkg.in/yaml.v3 最初の 1 件 / 全件 (Decoder ループ) 展開される 失われる あり

YAML → JSON 変換のコード自体は 1 行で済むことが多いです。難しいのは 8 つの落とし穴 (Norway 問題、コメント消失、マルチドキュメント処理、yaml.load の安全性、整数キーが文字列化、アンカー展開、1.0 が浮動小数点化、型推論のスキーマ依存) で、本記事ではそれぞれを before/after の実例で解説します。

なぜ YAML を JSON に変換するのか

実務でよくある場面をいくつか挙げます。

  • Kubernetes API への送信: YAML マニフェストを Kubernetes API 経由で POST したい場合、API は JSON エンコードされたボディしか受け付けない
  • YAML 構造のデバッグ: YAML のインデントベースのネストは時々曖昧。JSON に変換すると構造が一意に決まり、- やインデントの誤りが一目でわかる
  • JSON 専用ツール: 下流ツール (他言語の JSON パーサー、JSON を保存する DB、JSON Schema バリデータ付きイベントバス) が YAML を受け付けない
  • 設定監査: リポジトリの YAML 設定を JSON に変換して diff 分析、JSON Schema バリデーション、セキュリティスキャナーに投入
  • LLM コンテキスト: 設定を LLM に渡すとき、JSON のほうがオブジェクト境界を一貫して認識してくれる。特にネスト構造で顕著。詳しくは LLM に Markdown vs HTML を渡すなら を参照

両形式の違いについては YAML と JSON の違い で詳しく解説しています。

方法 1: FormatArc ブラウザツール (アップロード不要)

インストールなしでサッと変換したいときは YAML to JSON が最短です。すべてブラウザ内で処理され、データは外部に送信されません。

  1. YAML to JSON を開く
  2. 左側のエディタに YAML を貼り付ける
  3. 「変換」ボタンを押すと、右側に JSON が表示される

YAML to JSON の変換結果YAML to JSON の変換結果

ツールは YAML の構文を変換時に検証します。インデントずれ、コロン抜け、スペースを期待する箇所のタブなどの構文エラーは行番号付きで報告されるので、変換が主目的でなくとも YAML デバッグツールとして使えます。

ブラウザ内処理は機密データを扱うときに効きます。Kubernetes Secret (base64 エンコード済みとはいえ機密)、Ansible vault に書かれたクラウド認証情報、API トークンを含む CI 設定など、貼り付けたデータはタブの中だけで完結します。

これは理論上の懸念ではありません。2025 年 11 月には、人気の整形サイト JSONFormatter と CodeBeautify が保存機能を通じてユーザーの入力データ 5GB 超 (認証情報・秘密鍵・API トークンを含む) を誰でも閲覧できる状態にしていたと、セキュリティ企業 watchTowr が報告しました (watchTowr の調査報告)。ブラウザ内で完結するツールは入力を保存も送信もしないため、そもそも露出するものがありません。

オンライン変換が安全かを見分ける方法は オンライン JSON 変換は安全か を参照してください。

ブラウザツールは次の YAML 機能を正しく扱います。複数行文字列 (ブロックスカラー | とフォールドスカラー >)、アンカーとエイリアス (展開される)、任意の深さのネスト構造、混合型の配列、null / 真偽値 / 数値型。

方法 2: yq (DevOps の事実上の標準)

yq は YAML 版の jq ともいえるコマンドラインプロセッサ。DevOps パイプラインで YAML → JSON 変換に最もよく使われます。

# 基本的な変換
yq -o=json '.' input.yaml

# stdin からパイプ
cat config.yaml | yq -o=json '.'

# ファイルに保存
yq -o=json '.' config.yaml > config.json

# コンパクト出力 (単一行)
yq -o=json -I=0 '.' config.yaml

# サブツリーだけ抽出して変換
yq -o=json '.spec.template' deployment.yaml

# フィルタしながら変換
yq -o=json '.items[] | select(.kind == "ConfigMap")' multi.yaml

インストール:

# macOS
brew install yq

# Linux (snap)
snap install yq

# Linux (バイナリダウンロード)
sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
sudo chmod +x /usr/local/bin/yq

# Go install
go install github.com/mikefarah/yq/v4@latest

注意: 名前が同じ yq というツールが 2 つ存在します。本記事は Mike Farah 氏の Go 製 yq (Kubernetes / CNCF ツールで広く使われている) を扱います。kislyuk 氏の Python 製 yq は構文が異なります。両方使えますが、2026 年時点では Go 版がデファクトスタンダードです。

yq でマルチドキュメント YAML を扱う

# マルチドキュメント YAML (--- で区切られた複数文書)
yq -o=json '.' multi.yaml          # 入力 1 文書ごとに JSON 1 文書を出力
yq -o=json -I=0 '.' multi.yaml      # NDJSON (コンパクト、1 行 1 文書)
yq eval-all '[.]' -o=json multi.yaml  # 全文書を JSON 配列でラップ

Kubernetes の「複数リソースの YAML」を 1 つの JSON 配列に変換するときに、これが最もきれいな方法です。

方法 3: Python (最も柔軟)

Python は json を標準ライブラリに含み、pyyaml も大半の環境で入っています (なければ pip install pyyaml)。

Python ワンライナー

python3 -c 'import sys, yaml, json; json.dump(yaml.safe_load(sys.stdin), sys.stdout, indent=2)' < input.yaml > output.json

stdin から YAML を読み、yaml.safe_load でパースし、整形 JSON を stdout に書き出します。indent=2 で読みやすい出力。

Python スクリプト (マルチドキュメント・エラーハンドリング)

import sys
import yaml
import json

with open("config.yaml") as f:
    data = yaml.safe_load(f)  # マルチドキュメントなら safe_load_all() を使う

with open("config.json", "w") as f:
    json.dump(data, f, indent=2, ensure_ascii=False)

yaml.safe_load を使うことが重要。yaml.load は任意 Python オブジェクトの構築を許すので、悪意ある YAML でコード実行される危険があります (落とし穴 #4 参照)。

Python + ruamel.yaml (構造をより保持)

クォートスタイル、キー順、コメント (ただし JSON にコメントは出力されません) まで保持したい場合は ruamel.yaml を使います:

from ruamel.yaml import YAML
import json
import sys

yaml_parser = YAML(typ="safe")
data = yaml_parser.load(open(sys.argv[1]))
json.dump(data, sys.stdout, indent=2, ensure_ascii=False)

大半の用途では pyyaml.safe_load で十分。YAML フォーマットのラウンドトリップ保持が必要なときに ruamel.yaml を使う、という使い分けが現実的です。

方法 4: Node.js (js-yaml)

Node.js アプリでは js-yaml が標準です。

const fs = require("fs");
const yaml = require("js-yaml");

// 単一ドキュメント
const doc = yaml.load(fs.readFileSync("config.yaml", "utf8"));
fs.writeFileSync("config.json", JSON.stringify(doc, null, 2));

// マルチドキュメント
const docs = yaml.loadAll(fs.readFileSync("multi.yaml", "utf8"));
fs.writeFileSync("multi.json", JSON.stringify(docs, null, 2));

インストール: npm install js-yaml または yarn add js-yaml。

信頼できない YAML を扱う場合は yaml.load(text, { schema: yaml.JSON_SCHEMA }) で JSON 互換型のみに制限。デフォルトの DEFAULT_SCHEMA には Norway 問題などの YAML 1.1 の癖が含まれています。

方法 5: Go (gopkg.in/yaml.v3)

package main

import (
    "encoding/json"
    "fmt"
    "os"

    "gopkg.in/yaml.v3"
)

func main() {
    data, _ := os.ReadFile("config.yaml")
    var obj interface{}
    yaml.Unmarshal(data, &obj)
    result, _ := json.MarshalIndent(obj, "", "  ")
    fmt.Println(string(result))
}

yaml.v3 は go-yaml が保守するバージョンで、Kubernetes 本体でも使われています。注意点: YAML の整数キー (123: foo) は JSON で文字列化されます (JSON はオブジェクトキーが文字列のみのため、落とし穴 #5 参照)。

マルチドキュメント YAML をストリーミング処理するには yaml.NewDecoder ループを使います:

dec := yaml.NewDecoder(file)
for {
    var doc interface{}
    if err := dec.Decode(&doc); err != nil {
        if err == io.EOF { break }
        log.Fatal(err)
    }
    out, _ := json.Marshal(doc)
    fmt.Println(string(out))   // NDJSON: 1 文書 1 行
}

任意のサイズのマルチドキュメント YAML を定数メモリで処理できます。

YAML 変換 8 つの落とし穴

YAML と JSON は完全な 1 対 1 対応ではありません。実務でよく踏むのが次の 8 つです。

落とし穴 1: Norway 問題 (NO → false)

YAML 1.1 は次のような裸の文字列を真偽値として解釈します:

country: NO

変換後:

{ "country": false }

NO、no、Off、OFF、n、N、False、f、F はすべて false になります。YES、Y、On、True、T、t はすべて true。これが有名な「Norway 問題」で、国コードリストに country: NO を書くと意図せず真偽値にパースされます。

修正: 曖昧な値はクォートで囲む:

country: "NO"

YAML 1.2 (Core スキーマ) ではこの挙動は削除されました。ただ多くのツールが今でも YAML 1.1 をデフォルトにしています (PyYAML の safe_load や yq の v4 まで)。2 文字の国コード、1.0 のようなバージョン文字列、ユーザー入力に由来する文字列はクォートを徹底しましょう。

落とし穴 2: コメントは黙って消える

YAML は # でコメントを書けます。JSON は書けません。YAML のコメントは変換時に黙って捨てられます:

# 本番 DB の接続情報 (変更禁止)
host: db.prod.internal
port: 5432  # PostgreSQL の標準ポート

変換後:

{ "host": "db.prod.internal", "port": 5432 }

JSON にコメント構文がない以上、どのコンバータでも YAML のコメントを JSON に保持することはできません。JSON5 や JSONC はコメント対応ですが標準ではない。コメントが重要な情報を含むなら、別に保存するか、ruamel.yaml でプログラム的に抜き出してから変換します。

落とし穴 3: マルチドキュメント YAML — デフォルトで最初の 1 件しか変換されない

YAML は --- で区切って複数文書を 1 ファイルに格納できます:

---
apiVersion: v1
kind: ConfigMap
metadata:
  name: app-config
---
apiVersion: v1
kind: Service
metadata:
  name: app-service

デフォルト挙動:

  • yaml.safe_load (Python): 最初の 1 文書だけ返す (警告なし)
  • yaml.load (js-yaml): 同上、最初の 1 件
  • yq -o=json '.': 複数 JSON 文書を連結して出力 (NDJSON 互換、コンパクト指定なら)

全文書を JSON 配列で取得するには:

yq eval-all '[.]' -o=json multi.yaml

Python:

import yaml, json
docs = list(yaml.safe_load_all(open("multi.yaml")))
json.dump(docs, open("multi.json", "w"), indent=2)

Node.js:

const docs = yaml.loadAll(fs.readFileSync("multi.yaml", "utf8"));
fs.writeFileSync("multi.json", JSON.stringify(docs, null, 2));

Kubernetes の「複数マニフェスト 1 ファイル」はほぼ必ずマルチドキュメント YAML です。ケースを明示的に分けて扱いましょう。

落とし穴 4: yaml.load は危険、必ず safe_load

Python の PyYAML のデフォルト yaml.load 関数は任意 Python オブジェクトの構築を許します:

!!python/object/apply:os.system ["rm -rf /"]

悪意ある YAML が yaml.load で読まれるとコード実行されます。信頼できない YAML を扱う際は必ず yaml.safe_load (マルチドキュメントなら yaml.safe_load_all) を使ってください。

js-yaml は yaml.safeLoad を非推奨にして yaml.load をデフォルト安全にしました (危険なのは unsafeLoad)。Python と Node で命名が逆なので必ず確認を。

yq は Go の yaml.v3 を使っており、Python の !!python/object タグに相当するものがないので安全です。

落とし穴 5: 整数キーが文字列になる

YAML は整数キーを許可します:

123: first
456: second

JSON オブジェクトのキーは文字列のみなので、変換時にキャストされます:

{ "123": "first", "456": "second" }

通常はこれで問題ありませんが、下流コードが整数キーで lookup する (obj[123]) なら文字列キー (obj["123"]) で失敗します。必要ならアプリ層で int に戻すこと。

落とし穴 6: アンカーとエイリアスは展開される

YAML は &anchor で値を 1 度定義し *alias で参照できます:

defaults: &defaults
  timeout: 30
  retries: 3

production:
  <<: *defaults
  host: prod.internal

staging:
  <<: *defaults
  host: stage.internal

JSON に変換するとアンカーは展開されて埋め込まれます。production と staging の両方にデフォルト値が完全コピーされます:

{
  "defaults": { "timeout": 30, "retries": 3 },
  "production": { "timeout": 30, "retries": 3, "host": "prod.internal" },
  "staging": { "timeout": 30, "retries": 3, "host": "stage.internal" }
}

データとしては正しいですが、「これらはデフォルトを共有している」という元の意図は失われます。JSON にアンカーの概念はないので、これは不可避です。

落とし穴 7: 1.0 が浮動小数点になる (バージョン文字列が壊れる)

YAML は数値に見える値を数値として扱います:

version: 1.0
release: 2026

変換後:

{ "version": 1.0, "release": 2026 }

文字列としての "1.0" (バージョンラベル) が欲しかった場合、浮動小数点 1.0 に強制変換され、JSON エンコーダによっては 1 または 1.0 として出力されます。if version == "1.0" の比較は失敗します。

修正: バージョン文字列はクォートで囲む:

version: "1.0"
release: "2026"

これは数値に見えるけれど文字列でいたい値全般に当てはまります。電話番号、郵便番号 ("01234" の先頭ゼロが消える)、16 進数に見えるコミットハッシュ ("e10" が 1e+10 扱い) など。

落とし穴 8: 型推論はスキーマで挙動が変わる

YAML には型推論のスキーマが 3 種類あります:

  • FailSafe スキーマ: 文字列・シーケンス・マッピングのみ。数値や真偽値のパースなし。最も安全
  • JSON スキーマ: JSON の型 (文字列・数値・真偽値・null・配列・オブジェクト) と同じ。Norway 問題なし、yes/no も真偽値にならない
  • Core スキーマ (YAML 1.2 デフォルト): JSON スキーマに加え、null / Null / NULL / ~ / 空が null。true/false/True/False/TRUE/FALSE が真偽値

多くのツールは Core をデフォルトに使います。一部のレガシーツールは YAML 1.1 のフルスキーマ (Norway 問題と yes/no 含む) をデフォルトに残しています。

Python で JSON スキーマを強制:

yaml.safe_load(text, Loader=yaml.SafeLoader)  # デフォルト
# より明示的に:
yaml.load(text, Loader=yaml.CSafeLoader)

js-yaml:

yaml.load(text, { schema: yaml.JSON_SCHEMA });

yq v4 は YAML 1.2 Core スキーマがデフォルトなので Norway 問題は起きません。

オンラインツール比較

2026 年時点の主要なオンライン YAML → JSON コンバータの実際の比較:

ツール ブラウザ内処理 ファイルアップロード マルチドキュメント 行番号付きエラー 広告なし
FormatArc YAML to JSON あり なし (貼り付けのみ) 最初の 1 件 あり あり
onlineyamltools.com あり (主張) あり 最初の 1 件 限定的 あり
jsonformatter.org あり (主張) あり 最初の 1 件 なし なし (広告あり)
codebeautify.org あり (主張) あり 最初の 1 件 なし なし (広告あり)
jsonlint.com あり なし 最初の 1 件 あり あり
dadroit.com あり あり 最初の 1 件 限定的 あり

機密性のある YAML (Kubernetes Secret / Ansible vault / API トークン入り CI 設定) を扱う場合、「ブラウザ内処理」の表記が重要。DevTools でネットワークを無効化してから貼り付けて、ツールが動き続けるか確認すれば真偽がわかります。FormatArc はネットワーク無効化状態でも動作します。

マルチドキュメント YAML は上記オンラインツールすべて最初の 1 件しか変換しません。マルチドキュメントや NDJSON 出力が必要なら yq や Python に切り替えましょう。

YAML から JSON Lines (NDJSON) でストリーミング

入力がマルチドキュメント YAML で、出力がストリーミング消費側 (Kafka producer / 行単位 DB ローダ / ログシッパー) なら JSON Lines (NDJSON) が適切です。

yq で

# NDJSON: 各 YAML 文書を 1 行の JSON に
yq -o=json -I=0 '.' multi.yaml

# フィルタしてから NDJSON
yq -o=json -I=0 '.items[]' kubernetes-list.yaml

Python ストリーミングで

import yaml
import json
import sys

for doc in yaml.safe_load_all(sys.stdin):
    sys.stdout.write(json.dumps(doc, ensure_ascii=False) + "\n")

使い方: python3 yaml2ndjson.py < multi.yaml > multi.ndjson。

入力サイズによらず定数メモリで動きます。数千文書あるログ的 YAML でも安全。

Kafka / BigQuery / S3 へパイプ

# BigQuery にストリーミング
yq -o=json -I=0 '.' events.yaml | bq load --source_format=NEWLINE_DELIMITED_JSON dataset.events -

# S3 にストリーミング
yq -o=json -I=0 '.' events.yaml | aws s3 cp - s3://bucket/events.ndjson

# Kafka に kafkacat 経由でストリーミング
yq -o=json -I=0 '.' events.yaml | kafkacat -P -b broker:9092 -t events

CI/CD 自動化

3 つの代表的なパイプラインプラットフォームでの YAML → JSON 変換ステップ。

GitHub Actions

name: Convert YAML config to JSON
on: [push, pull_request]

jobs:
  convert:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Install yq
        run: |
          sudo wget -qO /usr/local/bin/yq https://github.com/mikefarah/yq/releases/latest/download/yq_linux_amd64
          sudo chmod +x /usr/local/bin/yq
      - name: Convert
        run: yq -o=json '.' config.yaml > config.json
      - name: Validate against JSON Schema
        run: |
          npx ajv-cli validate -s schema.json -d config.json

GitLab CI

convert-yaml:
  image: mikefarah/yq:latest
  stage: validate
  script:
    - yq -o=json '.' config.yaml > config.json
    - jq empty config.json   # 最終的な構文チェック
  artifacts:
    paths:
      - config.json

Jenkins (Declarative Pipeline)

pipeline {
  agent any
  stages {
    stage('Convert YAML to JSON') {
      steps {
        sh 'yq -o=json . config.yaml > config.json'
        sh 'jq empty config.json'
      }
    }
  }
}

どのプラットフォームでも変換にかかる時間は 1 秒未満で、パイプラインに自然に組み込めます。

Kubernetes の実用ワークフロー

実務でよくあるパターン。動いている Deployment を取得して編集し、YAML ↔ JSON を行き来する。

# 現在の Deployment を JSON で取得 (kubectl は両形式対応)
kubectl get deployment web-app -o json > deployment.json

# あるいは YAML で取得して変換 (ローカルの yq の動作確認も兼ねて)
kubectl get deployment web-app -o yaml | yq -o=json '.' > deployment.json

# jq で編集 (例: replicas をスケール)
jq '.spec.replicas = 5' deployment.json > updated.json

# Git にコミットするため YAML に戻す
yq -P '.' updated.json > deployment.yaml

# 適用
kubectl apply -f deployment.yaml

ワンパイプラインで:

kubectl get deployment web-app -o json \
  | jq '.spec.replicas = 5' \
  | yq -P '.' \
  > deployment.yaml

このパターンは kubectl の全リソース、Helm chart values、カスタムリソース定義 (CRD) に共通で使えます。

よくある質問

YAML の country: NO が false になる

これは有名な「Norway 問題」。YAML 1.1 は NO、Off、n、False などの裸の文字列を真偽値 false として解釈します。修正: country: "NO" のようにクォートで囲む。YAML 1.2 仕様ではこの挙動は削除されましたが多くのツールが今も 1.1 をデフォルトにしています。yq v4 は YAML 1.2 Core スキーマを使うのでこの問題は起きません。

YAML のコメントを JSON 出力に保持できる？

不可。JSON にコメント構文はありません。回避策としては ruamel.yaml でコメントを別メタデータとして抽出、または JSON5 / JSONC のような非標準フォーマット。コメントが重要なら YAML を真実の源 (source of truth) として残してください。JSON 内で別の回避策を取る方法は JSON にコメントを書く方法 を参照。

マルチドキュメント YAML — 変換時はどうなる？

デフォルトでは最初の 1 文書だけ変換されます。全文書を得るには Python の yaml.safe_load_all、Node.js の yaml.loadAll、または yq eval-all '[.]' で JSON 配列にラップ。ストリーミング (1 行 1 文書) なら yq -o=json -I=0 で NDJSON 出力。

YAML を JSON Lines (NDJSON) で出力する？

yq -o=json -I=0 '.' multi.yaml でコンパクトな 1 行 1 文書出力。Python なら yaml.safe_load_all でストリーミング読み込みして 1 行ずつ書き出し。NDJSON はストリーミング消費側 (BigQuery / S3 / Kafka / ログシッパー) の事実上の標準。

YAML を JSON5 (コメント付き) に変換できる？

JSON5 はコメントを許す JSON のスーパーセット。YAML → JSON5 にするには、まず標準 JSON に変換してから手動でコメントを戻すか、自作ツールを使う必要があります。json5.org の参照実装は JSON5 をパース・出力できますが、主要な YAML ライブラリで直接 JSON5 を出すものはありません。

アンカーとマージキーは JSON で保持される？

されません。JSON にアンカー / エイリアスの概念がないため、変換時にインライン展開されます。データとしては正しいですが「これらはデフォルトを共有している」という元の意図は失われます。YAML に戻すとアンカーは完全に失われます。

yq や Python なしで YAML を JSON に変換するには？

FormatArc YAML to JSON ブラウザツール を使ってください。すべてブラウザで完結、インストール不要。代替として、ほぼすべての現代 OS は Python 3 を持っているので、pip install pyyaml 後に python3 -c 'import sys, yaml, json; ...' が動きます。多くの Linux ディストロでは追加インストールなしでも動作します。

逆方向 (JSON → YAML)

JSON を YAML に変換するには JSON を YAML に変換する方法 を参照してください。FormatArc の JSON to YAML ツール も同じ手軽さで使えます。

関連ガイド

まとめ

5 つの方法で YAML → JSON の全ユースケースをカバーできます。

  • インストール不要・機密データ: FormatArc YAML to JSON — ブラウザ完結、行番号付きエラー
  • CLI / DevOps パイプライン: yq -o=json '.' — 事実上の標準
  • Python アプリ: yaml.safe_load (絶対に yaml.load ではなく) + json.dump
  • Node.js アプリ: js-yaml (yaml.load、安全のため JSON スキーマ指定)
  • Go サービス: gopkg.in/yaml.v3 + encoding/json、マルチドキュメントは Decoder ループ

8 つの落とし穴 (Norway 問題 / コメント消失 / マルチドキュメント処理 / yaml.load の危険性 / 整数キー文字列化 / アンカー展開 / 1.0 浮動小数点化 / スキーマ依存の型推論) は誰でも 1 度は踏みます。曖昧な文字列はクォート、safe_load を使う、マルチドキュメントは明示的に扱う — この 3 つを徹底すれば残りは付随的に解決します。