필사 모드: 設定言語 2026 — CUE / Pkl (Apple) / KCL / Dhall / Jsonnet / HCL / Nix / Starlark / Pulumi (TS) 徹底比較

プロローグ — 1,000行の YAML を覗いた SRE のため息

2026年春、ある基盤チームの会議室。

SRE「この Helm values.yaml が1,400行あるんです。インデント一つ間違えて昨日本番が壊れました」

PM「なぜそんなに長いんですか」

SRE「環境3つ × マイクロサービス47個 × リージョン4つ。掛けると564組み合わせで、差は5%くらい。でも YAML は抽象化がないから全部コピペなんです」

PM「別の言語使えばいいじゃないですか」

SRE「何で?Jsonnet?Helm template?Kustomize?CUE?Pkl?Terraform なら HCL?Bazel なら Starlark?Pulumi で TypeScript?Nix?全部社内で使われてます。どれを推奨するか決まったことがないんです」

これが2026年の風景である。我々は**設定爆発の時代**を生きている。Kubernetes YAML、Terraform HCL、Helm values、Backstage カタログ、ArgoCD ApplicationSet、GitHub Actions、CircleCI orbs、Buildkite pipeline、Dockerfile、Bazel BUILD、devcontainer.json、dprint config、biome.json、package.json、pyproject.toml — マイクロサービス1つ起こせば設定ファイル30個は当たり前だ。JSON/YAML/TOML では足りなくなり、新しい言語が登場し、2026年現在 **CUE・Pkl・KCL がビッグ3** となった。その周囲を Jsonnet・HCL・Nix・Starlark・Dhall が自分の領域で守り、Pulumi 陣営は「TypeScript を使え」と叫ぶ。

本稿は2026年の設定言語マップを描く。各言語がどこから来て、何を解き、どこで失敗し、我々のチームは何を選ぶべきかまで。

第1章 · 2026年の設定言語マップ — 4分類

まずは俯瞰表。

| カテゴリ | 代表言語 | 中心思想 |

| --- | --- | --- |

| データ+制約統合 | CUE, Pkl, KCL | 値とスキーマが同じ言語。型=部分データ |

| 関数型 / ラムダ | Dhall, Jsonnet | 純粋関数でデータを計算 |

| ドメイン特化(IaC) | HCL, Nix | 単一ドメイン(Terraform / NixOS) |

| ビルド決定性 | Starlark | Bazel 用 Python サンドボックス |

| 汎用言語=設定 | Pulumi(TS / Py / Go), CDK | 通常のプログラミング言語で IaC |

| タスクランナー | Mage, Earthfile, Just, Taskfile | Make の代替、タスク定義 |

| クラシックデータ | JSON, YAML, TOML | 単なるシリアライゼーション、抽象化なし |

各カテゴリが解く問題が違うのが本質である。CUE は「YAML が100ファイルに膨らんだ時にどう検証し合成するか」を解き、Pulumi は「なぜ IaC エンジニアは IDE 補完や単体テストを使えないのか」を解き、Starlark は「ビルドはなぜ毎回違う結果になるのか(非決定性)」を解く。1つの言語が全部解くことはできない。

もう一つの軸: **チューリング完全性**。Jsonnet・Dhall・CUE は意図的に非チューリング完全(または弱い形)である。無限ループが書けないので評価は必ず終わる。Pulumi(TS)・Starlark・Pkl はより豊かだが無限ループ可能だ。このトレードオフが「設定にどこまでロジックを入れるか」論争の核心である。

第2章 · 「なぜ JSON/YAML では足りないのか」 — 動機分析

2026年でも「YAML を使え」陣営は強い。彼らの主張はこうだ。

> 「YAML はすべての言語から読める。追加ツールチェーンが要らない。人間が読める。十分」

正論である。小規模プロジェクトは YAML で完結する。だが次の5つの症状が現れると YAML は限界に達する。

**症状1・重複**。環境別の values-dev.yaml / values-stg.yaml / values-prod.yaml に同じキーが95%繰り返される。1箇所修正すると3箇所修正する必要がある。ヒューマンエラーが爆発する。

**症状2・検証不在**。`replicas: "3"`(文字列)が通って k8s が拒否するまで気付かない。JSON Schema や OpenAPI で外部検証はできるが、IDE では即座に捕まらない。

