theonehub.app

KEYBOARD — キーボードとターミナル入力

スマホから Claude Code / Codex を動かす構成 — 外出先でセッションを進める

スマホから Claude Code / Codex を動かす構成 — 外出先でセッションを進めるのアイキャッチ

自宅の Mac で動く Claude Code / Codex の CLI エージェントを、Android から SSH で操作する構成を解説。tmux と VPN と入力環境が鍵になります。

この記事の目次

たとえば、朝、テストの拡充を Claude Code に頼んで家を出る場面を考えます。1時間後、エージェントは「既存のモックを置き換えてよいか」と確認を出したまま止まっている。机に戻る夕方まで、その一問に答える手段がない。CLI コーディングエージェントを使い始めると、仕事が「数十分の自走」と「一瞬の確認待ち」の繰り返しでできていることに気づきます。人間が机に張りついていなくても仕事は進む。ただし確認待ちに答える窓口がポケットにないと、自走は最初の質問で止まります。

この窓口を作るのが、自宅の Mac で動くセッションに Android から SSH でつなぐ構成です。エージェントをスマホで動かすのではなく、母艦で動かし続けたまま、スマホはその画面とキーボードに徹します。部品は SSH と tmux と VPN という枯れた道具だけで、どれも今日そろいます。セットアップで実際に打つコマンド、外出中の権限の扱い、Claude Code に公式で備わった Remote Control との使い分けまで含めて組み立てていきます。

なぜ「スマホで動かす」のではなく「母艦につなぐ」のか

最初に構成の思想を押さえておきます。この構成では、エージェントをスマホ上で動かしません。自宅やオフィスの Mac / PC(以下、母艦)で動かし、スマホはそのセッションに接続する画面とキーボードに徹します。

理由は3つあります。第一に、エージェントの仕事場は実行環境そのものだからです。リポジトリ、ツールチェーン、ビルド環境、テスト、認証情報。これらが揃った母艦でエージェントを動かせば、机で使っている環境とスマホから使う環境が完全に同一になります。第二に、スマホは長時間の計算に向かない機械だからです。電池と発熱の制約に加えて、Android はバックグラウンドの処理を積極的に止める OS なので、画面を消した瞬間に数十分の自走が中断されるリスクを常に抱えます。第三に、セッションの連続性です。母艦で動くセッションに「机からもスマホからも座る」形にすれば、場所を移るたびに作業を引き継ぐ必要がなくなります。

そしてこの構成は、通信の性質から見ても理にかなっています。CLI エージェントとの対話は結局のところ文字のやり取りです。文字だけを転送する SSH は通信量が小さく、モバイル回線の細さや不安定さに強い。画面を送るリモートデスクトップと違い、通信が届く区間なら短い確認に使いやすい一方、圏外では接続できません。スマホでターミナルを使う3方式の中で SSH 型がこの用途の本命なのは、この性質のためです。

構成の全体像 — 4つの部品

  1. 母艦: 自宅やオフィスの Mac / PC で Claude Code / Codex を動かします。作業中は起動したままにし、スリープしない設定にしておきます
  2. tmux: 母艦のターミナルを tmux 上で動かします。接続が切れてもセッションは母艦側で生き続け、机とスマホのどちらからでも同じ画面に戻れます
  3. VPN: 外出先から母艦へ届くように、Tailscale などのプライベート VPN を張ります。ルーターのポート開放より安全で、両端末の参加状態、アクセス許可、ファイアウォールも確認します
  4. SSH クライアント: Android 側は Termius / ConnectBot などから1つ。母艦へ ssh して tmux attach すれば、家で開いていたセッションがそのまま現れます

4つのうち3つ(tmux・VPN・SSH クライアント)は一度設定すれば触らない部品で、更新や認証の期限、アクセス設定も定期的に確認します。

