child pipeline（子パイプライン） は、GitLab CI/CD で親パイプラインから別の設定として起動される下流パイプライン。.gitlab-ci.yml の中で trigger: キーワードを使い、別ファイルの設定を子パイプラインとして実行する。1 つの巨大な設定を、責務ごと・対象ごとに分割できる。
基本構文
# 親側：別ファイルを子パイプラインとして起動
child-a:
trigger:
include:
- local: ci/child-a.yml
strategy: depend # 子の結果を親 MR に反映し、完了を待つstrategy: depend を付けると、子パイプラインの成果物レポートが親の MR ウィジェットに反映され、親が子の完了を待つ。
動的 child pipeline（dynamic child pipeline）
子パイプラインの設定を、静的ファイルではなくジョブの中で生成した YAML から起動する手法。GitLab 公式が正式に位置づけている。
“You can trigger a child pipeline from a YAML file generated in a job, instead of a static file saved in your project.” — GitLab Docs
# ① ジョブで子パイプライン用 YAML を生成（artifact として保存）
generate:
stage: prepare
script:
- ./generate.sh > generated.yml # 生成ロジックはスクリプトに閉じる
artifacts:
paths: [generated.yml]
# ② 生成された YAML を子パイプラインとして起動
run:
stage: trigger
needs: [generate]
trigger:
include:
- artifact: generated.yml
job: generate
strategy: depend何を生成するか（＝設計のキモ）はプロジェクトごとに決める。代表的な用途は **「変更があった対象だけのジョブを生成する」**こと。GitLab は Jsonnet 等のテンプレート言語による生成例を公式提供している。
なぜ効くのか — .gitlab-ci.yml を肥大化させない
動的生成を使わない場合、対象（サービス・スタック・クライアント）が増えるたびに .gitlab-ci.yml へ条件分岐を足し続けることになり、設定が線形に長くなって見通しが効かなくなる（俗に言う「秘伝のタレ」化）。
動的 child pipeline は、この問題を構造的に解く。
| 観点 | 静的 .gitlab-ci.yml のみ | 動的 child pipeline |
|---|---|---|
| 対象追加時 | 条件分岐を手で追記 | ディレクトリ追加のみ・CI 本体は不変 |
| 設定の長さ | 対象数に比例して増大 | 薄いまま一定 |
| 実行範囲 | 全対象走査になりがち | 変更分のみに限定可能 |
| 保守の属人性 | 高くなりやすい | 生成ロジックに集約 |
モノレポ／マルチスタックの Infra CI/CD で特に効果が大きい。
関連記事・用語
- Terraform IaC 実践ガイド：CI/CD パイプライン編 — 動的 child pipeline でマルチスタック Infra を運用する実例
- GitLab id_tokens — 子パイプラインのジョブでキーレス認証を行うキーワード
- Workload Identity Federation — 動的パイプラインと組み合わせるキーレス認証