Claude Codeはセルフホストできる？仕組み・対象プラン・個人の代替手段

「Claude Codeを自社のサーバーで動かしたい」「コードを外部に出さずにAIエージェントを使いたい」——セキュリティ要件の厳しい会社ほど、この壁に突き当たります。

結論から言うと、Claude Codeは2026年8月のv2.1.224から「セルフホスト環境」を公開ベータとして提供しており、クラウドセッションの実行を自社インフラに移せます。ただし対象はTeam・Enterpriseプランの組織のみで、データの境界を誤解したまま導入すると期待外れになります。個人プランには別の現実解（Remote Control）があります。

株式会社Fyveは中小企業のAI活用を支援しています。この記事では公式ドキュメントと、私自身が手元のClaude Code実機で確認した挙動をもとに、セルフホスト環境の仕組み・対象プラン・個人や小規模チームの代替手段までを整理します。

結論：セルフホストできるのは「クラウドセッション」だけ

最初に全体像を一枚で示します。Claude Codeのセッションには「どこで実行されるか」が異なる2種類があり、セルフホスト環境が関係するのは片方だけです。

• ターミナル・IDEの通常セッション——もともとあなたのPC上で実行されています。セルフホスト環境の対象外で、そもそも何も設定する必要がありません
• クラウドセッション——claude.aiのWeb画面・モバイルアプリ・デスクトップアプリ・定期実行（routines）・claude --cloud から起動するセッション。標準ではAnthropicのインフラで実行されますが、これをセルフホスト環境で自社ネットワーク内の実行に切り替えられます

つまり「セルフホスト環境」は、クラウドセッションの実行場所を Anthropic のサーバーから自社のサーバーへ移す機能です。リリースは2026年8月7日のv2.1.224で、現在はTeam・Enterpriseプラン向けの公開ベータです。

先に解いておくべき2つの誤解

検索でこの機能に辿り着いた方の多くが、次のどちらかを期待しています。導入判断を誤らないために、先に両方を訂正しておきます。

誤解①「普段のClaude Codeはクラウドで動いているから、セルフホストしないとコードが外に出る」

ターミナルやIDEで使う通常のClaude Codeは、最初からローカル実行です。コードの読み書き・コマンド実行はすべて手元のマシンで行われ、Anthropicのサーバーに送られるのはモデルへの問い合わせ（プロンプトと応答）です。

したがって「ローカルのコードベースをAIに触らせたいが、実行環境を外に出したくない」だけであれば、通常のターミナル利用で既に満たされています。セルフホスト環境は不要です。

誤解②「セルフホストすれば、会話内容もAnthropicに送られなくなる」

これも誤りです。セルフホスト環境でもモデル推論はAnthropic API（api.anthropic.com）で行われます。プロンプト・応答・ツールの実行結果といった会話内容は従来どおりAnthropicに送られ、セッションを別デバイスから再開できるようトランスクリプトも保存されます。

自社に残るのはリポジトリのチェックアウト・ビルド成果物・シークレット・セッションが作成/変更したファイルです。「完全オンプレでLLMごと自社運用」ではなく、実行環境だけを自社に置き、頭脳はAPI越しに借りる構図だと理解してください。公式ドキュメントも、推論をAmazon BedrockやGoogle Cloud経由に切り替えることはできないと明記しています。

読者特典・無料ダウンロードClaudeのこの5つの設定、今すぐ見直した方がいい無料でダウンロード →↓

セルフホスト環境の仕組み——Environment・Runner・Session

仕組みは3つの登場人物で説明できます。発想はGitHub ActionsなどのセルフホストCIランナーとほぼ同じです。

• Environment（環境）——クラウドセッションの送り先として組織が作る「名前付きの箱」。claude.aiの管理画面（Cloud environmentsページ）で作成し、複数のRunnerを束ねます
• Runner（ランナー）——自社ネットワーク内のホストで動かす常駐プロセス。環境作成時に一度だけ表示される「環境キー」で登録し、キューを監視してセッションを取りに行きます
• Session（セッション）——開発者が起動した1つのClaude Codeタスク。Runnerが子プロセスとして実行します

