YAMLとJSONの主な違いは何ですか？

YAMLは人間の可読性を重視して設計されています——インデントで構造を表現し、コメントを使え、文字列は多くの場合クォートが不要です。JSONはマシン可読性とデータ交換を重視して設計されています——厳格で、コメントなし、明示的な括弧と引用符。YAML 1.2はJSONのスーパーセットなので、有効なJSONは有効なYAMLでもあります。

YAML to JSON変換でデータが失われますか？

コメントは常に失われます——JSONにコメント構文がありません。YAMLのアンカーとエイリアスは解決されてインライン展開されます。カスタムYAMLタグはパーサーが処理方法を知らない限り削除されます。単純なスカラー、マップ、シーケンスのみを使う通常の設定ファイルでは変換はロスレスです。

YAMLのboolean問題とは何ですか？

YAML 1.1では、yes、no、on、off、true、falseがすべてbooleanとして扱われます。つまり「country: no」はJSON変換でbooleanのfalseになります。YAML 1.2ではtrueとfalseのみに制限されていますが、多くのパーサーがまだ1.1ルールを使っています。文字列として扱いたい場合は必ずクォートしてください。

JSONからYAMLへの逆変換はロスレスですか？

構造的には完全に往復できます——オブジェクト、配列、文字列、数値、booleanはすべてクリーンにマッピングされます。失われるのはコメント（JSONにはそもそも存在しない）と、手書きしたYAML特有の書式です。JSON→YAML変換の結果は機械生成のように見えます。

YAMLはJSONのスーパーセットですか？

YAML 1.2仕様では技術的にはYes。有効なJSONドキュメントは有効なYAMLでもあります。実際には古いYAML 1.1パーサーでいくつかのエッジケースがあります——特に先頭ゼロを持つ数値（JSONでは不正）とより広いbooleanセットについて。現実世界の使用では、JSONを有効なYAMLとして扱うことはほぼ安全です。

YAMLからJSONへ — いつ変換が必要か、何が失われるか

数年前、CI/CDパイプラインをあるプラットフォームから別のプラットフォームに移行する作業を手伝っていました。古いシステムはパイプライン定義にJSONを使用していました。新しいシステムはYAMLを使用していました。理論的には大した問題ではありません——どちらのフォーマットも同じ階層データを表現しますよね？

実際には、括弧をインデントに変換し、キーから引用符を削除し、JSONのnullがYAMLの~になるかパーサーの気分によってnullになるかを覚えるのに驚くほど多くの時間を費やしました。面倒でエラーが起きやすい作業でした。最終的に誰かがコンバーターツールを教えてくれて、最初からそれを使わなかったことを本当に馬鹿だと感じました。

YAMLとJSONとは何か

どちらも、プログラミング言語ではありません。データシリアライゼーションフォーマット——異なるシステムが読み書きできるよう構造データをテキストとして表現する方法です。

JSON（JavaScript Object Notation）は2000年代初頭にWebクライアントとサーバー間でデータを送るための軽量なXMLの代替として設計されました。厳格で最小限、明示的：すべての文字列は引用符、すべてのオブジェクトは波括弧、すべての配列は角括弧、そして値の型は6種類のみ（文字列、数値、オブジェクト、配列、boolean、null）。コメントなし、エスケープなしの複数行文字列なし、以前に定義した値を参照する方法もありません。

YAML（YAML Ain't Markup Language——再帰的略語）は後に登場し、人間の可読性を重視して設計されています。インデントでネストを表現し、ほとんどの場合にクォートなしの文字列、#によるコメント、値を一度定義して複数箇所で参照できるアンカーとエイリアスをサポートします。YAML 1.2はJSONのスーパーセットと定義しており、有効なJSONドキュメントは有効なYAMLでもあります。

実際には、JSONはAPIと通信して信頼性の高いマシン間通信が必要な場合に使うフォーマットです。YAMLは人間が設定を書き保守する場合に使うフォーマットです——インデントは括弧よりも速く把握でき、コメントは設定ファイルで非常に価値があります。

変換が実際に必要な場面

CI/CDプラットフォームの移行：異なるプラットフォームは異なる好みを持ちます。GitHub ActionsはYAMLを使います。古いJenkins設定はJSONやXMLを使います。移行する場合、パイプライン定義を変換する必要があります。

KubernetesとREST API：kubectlはYAMLを受け付けます。Kubernetes API自体はJSONで動作します。APIに直接スクリプトを使ってアクセスする場合、JSONが必要です。人間が読んでgitにコミットするためにマニフェストを書く場合、YAMLが欲しいです。

