YAML ⇔ JSON 変換ツール
YAML と JSON を相互変換。設定ファイルのフォーマット変換や、Kubernetes マニフェスト・Docker Compose・GitHub Actions・OpenAPI の編集に。
対応フォーマット
- YAML 1.2 準拠（js-yaml ライブラリを使用）
- JSON は整形・バリデート付きで出力
- 複数ドキュメント（
---区切り）は最初のドキュメントのみ変換 - YAML のアンカー（
&/*）にも対応
コピーしました
📖 つまずきやすいポイント
js-yaml (YAML 1.2 準拠) を使って YAML と JSON を相互変換します。アンカーとエイリアス、複数ドキュメント、構文エラーの行番号表示に対応し、処理はブラウザ内で完結します。YAML の難しさは構文ではなく、書いた覚えのない型変換が黙って起きることにあります — 文字列のつもりの値が数値や真偽値になり、しかもエラーにならないので、動かなくなってから原因を探すことになります。
| ケース | 何が起きるか | どうする |
|---|---|---|
| 文字列のつもりの値が数値や真偽値になる | YAML はクォートの無い値を見た目から型を推測して変換します。よく壊れるのは — version: 1.10 は数値になって 1.1 と等しくなり、zip: 007-0000 は文字列のままでも zip: 0070 は 8 進数と解釈されうる、country: NO (ノルウェー) は YAML 1.1 では false、GitHub Actions の on: は 1.1 では true というキー名になります。このツールは YAML 1.2 準拠なので NO や on は文字列のままですが、Python の PyYAML の既定や Ruby の Psych は今も 1.1 相当なので、同じファイルが処理系によって違う意味になります。 |
迷ったらクォートしてください。とくに バージョン番号・国コード・郵便番号・先頭が 0 の数字・yes/no/on/off/true/false・null/~・: や # を含む値は必ずクォートします。クォートは冗長ではなく、意図の明示です — レビューで「なぜここだけクォートしているのか」と聞かれたら、それは正しい質問であり、答えは「この値は文字列だと決めているから」です。設定ファイルをリポジトリに入れる前に、一度 JSON に変換して型を目で確認してください — このページの変換結果で "1.1" ではなく 1.1 と出ていたら、それが事故の予兆です。 |
| アンカーとエイリアスが展開されて参照が消える | &defaults で定義して <<: *defaults で取り込む書き方は、YAML の重複を減らす強力な機能ですが、JSON にはこの概念がありません。したがって変換するとすべてのマージが実際に展開され、同じ内容が何度も書かれた JSON になります。ここまでは想定内ですが、問題はそこから YAML に戻したときです — アンカーは復元されず、DRY に書かれていた設定ファイルが、全部ベタ書きの長大なファイルに変わります。docker-compose.yml や .gitlab-ci.yml のように共通定義を多用するファイルでは、行数が数倍になります。 |
設定ファイルを往復させないでください。YAML を正本として編集し、JSON は「機械に渡す最終出力」としてのみ生成するのが正しい流れです — CI が API に JSON で投げる、といった用途がまさにこれです。すでにアンカーが失われた YAML を受け取った場合、機械的に元へ戻す方法はありません — 重複している箇所を目で見つけて、手でアンカーに括り出すしかありません。だからこそ、正本がどちらなのかをリポジトリで明確にしておいてください — 生成物の JSON をコミットするなら、generated/ のようなディレクトリに置くか、ヘッダに「自動生成。編集しないこと」と書いておくと事故が減ります。 |
| インデントのエラーが直せない | YAML はタブ文字をインデントとして認めません — エディタの設定でタブが 1 つ紛れ込むだけで、必ず失敗します。しかも画面上ではスペースと見分けが付きません。さらに厄介なのがエラーメッセージの指す行で、YAML のパーサーは「構造の矛盾に気付いた行」を報告するため、実際に間違っているのはその数行から数十行上ということが普通にあります。ネストの深い Kubernetes マニフェストで、「120 行目でエラー」と言われて 118 行目から探しても何も無いのはこの理由です。 | まずエディタで「タブをスペースに変換」を有効にしてください — .editorconfig に [*.yml] indent_style = space と書いておけば、チーム全体で防げます。エラーを追うときは、報告された行から「上に向かって」読んでください — インデントの深さが 1 段だけおかしい箇所を探すのがコツです。もう 1 つ、リストのインデントには 2 通りの書き方が許されています — - を親と同じ列に置くか、2 スペース下げるかで、どちらも正しいのですが、1 つのファイルで混在させると人間が読み違えます。yamllint を CI に入れると、この種の問題は書いた瞬間に見つかります — 実行時に壊れるより圧倒的に安上がりです。 |
外部から受け取った YAML をサーバー側でパースするときは、必ず安全なローダーを使ってください。Python の yaml.load() は任意の Python オブジェクトを構築できるため、細工された YAML を読ませるとコード実行に至ります — 必ず yaml.safe_load() を使ってください。js-yaml は v4 で既定が安全側になりましたが、古いバージョンを使っているプロジェクトでは safeLoad を明示する必要があります。ブラウザで動くこのページは safe 相当なので問題ありません。もう 1 点、複数ドキュメントの扱いに注意してください — Kubernetes は --- 区切りで 1 ファイルに複数のリソースを入れますが、JSON には複数ドキュメントという概念が無いので配列になります。YAML に戻すときに --- 区切りへ復元し忘れると、kubectl apply が「配列は Kind として不正」と言って通りません — 変換を挟むパイプラインでは、ここを必ずテストしてください。
📖 使い方
-
1
入力を貼り付け左側のエディタに YAML または JSON を入力すると、右側に自動で変換結果が表示されます。
-
2
方向を切替「YAML → JSON」または「JSON → YAML」を選択できます。タブ/スペース・インデント幅も指定可能。
-
3
検証エラーを確認構文エラーがある場合は行番号と原因が表示されます。Kubernetes manifest や GitHub Actions ワークフローの編集に便利。
❓ よくある質問
YAML のアンカー (&) とエイリアス (*) は対応?
複数ドキュメント (---) は処理されますか?
Docker Compose や K8s manifest の編集に使えますか?
YAML の "Norway bug" (NO → false) は大丈夫?
🐛 このツールで問題が発生しましたか？
完全無料・登録不要。再現手順だけでも結構です。届いたご報告は運営者に直接届き、修正の参考にします。
ご報告ありがとうございます！
運営者に届きました。改善の参考にさせていただきます。