YAMLとJSONを相互変換して中身を確かめる手順
設定ファイルのYAMLをJSONに直して階層を確かめたり、JSONをYAMLに戻したりする手順を紹介します。読み取りに失敗したときに何行目のどこが悪いのかを日本語で確かめる方法も説明します。
公開読了目安 約6分
この記事の要点
- 貼り付けてボタンを押すだけで YAML と JSON を行き来できる
- 読めなかったときは理由と行番号と該当行が日本語で出る
- 全角スペースの字下げなど、エラーにならない崩れも指摘される
- --- で区切られた複数の設定はまとめて配列になる
- 入力した内容はブラウザの中だけで処理される
目次
設定ファイルの中身を確かめたいときは、YAML⇔JSON変換ツールに貼り付けてボタンを押してください。字下げで表された階層がカッコの入れ子に変わり、どれがどれの子なのかがひと目で分かります。
「読めない」「直らない」が起きる 3 つの場面
設定ファイルを触っていて、こんなところで止まったことはないでしょうか。
「字下げが深くて、どれが誰の子か分からない」。項目が 3 階層 4 階層と続くと、目で追うだけでは自信が持てません。手元で階層を確かめる手段がないと、動かしてみるまで分かりません。
「エラーが出るが、英語で何を言われているのか分からない」。多くのツールは読み取りに使ったライブラリの英語をそのまま出します。行番号だけ分かっても、何が悪いのかは伝わりません。
「エラーは出ないのに、設定が効いていない」。これが一番やっかいです。書き方の崩れには、読み取りが成功したまま構造だけ変わってしまう種類があります。
字下げの崩れは、エラーになるものとならないものがある
字下げの間違いは 2 種類に分かれます。片方は止めてくれますが、もう片方は素通りします。
| 書き方 | 読み取り | 何が起きるか |
|---|---|---|
| タブで字下げ | 失敗する | エラーになるので気づける |
| 半角スペースの数がそろわない | 失敗する | エラーになるので気づける |
| 全角スペースで字下げ | 成功する | 字下げと数えられず、項目名の一部になる |
全角スペースが素通りする理由は単純です。字下げとして数えられるのは半角スペースだけで、全角スペースはただの文字として扱われます。
その結果、親にぶら下げたはずの項目が親から外れ、親のほうは中身が空になります。日本語入力のまま打ってしまったときに起きやすく、画面上は半角スペースと見分けが付きません。
YAML⇔JSON変換ツールの使い方
YAML⇔JSON変換ツールを開くと、貼り付け欄とボタンが 2 つ並んだ画面が出ます。

1. 貼り付けて「YAML → JSON」を押す
設定ファイルの中身をそのまま貼り、左のボタンを押します。字下げで表されていた階層が、カッコの入れ子に変わります。

結果の下には「もう一度読み直して、同じ内容になることを確認しました」と出ます。変換したものを逆向きに戻して突き合わせた結果なので、取りこぼしがないかの目安になります。
2. 指摘が出たら行番号を見る
エラーにならない崩れがあると、結果の上に「先に直したい書き方」という枠が出ます。何行目で何が起きているのかと、どう直すのかが並びます。

上の画面では、変換そのものは通っています。それでも結果を見ると server の中身が空になり、全角スペースごと項目名に取り込まれているのが分かります。
3. 読めなかったときは理由と場所を読む
読み取りに失敗したときは、赤い枠に理由・行番号・その行そのものが出ます。行の下の ^ が、何文字目でつまずいたかを指します。

英語のメッセージを translate にかける手間が要りません。最後の一文に直し方が添えられているので、そのまま手を動かせます。
4. 逆向きに戻す
右のボタンを押すと JSON から YAML に戻せます。このとき、いくつかの値には引用符が付きます。

