Claude Code Remote Controlのセキュリティリスクと対策 – URLを知っている＝操作できるで本当に大丈夫か

AI・自動化
2026.02.26
スポンサーリンク

📋 セキュリティチェック指示書（クリックで展開）

.claude/commands/ に保存して /コマンド で実行

---
description: "Claude Code Remote Controlのセキュリティリスクと対策 - URLを知っている＝操作できるで本当に大丈夫か — セキュリティチェック"
---

# Claude Code Remote Controlのセキュリティリスクと対策 - URLを知っている＝操作できるで本当に大丈夫か

この指示書は https://akahara-vlab.com/claude-code-remote-control-security/ の内容に基づくセキュリティチェックリストです。

## 概要

Claude Code Remote Controlの仕組みとセキュリティリスクを解説。URL漏洩による被害シナリオ、MACアドレス認証の誤解、ペアリングコード・チャレンジレスポンス・mTLSの3段階対策、インジェクション防御まで。

## 使い方

1. このテキストを `.claude/commands/security-claude-code-remote-control-security.md` に保存
2. Claude Codeで `/security-claude-code-remote-control-security` と入力して実行

## チェック指示

上記の記事で解説されているセキュリティ上の注意点をもとに、現在のプロジェクトを診断してください。
問題があれば具体的な修正案を提示してください。
記事URL: https://akahara-vlab.com/claude-code-remote-control-security/

※ 平文なので中身を確認してから使ってください。安全性は目視で確認できます。

2026年2月25日、AnthropicがClaude Codeに「Remote Control」機能をリリースした。ターミナルで claude rc を実行するとセッションURLとQRコードが生成されて、スマホやタブレットからそのセッションに接続できる。

デスクで始めたコーディング作業をソファからスマホで続けられる。散歩しながらコード書ける。以前はSSHトンネルとかポートフォワードとか面倒な設定が必要だったのに、公式がワンコマンドで全部潰してきた。

ただ、この便利さの裏にはセキュリティ上のリスクがある。この記事では、Remote Controlの認証モデルを分析して、想定されるリスクと段階的な対策を解説する。

スポンサーリンク

Remote Controlの仕組み

基本的な動作は以下の通り。

  1. ターミナルで claude rc（または claude remote-control、セッション内なら /remote-control）を実行する
  2. セッションURLが表示される（スペースキーでQRコードも表示可能）
  3. そのURLをブラウザやClaudeモバイルアプリで開くとセッションに接続
  4. ローカルのファイルシステム、MCPサーバー、ツール、プロジェクト設定がすべてリモートから操作可能

ここで重要なのは、Claudeはクラウドではなくローカルマシン上で動作し続けるという点だ。WebやモバイルのUIはローカルセッションへの「窓」に過ぎない。

つまり、この窓を第三者に開けられた場合、被害はローカル環境全体に及ぶ。

設定方法

/config に「Enable Remote Control for all sessions」という項目が新しく追加されている。これを true に指定（スペースキーで切り替え）すると、すべてのセッションで自動的にRemote Controlが有効化される。

ただし、後述するセキュリティリスクを考えると、必要なときだけ手動で有効にするのがおすすめだ。

現状の認証モデルとその弱点

QRコード＝URLという事実

QRコードの正体は単なるURLだ。claude.ai/code/session/{ランダムトークン} のような形式のURLがエンコードされている。

ランダムトークンの組み合わせ数は天文学的であり、総当たりで推測することは現実的に不可能。でも問題は推測ではなく「漏洩」にある。

URLが漏洩するシナリオ

シナリオ発生しやすさ影響度
画面共有・配信中にQRコードが映り込む高極めて高
ターミナルのスクロールバックやログにURLが残る中高
スクリーンショットにQRが含まれる中高
公共の場（カフェ等）でQRを表示する低〜中極めて高
チャットツール等でURLを誤送信する低高

漏洩した場合の被害

