クラウドサーバーでエージェントを実行
クラウドサーバー上で Claude Code や Codex を長期動かす:ツール導入、QCode キーとエンドポイント、tmux による切断後の継続、鍵認証への安全な切り替え。
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 を例にします。他のディストリビューションではサービス名や設定ファイルのパスが違うため、そのディストリビューションのドキュメントを参照してください(考え方 — 鍵を先に確認し、次にパスワードを無効化し、変更後は先に検査する — は同じです)。
- 手元のマシンで鍵ペアを生成します(Ubuntu Server ドキュメント原文):
bash
ssh-keygen -t ed25519
- 公開鍵をサーバーへ配置します(macOS / Linux、または Windows の WSL で実行してください。
chmodはサーバー上、ログイン後のホームディレクトリで実行します):
bash
ssh-copy-id root@<IP>
Ubuntu のページには、id_ed25519.pub の内容を対象マシンの ~/.ssh/authorized_keys に追記し、そのファイルのパーミッションを再確認することと書かれています — 書き込み権限があるのは認証されたユーザーだけで、権限が正しくない場合は chmod go-w .ssh/authorized_keys を実行します。
- 鍵でログインできることを検証します。ページはこう書いています: 「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 に戻ってください。この時点では パスワードでログイン中のセッションを閉じないでください。別のターミナルを開いてください。
- ログインできることを確認したうえで、パスワードログインを無効にします。まずこのオプションをどのファイルが管理しているかを調べます。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."(公開鍵認証を許可するかどうか)です。
- 構文を検査し、実際に使われる設定値を確認し、最後に再起動します:
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
- 再起動後にもう一度確認し、元のセッションは閉じないでおきます。別のターミナルを開いて、手順 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 つの費用は 同じアカウント残高 から引き落とされます。
関連ページ¶
- クラウドサーバーの購入と使い方 — 回線の選び方、1 日トライアル、注文と開通
- ワンクリック設定スクリプト — ツールの導入と設定の書き込み
- 環境変数の設定 — 各ツールが読む変数
- Codex クイックスタート — Codex の config.toml と auth.json
- クラウドサーバーの請求とルール — 期間、自動更新、返金、許容される利用方針
QCode を始める
API キーひとつで Claude Code・Codex などに対応。トークン単位の課金で、各モデルの単価は qcode.cc/models に掲載