データ

YAML コンバーター

YAML を JSON、TOML、XML、JavaScript オブジェクトリテラル、PHP 配列に変換します。--- で区切られた複数ドキュメントは自動で配列にまとまり、anchor、alias、merge key（<<: *base）は実構造に展開されます。Kubernetes マニフェスト、Helm チャート、Docker Compose、GitHub Actions、GitLab CI、OpenAPI、AsyncAPI、Ansible playbook、CloudFormation など日常的な YAML をカバーし、Norway 問題、バージョン番号の浮動小数化、Number.MAX_SAFE_INTEGER を超える整数の精度損失、tab インデント、暗黙の null などの型のワナを行・列・前後文脈付きで検出します。解析、変換、コピーはすべてこのブラウザータブ内で完結し、YAML がサーバー、CDN、第三者の解析基盤に送られることはありません。

0 文字
入力待ち
変換結果はここに表示されます
アクション

関連記事

概要

YAML を起点とした変換作業に特化したツールです。複数ドキュメントの結合、anchor と merge key の展開、型のワナ検出、エンジン互換性のヒントを解析時点で処理し、CI、設定テンプレート、JSON Schema 検証、コードジェネレーターなど下流ツールにそのまま渡せる形で出力します。

  1. 01

    出力先 5 形式に標準対応

    YAML を JSON、TOML、XML、JavaScript オブジェクトリテラル、PHP 配列に変換できます。キー名のソートと巨大整数の扱いは 5 形式すべてに効き、JSON はさらにインデント幅を指定でき、TOML はオブジェクトルートを強制して中途半端な出力を出さず、XML はルート名・項目名・宣言・整形を選べてルートがリストでも変換でき、JS オブジェクトは引用符付きキーとエスケープを保持し、PHP 配列は <?php return [...]; を含む完全なファイルを生成します。

  2. 02

    複数ドキュメントの自動結合

    1 ファイルに --- で複数ドキュメントが含まれている場合（Kubernetes マニフェスト、Helm テンプレート展開、kustomize build 出力、Ansible playbook など）、出現順に 1 つの JSON 配列にまとめます。オプションを切り替えれば先頭ドキュメントのみを出力でき、Deployment、Service、Ingress などを個別に扱う場面にも適しています。

  3. 03

    anchor、alias、merge key を展開

    &base、*base、<<: *base は解析時に実構造へ展開されるため、下流の JSON、TOML、XML、JS オブジェクト、PHP 配列が参照切れや merge 欠落を見ることはありません。チェックパネルには見つかった anchor 名が並ぶので、どの参照が展開されたかは後から確認できます。際限なく膨らむ anchor 連鎖はページを固める前に打ち切ります。

  4. 04

    型のワナと YAML バージョン互換性のヒント

    Norway 問題（country: no が真偽値化）、バージョン番号の浮動小数化（1.10 が 1.1 になる）、Number.MAX_SAFE_INTEGER を超える整数、tab インデント、暗黙の null、八進数プレフィックスの曖昧さなど、実際に踏みうるワナを通知し、YAML 1.1 と 1.2 のどちらの挙動差であるかも明示します。

  5. 05

    行・列・文脈付きのエラー

    解析失敗時には行番号、列番号、周辺コードのスニペット、パーサーが返したヒントが表示されるため、目視でインデントを数えることなく元の YAML に戻って修正できます。

  6. 06

    ブラウザー内で完結

    解析、変換、チェック、コピーはすべてこのページで行われます。YAML はサーバー、CDN、第三者の解析基盤にリクエストとして出ていきません。本番マニフェスト、秘密情報を含むサンプルデータ、Cargo.toml への移行ドラフトなど機密性の高い内容も安心して扱えます。

使い方

