Skip to content
Published on

2026年のシステム言語とパッケージマネージャ - Zig, C++26, Carbon, Mojo, Swiftサーバ, Kotlin, C# .NET 9, uv, pnpm, Bun徹底解説

Authors

2026年のシステム言語エコシステムは転換点を迎えました。Zig 0.14は増分コンパイルと新しいビルドシステムを安定化させ、C++26はP2900 contractsとP2300 std::executionを標準に取り込み、Mojo 1.xはMLIRを基盤としたPythonスーパーセットとしてGPUカーネル記述まで一つの言語でこなせる段階に達しました。Swiftはvapor 4とHummingbird 2を通じてLinuxサーバ言語として地位を確立し、KotlinはKtor 3とGraalVMネイティブイメージでサーバランタイムを軽量化しました。C# 13/.NET 9はネイティブAOTとプライマリコンストラクタでコンテナ親和性を高めています。パッケージマネージャも同様に、uvがpipやPoetryを事実上置き換え、pnpm 10とBunがnpm生態系を二分しはじめています。

システム言語マップを俯瞰する

2026年5月時点で主流と次世代のシステム言語を単純化するとこうなります。C/C++はOSカーネル、ゲームエンジン、データベースで依然として主役ですが、Rust、Zig、Carbon、Mojoが領域ごとに浸透しています。JVM陣営ではKotlinがSpringとKtorの両方でJavaを置き換え、Scala 3とClojure 1.13はデータや金融領域で生き残っています。.NET 9はクラウドネイティブワークロードでGoに匹敵する起動時間とメモリ使用量を達成しました。

Zig 0.14 - 増分コンパイルとビルドシステム

Zig 0.14は増分コンパイル(incremental compilation)をベータから安定段階に引き上げ、asyncモデルを再設計し、build.zigビルドシステムにパッケージマネージャ(zig fetch)を統合しました。comptimeは依然としてZigの核となる特徴です。

const std = @import("std");

pub fn main() !void {
    var gpa = std.heap.GeneralPurposeAllocator(.{}){};
    defer _ = gpa.deinit();
    const allocator = gpa.allocator();

    var list = std.ArrayList(u32).init(allocator);
    defer list.deinit();

    try list.appendSlice(&[_]u32{ 1, 2, 3, 4, 5 });

    var sum: u64 = 0;
    for (list.items) |x| sum += x;

    std.debug.print("sum = {d}\n", .{sum});
}

comptimeジェネリクスはマクロなしで安全な抽象を実現します。comptimeキーワードはコンパイル時に評価されるコードを表し、型そのものを第一級の値として扱えます。

C++26 - contractsとstd::execution

C++26はISO標準にP2900 contracts(事前/事後条件、アサーション)とP2300 sender/receiver(std::execution)を取り込みました。さらに静的リフレクションの一部も含まれ、コンパイル時メタプログラミングが飛躍的に容易になりました。

#include <execution>
#include <expected>
#include <print>

std::expected<int, std::string> parse_port(std::string_view s) {
    int port = 0;
    auto [ptr, ec] = std::from_chars(s.data(), s.data() + s.size(), port);
    if (ec != std::errc{}) return std::unexpected("invalid number");
    if (port < 1 || port > 65535) return std::unexpected("out of range");
    return port;
}

int main() {
    auto result = parse_port("8080")
        .transform([](int p) { return p + 1000; });
    if (result) std::println("port = {}", *result);
    else std::println("error: {}", result.error());
}

C++23で導入されたstd::expected<T, E>std::printはLLVM/Clang、GCC 14+、MSVC 2024+で既に安定しており、deducing this(Self)はCRTPパターンを簡素化しました。

Carbon - Googleの「C++後継」実験

Carbonは2026年現在も実験段階(experimental)で、0.x系列でツールチェーンが部分的に動作します。狙いは既存C++コードとの双方向相互運用を維持しつつ、より安全でモダンな構文を提供することです。Rustとは異なりborrow checkerを採用せず、ジェネリクス、インターフェース、ADTといった現代的な機能に焦点を当てています。

package Sample api;

fn Fibonacci(n: i32) -> i32 {
  if (n < 2) { return n; }
  return Fibonacci(n - 1) + Fibonacci(n - 2);
}

fn Main() -> i32 {
  Core.Print("fib(10) = {0}", Fibonacci(10));
  return 0;
}

現状のCarbonは大規模な採用というより、「C++の進化の方向性」を示す青写真に近い位置付けです。