URLを取得した第三者が接続に成功した場合、以下の操作が可能になる。

  • ローカルファイルシステムの読み書き
  • MCPサーバー経由の外部サービス操作
  • プロジェクト設定の変更
  • Claudeを通じた任意のコマンド実行

実質的に「ローカルマシンのリモートアクセスを許可する」ことと同義であり、被害は深刻だ。

「MACアドレス認証」は有効か — よくある誤解

「接続するスマホのMACアドレスで端末を固定すればよいのでは」と考えるかもしれない。でもMACアドレスによる認証は機能しない。

そもそも届かない。MACアドレスはOSI参照モデルのレイヤー2（データリンク層）で使用される情報であり、インターネット越しのHTTPS通信（レイヤー7）ではサーバー側に到達しない。Remote Controlはブラウザベースの通信だから、クライアントのMACアドレスは原理的に取得できない。

偽装も容易だ。仮にローカルネットワーク内で取得できたとしても、MACアドレスはOSレベルで簡単にスプーフィング（偽装）が可能。AndroidではランダムMACがデフォルト設定になっており、固定識別子としても信頼性に欠ける。

つまり、MACアドレス認証はインターネット越しでは原理的に不可能であり、ローカルでも信頼性がないという二重の問題を抱えている。

外部認証基盤（Supabase等）の導入は可能か

Supabase AuthのようなBaaS（Backend as a Service）を認証レイヤーとして挟む案も考えられる。Supabase Authはメール/パスワード認証、OAuth、MFA（TOTP）をすぐに使える形で提供しており、Row Level Securityと組み合わせれば「このセッションはこのユーザーだけ」という制御も技術的には実現できる。

でも現状では、Remote ControlはAnthropicが提供するクローズドな機能であり、認証フローのカスタマイズやWebhook、プロキシの差し込みポイントは公開されていない。ユーザー側で勝手に外部認証を組み込むことはできない。

Anthropicが今後APIやプラグイン機構を公開すれば、外部認証との統合は現実的な選択肢になるだろう。

本当に有効な対策 — 3つのレベル

現状のURLベース認証を補強するために、導入コスト・堅牢性の異なる3段階の対策を提案する。

レベル1: ペアリングコード方式（導入コスト: 低）

Bluetoothデバイスのペアリングと同じ考え方だ。

  1. ターミナルに4〜6桁のワンタイムコード（例: 4829）が表示される
  2. スマホ側でセッションURLを開いた後、そのコードを入力する
  3. コードが一致して初めてセッションに接続される

URLが漏洩しても、ペアリングコードの入力ステップがあるため第三者はアクセスできない。ユーザー体験への影響も最小限で、最もバランスの取れた対策だと思う。

レベル2: チャレンジ・レスポンス方式（導入コスト: 中）

SSHの公開鍵認証と同じ原理を用いる。

  1. 初回ペアリング時にスマホ側で鍵ペア（公開鍵・秘密鍵）を生成し、公開鍵をターミナル側に登録
  2. 接続のたびにターミナル側がランダムなチャレンジを生成
  3. スマホ側が秘密鍵で署名して返す
  4. ターミナル側が公開鍵で検証し、一致すれば接続を許可

秘密鍵を持たない端末は応答できないため、URLの漏洩に加えて端末の物理的な盗難がなければ突破できない。WebAuthn/FIDOの考え方にも通じる堅牢な方式だ。

レベル3: mTLS（相互TLS証明書認証）（導入コスト: 高）

通常のHTTPS通信ではサーバー側のみが証明書を提示するが、mTLSではクライアント側にも証明書を持たせ、双方が証明書を検証する。

  • VPNや企業のゼロトラストアーキテクチャでは一般的な手法
  • 証明書の配布・管理にコストがかかるが、最も堅牢な1対1認証を実現できる
  • 企業のMDM（モバイルデバイス管理）環境との相性が良い

