クラウドサーバーでエージェントを実行

クラウドサーバー上で Claude Code や Codex を長期動かす:ツール導入、QCode キーとエンドポイント、tmux による切断後の継続、鍵認証への安全な切り替え。

最終更新 2026-10-19

API キーが必要ですか? 登録する →エンドポイントと Base URL →

目次

Last verified: 2026-10-19 · 📄 Per qcode.cc and official docs (tmux / OpenSSH / Ubuntu Server)

ℹ️ クラウドサーバーの構成ページとコンソールは、現在 中国語と英語の画面のみ に対応しています。製品ページ:https://qcode.cc/en/cloud

稼働しつづけるマシンで Claude Code や Codex を動かす場面です。数十分、数時間かかるジョブが SSH 切断で止まってはいけませんし、戻って進捗を確認できる必要があります。クラウドサーバーはその用途で作られています。ツールを入れてキーを設定したあとは、SSH を切ってもタスクを動かし続けることと、鍵認証に切り替えることの 2 点が重要になります。

マシンの買い方は クラウドサーバーの購入と使い方、課金と返金のルールは クラウドサーバーの請求とルール を参照してください。

サーバー上に Claude Code / Codex を入れる

クラウドサーバーのページには次の 2 つのコマンドが載っています。サーバー上でそのまま実行してください。

curl -fsSL https://qcode.cc/install/claude-code.sh | bash -s -- --lang en
curl -fsSL https://qcode.cc/install/codex.sh | bash -s -- --lang en

スクリプトの表示は英語になります(--lang で選べるのは zh と en だけです)。

スクリプトはアクセスの速さを測ってドメインを選び、cr_ で始まるキーを求め、設定を書き、必要なら Node.js と CLI を導入し、最後に最小限のリクエストを 1 回送って疎通を確認します。パラメータとロールバック手順は ワンクリック設定スクリプト にあります。

QCode のキーとエンドポイントを設定する

ワンクリックスクリプトが設定の書き込みまで済ませています。手書きで設定する場合、あるいは書いた内容を確認したい場合は、次の 2 箇所を見てください(環境変数の設定 と Codex クイックスタート 原文より)。

Claude Code(Anthropic プロトコル):

export ANTHROPIC_BASE_URL="https://api.qcode.cc/api"
export ANTHROPIC_AUTH_TOKEN="cr_あなたのキー"

Codex(OpenAI Responses プロトコル)— 先にディレクトリを作り、~/.codex/config.toml を書きます:

mkdir -p ~/.codex
model_provider = "qcode"
model = "gpt-6.1-sol"
model_reasoning_effort = "high"

[model_providers.qcode]
name = "qcode"
base_url = "https://api.qcode.cc/openai"
wire_api = "responses"
requires_openai_auth = true

~/.codex/auth.json:

{
  "OPENAI_API_KEY": "cr_あなたのキー"
}

設定後、base_url が https://api.qcode.cc/openai、ANTHROPIC_BASE_URL が https://api.qcode.cc/api になっているか、キーが cr_ で始まっているかを確認してください。手書きの export は現在のシェルにだけ有効なので、動いている tmux セッションにも反映させるには tmux セッション内で実行するか、~/.bashrc に書いてください。

tmux で切断後もタスクを動かし続ける

素の ssh root@<IP> でジョブを動かすと、接続が切れた瞬間にフォアグラウンドのプロセスは終了します。tmux のセッションは持続します — マニュアルの原文はこうです。

Each session is persistent and will survive accidental disconnection (such as ssh(1) connection timeout) or intentional detaching (with the ‘C-b d’ key strokes).

つまり、SSH が不意に切れた場合も、C-b d で自分で切り離した場合も、セッションは残ります。

よく使うコマンドは 3 つです(tmux が入っていない場合は、先にシステムのパッケージマネージャでインストールしてください。Ubuntu なら sudo apt install tmux です):

tmux new -s agent      # agent という名前のセッションを作って入る
tmux ls                # サーバー上のセッションをすべて表示する
tmux attach -t agent   # さっきのセッションに再接続する

セッションから一時的に離れるときは Ctrl-b に続けて d を押します(マニュアルの既定のキーバインドは C-b プレフィックスで、d は "Detach the current client."、つまり現在のクライアントから切り離す、という意味です)。ジョブはセッションの中で動き続け、戻ってきたら tmux attach で戻れます。再接続の方法はマニュアルのとおり $ tmux attach です。

SSH の安全: 鍵認証へ切り替え、ログインできることを確認してからパスワードを無効にする

順序が重要です。Ubuntu のドキュメントは OpenSSH の設定変更について、まさにこの点に注意喚起しています。SSH しか入口がなく、設定を間違えると再起動後に自分でロックアウトされます。したがって 先に確認し、その後に無効化してください。