部品の中でいちばん重要なのは tmux です。tmux はターミナルの中に「切断されても死なない作業部屋」を作る道具で、SSH 接続が切れてもエージェントは部屋の中で動き続けます。スマホの回線は移動やスリープで頻繁に切れるのが前提なので、ここでは tmux を使って接続と作業の寿命を分けます。逆に tmux さえあれば、切断は「再接続して attach し直せば元通り」というだけの扱いやすい出来事になります。ただし母艦の停止やエージェント自身の失敗は、tmux では防げません。

SSH クライアントの側で唯一こだわるべきは、接続直後に実行するコマンドとして tmux attach || tmux を仕込めることです。これがあると、アプリを開いてタップ1回で、いつものエージェントの画面の前に座っている状態を作れます。クライアント選びの詳しい軸はAndroid の SSH クライアントの選び方にまとめました。

スマホは操作画面、接続経路を経て母艦のセッションへ入る
スマホは操作画面、接続経路を経て母艦のセッションへ入る
画像を選ぶと拡大できます。
  1. スマホのクライアントを、母艦へ接続する操作画面として使います。
  2. VPN、認証、接続許可を整え、母艦へ届く経路を確認します。
  3. エージェントとtmuxのセッションは母艦側で動かし、そこへ接続します。

セットアップ手順

  1. 母艦で SSH サーバを有効にする。Mac ならアップルメニュー →「システム設定」→「一般」→「共有」と進み、「リモートログイン」をオンにします(Apple サポート: リモートコンピュータに Mac へのアクセスを許可する)。同じページに「お使いのMacへのリモートログインを許可すると、安全性が低下します」と注意があるとおり、次の鍵認証と VPN をセットにして使います。Linux なら openssh-server を導入します
  2. 母艦がスリープしない設定にする。電源接続時はスリープさせない設定にしておかないと、外出先から届かない原因の筆頭になります
  3. 認証を公開鍵方式にする。ssh-keygen -t ed25519 で鍵ペアを作り、公開鍵を母艦の ~/.ssh/authorized_keys に登録し、動作確認後にパスワード認証を無効化します。ed25519 は ssh-keygen の既定の鍵種別で、公開鍵を ~/.ssh/authorized_keys に追加する手順もマニュアルに書かれています(ssh-keygen(1))
  4. Tailscale を母艦とスマホの両方に入れ、同じアカウントでログインする。これで外出先からでも母艦のプライベートアドレスに届くようになります
  5. Android に SSH クライアントを入れ、ホスト・ユーザー・鍵を登録した接続プロファイルを作り、接続時コマンドに tmux attach || tmux を設定します
  6. 母艦の tmux の中で Claude Code / Codex を起動する。以後、エージェントは常に tmux の中で動かすことを習慣にします
  7. まず家の中でテストする。Wi-Fi を切ってモバイル回線からつなぎ、机の画面と同じセッションがスマホに出ることを確認します。外出前にここまで通しておくと、接続や入力の問題を事前に見つけやすくなります

手順3の設定例を示します。既存の設定と復旧用の接続手段を残し、別の接続で鍵認証を確認してから変更します。これは全認証方式を制限する完全な設定ではなく、環境によりキーボード対話認証や Include・Match の扱いも確認が必要です。PasswordAuthentication は既定が yes なので、鍵でログインできることを確かめてから no に変えます(sshd_config(5))。

# 鍵ペアを作る(スマホ用の鍵はスマホ側で作るのが原則。理由はセキュリティの節で)
ssh-keygen -t ed25519
# 母艦の sshd_config に書く2行。鍵で入れることを確認してから反映する
PubkeyAuthentication yes
PasswordAuthentication no

所要時間や追加費用は、既存の端末と契約、ネットワーク環境によって変わります。tmux は OS に標準搭載されていない場合があるため、利用環境に合う導入手順を確認します。VPN やエージェントの利用条件も、導入時の公式案内で確認してください。

