Claude Codeが自社サーバで動く|EC業務データを外に出さない3条件

Anthropicが2026年8月6日、Claude Codeのセッションを自社サーバで実行するセルフホスト環境をベータ公開。Team・Enterprise限定の3条件と、EC事業者がいま整理すべきデータの置き場所を解説します。

投稿日: カテゴリー AIニュース

Claude Code のセッションが、自社サーバ上で動かせるようになりました。

Anthropic は2026年8月6日、Claude Code のクラウドセッションを自社の管理するサーバ上で実行する「セルフホスト環境」をパブリックベータとして公開しました。対象は Claude Team と Enterprise を契約する組織に限られ、初期状態ではオフになっています。AIエージェントに社内のデータを触らせるとき、どこで動かすかを自分で選べるようになったという意味で、EC事業者にとっても他人事ではない発表です。本記事は、EC支援19年・5,000社超の実績を持ち、AI導入支援は2023年から提供する株式会社オルセル(うるチカラ運営)が解説します。

セルフホスト環境とは|Claude Code 2.1.224で追加された仕組み

セルフホスト環境とは、Claude Code のクラウドセッションを自社が用意したサーバ上で実行する仕組みのことです。Unite.AI が伝えたAnthropic の発表によると、Web・モバイル・デスクトップ・ターミナル・定期実行のいずれから始めたセッションでも、社内ネットワークの内側にある機材の上で処理が走ります。公式の変更履歴でも、2026年8月7日公開のバージョン2.1.224に claude self-hosted-runner コマンドが追加されたことが記載されています。

重要なのは、何が社内に残り、何が外に出るかが明確に線引きされている点です。リポジトリのチェックアウト、ビルド成果物、シークレット、セッションが作成・変更したファイルは、自社が用意したマシン上にとどまります。一方で、会話そのもの、つまりプロンプトと応答とツールの実行結果は推論のために Anthropic のAPIへ送られ、セッションの記録は Anthropic 側に保存されます。すべてが社内で完結するわけではないという点は、取り違えると事故につながります。

プレビューに参加した組織が導入した理由として挙がっているのが3つの条件です。第一に、社内サービスやデータベース、社内のレジストリへ、それらを公開インターネットに晒すことなく到達できること。第二に、コンパイラやSDK、社内向けのコマンドラインツールを事前に入れておけるため、セッションが始まった時点ですぐ作業できること。第三に、ソースコードとビルド成果物が社内に残るため、コンプライアンス要件を満たしやすいことです。導入企業である Faire でシニアエンジニアリングマネージャーを務める George Jacob は発表の中で、「セルフホスト環境によって、セキュリティと運用の統制を保ったまま Claude Code を既存の開発ワークフローに組み込めます」と述べています。

技術的な作りも公開されています。ランナーと呼ばれる常駐プロセスを社内のホストに置き、常に一定数を動かす固定モードと、セッションが届いたときだけ起動する需要対応モードのどちらかを選びます。1台のランナーは同時に1ユーザーしか担当せず、最初のセッションを受け取った時点でそのユーザーのアカウントに紐づくため、チェックアウトしたコードが他の利用者と混ざりません。ランナーが約60秒ポーリングを止めると、そのセッションは別のランナーへ回されます。通信はすべて api.anthropic.com への外向きHTTPSで、Anthropic 側から社内ネットワークへ接続してくることはありません。

制約も小さくありません。オーナーか管理者が管理画面で有効化する必要があり、ゼロデータ保持の設定を使っている組織は利用できません。推論先は Anthropic 固定で、Amazon Bedrock や Google Cloud の Agent Platform、Microsoft Foundry、社内のLLMゲートウェイ経由に振り替えることはできません。リポジトリの取得元は GitHub に限られます。課金はホスト型と変わらず、増えるのは運用の手間のほうです。

日本のEC事業者にとっての論点|対象は限られても判断軸は共通

