前任の担当者名義のドメイン・サーバー契約を、承継後に取り戻す手順

結論から言う。前任の担当者や先代個人の名義でドメインやサーバー契約が残っている会社は珍しくない。これは違法でも異常でもないが、承継後に必ず「会社名義」へ引き取る作業をしておくべき技術的負債である。手順は大きく分けて、(1) 契約実態の棚卸し、(2) レジストラ・サーバー事業者への名義変更申請、(3) 支払い方法と管理者情報の付け替え、(4) 台帳化して再発防止、の4段階になる。この記事では、実際に何を確認し、どこに何を提出すればよいのかを、つまずきやすい順に説明する。

こんな人に向けて書いている。先代の代からある会社で、ホームページやメールのドメインが「よくわからないけど動いている」状態のまま社長を継いだ方。契約書を探しても「@gmail.com」の個人アドレスでレジストラに登録されていたり、10年以上前に外注した制作会社の担当者の名前が今も「登録者」として残っていたりする方。あるいは、その担当者がすでに退職・独立していて連絡が取りづらくなっている方。こうした状態を放置すると、更新通知が届かない、支払いカードの有効期限切れに気づけない、最悪の場合は自社サイトのドメインが失効して第三者に取得されるという事態にもつながる。まずは落ち着いて、何が起きているのかを整理するところから始めよう。

なぜ「前任者名義」のドメインが生まれるのか

多くの場合、原因は悪意ではなく「その場しのぎ」の積み重ねだ。ホームページ制作を外部の制作会社や個人事業主に依頼した際、先方が代行してドメインを取得し、そのまま自社のアカウントで管理を続けているケースが典型的だ。あるいは、社内の情報システム担当者が個人のメールアドレスや個人名でレジストラのアカウントを作り、退職後もそのアカウントが会社の資産を握ったままになっているケースもある。

いずれにしても共通しているのは、「動いているから」という理由で名義の話が先送りにされてきたという点だ。中小企業庁は事業承継について、経営権だけでなく資産・知的資産をあわせて後継者に引き継ぐことの重要性を明示しており、経営者は早期から後継者と共に会社の経営資源を「見える化」する取り組みを進めるべきだとしている（中小企業庁「事業承継を知る」）。ドメインやサーバーの契約名義は、まさにこの「見える化」から漏れ落ちやすい典型的な資産だ。株式や不動産、機械設備のように登記簿や固定資産台帳に載るものではないため、税理士や弁護士といった承継の専門家が関与する範囲からもこぼれ落ちてしまう。

先代からすれば「昔、詳しい人に頼んでおいたから大丈夫」という認識のまま代替わりしてしまい、後継者が初めて実態に気づくのは、たいてい「更新料が引き落とせない」という通知が来たときか、ホームページが急に表示されなくなったときだ。

筆者が見聞きする範囲でも、パターンは大きく3つに分かれる。1つ目は「制作会社が代行取得したまま」パターン。ホームページを作った当時の制作会社の担当者名、あるいは制作会社自体の法人名でドメインが登録されており、その会社が廃業したり担当者が転職したりすると、誰にも連絡が取れなくなる。2つ目は「情シス担当者の個人アカウント」パターン。詳しい社員が個人のGmailアドレスでレジストラのアカウントを作り、会社の経費で支払いながらも名義は個人のまま何年も運用してしまう。3つ目は「先代個人の名義」パターン。先代が創業した当初、法人化前の個人事業主時代にドメインを取得し、法人成りした後も名義を切り替えないまま放置しているケースだ。いずれも「動いているから後回し」という判断の積み重ねであり、承継のタイミングまで顕在化しないことが多い。

まず確認すべき3つの契約主体

名義の取り戻し作業に入る前に、混同しやすい3つの契約主体を分けて把握しておく必要がある。

• ドメイン契約（レジストラとの契約。例: お名前.com、Xserverドメインなど）
• サーバー契約（レンタルサーバー事業者との契約。例: エックスサーバー、さくらのレンタルサーバなど）
• DNS管理・メール契約（ドメインとサーバーを紐づける設定と、独自ドメインメールの契約）

この3つは別会社・別アカウントで契約されていることが多く、「ドメインは会社名義に直せたが、サーバーは前任者の個人名義のままだった」という中途半端な状態に陥りやすい。特に創業から時間の経った会社では、ドメインとサーバーの契約先自体が異なる事業者になっていることも珍しくない。棚卸しの段階で、この3つをそれぞれ独立した契約として洗い出すことが最初の関門になる。

