結論から言う。会社のクラウド会計・グループウェア・名刺管理・ECサイトなどのSaaSが、先代個人のGmailやキャリアメールで契約されたままになっているのは珍しいことではない。これは違法でも特別に非常識でもないが、承継後は「管理者権限」を会社側に移す作業を、遅くとも1年以内には済ませておくべき技術的負債だ。手順は大きく分けて、(1) 契約実態の棚卸し、(2) サービスごとの管理者権限移譲、(3) 支払い方法の会社名義への一本化、(4) 台帳化して再発防止、の4段階になる。この記事では、何から手をつければよいかを、つまずきやすい順に説明する。
こんな人に向けて書いている。先代の代からある会社で、クラウド会計や顧客管理、グループウェアが「よくわからないけど動いている」状態のまま社長を継いだ方。ログイン画面を見ると管理者アドレスが「@gmail.com」の個人アドレスだったり、退職した経理担当者の社用メールがそのまま管理者権限を持ち続けていたりする方。あるいは、先代自身がまだ現役だが、いつ引退してもおかしくない年齢で、そのアカウントに会社の全データが紐づいている方。こうした状態を放置すると、契約者本人が退職・引退・体調不良になった瞬間に、会社側の誰もパスワードをリセットできず、請求データにも顧客データにもアクセスできなくなるという事態につながる。まずは何が起きているのかを整理するところから始めよう。
なぜ「個人アカウント」でのクラウド契約が生まれるのか
多くの場合、原因は悪意ではなく「立ち上げの手軽さ」の積み重ねだ。独立行政法人情報処理推進機構（IPA）が2026年6月に公表した「中小企業のためのクラウドサービス安全利用の手引き」は、クラウド会計・給与計算・顧客管理・名刺管理・グループウェア・電子メールといった業務アプリケーションが中小企業にとって身近なクラウドサービス（SaaS）の典型例だとしたうえで、利用者が「誰が使うのか、どう管理するか」「誰が責任を持つか」を運用段階で確認すべき項目として明示している（IPA「中小企業のためのクラウドサービス安全利用の手引き」（2026年6月））。裏を返せば、この「誰が管理するか」を最初に決めないまま契約してしまう会社が多いからこそ、公的機関がチェックシートという形でわざわざ明文化しているということでもある。
先代がクラウド会計サービスを導入した当時のことを想像してほしい。忙しい合間を縫って、税理士に勧められるまま、あるいは経理担当者に「これ使って」と言われるまま、手元にあった自分のスマホやパソコンのメールアドレスでアカウントを作った。法人用に別のメールアドレスを取得する手間や、社内で誰を管理者にするかを議論する時間は省略された。動き出してしまえばそれで日々の業務は回るし、わざわざ後から名義を付け替える必要性を感じる場面もない。こうして「会社の基幹データを扱うサービスの管理者権限が、特定の個人のメールアドレスに紐づいたまま」という状態が、何年も気づかれずに続いていく。
筆者が見聞きする範囲では、パターンは大きく3つに分かれる。1つ目は「先代個人のアカウントで契約」パターン。クラウド会計・請求書発行・ECサイトの管理画面など、先代が法人化前の個人事業主時代、あるいは法人化後もそのまま自分名義で契約を続けているケース。2つ目は「特定の担当者個人のアカウントで契約」パターン。経理や総務の担当者が自分のメールアドレスで法人用SaaSのアカウントを作り、会社の経費で支払いながらも管理者権限は個人名義のまま何年も運用してしまうケース。3つ目は「複数のサービスがバラバラの名義で乱立」パターン。会計はA氏、顧客管理はB氏、グループウェアはC氏というように、サービスごとに異なる個人アカウントが管理者になっており、誰か一人が抜けただけでは全体像が誰にも分からないケースだ。いずれも「動いているから後回し」という判断の積み重ねであり、承継のタイミングまで顕在化しないことが多い。
放置すると何が起きるか。3つの具体的なリスク
「動いているなら今は困っていない」と感じるかもしれないが、放置には具体的なリスクが3つある。
- 管理者本人と連絡が取れなくなるリスク：先代の引退・退職・体調不良・死去などで、管理者アカウントの持ち主と連絡が取れなくなると、パスワードリセットの手続きそのものが止まる。多くのSaaSは登録メールアドレス宛にリセットリンクを送る仕組みのため、そのメールアドレスにアクセスできる人間が誰もいなくなった時点で、会社は自社のデータにログインする手段を失う。
- 退会・解約されるリスク：管理者アカウントの持ち主が、悪意なく「もう使っていないだろう」と誤解してサービスを解約してしまう、あるいは支払いカードの失効に気づかず自動解約になるケースがある。契約者が個人である以上、会社側の意思決定を経ずにサービスが止まっても、法律上は契約者の意思として扱われてしまう。
- 退職・離反時にデータを持ち出される、あるいは人質化されるリスク：管理者権限を持つ担当者が会社と対立した状態で退職した場合、最悪、管理者パスワードの引き継ぎを拒否されたり、意図的にデータを削除・非公開化されたりする可能性がある。IPAの手引きが繰り返し強調する「クラウドサービスはサービス事業者と利用者が役割・責任を分担する」という原則のうち、利用者側の責任である「誰が管理するか」を個人任せにしてきたことの帰結だ。
いずれも「今日・明日に必ず起きる」話ではないため後回しにされがちだが、承継はまさにこのリスクが顕在化しやすい瞬間そのものである。先代が引退する、あるいは特定の担当者が退職するというタイミングは、管理者アカウントの持ち主が入れ替わる契機であり、そこで初めて「誰もパスワードを知らない」ことに気づくケースが後を絶たない。
まず確認すべき2つの論点：契約者は誰か、管理者は誰か
名義の取り戻し作業に入る前に、混同しやすい2つの論点を分けて把握しておく必要がある。
- 契約者（支払い義務を負う主体）：クレジットカードや口座振替で料金を支払っている名義。個人のカードで払い続けている場合、法人の経費処理上も本来は好ましくない。
- 管理者（システム上の権限を持つ主体）：ログインしてユーザー追加・削除、設定変更、データエクスポートができる権限を持つアカウント。支払いと管理者権限が別人に分かれているケースもある（例：支払いは会社の法人カードだが、管理者アカウントは辞めた担当者の個人メールのまま、など）。
この2つは別々に確認し、別々に会社名義へ揃える必要がある。支払いだけ法人カードに変えても、管理者権限が個人のままではリスクは残ったままだ。逆に管理者を変更しても支払いが止まれば強制解約されるリスクは残る。どちらか一方だけの対応で「終わった」と思い込まないことが重要になる。
移譲作業の4ステップ
ステップ1：契約しているクラウドサービスを洗い出す
まず何から手をつけるかというと、契約しているクラウドサービスそのものの棚卸しだ。経理の支払い記録（クレジットカード明細、口座引き落とし履歴）を過去1年分さかのぼり、「◯◯システム」「◯◯クラウド」といった名前の定期課金をリストアップする。次に、日常業務で使っているツール（会計ソフト、給与計算、顧客管理、名刺管理、ECサイトの管理画面、グループウェア、オンラインストレージなど）を担当部署ごとにヒアリングし、支払い記録と突き合わせる。
このとき、ログイン画面のURLと、登録されている管理者メールアドレスを必ず記録しておく。IPAの手引きが選択・運用・セキュリティ管理の3段階でチェック項目を示しているとおり、まず「何を使っているか」を可視化しない限り、運用面の確認にも進めない。
ステップ2：サービスごとに管理者権限の移譲・追加を申請する
洗い出しが終わったら、サービスごとに管理者権限を会社名義のアカウントへ移す。多くのSaaSは「オーナー権限の移譲」または「管理者の追加」という機能を管理画面に用意している。手順はサービスによって異なるが、大きく分けて次の2パターンがある。
- 管理者を追加できるサービス：既存の管理者（先代・元担当者）がまだ連絡可能なうちに、会社の代表用メールアドレスや、後継者本人のメールアドレスを「管理者」として追加してもらう。その後、元の管理者を削除するかどうかは会社の判断だが、少なくとも会社側が単独でログイン・操作できる状態を先に作ることが優先される。
- オーナー権限そのものを移譲する必要があるサービス：会計ソフトなど、契約の根幹に関わるサービスでは「オーナー」という特別な権限が1アカウントにのみ紐づいており、オーナー本人の操作でしか他者に権限を移せない設計になっていることが多い。この場合は元の管理者に必ず在職中・在任中に手続きを依頼する必要があり、退職後・引退後に本人と連絡が取れなくなると、サービス事業者のサポート窓口に登記事項証明書などの客観的資料を提出して個別対応してもらう以外に手段がなくなる。
このステップは、元の管理者と連絡が取れるうちに済ませておくことが最も重要な条件になる。 承継が決まった時点、あるいは特定の担当者の退職が決まった時点で、真っ先に着手すべき作業だと考えてよい。
サービス種別ごとの移譲のしやすさの傾向
すべてのクラウドサービスが同じ難易度というわけではない。業務の性質上、次のような傾向がある（個別のサービス仕様は必ず契約中のサービスのヘルプページで確認すること）。
- グループウェア・オンラインストレージ・名刺管理系：組織アカウント（会社ドメインでの契約）になっていれば、管理コンソールから他のメンバーを管理者権限で追加する操作が比較的用意されていることが多い。個人アカウントのまま契約している場合は、まず組織向けプランへの切り替え自体を検討する余地がある。
- クラウド会計・給与計算・請求書発行系：法人の根幹データ（仕訳、給与、取引先情報）を扱うため、オーナー権限の移譲に本人確認や追加書類を求める設計になっていることが多い。税理士や社労士が関与している場合は、移譲作業を専門家と一緒に進めると手戻りが少ない。
- ECサイトの管理画面・決済代行サービス：売上金の入金先口座と紐づいているため、名義変更には振込先口座の変更確認など、資金移動に関わる本人確認が特に厳格になる傾向がある。余裕を持ったスケジュールで着手したい。
ステップ3：支払い方法を会社名義に一本化する
管理者権限と並行して、支払い方法も会社名義のクレジットカードや口座振替に切り替える。個人のカードで支払いを続けている場合、経費精算の手間が発生するだけでなく、そのカードが失効・解約された瞬間にサービスが強制的に止まるリスクを抱え続けることになる。会社名義のカードに切り替えておけば、少なくとも「個人の事情でサービスが突然止まる」というリスクは大きく減らせる。
ステップ4：一覧化してシステム管理台帳に組み込む
移譲が完了したサービスから順に、サービス名・ログインURL・管理者アカウント・支払い方法・契約プラン・年間費用を一覧表にまとめる。すでに社内でシステム管理台帳を作っている場合は、そこにクラウドサービスの管理者情報を項目として追加すればよい。まだ台帳自体がない場合は、この移譲作業を機に台帳化まで済ませておくと、次に管理者が交代するときに同じ調査を繰り返さずに済む。
セキュリティの観点も同時に見直す
管理者権限を会社名義に揃える作業は、単なる名義変更にとどまらず、セキュリティを底上げする好機でもある。個人アカウントのまま長年運用されてきたサービスは、パスワードが使い回されていたり、多要素認証（MFA）が設定されていなかったりすることが多い。管理者を追加・変更するタイミングで、あわせて次の2点を確認しておきたい。
- 会社の代表的な管理者アカウントにMFAを設定する。
- 複数のクラウドサービスを横断的に管理できる場合は、シングルサインオン（SSO）の導入も選択肢に入れる。ただし全社的な導入は相応の検討が必要になるため、この記事の範囲では「選択肢として知っておく」程度にとどめる。
IPAの手引きも、クラウドサービスの運用段階での確認ポイントとして「誰が使うのか、どう管理するか」「誰が責任を持つか」を挙げており、管理者権限の所在を明確にすることがセキュリティ対策の出発点になる、という位置づけは公的資料の観点とも一致する。
退職者アカウントの棚卸しとは何が違うのか
似たテーマとして先代の退職者PCとアカウント、承継前にやる棚卸しの手順があるが、この記事が扱う「クラウドサービスの管理者権限」とは対象が異なる。退職者アカウントの棚卸しは、社内の業務システムやメールアドレスなど「誰が何にログインできる状態か」というアクセス権限全般を対象にした調査だ。一方、この記事で扱う管理者権限の移譲は、そのアクセス権限の中でも特に「契約そのものを左右できる最上位の権限（オーナー・管理者）が、誰の名義になっているか」という一段深い論点に絞っている。
退職者アカウントの棚卸しで「このサービスに誰がログインできるか」を洗い出した結果、管理者権限を持つ人物が先代や元担当者のままだと判明することも多い。その場合は、まず棚卸しで実態を可視化し、続けてこの記事のステップ2以降で管理者権限そのものの移譲に進む、という順序で対応するとよい。
元の管理者と連絡が取れない場合はどうするか
すでに先代が引退している、担当者が退職して連絡が取れないという状態で、この記事を読んでいる方もいるはずだ。その場合は次の順序で対応する。
- サービス事業者のサポート窓口に、代表者交代の事実（登記事項証明書の写しなど）を添えて事情を説明する。
- 契約者本人による本人確認が必須の設計になっているサービスでは、通常より時間がかかることを前提に、早めに問い合わせる。
- どうしても復旧できない場合は、そのサービス自体を新規に契約し直し、可能な範囲でデータをエクスポート・移行することも選択肢に入れる。既存データの移行可否はサービスごとに異なるため、個別に確認が必要になる。
「連絡が取れないから諦める」のではなく、まずサービス事業者に相談することで解決するケースは少なくない。この手の相談は珍しいものではなく、代表者交代自体は多くのサービス事業者が想定している事象だ。
まとめ：優先順位は「連絡が取れるうちに」
この記事で持ち帰れることは次の3点だ。
- クラウドサービスの契約者（支払い主体）と管理者（権限を持つ主体）は別の論点であり、両方を会社名義に揃える必要がある。
- 移譲作業でもっとも重要な条件は、元の管理者（先代・退職予定の担当者）と連絡が取れるうちに手続きを済ませておくことである。
- 移譲が完了したサービスから順に一覧化し、システム管理台帳に組み込んでおくと、次の担当者交代でも同じ調査を繰り返さずに済む。
今日からできる小さな一歩は、経理の支払い記録を1年分さかのぼり、契約しているクラウドサービスをリストアップすることだ。全部を一度に移譲する必要はない。まずは「何を契約しているか」が分かれば、次に何をすべきかは自然と見えてくる。
会社によっては、この棚卸しの過程で「そもそもこのサービス自体が今の業務に合っていない」という気づきにつながることもある。管理者権限の整理と合わせて、システム全体の棚卸しを進めたい場合は、先代システムの現状調査（棚卸し）のやり方や、属人化した先代システムを防ぐ、承継後の管理台帳の作り方もあわせて参考にしてほしい。
