先週、スケジュール実行しているビルド作業を一人だけで抱えるのが不安になり、もう一人に運用を手伝ってもらうことにしました。手を動かし始めてすぐ、ある事実が引っかかりました。二人目のノートパソコンからでも、リモートで私のローカルの Claude Code セッションを覗いたり操作したりできてしまう。個人開発で一台にすべてを寄せていた頃には考えなくてよかった問いが、人が一人増えた瞬間に立ち上がってきたのです。
Team/Enterprise 向けの Trusted Devices は、まさにこの隙間を埋める機能です。メンバーがローカルの Claude Code セッションをリモートで閲覧・操作する前に、その端末が管理者の登録した「信頼済み」の一台かどうかを検証します。ソロで一台をピン留めするだけなら設定は数分で終わりますが、二人以上で回し始めると、登録・失効・入れ替えという運用の面が急に重くなります。ここでは 2〜5 人規模のチームで、それを破綻させずに始めるための設計を書きます。
端末を信頼する前に、範囲を先に決める
Trusted Devices の一番の落とし穴は、機能を有効にしてから範囲を考えることです。順番が逆だと、ある日突然メンバーの手元でセッションが弾かれ、原因の切り分けに半日を溶かすことになります。有効化の前に、次の三点を紙に書き出してから進めるのを私はお勧めします。
第一に、リモート操作を許すのはどの操作までか。閲覧だけなのか、コマンド実行まで含めるのか。第二に、一人が何台まで信頼済みにできるか。母艦のデスクトップと予備のノートで二台、というように上限を決めておくと、後述するローテーションが楽になります。第三に、失効の責任者は誰か。退任・端末紛失のときに誰がボタンを押すのかが曖昧だと、信頼済みリストは古い端末の墓場になります。
この三点は、次のような最小のポリシー表にして共有フォルダに置いておくと、メンバーの認識がそろいます。
| 項目 | 初期値の例 | 決めておく理由 |
|---|---|---|
| 許可する操作 | 閲覧＋実行 | 実行まで許すなら失効の即応性が要る |
| 一人あたり上限台数 | 2台 | 入れ替え時に旧端末を必ず1台落とす前提 |
| 失効の責任者 | 管理者＋副管理者 | 単一障害点を作らない |
| 棚卸しの頻度 | 月1回 | 使っていない端末を残さない |
メンバー登録は「本人の手元」で完結させる
登録の実務でつまずきやすいのは、管理者が代理でメンバーの端末を信頼済みにしようとする流れです。デバイス検証は、その端末の手元で本人が承認して初めて意味を持ちます。管理者が肩代わりできる部分は「誰の・どの端末を・いつまで」信頼するかの承認であって、端末側の実際の検証操作ではありません。
そこで登録は、次の順序に固定すると混乱しません。管理者がメンバーを Trusted Devices の対象に含める。メンバーは自分の端末で Claude Code にサインインし、管理コンソールに表示された端末指紋（フィンガープリント）が自分の一台と一致することを本人が確認する。管理者はコンソール側で、上がってきた端末を名前付きで承認する。この「名前付き」が後から効いてきます。masaki-macbook-14 のように、人と機種が一目でわかる名前を付けておくと、半年後に棚卸しするとき、どれを落としてよいか迷いません。
無人実行の前に、信頼状態をプリフライトで確かめる
チーム運用でいちばん怖いのは、スケジュール実行が「信頼されていない端末」から静かに走り、途中で弾かれて中途半端な成果物を残すことです。無人のパイプラインは、失敗しても誰もその場にいません。だからこそ、本処理に入る前に信頼状態を確かめ、条件を満たさなければ処理そのものを始めない門番を置きます。
次は、実行前に一度だけ走らせるプリフライトの型です。ポイントは、検証に失敗したら exit 1 で明示的に止め、後続を絶対に走らせないことです。静かに続行させると、壊れた出力がキャッシュに乗って被害が広がります。
#!/usr/bin/env bash
# preflight_trusted_device.sh — 無人実行の直前に一度だけ走らせる門番
set -euo pipefail
# チームで合意した「信頼済み端末」の登録簿（管理コンソールからエクスポートして配置）
REGISTRY="${HOME}/.config/claude-team/trusted_devices.json"
# この端末の指紋（各端末で一度だけ発行し、環境変数か保護ファイルに保存）
THIS_FINGERPRINT="${CLAUDE_DEVICE_FINGERPRINT:-}"
fail() { echo "PREFLIGHT FAILED: $1" >&2; exit 1; }
[ -f "$REGISTRY" ] || fail "registry not found: $REGISTRY"
[ -n "$THIS_FINGERPRINT" ] || fail "device fingerprint is empty (env not set on this machine)"
# 登録簿に、この指紋が active 状態で載っているか
status=$(python3 - "$REGISTRY" "$THIS_FINGERPRINT" <<'PY'
import json, sys
registry, fp = sys.argv[1], sys.argv[2]
data = json.load(open(registry, encoding="utf-8"))
for d in data.get("devices", []):
if d.get("fingerprint") == fp:
print(d.get("status", "unknown")); break
else:
print("absent")
PY
)
case "$status" in
active) echo "device trusted (active). proceeding." ;;
revoked) fail "this device was revoked. stop and re-enroll." ;;
absent) fail "this device is not in the registry. do not run unattended here." ;;
*) fail "unknown device status: $status" ;;
esacこのスクリプトを本処理の先頭で ./preflight_trusted_device.sh && node run_pipeline.mjs のように連結しておけば、信頼済みでない端末からの実行は本処理に到達しません。登録簿の JSON は管理コンソールからの書き出しを正本とし、端末側で手編集しない運用にすると、改ざんの余地が減ります。なぜ端末側で持つかというと、無人実行はネットワークが不安定な時間帯にも走るからで、オンラインの問い合わせに毎回依存させると、検証サービスの一時的な不調がそのまま実行の停止に直結します。手元の登録簿で一次判定し、疑わしいときだけオンライン確認へ落とす二段構えが、私の環境では安定しました。
ローテーションとオフボーディングで漏れやすい点
端末は必ず入れ替わります。新しいノートに乗り換える、故障で修理に出す、メンバーが抜ける。このとき「新しい端末を足す」作業は誰もが忘れませんが、「古い端末を落とす」作業は驚くほど抜けます。信頼済みリストが増える一方になり、使われていない端末が静かに残り続ける。これが一番の弱点です。
漏れを防ぐには、追加と失効を対にして扱う習慣が要ります。上限を一人二台に決めておいたのは、このためです。三台目を足したくなったら、必ず一台を落とすところから始める。棚卸しの月一回は、最終アクセス日が一定期間より古い端末を候補として洗い出し、本人に確認してから失効させます。
| 場面 | やりがちな漏れ | 対処 |
|---|---|---|
| 端末の買い替え | 新端末を足すが旧端末を残す | 追加と失効を同じ作業でセットにする |
| 修理に出す | 一時的だからと放置 | 手元を離れる端末は即座に失効、戻ったら再登録 |
| メンバー退任 | アカウントは消すが端末登録が残る | 退任チェックリストに端末失効を含める |
| 指紋の再発行 | 古い指紋がregistryに残存 | 再発行時は旧指紋を revoked に更新 |
小さく始めるための判断
Trusted Devices は、全部を一度に固めようとすると腰が重くなります。私自身が二人体制で始めたときは、まず「閲覧＋実行を許す・一人二台まで・棚卸しは月一回」の最小構成だけを決め、プリフライトを一本入れて動かし始めました。範囲を広げるのは、運用が回り始めてからで十分です。App Store に出したアプリの更新作業を無人で回している私にとって、この最小構成でも十分に安心感が増しました。
次の一歩として具体的に手を付けるなら、いま無人で走っているスケジュール実行を一つ選び、その先頭にプリフライトを差し込むところからがよいと思います。門番が一枚あるだけで、「信頼されていない端末から静かに走って壊れる」という、後から気づくと厄介な失敗が構造的に消えます。人が増える前提でパイプラインを設計しておくと、実際に増えたときに慌てずに済みます。
運用の参考になれば幸いです。お読みいただきありがとうございました。