ワークフローは「YAML を貼る、出力形式を選ぶ、チェックを読む、結果をコピーする」の 4 ステップに集約されます。

  1. 01

    左の入力欄に YAML を貼り付けます。即座に解析が行われ、右下のチェックパネルにドキュメント数、anchor 一覧、インデント警告などの構造情報が表示されます。

  2. 02

    下部で出力形式を切り替えます。JSON、TOML、XML、JavaScript オブジェクト、PHP 配列のいずれかを選び、オプション（キー名のソート、巨大整数を文字列で出力、JSON のインデント幅、XML のルート名と項目名）をライブで調整できます。

  3. 03

    チェックパネルの通知を確認します。Norway 問題、バージョン番号の浮動小数化、巨大整数、tab インデントなどは変換を止めませんが、ソース YAML で引用符を付けるべき箇所や、インデント修正の指針として活用できます。

  4. 04

    長いマニフェストや OpenAPI 定義では右上の全画面モードに切り替えると、入力・出力の両ペインに広い表示領域が確保され、シンタックスハイライト、折り畳み、コピー操作はそのまま利用できます。

  5. 05

    確認できたらコピーボタンを押し、IDE、スニペット管理、CI ジョブ定義、Postman、Insomnia、Bruno などの API クライアントに貼り付けて作業を続行します。

詳細

日常の YAML 作業でよく引っかかる細部を、デフォルト動作で吸収します。外部ツールを併用しなくても綺麗な変換が得られます。

  • 解析はデフォルトで YAML 1.2 仕様に従い、加えて YAML 1.1 由来のリスクを通知するため、PyYAML、Symfony YAML などのレガシーランタイムと出力が静かに食い違うことを防ぎます。
  • 出力は既定で YAML のキー出現順を保持し、必要ならアルファベット順への整列を 5 形式すべてに適用できます。git diff、コードレビュー、JSON Schema 検証が安定して通ります。
  • TOML 変換はトップレベルがオブジェクトであることを要求し、不適合時には中途半端な出力ではなく明示的なエラーを返します。
  • XML はルート名、項目名、宣言、pretty print のすべてを設定でき、既存の SOAP、RSS、SAML、Atom スキーマにそのまま揃えられます。
  • JavaScript オブジェクトと PHP 配列の出力は入れ子、エスケープ、null、真偽値リテラルを保持し、テストデータ、Storybook story、Laravel 設定、WordPress サンプルにそのまま貼り付けられます。
  • 複数ドキュメントの YAML は配列として出力するか、先頭ドキュメントのみを出力するかを切り替え可能で、Kubernetes の Deployment、Service、Ingress を個別に扱う運用に向きます。
  • 構造サマリーには anchor 名、ドキュメント数、入れ子の深さが表示されるため、見慣れない YAML でも数秒で全体像を把握できます。
  • すべての処理はこのブラウザータブ内で完結し、SaaS バックエンドを持たないため、機内、VPN 限定ネットワーク、企業プロキシ越しでも継続して使えます。

活用シーン

出発点が YAML である日常作業では、下記のシーンが手作業の写経やスクリーンショット説明を省く助けになります。

  1. Kubernetes マニフェストと kustomize 出力の点検

    複数ドキュメントの Deployment、Service、Ingress、ConfigMap、Secret を貼り付け、スタック全体を 1 つの JSON 配列として表示し、json-diff にかければ本番と検証環境の差分をブラウザー内で比較できます。

  2. Helm チャートのデバッグと values の整理

    helm template の展開結果は複数ドキュメントと anchor 参照を含みます。JSON に変換するとリソースごとの最終形が完全に見え、values.yaml の階層的オーバーライドで埋もれた差異を表面化できます。

  3. GitHub Actions、GitLab CI、CircleCI の検証

    ワークフローを JSON に変換し、構造化比較で matrix、env、条件分岐、再利用可能ワークフローの最終的な展開結果を把握し、特定のジョブが起動しなかった理由を突き止められます。

  4. OpenAPI、AsyncAPI、JSON Schema の切り替え

    チームは YAML で仕様を書くものの、Stoplight、Swagger Codegen、Prism mock、AJV 検証などは JSON のみを受け入れる場合があります。ワンクリック変換で単一の真実情報源を保ち、手動コピーによる乖離を避けられます。

  5. フロント / バックエンドのテストデータと mock 同期

    バックエンドが YAML で保持しているテストデータ（Rails、Symfony、Laravel）を、フロントの Jest、Vitest、Storybook が必要とする JSON または JS オブジェクトへ変換し、専用スクリプトを書かずに貼り付けて再利用できます。

  6. TOML プロジェクトへの移行（Cargo、pyproject、Hugo）

    Cargo.toml、pyproject.toml、Hugo config.toml などへ YAML 設定を移す際は、まず YAML → TOML の構造化出力を確認し、その後手作業で微調整します。逐行転記によるタイプミスを構造的差分で発見できます。

  7. Ansible playbook と CloudFormation テンプレートの読解

    Ansible の vars ファイルや CloudFormation の SAM テンプレートは anchor と組み込み関数が深く入れ子になります。JSON に変換すると視覚的階層が整理され、レビューや新メンバーへの教育に使いやすくなります。

  8. セキュリティレビューと設定ベースラインの差分

    anchor の参照経路、入れ子の深さ、暗黙の型、引用符なしの機微なリテラルを点検し、YAML の暗黙挙動が本番真偽値を狂わせないか確認します。JSON 差分ツールと組み合わせれば、既知の良好ベースラインとの比較も容易です。

