1つのモジュールをターミナル・ブラウザ・SSH・AIエージェントの4画面に同時描画するRaxol、その仕組みを読む

「1つのアプリを書けば、ターミナルにもブラウザにもSSHにもAIエージェントにも出せる」──そう聞くと大抵は誇張だが、Elixir/OTP製のフレームワーク「Raxol」（GitHub: DROOdotFOO/raxol）は、README本文を読む限り実際にその設計で作られている。

3行まとめ

• RaxolはTEA（The Elm Architecture）パターンの単一モジュール（init/update/view）を、OTPのGenServerとして走らせ、ターミナル・ブラウザ・SSH・AIエージェント（MCP）の4surfaceに同時描画する
• mix raxol.codeは対話式のターミナルコーディングエージェント、bin/raxol-acpはAgent Client Protocol（ACP）でエディタから起動できる同じエージェント。すべての変更操作はALLOW/ASK/DENYの認可エンジンを通る
• GitHub実測でスター76・フォーク5（2026年8月27日確認）とまだ小規模。起源は「AGI向けターミナル」と「ガンダムのコックピットUI」という2つのアイデアの合流だとREADMEは説明している

「4つの画面に同じモジュールを描画する」という設計

READMEが示すアーキテクチャ図はシンプルだ。

                          +---> Terminal (termbox2 NIF)
                          |
  TEA module (GenServer) -+---> Browser (Phoenix LiveView)
                          |
                          +---> SSH (Erlang :ssh)
                          |
                          +---> Agent (MCP tools)

アプリケーション本体はinit・update・viewの3関数だけを持つ単一のTEAモジュールで、これがOTPのGenServerとして動く。Raxolはこの1つのモジュールを、termbox2のNIF（ターミナル）、Phoenix LiveView（ブラウザ）、ErlangのSSHライブラリ（SSH接続）、そしてMCP（AIエージェント）という4つの描画先に振り分ける。README本文の言葉を借りると、狙いは「クラッシュ分離、再起動不要のホットコードリロード、CRDTによる分散クラスタリング、そしてLLMがピクセルをスクレイピングする代わりに構造化されたComponentツリーと対話できるagent surface」を、単一のコードベースから引き出すことだという。

この比較対象としてREADMEが名指ししているのがBubble Tea・Ratatui・Textualという既存の高評価なターミナルUIレンダラー群、そしてA2UI・AG-UIというエージェント-UI間のワイヤーフォーマット規格だ。Raxolはこれらの代替ではなく「4つのsurfaceすべてを1つのソースモジュールから描画するランタイム」という立ち位置を取っている。

エージェント向けの2つの顔──raxol.codeとraxol.acp

Raxolの「Agent」欄の中身は単なるお飾りではない。README本文によれば、インタラクティブなComponent（Button・TextInputなど）は自動的にMCPツールを公開する。例えばButtonはclick、TextInputはtype_into/clear/get_valueを公開し、「focus lens」という仕組みが1回の操作に関係するツールをおよそ15個程度に絞り込む。

さらに、Raxol自体がコーディングエージェントの機能（「Code」と名付けられている）を内蔵している。

• mix raxol.code: 対話式のターミナルTUI（「axol」というキャラクターの顔≡··≡が表示される）
• mix raxol.p: そのヘッドレス版。プロンプトを引数で受け取り、標準出力に答えを返し、契約イベントを標準エラーに流す、パイプ・CI向けの実装
• bin/raxol-acp（mix raxol.acp）: 同じエージェントをAgent Client Protocol（ACP）でstdio越しに提供する。エディタ側からエージェントを起動して使う用途向けだ

これら3つの入口はすべて、ミューテーションを伴うツール呼び出し（ファイル書き込み・編集・シェル実行など）がALLOW/ASK/DENYの認可エンジンをくぐるという共通のガードを持つ。SSH経由のRaxol.Agent.Harness.McpTools（harness_start_session/harness_send_prompt/harness_read_transcript/harness_list_sessions）は、あえて読み取り専用ツールセットに絞られており、「承認プロンプトに答える人間がいない場面」ではwrite_file・edit_file・bashが最初から存在しない、とREADMEは明記している。