**症状3・合成**。ベース+オーバーレイを合わせなければならない。Helm は Go テンプレート、Kustomize は strategic merge patch、Jsonnet はオブジェクト合成で解く。YAML 自体ではできない。

**症状4・変数**。「この値を5箇所で参照」ができない。YAML アンカー(`&`/`*`)は同一ファイル内のみ。

**症状5・条件/反復**。「環境が prod なら replicas 5、それ以外なら1」が YAML では書けない。結局 Go テンプレート(Helm)や Jinja のようなテキスト置換を被せる。すると**インデント感受性が高い YAML を、インデントを知らないテキストエンジンで生成する**事態になる。これが Helm chart デバッグの90%である。

この5つこそ「設定言語」が登場した理由である。抽象化・検証・合成・変数・ロジックを**言語レベルで**解くのが目的だ。そして2026年、その椅子を巡って CUE・Pkl・KCL が競う。

第3章 · CUE — Marcel van Lohuizen のデータ+制約統合

CUE(Configure, Unify, Execute)はグーグル元エンジニア Marcel van Lohuizen が作った。彼は Go のコア貢献者であり、Protocol Buffers の設計者の一人でもある。彼がグーグルで見たのは**設定ファイルが数億行に膨らんだ時、どう検証し合成するか**という問題だった。CUE はその答えである。

CUE の中心的洞察: **型と値は同じ**。`int` は「全整数の集合」であり、`42` は「42 のみを含む集合」である。両方とも同じ種類のオブジェクト(constraint)だ。2つの constraint を合成する演算が **unification** である。

// スキーマ

#Server: {

name: string

port: int & >0 & <65536

replicas: int | *3 // デフォルト3

env: "dev" | "stg" | "prod"

}

// 値

server: #Server & {

name: "api"

port: 8080

env: "prod"

}

// replicas は明示していないのでデフォルト3

ここで `int & >0 & <65536` は「整数、0より大きく、65536より小さい値の集合」という制約である。`server` に `port: 70000` を入れると unification が失敗し、CUE がエラーを出す。これが**スキーマとデータを同じ言語で書く** CUE の魅力だ。

もう一つの核: **可換性**(commutativity)。`A & B = B & A` である。どの順序で合成しても結果が同じ。Helm の「values 優先順位」のような厄介なルールがない。

2026年の CUE 生態系:

- **Cuelang 公式ツール**: cue eval, cue export, cue vet, cue mod

- **Holos**: CUE ベースの k8s GitOps

- **Dagger CI/CD**: 初期は CUE ベースだったが2024年に Go SDK へ移行

- **kpt + CUE**: Google Cloud の k8s 設定ツール

- **Istio**: 内部設定検証の一部に CUE 採用

CUE の弱点: **学習曲線が急**。unification、disjunction、definitions、hidden fields、optional、default — 概念が多い。「YAML でいいでしょ?」を説得するのに半年かかる。さらに**エラーメッセージが難しい**。unification 失敗時にどこで衝突したかを追うのが大変である。

第4章 · Pkl(Apple, 2024年2月) — Apple のオープンソース設定言語

2024年2月、Apple が突然オープンソース設定言語 Pkl(Pickle, pkl.dev)を公開した。これは衝撃だった。Apple は OSS をほとんどやらない会社で有名だが、「我々が内部で何年も使ってきた設定言語を公開する」と発表したのである。

Pkl の設計哲学:

- **オブジェクト指向**: クラス、モジュール、継承あり。Scala 影響が強い(設計者の一人が Scala 出身)

- **豊かな型システム**: Listable, Mapping, Listing, Class, 制約(Constraints)、null safety

- **多様な出力フォーマット**: pcf(pkl ネイティブ)、JSON、YAML、plist、.properties、XML

- **IDE 統合が強力**: 公式 IntelliJ / VS Code プラグイン、LSP 対応、即時検証

class Server {

name: String

port: Int(this > 0 && this < 65536)

replicas: Int = 3

env: "dev" | "stg" | "prod"

}

api = new Server {

name = "api"

port = 8080

env = "prod"

}