ひとつだけ運用上の約束を決めておくと後が楽になります。「エージェントは必ず tmux の中で起動する」。机で作業を始めるときも、この約束さえ守っていれば、対応するターミナル作業を外出先から再開しやすくなります。逆にこの約束を破った作業だけが、切断と同時に消える作業になります。

一日の運用イメージ

家を出る前に、エージェントへ大きめのタスクを渡しておきます。「このモジュールのテストカバレッジを上げる」「この issue の再現手順を作って修正案を出す」といった、数十分は自走できる粒度です。指示には目的だけでなく、判断に必要な材料と受け入れ条件を書いておくと、途中で人間に確認を求めてくる回数が減ります。プロジェクトの前提知識は CLAUDE.md のようなプロジェクト側の設定に書いておけば、毎回の指示が短くなります。

渡すタスクの種類にも向き不向きがあります。向いているのは、テストの拡充、リファクタリング、調査とレポート、issue の再現と修正案づくりのような、受け入れ条件を機械的に書けて破壊的でない仕事です。向いていないのは、本番環境に触る作業や、要件そのものが揺れていて対話を重ねないと固まらない仕事です。後者は机の前の時間に回します。

電車に乗ったらスマホから接続します。接続時コマンドを仕込んであれば、接続が完了すると家で見ていた画面の続きが目の前にあります。エージェントの出力をスクロールで確認し、確認待ちの質問に答え、diff を眺めて方向性を判断し、次の指示を出す。ここまでやってスマホをポケットに戻せば、エージェントはまた自走を始めます。1回の関与は数分で済みます。

この運用で見えてくるのは、人間の仕事が「書く」から「監督と判断」に寄るほど、スマホというインターフェースの弱点が消えていくことです。ゼロからコードを書くにはスマホの画面もキーボードも貧弱ですが、進捗を読み、判断を伝え、方向を修正するだけなら十分に足ります。エージェントの自走時間が長くなるほど、この構成の価値は上がっていきます。

帰宅後の時間の使い方も変わります。移動中に方向の判断を済ませてあるので、机に座った時点でやることは、成果物をきちんとレビューして仕上げる作業です。diff を大画面で読み、テストを流し、コミットを整える。「考えて指示する時間」と「検証して仕上げる時間」が場所で自然に分かれるのは、この構成の副産物です。

指示の書き方 — 自走時間を延ばす粒度

この構成の快適さは、エージェントが人間を呼ばずに進める時間の長さで決まります。そして自走時間は、指示の書き方でかなり変わります。

悪い例は「ログイン周りを直しておいて」のような、目的も範囲も判断基準も曖昧な指示です。エージェントは早い段階で「どのファイルのことか」「仕様はどうするか」と確認を求めて止まり、こちらが圏外の間じゅう止まったまま、ということになります。良い指示には3つの要素を入れます。第一に目的と背景(なぜやるのか)。第二に範囲(触ってよい場所、触ってはいけない場所)。第三に受け入れ条件(何が通ったら完了か。テストが通る、lint が通る、など機械的に確認できるものが理想です)。

もうひとつのコツは、判断の権限をあらかじめ渡しておくことです。「迷ったら既存コードの流儀に合わせる」「仕様が曖昧な箇所は保守的な解釈を選び、判断内容を最後にまとめて報告する」と書いておくと、細かい確認で止まる回数が目に見えて減ります。外出前の指示は、机にいるときの指示より一段ていねいに書く。この一手間が、移動中の体験を決めます。

tmux 最小セット — スマホから使う5つの操作

