NanoClawのTelegramが応答しない：ポーリング、権限、ランタイムの確認

NanoClawのTelegramボットが応答しなくなったとき、最初に行うのは修正ではありません — 受信メッセージがそもそもホストに到達しているかを判断することです。これは、別々に報告された2つのNanoClaw障害が、正反対の兆候で同じ訴えを引き起こすためです。一方では、送信配信とスケジュール済みタスクが動き続ける中で受信だけが停止するため、オペレーターが確認するあらゆる画面は正常に見えます。もう一方では、何も送信されず、ログには送信されていないメッセージが配信済みと記録されます。同じ訴えでも原因は異なり、一方への対処は他方には何の効果もありません。

何より先に、混同を避けるために一点説明します。この語句の検索結果は、大半が別の製品についてのものだからです。OpenClawは別の、はるかに大規模なプロジェクトです — 2026年9月21日にリポジトリAPIの記録を読み取った時点で390,207スター、ライセンスはNOASSERTIONでした。NanoClawのホームページ自体もOpenClawとの対比で位置づけています。NanoClawはnanocoai/nanoclawで、MIT、アーカイブされておらず、フォークではなく、30,818スター、1,068件のオープンissue、最終プッシュは2026年9月19日です（同日のGitHub API）。以前のqwibitai/nanoclawアドレスは301でそこへリダイレクトされるため、2つ目のプロジェクトではなく、名前変更された同じプロジェクトです。2つのプロジェクトはTelegramのコード経路を共有していません — NanoClawはchannelsブランチ（add-telegramスキル）からソースをコピーして独自のアダプターをインストールします。そのため、OpenClaw向けの対処はNanoClawには適用できません。違いの全体については、NanoClawとOpenClawの比較をご覧ください。

何かに触れる前に兆候を読む

以下の各行は、それぞれ確認方法を伴う、別個に報告された独自の障害です。8件すべてを2026年9月21日に、NanoClaw独自のissueトラッカー、同梱スキル、チャンネルドキュメントから読み取りました。

NanoClawの公式の第一段階の診断は、2つのログファイルと、ncl sessions list、ncl dropped-messages list、ncl wirings listです。リリース済みバージョンにはチャンネルの稼働状況コマンドがないため、以下の切り分けではログ行に頼ります。

# 1. Is inbound polling failing, and for how long?
#    A rising consecutiveFailures count is the #3728 signature.
grep "Telegram polling request failed" logs/nanoclaw.error.log | tail -5

# 2. Did the Telegram adapter ever register this boot?
#    Its ABSENCE is the duplicate-host signature, not an error line.
grep "Channel adapter started" logs/nanoclaw.log | tail -10

# 3. Is a second host holding the polling session?
ps aux | grep 'nanoclaw/dist/index.js' | grep -v grep
systemctl --user list-units 'nanoclaw*' --all   # Linux systemd installs

受信が停止しているのに、すべてが正常に見える理由

これは構造上の問題であり、最も時間を浪費する部分です。NanoClawのREADMEでは、経路をメッセージングアプリからホストルーター、受信データベース、コンテナ、送信データベース、そして配信へ戻る流れとして説明しています。配信は送信データベースを独立してポーリングし、それとは別に60秒ごとのホストスイープが期限到来メッセージと定期メッセージを起動します。受信だけがTelegramポーラーに依存します — だからこそissue #3728の報告者は、約4日間にわたり受信が完全に停止し、11,178回連続で失敗を記録している間も、ホストが稼働し続け、送信配信が動き、スケジュール済みタスクが実行されるのを確認しました。

検出すべきヘルスフックも機能しません。NanoClawが公開しているアダプターインターフェースリファレンスでは、isConnected()について「現在、テスト以外ではホストから呼び出されていない」、また「ブリッジは常にtrueを返す」と説明しています。その後trunkは変更されています。アダプターごとの接続フラグを報告するncl statusコマンドが、v2.3.0リリース後の2026年9月15日にmainへ追加されました。このため、ドキュメントはすべてのリリース済みバージョンについては正確ですが、trunkについては古くなっています。このコマンドは未リリースの内部機能として扱い、助言には使わないでください — 非表示かつホスト専用として登録されており、ドキュメントには記載されていません。Telegramではいずれにせよ2つの経路が合流します。アダプターの4.29.0と4.41.0のどちらもisConnectedを実装していません（このページのために両方のdistビルドをgrepしました）。そのため、プローブはどちらの場合もtrueにフォールバックします。

ドキュメントには対応する空白があります。トラブルシューティングページには「Webhook channel is silent」という見出しのセクションがありますが、ポーリングに相当するものはなく、「Agent never replies」の手順はncl dropped-messages listとともに「Did the router accept it?」から始まります。これは、メッセージがすでにホストに到達したことを前提とするステップです。ポーラーが停止している場合、ルーターがメッセージを認識していないため、探すべきドロップメッセージの行はありません。Issue #2989にも、原因が同じ行き止まりであることが記録されています。ログ行も、ドロップメッセージの行もなく、デバッグの手掛かりが何もありません。

修正バージョンはないため、それを前提に計画してください

Issue #3728はコメント0件、ラベル0件、マイルストーンなしでオープンしており、更新日時も2026年9月6日の作成日時と同じままです。最新リリースは2026年8月24日のv2.3.0で、9月1日以降のchannelsブランチ上のコミットはMattermostの修正1件だけです。古いフィルターが残るケースも同様です。明示的な更新リストを固定するプルリクエストは2026年8月22日以来channelsに対してオープンしており、現在のブランチのソースにはallowedUpdatesが一度も現れません。重複ホストのケースを防げた単一インスタンスのホストロックは、マージされないままクローズされました。したがって、誠実な位置付けはバージョン番号ではなく、緩和策です。

