宿のホームページを作った担当者が退職した。制作会社との契約を見直したい。家族へ運営を引き継ぎたい。しかし、ドメインやサーバーを誰が契約しているのか分からない――。
この状態で旧担当者のアカウントを先に削除すると、ホームページ、予約、メール、アクセス解析へ誰も入れなくなることがあります。反対に、契約終了後も旧担当者の強い権限を残すのも安全ではありません。
この記事では、ITに詳しくない宿主さんが、CodexやClaude Codeに整理を手伝わせながら、宿サイトの管理を安全に引き継ぐ順番を説明します。
結論：新担当者が入れることを確認してから旧権限を外す
引き継ぎは次の順番で行います。
- 宿が使っているサービスを一覧にする
- 契約名義、請求先、管理者、復旧先を確認する
- 宿名義の継続管理アカウントを用意する
- 新担当者を必要最小限の権限で追加する
- 新担当者がログイン・確認できるか試す
- バックアップと緊急連絡先を確認する
- 旧担当者の権限、鍵、連携を外す
- 公開サイト、予約、メール、計測を再確認する
パスワードを教えて引き継ぐのではなく、新しい個人別アカウントを追加して権限を移すのが基本です。
引き継ぐ対象はWordPressだけではない
宿サイトの運営には、複数の契約と管理画面が関係します。
| 分類 | 確認するもの | 入れない情報 |
|---|---|---|
| ドメイン | 登録事業者、契約名義、更新日、連絡先 | ログインパスワード、認証コード |
| DNS | 管理事業者、変更担当、現在の用途 | APIキー、ゾーン変更用の秘密情報 |
| サーバー | 会社、プラン、請求先、保守担当 | SSH秘密鍵、rootパスワード |
| WordPress | URL、管理者、編集者、更新担当 | パスワード、2段階認証の復旧コード |
| メール | 管理者、代表アドレス、転送先 | メールパスワード、本文 |
| Analytics、Search Console、タグ | Googleアカウントのパスワード | |
| 予約 | 予約エンジン、OTA、在庫同期、担当 | 予約者情報、決済情報 |
| 決済 | 契約法人、管理者、入金先、経理担当 | カード情報、秘密鍵、本人確認書類 |
| 外部連携 | SMTP、バックアップ、監視、SNS | APIキー、アクセストークン |
この表へ記録するのは「どこで、誰が、何を管理しているか」です。秘密情報そのものは、組織で承認したパスワード管理手段など、別の安全な場所で管理します。
最初に契約名義と支払いを確認する
管理画面へ入れることと、契約を所有していることは同じではありません。請求書、契約メール、カード明細、管理画面の契約者表示を確認します。
特に重要なのはドメインです。ドメインが失効したり、旧制作会社の管理下から動かせなくなったりすると、サイトだけでなくメールにも影響します。ICANNは、ドメイン登録者がレジストラと契約し、連絡先、移管、更新を管理する立場であることを案内しています。
次を「確認済み」「確認中」「不明」で記録します。
- 正式な契約者・登録者
- 更新期限と自動更新の状態
- 請求先と支払い方法の管理者
- 更新案内が届くメールアドレス
- 契約変更や移管を承認できる人
- 問い合わせ先と契約番号の保管場所
分からない項目をAIに推測させず、契約先や現在の制作会社へ質問します。
宿名義の継続管理アカウントを残す
担当者個人のメールアドレスだけを最上位の管理者にすると、退職、病気、連絡不能によって管理を失うおそれがあります。
宿が継続管理できる連絡先を用意し、少なくとも次を整えます。
- 宿側で管理できる管理者がいる
- 復旧用メール・電話番号を最新にする
- 2段階認証を有効にする
- 復旧手段を安全な場所へ保管する
- 一人だけが唯一の管理者にならないようにする
- 制作会社や担当者は個人別アカウントで追加する
ただし、代表メールを全員で同じパスワードで使う方法は避けます。宿が所有権を維持するアカウントと、各担当者が日々使う個人別アカウントを分けます。
WordPressは役割に合わせて権限を分ける
WordPress公式では、管理者、編集者、投稿者などの役割ごとに実行できる操作が分かれています。記事更新だけを担当する人へ、プラグインの追加や利用者管理までできる管理者権限が必要とは限りません。
引き継ぎ時に確認する項目:
- 宿側の管理者アカウント
- 制作会社・保守会社のアカウント
- 記事を更新する担当者と役割
- 使われていない利用者
- 表示名と公開プロフィール
- 2段階認証の対象
- 外部投稿・連携用の認証
新担当者のログインを確認する前に、旧管理者を削除しません。投稿者を削除する必要がある場合は、記事の帰属がどうなるかも確認します。
Googleのサービスも個別に引き継ぐ
同じGoogleアカウントを共有するのではなく、AnalyticsやSearch Consoleへ新担当者を追加します。Google Analyticsでは、アカウントまたはプロパティ単位で利用者と権限を管理できます。追加する階層によって見える範囲が変わるため、必要な範囲だけを付与します。
確認するもの:
- Google AnalyticsのアカウントとGA4プロパティ
- Search Consoleのプロパティと確認済み所有者
- Googleタグとタグ管理方法
- Googleビジネスプロフィール
- 広告を利用している場合のGoogle広告
- YouTubeを運用している場合のチャンネル権限
Google公式は、管理者が一人だけだと、その人が利用できなくなった際に管理を失う可能性があると案内しています。宿側の継続管理者を残したうえで、旧担当者の権限を外します。
予約・決済は通常のサイト管理と分ける
予約と決済には、宿泊者情報、売上、返金、入金先が含まれます。WordPressの引き継ぎ表へ、予約者名やカード情報をコピーしてはいけません。
確認するのは次の管理関係です。
- 契約者と請求先
- 最上位の管理者
- 日常業務担当者の権限
- 入金先を変更できる人
- 返金やキャンセルを実行できる人
- OTAやサイトコントローラーとの連携
- 退職者・旧制作会社のアカウント
- 操作履歴と問い合わせ窓口
入金先、返金、予約変更は、AIだけで実行せず、人が対象と金額を確認します。本人確認や事業者情報の変更は各サービスの公式手順を使います。
サーバーとDNSの引き継ぎは専門担当者と行う
サーバー、DNS、TLS証明書、メール配送の変更は、サイトやメールを停止させる可能性があります。「新担当者へ渡すため」という理由でも、設定値をまとめて変更しないでください。
技術担当者へ次を確認します。
- サーバー方式と管理責任者
- 本番・検証環境の区別
- バックアップの保存場所と復元担当
- DNSの管理場所と現在の用途
- TLS証明書の更新方法
- SSH・SFTP・管理APIの利用者
- 監視通知と障害時の連絡先
- 制作会社固有のテーマやプラグインの利用条件
旧担当者のSSH鍵やAPIキーを外す前に、新しい経路で必要な確認ができることを試します。秘密鍵をチャットや引き継ぎ資料へ貼り付けず、新しい鍵を発行して古い鍵を無効化します。
引き継ぎ当日の安全な順番
1. 変更前の状態を記録する
公開ページ、予約ページ、問い合わせ、メール、管理画面への到達状況を確認します。対象と時刻を記録し、必要なバックアップを取得します。
2. 新担当者を追加する
新しい個人別アカウントを必要最小限の権限で追加します。招待メールは本人が確認し、パスワードや2段階認証を自分で設定します。
3. 新担当者側で確認する
ログインできるだけでなく、担当業務に必要な画面が見えるか、不要な画面まで変更できないかを確認します。
4. 宿名義の復旧経路を確認する
旧担当者のメールや電話だけが復旧先になっていないか確認します。復旧コードそのものを作業報告へ書きません。
5. 旧権限を外す
契約終了日と合意内容を確認し、旧アカウント、SSH鍵、APIキー、転送先、外部連携を対象ごとに外します。一括削除せず、一つずつ確認します。
6. 公開側を再確認する
トップページ、予約、問い合わせ、HTTPS、メール、Analytics・Search Consoleのアクセスを確認します。問題があれば追加変更を止め、どの変更から影響したか調べます。
AIに渡す引き継ぎ資料
AIは資産台帳と未確認事項の整理に役立ちます。ただし、資料へ秘密情報を含めません。
サービス名：［例：ドメイン管理］
用途：［サイトとメールの名前を維持］
契約名義：［宿／法人／確認中］
管理担当：［役割名。個人のパスワードは書かない］
権限：［管理者／編集者／閲覧者］
更新・請求：［月だけ。カード番号は書かない］
復旧担当：［宿側／制作会社／確認中］
公式窓口：［公式サポートURL］
未確認事項：［質問内容］
最終確認日：［年月日］
この形式なら、AIへ「不明項目を抽出して」「担当別に並べて」と頼めます。認証情報は別管理であることを明記します。
コピペで使えるAIへの依頼文
現状を変更せず整理する
宿サイトの担当者変更に備えて、管理対象を整理してください。
まだアカウント追加・削除・設定変更はしないでください。
ドメイン、DNS、サーバー、WordPress、メール、Google、予約、決済、
バックアップ、監視について、契約名義、管理者、請求、復旧先、
未確認事項を一覧にしてください。
パスワード、APIキー、秘密鍵、復旧コード、予約者情報は
読み取らず、出力にも含めないでください。
制作会社へ渡す質問を作る
作成した管理対象一覧から、現在の制作会社へ確認する質問を作ってください。
質問は、契約、所有権、権限、バックアップ、利用ライセンス、
解約後の引き渡し、旧アカウント停止の順に整理してください。
分からない内容を推測せず、回答欄と確認期限を付けてください。
認証情報そのものをメールで送るよう求めないでください。
旧権限を外す前に監査する
旧担当者の権限を外す前の確認表を作ってください。
新担当者のログイン、宿側管理者、復旧経路、バックアップ、
公開サイト、予約、問い合わせ、メール、Google計測を含めてください。
調査と提案だけを行い、アカウント削除、鍵の失効、DNS変更、
契約変更は実行しないでください。
引き継ぎ完了チェックリスト
- [ ] ドメイン、DNS、サーバーの契約先を確認した
- [ ] 契約名義、請求先、更新期限を確認した
- [ ] 宿側の継続管理者を確保した
- [ ] 管理者が一人だけになっていない
- [ ] 新担当者は個人別アカウントを使っている
- [ ] 必要最小限の権限を設定した
- [ ] 新担当者が実際にログインできた
- [ ] 復旧用の連絡先と2段階認証を確認した
- [ ] バックアップと復元担当を確認した
- [ ] 予約・決済情報を通常の資料へコピーしていない
- [ ] 旧担当者のアカウント、鍵、連携を確認した
- [ ] 公開サイト、予約、問い合わせ、メールを再確認した
- [ ] AnalyticsとSearch Consoleの権限を確認した
- [ ] 引き継ぎ日と確認結果を記録した
サーバー方式が分からない場合はあなたのWordPressはどのタイプ？から確認してください。日常の権限設計はAIに本番サーバーを触らせるときの権限設計、毎月の見直しは宿泊施設サイトの月次点検で解説しています。
参考にした情報
まとめ
宿サイトの引き継ぎでは、WordPressのパスワードだけを渡しても十分ではありません。ドメイン、サーバー、メール、Google、予約、決済まで、契約と管理権限を一つずつ確認します。
新担当者を個人別アカウントで追加し、実際に利用できることを確認してから旧権限を外します。AIには一覧化、質問作成、確認表の作成を任せられますが、秘密情報、契約変更、決済、アカウント削除は人が確認してください。
