はじめに
Anthropicが 2026年8月6日 、Claude Codeのクラウドセッションを自社が用意したインフラ上で実行できる「セルフホスト環境」をパブリックベータとして公開しました。本稿では、この機能がどのような仕組みで動き、どういった組織に向いているのかを、公式発表と技術ドキュメントをもとに整理します。
参考記事
メイン記事:
- タイトル: Run Claude Code sessions on your own compute
- 発行元: Anthropic
- 発行日: 2026年8月6日
- URL: https://claude.com/blog/run-claude-code-sessions-on-your-own-compute
関連情報:
- タイトル: Self-hosted environments
- 発行元: Claude Code Docs（Anthropic）
- 発行日: 2026年8月
- URL: https://code.claude.com/docs/en/self-hosted-environments
関連記事
要点
- セルフホスト環境は、Claude Codeのクラウドセッションを組織自身が運用するインフラ上で実行する機能であり、パブリックベータとして公開された
- Web・モバイル・デスクトップアプリ・ターミナル・定期実行ルーティンなど、どの入口から開始したセッションも同じ環境に振り分けられる
- リポジトリのチェックアウト、ビルド成果物、シークレット、セッションが生成・変更したファイルは、自社が用意したマシン上に残る
- 一方でプロンプト・応答・ツール実行結果は推論のためAnthropicへ送信され、セッションの記録もAnthropic側に保存される
- 対象はClaude TeamおよびEnterpriseプランの組織で、初期状態は無効、ゼロデータ保持（ZDR）を有効にしている組織は利用できない
詳細解説
セルフホスト環境が対象とする「クラウドセッション」
今回の対象は、開発者の手元のマシン以外で動く「クラウドセッション」です。公式ドキュメントによれば、claude.aiのWeb画面、モバイル・デスクトップアプリ、ターミナルからの claude –cloud、そして定期実行のルーティンから開始されたセッションがこれにあたり、既定ではAnthropic側のインフラで実行されます。セルフホスト環境は、この実行部分だけを自社ネットワーク内へ移す仕組みだと説明されています。
ブラウザからコーディングセッションを開始できる機能自体は、2025年10月に「Claude Code on the web」として公開されています。今回の発表は、その実行基盤の置き場所を組織側が選べるようにした延長線上の変更だと考えられます。なお、ターミナルやIDEで動かす通常のセッションは元々開発者のマシン上で完結するため、設定の必要はないとされています。
自社インフラで動かす3つの動機
Anthropicによれば、プレビュー段階で導入した組織の理由は大きく3つに整理されています。1つ目は ネットワークアクセス で、セッションが社内ネットワークの内側で動くため、内部サービスやデータベース、パッケージレジストリへ、それらをインターネットに公開することなく到達できます。2つ目は カスタマイズ性 で、コンパイラやSDK、社内独自のCLIツールをあらかじめ実行イメージに組み込んでおけば、セッション開始時点でビルドできる状態が整います。3つ目は コンプライアンス で、ソースコードやビルド成果物を自社の管理下に置き続けられます。
もっともAnthropic自身は、運用負荷のないホスト型の利用を大半の企業に推奨しており、セルフホストはネットワーク・ツール・コンプライアンス上の要件がある組織向けだと明記しています。導入時はプラットフォームチームなどが実行イメージの構築・更新や運用を担う体制が前提になるとされており、要件が明確な組織に絞って検討する対象だと言えます。
ランナーの仕組みと2つの運用モード
セルフホスト環境の中核となるのが ランナー です。ランナーは自社ホスト上で動き続けるプロセスで、キューに入ったセッションを引き受け、セッションごとにClaude Codeのプロセスを起動します。考え方としては、CI（継続的インテグレーション）のセルフホストランナーに近い構成だと説明されています。
運用モードは2種類あります。固定モードでは、あらかじめ決めた台数を常時稼働させ、セッションをその中で分散させます。オンデマンドモードでは、オーケストレーターと呼ばれる別プロセスがキューを監視し、セッションが入るとランナーを起動し、作業が終わると停止させることで、必要な分だけ処理能力を確保します。利用が時間帯によって偏る組織では、後者のほうが待機コストを抑えやすいと考えられます。
1つのランナーは複数のセッションを同時に処理できますが、セッションごとに別のチェックアウトが用意され、さらに公式ドキュメントによれば最初のセッションを受け取った時点で特定ユーザーのアカウントに紐づくため、開発者をまたいで作業が混ざることはないとされています。同時に稼働する利用者数が必要な最小台数の目安になるという点は、規模を見積もるうえで重要だと思います。なお、ランナーによるキューのポーリングは死活監視（ハートビート）を兼ねており、約60秒間停止するとサーバー側がセッションを別のランナーへ振り直すと記載されています。
自社に残るデータと、Anthropicへ渡るデータ
どこまでが自社に残るのかは、導入判断で最も確認したい点だと思います。Anthropicの説明では、リポジトリのチェックアウト、ビルド成果物、シークレット、セッションが作成・変更したファイルは、すべて自社が用意したインフラ上に留まります。
一方で、プロンプトや応答、ツールの実行結果（Claudeが読み込んだコードを含む場合があります）は推論のためAnthropicへ送信され、セッションの記録も保存されます。どの端末からでも同じセッションを再開できるのは、この記録があるためです。セルフホスト環境は「実行場所を自社に移す」仕組みであって、推論やセッション制御まで自社に移るわけではない、という理解が実態に近いと考えられます。
通信の向きにも特徴があります。公式ドキュメントによれば、キューの取得もイベントの送信もモデル推論も、すべて api.anthropic.com への外向きHTTPS通信で行われ、Anthropic側から社内ネットワークへ接続してくることはないと明記されています。企業の外向きプロキシにも対応しているとされており、ファイアウォール要件の説明はしやすい構成だと言えます。
利用条件と、現時点での制約
提供対象はClaude TeamおよびEnterpriseプランの組織で、機能は初期状態では無効です。有効化はオーナーまたは管理者が管理画面から行い、その前提としてClaude Code on the webが組織で有効になっている必要があるとされています。ゼロデータ保持（ZDR）を有効にしている組織は対象外です。
推論経路にも制約があります。公式ドキュメントでは、セッションはAnthropic APIを利用し、Amazon BedrockやGoogle CloudのAgent Platform、Microsoft Foundry、あるいはLLMゲートウェイ経由へ推論を振り向けることはできないと説明されています。クラウド事業者経由での利用を前提に社内標準を組んでいる組織では、ここが判断の分かれ目になりそうです。また、Claude TagやClaude Security、コードレビューから開始したセッションは現時点ではセルフホスト環境に振り分けられず、対応は別途進むとされています。リポジトリのチェックアウト元はGitHubが対象です。
なお、自分のマシンのセッションをスマートフォンやブラウザから操作し続けるRemote Controlとは別機能である点も、発表内で注意喚起されています。Remote Controlは実行元のマシンが停止すればセッションも終了し、実行したユーザーに紐づきます。対してセルフホスト環境は、プラットフォームチームが運用する共有インフラ上で動き、組織内の誰もが利用できる位置づけです。
まとめ
セルフホスト環境は、Claude Codeのクラウドセッションを社内ネットワークで実行し、コードや成果物を自社管理下に置ける選択肢です。ただし推論はAnthropic側で行われ、運用担当も必要になります。自社インフラでのコーディングAI活用という論点は他社の動きとあわせて整理していますので、参考になればと思います。
