2026 年の Raku — 20 年前に始まった言語が、いま土台を入れ替えている

この記事の事実確認は 2026 年 9 月 18 日時点。 最終話は「現在」を扱うので、最も速く古くなる。 版・スケジュール・状況は rakudo.org と Rakudo Weekly News で確認してほしい。 この注記自体が、この回の主題の一部である。

土台を入れ替えている最中

2026 年、Raku で最も大きな出来事は新機能ではない。コンパイラの土台の入れ替えである。

名前は RakuAST。

Rakudo のコンパイラの、構文解析からコード生成までの前段を作り直したもので、 新しい grammar を持ち、Raku のプログラムを明示的な AST（抽象構文木）として表す層を持つ。

従来の Rakudo は、パース中にコンパイラの中間表現を直接組み立てていた。 RakuAST はその間に一段挟む。

⚠️ 呼び方が揺れる。 公式アナウンスでも「新しい backend」と書かれることがあるが、 機能的にはコンパイラのフロントエンドの刷新である。 記事で書くときは「新しいコンパイラ基盤」のように役割で書くのが安全だ。

なぜ作ったのか

Jonathan Worthington が 2020 年に着手した。The Perl Foundation の支援を受けた助成プロジェクトである。

第 6 話と第 11 話に出てきた名前だ。6model を作り、MoarVM を作り、Cro を作った人物である。 Raku の技術基盤は、かなりの部分がこの人の仕事で説明できる。

動機はこうだった。

• 中間表現が暗黙的で、最適化を入れる場所が無かった
• 構文木をオブジェクトとして扱えないため、マクロや構文の内省が実装できない
• コンパイラの構造が理解しにくく、貢献の障壁になっていた

つまり「速くする」より先に、「手を入れられる形にする」ための工事である。

ここに、連載を通じて言いたかったことの 1 つがある。

最適化を入れる前に、最適化を入れる場所を作る工事が要ることがある。

そしてその工事に 6 年かかった。成果物が「前と同じように動く」ことを目標とする 6 年である。 第 8 話で書いた「15 年」と同じ種類の時間だ。外から見て進捗が見えにくい。

2026 年のスケジュール

時期	内容
2026.09（9 月 26 日予定）	RakuAST が既定になる。旧基盤は RAKUDO_LEGACY=1 で使える
6.e リリース時（2026 年内予定）	旧基盤を完全に削除

段階の切り方に見覚えがあるはずだ。第 10 話の Path-to-Raku.md と同じ型である。

既定を切り替える → 旧を環境変数で残す → 版の区切りで削除。

互換性を切って 15 年を失った経験は、このコミュニティに破壊的変更の作法として残っている。

何が変わり、何が変わらないか

変わらない — 利用者から見た Raku の言語仕様は変わらない。 既存のコードはそのまま動くことが目標で、エコシステムのモジュールに対する大規模なテストが行われている。

変わる — slang（文法拡張）は手直しが要る。 第 11 話で書いたとおり、Raku はユーザが文法を拡張できる。 その文法の構造が変わるため、旧 grammar に依存した拡張はそのままでは動かない。

文法を開くと決めた言語は、文法を変えるときに二重のコストを払う。 第 11 話の最後に書いた代償が、いま実際に請求されている。

マクロについて — ここは間違えやすい

RakuAST はマクロ実装の前提となる基盤である。 しかし マクロは 6.e には入らない（2026 年 9 月時点の見通し）。

「RakuAST が来るからマクロが使える」と書くと誤りになる。 正確には 「マクロを実装できる土台ができた。マクロ自体はこれから」。

2026 年の Raku を、正確に書く

この連載の書き方の規則 2 条にこう書いた。

「盛り上がっている」とも「終わっている」とも書かない。どちらも評価であって事実ではない。

では事実は何か。表にする。

項目	2026 年 9 月時点の状態
言語バージョン	6.d が既定。6.e は年内予定、未リリース
処理系	Rakudo。2026.08 が Release #196
コンパイラ基盤	2026.09 で RakuAST が既定に
VM	MoarVM が事実上唯一
実装の数	3。Rakudo に加え、2026 年に mutsu（Rust）と Raku++（C++17）が現れた
ガバナンス	Raku Steering Council
エコシステム	zef（fez / rea）、raku.land。規模は小さいが継続
専用 IDE	Comma は開発終了
Perl（5 系）	5.44（2026-07-15）。Perl 7 は未リリース

この表から言えることを 5 行にまとめる。これがこの連載の答えである。

1. 月次リリースが 196 回続いている。 継続の最も強い証拠だ
2. 6 年がかりのコンパイラ基盤刷新が完了しつつある。 保守ではなく前進している
3. 規模は小さい。 専用 IDE は失われ、モジュール数は少ない
4. 言語仕様は次の版へ向かっている。 止まっていない
5. 10 年ぶりに、Rakudo 以外の実装が動いている。 次の節で扱う

