Lobster言語の作者 Wouter van Oortmerssen（ワウター・ファン・オールトメルセン）氏が設計した新しいシステムプログラミング言語「Goose（グース）」が、2026年10月下旬から開発者のあいだで話題になっています。ヒープもガベージコレクション（GC）もライフタイム注釈も使わずにメモリ安全を実現し、作者の計測ではC++やRustより速いとされています。しかも、コンパイラの実装はほぼすべてAI（Claude）が担当しました。
「C++の3.3倍速い」「AIが作った言語」という見出しだけを見ると、どこまで信じてよいのか迷うはずです。この記事では、公式サイトとGitHubのREADMEをもとに、Gooseが何をしている言語なのか、速さの数字をどう読めばよいのか、Rustとの違い、できないこと、試し方までを整理します。内容は2026年11月1日時点のものです。
Gooseとは？ヒープもGCもライフタイム注釈も使わないメモリ安全な言語
Gooseは、CやRustに似た書き方で、ヒープを持たずにメモリ安全を守るシステムプログラミング言語です。 動的な値はすべて、コンパイラが管理する「データスタック」の上に置かれ、スコープを抜けると片付きます。プログラムはC言語に変換してからコンパイルします。
基本の情報を表にまとめます。
| 項目 | 内容 |
|---|---|
| 正式名 | The Goose Programming Language |
| 設計者 | Wouter van Oortmerssen氏（GitHubの名前は aardappel） |
| 実装 | Claude Fable（Anthropic のAI）がほぼすべてを担当 |
| 種類 | システムプログラミング言語（C・Rustに近い構文） |
| メモリ管理 | データスタック。ヒープ・GC・参照カウント・デストラクターなし |
| 出力 | プログラム全体を1つのCファイルに変換 |
| 対応OS | Windows（x64）、Linux（x64）、macOS（Apple シリコン・Intel） |
| 最新版 | v2026.3（2026年10月21日） |
| ライセンス | Apache License 2.0（無料で使えるオープンソース） |
| リポジトリの作成 | 2026年8月30日 |
詳しい説明はGooseの公式サイトにまとまっています。公開から約2か月ですが、2026年11月1日時点でGitHubのリポジトリのスターは2,600を超えています。
私がこの言語でいちばん面白いと感じたのは、速さそのものより、「ヒープを持たない」という一つの割り切りから、ほかの特徴がすべて組み立てられている点です。この割り切りが何を可能にし、何を手放したのかを順に見ていきます。
同じ名前の「goose」と混同しないために
「goose」で検索すると、別のソフトウェアが先に出てくることがあります。特に、GitHubの block/goose で公開されているAIエージェントの「goose」は、名前が同じでもまったく別物です。 こちらはパソコン上で動く汎用のAIエージェントで、プログラミング言語ではありません。
この記事で扱うのは、GitHubの「aardappel/goose」で公開されているプログラミング言語のほうです。調べるときは「Goose 言語」「Goose programming language」と言語であることを付けると、目的の情報にたどり着きやすくなります。
作ったのはLobsterの作者、実装したのはAIのClaude
Gooseは、人間が言語を設計し、AIが実装した言語です。 AIが言語を「発明」したわけではありません。READMEの作者欄では、役割がはっきり分けて書かれています。
- Wouter van Oortmerssen氏: 言語の設計、コンパイラの設計、コーディングの規約
- Claude Fable: コンパイラの実装、ベンチマーク、サンプルとドキュメントの執筆
van Oortmerssen氏は、ゲーム向けの言語Lobsterを作った人です。GoogleでデータのシリアライズのしくみFlatBuffersを作り、オープンソースのFPSエンジン「Cube」「Sauerbraten」も手がけてきました。いまはLobsterで作ったゲームを開発する会社を経営しています。
READMEによると、Gooseの設計自体は数年前に終わっていて、実装も始めていました。ところが、ゲーム会社の経営で完成させる時間が取れなかったそうです。そこで、Claude Fableが出たのをきっかけに、実装をAIに任せることにしました。
進め方にも工夫があります。van Oortmerssen氏は、自分の別のコンパイラ（Lobster）の書き方と構成をAIにまねさせました。AIが書いたコードを、自分のコードのように読める状態に保つためです。最初の設計で決めていなかった点は、AIとのやり取りの中で一つずつ決めていき、「その結果、より良い言語になった」と書いています。作者はこのプロジェクトを、既存の言語の再現ではなく、まったく新しい言語をAIが実装できるかの実験と位置づけています。
実装に使った言語はC++です。READMEでは、コンパイラはおよそ3万行のC++とされています。一方、ソースのフォルダ（src/）の行数を数えた開発者は6万1,518行と報告していて、数え方で差が出ています。
私は、ここがこのニュースの本当の中心だと見ています。言語の設計図はあっても、コンパイラを書き切る手間がなくて消えていった言語は多いはずです。Gooseは、その実装の壁をAIが越えた、早い時期の例です。
ヒープなしでなぜ安全なのか：データスタックと参照の推論
Gooseの仕組みの核は、「メモリは数本のデータスタックだけ」という決まりです。 伸びる値はスタックの一番上にあり、伸びるときはポインタを進めるだけ、スコープを抜けたらポインタを戻すだけです。mallocもfreeもGCも、言語のどこにも出てきません。
データスタック：伸びるときはポインタを進めるだけ
Gooseのプログラムが使うメモリは、ネイティブのコールスタック、静的データ、そしてN本のデータスタックです。Nの値はコンパイラがプログラムごとに決めます。データスタックは、アドレス空間を大きく予約した領域で、使った分だけ実際のメモリが割り当てられます。初期値では1本あたり2GBを予約します。
1本のスタックで伸び縮みできる値は、常に一番上の1つだけです。そのため、値が伸びても何も引っ越さず、容量のチェックも要りません。これらはすべてコンパイル時に確かめられ、実行時に管理するのはポインタの位置だけです。100万個の要素を持つ構造を片付けるのも、どれだけ深く入れ子になっていても、ポインタを1回書き換えるだけで終わります。
配列が伸びても参照が切れない
C++の vector やRustの Vec は、要素が増えて容量を超えると、別の場所へ引っ越します。そのとき、古い場所を指していた参照は使えなくなります。
Gooseでは、配列が伸びても中身は動きません。公式の例では、配列に要素を1つ入れて、その参照を取っておき、そのあと100万回追加してから最初の参照を使っても、そのまま有効です。C++なら reserve で容量を先に確保し、安全なRustなら番号（インデックス）で管理するような場面で、Gooseは型付きの参照のまま書けます。
ライフタイム注釈なしで、危ない参照をコンパイル時に止める
Rustでは、参照の寿命を 'a のような注釈で書く場面があります。Gooseには、ライフタイムの記法も、unsafe もありません。 コンパイラが、それぞれの参照がどの変数に「根を張っているか」を推論し、持ち主より長生きする参照をコンパイルエラーにします。
たとえば、関数の中で作った配列の一部を、関数の外へ返そうとすると止められます。実際に試した開発者の報告では、次のようなエラーが出ています。
error: returning a reference rooted in s, which dies with this function (§9.2)
「sに根を張った参照を返そうとしているが、sはこの関数と一緒に消える」という意味です。どの変数が原因かを名指ししてくれるのは、初めて触る人にも親切な作りだと私は思います。
入れ子のデータも1つのかたまり、そのままファイルに保存できる
Gooseでは、文字列、文字列の配列、可変長のフィールドを持つ構造体、その構造体の配列が、どれもポインタを含まない1つの連続したバイト列になります。
さらに、参照を1・2・4バイトの「相対参照」（自分の位置からの距離）で持てます。8バイトのポインタより小さく、データの置き場所に依存しないので、データ構造をそのままファイルに書き出し、そのまま読み込めます。 読み込むときは、すべての長さとリンクを確かめてから値にするので、壊れたファイルや細工されたファイルは拒否されます。
そのほかの特徴
ほかにも、次のような特徴があります。
return E from f: 何段も上の関数から直接戻れるエラー処理。途中の関数は普通の書き方のままで、コンパイラが静的に確かめる。例外の仕組みやResult型、?は使わない- 可変長のenum: 値ごとに、そのバリアントの大きさだけを使う
- 共有メモリのないスレッド: ワーカーは自分のメモリを持つ別のプログラムとしてコンパイルされ、型付きのキューで値をやり取りする。データ競合やロックは言語に存在しない
- ジェネリクスと高階関数: すべてコンパイル時に展開され、
filterのような関数も手書きのループと同じ形になる - C言語との連携: プログラム全体を1つのCファイルに変換し、
extern fnでCの関数を直接呼べる。TinyCCを内蔵していて、ビルドしなくても実行できる
「C++の3.3倍速い」は本当か：作者の計測と数字の読み方
結論から言うと、数字は作者自身の計測で、比べる相手と条件で意味が大きく変わります。 2026年11月1日時点で、第三者が同じベンチマークを測り直した結果は見つかりませんでした。負けているベンチマークも含めて公開されている点は評価できます。
公式サイトの冒頭では、16本のベンチマークの平均（幾何平均）で、Gooseは普通に書いたC++の3.3倍、手で最適化したC++の1.16倍、安全に書いたRustの最良の実装の1.12倍の速さだとしています。メモリの使用量は、それぞれ1.9分の1、1.3分の1、1.2分の1です。
同じ公式の中でも数字が違う
気をつけたいのは、公式サイトの中でも数字がそろっていないことです。冒頭の文と、同じページの表の数字が違います。
| 比べる相手 | 冒頭の文 | 表（MSVCでビルド） | 表（clangでビルド） |
|---|---|---|---|
| 普通に書いたC++ | 3.3倍速い | 3.51倍速い | 3.54倍速い |
| 手で最適化したC++ | 1.16倍速い | 1.24倍速い | 1.26倍速い |
| 安全に書いたRustの最良の実装 | 1.12倍速い | 1.13倍速い | 1.19倍速い |
| メモリの使用量（普通に書いたC++と比べて） | 1.9分の1 | 1.95分の1 | 1.95分の1 |
チュートリアルでは、さらに「手で最適化したC++や最良の安全なRustとはほぼ同じくらい」という書き方になっています。測り直した時期の違いと見られますが、どの数字が最新なのかは、公式には説明されていません。
平均の中身：負けている項目もある
全体の結果は、2026年10月16日に、1台のパソコン（AMD Ryzen 9 9950X3D、Windows 11）で、3回測ったうちの最も良い値をとったものです。
一部の項目を見ると、平均だけでは分からない差があります。数字が1倍より大きければGooseのほうが速く、小さければ遅いことを表します。
| ベンチマーク | 普通に書いたC++と比べて | 手で最適化したC++と比べて | 安全なRustの最良の実装と比べて |
|---|---|---|---|
| 16本の平均 | 3.51倍 | 1.24倍 | 1.13倍 |
| bintrees（いちばん差が大きい） | 15.58倍 | 1.91倍 | 1.14倍 |
| particles | 1.20倍 | 1.07倍 | 1.00倍 |
| lru | 3.36倍 | 0.88倍 | 0.81倍 |
| scene | 5.78倍 | 1.09倍 | 0.82倍 |
| calc | 4.06倍 | 1.07倍 | 0.91倍 |
「3倍以上速い」のは、unique_ptr や unordered_map を使って普通に書いたC++との比較です。手間をかけて最適化したC++や、安全なRustのいちばん速い書き方と比べると、差は1割前後で、項目によっては負けています。
私は、「C++の3.3倍」という見出しより、「細かいメモリ確保が多い処理なら、普通に書いても手で最適化したC++並みの速さが出る」と読むのが正確だと見ています。速さの理由も、新しい最適化ではなく、データの置き方を言語で決めていることにあります。
この数字の読み方を、日本語で丁寧に検証している動画があります。ベンチマークの中身、第三者の試し方、Gooseが手放した機能までを順に追っています。
動画では、「3.3倍」は細かいメモリ確保が大量に起きるデータ構造の処理、つまりGooseの得意分野の平均だと説明しています。海外のエンジニアが試したところ、公式の例の29バイトの注文データは測っても29バイトで、壊したファイルは宣言どおり拒否された一方、素数を数えるような単純なループでは、手書きのCとほぼ同じ速さだったそうです。「半分は嘘」ではなく「条件付きの本当」と読むべきだ、というのが動画の結論です。
RustやC++との違い：注文1件が29バイトになる理由
Rustとの最大の違いは、メモリ安全を所有権と借用の規則で守るのではなく、「ヒープを持たない」設計で守る点です。 そのぶん書き方の自由は減りますが、ライフタイム注釈や借用チェッカーとの格闘はありません。
| 観点 | C++ | Rust | Goose |
|---|---|---|---|
| メモリ管理 | 手動、またはスマートポインタ（ヒープ） | 所有権とヒープ | データスタック（ヒープなし） |
| メモリ安全 | 言語としては守らない | 守る | 守る |
| ライフタイム注釈 | なし | 必要な場面がある | なし（コンパイラが推論） |
| unsafe | （全体が安全でない） | あり | なし |
| エラー処理 | 例外、戻り値 | Result と ? | return ... from |
| 配列が伸びたときの参照 | 無効になることがある | 借用規則で守る（番号で管理することが多い） | そのまま有効 |
| クロージャ・関数ポインタ | あり | あり | なし（外へ持ち出せない） |
| 継承・仮想関数 | あり | トレイトオブジェクト | なし（ADTのタグで分岐） |
| 分割コンパイル | あり | あり | なし（プログラム全体） |
| 実績・周辺の道具 | 豊富 | 豊富 | 公開から約2か月 |
違いがいちばん分かりやすいのが、公式の「注文データ」の例です。注文番号、顧客名、商品明細2行を持つ注文1件を、メモリにどう置くかを比べています。
C++で std::string と std::vector を使って書くと、160バイトでメモリの確保が1回です。Rustで String と Vec を使うと、153バイトで確保が4回です。Gooseでは、29バイトで確保は0回になります。注文全体がポインタを含まない1つのバイト列になるので、たくさんの注文を並べても、メモリを先頭から順に読むだけで処理できます。
ただし、この並べ方には代償があります。大きさがそろっていない要素の配列は、先頭から順にたどることはできても、「5番目」のように番号で直接取り出せません（別に参照の一覧を作れば取り出せます）。
Gooseにできないこと・向かない用途
Gooseは、何でも書ける汎用の言語を目指していません。 公式サイトは、手放したものを「制約（Limitations）」として自分で一覧にしています。
| 制約 | 意味 |
|---|---|
| データの置き場所を考える必要がある | 誰がデータを持ち、どのスコープまで生きるかを書き手が考える。たいていはデータを作る関数が持ち主で、そうでないときはプール（slot_pool、slice_pool）を使う |
| 再帰で伸びるデータを持ち越せない | 再帰呼び出しをまたいで、伸びるデータを持ち続けられない。続けて使うデータはプールとして渡す |
| 大きさが不ぞろいな要素は番号で引けない | 可変長の要素の配列は、順にたどれても、番号では取り出せない |
| クロージャ・関数ポインタ・動的ディスパッチがない | 外へ持ち出せるクロージャや関数ポインタはなく、分岐はADTのタグだけ |
| プログラム全体のコンパイルだけ | ファイルごとに分けてコンパイルできない |
| プールに返した場所の参照 | 返したあとも参照していると、次の持ち主が入れた値が読める。論理的なバグにはなるが、メモリが壊れることはない |
このほか、伸びる値のムーブ、1つの構造体に伸びる値を2つ以上持つこと、ラベル付きの break、名前空間の非公開設定、OSやライブラリへの幅広いアクセスは、いまは意図して対象外にしていると公式は書いています。
向いているのは、パーサー（文字列や構文の解析）、ゲーム、大きなファイルを読み込んで木構造を作るような処理です。 データの持ち方と速さを細かく決めたい場面に合います。サンプルにも、JSONパーサー、スレッドを使ったマンデルブロ集合、物理演算で箱が降り積もるデモ、小さなMinecraftやDoom風のゲームが並んでいます。
反対に、一般的なWebサービスのサーバー側や、成熟した部品の豊富さが必要な仕事には向きません。 パッケージの仕組みはまだ育っておらず、外部の監査を受けたという情報も見当たりません。私は、Gooseを「C++やRustの置き換え」ではなく、「特定の処理を速く安全に書くための道具」として見るのが正しいと考えています。
Gooseの試し方：Windows・Mac・Linuxで動かす手順
Gooseは、配布されている実行ファイルを展開するだけで試せます。 Windowsなら、ほかに何も入れずにサンプルを動かせます。
手順は次のとおりです。
- GitHubのReleasesのページから、自分のOS用のファイル（Windows x64、Linux x64、macOS）をダウンロードする
- 好きな場所に展開し、そのフォルダをPATH（コマンドを探す場所）に追加する
goose ファイル名.gooseで、そのプログラムをすぐに実行する（内蔵のTinyCCを使うので、ビルドの手順は要らない）- 実行ファイルを作りたいときは、
goose build ファイル名.gooseを使う
最初のプログラムは、次の3行です。
fn main() {
print("hello, goose");
}
OSごとに必要なものが少し違います。
| OS | 実行（goose ファイル名）に必要なもの | 実行ファイルを作る（goose build）ときに追加で必要なもの |
|---|---|---|
| Windows（x64） | なし | Visual Studio 2022以降、またはclang |
| Linux（x64） | Cのライブラリのヘッダー（libc6-dev や glibc-devel）、glibc 2.35以降（Ubuntu 22.04、Debian 12など） | gcc または clang |
| macOS（Apple シリコン・Intel） | Xcodeのコマンドラインツール、macOS 13.3以降 | gcc または clang |
macOSでは、ダウンロードしたファイルがそのままでは実行できないので、展開したフォルダに xattr -dr com.apple.quarantine を実行します。スレッドを使うプログラムは、goose build で実行ファイルを作ってから動かします。
配布ファイルには、ドキュメント、31本のサンプル、VS Codeの拡張機能も入っています。拡張機能を入れると、入力中のエラー表示や定義へのジャンプが使えます。読み始めるなら、公式のチュートリアルが例を使って順に説明していて分かりやすいです。
実際に試した開発者は、Linuxでヘッダーが入っていなかったために最初は stdint.h が見つからないというエラーになり、C言語のコンパイラを指定し直して動かしています。整数の型の扱いが厳しく、自分で書いた小さなプログラムがコンパイルを通るまで3回かかったとも書いています。Linuxで試す人は、先に必要なものを入れておくと引っかかりにくいです。
開発者の反応：Carmack氏の評価と「READMEがAIっぽい」という声
Gooseへの反応は、仕組みへの高い評価と、主張や文章への疑問に分かれています。 どちらも、この言語を判断するうえで参考になります。
評価の代表は、ゲームプログラマーの John Carmack 氏です。Carmack氏はXで、Gooseを「本当によくできている」と評価し、次のように書いています。
複数のデータスタックとリサイズ可能なフィールドを自動で解析して使うことで、「多くの作業をこの方法でできる」から「基本的にすべてをこの方法でできる」に変わった。相対参照と、組み込みのバイナリ構造の検証によって、データ構造をそのままメモリに割り当てたり、ネットワークのデータをすぐに使ったりもできる。ファイルやネットワークのデータの「パース」は、必要な速さより100倍遅いことがよくある。
一方、Hacker Newsでは疑問の声も目立ちました。
- 「AIっぽい言い回しなしでREADMEを書き直してほしい」と、文章の読みにくさを指摘する声
- チュートリアルの最初の例で、C++の文字列の最適化（短い文字列はヒープを使わない）を考えに入れていないという指摘
- 「C++ではなくこれを使う理由が分からない」という意見
- 性能と安全のどちらを優先しているのかという質問。作者は「Gooseには unsafe の機能がなく、未定義動作もなく、完全にメモリ安全だ」と答えている
実際に試した人の中には、業務用の大きなRustのコードからいくつかのアルゴリズムをGooseに移したところ、Gooseのほうがはっきり速かったという人もいます。面白いのは、Gooseが選ばせたデータの持ち方をRustに戻しても、改善がほぼそのまま残ったという点です。言語そのものより、データの持ち方の考え方が効いたことになります。
私がいちばん参考になると感じたのは「AIの確かめ方」
私は、Gooseで本当に新しいのは、言語よりも、AIが書いたコードを信じすぎないための仕組みのほうだと見ています。リポジトリには、次のような仕組みがそろっています。
- 自動テスト（CI）を Windows・macOS・Linux で動かし、メモリの誤りを見つける検査（サニタイザー）を付けた別の確認もある
- ベンチマークは、すべての実装が同じチェックサム（計算結果の照合値）を出すことを確かめてから記録する。速くても答えが違う実装は、表に載らない
- コンパイラへの変更の記録に、採用しなかった変更や保留にした変更も残している
「AIは優秀だから大丈夫」ではなく、人間が設計を持ち、変更ごとに数字で確かめ、ときには却下する。AIでソフトウェアを作る人にとって、この進め方はGooseを使うかどうかに関係なく参考になります。また、v2026.3では、作者以外の5人が初めて変更を出していて、AIだけでなく人の手も入り始めています。
よくある質問
Gooseは本当にC++やRustより速いのですか？
作者の計測では、16本の平均で、普通に書いたC++より3倍以上、手で最適化したC++や安全なRustより1〜2割ほど速いとされています。ただし、第三者による測り直しはまだ見当たらず、項目によってはRustに負けています。細かいメモリ確保が多い処理で差が出やすい言語です。
Rustの代わりに使えますか？
今のところ、置き換えには向きません。クロージャや関数ポインタがない、再帰で伸びるデータを持ち越せないなどの制約があり、周辺の道具も育っていません。パーサーやゲームなど、向いている処理で試すのがおすすめです。
AIが作った言語を使っても大丈夫ですか？
設計は人間で、AIが実装したコンパイラは、3つのOSでの自動テストやメモリの検査で確かめられています。ただ、公開から約2か月で、外部の監査を受けたという情報はまだありません。仕事で使うより、学習や試作で触るのが無難です。
AIエージェントの「goose」とは関係がありますか？
関係ありません。GitHubの block/goose で公開されている goose は、パソコン上で動くAIエージェントです。この記事のGooseは、GitHubの aardappel/goose で公開されているプログラミング言語です。
どのOSで使えて、どうやって試せますか？
Windows（x64）、Linux（x64）、macOS（Apple シリコン・Intel）で使えます。GitHubのReleasesから自分のOS用のファイルを落として展開し、goose ファイル名.goose で実行できます。
無料で使えますか？
無料です。Apache License 2.0のオープンソースとして、GitHubで公開されています。
Gooseを自分の目で確かめるために
Gooseのポイントを振り返ります。
- ヒープ・GC・ライフタイム注釈を使わず、データスタックでメモリ安全を守るシステムプログラミング言語
- 設計はLobsterの作者 Wouter van Oortmerssen氏、実装はほぼすべてAIのClaude Fable
- 「C++の3.3倍」は普通に書いたC++との比較で、作者の計測。最適化したC++や安全なRustとの差は1割前後で、負ける項目もある
- クロージャや関数ポインタがないなど、手放したものがはっきりしている。パーサーやゲームには向き、一般的なWebサーバーには向かない
- Windowsなら、配布ファイルを展開するだけで試せる
数字の真偽は、自分の手で確かめられます。まずはReleasesからファイルを落として、サンプルを1本動かしてみてください。速さよりも、「ヒープがない」書き方がどんな感覚なのかを体験することが、この言語を判断するいちばんの近道です。
