「モデルはクラウドの最新を使いたい。でも、コードとシークレットは自社ネットワークの外に出せない」——この二律背反が、規制業種やセキュリティ要件の厳しい企業がコーディングエージェントの導入を見送ってきた最大の理由でした。homula がエンタープライズのエージェント導入を支援するなかでも、「実行の場所」は毎回論点になります。
2026年8月、Anthropic はこの制約に正面から答える機能を出しました。Claude Code のセッションを自社インフラ上で実行する「セルフホスト環境（self-hosted environments）」を公開ベータで解禁したのです（Anthropic 公式ブログ）。本稿では、何が変わったのか、なぜ企業に効くのか、そして見落とされがちな「自前で回すことの運用コスト」を、実務の判断軸として整理します。
何が変わったのか——実行のプレーンが「自社側」に移る
これまで Claude Code のバックグラウンド実行（クラウドで走るセッション）は、Anthropic の管理するサーバー上で完結していました。便利な反面、コード・シークレット・ビルド成果物が一度は社外の環境に置かれることを意味し、データ持ち出しを禁じる企業では使えませんでした。
新しいセルフホスト環境は、この実行の場所を丸ごと自社側に引き込みます。要点は次のとおりです（Anthropic 公式ブログ、および Claude Code チェンジログ / v2.1.224 に基づく）。
claude self-hosted-runnerコマンドで、自社のマシンやコンテナを Claude Code の実行レイヤーに変える。- 組織は claude.ai の管理設定で**「環境（environment）」を名前付きで作成し、そこに複数のランナー**を束ねる。ランナーは、自社ネットワーク内のホスト上で常駐する長寿命プロセスで、セルフホスト型の CI ランナーと同じ考え方で動く。
- ランナーは固定（fixed）でもオンデマンド（on-demand）でも構成できる。オンデマンドの場合は、必要に応じてランナーを起動するオーケストレーターを自社で運用する。
- 対象は Claude Team / Enterprise プラン。**既定では無効（off by default）**で、管理者が明示的に有効化する。
一言でいえば、「頭脳（モデル推論）はクラウド、実行は自社ネットワークの中」という分離を、正式な製品機能として選べるようになった、ということです。homula ではこの発想を以前から「エージェントの責任分界点」として論じてきましたが、今回はそれが具体的な運用形態に落ちた格好です。
なぜエンタープライズに効くのか——データが「境界」を越えない
セルフホスト実行の本質的な価値は、パフォーマンスやコストではなく、信頼境界（trust boundary）の設計にあります。コード、シークレット、ビルド成果物が自社ネットワークの中に留まるため、これまで「クラウド実行が使えない」と判断していた企業が、初めてバックグラウンドのコーディングエージェントを俎上に載せられます。
| 観点 | クラウド背景実行（従来） | セルフホスト実行（新） |
|---|---|---|
| コード・シークレットの所在 | Anthropic 管理サーバー上に一時的に展開 | 自社ネットワーク内に留まる |
| 内部リソースへの到達 | 制約あり | 社内ネットワーク・内部ツールに直接到達可 |
| コンプライアンス適合 | データ持ち出し禁止の企業は不可 | 域内完結を要件とする企業でも検討可 |
| 運用の主体 | Anthropic 側 | 自社（ランナー/オーケストレーター） |
| 対象プラン | 標準 | Team / Enterprise（既定オフ） |
この構図は、homula が ソブリンAI（主権AI） の文脈で扱ってきた「データを国外・社外に出せない企業の域内完結スタック」と地続きです。エージェントの実行を自社に寄せることは、単なる技術選択ではなく、どこまでを自社の統制下に置くかというガバナンス上の意思決定になります。
「実行を自社に引き込む」ことは、内部ネットワークへの到達性という副次効果ももたらします。エージェントが社内の内部ツールやプライベートな依存関係に直接アクセスできる一方で、その到達範囲は新たな管理対象——つまり最小権限と監査の対象になります。
見落とされがちな論点——「自前で回す」には運用の実体がある
ここが本稿でもっとも強調したい点です。セルフホスト実行は「オンにすれば終わり」ではありません。Anthropic 自身が、これは一度きりのセットアップではなく継続的なエンジニアリングを要すると明言しています。
同社は、この環境の構築・運用にプラットフォーム/開発者体験（DevEx）/開発生産性チームを割り当てることを推奨し、責任範囲として次を挙げています。
- ランナーイメージの構築と保守（実行環境の中身を自社で定義・維持する）
- ランナーの更新（バージョン追随、セキュリティパッチ）
- オンデマンド構成の場合のオーケストレーターの運用
「クラウドが使えないから自社実行にする」という動機だけで踏み込むと、CI ランナー群を自前で運用するのと同等の負荷を見誤ります。ランナーの可用性・更新・権限・監査は、そのまま自社の運用チームの仕事になります。導入判断では、機能の有無だけでなく**運用体力（誰が回し続けるのか）**を必ず織り込むべきです。
つまりセルフホスト実行は、コンプライアンス上の制約を解く鍵であると同時に、運用責任をベンダーから自社へ移す取引でもあります。この非対称性を理解しないまま導入すると、「動かせるが、誰も面倒を見ていない実行基盤」を抱えることになりかねません。
どの企業が自社実行に踏み込むべきか——3つの判断軸
すべての企業がセルフホストにすべきわけではありません。次の3軸で、自社にとって合理的かを見極めるのが実務的です。
- データ分類と規制要件：ソースコード・シークレット・成果物が「社外に出せない」明確な規約や規制があるか。あるなら、実行の域内完結は要件そのものであり、運用コストは支払う価値がある。
- 内部リソースへの到達必要性：エージェントに社内ネットワーク内のツールやプライベートな依存へ到達させたいか。到達が必須なら自社実行が近道になる。
- 運用体力：ランナーイメージ・更新・オーケストレーターを継続的に見るチームがあるか。ないなら、まずは限定的な固定ランナーで小さく始め、統制設計を固めてから拡げる。
3軸のいずれも「弱い」なら、無理に自社実行へ踏み込まず、まずは適用範囲を絞った検証から入るのが堅実です。逆に規制要件が強く運用体力もあるなら、これは長く待たれていた選択肢です。
homula の観点——「実行を自社に」を、統制ごと設計する
homula は、エンタープライズ企業向けの AIエージェント・インテグレーターとして、戦略策定 → PoC（最短5日）→ 実装 → 運用 → 内製化までを一気通貫で支援しています。今回のようなセルフホスト実行は、まさに「機能を入れる」ことと「回し続ける」ことの間に落ちる領域で、伴走の価値が出ます。
- 実行の場所の設計：どこまでを自社側に引き込み、どこをクラウドに残すか。データ分類と規制要件から逆算して、実行プレーンの分界点を決める。
- 統制の同時設計：実行を自社に寄せても、承認・監査・権限が抜けては意味がありません。Agens Control は、承認フロー・DLP・5年分の監査ログ・RBAC を提供し、「誰が・どのエージェントに・何を許すか」を実行基盤とセットで統べます。エージェントの到達範囲が広がるほど、最小権限と監査の設計が効いてきます。
- 運用の内製化：ランナーの更新やオーケストレーター運用を、外部依存のまま放置しない。n8n / Dify / LangGraph を含む自社スタックの運用ノウハウを、伴走のなかで社内へ移していきます。
セルフホスト実行は「クラウドか自社か」の二者択一を迫るものではなく、実行のどの部分をどこに置くかを、統制ごと設計する問題です。homula はその設計と運用の定着までを支援します。
まとめ
- Anthropic は2026年8月、Claude Code のセッションを自社インフラで実行するセルフホスト環境を公開ベータで解禁した（Team / Enterprise、既定オフ）。
- 価値の本質は速度でもコストでもなく、コード・シークレット・成果物が信頼境界を越えないこと。データ持ち出しを禁じる企業に、初めて現実的な選択肢が生まれた。
- ただしこれは運用責任をベンダーから自社へ移す取引でもある。ランナーイメージの保守・更新・オーケストレーター運用を継続的に見るチームが要る。
- 判断は「データ分類・規制」「内部到達の必要性」「運用体力」の3軸で。強い要件と運用体力があるなら、待たれていた選択肢だ。
実行を自社に引き込むかどうかは、機能の話である前に「統制と運用をどこまで自社で持つか」の意思決定です。次の一歩は、自社のデータ分類と要件から実行プレーンの分界点を描くことから始めましょう。