JSON ↔ YAML コンバーター

YAML / JSON コンバーターとは？#

YAML と JSON は、同じ種類のデータ——入れ子のマップ・リスト・文字列・数値・真偽値・null——を書く 2 つの方法です。JSON は厳格で句読点が多い（すべての文字列がダブルクォート、至る所に括弧）ですが、YAML はそれらのクォートや波括弧をインデントとダッシュに置き換え、人が設定ファイル・CI パイプライン・コンテナマニフェストを手書きできるほど読みやすくしています。

異なるツールが異なるフォーマットを好むため、両者を行き来する必要は常に生じます。Kubernetes のチャートは YAML で書かれますが、API は JSON を話します。CI の設定は YAML ですが、それを食わせたいリンターは JSON を期待します。チームメイトがチャットに YAML の塊を貼り、あなたのスクリプトは JSON.parse を欲している、という具合です。これを手作業で行う——再インデント・再クォート・括弧とダッシュの入れ替え——は、まさに余計なカンマやずれたスペースを紛れ込ませ、結果として何も解析できなくなるような面倒な作業です。

このページはブラウザ内で両方向の変換を行います。機械に扱いやすい厳格さが必要なときは YAML から JSON へ、人が実際に読める設定ファイルが欲しいときは JSON から YAML へ。YAML 1.2 コアスキーマで解析し（リスクのあるオブジェクト生成はなし）、エラーを正確な行と列に固定し、長い行を折り返さないため出力は diff に適したまま保たれます。

使い方#

1. ツールバー左上の 2 つのボタン切り替えで方向を選びます:
   • YAML → JSON（既定）: 左に YAML を貼り付け、右に厳格な JSON を得ます。
   • JSON → YAML: 左に JSON を貼り付け、右にインデントされた YAML を得ます。
2. インデントを選びます——2 または 4 スペース。両方向の出力の入れ子の深さを制御します。
3. サンプルをクリックして、自分のデータを貼る前に動作を見たい場合の短い例を読み込むか、クリアで両ペインを消去します。
4. 変換が走ると右ペインが更新されます。下のステータスバーは 3 つのうちいずれかを報告します——出力のバイトサイズを伴う成功行、空入力のヒント、あるいは問題のトークンを正確に指す1 始まりの行と列を持つ解析エラーです。
5. 出力ヘッダーのコピーをクリックして結果を取り出します。

変換は入力が解析された瞬間に走ります。クリックする生成ボタンはありません——入力を直せば出力が更新されます。

主な特徴#

• 1 組のペインで両方向。 同じ入出力レイアウトが両方向を扱い、切り替えボタンがどちらのパーサーを走らせるかを決めます。
• YAML 1.2 コアスキーマ。 null、true/false、整数、浮動小数点、クォート付き文字列はすべて、標準準拠のパーサーが解決するのと正確に同じように解決されます——緩いヒューリスティックではありません。
• 行折り返しは無効。 長い出力行は折り返されたり省略されたりしないため、チェックインされたファイルに対する diff は本当の変更だけを示します。
• 正確なエラー位置。 ずれたインデントや迷いの : は、総称的な「解析できません」ではなく 行:列 として報告されます。
• 深さガード付き。 深く入れ子になった入力（古典的な「YAML billion-laughs」膨張）はキャップされるため、悪意のある、あるいは誤って再帰的なファイルがタブをフリーズさせることはありません。
• ローカルのみ。 設定がページから外に出ることはありません——送信先のバックエンドが存在しません。1 メガバイトを超えると、重い解析はバックグラウンドワーカーに任され、UI は応答性を保ちます。

実例#

よくある現実の作業: YAML で書かれたサービス設定を JSON のリクエストボディに入れる必要があります。YAML → JSON と2 インデントを選び、これを左ペインに貼り付けます:

name: api-gateway
port: 8080
replicas: 3
targets:
  - host: example.com
    port: 443
  - host: cdn.example.com
    port: 8443
features:
  retries: true
  timeout_ms: 2500

右ペインは厳格で解析可能な JSON を生成します:

{
  "name": "api-gateway",
  "port": 8080,
  "replicas": 3,
  "targets": [
    {
      "host": "example.com",
      "port": 443
    },
    {
      "host": "cdn.example.com",
      "port": 8443
    }
  ],
  "features": {
    "retries": true,
    "timeout_ms": 2500
  }
}

クォートなしの YAML 値 8080、true、3 が、それぞれ JSON の数値・真偽値・数値になったことに注意してください——コアスキーマが型付けしたのであり、あなたがする必要はありませんでした。方向を逆にし（JSON → YAML）て JSON を貼り戻せば、同じ入れ子構造がリスト項目にダッシュを使って再インデントされた形で得られます。それが設定リポジトリにチェックインする形です。

よくある質問#

YAML のコメントは往復変換で保存されますか？#

いいえ。JSON にはコメントの構文がまったくないため、YAML 内の # comment は読まれた後、JSON への道中で破棄されます——置き場所がないのです。コメントは入力として許容されます（エラーを引き起こすことはありません）が、この行き来を生き延びることはできません。コメントが重要なら、YAML を真実のソースとして保持し、毎回そこから JSON を生成してください。

複数ドキュメントの YAML（--- で区切られたファイル）は扱えますか？#

ドキュメントストリームを処理し、先頭のドキュメントを返します。ほとんどの設定ファイルやマニフェストは単一ドキュメントなので、これが問題になることはまれです。複数ドキュメントのストリームがある場合は、--- 区切りで分割して各部分を変換してください。

設定ファイルは YAML と JSON のどちらがいいですか？#

人が手で編集し、アンカーとインデントによる入れ子を持つコメント的な可読性を欲するなら YAML を。機械が生成し、パーサーが消費する場合や、厳密さが重要な場合（JSON には各値を書く正当な方法がちょうど 1 つしかなく、デバッグすべき曖昧さがない）は JSON を。このツールは、どちらか一方に絞らなくて済むように存在します。

エラーが「行 4、列 5」と言いますが、その行は問題なさそうです。何が悪いのでしょう？#

ほぼ常にインデントです。YAML は先頭のスペースから構造を決めるため、1 スペース分左や右にずれた子、あるいはタブとスペースの混在は、パーサーが次のトークンを読むときに初めて不整合に気づくため、本当の原因の次の行のエラーとして現れます。報告された行の 1 つ上の行のインデントをまず確認してください。