Mojo 1.x - PythonスーパーセットとMLIR

ModularのMojoは2026年に1.x正式版を投入し、Pythonスーパーセット互換性をさらに広げました。MLIR(多段中間表現)上に構築され、CPU SIMDとGPUカーネルを同じ言語で記述できる点が差別化要素です。

from tensor import Tensor

fn dot_product(a: Tensor[DType.float32], b: Tensor[DType.float32]) -> Float32:
    var acc: Float32 = 0.0
    for i in range(a.num_elements()):
        acc += a[i] * b[i]
    return acc

fn main():
    var x = Tensor[DType.float32](1024)
    var y = Tensor[DType.float32](1024)
    print(dot_product(x, y))

Mojoは既存のPythonコードをそのままimportでき、fnで定義した関数は静的型とSIMD最適化を自動で受けられます。

Swift 6サーバ - Vapor 4とHummingbird 2

Swift 6は厳密なconcurrencyをデフォルトで強制し、Linuxビルドと静的リンクが格段に安定しました。Vapor 4とHummingbird 2はいずれもSwiftNIOベースのHTTPサーバフレームワークです。

import Vapor

let app = try Application(.detect())
defer { app.shutdown() }

app.get("hello", ":name") { req async throws -> String in
    let name = req.parameters.get("name") ?? "world"
    return "Hello, \(name)!"
}

try await app.execute()

Mercariは一部バックエンドをSwiftサーバで運用していることが知られており、Appleはswift.org/serverワーキンググループを通じて標準ライブラリやSwiftPMの整備を進めています。

Kotlinサーバ - Ktor 3とSpring Boot 3 native

Kotlin 2.1はK2コンパイラをデフォルトとし、マルチプラットフォームの安定性を強化しました。Ktor 3はコルーチンベースの軽量HTTPサーバを提供し、Spring Boot 3はGraalVM Native Imageでビルドすると50MB未満の静的バイナリを生成できます。

import io.ktor.server.application.*
import io.ktor.server.engine.*
import io.ktor.server.netty.*
import io.ktor.server.response.*
import io.ktor.server.routing.*

fun main() {
    embeddedServer(Netty, port = 8080) {
        routing {
            get("/health") { call.respondText("ok") }
            get("/users/{id}") {
                val id = call.parameters["id"] ?: "0"
                call.respondText("user $id")
            }
        }
    }.start(wait = true)
}

TossはSpring Boot + Kotlinをメインバックエンドスタックとし、CoupangはJavaからKotlinへ段階的に移行しています。LINEヤフーもメッセージングや広告サーバにKotlinを積極導入しました。

C# 13 / .NET 9 - ネイティブAOTとプライマリコンストラクタ

.NET 9はネイティブAOTをprod-ready水準に引き上げ、プライマリコンストラクタやコレクション式が定着しました。ASP.NET Core minimal APIはSpringより軽量な起動時間を実現します。

var builder = WebApplication.CreateSlimBuilder(args);
builder.Services.AddAuthorization();

var app = builder.Build();
app.MapGet("/health", () => Results.Ok(new { status = "ok" }));
app.MapGet("/users/{id:int}", (int id) =>
    Results.Ok(new { id, name = $"user{id}" }));

app.Run();

CreateSlimBuilderはリフレクションを抑えてAOTコンパイルに適しており、PublishAot=trueでビルドすると10MB前後の単一実行ファイルが得られます。

JVM言語エコシステム - Scala 3、Clojure 1.13、Groovy 4

Scala 3はインデントベース構文とユニオン型を定着させ、Akkaのライセンス変更後はPekkoが事実上の後継となりました。Clojure 1.13はdeps.ednとtools.buildでビルド体験を改善し、REPL中心のワークフローは依然として強力です。Groovy 4はGradle DSLという居場所のおかげで命脈を保っていますが、新規採用はほぼありません。

Crystal, Nim, V - 小規模なコンパイル言語

Crystal 1.13はRubyとほぼ同じ構文に静的型とLLVMバックエンドを組み合わせます。Nim 2.xはPython風構文にARC/ORC GCとメタプログラミングを足した言語です。V(Vlang)は高速なコンパイルとシンプルさを掲げますが、エコシステムはまだ小規模です。いずれも小さなCLIツールや組み込みサービスで実用的です。

Bazel 8、Buck2、Pants - モノレポビルドシステム

Bazel 8はbzlmodをデフォルトとし、外部依存関係管理を単純化しました。Buck2はMetaがRustで書き直したビルドシステムで、リモート実行性能に優れます。Pants 2.20はPython/Java/Goを幅広くサポートし、デジタル広告や金融業界で人気があります。

