2026 OpenClaw ゲートウェイ再起動：Telegram の無音初期化、プラグイン競合、botToken 注入タイミング、古い Webhook の検証

1. 問題の境界：未初期化チャネルであり、モデル返信の沈黙ではない

本ガイドの対象は無音の非登録です。Telegram が大きなエラーを出さないまま、ゲートウェイが期待するプロバイダに到達しない状態を指します。すでにモデル HTTP 行や 429、緑のプローブに対してチャットが死んでいる場合は、チャネルオブジェクトが存在しイベントが後段で落ちている前提の チャネルプローブ緑・無返信 から着手してください。

初期化が早い段階で失敗すると、ユーザメッセージはモデル呼び出しのキューに載らないため、「プロンプトを直す」では解決しません。チケットには再起動直後の openclaw health（または同等）、telegram / provider / webhook / plugin を含む先頭 200 行程度のログ、サービスと同一 UIDで実行した config validate の証跡を添付すべきです。この三点セットが無いと、TLS ガイドなど本質と無関係な方向にエンジニアリング工数が流れます。

2. 層状検証：プローブ、ログ、validate の順

ステップ A — channels status --probe： 制御面が、プロセスが保持しているトークンで Bot API に到達できるかを示します。プローブが失敗する場合は、まずネットワーク・プロキシ・シークレットの可読性を疑い、YAML の大規模書き換えは後回しにします。

ステップ B — ゲートウェイログ： 再起動直後に「登録」に相当する文言を検索します。他サブシステムは喋っているのに該当行が完全に欠ける場合、設定がチャネルファクトリに届かなかったか、先にプラグインが異常終了した可能性が高いです。

ステップ C — config validate： スキーマエラーや壊れた SecretRef パスはここで検出します。ビルドによってはシークレット欠落が「チャネル一覧に出ない」程度に飲み込まれ、tcpdump より検証コストが低いです。

openclaw channels status --probe
openclaw config validate
journalctl --user -u openclaw-gateway -n 200   # systemd 例
# launchd: StandardOutPath の確認 / サービスラベルに対する log stream

3. plugins.load 最小化を A/B のレバーにする

起動時に例外を投げるプラグインは、デフォルトのログレベルでは静かなまま下流アダプタの登録を妨げることがあります。openclaw.json（またはパックのパス）をスナップショットしたうえで、plugins.load を空リストまたは既知の最小集合にし、ゲートウェイを再起動して health に Telegram が戻るか確認します。戻るならプラグインを一つずつ戻し、再現する組み合わせを特定します。フリート向けに「勝ち順」を文書化しておけば、次回アップグレードで順序が盲信的に入れ替わるのを防げます。

これは登録後の沈黙とは異なります。ここではルータがそもそも Telegram プロバイダオブジェクトを立てていないため、ユーザメッセージはツール層やモデル層に届きません。

4. botToken：平文、環境変数、監督下での SecretRef

現場では三パターンが多いです。インラインのトークン（速いが危険）、TELEGRAM_BOT_TOKEN 系のエクスポート変数、実行時に読むファイルバックのSecretRef。systemd --user では、EnvironmentFile= が ExecStart より前に適用されていない、ユニット編集後の daemon-reload 忘れ、対話シェルのユーザーとサービスユーザーが異なる、といった失敗が支配的です。結果、手動の openclaw gateway は成功するが監督下の再起動ではトークンが空で Telegram が静かにスキップされます。

systemctl --user show <unit> -p Environment（または launchd の launchctl print 相当）で、上流障害を疑う前にトークンが存在することを証明してください。インストールと doctor の資料で監査した認証ツリーと HOME を揃え、再起動後も SecretRef の相対パスが一貫して解決するようにします。

5. トークン更新と古い Webhook

BotFather がトークンを回した場合、古いトークンが死んだエンドポイントを指す Webhook URL を握っていることがあります。推奨手順はゲートウェイを停止 → 新トークンで Telegram の deleteWebhook（またはチームがラップした CLI 相当）を呼ぶ → getWebhookInfo がクリーン、または現行の入口と一致することを確認 → ゲートウェイを起動し、リリース文書の再ペアを繰り返す、の順です。deleteWebhook を飛ばすと、ローカルでは「設定済み」に見えても Telegram は応答しない URL に配信し続け、クライアント側のノイズは意外と少ないままです。

ロングポーリングと Webhook を行き来する場合は、ビルドのリリースノートに従い、完全停止なしにモードを混ぜると、無音初期化に似た競合が出ます。

6. 関連記事

ベースラインのインストールと doctor の流れ：OpenClaw インストールとトラブルシューティング 2026。アップグレード後のペアリングとバージョン整合：切断されたゲートウェイとペアリングのランブック。Telegram が登録されたあとは 緑プローブ・無返信 に戻り、モデル側スロットリングや二重トグルを扱います。launchd と systemd の常駐とユニット衛生：デーモン再インストールと linger のランブック。

7. よくある質問