本番環境で複数のOpenClawゲートウェイを運用して得られた教訓

本番環境での障害とその原因

個人利用、非営利団体、コミュニティ組織向けに3台以上のOpenClawゲートウェイを24時間365日稼働させていた開発者は、OpenClawの変更を本番デプロイではなくスクラッチ作業のように扱ったことで、繰り返し本番環境での障害を経験しました。

具体的な障害シナリオ

終わらないアップグレード: pnpm add -g openclaw@latest を実行すると、新しいバージョンが異なるパスにインストールされた一方でサービスファイルには古いパスがハードコードされていたため、ゲートウェイがMODULE_NOT_FOUNDでクラッシュしました。5分ごとに再起動するレスキュースクリプトは、一時的なクラッシュ（再起動で解決）と構造的な障害（サービスファイルの修正が必要）を区別できませんでした。

無言の機能喪失: 新しい統合を設定してゲートウェイを再起動した後、ボードアクセシビリティのためのテキスト読み上げ、メール送信、X.com投稿などの機能は設定されているように見えましたが、APIキーが間違った設定セクションにあるか、期限切れの資格情報のため、実際には壊れていました。これらの障害は数日間検出されませんでした。

根本原因分析

OpenClawゲートウェイの設定は少なくとも5つの場所に分散しています:

• メインJSONファイル
• サービスファイル内の環境変数
• Dockerフラグ
• プロバイダーブロック
• 独自の資格情報を持つスキル

1つの場所でキーをローテーションすると、他の場所は古くなります。OpenClawをアップグレードするとハードコードされたパスが壊れます。スキルを更新すると、資格情報が無言で読み込まれなくなります。これらはソフトウェア開発ではCI/CDが検出する回帰ですが、ゲートウェイインフラにはCIがありませんでした。

実装中の解決策

機能監査: 変更前後に:

• 設定を解析して宣言された機能を列挙
• 実際に動作するかライブAPIテストで検証（5秒タイムアウト）
• 前後のスナップショットを差分比較

設定検証ゲート: ライブ設定を直接編集しない:

• JSON有効性チェック
• タイムスタンプ付きバックアップ
• 危険な既知パターンをブロック

再現可能な環境:

• バージョンに依存しないサービスファイル（ハードコードされたパスなし）
• 1つの正規資格情報ファイル、他はすべてそこから派生
• クラッシュループ検出（3回の失敗 = 再起動モードではなく診断モード）

回帰検出器:

• 既知の良好なベースラインとの日次比較
• 変更を改善と劣化に分類
• 機能喪失時にアラート

開発者はこの作業を早期に共有し、他のAIインフラ運用者に問いかけています：「ゲートウェイ管理をどのように扱っていますか？」「あなたのopenclawのテスト戦略は何ですか？」