結論から言えば、今回の機能そのものを今すぐ使う日本のEC事業者は多くありません。Team と Enterprise の契約が前提で、ランナーのイメージ構築と運用を担う担当者も必要になるため、実質的に情報システム部門を持つ規模の会社向けの機能です。それでも押さえておく価値があるのは、ここで示された線引きが、規模を問わず同じ形で問われるからです。

いま現場で増えているのは、楽天市場のRMSから落とした受注データ、Amazonのビジネスレポート、Shopifyの注文エクスポートをAIに処理させる自動化です。これらには氏名や住所、電話番号といった個人データが含まれます。ところが、その処理スクリプトが担当者個人のパソコンで動いているのか、共有サーバで動いているのか、誰のアカウント権限で動いているのかを整理できていない現場は少なくありません。今回の発表が明示したのは、モデルに何を送るかという問題と、コードやファイルをどこに置くかという問題は別だ、という切り分けです。

1台のランナーが1ユーザーにひもづくという設計も示唆的です。社内で共通の自動化サーバを1台立てると、誰の権限で何のデータに触ったのかが混ざりやすくなります。AIエージェントに任せる範囲が広がるほど、この履歴の分離が効いてきます。うるチカラでもAIエージェントのセキュリティ認証情報の取り扱いを扱ってきましたが、置き場所と権限の設計は後回しにされがちな領域です。

なお、個人データを国外の事業者へ渡す場合の扱いは、個人情報保護法上の第三者提供や越境移転の要件に関わります。契約形態や利用するプランによって整理が変わるため、実際の運用に載せる前に法務での確認が必要です(要確認)。

初動アクション|自社の自動化を棚卸しする3つの視点

まず取り組むべきは、契約プランの検討ではなく棚卸しです。いま社内で動いているAI関連の自動化について、どのスクリプトがどのデータに触れ、どこで実行されているかを一覧にしてください。担当者のパソコン上で動いているものが混じっていれば、その担当者が離席や退職をした瞬間に業務が止まります。

次に、送るデータと置くデータを分けて記録します。AIに読ませる必要がある情報と、単にファイルとして保管されているだけの情報は別物です。受注CSV全件をそのまま渡す必要があるのか、注文IDと数量だけで足りるのかを見直すだけでも、外に出る情報量は変わります。Claude CodeによるEC業務の自動化を進めている場合は、ここを最初に決めておくと後の設計が楽になります。

最後に、権限と実行アカウントを分離します。人間の担当者アカウントで自動処理を動かし続けると、権限の棚卸しができません。自動化専用のアカウントを用意し、必要最小限の権限だけを与えるのが基本です。今回の発表は、Anthropic 側が組織向けにこの分離を製品として用意し始めた、という読み方ができます。

まとめ

Anthropic は2026年8月、Claude Code のセッションを自社サーバ上で実行できるセルフホスト環境をパブリックベータで公開しました。対象は Team と Enterprise に限られ、推論は Anthropic 側で行われる点は変わりません。日本のEC事業者にとっての実利は、機能そのものより「AIに送る情報」と「社内に置くファイル」を分けて設計するという考え方にあります。まずは自動化の棚卸しから着手するのが現実的です。

参考文献

※うるチカラでは、生成AIの導入支援から運用最適化まで、貴社のEC事業に合わせたカスタマイズ提案を行っています。無料相談(30分)も実施中ですので、お気軽にお問い合わせください。
https://uruchikara.jp/contact/

引用元: Unite.AI


投稿者: 齋藤竹紘

株式会社オルセル代表取締役 / うるチカラ編集長。19年・5,000社以上のEC支援実績を持ち、楽天市場・Amazon・Yahoo!ショッピング・Shopify・Shopee越境ECの実装ノウハウを保有。AI×ECに関する書籍を3冊執筆。「現場で使えるAI実装」を一次情報として発信しています。

お問い合わせ