Claude Codeセルフホスト環境の6つの落とし穴｜自社インフラで動かす条件

「Terraform はプリインストールされてませんでした」。クラスメソッドのかずえ@製造BT氏が、Claude Code on the webを試したときの記録にそう書いている（DevelopersIO, かずえ@製造BT, 2026年7月5日）。同じ記事には「MDM で全社員の端末に入れているセキュリティツール（Sentinel など）は、クラウド上の隔離された VM では範囲外になります」という指摘もある。MDM（端末管理）で守っていたはずの範囲から、実行環境が外れていたわけだ。

2026年8月6日、Anthropicはその実行場所を自社側へ引き戻す選択肢を公開ベータで出した。Claude Codeのセルフホスト環境だ（Anthropic, 2026年8月6日。以下、英語ソースからの引用はいずれも筆者訳）。

公式ブログと公式ドキュメント2ページを突き合わせると、発表記事や要約では落ちている運用上の制約がいくつも出てくる。「ランナーは1ユーザーに固定される」「未pushの作業は消える」あたりは、構築を決める前に知っておきたい類のものだ。なお自分はTeam・Enterprise契約者ではないので、この環境を実際に構築して動かしたわけではない。以下は公式ドキュメント「Self-hosted environments」と「Deploy self-hosted environments to production」（いずれも2026年8月7日閲覧）を読み込んだうえでの整理だ。

仕組み：CIのセルフホストランナーとほぼ同じ発想

公式ドキュメントは構成要素を3つに整理している。

用語	実体
Environment（環境）	claude.aiの管理画面で作る「送り先」の名前。ランナーの束をまとめる単位
Runner（ランナー）	自社ネットワーク内のホストで常駐するプロセス。セッションを引き取って実行する
Session（セッション）	開発者が投げたClaude Codeのタスク1件

開発者がclaude.ai、モバイル・デスクトップアプリ、claude --cloud、スケジュール実行のRoutinesからセッションを始めると、開始画面に環境の選択肢が並ぶ。自社の環境を選ぶと、Anthropicのコントロールプレーン（セッションの受付・キュー管理・UIを担う管制側。コードの実行はしない）がその環境のキューにセッションを置く。社内のランナーがそれを引き取ってリポジトリをクローンし、自社ホスト上でClaude Codeプロセスを起こす。ドキュメントは「考え方はCIのセルフホストランナーと同じ」と説明している。

通信の向きが重要だ。ランナーはキューのポーリング、セッションのイベントストリーム、モデル推論のすべてをapi.anthropic.comへの外向きHTTPSで行う。公式ドキュメントには「Anthropicが自社ネットワークへ接続することは一切ない」と明記されている。ファイアウォールに穴を開けて待ち受ける構成ではない。

そのランナーの並べ方に2方式ある。この違いが後で効いてくるので先に置いておく。

方式	動き	環境シークレットの置き場所
固定フリート	ランナーを常駐させておき、セッションを引き取らせる	セッション実行ホスト上（＝あらゆるセッションのコードから読める）
オンデマンド	オーケストレーターがキューを見て、必要になったらランナーを起こす。仕事が終わればランナーは自分で終了する	オーケストレーターのホストのみ

Anthropic側が挙げるメリットは3つだ。閉域の社内サービス・DB・レジストリへ公開せずに到達できること、コンパイラやSDK、社内CLIをランナーイメージに焼いておけること、チェックアウトとビルド成果物が自社インフラに残ること。冒頭の「Terraformが入っていない」問題は、確かにイメージを自分で作れば解決する。

なお、5月に発表されたManaged Agents向けのSelf-hosted Sandboxとは別物だ。あちらはManaged Agentsの実行環境の話で、今回はClaude Codeのクラウドセッションが対象になる。

「セルフホスト＝外に出ない」ではない

ここが最大の誤解ポイントなので先に潰しておく。

自社インフラに残るのは、リポジトリのチェックアウト、ビルド成果物、シークレット、セッションが作成・変更したファイルだ。一方でAnthropicへ送られるものが公式ドキュメントに明記されている（Anthropic, Self-hosted environments、2026年8月7日閲覧。以下、同ページからの引用は筆者訳）。

会話そのもの、つまりプロンプト、応答、ツールの実行結果は、モデル推論のためにapi.anthropic.comへ送られ、セッションのトランスクリプトはAnthropicが保存する。任意のサーフェス（claude.ai・アプリ・CLIなどの利用面）からセッションを再開できるようにするためだ。

「ツールの実行結果」には、Claudeが読んだコードが含まれる。つまりエージェントが社内リポジトリを読んで作業する以上、そのコードは推論のためにAnthropicへ渡る。同ドキュメントも「セルフホスト環境が自社ネットワークへ移すのはセッションの実行であって、コントロールプレーンではない」と書いている。

