RunAnywhere SDK レビュー: 8つのSDKと1つのC++コアが端末上でモデルを動かすまで

RunAnywhere が埋めるのは「プラットフォームごとに推論コードを書き直す」コスト

iOS、Android、Web、デスクトップで同じ機能を端末内推論で提供しようとすると、通常はプラットフォームごとに異なるランタイムを呼び分けるコードが必要になる。Apple では MLX や Core ML、Android では llama.cpp や Hexagon NPU 向けのバックエンド、ブラウザでは WebGPU といった具合で、API の形もモデルの読み込み手順も揃わない。RunAnywhere はこの差を C++ コアに寄せ、その上に Swift、Kotlin、Flutter、React Native、Web などの SDK を並べる構成を取る。README の表現を借りれば「One SDK. Every device.」であり、対象はモバイルアプリ、ブラウザアプリ、デスクトップアプリのいずれかで、LLM チャットだけでなく音声認識、音声合成、視覚、埋め込み、RAG、画像生成までを同じ意味の API で扱いたい開発者である。クラウド推論のコストやデータ送信を避けたいが、プラットフォームごとに推論スタックを自作する余力はない、という状況が想定されている。

capability registry がエンジンを選び、コードはハードウェアを選ばない

このプロジェクトの中心にあるのは capability registry と呼ばれる仕組みである。各エンジンは自分が実行できる処理を登録し、デバイスに適合する中で最も優先度の高いエンジンが呼び出し先として選ばれる。README によれば優先順位は QHexRT が Snapdragon の Hexagon NPU、MLX が Apple silicon、llama.cpp がそれ以外の環境（Apple では Metal、NVIDIA ではオプトインの CUDA ビルド、ブラウザでは WebGPU）、音声と埋め込みは sherpa と ONNX、拡散モデルは Core ML という割り当てになっている。重要なのは、アプリケーション側のコードがハードウェアを直接指定しない点だ。同じ generate 呼び出しが、端末によって Hexagon NPU で処理されたり Metal で処理されたりする。ただし README は capabilities() を呼んで実際に何が実行できるかを確認するよう求めており、enum が存在することとエンジンがインストールされていることは別だと明記している。ここは設計上の割り切りとして正直に書かれている部分で、抽象化の便利さと引き換えに、実行時に何が使われるかを開発者が把握しづらくなる側面がある。

Python から CLI、Swift まで、入口は複数ある

最も短い導入は Python パッケージである。pip install runanywhere の後、ra.initialize() を呼び、ra.llm.generate() に LlmOptions(model="qwen2.5-0.5b") を渡す。README の例ではモデルは初回利用時にダウンロードされると注記されている。ターミナルから試す場合は別リポジトリの RCLI を使う。brew install runanywhereai/tap/rcli、あるいは install.sh を curl で取得して実行し、rcli run qwen3 "..." の形式で呼び出す。RCLI はこのリポジトリが公開する C++ デスクトップキットを消費する立場にある。モバイルやデスクトップ向けには Swift Package Manager 経由で RunAnywhere と LlamaCPPRuntime をインポートし、LlamaCPP.register()、RunAnywhere.initialize()、RAModelLoadRequest に modelID、category、framework を設定して loadModel を呼ぶ流れが README に示されている。Apple silicon で MLX を使う場合は RunAnywhereMLX をインポートして MLX.register() を追加する。いずれの経路も、モデルのロードと生成という2段階の構造は共通している。

8つの SDK を1つのコアで支える構成の重さ

アーキテクチャ図が示すのは、8つの SDK が1つの C++ コアの上に載り、その下に QHexRT、MLX、llama.cpp、sherpa と ONNX、Core ML、そしてクラウドという複数のバックエンドが並ぶ構造である。ハードウェア層には Hexagon NPU、Apple Neural Engine、Metal、CUDA、WebGPU、CPU が列挙されている。この多層構造は、対応プラットフォームを広げるほど検証対象が掛け算で増えることを意味する。同じ LLM 推論でも、Hexagon NPU 経由、Metal 経由、WebGPU 経由で挙動が異なりうるし、音声パイプラインは sherpa と ONNX の組み合わせに依存する。リリースが v0.20.35 から v0.20.37 へ数日おきに進んでいる点も、変化の速度を示している。バージョン番号が 0.20 台であることは、API の安定性を前提にした長期運用よりも、追従しながら使う段階にあると読める。C++ コアを共有している以上、あるプラットフォーム向けの修正が別のプラットフォームに影響する可能性は常にある。