さらに言えば、ホームページの制作・保守を委託している外注先が別に存在する場合、その外注先が「サーバーの管理画面にはログインできるが契約者ではない」という、いわば又貸しのような状態で運用していることもある。この場合、契約書上の当事者(レジストラ・サーバー事業者から見た顧客)と、実際に日々の運用作業をしている人間が異なるため、棚卸しの際には「誰が契約者か」と「誰が実際に触っているか」を分けて記録しておくとよい。この2つを混同したまま名義変更を進めると、契約者本人の同意を取り忘れたまま作業だけを外注先に依頼してしまい、後から手続きがやり直しになることがある。

ステップ1: 契約情報の棚卸し

最初にやるべきは「今、何がどう登録されているか」の事実確認だ。感覚や記憶に頼らず、以下の方法で機械的に確認する。

1. WHOIS情報の確認：ドメインの登録者情報は「Whois情報」としてインターネット上で公開・照会できる。JPRSが提供する検索サービス（JPRS WHOIS）で自社ドメインを検索すれば、登録者（Registrant）や管理担当者（Administrative Contact）に誰の名前・組織名が入っているかを確認できる。gTLD（.com、.netなど）は登録者情報の公開範囲がプライバシー保護の観点から制限されている場合もあるが、少なくとも管理事業者（レジストラ）がどこかは判明する。
2. 請求書・引き落とし明細の確認：経理の帳簿やクレジットカード明細から、ドメイン・サーバー関連の定期支払いを洗い出す。個人名義のカードから引き落とされている場合、それ自体が名義未整理の証拠になる。
3. メールの転送履歴の確認：レジストラやサーバー事業者からの更新通知メールがどのアドレス宛てに届いているかを確認する。前任者の個人アドレス宛てになっている場合、更新期限が近づいても社内の誰も気づけない状態にある。

「動いているから問題ない」は最も危険な思い込みだ。動いているのは前任者のアカウントが生きているからであって、その人がアカウントを閉じた瞬間、あるいは支払いカードが失効した瞬間に、会社の顔であるホームページとメールが同時に止まる。

この棚卸し結果は、口頭やメモで終わらせず、必ず一覧表に残す。これが後述する管理台帳の出発点になる。

棚卸しの際、あわせて確認しておきたいのが「更新サイクル」だ。ドメインは1年更新・2年更新・5年更新など事業者やプランによってまちまちで、なかには5年分をまとめて支払い済みのケースもある。この場合、次の更新のタイミングまで数年先になるため、「まだ動いているから急がなくていい」と誤解しやすい。しかし支払い済みの期間が長いほど、契約者本人と連絡が取れなくなってからの経過年数も長くなりがちで、いざ名義変更が必要になったときには本人の記憶自体が薄れていることも多い。更新サイクルが長いドメインほど、むしろ早めに名義を確認しておく価値がある。

ステップ2: レジストラへの名義変更申請（JPドメインの場合）

日本語ドメイン（co.jp、株式会社の登記名を含む属性型JPなど）は、JPRSが定めるルールに従って名義変更の手続きを行う。JPRSの公式説明によれば、登録者名そのものを変更したい場合は「移転」の手続き、住所や電話番号、登録担当者名など登録者名以外の情報を変更したい場合は「変更」の手続きが必要になる、という区分がある（JPRS「JPドメイン名のルール」）。つまり、「前任の個人名から自社名義に変える」というのは単なる情報修正ではなく、名義そのものの移転（登録者変更）に該当する点を理解しておく必要がある。

実務上は、ドメインを取り扱っている指定事業者（レジストラ）経由で申請する。多くの事業者では次のような書類・情報の提出を求められる。

• 現在の登録者（前任者）の同意、または登録内容変更に関する申請書
• 新しい登録者（会社）の商号・所在地を証明する書類（登記事項証明書など）
• 申請者の本人確認書類

前任者と連絡が取れる場合は、この同意取得が最もスムーズだ。連絡が取れない、あるいは退職者が非協力的な場合は、契約しているレジストラのサポート窓口に「登録者と連絡が取れない場合の名義変更」について個別に相談する必要がある。レジストラによって対応可能な代替書類（登記簿謄本、委任状、経緯説明書など）が異なるため、自己判断で進めず窓口に事情を説明するのが結局は近道になる。

