Paperspace の GPU インスタンスを VS Code から使い、さらに Codex を動かすまで

2026.06.24

Paperspace の GPU インスタンス上で VS Code のリモート開発環境を立て、さらに Codex を認証して AI エージェントを動かすところまでをまとめた記事です。Paperspace のインスタンス起動はブラウザから手動で行い、その後の開発作業はローカルの VS Code から進める前提です。なお、本記事は大部分をPerplexityに執筆させてものです。

背景

クラウド GPU を使うと、手元の PC では重い学習や推論を回しにくい場面でも、強い計算資源を使って実験や開発を進めやすくなります。
一方で、ブラウザ上の Jupyter だけで作業すると、普段の IDE の操作性や拡張機能の恩恵を受けにくく、開発体験が分断されがちです。
そのため、GPU は Paperspace 側で確保しつつ、普段使っている VS Code からそのまま開発できるようにすると、コード編集・実行・エージェント利用を 1 つの画面に集約できます。

この記事で扱う範囲

この記事で扱うのは次の 2 点です。

  • Paperspace のインスタンスをブラウザから手動で起動し、ターミナルで VS Code CLI を使って GitHub 認証付きのトンネルを張ること。
  • ローカルの VS Code からそのインスタンスへリモート接続し、さらに Codex を認証して Paperspace 上で AI エージェントを動かすこと。

インスタンスの自動起動や API 叩きによる自動化には触れません。クラウド GPU サービスの利用規約や課金設計に関わるため、運用は各サービスの公式 UI や公式ドキュメントに従うのが安全です。

全体像

流れはかなり単純です。

  1. Paperspace のブラウザ画面から GPU インスタンスを手動で起動する。
  2. インスタンス上のターミナルで VS Code CLI を用意する。
  3. code tunnel を実行し、GitHub の device code 認証を通す。
  4. ローカルの VS Code から、そのトンネル名のサーバに接続する。
  5. リモート側で Codex を認証し、VS Code の PORTS タブに表示された転送先 URL を使って認証を完了させる。

この構成のポイントは、GPU リソースを使う処理そのものは Paperspace 上で走り、エディタや拡張機能の操作は手元の VS Code から一貫して行えることです。

Paperspace 側で VS Code CLI を入れる

まずは Paperspace のインスタンスをブラウザから手動で起動し、ターミナルを開きます。その上で、VS Code 公式の CLI 配布物を取得して展開します。

%cd /notebooks
curl -Lk 'https://code.visualstudio.com/sha/download?build=stable&os=cli-alpine-x64' --output vscode_cli.tar.gz
tar -xf vscode_cli.tar.gz

mkdir -p /storage/.vscode/server
ln -s /storage/.vscode/server $HOME/.vscode-server
cp code /storage/.vscode/code
ls /storage/.vscode

code.visualstudio.com から cli-alpine-x64 を取っているので、これは VS Code の公式 CLI をサーバ側に置く手順です。
/storage/.vscode/server を使うようにしているのは、Paperspace 側の永続領域を使って VS Code Server 関連のファイルを保持したいからです。毎回インスタンスの状態が初期化される構成では、この種の保存先を意識しておくと再セットアップが軽くなります。

GitHub 認証付きトンネルを張る

VS Code CLI が入ったら、次のように code tunnel をpaperspaceのターミナル上で実行します。

/storage/.vscode/code tunnel --accept-server-license-terms --name=<任意のトンネル名>

実行すると、ログイン方法として GitHub Account か Microsoft Account を選ぶ画面が出て、GitHub を選ぶと https://github.com/login/device にアクセスして一時コードを入力するよう求められます。
この認証は Git の push/pull 用の SSH 鍵ではなく、「どの GitHub アカウントにこのトンネルを紐付けるか」を決めるための device code フローです。
認証が完了すると、その Paperspace インスタンス上の VS Code Server が、自分の GitHub アカウントに紐づいたトンネル経由で見えるようになります。

ここは誤解しやすい点ですが、SSH 設定を明示的に書いていなくても問題ありません。今回使っているのは SSH ではなく、VS Code の Remote Tunnels によるクラウド中継型のリモート接続です。

ローカルの VS Code から Paperspace に入る

トンネルが張れたら、ローカル側の VS Code でも同じ GitHub アカウントでサインインしておきます。すると、Remote Tunnels の接続先一覧から先ほどのトンネル名を持つマシンに接続できるようになります。VSCode上でのリモートマシンへの接続方法は、Developing with Remote Tunnelsを参照してください。

