×

Arshes Remote Editor Protocolを公開した

Arshes（アーシェス）というのは私が趣味で開発しているシェーダーカメラiOSアプリのことで、現在外部テスト公開中である。 Arshesではユーザーがシェーダーを使ってカメラエフェクトを作って公開できる、いわゆるUGCプラットフォームになっている。

Remote Editor

アプリ内にはこんな感じのエディタ画面があって、Slangシェーダー言語を書くことができる。

しかし、スマホでシェーダーを書くのはやっぱり大変なので、arshes-cli というCLIを作って、PCと接続することでPCでシェーダーを書けるようにした。これをArshesのRemote Editor機能と呼んでいる。

GitHub - shivaduke28/arshes-cli · GitHubgithub.com

arshes serveでローカルサーバーを立ち上げてファイルを監視し、VSCodeなどからファイルを変更するとアプリにシェーダーを送って、アプリ側でコンパイルする。

コンソールにはこんな感じでコンパイル結果が出力されるので、それを見つつコードを書く。

詳細は以前書いた記事を参照してほしい。 ArshesのシェーダーをPCから編集できるようにする

ローカルMCPサーバー

その後の進展として、arshes mcpを実行するとMCPサーバーとして起動できるようにした。 .mcp.jsonにこんな風に書くと、Claude Codeがarshes-cliをMCPサーバーとして使ってくれる。

{
  "mcpServers": {
    "arshes": {
      "command": "arshes",
      "args": ["mcp"]
    }
  }
}

MCPサーバーの中身はこんな感じ。

Tool

内容

get_status

Arshesアプリが接続状況とWebSocketサーバーアドレスを取得する

get_shader_spec

Arshesで使用できるSlangの仕様を取得する（アプリが接続後にサーバーに送る）

compile_shader

Arshesアプリにシェーダーを送ってコンパイルさせる

get_shader

アプリがサーバーに送ってきたシェーダーがあれば取得する

MCPサーバーはArshesの開発においても大変便利で、動作確認用のシェーダーをその場で書かせてバグってないかをClaude Codeが確認してくれる。 compile_shaderはコンパイルに成功するとレンダリング結果をjpgファイルで返すので、Claude Codeがそれを見て判断もしてくれる。 テスト用のシェーダーをいくつか用意していて、周辺機能を触ったらそれらを通して実行する、とかが自動で行われて快適である。

リモートMCPサーバー？

ローカルMCPサーバーが動くようになると、スマホアプリでということもあって、出先でもAIに書かせたいという声がユーザーから出てくるようになった。 リモートMCPサーバーを作るとなると、結構考えることが増えてくる。 ユーザーがarshes mcpをクラウド上にデプロイするという手もあるし、 ArshesがプラットフォームとしてマネージドなMCPサーバーを立てて、ユーザーに使わせるということも考えられる。

そうするとArshesのRemote Editor機能は接続先が４パターンあるということになる。

  1. arshes serveで起動したローカルサーバー
  2. arshes mcpで起動したローカルMCPサーバー
  3. ユーザーが立てたリモートMCPサーバー
  4. プラットフォームのマネージド リモートMCPサーバー

多くて大変！ 特に、４つ目は サーバー : アプリ = 1 : N なのが大きな違いである。 サーバー上でアプリとMCPクライアント（e.g. Claude Code、Codex）を対応づける必要がある。 本格的にやるならMCPサーバーの認可の実装をする必要があるし、 そうでなくてもプラットフォームがAPI Keyを発行して、MCPクライアントがそれをリクエストに含めるくらいのことはした方が良さそうである。

こういうことを考え始めると、だんだん話が複雑になってきていて、Arshesアプリとしての振る舞いをどう規定するべきかわからなくなってくる。 それで、サーバーはマネージドもサードパーティも色々あるとして、Arshesアプリとサーバーの間の取り決めを Arshes Remote Editor Protocol として決めてしまうことにした。

例えば、接続時のhandshakeはこんな感じになった。

helloではアプリはサーバーに”token”を送る。 これが何のtokenかは決まっておらず、サーバーは使っても使わなくてもよい。 例えば、arshes serveやarshes mcpで立てたローカルサーバーについてはtokenは不要であろう。 ユーザーが立てたリモートMCPサーバーの場合は一応何らかのシークレットとかを指定したくなることもあると思うので、そういう場合はtokenを使ってもらう。 プラットフォームのマネージドMCPサーバーの場合は、Arshesはアカウント認証にFirebase Authを使っているので Firebase AuthのJWTを送って、サーバーで検証するんじゃないだろうか。実装方法は色々ありそうだけど、ともかくtokenを送るようにしておけば良さそうと踏んでこの仕様にした。

なんか見落としなどがあれば教えていただけると嬉しい。

早いところArshesをシェーダーを書かない層にとって使いやすいアプリにしてストアに公開したいのだけれど、結局こういうプロトコルとかAPI設計とかが面白くて、なかなか進んでいない。 リモートMCPサーバーはわかりやすい課金要素ではあると思うので、勉強もかねて認可の実装をしてみようかと思う。 今はシェーダー書いてるユーザーは自分含めて10人もいないので一旦はFly.ioとかになりそう。

Continues

Continued by

References