iPhone から開発マシンに接続できない場合：ローカルネットワークと Tactic Relay の完全トラブルシューティング手順

自宅では Mac に接続できるのに、カフェに行くと失敗する。アカウント一覧にはコンピューターが表示されるのに、プロジェクトを開こうとするとタイムアウトする。あるいはターミナルは表示されているのに、新しい返信が届かない。これらはどれも接続障害のように見えますが、実際に確認すべき箇所はそれぞれ異なります。

トラブルシューティングでは、まず「最後に正常だった段階」を特定します。コンピューター自体が稼働していなければ、まずホストを復帰させます。ローカル接続が失敗しても設定済みの Relay が利用できるなら、ローカルネットワークを調べます。元のセッションにターミナルのリアルタイム出力があるなら、エージェントの状態確認に進みます。これにより、各ステップで具体的な判断ができ、進行中のタスクも安全に保護できます。

接続設定を変更する前に、現状を記録する

コンピューター名、プロジェクトとセッション、接続方式、エラーメッセージ、おおよその発生時刻を記録します。さらに、ネットワークの切り替え、コンピューターのスリープ、ホスト側のアップデート、サインインのキャンセルなど、直近に変更がなかったか確認します。

いきなりコンピューターの登録解除やセッションの削除、全接続設定の消去を行わないでください。これらの操作は元の認証状態や作業状態を変更してしまい、コンピューターのスリープやゲストネットワークの隔離問題を解決することはできません。現象に関連する条件を 1 つずつ変更し、結果を比較してください。

以下の手順は、すでに設定済みの接続のトラブルシューティングを対象としています。初めてセットアップする場合は、iPhone スタートガイドに沿ってコンパニオンの導入とペアリングを行ってください。

ステップ 1：コンピューターとコンパニオンサービスが稼働しているか確認する

コンピューターが作業可能な状態にあり、コンパニオンアプリまたは CLI サービスが実行されている必要があります。画面の消灯とシステム全体のスリープは異なります。また、アカウント一覧にコンピューターが表示されていること自体は、現在の接続が有効である証明にはなりません。ホスト側でサービスが稼働しているか、エラーが出ていないか、目的のコンピューターに正しく接続しようとしているかを確認します。

Mac では、以下の読み取り専用コマンドでデフォルトポートの状態を確認できます：

lsof -nP -iTCP:8765 -sTCP:LISTEN

デフォルトポートは 8765 です。変更している場合は、設定したポート番号を使用してください。出力される COMMAND、PID、リッスンアドレスから、どのプロセスがサービスを提供しているかを特定できます。

この確認は Tactic の認証を検証するものではなく、iPhone からアクセスできることを証明するものでもありません。Mac アプリと独立 CLI はどちらも同じデフォルトポートを使用する場合があるため、どちらを起動したかを明確にしてください。コンピューターを直接確認できない場合は、「ホスト状態は未確認」としたまま、スマートフォン上で確認できるエラーの切り分けを続けてください。

ステップ 2：ローカル接続の場合、権限と実際の到達性を確認する

2 つのデバイスに同じ Wi-Fi 名が表示されていても、相互に通信できるとは限りません。ゲストネットワーク、企業内ネットワークの端末間隔離、VPN のルーティングなどが接続に影響することがあります。まず iPhone の「設定 → プライバシーとセキュリティ → ローカルネットワーク」で Tactic Remote のアクセス権限を確認してください。Apple のローカルネットワーク権限に関する案内に詳しい設定方法が記載されています。

次に、コンピューターの現在のアドレスとアプリに保存されているアドレスを照合します。ルーターの交換、Wi-Fi から有線 LAN への切り替え、DHCP による新しい IP アドレスの割り当てなどにより、保存されたアドレスが別の場所を指している可能性があります。ホスト側コンパニオンに現在表示されているアドレスを確認し、すべての Mac の Wi-Fi が en0 であると思い込まないようにしてください。

同じ信頼されたネットワーク内に別の Mac がある場合、対象のコンピューターに対して TCP 接続の到達性を確認できます：

# サンプルの IP アドレスを開発マシンの実際のローカル IP に置き換えてください。
nc -vz -G 3 192.168.1.42 8765

このコマンドは TCP 接続の確立のみを試行し、Tactic の認証情報やプログラミング指示は送信しません。-G 3 は macOS の nc における接続タイムアウト引数です。他の OS ではオプションが異なる場合があります。

開発マシン自身で 127.0.0.1 をテストしても、自分自身の状態しか確認できません。iPhone のブラウザで 127.0.0.1 にアクセスしても、それはスマートフォン自身を指しており、Mac へのアクセスにはなりません。また、ネットワークが ICMP を制限している場合があるため、ping が通らないことだけをもってサービスが停止していると判断することはできません。

ファイアウォールの設定を変更する必要がある場合は、実際に稼働しているコンパニオンアプリに対して必要なアクセスのみを許可し、認証は必ず維持してください。VPN を使用している場合は、組織のネットワークポリシーの範囲内でルーティングの変更を比較してください。ファイアウォール全体の無効化、認証の解除、ルーターのポート開放を通常の復旧手段として用いてはなりません。基本設定についてはローカルネットワーク設定ガイドを参照してください。

ステップ 3：Relay 接続の場合、アカウントとホストの状態を確認する

外出先では、自宅のコンピューターのローカルネットワークアドレスにはアクセスできなくなります。Tactic Relay を使用する場合は、双方のデバイスで目的の Tactic アカウントを使用していること、コンピューターが正しく紐付けられていること、ホスト側コンパニオンの Relay 接続がアクティブであることを確認します。