できないことと、向かないケース

README は制約を比較的はっきり書いている。まず、LiteRT と ExecuTorch は framework の値として予約されているだけで、統合されたランタイムではない。これらを前提にした設計は現時点で成立しない。音声エージェントについては VAD、STT、LLM、TTS を1つのパイプラインにまとめ、SpeechHandle スコープの再生制御を提供するが、ウェイクワード検出は実装されていないと明記されている。常時待ち受け型の音声アシスタントを作るなら、その部分は自前で用意する必要がある。CUA（computer-use action parser）も、Fara1.5 形式のアクション文字列をビューポート座標に変換するパーサであり、自律エージェントのフレームワークではないと釘を刺している。画像生成のインペインティングは Hexagon NPU 上で、プラットフォームとバックエンドに依存する。つまり、特定の NPU でしか動かない機能が複数あり、全プラットフォームで同じ結果を期待する使い方は向かない。また、バックエンドを自分で選び、そのランタイム固有の機能を直接叩きたい場合、エンジン選択を registry に委ねるこの設計は制御を奪う方向に働く。

llama.cpp を直接使う場合との違い

比較対象として最も分かりやすいのは llama.cpp である。llama.cpp は GGUF 形式のモデルを読み込み、Metal、CUDA、CPU などのバックエンドをビルド時に選ぶ。アプリケーションはどのバックエンドで動くかを自分で把握し、モデルのロードからトークンループまでを自分で書く。RunAnywhere は llama.cpp を複数あるバックエンドの1つとして内部に持ち、その上に capability registry とプラットフォーム別 SDK を重ねる。得られるのは、音声認識や埋め込み、RAG まで含めた統一 API と、デバイスに応じた自動選択である。失うのは、バックエンド固有のオプションへの直接アクセスと、何がどこで動くかの完全な予見性だ。たとえば llama.cpp の特定の量子化設定やサンプリング制御を細かく詰めたいなら、直接使う方が早い。逆に、iOS と Android の両方で音声入力付きのチャットを出したいだけなら、プラットフォームごとに llama.cpp と sherpa を組み合わせて配線するより、RunAnywhere の API に寄せた方が記述量は減る。どちらが優れているかではなく、抽象化の層をどこに置くかの選択である。

ライセンス表記の不明瞭さと更新コスト

このリポジトリのライセンスは NOASSERTION と記録されており、README のバッジも「RunAnywhere License」と表示するだけで、MIT や Apache-2.0 のような標準識別子を示していない。つまり、一般的なオープンソースライセンスなのか、独自条項を含むのかが、この情報だけでは判断できない。商用製品に組み込む前に LICENSE ファイルの全文を読み、再配布や商用利用の条件を確認する必要がある。これは法的助言ではなく、確認すべき項目の指摘である。更新コストの面では、リリースが短期間に連続しており、cpp-desktop キットのようにプラットフォーム別のタグが切られている。C++ コアと各 SDK のバージョンを揃えて追従する運用が前提になり、特定バージョンに固定して長期間据え置く使い方は、バグ修正やモデル対応の取り込みを諦めることを意味する。RCLI のように別リポジトリがこのリポジトリの成果物を消費する構成もあり、依存関係は単一リポジトリ内で完結しない。

編集部の結論

複数のプラットフォームで同じ意味の API を使い、音声や視覚まで含めて端末内で完結させたいチームには向いている。逆に、対応エンジンが限られる特定の NPU だけを狙う場合や、バックエンドを自分で細かく差し替えたい場合は、この抽象化は邪魔になる。採用前に確認すべきは、LICENSE ファイルの実際の条項、利用予定デバイスで RunAnywhere.capabilities() が返す内容、そして対象モデルのライセンスの3点である。README が挙げるエンジンのうち LiteRT と ExecuTorch は framework 値として予約されているだけで統合されたランタイムではないため、これらを前提にした設計は避けたい。

公式情報源

1. Issues
2. Project website
3. README
4. Releases
5. RunanywhereAI/runanywhere-sdks on GitHub