For the complete documentation index, see llms.txt. Markdown versions of documentation pages are available by appending .md to the page URL.
メインナビゲーション
2026年6月23日 Codex

スマートフォンで使いこなすリモート開発

ChatGPT モバイルアプリのリモートを使って、開発作業の開始、軌道修正、レビュー、整理を行いましょう。

著者: Thomas Ricouard

スマートフォンで使いこなすリモート開発

ChatGPT モバイルアプリのリモートは、その実力が見過ごされがちです。

一見すると、スマートフォンからコーディングのチャットの様子を確認するための機能に見えます。それも便利ですが、本質はもっと大きなところにあります。リモートの真価は、iPhone を小さなターミナルとして使おうとせずに、開発マシン上の作業を開始し、指示を出し、レビューし、整理できることにあります。

この 2 か月間で、こうした一連の操作に驚くほど多くの機能を加えてきました。リモートホストへの接続、Worktree、目標、サイドチャット、インラインコードレビュー、プロンプトのキューへの追加と軌道修正、添付ファイル、スキルとプラグイン、チャットのアーカイブ、セキュリティ管理に加え、本格的な作業でアプリを役立てるための細かな改善も数多く行いました。

この記事は、これから使いこなそうとするすべての方に届けたい実践ガイドです。

ChatGPT モバイルアプリのリモートのプロジェクト選択画面

基本の考え方:スマートフォンは制御の窓口

コードが動く場所は変わりません。Mac、Windows マシン、開発用マシン、その他の接続済みホストなど、本来実行すべき場所で動きます。ChatGPT モバイルアプリのリモートは、その作業を操作するためのネイティブインターフェースを提供します。

この役割分担が重要です。目的は、ターミナルでできることをすべて小さな画面に再現することではありません。エージェントの作業を前に進めるために必要な次のような判断を、どこからでも簡単に下せるようにすることです。

  • どのリポジトリとワークスペースを使うべきですか?
  • 現在のブランチと新しい Worktree のどちらで実行すべきですか?
  • 次のメッセージは待たせるべきですか?それとも、進行中のターンの方向を変えるべきですか?
  • このコマンドは承認しても安全ですか?
  • 何が変わり、その変更に納得できますか?
  • 継続的に取り組む目標にすべきですか?別のチャットに分けるべきですか?それとも、ちょっとした補足の質問で済みますか?

このように使うと、アプリはリモートデスクトップソフトウェアというよりも、開発作業を統括するための窓口に感じられるようになります。

1. チャット開始時の適切な作業範囲の設定

エージェントに良い仕事をしてもらうには、作業範囲を適切に定めた環境を用意することが出発点です。リモートでは、最初のプロンプトを送る前に、接続済みホストとワークスペースを選べます。新しいチャットでは、ブランチの選択、独立した Worktree の作成、それに紐づく環境セットアップの実行もできます。

ホスト、リポジトリ、Worktree、環境を選ぶリモートの操作画面

これにより、次のような便利な使い方ができます。

  • 手早く調査したいときは、現在のチェックアウトを使います。
  • 他の作業から切り離しておきたい変更には、新しい Worktree を作成します。
  • 後から Git の状態を直さずに済むよう、意図したベースブランチから始めます。
  • Codex にビルドやテストを依頼する前に、環境セットアップを実行しておきます。

使いこなすうえで特に大切なのは、10 秒かけて適切な実行コンテキストを選び、後の片付けにかかる 10 分を省く習慣です。

コンポーザーでは、テキスト以外のコンテキストも渡せます。ファイルや写真、その場でカメラ撮影した画像を添付できます。スキルとプラグインはインラインで表示されるため、プロンプトが意図した機能を呼び出すかどうかを、ずっと簡単に確認できます。

複数のスキルとプラグインをインラインで追加したリモートのコンポーザー

私が決めていることはシンプルです。スクリーンショット、ファイル、特定のスキルで曖昧さをなくせるなら、最初のターンの前に添付するか、名前を指定しておきます。

2. 「キューに追加」と「軌道修正」の違い

これは、リモートの中でも効果の大きさが最も伝わりにくい設定かもしれません。

Codex がすでに作業中の場合、追加のメッセージの扱いには次の 2 通りがあります。

  • キューに追加 では、現在の応答が終わるまで待ち、その後でプロンプトを次のターンとして送信します。
  • 軌道修正 では、進行中の作業に指示を差し込みます。