文法は CUE より親しみやすい。Java / Kotlin / Scala 出身なら5分で読める。そして**エラーメッセージが非常に良い**。どこで制約が壊れたかを正確に指す。Apple が内部で何年も磨いた跡が見える。

Pkl の強力機能: **言語バインディング**。Java、Kotlin、Swift、Go、Python に SDK があり、Pkl 設定をその言語のオブジェクトとして直接読める。Spring Boot が application.properties / application.yml を読むのと同じ感覚で application.pkl を読む。これが「なぜ Apple がこれを作ったか」の答え — Swift / Java / Kotlin バックエンドの型安全な設定だ。

2026年の Pkl 採用状況:

- Apple 内部: 広範(公表しないが発表で言及)

- AWS、Booking.com、ING などが評価中と報告

- 韓国では Toss が一部バックエンド設定で Pkl の PoC を発表(2025 SLASH)

- 日本では Sansan、メルカリの一部チームが Java / Kotlin バックエンド設定で使用

弱点: **比較的新しい言語**。2024年公開のため生態系がまだ小さい。Apple 主導のため、開発速度や統治構造が Apple の方針に縛られる。Kubernetes のようなインフラドメインには弱い(YAML / JSON 変換はできるが k8s ツールチェーン統合が弱い)。

第5章 · KCL(Kusion Stack, CNCF Sandbox 2024)

KCL(Kusion Configuration Language)は中国の Ant Group で始まり、2023年に Kusion Stack プロジェクトの一部としてオープンソース化、2024年に CNCF Sandbox 入りした。2026年現在、CNCF Incubation を狙う段階である。

KCL の設計:

- **Python 風文法**: インデント、コロン、親しみやすい

- **静的型付け**: type checking 強力

- **OOP**: クラス、継承、ミックスイン

- **k8s 特化**: KRM(Kubernetes Resource Model)フレンドリー

schema Server:

name: str

port: int

replicas: int = 3

env: "dev" | "stg" | "prod"

check:

port > 0 and port < 65536, "port out of range"

api = Server {

name = "api"

port = 8080

env = "prod"

}

読みやすさはトップ。Python 開発者なら5分で書ける。**エラーメッセージも明確**で、**コンパイラが速い**(Rust + LLVM ベース)。何より **k8s 集中**している — kcl-operator、kclvm-go、KCL-as-Crossplane-composition、KCL-as-Argo-CD-plugin 等、k8s 生態系統合がもっとも活発だ。

2026年の KCL の位置:

- **CNCF Sandbox**(2024年加入)、Incubation 準備中

- **Ant Group、Alibaba** 内部広範使用

- **KubeCon China 2025** で KCL 単独トラック開催

- 韓国企業の一部メガコープ(通信会社)が社内標準として PoC

- 日本ではまだ採用事例少ない

弱点: **k8s 外ドメインでは弱い**。汎用バックエンド設定では Pkl が強く、純粋なデータ+制約では CUE が洗練されている。さらに**中国企業主導という政治変数**で一部欧米企業の採用が遅れる(KCL は100% OSS で CNCF 統治下だが、認知の問題)。

第6章 · Dhall — 関数型、古く、堅い

Dhall(dhall-lang.org)は2017年に Gabriel Gonzalez(Haskell コミュニティの巨匠)が作った関数型設定言語である。2026年基準で最古の「現代設定言語」だ。

Dhall の設計哲学:

- **全域**(total): すべての評価が必ず終わる。無限ループ不可能

- **純粋関数型**: Haskell の影響が非常に強い

- **依存型の一部**: 関数シグネチャに値制約可能

- **インポートが第一級**: URL/ファイルからインポート、ハッシュで整合性検証

let Env = < Dev | Stg | Prod >

let Server =

{ name : Text

, port : Natural

, replicas : Natural

, env : Env

}

let api : Server =

{ name = "api"

, port = 8080

, replicas = 3

, env = Env.Prod

}

in api

Dhall は**信頼の言語**である。URL からインポートしたコードのハッシュを検証できるので、上流が改竄されても即座に検出できる。インポートキャッシュもハッシュベース。これがサプライチェーンセキュリティ時代に再注目されている。

もう一つ: **コンバータ**。Dhall は `dhall-to-yaml`、`dhall-to-json`、`dhall-to-bash`、`dhall-to-nix` などほぼすべてのフォーマットに変換できる。「一度 Dhall で書いて複数の出力を作る」パターンが現実的だ。

