YAML と JSON の変換

貼り付けると、もう一方に変換します。そのときそれぞれの値がどの型として読まれたかも出すので、書いたつもりと違う型になっていたことに気づけます。

no と書くと、false になります

YAML でいちばん有名な事故です。国の一覧を書くとします。

ノルウェーの国コードは NO です。ところがこれを引用符で囲まずに書くと、ノルウェーだけが false に化けます。 国の一覧のはずが、1つだけ「うそ」という値になるわけです。

原因はYAML 1.1 が真偽値として認めている語が6つあることです ──yes・no・on・off・true・false。 これに大文字だけの形（NO）と 頭文字だけ大文字の形（No）も含まれるので、国コードの NO も当たります。

いまの YAML 1.2 では、真偽値は true と false の2語だけになりました。 だから同じ1行でも、読む道具しだいでfalse にも、no という文字列にもなります。 上の道具で版を切り替えると、出てくる JSON そのものが変わることを確かめられます。

直し方は、引用符で囲むだけです

code: 'no' と書けば、どの版のどの道具でも文字列になります。 この道具で JSON から YAML に変換すると、囲まないと型が変わってしまう文字列を自動で囲み、 なぜ囲んだのかも一覧で出します。

キーにも型があります ── on: が true という名前に変わる

値だけの話ではありません。キーの名前も同じ規則で型が決まります。 GitHub Actions の設定ファイルは、いつ動かすかをon: というキーで書きます。ところが on は YAML 1.1 の6語のうちの1つなので、1.1 に従う道具で読むと、キーの名前が true になります。

実際に読ませて確かめました。同じ1行 on: push を読ませると、 キーの名前は PyYAML では True、Ruby Psych では true、js-yaml では on でした。 手元の道具で workflow の設定を読み込んで on というキーを探しても見つからないのは、このためです。

さらにJSON のキーは必ず文字列です。だから YAML のキーが真偽値や数になると、 JSON にするときに文字列へ書き直すしかありません。 この道具は書き直したことを必ず知らせます── 黙って直すと、名前が変わったことに気づけないからです。

同じ YAML 1.1 でも、答えが違うことがあります

1:30 と書いた1行を、YAML 1.1 に従う2つの道具に読ませました。結果はPyYAML が 90、Ruby Psych が 5400。どちらも同じ版を名乗っているのに、値が60倍ちがいました。

YAML 1.1 には60進数という書き方があります。時計と同じ数え方で、1:30 を「1分30秒」と読めば 90、「1時間30分」と読めば 5400秒。 どちらに読むかが実装で分かれていました。 3つに区切った 12:34:56 なら、どちらも 45296 で一致します。

だからこの道具は、こういう値について1つの答えを出して黙るということをしません。 「60進数として読まれることがあり、実装によって値が違う」と出します。YAML 1.2 では、そもそも 1:30 は文字列です。

0 で始まる数字は、8進数になります

YAML 1.1 は、0 で始まる数字を8進数として読みます。だから 012 は 12 ではなく 10 です。 郵便番号や部屋番号を引用符なしで書くと、この形に当たります。

面白いのは090 が文字列のまま残ることです。8進数に 9 という数字は無いので、 どの数の形にも当てはまらず、文字列として扱われます。012 は数に化けるのに、090 は化けない── 同じ「0 で始まる数字」なのに結果が分かれます。

YAML 1.2 では 8進数の書き方が 0o12 に変わり、012 はふつうの10進数の 12 になりました。 つまり 012 は 10 にも 12 にもなり、0o12 は文字列にも 10 にもなります。 どちらの向きにも食い違うので、 数字に見える文字列は引用符で囲むのが安全です。

JSON は YAML の一部です

YAML 1.2 の仕様書（新しいタブで開きます）が、どの JSON ファイルも、そのまま正しい YAML ファイルであると書いています。 上の道具に JSON を貼って「YAML → JSON」で読ませても、ちゃんと読めるのは そのためです。

仕様書には但し書きもあります。YAML ではコロンの前に置けるキーの長さが1024文字までと決められているので、 それより長いキーを持つ JSON はここから外れます。 ふつうの設定ファイルで当たることは、まずありません。

逆は成り立ちません

YAML にできて JSON にできないことは、たくさんあります ──コメント（#）、末尾のカンマ、1つのファイルに文書を2つ以上入れる書き方（---）、同じ中身に名前を付けて使い回す書き方（& と *）。 この道具に、末尾にカンマの付いた JSON を貼ってみてください。JSON としては読めないのに、YAML としてなら読めることが分かります。

字下げに使えるのは、半角スペースだけです

YAML はタブで字下げできません。 仕様書（新しいタブで開きます）が「移植性のため、字下げにタブ文字を使ってはならない」とはっきり書いています。 見た目はスペースと区別がつかないので、画面を見ても分からないのがたちの悪いところです。

日本語を打っているときは、全角スペースも混ざります。 こちらはエラーにならず、キーの名前の一部になります。 名前が変わってしまうので、その項目は「無い」ことになります。 この道具は、どちらも見つけて何行目かを知らせます。

書き方ごとに、どう読まれるか

下の表の値は、実際に3つの実装に同じ文字列を読ませて記録したものです。 1.1 の列は PyYAML 6.0.1、1.2 の列は js-yaml 4.1.0 の結果です。

この道具が読める範囲

YAML には、この道具が読めない書き方があります。読めないものは、黙って飛ばさずにその場でお断りします── 黙って飛ばすと、抜け落ちたことに気づけないからです。

読めるもの

• キーと値（入れ子・字下げ）
• 並び（- で始まる行）
• { } と [ ] で書く形（JSON はこの形なので、そのまま読めます）
• 引用符（' と "）とコメント（#）
• 文書の始まりの ---
• 改行を残す | と、つなげる >

読めないもの（見つけたら、その場でお知らせします）

• アンカーと参照（&名前 と *名前）
• タグ（!!str のような型の指定）
• 1つのファイルに文書を2つ以上（--- で区切る形）
• %YAML のような指示行
• ? で始まる複雑なキー

型の決まりは、思い込みではなく実際に読ませて確かめました（2026-08-15）。 使ったのは PyYAML 6.0.1（Python・YAML 1.1）、Ruby Psych 5.1.2（YAML 1.1）、js-yaml 4.1.0（JavaScript・YAML 1.2 に沿う実装）の3つです。 規則そのものの出どころは、YAML 1.2.2 仕様の Core Schema（新しいタブで開きます）とYAML 1.1 の型の一覧（新しいタブで開きます）です。 なお 1.2 に沿う実装でも、仕様より広く読むところがありました ── js-yaml は 0b1010 と 1_000 を数として、日付の形を日付として読みます。 この道具は、仕様書の表のほうに合わせています。 変換はすべてこの画面の中で行っていて、貼り付けた中身はどこにも送っていません。