関連情報

逆に手元のソースが JSON のとき——たとえば最小化された API レスポンス、Helm values の JSON ダンプ、Terraform plan の JSON ビュー、kubectl get -o json の出力——から、YAML、TOML、XML、CSV、JavaScript オブジェクトリテラル、PHP 配列ファイルへ反対方向に書き戻したい場合は JSON コンバーター を開いてください。各形式ごとに専用オプションがあり、YAML のインデントとキー順、XML のルート名と属性モード、CSV の区切り文字とヘッダー行、TOML のキー順、PHP のトップレベル return ラッパーなど、下流ツールにそのまま渡せる出力を生成できます。変換の前に JSON 自体を整形したい、深い階層を折り畳みたい、構文エラーの位置を特定したい、キーの統計を確認したい場合は、まず JSON フォーマッター に通すと向いています。階層の折り畳み、エラー行のハイライト、キー検索、深さ統計、ブラウザー内での整形と圧縮を備え、同じくアップロードを行わない保証付きです。さらに 2 つの YAML を変換した JSON の差を厳密に追いたい場合——例えば本番と検証環境の Kubernetes マニフェスト、複数環境にわたる GitHub Actions ワークフロー、2 つの Helm release の比較——両方の出力を JSON 差分 に貼り付ければ、JSON Path ごとの追加・削除・変更が git スタイルの並列ビューで一覧でき、目視では見落としがちな意図しない上書き、暗黙の型変換、インデントずれによる副作用も洗い出せます。手元のファイルが TOML の場合 —— Cargo のマニフェスト、pyproject、Netlify の設定 —— 同じ変換をそちら側から始めることになり、使うのは TOML コンバーター。

YAML は JSON より多くを表現できる。あふれた分はどこへ行くのか

YAML のキーは任意のスカラーでよく、値にはタグを付けられ、ノードどうしが参照し合えます。JSON にはそのどれもありません。変換では、これらを JSON が理解できる形に落とし込む必要があります。正確に翻訳されるものもあれば、何も言わずに消えるものもあります。以下の 4 つはすべて、上のツールで再現できます。

  1. !! の標準タグは効く。アプリ独自のタグは捨てられる

    !!str 42 は正しく "42" に、!!int "7" は 7 になります。しかし独自タグはそうなりません。!Ref MyBucket は "MyBucket"、!GetAtt [MyBucket, Arn] は ["MyBucket", "Arn"] として出力され、タグ自体が警告もなく消えます。CloudFormation、SAM、CDK のテンプレートを変換すると、構文は正しいのに意味を失った JSON ができあがります。本来は {"Ref": "MyBucket"} と書かれるべきだからです。ついでに、!!binary "aGk=" はバイト列にデコードされ、JSON では {"0": 104, "1": 105} になります。

  2. YAML のキーは文字列でなくてよいが、JSON のキーは文字列でなければならない

    {true: A, "true": B, 1: C, "1": D, null: E} は {"1": "D", "true": "B", "": "E"} になります。真偽値の true と文字列の "true" は JSON では同じキーで、数値の 1 と "1" も同じです。後に現れたほうが先のものを上書きします。null をキーにすると空文字列のキーになります。5 つ入って 3 つ出てくるだけで、上書きされた 2 つの値は痕跡すら残りません。

  3. 重複キーはエラーになる。これはありがたいこと

    {a: 1, a: 2} は変換されず、Map keys must be unique (line 1, column 8) と表示され、原文の位置も示されます。多くの YAML ランタイムは黙って最後のものを採用するため、設定が誰もレビューしていない値へ静かにずれていきます。本番で気づくより、ここで止められるほうがずっと安全です。

  4. alias は参照だが、展開はコピーになる

    &a で 10 要素の配列を定義し、*a で 10 回参照すると、出力にはポインタではなく完全なコピーが 10 個並びます。数百バイトの YAML が数十メガバイトの JSON になることもあり、YAML 爆弾はまさにこの仕組みです。大きな Helm values や Kubernetes マニフェストを変換する前に、各アンカーが何回参照されているかを確認してください。