2026年の Dhall の位置: **ユーザーは少ないが熱狂的**。主に Haskell / PureScript コミュニティが使い、セキュリティ意識の高い一部チームが GitOps で使う。新規採用は鈍化したが**保守は安定**している。韓国/日本での採用事例はほぼゼロ(少数の関数型プログラマのみ)。

Dhall の弱点: **学習曲線が極めて急**。関数型の概念(monad は無いが fold / 再帰)に慣れていないと厳しい。そして**エコシステムが小さい** — IDE サポートが CUE / Pkl / KCL より弱い。

第7章 · Jsonnet — Google のデータテンプレート + Sjsonnet / Tanka / Grafonnet

Jsonnet(jsonnet.org)は2014年に Google が BCL(Borg Configuration Language)を簡略化して公開したもの。**2026年でも依然として最も広く使われている「JSON 上の抽象化」**言語である。

Jsonnet の設計:

- **JSON の拡張**: すべての JSON は有効な Jsonnet

- **関数、オブジェクト、継承、パッチ**: オブジェクト合成が強力

- **チューリング完全**: 関数型+オブジェクト指向、再帰可能

- **純粋**: 副作用なし、同じ入力→同じ出力

local Server(env) = {

name: "api",

port: 8080,

replicas: if env == "prod" then 5 else 1,

env: env,

};

{

dev: Server("dev"),

prod: Server("prod"),

}

2026年でも Jsonnet 生態系が強い3つの理由:

**1. Tanka(Grafana Labs)**: Jsonnet で k8s を管理するツール。Grafana 自社が全インフラを Tanka で運用していると公開。Helm の代替として最も真剣に使われている。

**2. Grafonnet**: Jsonnet で Grafana ダッシュボードをコードで定義するライブラリ。ダッシュボード数十個を持つチームの標準ツール。

**3. Sjsonnet(Databricks)**: Scala で書き直した Jsonnet インタプリタ。公式 C++ インタプリタより5〜50倍速い。大規模 Jsonnet コードベースでビルド時間を劇的に短縮する。

また: **Bazel + Jsonnet** の組み合わせも人気。Bazel ビルド定義は Starlark だが、生成する設定(k8s manifest 等)は Jsonnet で作るパターン。

2026年の Jsonnet 使用事例:

- **Grafana Labs**: 全社インフラ(数百万行の Jsonnet)

- **Databricks**: クラスタ設定(Sjsonnet を自社開発)

- **Red Hat**: OpenShift 設定の一部

- **カカオ**: 一部インフラチームが Jsonnet で k8s GitOps

- **メルカリ**: 広告プラットフォーム一部で使用と報告

弱点: **型システム無し**。CUE / Pkl / KCL と違って Jsonnet は動的型である。大規模コードベースでリファクタリングが難しい。さらに**エラーメッセージが深いスタックトレース**として現れることが多く、どこが悪いか追いにくい。

第8章 · HCL(HashiCorp) — Terraform の言語

HCL(HashiCorp Configuration Language)は2014年に HashiCorp が作った。2026年現在 **世界でもっとも使われている IaC 言語**である(Terraform が圧倒的)。HCL2 を基準にする。

variable "env" {

type = string

}

resource "kubernetes_deployment" "api" {

metadata {

name = "api"

}

spec {

replicas = var.env == "prod" ? 5 : 1

template {

spec {

container {

name = "api"

image = "myapi:latest"

}

}

}

}

}

HCL の設計:

- **宣言的**: リソース=望ましい状態

- **式表現可**: for、条件、関数呼び出し

- **モジュール**: 再利用単位

- **JSON 互換**: HCL はすべて JSON で表現可能(人間は HCL 形式を好む)

2024年の HashiCorp の IBM 買収とライセンス変更(BSL)以降、**OpenTofu**(Linux Foundation, 2023年 fork)が急成長し、2026年現在 OSS Terraform 代替として定着した。両方とも HCL を使うが、OpenTofu は一部追加機能をより速く導入する(provider-defined functions、state encryption など)。

HCL の強み: **Terraform 生態系そのもの**。すべてのクラウドの provider が HCL で定義され、すべてのモジュールマーケットが HCL である。「Terraform を使うなら HCL を使え」は事実上強制だ。