Anthropicに渡ったあとの統制は、プロンプトをモデルに届く前に検査するInference hooksやCompliance APIによる事後監査の領分で、セルフホストは別の軸の話だ。混ぜて理解すると導入判断を間違える。

落とし穴1：ランナーは1ユーザーに固定される

ランナーは最初に引き取ったセッションのユーザーアカウントにロックされ、以降そのユーザーのセッションだけを実行する。ユーザー間でチェックアウト済みコードが混ざらないようにするための設計だ。

結果として、公式ドキュメントは「最小のフリートサイズは、同時にアクティブになると見込むユーザー数」と書いている。ランナー起動時のフラグ--capacityは1ユーザー内の並列数を増やすだけで、ユーザーをまたいだ相乗りはできない。10人が同時に使うなら10台。CIランナーのように「空いている台が拾う」感覚で台数を見積もると、セッションがキューに滞留する。

トラブルシューティングの項にも「セッションがキューに残り続ける」原因として「オンラインのランナーがすべて別アカウントにロックされている可能性」が挙げられている。

落とし穴2：セッション再開で未pushの作業が消える

アイドルタイムアウトやランナー再起動でセッションが解放されたあと、ユーザーが次のメッセージを送ると、セッションは別のランナー上で開始ブランチからリポジトリを再クローンして再開する。ドキュメントの表現はこうだ（Anthropic, Deploy self-hosted environments to production、2026年8月7日閲覧、筆者訳）。

セッションがpushしていなかった作業は失われる。