以下のコマンドは Ubuntu を例にします。他のディストリビューションではサービス名や設定ファイルのパスが違うため、そのディストリビューションのドキュメントを参照してください(考え方 — 鍵を先に確認し、次にパスワードを無効化し、変更後は先に検査する — は同じです)。

  1. 手元のマシンで鍵ペアを生成します(Ubuntu Server ドキュメント原文):

bash ssh-keygen -t ed25519

  1. 公開鍵をサーバーへ配置します(macOS / Linux、または Windows の WSL で実行してください。chmod はサーバー上、ログイン後のホームディレクトリで実行します):

bash ssh-copy-id root@<IP>

Ubuntu のページには、id_ed25519.pub の内容を対象マシンの ~/.ssh/authorized_keys に追記し、そのファイルのパーミッションを再確認することと書かれています — 書き込み権限があるのは認証されたユーザーだけで、権限が正しくない場合は chmod go-w .ssh/authorized_keys を実行します。

  1. 鍵でログインできることを検証します。ページはこう書いています: 「You should now be able to SSH to the target_machine without being prompted for a password.」(Ubuntu ページの target_machine はサーバーのアドレスを指します。この文の意味は、パスワードを聞かれずにログインできる、ということです。)この段階では パスワードにフォールバックさせません。そうしないと、鍵が正しく入っていないままでもパスワードで通ってしまいます:

bash ssh -o PasswordAuthentication=no -o PreferredAuthentications=publickey -i ~/.ssh/id_ed25519 root@<IP>

-o PasswordAuthentication=no を付けると、鍵が違えば Permission denied と表示されて即座に失敗し、パスワードを尋ねません。拒否されたら この先へ進まず、手順 2 に戻ってください。この時点では パスワードでログイン中のセッションを閉じないでください。別のターミナルを開いてください。

  1. ログインできることを確認したうえで、パスワードログインを無効にします。まずこのオプションをどのファイルが管理しているかを調べます。Ubuntu の /etc/ssh/sshd_config には先頭に Include /etc/ssh/sshd_config.d/*.conf があり、sshd_config.d/ の設定が主ファイルを上書きします:

bash sudo grep -rEi '^\s*PasswordAuthentication' /etc/ssh/sshd_config /etc/ssh/sshd_config.d/

一致した行はすべて PasswordAuthentication no に変更してください(sshd_config.d/ の中で yes と書いてあるファイルも同様です)。1 つも一致しなかった場合に限り、/etc/ssh/sshd_config の末尾に PasswordAuthentication no の 1 行を追加します。理由は sshd_config(5) に「Unless noted otherwise, for each keyword, the first obtained value will be used.」(特に指定がない限り、各キーワードは最初に読み込まれた値が使われます)とあるためです。Include で読み込まれるファイルは辞書順に展開され、先にある値が優先されます。マニュアルの 2 つのオプションの説明は、PasswordAuthentication — "Specifies whether password authentication is allowed."(パスワード認証を許可するかどうか)、PubkeyAuthentication — "Specifies whether public key authentication is allowed."(公開鍵認証を許可するかどうか)です。

  1. 構文を検査し、実際に使われる設定値を確認し、最後に再起動します:

bash sudo sshd -t sudo sshd -T | grep -Ei '^(passwordauthentication|pubkeyauthentication) '

sshd -T は sshd が実際に採用する設定を出力します(sshd(8) の "extended test mode" — 設定が標準出力に書き出されます)。passwordauthentication no と pubkeyauthentication yes の 2 つの値になっていることを確認してから再起動してください。passwordauthentication がまだ yes なら、別のファイルが上書きしているので、手順 4 に戻ってください。sshd -t がエラーを返した場合は、再起動せずに設定を直してください。

bash sudo systemctl restart ssh.service

  1. 再起動後にもう一度確認し、元のセッションは閉じないでおきます。別のターミナルを開いて、手順 3 と同じコマンドで鍵ログインをもう一度試します。次にパスワードだけのログインを試みて、拒否されることを確認します:

bash ssh -o PubkeyAuthentication=no root@<IP>

Permission denied が出ればパスワードログインは無効になっています。両方とも期待どおりになったら、最初のパスワードログイン中のセッションを閉じてください。

💡 ここまでで、エージェントを長期動かし続けられるマシンの準備が整いました: ツールを入れ、キーとエンドポイントを設定し、切断してもタスクが落ちず、ログインは鍵方式になりました。

費用: 2 つの内訳

  • サーバー: 注文時に選んだ期間(1・3・6・12 か月)分が残高から課金されます。期間が長いほど月あたりの換算額が安くなります。開始価格は qcode.cc/en/cloud の Compare lines 表にあります。
  • モデル: token 単位の課金で、モデルごとの単価は qcode.cc/models に掲載されています。

2 つの費用は 同じアカウント残高 から引き落とされます。

関連ページ

QCode を始める

API キーひとつで Claude Code・Codex などに対応。トークン単位の課金で、各モデルの単価は qcode.cc/models に掲載

企業版 →