Anthropic が2026年に立て続けに投入した Claude Code on the Web（リサーチプレビュー）と Remote Control（v2.1.51 以降）により、Claude Code は「ローカル端末に張りついた CLI」から「どこからでもアクセス可能な開発エージェント」へと位置付けを変えつつある。これに GitHub Actions の @claude メンション、そして従来から存在する SSH+tmux による自宅マシン接続を加えると、スマートフォンから Claude Code を利用する手段は実質4方式に整理できる。本稿では各方式のアーキテクチャを比較し、移動中・出張中・通勤途中といったモバイル文脈で何を選ぶべきかを設計の観点から整理する。Claude Code 2026年2月アップデートの全体像と合わせて読むと、リモート制御機能の戦略的位置付けがより明確になる。

4方式の構造的比較 ── 実行環境・状態保持・MCP可用性で割る

スマートフォンから Claude Code を利用する手段は、表層的には「Webブラウザで操作するか」「アプリで操作するか」の違いに見える。しかし設計の本質は「コードが実際にどこで実行されるか」と「セッション状態が誰に保持されるか」にある。この2軸で整理すると、現在利用可能な方式は明確に4つに分かれる。

第一に Claude Code on the Web。実行環境はAnthropic側のクラウドサンドボックスであり、リポジトリは GitHub からクローンされてセッション内に存在する。ローカル端末との接続は不要で、スマートフォンのモバイルブラウザから claude.ai/code にアクセスするだけで動作する。Pro 以上のプランで利用可能で、2026年時点ではリサーチプレビュー段階にある。

第二に Remote Control。実行環境は ローカルマシン（自宅Mac、社内ワークステーション等）であり、スマートフォンはあくまでフロントエンド端末として動作する。ローカルで claude remote-control を実行すると QR コードが表示され、Claude iOS/Android アプリでスキャンするとペアリングが完了する。これによりローカルに設定済みの MCP サーバー、認証情報、Supabase 接続、git リポジトリのフル状態がそのまま利用可能になる。

第三に GitHub Actions による @claude メンション。実行環境は GitHub Actions のランナーであり、トリガーは PR・Issue のコメント欄。スマートフォンの GitHub アプリから @claude このバグ修正してと書き込むだけで、リポジトリに設定済みの workflow が起動する。実装は Claude Code hooks による品質ゲートとも親和性が高く、コードレビューや軽微な修正の自動化に向く。

第四に SSH+tmux による自宅マシン接続。これは Claude Code の機能ではなく汎用的な手法で、Tailscale のような VPN メッシュ網を経由して自宅マシンに SSH 接続し、tmux でセッションを保持した状態の Claude Code を操作する。iOS では Termius・Blink Shell・Prompt 3、Android では Termux・JuiceSSH が代表的なクライアントとなる。

Remote Control の技術構造 ── QRペアリングと永続セッションの設計

Remote Control が他の3方式と決定的に異なるのは、「ローカルマシンの状態を一切失わずにモバイルから継続できる」点である。Web版はクラウドにリポジトリをクローンしてセッションを構築するため、ローカル特有の MCP サーバー設定（例えば Taolis であれば Supabase MCP や ComfyUI 連携）は利用できない。一方 Remote Control はローカルプロセスを単に「遠隔操作の対象」として公開しているにすぎず、すべての副作用は依然としてローカルマシン上で発生する。

ペアリング手順は意図的にシンプルに設計されている。ローカルマシンで claude remote-control を実行すると、Anthropic 側のリレーサーバーとの間に WebSocket 接続が確立し、QR コードが端末に表示される。このQRには一時的なペアリングトークンが含まれており、Claude モバイルアプリでスキャンするとアプリ側もリレーサーバーに接続して双方向のチャネルが完成する。認証は同一の Anthropic アカウントでログインしていることが前提であり、API キー認証では Remote Control は利用できない。

セッションの永続性については、ローカルマシンのスリープに対しては Claude Code 側が再接続を試行するが、ネットワーク切断が10分を超えるとタイムアウトする仕様になっている。出先で電波が不安定な場合、tmux のような再接続容易性は持たないため注意が必要だ。逆に短時間の地下鉄通過や電車のトンネル程度であれば、自動再接続によりほぼ意識せず継続できる。

プッシュ通知は Remote Control の重要な構成要素で、長時間タスク（例: テストスイート実行、リファクタリング、大量ファイルの一括修正）が完了したタイミングで iOS/Android にネイティブ通知が届く。これにより「タスクを投げて画面を閉じ、別作業をしながら完了を待つ」という非同期型のワークフローが実用化される。

