コーディングエージェントは、なぜ黒い画面ばかりなのか — JUCE作者が出したGUIツール「Juggler」

いまAIコーディングエージェントの主流は、ほとんどが黒いターミナルの中にいる。Claude Code もそうだし、各種のCLIエージェントもそうだ。プロンプトを打つと、AIがファイルを読み、コマンドを実行し、差分を書き込む。速いし、慣れれば強力だ。でも、AIが「いま何を根拠に、どのファイルをどう触ろうとしているのか」を、私たちは薄い文字の流れから読み取るしかない。

Juggler は、その状況に対する「それ、GUIでよくない？」という問いかけだ。

作者が誰かを聞くと、少し背筋が伸びる。オーディオ開発の世界で30年以上使われてきたフレームワーク JUCE、DAWの Tracktion、DSP言語の Cmajor を作ってきた人物だ。つまり「開発者向けのツールを長く作り込んできた職人」が、AIコーディングのCLI体験に不満を持ち、「もっとまともなUXがあるはずだ」と自分で作り始めた——それがJugglerの出自になる。

Jugglerは何をするツールなのか

ひとことで言えば、AIコーディングエージェントを「見て・操作する」ためのビジュアルワークベンチだ。公式は "a visual workbench for AI coding agents" と表現している。

核になるのは、AIがコードベースに対して行おうとしていることを、透明に見せる思想だ。ツールコール（AIがどのツールをどう呼んだか）は検査可能な形で表示され、会話スレッドは分岐できる。文脈（コンテキスト）は編集可能で、AIに渡す情報を人間が手で整えられる。ローカルでもリモートでも、その両方でも動く。

技術的に一番おもしろいのは、セッションを CRDT（Conflict-free Replicated Data Type）で管理している点だ。これによってスレッドの分岐、undo/redo、複数クライアント間の同期が成立している。Hacker News でも、この「セッションそのものをCRDTのドキュメントとして扱う」設計にはまっとうな称賛が集まっていた。地味に聞こえるが、これは効く。

そしてもうひとつ、思想を感じるのが引き算のほうだ。Electron を使わない。テレメトリを送らない。 昨今のデスクトップアプリが当然のように積んでくるこの2つを、あえて外している。動作の軽さと、手元のコードが外に漏れない安心感。長年ネイティブなツールを作ってきた人らしい判断だと思う。

モデルは特定のベンダーに縛られず、Claude、OpenAI、Gemini、Ollama などに対応する。ローカルのOllamaで動かせるということは、コードを一切クラウドに出さずにエージェントを回すこともできる、ということだ。

「可視化」が効くのはどんな場面か

機能を並べるだけでは、この手のツールの価値は伝わりにくい。「で、それがあると何が変わるのか」を具体的に考えてみる。

一番わかりやすいのは、AIの暴走を「事前に」止められることだ。CLIエージェントに大きめのタスクを投げて、気づいたら意図しないファイルまで書き換えられていた——という経験は、この手のツールを使う人なら一度はあるはずだ。ツールコールが検査可能な形で見えていれば、AIが「何をどうしようとしているか」を実行前・実行中に把握できる。差分を後から慌てて戻すのではなく、危ない動きをその場で押しとどめられる。

次に、「試行の分岐」がコードレビューの形を変える可能性がある。スレッドを分岐できるということは、「このリファクタをAパターンで進めた場合」と「Bパターンで進めた場合」を、別々の枝として並行して育てられるということだ。CLIだと一本道で進みがちな試行錯誤が、ツリー状に展開できる。実装方針を迷っているとき、両方をAIに走らせて見比べる——というワークフローが自然になる。

さらに踏み込むと、CRDTベースのマルチクライアント同期は、**「AIエージェントとのペアプロを複数人で覗く」**未来につながりうる。同じセッションを別のクライアントから同期して見られるなら、片方が方針を指示し、もう片方が文脈を編集する、といった分担も理屈のうえでは成立する。ここは現時点でどこまで実用的かは未知数だが、「エージェントとの作業を共有可能なドキュメントにする」という土台があるからこそ描ける絵だ。

正直に気になるところ

期待を書いたので、引っかかる点も同じ熱量で書いておく。

まず、CLIの速さと引き換えになるものがある。GUIは可視性を得る代わりに、操作のテンポや自動化のしやすさで不利になりやすい。ターミナルに慣れ、スクリプトやパイプでエージェントを組み込んでいる人にとって、GUIは「わざわざマウスに戻される」感覚になるかもしれない。可視化の恩恵と操作コスト、このトレードオフをどう感じるかは人による。

次に、エコシステムの厚み。Claude Code や Cursor は、周辺の拡張・ノウハウ・コミュニティが積み上がっている。Jugglerは出たばかりで、その蓄積はこれからだ。OSSなので伸びしろは大きいが、「今すぐ実務のメインに据える」には情報が少ない段階でもある。

そして、これはネガティブではなく期待なのだが、「職人が作ったUX」がどこまでスケールするかは見ものだ。個人〜少人数の思想が濃いツールは、鋭い代わりに万人向けの角を残していることがある。そこが磨かれるのか、あえて尖ったまま行くのか。

どんな人が触るべきか

刺さるのは、AIエージェントに「任せきり」にすることへ、うっすら不安を感じている人だ。何をされているか見えないまま差分だけ受け取る運用に違和感がある人、大きなリファクタをAIに投げる前にツールコール単位で挙動を確認したい人、そしてコードをクラウドに出さずローカルのモデルでエージェントを回したい人。この層にはかなり相性がいい。

逆に、CLIの速度と自動化がすでに体に馴染んでいて、可視化より手数を優先したい人には、無理に乗り換える理由はない。両者は競合というより、別の哲学の道具だと捉えたほうが正確だと思う。

「コーディングエージェント＝ターミナル」という空気が固まりかけた今、あえてGUIで、しかも透明性を軸に殴り込んだJugglerは、単なる新ツール以上に「AIとの作業をどう可視化するか」という問いを投げている。触ってみたい人はJuggler公式サイトから確認してほしい。オープンソースなので、中身を読んで判断できるのも強みだ。