時間のアルゴリズムはどう、オフライン処理に適用されているか？

時間のアルゴリズムとは — 4つの基本概念

「時間のアルゴリズム」は学術的にはスケジューリング理論と呼ばれ、複数のタスクを限られた資源（CPU・帯域・クローラー数）でいつ実行するかを決定する数学的枠組みです。Google検索のインフラもこの理論で動いています。

Googleのインデックス処理 — リアルタイムとオフラインの組み合わせ

Googleのインデックスは単一のシステムではなく、複数の階層で動いています。それぞれが異なる「時間アルゴリズム」で動作しています。

1. クロール（リアルタイム寄り）

• Googlebotのクロール: 各URLに対して個別の頻度設定（クロールバジェット）を持つ。重要URLは数分〜数時間、低優先度URLは数週間〜数ヶ月
• クロール時刻の意図: ニュースサイトは午前中、ECは早朝、ブログは深夜など、コンテンツ更新パターンに合わせて学習
• Yahooリアルタイムサーチの影響: Yahoo経由でクローラーがコンテンツ更新を検知すると、Googlebotの再クロール頻度が上がる現象あり

2. インデックス処理（オフライン寄り）

• Caffeineインフラ: 2010年導入、継続的に索引を更新する。ただし「即時反映」ではなく数分〜数時間の遅延あり
• シャード更新: 巨大な索引は複数のシャードに分割され、シャードごとに更新タイミングが異なる
• 「クロール済みインデックス未登録」の正体: クロールは済んでいるが、インデックス処理キューで保留されている状態

3. ランキング処理（完全オフライン）

• PageRank再計算: 月単位の周期で全グラフを再計算（コアアップデートのタイミングと重なる）
• SpamBrain判定: バッチ処理で疑わしいサイトを検出。即時ペナルティではなく次回更新時に反映
• コアアップデート展開: 1〜2週間のロールアウト期間中、徐々に新評価モデルが適用される

EDF（最早期限優先）アルゴリズムの仕組み

EDF（Earliest Deadline First）はリアルタイムOSやクラウドスケジューラーの古典的アルゴリズムです。Liu & Layland（1973）により単一プロセッサ環境では最適であることが数学的に証明されています。

// EDFスケジューリングの擬似コード
function edfSchedule(tasks) {
  // 各タスク: { id, deadline, executionTime }
  while (tasks.length > 0) {
    // 締切が最も近いタスクを選択
    const next = tasks.sort((a, b) => a.deadline - b.deadline)[0];
    execute(next);
    tasks = tasks.filter(t => t.id !== next.id);
  }
}

// Googlebotクロールでの応用
const crawlTasks = [
  { url: '/news/breaking', deadline: 5 },     // ニュースは即時
  { url: '/blog/old-post', deadline: 86400 }, // ブログは1日後でOK
  { url: '/products/new', deadline: 3600 },   // 新商品は1時間以内
];
// EDFが /news/breaking → /products/new → /blog/old-post の順で処理

計算量はO(log n)（ヒープ構造使用時）。タスク数が数千でも高速動作するため、Googleのクロール優先度判定にもこの考え方が応用されています。

「クロール済みインデックス未登録」の時間アルゴリズム的解釈

Search Consoleで頻出する「クロール済み — インデックス未登録」というステータス。多くのWEBディレクターが「ペナルティか?」と不安になりますが、時間アルゴリズム的には「優先度キュー上の保留状態」と理解するのが正しい見方です。

WEB運営でのスケジューリング思考 — 実装手順5つ

時間アルゴリズムの考え方を、自サイト運営に落とし込む手順:

1. バッチ処理の活用（オフライン化）: sitemap.xml再生成、画像最適化、ログ集計など即時性が不要なタスクは深夜2:00-5:00のバッチウィンドウへ。サーバー負荷を平準化し、ユーザー応答を高速化
2. EDF的優先順位設定: 「コンテンツ強化を頑張る」では曖昧。「コアアップデート完了から2週間以内に影響ページTop10を改修」と締切＋件数で表現すると自然に動ける
3. 更新タイミングの戦略化: 重要記事は午前9:00〜11:00公開。Yahoo・X・SNSのアクティブ時間帯と重なり、初動シグナルが取りやすくなる
4. 監視周期の最適化: サーバー監視5分間隔、デイリーレポート1日1回、コンテンツ鮮度チェック月1回。Cron + 監視ツールで「気づき遅れ」を防ぐ
5. インデックス保留の中長期管理: Search Consoleの「クロール済み・インデックス未登録」を月次でレポート化。3ヶ月超のURLは削除/統合/強化のいずれかを必ず判断

