自社のマシンを実行先にできる
Claude Code v2.1.224 で、claude self-hosted-runner が追加されました。公式の記述を引きます。
Added self-hosted environments:
claude self-hosted-runnerturns your own machines or containers into a place Claude Code web, mobile, and desktop sessions can run, on Team and Enterprise plans
自社のマシンやコンテナを、セッションが動く場所にできます。 対象は Team と Enterprise プランです。
まず壊れ方から言うと、この機能は「入れると安全になる」類のものではありません。実行場所が自社側に移るぶん、その環境の管理責任もこちらに来ます。 そこを踏まえて判断する話です。
どういうときに要るか
自分なら、次のどれかに当てはまるときだけ検討します。
| 状況 | self-hosted の必要性 |
|---|---|
| 社内ネットワーク内のリソースに届かせたい | 高い |
| 実行環境の構成を自分で決めたい | 高い |
| 契約や規程で実行場所が指定されている | 高い |
| とくに制約はないが、なんとなく不安 | 低い |
いちばん下は要りません。提供されている環境をそのまま使うほうが、手間も事故も少なく済みます。 漠然とした不安を、運用の負担で埋めることになります。
逆に上 3 つに当てはまるなら、これまでは選択肢がありませんでした。「使えない」から「使える」に変わったのが、今回の意味です。
注意
自社で動かすということは、そのマシンの用意・更新・監視が自社の仕事になるということです。動かす前に、誰が面倒を見るかを決めてください。
入れる前に決めること
運用に乗せるなら、先に決めておく項目があります。ここを決めずに動かし始めると、あとで止まります。
どのマシンで動かすか。 常時起動している必要があります。誰かの手元の端末で動かすと、その人が電源を落とした時点でセッションが止まります。
どこまでアクセスできる場所に置くか。 社内リソースに届くのが利点である以上、届く範囲がそのまま影響範囲になります。 必要な範囲だけに届く場所へ置いてください。
誰が面倒を見るか。 更新、障害時の対応、容量の管理。動き続けるものなので、担当が要ります。
壊れたときにどうするか。 自社の実行環境が落ちたら、そのセッションは動きません。提供されている環境へ戻せるようにしておくか、止まったままでよいかを決めておいてください。
この 4 つは、どれも動かす前に 10 分で決まります。決めずに動かし始めると、必要になったときに慌てて決めることになります。 そのときはたいてい、誰かが止まっている最中です。
同じ版に入った他の変更
v2.1.224 には、self-hosted 以外にも扱いやすくなる変更が入っています。運用に効きそうなものを 2 つ挙げます。
zip からプラグインを導入できるようになりました。 git や npm を経由せず、HTTPS 越しの zip から入れられます。SHA-256 での固定も指定できます。社内で配布するプラグインを、公開のレジストリに置かずに配れる形です。
サブエージェントの上限が撤廃されました。 従来はセッションあたり 200 までという制限がありましたが、これが無くなっています。長時間動かすセッションで、途中から新しいエージェントが立たなくなる問題が解消します。同時実行数と深さの制限は引き続きあります。
どちらも、長く動かす運用で効いてくる種類の変更 です。短いセッションを繰り返す使い方では、まず当たりません。
とくに zip からの導入は、社内向けの配布で使い道があります。公開の場所に置きたくないものを、社内のサーバーから配れる ためです。SHA-256 で固定しておけば、配布物がすり替わっていないことも確認できます。ここは押さえておいて損がありません。
支出上限が読めるようになった
v2.1.225 では、別の方向の改善が入っています。LLM ゲートウェイ経由で使っている場合の話です。
Added gateway spend-limit support to Claude Code's usage warning; the limit-reached message now names the cap, its reset time, and the operator's message (requires the gateway on 2.1.225)
上限に達したとき、上限額とリセット時刻と運用者からのメッセージが表示されます。 ゲートウェイ側も 2.1.225 である必要があります。
地味に見えますが、現場では効きます。従来は「止まった」ことは分かっても、理由と復帰の見込みが分かりませんでした。 上限なのか障害なのか、いつ戻るのか。そこを問い合わせで確認する時間が消えます。
運用する側から見ると、問い合わせを減らす改善 です。上限を設定している組織なら、上げておく価値があります。
ただし条件があります。ゲートウェイ側も 2.1.225 である必要があります。 手元だけ上げても表示は変わりません。ゲートウェイを運用しているのが別のチームなら、そちらに更新を依頼する話になります。
なお、運用者からのメッセージも表示されます。「上限に達したときに何をしてほしいか」を書いておける ということです。申請の窓口や、翌日まで待ってほしい旨など。ここを空にしておくと、結局問い合わせが来ます。せっかく表示されるので、埋めておいてください。
claude agents にも信頼の確認が入った
同じ版で、もう 1 点。
Added a workspace trust prompt to
claude agentsfor untrusted directories, matching the behavior ofclaude
信頼していないディレクトリで動かすとき、確認が入るようになりました。 claude 本体には既にあった挙動が、claude agents 側にも揃った形です。
エージェントを別のディレクトリで動かす運用をしているなら、そこにも同じ確認が入ります。揃っていなかったものが揃った、という種類の変更です。
この手の「片方にだけあった保護が両方に入る」修正は、地味ですが重要です。同じ道具の中に、確認が入る経路と入らない経路が混在している状態がいちばん危ういからです。 使う側は、どちらを使っているかを意識していません。
自分なら、こういう修正が入ったときは 自社の運用で該当する経路を使っていたかを確認します。 使っていたなら、それまでは確認なしで動いていたということです。過去に何かが通っていた可能性を、一度は考えておく価値があります。
FIXIT自社で動かせるようになったって、うちも使ったほうがいい？
DodaiFIXITDodai導入するなら小さく始める
要件があって入れると決めた場合の進め方です。いきなり全員分を用意しないでください。
順番としては次になります。
- 1 台用意して、1 人が使う。 動くこと、届いてほしい場所に届くことを確認する
- 同じチームの数人に広げる。 同時に使ったときの挙動を見る
- 必要なら台数を増やす。 足りなくなってからで間に合う
2 番で見るのは、同時に使ったときに詰まらないか です。1 人で試しているうちは分かりません。ここで問題が出れば、台数か構成を変える判断になります。
3 番を先回りしないでください。足りない状態は分かりますが、余っている状態は分かりません。 使われないマシンが増えるほど、更新と監視の手間だけが積み上がります。
止める判断も持っておいてください。運用の負担に見合わないと分かったら、提供されている環境に戻すのが正解です。 一度入れたから続ける、という理由で維持するものではありません。
更新の優先度
この 3 点だけを理由に、急いで上げる必要はありません。どれも「要件がある人に効く」種類の追加です。
ただし、同じ時期のリリースには権限チェックの不具合の修正が複数含まれています。そちらは性質が違います。承認したつもりの範囲を超えて動きうる類のものなので、優先度が高くなります。
結果として、最新版まで上げることになります。新機能を待って上げるのではなく、修正を当てる目的で上げてください。 経緯は Claude Code の権限バイパス修正が続いた 3 リリース に整理しています。
稟議で聞かれること
self-hosted を検討する場合、社内で聞かれる点はだいたい決まっています。先に答えを用意しておくと早く進みます。
「これで社外に出なくなるのか」。 実行場所が自社になるだけで、モデルへの通信は残ります。処理が動く場所と、モデルが応答する場所は別です。 ここを混同したまま説明すると、あとで話が崩れます。
「何台必要か」。 使う人数と同時実行の量によります。1 台から始めて、足りなければ増やす形が現実的です。
「落ちたらどうなるか」。 そのセッションは動きません。提供されている環境へ戻せる状態にしておくのが現実的な備えです。
「費用はどうなるか」。 マシンの費用が別途かかります。利用そのものの費用が減るわけではありません。
4 つ目が誤解されやすい部分です。自社で動かすと安くなる、という話ではありません。 増える方向の変更なので、要件があるから選ぶ、という順序を崩さないでください。
実行場所を選べることの意味
少し引いた話をします。実行場所を選べるようになったのは、導入の議論が変わる種類の変化です。
エンタープライズの導入では、「処理がどこで動くか」が繰り返し論点になります。規程や契約で場所が指定されている場合、技術的に選べなければそこで終わりです。
今回、選べるようになったことで、その議論に答えが出せるようになりました。 使えるかどうかの前提が変わっています。
とはいえ、選べることと選ぶべきことは別です。自社で動かす選択には、相応の運用コストがついてきます。 要件がないなら、提供されている環境のほうが安く、確実です。
全社導入の全体像は Claude Code 全社導入 完全ガイド にまとめています。実行場所の話は、その中の 1 項目として扱うのが妥当な位置づけです。
同じ時期に、プロンプトの内容を組織側で検査する仕組みも Enterprise 向けに出ています。実行場所と検査、どちらも「自社側で押さえられる範囲を広げる」方向の追加です。 そちらは Inference hooks とは にまとめました。要件から入る、という判断の仕方は同じです。
まとめ
- v2.1.224 で
claude self-hosted-runnerが追加。自社のマシンやコンテナを実行先にできる - 対象は Team と Enterprise。web・モバイル・デスクトップのセッションが動く
- 要件がないなら使わなくてよい。自社で動かすぶんの運用コストがつく
- 入れるなら、マシン・アクセス範囲・担当・障害時の扱いを先に決める
- v2.1.225 でゲートウェイの支出上限が読めるようになった。問い合わせが減る
- 更新の優先度を決めているのは、新機能ではなく同時期の権限まわりの修正
- 入れるなら 1 台 1 人から。足りなくなってから増やす。合わなければ戻す