tmux は多機能ですが、この構成で最初に必要な操作は5つだけです。プレフィックスキー(既定は Ctrl+B)を押してから続きのキーを打つ、という作法だけ覚えてください。以下のキー割り当てはすべて tmux のマニュアルに載っている既定値です(tmux(1))。

  1. tmux attach — 接続してセッションに座る。接続時コマンドに仕込むので、実際に手で打つ機会は少ないはずです
  2. プレフィックス + d — セッションから離席する(デタッチ)。エージェントは動き続けます。接続を閉じる前に作業状態を確認し、行儀よく離れたいときに使います
  3. プレフィックス + c — 新しいウィンドウを作る。エージェントを走らせたまま、別のウィンドウでログや git の状態を確認できます
  4. プレフィックス + 数字 — ウィンドウを切り替える。ウィンドウ0にエージェント、1に作業用シェル、という配置を固定しておくと迷いません
  5. プレフィックス + [ — スクロールモード(コピーモード)に入る。エージェントの過去の出力をさかのぼって読むのに必須で、矢印キーで移動し、q で抜けます

セッションに名前を付けておくと、接続時コマンドやウィンドウ配置が安定します。母艦で最初に一度だけ作り、以後はスマホからも机からも同じ名前で座ります。

tmux new-session -s agent   # agent という名前でセッションを作る(母艦で一度だけ)
tmux attach -t agent        # そのセッションに座る(接続時コマンドに向く)
tmux attach -d              # 他の端末の接続を切りながら座る(表示が狭くなったとき)

5つとも、プレフィックスの Ctrl が打てることが前提です。ソフトウェアキーボードでの Ctrl の打ち方は修飾キーの仕組みで解説しています。この5つに慣れたら、次はターミナルのショートカットで編集系の語彙を増やすと、スマホでの操作がさらに軽くなります。

ボトルネックは入力

この構成を試した人が最初にぶつかるのが入力です。エージェントへの指示は日本語や英語の文章なので普通のキーボードで打てますが、問題はそれ以外の操作です。

  • Ctrl+C(実行中の処理の中断)や Esc、履歴をさかのぼる矢印キーが標準のソフトウェアキーボードにありません。この背景は修飾キーの仕組みで解説したとおりで、多くのキーボードアプリにはそもそも修飾キーを送る経路がありません
  • /clear /compact /resume /model などのスラッシュコマンドを毎回手打ちするのが地味に面倒です。スラッシュコマンドはエージェント操作の要なのに、記号と英字の切り替えが多く、ソフトウェアキーボードと相性が悪いのです
  • tmux のプレフィックスキー(既定は Ctrl+B)が打てないと、ウィンドウの切り替えすらできません
  • 日本語の指示と英字のコマンドを行き来するため、IME の切り替えが頻発します

対策は、キーイベントを送れるターミナル向けキーボードを入れることです。The KeyBoard は Claude Code / Codex のスラッシュコマンドをワンタップで入力するパッドと本物の ⌃⌥⌘ を備えていて、まさにこの構成のために設計しました。対応する SSH クライアントでは操作系を揃えやすく、クライアント側の内蔵キーバーに頼る必要がなくなります。

よくある失敗と対処

  • tmux の外でエージェントを起動していて、切断と同時に消えた: この構成の失敗の定番です。エージェントの起動は必ず tmux の中で。接続時コマンドの tmux attach || tmux を仕込んでおけば、そもそも tmux の外に出る機会がなくなります
  • スマホで attach したら母艦側の表示が狭くなった: tmux はウィンドウの大きさを window-size オプションで決めていて、smallest ならいちばん小さい端末、latest なら最後に操作した端末に合わせます。スマホ側の接続が残っていると机の画面がスマホの幅に引きずられるので、tmux attach -d で他の接続を切りながら attach すれば解決します。-d はそのセッションに接続している他のクライアントをデタッチするオプションだとマニュアルにあります(tmux(1))
  • 戻ってみたら承認待ちで止まっていた: エージェントは危険な操作の前に人間の承認を求めて止まります。長く自走させたい日は、出かける前にそのタスクで必要になる操作の承認方針を整えておくか、「止まっているかもしれない」前提でこまめに覗く運用にするかを選びます
  • スマホで長文の指示を書くのがつらい: 無理にターミナル内で書く必要はありません。フリック入力で下書きしてから貼り付ける、音声入力で骨子を作って整えるなど、文章作成はスマホの得意な道具に任せて、ターミナルには完成した指示だけを渡すやり方が楽です
  • 圏外に入るたびに不安になる: 母艦と tmux 内のプロセスが稼働していれば、スマホの切断後も作業は継続できます。トンネルを抜けたら attach し直すだけです。切断=事故ではなく、切断=いったん席を立った、と捉え直すとこの構成の気楽さが分かります
  • 電池の減りが気になる: SSH 自体の通信は軽く、電池を食うのは主に画面の点灯です。確認のたびに接続し直す使い方で十分で、つなぎっぱなしにする必要はありません
  • 机とスマホの両方からセッションを開いていて入力が混ざった: tmux は同じセッションに複数の画面から同時に入力できてしまいます。家族や同僚と共有しているマシンでなければ実害は稀ですが、机の端末で何かを打ちかけたまま外出すると、スマホでの入力と混ざって混乱します。離席するときは打ちかけの行を消しておく習慣で防げます
  • エージェントの長い出力を追いきれない: スマホの画面では一度に読める量が少ないので、スクロールモード(プレフィックス + [)でさかのぼって読むのが基本動作になります。エージェント側に「変更点を最後に箇条書きで要約して」と指示しておくと、小さい画面でも把握が楽になります

セキュリティの注意

この構成は自宅の開発マシンへの入口を持ち歩くことを意味するので、守りは固めておきます。第一に、SSH は公開鍵認証にしてパスワード認証を無効化すること(前述の PasswordAuthentication no)。第二に、SSH ポートをインターネットに直接晒さず、必ず VPN の内側に置くこと。この2つで、経路の守りはかなり固くなります。

エージェント側の設定にも注意が要ります。Claude Code の権限モードには、ツールごとに最初の使用時に確認する default、ファイル編集を自動で受け入れる acceptEdits、権限プロンプトを省く bypassPermissions などがあり、bypassPermissions については「Claude Code が損害を引き起こせないコンテナや VM などの隔離された環境でのみ使用」するよう公式ドキュメントが警告しています(Claude Code Docs: 権限を設定する)。危険な操作の自動承認を広く与えたまま外出すると、確認の目が届きにくいところでエージェントが強い権限で動くことになります。外出中に走らせるタスクでは、/permissions で許可ルールを必要なコマンドに絞り、モードは保守的に振っておくのが無難です。破壊的な操作やデプロイを伴うタスクは、机の前にいる時間帯に回すという運用上の切り分けも効きます。

鍵の管理にもひとつ原則があります。スマホ用の鍵は母艦からコピーせず、スマホの上で新しく作ることです。端末ごとに別の鍵にしておけば、スマホを失くしたときに母艦側でその鍵の行だけを authorized_keys から消せば済み、他の端末は影響を受けません。秘密鍵をメールやチャットで端末間コピーするのは、それ自体が漏えい経路になるので避けてください。

最後にスマホ本体です。この構成ではスマホが開発環境の鍵になるので、画面ロックを固くし、SSH クライアントの鍵には生体認証のアンロックを設定し、紛失時に遠隔で消去できる状態にしておいてください。また、業務のコードベースにこの構成でつなぐ場合は、必ず先に社内規程を確認してください。

Claude Code 公式の Remote Control との使い分け

Claude Code には、動いているセッションに Claude アプリや claude.ai/code から接続する Remote Control が組み込まれています。新しく Remote Control のサーバーモードを始めるには claude remote-control を使います。すでに対話中の会話を公開する場合は、その会話内で /remote-control を使います。セッション本体は母艦で動き続け、Web とモバイルは「そのローカルセッションへのウィンドウにすぎません」と公式ドキュメントは説明しています(Claude Code Docs: Remote Control)。通信は母艦からのアウトバウンド HTTPS だけなので、VPN も SSH サーバも要りません。利用には対応するサインインと環境条件があり、API キーによる利用は対象外です。プランや組織の許可条件は公式資料の Requirements を確認してください。

claude remote-control

SSH + tmux が不要になるわけではなく、役割が違います。Remote Control は Claude Code のセッションを操作する機能で、Codex など他の CLI や git の確認といったターミナル全体の操作は対象外です。また「ローカルプロセスは実行し続ける必要があります」と明記され、ターミナルを閉じるとセッションは終了します。tmux の中で起動する約束はここでも有効で、tmux の中で claude --remote-control を起動しておけば、SSH からもアプリからも同じセッションに座れます。

観点SSH + tmuxRemote Control
操作できる範囲ターミナル全体(Codex など他の CLI も)Claude Code のセッション
経路VPN 内の SSH(自分で用意)Anthropic API 経由のアウトバウンド HTTPS
母艦側の準備SSH サーバ、VPN、tmuxClaude Code のサインインと claude remote-control
通知なし(覗く運用)アプリへのプッシュ通知あり

応用

構成が安定してきたら、いくつか広げられる方向があります。

まず、tmux のウィンドウを増やして複数の作業を並走させる形です。ウィンドウ1でエージェントが実装、ウィンドウ2で自分がログ確認、ウィンドウ3で別リポジトリの調査、といった構えを作っておき、スマホからはプレフィックスキーと数字で行き来します。エージェントを複数並走させることもできますが、スマホから監督できる並列数には限りがあるので、外出中は1〜2本に絞るのが現実的です。

次に、SSH クライアントを Termux に置き換える選択肢です。Termux にはフルセットの OpenSSH が入るので、母艦の ~/.ssh/config の資産をそのまま持ち込めます。ターミナル環境として Termux に慣れておくと、母艦に届かない非常時にスマホ単体で git 操作するといった逃げ道も増えます。

母艦の tmux セッションという「作業の本体」が場所から独立しているので、出先ではスマホから、自宅では机の大画面から、同じセッションに座れます。移動が多い日には、回線の切り替わりや一時的な圏外に強い mosh の併用も検討の価値があります。構成は変えず、端末側だけを場面に合わせて選べるのが、母艦にすべてを置くこの構成の利点です。

よくある質問

Claude Code と Codex で構成は変わりますか

変わりません。この構成はエージェントの種類に依存せず、「母艦のターミナルで動く対話型 CLI を tmux 越しに操作する」という一般的な形です。他の CLI エージェントでも、ターミナルで動くものならそのまま当てはまります。前述の Remote Control は Claude Code 側の機能ですが、SSH + tmux は両方に共通なので、乗り換えや併用のときも構成側は何も触る必要がありません。

母艦は常時起動しておく必要がありますか

エージェントを走らせている間は起動が必要です。24時間の常時稼働までは要りませんが、外出中に使いたい日は電源とスリープ設定を確認してから出てください。自宅に置けるマシンがない場合は、クラウドの VPS を母艦にする手もあります。常時起動と回線品質の点ではむしろ有利ですが、コードと認証情報を預ける先としての判断は必要です。

回線が切れたらエージェントは止まりますか

母艦とプロセスが正常に稼働していれば、スマホ側の切断だけで作業が終了する構成ではありません。ただし、承認待ちや母艦の通信障害、プロセスの終了で停止することはあります。tmux がセッションを保持しているため、再接続して attach すれば切断中の出力もさかのぼって確認できます。むしろ「切れても進む」ことがこの構成の核心で、スマホは監督者が時々覗く窓にすぎません。

作業の完了を通知で知ることはできますか

SSH + tmux の構成単体では、スマホに通知は届きません。基本は「移動の区切りで覗く」運用で、エージェントの自走時間は数十分単位なので、それで実用上は困りません。覗く行為自体が数十秒で終わるように接続の摩擦を減らしておくことのほうが、通知の仕組みを作るより先に効きます。Claude Code なら Remote Control を有効にしているときにアプリへプッシュ通知を送れ、/config の「Push when Claude decides」「Push when actions required」で切り替えられます(Claude Code Docs: Remote Control)。まずは覗く運用で始めて、必要を感じてから足すことをすすめます。

iPhone でも同じ構成が組めますか

構成の骨格(母艦 + tmux + VPN + SSH クライアント)はそのまま組めます。iOS にも SSH クライアントの定番は複数あり、Tailscale も動きます。違いが出るのは入力環境で、キーボード拡張に関する OS の制約が Android より強いため、修飾キーやスラッシュコマンド入力の自由度は Android に分があります。iPhone で組む場合は、SSH クライアント内蔵のキーバーが充実したアプリを選ぶことが Android 以上に重要になります。

スマホ単体で完結させられませんか

エージェント本体を母艦に置くのがこの記事の前提です。実行環境・電池・バックグラウンド制限という3つの理由から、スマホ単体でエージェントを長時間自走させる構成はすすめません。スマホ側を厚くしたい場合も、Termux は踏み台と軽作業に使い、重い処理は母艦か VPS に寄せる構成が安定します。

次の一歩

時間を確保できるときに、セットアップ手順の1〜5(リモートログイン、スリープ設定、鍵と PasswordAuthentication no、Tailscale、クライアント)まで進めてください。明日の朝、家を出る前に tmux new-session -s agent の中でエージェントにタスクをひとつ渡し、電車の中で tmux attach -t agent してみる。初回は眺めるだけで構いません。「家の作業が、ポケットの中で続いている」感覚を一度体験すると、この構成が手放せなくなる理由が分かります。入力のもたつきを感じたら、それが修飾キーと入力環境に投資するタイミングです。

外出先で受け取る報告の形を決める

スマートフォンで大きな差分をすべて読むのは難しいため、依頼するときに「何を報告してほしいか」も決めておきます。たとえば「変更したファイル」「利用者から見た変化」「実行した確認と結果」「未確認の点」の順でまとめてもらうと、次の判断に必要な情報を探しやすくなります。

仮に問い合わせフォームの表示を直すなら、「修正しました」という報告だけでは、スマートフォンの表示を確認したか、送信処理も変更したかがわかりません。「見た目の変更」「送信への影響」「確認した画面」を分けて報告してもらいます。これは成果物そのもののレビューを置き換えるものではなく、何を追加で確認すべきかを絞るための要約です。

報告の項目次の判断につながる内容
変更内容どの問題を、どの範囲で直したか
確認結果実行した確認と、成功・失敗の結果
残る疑問未確認の条件や必要な判断
次の操作続ける作業と、その影響範囲

小さな画面で判断できない差分は、対象ファイルを絞って読むか、大きな画面へ戻るまで保留します。短い要約がもっともらしく見えることと、変更が適切なことは別です。

回線復帰後は、最後に確認できた状態から続ける

接続が切れた直後に同じ依頼をもう一度送ると、すでに終わった操作を重ねて指示することがあります。再接続時には、エージェントが動いているかだけでなく、最後の依頼に対する結果まで確認します。

順序としては、接続先とセッション名を確かめ、直近の出力を読み、ファイルの変更や実行中の処理を確認してから、次の依頼を送ります。たとえば「テストを開始した」まで見て切れたなら、再開後はまず結果を探します。結果が確認できない場合に、再実行が適切かを判断します。

移動中の最後に「どこまで確認したか」を短く残しておくと、机へ戻ったときも役に立ちます。「差分の要約は読んだが、画面確認は未実施」のように、作業の完了と人間の確認の完了を分けて記録します。これにより、スマートフォンと PC の往復が、確認漏れを生む切れ目になりにくくなります。

参考リンク