> ## Documentation Index
> Fetch the complete documentation index at: https://docs.pubrio.com/llms.txt
> Use this file to discover all available pages before exploring further.

# ベストプラクティスとポーリング

> 信頼性、パフォーマンス、効率的な配信のためにモニター設定を最適化します。

## リアルタイムフリクエンシー

`frequency_minute` パラメータはモニターのスキャン頻度を制御します。

| 設定             | 動作                             | ユースケース                  |
| -------------- | ------------------------------ | ----------------------- |
| **`0`（デフォルト）** | **リアルタイム** — シグナルが現れると同時に検出・配信 | ほとんどのモニター — 最速の配信       |
| `1 - 60`       | 固定間隔（分）                        | 予測可能なケイデンスが必要な場合        |
| `60 - 1440`    | 毎時〜毎日                          | ダイジェスト形式のサマリー、低優先度のシグナル |

<Tip>
  `frequency_minute: 0` に設定すると、Pubrioはシグナルが現れると同時に検出・配信します — ポーリング不要、遅延なし。
</Tip>

***

## リトライ設定

ウェブフック配信が失敗した場合、リトライによる自動回復が可能です。

| パラメータ                   | 範囲    | デフォルト | 推奨                    |
| ----------------------- | ----- | ----- | --------------------- |
| `max_retry_per_trigger` | 0 - 3 | 1     | 重要なモニターは2-3に設定        |
| `retry_delay_second`    | 1 - 5 | 1     | 一時的な問題の解決を待つため3-5秒を使用 |

<Note>
  リトライは同じペイロードを再配信します — シグナル検出は再実行されず、追加の検索クレジットも発生しません。
</Note>

***

## プロセスリトライ

[プロセスリトライ](/jp/api-reference/endpoint/monitors/process_retry) エンドポイントを使用すると、特定の失敗した配信を再試行できます。主なメリット：

* **失敗時は課金なし** — 配信が失敗した場合、クレジットは消費されません。クレジットは成功した配信時のみ課金されます。
* **トラブルシューティング** — 失敗したログエントリを再試行して、新しいトリガーを作成せずにWebhookの問題を診断できます。
* **元の配信先オプション** — `is_use_original_destination` を使用すると、元のログの配信先スナップショットで再試行できます。障害後にWebhook URLを更新した場合に便利です。

[統計ログ](/jp/api-reference/endpoint/monitors/statistics_logs) で失敗した配信を確認し、個別に再試行してください。

***

## 障害処理

`max_failure_trigger` パラメータ（範囲：1-10、デフォルト：5）は、モニターが自動的に一時停止するまでの連続配信失敗回数を制御します。

**推奨アプローチ：**

1. 障害発生時にアラートを受信するため `notification_email` を設定
2. プロダクションモニターは `max_failure_trigger` を3-5に維持
3. [統計ログ](/jp/api-reference/endpoint/monitors/statistics_logs)を使用して障害を診断 — `error_message` と `response_status_code` を確認
4. 問題を修正後、[モニター更新](/jp/api-reference/endpoint/monitors/update)で再アクティベート
5. [プロセスリトライ](/jp/api-reference/endpoint/monitors/process_retry)を使用して特定の失敗した配信を再試行

***

## 統計エンドポイントによるポーリング

ウェブフックがリアルタイム配信を処理する一方、統計エンドポイントはモニタリング、デバッグ、監査の機能を提供します。

### オーバービューポーリング

[モニター統計](/jp/api-reference/endpoint/monitors/statistics)を使用してダッシュボードレベルのヘルスチェックを行います：

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{ "profile_id": 1 }'
  ```
</CodeGroup>

集計メトリクスを返します：モニター総数、今日と昨日のトリガー数、成功率、比較率。

### ログベースのポーリング

[統計ログ](/jp/api-reference/endpoint/monitors/statistics_logs)を使用してトリガー履歴を確認します：

<CodeGroup>
  ```bash cURL theme={null}
  curl -X POST https://api.pubrio.com/monitors/statistics/logs \
    -H "Content-Type: application/json" \
    -H "pubrio-api-key: YOUR_API_KEY" \
    -d '{
      "profile_id": 1,
      "monitor_id": "a1b2c3d4-e5f6-7890-abcd-ef1234567890",
      "page": 1,
      "per_page": 10
    }'
  ```
</CodeGroup>

各ログエントリにはステータス、クレジット使用量、シグナル/企業/人物の数、処理時間、エラー詳細が含まれます。

<Tip>
  最大の信頼性を得るために、ウェブフック配信と定期的なログポーリングを組み合わせてください：ウェブフックがリアルタイム処理を担当し、ログポーリングが見逃した配信をキャッチして監査証跡を提供します。
</Tip>

***

## スケーリングの推奨事項

<AccordionGroup>
  <Accordion title="フォーカスしたモニター vs. 広範なフィルター">
    **過度に広範なモニターよりもフォーカスしたモニターを優先してください。**「米国エンタープライズ企業のAI求人」を追跡するモニターは、「あらゆる場所のすべての求人」よりもデバッグが容易です。フォーカスしたモニターでは、異なるシグナルタイプを異なるウェブフックエンドポイントにルーティングすることも可能です。
  </Accordion>

  <Accordion title="ウェブフックエンドポイントの信頼性">
    ウェブフックエンドポイントは以下を満たすべきです：

    * 30秒以内にレスポンス
    * 即座に `200` を返し、データは非同期で処理
    * 重複ペイロードを適切に処理（冪等性）
    * デバッグのためにすべての受信ペイロードをログに記録
  </Accordion>

  <Accordion title="多数のモニターの管理">
    [モニターリスト取得](/jp/api-reference/endpoint/monitors/monitors)をフィルタリングと共に使用：

    * `detection_mode` と `destination_type` でフィルタリング
    * `last_modified` または `last_trigger_at` でソート
    * `search_term` で名前検索

    [モニター統計](/jp/api-reference/endpoint/monitors/statistics)を使用してパフォーマンスの低いモニターをすばやく特定。
  </Accordion>
</AccordionGroup>