エージェンシーは「サブアカウント」という言葉で検索する。ほとんどのツールが、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でそれぞれ別々に報告される。ラベルなしで送られたトラフィックは、後から分割することができないため、共有プランではすべてのジョブにラベルを付けること。
あるクライアント向けのリクエストで、ラベルの後にターゲティングとセッションを指定する例は次のようになる。
curl -x customer-USERNAME-subaccount-client_a-country-us-sid-abc123-ttl-600:PASSWORD@p.shifter.io:443 \
http://ip-info.com/json同じクライアントの10月分のトラフィックを、APIで取得する例は次の通りである。
curl "https://shifter.io/api/v1/memberships/68057/subaccounts/client_a/usage?start=2026-10-01&end=2026-11-01&api_token=YOUR_API_TOKEN"サブアカウント名は、英字、数字、アンダースコアのみで1~16文字とし、ハイフンは使用できず、大文字小文字は区別される。事前の設定は不要で、サブアカウントは最初のリクエストから数分後に表示される。サブアカウントはトラフィックの追跡のみを行い、プランの帯域を共有し、クライアントごとの上限は設定されない。
月次の運用ルーティン
帰属管理は一度実行するレポートではなく、習慣である。
- 各サイクルの開始時に、各プランの開始時点の割り当てとサイクルの期日を記録する。
- 週次で、各クライアントの消費量を想定ペースと比較し、月末の使用量予測を「消費済み帯域 ÷ 経過日数 × サイクル日数」として再計算する。
- トレンドが急上昇したときは、クライアントのスコープが拡大したと決めつける前に、上位の送信先を確認する。
- 割り当てが尽きる前に、超過分をウォレットから賄うか、ジョブを一時停止するかをクライアントごとに判断する。レジデンシャルプランの超過分は、そのプラン自体のGB単価でウォレットから請求される。
- クライアントが離脱したときは、その関係者を削除し、すべてのジョブからそのプランの認証情報を外し、プランを解約する。
週次チェックの背後にある予測手法については、レジデンシャルプロキシの帯域予測を参照のこと。
認証情報は分離のもう半分
ワークスペースはプランを分離する。認証情報を分離するのは、自分自身のシステムの役目である。
各プランには独自の認証情報がある。それをクライアントごとにシークレットマネージャーに保存し、各クライアントのジョブにはそのクライアントのプランのみを使わせ、作業を手早く済ませるためにあるクライアントの認証情報を別のクライアントのジョブにコピーすることは絶対にしないこと。それが帰属を静かに崩す原因になる。プロキシの接続文字列全体をログに記録しないこと。これは認証情報がログ集約ツールに漏れる最も一般的な原因である。
セッションIDの命名は自由である。クライアントコードを接頭辞として付けること、例えばsid-acme-serp-01、には何のコストもかからず、自分のログを読みやすくする。パネルはセッションID別に使用量を分けて表示しないが、それこそがサブアカウントの役割である。
FAQ
Shifterには、プラン内にサブユーザーがありますか?
プラン内に個別のログインは存在しないが、サブアカウントはプランのトラフィックをクライアントごとに分割する。これはプロキシのユーザー名に含まれるラベルで、パネルとAPIで別々に報告される。アクセスは3つのロールを使ってワークスペースごとに管理され、クライアント間の完全な分離は、別々のプラン、そして必要に応じて別々のワークスペースによって実現される。
1つのエージェンシーログインで管理できるクライアント数は?
1つのログインは、必要な数だけワークスペースに所属でき、サイドバーから切り替えることができる。10席のソフトな上限は、ログインごとではなくワークスペースごとに適用される。
クライアントは、こちらの他のクライアントを見ることができますか?
ワークスペースをまたいでは見えない。1つのワークスペース内では、すべてのメンバーがすべてを見られるため、クライアントの担当者は必ず自分自身のワークスペースにのみ招待すべきである。
プランをあるクライアントから別のクライアントへ移動できますか?
プランは購入されたワークスペースにとどまる。最初から各クライアントのプランは、そのクライアントのワークスペースで購入すること。
まとめ
Shifterでは、ワークスペースがアクセスと請求を分離し、サブアカウントがプラン内のトラフィックを分割する。すべてのクライアントに、それぞれ専用のプランか専用のサブアカウントを割り当て、クライアントが自分自身の請求を持つ場合はクライアント所有のワークスペースを、再販する場合は共有のエージェンシーワークスペースを選び、クライアントの担当者を共有ワークスペースから除外し、請求時ではなく毎週クライアントごとの使用量を確認すること。
このように構成すれば、分離、帰属、アクセス、オフボーディングのすべてが自然に満たされる。製品についてはエージェンシー向けレジデンシャルプロキシページを、料金については料金ページを参照のこと。