個人利用にはオーバースペックだけど、Team/Enterpriseプランへの展開時には検討に値する。

インジェクション対策 — 認証とは別軸の防御

1対1認証が確立されたとしても、セッション内で悪意ある操作が行われる可能性は残る。特にプロンプトインジェクション（Claudeへの入力を細工して意図しないコマンドを実行させる攻撃）には注意が必要だ。

コマンドのスコープ制限

リモート側から実行可能な操作をホワイトリストで制限する。ファイルの閲覧は許可するが削除は禁止する、といった粒度での制御が望ましい。

破壊的操作の二重承認

ファイル削除、システム設定の変更、外部サービスへの書き込みなどの破壊的操作については、ターミナル側（＝物理的にマシンの前にいる人）での承認を必須にする。

入力のサニタイズ

リモートから送信されたメッセージに対して、プロンプトインジェクションのパターン検出とフィルタリングを行う。

セッションの自動失効

一定時間操作がないセッションは自動的に切断する。長時間放置されたセッションは攻撃者にとって格好の標的になる。

サンドボックスの活用

Remote Controlには --sandbox フラグが用意されており、ファイルシステムとネットワークのアクセスを制限できる。リモート接続時はデフォルトで有効にすることをおすすめする。

過去の脆弱性から学ぶ

Claude Codeにはこれまでにも重大な脆弱性が報告されている。

  • CVE-2025-59536（CVSS 8.7）: 信頼できないディレクトリでClaude Codeを起動した際に、ツールの初期化時に任意のシェルコマンドが自動実行される脆弱性
  • CVE-2026-21852（CVSS 5.3）: 悪意あるリポジトリの設定ファイルを通じて、AnthropicのAPIキーが外部に漏洩する脆弱性

いずれも修正済みだけど、Remote Controlという新たな攻撃面が追加されたことで、同種の脆弱性が発見される可能性は十分にある。特に「信頼できない入力を受け付けるリモートインターフェース」は、攻撃者にとって魅力的なターゲットだ。

今すぐできる対策チェックリスト

Remote Controlを利用する開発者が今日から実践できる対策をまとめる。

  • 画面共有・配信時にはターミナルウィンドウをOBS等で非表示にする
  • 使い終わったセッションは速やかに終了する
  • --sandbox フラグを使用してサンドボックスを有効にする
  • 全セッション自動有効化（Enable Remote Control for all sessions）は本当に必要な場合のみ有効にする
  • ターミナルのスクロールバック・ログにURLが残っていないか確認する
  • Claude Codeを常に最新バージョンに更新する
  • 公共の場ではQRコードを表示しない
  • 接続先が想定どおりか、セッション名で確認する習慣をつける

まとめ

Claude Code Remote Controlは開発者の生産性を大きく向上させる革新的な機能だ。でも、現状の認証モデルは「セッションURLの秘匿性」に大きく依存しており、URLが漏洩した場合のリスクは無視できない。

MACアドレスのような直感的だが技術的に無効な対策ではなく、ペアリングコードやチャレンジ・レスポンスといった暗号学的に裏付けのある認証方式の導入が望まれる。Anthropicが今後Team/Enterpriseプランへ展開する際には、こうした多層的な認証がほぼ必須になるだろう。

便利さとセキュリティは常にトレードオフの関係にある。Remote Controlの利便性を最大限に享受しつつ、自衛できるところは自衛しよう。

この記事はリサーチプレビュー段階の機能について書いているので、今後仕様が変更される可能性がある点は留意してほしい。

あわせて読みたい

この記事が参考になったら｜以下のリンクから見てもらえるだけで、ブログ運営の応援になります。

  • NordVPN

    セキュリティが気になる方は、VPNで通信を暗号化するのがおすすめです。



  • AI開発環境やブログ運営に。初期費用無料、月額296円から。

スポンサーリンク

コメント

タイトルとURLをコピーしました