自己ホスト環境は 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が有効になっている必要があります。
- ゼロデータ保持: ゼロデータ保持が有効になっている組織では利用できません。
- モデル推論: セッションは Anthropic API を使用し、推論はAmazon Bedrock、Google Cloud の Agent Platform、Microsoft Foundry、またはLLM ゲートウェイを通じてルーティングできません。
- サーフェス: ウェブ上の Claude Code、モバイルおよびデスクトップアプリ、スケジュール済みルーチン、およびターミナルから開始されたセッション（
claude --cloudまたは--environmentディスパッチを使用）は、自己ホスト環境で実行できます。Claude Tagセッションもそれらで実行できますが、Claude はまだそれらのセッションでアクセスバンドルを使用できません。Claude SecurityおよびCode Reviewセッションはまだそれらにルーティングされません。これら 2 つのサーフェスのサポートは別途提供されます。 - リポジトリ: セッションは GitHub からリポジトリをチェックアウトします。GitHub 認証オプションを参照してください。
- 請求: 自己ホスト環境のセッションは、Anthropic ホスト環境のセッションと同じ方法で組織の Claude Code 使用量を消費します。
自己ホスティングを選ぶ理由
ほとんどのチームは、実行または保守するインフラストラクチャが不要な Anthropic ホスト環境の方が適しています。自己ホスティングは、ネットワーク、ツール、またはコンプライアンス要件により、セッション実行を管理するインフラストラクチャに保つ必要があるチーム向けです。その場合、運用上の所有権を計画してください。ランナーイメージを構築および保守し、フリートを運用し、ネットワークを制御します。 その代わりに、自己ホスティングはネットワークアクセス、カスタムツール、およびコンプライアンス制御を提供します。- ネットワークアクセス: セッションはネットワーク内で実行され、内部サービス、データベース、およびレジストリに到達でき、それらをパブリックインターネットに公開する必要がありません。
- カスタムツール: コンパイラ、SDK、および内部 CLI をランナーイメージにプリインストールして、すべてのセッションが構築の準備ができた状態で開始されるようにします。
- コンプライアンス: リポジトリのチェックアウトとビルドアーティファクトは、管理するインフラストラクチャに保たれます。セッションコンテンツは、モデル推論のために
api.anthropic.comに送信されます。
環境、ランナー、およびセッション
環境は claude.ai 管理設定のクラウド環境ページで管理されます。ランナーは、自分のインフラストラクチャで開始および管理するプロセスです。主要な概念
これらの用語は自己ホストページ全体に表示されます。
API フィールド、トークンクレーム、およびメトリック名では、環境は
poolとして表示され、環境 ID はpool_idです。リファレンスは 2 つのスペルをマップします。これには、非推奨のpoolフラグ名も含まれます。
ランナーは一度に 1 つのオーナーに対応します。ランナーが最初に取得するセッションはランナーをそのセッションのオーナーにロックし、ランナーはそのオーナーのセッションのみを実行し、設定容量まで実行します。オーナーが誰であるかは、セッションがどのように開始されたかによって異なります。
- ユーザーが開始するセッション: オーナーはそのユーザーのアカウントです。
- Claude Tag チャネルセッション: Claude はそれらをユーザーアカウントなしで実行するため、オーナーはセッションを開始したClaude Tag エージェントです。そのエージェントが開始するすべてのチャネルセッションは同じオーナーを持ち、Slack メッセージを送信した人です。そのため、
--capacityが 1 より大きい場合、または正の--drain-grace-secで実行する場合、ランナーはそれにロックされたセッションを提供し、異なる人が開始したセッションを実行します。ユーザーにロックされたランナーはこれらを取得しません。Claude Tag エージェントにロックされたランナーはユーザーのセッションを取得しません。
セッションのライフサイクル
開発者がセッションを開始して環境を選択すると、Anthropic のコントロールプレーンはセッションを環境のキューに配置します。そこから。- 空き容量のあるランナーがセッションを要求し、それに対するリースを保持します。
- ランナーはリポジトリを作業ディレクトリにクローンし、子 Claude Code プロセスを生成します。
- 子はランナーがポーリングを続ける間、HTTPS 経由でイベントをストリーミングします。各ポーリングはリースをリフレッシュし、ハートビートとしても機能します。
- ランナーが約 60 秒間ポーリングを停止すると、サーバーはセッションを別のランナーのキューに戻します。
ランナーのライフサイクル
ランナーが最初に取得するセッションはランナーをそのセッションのオーナーにロックし、ランナーはそのオーナーの最大--capacity個の同時セッションを実行します。ランナーがアクティブなセッションを持ち、シャットダウン信号を受け取っていない、または退職時間に達していない間、ランナーはロックされたオーナーのキューに入った作業を要求し続けます。完了後の動作は--drain-grace-secによって異なります。
- デフォルトの
0: ランナーはアクティブなセッションが完了するとすぐに終了し、ポーリングを続けません。デプロイされたオーケストレーター（Kubernetes など）は、新しいディスクで再起動でき、任意のオーナーに対応する準備ができています。 - 正の値: ランナーは終了する前に、ロックされたオーナーのキューをその秒数ポーリングし続けます。
--retire-atが必要かどうかが決まります。SIGTERMを配信するキルには、フラグは不要です。ランナーはシャットダウンタイミングで説明されているようにドレインするか、--defer-shutdown-max-minを設定するときに既に保持しているセッションの提供を続けます。インフラストラクチャが代わりに既知の壁時計時刻でホストを破棄する場合、またはシグナルなしで、またはサンドボックスライフタイムキャップやスポットインスタンス再利用などのドレインに短すぎるグレースピリオドで、--retire-at <epoch-seconds>を渡します。その時刻の数分前に設定します。退職時刻に。
- ランナーは新しい作業を受け取るのを停止します。
- ランナーは、
--release-idle-session-minフラグが使用する同じリリースパスを通じて各アクティブセッションをリリースするため、セッションはユーザーが次のメッセージを送信するときに新しいランナーで再開されます。ランナーが各セッションをリリースするタイミングはその状態によって異なります。- ランナーはターン中のセッションをそのターンが完了するとすぐにリリースします。
- ターンが完了し、バックグラウンドタスクが実行されたままの場合、ランナーは最大 60 秒待機してから、まだ実行中でもセッションをリリースします。タスクが完了しているが、その結果を読む後続のターンがまだ実行されていない場合、ランナーはそのターンが完了するまでセッションを保持し、
SELF_HOSTED_RUNNER_BG_RESULT_GRACE_MS以上待機しません。そのターンが開始されるまで。
- ランナーはすべてのセッションがリリースされると、0 で終了します。
--retire-atがない場合、シグナルレスホストキルはクラッシュと区別できません。コントロールプレーンはクリーンリリースではなく、失われたワーカーを記録し、セッションは別のランナーにキューに戻されます。
ネットワークパス
ランナーとそのセッションはいくつかの種類の送信接続を行い、Anthropic からのインバウンド接続は不要です。- コントロールプレーン: ランナーは
api.anthropic.comをポーリングして作業を取得し、セットアップ進捗とエラーイベントを投稿します。すべて送信 HTTPS です。ポーリングはランナーのハートビートとしても機能します。 - SCM コネクタ: オプションのオーケストレーターSCM コネクタトンネルは唯一の WebSocket 接続です。
- Git: ランナーは HTTPS または SSH 経由で git ホストからクローンおよびプッシュし、デプロイが提供する認証情報で認証されます。git の設定では、セッションごとにミントされた認証情報やAnthropic git プロキシ（git を
api.anthropic.com経由でルーティング）を含むオプションについて説明しています。 - セッション子: 子 Claude Code プロセスはセッションのイベントストリームを
api.anthropic.comに保持し、モデル推論とセッション中に実行される git コマンドの送信呼び出しを行います。完全な送信リストについては、ネットワーク要件を参照してください。上記の図はこれらのパスを示しており、オプションの SCM コネクタを除きます。
HTTPS_PROXYやNO_PROXYなど）を尊重します。各プロセスの環境で設定します。変数はコントロールプレーン呼び出し、オーケストレーターのSCM コネクタWebSocket、および HTTPS リモートの組み込みクローンをカバーし、セッションはランナーからそれらを継承します。セッションストリーミングは HTTPS 経由のサーバー送信イベントを使用するため、パス内のプロキシは応答をバッファリングしてはいけません。
プロキシがProxy-Authorizationヘッダーも必要とする場合、ランナーはプロキシへの各接続にそれを追加できます。送信プロキシへの認証を参照してください。
インフラストラクチャに保たれるもの
リポジトリのチェックアウト、ビルドアーティファクト、シークレット、およびセッションが作成または変更するファイルは、プロビジョニングしたマシンに保たれます。会話自体（プロンプト、応答、ツール結果を含む）は、モデル推論のためにapi.anthropic.comに送信され、Anthropic はセッショントランスクリプトを保存して、別のサポートされているサーフェスからセッションを再開できるようにします。
自己ホスト環境はセッション実行をネットワークに移動させます。コントロールプレーンは Anthropic ホスト型のままです。セッションオーケストレーション、キューイング、および claude.ai インターフェースは Anthropic のインフラストラクチャで実行され続けます。
開始する
自己ホスト環境ページは、実行している内容によって整理されています。- クイックスタート: Claude Code をインストールし、環境を作成し、ランナーを開始し、最初のセッションをルーティングします。
- 本番環境へのデプロイ: セキュリティ強化、ネットワーク送信、git 認証情報、Kubernetes および Compose レシピ、既知の問題、およびトラブルシューティング
- セッションをカスタマイズ: セッションごとの認証情報、ライフサイクルフック、オンデマンドランナー、MCP サーバー、および権限のためのラッパースクリプト
- エンドツーエンドをテスト: ランナーイメージをプロモーション前に検証する CI スモークテスト
- リファレンス: すべての CLI フラグ、環境変数、メトリック、およびヘルスエンドポイント
- セッション ID を検証: 独自のサービスからセッショントークンを検証してから、アクセスを許可します。