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

JSON YAML 変換ガイド — Kubernetes / Docker Compose / Ansible 対応

JSON を YAML に変換する方法を解説。Kubernetes マニフェスト、Docker Compose、Helm values、Ansible playbook 対応。ブラウザツール (アップロード不要) と yq / Python / Node.js / Go の使い分け、キー順保持・ブロックスカラー・マルチドキュメント出力・落とし穴 (Norway 問題) まで網羅。

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

  • 今すぐ変換したい・インストール不要 → FormatArc JSON to YAML (ブラウザ完結、アップロード不要、JSON 検証、キー順保持)
  • CLI / ワンライナー → yq -P '.' file.json (DevOps 標準、-P でブロック形式)
  • Python スクリプト + キー順保持 → yaml.dump(data, sort_keys=False, default_flow_style=False, allow_unicode=True)
  • Node.js アプリ → js-yaml の yaml.dump(data, { lineWidth: -1 })
  • Go サービス → gopkg.in/yaml.v3 の yaml.Marshal
  • Kubernetes ラウンドトリップ → kubectl get ... -o json | jq '...' | yq -P '.'
  • JSON 配列をマルチドキュメント YAML に分割 → yq -P '.[]' --split-exp 'true' array.json
方法 セットアップ キー順保持 ブロックスカラー (|) マルチドキュメント出力 コメント挿入
FormatArc ブラウザ なし あり あり なし なし (後で追加)
yq -P '.' brew install yq あり あり あり (split-exp) なし
Python yaml.dump (PyYAML) pip install pyyaml sort_keys=False 必須 あり 手動 --- 区切り なし
Python ruamel.yaml pip install ruamel.yaml あり あり あり あり (API 経由)
Node js-yaml npm install js-yaml あり あり 手動 なし
Go yaml.Marshal go get gopkg.in/yaml.v3 あり (yaml.Node 経由) あり Encoder ループ なし

JSON → YAML 変換は構造的にはほぼ自明 (両形式が同じデータモデルを表現する)。難しいのはキー順の保持、文字列のクォート判断、複数行文字列の扱い、JSON 配列をマルチドキュメント YAML に分割、Norway 問題の回避といった実装上の注意点です。

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

JSON と YAML は同じデータ構造 (map / list / 文字列 / 数値 / 真偽値 / null) を表現できます。機能的には互換ですが、文脈と可読性で使い分けます。

Kubernetes / コンテナオーケストレーション

Kubernetes はリソース定義として JSON と YAML の両方を受け付けますが、エコシステムは圧倒的に YAML 中心です。公式ドキュメント・チュートリアル・ブログ記事・Stack Overflow 回答もほぼ YAML。プログラムで生成されたリソース定義 (多くは JSON) を YAML に変換することで、クラスタ設定全体と一貫性を保ち、プルリクエストでレビューしやすくなります。

kubectl には変換用のフラグがあります:

kubectl get deployment web-app -o yaml > deployment.yaml

ただし source of truth が JSON のとき (admission controller webhook レスポンス、Terraform Kubernetes プロバイダの出力、カスタムオペレータの reconciliation 結果) は明示的な変換が必要です。

Docker Compose / Helm values

Docker Compose ファイルは YAML が定義です。サービス設定が JSON で保存されている場合 (configuration management API やサービスメッシュコントロールプレーン由来)、Compose ファイルとして使う前に YAML 化が必要。

Helm chart の values ファイルも YAML。Vault や AWS Parameter Store のような外部ソースから取得 (JSON で返ってくる) するとき、helm install -f values.yaml に渡す前に YAML 化します。

Ansible playbook

Ansible playbook やインベントリは YAML 形式。クラウド API / CMDB / 資産管理 DB からの出力は通常 JSON。playbook で使う前の最初のステップが YAML 変換です。

可読性と編集しやすさ

YAML は人にとって読みやすい形式。波括弧・角括弧・カンマがない分、ノイズが少ない:

JSON:

{
  "server": {
    "host": "0.0.0.0",
    "port": 8080,
    "workers": 4,
    "logging": {
      "level": "info",
      "format": "json"
    }
  }
}

YAML:

server:
  host: 0.0.0.0
  port: 8080
  workers: 4
  logging:
    level: info
    format: json

YAML 版は文字数も少なく、階層構造がインデントで表現されます。人が頻繁に編集する設定ファイルではこの差が効きます。

コメントの追加

