2026 年 4 月時点の検証内容です。OPPO 系 Android 端末（ColorOS）+ 各種クライアントで確認しています。「自分のユースケースには合わなかった」というレビューであり、各ツール自体の良し悪しを断じるものではありません。AOSP / Pixel / Galaxy 等、別ベンダー UI では挙動が異なる可能性があります。

Quick Answer

Android から自分の Claude Code（claude -p ラッパー）を操作する方法として Termux・VSCode Web・Parsec など 5 方式を実機検証した。自由文入力・音声・日本語 IME・回線断耐性・双方向 push を同時に満たすものはなく、Discord を入口にした自作ワーカーで Real E2E 11,148 ms を達成した。

TL;DR

寝る前のベッドや外出先から、自宅サーバー上で動いている Claude Code にチャット感覚でタスクを投げて結果を受け取りたかった
Android × Claude Code 運用候補として 5 方式を実機で試した が、自分の要件（自由文／音声入力／日本語 IME／回線断耐性／Bot 抜きの双方向）にすべて合致するものはなかった
結果、Discord を入口にしたラッパーを自作 し、Real E2E で 11,148 ms の round-trip を達成した
5 方式の比較と「なぜ自作に倒れたか」を、後追いの人が同じ袋小路で時間を溶かさないように残しておく

評価した 5 方式（先に結論）

方式	主用途	自分の要件で外れた点
Anthropic 公式 Remote Control	ブラウザ / モバイル UI から自社環境のエージェントを操作	自前の `claude -p` ラッパーや任意 CLI を直接叩く想定ではない
Termux + mosh / OpenSSH	Android で Linux ターミナルを再現	バックグラウンド制限と回線断で SSH セッション維持が難しい
VSCode Web (code-server / vscode.dev)	ブラウザ上のコードエディタ	拡張機能を載せたタブの消費が大きく、モバイルでは常用しづらい
Parsec	低遅延リモートデスクトップ	文章入力中心の用途では往復遅延が大きい
Google Remote Desktop	Chromium 上の RDP	音声入力（ブラウザ Speech API）が動作対象外
自作（Discord 経由 worker）	自由文チャット → `claude -p` → Discord 返信	採用。要件をすべて満たしたのはこの形のみ

何をしたかったか

簡単に言うと、

スマホで Discord に「このバグ直して」と打つと、自宅の Ubuntu サーバーで claude -p が動いて、Discord に結果が返ってくる

という「PC を開かずに Claude Code を回す」運用を作りたかったのが出発点です。

具体的なシーン:

寝る前のベッドで、書きかけの PoC のレビューや TODO 整理を投げて、朝起きたら結果が来ている
外出先で「このエラー、何？」というスタックトレースを送って、調査結果だけ受け取る
移動中に音声入力でざっくり投げて、机に戻った時に整理されている

要件を整理すると、こうなります:

要件	説明
自由文	コマンドではなく自然言語で投げたい
音声入力	移動中に手を使わず投げたい
日本語 IME	スマホで普通に日本語が打てる
回線断耐性	電車・地下鉄・WiFi 切替で接続が切れても自然に再開
双方向	投げっぱなしでなく、結果が返ってくる（push）
任意 CLI	`claude -p` だけでなく自分のラッパーを呼べる
既存資産	サーバー側はすでに動いている systemd / SQLite / Discord Bot 資産を流用したい

この 7 つを 同時に満たす方式 を、5 種類試したけれど見つからなかった、というのが本記事の主題です。

各方式の評価

(以下、各方式について「何ができるか／何が要件と合わなかったか／どんな用途なら向くか」を 断じない言い回し で書く。"NG" や "壊れている" ではなく "自分の用途では満たせなかった" 表現に統一)

方式 1: Anthropic 公式 Remote Control

何ができるか

Anthropic 公式が提供している、ブラウザやモバイルから Claude Code をリモート操作できる仕組み
自分のローカル環境で動いている Claude Code セッションをリモートデバイスから「指示する」用途に向く

自分の要件で合わなかった点