この時点で、見た目はローカルの VS Code ですが、実際に拡張機能やターミナルが動く先は Paperspace 上の VS Code Server です。
そのため、ターミナルから Python や学習スクリプトを回せば、A6000 を含む GPU リソースをそのまま使えます。編集体験はローカル、実行環境はクラウド、という分業ができるのがこの構成の強みです。

Codex をリモート環境で認証する

ここからが少しハマりどころです。Codex の認証フローは、最終的に http://localhost:1455/... のようなローカルアドレスへ戻ってくる OAuth コールバックを前提としているため、VS Code Server が Paperspace 側にいてブラウザが手元の PC にある構成では、そのままだと認証が完了しないことがあります。

つまり、ブラウザがアクセスする localhost:1455 は手元の PC を指してしまい、Paperspace 上の Codex 拡張が待ち受けているポートに届きません。
このため、リモート開発環境や VS Code Server 上では、Codex 認証が localhost のコールバックで詰まることがあります。

PORTS タブの URL を使って認証を通す

今回うまくいった方法は、Codex の認証途中で VS Code の PORTS タブを開き、該当ポートの Forwarded Address を使うやり方です。VS Code には Microsoft dev tunnels ベースのポート転送機能があり、PORTS ビューには転送したポートとその Forwarded Address が表示されます。

実際の操作としては、ブラウザが http://localhost:1455/... のようなアドレスで止まったあと、VS Code の PORTS タブで 1455 の行を探し、その Forwarded Address に表示されている https://<subdomain>-1455.usw3.devtunnels.ms/ をコピーします。その後、ブラウザに貼り付け、http://localhost:1455/の部分と差し替えます。
これでブラウザからのアクセスが dev tunnels を経由してリモート側の該当ポートに届き、Codex の認証完了ページまで進めました。たまに認証成功の画面もhttp://localhost:1455/... のようなアドレスになっているときがあるので、その際は再度https://<subdomain>-1455.usw3.devtunnels.ms/ と差し替えます。

ここで重要なのは、1455 というポート番号や devtunnels のサブドメインは固定ではない可能性があることです。記事では固定値として書かず、「その時点で PORTS タブに表示されている該当ポートの Forwarded Address を使う」と説明するのが安全です。

要するに、ブラウザから見た localhost は手元の PC であり、Codex から見た localhost はリモートの Paperspace です。このズレを、VS Code のポート転送機能と dev tunnels の公開 URL が橋渡ししてくれた、というのが実態です。

Paperspace 側ではハートビートを回している

運用上の小さな工夫として、Paperspace 側の Notebook では簡単なハートビートを動かしています。VS Code からリモート接続して作業していると、Paperspace の画面上では「何も実行していない」ように見えることがあるためです。

例えば、ipynb 上で次のようなコードを流しておくと、一定間隔でタイムスタンプが出力されるので、Notebook セッションが生きていることを確認しやすくなります。

import time, datetime

while True:
    print("heartbeat:", datetime.datetime.now())
    time.sleep(60)

これは GPU を大きく使う処理ではなく、あくまで Paperspace 側の UI から見て「今もセッションが生きている」ことを確認しやすくするための運用上の工夫です。

この構成で何が便利か

この環境が便利なのは、GPU が必要な処理と AI エージェントによる開発支援を、同じ VS Code セッションにまとめられることです。
たとえば、Paperspace 上で Python 環境や Jupyter 資産をそのまま使いながら、Codex に環境構築、実験コード生成、デバッグ補助、リファクタリングを任せるといった運用ができます。
ローカル PC 側には高性能 GPU がなくても、契約している AI エージェントの能力とクラウド GPU の計算資源を組み合わせて、かなり強い開発環境を組めます。

注意点

この構成では、Paperspace のインスタンス起動はブラウザから手動で行う前提にしておくのが無難です。接続や開発を快適にするための工夫と、サービスの起動制御を自動化することは別問題だからです。
また、記事に載せるスクリーンショットでは、トンネル名、device code、認証 URL 内のトークン、アカウント名などは必ず伏せます。特に device code は短時間でも第三者に使われると危険なので、そのまま載せないようにします。

まとめ

Paperspace の GPU インスタンス上で VS Code CLI を動かし、GitHub の device code 認証で Remote Tunnels を有効化すると、ローカルの VS Code からクラウド GPU 環境に自然に入れるようになります。
さらに、Codex の認証で localhost のコールバックが詰まる問題は、VS Code の PORTS タブに表示される Forwarded Address を使ってリモート側のポートへ到達させることで突破できます。
公式寄りの VS Code トンネル運用に、リモート OAuth のハマりどころとその解決策を重ねることで、「強い GPU サーバ上で AI エージェントを使って開発する」環境がかなり現実的になります。

コメント

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