独自のパッチを書く前に知っておく価値のあることが3つあります。第一に、src/channels/telegram.tsをローカル編集しても保持されません。add-telegramスキルは、そのブランチが正規のものだから上書きするよう指示しつつ、channelsブランチからそのファイルをコピーします。また、updateスキルはインストール済みのすべてのチャンネルを更新します。#3728の報告者が更新のたびにその修正を失ったのは、まさにこのためです。第二に、報告者のwatchdogは手順であると同時に警告でもあります。カウンターだけを使った最初のバージョンは、より深刻な3日間の停止を引き起こしました。ポーラーが失敗するのではなく停止してしまったため、それ以上の失敗が記録されず、カウンターがしきい値に達しなかったのです。2番目のバージョンは独立した2つのシグナルを使い、ポーラーを停止状態のままにしませんでした。これらはいずれも提供済みでも、推奨済みでも、独立検証済みでもありません。第三に、何を構築するにしても、両方向の復旧をテストしてください。アウトバウンドの成功はインバウンドについて何も証明しないため、重要な確認は、ペアリング済みチャットから送信した新しいメッセージによって、新しいインバウンド行が生成されることです。

Telegramチャンネルの障害は、モデルやAPIの問題ではありません

これは明確に述べておく価値があります。次に行いがちな検索が、人々を誤った方向へ導くからです。NanoClawの認証情報ドキュメントには、TELEGRAM_BOT_TOKENのようなチャンネルトークンは.envに保存され、コンテナではなくホストプロセスによって使用されるとあります。一方、モデルの認証情報はボールトに保存され、送信リクエストにその場で注入されます。インバウンドメッセージは、プロバイダーが選択される前にルーターとセッションのインバウンドデータベースへ到達します。プロバイダーはコンテナの起動時に解決されるためです（エージェントプロバイダーのドキュメント）。ベースURL、キー、ゲートウェイ、プロバイダーの切り替えでは、停止したポーリングループ、古い更新フィルター、ポーラーの衝突、Group Privacy、壊れたIPv6経路のいずれも修復できません。

実際のクロスオーバーは逆方向です。NanoClawのREADMEは、/customize、/debug、およびすべての/add-channelスキルに必要なものとしてClaude Codeを明記しています。したがって、エージェントグループが別の環境で動作していても、チャンネルの修復にはホスト上にClaude Codeが必要です。ホスト要件はmacOSまたはLinux、WSL2経由のWindows、Node.js 22以降、pnpm 10以降、そしてDockerです。なお、nanoclaw.devは現在もNode.js 20以降と宣伝していますが、READMEとv2.3.0の変更履歴では22が最低要件になっています。引き上げをbreakingと呼んでいる変更履歴に従ってください。

NanoClawとそのTelegramチャンネルに実際にかかる費用

応答しないボットから逃れるために購入できる有料ティアはありません。この表が示す有用な点はそこです。費用が発生し始めるのは、チャンネルが再び動作し、エージェントが応答するようになってからです。以下の数値は測定済みのタスク費用でも請求上限でもない、例示的なトークン計算です。1日25ターン、1ターンあたりキャッシュされない入力20,000トークンと出力900トークンのペアリング済みチャット1件を、30日間使用すると仮定します。料金は100万トークンあたりの最新のKunavoカタログ価格です。

予算として扱う前に、自分のトラフィックに合わせて換算してください。また、最も大きく影響する仮定にも注意が必要です。何もキャッシュから提供されないという仮定です。長時間存続するエージェントセッションはコンテキストを再送するため、キャッシュの挙動は、隣接する2つのモデル間のトークン単価の差よりもこの数値を大きく動かします。Kunavoのカタログ金額は上限ではなく課金下限です。上流が料金を報告した場合、請求額はカタログ費用と、適用されるマークアップを掛けた上流費用のうち大きい方になります。最低チャージ額は前払いクレジットで$10です。これはタスク料金でもサブスクリプションでもなく、資金投入の最低額です。請求の詳細を参照してください。

この4つの選択肢のいずれもTelegram経路には影響しません。プロバイダー側の全体像、つまりセットアップが読み取る2つの環境変数、コンテナが実際に認識するもの、OpenCodeとCodexの位置付けについては、NanoClawのAPI費用とプロバイダーを参照してください。デフォルトのClaudeランタイムをカスタムエンドポイントに接続する場合は、Claude Code統合ガイドとベースURLリファレンスで設定を確認できます。キーへの資金投入の準備ができたら、Kunavoアカウントを作成できます。KunavoはNanoClawを実行時にテストしておらず、公開されたセットアップガイドは互換性テストではなく設定リファレンスです。

よくある質問

2026年9月21日確認：nanocoai/nanoclawリポジトリの記録とリリース一覧、Issue #2377、#2989、#3162、#3569、#3728、およびプルリクエスト#2225、#2697、#3449、#3460、#3570のオープン／クローズ状態、channelsブランチのTelegramアダプターソース、npmの固定版4.29.0と現行版4.41.0の両アダプタービルド、NanoClawのチャンネル、認証情報、トラブルシューティング、アダプターインターフェースのドキュメント、add-telegramおよびdebugスキル、TelegramのBot APIページを確認しました。このページの内容は、実行中のNanoClawインストールに対して実行していません。Kunavoのトークン料金は最新カタログから取得し、ドル金額は例示的なトークン計算です。