シーケンスの中にマッピングを書くとき、ハイフンの位置を毎回迷っていました。「マッピング・シーケンス・スカラーの3つしかない」と要素を数で捉え直してから、どんなに深くネストしても読み解けるようになった気がします。
YAMLの3要素
図1: インデントの深さがそのままツリーの階層になる
YAMLで表現できるデータは、以下の3種類の組み合わせだけで構成されています。
キー: 値 の組。他言語での辞書(dict)やオブジェクトに相当。マッピングの値やシーケンスの要素として、別のマッピング・シーケンス・スカラーを自由に入れ子にできます。これが「ネスト」であり、YAMLで複雑な構造を表現する仕組みそのものです。
マッピング(辞書)の書き方
マッピングは キー: 値 の形式で書きます。コロンの直後に半角スペースが1つ必須である点に注意してください。
name: web-app
version: 1.2.0
description: サンプルアプリケーション
⚠️ コロンの後のスペースを忘れると別の意味になる
name:web-app のようにスペースを省略すると、YAMLパーサーはこれを「マッピング」ではなく1つの文字列スカラー "name:web-app" として解釈してしまいます。key: の直後は必ず半角スペースを1つ入れてください。
ネストしたマッピング(マッピングの値として、さらにマッピングを書く)は次のように表現します。
database:
host: db.example.com
port: 5432
credentials:
user: admin
password: secret
database の値は空にして改行し、次の行から2スペース深くインデントすることで「databaseの中にhost・port・credentialsがある」という階層を表現しています。
シーケンス(配列)の書き方
シーケンスは、各要素の先頭に -(ハイフン + 半角スペース)を付けて表現します。
fruits:
- apple
- banana
- orange
マッピングのキーに紐づくシーケンスは、キーと同じインデント位置に - を置いても、1段深くインデントしても、どちらも同じ意味として解釈されます(多くのパーサー・Lintツールでは後者の書き方が推奨されます)。
users:
- name: Alice
role: admin
- name: Bob
role: viewer
この例では users がシーケンスで、その各要素が「nameとroleを持つマッピング」になっています。- name: Alice の name と、次の行の role が同じインデント位置(-の後ろの文字の位置)にそろっている点がポイントです。
スカラー値の型
スカラー値には型がありますが、YAML自体は「文字列っぽく見えるものを、文脈から型推論する」という設計になっています。
| 型 | 書き方の例 | 備考 |
|---|---|---|
| 文字列 | name: web-app | クォート省略可。特殊文字を含む場合は引用符が必要 |
| 整数 | port: 8080 | そのまま数値として解釈される |
| 浮動小数点数 | ratio: 0.75 | 指数表記(1.5e3)も可 |
| 真偽値 | enabled: true | false・true推奨(後述の曖昧な表記に注意) |
| null | value: null / value: ~ | キーだけ書いて値を省略してもnullになる |
| 日付 | created: 2026-07-22 | ISO 8601形式は自動的に日付型として解釈される |
⚠️ 「ノルウェーの問題」に注意
YAML 1.1では yes / no / on / off / NO なども真偽値として解釈されます。国名コード「NO」や設定値「on」を文字列として使いたい場合は、"NO" のように明示的にクォートで囲んでください。PART 02で導入したyamllintの truthy ルールで、許容する表記を true/false のみに制限できます。
文字列にコロン・ハイフン・特殊記号を含む場合や、意図的に数値・真偽値と誤解されるのを防ぎたい場合は、シングルクォート('...')またはダブルクォート("...")で明示的に囲みます。
インデントルール
YAMLの階層構造はすべてインデント(字下げ)の深さで決まります。ここがJSON/XMLと最も違う部分であり、最も事故が起きやすい部分でもあります。
- インデントには半角スペースのみ使用する — タブ文字は仕様上禁止されている
- 同じ階層は必ず同じ幅でそろえる — 1つでもズレるとエラーになるか、意図しない階層になる
- スペースの数自体に決まりはないが、慣習的に2スペースが最も広く使われる
service:
name: web-app
port: 8080 # ← nameより1スペース深く、階層が崩れてエラーになる
💡 エディタ設定でタブをスペースに自動変換する
VS Codeの設定で「Editor: Insert Spaces」を有効にし、YAMLファイル用に「Editor: Tab Size」を2に設定しておくと、Tabキーを押しても自動的に半角スペース2つに変換され、事故を未然に防げます。
ネストの書き方
実務でよく登場する「マッピングの中にシーケンス、シーケンスの中にマッピング」というネストの組み合わせをまとめて見ておきます。
services:
web:
image: nginx:latest
ports:
- "80:80"
- "443:443"
environment:
- ENV=production
- DEBUG=false
db:
image: postgres:16
volumes:
- db-data:/var/lib/postgresql/data
volumes:
db-data:
この例では、services(マッピング)の中に web と db(マッピング)があり、それぞれの中に ports や environment(シーケンス)が入っています。最後の volumes: → db-data: のように、値を省略してnullを表す書き方もよく使われます。
コメントの書き方
コメントは # から行末までです。行全体をコメントにすることも、値の後ろに付けることもできます。
# このファイル全体の説明
service:
port: 8080 # 開発環境では8080、本番では環境変数で上書きされる
💡 「なぜこの値なのか」を残せるのがYAMLの強み
JSONにはコメント機能がないため、設定意図を残すには別ファイルのドキュメントに頼るしかありません。YAMLならその場に理由を書き残せるため、後から見た人(未来の自分を含む)が助かります。
まとめ:記法早見表
| 要素 | 記法 | 対応する他形式のイメージ |
|---|---|---|
| マッピング | key: value | JSONのオブジェクト {} |
| シーケンス | - item | JSONの配列 [] |
| 文字列 | text / "text" | JSON文字列 "text" |
| 数値 | 123 / 0.5 | JSON数値 |
| 真偽値 | true / false | JSON真偽値 |
| null | null / ~ / 空欄 | JSON null |
| コメント | # comment | JSONには存在しない |
✅ 次の章では…
PART 04 では、同じ値を使い回すアンカー(&)と参照(*)、1ファイルに複数の設定をまとめる複数ドキュメント、JSON風に1行で書くフロースタイルなど、一歩進んだ応用記法を解説します。