self-hosted environmentsとself-hosted-runnerの違い
self-hosted-runnerとself-hosted environmentsは別機能ではなく同じ仕組みの2つの呼び名です。用語がどこで置き換わるかをCHANGELOGと公式docsで確認します。
Claude Codeの公式docsを読んでいると、同じ機能を指すのに「self-hosted environments」というページ名と、claude self-hosted-runnerというコマンド名の両方に出会います。別々の機能が2つあるわけではありません。self-hosted environmentsは製品名、self-hosted-runnerはそれを動かすCLIサブコマンドの名前で、指している実体は同じです。どちらで検索しても同じドキュメント群にたどり着きます。
なぜ2つの名前が併存するのか
CHANGELOGでこの機能が最初に登場したv2.1.224の1行は、両方の語を同じ文に含んでいます。「self-hosted environments」という機能名の説明に続けて、それを実現するのがclaude self-hosted-runnerというコマンドだと書かれています。命名が途中で割れたのではなく、最初から役割の異なる2つの名前として設計されていた、ということです。
製品名の「environments」が指すのは、Environment・Runner・Sessionという3つの要素からなるしくみ全体です。管理画面でEnvironmentを作り、複数のRunnerをそこにぶら下げ、開発者が始めたSessionをRunnerが拾って実行する、という一連の流れをまとめて呼ぶときにこの名前を使います。一方の「runner」は、その中の1要素であるRunnerプロセスを起動する実際のコマンド名です。読者が公式docsのURLで見るself-hosted-environmentsという語は前者、ターミナルに打ち込むself-hosted-runnerという語は後者を指しています。
用語は見る場所によって変わる
同じ実体でも、見る場所によって呼び方が変わります。
| 見る場所 | 使われる語 |
|---|---|
| CLIのサブコマンド | 使われる語self-hosted-runner(例: claude self-hosted-runner setup) |
| 公式docsのURL・ページ名 | 使われる語self-hosted-environments(例: /docs/en/self-hosted-environments) |
| 管理画面のメニュー名 | 使われる語Cloud environments |
| APIのフィールド名・トークンのクレーム | 使われる語pool(EnvironmentのIDはpool_id、管理画面のIDはccpool_...形式) |
| CLIのフラグ名(現行) | 使われる語--environment-secret-fileなど、environmentに統一 |
| CLIのフラグ名(非推奨) | 使われる語referenceページが非推奨のpool系フラグ名を現行名に対応付けている |
| CHANGELOGの本文 | 使われる語ほぼ一貫して「self-hosted runner」(スペース区切りの英語表記) |
このばらけ方は場当たり的ではありません。CLIとCHANGELOGは開発者がターミナルで打つ・読む文脈なので、実装物のRunnerを主語にしています。docsと管理画面は機能を選ぶ・設定する文脈なので、製品全体のEnvironmentsを主語にしています。APIのpoolという語だけは経路が異なります。フィールド名・トークンのクレーム・メトリクス名ではEnvironmentがpool、環境IDがpool_idと表記されます。referenceページが両方の綴りと非推奨のpool系フラグ名を対応付けています。
命名の徹底ぶりは、URLのパス設計にも表れています。公式のGet startedには、クイックスタート・本番デプロイ・セッションのカスタマイズ・CI向けのテスト・セッション識別子の検証・リファレンスという、性格の異なる6つのページがあります。URLはすべてself-hosted-environments-で始まります。書いてある中身の大半は、Runnerのコマンドラインフラグや環境変数、Kubernetesでの運用方法です。実装物としてのRunnerに関する説明が中心です。それでもページ名だけは製品名で統一されています。実装の詳細を読みに来た開発者も、まず製品名の入口を通ってから個別ページへ進む導線になっています。管理画面側も同様です。Ownerが有効化する際に押すトグルの表示名は「Allow self-hosted environments」で、ここにもrunnerという語は出てきません。
この機能を初めて知った人がつまずきやすい点
名前の由来をたどると、混同しやすい隣接語が2つ見えてきます。ひとつはGitHub Actionsの「self-hosted runner」です。公式docsのRunnerの説明自体が「自社CIのself-hosted runnerと同じ発想」と書いています。Runnerというしくみの設計思想は、GitHub Actionsから借りています。ただし実体は別物です。GitHub Actionsのランナーが実行するのはワークフローのジョブです。対してClaude CodeのRunnerが動かすのは、クラウドセッション用のClaude Codeプロセスです。検索結果でGitHub側の解説記事が混ざってきたら、探しているのはCI/CDの文脈かClaude Codeの文脈か、まず切り分けます。
もうひとつの混同は「Claudeモデル自体を自社インフラで動かす」話との混線です。Amazon BedrockやGoogle CloudのAgent Platform、Microsoft Foundryを使ったモデル推論の自前ホスティングは、self-hosted environmentsとは無関係です。self-hosted environmentsが自社側に持ってくるのは、あくまでコードのチェックアウトとビルドの実行環境だけです。モデル推論は変わらずAnthropicのAPIに送られます。実際、self-hosted environments自体がBedrock・Google CloudのAgent Platform・Microsoft Foundry経由のモデル推論に対応しないことは、公式docsにも明記済みです。「self-hosted」という語からモデルまで自社に置けると連想すると、要件を読み違えます。
CHANGELOGを通しで見ると分かること
v2.1.224以降、この機能に関する変更は一貫して「self-hosted runner」という語で記録されています。抜粋すると次のような流れです。
| バージョン | 変更内容 |
|---|---|
| v2.1.224 | 変更内容self-hosted environmentsを追加。実行を担うのはclaude self-hosted-runner |
| v2.1.229 | 変更内容Windowsでの起動に--base-dirの明示を必須化。GCM(Git Credential Manager)のプロンプトでハングする不具合を修正 |
| v2.1.229 | 変更内容サーバー側から配信するhookをセルフホストランナーのセッションでもサポート |
| v2.1.238 | 変更内容--defer-shutdown-max-minと--proxy-authorization-commandなどのフラグを追加。ポーリング遅延だけでランナーがサーバーから除外される不具合を修正 |
| v2.1.248 | 変更内容--client-label(またはSELF_HOSTED_RUNNER_CLIENT_LABEL)でランナーの登録名を上書きできるように |
| v2.1.251 | 変更内容強制停止されたセッションのBashツールプロセスが残り続ける不具合を修正 |
CHANGELOGの関連エントリを通しで見ても、「self-hosted environments」という表記が現れるのはこの機能を紹介する冒頭の説明文だけです。バグ修正や新フラグの告知はすべて「self-hosted runner」で記録されています。CHANGELOGは実装の変更点を追うログです。ページ名より実行主体であるRunnerを主語にするほうが自然だと分かります。
self-hosted-runnerとself-hosted environments、どちらを検索すればよいか
導入の可否・料金・対象プランなど「機能として何ができるか」を知りたいなら、self-hosted environmentsで検索してdocsのトップページから読むのが近道です。3つの構成要素の関係、対応プラン、ゼロデータ保持との非互換性といった全体像はここに集約されています。
逆に、コマンドのフラグや具体的なエラーメッセージ、CHANGELOGでの不具合修正を追いたいなら、self-hosted-runnerで検索したほうがヒットします。--capacityや--retire-atといったフラグ名、Runnerのライフサイクルに関する挙動は、実装物としてのRunnerを主語に説明されているためです。
Remote Controlや通常のクラウドセッションとどう違うか
self-hosted environmentsが対象にするのは、claude.ai/codeやモバイル・デスクトップアプリ、ターミナルの--cloudから始める「クラウドセッション」の実行場所です。これらは既定でAnthropicのインフラ上を動きますが、self-hosted environmentsを有効にした組織では、自社のマシンやコンテナに実行場所を差し替えられます。常時稼働している自分のマシンを別デバイスから操作したいだけなら、対象はそもそも別の機能です。Pro・Maxプランでも使えるRemote Controlのほうが目的に合います。両者の対象プラン・要件を並べた早見表と具体的な導入手順は、既存のClaude Code self-hosted-runnerとはにまとめています。
よくある質問
self-hosted-runnerというコマンドを覚えれば、機能の全体像も分かりますか
コマンド単体からはEnvironmentの概念が見えにくいので、docsは製品名のself-hosted environmentsで章立てされています。導入を検討する段階ではdocsのトップページから読み、実装の詳細に入ったらCLIのヘルプやreferenceページに切り替えるのが効率的です。
APIのpoolという語は何を指しますか
APIのフィールド名・トークンのクレーム・メトリクス名でEnvironmentを指す語です。EnvironmentのIDはpool_id、管理画面のIDはccpool_...形式で表記されます。CLIのフラグ名や管理画面の表示名はenvironmentに統一されていますが、APIとreferenceページだけはpool側の綴りも残っています。
古いブログ記事やフォーラムでself-hosted runnerとだけ書かれているのは間違いですか
間違いではありません。CHANGELOGの本文もほぼ一貫してこの表記なので、CLIの挙動を説明する文脈ではself-hosted runnerと書くほうがむしろ実態に近い表現です。機能の全体像を説明する文脈でだけ、self-hosted environmentsという製品名に読み替えれば混乱しません。
まとめ
self-hosted-runnerとself-hosted environmentsは競合する2つの機能ではなく、同じしくみを指す2つの名前です。environmentsは製品全体の名前で、docsのページ名や管理画面のメニューに使われます。runnerはそれを動かすCLIサブコマンドの名前で、CHANGELOGやフラグの説明はほぼこちらに統一されています。APIだけがpoolという第三の綴りをフィールド名やトークンのクレームに残していますが、referenceページが対応関係を示しているとおり、読者が新しく覚える必要がある概念ではありません。
導入の可否を調べるならself-hosted environments起点で、コマンドやフラグの挙動を追うならself-hosted-runner起点で検索すると、目的のページに早くたどり着けます。常時稼働の自分のマシンを別デバイスから操作したいだけの場合はClaude Code Remote Controlで作業を別デバイスに引き継ぐ、定期実行との組み合わせはClaude Code Routines完全ガイドから辿れます。