Web版とブラウザ実行の制約 ── サンドボックスがもたらす設計上のトレードオフ

Claude Code on the Web は最も導入摩擦が低い選択肢である。ローカル環境のセットアップが一切不要で、claude.ai/code に行ってリポジトリを指定すれば即座にセッションが立ち上がる。これはモバイルブラウザでも完全に動作するため、外出先で「ちょっとあのリポジトリのREADMEを修正したい」「Issue のテキストを整形したい」といった軽量タスクには最適である。

一方、Web版には「ローカル MCP サーバーが使えない」「ローカルファイルシステムへの直接アクセスがない」「実行可能なコマンドがサンドボックス内に限定される」という3つの設計上の制約がある。Taolis のようなプロジェクトで言えば、Supabase へのリモート接続スクリプト（scripts/x-test-post.sh 等）はクラウドサンドボックス側からは到達不能な場合があり、本番DBに影響するワークフローはWeb版では現実的に動かせない。

ただし、これは制約というよりも「安全側の設計」として理解すべきである。Web版は不特定多数のデバイスからアクセス可能であり、デバイス紛失リスクも高い。本番認証情報や Service Role Key が即座に手元から漏れない構造になっていることは、企業利用において重要な防御層になる。MCP セキュリティの構造的欠陥で論じたように、AIエージェントとローカル特権の境界設計は2026年最大のセキュリティ論点であり、Web版の制約はこの議論への一つの回答でもある。

セッションの永続性については、Web版はクラウド側にセッション状態が保持されるため、モバイルアプリと同期して途中から再開できる。「通勤電車でブラウザから書き始め、デスクに着いてからモバイルアプリで続きを確認する」というデバイス横断の継続性は、Remote Control とは異なる Web版独自の強みである。

GitHub Actions @claude ── 非同期PR駆動開発のモバイル化

GitHub Actions の @claude メンション機能は、モバイル開発という文脈で見ると「最も手数の少ない方式」である。スマートフォンに GitHub アプリさえ入っていれば、追加のセットアップなしに PR や Issue のコメント欄から Claude にタスクを依頼できる。実行はクラウド側のランナーで完結し、ローカルマシンの起動もスマホアプリの追加インストールも不要だ。

典型的なユースケースは「移動中にコードレビュー結果を見て、軽微な修正を依頼する」「Issue を読んで初期実装の叩き台を作らせる」といったレビュー駆動・Issue駆動のワークフローである。Claude が PR にコミットをプッシュすると、開発者は後で内容を確認・編集・マージするだけでよい。これはAIコーディングツールの比較で論じたエージェント型ツールの利点を、最小コストで享受する方法とも言える。

セキュリティ面では、GitHub Actions の workflow に Anthropic API キーを Secrets として登録する必要があり、リポジトリの管理権限と漏洩リスクをどう設計するかが鍵となる。Claude Code 公式ドキュメントでは OIDC 連携によるトークン交換も推奨されており、長期キーをリポジトリに保持しない構成が望ましい。

SSH+tmux による自宅マシン接続 ── 自由度と運用負荷のバランス

SSH+tmux 方式は Claude Code が公式に提供する機能ではないが、「Remote Control が登場する前の標準的なモバイル開発手法」として広く使われてきた経緯がある。基本構成は以下の通り。

  • Tailscale で自宅マシンとモバイル端末を同一の仮想プライベートネットワークに収容する
  • SSH で接続し、tmux でデタッチ可能なセッションを起動する
  • tmux 内で claude CLI を実行し、入力はモバイル端末のソフトウェアキーボードで行う

iOS では App Store ポリシーの制約により、ターミナル系アプリの選択肢は限定的だ。Termius、Blink Shell、Prompt 3 が主要な選択肢となる。Android では Termux が圧倒的に強力で、ローカルに Linux 環境を持つことも可能だ。

この方式の強みは「自由度の高さ」に尽きる。Remote Control が公式アプリのUIに縛られるのに対し、SSH+tmux はターミナルそのものをモバイル化するため、grep、find、vim、git といったあらゆるCLIツールが利用可能だ。長期的にセッションを保持したい場合や、Claude Code 以外のツール（テストランナー、ログtailing 等）を並行して扱いたい場合に向く。

