エディタ上では問題なく見えていたYAMLが、CI環境で実行したら構文エラーで落ちる、ということが何度かありました。エディタのチェックとコマンドラインのチェックは別物だと気づいてから、両方を必ずセットで用意するようにしています。

この記事で構築する環境

VS Code YAML拡張機能とyamllintを組み合わせた環境構成図

図1: エディタ側のリアルタイムチェックと、コマンドライン側の静的チェックを両方用意する

本記事では2つのツールを導入します。1つはVS Code の YAML拡張機能で、編集中にリアルタイムでエラーや警告を表示してくれます。もう1つはyamllintというPython製のコマンドラインツールで、エディタを介さずファイルを直接検査でき、CI(継続的インテグレーション)にも組み込めます。

この2つを揃えることで、「書いている最中に気づける」チェックと「提出前に機械的に強制できる」チェックの両方をカバーします。

VS Code — YAML拡張機能の導入

VS Code の拡張機能マーケットプレイスで最も広く使われているYAML拡張機能は、Red Hat社が提供する YAML(拡張機能ID: redhat.vscode-yaml)です。裏側でJSON Schemaを使ったバリデーションエンジン(yaml-language-server)が動いています。

Shell — VS Code拡張機能のインストール
# コマンドパレット経由でもよいが、CLIから一括導入すると再現性が高い
code --install-extension redhat.vscode-yaml

GUIから入れる場合は、拡張機能タブ(Ctrl+Shift+X)で YAML を検索し、発行元が Red Hat のものをインストールしてください。

💡 チームで揃える場合は extensions.json

プロジェクト直下に .vscode/extensions.json を置いて "recommendations": ["redhat.vscode-yaml"] と書いておくと、リポジトリを開いたメンバーに拡張機能のインストールが自動的にレコメンドされます。

拡張機能の主な機能

機能説明
構文エラー検出インデント崩れ・タブ文字混入などを赤波線でリアルタイム表示
スキーマ検証JSON Schemaを紐づけると、キー名の誤りや必須項目の欠落を警告してくれる
自動補完スキーマに沿ったキー名・値の候補をCtrl+Spaceで表示
ホバー情報キーにカーソルを合わせると、スキーマ上の説明文をポップアップ表示
アウトライン表示エディタ右側のミニマップ横に、マッピングの階層構造を表示

特に便利なのがスキーマ検証機能です。GitHub Actionsのワークフローファイルや Kubernetes マニフェストなど、有名なフォーマットについては拡張機能が自動的にスキーマを推測して適用してくれる場合があります。独自フォーマットの場合は、設定でスキーマファイルのパスを明示的に紐づけることもできます。

JSON — settings.json でスキーマを明示的に紐づける例
{
  "yaml.schemas": {
    "https://json.schemastore.org/github-workflow.json": ".github/workflows/*.yml",
    "./schemas/app-config.schema.json": "config/*.yaml"
  }
}

yamllintのインストール

yamllint はPython製のYAML構文・スタイルチェッカーです。エディタに依存せず、ターミナルやCI環境でそのまま実行できるのが最大の利点です。

Shell — yamllintのインストール
# pip でインストール(仮想環境の利用を推奨)
pip install yamllint

# インストール確認
yamllint --version

# 特定ファイルを検査
yamllint config.yaml

# ディレクトリを再帰的に検査
yamllint .

# 標準のstrictルールを使う場合
yamllint -d default config.yaml
yamllint config.yaml の出力例(問題がある場合)
config.yaml
  3:1       error    wrong indentation: expected 2 but found 4  (indentation)
  7:10      warning  line too long (92 > 80 characters)  (line-length)
  12:1      error    duplication of key "port" in mapping  (key-duplicates)

⚠️ 問題がなければ何も出力されない

yamllintは正常時に何も表示しません。「実行して無反応=OK」という挙動に最初は戸惑うかもしれませんが、Unix系コマンドラインツールの一般的な流儀(Silence is golden)に沿った設計です。終了コードは正常時 0、問題検出時は 1 になります。

yamllintの実行と設定ファイル(.yamllint)

デフォルトのルールセットは厳しめに設定されています。プロジェクトごとに緩めたい・強めたいルールがある場合は、リポジトリ直下に .yamllint(または.yamllint.yml)を置いてカスタマイズします。

YAML — .yamllint 設定例
extends: default

rules:
  # 1行の長さ制限を緩和(デフォルトは80文字)
  line-length:
    max: 120
    level: warning

  # インデント幅を明示的に2に固定
  indentation:
    spaces: 2
    indent-sequences: true

  # 末尾の空白行を最大1行まで許容
  empty-lines:
    max-end: 1

  # true/false以外の曖昧な真偽値表記を禁止(yes/no, on/offなど)
  truthy:
    allowed-values: ["true", "false"]

ignore: |
  vendor/
  node_modules/
設定キー役割
extendsベースとなるルールセットを指定(default が標準)
rules個別ルールの有効化・無効化・パラメータ調整
ignore検査対象から除外するパス(複数行文字列で記述)

2つのツールを組み合わせたワークフロー

  1. VS Code上でYAMLファイルを編集し、拡張機能の赤波線でその場のミスに気づく
  2. 区切りの良いタイミングでターミナルから yamllint . を実行し、プロジェクト全体を横断的に検査する
  3. コミット前に問題がないことを確認してからPushする

pre-commitフックとの相性も良い

yamllintはpre-commit(Gitフック管理ツール)用のフックが公式に提供されており、コミット時に自動実行させることも可能です。CIへの組み込み方はPART 05で詳しく扱います。

動作確認

わざとインデントを崩したファイルで、拡張機能とyamllintの両方が反応することを確認しておきましょう。

YAML — わざとインデントを崩した例(check.yaml)
service:
  name: web-app
   port: 8080

このファイルをVS Codeで開くと、3行目の port の位置に赤波線が表示されます。同じファイルに yamllint check.yaml を実行すると、syntax error として行番号付きでエラーが報告されます。両方で検出できれば、環境構築は完了です。

次の章では…

PART 03 では、いよいよYAMLの中身であるマッピング・シーケンス・スカラー値の書き方と、YAML最大の特徴であるインデントルールを具体的に解説します。

→ PART 03 — 基本記法へ