この 5 行を並べて書くのが、2026 年の Raku についての正確な記述である。 どれか 1 行だけを引けば、盛り上がっているようにも終わっているようにも書ける。 だから並べる。

10 年ぶりに、Rakudo 以外の実装が動いている

この連載を書いている最中に知ったことなので、正直に順序どおり書く。 第 7 話で「2 つ目の実装が去った損失」と書いた。その直後に、2 つ現れていた。

実装	作者	言語	方式	開始
mutsu	tokuhirom	Rust	バイトコード VM	2026-02
Raku++（rakupp）	ash	C++17（外部依存なし）	手書きの字句・構文解析 + 木渡り評価器	2026-07

どちらも Rakudo のフォークではなく、ゼロから書かれている。 そして両方とも Artistic-2.0、つまり Perl / Raku と同じライセンスを選んでいる。

適合度は roast で測られている

	roast ファイル完全通過（1,464 中）	個別テスト
mutsu	1,433（97.9%）	—
Raku++	676（46%）	200,843 / 約 219,610（91%）

この表が成立すること自体が、第 7 話の主題の帰結である。

「Raku に準拠している」が主張ではなく数字になるのは、 仕様を散文からテストスイートへ移したからだ。 もし仕様が Synopsis のままだったら、この 2 つのプロジェクトは 「どれくらい Raku なのか」を自分で申告するしかなかった。

エコシステムの測り方も正直

両者とも「roast を通る」だけでは足りないことを分かっていて、 実際のモジュールが動くかを別に測っている。

• mutsu: 1,624 distribution のうち 41.2% が「rakudo が通す全テストファイル」を通す
• Raku++: 2,529 のうち 1,006 が自身のテストを通す。 ただし同じマシンで Rakudo を走らせると 1,791 しか到達可能でない （残り 738 は libgsl・fontconfig・ネットワークが無くて誰も通せない）。 だから 1,006 は「到達可能の 56%」である

分母を先に測ってから比率を出している。数字の作法として正しい。

開発の速度

mutsu は 2026 年 2 月に始まり、7 か月半で 12,266 コミット・PR 8,700 本超に達している。 1 日あたり約 55 コミットだ。

ブランチ名を見ると claude/raku-line-profiler-design-... のような形が並んでいて、 大規模な AI 支援開発であることが分かる。ただし雑ではない。 直近のコミットにはこういうものが並ぶ。

docs(adr): record ADR-0106's gates as measured after Slice 2
docs(adr): record the three corrections ADR-0106 Slice 2 forced

ADR で設計を残し、スライスで刻み、ゲートを実測で記録し、 「実装が強いた訂正」を文書として残している。

第 5 話でこう書いた。

実装は、読んで分かる誤りとは別の種類の誤りを出す。

mutsu はその訂正を捨てずに記録している。Pugs が roast を始めたのと、形が似ている。

grammar が、初めて外へ出ようとしている

Raku++ は売り文句としてこう書いている。

Raku の grammar は .raku ファイルのままで、任意のホスト言語がそれを駆動できる — それに相当するものは他のどれも持っていない

C API を 1 つ用意し、C++ / Go / JavaScript / Python / Rust / Wolfram へのバインディングを出している。 つまり「Raku の grammar だけを他の言語から使う」ことを狙っている。

この回の最後で「grammar は Raku の形のままでは広まっていない」と書くが、 広める試みは、いま始まったところである。

正直な但し書き

• どちらも production ready ではないと本人たちが明言している
• mutsu の既知の穴: 未宣言変数をコンパイル時に弾かない、例外型が限定的、 パッケージマネージャが未成熟、RakuAST 未実装
• 数字は毎日動く。 mutsu の README には「適合度は毎日良くなっている」と書かれている

⚠️ ここに挙げた数字はすべて 2026 年 9 月 18 日に各リポジトリで確認したもの。 引用するなら測り直すこと。この連載の規則 1 条のとおりである。

連載の論としてどうなるか

第 7 話の懸念は、部分的に解消された。

単一実装のとき、実装のバグは「言語の仕様」として定着しうる。 実装が 3 つになると、食い違いが「仕様の穴か、実装のバグか」として可視化される。

そして第 6 話の型がここで効く。

1 人目の利用者では、汎用のふりを見抜けない。

roast は 10 年以上、Rakudo という 1 人の利用者しか持たなかった。 roast がどれだけ仕様を捉えているかは、これから検証される。

では、Raku は何に向いているのか

「小さいが継続している」は状態の記述であって、使う理由ではない。 2026 年に Raku を選ぶ理由があるとすれば何かを、測り直して書く。