この設計の土台にあるのが「Harness」と呼ばれるエージェントセッションエンジンだ。永続的なイベントジャーナル（Raxol.Agent.Journal）、型付きのイベント/コマンド契約（Raxol.Agent.Contract）、イベントストリームに対する純粋なfold処理としてのsurface状態（Raxol.Harness.Projection）で構成され、claudeやcursorのような外部エージェントCLIを、Raxol自身のループと同じように監督できるという。セッションは--continue/--resume <id>で復元でき、--replay <id>はジャーナルから直接トランスクリプトを出力する。

パフォーマンス数値──README記載の自己計測

READMEには2026年8月7日時点、コミットfce2465bbでのベンチマーク結果が掲載されている。Apple M1・Elixir 1.20・OTP 29の環境で、フルフレーム（生成＋描画＋差分）の描画に5.0ミリ秒。これは60fpsの予算の31%にあたるという。

いずれも開発者自身の計測であり、第三者による独立したベンチマークは今回の確認範囲では見つかっていない。

Hex.pmで実際のパッケージ構成を確認する

READMEの記述だけでなく、パッケージレジストリのHex.pmをhex.pm/api/packages?search=raxolで直接検索し、実際に公開されているパッケージとダウンロード数を確認した。2026年8月31日時点で以下の12パッケージがヒットした。

目を引くのはraxol_paymentsで、累計3,351ダウンロードのうち3,302件が「直近」に集中している。他のパッケージが累計と直近でおおむね同水準なのに対し、決済パッケージだけ急激に伸びている格好だが、この記事ではその要因（特定プロジェクトからの一括導入なのか、ボット的なダウンロードなのか等）までは切り分けられていない。

計画は6パッケージ、実際は13パッケージに膨らんだ

作者本人が運営するブログ「droo.foo」に、Raxolの開発経緯を綴った記事「Raxol: The Terminal For My Gundam」（初出2026年5月10日、最終更新2026年8月27日）がある。この本文を直接確認したところ、次のような記述があった。

The plan was six packages. There are thirteen now, which probably says something about how much I've underestimated the scope of this thing every quarter for two years.

（計画では6パッケージだった。今は13パッケージある。この2年間、四半期ごとに自分がこのプロジェクトの規模をどれだけ過小評価してきたかを物語っていると思う）

同記事によれば、当初からの安定版6パッケージ（raxol_core・raxol_terminal・raxol_sensor・raxol_mcp・raxol_liveview・raxol_plugin）に、途中で独立パッケージ化されたraxol_agent・raxol_payments、想定外に追加された3つのsurfaceパッケージ（raxol_speech・raxol_telegram・raxol_watch）、さらに直近で加わった2つの新パッケージraxol_symphonyとraxol_acpを合わせて13になるという。Hex.pm上で確認できた12パッケージ（上表）と、ブログが言う「Hex公開済み11＋Pre-alpha 2」という内訳はおおむね符合する（Hex検索結果には集計対象になっていないパッケージが含まれている可能性があり、完全な一致は確認していない）。

raxol_symphonyはOpenAI Symphonyの移植で、LinearまたはGitHub Issuesのトラッカーをポーリングし、対応可能なタスクを取得してワークスペースごとに隔離し、コーディングエージェントを走らせるオーケストレーターだとブログは説明している。

注意が必要なのはraxol_acpだ。この記事の冒頭で紹介したbin/raxol-acp（mix raxol.acp、エディタ用のAgent Client Protocol実装）と名前が似ているが、ブログ本文によればraxol_acpパッケージが指すのは別の規格「Agent Commerce Protocol」（Virtualsのエージェントマーケットプレイスが使う決済プロトコル）である。

raxol_acp is the other one. Agent Commerce Protocol, the spec used by Virtuals' agent marketplace.

（raxol_acpはもう一つの方だ。Agent Commerce Protocol、Virtualsのエージェントマーケットプレイスが使う規格を指す）

同じ「ACP」という略称が、README側の「Agent Client Protocol」（エディタ-エージェント間のJSON-RPC規格）とブログ側の「Agent Commerce Protocol」（オンチェーン決済規格）という、意味の異なる2つの規格に対して使われている。この記事を書く過程でこの重複に気づいたが、Raxolのドキュメント側でこの命名の重複について注意書きがあるかどうかまでは確認していない。

