1つの契約アカウントを共有すれば席数料金を抑えられるように見えますが、実際のコストは高くなりがちです。規約違反、認証情報の拡散、操作ログの追跡不能、退職後に残る権限という4つの問題と、ユーザー席の追加購入など適切な代替策を解説します。
SaaSツールにユーザー席を1つ追加するだけでも、決して小さくない費用がかかることがあります。人数が増えるほど、その負担は目立ってきます。
そこで、1組のログイン情報を共有する方法が自然に思えることがあります。特に、たまにレポートを見るだけ、あるいは一時的に顧客向けのデータを確認するだけなら、なおさらです。しかし、この方法の代償は見過ごされがちで、利用規約、認証情報、操作ログ、メンバーの入れ替わりという複数の場所に分散しています。それぞれ別の問題を抱えています。
規約は明確：アカウント共有は禁止されるのが一般的
多くのSaaS製品は席数ベースのライセンスモデルを採用しています。複数ユーザーを明示的にサポートするエンタープライズプランやチームプランを除き、通常のプランは1人の利用を前提としていることが一般的です。利用規約では、複数人が同じログイン情報を共有する行為が明確に禁止されていることが多く、検知された場合にはプラットフォーム側がアクセスを停止または取り消すことがあります。見落とされやすい点は、こうした終了措置では通常返金がなく、支払い済みの料金がそのまま失われる可能性があることです。
もう1つ、見えにくいコストがあります。共有の目的は節約ですが、プラットフォームがアクセス人数に応じて料金を設定している事実は変わりません。節約した分は、実質的にはライセンス費用を規約違反のリスクに置き換えただけで、問題が起きない限り表面化しないのです。
パスワードを複数人が持つと、誰の操作か分からなくなる
共有するには、パスワードを複数人の間で回す必要があります。多くの場合、チャットツールやメモなどが使われ、送った内容が長く残る記録になりがちです。
問題はパスワードそのものだけではなく、そこから生じる2つの点です。1つ目は、漏えいの接点が増えることです。共有に関わる人が増えるほど、誰かが同じパスワードを別の場所で使い回していたり、端末が侵害されたりして、そのアカウントへの入口になる可能性が高まります。2つ目は、責任の所在を特定しにくくなることです。アカウントからデータがエクスポートされた、設定が変更された、送るべきでない内容が送信されたといった場合でも、後から分かるのは「そのアカウントが何をしたか」までで、「誰が操作したか」までは特定できません。顧客にデータの流れを説明する必要があるチームにとって、これは特に厄介な問題です。
操作ログが記録するのは人ではなくアカウント
SaaSの管理画面では、操作履歴は通常アカウント単位で保存されます。誰がレポートをエクスポートしたか、どの設定が変更されたか、どのデータが削除されたかといった情報も、ログ上では1つのアカウント名として残ることが一般的です。
複数人が同じアカウントを使うと、この追跡可能性が失われます。チーム内で誰が変更したのか分からなくなるだけでなく、プラットフォーム側の異常検知も同じ問題に直面します。同じアカウントが複数の都市、複数の端末、複数のネットワーク出口からログインし、同時セッションが存在すれば、異常としてフラグが立つ可能性があります。よくある対応は、強制ログアウト、一時凍結、再認証の要求です。そのツールが日常業務に欠かせない場合、勤務時間中に利用できなくなる損失は、数席分の料金を大きく上回り得ます。
プロキシを切り替えたり、ブラウザフィンガープリントを統一したりしても、検知される確率を下げられるだけで、複数人による1アカウントの共有が規約に適合するようになるわけではありません。さらに、すべてのログインを同じ環境に結び付けると、その環境に問題が起きた場合、たとえばIPがフラグ付けされたり環境が異常と判定されたりすると、全員のアクセスが同時に止まり、障害範囲がかえって広がります。
人が辞めても、権限が残る
メンバーが退職したり、外部委託の契約が終了したりしたとき、共有アカウントではアクセス権の回収を誰が担当するのか曖昧になりがちです。理由は単純で、アカウントが「みんなのもの」になっているため、明確な引き継ぎ手順が存在しないからです。
その結果、いくつかのリスクが残ります。退職者がまだパスワードを知っている可能性があり、ほかに誰が保存しているかも分かりません。以前発行されたセッションCookieがまだ有効な場合もあります。その人がアカウントを使って自動化スクリプトやAPI呼び出しを設定していた場合、そうした入口も自動では失効しません。問題に気付いた時点では、すでにデータが変更されていることもあります。
また、チームの構成が変わるたびに全員分のパスワードを変更する必要がありますが、共有運用ではそれを完全に徹底するのが難しくなります。
適切な代替策は複雑ではない
共有したくなる理由を分けて考えれば、適切な対応方法は比較的明確です。
- 長期的に利用する固定メンバーがいる場合：追加のユーザー席を購入します。これは複数人利用として公式にサポートされる唯一の方法で、ログの追跡性も個人単位に戻せます。
- チーム人数が多い場合：複数ユーザーに対応したチームプランやエンタープライズプランがあるか確認します。こうしたプランには通常、役割ごとに閲覧・変更できる範囲を制限する権限モデルがあります。
- アクセスを一元管理したい場合：SSOを使います。メンバーが退職したら一括で無効化でき、権限回収を誰かの記憶に頼る必要がありません。
- 顧客に結果を一時的に見せるだけの場合：レポートをエクスポートするか、読み取り専用の共有リンクを生成し、顧客がアカウントにログインしなくてもデータを確認できるようにします。
注意したいのは、「アカウント共有」と「複数アカウント」は別の話だということです。前者は複数人が1組の認証情報を使うこと、後者は各自が自分の認証情報を持ちながら、同じ端末上で互いに干渉せず操作することです。後者そのものは適切な運用になり得ます。たとえば、チームが各メンバー分の席を購入し、それぞれが自分のアカウントを持っている場合、同じブラウザ内ではCookieやセッションが上書きし合うことがあります。アカウントごとに独立したブラウザ環境を用意すれば、セッション、キャッシュ、データを分離できます。PurpleMarkが提供するのは、この種の環境分離機能です。複数の正規アカウントを同じ端末で安定して共存させる問題を解決するものであり、複数人が1組のログイン情報を共有する行為が利用規約に反するという点は変わりません。
まず計算してから選ぶ
アカウント共有の本質は、少しの席数料金を節約する代わりに規約・コンプライアンス上のリスクを引き受けることです。たまに、短時間、1人だけで使う状況ではしばらく問題が見えないかもしれませんが、チーム規模では、アクセス停止やデータ事故が起きた際の損失は節約額を大きく上回ります。
まずライセンス費用を計算し、そのうえで方法を選びましょう。席を買えるなら席を購入し、データをエクスポートできるならエクスポートするのが基本です。
具体的なライセンス規則は、各製品の公式利用規約を確認してください。
