結論：2026年8月6日、Anthropicは「self-hosted environments」（CLIコマンド名はclaude self-hosted-runner）をTeam・Enterpriseプラン向けのパブリックベータとして発表しました。claude.ai・モバイル/デスクトップアプリ・スケジュール実行から始めるClaude Codeの「クラウドセッション」を、Anthropicのインフラではなく自社が管理するホストやコンテナの中で実行できる機能です。デフォルトはオフで、組織のOwner/管理者が管理画面から有効化する必要があります。
- 要点1：セッションはVPN越しなどではなく自社ネットワークの内部から実行されるため、外部公開していない社内DB・レジストリ・Git ホストへ、公開せずにアクセスできる（公式ドキュメント基準）
- 要点2：リポジトリのチェックアウトやビルド成果物は自社が用意したホスト上に留まる。ただし会話内容（プロンプト・応答・ツール結果）はモデル推論のため
api.anthropic.comへ送信される仕様で、ここは通常のクラウドセッションと同じ - 要点3：Zero Data Retention設定の組織では使えない、モデル推論をAmazon Bedrock/Google CloudのAgent Platform/Microsoft Foundry/LLMゲートウェイ経由にはできない、Claude Tag・Claude Security・Code Reviewのセッションはまだ非対応、という2026年8月時点の制約がある
対象読者：社内ネットワークやコンプライアンス要件でClaude Codeのクラウド実行を検討している開発リーダー・情報システム部門・SRE、Claude Code導入支援やコンサルティングに関わる担当者
今日やること：自社の runner ホストでclaude self-hosted-runner --helpを実行し、Claude Code v2.1.224以降が入っているか確認する（古いバージョンでは通常のclaude --helpが返るだけで対応していない）
「社内のGitHubはインターネットに公開できないので、Claude Codeのクラウド実行は使えないですよね」——Claude Codeの個別指導や導入支援の場で、この手の相談が増えています。似た質問に「監査ログの観点で、ソースコードが社外のインフラに一切触れないことを証明したい」というものもあります。以下は特定企業の実例ではなく、繰り返し出てくる相談内容を一般化した想定シナリオです。
2026年8月8日現在の答えはこうです。claude --cloudや claude.ai/code から始める「クラウドセッション」自体は、これまで基本的にAnthropicのインフラ上で実行される前提でした。ターミナルやIDEでの通常のセッションはもともと開発者のローカルマシンで動くので関係ありません。しかし8月6日の発表以降は、そのクラウドセッションの実行場所を自社が管理するホストに変える選択肢が、Team/Enterpriseプランのパブリックベータとして存在します。本記事は公式ドキュメント（code.claude.com/docs）とAnthropic公式ブログを一次情報として、仕組み・セットアップ手順・利用条件・既存のVPS手動運用との違いを整理します。確認できなかった点は「未確認」と明記します。
Self-Hosted Runnerとは何か——2026年8月6日発表の中身
公式ドキュメントは self-hosted environments を「自社が運用するインフラ上でClaude Codeのクラウドセッションを実行する仕組み」と定義しています。ここでいう「クラウドセッション」とは、claude.ai・モバイルアプリ・デスクトップアプリ・ターミナルのclaude --cloud・スケジュール実行の routines のいずれかから開始される、開発者のローカルマシン以外のどこかで動くセッション全般を指します。これらは初期設定ではAnthropicのインフラで実行されますが、self-hosted environmentsを設定すると、同じセッションが自社ネットワークの内側で実行されるようになります。開発者から見た体験は基本的に変わりません。
Anthropic公式ブログ「Self-hosted environments for Claude Code」（2026年8月6日公開）では、Faire社のシニアエンジニアリングマネージャーGeorge Jacob氏のコメントとして「Self-hosted environments let us integrate Claude Code into our existing development workflows while maintaining our security and operational controls.」（既存の開発ワークフローにClaude Codeを組み込みながら、自社のセキュリティ運用統制を維持できる）が紹介されています。この一言が、機能の狙いを端的に表しています。
アーキテクチャの基本——Environment・Runner・Sessionの3層
公式ドキュメントは仕組みを3つの要素で説明しています。
| 要素 | 役割 |
|---|---|
| Environment（環境） | クラウドセッションの送り先となる名前付きの箱。claude.aiの管理画面で組織のOwner/管理者が作成し、複数のRunnerをグループ化する |
| Runner（ランナー） | 自社ネットワーク内のホスト上で動くプログラム。セルフホストCIランナーと同じ発想で、セッションを実際に実行する |
| Session（セッション） | 開発者が開始した1つのClaude Codeタスク。Runnerが子プロセスとしてClaude Codeを起動して処理する |
開発者がクラウドセッションを開始すると、画面の環境ピッカーにAnthropicホスト型の環境と並んで自社が作成した環境が表示されます。自社環境を選ぶと、Anthropicの制御プレーンがセッションをその環境のキューに置き、空き容量のあるRunnerがそれを受け取ってリポジトリをクローンし、子プロセスとしてClaude Codeを起動します。通信は一貫して自社側からAnthropic側への発信（アウトバウンドHTTPS）のみで、Anthropicから自社ネットワークへの着信は発生しない設計です。1台のRunnerは、最初に受け取ったセッションのアカウントに「ロック」され、そのユーザーのセッションだけを設定した並列数（--capacity）まで処理します。異なる利用者のチェックアウト済みコードが同じRunner上で混ざらないための仕組みです。
なぜ今この機能が必要とされているのか——3つの利用条件
公式ドキュメントは「ほとんどのチームはAnthropicホスト型の環境で十分」としたうえで、self-hosted environmentsを選ぶべき条件を3つ挙げています。
- ネットワークアクセス——セッションが自社ネットワークの内側で動くため、外部公開していない社内サービス・データベース・パッケージレジストリへ、インターネットに露出させずアクセスできる
- カスタムツール——自社のコンパイラ・SDK・社内CLIをあらかじめRunnerのイメージに組み込んでおけば、セッション開始時点からビルド可能な状態にできる
- コンプライアンス——リポジトリのチェックアウトとビルド成果物は自社が管理するインフラに留まる（ただしセッションの内容自体はモデル推論のため
api.anthropic.comへ送信される点は変わらない）
実際の相談でよく出るのは「オンプレのGitLab/GitHub Enterpriseや社内Jenkinsに、外部公開せずにアクセスしたい」というケースです。これは想定シナリオですが、外部にリポジトリを公開したくない、あるいはVPNやIP制限の背後にGitホストを置いている企業では典型的な要件で、self-hosted environmentsが直接効くパターンに該当します。一方で「AIに読ませた社内コードの内容そのものを外部に一切出したくない」という要件には答えが変わります。公式ドキュメントは「Session content still goes to api.anthropic.com for model inference（セッションの内容はモデル推論のためapi.anthropic.comへ送信され続ける）」と明記しており、自社に残るのはチェックアウトしたコードやビルド成果物、シークレットまでで、会話内容そのものではありません。この線引きを理解しないまま「オンプレ化すれば何もかも社外に出なくなる」と説明すると、後から認識のズレが起きます。
セットアップの実際——Quickstartの4ステップ
公式Quickstartは「1台のRunnerで1つのテストセッションを動かす」最小構成を、次の4ステップで示しています。事前にRunnerホスト（Linux/macOSまたはLinuxコンテナ。Windowsは非対応でLinuxコンテナ経由が必要）にClaude Code v2.1.224以降とGit 2.24以降を用意し、時刻をNTPなどで同期しておく必要があります（クロックが5分以上ずれていると認証に失敗します）。
- 環境を作成する——claude.aiの管理画面「Cloud environments」で新規環境を作成し、表示される環境シークレット（環境キー）をコピーする。このシークレットは作成時に一度しか表示されず、作成から365日で失効する
- Runnerを起動する——シークレットをファイルに保存し、
claude self-hosted-runner --environment-secret-file '/etc/claude/environment-secret' --base-dir '<writable-dir>'を実行する。Runnerは環境に登録され、キューのポーリングを始める - Runnerの登録を確認する——管理画面の環境ステータスが「No runners deployed」から「Healthy」に変わったことを確認する
- セッションをその環境に送る——claude.ai/codeで新しいセッションを開始し、環境ピッカーで自社の環境を選ぶ。空き容量のあるRunnerがセッションを拾い、ログに
Picked up session <session-id>と出力される
なお、Owner/管理者権限でclaude auth login済みのホストでは、この4ステップを対話形式で案内するclaude self-hosted-runner setupというガイド付きセットアップも用意されています（APIキーやサードパーティのモデルプロバイダー経由では使えません）。稼働中のセッションには、別のマシンからでもclaude -p "メッセージ" --cloud <session-id>でフォローアップを送信できます。
Runnerはアクティブなセッションが終わると既定でそのまま終了する設計です。公式ドキュメントは2つの運用モードを説明しています。1つはRunnerを自分で起動し続ける固定台数の「Fixed mode」、もう1つはセッションがキューに積まれるたびにRunnerを起動する、自前でホストするオートスケーリング・オーケストレータです。いずれのモードでも、環境自体は一度設定すれば、対応する画面（claude.ai・モバイル/デスクトップアプリ・routines）すべてにピッカーとして表示され続けます。停止方法にも段階があり、SIGTERMによる通常終了のほか、スポットインスタンスの強制回収のようにシグナルなしでホストが消える環境向けに--retire-atで退役予定時刻を指定すると、Runnerは新規セッションの受け付けを止めたうえで実行中のセッションを解放してから終了します。本番運用では、Kubernetesなど再起動を任せられるオーケストレータの配下で動かすことが公式ドキュメントでも前提とされています。この記事はQuickstartレベルの導入判断を目的としており、ネットワークの堅牢化・Git認証情報の設計・Kubernetes/Compose向けの構成例といった本番投入前の詳細は、公式の「Deploy to production」ページを別途確認してください。
対応プランと利用条件——2026年8月時点でできないこと
導入検討で見落とされがちな制約を、公式ドキュメントの「Availability and limitations」からそのまま整理します。
| 項目 | 2026年8月時点の内容 |
|---|---|
| 対応プラン | Team・Enterprise組織のパブリックベータ。デフォルトはオフで、Owner/管理者が管理画面の「Allow self-hosted environments」を有効化する必要がある |
| Zero Data Retention | Zero Data Retentionを有効化している組織では利用できない |
| モデル推論の経路 | Anthropic APIを直接使用する前提で、Amazon Bedrock・Google CloudのAgent Platform・Microsoft Foundry・LLMゲートウェイ経由にはできない |
| 対応セッション種別 | claude.ai on the web・モバイル/デスクトップアプリ・スケジュール実行のroutines・ターミナルのclaude --cloudが対象。Claude Tag・Claude Security・Code Reviewのセッションはまだこの機能に流れない（別途対応予定とされるが時期は未確認） |
| リポジトリ | GitHubからのチェックアウトが前提 |
| 課金 | Anthropicホスト型の環境と同じ基準で組織のClaude Code利用量にカウントされる。self-hosted化による追加コスト有無は本稿執筆時点で公式に明記されておらず未確認 |
特に注意したいのがZero Data Retentionとの排他関係です。データ保持ポリシーを厳格化する目的でZero Data Retentionをすでに契約している企業が、同じ理由でself-hosted environmentsも欲しくなるのは自然な発想ですが、2026年8月時点ではこの2つは併用できません。導入検討の初期段階で、自社が現在どちらの設定を使っているかを必ず確認してください。
既存のVPS手動運用との違い
Claude Codeを自分でVPSに入れて動かす方法は、本サイトのClaude CodeをVPSで動かす手順と7つの落とし穴で解説した通り以前から可能でした。self-hosted environmentsとの違いを混同すると導入判断を誤るため、要点を比較します。
| 比較軸 | VPSに自分で入れて運用（DIY） | self-hosted environments（公式機能） |
|---|---|---|
| セッションの起動元 | SSHでログインして自分でclaudeを実行、またはcronで起動 |
claude.ai・モバイル/デスクトップアプリ・routinesから通常通り開始し、環境ピッカーで自社環境を選ぶだけ |
| キュー・振り分け | 自分で設計する（存在しない場合も多い） | Anthropicの制御プレーンが自動でキューイングし、空きRunnerに割り当てる |
| 対応プラン | Pro/Max含め制限なし（通常のサブスクリプションで可能） | Team・Enterprise限定のパブリックベータ |
| 運用の主体 | 認証・再起動・監視まですべて自作 | キューイングと管理画面はAnthropicが提供。Runnerのイメージ管理・フリート運用・ネットワーク制御は自社が担当 |
| 向いている用途 | 個人の実験、cronでの定型バッチ処理 | 組織として複数人がクラウドセッションを日常的に使い、かつネットワーク・コンプライアンス要件がある場合 |
もし「自分のマシンを常時起動しておいて、外出先の端末から操作したい」という個人利用に近い目的であれば、Pro/Maxプランでも使えるRemote Controlのほうが要件に合うことを公式ドキュメントも明示しています。self-hosted environmentsは、組織として複数開発者のクラウドセッションを統制する目的の機能で、個人の遠隔操作の代替ではありません。
セキュリティ設計で押さえるべきポイント
公式ドキュメントが明示している設計上の前提を、実務で確認すべき順に並べます。
- 通信方向はすべて自社発——Runnerと各セッションの通信はキューのポーリング、イベントストリーム、モデル推論、Git連携まですべてアウトバウンドHTTPSで、Anthropic側から自社ネットワークへの着信は発生しない
- Runnerは1度に1ユーザー——最初に受け取ったセッションのアカウントにRunnerがロックされ、そのユーザーの分だけ処理する。同時に稼働しうる利用者数が、必要な最小Runner台数になる
- 心拍とタイムアウト——Runnerが約60秒ポーリングを止めると、セッションは別のRunnerに再キューされる。SIGTERMでのシャットダウンには猶予があるが、時刻同期がずれた状態で起動すると認証自体に失敗する
- 環境シークレットの管理——環境作成時に一度だけ表示され、365日で失効する。紛失・ローテーションが必要な場合は新しいシークレットを発行し、古いRunnerを新シークレットへ切り替えてから旧シークレットを失効させる運用になる
- プロキシ対応——企業のアウトバウンドプロキシ環境下でも、
HTTPS_PROXYなどの環境変数をRunner・オーケストレータ側に設定すれば動作する - 内部サービス側での本人確認——セッションが社内API・内部管理画面などにアクセスする構成にする場合、公式ドキュメントは「Verify session identity」ページで、自社サービス側からセッションのトークンを検証してからアクセスを許可する手順を用意している。「Runnerが自社ネットワーク内にある」ことと「そのセッションが正当な利用者のものである」ことは別軸の話なので、内部サービス側の認可設計を省略しない
【要注意】導入検討でよくある誤解と失敗パターン
❌ 「self-hosted環境にすれば、コードもプロンプトも一切社外に出ない」
⭕ 社外に出ないのはリポジトリのチェックアウト・ビルド成果物・シークレットまで。会話内容（プロンプト・応答・ツール結果）はモデル推論のためapi.anthropic.comへ送信される。「一切外に出ない」という説明は公式ドキュメントの記述と食い違うため、セキュリティ部門への説明ではこの境界線を正確に伝える
❌ 「Zero Data Retentionを契約していれば当然self-hosted環境も併用できる」
⭕ 2026年8月時点で両者は排他。まずは自社の契約状況を確認し、必要な組み合わせが技術的に成立するかを先に見極める
❌ 「Runner1台でチーム全員のセッションをまとめて処理できると想定して容量計画を立てる」
⭕ Runnerは最初に受け取ったユーザーにロックされる仕様のため、同時にクラウドセッションを使う利用者数ぶんのRunnerが最低限必要になる。1台構成のまま複数人に展開すると、後発の利用者がキューで待たされる
❌ 「本番投入もQuickstartの1台構成のまま続ける」
⭕ Runnerはアクティブセッション終了後にプロセスが終了する設計のため、本番運用ではKubernetes等のオーケストレータで再起動を任せる前提になっている。Quickstartはあくまで最小構成の動作確認用
よくある質問（FAQ）
まとめ：今日から始める3つのアクション
- 今日やること：候補ホストで
claude self-hosted-runner --helpを実行し、Claude Code v2.1.224以降が入っているか確認する - 今週中：公式Quickstartに沿って1台構成でテストセッションを動かし、Runnerがログに
Picked up sessionと出力するところまで確認する。本番投入前に「Deploy to production」ページのネットワーク要件とGit認証設定を必ず読む - 今月中：自社がZero Data Retentionを契約しているか、Bedrock/Vertex/Foundry経由でモデルを使っているかを洗い出し、self-hosted environmentsの対象になり得るかを判定する
直近1週間ではMCPプロトコルの大改定も発表されています。あわせてMCP新仕様7/28対応ガイド｜既存サーバー改修要否を読むと、直近のClaude Codeまわりのアップデート全体像がつかめます。全社導入時のモデル・スキル統制の基本設計はClaude Code全社ガバナンス｜利用モデルとスキル統制、法人導入時のセキュリティ確認項目はClaude Code法人導入セキュリティ完全チェックリスト、権限・サンドボックスの基本設計はClaude Codeサンドボックスで安全に自動実行もあわせて参照してください。
参考・出典
- Self-hosted environments — Claude Code公式ドキュメント（2026年8月参照）
- Self-hosted environments quickstart — Claude Code公式ドキュメント（2026年8月参照）
- Claude Code changelog（v2.1.224, 2026年8月7日） — Claude Code公式ドキュメント
- Self-hosted environments for Claude Code — Anthropic公式ブログ（2026年8月6日公開）
- Use Claude Code on the web — Claude Code公式ドキュメント（クラウドセッションの定義、2026年8月参照）
- Remote Control — Claude Code公式ドキュメント（個人利用の代替手段として参照、2026年8月参照）
著者：佐藤傑（さとう・すぐる）
株式会社Uravation代表取締役。X（@SuguruKun_ai）フォロワー約10万人。100社以上の企業向けAI研修・導入支援を展開。著書『AIエージェント仕事術』（SBクリエイティブ）。SoftBank IT連載7回執筆。
ご質問・ご相談は お問い合わせフォーム からお気軽にどうぞ。