JSON にコメント構文はありません。YAML はあります。設定ファイルに「なぜこの値か」を残したいときは YAML に変換してからコメントを追加します:

server:
  host: 0.0.0.0
  port: 8080
  # 本番は workers を増やす。staging なら 4 で十分
  workers: 4

JSON → YAML 変換は注釈追加の最初のステップになることが多い。コメント自体は JSON から持ち越せません (JSON にコメント構文がないため)。どうしても JSON 側で表現したい場合は JSON にコメントを書く方法 を参照。

JSON → YAML が必要な 4 つの具体シーン

シーン 1: Kubernetes API → Git のマニフェスト

Kubernetes API は JSON を返します。Deployment を GitOps リポジトリに YAML で commit したい:

kubectl get deployment web-app -o json | yq -P '.' > deployment.yaml
git add deployment.yaml && git commit -m "Capture web-app current state"

シーン 2: Vault の Helm values

Vault はシークレットを JSON で返します。Helm は values.yaml が必要:

vault read -format=json secret/prod/app | jq '.data.data' | yq -P '.' > values.yaml
helm upgrade --install app ./chart -f values.yaml

シーン 3: コントロールプレーン API から Docker Compose

サービスメッシュのコントロールプレーンが JSON でサービス定義を返す。Docker Compose は YAML:

curl -s https://control-plane/services | jq '.' | yq -P '.' > docker-compose.yml
docker compose up -d

シーン 4: CMDB から Ansible インベントリ

多くの CMDB (Device42 / ServiceNow / NetBox) は REST で JSON を返します。Ansible インベントリは YAML:

curl -s https://cmdb/hosts | jq '.hosts' | yq -P '.' > inventory.yaml
ansible-playbook -i inventory.yaml site.yaml

4 シーンすべてで変換は 1 パイプラインステップで済み、スクリプト化が容易です。

ブラウザ完結 vs クラウド変換: 設定ファイルアップロードのリスク

多くのオンライン JSON → YAML コンバータが「クライアントサイド処理」と謳いつつ、実際にはサーバーに POST しています。設定ファイルでこれは危険です。設定はしばしば次のような情報を含むため:

  • secret: ブロックの API トークン・認証情報
  • パスワード入りデータベース接続文字列
  • クラウドアクセスキー (IAM ロール、サービスアカウント JSON)
  • 内部ホスト名・インフラレイアウト
  • 暗号鍵・TLS 証明書

「ログには残さない」と謳っていても、サーバー側の 1 つの設定ミスでシークレットが漏れます。ブラウザ内で完結 (本当にサーバーに送らない) ツールを使うのが安全策です。

これは机上の話ではありません。2025 年 11 月、人気のオンライン整形・変換サイト JSONFormatter と CodeBeautify で、ユーザーが保存したデータが「Recent Links」機能を通じて誰でも閲覧できる状態になっていたと、セキュリティ企業 watchTowr が報告しました。集まった提出物は 8 万件超 (5GB 以上) にのぼり、Active Directory 認証情報、データベースやクラウドのアクセスキー、秘密鍵、CI/CD のシークレット、JWT や API トークン、決済ゲートウェイの認証情報、AWS Secrets Manager の完全エクスポートまで含まれ、政府・銀行・医療・航空宇宙など幅広い組織が影響を受けました (watchTowr の調査報告)。入力を保存または送信するコンバータに貼り付けたものは、同じように露出しうるのです。

確認方法: コンバータを開き、DevTools の Network タブで「Disable network」をオンにしてから JSON を貼り付ける。ツールが動き続けるならブラウザ内処理。ハングしたりエラーが出るならクラウド処理。

FormatArc JSON to YAML ツール はネットワーク無効でも動作します。ローカルの yq も、Python / Node / Go スクリプトも同じです。

Kubernetes Secret、API トークン入りの Helm values、認証情報を含む設定はすべてローカル変換を使ってください。

オンライン変換ツールが安全かを自分で見分ける手順は オンライン JSON 変換は安全か でまとめています。

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

JSON to YAML ツール は JSON を整形 YAML に変換します。すべてブラウザ内処理。

  1. JSON to YAML を開く
  2. 左側のエディタに JSON を貼り付ける
  3. 「変換」ボタンを押す

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

ツールは変換前に JSON を検証します。カンマ抜け、末尾の余分な }、クォートなしキーなどの構文エラーは行番号付きで報告。YAML 変換が目的でなくとも JSON バリデータとして使えます。よくある JSON 構文エラーの対処は JSON parse error の対処 を参照。

