シーケンスの中にマッピングを書くとき、ハイフンの位置を毎回迷っていました。「マッピング・シーケンス・スカラーの3つしかない」と要素を数で捉え直してから、どんなに深くネストしても読み解けるようになった気がします。

YAMLの3要素

YAMLのマッピング・シーケンス・スカラーとツリー構造の対応を示す図

図1: インデントの深さがそのままツリーの階層になる

YAMLで表現できるデータは、以下の3種類の組み合わせだけで構成されています。

マッピング(Mapping)
キー: 値 の組。他言語での辞書(dict)やオブジェクトに相当。
シーケンス(Sequence)
順序付きのリスト。他言語での配列(array / list)に相当。
スカラー(Scalar)
それ以上分解できない単一の値。文字列・数値・真偽値・nullなど。

マッピングの値やシーケンスの要素として、別のマッピング・シーケンス・スカラーを自由に入れ子にできます。これが「ネスト」であり、YAMLで複雑な構造を表現する仕組みそのものです。

マッピング(辞書)の書き方

マッピングは キー: 値 の形式で書きます。コロンの直後に半角スペースが1つ必須である点に注意してください。

YAML — マッピングの基本
name: web-app
version: 1.2.0
description: サンプルアプリケーション

⚠️ コロンの後のスペースを忘れると別の意味になる

name:web-app のようにスペースを省略すると、YAMLパーサーはこれを「マッピング」ではなく1つの文字列スカラー "name:web-app" として解釈してしまいます。key: の直後は必ず半角スペースを1つ入れてください。

ネストしたマッピング(マッピングの値として、さらにマッピングを書く)は次のように表現します。

YAML — ネストしたマッピング
database:
  host: db.example.com
  port: 5432
  credentials:
    user: admin
    password: secret

database の値は空にして改行し、次の行から2スペース深くインデントすることで「databaseの中にhostportcredentialsがある」という階層を表現しています。

シーケンス(配列)の書き方

シーケンスは、各要素の先頭に -(ハイフン + 半角スペース)を付けて表現します。

YAML — シーケンスの基本
fruits:
  - apple
  - banana
  - orange

マッピングのキーに紐づくシーケンスは、キーと同じインデント位置に - を置いても、1段深くインデントしても、どちらも同じ意味として解釈されます(多くのパーサー・Lintツールでは後者の書き方が推奨されます)。

YAML — シーケンス内にマッピングを入れる
users:
  - name: Alice
    role: admin
  - name: Bob
    role: viewer

この例では users がシーケンスで、その各要素が「nameroleを持つマッピング」になっています。- name: Alicename と、次の行の role が同じインデント位置(-の後ろの文字の位置)にそろっている点がポイントです。

スカラー値の型

スカラー値には型がありますが、YAML自体は「文字列っぽく見えるものを、文脈から型推論する」という設計になっています。

書き方の例備考
文字列name: web-appクォート省略可。特殊文字を含む場合は引用符が必要
整数port: 8080そのまま数値として解釈される
浮動小数点数ratio: 0.75指数表記(1.5e3)も可
真偽値enabled: truefalsetrue推奨(後述の曖昧な表記に注意)
nullvalue: null / value: ~キーだけ書いて値を省略してもnullになる
日付created: 2026-07-22ISO 8601形式は自動的に日付型として解釈される

⚠️ 「ノルウェーの問題」に注意

YAML 1.1では yes / no / on / off / NO なども真偽値として解釈されます。国名コード「NO」や設定値「on」を文字列として使いたい場合は、"NO" のように明示的にクォートで囲んでください。PART 02で導入したyamllintの truthy ルールで、許容する表記を true/false のみに制限できます。

文字列にコロン・ハイフン・特殊記号を含む場合や、意図的に数値・真偽値と誤解されるのを防ぎたい場合は、シングルクォート('...')またはダブルクォート("...")で明示的に囲みます。

インデントルール

YAMLの階層構造はすべてインデント(字下げ)の深さで決まります。ここがJSON/XMLと最も違う部分であり、最も事故が起きやすい部分でもあります。

  • インデントには半角スペースのみ使用する — タブ文字は仕様上禁止されている
  • 同じ階層は必ず同じ幅でそろえる — 1つでもズレるとエラーになるか、意図しない階層になる
  • スペースの数自体に決まりはないが、慣習的に2スペースが最も広く使われる
YAML — インデント崩れでエラーになる例
service:
  name: web-app
   port: 8080   # ← nameより1スペース深く、階層が崩れてエラーになる

💡 エディタ設定でタブをスペースに自動変換する

VS Codeの設定で「Editor: Insert Spaces」を有効にし、YAMLファイル用に「Editor: Tab Size」を2に設定しておくと、Tabキーを押しても自動的に半角スペース2つに変換され、事故を未然に防げます。

ネストの書き方

実務でよく登場する「マッピングの中にシーケンス、シーケンスの中にマッピング」というネストの組み合わせをまとめて見ておきます。

YAML — 複合的なネストの例
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(マッピング)の中に webdb(マッピング)があり、それぞれの中に portsenvironment(シーケンス)が入っています。最後の volumes: → db-data: のように、値を省略してnullを表す書き方もよく使われます。

コメントの書き方

コメントは # から行末までです。行全体をコメントにすることも、値の後ろに付けることもできます。

YAML — コメントの書き方
# このファイル全体の説明
service:
  port: 8080  # 開発環境では8080、本番では環境変数で上書きされる

💡 「なぜこの値なのか」を残せるのがYAMLの強み

JSONにはコメント機能がないため、設定意図を残すには別ファイルのドキュメントに頼るしかありません。YAMLならその場に理由を書き残せるため、後から見た人(未来の自分を含む)が助かります。

まとめ:記法早見表

要素記法対応する他形式のイメージ
マッピングkey: valueJSONのオブジェクト {}
シーケンス- itemJSONの配列 []
文字列text / "text"JSON文字列 "text"
数値123 / 0.5JSON数値
真偽値true / falseJSON真偽値
nullnull / ~ / 空欄JSON null
コメント# commentJSONには存在しない

次の章では…

PART 04 では、同じ値を使い回すアンカー(&)と参照(*)、1ファイルに複数の設定をまとめる複数ドキュメント、JSON風に1行で書くフロースタイルなど、一歩進んだ応用記法を解説します。

→ PART 04 — 応用記法へ