一方、運用負荷はもっとも高い。Tailscale のセットアップ、SSH 鍵の管理、tmux のキーバインド習熟、モバイル端末でのキーボード操作の不便さなど、初期コストと継続コストは無視できない。Remote Control が登場した2026年以降は、「軽量タスクは Remote Control、フル CLI が必要な場合のみ SSH+tmux」という棲み分けが現実的だろう。

モバイル運用の選定基準とTaolis的ワークフロー設計

4方式の使い分けは、実行環境の所在、セキュリティ境界、セットアップコストの3軸で整理できる。

方式実行環境MCP可用性セットアップ適するシナリオ
Web版Anthropicクラウド制限あり不要軽量編集、READMEやIssue整形
Remote ControlローカルマシンフルQRスキャンのみ本番DB操作含む実作業の継続
GitHub @claudeGitHub Actionsランナーworkflow内のみworkflow設定レビュー駆動・Issue駆動の修正
SSH+tmuxローカルマシンフル高（VPN・鍵管理）フルCLI操作・複数ツール並行

個人的な運用経験から言えば、無停止のインシデント対応に近い緊張感を強いる作業ほど、手順書とツール選定の事前準備が成否を決める。モバイルから本番DBに触れるような操作は、Remote Control 経由でローカルの確立済みスクリプトを呼び出す設計にしておかないと、ソフトウェアキーボードのミスタッチ一つで取り返しのつかない事態を招きうる。「外出先でも操作できる」ことと「外出先で操作すべき」ことは慎重に切り分ける必要がある。

Taolis のような Next.js + Supabase 構成のプロジェクトを例にとると、推奨されるレイヤー設計は以下になる。第一層として、軽量タスクは Web版でこなす（タグ修正、READMEの整形、サイトマップ確認等）。第二層として、本番DBや MCP サーバーに触れる作業は Remote Control 経由で自宅Macの確立済み環境に投げる（記事公開、X連携トリガーの確認等）。第三層として、定型的なPR対応は @claude メンションに委任する。第四層として、フルCLIが必要な障害対応のみSSH+tmuxを温存する。

この多層化により、デバイス紛失時のリスク・モバイル端末の入力ミスのリスク・クラウドサンドボックスでは到達できない作業のカバー範囲、という3つの異なる制約を同時に最適化できる。「スマホで Claude Code を使う」は単一の質問ではなく、作業の粒度とリスクプロファイルごとに別々の答えがあると理解することが、2026年の Claude Code モバイル運用設計の核心である。

FAQ

Remote Control は API キーでも使えるか？

使えない。Remote Control は claude.ai アカウントでのログインが前提であり、同一アカウントでローカル CLI とモバイルアプリの双方を認証する必要がある。API キー方式の Claude Code ユーザーは現状 Remote Control の対象外で、Pro 以上のサブスクリプション契約が必要となる。

Claude Code on the Web で Supabase のような外部サービスに接続できるか？

環境変数として API キーを設定すれば外部 API への HTTP リクエストは可能だが、ローカル MCP サーバー（例: Supabase MCP）はクラウドサンドボックス側から起動できないため、MCP プロトコル経由の高度な統合は利用できない。本番DBに対する複雑な操作は Remote Control 経由でローカル環境から実行する設計が推奨される。

iOS でターミナル系アプリを使う場合、最も実用的なクライアントはどれか？

用途による。tmux 連携と日本語入力の安定性で評価が高いのは Blink Shell（有償）、無料で始めやすいのは Termius、Mosh（不安定回線での再接続性能に優れる）を使いたい場合は Blink Shell か Termius の Mosh 対応版となる。ソフトウェアキーボードの不便さは共通課題であり、外付け Bluetooth キーボードの併用を強く推奨する。

GitHub Actions @claude はコストがどう発生するか？

2つのコスト軸がある。GitHub Actions ランナーの実行時間（GitHub プランに依存）と、Anthropic API の利用料金（リポジトリに登録した API キーに対して課金）である。大規模リポジトリで Claude が探索的にファイルを読む場合、入力トークン数が急増することがあり、月次コストの監視と上限設定は必須となる。

移動中の不安定な回線で Remote Control はどこまで耐えるか？

短時間（数十秒〜数分）の切断であれば自動再接続で復帰するが、10分を超える切断ではセッションタイムアウトとなる。長距離移動で長時間のオフラインが想定される場合は、Remote Control よりも GitHub Actions @claude 経由の非同期ワークフローのほうが堅牢である。タスクを投げてからオフラインになっても、結果は GitHub 側で完結し後で確認できる。

参考文献