ブラウザ内処理なので認証情報・内部設定・機密データを貼り付けても安全。

出力は 2 スペースインデント (Kubernetes 標準) で、入力 JSON のキー順を保持、デフォルトでブロック形式 (普通の YAML の見た目、フロー形式の波括弧 ではない)。

方法 2: yq (DevOps 標準)

yq は逆方向の変換と同じくらいスムーズに JSON → YAML を扱えます:

# 基本的な変換
yq -P '.' input.json > output.yaml

# stdin からパイプ
cat config.json | yq -P '.' > output.yaml

# ブロック形式 (整形); -P がないとフロー形式になることがある
yq -P '.' input.json

# インデント幅指定 (デフォルト 2)
yq -P -I=4 '.' input.json

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

# JSON 配列からマルチドキュメント YAML 出力
yq -P '.[]' --split-exp 'true' kubernetes-list.json

-P は --prettyPrint の短縮形で、YAML をブロック形式に強制します。-P なしだとネスト構造でフロー形式 (JSON 風) で出力されることがあります。

インストール:

# macOS
brew 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

# Docker
docker run --rm -i mikefarah/yq -P '.' < input.json > output.yaml

yq + jq でフィルタしながら変換

# Deployment から spec.template だけ抽出して YAML 化
jq '.spec.template' deployment.json | yq -P '.'

# yq 1 つでも可能
yq -P '.spec.template' deployment.json

方法 3: Python (yaml.dump と ruamel.yaml)

PyYAML 基本

import json
import yaml

with open("config.json") as f:
    data = json.load(f)

with open("config.yaml", "w") as f:
    yaml.dump(
        data,
        f,
        default_flow_style=False,   # ブロック形式 (通常の YAML 表示)
        allow_unicode=True,          # Unicode を escape せず出力
        sort_keys=False,             # 入力のキー順を保持
    )

重要な 3 つのオプション:

  • default_flow_style=False — {a: 1, b: 2} のフロー形式ではなく通常の YAML
  • allow_unicode=True — 日本語・アクセント文字・絵文字を \uXXXX エスケープせずに出力
  • sort_keys=False — JSON の入力順を保持 (Kubernetes では apiVersion を kind より前に置く必要があり必須)

ワンライナー

python3 -c 'import sys, json, yaml; yaml.dump(json.load(sys.stdin), sys.stdout, default_flow_style=False, allow_unicode=True, sort_keys=False)' < input.json > output.yaml

ruamel.yaml でラウンドトリップ + コメント

生成した YAML にコメントを追加したい場合や、特定のフォーマットを保持したい場合:

from ruamel.yaml import YAML
import json

yaml_writer = YAML()
yaml_writer.default_flow_style = False
yaml_writer.preserve_quotes = True
yaml_writer.indent(mapping=2, sequence=4, offset=2)

with open("config.json") as fin:
    data = json.load(fin)

# プログラムでコメントを追加
data.yaml_set_comment_before_after_key("server", before="Web server 設定")

with open("config.yaml", "w") as fout:
    yaml_writer.dump(data, fout)

コメントが必要な場面では ruamel.yaml が正解。JSON はコメントなしなので、注釈は変換中または変換後に追加するしかありません。

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

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

const data = JSON.parse(fs.readFileSync("config.json", "utf8"));
const ymlText = yaml.dump(data, {
  lineWidth: -1,    // 長い行を折り返さない
  noRefs: true,     // YAML アンカー・エイリアスを出力しない
  sortKeys: false,  // 入力順を保持
  quotingType: '"', // クォートが必要なときはダブルクォート優先
});

fs.writeFileSync("config.yaml", ymlText);

lineWidth: -1 で js-yaml の自動折り返しを抑制 (URL や長い値が予期せぬ改行で壊れるのを防ぐ)。noRefs: true でアンカー生成を無効化 (kubectl などアンカー非対応の下流ツール向け)。

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

package main

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

    "gopkg.in/yaml.v3"
)

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

Go でキー順を保持するには interface{} ではなく yaml.Node を直接使います。json.Unmarshal で map[string]interface{} に入れると Go のマップが意図的にランダム化されるため順序が壊れます。Kubernetes マニフェストでは順序が重要なので問題:

// 明示的に順序保持するなら yaml.Node を使う
var node yaml.Node
yaml.Unmarshal(data, &node)
out, _ := yaml.Marshal(&node)

代替案: Go の encoding/json はマップのキーをアルファベット順に並べるため、挿入順を保持するには github.com/iancoleman/orderedmap などのサードパーティライブラリを使います。

Kubernetes Deployment 実例: JSON ↔ YAML ラウンドトリップ

実際のシナリオ。JSON で書かれた Deployment 定義から始めます:

{
  "apiVersion": "apps/v1",
  "kind": "Deployment",
  "metadata": {
    "name": "web-app",
    "labels": { "app": "web", "tier": "frontend" }
  },
  "spec": {
    "replicas": 3,
    "selector": { "matchLabels": { "app": "web" } },
    "template": {
      "metadata": { "labels": { "app": "web" } },
      "spec": {
        "containers": [{
          "name": "nginx",
          "image": "nginx:1.25",
          "ports": [{ "containerPort": 80 }],
          "env": [
            { "name": "LOG_LEVEL", "value": "info" }
          ]
        }]
      }
    }
  }
}

yq で変換:

yq -P '.' deployment.json

出力:

apiVersion: apps/v1
kind: Deployment
metadata:
  name: web-app
  labels:
    app: web
    tier: frontend
spec:
  replicas: 3
  selector:
    matchLabels:
      app: web
  template:
    metadata:
      labels:
        app: web
    spec:
      containers:
        - name: nginx
          image: nginx:1.25
          ports:
            - containerPort: 80
          env:
            - name: LOG_LEVEL
              value: info

apiVersion → kind → metadata → spec の順が保持されています。PyYAML をデフォルト (sort_keys=True) で使うとアルファベット順になり、kubectl apply は通るものの上流の Kubernetes サンプルとの diff が崩れてレビューしづらくなります。

適用: kubectl apply -f deployment.yaml。

YAML の文字列クォート: "8080" が 8080 になる

YAML の文字列クォートルールは複雑で、コンバータはこれを出力に適用します。これが予期せぬ型変化を引き起こすことがあります。

数値風の文字列がアンクォート化される

JSON で "8080" (API がそう返したから) を文字列で持っていた場合、コンバータが YAML でアンクォートして数値化してしまうことがあります:

JSON:

{ "port": "8080" }

良い変換結果:

port: "8080"   # 文字列のまま保持

悪い変換結果:

port: 8080     # 数値になってしまった

yq v4 は元の型を保持 (文字列のまま)。PyYAML もデフォルト設定で保持。js-yaml も保持。手作りの変換コードでヒューリスティクスを使うとこのリスクが高い。

PyYAML でクォートを強制するには:

class QuotedString(str): pass

def represent_quoted(dumper, data):
    return dumper.represent_scalar("tag:yaml.org,2002:str", str(data), style='"')

yaml.add_representer(QuotedString, represent_quoted)

真偽値風の文字列

{ "active": "yes" }

変換後 (YAML 1.1 スキーマで):

active: yes    # 次のラウンドトリップで真偽値 true に解釈される

良いコンバータはこれをクォートします:

active: "yes"

ソース JSON を制御できるなら、true / false / null (JSON ネイティブ型) を "yes" / "no" のような文字列より優先しましょう。Norway 問題を回避できます。

特殊文字で始まる文字列

