Claude Codeを自社環境で動かす7手順

結論：実行場所は自社でも、推論と運用責任は分けて考える

導入判断では「コードが動く場所」「モデルへ送る内容」「git認証」「host運用」を分けて確認します。

具体的な悩みは、内部serviceへ接続したい一方で、runnerを置けばすべて社内処理になるのか、誰が秘密情報とhostを守るのか説明できないことです。この記事を読むと、Anthropic-hosted環境とself-hosted環境のどちらを選び、試験runnerへ何を許可するか判断できます。

最初に行うこと：対象repository、必要な内部接続、外向き通信、運用ownerを一行ずつ書き出してください。

self-hosted environmentsの構成と提供条件

構成要素はenvironment、runner、sessionの三つです。管理者がclaude.aiのCloud environmentsでenvironmentを作り、組織が管理するLinuxまたはmacOSのhostやcontainerでrunnerを起動します。開発者がcloud sessionの開始時にそのenvironmentを選ぶと、Anthropicのcontrol plane上のqueueからrunnerがsessionをclaimし、指定repositoryをcloneしてClaude Code child processを実行します。Anthropicから社内networkへのinbound接続は不要です。

2026年8月10日時点ではTeamとEnterprise向けpublic betaで、Claude Code on the webとAllow self-hosted environmentsをOwnerまたはadminが有効化します。runnerにはClaude Code v2.1.224以降とGit 2.24以降が必要です。native Windowsはrunner hostにできないため、Windows基盤で試す場合もLinux containerを使います。Zero Data Retention有効組織では利用できず、model inferenceをBedrock、Google Cloud、Microsoft Foundry、LLM gatewayへ振り替えることもできません。

対応するのはweb、mobile、desktop、terminalのclaude --cloud、scheduled routinesなどのcloud sessionです。terminalやIDEで開いている通常のlocal sessionは元から開発者端末で動くため、self-hosted化の対象ではありません。またClaude Tag、Claude Security、Code Reviewは現時点でこのenvironmentへrouteされません。自社hostの費用に加え、Claude Code usageはAnthropic-hosted環境と同様に組織利用量へ計上されます。

Anthropic-hostedと自社基盤を比べる5軸

1. 内部network：非公開registry、database、検証serviceへsessionから到達する必要がなければ、保守不要なAnthropic-hosted環境が基本です。
2. toolchain：独自compilerや社内CLIを常備したい場合は、runner imageへ固定できます。
3. artifact：repository checkoutやbuild生成物は自社基盤へ保持できます。ただしprompt、tool resultなど推論に必要なsession contentはAnthropic APIへ送られます。
4. 隔離：productionではfreshなcontainerまたはVM、capacity 1、defaultのdrain grace 0を採用し、1 sessionごとに破棄するのが公式推奨です。
5. 運用責任：image更新、secret rotation、git credential、egress、監視、障害復旧を自組織が持ちます。「自社運用の方が安全」ではなく、管理できるcontrolと増える責任を一緒に評価します。

最初のrunnerを動かす7手順

1. 内部接続、artifact保持、独自toolchainのうち、self-hostedが必要な理由を一つに固定します。
2. OwnerまたはadminがClaude Code on the webとself-hosted environmentsを有効にします。
3. LinuxまたはmacOS hostへClaude Code v2.1.224以降とGit 2.24以降を用意し、時刻同期とoutbound HTTPSを確認します。
4. Cloud environmentsでenvironmentを作り、一度だけ表示されるenvironment secretを権限制限したfileへ保存します。
5. 書き込み可能なbase directoryを用意し、secret fileとbase directoryを指定してrunnerを起動します。
6. 管理画面がHealthyになった後、公開または最小権限でclone可能な試験repositoryのsessionをrouteします。
7. runner log、clone、tool実行、event stream、終了後のdisk破棄を確認してからproduction設計へ進みます。

environment secretはrunnerを登録し、組織メンバーのqueued sessionを受け取れる強いcredentialです。固定fleetではsession codeからsecret fileを読める前提で扱い、疑わしい実行後はrotateします。productionではsecretをuser codeが動かないorchestrator側へ置き、single-use work orderでon-demand runnerを起動する設計が優先されます。

production前のセキュリティチェックリスト

• freshなper-session containerを使う
• capacityを1にする
• 長期git keyやcloud credentialをimageへ埋め込まない
• credentialをsession単位で発行する
• metadata endpointを遮断する
• host IAMを最小権限にする
• filesystemをrunner間で共有しない
• egressをdefault-denyにする
• internal serviceを必要なhostとportだけに絞る
• repo settings guardをenforceへ設定する

特にdispatchはenvironment単位の細かなaccess controlではなく、Anthropic organizationの全memberが対象environmentへsessionを送れる設計です。hostへ「この部署しか見てはいけないcredential」を置く運用は成立しません。

repository側でも、workspace外へのwrite、env injection、sandbox無効化などを拒否するguardを使い、hookやMCPを別途reviewします。

障害時はrunnerのpollが約60秒止まるとsessionがrequeueされます。これは可用性の仕組みであって、実行中turnを必ず保存する保証ではありません。SIGTERMでdrainできる終了時間、spot instanceのretire時刻、session再開時の冪等性を試験します。

「接続できた」だけを完了にせず、隔離、credential、停止、証跡までをrelease条件にしてください。

よくある質問と次の行動

正式な構成、提供条件、network pathはAnthropic公式Self-hosted environments、初回runnerの要件と手順は公式Quickstart、productionの隔離とegressは公式Deploy guideで確認できます。

権限の基本はClaude Codeの権限設定、cloudを含む利用面の選択はClaude Codeの画面比較、企業導入の停止条件は企業導入チェックを参照してください。Miraigentの無料診断では、内部接続、runner隔離、credential、運用ownerを一枚の導入判定へ整理します。