余計な装飾に見えますが、これには理由があります。NO や yes や 007 は、引用符を外すと読み込む側で真偽値や数値に変わってしまうためです。
画面には何件に引用符を付けたのかと、その理由が出ます。理由が分かっていれば、手で外して壊すことがなくなります。
さらに細かく指定したいとき
「詳細設定」を開くと 3 つの項目が出ます。
- 字下げの幅: 2 スペースか 4 スペースを選べます。両方向の出力に効きます。
- 日付の扱い:
2026-08-25を文字列のまま扱うか、UTC の日時に変える(2026-08-25T00:00:00.000Z)かを選べます。既定は文字列のままです。 - キーを名前順に並べる: JSON から YAML に戻すときに、項目を名前順に並べ替えます。
日付の既定を「文字列のまま」にしているのには理由があります。多くの変換ツールは、日付らしい書き方を見つけると勝手に日時へ変えてしまうためです。
頼んでいない書き換えは起きないほうがよいので、変えたいときだけ選ぶ形にしています。
こんな場面で使える
設定ファイルの階層を確かめる。字下げが深くなった設定を JSON に直すと、カッコで階層が見えます。どの項目がどこにぶら下がっているかを、動かす前に確かめられます。
共有する資料に載せる。手元の JSON を YAML に直すと、カッコと引用符が減って行数も短くなります。説明資料や手順書に貼るときに読みやすい形です。
複数の設定をまとめて見る。--- で区切って 1 つのファイルに複数の設定を書いている場合も、まとめて配列になります。何件あったかが表示されるので、途中が抜けていないかを数で確かめられます。
項目名の並びをそろえる。「キーを名前順に並べる」を使うと、書いた順番の違いが消えます。2 つのファイルを見比べるときに、中身の違いだけが残ります。
使用例
たとえば、社内向けの手順書を書いている担当者が、開発チームから受け取った設定ファイルの内容を資料に載せたいとします。
もらったファイルは JSON で、カッコと引用符が多くて資料には向きません。「JSON → YAML」を押すと、行ごとに項目が並んだ形に変わります。
このとき、郵便番号の 007 に引用符が付きました。画面の説明を読むと、引用符を外すと数値の 7 として読まれると書いてあります。理由が分かったので、そのまま資料に貼りました。
安心して使えるポイント
貼り付けた内容はブラウザの中だけで処理されます。読み取りも書き出しも画面の中で完結するので、社内の設定ファイルをそのまま貼り付けてかまいません。
関連ツール
- JSON整形ツール — 形式は JSON のまま、見た目だけを整えたいとき
- CSV⇔JSON変換 — 表形式のデータと JSON を行き来したいとき
- CSV→Markdownテーブル変換 — 表を文書に貼れる形に直したいとき
- 文字列エスケープ — 引用符や記号の扱いで困ったとき
関連記事
まとめ
設定ファイルの中身を確かめたいとき、読み取りに失敗して困ったとき、どちらも同じ画面で片が付きます。
エラーにならない崩れまで拾ってくれるので、「エラーは出ないのに効かない」に時間を取られることも減ります。
補足: 開発者の方へ
読み取りには js-yaml の loadAll を使い、既定のスキーマではなく CORE_SCHEMA を指定しています。既定の DEFAULT_SCHEMA は YAML 1.1 のタイムスタンプ型を持つためです。
そのままだと 2026-08-25 が Date になります。JSON.stringify を通せば "2026-08-25T00:00:00.000Z" に変わります。
書き出し側は dump に noRefs: true と lineWidth: -1 を渡しています。前者はアンカーの自動生成を止めるため、後者は長い文字列が勝手に折り返されないためです。
引用符が付く判定は js-yaml 側が行いますが、なぜ付いたのかは画面で補っています。js-yaml 4 は YAML 1.2 なので NO を文字列として読みます。
一方 Ruby の Psych や YAML 1.1 の実装は false として読みます。この食い違いは、ノルウェーの国コードで実際に起きたことから NO 問題と呼ばれています。
安全な整数の範囲(Number.MAX_SAFE_INTEGER)を超える整数は、読み込んだ時点で末尾の桁が変わります。この場合は「書いた値 → 読まれた値」の形で画面に出るので、丸まったことに気づけます。
あわせて読みたい
同じテーマ・関連ツールの記事です。