以下の数字はすべて 2026 年 9 月 18 日、macOS / Rakudo Star 2026.08 で測った。 再現コマンドを併記する。数字は腐るので、引用するときは自分で測り直してほしい。

通底している 1 つの判断

Raku の強みは個別の機能というより、全部が同じ判断から出ている。

素直に書いたときの答えが正しいことに、性能と規模を払う。

多くの言語は逆を選んだ。安い答えを既定にして、正しい答えは要るときに取りに行かせる。 Raku は正しい答えを既定にした。実測で見る。

実測 1 — 文字列

入力を全言語で明示的に分解形（e + U+0308）に揃えて比較した。

raku   -e 'my $s = "noe\c[COMBINING DIAERESIS]l"; say $s.chars, " / ", $s.flip'
python3 -c 's = "noe\u0308l"; print(len(s), "/", s[::-1])'
perl -CS -e 'my $s = "noe\x{0308}l"; print length($s), " / ", scalar reverse($s), "\n"'

言語	長さ	反転	家族絵文字 👨‍👩‍👧‍👦 の長さ
Raku	4	lëon	1
Swift	4	lëon	1
Python 3	5	l̈eon ← 濁点が l に移った	7
Perl 5	5	l̈eon ← 同上	7

文字列を反転しただけで発音記号が別の文字に移るのが、コードポイント単位の言語の既定の挙動である。

ただし Raku だけの特権ではない。 Swift も書記素クラスタ単位だ。 Raku が違うのは、これが正規表現と grammar にそのまま繋がる点である（第 11 話）。

実測 2 — 数値

raku    -e 'say 0.1 + 0.2 == 0.3; say (0.1 + 0.2).WHAT, " ", (0.1 + 0.2).nude'
python3 -c 'print(0.1 + 0.2 == 0.3, 0.1 + 0.2)'

言語	0.1 + 0.2 == 0.3	実際の値
Raku	True	Rat の 3/10（厳密）
Python 3	False	0.30000000000000004

小数リテラルが既定で有理数。Fraction や Rational を持つ言語は多いが、 リテラルが既定でそれになる言語はほぼ無い。

明確に強い 4 領域

領域	なぜ	代替案との差
パーサ / DSL / 独自フォーマット読み	grammar が言語機能（第 11 話）	ANTLR / yacc はビルド段が要る。Parsec / nom はホスト言語の関数として書く
複雑な Unicode テキスト処理	書記素単位 + それが正規表現に繋がる	Swift は書記素だが正規表現の表現力が違う。他は自前で正規化の面倒を見る
正確さが速さより重要な数値計算	有理数が既定、整数は任意精度	明示的に取りに行く必要がある
多数のイベント源を 1 か所で束ねる並行処理	react / whenever が構文	Go の select は channel 限定。RxJS はライブラリ

この 4 つに共通するのは、**「正しい答えが高くつく領域」**だということだ。 Raku が強いのは、そこで高い方を既定にしたからである。

正直な弱点

同じ環境で測った。

for i in 1 2 3 4 5; do raku -e 'say 1' >/dev/null; done   # 5 回平均を取る

言語	起動時間（5 回平均）
Raku	138.8 ms
Python 3	38.4 ms
Perl 5	13.9 ms

Perl の 10 倍である。 ワンライナーやシェルスクリプト代わりには不利で、 長時間走るプロセスなら相対的に問題にならない。 これは言語仕様ではなく実装の性質で、MoarVM の起動と組み込みライブラリのロードが理由だ。

加えて、この回の表に書いたとおり — 専用 IDE は開発終了、 モジュール数は CPAN とも RubyGems とも比較にならない。 （実装の数については、次の節で訂正する。）

まとめ

「Raku を使うべき」と言える場面は少ない。 2026 年に新規プロジェクトの言語として勧めるのは、エコシステムと人材の観点から難しい。

言えるのはこちらである。

パーサを書く、複雑な Unicode を扱う、数値の正確さが要る — このどれかが仕事の中心にあるなら、Raku は「他の言語でやるより明らかに楽」な選択肢になる。

そしてもう 1 つ、実務ではない価値がある。 言語設計の見本市としては群を抜いている。 型・MOP・並行・文法拡張・数値タワーの実例が 1 つの言語に全部入っていて、 しかも設計判断がすべて公開されている。この連載が 12 話ぶん書けたのは、そのおかげだ。

5 つの問いに戻る

第 0 回（連載の地図）で、5 つの問いを立てた。答え合わせをする。

1. なぜ互換性を切ったのか

Perl 5 の根本的な制約 — シジルの規則、bless ベースの OO、@_ による引数渡し — は、後方互換性のため変えられなかった。そして後方互換性が重かったのは、CPAN があったからだ（第 2 話）。

成功した言語は、その成功の形に固定される。

