📚 ナレッジベース
04-10_トラブルシューティング
最終更新 2026年08月25日 ／ 21_ナレッジベース/マニュアル_ナレッジ/制作部署/04-10_トラブルシューティング.md
出典: 制作部署マニュアル トラブルシューティング（自動ミラー・正本は /Users/oogushiyuuki/manual-terasu）
このPhaseのゴール
公開後・運用中に発生するよくある問題と緊急事態への対応マニュアル。困った時にここを開けば解決できる、TERASU の医務室的存在。
トラブルは必ず発生する。「想定済み・対応手順あり」の状態を作っておけば、信頼を失わずに乗り切れる。
トラブル対応の基本フロー
1. 発生・検知
2. 一次切り分け（どこの問題か）
3. 顧客への一次連絡（影響範囲・対応中の旨）
4. 原因特定
5. 対応・復旧
6. 顧客への完了連絡
7. 再発防止策の策定
8. ナレッジ化（このマニュアルに追記）
→ 最重要：顧客への報・連・相。技術より対応速度が信頼を決める。
よくある問題と解決法
1. サイトが見られない（500/503エラー・接続不可）
一次切り分け
- 別のデバイス・ネットワークで確認（自分だけの問題？）
- Cloudflare ステータス 確認
- ドメイン期限切れ確認
- DNS伝搬確認（whatsmydns.net）
対応
- Cloudflare 障害 → 待つしかない・顧客に状況連絡
- ドメイン期限切れ → 即更新
- DNS問題 → DNS設定確認・修正
2. SSL証明書エラー
症状
- 「保護されていない通信」警告
- 鍵マーク赤
- ブラウザが「接続を拒否」
対応
- Cloudflare SSL設定確認（Full/Strict推奨）
- 証明書発行状況確認（Active 状態か）
- DNS伝搬完了確認
- キャッシュクリア
- 1-2時間で自動回復することが多い
3. Mixed Content（混在コンテンツ）警告
症状
- ブラウザのコンソールに警告
- 一部画像・CSSが表示されない
対応
- F12 → Console で http:// 始まりのリソースを特定
- https:// に書き換え
- 相対パスに変更（/image.jpg）も可
4. ファビコンが表示されない
原因
- ブラウザキャッシュ
- favicon.ico の配置ミス
- 拡張子の問題
対応
- ハードリロード（Cmd+Shift+R）
- シークレットモードで確認
<link rel="icon">タグ確認- パスが正しいか（絶対パス推奨）
5. 検索結果に出てこない（インデックスされない）
確認手順
- Search Console → URL検査
- 「インデックス未登録」と表示？
- 原因を確認：
-robots.txtで Disallow されてる？
-<meta name="robots" content="noindex">がある？
- 公開してから日が浅い（〜2週間）？
対応
- robots.txt 修正
- noindex 削除
- URL検査でインデックスリクエスト
- 1-7日待つ
6. 順位が上がらない
確認
- 公開から何ヶ月？（3-6ヶ月かかるのが普通）
- メインKWの競合性は？
- コンテンツの量・質は十分？
対応
- 競合上位3記事の分析
- リライト（情報追加・独自性強化）
- 内部リンク追加
- 被リンク獲得施策
7. 流入が急減した
切り分け
- GA4で「いつから」「どのチャネル」「どのページ」が急減？
- Search Console で順位変動確認
- アナリティクスタグの動作確認
原因パターン
| 症状 | 原因可能性 |
|---|---|
| 全チャネル一気に減 | アナリティクスタグ剥がれ・サイトダウン |
| Organicだけ減 | コアアップデート・ペナルティ |
| Direct増 | キャンペーン効果 |
| Social減 | SNS投稿停滞 |
対応
- タグ動作確認（GA4 リアルタイム）
- Search Console でペナルティ通知確認
- 業界全体の動向確認（namaz.jp等）
8. フォーム送信が届かない
切り分け
- 自分でテスト送信
- メール届く？届かない？
原因
- フォーム設定ミス
- 送信先メールアドレス間違い
- 迷惑メールフォルダに振り分け
- SPF / DKIM / DMARC 未設定
- フォームサービス障害（formrun等）
対応
- テスト送信
- 迷惑メールフォルダ確認
- 送信先メアドの正確性確認
- SPF / DKIM / DMARC 設定（Google Workspace等）
- フォームサービスのサポート確認
9. 画像が表示されない
原因
- パス間違い（相対 vs 絶対）
- ファイル名のスペル
- 大文字小文字（Linuxサーバーは区別）
- 画像形式（WebP対応してない古いブラウザ）
対応
- F12 → Network で 404 確認
- パス・ファイル名修正
- WebP の場合は JPG/PNG フォールバック追加：
<picture>
<source srcset="/image.webp" type="image/webp">
<img src="/image.jpg" alt="...">
</picture>
10. ページ表示が遅い
計測
- PageSpeed Insights
- 改善ポイント確認
よくある原因と対応
| 原因 | 対応 |
|---|---|
| 画像サイズ大 | WebP化・圧縮・lazy load |
| 不要なJS | 削減・async/defer |
| 大量のフォント | 必要分のみ・preload |
| サードパーティスクリプト | 最小化・遅延読込 |
| サーバー応答遅い | Cloudflare CDN利用 |
11. レスポンシブ崩れ（モバイル表示）
確認
- F12 → Device Toolbar → 各サイズで確認
- 実機（iPhone・Android）
対応
- viewport meta タグ確認
- CSS の media query 修正
- 横スクロール発生箇所特定（要素の幅オーバー）
- overflow-x: hidden を body に（最終手段）
12. お知らせ・実績の追加依頼対応
受付フロー
- クライアントからメール or Slack
- 情報確認（タイトル・本文・画像・公開日）
- 制作（30分-1時間）
- プレビュー確認 → クライアント確認
- 公開
- 完了報告
SLA：翌営業日対応
緊急対応マニュアル
A. サイトダウン（500エラー・全ページ表示不可）
緊急度： 最高
対応フロー
1. 検知（モニタリングツール / 顧客報告 / 自社チェック）
2. 一次切り分け（3分以内）
- 自社確認
- Cloudflare ステータス確認
- DNS確認
3. 顧客への一次連絡（5分以内）
「サイトに接続できない事象を検知しました。
現在原因調査中です。
判明次第ご連絡いたします。」
4. 原因特定（30分以内）
5. 復旧作業
6. 動作確認
7. 顧客への完了報告
「○時○分に復旧しました。
原因は○○、対策として○○を実施しました。」
8. 事後報告書作成（24時間以内）
事後報告書テンプレ
■ 障害概要
- 発生日時：
- 復旧日時：
- 影響範囲：
■ 原因
- 直接原因：
- 根本原因：
■ 対応内容
- 一次対応：
- 復旧作業：
■ 再発防止策
- 短期：
- 長期：
■ 影響の補填（必要なら）
- 月額の日割り返金等
B. 改ざん検知
緊急度： 最高
改ざんパターン
- マイニングスクリプト挿入
- フィッシングサイト埋め込み
- スパムリンク大量挿入
- 内容差し替え
対応フロー
1. 即座にサイト公開停止（Cloudflare Pages 一時停止）
2. 顧客への緊急連絡
「サイト改ざんの疑いを検知し、一時公開停止しました」
3. 原因調査
- 管理画面パスワード漏洩？
- 第三者ライブラリの脆弱性？
- サーバー設定？
4. クリーンなバックアップから復元
5. パスワード一斉変更
6. セキュリティパッチ適用
7. 動作確認
8. 公開再開
9. 事後報告書作成
10. 必要なら警察・専門機関連絡
C. データ漏洩疑惑
緊急度： 最高
漏洩の例
- お問い合わせフォーム経由の個人情報
- 管理画面ログイン情報
- 顧客リスト
- 決済情報（あれば）
対応フロー
1. 影響範囲特定
- 何が漏れた可能性？
- 何件分？
2. クライアントへの即時連絡
3. 影響対象者リストアップ
4. 個人情報保護委員会への報告
（72時間以内・漏洩規模により）
5. 弁護士連絡
6. 公表判断（規模・影響により）
7. 被害者への通知
8. 原因究明・再発防止
9. プレスリリース（重大なら）
法令遵守
- 個人情報保護法 改正（2022年）
- 個情委への報告義務（漏洩規模1,000人超等）
- 被害者への通知義務
D. Google ペナルティ
検知
- Search Console → セキュリティと手動による対策
- 「手動による対策」に通知が来る
ペナルティの種類
| 種類 | 内容 |
|---|---|
| 手動ペナルティ | Google担当者の判断 |
| アルゴリズムペナルティ | 自動判定（コアアップデート等） |
対応フロー
1. Search Console通知を確認
2. 違反箇所の特定
3. 違反箇所の修正
4. 再審査リクエスト送信
5. 通常2-4週間でGoogleから返答
6. 解除されない場合は再修正→再申請
E. DNS切り替え失敗
緊急度：高
状況
- 新ドメインへの切り替え時にサイト見えなくなった
対応
- 直前の DNS 設定を確認（変更履歴）
- ロールバック（元の設定に戻す）
- TTL 確認（短くしてあれば反映早い）
- DNS伝搬待ち
- 顧客への状況連絡
予防
- DNS変更前に TTL を300秒に下げる
- 変更は深夜・休日に
- バックアップ保管
トラブル防止のための予防策
モニタリング設定
サイト監視サービス（無料）
- UptimeRobot：5分ごとに監視・Slack通知
- StatusCake
- Cloudflare Insights（有料機能）
自社で設定
# 簡易ヘルスチェック（5分ごとにcron）
*/5 * * * * curl -sS -o /dev/null -w "%{http_code}" "https://example.com/" | grep -v 200 && echo "DOWN" | mail -s "ALERT" admin@scale-group.co.jp
バックアップ運用
- 月次でフルバックアップ（手動でも）
- 大幅変更前は必ずバックアップ
- バックアップは別場所に保管
セキュリティ
- パスワード強度（12文字以上・記号含む）
- 2段階認証ON
- 最終ログイン日確認
- 不要アカウント削除
連絡フロー（社内）
エスカレーション
クライアント問い合わせ
↓
担当PM（30分以内に一次対応）
↓
解決できない場合 → 制作担当に相談
↓
それでも解決できない → 大串
↓
緊急時（サイトダウン等） → 直接大串
Slack 緊急チャンネル
#terasu-emergency：緊急時のみ- メンション：@大串 @制作リード
クライアント連絡のテンプレ
一次連絡（問題検知時）
○○様
お世話になっております。
TERASUの○○です。
○○の事象を検知いたしました。
▼ 状況
- 発生時刻：
- 影響範囲：
現在原因調査・対応中です。
解決次第、改めてご連絡いたします。
ご不便をおかけしますが、何卒よろしくお願いいたします。
復旧連絡（解決時）
○○様
先ほどお伝えした○○の事象について、復旧いたしましたのでご報告いたします。
▼ 復旧情報
- 復旧時刻：
- 原因：
- 対応内容：
▼ 再発防止策
- ○○
詳細な事後報告書は別途お送りいたします。
ご心配・ご不便をおかけし、誠に申し訳ございませんでした。
今後とも何卒よろしくお願いいたします。
Phase 10 トラブル対応 チェックリスト
予防的に整備すべきもの
- [ ] サイト監視（UptimeRobot 等）設定
- [ ] バックアップ運用ルール確立
- [ ] パスワード強度・2段階認証
- [ ] セキュリティパッチ適用
- [ ] Slack 緊急チャンネル
- [ ] 顧客連絡先一覧
- [ ] 弁護士・専門機関の連絡先把握
トラブル発生時の確認
- [ ] 一次切り分け完了
- [ ] 顧客への一次連絡完了
- [ ] 原因特定
- [ ] 復旧
- [ ] 顧客への完了報告
- [ ] 事後報告書作成
- [ ] 再発防止策
- [ ] ナレッジ追記
トラブル時の絶対NG
| NG | 結果 |
|---|---|
| 顧客への一次連絡を遅らせる | 信用喪失 |
| 「自分で解決してから報告」 | 状況が悪化する可能性 |
| 原因不明のまま「直りました」 | 再発する |
| 事後報告書なし | 信頼回復できない |
| 同じトラブルを2回繰り返す | 致命的 |
| 改ざん・漏洩を隠蔽 | 法的責任・契約解除 |
ナレッジベース化
このマニュアルへの追記
新しいトラブルパターンが発生したら：
■ 追記項目
- 症状
- 切り分け方法
- 原因
- 解決策
- 予防策
→ 同じトラブルを2度起こさないために。
Slack に「ナレッジチャンネル」
#terasu-knowledge：解決事例をストック。
参考資料・連絡先
公式ドキュメント
専門機関連絡先
- 個人情報保護委員会：03-6457-9849
- IPA（情報処理推進機構）：03-5978-7503
弁護士
- スポット相談：弁護士ドットコム / 弁護士.com
- 顧問契約：要検討
トラブル対応の質 = ブランドの強さ。
起きないように予防し、起きたら誠実に対応。それだけ。