OpenClawのリトライポリシーを設定する

ネットワークのリクエストは、時として予期せぬエラーで失敗します。APIのレート制限や一時的な接続エラーに直面するたび、手動でリトライ処理を実装するのは非常に面倒な作業です。

信頼性の高いシステムを構築するためには、賢いリトライ戦略が欠かせません。OpenClawのリトライポリシーを使えば、複雑なフローを壊すことなく、個別の HTTP リクエストに対して自動的に再試行を行うことができます。

必要なもの

• ~/.openclaw/openclaw.json へのアクセス権

クイックスタート

OpenClawのリトライポリシーは、HTTP リクエスト単位で動作します。マルチステップのフロー全体をやり直すのではなく、失敗したそのステップだけを再試行するため、処理の順序が崩れる心配はありません。

設定は ~/.openclaw/openclaw.json ファイルで行います。以下の設定をコピーして、必要に応じて値を調整してください。

{
  channels: {
    telegram: {
      retry: {
        attempts: 3,
        minDelayMs: 400,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
    discord: {
      retry: {
        attempts: 3,
        minDelayMs: 500,
        maxDelayMs: 30000,
        jitter: 0.1,
      },
    },
  },
}

デフォルトでは以下の設定が適用されます。

• 最大試行回数: 3回
• 最大遅延キャップ: 30000 ms
• Jitter: 0.1 (10%)

Behavior

プロバイダーによってリトライの挙動が異なります。

Discord

• レート制限エラー（HTTP 429）が発生した場合のみリトライします。
• Discord の retry_after が利用可能な場合はその時間に従い、そうでない場合は指数バックオフを使用します。

Telegram

• 429 エラー、タイムアウト、接続リセット、一時的な利用不可などの一時的なエラーでリトライします。
• retry_after がある場合はそれに従い、ない場合は指数バックオフを使用します。

トラブルシューティング

Telegram で Markdown のパースエラーが発生する

Markdown のパースエラーはリトライの対象外です。このエラーが発生した場合、システムは自動的にプレーンテキストにフォールバックして送信を試みます。

完了済みのステップが重複して実行される

リトライは HTTP リクエスト（メッセージ送信、メディアアップロード、リアクション、投票、ステッカーなど）ごとに適用されます。複合的なフローにおいて、すでに完了したステップがリトライによって重複して実行されることはありません。

設定や導入に関する個別の質問がある場合は、AI Setup Assistant を活用してください。

次のステップ

• Provider Configuration
• Message Templates