代理店が「サブアカウント」を検索するのは、1つの親ログインの下に複数のクライアントアカウントを保持する仕組みを指す言葉として、ほとんどのツールがこの言葉を使っているからだ。何かを構築する前に、それがShifterにどう対応するかを正確に把握しておく価値がある。正しい構造はそこにかかっているからだ。
Shifterでは、2つの仕組みがその役割を分担している。ワークスペースは独立した空間で、独自のプラン、ウォレット、請求書、チームを持ち、同じ人物が複数のワークスペースに所属し、サイドバーから切り替えることができる。サブアカウントはプロキシのユーザー名に付けるラベルで、1つのプランのトラフィックをクライアントごとに分割し、パネルとAPIで別々に報告される(2026年10月に導入)。使用量はプランごと、そしてその中のサブアカウントごとに追跡される。これらの事実を構造に組み込めば、あとは自然に決まっていく。
サブアカウントが満たすべき要件
専門用語を取り払うと、代理店がクライアント用サブアカウントに求めるものは4つある。
| 要件 | 意味するもの | Shifterでの提供方法 |
|---|---|---|
| 分離 | あるクライアントのトラフィックと予算が他のクライアントと混ざらないこと | プランはワークスペースをまたがない |
| 帰属 | 各クライアントのコストを明確に示せること | 使用量はプランごと、サブアカウントごとに報告される |
| アクセス制御 | 適切な人が適切なものを見られること | ワークスペースごとのViewer、Billing、Adminロール |
| スムーズなオフボーディング | 他の誰にも影響を与えずクライアントが離脱できること | メンバーの削除、クライアントのプランの終了 |
このガイドの残りの部分は、これら4つすべてを同時に満たすようにワークスペースとプランを配置する方法を選ぶことだ。
うまくいく2つの構造
クライアント所有のワークスペース
各クライアントが自身のワークスペースを所有する。クライアントがウォレットに資金を入れ、請求書を受け取る。代理店のアカウント担当者は各クライアントのワークスペースにAdminとして招待され、そこから収集業務を行う。
クライアントが自身の請求関係を持つことを望む場合、これが最もクリーンな構成だ。分離は絶対的であり、帰属は各クライアントの請求書がそれぞれ独立しているため手間がかからず、オフボーディングはクライアントが自分のワークスペースから代理店を削除するだけで済む。代理店の1つのログインで、ワークスペース切り替え機能を使ってすべてのクライアントにアクセスできる。
代理店所有のワークスペース、クライアントごとに1プラン
代理店が1つのワークスペースを所有し、その中でクライアントごとに個別のプランを購入し、各プランの使用量に基づいてクライアントに請求する。
これは、収集業務をリテーナーの一部として再販する代理店に適している。帰属が成立するのは、ルールが厳格に守られる場合に限られる。1クライアント、1プラン、共有なし、あるいは共有プランの場合は1クライアント、1サブアカウントだ。この構造を選ぶ前に知っておくべき2つの結果がある。
- ウォレットはワークスペース単位で管理され、どのプランの超過分もそのウォレットから賄われる。ワークスペース内のすべてのプランが同じ資金源から引き出されるため、あるクライアントの急増が別のクライアントが頼りにしている余裕を消費してしまうことがある。プランごとの超過分を注意深く監視するか、大量利用のクライアントには専用のワークスペースを与えること。
- ワークスペース内のすべてのものは、そのメンバーに見える。共有の代理店ワークスペースにクライアントの担当者を招待してはならない。たとえViewerとしてでも、他のすべてのクライアントのプランと請求書が見えてしまうからだ。
多くの代理店は結局ハイブリッド型に落ち着く。独自の請求を望む大口アカウントにはクライアント所有のワークスペースを、リテーナーで請求する小規模クライアントにはそのプランを保持する1つの代理店ワークスペースを使う形だ。
設定方法
どちらの構造でも仕組みは同じだ。
- 管理したいワークスペースで、パネルのサイドバーからチームページを開く。
- メールアドレスで招待し、ロールを選ぶ。 既存のShifterユーザーは次回サインイン時にワンクリックでJoinでき、自分のアカウントをそのまま使い続けられる。新しいメールアドレスの場合は、パスワード不要のマジックリンクによる簡単なサインアップになる。
- サイドバーのドロップダウンからワークスペースを切り替える。これは2つ以上のワークスペースに所属すると表示される。プラン、ウォレット、請求書、チームなど、画面上のすべてがそれに応じて切り替わる。
- 各クライアントのプランは、そのクライアントが属するワークスペースで購入する。 プランは後からワークスペース間を移動できないため、誤ったワークスペースで購入すると買い直すことになる。
各ワークスペースには10席のソフトな上限がある。大口クライアントのためにそれ以上必要な場合は、厳密な制限ではなくサポートとの相談事項となる。クライアントとの関係性が変化した場合、ワークスペースの所有権を依頼によって移管することもできる。
この機能自体はTeam Workspacesの紹介で説明されている。
ロールの選び方
各メンバーに必要最小限のロールを与えること。
| ロール | できること | 付与対象 |
|---|---|---|
| Viewer | プラン、トラフィック、請求書の閲覧、カタログの閲覧 | 使用状況を確認したいクライアントの担当者、自分のワークスペース内のみ |
| Billing | Viewerができることに加え、ウォレットへの入金、請求書の支払い、プランの購入・アップグレード | カードを保持している側の人物、どちらの側でも |
| Admin | Billingができることに加え、プランとチームの管理 | 収集業務を統括する代理店のアカウント担当者 |
ロールはワークスペースごとに設定されるもので、全体共通ではない。同じ人物が、あるクライアントのワークスペースではAdmin、別のクライアントのワークスペースではViewerということもあり得る。常に適用されるのは、アクティブなワークスペースでのロールだ。
クライアントごとの使用量の追跡
各プランには、パネル内のダッシュボード概要とプラン自体のページの両方にリアルタイムの使用状況ビューがあり、毎分更新される。サイクル内の残り帯域幅、日次消費トレンド、ホスト名別の上位トラフィック先が表示される。
これら3つがそろえば、クライアント帰属を適切に運用するには十分だ。
残り帯域幅は、クライアントがサイクル内の割当量に収まる見込みかどうかを示す。
日次トレンドは、消費量がいつ変化したかを示す。これは通常、新しいジョブの開始、クローラーの暴走、あるいはクライアントが申告せずに対象範囲を拡大したことを意味する。
ホスト名別の上位トラフィック先は、見過ごされがちだが重要な指標だ。これにより、各クライアントのプランが実際にそのクライアントの対象に向かっているかを確認できる。あるプランの上位トラフィック先が別のクライアントの競合先に属している場合、どこかのジョブで誤った認証情報が使われているということだ。
1つのプランをクライアント間で分割するには、各クライアントにサブアカウントを割り当てる。そのクライアントのジョブでユーザー名の直後に-subaccount-CLIENTを追加すると、パネルと使用量APIがそれぞれ別々に報告する。ラベルなしで送信されたトラフィックは後から分割できないため、共有プランではすべてのジョブにラベルを付けること。
月次運用ルーチン
帰属管理は一度きりのレポートではなく、習慣として行うものだ。
- 各サイクルの開始時に、各プランの開始時割当量とサイクルの日程を記録する。
- 毎週、各クライアントの消費量を想定消費率と比較し、月末使用量を「消費した帯域幅÷経過日数×サイクル日数」として再予測する。
- トレンドが急変したときは、クライアントのスコープが拡大したと決めつける前に、上位トラフィック先を確認する。
- 割当量が尽きる前に、超過分をウォレットから賄うか、ジョブを一時停止するかをクライアントごとに判断する。レジデンシャルプランの超過分は、プラン固有のGB単価でウォレットから請求される。
- クライアントが離脱したときは、そのメンバーを削除し、すべてのジョブからそのプランの認証情報を削除し、プランを終了する。
毎週の確認の背景にある予測方法は、レジデンシャルプロキシの帯域幅予測にある。
認証情報は分離のもう半分
ワークスペースはプランを分離する。自分たちのシステムは認証情報を分離しなければならない。
各プランには独自の認証情報がある。それをクライアントごとにシークレットマネージャーに保管し、各クライアントのジョブにはそのクライアントのプランのみを使わせ、何かを急いで片付けるためにあるクライアントの認証情報を別のクライアントのジョブにコピーすることは絶対に避けること。それが帰属管理が静かに崩れる原因になる。プロキシの完全な接続文字列をログに記録してはならない。これはログ集約システムへ認証情報が漏洩する最も一般的な経路だ。
セッションIDは自由に命名して構わない。クライアントコードを接頭辞として付ける(sid-acme-serp-01)ことにコストはかからず、自分たちのログを読みやすくする。パネルはセッションID別の使用量の内訳を表示しない。それはサブアカウントの役割だ。
FAQ
Shifterにはプラン内のサブユーザーはありますか?
プラン内に個別のログインは存在しないが、サブアカウントはプランのトラフィックをクライアントごとに分割する仕組みだ。プロキシのユーザー名に付けるラベルで、パネルとAPIが別々に報告する。アクセスはワークスペースごとに3つのロールで管理され、クライアント間の完全な分離は、別々のプラン、必要に応じて別々のワークスペースによって実現される。
1つの代理店ログインで何人のクライアントを管理できますか?
1つのログインは必要なだけ多くのワークスペースに所属でき、サイドバーから切り替えられる。10席のソフトな上限はログインごとではなく、ワークスペースごとに適用される。
クライアントは他のクライアントを見ることができますか?
ワークスペースをまたいでは見えない。ただし1つのワークスペース内では、すべてのメンバーがすべてを見ることができる。だからこそ、クライアントの担当者は自分自身のワークスペースにのみ招待すべきだ。
プランを別のクライアントに移すことはできますか?
プランは購入されたワークスペースにとどまる。各クライアントのプランは、最初からそのクライアントのワークスペースで購入すること。
まとめ
Shifterでは、ワークスペースがアクセスと請求を分離し、サブアカウントがプラン内のトラフィックを分割する。クライアントごとに独自のプラン、または独自のサブアカウントを与え、クライアントが自身の請求を保持する場合はクライアント所有のワークスペースを、代理店が再販する場合は共有の代理店ワークスペースを選び、クライアントの担当者を共有ワークスペースに入れず、請求時ではなく毎週クライアントごとの使用量を確認すること。
このように構造化すれば、分離、帰属、アクセス制御、オフボーディングはすべて自然と実現される。この製品は代理店向けレジデンシャルプロキシページにあり、料金は料金ページに掲載されている。