デフォルトには「キューに追加」を選ぶと安心です。次のタスク、追加のテスト依頼など、現在の作業が終わってから行うべきことに使います。

「軌道修正」は、間違った方向へ進み続けることで無駄が増えているときに、方向を正すために使います。たとえば、次のような指示です。

修正はモバイルパッケージ内にとどめてください。共有レンダラーのリファクタリングはしないでください。

問題が再現するのは再接続後だけです。接続が続いている場合の処理ではなく、再開時の処理をテストしてください。

UI の調査はやめてください。再開時にサーバーがその項目を削除したかどうかを確認してください。

これにより、スマートフォンは単なる状況確認用の画面以上に役立ちます。実行中の作業で判断が必要になった、その瞬間に介入できます。

追加のメッセージのデフォルトの動作は、設定で選べます。私は「キューに追加」をデフォルトにして、「軌道修正」は必要なときに意識して使っています。ターンの途中でうっかり方向を変えると、たいていは待つよりも手間が増えるからです。

3. 考えを枝分かれさせるサイドチャットの活用

長く続くコーディングのチャットには、貴重なコンテキストが蓄積されます。補足の質問を思いつくたびに割り込むと、メインの会話履歴が雑然とし、エージェントが目標からそれることもあります。

サイドチャットは、この問題を解決します。

/side を使うと、現在のチャットにつながる軽量な会話を開けます。/side <prompt> を使えば、質問を添えて開けます。さらに便利なのが、会話履歴のテキストを選択して サイドチャットで質問を選ぶ方法です。選択した箇所が、新しい会話の最初のコンテキストになります。

会話履歴のテキストを選択し、「サイドチャットで質問」アクションを表示した画面

私は、次のような質問にサイドチャットを使っています。

  • Codex がこのアーキテクチャを選んだのはなぜですか?
  • このエラーは、具体的には何を意味していますか?
  • この動作はデスクトップアプリと一致していますか?
  • この実装の詳細を、リリースノート向けに書き直してください。
  • このコマンドを承認する前に、何を確認すべきですか?

メインのチャットは作業を進める場所、サイドチャットはその作業を理解するための場所と分けると便利です。

4. 進め方を決めるプランと、成果を定める目標

プランモードと目標は、それぞれ異なる問題を解決します。

プランモードでは、コードを変更する前に実装の進め方を提案するよう Codex に求めます。タスクの詳細が十分に決まっていない場合や、リスクがある場合、複数のシステムに変更が及びそうな場合に役立ちます。

目標は、ターンをまたいで保持されます。どのような成果を追求し続けるべきかを Codex に伝えるものです。モバイルでは、/goal で目標を作成、管理でき、作業が進む間も進捗を確認できます。

実践的な進め方は、次のとおりです。

  1. リスクのある変更は、プランモードから始めます。
  2. 提案された作業範囲を確認します。
  3. 何度か試行や修正を重ねる必要がある作業では、合意した成果を目標として設定します。
  4. 毎回目標を伝え直すことなく、実装、テスト、レビューのフィードバックへの対応、後片付けまで Codex に進めてもらいます。

プランは「どう進めるべきか?」に答えます。目標は「何が満たされれば完了と言えるか?」に答えます。

5. 会話を離れずにコードレビュー

リモートが単に便利な機能を超え、エンジニアリングで真価を発揮するのが、このレビューのサイクルです。

ターンが完了すると、変更されたファイルの概要が表示されることがあります。そこから差分を開き、個々のファイルの確認、セクションの展開や折りたたみ、長い行の折り返しができます。ソースファイルをシンタックスハイライト付きで開くこともできます。該当する行にインラインコメントを付け、そのレビューのコンテキストを Codex に送り返せます。

インラインのレビューコメントが付いたリモートの差分画面

このワークフローでは、必要に応じて確認の深さを選べます。

  • 変更ファイルの概要を開き、大きな問題がないか手早く確認します。
  • 差分だけでは前後の文脈が足りないときは、タップしてソース全体を開きます。
  • インラインコメントを追加して、修正内容を具体的に伝えます。
  • レビューコマンドで、ローカルの変更をレビューしたり、ブランチと比較したりします。
  • 特定のファイルについて Codex に検討してほしいときは、そのファイルへのリンクをチャットに追加します。

