レンタルしたリモートMacでOpenClawを複数チームから使うと、スキルパック別のAPIとトークンが混線し、請求上限突破や無秩序な再試行が起きやすくなります。本稿はゲートウェイでマルチテナント予算を数え、最小権限トークンと監査ログで説明責任を残す手順です。Docker本番稿、スキル沙箱稿、Ollama批推論稿と併読してください。
痛点の整理:①カウンタがクライアント分散で合算できない ②長寿命トークンがプロジェクト横断で再利用される ③超過時の挙動が未定義で再試行が増殖する。
① 予算モデルと計数次元
まず誰の消費かをキーに埋め込みます。推奨はテナントID×プロジェクトまたはスキルパックID×上流モデル×時間窓(分・時・日)です。数える対象はゲートウェイ通過リクエスト、ツール呼び出し、推定トークン、換算コストのいずれかに統一します。Redis等にカウンタを置き、跨リージョン時はTTLを台帳化します。監査にはリクエストID、テナント、残予算、判定(許可・遅延・拒否)を必須にします。
② 設定ファイル/環境変数テンプレート
リポジトリ直下にテンプレを置き、composeやlaunchdから読み込みます。実値は秘密管理へ、テンプレのみレビューします。
# .env.example(ゲートウェイ/計数サイドカー用・例示)
GATEWAY_PUBLIC_URL=https://gw.example.internal
BUDGET_BACKEND_URL=redis://127.0.0.1:6379/0
BUDGET_KEY_PREFIX=oc:budget
DEFAULT_RPM_PER_SKILL=60
DEFAULT_TOKENS_PER_MIN=80000
FUSE_ERROR_RATE_OPEN=0.25
FUSE_ERROR_RATE_HALF=0.12
FUSE_WINDOW_SEC=60
AUDIT_LOG_PATH=/var/log/openclaw-budget-audit.log
AUDIT_RETENTION_DAYS=30
SKILL_EGRESS_ALLOWLIST_FILE=/etc/openclaw/egress.allow
各プロジェクトのデプロイキーはOC_PROJECT_API_KEYのように分離し、スコープは当該スキルパックのエンドポイントのみに限定します。
③ サーキットブレーカーと降格の方針表
開閉条件を運用で口頭に頼らず、下表のように観測信号と利用者へ見える挙動を固定します。
| 段階 | トリガ(例) | 降格・挙動 |
|---|---|---|
| 正常 | エラー率窓内・予算残あり | 全機能、通常レイテンシ |
| 警戒 | 分間トークンが上限の七割 | 非必須ツール呼び出しをキューへ |
| 半開 | 上流五〇三が連続 | 試験トラフィックのみ通過、他はキャッシュ短文 |
| 開 | 予算窓ゼロまたは誤り率超過 | 四二九とRetry-After、ローカル軽量モデルへ誘導 |
④ CI の呼び出し頻度との連携
CIには別キーと短い窓を割り当て、cronやActionsの同時実行が重ならないよう開始時刻をずらします。日中対話と共有カウンタのときはCIのバースト係数を下げるか、夜間のみ別スキルIDにします。再試行はRetry-Afterに従い、パイプライン丸ごとの再実行よりバックオフを優先します。
- CIシークレットをプロジェクト別に発行しローテ日を台帳化
- 手動dispatchの同時上限をワークフロー側で制限
- CIキー消費を週次でダッシュボード確認
- ホストTZとメンテ窓を踏まえピーク分散
- 超過アラートをチャットとメールの二経路へ
⑤ よくある超過 FAQ
問 スキルだけで上限を守れませんか。
答 迂回が残るためゲートウェイ/サイドカーで強制し、トークンは短期スコープにします。
問 見積トークンと請求がずれます。
答 usageやCSVを突合し、カウンタに保守係数を掛けるか推定と明示します。
問 サーキットが頻繁に開きます。
答 CIと手動の重複、半開試験過多、上流障害を切り分け、降格先を事前検証します。
問 監査の必須項目は。
答 時刻、主体、キーID、スキルパック、残高、判定、リクエストID。個人情報はマスクします。