想定されているフローは「公式が用意したインタラクション層を経由して Claude Code を操作する」もので、自前の claude -p ラッパー（独自の前処理 + idempotency / rate limit / sandbox 層）を Discord 経由で叩くような構成は設計の主眼ではない
自分の場合、Claude Code を呼ぶ前に「Discord メッセージ → idempotency check → rate limit check → sandbox 内 claude -p」という前段が必要で、ここに公式 RC を挟む利点が薄かった

こんな用途には向く

純粋に「PC 前の Claude Code セッションをモバイルからピンポイントで操作したい」場合
自前の前処理・後処理層を持たないシンプルな運用

方式 2: Termux + mosh / OpenSSH

何ができるか

Android 上で Linux 環境（パッケージマネージャ込み）を動かせる
mosh で接続安定性を上げ、SSH キーで自宅サーバーに入って claude -p を直接叩く運用が理屈上は可能

自分の要件で合わなかった点

Android のバックグラウンド実行制限により、画面を消しているうちに Termux のセッションが落ちることがある
mosh で多少緩和されるが、地下鉄や WiFi 切替などで完全に圏外になる時間が一定以上続くと再接続に手作業が要る
ターミナル前提の操作になるため、「自由文で投げて結果を別の場所に押し出す」モバイル特有の使い心地 にはならなかった
音声入力経由でターミナルに長文を流し込むのは、IME と shell の組み合わせ的にもストレスが大きい

こんな用途には向く

通信が安定している環境（自宅 WiFi 内）で軽い保守作業をする
ターミナル操作に慣れていて、画面を消さずに作業できる場面

方式 3: VSCode Web (code-server / vscode.dev)

何ができるか

code-server を自宅サーバーで起動するか、vscode.dev をブラウザで開くことで、Android Chrome / Firefox 上に VSCode の UI を再現できます。VSCode の統合ターミナルから claude -p を直接叩けるので、構成としてはストレートに「IDE 越しに Claude Code を呼ぶ」が成立します。

自分の要件で合わなかった点

実装上は動くのですが、Android で常用するにはオーバースペック でした。具体的には:

TS Language Server や ESLint・Prettier・Git lens 系の拡張機能を載せた状態で開くと、ブラウザタブ単独でも常駐メモリの消費が大きく、モバイルブラウザでは厳しい
自分の OPPO 系端末でも、長時間使用で発熱と動作のもたつきが気になり始める
5-6 インチのスクリーンで VSCode の左サイドバー・エディタ・統合ターミナルを同時に表示するのは現実的ではなく、結局ターミナルだけ開いて使うことになりがち
それなら最初から SSH クライアントで良い、という結論になる

つまり、「軽量なテキストやり取りで Claude Code を呼びたい」という自分の用途に対して、フル IDE を起動するコスト が大きすぎました。

こんな用途には向く

タブレット端末（10 インチ以上）で VSCode のフル UI を活かしたい
編集対象のファイルが手元にあり、コードを直接書きたい
モバイル前提ではなく、外出先でたまに使う「予備の作業環境」として置いておく
自宅 WiFi 内で電源繋いで使う（発熱・バッテリーを気にしなくていい場面）

方式 4: Parsec

何ができるか

ゲーム用途で評価される低遅延リモートデスクトップソフトウェアです。自宅 PC を Parsec ホスト化し、Android からクライアント接続することで、自宅 PC のデスクトップ画面ごと操作できます。Claude Code を CLI でも GUI（VSCode 上のセッション等）でも、ホスト側の状態をそのまま使えるのが強みです。

自分の要件で合わなかった点

ゲーム配信向けの遅延最適化（数十 ms オーダー）は確かに効いているのですが、チャット感覚で文章を打って結果を受け取る用途とは噛み合いませんでした:

「タップ → 自宅 PC でキー受信 → 画面更新 → モバイルに描画」の 1 サイクルが、文章入力では往復遅延として体感される
公式ドキュメント上、Parsec Android アプリは experimental と位置付けられており、マウス/キーボード入力は "still in progress and may work incorrectly" と明記されています。さらに Immersive Mode のキーボード挙動も "does not work well at this time" と公式が認めています
そのため自分の手元では、日本語 IME 経由の文字入力が確定する前にホストへ流れる / 確定がずれるといった見え方をしましたが、これが OS IME と host IME の二重になる「構造的な仕組み」かどうかは一次ソースで裏が取れていません。文字入力経路が公式に未成熟と書かれている点までを根拠に、自分の用途では候補から外す判断に倒しています
音声入力も同じ経路を通るので、テキスト入力が不安定なら音声 → テキストの段で同じ症状が出る
結局「ホスト PC の画面を見る」必要があるので、5-6 インチのスマホ画面ではフル HD のデスクトップが縮小されすぎる

要するに、ゲーム配信のために最適化されたツールで、Android 側の文字入力周りは公式自身が experimental と認めている、という状況が自分の用途とミスマッチでした。

こんな用途には向く

自宅 PC のフル画面でゲームをモバイルから操作したい（本来用途）
タブレット端末で自宅 PC のデスクトップを使いたい
ホスト PC の GUI ツール（Photoshop 等）をモバイルで触りたい
WiFi 環境で帯域に余裕があり、画面共有が前提の用途

方式 5: Google Remote Desktop

何ができるか

Google が提供する Chromium ベースのリモートデスクトップサービスです。ブラウザ上から自分の PC に接続でき、追加の課金なしで使えます。Parsec 同様、ホスト PC のデスクトップ画面ごと操作する形になります。

自分の要件で合わなかった点

テキスト入力ベースで触る分には Parsec より軽快ですが、音声入力経路が自分の検証条件では安定して通らなかった のがネックでした。

Chrome Remote Desktop Android 公式ヘルプ上はオンスクリーンキーボードでホスト側にテキスト入力する前提があるので、Android 側キーボードに付属する音声入力（Gboard の音声入力など）で確定した文字列をキーボード経由でホストに送る経路 は理屈上は使えるはずです。実際、英文の短い入力ではこの経路が通ったケースもありました。

しかし、自分が日本語の自由文で長めの指示を投げる用途では:

音声認識中の暫定文字列がリモート画面に断続的に渡って表示が落ち着かない
一度に長文を音声入力した結果のうち、確定後の文字列のみがホスト IME に渡る経路と、暫定文字列まで漏れて渡る経路で挙動が分かれる
認識のキャンセル / バックスペースが Chrome 側の文字操作として処理される

といった理由で、Discord に直接「ちょっとバグ直して」と長文を投げる用途には合いませんでした。「構造的に音声入力できない」と決めつけるのは言い過ぎで、自分の検証条件（OPPO 系 / ColorOS + Gboard + 日本語長文 + Chrome Remote Desktop Android アプリ）で安定運用に乗らなかった、という限定付きの評価にとどめます。

こんな用途には向く

外出先から自宅 PC に「ちょっと触りに行きたい」程度の用途
テキスト入力中心で、音声入力を必要としない
既に Google エコシステム（Chrome / Google アカウント）に乗っており、追加導入コストを下げたい
Parsec のような専用クライアントを入れたくない

どこへ倒れたか — Discord 入口の自作ラッパー

5 方式が要件のどこかで外れたため、最終的には 「Discord を入口にして、サーバー側で worker が claude -p を叩いて、結果を Discord に返す」 という構成に倒しました。

構成図

Android (Discord アプリ)
   ↓ 自由文メッセージ + 音声入力経由テキスト
Discord Bot (gateway 接続)
   ↓ 受信 + idempotency check + rate limit + sandbox
worker (Node.js / TypeScript)
   ↓ claude -p "<task>" --output-format json
Claude Code CLI
   ↓ 結果（要約 + diff + log）
Discord 返信

なぜ Discord か

回線断耐性: Discord クライアントは push 接続を内部で再確立する。地下鉄を出た瞬間に投げた発言が反映されている、という挙動がそのまま使える
日本語 IME / 音声入力: Discord アプリは普通の Android 入力フィールドなので、Gboard の音声入力 / 日本語 IME がそのまま動く
双方向 push: worker からの結果も Discord メッセージとして届くので、結果取得のためにアプリを切り替えなくてよい
既存資産: サーバー側にはすでに Discord Bot を使った別ラッパー（後述の OSS 提出物）が動いていたので、そのアダプタ層を流用できる
複数端末: Android / iOS / Web / デスクトップ、どの入口からでも同じスレッドが見える