ステップ3: gTLD（.com/.netなど）の移管はAuthCodeがカギ

.com や .net など、JPRSが取次を行うgTLDの管理指定事業者（レジストラ）を変更する場合は、認証コード（AuthCode、Transfer Codeとも呼ばれる）を使ったレジストラトランスファーの手続きになる。JPRSの解説では、レジストラトランスファーの申請にあたっては、まず取次事業者を経由して申請を行い、現在契約している登録事業者（レジストラ）からAuthCodeを確認したうえで、登録者のメールアドレス宛てに送信される確認メールで移転を承認するという流れが示されている（JPRS「レジストラトランスファーに関する方針」）。

ここで問題になるのが「登録者のメールアドレス」が前任者個人のものになっているケースだ。確認メールが前任者にしか届かない設計になっているため、移管の実行前に、まず前任者のアカウントにログインして登録メールアドレスを会社のアドレスに書き換えておく必要がある。前任者のアカウントに誰もログインできない状態(いわゆる単一障害点（SPOF）)に陥っている場合は、レジストラのサポートに本人確認書類一式を提出したうえでの代替手続きを依頼することになる。この場合、数日から数週間単位で時間がかかることを見込んでおいた方がよい。

なお、ドメインの「移管」と「名義変更」は似て非なる手続きだ。

自社がどちらを必要としているかを取り違えると、無関係な書類を集めて手続きが差し戻される。まずは自社ドメインの契約先(レジストラ)を特定し、そのレジストラのサポート窓口で「名義変更をしたいのか、移管をしたいのか」を明確に伝えることが早道になる。

ステップ4: レンタルサーバーの契約者名義変更

ドメインとは別に、レンタルサーバーの契約者名義も変更する必要がある。大手事業者の例では、契約者名義の変更は書面申請によって行われ、必要書類を事業者に提出したうえで、通常は提出書類が到着してから数営業日で手続きが完了するという運用が案内されている（エックスサーバー「ご契約名義を変更する場合」）。

ただし注意点がある。多くの事業者では、名義変更はあくまで「現在の契約者本人からの申請」を前提とした手続きであり、契約者以外の第三者(たとえば後継者)が代わりに名義だけを書き換えることはできない場合がある。前任者が退職済みで協力を得られない、あるいは先代がすでに引退して連絡が取りづらいといった状況では、「第三者への契約譲渡」という別区分の手続きが必要になることもある（エックスサーバー「第三者にご契約を譲渡する場合」）。

サーバー事業者ごとに名義変更・契約譲渡・支払い方法変更のメニューが分かれているため、自社が契約している事業者のサポートページを確認し、該当するメニューを問い合わせる。

もう一つ実務でよく発生するのが、サーバーの管理画面(コントロールパネル)のログインIDと、契約者情報(会員情報)が別レイヤーになっている点だ。多くのレンタルサーバー事業者では、「会員ID・パスワード」でログインする管理画面と、その配下にある「契約者名義・支払い情報」は別の設定項目になっている。名義変更の申請をしても、管理画面のログインIDまでは自動的に引き継がれないことがあるため、名義変更の完了後は必ず管理画面に実際にログインし、契約情報の表示が会社名になっているか、支払い方法が更新されているかを目視で確認する。この確認を怠ると、書類上は名義変更が完了しているのに、実際の運用は前任者のログイン情報に依存したままという状態が続いてしまう。

ステップ5: 支払い方法の付け替え

名義変更と同時に必ず対応すべきなのが支払い方法だ。前任者個人のクレジットカードで契約が継続している場合、そのカードが失効・解約された瞬間にドメインもサーバーも更新が止まる。これは名義変更よりも緊急性が高い問題だ。

支払い方法の変更は、多くの場合レジストラ・サーバー事業者の管理画面から社長自身、あるいは新しい情報システム担当者が直接操作できる。ただし管理画面にログインするためのアカウント自体が前任者名義になっていることが多いため、実質的には「ログインアカウントの引き継ぎ」→「支払い方法の変更」→「登録者名義の変更」という順序で進めることになる。ログイン情報(ID・パスワード)が引き継がれていない場合は、各社のパスワードリセット手続きから着手する必要がある。

