Rune：Go で書かれたオープンソースの IDE

Rune は Unstable Build が開発した、キーボード中心の IDE 兼ターミナルマルチプレクサで、コードの約 97.6% が Go です（GitHub languages API、2026 年）。ウィンドウは Linux では OpenGL、macOS では Metal を使って GPU で自前描画しており、Electron もブラウザエンジンも使っていません。ソースコードは 2026 年 9 月 12 日に GPLv3 で公開されました（Rune ブログ、2026 年）。macOS と Linux で動作し、無料でダウンロードできます。Go の開発者にとって、Rune には 2 つの見方があります。試してみられるエディタであると同時に、GPU レンダリング、ターミナルエミュレーション、プラグインを Go の外に出ることなく扱う、大規模で読みやすい Go のコードベースでもあります。

要約

Rune は、UI がターミナルマルチプレクサのように動く IDE です。9 つのワークスペーススロット、無制限のターミナル、タブ、ウィンドウがあり、すべてをファジー検索できるコマンドプロンプト 1 つで操作します。
作者が Go を選んだ理由は反復の速さです。その後のプロファイリングによって、ターミナルは Alacritty、Ghostty、Kitty より 2 桁近く遅い状態から、ホットパスで cgo に頼ることなく互角の性能にまで改善されました（Rune ブログ、2026 年）。
描画には Ebitengine、構文解析には tree-sitter を使います。拡張機能とは Unix ソケット上の gRPC で通信し、設定は Starlark から読み込み、バージョン管理は go-git で処理します。
macOS か Linux で、普段から Vim、Emacs、Helix、tmux を使っている Go と Python の開発者に向いています。Windows 版はありません。
internal/ ツリーには、別プロセスとして動き、クラッシュしてもエディタを巻き込まないプラグインなど、自分のコードで再利用できるパターンがあります。

Rune とは？

Rune は自らを「高速で GPU アクセラレーションに対応した、フル機能の IDE 兼ターミナルマルチプレクサ」と説明しています（Rune の README、2026 年）。注目すべきはターミナルマルチプレクサの部分です。UI の見た目や動きが、VS Code よりも tmux に近いからです。画面をウィンドウに分割し、各ウィンドウにエディタのバッファかターミナルを置き、9 つのワークスペーススロットの間をキーボードで移動します。

初回起動時には、standard、vim、emacs、helix の 4 つの組み込みキーバインドのプリセットから 1 つを選びます（Rune ドキュメント、2026 年）。この選択はターミナル、入力ボックス、ファイルエクスプローラーを含むすべての場所に適用されるので、vim ユーザーはシェルの中でもモーダル編集を使えます。

ほかの機能を並べると、本格的な IDE そのものです。

Go と Python はファーストクラス（Tier 1）の扱いで、LSP、シンボルインデクサー、エコシステムに合わせたワークフローがそろっています。Rust と Zig はベータ版で、TypeScript はロードマップに載っています（Rune の対応言語、2026 年）。そのほか 300 以上の言語が、tree-sitter の文法パッケージを通じてシンタックスハイライトと構造的検索に対応しています。
デバッガー。Rune は google/go-dap を通じて Debug Adapter Protocol で通信し、デバッガーはコンソールから操作します。
コンソール。長時間動き続ける REPL で、パッケージのインストール、モデルの設定、拡張機能やプロセスの管理を行います。
Rune Agent。組み込みのコーディングエージェントで、シンボルを grep で探すのではなく、LSP と tree-sitter を通じてワークスペースに問い合わせます。
Rune Network。すべての Rune インスタンスは暗号化されたピアネットワークに参加するので、rune:// の URL を使ってノート PC からデスクトップのワークスペースを開けます。

既存のターミナル内で動く rune --tui モードと、ディスプレイのないマシン向けの rune --headless モードもあります。

Rune はなぜ Go で書かれているのか？

一言で言えば、反復の速さのためです。オープンソース化の告知で、創業者の Ernest Romero Climent は、IDE は「Rust や C/C++ のように書くのもコンパイルするのも遅い言語で書かれているか、パフォーマンスが重要な処理に合わせて曲げるのが難しいランタイムの上に作られている」と述べています。後者の例として挙げているのが Electron です（Rune ブログ、2026 年）。Go はコンパイルが速くて読みやすく、それでいて必要なときにパフォーマンスを追い込めるだけのメモリとスケジューリングの制御も手元に残ります。

