YAML フォーマッター
YAMLを一貫したインデント幅に整形したり、JSONに変換したりできるツールです。タブ混入やインデントの不整合も検出します。
YAMLフォーマッターとは
YAMLフォーマッターは、インデントの幅がバラバラなYAMLをスペース2または4に統一して整形したり、構文エラーがないかをその場で検証したりできるツールです。設定ファイルはコピー＆ペーストや手作業の編集を繰り返すうちにインデントが崩れやすく、崩れたままではCI/CDや構成管理ツールがエラーを出して初めて気づく、ということが起こりがちです。このツールはブラウザ内で完結するため、機密性の高い設定ファイルの内容を外部サーバーに送信せずにチェックできます。
このツールは自前実装の軽量パーサーで動いており、Docker Compose・GitHub Actions・Kubernetesマニフェストなどでよく使われる「マッピング・リスト・インラインフロー・基本スカラー型」の範囲を対象としています。アンカー（&）・エイリアス（*）・複数ドキュメント・ブロックスカラー（|や>）といった高度な機能には対応していないため、これらを含む本格的なYAMLを扱う場合は専用のパーサーを併用してください。
YAMLフォーマッターの使い方
- YAMLを入力する 左側の入力欄に整形したいYAMLを貼り付けます。手元にサンプルが無い場合は「サンプル」ボタンを押すと動作確認用のYAMLが挿入されます。
- モードを選ぶ 「整形・検証」で構文チェックとインデント統一を行うか、「JSONに変換」でYAMLの内容をJSON形式に変換するかを選びます。
- インデント幅を選ぶ 「整形・検証」モードのみ、出力するインデントをスペース2またはスペース4から選べます。既存のプロジェクトの規約に合わせてください。
- 出力結果を確認する 有効なYAMLであれば右側に整形後の結果（またはJSON）が表示されます。無効な場合はエラー内容と行番号が表示されるので、該当行を修正してください。
- 結果をコピーする 「コピー」ボタンで出力結果をクリップボードにコピーし、設定ファイルへそのまま貼り戻せます。
使いこなすためのヒント
- このツールは自前実装の軽量パーサーのため、キー: 値・ネスト・リスト・インラインの
[a, b, c]や{a: 1}形式に対応しています。 - インデントが3スペースや5スペースなど不揃いなYAMLを貼り付けても、解析に成功すればスペース2または4に統一して出力し直せます。
- 「JSONに変換」モードでは、YAMLの内容をそのままJSON形式に変換したプレビューを確認できます。CI設定やAPIレスポンスとの比較に便利です。
- エラーが出た場合は行番号が表示されるので、該当行のインデントやコロンの後ろのスペース忘れを確認してください。
- YAMLではタブ文字によるインデントが禁止されています。エディタの設定で「タブをスペースに変換」を有効にしておくとトラブルを防げます。
こんな場面で使えます
CI設定ファイルの事前チェック
GitHub ActionsやGitLab CIの.ymlファイルをコミットする前に、インデントの崩れやタブ混入がないかをこのツールで確認し、パイプラインが構文エラーで止まるのを未然に防げます。
Kubernetesマニフェストの整形
複数人で編集したDeploymentやServiceのマニフェストはインデント幅が不揃いになりがちです。チームの規約（スペース2など）に統一してからレビューに出せます。
Docker Composeファイルの検証
docker-compose.ymlのインデントミスは起動時までエラーに気づきにくいため、事前にこのツールで構文とインデントの整合性をチェックしておくと安心です。
YAMLとJSONの相互比較
APIレスポンスや設定値をYAMLとJSONの両方の形式で扱う場合、「JSONに変換」モードで変換結果を確認し、他のJSONベースのツールやスキーマ検証と組み合わせて使えます。
用語集
- YAML
- 「YAML Ain't Markup Language」の再帰的頭字語で、インデントによって階層構造を表現するデータ直列化フォーマットです。設定ファイルとして広く使われています。
- インデント
- 行頭に置く空白文字で、YAMLでは階層構造（親子関係）を表します。YAMLの仕様上、インデントにタブ文字を使うことはできません。
- マッピング
- 「キー: 値」の形式でデータを表す構造で、他言語における連想配列やオブジェクトに相当します。
- リスト（シーケンス）
- 複数の値を順序付きで並べる構造で、各項目を「- 」（ハイフンとスペース）で始めて表します。
- フロースタイル
- マッピングやリストを
{a: 1}や[a, b, c]のように1行にインライン記述する書き方です。インデントに頼らず簡潔に書けます。 - アンカーとエイリアス
&nameで定義した内容を*nameで再利用する仕組みで、同じ値の重複記述を避けられます。このツールでは非対応です。- ブロックスカラー
|（改行を保持）や>（改行をスペースに畳む）で複数行の文字列を記述する書き方です。このツールでは非対応です。- Norway Problem
- クォートなしの
no・yes等が文字列ではなく真偽値として解釈されてしまう、YAMLでよく知られた落とし穴です。
よくある質問
|・>）といった高度な機能は非対応です。no や yes・on・off と書くと、多くのYAML実装がノルウェーの国コードなどの文字列ではなく真偽値として解釈してしまう有名な落とし穴です。文字列として扱いたい場合は "no" のようにクォートで囲む必要があります。
余談ですが ― YAMLが設定ファイルの主流になった理由
YAML（YAML Ain't Markup Language）は2001年に登場したデータ直列化フォーマットです。XMLに比べて閉じタグが不要で見た目がシンプルなことから、2010年代以降はDocker Compose・GitHub Actions・Kubernetesマニフェストなど、インフラ関連の設定ファイル形式として広く採用されるようになりました。
一方でYAMLの「インデントで構造を表す」という設計は、人間にとって読みやすい反面、コピー＆ペースト時にインデントが崩れやすいという弱点も抱えています。特にタブとスペースが混在すると、多くのパーサーがエラーを出さずに誤った構造として解釈してしまうことがあり、意図しない設定ミスの温床になりやすい点は注意が必要です。
また「Norway Problem」と呼ばれる有名な落とし穴もあります。国コード no をクォートなしで書くと、多くのYAML実装が真偽値の false と解釈してしまう問題です。YAML 1.1と1.2で真偽値として扱われる文字列の範囲が異なることも、実装間の互換性トラブルの一因になっています。