Claude Code のセッションを自社インフラで実行できる self-hosted environments が公開ベータ
Claude Code のセッションを Anthropic のホスト環境ではなく組織自身のインフラ上で実行できる self-hosted environments が公開ベータで提供された。対象は Claude Team / Enterprise で既定は無効、Zero Data Retention 利用組織は対象外。組織側に runner と呼ばれる長寿命プロセスをデプロイして運用する。
ニュース原文を読む ↗要約
Anthropic は 2026-08-06、Claude Code のセッションを組織自身のインフラ上で実行できる self-hosted environments を公開ベータで提供開始しました。Web / モバイル / デスクトップ / プログラム経由でセッションを開始でき、実行そのものは組織のネットワーク内、社内サービスやツールチェーンの隣で行われます。
対象は Claude Team および Enterprise プランの組織です。既定は無効で、組織側で有効化します。Zero Data Retention（ZDR）を利用している組織は対象外です。
セットアップでは「runner」と呼ばれる長寿命プロセスを組織側にデプロイします。運用形態は2つあります。あらかじめ決めた数のインスタンスを常駐させて負荷分散する fixed mode と、セッションがキューに入るとオーケストレータが runner を払い出し、完了後に破棄する on-demand mode です。公式は、イメージの保守、runner の更新、オーケストレータの運用に専任のエンジニアリングリソースが必要だと明記しています。
解決する課題として3点が挙げられています。社内データベースやサービスへ、インターネットに露出させることなくアクセスできること。コンパイラ・SDK・自社 CLI を事前導入した状態でセッションを始められること。ソースコードとビルド成果物を自社の管理下に留められることです。
重要な制約として、データの扱いは分離されます。ファイル成果物は自社側に残りますが、会話のプロンプト・応答・ツール実行結果は推論のため Anthropic へ送信され、セッションのトランスクリプトは複数サーフェス間の継続のため Anthropic 側に保存されます。開発者の手元マシンで動く Remote Control とは別の機能です。
何が変わったか
- Claude Code セッションを組織自身のインフラ（runner）上で実行できる（公開ベータ）
- fixed mode / on-demand mode の2形態で runner を運用できる
- 社内ネットワーク内のデータベース・サービスへ、外部露出なしにアクセスできる
- 自社の compiler / SDK / CLI を事前導入したイメージでセッションを開始できる
- ソースコードとビルド成果物を自社インフラに留められる
- 対象は Team / Enterprise。既定は無効、ZDR 利用組織は対象外
- プロンプト・応答・ツール実行結果は推論のため Anthropic へ送信される
- セッションのトランスクリプトは Anthropic 側に保存される
- イメージ保守・runner 更新・オーケストレータ運用に専任リソースが必要
業務インパクト（一般企業向け）
この機能を評価するとき、最初に整理すべきなのは「何がオンプレになって、何がならないか」です。
「自社インフラで実行」と聞くと、データが一切外に出ない構成を想像しがちですが、そうではありません。実行環境が自社側に来るだけで、会話の中身は推論のために Anthropic へ送られます。ファイルは残る、会話は出る、という分離です。したがって、この機能が刺さるのは「ソースコード全体を外に出したくない」組織であって、「AI に一切の情報を渡したくない」組織ではありません。後者の要件を持つ部門に対してこれを提案すると、話が噛み合いません。
実際に効くのは、ネットワーク到達性の問題です。社内 DB、社内 API、認証が必要な内部サービス — こうした資産に Claude Code から触らせたい場合、従来はローカル実行しか選択肢がありませんでした。ローカル実行は開発者の手元環境に依存するため、「あの人の環境では動く」という属人化を生みます。runner を社内に置けば、同じイメージで全員が同じ環境を使えます。この「環境の標準化」の方が、セキュリティ要件より実務的な価値が大きい組織は少なくないはずです。
もう一つの利点は、ツールチェーンの事前導入です。専用のコンパイラ、社内 SDK、独自の CLI が必要なプロジェクトでは、セッションの立ち上がりに毎回セットアップが走ります。runner のイメージにこれらを焼いておけば、セッション開始直後から実作業に入れます。ビルドが重い言語やモノレポ構成では、この差が体感で効きます。
導入判断で最大の論点は運用コストです。公式が「専任のエンジニアリングリソースが必要」と明記している点は、控えめな表現として読むべきです。runner のイメージは Claude Code のバージョン更新に追従させる必要があり、Claude Code はほぼ毎日リリースが出ています。on-demand mode を選べばオーケストレータの実装・運用も加わります。プラットフォームチームが既にあり、コンテナ基盤を運用している組織なら追加負荷は限定的ですが、そうでない組織にとっては新しい運用対象が1つ増えます。
導入するなら、fixed mode から始めるのが現実的です。on-demand mode は利用が波打つ組織でコスト効率が良い設計ですが、オーケストレータという可動部が増えます。まず固定台数で回して、実際の同時利用数を測ってから on-demand への移行を検討する順序が安全です。
ZDR 利用組織が対象外である点にも注意が必要です。契約上 ZDR を選んでいる組織は、この機能を使うために ZDR を外す判断が必要になります。それはセキュリティ要件の緩和にあたるため、単なる機能追加の稟議では通りません。
副業・個人活用視点
個人利用者が直接使う機能ではありません。Team / Enterprise 契約が前提で、運用にインフラの手が要ります。個人の副業案件でこれを自分の環境に導入する場面は、まず想定しなくてよいでしょう。
意味があるのは、支援側に回る場合です。
企業に Claude Code を導入する支援をしていると、必ず「社内システムに繋げられないと業務では使えない」という壁に当たります。営業支援ツールのデータ、社内の在庫 DB、認証が要る基幹システム — これらに触れないと、AI にやらせたい作業の半分が対象外になります。従来はローカル実行 + VPN という構成で凌ぐしかなく、開発者ごとに環境が違う問題が残りました。self-hosted environments は、この相談に対する公式の回答になります。
ただし、提案するなら運用コストを最初に明示すべきです。「自社インフラで動かせます」とだけ伝えると、クライアントは「セキュリティが解決した」と受け取ります。実際には、コンテナ基盤の運用、イメージの更新追従、runner の監視という継続作業が発生します。ここを曖昧にしたまま導入すると、半年後に「更新されないまま古い Claude Code が動いている」という状態になり、支援した側の信用が下がります。
案件としては、初期構築より継続的な保守の方が価値を出しやすい領域です。イメージの更新運用、runner のスケーリング調整、社内システムへの接続設定の追加 — これらは一度作って終わりにならない性質の作業です。単発の構築案件として受けるより、月次の保守契約として設計する方が、クライアントにとっても実態に合います。
もう一つ、提案時に確実に確認すべきなのが ZDR の利用有無と、データの流れについての認識です。「ソースコードは外に出ないが、会話の中身は Anthropic に送られる」という点を、こちらから先に説明しておかないと、後で認識のずれが露見したときに責任問題になります。技術的な説明としては地味ですが、この一言を最初に置けるかどうかで、支援者としての信頼度が変わります。