弱点: **Terraform 外では弱い**。Nomad、Vault、Packer などの HashiCorp ツールも HCL を使うが、それ以外のドメインではほぼ使われない。さらに**チューリング完全ではない**(意図的)ので複雑なロジックが難しい — そのため CDK for Terraform(CDKTF)が出た。

第9章 · Nix Lang + NixOS — 宣言的システムの精髄

Nix は2003年の Eelco Dolstra の博士論文から始まる。2026年現在、Nix Lang は**最も熱狂的なユーザー集団を持つ設定言語**だ。NixOS、nixpkgs、Nix Flakes 生態系がすべて Nix Lang で書かれている。

{ config, pkgs, ... }:

{

services.nginx = {

enable = true;

virtualHosts."example.com" = {

forceSSL = true;

enableACME = true;

locations."/" = {

root = "/var/www";

};

};

};

environment.systemPackages = with pkgs; [

vim

git

htop

];

}

Nix Lang の設計:

- **純粋関数型、遅延評価**: 必要な部分のみ評価

- **再現性**: 同じ入力→同じ出力、ビット単位で

- **不変ストア**: /nix/store に全ビルド結果をハッシュディレクトリで

- **Nix Flakes**: 入力ロック、モジュール化

Nix の魅力は**システム全体をコードで**である。NixOS は OS 全体を Nix 設定で定義する。nix-darwin は macOS 環境をそうする。home-manager はユーザー dotfiles をそうする。

2026年の Nix の位置:

- **Determinate Systems**(Nix 創業者 Eelco が共同創業): エンタープライズ Nix サービス

- **NumTide、Tweag** など Nix コンサル会社が安定

- **Jane Street、Anduril** のような会社が社内標準

- **カカオの一部インフラチーム**が NixOS 実験を公開発表(2025)

- 日本は関数型コミュニティの一部(メルカリ一部エンジニア)が採用

Nix Lang の悪名: **学習曲線が残酷**。「Nix は90%難しくて10%魔法」というジョークがある。エラーメッセージがほとんど役立たず、ドキュメントが散乱し、魔法のような関数が多すぎる。だが一度悟ると**他のどんなシステムも違和感**になると信徒は証言する。

第10章 · Starlark — Bazel の決定論的 Python

Starlark(元 Skylark)は Google が Bazel 用に作った Python の決定論的サブセットである。2020年に仕様が分離されオープン化された。**Bazel、Buck2(Meta)、Tilt、Pants のようなビルドシステムの設定言語**だ。

def deploy_target(name, env, replicas = 3):

return struct(

name = name,

env = env,

replicas = 5 if env == "prod" else replicas,

)

api_prod = deploy_target("api", "prod")

api_dev = deploy_target("api", "dev")

Starlark の設計決定:

- **Python サブセット**: 文法は Python、意味論は違う

- **無限ループ可能だがサンドボックス**: `while True` 可能だが時間・メモリ制限あり

- **副作用なし**: ファイル I/O、ネットワーク、時計アクセス不可

- **凍結可能オブジェクト**: ビルドグラフの決定性保証

- **再帰制限**: 深さ制限で無限再帰防止

中心思想: **ビルドは決定的でなければならない**。同じ入力(ソース+依存)なら同じ出力。そうしてはじめてキャッシュが意味を持ち、分散ビルドが可能になり、セキュリティ監査が成立する。Python をそのまま使うと、インポート時に外部 API を呼んだり、時計を読んだり、環境変数を見て結果が変わる。Starlark はそれを禁じる。

2026年の Starlark の位置:

- **Bazel**(Google、広範): Pinterest、Stripe、Two Sigma、Adobe など

- **Buck2**(Meta、Rust で書き直し、2023年オープンソース化)

- **Tilt**(k8s ローカル開発)

- **Pants**(Python / Java モノレポ)

- 韓国: Toss が一部モノレポに Bazel 導入(Starlark)報告

- 日本: メルカリ・LINE が Bazel 広範使用

Starlark の弱点: **ビルドドメイン外ではほぼ使われない**。「Python に見えるけど何で別?」という参入障壁。そして Bazel 自体の重さ(BUILD ファイル、WORKSPACE、MODULE.bazel)が大きい。