セッションが実行されるまでの流れ

開発者がクラウドセッションを起動すると、環境の選択画面にAnthropicホストの環境と並んで自社の環境が表示されます。自社環境を選ぶと、次の流れで処理されます。

• Anthropicのコントロールプレーンがセッションを環境のキューに載せる
• 空きのあるRunnerがセッションを取得し、リースを保持する
• Runnerが対象リポジトリをクローンし、子プロセスとしてClaude Codeを起動する
• 子プロセスがHTTPSでイベントをストリーミングし、Runnerのポーリングがハートビートを兼ねる
• Runnerが約60秒応答しなくなると、サーバーがセッションを別のRunnerに再キューする

重要な設計として、1つのRunnerは同時に1ユーザーにしか仕えません。最初のセッションを取得した時点でそのユーザーのアカウントにロックされ、以降はそのユーザーのセッションだけを処理します。チェックアウトしたコードがユーザー間で混ざらないための分離設計で、必要なランナー台数の下限は「同時にアクティブになるユーザー数」になります。

ネットワークはすべてアウトバウンド——Anthropicからの着信は不要

セキュリティ審査で最初に聞かれる点ですが、必要な通信はすべて自社側からの外向き（アウトバウンド）HTTPSで、Anthropicから自社ネットワークへの着信は一切ありません。

• コントロールプレーン——Runnerがapi.anthropic.comへポーリング（外向きHTTPS）
• Git——自社のGitホストへHTTPSまたはSSHでクローン/プッシュ。社内ネットワーク内のGitホストにもそのまま届く
• セッション本体——イベントストリームとモデル推論をapi.anthropic.comへ（外向きHTTPS）

社内のプロキシ経由（HTTPS_PROXY等）もサポートされています。1点だけ注意があり、セッションのストリーミングはSSE（Server-Sent Events）を使うため、経路上のプロキシがレスポンスをバッファリングすると動きません。

対象プランと有効化の条件

2026年8月時点の提供条件は次のとおりです。

• プラン——Team・Enterpriseプランの組織向け公開ベータ。デフォルトはOFFで、組織のOwnerまたは管理者がclaude.ai管理画面のCloud environmentsページで「Allow self-hosted environments」を有効化する必要があります（前提としてClaude Code on the webが組織で有効であること）
• Zero Data Retention（ZDR）を有効にした組織は利用不可——データ保持なし契約とセッショントランスクリプト保存が両立しないため
• リポジトリはGitHub——セッションがチェックアウトするリポジトリはGitHubが前提です
• 課金——セルフホスト環境のセッションも、Anthropicホストと同じように組織のClaude Code利用枠を消費します。自社インフラで動かしても利用料が安くなるわけではなく、サーバー費用は別途自社持ちです

私の環境（個人のMaxプラン・Claude Code v2.1.233）でも実際に確認しましたが、claude --help にはセルフホスト環境へセッションを送る --environment オプションが載る一方、ランナーのセットアップコマンドは個人アカウントでは露出していません。

プランによるゲートは実際に効いています。個人プランで検討している方は、この後の「個人・小規模の現実解」へ進んでください。

もう1つ、公開ベータ時点ではルーティングされないセッション種別があります。Claude Tag（Slack連携）・Claude Security・Code Reviewの各セッションはまだセルフホスト環境に送れず、対応は順次追加予定とされています。これらを主用途にしている組織は、対応状況を確認してから計画してください。

導入の流れ（概要）

細かい手順は公式のクイックスタートに譲り、ここでは全体の流れだけ押さえます。大きくは4ステップです。