# BUILD file (Bazel)
load("@rules_rust//rust:defs.bzl", "rust_binary", "rust_library")

rust_library(
    name = "core",
    srcs = glob(["src/lib.rs", "src/**/*.rs"]),
    edition = "2024",
)

rust_binary(
    name = "server",
    srcs = ["src/main.rs"],
    deps = [":core"],
    edition = "2024",
)

Gradle 9とMill - JVMビルドの二系統

Gradle 9はKotlin DSLを推奨構文として明示し、configuration cacheを安定化させました。MillはScala製の新しいJVMビルドツールで、Bazel風のtask graphとMaven互換性を組み合わせます。

plugins {
    kotlin("jvm") version "2.1.0"
    application
}

repositories { mavenCentral() }

dependencies {
    implementation("io.ktor:ktor-server-core:3.0.0")
    implementation("io.ktor:ktor-server-netty:3.0.0")
    testImplementation(kotlin("test"))
}

application {
    mainClass.set("com.example.MainKt")
}

uv - Pythonパッケージマネージャの新標準

Astralのuvは Rustで書かれ、pip、pip-tools、Poetry、virtualenvを一つに統合します。2026年には新規Pythonプロジェクトの事実上のデフォルトとなりました。依存解決速度はpip比で10-100倍速く、単一の静的バイナリで配布されます。

[project]
name = "my-app"
version = "0.1.0"
requires-python = ">=3.12"
dependencies = [
    "fastapi>=0.115",
    "pydantic>=2.9",
    "httpx>=0.27",
]

[dependency-groups]
dev = [
    "pytest>=8.3",
    "ruff>=0.7",
    "mypy>=1.13",
]

[tool.uv]
managed = true

Poetryからuvへの移行では、poetry exportでrequirements.txtを生成してからuv addで移し替えるパターンが一般的です。

pnpm 10、Yarn 5(Berry)、Bun - npmエコシステムの分岐

pnpm 10はディスク効率の良いcontent-addressable storeとワークスペース機能でモノレポの事実上の標準になりました。Bunは独自のパッケージマネージャ(bun install)、バンドラ、ランタイムを一つのバイナリに収めます。Yarn 5(Berry)はPlug'n'Playでnode_modules自体を排除する方向を維持しています。

# pnpm-workspace.yaml
packages:
  - 'apps/*'
  - 'packages/*'
catalog:
  react: ^19.0.0
  typescript: ^5.7.0

インストール速度のベンチマークは一般にBun > pnpm > Yarn Berry > npmの順ですが、モノレポ規模やキャッシュ状態によって変動します。

Bun 1.x - JavaScriptランタイム統合

Bun 1.xはNode互換性を確保しつつ、bun installbun testbun buildbun runを単一バイナリで提供します。esbuild比でバンドル速度が速く、TypeScriptとJSXをネイティブで実行します。

# 新規プロジェクト作成
bun init -y

# 依存追加
bun add hono zod
bun add -d @types/node

# サーバ実行
bun --hot src/server.ts

# 単一実行ファイル生成
bun build --compile --target=bun-linux-x64 src/server.ts --outfile server

Pixi - 多言語科学計算パッケージマネージャ

Prefix.devのPixiはConda生態系を基盤としつつ、Cargoスタイルのlockファイルとタスクランナーを提供します。Python、R、C++、CUDAの依存を一つのmanifestにまとめられるため、ML/科学計算で急速に普及しています。

[project]
name = "ml-experiment"
channels = ["conda-forge", "pytorch", "nvidia"]
platforms = ["linux-64", "osx-arm64"]

[dependencies]
python = ">=3.12,<3.13"
pytorch = ">=2.5"
numpy = ">=2.0"

[tasks]
train = "python train.py"
eval = "python eval.py --checkpoint=last"

NixとNix Flakes - 再現可能なビルド

Nixは関数型パッケージマネージャで、依存とビルドをハッシュベースで固定します。Flakesは入力と出力を明示的に宣言するモダンなインターフェースです。

{
  description = "Polyglot dev shell";
  inputs.nixpkgs.url = "github:NixOS/nixpkgs/nixos-unstable";
  outputs = { self, nixpkgs }:
  let
    system = "x86_64-linux";
    pkgs = import nixpkgs { inherit system; };
  in {
    devShells.${system}.default = pkgs.mkShell {
      packages = with pkgs; [ zig rustup nodejs_22 bun uv go_1_23 ];
    };
  };
}

