設定言語 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 を書けるツールだ。

import * as k8s from "@pulumi/kubernetes";

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

import "github.com/magefile/mage/sh"

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)の採用率は四半期ごとに変わる。導入前に最新状況の確認を推奨する。