パスワードリセットの際に注意したいのが、二段階認証や登録済みの秘密の質問だ。前任者が退職前にセキュリティ強化のつもりで携帯電話番号による二段階認証を設定していた場合、その電話番号自体が使えなくなっていると、通常のパスワードリセットのフローでは突破できない。この場合も、結局は運営事業者のサポート窓口に対して、契約者本人であることを証明する書類(登記事項証明書、代表者の身分証明書、名刺など)を提出し、個別に本人確認を経てアカウントの制御を取り戻す流れになる。あらかじめ「二段階認証が前任者の電話番号に紐づいていないか」を確認しておくと、いざというときに慌てずに済む。

承継特有の壁: 「相談できる人がいない」問題

株式の名義書換であれば税理士や司法書士に相談すればよい。しかし、ドメインやサーバーの名義変更は、誰に相談すればいいのか分からないという後継者は多い。会計士・弁護士は詳しくないし、レジストラのサポート窓口は「契約手続き」の案内はしてくれても、「会社としてどう体制を整えるべきか」までは踏み込んでくれない。

さらに厄介なのは、古参社員に聞いても「昔、外の業者さんに任せていたはずだが詳しいことは分からない」という答えしか返ってこないことだ。先代が現役だった頃は、ホームページやメールのことは特定の担当者や外注先に「丸投げ」で済んでいた。それ自体は当時としては合理的な判断だったかもしれないが、その担当者が退職したりその外注先と縁が切れたりした瞬間に、社内の誰も契約の全体像を知らないという状態が生まれる。これは典型的な属人化の一形態であり、株式や登記のように公的な記録が残らない分、発覚が遅れやすい。

このとき頼れるのは、結局のところ各レジストラ・サーバー事業者のサポート窓口と、状況によっては顧問弁護士(本人確認書類や委任状の形式面で助言をもらう)くらいしかない。「うちの会社は特殊な事情があるので、通常のフローでは対応しきれないかもしれない」と最初に率直に伝え、個別対応の余地を確認するのが結果的に早い。

古参社員との関係にも触れておきたい。長年経理を任せてきたベテラン社員が「昔から支払いは私が管理していたので」とドメイン更新費用の支払い明細を握っているケースもある。この場合、当人に悪意はまったくなく、むしろ会社を守るつもりで長年管理を続けてくれていたのだが、後継者から見ると「なぜ経理担当者の個人的な管理下にドメインの支払いがあるのか」という違和感につながる。こうした場面では、相手がこれまで果たしてきた役割を否定せず、「属人化した管理を会社の仕組みに移す」という前向きな文脈で説明すると、協力を得やすい。頭ごなしに「今のやり方はおかしい」と指摘すると、長年会社を支えてきた自負のある社員ほど態度を硬化させることがある。承継直後は特に、こうした人間関係の機微への配慮が、技術的な正しさと同じくらい手続きの成否を左右する。

名義変更が完了したら: 台帳化で再発を防ぐ

名義を会社に取り戻せたら、そこで終わりにせず、必ず記録に残す。おすすめは、Excelでもよいので「ドメイン・サーバー管理台帳」を作成し、以下の項目を最低限記載しておくことだ。

• ドメイン名／契約先レジストラ名
• 登録者名義（会社名で統一)
• 契約の更新日・自動更新の有無
• ログインID(パスワードは別管理)
• 支払い方法(会社名義のカードまたは口座)
• 緊急連絡先(現在の情報システム担当者、または社長本人)

この一覧が、いわゆるシステム管理台帳の最初の1ページになる。ドメインとサーバーだけでなく、今後は業務で使っている他のシステムやソフトウェアについても同様の棚卸しを広げていくことで、「誰かが辞めたら誰も分からなくなる」状態を構造的に防げるようになる。台帳は完璧な網羅性を最初から目指す必要はない。まずはドメインとサーバーという、対外的な信用に直結する2点から埋めていき、四半期に一度など決まったタイミングで見直す運用に乗せることが継続のコツだ。台帳全体の設計・運用方法は属人化した先代システムを防ぐ、承継後の管理台帳の作り方で詳しく扱っている。

よくある失敗パターン

実務でつまずきやすいパターンをいくつか挙げておく。

