Zeroとは？AIエージェント向けプログラミング言語の入門

「読み手」を起点に設計された言語

ほとんどのプログラミング言語は、人間のために設計されています。文法は人間が気にすることに最適化されていて、簡潔な構文、表現力のあるイディオム、「エレガント」なショートカットなどがそうです。コンパイラーがエラーメッセージを散文で出力するのも、読み手が人間だからです。標準ライブラリは、ライブラリ作者にとって覚えやすい構成になっています。

Zero は別の前提から出発します。主な読み手は AI エージェント、つまり誰かの代わりにコードを書き、デバッグし、修復する言語モデルです。もちろん人間も関わり続けますが、言語設計の上では、初日からエージェントを第一級のユーザーとして扱う、という思想です。この一点を変えるだけで、言語の見える機能のほぼすべてに影響が及びます。

Zero は Vercel Labs によって作られ、zerolang.ai で公開されています。ソースは github.com/vercel-labs/zero にあり、ファイル拡張子は .0 です。

pub fun main(world: World) -> Void raises {
    check world.out.write("hello from zero\n")
}

このスニペットに登場する 5 つのもの——pub、World、raises、check、そして明示的な world.out.write——から、Zero の発想がすでに見えてきます。以降で順に解きほぐしていきましょう。

「すべては明示的に」

Zero のドキュメントには、非公式のスローガンとして「すべては明示的に」というフレーズが繰り返し登場します。人間にとっては便利でも、コードジェネレーターにとっては危険な「隠れた仕掛け」を、この言語は意図的に避けています。

• 必須のガベージコレクターがない。
• 隠れたアロケーターがない。
• 暗黙の async ランタイムがない。
• 魔法のグローバルがない——アンビエントな stdout も process.env も、暗黙のファイルシステムもない。

関数が外の世界に触れる動作は、すべてシグネチャに現れる必要があります。人間にはタイプ量が多く感じられますが、関数が実際に何をするかを推論するエージェントにとっては、ありがたい設計です。

グローバルではなく「ケイパビリティ」

I/O の扱いは、この哲学を最もはっきり示す部分です。グローバルな print 関数は存在しません。出力は、ランタイムが main に渡す World という値を通じて行います。

pub fun main(world: World) -> Void raises {
    check world.out.write("hello\n")
}

コールスタックの深い場所にある関数がログ行を書きたいなら、World（あるいはより狭いケイパビリティ）を明示的に受け取る必要があります。関数のシグネチャを読むだけで、本文を読まずに、その関数がネットワーク・ファイルシステム・標準出力に触れる可能性があるかどうかを判断できます。これは静的解析器（あるいはコードレビューをするエージェント）が頼りにできる性質です。

詳しくは World ケイパビリティ を参照してください。

raises と check で失敗を明示する

失敗しうる関数は、その旨を宣言します。失敗しうる関数を呼ぶ側は、それを認識します。サイレントスローはありません。

fun validate(ok: Bool) -> i32 raises { InvalidInput } {
    if ok == false {
        raise InvalidInput
    }
    return 42
}

pub fun main(world: World) -> Void raises {
    check validate(true)
    check world.out.write("ok\n")
}

validate の raises { InvalidInput } は「この関数は InvalidInput で失敗しうる」という意味です。呼び出し側の check は「失敗したら、そのエラーを上に伝播させる」という意味になります。エラーをうっかり「床に落とす」ことはできません——シグネチャに現れるか、コンパイラーが止めるかのどちらかです。詳しくは Raises と Check を参照してください。

エージェントに語りかけるコンパイラー

Zero の最も特徴的な部分は、構文機能ではなく、コンパイラーの出力です。壊れたプログラムに対して zero check --json を実行すると、次のような出力が返ってきます。

{
    "ok": false,
    "diagnostics": [
        {
            "code": "NAM003",
            "message": "unknown identifier",
            "line": 3,
            "repair": { "id": "declare-missing-symbol" }
        }
    ]
}

通常のコンパイラーエラーと違うポイントが 3 つあります。

1. 安定したエラーコード。 NAM003 は今日「未知の識別子」を意味し、次のコンパイラーバージョンでも全く同じ意味のままです。エージェントは英語を解釈せずにコード値でパターンマッチできます。
2. 構造化された修復メタデータ。 repair フィールドは、コンパイラーがそのエラーを解消できると考える修正の 種類 を示します。エージェントは zero fix --plan --json でプランを取得し、それを適用できます。
3. 散文をパースする必要がない。 次に何をすべきかを判断するために、人間向けのメッセージを解釈する必要がない——それが本来の狙いです。

詳しくは JSON 診断 で形式を細かく見ていきます。

意図的に小さい表面積

Zero の文法は小さく規則的で、Scala やモダンな C++ のような「なんでも詰め込み型」の言語よりも、初期の C に近い思想です。理由は実利的で、エージェントがセッション中に言語の全体を頭に入れて、エッジケースで誤射しないようにするためです。

そのため次のような特徴があります。

• 関数を宣言する方法は 1 つ（fun または pub fun）。
• ローカル値を束縛する方法は 1 つ（let）。
• 直積型を表現する方法は 1 つ（shape）、直和型は 1 つ（choice）、ラベルだけの列挙は 1 つ（enum）。
• パターンマッチの構文は 1 つ（match）。
• 初期の言語におけるループは 1 つ（while）。

少なくとも現段階では、演算子オーバーロード、暗黙の変換、マクロ、デコレーター、同じことを表現する 3 つの競合構文などは見当たりません。これは禁欲主義ではなく、エージェントが間違ったバリアントを選びにくいよう、表面積を意図的に小さく保つための選択です。

Zero が「ではない」もの

期待値を合わせておきましょう。

• スクリプト言語ではない。 Zero はネイティブバイナリにコンパイルされます。プログラムは小さく（ドキュメントでは 10KB 未満の実行ファイルにも言及があります）、ランタイムを引きずりません。
• Rust でも Go でも Zig でもない。 構文には共通の祖先がありますが、優先順位が違います。Rust が洗練された型システムでメモリ安全性を最適化するのに対し、Zero は意図的に小さな型システムでエージェントの学習しやすさを最適化します。
• 安定していない。 Zero は pre-1.0 です。チームはエージェント・ファーストの目標を進めるためなら破壊的変更も入れると明言しています。本気の用途で頼ってはいけません。
• Vercel のデプロイ機能ではない。 Vercel Labs 発ではありますが、Zero は Next.js や Vercel ホスティングと結びついた機能ではなく、独立したシステム言語です。

どんな時に Zero を試す価値があるか

次のような関心がある人には、今 Zero を触ってみる価値があります。

• 設計上の制約が「人間」ではなく「エージェント」から来ると、言語はどう変わるのか。
• 研究言語に手を出さずに、ケイパビリティベースの I/O を試してみたい。
• 「構造化されたコンパイラー出力」が、後付けではなく第一級の機能だったらどう見えるのかを知りたい。
• 進化中のプロジェクトに対して Vercel Labs にフィードバックを送りたい。

逆に、安定した言語で実務をこなしたい、成熟したライブラリエコシステムが欲しい、Rust や Go レベルのクロスプラットフォームツールが必要、という場合は、今は見送るのが無難です。

次回: Zero をインストールする

次のドキュメントでは、Zero のツールチェーンをインストールして、最初のプログラムをコンパイルするまでを案内します。最初から最後まで 1 分程度です。