第11章 · TypeScript-as-config(Pulumi) — 汎用言語で設定

Pulumi(2018年創業)は最も挑発的な立場をとる — **「設定言語など要らない。TypeScript / Python / Go / Java を使え」**。Pulumi は通常のプログラミング言語で IaC を書けるツールだ。

const env = process.env.ENV || "dev";

const replicas = env === "prod" ? 5 : 1;

const deployment = new k8s.apps.v1.Deployment("api", {

spec: {

replicas: replicas,

selector: { matchLabels: { app: "api" } },

template: {

metadata: { labels: { app: "api" } },

spec: {

containers: [{

name: "api",

image: "myapi:latest",

}],

},

},

},

});

Pulumi の主張:

- **IDE 補完が無料**: TS の全ツール使用可能

- **単体テスト可能**: Jest で IaC コードをテスト

- **抽象化無限**: 本物のプログラミング言語。ライブラリ、モジュール、継承すべて可能

- **型安全**: provider が自動生成された TS 型を提供

別陣営:

- **AWS CDK**(TypeScript / Python / Java / Go): AWS CloudFormation をコードで

- **CDKTF**: Terraform を汎用言語で

- **CDK8s**: Kubernetes を汎用言語で

- **SST**: AWS フルスタック TS

2026年の Pulumi 採用:

- **Snowflake、BMW、Mercedes**: エンタープライズ標準

- **2023年 Sapphire Ventures C ラウンドで4,100万ドル調達**

- 韓国では Toss・当ジン(Daangn)マーケットが一部導入と報告

- 日本ではメルカリ・SmartHR などが Pulumi / CDK を活用

批判: **汎用言語は強力すぎる**。無限ループ、副作用、非決定性が可能。「昨日 plan したのに今日同じコードが違う結果を出します」事例が発生する。そのため Pulumi は**純粋性ガードレール**(state ロック、preview vs apply)を強化する方向だ。

第12章 · タスクランナー — Mage / Earthfile / Just / Taskfile

設定言語の隣に**タスクランナー言語**がある。Make の後継を狙う4強。

**Mage(Go)**: Go コードでビルドタスクを定義。magefile.go に関数を書けばそれがタスク。

//go:build mage

package main

func Build() error {

return sh.Run("go", "build", "./...")

}

func Test() error {

return sh.Run("go", "test", "./...")

}

Go 開発者に親しい。型安全。だが非 Go プロジェクトには過剰。

**Earthfile(Earthly)**: Dockerfile + Makefile の結合。コンテナ内でビルド段階を定義。

VERSION 0.7

FROM golang:1.21

WORKDIR /app

build:

COPY . .

RUN go build -o myapp .

SAVE ARTIFACT myapp /myapp

docker:

FROM alpine

COPY +build/myapp /myapp

ENTRYPOINT ["/myapp"]

SAVE IMAGE myapp:latest

長所: **再現性**。毎回クリーンなコンテナでビルドして「私のマシンでは動くんですが」が消える。短所: **コンテナビルドのオーバーヘッド**が常にかかる。

**Just(justfile)**: Make の簡略化版。依存グラフより命令エイリアスに近い。

default:

just --list

build:

cargo build --release

test:

cargo test

deploy ENV="dev":

./scripts/deploy.sh {{ENV}}

Just は Rust で書かれ速く、文法がきれいで、cross-shell。小規模プロジェクトに人気。韓国・日本の開発者にも急速に広がっている。

**Taskfile(Task)**: YAML ベースのタスクランナー。Go で書かれている。

version: '3'

tasks:

build:

cmds:

- go build -o myapp .

test:

cmds:

- go test ./...

deploy:

deps: [build, test]

cmds:

- ./scripts/deploy.sh

YAML なので学習負担が少ない。依存関係、変数、watch モードに対応。Make と Just の中間。

2026年のタスクランナー採用は**言語親和度**で分かれる。Go チーム→Mage / Taskfile、Rust チーム→Just、コンテナ優先チーム→Earthfile、伝統派→Make 維持。

第13章 · 「TOML / JSON / YAML を使え」 — 反対意見

設定言語戦争の反対側には強力な保守派がいる。その論理はシンプルだ。