使い方のヒント

YAML の可読性は両刃の剣です。インデントとリテラルが入門の敷居を下げる一方、境界事例で予想外の挙動が出やすいので、どのプロジェクトでも有効な小さな習慣を残しておきます。

  • yes、no、on、off、true、false、null など機微なリテラルにはすべて引用符を付け、YAML 1.1 互換エンジンで真偽値や null に強制変換されるのを防ぎます。
  • バージョン番号、シリアル、電話番号風文字列、注文 ID、Git コミットハッシュ、ISBN などは必ず引用符を付け、浮動小数、八進数、巨大整数として解釈されるのを避けます。
  • インデントはスペースのみを使い、2 個か 4 個に統一します。tab とスペースを混在させず、エディターで空白文字を可視化しておくとさらに安全です。
  • 構造の再利用にはコピーではなく anchor と alias を用い、共通フィールドは merge key（<<: *base）で 1 箇所にまとめます。
  • YAML を JSON に変換したあとは json-diff で前バージョンと比較し、静かに変わったフィールドを取り逃さないようにします。CI に組み込めば設定駆動の回帰を未然に防げます。
  • 複数ドキュメントの YAML を変換したら、配列順序が元ファイルと一致しているか確認してください。Kubernetes の namespace、CRD、Operator のように順序に敏感なリソース連鎖では特に重要です。
  • 本番マニフェストを提出する前に本ツールで一度展開し、anchor、merge、include が意図しないフィールド上書きを生んでいないか確認します。
  • YAML の binary、timestamp、カスタムタグは JSON や TOML への変換でセマンティクスが失われる可能性があります。文字列リテラルで書き直し、意図する型をドキュメント内に記録すると安全です。

制限事項

このツールが扱わない範囲を把握しておくと、完全な YAML IDE、スキーマ検証器、GitOps パイプラインの代わりに使ってしまう事故を避けられます。

  • 業務スキーマの検証は行いません。Kubernetes API オブジェクト、OpenAPI のフィールド制約、JSON Schema、Cargo マニフェストのフィールド規約などは対象外で、構文の成功はセマンティクスの正しさを意味しません。
  • YAML のコメントは保持されません。JSON、TOML、XML 出力では # 以降が削除されます。残したいコメントは独立フィールドや外部ドキュメントに移してください。
  • ソースファイル自体を書き換えることはありません。修正はすべて元のドキュメントで行い、バージョン管理を唯一の真実情報源として保ってください。
  • 非常に大きなファイル（数十万行、数 MB）ではブラウザーが重くなる場合がありますが、処理はローカルで完結し、切り詰めや送信は行われません。代表的なスライスでオプションを検証してから全文に適用するのがおすすめです。
  • !!python/object、!!js/function、CloudFormation の !Ref といったカスタムタグは解決も実行もしないため、デシリアライズ脆弱性は発生しません。未解決のまま残り、チェックパネルに一覧されます。値は残りますがタグが表す意味は失われます。
  • バージョン管理、コラボレーション、コメント、Git 連携などの機能はありません。本ツールの位置付けは単発の変換と検査で、レビューや承認は Git ワークフローと組み合わせてください。
  • 出力形式にはそれぞれ限界があります。TOML はルートがオブジェクトである必要があり null を一切持てず、XML と PHP 配列はテキスト以上の型情報を運べず、どの形式も YAML の参照を表現できません。こうした衝突は誤解を招く出力を作らずにチェックパネルで明示します。

