JSONとYAMLを貼り付けるだけで相互変換します。--- 区切りの複数ドキュメント、行番号つきの構文エラー表示、先頭ゼロや日付が壊れる型崩れの検出まで、この画面だけで確認できます。
このツールはブラウザの中だけで動いています。入力した内容が、外部に送信されることはありません。入力内容は外部に送信されません。
詳しくJSON ⇄ YAML 変換ツールとは？
本ツールは、データ記述形式であるJSONとYAMLを相互に変換できるオンラインツールです。貼り付けた時点で形式を自動判定し、入力するたびにリアルタイムで変換と構文チェックを行います。変換ボタンを押す必要はありません。
一般的な変換ツールと異なるのは、実務でつまずく箇所を先回りして知らせる点です。Kubernetesのマニフェストで使われる--- 区切りの複数ドキュメントに対応し、構文エラーは行番号と列位置つきで該当行を抜き出して表示します。さらに、郵便番号の先頭ゼロが消える、日付が別の表記に変わる、コメントが失われるといった型崩れやデータ欠落を自動で検出して警告します。
出力設定では、インデント幅の変更、キーのアルファベット順への並べ替え、YAMLの値を必ず引用符で囲む指定、JSONの1行圧縮に対応しています。
こんなシーンで便利です
Kubernetes・Dockerの設定編集
--- 区切りの複数マニフェストをJSONの配列として取り出したり、逆に読みやすいYAMLへ整形したりできます。
APIレスポンスの可読性向上
複雑なJSONをYAMLに変換すると、括弧が消えて階層がインデントで表現され、目視での確認が容易になります。
CI/CD設定ファイルの構文チェック
GitHub ActionsなどのYAMLに誤りがないか、行番号つきのエラー表示で修正箇所を特定できます。
設定データの型崩れチェック
先頭ゼロの番号、日付、yes / no といった値が意図しない型に変わっていないかを、変換前に確認できます。
使い方は簡単 4ステップ
- 入力エリアにJSONまたはYAMLを貼り付けるか、ファイルを読み込みます。
- 形式が自動判定され、変換結果と構文チェックがリアルタイムで表示されます。
- 警告が出た場合は内容を確認し、必要に応じて引用符を追加するなどの対処を行います。
- 出力設定でインデントや並び順を調整し、コピーまたはファイルとして保存します。
※変換方向は自動判定のほか、JSON→YAML、YAML→JSONを明示的に指定することもできます。判定が意図と異なる場合は手動で切り替えてください。
ご利用時の注意点
- 複数ドキュメント：--- で区切られたYAMLは、JSONの配列としてまとめて出力します。検出したドキュメント数は画面下部に表示されます。
- コメントの扱い：JSONの仕様上コメントは保持できません。変換前に元のYAMLをバックアップしてください。
- 型の解釈：0123 は数値、2026-01-01 は日付、true / false は真偽値として解釈されます。文字列として保ちたい場合は引用符で囲むか、値を必ず引用符で囲む設定を有効にしてください。
- アンカーとエイリアス：YAMLの & と * による参照は、変換時にすべて展開された状態でJSONへ出力されます。参照構造そのものは保持されません。
- JSONの整形や構文修復はJSON整形・構文チェックツール、YAML単体の検証はYAMLリンター、CSVやXMLとの変換はCSV⇄JSON変換をご利用ください。
YAMLからJSONへ変換したときに値が変わるパターン一覧
引用符のない値はYAMLのパーサが型を推測します。意図しない変換が起きやすい代表的なパターンと、その回避方法です。
| YAMLでの記述 | 変換後のJSON | 起きること | 回避方法 |
|---|---|---|---|
| zip: 0123 | 123 | 数値として解釈され先頭のゼロが消える | '0123' と引用符で囲む |
| date: 2026-01-01 | "2026-01-01T00:00:00.000Z" | 日付型として解釈されISO形式になる | '2026-01-01' と引用符で囲む |
| version: 1.10 | 1.1 | 数値の末尾のゼロが失われる | '1.10' と引用符で囲む |
| answer: yes | "yes" または true | パーサにより真偽値になる場合がある | true を使うか引用符で囲む |
| value: null / ~ / 空 | null | いずれもnullとして扱われる | 'null' と書けば文字列になる |
| # コメント | （消失） | JSONにコメントの概念がない | 元ファイルを別途保管する |
| base: &ref / use: *ref | 展開された実体 | 参照構造が失われ内容が複製される | 参照を保ちたい場合はYAMLのまま扱う |
| --- で区切られた複数ドキュメント | 配列 [ {...}, {...} ] | 1つの配列にまとめられる | 個別に扱う場合は分割して変換する |
JSONとYAMLの使い分け
- JSON： API通信やプログラム間のデータ交換。仕様が厳密で解釈のぶれがなく、あらゆる言語で扱えます。
- YAML： 人が読み書きする設定ファイル。コメントが書け、括弧が不要なぶん階層を追いやすい形式です。
- 変換が必要になる場面： JSONで生成した定義を人がレビューするときはYAMLへ、YAMLで管理した設定をプログラムへ渡すときはJSONへ、という往復が実務では頻繁に発生します。
※本ツールはECMA-404標準のJSONおよびYAML 1.2の仕様に基づいて相互変換を行います。YAMLの型解釈はパーサの実装によって差があるため、他の言語や環境へ渡す前には、変換結果の型が意図どおりかを必ず確認してください。
設定ファイルの変換と運用で事故を起こさないための実務的な考え方
単に形式を変えるだけでなく、型の一貫性、秘匿情報の扱い、バージョン管理まで含めて安全に運用するための指針を整理します。
型の推測に頼らず、引用符で意図を明示するという原則
YAMLの利点である記述の簡潔さは、裏を返せばパーサに型を推測させているということです。郵便番号、電話番号、商品コード、バージョン番号のように「数値に見えるが文字列として扱いたい値」は、必ず引用符で囲んでください。
特に厄介なのは、開発環境では問題なく動いていたものが、別言語のパーサに渡した途端に挙動が変わるケースです。yes や no はYAML 1.1系のパーサでは真偽値、1.2系では文字列になるなど、仕様のバージョンによって解釈が異なります。曖昧さを残さないことが最も確実な予防策です。
変換したファイルをコミットする前に、キーの並び順を正規化する
プログラムが出力したJSONやYAMLは、内容が同じでもキーの並び順が実行ごとに変わることがあります。そのままバージョン管理へコミットすると、意味のない差分が大量に発生し、レビューで本質的な変更が埋もれます。
対策は、コミット前にキーをアルファベット順へ並べ替えて正規化すること。本ツールの出力設定から一括で適用できます。あわせてインデント幅もプロジェクト内で統一しておくと、差分は変更箇所のみに絞られます。
認証情報を含む設定ファイルを扱う際のツール選定
APIキー、データベースの接続文字列、トークンを含む設定ファイルを、サーバー側で処理する変換サービスへ貼り付けるのは避けてください。通信経路やサーバーのログに秘匿情報が残る可能性があり、組織のセキュリティ規程に抵触します。
本ツールはすべての処理をブラウザ内で完結させる設計のため、入力内容がネットワークへ出ることはありません。とはいえ、共用端末で作業した場合はブラウザの履歴やクリップボードに残る点には注意し、作業後はクリアしてください。
スキーマ検証と組み合わせて、変換後の構造を機械的に担保する
形式の変換が成功しても、アプリケーションが期待する構造になっている保証はありません。必須項目の欠落や型の不一致は、本番環境で初めて表面化することが少なくありません。
重要な設定ファイルについては、JSON Schema による検証を継続的インテグレーションの工程へ組み込み、変換後のデータが定義どおりかを機械的にチェックする体制を用意してください。変換ツールは形式を変える役割、スキーマ検証は内容を保証する役割、と分けて考えるのが確実です。
JSONとYAMLの変換でよくある失敗と対策
複数ドキュメントのYAMLが変換できず、手作業で分割してしまう失敗
Kubernetesのマニフェストのように --- で区切って複数の定義を1ファイルにまとめた形式は実務で広く使われますが、単一ドキュメントしか想定していない変換ツールではエラーになります。結果としてドキュメントごとに手作業で切り出して変換し、また結合するという非効率な作業が発生し、その過程で取りこぼしも起こります。
💡 対策・解決策を見る▼
先頭ゼロや日付が意図せず変換され、データが静かに壊れる失敗
郵便番号の 0123 が 123 に、バージョンの 1.10 が 1.1 に、日付の 2026-01-01 がISO形式の文字列に変わるケースです。変換自体はエラーにならず正常終了するため気づきにくく、本番環境でデータの不整合として表面化したときには原因の特定に時間がかかります。
💡 対策・解決策を見る▼
コメントが消えることを知らずに変換し、元ファイルを上書きする失敗
Infrastructure as CodeやCI/CDの設定では、なぜその値なのかという意図をコメントとして残していることが多くあります。JSONへ変換した時点でこれらはすべて失われ、その状態からYAMLへ戻しても復元されません。元ファイルを上書きしてしまうと、蓄積してきた知見が完全に失われます。
💡 対策・解決策を見る▼
インデントのずれやタブの混入を目視で探し、時間を浪費する失敗
YAMLはインデントによって階層を表現するため、半角スペースが1つずれただけで別の構造として解釈されます。エディタの設定違いでタブ文字が混入した場合も同様にエラーとなりますが、見た目では判別できないため、長いファイルでは原因の箇所にたどり着くまでに時間がかかります。
💡 対策・解決策を見る▼
よくある質問（FAQ）
Q.Kubernetesのように --- で区切られた複数のYAMLも変換できますか
A. 変換できます。--- で区切られた複数のドキュメントを読み取り、JSONの配列としてまとめて出力します。ConfigMapとServiceを1つのファイルにまとめたマニフェストのような、実務で扱う形式にそのまま対応しています。何件のドキュメントを検出したかは画面上に表示されるため、意図した数と一致しているかも確認できます。
Q.構文エラーが出た場合にどこが間違っているか分かりますか
A. 分かります。エラーが発生した行番号と列位置を表示し、該当する行の内容を抜き出して問題の位置に記号を立てて示します。YAMLのインデントのずれやタブ文字の混入、JSONのカンマの欠落など、原因ごとに異なる説明が表示されるため、長いファイルでも修正箇所をすぐに特定できます。入力するたびに自動で検証されるため、変換ボタンを押す必要はありません。
Q.郵便番号の 0123 が 123 になってしまうのはなぜですか
A. YAMLでは引用符で囲まれていない 0123 が数値として解釈されるためです。数値には先頭のゼロという概念がないため、変換すると桁が失われます。本ツールはこのような値を検出して警告を表示します。文字列として保ちたい場合は '0123' のように引用符で囲むか、出力設定の値を必ず引用符で囲むを有効にしてください。
Q.2026-01-01 のような日付はどう扱われますか
A. YAMLのパーサは引用符のない日付形式を日付型として解釈します。そのままJSONへ変換すると 2026-01-01T00:00:00.000Z のようなISO 8601形式の文字列になり、元の表記と一致しません。本ツールは日付として解釈された値がある場合に警告を表示します。元の表記を保ちたい場合は引用符で囲んでから変換してください。
Q.YAMLのコメントは変換後も残りますか
A. 残りません。JSONの仕様にコメントが存在しないため、# で始まる記述は変換の過程で失われます。これはツールの制限ではなく形式上の制約です。本ツールはコメントを含むYAMLを検出すると警告を表示します。元のYAMLは必ずバージョン管理やローカルに保管したうえで変換してください。
Q.入力したデータが外部に送信されることはありませんか
A. ありません。本ツールは完全ローカル処理型の設計で、入力されたテキストが外部サーバーへ送信されることも、データベースへ保存されることもありません。すべての解析と変換はお使いのブラウザ内で完結し、ページを閉じた時点で消去されます。認証情報を含む設定ファイルでも安全に取り扱えます。
あなたの声で、
このツールをより鋭く。
「こんな機能が欲しい」「ここを直してほしい」といったご意見や、新しいツールのリクエストを募集しています。エンジニアが直接目を通し、開発の参考にさせていただきます。