Rune のターミナルエミュレーターは Go で書かれており、記事によると PTY のスループットは当初、Alacritty、Ghostty、Kitty より「2 桁近く遅かった」そうです。その差を埋めたのは 4 つの変更で、別の言語での書き直しは 1 つも含まれていません。

アルゴリズムの改善。
goroutine への処理の分散をより効果的にしたこと。
goroutine の起床のバランスを取り、Go のスケジューラーが無駄な仕事をしないようにしたこと。
ゲームエンジンが使うフレームレート単位のループから、イベント駆動のモデルに移行し、レイテンシを減らしたこと。

チームは、これが何を証明するのかについて慎重です。vtebench のグラフは「Go が Rust や Zig と同じくらい速いことを示すものではない」と書いています。示しているのは、Go でのプロファイリングと丁寧なエンジニアリングだけで、これらの処理においてターミナルを互角の性能にできたということです。これは Go のパフォーマンス改善の多くに共通する流れです。まずプロファイリングを行い、修正はたいていアルゴリズムと、goroutine 同士の処理の受け渡し方に入ります。

このプロジェクトは、公開リポジトリよりずっと前から存在しています。作者は長い歴史をまとめた記事で、最初の vi のプロトタイプを 2017 年 8 月 3 日のコミットにさかのぼるとしています（Rune ブログ、2026 年）。始まりは、作者自身が Go の作業で使うための Vim の代わりでした。2019 年には Six と呼ばれ、2024 年に Ox となり（このとき GPU ウィンドウのために Ebitengine へ移行しました）、2025 年の終わりに Rune と改名されました。どのバージョンも Go で書かれています。

Rune はどのように作られているのか？

Rune のアーキテクチャ図：Ebitengine の GPU レンダラー、セルグリッドのバッファ、tree-sitter と LSP のクライアントを持つ Go のコアプロセスが、Unix ソケット上の gRPC で Go サポート、Python サポート、Rune Agent などの独立した拡張機能プロセスと通信している

go.mod ファイルは、アーキテクチャを把握するための格好の地図です。Go 1.26.6 が宣言されており、依存関係はいくつかの役割に分けられます。

役割	依存関係
GPU ウィンドウと描画	`github.com/hajimehoshi/ebiten/v2`（Ebitengine）、`go-text/typesetting`
ターミナルと TUI	`tcell/v3` のフォーク、`unstablebuild/pty`
構文木	`github.com/tree-sitter/go-tree-sitter`
拡張機能	`google.golang.org/grpc`、`unstablebuild/rune-go-sdk`
設定	`go.starlark.net`、`gopkg.in/yaml.v3`
バージョン管理	`github.com/go-git/go-git/v6`
デバッグ	`github.com/google/go-dap`
ネットワーク	`github.com/gliderlabs/ssh`、`pion/webrtc/v4`
AI モデル	`anthropic-sdk-go`、`openai-go/v2`、AWS Bedrock SDK

Ebitengine は 2D ゲームエンジンで、Rune はこれを GPU レイヤーとして使っています。ネイティブのグラフィックスパイプラインが OpenGL と Metal にリンクするため、Makefile は CGO_ENABLED=1 でエディタをビルドします。デフォルトの設定は Starlark のスクリプト（rune.star）です。Starlark は設定用に設計された、Python に似た小さな言語です。設定の中で if 文やループを使え、その結果は単純なデータとしてローダーに渡されます。

2026 年 9 月 27 日に shallow clone したところ、テスト以外の Go コードは約 316,000 行ありました（wc -l で計測、生成コードを含む）。バイト数では Go が 97.6% を占めます。次に多い言語は Starlark で、0.5% です。

Rune リポジトリの言語構成を示す棒グラフ：Go 97.6%、Starlark 0.5%、Shell 0.5%、Makefile 0.4%、その他 1.0%

拡張機能は別プロセスで動く

Rune はコアを小さく保ち、機能を拡張機能として外に出しています。Go 言語サポート、Python サポート、ファジー検索、Rune Agent はすべて拡張機能で、「組み込み拡張機能という別の区分は存在しない」とされています（Rune の拡張機能ドキュメント、2026 年）。

各拡張機能はそれぞれ独立した実行ファイルです。Rune はそれを子プロセスとして起動し、標準入出力で認証情報を渡したあと、Unix ドメインソケット上の gRPC で通信します。この処理は internal/extension/extensionv2/runner.go で確認でき、Unix リスナーと grpc.NewServer を作成しています。ワークスペースごとに専用の拡張機能プロセス一式があり、各機能（エディタ、ファイルシステム、ストレージ、コマンド）は、拡張機能が要求しなければならない権限の背後に置かれています。

