OpenClaw のゲートウェイは、平常時はしなやかに見えます。上流の LLM ベンダーが地域全体へ HTTP 429 Too Many Requests を返し始めると一転します。プロダクトは 30 秒以内の応答を期待し、財務は請求のブレを嫌い、セキュリティはパニックログでの秘密漏えいを許しません。本稿は 24/7 の macOS Mac mini で OpenClaw を載せ、Retry-After を尊重しつつジッター付きバックオフを入れ、正直なバックプレッチャをユーザーへ返す運用者向けのランブックです。ローカルのトークンとツールのスロットル と ゲートウェイ doctor の診断手順 をセットで読んでください。スロットルはホストと財布を守り、プロバイダ側バックオフはベンダー関係を守る、という二層構えが前提です。
意思決定用のマトリクス、秒・キュー上限・ジッター割合といった数値の出発点、macOS 特有の落とし穴、チャネル UX、テレメトリ、ベンダー調整、バックオフ中のセキュリティ、そして FAQ まで、英語版の章立てを日本語で厚めに補いました。
429 を誤処理しているシグナル
ユーザーに見える返答が 400 ms 以内に二重化するのは、Retry-After を無視して同一ペイロードを即リプレイしている典型です。CPU が 40% を超えないのに p95 遅延だけが伸びるのも兆候で、詰まっているのはゲートウェイではなくモデル側のキューです。
財務と折り合いの付くカウンタは、時間あたりのプロバイダ 429 件数、実際に待った秒数の平均、放棄された会話数、「AI が遅い」タグの再オープンチケット数の四本柱です。この四系列が無いと、バックオフ変更が効いたかを証明できません。
インシデント時は機能開発を凍結し、マスク済みヘッダ（Retry-After と x-request-id）をスナップショットしてから直近のクライアント変更を巻き戻します。「ブレイクグラス」で一時的にレートを上げる場合はチケット ID を必ず紐付け、無言の引き上げが日曜の請求スパイクを生むのを防ぎます。
サポートには HTTP ステータス行そのものを記録させ、「AI が落ちた」という曖昧語だけを残さないでください。エンジニアがベンダーを呼ぶべきかローカル方針を直すべきかが分岐します。
429 の嵐の直後に 5xx が跳ねるとき、上流の絞り込みを社内障害として誤分類している可能性があります。ダッシュボードの色分けを見直してください。
デプロイマーカと相関させ、リリース 10 分以内に 429 が倍増したら、まずクライアントを戻してからベンダーチケットを開く運用が無難です。感情ではなく時系列で語れるよう、タイムラインは単一のソースに集約します。
組織が大きいほど、「一時的に並列度だけ上げた」変更が散らばり、週末に一斉に上限に達するパターンが出ます。変更管理のテンプレに「429 影響チェック」を 1 行足すだけでも効果があります。
マトリクス：Retry-After と盲目的指数バックオフ
| 戦略 | ベンダー整合 | ユーザーへの正直さ | リスク |
|---|---|---|---|
| Retry-After を尊重 | 高い | 中—待ち時間は長いが予測しやすい | HTTP-date の時計ずれによる誤解析 |
| ヘッダ無しの指数バックオフ | 低い | 低い—待ちすぎ／待ち不足の両方が起きうる | 停止復旧後のサンダリングハード |
| ジッター付きハイブリッド | 高い | 高い—明示的なキュー文言とセット | コードパスが増える |
2026 年の実務ではハイブリッドが勝ちます。Retry-After があれば従い、無ければ指数曲線へ落としつつジッターを載せ、上限は 120 秒付近で頭打ちにします。
表の「正直さ」はコピーライティングとセットです。待ち時間を数字で示せるほど、サポートの電話は減ります。逆にスピナーだけを見せ続けると、ユーザーは再送ボタンを叩き、429 を悪化させます。
監査に耐える初期数値
クライアント初期値の一例：ベース遅延 1.5 秒、倍率 2.0×、ジッター ±15%、ハード上限 120 秒、チャネルあたりの待ちターン 8 件で構造化された「混雑中」メッセージへ切り替えます。
ユーザー発話あたりの壁時計待ちは 180 秒で打ち切り、それ以上は人間のエスカレーションリンクを返して無限スピナーを避けます。メンテナンス告知があるなら、開始 15 分前から並列度を 25% 下げる先行抑制が有効です。
429 嵐のリプレイファイルでレッドチームし、合成セッションの 3% を超えてデッドロックするならキュー実装がまだ漏れています。バックオフ定数は Git で版管理し、当番がインシデント中に当て推量しないようにします。
数値はワークロードで変わります。カスタマーサポート用途は対話が長く、開発者向け CLI は短いバーストが続きます。それぞれ別テーブルを持ち、混同しないよう命名規則を分けてください。
財務レビューでは「最大待ち」と「平均待ち」を混同されやすいので、ヒストグラムの説明スライドを先に配布すると会議が早く終わります。
macOS の時計、LaunchAgent、TLS 再利用
launchd が継承するモノトニック時計はバックオフタイマーに向いていますが、HTTP-date の解析は UTC 基準の堅牢なライブラリへ寄せ、夏時間の切り替え前後は年 2 回テストします。
TLS セッション再利用が有効だと、断続的な 429 の再現が難しくなることがあります。ベンダー切り分けでは診断クライアントを時々作り直し、新しいハンドシェイクを強制してください。
共有 Mac mini ではテナントごとにプロバイダ資格情報を分離し、騒がしいワークスペースが共通クォータを焼き尽くさないようにします。ローカルのフォーク上限とは別レイヤーです。並列度の詳細は トークンとツールのスロットル記事 を参照してください。
調達が遅いときはクラウドの Mac mini を数日借り、MacHTML の Apple Silicon ホストは多くの場合 1 日約 $16.9 前後から、SSH と VNC で生ヘッダを採取しながらリハーサルできます。Linux CI だけでは拾い損ねるタイミング差分をここで潰します。
LaunchAgent の plist を複数テナントで共有していると、キーローテ後に一部だけ古い環境変数が残る事故が起きます。doctor の出力と突き合わせ、ゲートウェイ診断 のチェックリストに「plist の再読み込み確認」を足しておくと安心です。
macOS のシステム時刻が NTP で大きく跳んだ場合の挙動もシミュレーションしておくと、Retry-After の HTTP-date 解釈が将来壊れないかを先に潰せます。
すべてがキューに積もるときのチャネル UX
Slack や Teams の利用者は、理由が分かれば待てます。5 秒待った時点で定型文、30 秒でもう一段、90 秒で人間へのハンドオフリンク、という三段が無難です。
生のプロバイダ JSON をそのまま貼らないでください。内部ホスト名が混ざることがあります。多言語ワークスペースではロケールヘッダに合わせて混雑メッセージを出し分けます。
アシスタントが既にキューに入っているのに「入力中」イベントを送り続ける実装は、負荷を増幅します。タイピングインジケータもスロットルしてください。復旧後は backlog が 2 件未満になった旨を短いサマリーで知らせると信頼が戻ります。
チャネルごとに「最大待ち」の表示ポリシーを変えても構いませんが、ダッシュボード側の定義を一つに揃えないとプロダクトとサポートで数字が食い違います。
音声チャネルでは視覚的スピナーが無いため、定期的なテキスト通知がより重要になります。読み上げに配慮し、同じ文言の機械的リピートは避けてください。
テレメトリと財務に優しい指標
実際に尊重した Retry-After 秒数のヒストグラムをモデル化した遅延と比較し、乖離が 20% を超えたらパースバグを疑います。
429 率が 7 日平均の 5 倍を 10 分超えたらページングし、モデルルーティングを触る前にベンダーステータスを確認します。相関 ID でユーザーメッセージとプロバイダ request id を結び、90 日は構造化ログとして保持します。
「初回試行で回答できた率」と 429 件数を同じボードに載せ、遅延だけを追ってスループットを壊す最適化を防ぎます。四半期ごとに最長待ち上位 40 件を手で読み、自動バケットが地域ブラウンアウトをローカル不具合と誤ラベルしていないか確認します。
Grafana の注釈にバックオフ定数を触った Git マージを載せ、スパイクが意図的変更かを即断できるようにします。
コスト配賦ではテナント別の 429 件数をそのまま請求根拠にしない方が無難です。相関は示しつつ、因果の説明は別段落に分けます。
オブザーバビリティの投資は、インシデント後のポストモーテムの速度に直結します。相関 ID の命名規則を一つに決めるだけでも、夜間の調査時間が短くなります。
ベンダー調整とステータスページ
各モデルルートから公開ステータス RSS または JSON へのリンクを私的ランブックにまとめ、劣化が出た時点で 429 が来る前に並列度を 30% 削る先行抑制を入れます。数時間事故の間は 20 分ごとに単一オーナーが社内チャットへ更新し、重複エスカレーションによる追加 API 呼び出しを抑えます。
バーストクォータは書面で取り交わし、PDF をバックオフ表の隣に貼って財務が日付と整合を追えるようにします。SDK アップグレードで既定タイムアウトが変わる場合は、5% のカナリアを 24 時間流しながら 429 の差分を見ます。
ベンダーとの定例会では、429 以外のエラー分類の取り扱いもテーブル化しておくと、責任分界がクリアになります。社内ゲートウェイが誤って 429 をラップしていないかも定期的に確認してください。
契約上のクレジットが出るインシデントでは、ログの保全期間とマスク方針を先に合意しておくと、後から証跡不足で揉めにくくなります。
バックオフ中のセキュリティとコンプライアンス
429 応答と一緒にプロンプト全文をログに残さないでください。インシデントバンドルにはハッシュ化した会話 ID のみを入れ、深夜 3 時のデバッグダンプからも API キーを赤化します。
GDPR や SOC2 の監査では「絞り込みの公平性」を問われます。ブラウンアウト中にどの顧客も中央値の 2 倍を超えて待たされていないヒストグラムを用意してください。
漏えいが疑われたら共有プロバイダキーを回し、新しいキーがすべての LaunchAgent plist に行き渡るまでテナント並列を一時的に絞ります。ペネトレーションのリプレイでリトライエンドポイントを叩くスクリプトには、認証失敗にも指数バックオフを適用し、401 嵐を CPU 枯渇へ変換しないでください。
夏時間と冬時間の切り替わりには、合成の Retry-After HTTP-date を使ったリハーサルを年 2 回実施し、パーサが静かに劣化しないようにします。
インシデント中に一時的に verbose ログを上げる場合は、自動的に期限が切れるフラグを用意し、終了後に必ず戻す運用へします。人間は疲れるので機械のタイマーに寄せます。
よくある質問
プロバイダ 429 とローカル制限は同じ方針でよいですか？
いいえ。ヘッダ駆動の上流待ちと、CPU と支出を守るローカル制限は併用してください。
Retry-After が無い場合は？
ジッター付き指数バックオフで上限を 120 秒付近に置き、相関 ID をログへ残します。
物理 Mac mini でリハーサルする理由は？
macOS のスケジューリングと TLS 挙動は Linux CI と異なります。レンタルした Apple シリコンが本番に近いです。
Apple Silicon Mac mini は OpenClaw の障害リハーサルに依然として最適です。長時間キャプチャでも読みやすい熱挙動、ネイティブ Keychain、本番と揃う LaunchAgent のタイミング。MacHTML は SSH と VNC 付きのクラウド Mac mini を短い契約で提供し、429 対応・doctor プローブ・スロットルの相互作用を CapEx を増やさず検証できます。ドリルのために借り、証跡を取り、グリーンなら解放、というサイクルが現実的です。料金の目安として、Apple Silicon ホストは多くの場合 1 日あたり約 $16.9 前後から利用できる構成が並び、予算のたたき台にそのまま載せられます。
クラウド Mac mini で OpenClaw 429 をリハーサル
Retry-After ヘッダの採取、バックオフ表の調整、doctor とスロットルの相互作用を実際の macOS 上で検証できます。