変えたい。しかし変えられない。ならば別の言語を作るしかない。

2. なぜ 15 年かかったのか

4 つある（第 8 話で総括した）。

設計が壮大すぎた（第 4 話）／実装基盤の賭けを外した（第 6 話）／ 仕様が動き続けた（第 5・7 話）／専任の担い手が薄かった。

怠慢でも混乱でもない。 そして MoarVM に移ってからは 2 年半で出ている。

3. なぜ名前を変えたのか

「Perl 6」という名前が、検証されていない主張を 19 年運び続けたから（第 9 話）。

三方が損をしていた。Perl 5 は「終わった言語」に見え、 Perl 6 は「未完成の Perl」に見え、Perl 5 はバージョン番号を進められなかった。

そして 2015 年に完成したからこそ、2019 年に改名できた。

4. Perl 5 は何をしていたのか

待っていなかった。 Moose が出て、5.10 が出て、年次リリース体制になり、 シグネチャが安定化し、class が入った。2026 年 7 月に 5.44 が出ている。

この 15 年で最も損をしたのは、Perl 6 ではなく Perl 5 だったかもしれない。 存在しない後継に、15 年間追い立てられ続けたからだ。

5. 今どうなっているのか

上の 4 行のとおり。小さいが、継続していて、前進している。

この連載で出た 13 の型

技術の話としてこの連載を読むなら、残るのはこれだと思う。 どれも Perl / Raku に固有ではない。

#	型	話
1	言語の根本的な制約は、機能を足しても解けない。実装を作り直すことになる	1
2	成功した言語は、その成功の形に固定される。資産が大きいほど変更コストが上がる	2
3	公募が返してくるのは、解ではなく問題である	3
4	足す対象を、機能から規則へ引き上げる	4
5	実装は、読んで分かる誤りとは別の種類の誤りを出す	5
6	1 人目の利用者では、汎用のふりを見抜けない	6
7	バックエンドが N 本あることと、N 本が検証されていることは別である	6
8	散文は全部について曖昧に語り、テストは一部について厳密に語る	7
9	リリースとは機能の追加ではなく、変えないという約束の開始である	8
10	名前は、付けた瞬間の主張を凍結する	9
11	改名は「名前が埋まっている場所を全部数える作業」である	10
12	記法の長さは、頻度への割り当てである	11
13	構文拡張のしやすさは、元の構文の小ささと引き換えである	11

そして最後に、もう 1 つ足したい。この回を書いていて分かったことだ。

現在について書くことは、いつ調べたかを書くことである。

この記事の冒頭に「事実確認は 2026 年 9 月 18 日時点」と書いた。 書いたのは、それが誠実だからというより、書かないと使えないからだ。

「Raku の最新版は」と書かれた記事は、日付が無ければ判断できない。 古いのか、新しいのか、どちらとも言えないのか。 日付の無い「現在」は、読む人にとって情報ではない。

この連載が扱った 40 年は、そのことの巨大な実例でもあった。 2000 年に「Perl 6 は数年で出る」と書かれた記事は、 書かれた時点では正しかった。 第 9 話で名前について書いたのと同じ構造だ。

名前は、付けた瞬間の主張を凍結する。

記事も同じである。だから日付を書く。

終わりに — 最初の 3 行に戻る

この連載は、3 行の結論から始まった。

• Raku は Perl 6 の新しい名前である。 2019 年 10 月に改名した。同じ言語だ。
• Perl 6 は Perl 5 の次のバージョンではなかった。 互換性のない別言語として設計され、そう育った。
• Perl（5 系）は今も現役である。 2026 年 7 月に Perl 5.44 が出ている。終わっていない。

12 話を経た今、この 3 行は同じままだ。変わったのは、なぜそうなのかが分かっていることである。

そして最後に 1 つだけ、事実として書き添えておきたい。

2026 年 11 月、東京で、Larry Wall と Matz が同じ場所で話す。 Perl を作った人と、Ruby を作った人である。

この連載で扱った 40 年は、Perl が何を試し、何を諦め、何を諦めなかったかの記録だった。 その試みの多くは、他の言語に流れていった。CPAN はすべてのパッケージリポジトリの祖先になり、 正規表現は業界標準になり、Moose のオブジェクトモデルは Perl 5 に戻り、 そして grammar は — Raku の形のままでは、まだ広まっていない。

文法を拡張できる言語は他にもある（第 11 話で層ごとに並べた）。 Racket はその層で Raku より強い。しかし 正規表現の延長として書けて、クラスとして継承できる文法は、まだ Raku にしかない。

Raku にしかないものが、まだ Raku にある。 それが 2026 年の現在地である。

---

この連載を最後まで読んでくれた方に感謝します。 事実の誤り・更新の指摘は歓迎します。