自己ホスト環境は Team および Enterprise プランでパブリックベータ版であり、デフォルトではオフになっています。有効化パスと除外される内容については、利用可能性と制限事項を参照してください。
claude --cloud を使用したターミナル、およびクラウドスケジュールタスクからクラウドセッションを開始します。デフォルトでは、クラウドセッションは Anthropic のインフラストラクチャで実行されます。
自己ホスト環境では、これらの同じセッションがネットワーク内で実行されます。それ以外の開発者体験は、利用可能性と制限事項の違いとデプロイページの既知の問題を除いて同じです。
チームがクラウドセッションを使用していない場合、ここで設定することはありません。ターミナルまたは IDE のセッションは常に開発者自身のマシンで実行されます。Claude Code を常時稼働しているマシンで実行し、他のデバイスから駆動したい場合は、リモートコントロールを使用してください。これは Pro および Max プランでも利用可能です。セットアップの準備ができたら、クイックスタートに直接進んでください。セキュリティ体制を最初に確認したい場合は、本番環境へのデプロイから始めてください。このページの残りの部分では、自己ホスティングの仕組みと、それを選択する時期について説明します。
セルフホスト環境の仕組み
セルフホストは 3 つの要素で構成されます。- 環境: クラウドセッションの送信先となる名前付きの宛先です。組織は claude.ai の管理設定で環境を作成し、各環境は一連のランナーをまとめます。
- ランナー: ネットワーク内のホスト上で動作するプログラムです。ランナーがセッションを実行します。考え方はセルフホスト型 CI ランナーと同じです。
- セッション: 開発者が開始した 1 つの Claude Code タスクです。
api.anthropic.com へのアウトバウンド HTTPS であり、セッションがアクセスできるその他の少数のホストについてはネットワーク要件に記載されています。Anthropic がネットワークの外部から内部へ接続することは一切ありません。
利用可能性と制限事項
ロールアウトを計画する前に、これらを確認してください。- プラン: Team および Enterprise 組織向けのパブリックベータ版。自己ホスト環境はデフォルトではオフになっています。オーナーがクラウド環境管理ページで自己ホスト環境を許可をオンにします。これには、組織に対してウェブ上の Claude Codeが有効になっている必要があります。
- ゼロデータ保持と HIPAA: ゼロデータ保持が有効になっている組織、または HIPAA 設定が適用されている組織では利用できません。
- モデル推論: ランナーを Amazon Bedrock または Google Cloud の Agent Platform にモデルリクエストを送信するように構成しない限り、セッションは Anthropic API を使用します。いずれの場合も、セッションのコンテンツは Anthropic に送信されます。このように構成されたランナーでは、claude.ai のサーバー管理設定と組織ポリシーはセッションに適用されません。
- サーフェス: claude.ai/code、モバイルおよびデスクトップアプリ、クラウドスケジュールタスク、およびターミナルから開始されたセッション（
claude --cloudまたは--environmentディスパッチを使用）は、自己ホスト環境で実行できます。Claude Tagセッションもそれらで実行できますが、Claude はまだそれらのセッションでアクセスバンドルを使用できません。Claude SecurityおよびCode Reviewセッションはまだそれらにルーティングされません。これら 2 つのサーフェスのサポートは別途提供されます。 - リポジトリ: セッションは GitHub からリポジトリをチェックアウトします。GitHub 認証オプションを参照してください。GitHub Enterprise Server ホストについては、そのネットワーク要件を参照してください。
- 請求: 自己ホスト環境のセッションは、Anthropic ホスト環境のセッションと同じ方法で組織の Claude Code 使用量を消費します。
自己ホスティングを選ぶ理由
ほとんどのチームは、実行または保守するインフラストラクチャが不要な Anthropic ホスト環境の方が適しています。自己ホスティングは、ネットワーク、ツール、またはコンプライアンス要件により、セッション実行を管理するインフラストラクチャに保つ必要があるチーム向けです。その場合、運用上の所有権を計画してください。ランナーイメージを構築および保守し、フリートを運用し、ネットワークを制御します。 その代わりに、自己ホスティングはネットワークアクセス、カスタムツール、およびコンプライアンス制御を提供します。- ネットワークアクセス: セッションはネットワーク内で実行され、内部サービス、データベース、およびレジストリに到達でき、それらをパブリックインターネットに公開する必要がありません。
- カスタムツール: コンパイラ、SDK、および内部 CLI をランナーイメージにプリインストールして、すべてのセッションが構築の準備ができた状態で開始されるようにします。
- コンプライアンス: リポジトリのチェックアウトとビルドアーティファクトは、管理するインフラストラクチャに保たれます。ただし、セッションコンテンツは引き続き
api.anthropic.comに送信されます。
環境、ランナー、セッション
環境は claude.ai の管理設定にある Cloud environments ページで管理します。ランナーは、ユーザーが自身のインフラストラクチャ上で起動・管理するプロセスです。主要な概念
以下の用語はセルフホスト関連のページ全体で使われます。
API のフィールド、トークンのクレーム、メトリクス名では、環境は
pool として表記され、環境 ID は pool_id です。リファレンスでは、非推奨の pool フラグ名を含め、2 つの表記の対応を示しています。
ランナーは一度に 1 人のオーナーにのみサービスを提供します。ランナーが最初に取得したセッションによって、ランナーはそのセッションのオーナーにロックされ、以降は設定された容量の範囲内で、そのオーナーのセッションのみを実行します。オーナーが誰になるかは、セッションの開始方法によって異なります。
- ユーザーが開始したセッション：オーナーはそのユーザーのアカウントです。
- Claude Tag チャネルセッション：Claude はユーザーアカウントを紐付けずにこれらを実行するため、オーナーはセッションを開始した Claude Tag エージェントになります。そのエージェントが開始するチャネルセッションは、誰が Slack メッセージを送信したかにかかわらず、すべて同じオーナーを持ちます。そのため、
--capacityを 1 より大きくするか、--drain-grace-secを正の値にして実行した場合、このエージェントにロックされたランナーは、異なるユーザーが開始したセッションも処理します。
セッションのライフサイクル
開発者がセッションを開始して環境を選択すると、Anthropic のコントロールプレーンはそのセッションを環境のキューに配置します。その後の流れは次のとおりです。- 空き容量のあるランナーがセッションを取得し、そのリースを保持します。
- ランナーはリポジトリを作業ディレクトリにクローンし、子 Claude Code プロセスを生成します。
- 子プロセスは HTTPS 経由でイベントをストリーミングし、その間ランナーはポーリングを続けます。各ポーリングはリースを更新し、ハートビートも兼ねます。
- ランナーがポーリングを停止すると、リースは約 60 秒後に失効します。その後、サーバーがそのセッションを別のランナー向けに再度キューに入れるまでに、数分、場合によってはそれ以上かかることがあります。
ランナーのライフサイクル
ランナーが最初に取得したセッションによって、ランナーはそのセッションのオーナーにロックされ、そのオーナーのセッションを最大--capacity 件まで同時に実行します。ランナーにアクティブなセッションがあり、シャットダウンシグナルを受信しておらず、リタイア時刻にも達していない間は、ランナーはロックされたオーナーのキューにある作業を取得し続けます。それらのセッションが終了した後の動作は --drain-grace-sec によって異なります。
- デフォルトの
0の場合：ランナーはアクティブなセッションが終了するとすぐに、追加のポーリングを行わずに終了します。これにより、Kubernetes などランナーをデプロイしているオーケストレーターが、新しいディスクでランナーを再起動し、任意のオーナーにサービスを提供できる状態にできます。 - 正の値の場合：ランナーは終了する前に、その秒数だけロックされたオーナーのキューをポーリングし続けます。
--retire-at が必要かどうかは、インフラストラクチャがランナーをどのように停止するかによって決まります。SIGTERM を送信する kill の場合、フラグは不要です。ランナーはシャットダウンのタイミングで説明されているとおりにドレインするか、--defer-shutdown-max-min を設定している場合は、すでに保持しているセッションの処理を続けます。一方、サンドボックスの存続期間の上限やスポットインスタンスの回収など、インフラストラクチャがシグナルなしで、またはドレインするには短すぎる猶予期間で、既知の時刻にホストを破棄する場合は、その時刻の数分前に設定した --retire-at <epoch-seconds> を渡してください。リタイア時刻になると、次のように動作します。
- ランナーは新しい作業の受け付けを停止します。
- ランナーは、
--release-idle-session-minフラグが使用するのと同じリリース経路を通じて各アクティブセッションをリリースします。これにより、ユーザーが次のメッセージを送信したときに、セッションは新しいランナー上で再開されます。ランナーが各セッションをリリースするタイミングは、そのセッションの状態によって異なります。- ターンの途中にあるセッションは、そのターンが終了した後にリリースされます。ランナーはまず、セッションのプロセスがターンの終了を Anthropic に報告するのを待ちますが、待機時間は
SELF_HOSTED_RUNNER_POST_TURN_SETTLE_MSを超えません。v2.1.280 より前は、ターンが終了するとすぐにセッションをリリースしていました。 - ターンが終了してもバックグラウンドタスクが実行中のままの場合、ランナーは最大 60 秒間それらを待ち、まだ実行中であってもセッションをリリースします。タスクが終了していても、その結果を読み取る後続のターンがまだ実行されていない場合、ランナーはそのターンが終了するまでセッションを保持します。そのターンの開始を待つ時間は、最長でも
SELF_HOSTED_RUNNER_BG_RESULT_GRACE_MSまでです。
- ターンの途中にあるセッションは、そのターンが終了した後にリリースされます。ランナーはまず、セッションのプロセスがターンの終了を Anthropic に報告するのを待ちますが、待機時間は
- すべてのセッションがリリースされると、ランナーは終了コード 0 で終了します。
--retire-at を指定しない場合、シグナルなしのホスト kill はクラッシュと区別できません。コントロールプレーンはクリーンなリリースではなくワーカーの喪失として記録し、セッションは別のランナーに再度キューイングされます。
ネットワーク経路
ランナーとそのセッションは数種類のアウトバウンド接続を行いますが、Anthropic からのインバウンド接続は必要ありません。- コントロールプレーン：ランナーは
api.anthropic.comをポーリングして作業を取得し、セットアップの進行状況や失敗のイベントを送信します。これらはすべてアウトバウンドの HTTPS です。ポーリングはランナーのハートビートも兼ねます。 - Git：ランナーは、デプロイによって提供される認証情報で認証し、HTTPS または SSH 経由で git ホストからクローンおよびプッシュを行います。セッションごとに発行される認証情報を含むオプションについては、git の設定を参照してください。Anthropic git プロキシを使用する場合、github.com 上のリポジトリに対する git トラフィックは代わりに
api.anthropic.comを経由します。 - セッションの子プロセス：子 Claude Code プロセスは
api.anthropic.comへのセッションのイベントストリームを保持し、モデル推論とセッション中に実行される git コマンドのために独自のアウトバウンド呼び出しを行います。Anthropic が管理する git を使用するセッションでは、子プロセスは github.com 向けのgitおよびghのトラフィックを、自身がapi.anthropic.comに対して開く WebSocket 接続経由で送信します。 - SCM コネクタ：オプションのオーケストレーター SCM コネクタは利用できないため、そのトンネルは開かれません。このトンネルは
api.anthropic.comへの WebSocket 接続です。
HTTPS_PROXY や NO_PROXY など、ネットワーク設定で説明されているプロキシおよび mTLS の環境変数に従います。これらは各プロセスの環境で設定してください。これらの変数は、コントロールプレーンへの呼び出し、オーケストレーターの SCM コネクタの WebSocket、および HTTPS リモートの組み込みクローンに適用され、セッションはランナーからこれらを継承します。セッションのストリーミングは HTTPS 上の server-sent events を使用するため、経路上のプロキシはレスポンスをバッファリングしてはいけません。
- プロキシ認証：プロキシで
Proxy-Authorizationヘッダーも必要な場合、ランナーはプロキシに対して開く各接続にそのヘッダーを追加できます。エグレスプロキシへの認証を参照してください。 - 長時間維持されるレスポンス：ランナーがセッションを取得したにもかかわらず、Claude が最初のメッセージに一向に応答しない場合、プロキシが原因である可能性があります。セッションは取得されたが、Claude が最初のメッセージに応答しないを参照してください。
インフラストラクチャに保たれるもの
リポジトリのチェックアウト、ビルドアーティファクト、シークレット、およびセッションが作成または変更するファイルは、プロビジョニングしたマシンに保たれます。会話自体（プロンプト、応答、ツール結果を含む）はapi.anthropic.com に送信され、Anthropic はセッショントランスクリプトを保存して、別のサポートされているサーフェスからセッションを再開できるようにします。ランナーがモデルリクエストを Amazon Bedrock または Google Cloud の Agent Platform に送信する場合でも、会話はセッションのイベントストリーム内で引き続き api.anthropic.com に送信されます。
自己ホスト環境はセッション実行をネットワークに移動させます。コントロールプレーンは Anthropic ホスト型のままです。セッションオーケストレーション、キューイング、および claude.ai インターフェースは Anthropic のインフラストラクチャで実行され続けます。
開始する
自己ホスト環境ページは、実行している内容によって整理されています。- クイックスタート: Claude Code をインストールし、環境を作成し、ランナーを開始し、最初のセッションをルーティングします。
- 本番環境へのデプロイ: セキュリティ強化、ネットワーク送信、git 認証情報、Kubernetes および Compose レシピ、既知の問題、およびトラブルシューティング
- セッションをカスタマイズ: セッションごとの認証情報、ライフサイクルフック、オンデマンドランナー、MCP サーバー、および権限のためのラッパースクリプト
- エンドツーエンドをテスト: ランナーイメージをプロモーション前に検証する CI スモークテスト
- リファレンス: すべての CLI フラグ、環境変数、メトリック、およびヘルスエンドポイント
- セッション ID を検証: 独自のサービスからセッショントークンを検証してから、アクセスを許可します。