エディタ上では問題なく見えていたYAMLが、CI環境で実行したら構文エラーで落ちる、ということが何度かありました。エディタのチェックとコマンドラインのチェックは別物だと気づいてから、両方を必ずセットで用意するようにしています。
この記事で構築する環境
図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)が動いています。
# コマンドパレット経由でもよいが、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 マニフェストなど、有名なフォーマットについては拡張機能が自動的にスキーマを推測して適用してくれる場合があります。独自フォーマットの場合は、設定でスキーマファイルのパスを明示的に紐づけることもできます。
{
"yaml.schemas": {
"https://json.schemastore.org/github-workflow.json": ".github/workflows/*.yml",
"./schemas/app-config.schema.json": "config/*.yaml"
}
}
yamllintのインストール
yamllint はPython製のYAML構文・スタイルチェッカーです。エディタに依存せず、ターミナルやCI環境でそのまま実行できるのが最大の利点です。
# pip でインストール(仮想環境の利用を推奨)
pip install yamllint
# インストール確認
yamllint --version
# 特定ファイルを検査
yamllint config.yaml
# ディレクトリを再帰的に検査
yamllint .
# 標準のstrictルールを使う場合
yamllint -d default 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)を置いてカスタマイズします。
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つのツールを組み合わせたワークフロー
- VS Code上でYAMLファイルを編集し、拡張機能の赤波線でその場のミスに気づく
- 区切りの良いタイミングでターミナルから
yamllint .を実行し、プロジェクト全体を横断的に検査する - コミット前に問題がないことを確認してからPushする
✅ pre-commitフックとの相性も良い
yamllintはpre-commit(Gitフック管理ツール)用のフックが公式に提供されており、コミット時に自動実行させることも可能です。CIへの組み込み方はPART 05で詳しく扱います。
動作確認
わざとインデントを崩したファイルで、拡張機能とyamllintの両方が反応することを確認しておきましょう。
service:
name: web-app
port: 8080
このファイルをVS Codeで開くと、3行目の port の位置に赤波線が表示されます。同じファイルに yamllint check.yaml を実行すると、syntax error として行番号付きでエラーが報告されます。両方で検出できれば、環境構築は完了です。
✅ 次の章では…
PART 03 では、いよいよYAMLの中身であるマッピング・シーケンス・スカラー値の書き方と、YAML最大の特徴であるインデントルールを具体的に解説します。