JSON から YAML への変換ツール
JSON を YAML に、YAML を JSON に変換します。
このツールについて
JSON または YAML を貼り付けると、もう一方の形式に変換します。変換方向は自動的に判別され、解析エラーは問題のある行を示します。Kubernetes のマニフェスト、Docker Compose ファイル、CI の設定に便利です。
使い方
- JSON または YAML を「入力」ボックスに貼り付けます。
- 方向は「自動判別」のままにするか、JSON から YAML、または YAML から JSON に固定します。
- インデントをスペース 2 個か 4 個から選びます。
- 出力をコピーするか、「出力を入力として使用」をクリックして逆方向に変換します。
よくある質問
- YAML は JSON のスーパーセットですか?
- 実質的にはそうです。YAML 1.2 以降、有効な JSON ドキュメントはほぼすべて有効な YAML でもあります。逆は成り立ちません。YAML にはコメント、アンカー、複数行文字列など、JSON では表現できないものがあるためです。
- JSON に変換すると、YAML のコメントはどうなりますか?
- JSON にはコメントがないため、削除されます。コメントが重要な場合は、YAML ファイルを正本として保管してください。
- --- で区切られた複数の YAML ドキュメントを含むファイルを変換できますか?
- はい。各ドキュメントが JSON 配列の 1 要素になり、ステータス行に見つかったドキュメントの数が表示されます。
- 「no」が false になるのはなぜですか?
- 古い YAML 1.1 のパーサーは、yes、no、on、off などの単語を真偽値として扱います。このツールは true と false だけが真偽値となる YAML 1.2 のルールを使いますが、他のツールがファイルを読む場合はそうした値を引用符で囲んでください。
- YAML の日付は JSON の日付に変換されますか?
- JSON には日付型がないため、2026-01-12 や 2026-01-12T10:00:00Z のような値はただの文字列のまま残り、ほとんどのプログラムもそれを想定しています。PyYAML など一部の YAML 1.1 パーサーは同じ値を日付オブジェクトに変換するため、ファイルを読み込んだ結果がツールによって異なることがあります。
- 0755 のようなファイルモードが 755 になるのはなぜですか?
- YAML 1.2 の規則では先頭のゼロは 8 進数を意味しないため、0755 は 10 進数の 755 になります。8 進数には 0o 接頭辞が必要で、0o755 は 493 になります。古い YAML 1.1 のツールは 0755 を 8 進数として読むため、読み込むツールが重要な場合は mode: "0755" のようにファイルモードをクォートしてください。
- YAML の出力で一部の文字列がクォートされるのはなぜですか?
- 読み戻したときに別の型として解釈される文字列にはクォートが付くため、往復しても値が保たれます。JSON の文字列 "true" は YAML でも真偽値の true ではなく "true" になり、"123"、"null"、"1.10"、コロンとスペースを含むテキストも同様です。通常の文字列はクォートされません。
JSON と YAML の違いと使い分け
JSON と YAML が表現するデータは同じで、オブジェクト、配列、文字列、数値、真偽値、null です。JSON は厳格でパースが速いため、API、package.json、プログラム間で受け渡すデータの標準になっています。YAML は人が手で編集するために設計されており、波かっこやクォートが少なく、# でコメントを書け、複数行の文字列も扱えます。そのため、Kubernetes のマニフェスト、Docker Compose ファイル、GitHub Actions のワークフロー、Ansible の playbook は YAML で書かれています。
実用的な目安として、プログラムが書き出したファイルを別のプログラムが読むなら JSON を使います。人がファイルを管理するなら、YAML のほうが読みやすくレビューしやすいでしょう。多くのツールは両方を受け付け、kubectl apply もどちらの形式でも使えます。JSON から YAML への変換ツールは、kubectl get deployment web -o json のように CLI や API から JSON が返ってきて、Git に保存する読みやすい YAML 版が欲しいときに便利です。
YAML のインデントエラーとパースエラーを直す方法
YAML はインデントで構造を表すため、パースエラーのほとんどは空白の問題です。インデントにタブはまったく使えず、パーサーは「Tabs are not allowed as indentation」と報告します。同じリストの項目や同じマップのキーは同じ列から始める必要があり、入れ子の値はそのキーより深くインデントしなければなりません。エラーにはパースが止まった行と列が表示され、たいていは本当の誤りの位置かその直後です。
クォートしていない値の中にあるコロンとスペースも、YAML の典型的なエラーです。url: http://example.com は問題ありませんが、title: Note: read this は 2 つ目のコロンが入れ子のマッピングを始めてしまうため失敗します。title: "Note: read this" のように、こうした値はクォートしてください。@ やバッククォートで始まる値もクォートが必要で、version: "1.10" のように数値に見える文字列も同様です。クォートしないと数値の 1.1 になってしまいます。
JSON に変換すると YAML のアンカーはどうなりますか?
YAML では、&defaults のようなアンカーでブロックを一度定義し、エイリアス *defaults で別の場所から再利用できます。JSON には同等の仕組みがないため、YAML から JSON への変換では、すべてのエイリアスがアンカーの値の完全なコピーに置き換えられます。JSON としては正しいものの長くなり、コピー同士のつながりは失われます。<<: *defaults と書くマージキーは YAML 1.2 の仕様に含まれないため、JSON では << という名前のキーとして残ります。
変換したファイルをコミットする前に、往復変換を確認しましょう。「出力を入力として使用」をクリックして結果を逆変換し、テキスト差分で元のファイルと比較します。値は変わらずに残るはずですが、表現は異なる場合があります。コメントは消え、アンカーは展開され、クォートの付け方が変わることもあります。Kubernetes やほとんどの YAML スタイルガイドはスペース 2 個でインデントし、ここでもそれがデフォルトです。好みに応じて、スペース 4 個も選べます。
うまく動かない、または結果がおかしいですか? このツールの問題を報告