§

変換したい JSON または YAML を貼り付けてください。

モード
インデント
オプション
§

出力

yaml

国内のクラウドネイティブ現場では、JSON と YAML の往復変換が日常的に発生します。日本最大級の Kubernetes 基盤を運用するメルカリ、CIU コンテナ基盤を擁するサイバーエージェント、Z Holdings / LINE のサービス群、SoftBank のテレコム向け K8s 採用事例まで、本番投入されるマニフェストはすべて YAML で書かれ、kubectl と Helm が内部で JSON として扱います。経済産業省（METI）の「クラウド・バイ・デフォルト」原則に従う SaaS 各社や、楽天モバイルのクラウドネイティブ移行、NTT データの Kubernetes コンサルティング案件でも、YAML を JSON に変換して Ajv や OPA Rego で検証する流れが定着しています。CNCF Japan Chapter のミートアップでも頻出するこのワークフローを、本ツールはブラウザー完結で安全に処理します。

// 関連ツール

./json-formatter
JSON フォーマッター
ブラウザー内で JSON をフォーマット・検証・最小化します。
→
./json-csv-converter
JSON から CSV への変換ツール
ブラウザー内で JSON を CSV に変換します。アップロード不要。
→
./base64-encoder
Base64 エンコーダー
テキストやファイルを Base64 形式にエンコードします。
→
./
すべてのツール
Ultim8Soft のオンラインツール一覧をご覧ください。
→

JSON ↔ YAML 変換とは何ですか？

JSON（JavaScript Object Notation、RFC 8259）は、波括弧で区切られた構造化データ用の厳密なテキスト形式です。YAML（YAML Ain't Markup Language、1.2 版）は JSON のスーパーセットで、インデント、改行、人間に読みやすい構文で同じ値モデルを表現します。両者を変換することで、同じ設定を機械向けの形式（JSON：API、スキーマ検証、プログラム的変換）と人間向けの形式（YAML：コードレビュー、Kubernetes マニフェスト、GitHub Actions ワークフロー）の間で、1 つのキーも打ち直すことなく切り替えられます。

JSON ↔ YAML 変換はどのように動作しますか？