よくある質問

よくある質問は、複数ドキュメントの扱い、anchor と merge key、型のワナ、データがブラウザーから出ないかという 4 点に集中しています。

YAML に複数のドキュメントが含まれている場合は？

--- で区切られた複数ドキュメントは自動的に認識され、出現順で JSON 配列にまとめられます。Kubernetes マニフェスト、Helm 展開、Ansible playbook など多リソースのファイルを一度に閲覧したいときに便利です。オプションで先頭ドキュメントのみ出力に切り替えれば、単一リソースに集中することもできます。

anchor、alias、merge key は保持されますか？

実構造に展開します。JSON、TOML、XML、JS オブジェクト、PHP 配列のいずれにも参照という概念がないため、展開が唯一忠実な選択で、下流ツールが参照切れや merge 欠落を見ることも防げます。anchor の出どころや適用範囲を追いたい場合は、チェックパネルにソース中の anchor 名がすべて並ぶので、どの merge から来た値かを辿るにはたいてい十分です。

なぜ country: no が JSON に変換すると false になるのですか？

有名な Norway 問題です。YAML 1.1 では yes、no、on、off が真偽値として解釈されるため、ISO 国コード NO は引用符を付けないと false に化けます。本ツールはデフォルトで YAML 1.2 に従いますが、PyYAML、Symfony YAML などの YAML 1.1 互換ランタイムとの不一致を避けるため、この種のリスクを通知します。値に引用符を付けるのが最も安全です。

バージョン番号らしき 1.10 が 1.1 になります。なぜ？

引用符のない 1.10 は YAML では浮動小数 1.1 として解析されます（小数点以下の末尾の 0 は捨てられます）。バージョン番号、電話番号風の値、シリアル、ISBN、Git コミットハッシュなど見た目は数値でも実体は文字列の値はすべて引用符を付けてください。検出時はチェックパネルにも警告が出ます。

TOML 変換で「ルートはオブジェクトである必要があります」と出ます。なぜ？

TOML 仕様はトップレベルにテーブルを要求し、配列、文字列、数値、null を許しません。YAML のルートがリスト（例: [a, b, c]）の場合は items: [a, b, c] のようにキーで包んでから変換してください。配列に意味のある名前を与えつつ、TOML のセマンティクスにも適合します。

大きな整数で精度が失われる理由は？

JavaScript の Number の上限は 2^53 - 1 です。Snowflake ID、整数形式の UUID、ミリ秒に拡大されたタイムスタンプなどはこの範囲を超えると JSON 出力時に近似値になります。チェックパネルが該当値を一つずつ挙げ、巨大整数を文字列で出力をオンにすると全桁を保ったまま文字列として書き出します。YAML ソース側で引用符を付けておく対応が最も確実なのは変わりません。

貼り付けたデータは送信されますか？

いいえ。解析、変換、チェック、コピーはすべてブラウザー内で完結し、リクエストとして YAML がサーバー、CDN、分析基盤に出ていくことはありません。タブを閉じればデータは残らず、本番マニフェスト、機密性の高いサンプルデータ、移行ドラフトも安心して扱えます。

オフラインで使えますか？

初回ロード後はブラウザーが解析と変換に必要なリソースをすでに保持しているため、ネットワークが切れた状態でも継続して利用できます。機内、企業プロキシ越し、エアギャップ環境でも同じワークフローを維持できます。

関連ツール

データ系の作業を続けます。逆方向の JSON から YAML への変換、JSON の整形、入れ子の構文エラー特定、2 つの結果の並列比較まで、下記のツールを組み合わせれば一連のワークフローになります。