データと形式変換

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、第三者の解析基盤に送られることはありません。

  • 1 つの入力から JSON、TOML、XML、JS オブジェクト、PHP 配列の 5 形式を出力でき、それぞれ専用オプションを備える
  • 複数ドキュメント（---）の YAML は出現順で JSON 配列に整え、Kubernetes マニフェストや Helm 出力をまとめて閲覧できる
  • anchor、alias、merge key をデフォルトで展開し、下流の JSON、TOML、XML が参照切れや merge 欠落を見ないようにする
  • YAML 1.1 互換のワナを自動検出：Norway 問題、yes/no/on/off の真偽値化、1.10 → 1.1 の浮動小数化、巨大整数の精度損失、tab インデント、暗黙 null
  • すべてローカル処理。アップロードもテレメトリーも無し。本番マニフェスト、秘密情報を含むフィクスチャ、移行ドラフトも安心して貼り付けられる
工具/YAML コンバーター
0 文字
入力待ち
変換結果はここに表示されます
アクション

概要

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

  1. 01

    出力先 5 形式に標準対応

    YAML を JSON、TOML、XML、JavaScript オブジェクトリテラル、PHP 配列に変換できます。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 欠落を見ることはありません。デバッグ目的で参照グラフのまま見たい場合は、展開オプションを切ることもできます。

  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 配列のいずれかを選び、形式ごとのオプション（インデント、キー順、anchor 展開、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 などのレガシーランタイムと出力が静かに食い違うことを防ぎます。
  • JSON 出力は YAML のキー出現順を保持し、必要に応じてアルファベット順に整列できます。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 スタイルの並列ビューで一覧でき、目視では見落としがちな意図しない上書き、暗黙の型変換、インデントずれによる副作用も洗い出せます。

使い方のヒント

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 のようなカスタム YAML タグは無視するか拒否し、デシリアライズ脆弱性を避けます。信頼できないコードの実行は一切発生しません。
  • バージョン管理、コラボレーション、コメント、Git 連携などの機能はありません。本ツールの位置付けは単発の変換と検査で、レビューや承認は Git ワークフローと組み合わせてください。
  • YAML から XML、CSV への変換ではルートが配列、または混在型のリストなど構造的に綺麗にマッピングできない場合があり、その際は誤解を招く出力を作らずに矛盾を明示します。

よくある質問

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

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

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

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

デフォルトでは実構造に展開します。JSON、TOML、XML、JS オブジェクト、PHP 配列のいずれも参照をサポートしないため、展開する方が安全で、下流ツールが参照切れや 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 つの結果の並列比較まで、下記のツールを組み合わせれば一連のワークフローになります。