副産物パッケージ群──決済・自己改善・チャットプラットフォーム橋渡し

Raxolのagentサブシステムは、それぞれ独立したパッケージとしても切り出されている。財布・台帳・支出上限を持ち、HTTPの402応答に対して自動決済する「Pay」（x402・MPP・Xochiクロスチェーン・Permit2・Riddlerの5プロトコル対応）、逆に売り手側として機能する「Earn」（Virtualsのジョブライフサイクルを通じてオンチェーン決済）、1回解いたタスクを再利用可能なSKILL.mdに変える「Improve」、複数チャットプラットフォームへのアダプタを共通化する「Reach」、OpenAI Symphonyのポートである「Orchestrate」、そしてエディタとAIコーディングエージェント間のJSON-RPC 2.0規格であるAgent Client Protocolを実装する「Bridge」（raxol_agent_client_protocol）が並ぶ。「Earn」と「Bridge」はREADME上「Pre-alpha」と明記されており、まだ実験段階だ。README側の「Pay」の説明とHex/ブログ側のraxol_paymentsの説明は対応する部品を指しているとみられるが、プロトコル数の内訳（README「5プロトコル」・ブログ「x402/MPP/Xochiの3つ」）が完全に一致するかどうかまでは、パッケージのソースコード本体を読んで突き合わせていない。

まだ小さいプロジェクトという実態

RaxolのGitHubページを2026年8月27日に直接開いて確認したところ、スター数は76、フォーク数は5だった。GitHub APIで同日改めて取得した数値も同じ（スター76・フォーク5・open issues 47・MITライセンス）で、READMEの記載と食い違いはなかった。README本文が語る設計思想の射程の広さ（4surface同時描画、決済プロトコル5種対応、エージェント自己改善機構）に比べると、コミュニティの規模はまだ小さい。実際に動かして4つのsurfaceが本当に同じ挙動をするかを検証したわけではなく、この記事はREADME本文・ブログ記事・Hex.pmのパッケージ一覧をもとに書いている。

作者はREADMEの「Origin」欄で、Raxolの出発点を「AGI向けの端末（AIエージェントが人間と同じように本物のターミナルエミュレータと対話する）」というアイデアと、「ガンダムのウイングスーツのコックピット向けインターフェース（フォールトアイソレーション・リアルタイム応答性・センサーフュージョンが生死を分ける）」というアイデアの合流だったと説明している。「ガンダムの話は冗談に聞こえるかもしれないが、制約条件を見るとまさにOTPが作られた目的そのものだ」という一文は、この手のREADMEにしては珍しく率直だと感じた。ブログ側でも同じ起源が「Two problems, one shape」という節で語られており、AIエージェントがターミナルの画面状態を読み取れずhtopを諦めた、という具体的なエピソードが起点として書かれている。

Raxolを使った実例としてREADMEが挙げているのは、クロスチェーンDEX「Xochi」（トレーディング画面全体がRaxol製で、1つのComponentツリーからSSHトレーダー端末・LiveView Web UI・ソルバーエージェントsurface・運用コックピットの4つを投影しているという）と、SSH専用のレトロ掲示板「foglet-bbs」の2件だ。

raxol_acpとraxol_symphonyの実装レベルまでは確認できていない

この記事はREADME・作者ブログ・Hex.pmのパッケージ一覧という3種類の一次情報を突き合わせて書いたが、次の点は確認できていない。

• raxol_acpとraxol_symphonyはHex.pm検索に出てこず（Pre-alpha扱いのため未公開とみられる）、実際のソースコードやテストの有無は確認していない
• ブログが述べる「v0.1エンジニアリングは完了」「オンチェーンクライアントは実物のReqベースJSON-RPC」という主張は、この記事ではソースコード本体まで開いて検証していない
• raxol_paymentsのダウンロード数が他パッケージと比べて突出している理由は特定できていない
• Elixir/OTPでのGenServer・termbox2 NIFの実際の挙動を手元の環境で動かして確かめたわけではなく、この記事はドキュメント本文の記述をそのまま紹介している

関連記事: MCP（Model Context Protocol）とは / Agent Client Protocol(ACP)とは / AIエージェント決済（x402/AP2）は今どれだけ動いているのか

感想・指摘はコメント欄へ。