zerostack を読む: Rust 製コーディングエージェントのメモリ設計と機能ゲート
Lightweight coding agent written in Rust, optimized for memory footprint and performance
ひと目でわかる
- これは何？
- Rust で書かれた軽量コーディングエージェント zerostack について、README とリポジトリ情報から確認できる範囲で、メモリ消費の主張、コンパイル時機能ゲート、権限モード、そして採用判断の境界を整理する。
- 誰に向いている？
- zerostack は、JS ベースのコーディングエージェントが常駐するメモリ量を問題視していて、Rust の単一バイナリとコンパイル時機能ゲートを許容できる開発者に向く。Windows は README が「まったくテストしていない」と明記しているため、Windows 中心のチームには現時点で勧められない。
- 商用利用できる？
- 条件付きでできます。GPL-3.0 はコピーレフトのライセンスで、これを含むソフトウェアを配布する場合、そのソフトウェアのソースコードを同じライセンスで公開する必要があります。配布せず社内で使うだけなら、この義務は生じません。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Rust です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
zerostack が狙うのはエージェントの常駐メモリ
コーディングエージェントの多くは Node.js や Bun の上で動き、セッション中はプロセスが常駐する。zerostack の README はこの常駐コストを正面から問題にしている。README の Performance 節には、RAM フットプリントが平均約 16MB、ピークで約 24MB、比較対象として opencode などの JS ベースエージェントが約 300MB、ピーク約 700MB と記載されている。CPU もアイドル時 0.0%、ツール使用時で約 1.5%（Intel i5 第 7 世代での測定）と書かれている。
ただしこれらは README の主張であり、本記事が追試した数値ではない。測定環境が 1 つの CPU に限られている点、比較対象のバージョンが示されていない点は、そのまま受け取る前に確認したい。バイナリサイズ 26MB、コアの行数約 30k LoC（テストを除く）という数字も同じ節に並んでいる。
誰に向くかというと、エージェントを常時起動しておく使い方をする人、あるいは複数のエージェントを並列で走らせる人である。README には並列エージェント管理ツール multistack への言及があり、メモリが小さいほど同時起動の本数を増やしやすいという単純な理由がある。
機能はコンパイル時にゲートされる
zerostack の機能一覧を見ると、いくつかの項目に (gated) という注記が付いている。ACP サポート、永続メモリ、ライフサイクルフック、Advisor、マルチモーダル入力がこれに当たる。これは実行時フラグではなく、Cargo のフィーチャーとして扱われている。README のインストール例では次のように書かれている。
cargo install zerostack --features acp,memory,hooks,advisor
デフォルトのフィーチャーセットは README によれば loop、git-worktree、mcp、subagents、archmd、status-signals、multithread である。つまり永続メモリやフックを使いたい場合は、インストール時に明示するか --all-features を選ぶ必要がある。
この設計の利点は、使わない機能のコードと依存をバイナリに含めずに済むことだ。欠点は、後から機能を足すたびに再ビルドが必要になること、そして「zerostack にはメモリ機能がある」という情報だけを見て入れた人が、実際には自分のビルドにそれが入っていないという食い違いが起きやすいことである。インストール後にどのフィーチャーが有効かを確認する手段が README には明記されていないため、そこは各自で確かめるしかない。
権限モードとサンドボックスは別の層
zerostack には 5 つの設定可能な権限モードがあり、ツールごとのパターン、セッション単位の許可リスト、モードからルールへの適用ポリシーを設定できると README は説明している。これはエージェントがどのツール呼び出しを実行してよいかを決める層である。
もう一つが --sandbox で、こちらは bash コマンドを隔離環境で実行する。README は bubblewrap を例に挙げ、Debian/Ubuntu なら apt install bubblewrap、Fedora なら dnf install bubblewrap、Arch なら pacman -S bubblewrap とコマンドを示している。bubblewrap は Linux 専用なので、macOS では zerobox を cargo install zerobox で入れ、sandbox-backend = "zerobox" を設定する。
重要なのは README 自身がこの機能の限界を書いている点だ。「a seatbelt, not a boundary against untrusted code」と表現され、信頼できないコードに対する境界ではなく安全帯だと位置づけている。さらに --sandbox は best effort であり、バックエンドのバイナリが見つからない場合は警告をログに出したうえで、サンドボックスなしで bash コマンドが実行される。これを防ぐには --sandbox-required、または設定ファイルで sandbox-required = true を指定する。
権限モードとサンドボックスは目的が違う。前者はエージェントの判断に対する制御、後者は実行されたコマンドの影響範囲の限定である。片方だけ設定して安心するのは避けたい。
永続メモリとサブエージェントの仕組み
永続メモリは gated 機能で、README によればプレーンな Markdown として保存される。グローバルな MEMORY.md と、プロジェクトごとの日次ログ、スクラッチパッド、ノートで構成され、セッションごとにシステムプロンプトへ注入される。データベースやバイナリ形式ではなく Markdown なので、中身を人間が読んで編集でき、git で差分も追える。
設計の詳細は README ではなくブログ記事へのリンクに置かれている。memory design と題された記事、および第三者による xavier's memory analysis というメモリ分析記事が参照されている。リポジトリ内のコードだけから挙動を確認したい場合、この構成はやや追いにくい。
サブエージェントはコードベース探索用で、並列かつ高速だと README は説明している。ARCHITECTURE.md は AGENTS.md の companion ファイルとして位置づけられ、同じコードベースで作業する複数のエージェントに共通のコア知識を与える。プロンプトチェイニングは brainstorm、plan、code、review の各フェーズを順に進める提案を行い、遷移ごとに設定でゲートされる。
これらは「エージェントに毎回同じ説明をさせない」ための仕組みであり、リポジトリに AGENTS.md と ARCHITECTURE.md を置いて運用する前提だと読める。
インストールと初期設定の実際
導入経路は 4 つ示されている。スクリプトは curl -fsSL https://raw.githubusercontent.com/gi-dellav/zerostack/main/install.sh | bash、Cargo は cargo install zerostack、Homebrew は brew tap gi-dellav/tap の後に brew trust gi-dellav/tap（Homebrew 6.0.0 以降で必要と明記）を実行してから brew install zerostack、Nix は nix-run で tarball を直接指定する方法と、nix profile add、overlay として取り込む方法が並んでいる。
インストール後に README が案内するのは、zerostack 内で /prompt autoconfig を実行することである。これはドキュメントを辿りながら対話的に設定するコマンドだと説明されている。プロバイダは OpenRouter、OpenAI、Anthropic、Gemini、Ollama、およびカスタムに対応する。
注意点として、Cargo 経由のデフォルトでは memory や hooks が入らない。永続メモリを前提に運用を組み立てるなら、最初から cargo install zerostack --features memory のように指定するか、--all-features を選ぶ判断が要る。Homebrew の brew trust は tap を信頼させる操作で、これを省くとインストールが進まない。
Windows については README が「まったくテストしていない」と明記し、試して問題があれば issue を立ててほしいと書いている。対応済みという記述はどこにもない。
向かない場面と代替の考え方
zerostack が向かないのは、まず Windows が主戦場のチームである。README の記述からは動作保証の根拠が得られない。次に、エージェントの機能を実行時に切り替えたい場合。gated 機能はコンパイル時に決まるため、ビルドを変えずに有効化することはできない。
サンドボックスを信頼境界として使いたい場合も適さない。README 自身が seatbelt であって boundary ではないと述べており、バックエンド不在時は無警告ではなくログ警告のみでサンドボックスなし実行に落ちる。
代替として README が名前を挙げているのは opencode と pi である。zerostack はこの 2 つに触発されたと書かれている。アプローチの差は言語と配布形態にある。opencode のような JS ベースのエージェントは Node ランタイム上で動作し、機能追加は多くの場合ランタイム設定やプラグインで完結する。zerostack は Rust の単一バイナリにまとめ、機能を Cargo フィーチャーで取捨選択する。ランタイム依存を減らしメモリを抑える代わりに、機能の追加・削除がビルド作業になる。どちらが優れているという話ではなく、環境の再現性をバイナリで担保したいか、設定ファイルで担保したいかの違いである。
もう一つの選択肢は multistack で、これは zerostack 自体の代替ではなく、複数の zerostack エージェントを端末から編成するための別ツールである。
ライセンスと保守コストの見積もり
ライセンスは GPL-3.0 である。コーディングエージェントを開発ワークフローの中で使うだけなら通常は問題になりにくいが、zerostack を自社製品や社内配布ツールに組み込んで再配布する場合、GPL-3.0 の条件が及ぶ可能性がある。ここでは法的助言はできないので、組み込みを検討する場合は法務に確認してほしい。
保守コストの面で README から読み取れるのは、リリース頻度が高いことである。v1.8.2、v1.8.3、v1.8.4 が 2026 年 9 月 6 日から 7 日にかけて立て続けに出ており、最終 push は 2026 年 9 月 9 日である。活発に動いている代わりに、追従しないと取り残される速度でもある。
機能ゲートはここでも効いてくる。memory や hooks を有効にしたビルドを運用していると、更新のたびに同じフィーチャーセットで再ビルドする必要がある。Cargo の場合、フィーチャー指定をどこかに記録しておかないと、更新時にデフォルトセットへ戻ってしまう。
また README はスポンサーと寄付の窓口を案内しており、個人が維持している側面が強い。長期の社内標準ツールとして採用するなら、フォークして自分でビルドを維持する体制を先に考えておくほうが現実的である。
編集部の結論
zerostack は、JS ベースのコーディングエージェントが常駐するメモリ量を問題視していて、Rust の単一バイナリとコンパイル時機能ゲートを許容できる開発者に向く。Windows は README が「まったくテストしていない」と明記しているため、Windows 中心のチームには現時点で勧められない。また GPL-3.0 なので、自社製品に組み込む前にライセンス条件を確認する必要がある。導入前に見るべきは 3 点で、cargo install zerostack のデフォルト機能セットに memory や hooks が含まれるか、--sandbox が bubblewrap または zerobox のどちらを要求するか、そして /prompt autoconfig が提示する設定が自分のプロバイダ構成に合うかである。
コミュニティノート