• 前任者と連絡がついたが、返信が遅い：退職者は在職中ほど迅速に対応してくれない。督促のタイミングをあらかじめ決め、期限までに返信がなければレジストラのサポートに「本人と連絡が取れない場合の対応」を相談する方針に切り替える。
• 登記事項証明書の商号が旧字体・旧商号のままで却下される：会社名変更や本店移転をしたことがある会社は、最新の登記事項証明書を取得し直してから提出する。
• ドメインとサーバーを別々に進めて片方だけ完了し、安心してしまう：3つの契約主体(ドメイン・サーバー・メール)をそれぞれ個別にチェックし、すべて完了するまでは「未完了」として管理する。
• 移管作業中にサイトが一時的に表示されなくなる：DNS設定の切り替えには反映に時間がかかることがある。繁忙期や商談前を避け、余裕を持ったスケジュールで進める。
• メールアドレスの受信が止まっていることに気づかない：独自ドメインでメールを運用している場合、サーバー移管の作業タイミングによっては数時間から数日、メールの送受信が不安定になることがある。取引先からの問い合わせメールが届かなくなっていないか、作業後は必ず送受信テストを行う。
• 社内向けの周知を忘れる：名義変更やサーバー移行の作業中は、一時的に管理画面のパスワードが変わったり、社内システムへのアクセス方法が変わったりすることがある。経理担当や広報担当など、日常的にサイト更新やメール送信を行う社員には事前に一言伝えておく。
• 委任状のフォーマットが事業者ごとに異なることを知らずに使い回す：レジストラAで使った委任状のひな形をそのままレジストラBに提出して差し戻されることがある。各社が指定する様式を必ず個別に確認する。

専門家に頼るべきか、自社で完結できるか

ここまでの手続きの多くは、社長自身または情報システム担当者が各社のサポート窓口とやり取りしながら進められる範囲のものだ。ただし、次のようなケースでは外部の専門家(制作会社やIT担当のパートナー)に相談した方がよい。

• 前任の外注先(制作会社)がドメインを保有したまま連絡がつかない
• 登録者情報が海外のレジストラ経由になっており、日本語サポートがない
• ドメインに紐づくメールサーバーやSSL証明書の設定まで含めて移行が必要

自社にIT専任者がいない会社では、こうした移行作業自体が久しぶりの「システムに手を入れる」機会になる。この機会に、ドメイン・サーバーだけでなく社内で使っているソフトウェアのEOL（サポート終了）(サポート終了時期)もあわせて確認しておくと、次の見直しの手間が減る。「触ると壊れる」と言われてきたシステムを調べる際の順番の考え方は、「触ると壊れる」と先代に言われ続けたシステムを調査する順番にまとめている。

外部の制作会社やIT担当のパートナーに相談する際は、「名義変更の手続き代行」だけを依頼するのか、「今後の運用体制の構築」まで含めて依頼するのかを最初に切り分けておくとよい。前者だけであれば、単発のスポット対応で完結することが多い。後者まで含める場合は、月額の保守契約や顧問契約といった継続的な関係を結ぶことになるため、費用感や対応範囲について複数社から見積もりを取り、比較検討する時間的余裕を持って動き出したい。承継直後は他にも決めるべきことが山積みになりがちなので、システム周りの相談先探しは後回しにされやすいが、一度信頼できる相談先を確保できれば、今後同種のトラブルが起きたときの心理的な負担が大きく下がる。

名義変更にかかる期間の目安

「どれくらい時間がかかるのか」を最初に見積もっておくと、社内の期待値調整がしやすい。あくまで一般的な目安だが、参考として整理する。

この目安からも分かる通り、「前任者と連絡が取れるかどうか」が所要期間を大きく左右する最大の変数だ。承継が決まった段階、あるいは承継後できるだけ早いタイミングで前任者に連絡を取っておくことが、結果的に最短ルートになる。時間が経てば経つほど、前任者側の記憶も薄れ、連絡先そのものが変わってしまうリスクも高まる。

支払いカードの名義と法人カードへの一本化

支払い方法の付け替えについて、もう一歩踏み込んで触れておきたい。個人のクレジットカードで契約が継続されている場合、そのカードの名義人が退職・独立した後も、会社が経費として利用料を精算し続けているケースが少なくない。これは経理上も好ましくない状態だ。退職者への個人的な立替払いが継続する形になり、税務上の説明も煩雑になる。

理想的には、ドメイン・サーバーの支払いはすべて法人名義のクレジットカードか、法人口座からの口座振替に一本化しておきたい。名義変更の手続きと合わせて、支払い方法も同時に会社名義へ切り替えることで、「名義は会社になったが支払いだけ個人カードのまま」という中途半端な状態を避けられる。多くのレジストラ・サーバー事業者では、管理画面から支払い方法(クレジットカード情報)を変更できるため、名義変更の完了後、忘れずにこの作業まで実施する。