これにより、モバイルでも次のようにテンポよくレビューを進められます。

  1. Codex が実装を完了します。
  2. 私がスマートフォンで差分を確認します。
  3. インラインコメントを 2 件残します。
  4. Codex が同じチャットでそれらに対応します。
  5. 追加修正による小さな差分を私がレビューします。

重要なのは、コードをじっくり読むための大型モニターをスマートフォンで置き換えることではありません。それはできません。多くのレビューは 1 つか 2 つの判断を待って止まっており、その判断のためにデスクに戻るまで待つ必要がなくなることに意味があります。

6. ワークフローの一部としての権限管理

リモートでの作業が役立つのは、何を許可するかを明確に管理できる場合に限られます。

リモートでは、コマンド、ファイルの変更、ネットワークアクセス、接続されたツールに対する承認リクエストが表示されます。リクエストとホストの構成によって、承認の適用範囲は今回限り、現在のチャット全体、またはそれより広い範囲になる場合があります。

使いこなすコツは、すべてを承認することではありません。作業を進めるために必要な、最小限の権限を選ぶことです。

信頼できるチャットで、動作を十分に理解しているコマンドを実行する場合は、チャット単位の承認にすると繰り返し中断されずに済みます。見慣れないコマンド、機密性の高いリポジトリ、影響が不明なリクエストの場合は、今回限りの承認にするか、拒否して Codex に説明や、より安全な方法での対応を求めます。

作業を始める際には、チャット全体の承認動作も選べます。ホスト、ワークスペース、ブランチ、モデルの選択と同じく、チャットのセットアップの一部と考えてください。

7. 問題が起きる前のコンテキスト管理

エージェントとのチャットは状態を保持します。長く続けるとコンテキストが蓄積し、やがて応答が遅くなったり、焦点がぼやけたりします。

リモートには、こうしたチャットのライフサイクルを管理するためのツールがいくつかあります。

  • /status は、セッションの詳細、ワークスペース、コンテキストの使用量、取得可能なレート制限の情報を表示します。
  • 任意で有効にできるコンテキストインジケーターを使うと、コンポーザーでコンテキストの残量を常に確認できます。
  • /compact は、作業に役立つ状態を保ちながら、長くなりすぎたチャットを圧縮します。
  • 履歴を引き継ぎながら別の方向に進みたいときは、/fork で現在のチャットから新しいチャットを作成します。

実際には、まず状態を確認し、目的が変わっていなければコンパクションを行い、目的が分かれたらフォークする、という順序で判断します。

サイドチャットとフォークは使い分けてください。サイドチャットは、現在の作業にまつわるちょっとした質問のためのものです。フォークすると、元のチャットの履歴を引き継ぐ新しいメインチャットが作成されます。

8. チャット一覧の整理

私自身の Codex ワークフローは、だんだん小さな管制室のようになってきました。

実際に動いている少数のチャットをピン留めし、目指す成果が分かる名前に変更し、作業が終わったら積極的にアーカイブしています。アーカイブしたチャットも閲覧できるので、安心して整理できます。アーカイブは削除ではなく、整理です。

通知もこの仕組みの一部です。完了通知から該当する Codex チャットを直接開けるので、「エージェントの作業完了」から「人によるレビュー」への引き継ぎは、ワンタップで済みます。

Spotlight やショートカットからリモートを直接開けます。iPad では、キーボードショートカットを使うと驚くほど効率よく操作できます。新しいチャットの作成、チャット間の移動、変更ファイルの表示、ピン留め、名前の変更、アーカイブといった操作のたびに、画面上のボタンに手を伸ばす必要がありません。

これは、リモートを「参謀役」として使う方法です。私にとって、このアプリはプロンプトを送るだけの場所ではありません。どの開発作業が進行中で、何が行き詰まり、どれがレビュー待ちで、何が完了したのかを把握する場所でもあります。

9. 隠れたコマンドパレット

/ を入力すると、アプリのさまざまな高度な機能に最短でアクセスする方法が表示されます。利用できる機能は、接続先のホスト、アプリのバージョン、アカウントの構成によって異なる場合があります。