以下の順序で確認してください：

1. コンピューターが起動しており、コンパニオンが実行中で、インターネット接続が利用可能か。
2. スマートフォンとコンピューターが目的のアカウントにサインインしており、正しいコンピューターを選択しているか。
3. コンピューター側で Relay 接続が正常と表示されているか（再接続中や具体的なエラーになっていないか）。
4. アカウント検証、再サインイン、またはブラウザからアプリへの復帰処理を求められていないか。
5. 指示に従ってこれらを完了させた後、そのコンピューターに接続してプロジェクトを開きます。

Tactic アカウントへのサインインは、ホストの紐付けとアクセス認可を担当します。Claude Code などのコーディングエージェントは、開発マシン上の独自のアカウントを使用します。アカウント内にコンピューターが表示されること、ワークスペースに接続できること、エージェントがサインインしていることは、それぞれ異なる状態です。

バージョン 1.11 では、サインインから一定時間が経過した後にコンピューターの紐付けが失敗する問題が修正されました。認証を求められた場合は、指示に従って完了させてから再試行してください。登録解除と再紐付けを繰り返すと追跡すべき変更が増えるため、すべてのタイムアウトに対する最初の対処とすべきではありません。

2 つの接続方式が正しく設定されていれば、両者を比較して問題を絞り込めます。同じコンピューターでローカル接続が失敗し Relay が成功する場合はローカルネットワークを優先して確認します。ローカル接続が成功し Relay が失敗する場合は、アカウント認証、ホスト側の Relay 状態、インターネット接続を優先して確認します。この比較は切り分けのためのものであり、特定のコンポーネントに問題がないことを証明するものではありません。

Cloudflare Tunnel を使用している場合はトンネルアドレスを別途確認する

Cloudflare Tunnel を使用している場合は、トンネルプロセス、現在のアドレス、実際にマップされているサービスを確認してください。一時的なトンネルを再起動するとアドレスが変わることがあり、保存された古い URL が現在のコンピューターを指していない可能性があります。

ブラウザで HTTP ページが開けることだけでは、アプリの WebSocket 接続や認証が機能していることの証明にはなりません。完全なエラー内容を保持し、現在のアドレスを確認した上で、Cloudflare Tunnel 設定ガイドに沿って確認してください。トンネルのアクセスルールと Tactic Relay のアカウント設定を同時に変更しないように注意してください。

ステップ 4：元のセッションに戻り、新しい出力を確認する

接続が復旧したら、障害発生前に使用していたコンピューター、プロジェクト、元のセッションを選択します。プロジェクト一覧が表示されればワークスペースへのアクセスは回復しています。元のターミナルでリアルタイムな出力の変化が確認できれば、セッションの出力がスマートフォンに届いています。古い履歴テキストは過去の記録を示すだけであり、現在の接続が正常である証拠にはなりません。

ターミナルがプロジェクトの信頼確認、プロバイダーへのサインイン、または起動プロンプトで停止している場合は、エージェント待機トラブルシューティングガイドを参照してください。この状態で Wi-Fi を切り替えたりアカウントを再紐付けしたりしても、そのターミナルプロンプトに回答することはできません。

送信中に切断された場合は、そのリクエストに対応する新しい出力を探してください。リクエストはすでにコンピューターに届いている可能性があります。ネットワーク復旧後に、タスク全体をすぐに再送信しないでください。セッションがアイドル状態であることを確認した上で、小規模なステータス確認を送信できます：

現在のプロジェクト、完了済みの作業、保留中の決定事項について、読み取り専用で要約してください。直前のタスクを再実行したり、ファイルを編集したりしないでください。

ディレクトリと結果が元のタスクと一致しているか確認し、次の操作を判断します。新しいセッションを作成する必要がある場合は、まず古いセッションの実際の状態を記録してください。新しいセッションがすべてのコンテキストを自動的に引き継ぐわけではありません。

それでも解決しない場合は、調査結果をサポートに共有する

以下のテンプレートをコピーし、把握できている事実を記入してください。未確認の項目には「未確認」と記入します。

スマートフォンの OS と Tactic Remote のバージョン：
コンピューターの OS、コンパニオン種別、およびバージョン：
接続方式：ローカルネットワーク / Tactic Relay / Cloudflare Tunnel
障害が発生し始めた日時（タイムゾーンを含む）：
最近の変化：スリープ / ネットワーク切り替え / 更新 / サインイン / その他
最後に正常だった段階：サインイン / コンピューターの検出 / プロジェクトを開く / ターミナルのリアルタイム出力
完全なエラーテキスト：
ホスト側サービスおよび Relay の状態：
すでに実施した確認項目と結果：
元のセッションが引き続き開けるか：
直前のリクエストが送信済みの可能性があるか：

共有する前に、認証情報、ペアリング用 QR コード、サインインリンク、プライベートなターミナル出力を削除してください。アカウント、パス、ネットワークアドレスは必要に応じてマスキングしてください。サポートチームに対して、「ローカルポートには疎通するが、アプリで認証エラーが表示され、ホスト側のバージョンは……」のように具体的な診断情報を提示することで、単に「接続できない」と伝えるよりも迅速な原因特定が可能になります。

接続が復旧したら、ダウンロードページで双方のバージョンを照合し、バージョンの不一致が原因で次回のリモート利用時に問題が再発しないようにしてください。1.11 のその他の変更点や、モバイルアプリおよびホスト側コンパニオンのアップデート方法については、Tactic Remote 1.11 の概要を参照してください。