すべての処理はブラウザ内で実行されます — ファイルや入力はサーバへ送信されません。
左に YAML ドキュメントを貼り付けると、右のパネルに Valid / Invalid が表示され、エラーと警告がすべて行・列番号付きで一覧化されます。`---` で区切られた複数ドキュメントもサポートされ、パースできたドキュメント数が表示されます。警告には、パーサが自動解決する重複マップキーなど致命的でない問題が含まれます。
本ツールは構文検証であり、スキーマ検証ではありません。「YAML の形が壊れている」(インデントの誤り、閉じていない引用符、タブ混在、無効なアンカー参照など)は検出しますが、「Kubernetes マニフェストに `metadata.name` が必要」や「GitHub Actions ワークフローに不明なステップがある」は検出しません。k8s、GitHub Actions、自前の JSON Schema に対するスキーマ検証が必要な場合は、`kubeval`・`actionlint`・`ajv` と組み合わせてください。すべての処理は `yaml` パーサを使ってブラウザ内で行われるため、設定から貼り付けた秘密情報はマシン外に出ません。
apiVersion: v1 kind: ConfigMap metadata: name: app-config data: database_url: postgres://localhost:5432/app retries: 3
Valid · 1 document
標準的な 2 スペースインデントと、正しい深さに置かれたキー / 値のペアです。検証側はドキュメント数も表示するため、`---` で連結された複数リソースのマニフェストでも確認できます。
services:
web:
port: 8080
image: nginxInvalid · line 3, column 1: Tabs are not allowed as indentation in YAML
YAML 1.2 §5.1 は、インデントが期待される位置でのタブ文字を明確に禁止しています。多くのエディタはタブをスペースに自動変換しますが、別ソースからの貼り付けで `\t` バイトがそのまま入り込むことがあります。検証側が該当行を示してくれるので修正がすぐにできます。
countries: - US - JP - NO - KR
Valid · 1 document (Note: NO is parsed as the boolean false in YAML 1.1)
YAML 1.1 は `yes`・`no`・`on`・`off` とその大文字化形を真偽値として扱うため、国コードのリストからノルウェーが消えます。本ツールが使う `yaml` ライブラリは既定で 1.2 を採用しているため(真偽値は `true`・`false` のみ)、この例は文字列のままになります。とはいえ、PyYAML・libyaml・多くの Ansible や旧 Ruby パーサは現在も 1.1 を既定とします。曖昧なスカラーは必ず引用符で囲んでください(`- "NO"`)。
内部の `yaml` パッケージは既定で YAML 1.2 を使います。実務上の最大の違いは、1.1 が `yes/no/on/off/y/n/Y/N` とその大文字形を真偽値として扱う(ノルウェー問題)のに対し、1.2 は真偽値を `true/false` に絞ったことです。1.2 は 8 進数リテラルの混乱も整理しました。デプロイ先が 1.1 パーサ(多くの Ansible、旧 PyYAML)なら、両方で検証してください。本ツールでパスしても、向こうで挙動が変わる可能性があります。
よくある原因はタブとスペースの混在です。YAML はインデント位置でのタブを禁止しますが、多くのエディタはタブを 4 / 8 スペース幅で表示するため、見た目はスペースインデントと区別できません。ファイルを hex 表示するか `cat -A` で `\t` バイトを確認してください。他に静かに失敗させる要因として、ドキュメントから貼り付けた改行禁止スペース(U+00A0)、ファイル先頭の BOM、プレーンスカラー内に紛れた制御文字などがあります。
いいえ。本ツールは YAML の*構文*のみを検証します。「`Deployment` には `spec.template.spec.containers` が必要」「ワークフローの `run:` は `uses:` と兄弟関係にできない」のようなスキーマルールには、スキーマ対応ツールが必要です。Kubernetes には `kubeval` や `kubeconform`、GitHub Actions には `actionlint`、任意の JSON Schema には `ajv-cli` を使ってください。これらはちゃんと整形された YAML を入力に取るため、本検証を通してから走らせるのが順序です。
はい。複数ドキュメントのストリームは YAML の標準仕様で、本検証はドキュメント数を表示します。各ドキュメントは独立して検証され、ドキュメント 2 のエラーがあってもドキュメント 3 はスキップされません。`kubectl apply -f manifest.yaml` も同じ複数ドキュメント形式を受け付けるため、Helm チャートの出力や `kustomize build` の結果はこの形になっています。
YAML 1.2 §6.7 では重複キーはエラーとされていますが、実環境のパーサ(PyYAML・libyaml・寛容モードの snakeyaml など)はファイルを受け入れ、静かに最後の値を残すものが大半です。`yaml` ライブラリは実情に合わせて回復可能な警告として扱います。ドキュメントは引き続きパースされますが、警告として表面化することでバグが隠れないようにしています。
本ツールではできません。検証のみです。相互変換が必要なら本サイトの JSON ↔ YAML コンバータを使ってください。YAML は JSON にない型(日付、集合、改行を保持する複数行文字列、アンカー経由の参照など)を扱えるため、YAML → JSON への一方向変換ではこれらが失われるか、文字列化されます。
YAML(YAML Ain't Markup Language)は、Clark Evans・Ingy döt Net・Oren Ben-Kiki により設計され 2001 年に最初に公開された、人手編集に最適化されたデータシリアライゼーション言語です。現行版は YAML 1.2.2(2021 年 10 月)。コアデータモデルは JSON 互換のスカラー / 配列 / マップのツリーで、JSON として有効なものはすべて YAML としても有効です。さらに YAML はインデントベースの構造、コメント、アンカー / エイリアス、複数ドキュメントストリーム、より豊かなスカラー型などを追加で備えます。
つまずくのは表層構文です。インデントはスペース必須、インデント位置でのタブ文字は禁止されます。文字列はプレーン(引用符なし)、シングルクォート(`''` 以外はリテラル)、ダブルクォート(エスケープあり)、ブロック(`|` は改行を保持、`>` は折り畳む)のいずれかです。引用符なしスカラーは真偽値(`true`・`false`)、整数、浮動小数、null(`null`・`~`・空)、または文字列に自動型付けされます。これが YAML 1.1 の悪名高いノルウェー問題を生みました(`no`・`false`・`off` がすべて真偽値の false になる)。型付きリテラルに似たスカラーは、引用符で囲むことで曖昧さを排除できます。
隣接するシリアライザはそれぞれ異なる領域を担います。**JSON** は YAML 1.2 の厳密な部分集合で、機械処理に向くが人手編集には冗長です。**TOML** は設定ファイル向けで、よりフラットで曖昧さの少ない構文を持ち、Rust の `Cargo.toml` や Python の `pyproject.toml` で一般的です。**HCL**(HashiCorp Configuration Language)は Terraform 構成を支え、ブロック指向で式を扱える構文を備えます。YAML の居場所は、複数ドキュメント・アンカー・人間が書くコメントが、インデントの厳しさを払う価値のある分野です。Kubernetes マニフェスト、GitHub Actions ワークフロー、CI / CD パイプライン、Ansible プレイブックなどがそれにあたります。