Codexの使用量が切れた。そこでChatGPTから自宅PCにつなぐ「リモート開発」を試した
AIにコードを書かせていると、いちばん困るのはエラーではなく「続きができない」ことかもしれません。私の実験室でも、Codexで作業を進めている途中に利用上限へ達し、画面に「You've hit your usage limit.」と表示されました。
以前なら、そこで回復を待つか、私がPCの前に戻って手作業するしかありませんでした。今回は別の方法を試しています。AIチャットから自宅のWindows PCへ接続し、ファイルやターミナルを直接扱える経路を用意しておく方法です。
先に書いておくと、これは「Codexを無料で無制限に使う裏技」ではありません。AIそのものと、AIが作業するPCを分けて考え、一つのエージェントが止まっても仕事全体まで止めないための設計です。
Codexが止まると、開発そのものが止まっていた
実験室では、Codexの利用上限到達を実際の画面で確認しています。コードやGitHub側に問題がなくても、エージェントの利用枠がなくなれば、その経路では先へ進めません。
この問題は、AIをたくさん使うほど効いてきます。開発の入口を一つのAIにまとめると、そのAIの利用枠がそのまま「今日どこまで仕事できるか」の上限になるからです。
私は以前、もっと原始的なところでも止まっていました。PC画面をスマホで撮り、AIへ送り、「次はどこを押す？」と聞いて、言われた通りに操作する。この頃の記録は、前回の記事「実験日誌 #2｜AIに開発を任せたはずが、私はずっと『スクショ係』だった」に残しています。
AIがコードを書いているのに、人間が画面を運んでいる。この状態では、AIが賢くなっても私の作業はなかなか減りませんでした。
変えたのはAIではなく「PCまでの道」だった
そこで試したのが、AIチャットと自宅PCを直接つなぐ方法です。現在の実験環境では、Windows PCをDesktop Commander Remote経由で接続し、AIチャット側からPC上のファイルを読んだり、ターミナルでコマンドを実行したりできる状態を確認しています。
ここは少し誤解しやすいところです。Desktop Commander Remoteは、一般的なリモートデスクトップのように「画面を丸ごと見てマウスを動かすアプリ」と同じものではありません。今回役に立っているのは、AIチャットからPCのファイルやターミナルへ届く経路です。
これがあると、少なくともファイルとコマンドで完結する作業では、私がスクリーンショットを何枚も運ぶ必要が減ります。AI側が対象ファイルを読み、必要なコマンドを実行し、その出力を確認できます。
一方、画面上のボタンを押すようなGUI操作は別問題です。実験室では過去にAntigravityのRemote Controlも試し、スマホからPC上の開発エージェントへ入り、実装からテスト、GitHubへの反映、CI、レビュー、マージ、その後のmain確認まで一連の流れを完走した記録があります。
ただし、これは過去の成功実験です。その後の運用見直しで、Antigravityは標準の開発経路から外しています。「一度うまくいったから、今も常にこれが最適」とは扱っていません。
実際に便利だったのは「別のAIへ逃げること」ではない
最初は「Codexが止まったらGemini、Geminiが止まったら別のAI」と考えがちでした。でも、それだけでは根本的な解決になりません。AIを替えるたびに作業場所、認証、ファイル、進捗の説明までやり直すなら、人間が新しい中継係になるだけです。
役に立ったのは、PCとGitHubを共通の作業場所にしたことでした。AIが変わっても、同じリポジトリ、同じブランチ、同じテスト結果を見られるようにしておけば、引き継ぎの負担を小さくできます。
そして、もう一つ大事だったのが「完了」の判定です。AIが「終わりました」と返しただけでは完了にしません。GitHubに変更があるか、CIが通ったか、必要な成果物が保存されているかを実物で読み直します。実験室ではこの確認をREAD-BACKと呼んでいます。
このルールを入れると、使うAIを替えても判定基準は変わりません。Codexでも、別のAIでも、最後に見るのはAIの自信ではなく残った成果です。
ただし、リモート接続は万能な代替手段ではない
今回の実験から「Codexが使えなくても同じ品質と速度で全部できる」とは言えません。ファイル編集やターミナル操作はリモート接続と相性がよい一方、GUIだけで完結する操作や、そのサービス固有の機能が必要な仕事は別の経路が必要です。
また、自宅PCがオンラインであることも前提になります。PCが落ちていれば、そのPCを作業場所にする方法は使えません。別のAIにもそれぞれ利用上限や制約があるので、単純にサービス名を入れ替えれば無限に働けるわけでもありません。
認証情報の扱いにも注意が必要です。パスワードやAPIキーをAIへの指示文へ貼り付けるのではなく、OSやGitHubなど既存の認証機構に置き、AIには必要以上の秘密情報を渡さない方が安全です。
私なら「利用上限」をこう扱う
今は、利用上限をエラーというよりルーティング条件として扱っています。
- Codexが使えるなら、Codexに向いている開発作業を任せる。
- Codexが止まったら、ファイルやターミナルで完結する仕事はAIチャットからリモートPCへつなげられるか確認する。
- GUI操作が必要なら、承認済みの別経路がある場合だけそちらへ切り替える。
- どの実行経路も使えないなら、無理に突破せず、仕様整理、監査、記事化などPC実行を必要としない仕事へ移る。
大事なのは、同じ仕事を複数のAIへ同時に投げないことです。誰がどのブランチを触っているか分からなくなると、利用上限より面倒な重複作業や競合が起きます。私の環境では「一つの仕事に一つの主担当」を基本にしています。
「AIを止めない」より「仕事を止めない」方が大事だった
Codexの利用上限に当たったとき、最初に考えたのは「どうやってCodexを復活させるか」でした。でも、実際に仕組みを組み替えてみると、問いが少し違っていました。
止めたくないのはCodexではなく、開発そのものです。
そのためには、特定のAIを常に使えるようにするより、PC、GitHub、テスト、成果物の確認方法を共通化し、使える実行経路へ仕事を渡せるようにしておく方が効きました。
もし今、AIコーディングエージェントの利用上限で毎回作業が止まっているなら、次に検討するのは「別の有料枠を買うか」だけではありません。まず、自分の開発作業のうち、ファイル操作、ターミナル操作、GUI操作、最終確認を分けてみる。そこから、どの部分なら別の経路へ逃がせるかを見ると、単一サービスへの依存を減らしやすくなります。
この実験室でも、リモート開発の仕組みはまだ完成形ではありません。今後は、どの作業をどの経路へ振り分けると人間の介入が減るのかを、実際の開発ログで引き続き測っていきます。