設定ファイルとアプリケーションのデフォルト：多くのアプリケーションはJSONでデフォルト設定を出荷しますが（機械生成なので）、YAMLでドキュメント化します（人間が読む場合）。ドキュメントから設定をプログラム的な設定ファイルにコピーする場合、変換が必要です。

APIレスポンスのデバッグ：APIはJSONを返します。レスポンスを検査し、編集して再実行したい場合、YAMLの方が読みやすいことがあります。

YAML to JSONコンバーターの動作

変換は2つのステップです：YAMLをメモリ内データ構造に解析し、その構造をJSONとしてシリアライズします。

YAMLアンカーとエイリアスが解決されます。YAMLでは&anchorで値を定義し、*aliasで参照できます。JSONに変換すると、アンカーはなくなり——参照された値が使われているすべての場所にそのままインラインで繰り返されます。

型推論が発生します。YAMLは暗黙の型付けを行います。裸のtrueはbooleanになります。42は整数になります。3.14はfloatになります。2026-04-21はいくつかのパーサーでは日付になります。JSONには日付がなく、仕様上intとfloatの区別もありません——ただ「数値」です。

コメントは削除されます。これが最も痛い損失です。タイムアウトが30秒に設定されている理由や謎のフラグが何をするかを説明する役立つコメントが、変換後はなくなります。JSONにはコメント構文がありません。

YAML 1.1対1.2のboolean問題

YAML 1.1では、以下の値がすべてbooleanとして扱われます：

true, false, yes, no, on, off
TRUE, FALSE, YES, NO, ON, OFF
True, False, Yes, No, On, Off

つまりenabled: yesは"enabled": trueになります。そしてcountry: NO——ノルウェーのISO国コードかもしれません——は"country": falseになります。

YAML 1.2は2009年に発行され、booleanをtrueとfalseだけに制限しましたが、驚くほど多くのYAMLパーサーがまだ1.1ルールを実装しています。

安全なルール：変換されるかもしれないYAMLファイルでは、booleanのように見えるすべての文字列をクォートしてください。文字列として扱いたい場合はcountry: "NO"とenabled: "yes"と書きます。これは追跡に3時間かかり修正に5秒かかるバグを引き起こす種類のことです。

変換のラウンドトリップは安全ですか？

YAMLからJSONからYAMLへ：コメント、アンカー定義（繰り返し値になります）、元のYAMLのすべての書式選択が失われます。結果のYAMLは正しいですが機械生成のように見えます。

JSONからYAMLからJSONへ：標準JSONでは実際に非常に安全です。JSONはYAMLのサブセットなので、ラウンドトリップはすべてのデータを保持します。

実際的な要点：変換は一方向または同方向のタスクに使用してください。YAMLの設定とJSON表現を並行して維持する必要がある場合、一方を真実の源として保ち、そこからもう一方を生成してください。変換後に両方を手動で同期しようとしないでください。

ToolboxHubsのYAML-JSONツールの使い方

YAML to JSONコンバーターはこれらすべてを処理します：

YAMLを貼り付け — 左パネルにYAMLを貼り付けます。単純なキーバリュー設定から深くネストされたKubernetesマニフェストまで受け付けます。
JSON出力を確認 — 変換はブラウザ内で実行され、サーバーには何も送信されません。
結果をコピー — コピーボタンを押せば完了です。

ツールはアンカー、複数行文字列、すべてのboolean型、null値、ネストされた構造を処理します。入力しながらYAMLを検証します——インデントエラーや不正なドキュメントがある場合、サイレントに間違った出力を出すのではなくエラーメッセージが表示されます。

逆方向に進みたい場合は、JSON to YAMLコンバーターがあります。同じ原則、逆方向です。

YAMLとJSONの使い分け

人間が主要な作者および読者の場合はYAMLを使います。設定ファイル、CIパイプライン定義、Kubernetesマニフェスト、Ansibleプレイブック——これらはバージョン管理に存在し、人間に読まれ、レビューされ、デバッグされます。YAMLの可読性とコメントサポートは本当に重要です。

マシンが主要な生産者または消費者の場合はJSONを使います。APIレスポンス、データベースレコード、生成された設定、サービス間のデータ交換——これらは人間が手作業で書かないため可読性から恩恵を受けません。

境界にいる場合——APIからJSONを受け取るがYAMLベースのシステムを設定する、またはその逆——変換はワークフローのツールに過ぎません。重要なのは、変換で何が変わる可能性があるかを理解し、何かがうまくいかない場合に確認することです。

まとめ

YAMLとJSONはどちらも優れたデータフォーマットですが、異なる状況に適しています。その境界で働くとき——人間がYAMLを書き、システムがJSONを期待するか、その逆——変換は日常的なタスクになります。

YAML to JSONコンバーターは機械的な部分を処理します。この記事が担当したのは変換で何が失われるかの理解です。