トップ／プロダクト／手動でクロール実行

手動でクロール実行

このページでできること

選択中プロダクトの「全 URL 数 / 当日クロール済み / 当日未クロール」を確認できます。
本日未クロールのみ・全 URL 再クロール・一覧から選択した URL のみの 3 通りで手動クロールを開始できます。
ブラウザ上でリアルタイム進捗（SSE ストリーミング）を確認しながら完走できます。
クロール間隔と（pending / all モード向けの）件数上限で負荷を制御できます。

URL: pages/run.php?product_id=<id>。サイドバーの「プロダクト → 手動でクロール実行」から開きます。システム管理者・プロダクト管理者の両方がアクセスできます。

登録 URL の状況（カード①）

本日（JST 日付）時点で、このプロダクトの登録 URL がどこまで処理済みかを 3 つの数字で表示します。

項目	意味	計算元
事前登録 URL（全件）	このプロダクトに登録されている URL の総数	`Repository::countUrls()`
本日クロール済み	当日 (JST) すでに `crawl_results` に行がある URL の本数	`Repository::countUrlsCrawledOnDate()`
本日未クロール	「全件 − 本日クロール済み」	計算値

日付の判定は JST（日本時間）です crawl_results.created_at は UTC で保存されています。「本日クロール済みか」は date(created_at, '+9 hours') で JST に補正して比較します（データベース設計参照）。

クロール設定（カード②）

クロール間隔（秒）

0〜60 秒の範囲。既定 5 秒。
2 件目以降の URL を取得する前に sleep(N) を挟みます。長時間クロール中は SSE の : ping コメント行も 1 秒ごとに送出し、プロキシの idle timeout を防ぎます。

1 回のクロール件数の上限

無制限（既定）：対象 URL をすべて処理。件数が多くても SSE 経由ならブラウザを開いたまま進捗を追えます。
上限を指定：1〜100,000 件。mode=pending / mode=all のときだけ先頭 N 件に array_slice() します。
「URL を選んで再クロール」（mode=selected）では上限を適用しません。チェックした件数がそのまま全件処理されます。

3 つの実行モード

ボタン / モード	挙動	典型的な使いどき
本日未クロールの URL のみ（`pending`）	`listUrlsNotCrawledOnDate()` の URL のみ。同日の二重取得を避ける推奨モード。	cron 補完・新規 URL の即時取得。
全 URL を再クロール（`all`）	`listUrls()` の全件。当日済み URL も再取得。	サイト改修後の全体再評価・ロジック更新後の再解析。
選択した URL を再クロール（`selected`）	下の一覧でチェックした `product_urls.id` のみ。`listUrlsByIds()` で解決。	特定パスのみ再取得・改修ページのピンポイント確認。

URL を選んで再クロール（一覧 UI）

登録 URL が 1 件以上あるとき、フォーム下部に選択用テーブルが表示されます。

URL で絞り込み：部分一致（クライアント側）。
最終クロール日 (JST)：すべて / 未クロールのみ / 本日 / 本日以外 / 日付指定 / 指定日時以前（datetime-local）。
並び順：登録順・URL 昇降順・最終クロール日・未クロール優先。
表示中をすべて選択／解除、ヘッダチェックボックス。
列：URL、最終クロール (JST)（UTC → JST 変換表示）、HTTP（直近ステータスのバッジ）。
選択 ID は hidden の url_ids_csv にカンマ区切りで詰めます（max_input_vars 対策。旧フォームの url_ids[] もサーバ側フォールバック対応）。

ストリーミング実行（通常経路）

JavaScript 有効時は、フォーム送信をインターセプトして pages/run_stream.php へ fetch() します（画面自体の UI は run.php のまま）。

run_stream.php（SSE）

Content-Type: text/event-stream、X-Accel-Buffering: no でバッファリングを抑止。
イベント：start（run_id 確定）→ 各 URL ごとに progress → 完了時 done。致命的エラーは error。
処理本体は Crawler::run() の onProgress / onHeartbeat / onRunStart コールバック経由。
開始前に Auth::releaseSession() でセッションロックを解放し、他タブの操作をブロックしません。
fatal 時は register_shutdown_function で可能な限り event: error を送出。

run_status.php（JSON ポーリング）

SSE 接続が途中で切れたとき、クライアント JS が GET run_status.php?run_id= をポーリングし、サーバ側でクロールがまだ走っているか／完了したかを確認します。

認証は requirePageAccess('run') と同じ。run が現在選択中プロダクトのものであることを検証（他プロダクトの run は 403）。
返却例：done / total_urls / is_finished / last_result_at など。

画面上の進捗表示

実行中はプログレスバー・現在処理中 URL・成功／エラー件数・Run #ID が更新されます。完了後は結果テーブル（URL / HTTP / 状態）と、結果一覧・エラー URL 管理へのリンクが出ます。

フォールバック（JavaScript 無効時）

通常はクライアント側 JS がストリーミングを担当するため、run.php への同期 POST は JS 無効環境向けのフォールバックです。この経路では件数が多いと Web サーバ／リバプロのタイムアウトに当たりやすいため、上限を強めに抑え、JS 有効化を案内します。

クロールの内部動作

モードに応じて URL 配列を作成（pending / all / selected）。
（pending / all のみ）上限指定時は array_slice()。
crawl_runs に 1 行 INSERT（trigger='manual'）。
プロダクト設定を読み込み：breadcrumb_selectors、disabled_detection_types（メタ情報・検出設定）。
各 URL を PageFetcher → SchemaAnalyzer で解析し crawl_results へ INSERT。
完了後 crawl_runs を UPDATE。

長時間のクロールに注意 処理時間の目安は (対象件数) × (クロール間隔) ＋ (各 URL の取得時間)。大量 URL は Cron スケジュールの「1 回あたり URL 上限」と毎時の cron 自動実行の併用を推奨します。

cron との関係 手動の pending と cron は同じ listUrlsNotCrawledOnDate() を共有します。cron が処理した URL は手動の「本日未クロール」件数からも減ります（cron 自動実行参照）。