最大の利点はクラッシュの分離です。拡張機能で panic が起きても終了するのはそのプロセスだけで、ドキュメントでは拡張機能のクラッシュが「エディタを道連れにすることは決してない」と約束しています。やり取りの取り決めが gRPC なので、拡張機能は Rune SDK のある言語ならどれでも書けます。Go SDK は完成しており、Python SDK も作業が始まっています。Go の拡張機能にはもう 1 つ利点があります。それぞれが 1 つの静的バイナリにビルドされ、pkg install でデータディレクトリに配置されます。

SDK のエントリーポイントは 1 回の呼び出しです。Go の拡張機能はメタデータと権限を宣言し、関数を extensionapi.ServeWorkspaceExtension に渡します。プロセスのライフタイムはこの関数が管理します（Rune Go SDK ドキュメント、2026 年）。形は http.ListenAndServe と同じで、ハンドラーを渡せば、ループはライブラリが回してくれます。プロトコルは一度書き直されています。作者は最初 HashiCorp の go-plugin でプラグインを作りましたが、Go 以外の SDK がすべて go-plugin のプロトコルを再実装しなければならなくなるため、よりシンプルなハンドシェイクに置き換えました（Rune ブログ、2026 年）。

channel やソケットを通じて goroutine が互いにデータを渡すという考え方が初めてなら、chan キーワードのガイドでこのパターンのうちプロセス内の部分を解説しています。

Rune vs VS Code、Zed、Neovim + tmux

Rune の競合は、言語、描画、プラグインについてまったく異なる選択をしています。

	Rune	VS Code	Zed	Neovim + tmux
主な言語	Go	TypeScript	Rust	C と Lua
描画	GPU（OpenGL または Metal）のセルグリッド	Electron（Chromium）	GPU（GPUI）	使っているターミナルエミュレーター
拡張機能のモデル	gRPC で通信する別プロセス	Node.js の拡張機能ホスト	WebAssembly	プロセス内の Lua と RPC プラグイン
組み込みのターミナルマルチプレクサ	あり	ターミナルパネル	ターミナルパネル	tmux が担当
ライセンス	GPLv3	MIT（Code - OSS）	GPLv3（エディタ）	Apache 2.0 と ISC
対応プラットフォーム	macOS、Linux	Windows、macOS、Linux	Windows、macOS、Linux	ほぼすべての環境

最も近い比較対象は Neovim と tmux の組み合わせで、Rune の作者が置き換えようとしていたのもこの構成です。Rune は両者を本物の GPU ウィンドウを持つ 1 つのプログラムにまとめているので、どのターミナルエミュレーターを使っていてもフォントは同じように描画されます。パフォーマンスを重視する姿勢では Zed が最も近いものの、Zed は Rust で書かれており、文字グリッドではなく一般的な GUI を描画します。拡張機能のエコシステムは VS Code が群を抜いて大きく、Rune はそれに張り合おうとはしていません。

Rune のインストール方法は？

公式のインストールスクリプトは macOS と Linux で使えます。

example.bashbash
curl -fsSL https://rune.build/install.sh | sh

GitHub のリリースページからビルドをダウンロードすることもできます。2026 年 9 月 11 日の v1.2.1 リリースには、Apple Silicon と Intel の Mac 向けの .dmg ファイルと、amd64 と arm64 の Linux 向けの .tar.gz アーカイブが含まれています。

ソースから実行するには、リポジトリをクローンして Go のツールチェーンを使います。

example.bashbash
git clone https://github.com/unstablebuild/rune.git
cd rune
go run ./cmd/rune

Linux では glibc 2.28 以降と、システムの OpenGL および X11 ライブラリが必要です。Wayland では XWayland 経由で動作します（Rune ドキュメント、2026 年）。make test はレースディテクターを有効にしてテストスイートを実行します。大規模な Go プロジェクトがテストをどう整理しているかを知るのにも役立ちます。

Rune は無料でダウンロードして使えます。Rune Pro は月額 $10 で、Rune Network で接続できるマシンの上限が 2 台から 10 台に増えます（Rune の料金、2026 年）。エディタ、言語サポート、エージェントを使うのに Pro は必要ありません。