**1. すべての新言語は負債**。チームが学ばねばならず、ツールが不足し、メンテナーが去ればマイグレーション地獄になる。**YAML / JSON / TOML は永遠**だ。

**2. 設定はシンプルであるべき**。設定にロジックが入ればそれはコード。コードはコードリポジトリにあるべき。設定ファイルが if / else / for で埋まれば、それは間違った抽象化のシグナル。

**3. ツールは直交**: 検証は JSON Schema、合成は Kustomize / Helm、変数は環境変数 — 各問題を小さなツールで解け。1つの言語がすべてを解こうとすればその言語が肥大化する。

**4. 学習コスト > 節約効果**: 100人チームが CUE を学ぶのに1人2週間とすれば200週間=4人四半期。その時間でどれだけ機能を出せるか?

この論理は**小チーム、シンプルドメイン**では非常に正しい。だから2026年でも新規マイクロサービスの80%はとりあえず YAML で始める。設定言語は「これは限界」を感じたチームが導入する。

興味深い折衷案:

- **YAML + JSON Schema + 強力な IDE 検証**: 抽象化はないが IDE で即座に捕まる。2026年の VS Code の YAML / JSON 拡張は非常に良くなった。

- **YAML + Kustomize**: 合成をツールレベルで処理。k8s 陣営で依然強力。

- **YAML + cue vet**: CUE を検証専用ツールとして使い、データは YAML で維持。CUE 導入の入口。

第14章 · 韓国/日本 — Toss・カカオ・メルカリの設定運用

韓国/日本企業の設定言語採用状況を整理する(公開カンファレンス発表+ブログベース)。

**Toss**: バックエンドマイクロサービス1,000個以上運用。基本設定は application.yml(Spring Boot 慣行)+ Spring Cloud Config Server。一部決済・バンキングバックエンドが **Pkl の PoC** を発表(2025 SLASH カンファレンス)。インフラは Terraform(HCL)+ 一部 Pulumi(TS)。モノレポ一部に Bazel(Starlark)導入。

**カカオ**: マルチクラウド環境。**Jsonnet + Tanka で一部インフラの GitOps** 運用(2025 if(kakao) 発表)。**NixOS 実験**も一部インフラチームが公開。Terraform(HCL)+ ArgoCD ApplicationSet(YAML)の組み合わせが標準。

**ネイバー**: 社内標準は YAML + Helm + Kustomize。ClovaX 等の AI インフラ一部で Pulumi 導入発表。nGrinder のようなツールの設定は依然 properties + YAML。

**LINE**: グローバルメッセンジャーインフラ。Bazel 広範使用(Starlark)。一部チームが Jsonnet 導入。メイン IaC は Terraform(HCL)。

**メルカリ**: マイクロサービス200個+。広告・検索の一部で Jsonnet 使用報告。一部 Java / Kotlin バックエンドが **Pkl 評価中**。Terraform(HCL)+ Helm(YAML)標準。

**Sansan、SmartHR、Cybozu** 等の日本 SaaS: 概して YAML + Helm + Terraform の保守的な組み合わせ。一部が Pulumi / CDK を導入。

共通パターン: **ハイブリッド**。1つの言語がすべてを征服しない。IaC は HCL、ビルドは Starlark / Make、k8s は YAML + Kustomize / Helm、バックエンド設定は YAML / Pkl。チームが大きいほど標準が複数になる。

第15章 · 誰が何を選ぶべきか — 意思決定ガイド

最後に、我々のチームが何を選ぶべきかについての実用ガイド。

**Case 1 · k8s YAML が1,000行超え、環境5つ**

- 最速ルート: **Kustomize**。YAML 維持、ツール追加のみ。学習1日。

- 次段階: **Helm**。テンプレートあり。学習1週間。

- 本格的: **CUE** または **KCL**。データ+検証統合。学習1ヶ月。

- 判断基準: 環境がシンプル(3個以下)なら Kustomize、複雑(10個+リージョン・環境組み合わせ)なら CUE / KCL。

**Case 2 · マルチクラウド IaC、チームが TS に習熟**

- 正解: **Pulumi(TypeScript)** または **CDK**。IDE 補完、単体テスト、モジュール化。

- 代替: Terraform(HCL)+ CDKTF。HCL ベースだが TS で書く。