主要なクロール頻度の実例 — サイトタイプ別

Googleがクロール頻度をどう決めているか、業界別の傾向:

クロール頻度を上げるには: 更新リズムを一定にする・sitemapの<lastmod>を正確に出す・内部リンク密度を上げる・重要記事への外部リンク獲得。「頻度が上がる→インデックス反映が早まる→検索流入増」の好循環が生まれます。

類似スケジューリング技術との比較

Caffeineインフラとシャード更新の仕組み — 技術詳細

Googleの主要インデックス基盤Caffeine（2010年6月導入、現行は後継のIndexerが稼働）は、従来のバッチ処理型インデックスと違い、継続的に断片単位で索引を更新する分散システムです。この仕組みを理解すると「なぜ反映タイミングがバラつくのか」が腑に落ちます。

シャード更新のタイミングは、シャードに含まれるURLの「重要度」「更新頻度」「クロール頻度」を総合判定して決まります。ニュース・トレンド系のシャードは数分〜数時間、企業静的サイト系のシャードは数日〜数週間の周期で更新されます。これが「同じ日に公開した2つの記事のインデックス反映タイミングがズレる」理由です。

バッチウィンドウ設計 — WEB運営での実装手順

「バッチウィンドウ」とは、サーバー処理を集中させる時間帯のこと。WEB運営では、ユーザーアクセスが少ない深夜帯にバッチ処理を寄せるのが基本戦略です。

典型的なバッチウィンドウ設計（中規模サイト想定）

# crontab 設定例
# === 深夜バッチウィンドウ 02:00-05:00 ===
0  2 * * * /usr/local/bin/sitemap-generate.sh    # sitemap.xml再生成
30 2 * * * /usr/local/bin/image-optimize.sh      # 画像最適化バッチ
0  3 * * * /usr/local/bin/db-backup.sh           # DB バックアップ
30 3 * * * /usr/local/bin/log-rotate.sh          # ログローテーション
0  4 * * * /usr/local/bin/cache-warmup.sh        # キャッシュウォームアップ
30 4 * * * /usr/local/bin/llms-txt-generate.sh   # llms.txt 再生成

# === 早朝レポート時間 06:00-08:00 ===
0  6 * * * /usr/local/bin/seo-monitor.sh         # SEO定点観測
0  8 * * * /usr/local/bin/daily-report.sh        # デイリーレポート

負荷分散の効果 — 計測値の例

バッチウィンドウ設計の実装手順 — 5ステップ

1. 処理タスクの棚卸し: 現在動いているcron / スケジュール処理を全リストアップ。「即時性必須」「日次でOK」「週次でOK」に分類
2. 依存関係の整理: 「DBバックアップ → ログローテ」「sitemap生成 → IndexNow送信」など、順序のある処理を線形化
3. 実行時間の計測: 各タスクの実行時間を計測し、合計時間を把握。3時間ウィンドウに収まるか確認
4. ウィンドウ配置: 02:00-05:00 など低トラフィック帯に集約。重い処理は最初に、軽い処理を後ろに
5. 監視設定: 各タスクの完了通知（Slack / メール）を設定。失敗時に翌朝までに気づける体制

実例 — オフライン処理が見える3つの「Search Console異常」

1. 「最終データ更新日より1日先のデータ」: バッチ処理で前倒し集計が走った結果。リアルタイムシステムなら起きえない現象
2. 「URL検査」と「カバレッジ」のステータス不一致: 前者はリアルタイム取得、後者はバッチ集計。タイミングのズレが原因
3. 「コアアップデート期間中の不規則な順位変動」: 複数バッチが並行展開され、シャードごとに異なる評価が一時的に共存する

これらは「バグ」ではなく「複数の時間アルゴリズムが並走している正常な挙動」。理解していれば慌てずに済みます。

📌 関連コンテンツ

• 📰 リアルタイムに近い検索結果にGoogle検索が進化 — Search Console時刻ズレの背景
• 📰 2026年3月コアアップデートでデータベースがリセットされた — オフライン処理の実例
• 🔧 Google対策チェッカー — インデックス状況をリアルタイム確認
• 🔧 WEBサイト総合分析ツール — クロール最適化の総合診断
• 📝 Search Consoleが教えてくれること — データを読む力
• 📝 "何も起きていない"は、本当に安全か — 沈黙のリスクと監視周期
• 📝 "仕組み"を作れるWEBディレクターになれ