ランナー起動時のフラグ--push-outcome-on-releaseを設定すれば解放前にベストエフォートでpushしてくれるが、救えるのはコミット済みの内容だけで、ダーティな作業ツリーは対象外だ。しかもこのフラグには別のリスクが付く。再開時にランナーは「誰がpushしたか」を検証せずに以前のブランチをfetchするため、claude/*へのpush権限を持つ者は再開後のワークスペースへ任意の内容を差し込める。ドキュメントは有効化前にブランチルールセットでpush権限を絞るよう求めている。

なお、解放までのアイドル時間は--release-idle-session-minで運用側が決める値で、既定値は今回読んだ2ページには書かれていない。つまり「何分放置すると危ないか」は導入先の設定次第になる。

使う側の防衛策は結局「こまめにcommitしてpushする」に尽きる。ダーティな作業ツリーは--push-outcome-on-releaseでも救われない。セッションを長時間放置しない、離席前に一度区切る。ローカルのClaude Codeなら気にしなくていい習慣が、クラウドセッションでは必要になる。

落とし穴3：止まるときはAnthropic側の障害で止まる

セッションのオーケストレーション、キューイング、claude.aiのUIはAnthropicホストのままだ。自社にランナーを置いても、コントロールプレーンが落ちればセッションは始まらない。

Anthropicの稼働率については、第三者モニタリングサービスStatusGatorの集計で2026年に164件のインシデントが記録されている（Anthropicの公式カウントではない）。この数字を踏まえると、「自社インフラに移したから可用性を自分でコントロールできる」という期待は、筆者の見立てでは成立しにくい。むしろ自社ランナーの運用責任が増えたぶん、障害切り分けの手間は増える。

ランナー側にも時間の縛りがある。ランナーのポーリングが60秒ほど途絶えると、サーバーはそのセッションを別のランナーへ回す。ホストの時計がずれていると認証が失敗し、ドキュメントは「5分以上のスキューで認証に失敗する」と書いている。

落とし穴4：誰でも任意の環境にセッションを投げられる

ハードニングの章にこう書かれている。

組織のメンバーは誰でも、任意の環境へセッションをディスパッチできる。ディスパッチに関する、環境ごとのアクセス制御は存在しない。

つまり全ランナーホストは「組織の全メンバーがコード実行できるホスト」として扱う必要がある。特定チームの本番隣接ネットワークにランナーを置くなら、その事実が持つ意味は重い。--lock-to-accountで「そのホストがどのアカウントのセッションを実行するか」は絞れるが、環境へのディスパッチ自体は組織全体に開いたままだ。OwnerまたはAdminがAnthropicホストの環境を選択肢から隠すことはできるが、それは逆方向の制御でしかない。

さらに固定フリート構成では、環境シークレット（ランナー登録用の共有credential）がセッション実行ホスト上に置かれる。ドキュメントは「そのファイルはあらゆるセッションのコードから読める前提で扱い、侵害が疑われたらローテートせよ」と明言している。回避策が先に挙げたオンデマンドランナーで、シークレットはユーザーコードを実行しないオーケストレーターのホストにだけ残る。

落とし穴5：egress（外向き通信）の遮断は自社の仕事

ドキュメントは「default-denyのegressを自社のネットワーク境界で適用せよ。製品側では検証も強制もできない」と書き、その理由として「セッションのコードはモデルが指示するものであり、任意のホストへの接続を試みうる」を挙げている。

ClaudeがCTFの演習中に実在の企業環境へ到達した件を踏まえると、この警告を形式的なものとして読み流すのは避けたい、というのが筆者の受け止めだ。セルフホスト環境における既定の事前承認ツール（起動時点で許可済みのツール）にBashが含まれる旨もドキュメントに記載がある。この設定のままではシェル経由の外向き通信を製品側で止めることは期待できない。だからこそネットワーク境界でのdefault-denyが要求されている、と読むのが素直だろう。

セッションからクラウドのメタデータエンドポイント（169.254.169.254）を遮断せよという要求も同じ文脈だ。サブネット単位のegressポリシーはリンクローカル宛の通信を捕まえないので、コンテナの中で明示的に落とす必要がある。

落とし穴6：ZDR・Bedrock・GitHub以外は使えない

制約の一覧が地味に厳しい。

• ZDR非対応：Zero Data Retentionを有効にしている組織は使えない。機微データを扱う組織が真っ先に入れる設定がこれだ
• 推論の迂回不可：Amazon Bedrock、Google CloudのAgent Platform、Microsoft Foundry、LLMゲートウェイのいずれにも通せない
• リポジトリはGitHubのみ：チェックアウト元はGitHub（GitHub Enterprise Server含む）
• 一部サーフェス未対応：Claude Tag、Claude Security、Code Reviewのセッションはまだセルフホスト環境へ回らない
• セッション途中の非公開リポジトリ追加が失敗：開始後に追加したリポジトリは認証情報付きでクローンされない。必要なリポジトリはセッション作成時に全部選ぶ
• コネクタ通信は社内を経由しない：GitHub、Slack、Linearなどのコネクタ系ツールはAnthropic側から呼ばれる。「ツールの通信も社内に閉じたい」なら、ランナーイメージにローカルMCPサーバーとして同等品を持つ必要がある

コンプライアンス目的でセルフホストを検討する組織ほど、ZDRやBedrock経由を既に使っている可能性が高い。そこが排他になっているのは痛い。政府向けのFedRAMP High対応のような要件を抱える現場では、この一覧を最初に突き合わせるべきだ。

なお導入事例として公式ブログが引いているのは1社だけだ。FaireのシニアエンジニアリングマネージャーGeorge Jacob氏の「セルフホスト環境のおかげで、セキュリティと運用上の統制を保ったままClaude Codeを既存の開発ワークフローに組み込める」というコメントが載っている（Anthropic, 2026年8月6日、筆者訳）。公表事例が公開ベータ初日時点で1社にとどまることは、評価を確定させるには材料がまだ少ないことを意味する。

運用は「もう一つのCI基盤」を持つのと同じ

Anthropicはビルド済みイメージを配布しない。claudeバイナリを入れたDockerfileを自社で書き、言語ランタイムやMCPサイドカー（同じPodやコンテナ群に相乗りさせる補助プロセス）を積む。ドキュメントのサンプルはDebian bookworm-slimベースで、Claude Code 2.1.224以降でビルドするよう指定されている。

そのうえで運用の細かい要求が並ぶ。Kubernetesで動かすなら特に注意がいる。

• 本番ハードニングの推奨は--capacity 1＋使い捨てコンテナ、つまり1セッション1コンテナ
• KubernetesのterminationGracePeriodSecondsは既定30秒だが、ランナーがドレイン（実行中セッションの後始末）を終えるまで既定設定で合計80秒かかる。このままだと後始末の途中でpodが殺される
• 同一環境内の全ランナーで--base-dirと--capacityを揃えないと、再開したセッションの作業ディレクトリが変わり、エージェントが記録した絶対パスが壊れる
• コミット署名にgit 2.34以降、Anthropicのgitプロキシ利用に2.32以降が必要

セルフホストCIランナーを運用したことがあるなら既視感があるはずだ。RunsOnはセルフホストランナーの隠れコストとして「AMIの保守、インフラの監視、APIの不具合のデバッグ」「インフラ費用、egress課金、遊休キャパシティ」「製品開発ではなく保守に費やされるエンジニアの時間」を挙げている（RunsOn。同社はセルフホストランナーの代替となるマネージドサービスの提供元であり、その立場を踏まえて読む必要はある）。GitHub公式ドキュメントも、セルフホストランナーについて「OSとその他すべてのソフトウェアの更新はあなたの責任である」「ランナーマシンの維持費用はあなたの負担になる」と明記している（GitHub Docs, About self-hosted runners、2026年8月7日閲覧、筆者訳）。

Anthropic自身も同じ方向の但し書きを付けている。「ほとんどのチームにとってはAnthropicホストの環境のほうが適している。運用も構築も不要だからだ」（Anthropic, Self-hosted environments、2026年8月7日閲覧、筆者訳）。セルフホストは、ネットワーク・ツール・コンプライアンスの要件がそれを求める場合の選択肢という位置づけだ。

Anthropicホスト環境との違い

	Anthropicホスト環境	セルフホスト環境
セッションの実行場所	Anthropicのインフラ	自社のランナーホスト
コントロールプレーン	Anthropic	Anthropic（変わらない）
社内ネットワークへの到達	不可	可能
プリインストールされるツール	Anthropicが決める	自社のイメージで決める
運用責任	Anthropic	自社（イメージ・フリート・egress）
対象プラン	全プラン（Claude Code on the web有効時）	Team・Enterpriseのみ、既定オフ
Bedrock / Vertex / LLMゲートウェイ経由	構成による	不可

導入判断：自分ならこうする

PMとしての理解の範囲で評価すると、この機能の価値は「情報を外に出さないこと」ではなく「エージェントを閉域の中に置けること」にある。そこを取り違えると、労力に見合わない。

筆者の判断基準としては、エージェントに社内DB・社内API・社内レジストリを触らせたいなら検討に値する。一方、コードをAnthropicに渡したくないのが動機なら、上で見たデータフローの通り、この機能はその要件を満たさない。

導入するとして、自分ならこの順で進める。

1. クラウドセッションを実際に使っているかを先に確認する。ターミナルやIDEのClaude Codeは元から開発者のマシンで動く。クラウドセッションを使っていないなら、設定するものは何もない
2. 制約の突き合わせを最初にやる。ZDR、Bedrock/Google Cloud経由、GitHub以外のgitホスト。どれか1つでも該当したらそこで終わる。イメージを作り始める前に確認する
3. 同時アクティブユーザー数でランナー台数を見積もる。CIランナーの感覚で「まず3台」と置くと、4人目からキューで詰まる
4. オンデマンドランナー＋--capacity 1から入る。環境シークレットをセッション実行ホストから外せる構成がこれしかない。固定フリートは評価用と割り切る
5. egressのdefault-denyを、ランナーを本番ネットワークに繋ぐ前に作る。製品側は検証も強制もしてくれない

導入しない判断もある。ベータ機能であり、既知の制約に「未pushの作業が消える」が正面から書かれている段階のものだ。公表されている導入事例も1社にとどまる。ランナーイメージの保守と更新を継続的に引き受けられるプラットフォームチームがないなら、Anthropicホストの環境で回しつつ、必要な社内リソースだけをMCPサーバー経由で安全に露出させるほうが安く済む。

個人契約（Pro / Max）ならどうか

この機能は使えない。ただ、動機が「自宅の常時起動マシンにタスクを投げて、外出先から結果を見たい」なら、公式ドキュメントはProとMaxでも使えるRemote Controlを代替として案内している。ローカルのClaude Codeセッションを別デバイスから遠隔操作する仕組みで、ランナーもDockerイメージも要らない。セルフホスト環境がやりたいことの半分は、個人ならこちらで足りる。

クラウドセッション自体の使い勝手については、iimonのamahisa3氏が「ブランチ名を任意に付けることができません。またclaude/はじまりになる」と書いていた（iimon TECH BLOG, amahisa3, 2026年4月2日）。同記事はMCPサーバーやローカルにしかないツール、秘密鍵などローカル環境に依存するものが使えない点も挙げている。このうちツール周りはセルフホストで解消するが、ブランチ名のようなクラウドセッション共通の制約は変わらない。詳しくはClaude Code on the Webの基本を参照してほしい。

---

関連記事

• Claude Code on the Webとは？ブラウザからコーディングを委任する新機能の全貌
• Claude障害2026年164回：$71B投資でも解決しないAPI信頼性とSLA問題
• Claude Code・Coworkが政府解禁｜FedRAMP High対応と禁止令逆転の5ヶ月
• 企業Claude導入の壁を崩す28の接続先: Compliance APIが変えるAIガバナンス

---

本記事の情報は2026年8月7日時点のものです。セルフホスト環境は公開ベータ機能であり、フラグ名・既定値・提供範囲・既知の制約は変更される場合があります。構築前に必ず公式ドキュメントの最新版を参照してください。プラン名・提供条件・料金体系も変更される可能性があるため、契約前にAnthropicの公式情報で最新の条件をご確認ください。英語の公式ドキュメントおよび海外記事からの引用は、いずれも筆者による日本語訳です。本記事は情報提供および筆者個人の見解を目的としたものであり、特定の構成の採用・不採用や具体的なセキュリティ設定を推奨するものではありません。実際の設定は自社のリスク評価と社内規程に基づき、責任者の判断で決定してください。Claude、AnthropicはAnthropic PBCの商標です。その他の製品名・サービス名は各社の商標または登録商標です。