YAML の特殊文字 (*、&、!、{、[、>、|、#、@、\``、先頭の -`) で始まる値はクォートが必要:

{ "tag": "*production*" }

tag: "*production*"   # 先頭の * のためクォートされる

主要コンバータはこれを正しく処理します。リスクは手作りコンバータでのみ顕在化。

ブロックスカラー: | vs > 複数行文字列

JSON は複数行文字列を \n エスケープシーケンスで表現します。良いコンバータは YAML でブロックスカラー記法を使います:

JSON:

{
  "description": "Line one\nLine two\nLine three"
}

コンバータには YAML で 3 つの合理的選択肢があります:

リテラルブロック (|) — 改行をそのまま保持

description: |
  Line one
  Line two
  Line three

ソースの改行が出力文字列の改行になります。ログメッセージ、証明書 PEM ブロック、設定に埋め込むコードスニペットに最適。

フォールドブロック (>) — 改行をスペースに

description: >
  Line one
  Line two
  Line three

これは Line one Line two Line three という文字列になります (改行がスペースに、空行が単一改行に)。段落として表示したい長文に最適。

クォート付き単一行

description: "Line one\nLine two\nLine three"

ダブルクォート文字列内のリテラル \n エスケープ。動きますが 2-3 行以上だと読みにくい。

yq -P は改行を含む文字列にデフォルトで | (リテラル) を使います。PyYAML は default_style=None (デフォルト) で改行を含む文字列に | を使用。js-yaml も同じ。

PyYAML で特定スタイルを強制:

yaml.dump(data, default_style='|')   # すべて文字列をリテラルブロックに
yaml.dump(data, default_style='"')   # すべて文字列をダブルクォートに

複数行スクリプトや PEM 証明書を含む Kubernetes ConfigMap では | が正解。kubectl create configmap --from-file も | を生成します。

キー順序: apiVersion → kind → metadata を保持

JSON オブジェクトと YAML マッピングはどちらも仕様上 unordered。実際には全員が意味のある順序を期待します。特に Kubernetes リソースでは慣習的に apiVersion を先頭、続いて kind、metadata、spec の順。

主要コンバータはソース順を保持します:

  • yq (Go yaml.v3): 内部 yaml.Node 経由で順序保持
  • PyYAML + sort_keys=False: 順序保持 (デフォルトは sort_keys=True でアルファベット順、明示的に設定)
  • js-yaml + sortKeys: false: 順序保持
  • ruamel.yaml: デフォルトで順序保持

注意点:

  • PyYAML のデフォルト sort_keys=True — すべてアルファベット順、apiVersion が kind の後ろになる
  • Go の interface{} unmarshalling — 順序がランダム化される (yaml.Node を使う)
  • 自作コンバータが map[string]string を構築して出力 — Go のマップは意図的にランダム

YAML を Git にコミットする場合、キー順のランダム化はデータが変わっていないのに巨大な diff チャーンを引き起こします。GitOps ワークフローでコンバータを採用する前に必ず順序保持を確認してください。

JSON 配列からマルチドキュメント YAML

よくあるパターン。Kubernetes リソースの JSON 配列があり、--- で区切られた複数文書の YAML ファイル 1 つにしたい (リソース 1 つにつき 1 文書)。

yq で

yq -P '.[]' --split-exp 'true' kubernetes-list.json

出力:

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

ファイル保存: yq -P '.[]' --split-exp 'true' kubernetes-list.json > resources.yaml。これで kubectl apply -f resources.yaml できる状態に。

Python で

import json
import yaml

with open("list.json") as f:
    items = json.load(f)["items"]   # 実際の配列パスに合わせて調整

with open("resources.yaml", "w") as f:
    yaml.dump_all(
        items,
        f,
        default_flow_style=False,
        allow_unicode=True,
        sort_keys=False,
    )

yaml.dump_all が --- 区切りで複数文書を出力。

Node.js で

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

const items = JSON.parse(fs.readFileSync("list.json", "utf8")).items;
const ymlText = items.map(item => yaml.dump(item, { lineWidth: -1 })).join("---\n");

fs.writeFileSync("resources.yaml", ymlText);

js-yaml には組み込みの dumpAll がないので ---\n で手動結合。

CI/CD パイプライン統合

GitHub Actions

name: Convert JSON config to YAML for deployment
on:
  push:
    paths: ["config/*.json"]

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 all configs
        run: |
          for f in config/*.json; do
            yq -P '.' "$f" > "${f%.json}.yaml"
          done
      - name: Validate against Kubernetes
        run: |
          for f in config/*.yaml; do
            kubectl apply --dry-run=client -f "$f"
          done
      - uses: stefanzweifel/git-auto-commit-action@v5
        with:
          commit_message: "Auto-convert configs to YAML"

GitLab CI

generate-yaml:
  image: mikefarah/yq:latest
  stage: build
  script:
    - for f in config/*.json; do yq -P "." "$f" > "${f%.json}.yaml"; done
  artifacts:
    paths:
      - config/*.yaml

Jenkins (Declarative)

pipeline {
  agent any
  stages {
    stage('Convert configs') {
      steps {
        sh 'for f in config/*.json; do yq -P "." "$f" > "${f%.json}.yaml"; done'
      }
    }
    stage('Validate') {
      steps {
        sh 'for f in config/*.yaml; do kubectl apply --dry-run=client -f "$f"; done'
      }
    }
  }
}

変換 + 検証で典型的な CI ランに 5 秒未満を加算するだけ。

Kubernetes の実用ワークフロー

実務でよくあるシナリオ。kubectl で JSON 取得、修正、YAML で保存、Git にコミット:

# 現 Deployment を JSON で取得
kubectl get deployment web-app -o json > deployment.json

# 編集 (または自動修正なら jq)
jq '.spec.replicas = 5' deployment.json > updated.json

# Git リポジトリ用に YAML 化
yq -P '.' updated.json > deployment.yaml

# 確認、コミット、push
git diff deployment.yaml
git add deployment.yaml && git commit -m "Scale web-app to 5 replicas"

ワンパイプラインで:

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

スクリプト化不要な単発修正なら、JSON を JSON to YAML ツール に貼り付け、YAML 出力をコピーしてファイルに保存するのが最速。

よくある質問

YAML 出力で port 8080 が文字列になる

なりません — YAML はクォートなしの数値を数値として扱います。実際に起きるのは逆のケース。JSON の文字列 "8080" が YAML でクォートなしの 8080 として出力され、次のラウンドトリップで数値化されます。文字列型を保持するにはコンバータが曖昧な値をクォートするか確認。yq v4 とモダンな PyYAML はこれを正しく処理します。

YAML のコメントをラウンドトリップで保持できる？

不可。JSON にコメントがないので、JSON → YAML 変換でコメントを追加しても、YAML → JSON 変換で消えます。コメントが重要なら YAML を真実の源として残し、JSON 側では JSON コメントの回避策 を使ってください。

PyYAML がキーをアルファベット順にしてしまう

PyYAML の yaml.dump はデフォルト sort_keys=True。sort_keys=False で入力順を保持します。Kubernetes リソースで apiVersion を先頭に置きたいなら必須。

Helm values.json を values.yaml に変換できる？

可能。values 構造は同一で形式だけ違います。yq -P '.' values.json > values.yaml を使い、helm template ./chart -f values.yaml > rendered.yaml で確認するとマニフェストが一致しているか検証できます。

YAML の null が ~ で表示される

YAML の null には複数表現があります: null / Null / NULL / ~ / 空。コンバータごとに選択が異なります。yq は null、PyYAML はデフォルトで空、js-yaml は null。すべて等価で見た目だけの違い。特定表現を強制したいなら:

yaml.add_representer(type(None), lambda d, _: d.represent_scalar("tag:yaml.org,2002:null", "null"))

JSON のアンカーは YAML 出力に保持される？

JSON にアンカーはありません。YAML 出力でアンカー (&anchor / *alias) を使いたい場合は、変換後に手動で追加するか YAML 対応エディタを使う必要があります。ruamel.yaml はプログラム的なアンカー生成をサポートしているので自動化したい場合はこれ。

ネット接続なしで JSON を YAML に変換するには？

ローカル選択肢 3 つ: yq をインストール (Go バイナリ、依存ゼロ)、Python スクリプト + pyyaml、Node.js スクリプト + js-yaml。FormatArc JSON to YAML ツール もページを 1 度ロードすればオフライン動作 (ブラウザ内処理なので追加のネットワークアクセス不要)。

逆方向 (YAML → JSON)

YAML を JSON に戻す (API 送信、デバッグ、JSON 専用ツールへの投入) には YAML を JSON に変換する方法 を参照。FormatArc の YAML to JSON ツール も同じ手軽さ。

関連ガイド

まとめ

JSON → YAML 変換は DevOps、Infrastructure as Code、Configuration Management のワークフローで頻繁に必要になります。5 つの方法で全用途をカバー:

  • インストール不要・機密データ: FormatArc JSON to YAML — ブラウザ完結、キー順保持、行番号付き JSON エラー
  • CLI / パイプライン: yq -P '.' — DevOps 標準、フィルタとマルチドキュメント出力対応
  • Python アプリ: yaml.dump(data, sort_keys=False, default_flow_style=False, allow_unicode=True)
  • Node.js アプリ: js-yaml の yaml.dump + lineWidth: -1 と sortKeys: false
  • Go サービス: gopkg.in/yaml.v3 の Marshal、順序保持には yaml.Node

本番で重要な 4 つの観点: キー順保持 (Kubernetes で必須)、複数行文字列にブロックスカラー (|) を使う、消費側がマルチドキュメントを要求するなら JSON 配列を分割、Norway 問題でアンクォート文字列が真偽値・数値化されないよう注意。