すべての変換はブラウザー内で同梱の js-yaml ライブラリ（MIT、4.1.0 版）を用いてローカルに実行されます。大まかな手順は次のとおりです：

  1. モード選択（自動判定 / JSON → YAML / YAML → JSON）がどちらのパイプラインを走らせるかを決めます。自動判定モードでは、入力の最初の非空白文字が方向を決めます — { または [ なら JSON、それ以外は YAML として扱われます。
  2. JSON → YAML：JSON.parse が入力を検証し JavaScript の値を生成、jsyaml.dump(value, { indent, lineWidth: -1, sortKeys: false }) が YAML 1.2 形式に書き出します。複数文書をオンにすると、入力配列は要素ごとに 1 文書として出力され、--- 区切りで連結されます。
  3. YAML → JSON：jsyaml.loadAll が入力のすべての文書を解析し（--- 区切りも自動処理）、配列にまとめます。単一文書の入力はアンラップされるため、JSON 出力は 1 要素の配列ではなく、その文書そのものになります。
  4. インデント（スペース 2 または 4）とプリティプリントは設定可能です。プリティプリントを切ると、JSON.stringify(value) で空白なしの最小化 JSON が出力されます。
  5. 結果は読み取り専用のテキストエリアに書き込まれます。YAML 解析に失敗した場合、エラーメッセージには js-yaml が e.mark で報告する 1 始まりの行・列番号が含まれ、問題箇所に直接ジャンプできます。

このツールで JSON と YAML を変換する理由は？

  • プライバシー：解析・変換・出力のすべてがブラウザー内で行われます。Kubernetes の Secret、署名済み JWT、機密設定を含むデータは、当社のサーバーに届くことはありません。
  • 複数文書 YAML：jsyaml.loadAll は --- 区切りを認識して文書の配列を返し、単一文書ではアンラップ、複数文書では JSON 配列として保持します。
  • アンカーとエイリアスを解決：YAML の &anchor / *alias 機構は js-yaml のデフォルトスキーマで解決されます。1 度定義して 2 度参照した値は、すべての参照が等しい値を持つ JSON オブジェクトとして往復します。
  • CDN なし、テレメトリーなし：js-yaml.min.js はページと同一オリジンから配信されるので、オフラインでも、企業プロキシ越しでも、エアギャップ環境でも動作します。

JSON ↔ YAML 変換の一般的な用途は何ですか？

DevOps、プラットフォームエンジニアリング、API ツーリングの随所で JSON と YAML の往復変換が登場します：

  • Kubernetes マニフェスト：YAML の Deployment、ConfigMap、HelmRelease を JSON に変換し、社内ポリシー検証器（Joi、Ajv、OPA Rego）でプログラム的に lint してから YAML に戻してクラスターへ適用します。
  • CI/CD ワークフロー：GitHub Actions の workflow.yml を JSON 経由で往復させ、コードジェネレーターでマトリクスやジョブ依存関係を書き換えてから、整形した YAML を PR にプッシュします。
  • OpenAPI 仕様：バックエンドが自動生成したドキュメントから出力した JSON の openapi.json を openapi.yaml に変換し、人手で編集するリファレンスとしてリポジトリに登録します。

JSON ↔ YAML の往復変換の例はどのような見た目ですか？

{"apiVersion":"apps/v1","kind":"Deployment","metadata":{"name":"web"},"spec":{"replicas":3,"selector":{"matchLabels":{"app":"web"}}}} を貼り付け、JSON → YAML モードで「変換」を押すと、1 行目が apiVersion: apps/v1 で始まる 8 行のインデント付き YAML が得られます。その YAML を YAML → JSON モード（プリティプリント オン）に戻すと、JSON.stringify(value, null, 2) の後に元のオブジェクトがバイト単位で再現され、キーの順序も保たれます — js-yaml のデフォルトスキーマが両方向で挿入順を尊重するからです。

この JSON ↔ YAML 変換ツールは完全にブラウザー内で動作しますか？

はい。解析・変換・出力のすべてがブラウザータブの中の JavaScript としてローカルに実行されます。同梱の js-yaml ライブラリはページと同一オリジンから配信され — CDN なし、fetch なし、XMLHttpRequest なし、入力に対する navigator.sendBeacon もありません。ページを一度読み込んでしまえばオフラインでも動作します。実行時 API 依存を持たず、ベンダーライブラリも同梱した静的な HTML/CSS/JS バンドルだからです。Kubernetes の Secret、JWT のペイロード、署名済み CloudFormation YAML、機密設定はすべて手元の端末に留まります。

変換ツールは複数文書 YAML をどう扱いますか？

YAML は --- のみからなる行で区切ることで、1 つのストリームに複数の文書を含められます。YAML → JSON では変換ツールが jsyaml.loadAll を呼び、すべての文書を JavaScript 値として返します。文書が 1 つだけ見つかれば JSON 出力はその文書そのもの、2 つ以上見つかれば JSON 出力は配列です。JSON → YAML では、入力が JSON 配列で複数文書トグルがオンのとき、各配列要素を独立した文書として出力し、その間に --- 区切りを挿入します — JSON のリソース配列から kubectl apply 向けのバンドルを生成するのに便利です。

YAML のアンカーとエイリアスはサポートされていますか？

はい — &anchor 定義と *alias 参照は読み込み段階で js-yaml のデフォルトスキーマによって解決されます。defaults: &d\n retries: 3\n timeout: 30\njob_a:\n <<: *d\njob_b:\n <<: *d のような YAML 入力は、job_a と job_b がともに retries: 3, timeout: 30 を含む JSON オブジェクトに解析されます。マージキー <<（YAML 1.1 の拡張で、js-yaml は今も尊重）もデフォルトスキーマでサポートされています。

JSON と YAML を往復するとき YAML のコメントは保持されますか？

いいえ — js-yaml は解析段階でコメントを取り除くため、YAML → JSON → YAML の往復では # で始まる行はすべて失われます。これは load/dump モデルの既知の制限です。コメントの保持が重要な場合は、js-yaml ではなく、コメント認識型のライブラリ（trivia を保つよう設計された CST + AST API を備える yaml npm パッケージなど）を使ってください。多くの設定変換ワークフローではこのトレードオフは許容範囲で、往復後の YAML はすべてのキー、値、アンカー、エイリアスを保ったまま、人手のコメントだけを失います。

カスタム YAML タグはどうなりますか？

変換ツールは js-yaml の DEFAULT_SCHEMA を使い、!!str、!!int、!!float、!!bool、!!null、!!seq、!!map、!!binary、!!timestamp を理解します — つまり YAML 1.2 の core および JSON スキーマの全タグです。カスタムやアプリ固有のタグ（CloudFormation の !Ref、Ansible の !vault など）は認識されず、対応していないタグを明示する明確なエラーになります。CloudFormation の場合は、aws cloudformation package + --output-template-file でカスタムタグを展開してから本変換ツールに貼り付けてください。

この JSON ↔ YAML 変換ツールは、js-yaml@4.1.0 を同一オリジンに同梱し、複数文書ストリームとアンカー / エイリアスを標準でサポートし、YAML 解析エラーを行・列番号付きで報告するので、ソースを直接修正できます。アップロードなし、CDN なし、テレメトリーなし — すべてのバイトがブラウザー内に留まります。