Real E2E 計測

ラッパー初版を Linux サーバー上で systemd 化し、Android からの 1 タスクあたりの round-trip を計測しました。worker 側のサービスログにそのまま残った 1 行:

[worker] result for 6e34c7e2-c2e3-4c51-9aef-f27ede3f7b41 posted
  (ok, 11148ms, 52 chars, redacted hits=0)

指標	値
Total round-trip（Android 送信 → Discord 返信着信）	11,148 ms
返信本文（Claude Code の応答）	52 chars
redaction hits（PII フィルタの作動）	0
サンプル数	N=1（Phase 5 デプロイ直後のスモークテスト 1 ラウンド）

注意: 上記は N=1 の 1 ラウンドスナップショット であり、平均値・標準偏差は別途取り直しが必要です。claude -p 実行時間（11 秒の大部分）はタスク内容に依存するため、変動幅は本来サンプリングしないと意味のある区間推定はできません。本記事では「実機で 1 ラウンド回って体感成立した」という事実までを示すスコープにとどめます。

11 秒前後はチャットの体感としては許容範囲で、「投げた → 何かやってる → 返ってきた」が 1 つの会話のリズムとして成立します。Discord クライアントの push 受信に体感ラグがほぼないので、手元の感覚としては「LINE で誰かに頼んだら返事が来た」程度 に近い読み心地でした。

自作の落とし穴 — `claude -p` を systemd で固める時

ラッパーを 24/7 で動かすため Ubuntu サーバー上で systemd unit 化したのですが、ここで 5 段階の hardening 罠 に詰まりました（Node.js / V8 の JIT が MemoryDenyWriteExecute=true と非互換、Ubuntu の .bashrc が非対話シェルで早期 return する、sudo -iu heredoc が改行を潰す、などなど）。

ここの話は 記事の主題からズレるので別記事に分離 しました。「claude -p を呼ぶラッパーを Linux サーバー上で 24/7 動かしたい人」向けには、合わせて読むと地雷を踏まずに済むと思います。

→ 兄弟記事（Zenn）: Claude Code 連携エージェントを systemd で固めたら、Node.js/V8/JIT/sandbox で 5 回詰まった話

まとめ — 何を選ぶべきか

要件によって最適解は変わります。自分用のチートシートとしては以下の通り。

あなたの状況	推奨方式
PC 前の Claude Code をピンポイントで操作したい	Anthropic 公式 Remote Control
自宅 WiFi 内で軽いターミナル作業	Termux + mosh
IDE 込みで作業したい（モバイル前提でなく）	VSCode Web
デスクトップごとリモート操作したい	Parsec / Google RD
自由文 / 音声入力 / 双方向 / 自前ラッパー連携	Discord 入口の自作ラッパー

最後の行を満たす SaaS は調べた範囲では見当たらず、自分で作ることになりました。同じ袋小路に来た人がいたら、5 方式を全部試す前にこの記事に当たってくれたら時間の節約になると思います。

参考リンク

Anthropic 公式 Claude Code ドキュメント: docs.claude.com/en/docs/claude-code — モバイル / リモート系の機能はここを起点に
Termux: termux.dev / mosh: mosh.org
code-server: github.com/coder/code-server / vscode.dev: vscode.dev
Parsec: parsec.app
Google Remote Desktop: remotedesktop.google.com
自作ラッパー OSS: tokimwc/clawbus — Discord ↔ ClawBus task プロトコル実装。今回の自由文チャンネル拡張は PR #1 として upstream に還元済み。本記事の生産環境側（idempotency / rate-limit / sandbox / systemd hardening）は private ラッパーで実装。
兄弟記事（Zenn）: Claude Code 連携エージェントを systemd で固めたら、Node.js/V8/JIT/sandbox で 5 回詰まった話 — Linux サーバー側の話。claude -p を 24/7 動かすと踏む 5 段階の hardening 罠を扱う