Operit AI 評価：Android 端末内で完結するエージェント実行環境の実像
The most powerful AI agent and AI chat software on Android/Operit是一款Android上能力最为强大、发展最久的AI Agent
ひと目でわかる
- これは何？
- Android 8.0 以降の ARM64 端末で、クラウドまたはローカルのモデルに端末操作・ターミナル・ブラウザ・ファイル操作を委ねる Kotlin 製エージェント。LGPL-3.0 の Android 専用実装であり、後継の Operit 2 とは別リポジトリである点を踏まえて評価する。
- 誰に向いている？
- 採用すべきなのは、Android 端末を開発・自動化の実行環境として使いたい個人開発者、および端末内で完結するローカル推論を試したい人である。クラウドの推論基盤として使いたい場合や、iOS・デスクトップを同じ構成で揃えたい場合には向かない。
- 商用利用できる？
- 条件付きでできます。LGPL-3.0 は弱いコピーレフトのライセンスで、商用やクローズドソースのソフトウェアにも組み込めますが、このソフトウェア自体のファイルを改変して配布する場合は、その変更を同じライセンスで公開する必要があります。
- 今もメンテナンスされている？
- されています。直近 1 日以内に新しいコミットがあります。
- 何の言語で書かれている？
- 主に Kotlin です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月15日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Operit が埋めようとしている穴は「スマホがエージェントの実行主体になれない」こと
デスクトップのエージェントは、シェル、ファイルシステム、ブラウザを最初から持っている。Android にはそのどれも標準では存在しない。Operit はこの欠落を埋めるために、モデルと Android システムの間にツール実行層を置く。README の説明では、Operit AI は「Android 上で動作するオープンソースの AI Agent プラットフォーム」であり、モデルを Android システム、ターミナル、ブラウザ、ファイル、プロジェクトワークスペースに接続し、ツール呼び出しとワークフローを通じて情報検索、ファイル処理、コード開発、デバイス自動化を実行する。
対象読者は明確である。PC を開かずにスマホだけでコードを書き、端末を自動操作し、ローカルモデルを動かしたい人。逆に、サーバ上のバッチ処理や CI に組み込みたい人には、この設計は噛み合わない。実行主体が端末そのものだからだ。
モデル選択とローカル推論：MNN と llama.cpp を同じアプリ内に抱える構成
README の「AI 对话与模型」節によれば、対応する API 形式は OpenAI Chat/Responses、Anthropic、Gemini と、その互換サービスである。加えて ToolPkg でモデル提供元そのものを拡張できる。用途ごとにモデルを割り当てられる点は実務的で、チャット、記憶、要約、UI 制御に別々のモデル設定を指定できると明記されている。
ローカル側は二系統ある。組み込みの MNN 推論と、llama.cpp による GGUF モデルの実行である。GGUF 対応は v1.8.1（2026-02-03）で追加されたとリリース摘要に記されている。Ollama や LM Studio のようなローカル模型サービスへの接続も可能だ。
ここで注意したいのは、ローカル推論は端末のメモリとストレージを直接消費するという点である。README の「快速开始」表は、メモリとストレージの占有量がターミナル環境、インストール済みツールパッケージ、ローカルモデルに依存するとし、モデルをダウンロードする前にモデル側の説明に従って空き容量を確保するよう求めている。具体的な推論速度や消費量の数値は提示されていない。この点は採用前に自分の端末で確かめるしかない。
ツール権限は三档、UI 自動化は三系統：端末を触る許可の設計
エージェントが端末を操作する以上、権限の粒度が設計の中心になる。README はツール権限について「自动允许、每次询问和禁止三档工具权限设置，默认采用询问模式」と述べている。既定が自動許可ではない点は、この種のアプリとしては慎重な側に振っている。
UI 自動化の実行経路は三つある。アクセシビリティ、Shizuku 経由の ADB 相当のデバッグ権限、Root チャネルである。PhoneAgent/AutoGLM は画面の視覚情報と組み合わせて操作を実行し、仮想表示などの機能には対応する権限と端末側の対応が必要になる。つまり、できることの上限は端末の状態で決まる。Root なし、Shizuku なしの端末では、アクセシビリティで届く範囲に操作が限定される。
ブラウザ側も同様に階層がある。内蔵ブラウザはマルチタブ、履歴、ブックマーク、ダウンロード、権限、マルチウィンドウ、ユーザースクリプトを備え、ブラウザエージェントはページ構造を読み取ってクリック、入力、スクロール、キー操作、スクリーンショットを実行する。UI 自動化とブラウザ自動化は別経路であり、同じ「操作」でも失敗の仕方が違う。
Ubuntu 24.04 ユーザ空間と PRoot：スマホを開発機にする場合の現実的な制約
「项目工作区与终端」節によれば、内蔵の Ubuntu 24.04 ARM64 ユーザ空間は既定で PRoot 上で動作し、条件が揃えば chroot も使える。PRoot はカーネル名前空間を使わず ptrace でシステムコールを仲介する方式なので、chroot と比べて syscall のオーバーヘッドが乗る。ビルドやパッケージ操作の速度はこの層の影響を受ける。README はこの速度差について数値を出していない。
ワークスペース側は Web、Android、Flutter、Node.js、TypeScript、Python、Java、Go のテンプレートを用意し、ファイルツリー、コード編集、シンタックスハイライト、ライブプレビュー、変更追跡、バックアップ、エクスポートを提供する。ファイルシステムはアプリ内部ディレクトリ、SAF、SFTP、SSH に対応する。チャットをワークスペースに紐づけると、AI がプロジェクト規約を読み、ファイルを参照してコードを変更する。
ターミナルはマルチセッション、Python、Node.js、vim、SSH、tmux、カスタムキー、ソフトウェアソースに対応する。Logcat、SQLite、Git、APKTool、HTML パッケージングといった開発ツールも同梱される。ツール群の幅は広いが、いずれも arm64-v8a 上で動く必要がある。
インストール手順と、最初に触る設定キー
配布は APK のみである。README の「快速开始」表は、Releases ページから最新 APK をダウンロードし、公式サイトでチュートリアルを見る流れを示している。インストール手順は「下载 APK → 安装并启动 → 按引导配置模型与权限 → 开始使用」の四段階。
システム要件は Android 8.0（API 26）以上、かつ ARM64（arm64-v8a）のみ。x86 や 32 ビット ARM の端末は対象外である。これはエミュレータでの検証を難しくする。
設定面で押さえるべき項目は README に列挙されている。ツール権限の三档（自动允许 / 每次询问 / 禁止、既定は询问）、用途別モデル割り当て、密钥池と连接测试、そしてローカル推論を使う場合の MNN または llama.cpp の選択である。
ネットワーク面では、可选的局域网 Web Chat 和 HTTP API 默认关闭，启用时需要配置 Bearer Token 并评估局域网暴露风险、と明記されている。有効化する場合はトークン設定と露出範囲の確認が前提になる。Android Intent やブロードキャスト連携も信頼できるアプリにのみ渡すべきだと README は注意している。
データの所在と外部通信：どこまでが端末内で閉じるか
README の「数据与网络边界」記述は明確である。聊天、角色、记忆和模型配置由应用保存在本地。つまり会話、キャラクター、記憶、モデル設定はアプリが端末内に保存する。クラウドモデルを使う場合、リクエストは端末から利用者が設定したサービス提供元へ送られ、Operit はチャット推論をホストしない。
一方で、市场、MCP、Skill、语音、绘图 といった機能は第三者サービスに接続する可能性がある。ローカル完結を売りにしつつ、拡張機能の経路は外部に開いている。この非対称性は把握しておく価値がある。記憶やキャラクターカードを端末外に出したくないなら、市場系と音声系の設定を個別に確認する必要がある。
セキュリティ面では、公式 Releases ページまたは公式サイト以外からインストールパッケージを入手しないよう README が警告している。改変された APK はデータと端末の安全リスクになる。
LGPL-3.0 であることの実務的な意味と、更新コストの見積もり
ライセンスは LGPL-3.0。GPL 系と違い、ライブラリとして組み込んで自作物とリンクさせる形態には条件緩和があるが、Operit 自体を改変して配布する場合は、その改変版に対するソース提供义务が及ぶ。APK を fork して社内配布する、あるいは改造版をストア外で配る、といった使い方を想定するなら、この点は法務ではなく工数の問題として先に効いてくる。法的判断はここでは扱わない。
更新コストは小さくない。リリースは v1.11.0（2026-05-16）、v1.12.0（2026-07-01）、v1.12.1（2026-08-08）と約一か月半から二か月間隔で続いており、各版で機能追加と修正がまとまって入る。v1.12.0 では统一市场与 Artifact 流程、工作区与 ToolPkg 运行时の強化、多言語・音声・メディア能力の拡張、崩溃恢复能力の向上が挙げられている。追従しない選択もあるが、その場合は端末側の権限まわりの修正を取り逃す可能性がある。
もう一つ見落とせないのは、このリポジトリが Android 版であり、後継の Operit 2 が別リポジトリとして存在することだ。README は Operit 2 を「独立的第二代实现」とし、Rust 共享运行时、Flutter 客户端、operit2 CLI/TUI を中核に、Android、iOS、Windows、macOS、Linux、Web の実装またはビルド経路を含み、OpenHarmony 适配を進めていると説明する。今から新規に触る人が、Android 単体で完結する Operit とクロスプラットフォームの Operit 2 のどちらに投資するかは、最初に決めるべき分岐点である。
向かないケースと、比較対象としての Termux + エージェント構成
Operit が適さない場面はいくつかある。第一に、iOS やデスクトップと同一の構成を揃えたい場合。Android 版は Android 専用であり、その役割は Operit 2 が引き受ける建て付けになっている。第二に、x86 エミュレータ上で自動テストを回したい場合。arm64-v8a のみという制約がそのまま障害になる。第三に、端末のルート化や Shizuku 導入を組織として許可できない場合。UI 自動化の到達範囲がそこで頭打ちになる。
比較対象として素直なのは Termux 上にエージェントを組む構成だ。違いは統合の度合いにある。Termux はシェルとパッケージ管理を与えるが、GUI 自動化、記憶空間、キャラクターカード、ツール権限の三档管理、統一市場は持たない。逆に Operit は、Termux が提供する自由なパッケージ操作の一部を、アプリ内の Ubuntu 24.04 ユーザ空間と PRoot という固定された経路に置き換える。何でも自分で組む代わりに、用意された統合を使うという取引である。
もう一つの比較軸はモデルの置き場所だ。Ollama や LM Studio を別マシンで動かし、Operit をクライアントとして使う構成は、端末のメモリを消費せずに済む。端末内の MNN や llama.cpp はオフライン性と引き換えに、端末の空き容量と発熱を要求する。どちらが正しいかは、ネットワークが常時あるかどうかで決まる。
編集部の結論
採用すべきなのは、Android 端末を開発・自動化の実行環境として使いたい個人開発者、および端末内で完結するローカル推論を試したい人である。クラウドの推論基盤として使いたい場合や、iOS・デスクトップを同じ構成で揃えたい場合には向かない。導入前に確認すべきは、arm64-v8a 以外が除外されること、ツール権限の既定が「每次询问」であること、Web Chat と HTTP API が既定で無効であり有効化には Bearer Token 設定が要ること、そして LGPL-3.0 の下で改変版 APK を配布する場合のソース開示義務の範囲である。
コミュニティノート