Rune の弱点はどこにあるのか？

Rune は公開プロジェクトとしてはまだ新しく、乗り換える前に知っておくべき制限がいくつかあります。

Windows 版はありません。リリースが対応しているのは macOS 13.3 以降と Linux だけです。
Linux のウィンドウ版エディタは glibc が必要なので、Alpine などの musl ベースのディストリビューションには対応していません。X11 ライブラリか XWayland も必要です。TUI モードとヘッドレスモードには、これらの要件はありません。
現時点でフルサポートを受けているのは Go と Python だけです。Rust と Zig はベータ版で、TypeScript はまだ Tier 1 に入っていません。そのため、フロントエンドや JVM の開発者の多くにとって、Rune はメインのエディタの候補になりません。
コマンドプロンプトとコンソールを中心とした操作は、手になじめば速いものの、そこに至るまでには VS Code を開いてクリックしながら覚えるより時間がかかります。その助けとして、初回起動時にはガイド付きのチュートリアルが IDE 内で始まります。
公開リポジトリはできたばかりです。GitHub リポジトリが作成されたのは 2026 年 9 月 10 日で、9 月 27 日時点でスターが 1,184、フォークが 87 でした（GitHub API、2026 年）。コード自体は 2022 年ごろから日常的に使われていますが、コントリビューターのコミュニティはまだ数週間の歴史しかありません。

オープンソース化の発表は Hacker News で 224 ポイントと 70 件のコメントを集め、それ以前の 1.1 リリースは 100 ポイントを獲得しました（Hacker News、2026 年）。これほど新しいリポジトリとしては大きな注目ですが、拡張機能のエコシステムもコントリビューターのコミュニティも、まだ生まれて数週間です。

LevelUpGo の役割

Go といえば、多くの人はクラウドインフラ、CLI、バックエンドサービスを思い浮かべます。これについては Go 言語はどこで使われている？で紹介しています。Rune は、Go が GPU で描画するデスクトップアプリも動かせることを示しています。Wails の記事で取り上げた、Electron の代わりに Go を使うという考え方に共感したなら、Rune は webview まで取り除いて、その考え方をさらに先へ進めています。

Rune のようなコードベースは、基礎が身についていると格段に読みやすくなります。LevelUpGo の Go Basics コースでは、どのファイルにも出てくる関数、struct、slice、エラー処理を扱います。Rune のターミナルのスループット改善を支える goroutine と channel は Concurrency Fundamentals で学べます。Rune のキーボード中心のワークフローに惹かれたなら、Command Line Basics で、Rune が前提としているシェルの習慣を身につけられます。各コースの位置づけは Go のロードマップで確認できます。

よくある質問

Rune は無料なのか？

はい。Rune は macOS と Linux 向けに無料でダウンロードでき、ソースコード全体が GPLv3 で公開されています。Rune Pro は月額 $10 で、Rune Network で接続できるマシンの数が 2 台から 10 台に増えます。チーム向けのエンタープライズプランもあります。

Rune はオープンソースなのか？

はい。Unstable Build は 2026 年 9 月 12 日に、GNU GPLv3 のもとで GitHub にソースコードを公開しました。コントリビューターは自分の成果物の著作権を保持し、CLA に署名する必要はありません。同社は、Rune の収益の一部をコントリビューターに還元するプログラムも計画しています。

Rune は Windows で動くのか？

いいえ。Rune が対応しているのは、Apple Silicon と Intel の macOS 13.3 以降と、glibc 2.28 以降を備えた x86_64 および arm64 の Linux です。Windows 版のリリースはなく、ドキュメントにも予定時期は記載されていません。

Rune はどの言語に対応しているのか？

Go と Python はファーストクラスの扱いで、LSP、シンボルインデクサー、エコシステムに合わせたワークフローがそろっています。Rust と Zig はベータ版で、TypeScript はロードマップに載っています。そのほか 300 以上の言語が、tree-sitter の文法パッケージを通じてシンタックスハイライトと構造的検索に対応しています。

Rune は Rust で書かれているのか？

いいえ。Rune のコードの約 97.6% は Go です。ネイティブの OpenGL と Metal のグラフィックスパイプラインにリンクするため、エディタは cgo を有効にしてビルドされますが、エディタ本体、ターミナルエミュレーター、公式の拡張機能は Go で書かれています。Rune という名前になる前、このプロジェクトは Six、その後 Ox と呼ばれていました。