コマンド用途
/plan実装前にプランモードのオン・オフを切り替えます。
/goal <objective>ターンをまたいで維持される目標を作成・更新します。
/side [question]メインチャットの流れを妨げずに、関連する質問をします。
/reviewローカルの変更をレビューしたり、ブランチと比較したりします。
/statusセッション、ワークスペース、コンテキスト、レート制限を確認します。
/compact長くなったチャットのコンテキストを圧縮します。
/fork現在の履歴から新しいメインチャットを作成します。
/fast利用可能な場合に、標準の実行とより高速な実行を切り替えます。
/feedback現在のセッションに紐づけて、製品へのフィードバックを送信します。

コマンドパレットは覚える価値があります。計画し、目標を追い、分岐し、レビューし、状態を確認し、立て直すという、この製品の基本的な考え方が表れているからです。

10. モバイルと特に相性のよい 5 つのワークフロー

リリースの取りまとめ

リリースや Pull Request に絞ったチャットを始めます。現在のブランチ、CI の状態、未対応のレビュー指摘、リリースに含まれる変更を確認するよう Codex に依頼し、そのチャットをピン留めします。新しい情報が入ったら、進行中の調査の前提が崩れる場合にだけ方向修正し、それ以外はキューに入れます。スマートフォンから最終的な差分やリリースノートをレビューし、リリースが完了したらチャットをアーカイブします。

割り込みで入るバグ修正

スクリーンショット、ログ、取得したファイルを添付します。編集前に原因を診断するよう Codex に依頼します。メインの調査を脱線させずに、サイドチャットで疑わしいエラーを 1 つ掘り下げます。原因が明らかになったら、メインチャットに戻り、範囲を絞った修正を許可します。

モバイルでのレビュー

意図したブランチを比較対象にレビューを実行し、変更ファイルの概要を確認して、重要なファイルを開き、インラインコメントを付けます。そのコメントだけに対応するよう Codex に依頼し、追加修正の差分をレビューします。

長時間かけて取り組む目標

テストの成功、レビュー指摘の解消、再現可能な形での性能基準の達成など、具体的な完了条件を持つ目標を作成します。「終わりましたか?」と繰り返し尋ねる代わりに、通知やステータスで進捗を確認します。追加の作業はプロンプトをキューに入れ、進行中の作業への介入は方向修正が必要な場合に限ります。

複数マシンの使い分け

ホストには分かりやすい名前を付け、マシンとワークスペースごとに作業を整理します。必要なチェックアウトや認証情報、シミュレーター、OS を備えたマシンで、スマートフォンからチャットを始めます。あるチャットでは Mac が必要で、別のチャットでは Windows ホストが必要な場合などに、特に便利です。

小さくても効果の大きい機能

私が特に気に入っている追加機能には、次のような目立たないものもあります。

  • 修正のためにターンを追加する代わりに、最後に送信したプロンプトを編集します。
  • チャットに表示された画像を保存またはコピーします。
  • Codex の実行中に、キューに入っているプロンプトを確認します。
  • 通知から完了したチャットを直接開きます。
  • アクティブなチャットの一覧をいっぱいにせず、アーカイブ済みのチャットを参照します。
  • 幅の狭い画面で差分を読むときは、長い行を折り返します。
  • Face ID またはデバイスのパスコードを使って、ChatGPT モバイルアプリを保護します。
  • 送信前に、コンポーザー内に表示されているスキルやプラグインを確認します。
  • 実物を見せることで状況が伝わる場合は、写真を撮影してプロンプトに直接添付します。
  • 質問を説明し直す代わりに、会話履歴のテキストを選択してサイドチャットを始めます。

どの機能も、エージェントの基本的な仕組みを変えるものではありません。これらが組み合わさることで、リモートでのワークフローを心もとなく感じさせる手間や不便がなくなります。

ここから得られる教訓

優れたモバイルソフトウェアは、デスクトップのインターフェースを単に縮小するものではありません。デスクを離れているときに重要となる判断を見極め、状況を把握したうえで、すばやく安全に判断できるようにします。

今の私は、リモートをそのように捉えています。適切な環境を選び、目標を設定し、実行中の作業の方向を修正し、承認リクエストに応答し、結果を確認し、開発作業のキュー全体を整然と管理できる場所です。

作業をするのは、変わらずコンピューターです。スマートフォンがあれば、私はその作業の主導権を握り続けられます。