NixOSは依然として学習コストが高いですが、単一のnix developでチーム全員が同一の環境を持てる価値は大きいです。

Conan、vcpkg - C/C++パッケージマネージャ

Conan 2.xとMicrosoftのvcpkgはC/C++依存管理の二大柱です。ConanはプロファイルベースのABI追跡が緻密で、vcpkgはmanifest modeとCMake統合が自然です。いずれも1,000以上のよく知られたライブラリをパッケージ化しています。

SpackとHPC

Spackは高性能計算(HPC)分野で、BLASやMPIといったライブラリを複数コンパイラ/MPI実装の組み合わせでビルドする必要がある場面で標準のツールです。米国国立研究所やスーパーコンピュータサイトで広く使われています。

go mod、Cargo、Mix、opam、Hex - 言語ごとの標準ツール

Goのgo mod、RustのCargo、ElixirのMix、OCamlのopam、Erlang/ElixirのHexは、各言語の事実上の標準ツールとして定着しています。いずれもlockファイル、ワークスペース、ビルドキャッシュを標準でサポートします。

Maven、Gradle、sbt - JVMパッケージ管理

Mavenは依然としてJavaエコシステムで最も保守的な選択で、GradleはAndroidとKotlin陣営のデフォルト、sbtはScala陣営で生き残っています。新規Javaプロジェクトでも、MavenよりGradle Kotlin DSLを採用する比率が増えました。

brew、Linuxbrew - 開発マシン用パッケージ

macOSではHomebrew(brew)が管理者権限なしの依存インストールの事実上の標準で、LinuxではLinuxbrewがNix、asdf、miseと競合します。多くのバックエンド開発者はbrewで言語ランタイムを入れ、プロジェクト単位でuv/pnpm/cargoで依存を固定しています。

韓国企業の採用状況

Naverは一部のインフラツールでZigを実験的に採用しており、CoupangはKotlin比率を高めJava + Spring BootからKotlin + Spring Bootへ徐々に移行しています。Tossは最初からKotlin + Springをメインに据え、KakaoはGoとKotlinを併用します。Naverはswift.org/serverに一部貢献しつつSwiftサーバ実験を進めていると報じられています。

日本企業の採用状況

Mercariは一部バックエンドをSwift on Linuxで運用し、Appleと協力してswift-nioに貢献しています。CyberAgentはML推論パイプラインの一部をMojoで試しています。LINEヤフーは広告プラットフォームやメッセージングサーバにKotlinを積極採用し、DeNAやSmartNewsもKotlin/JVM比率が高い構成です。

速度比較 - uv vs pip、pnpm vs npm、Bun vs esbuild

ベンチマークはマシンやキャッシュ状態に左右されますが、全体傾向は一貫しています。uvのコールドインストールはpip比で10-100倍速く、pnpmのモノレポインストールはnpm比で2-5倍速く、Bun bundleはesbuildより速いケースが多いものの、プラグイン互換性に差があります。最も簡単な計測は、同じキャッシュ状態でtime uv pip installtime pip installを比較することです。

どの言語とマネージャを選ぶか

OSカーネル、ゲームエンジン、HFTのようにサイクル単位で最適化が必要なら、依然としてC++26とRustが選択肢です。ML推論とGPUカーネルなら、MojoとCUDA C++を併用するのが妥当です。サーババックエンドではKotlin/Ktor、Go、Swiftサーバ、.NET 9 minimal APIのいずれも合理的です。小さなCLIや単純なデーモンならZig、Nim、Crystalが魅力的です。パッケージマネージャは言語ごとの標準(Cargo、go mod、uv、pnpm)に従いつつ、モノレポではBazel/Buck2、多言語科学計算ではPixi/Nixを使うパターンが定着しています。

まとめ - 2026年のシステム言語とマネージャの風景

2026年はどれか一つの言語が他を駆逐する年ではなく、領域ごとに最適なツールが明確になった年です。C++26とRustがシステムコアを守り、Zigが比較的単純なシステムコードを引き受け、MojoがML加速、SwiftとKotlinがサーバ、.NET 9がクラウドバックエンドを担います。パッケージマネージャはCargoの単純さと厳密さが他言語にも波及し、uv、Bun、pnpmのように高速かつ決定論的なツールが標準となりつつあります。多言語モノレポではBazel/Buck2/Pantsと、Pixi/Nixが共存して再現可能なビルドを支えています。

References