上司から「このサイトを上から順にやっていって」とサイトを渡された初日に、何から手をつけるかを書きます。
結論から書きます。最初にやるのは、前任者のヒアリングでも、画面を上から眺めることでもありません。サーバーで実際に動いているスクリプトと定期ジョブを一覧にし、「止まっても誰も気づかない自動処理」を先に特定します。
ここを飛ばすと、裏で止まったまま数か月放置される処理が出ます。表の画面には何も出ないので、担当者が代わってからもしばらく分かりません。気づいたときには、サイトの数字が落ちた理由を遡る手がかりがもう残っていない、という状態になります。
この記事は、散らかったサイトをAIで作り変えるマニュアルの、一番最初の作業です。前任者が居るうちに終わらせます。
目次
この作業で決まること
この作業が終わると、次の3つが手元に揃います。
- 作業の全数：定期ジョブ・スクリプト・一次記録・引き継ぎメモから機械で取り出した、サイトを支えている作業の一覧
- 止まっても気づかない自動処理の一覧：画面に出ないので、監視を足さないと静かに止まる処理
- アカウントと権限の持ち主：WordPress の管理者、Search Console、サーバー、DNS、計測タグ、外部APIのキー
これが揃って初めて、「サイトを直す」の話に入れます。
よくある失敗は、前任者に口頭でヒアリングしてメモを作ることです。前任者も、毎週動いている地味な処理は忘れています。記憶に残るのは失敗したことと、派手な施策だけで、網羅には使えません。
前提：この記事の前に必要なもの
- サイトが載っているサーバーへのログイン権限（SSH または管理画面）
- WordPress の管理者権限
- Search Console・解析ツール・広告アカウントの所有者からの招待
- Claude Code などの、ファイルを読んで一覧を作れるAI
前任者がまだ在席していれば、「アカウントの移管」と「サーバーの中にあるスクリプトと定期ジョブの場所」の2つだけ、先に聞いておきます。中身は読まなくてよく、置き場所だけで足ります。
AIに渡すもの
- サーバー上のスクリプト置き場のパス（例:
scripts/ディレクトリ） - 定期ジョブの設定（Linux なら cron、Mac なら launchd の
.plist） - 前任者が書き残したメモの置き場所
- やってはいけないこと：棚卸しの段階ではスクリプトを動かさない・設定を書き換えない。読むだけにする
AIに書かせるのではなく、AIにファイル名・docstring・スケジュール設定を機械で読んで一覧化させます。文章の生成は不要です。LLMを使わずに取れる情報だけで、作業の全体像は出ます。
手順
- スクリプトを一覧にする
スクリプト置き場の .py と .sh を全部拾い、ファイル名と、ファイルの先頭のdocstring1行（何をするスクリプトか）を表にします。テスト用（test_ で始まるもの）と、設定ファイル（config.py など）は除きます。
- 定期ジョブを一覧にする
cron なら crontab -l、launchd なら ~/Library/LaunchAgents/*.plist を読み、「何を」「いつ」動かしているかを表にします。実行対象のスクリプトのパスも一緒に残します。
- 一次記録を一覧にする
前任者が残した作業記録・失敗の記録・ルールファイルがあれば、タイトルと日付だけを拾います。中身は後で読みます。
- 1〜3を1枚にまとめる
種類（スクリプト／定期ジョブ／一次記録）、名前、中身の1行、頻度、ファイルの場所、を列に持つ表にします。この1枚が、以降のすべての作業の入口になります。
- 分類の空欄を見る
表に「このサイトの作業（SEO・公開・計測）か、それ以外か」の列を足します。空欄のまま残ったものが、新しく発見した作業です。
- 止まっても気づかない自動処理を印でつける
各定期ジョブについて、「止まったら誰かが画面で気づくか」を自問して印を付けます。公開に関わる処理は止まれば記事が出ないので気づきます。裏でデータを更新するだけの処理は、止まっても画面に出ません。この印が付いた処理に、次の作業で死活監視を足します。
- アカウントの持ち主を1枚にする
WordPress・Search Console・サーバー・DNS・計測タグ・外部APIのキー、それぞれの「所有者」「管理者」「請求先」を1枚にします。所有者が前任者のままになっているものを、在席中に自分へ移します。
完了条件
- ☐ スクリプト・定期ジョブ・一次記録を1枚の表にまとめた
- ☐ 定期ジョブごとに「止まっても画面に出ないか」の印が付いている
- ☐ アカウントの所有者・管理者・請求先が、前任者から自分に移っている
- ☐ 「このサイトの作業ではないもの」が、別の列として分けられている
実際に起きた失敗
頭で組んだ目次には、新人が最初にやる地味な作業が抜けていた
自分のサイトを引き継ぎマニュアルにするために、最初は失敗の記録と頭の中の構成だけで100本の目次を作りました。差し戻しが入って、「本当にやっている作業を、動いているスクリプトと定期ジョブから機械で取る」やり方に変えました。
自分のサイトで、スクリプト約290本、定期ジョブ約40本、失敗の記録134件、過去のメモ約120件を機械で一覧にしたら、594件になりました。頭で組んだ目次に無かったのは、重複記事のURL統合、テーマ移行で残ったコードの掃除、順位に依存しないサイト点検、といった毎週動いているのに失敗していないので記録に残らない作業でした。失敗の記録には「何を学んだか」しか残らず、「何の作業を毎週しているか」はスクリプトと定期ジョブにしか残っていませんでした。
もう1つ分かったのは、594件のうち277件がサイト以外（動画・SNS・メール・顧客対応）の作業だった、ということです。表に出ない作業の総量は、画面を眺めただけでは見えません。
「最終実行時刻」だけ見る死活監視では、黙って止まる処理を取りこぼす
自分の別のサイトで、自動処理の死活監視スクリプト（heartbeat.py）を作ったときの設計の話です。最初は「スクリプトが最後に動いた時刻」を見ればよいと考えました。cron や launchd の実行ログが新しければ緑、古ければ赤、という作りです。
これだと取りこぼす処理があります。処理そのものは毎日動いていても、出力ファイルが更新されていないことがあるからです。入力元のデータが古いまま、途中で例外を握りつぶして空の結果を書く、外部APIが黙って空を返す、といったケースです。ログは緑のまま、裏では古いデータが配られ続けます。
そこで heartbeat.py では、各処理について次の3つを別々に見るようにしました。
- ログの鮮度（最後に実行された時刻）
- 出力ファイルの鮮度（最後に中身が更新された日からの日数と、しきい値）
- 公開まわり専用の項目：WordPressの定期実行がロードされているか、予約投稿の時刻が過去になったまま公開漏れしていないか
赤が出たら Mac の通知で知らせます。引き継ぎ初日にこの3層を回しておくと、「表の画面には出ない停止」が見える状態で、以降の作業に入れます。
よくある質問
Q. 前任者がまだ在席していますが、何を聞けばいいですか？
A. 作業の中身は聞きません。スクリプト置き場のパス、定期ジョブの設定場所、各アカウントの持ち主、の3つだけ聞きます。中身はこちらで機械で取れます。前任者の記憶は、本人も忘れている部分があるので、網羅には使いません。
Q. 棚卸しのあと、全部のスクリプトを読む必要がありますか？
A. 最初は読みません。1枚の表ができた時点で、「このサイトの作業」の列だけに絞り、「止まっても気づかない」印の付いた処理から順に、監視を足していきます。中身を全部読むのは、監視が整ってからです。
Q. 外注先が運用している部分はどう扱いますか？
A. 棚卸しの表に「所有者：外注」の列を足し、同じ1枚に載せます。中身を見られなくても、「どのアカウント」「どの時間に」「何を更新しているか」だけは契約書や請求書から取れます。見えない処理を無いことにしないのが目的です。
関連記事
- まとめ: AIに渡す前提
- AIにSEOを任せる前に渡す4つの前提
- 全記事の台帳を作り、「今のサイト」をAIの判断の基準にする
- AI作業の失敗ログを残す仕組み
- 仕事用と個人用でAIのアカウントと情報を分ける
次の作業
- 止まっても気づかない自動処理に死活監視を足す
- AIにサイトを操作させる準備（WordPress REST API）
- AIにSEOを任せる前に渡す4つの前提