- 避けるべき: HCL を知らないチームが無理に Terraform 導入。

**Case 3 · モノレポビルド、100パッケージ**

- 正解: **Bazel + Starlark** または **Buck2 + Starlark**。決定論的ビルド、キャッシュ。

- 代替: **Pants**(Python 中心)、**Nx**(JS / TS 中心)。

- 避けるべき: Make で依存グラフを手作業管理。

**Case 4 · Spring Boot バックエンド、application.yml が長すぎる**

- 正解: **Pkl**。Java / Kotlin SDK 強力、型安全。

- 代替: ただ YAML + Spring Cloud Config + 環境別プロファイル。

- 学習コスト1週間。

**Case 5 · NixOS マニアック、システム全体再現性**

- 正解: **Nix Lang**。他の選択肢無し。

- 警告: 学習1ヶ月〜半年。チーム合意必須。

**Case 6 · ただの GitHub Actions / Docker Compose**

- 正解: **YAML 維持**。設定言語導入の ROI が出ない。

- 補助: JSON Schema 検証追加、IDE で即座に捕まえる。

**Case 7 · シンプル CLI ツール設定**

- 正解: **TOML**。Rust 陣営の事実上の標準。人間が読みやすい。

- 代替: JSON(JS 親和)、YAML(Python 親和)。

**Case 8 · Grafana ダッシュボード数十個**

- 正解: **Grafonnet(Jsonnet)**。ダッシュボード=コード。

- 代替: Terraform Grafana provider。

**原則**: 小さく始めよ。1つの言語ですべてを征服しようとするな。**ハイブリッドが正常**である。

第16章 · 参考文献 / References

中核仕様とドキュメント:

- CUE 公式サイト — https://cuelang.org

- Pkl 公式サイト(Apple) — https://pkl-lang.org

- KCL 公式サイト(Kusion Stack) — https://kcl-lang.io

- Dhall 公式サイト — https://dhall-lang.org

- Jsonnet 公式サイト — https://jsonnet.org

- HashiCorp HCL — https://github.com/hashicorp/hcl

- Nix 公式 — https://nixos.org

- Starlark 仕様 — https://github.com/bazelbuild/starlark

- Pulumi — https://www.pulumi.com

タスクランナー:

- Mage — https://magefile.org

- Earthly Earthfile — https://earthly.dev

- Just — https://just.systems

- Task(Taskfile) — https://taskfile.dev

エコシステム / ツール:

- Tanka(Grafana Labs) — https://tanka.dev

- Grafonnet — https://github.com/grafana/grafonnet

- Sjsonnet(Databricks) — https://github.com/databricks/sjsonnet

- OpenTofu — https://opentofu.org

- Determinate Systems(Nix) — https://determinate.systems

- Buck2(Meta) — https://buck2.build

- CDK for Terraform — https://developer.hashicorp.com/terraform/cdktf

- AWS CDK — https://aws.amazon.com/cdk/

CNCF と標準:

- KCL CNCF Sandbox — https://www.cncf.io/projects/kcl

- Crossplane Composition with KCL — https://docs.crossplane.io

- Argo CD KCL Plugin — https://github.com/argoproj/argo-cd

韓国/日本カンファレンス事例:

- SLASH 2025(Toss) — https://toss.tech/slash25

- if(kakao) 2025 — https://if.kakao.com

- KubeCon China 2025(KCL track) — https://www.cncf.io

- Mercari Engineering Blog — https://engineering.mercari.com

背景/インタビュー:

- Marcel van Lohuizen on CUE — https://cuelang.org/docs/introduction

- Apple Pkl 発表(2024.2) — https://pkl-lang.org/blog

- KCL CNCF Sandbox 発表 — https://www.cncf.io/blog/kcl

- Eelco Dolstra(Nix 創業者)インタビュー多数

議論/批判:

- 「YAML を使え」陣営 — https://hn.algolia.com で検索

- 「Configuration languages comparison」 — 多様なブログ記事

- Pulumi vs Terraform 論争 — https://www.pulumi.com/blog

本稿は2026年5月時点の情報であり、設定言語生態系は急速に進化する。特に Pkl(Apple)と KCL(CNCF)の採用率は四半期ごとに変わる。導入前に最新状況の確認を推奨する。