宿の公式サイトが止まっていたことを、お客様の電話で初めて知る。予約ページのリンク切れが数日間そのままになっていた。SSL証明書の問題でブラウザに警告が出た――。こうした問題は、管理画面を月に一度見るだけでは気づけないことがあります。
そこで役立つのが、宿の外側から公開ページへ定期的にアクセスし、正常な応答が返るかを確認する外形監視です。AIは監視対象の整理、設定案、通知の分類、月次報告を手伝えます。
この記事では、ITに詳しくない宿主さんが、何をどこまで監視すればよいかを初心者向けに説明します。
結論：最初は四つだけ外から確認する
最初から全ページやサーバー内部を監視する必要はありません。宿の営業に近い四つから始めます。
- トップページが開く
- 予約案内または予約ページが開く
- 問い合わせページが開く
- HTTPSで安全に接続できる
監視は「異常を知らせる仕組み」であり、自動修復ではありません。異常通知を受けても、AIが勝手に再起動、キャッシュ削除、プラグイン停止、復元を実行しない設計にします。
外形監視とは
外形監視は、お客様と同じようにインターネット側からURLへアクセスし、ページが応答するかを定期的に確認する方法です。
外部の監視場所
↓ 定期的にアクセス
宿の公開ページ
↓ 応答時間・状態・内容
正常なら記録 / 異常なら通知
サーバー内部のCPUや容量を見る監視とは役割が異なります。内部が正常でも、DNS、HTTPS、Webサーバー、WordPressのどこかで問題があれば、お客様からページが開かない場合があります。反対に、外形監視だけでは容量不足やバックアップ失敗までは分かりません。
HTTPステータスを初心者向けに理解する
ブラウザがページへアクセスすると、サーバーは状態を示す番号を返します。
| 範囲 | 大まかな意味 | 例 |
|---|---|---|
| 200番台 | 成功 | ページを正常取得できた |
| 300番台 | 別URLへ移動 | HTTPからHTTPS、旧URLから新URL |
| 400番台 | 要求したページ側の問題 | 404でページが見つからない |
| 500番台 | サーバー側の問題 | 500、502、503等 |
多くの公開ページでは、最終的に200 OKへ到達する状態を監視します。ただし、予約ボタンが外部サービスへ正しく移動する場合など、意図したリダイレクトは異常ではありません。AIに現在の移動先を調査させ、人が正しい予約先か確認します。
200が返っても正常とは限らない
WordPressがエラー画面やメンテナンス案内を200で返すこともあります。そのため、応答番号だけでなく、ページ内の「あるべき内容」も確認します。
トップページ
- 宿名が表示される
- 予約案内へのリンクがある
- エラー文やメンテナンス画面になっていない
予約案内
- 予約ボタンが存在する
- 意図した予約サービスへ進む
- 「受付停止」等の想定外表示がない
問い合わせ
- フォームまたは連絡方法が表示される
- 入力欄が画面外へ崩れていない
本文全体を保存して比較すると、料金、個人情報、動的な空室情報まで記録する可能性があります。監視には公開ページ上の短い固定文や要素だけを使い、必要以上の内容を保存しません。
予約は「ページ表示」と「予約成立」を分ける
自動監視で実在する予約を何度も作ってはいけません。予約導線は段階を分けます。
| 段階 | 自動監視の例 | 人が確認すること |
|---|---|---|
| 入口 | 予約案内ページが開く | 料金・注意事項が正しい |
| リンク | 予約ボタンの移動先が正しい | 契約中の予約サービスか |
| 予約画面 | 外部予約画面が表示される | 対象プラン・日付が正しい |
| 入力・確定 | 原則自動実行しない | テスト方法を予約会社へ確認 |
監視ツールが予約枠を消費したり、通知メールを大量送信したりしないようにします。決済を含む操作は、利用サービスが用意するテスト環境や正式な確認方法を使います。
問い合わせフォームは送信せず監視できる
日常監視では、ページが開き、フォームの主要項目や送信ボタンが存在するところまで確認できます。ただし、それだけではメールが届くとは限りません。
フォーム送信の確認は、月次点検や更新後確認として、専用のテスト内容と宛先を決めて人が行います。自動送信する場合は次を先に設計します。
- テストだと分かる件名
- 実在予約と混ざらない内容
- 個人情報を含まない入力
- 送信頻度の上限
- 受信確認する担当者
- 自動返信や外部連携への影響
フォームへ短時間に繰り返し送ると、迷惑送信対策に引っかかることがあります。
SSL・HTTPSで監視すること
HTTPSは、宿とお客様の通信を暗号化し、接続先を確認する仕組みです。証明書に問題があると、ブラウザが警告を表示し、予約前に離脱される可能性があります。
確認する項目は次のとおりです。
- HTTPSで接続できる
- 証明書が期限内である
- 宿名のドメインに対して有効である
- 証明書の連鎖に問題がない
- HTTPからHTTPSへ意図どおり移動する
- 期限前に更新確認の通知が届く
自動更新を設定していても、DNS、認証、容量、Webサーバー設定などの理由で更新に失敗する可能性があります。「自動だから確認不要」にはしません。
WordPressのサイトヘルスとの違い
WordPress管理画面の「ツール → サイトヘルス」は、WordPress、テーマ、プラグイン、PHP、HTTPS、バックグラウンド更新などの問題を確認する機能です。
| 確認方法 | 得意なこと | 苦手なこと |
|---|---|---|
| 外形監視 | お客様側からページが開くか | WordPress内部の細かな構成 |
| サイトヘルス | WordPress内部の推奨事項や構成 | サイト全体が止まると確認できない |
| サーバー監視 | CPU、メモリ、容量、プロセス | 予約内容や見た目の正しさ |
| 人の確認 | 料金、予約、使いやすさ | 常時繰り返すのは難しい |
どれか一つで全部を代替するのではなく、役割を組み合わせます。サイトヘルス情報には技術構成や内部情報が含まれるため、そのまま公開したり、AIとの公開会話へ貼ったりしません。
最初の監視対象を決める
宿主さんは次の表を作るだけで構いません。
| 優先 | 対象 | 正常の条件 | 異常時の連絡先 |
|---|---|---|---|
| 1 | トップ | 200・宿名がある | サイト担当者 |
| 1 | 予約案内 | 200・予約ボタンがある | 予約担当者 |
| 1 | HTTPS | 証明書が有効 | サーバー担当者 |
| 2 | 問い合わせ | 200・フォームがある | サイト担当者 |
| 2 | アクセス | 200・地図案内がある | サイト担当者 |
監視対象に管理画面URL、プレビューURL、予約管理URL、顧客ページを入れません。公開ページだけを使い、認証情報を監視サービスへ不用意に渡さないようにします。
通知先と通知頻度を決める
通知が多すぎると、重要な異常も読まなくなります。
- 一回の失敗だけで緊急通知するか
- 数回連続で失敗したとき通知するか
- 復旧時にも通知するか
- 夜間の連絡先は誰か
- サーバー会社と制作会社のどちらへ連絡するか
- 同じ障害をまとめるか
予約ページの完全停止は早く知りたい一方、一時的な通信遅延は再確認してから通知する方法があります。営業への影響に応じて優先度を分けます。
AIに任せられる作業
CodexやClaude Codeは次を支援できます。
- 公開ページから監視候補を洗い出す
- 予約に近い順に優先度を付ける
- 正常時のHTTP状態とリダイレクトを記録する
- 固定文や要素の確認条件を提案する
- SSL証明書の確認項目を整理する
- 監視通知を重複・緊急度別にまとめる
- 障害対応カード用の連絡表を作る
- 月次の成功率や障害時間を要約する
- 障害後の振り返りへ監視記録を渡す
AIには、通知を受けただけで本番を自動変更させません。まず複数地点、別回線、サーバー会社の障害情報などで事実を確認します。
コピペで使えるAIへの依頼文
監視対象を決める
宿の公開サイトで、外部から定期確認するURLを選んでください。
トップ、客室・料金、予約案内、問い合わせ、アクセスを候補にし、
営業への影響と監視頻度で優先順位を付けてください。
公開ページだけを対象にし、管理画面、顧客ページ、プレビュー、
予約管理画面、認証が必要なURLは除外してください。
まだ監視サービスの契約や設定変更はしないでください。
正常条件を作る
次の公開URLについて、外形監視の正常条件を作ってください。
［URL一覧］
HTTP状態、意図したリダイレクト、固定文または要素、
HTTPS証明書、応答時間を分けてください。
料金、空室、個人情報、動的な日時を固定条件にしないでください。
予約やフォーム送信は実行せず、入口とリンクだけを確認してください。
異常通知を調査へ渡す
サイト監視から次の異常通知が届きました。まだ修正しないでください。
［対象URL、時刻、HTTP状態、継続時間］
一時的な通信問題、サイト全体、WordPress、予約サービス、HTTPSの
どこを確認するか、読み取り専用の順序を作ってください。
再起動、更新、停止、復元、キャッシュ削除は実行しないでください。
確認済みの事実、原因候補、未確認事項を分けてください。
月次報告を作る
外形監視の一か月分の結果を宿主向けに要約してください。
正常期間、異常日時、対象URL、継続時間、誤通知、対応結果を整理し、
翌月に見直す監視条件を提案してください。
訪問者情報、IPアドレス、内部構成、認証情報は含めないでください。
監視サービスを選ぶ比較項目
特定サービス名や料金だけで決めず、次を比較します。
- HTTP・HTTPSのURL監視
- 文字・要素の確認
- SSL期限の通知
- 監視間隔
- 複数地点からの確認
- メール・電話・チャット等の通知方法
- 担当者の追加と退職時の引き継ぎ
- 履歴の保存期間
- 日本語の管理画面・サポート
- 保存されるデータと利用地域
- 契約名義と支払い管理
宿の個人アカウントではなく、引き継げる宿名義の連絡先で管理します。無料プランから試す場合も、監視数、間隔、通知方法、履歴期間が宿の用途に合うか公式案内を確認します。
誤通知を減らす
正常なのに異常と判定される原因もあります。
- 一時的なネットワーク遅延
- キャッシュやCDNによる地点差
- 監視元アクセスへの迷惑送信対策
- 動的な在庫・日付・スライド
- メンテナンス予定
- リダイレクト先の変更
誤通知が出ても監視をすぐ止めず、条件を狭めます。日付や空室数ではなく固定の見出しを確認し、一回失敗後に再確認するなど調整します。
監視してはいけないもの
- WordPress管理画面への自動ログイン
- 顧客・予約管理ページ
- 決済完了までの自動操作
- 個人情報を含む問い合わせ結果
- Basic認証や管理者パスワードを外部へ渡す設定
- 高頻度なフォーム送信
- 異常時の自動再起動・自動復元
技術担当者が合成監視を設計する場合でも、テスト環境、専用アカウント、権限、データ削除、外部サービス規約を先に確認します。
宿主さん向けチェックリスト
- [ ] トップ・予約・問い合わせ・HTTPSを候補にした
- [ ] 公開ページだけを対象にした
- [ ] HTTP状態だけでなく固定要素も確認する
- [ ] 予約確定やフォーム送信を日常監視に含めていない
- [ ] SSL期限の通知先を決めた
- [ ] ドメイン契約の更新期限と支払いも別に確認した
- [ ] 異常と復旧の両方を通知する
- [ ] 夜間を含む連絡先を決めた
- [ ] AIは調査までで、自動修復させない
- [ ] 月に一度、誤通知と監視漏れを見直す
- [ ] 契約と通知先を宿名義で引き継げる
ドメイン契約と証明書更新の管理は宿サイトのドメイン・SSL期限切れを防ぐ方法で確認できます。サイト内外のリンクと最終的な移動先をまとめて調べる場合は宿サイトのリンク切れをAIで点検する方法へ進んでください。障害通知を受けた後の行動はWordPress障害発生後の最初の30分、振り返りはAIと作る再発防止報告書、画面の自動比較はPlaywright入門を参照してください。
参考にした情報
まとめ
宿サイトの監視は、難しいサーバー管理から始めなくても構いません。まずトップ、予約、問い合わせ、HTTPSを外側から確認し、異常時に担当者へ届く仕組みを作ります。
AIは監視対象、正常条件、通知の分類、月次報告を整えられます。宿主さんは予約や料金の正しさ、通知の優先度、連絡先、自動化してはいけない操作を決めます。表示速度が継続的に悪い場合はWordPressが重い・遅い原因をAIと切り分ける方法へ進んでください。「止まらないサイト」を約束するのではなく、「止まったときに早く気づき、安全に動ける宿」を目指すことが現実的です。