SSL証明書やメールの設定も一緒に確認する

ドメインとサーバーの名義変更に気を取られていると見落としがちなのが、SSL証明書(常時HTTPS化のための証明書)の契約主体だ。無料のSSL証明書(Let's Encryptなど)をサーバー事業者が自動発行している場合は名義の問題は生じにくいが、有料のSSL証明書を別途契約している場合、その契約者情報も個人名義になっていないか確認が必要になる。

同様に、独自ドメインのメールを外部のメールサービス(Google WorkspaceやMicrosoft 365など)で運用している場合、そのメールサービス自体の契約者・管理者アカウントが前任者の個人アカウントになっていないかも合わせて点検したい。メールサービスの管理者アカウントを前任者が握ったままだと、社員のメールアカウントの追加・削除、パスワードリセットといった日常的な運用そのものが、前任者の協力なしにはできない状態が続いてしまう。ドメイン・サーバーの名義変更と同じタイミングで、こうした周辺サービスの契約者情報も棚卸しの対象に含めておくと手戻りが少ない。

まとめ: 名義変更は「今すぐ」ではなく「承継直後」にやる

前任者名義のドメイン・サーバー契約は、多くの場合すぐに実害が出るわけではない。しかし、実害が出たときには「ホームページが消える」「会社のメールが届かなくなる」という、対外的な信用に直結するトラブルとして現れる。株式の名義書換や登記変更のように士業が伴走してくれる手続きではないからこそ、後継者自身が能動的に動く必要がある。

やるべきことを整理すると、次の3行に集約できる。

1. WHOISと請求明細で契約実態を洗い出す
2. レジストラ・サーバー事業者ごとに「移管」「名義変更」「担当者変更」を切り分けて申請する
3. 完了後は台帳化し、支払い方法も会社名義に統一する

先代の代からの「その場しのぎ」を清算する作業は地味だが、承継後のシステムの安定運用における最初の一歩になる。株式や不動産と違って公的な記録に残らない分、後回しにされがちな領域だからこそ、代替わりのタイミングで一度きちんと手を付けておく価値がある。M&Aによる承継の場合は、前オーナーの契約を洗い出す順番自体が重要になる。ガイドM&Aでの承継1年目は、前オーナーの契約を洗い出す順番から始めるも参考にしてほしい。

よくある質問

Q1. 前任の担当者と連絡が全く取れません。それでも名義変更はできますか。 A. 可能な場合が多いが、通常より時間と書類が必要になる。レジストラやサーバー事業者のサポート窓口に、登記事項証明書などの客観的な資料を添えて「登録者本人と連絡が取れない」事情を説明し、個別の代替手続きを案内してもらう必要がある。事業者やドメインの種類によって対応可否・必要書類が異なるため、自己判断せず早めに問い合わせるのが得策だ。

Q2. ドメインの「移管」と「名義変更」はどちらを申請すればいいですか。 A. 契約している事業者(レジストラ)自体を変えたいなら「移管(レジストラトランスファー)」、事業者は変えずに登録者名を個人から会社に変えたいだけなら「名義変更(登録者変更)」になる。両者は必要書類も申請窓口も異なるため、まず自社ドメインの現在の契約先を確認し、そのサポート窓口に目的を明確に伝えて手続き名を確認するとよい。

Q3. サーバーとドメインを両方とも名義変更する必要がありますか。片方だけではだめですか。 A. 両方必要になる。ドメインとサーバーは別々の事業者と契約していることが多く、片方だけ会社名義にしても、もう片方が前任者名義のままでは同じリスク(支払い停止による失効、連絡不通)が残る。棚卸しの段階で両方を独立した契約として洗い出し、両方が完了するまでは「未完了」として管理することを勧める。

Q4. 名義変更が完了するまでの間、サイトが止まるリスクを避けるにはどうすればいいですか。 A. 手続き中であっても、まずは支払い方法だけでも会社名義のカードに切り替えておくと、更新停止による失効リスクを大きく減らせる。名義そのものの変更には時間がかかることがあるため、支払いの継続性を最優先で確保し、名義変更は並行して進めるという優先順位で対応するのが実務的だ。