Waku がコーディングエージェントのCLI群をネイティブなローカルデスクトップアプリに統合

Why it matters

Coding agents are multiplying faster than their interfaces. Waku is betting the durable layer will be a local, provider-neutral record of agent work and code state.

Waku の現行バージョン 0.1.0 は、開発者が既に使っている coding-agent コマンドラインツールのためのネイティブデスクトップ制御プレーンだ。Rust と GPUI で構築されており、Waku はセッション、トランスクリプト、ツールのアクティビティ、リポジトリのチェックポイントを1つのローカルアプリケーション内に収集する。

ビルダーは明確なプロダクト賭けをしている。複数のコーディングエージェントを使う開発者にとって、別のエージェントやモデル、エディタが必要というわけではない。各エージェントが何をしたかを確実に見られ、処理を中断し、会話を継続し、タスクが失敗したときに復旧できる信頼できる場所が必要なのだ。

その決定は Waku のほぼ全ての部分を形作っている。Electron を避け、作業データをユーザーのマシン上に保存し、既存のエージェント CLI とその構造化されたインターフェースを通じて接続する。アプリケーションはそれぞれ異なるイベントストリームを受け取り、プロバイダに依存しない単一のモデルへと翻訳する。

エージェントを超えた一つのインターフェース

Waku は開発者に新しいエージェントランタイムの採用を求めるのではなく、既存のツールを駆動するように設計されている。Waku の 製品ページ によれば、アプリケーションは stream-JSON、JSON-RPC、ライブイベントなどのインターフェースを通じて接続し、各プロバイダに対して利用可能な最も強力な接続を選択するという。

Waku が公開したスクリーンショットには、基盤となるドライバ層に Amp、Claude Code、Codex、Cursor、OpenCode、Grok、Pi が表示されているように見える。アーキテクチャの狙いは、これらのプロバイダを各々の認証や実行経路を保持したまま、共通のタイムライン上のセッションとして見せることだ。

このアプローチは、Waku の背後にいる開発者にとって、単なるモデルラッパーを作るのとは異なる仕事を与える。サポートされる各 CLI はイベントスキーマ、セッション形式、再開挙動を独立して変更し得る。Waku の価値は、それらの差異をアダプタがどれだけ吸収できるか、そしてプロバイダがツールを更新したときにどれだけ早く回復できるかに依存するだろう。

インターフェースはキーボード優先だ。Waku によれば Command-N でセッションを開始し、Return はエージェントが作業中でも別のプロンプトをキューし、Command-Return はアクティブターンを操り、Escape は停止させるという。これらのコントロールは、エージェントの作業を孤立したチャットメッセージの連続ではなく、監督が必要な継続的なプロセスとして扱っている。

ロールバックがコアの製品判断であること

Waku の最も重要な機能はトランスクリプトの下にある。すべてのプロンプトは隠し Git リファレンスの下で作業ツリーのチェックポイントを作成する。開発者はその後、リポジトリと関連するプロバイダとの会話を一緒に復元できる。

その組み合わせが重要なのは、チャットログだけではエージェントの作業の不完全な記録に過ぎないからだ。コーディングエージェントはファイルを読み、コマンドを実行し、複数ターンにわたってリポジトリを編集する。古いメッセージを開き直しても対応するコードを復元しなければ、会話と作業ツリーが同期しないままになる。

Waku のビルダーは事実上プロンプトをトランザクション境界として扱っている。各命令は会話の状態をリポジトリの状態に結び付ける。エージェントが誤ったアプローチを取ったり、過度に広範な変更を行ったり、診断が難しい状態でプロジェクトを残した場合に戻る道を作るのだ。

この仕組みはまた、Waku を一般用途のエージェントダッシュボードよりも明確な役割にする。開発者が何を頼んだか、エージェントが何を報告したか、その時点でコードがどう変わったかのローカルな記録になる。

ネイティブソフトウェアは賭けの一部である

Rust と GPUI の選択は Waku の訴求点の中心だ。GPUI は Zed のチームが作った GPU 加速インターフェースフレームワークだ。

Waku のホームページは、ネイティブアプリケーションは Electron を回避し、即時起動と長いトランスクリプトのなめらかなナビゲーションを提供すると述べているが、独立した性能測定を公開はしていない。

Waku はまた、プロジェクト、トランスクリプト、セッション、プロバイダ識別子がディスク上に残り、Waku アカウント、テレメトリ、ホストされた仲介者がないと述べている。そのローカルアーキテクチャは Waku が運用するインフラの量を削減し、開発者にアプリケーションの記録の直接的な管理を与える。

ただし、基盤となるコーディングエージェントをローカルにするわけではない。プロンプト、コード、ツール出力はユーザーが選択したエージェント CLI とモデルプロバイダの挙動とポリシーに従う。Waku は自身のストレージレイヤーを制御するが、その下にあるプロバイダを置き換えるものではない。

配布については、Waku はアプリケーションに署名と公証がされており、Sparkle がバイナリデルタによる自動更新を扱うと述べている。この詳細は、エージェントベンダーがインターフェースを変更するたびに統合に修復が頻繁に必要になり得る若いデスクトッププロダクトにとって重要だ。

コーディングエージェントの制御プレーンは混雑しつつある

Waku は、コーディングエージェントの周りのインターフェースが独立したプロダクトカテゴリーになりつつある状況で登場する。OpenAI introduced the Codex desktop app は 2月2日に macOS 向けに、3月4日に Windows サポートを追加した。Codex は複数のエージェントをプロジェクトスレッドと分離されたワークツリーに整理するが、OpenAI のエージェントスタックを中心に据えている。

Zedのエージェントシステム はネイティブエージェント、Agent Client Protocol を通じて接続された外部エージェント、ターミナルベースの CLI セッションをサポートする。エディタ内で複数のスレッドを並列に実行することも可能だ。

cmux、コーディングエージェントを監督するためのネイティブ macOS ターミナルは、垂直タブ、通知、ソケット制御 API という別の近接するアプローチを取っている。

Waku はより狭い独立した役割を選ぶ。それは完全なエディタでもなく、ファーストパーティのモデルインターフェースでもない。開発者はプログラマーが複数のエージェントのサブスクリプションや CLI を保持し続けると賭けており、それらの上の中立的なデスクトップレイヤーに対する需要を生むと期待しているのだ。

バージョン 0.1.0 は、実際のプロバイダの変化の下でその中立性を証明しなければならない。セッションが正しく再開され、ツールイベントが意味を保持し、チェックポイントが開発者が期待する正確な状態を復元する場合にのみ、統一されたタイムラインは有用だ。これらの信頼性の詳細が、Waku が日常的なインフラになるか、あるいは興味深いデモを確認するためだけに開かれる別のインターフェースにとどまるかを決定するだろう。

ホームページの一文「"YNot backed by Y Combinator"」は資金調達の発表というより言葉遊びだ。Waku の現在のケースは製品自体にかかっている：増え続けるエージェント端末の山を、一つの高速で可逆的なワークフローに変えようとするビルダーの試みである。