• ① 組織側で機能を有効化——Ownerまたは管理者がclaude.ai管理画面で「Allow self-hosted environments」をON
• ② 環境（Environment）を作成——同じ管理画面で作成。このとき一度だけ表示される環境キーを控える（Runnerの登録に使う共有クレデンシャル）
• ③ 自社ホストでRunnerを起動——環境キーで登録すると、Runnerがキューのポーリングを開始する。本番運用ではKubernetesやDocker Composeでの構成例が公式ドキュメントに用意されている
• ④ セッションを送る——開発者がクラウドセッションの起動時に環境ピッカーで自社環境を選ぶだけ。ターミナルからは claude --cloud や --environment オプションでも送れる

③のRunnerイメージには、ビルドに必要なコンパイラ・SDK・社内CLIを事前に焼き込んでおきます。ここの作り込みがそのまま「セッションが即戦力で始まるか」を決めるため、導入工数の本体は①②④ではなく③のイメージ整備と考えておくと見積もりを外しません。

なお、Runnerの停止まわりも実運用では重要です。通常の停止（SIGTERM）では実行中のセッションを流し切ってから終了します。

スポットインスタンスのように猶予なくホストが消える環境では、消える時刻の少し前を指定する起動フラグ（retire-at）が用意されており、実行中のセッションを解放してから終了させることで、ユーザーの次のメッセージで別Runnerに引き継がれます。この設計が最初から入っている点は、CIランナー運用の経験があるチームほど評価できるはずです。

運用は2モード——fixedとon-demand

Runnerの運用方法は2つから選べます。

• fixed（固定）——決まった台数のRunnerを常時起動しておき、セッションを分散させる。構成が単純で、まず試すならこちら
• on-demand（オンデマンド）——オーケストレーター（自社でホストするもう1つのプロセス）がキューを監視し、セッションが来たらRunnerを起動、終わったら停止する。需要に応じて自動でスケールする

見落とされがちなのが運用の所有コストです。公式ドキュメントは「ほとんどのチームはAnthropicホストの環境で十分」と明言した上で、セルフホストを選ぶなら、Runnerイメージの構築と保守・フリートの運用・ネットワーク管理を担うチーム（プラットフォームチームや開発生産性チーム）を置くことを推奨しています。

「コマンド一発で終わり」ではなく、CIランナー基盤を1つ増やすのと同等の運用が発生すると見積もるのが実態に近いです。

その対価として得られるのは、次の3点です。

• 社内ネットワークへのアクセス——セッションが内部のサービス・データベース・レジストリに、外部公開なしで届く
• カスタムツーリング——コンパイラ・SDK・社内CLIをRunnerイメージに事前インストールし、毎セッションが即ビルド可能な状態で始まる
• コンプライアンス——リポジトリのチェックアウトとビルド成果物が自社管理のインフラから出ない

個人・小規模チームの現実解はRemote Control

ここまで読んで「うちはTeamプランではない」という方が大半だと思います。実は公式ドキュメント自身が、その場合の答えを示しています。

「自分の常時起動マシンでClaude Codeを動かし、他のデバイスから操作したい」というニーズにはRemote Controlを使ってください——これはProプラン・Maxプランで利用できます。

自宅やオフィスのMac miniなど常時起動のマシンでClaude Codeを動かし、外出先のスマホやノートPCから同じセッションを操作する構成で、「実行環境を自分の管理下に置く」という目的の大部分はこれで達成できます。

私自身、この構成を実際に運用しています。自宅のMac miniを常時起動サーバーにして、Claude Codeの定期ジョブと外出先からの接続を両立させる方法は、次の記事で構成図付きで解説しています。

Claude CodeTailscale使い方｜Mac miniへ外出先から安全に接続

整理すると、目的別の選択肢はこうなります。

• コードを手元から出したくないだけ——通常のターミナル利用で既に満たされている（追加設定不要）
• 個人・小規模で、自分のサーバーからClaude Codeを使いたい——Remote Control（Pro/Max）
• 組織として、クラウドセッションを社内ネットワークで実行したい——セルフホスト環境（Team/Enterprise）

データの境界——何が自社に残り、何がAnthropicに送られるか

導入判断の核心なので、境界を表にまとめます。

• 自社インフラに残るもの——リポジトリのチェックアウト、ビルド成果物、シークレット（環境変数・認証情報）、セッションが作成・変更したファイル
• Anthropicに送られるもの——会話内容（プロンプト・応答・ツールの実行結果）。モデル推論のためにapi.anthropic.comへ送信され、別デバイスからの再開用にセッショントランスクリプトが保存される
• Anthropic側に残る役割——コントロールプレーン（セッションのオーケストレーション・キュー・claude.aiの画面）はAnthropicホストのまま

「会話内容は送られる」という点をどう評価するかは、組織のデータ分類次第です。ソースコードの断片はツール実行結果として会話に含まれ得るため、「コードが一切Anthropicに行かない」構成ではないことは経営層・情報システム部門への説明で正確に伝えるべきポイントです。Claude Code全体のデータ保護（暗号化・学習利用の扱い・保持期間）はプラン別に整理した次の記事が参考になります。

Claude CodeClaude Codeの情報漏洩対策｜データの暗号化・学習オフ・自動削除をプラン別に比較

よくある質問

個人のPro/Maxプランでセルフホスト環境は使えますか？

使えません。Team・Enterpriseプランの組織向け公開ベータです。個人で「自分のマシンを実行環境にしたい」場合はRemote Control（Pro/Maxで利用可）が該当します。

料金は安くなりますか？

なりません。セルフホスト環境のセッションも組織のClaude Code利用枠を通常どおり消費し、加えてRunnerを動かすサーバー費用が自社負担になります。コスト削減ではなく、ネットワーク到達性とコンプライアンスのための機能です。

モデル推論を自社のLLMやBedrockに切り替えられますか？

できません。推論はAnthropic APIに固定で、セッションごとに発行されるOAuthトークンで認証されます。Amazon Bedrock・Google Cloud・Microsoft Foundry・LLMゲートウェイ経由への切り替えは、セルフホスト環境では利用できないと公式に明記されています。

Zero Data Retention（ZDR）契約の組織でも使えますか？

使えません。ZDRを有効にした組織ではセルフホスト環境は利用できません。

普段ターミナルで使っているセッションもセルフホスト環境に移すべきですか？

不要です。ターミナル・IDEのセッションはもともとローカル実行です。セルフホスト環境の対象は、claude.aiやモバイルアプリ・定期実行から起動するクラウドセッションだけです。

GitHub以外のGitホスティングでも使えますか？

2026年8月時点では、セッションがチェックアウトするリポジトリはGitHubが前提です。ただしRunner自体は社内のGitホストへHTTPS/SSHで到達できるため、詳細は公式ドキュメントの認証オプションを確認してください。

まとめ

Claude Codeのセルフホスト環境について、判断に必要な要点をまとめます。

• セルフホストの対象はクラウドセッションのみ。ターミナルの通常セッションはもともとローカル実行
• v2.1.224（2026年8月7日）からの公開ベータ。Team・Enterprise限定・デフォルトOFF・ZDR組織は不可
• 自社に残るのはチェックアウト・成果物・シークレット。会話内容は推論のためAnthropicに送られる——完全オンプレではない
• 仕組みはセルフホストCIランナーと同型（Environment/Runner/Session）。通信はすべてアウトバウンドHTTPSで着信不要
• 運用はfixed/on-demandの2モード。Runnerイメージの構築・保守を担う体制を前提に見積もる
• 個人・小規模の現実解はRemote Control（Pro/Max）。目的が「手元からコードを出さない」だけなら追加設定は不要

一次情報は公式ドキュメント（Self-hosted environments - Claude Code Docs）と公式ブログ（Run Claude Code sessions on your own compute）です。導入を検討する際は、最新の提供条件をあわせて確認してください。