OpenClawのトラブルシューティング完全ガイド｜Slackで返信が来ない4つの原因と対処法

OpenClawでSlackからClaude Codeが返信しなくなった場合、原因は4つのパターンに絞られます。それぞれ症状が異なり、ログを読むことで原因のパターンを特定できます。

「ゲートウェイは動いているはずなのにSlackが無反応」「cronジョブの結果が届かなくなった」「しばらく前まで動いていたのに突然返信が来なくなった」——こうした問題に直面したことがある方は少なくないはずです。

この記事では、実際のOpenClaw運用で発生したトラブルをもとに、ログの読み方から各パターンの解消手順まで具体的に解説します。

OpenClawとは？Slack連携の仕組みをおさらい

OpenClawとは、Claude CodeなどのAIエージェントをSlack・WhatsApp・Teams等のメッセージングツールに接続するためのオープンソースのゲートウェイソフトウェアです。ローカルPCやサーバーで動作し、外部のメッセージングツールからAIエージェントを操作できるようにします。

Slackと連携する場合、次の3コンポーネントが協調して動作します。

コンポーネント	役割
OpenClawゲートウェイ	Slackのメッセージを受け取り、エージェントに渡す仲介役
Claude CLIエージェント	実際にAI処理を行うプロセス
Slack Socket Mode	WebSocketでリアルタイム通信を維持する接続方式

ゲートウェイとエージェントの違い

ゲートウェイはメッセージの「受付窓口」です。Slackからメッセージが来ると、ゲートウェイがそれを受け取り、Claude CLIエージェントを起動して処理を委託します。処理が完了したら、エージェントからゲートウェイを経由してSlackに返信が届く仕組みです。

つまり、Slackから返信が来ない場合は「ゲートウェイが止まっている」「エージェントがハングしている」「Slack接続が切れている」のいずれかが原因です。

Slack Socket Modeで何が起きているか

Slack Socket ModeはWebSocketを使い、OpenClawとSlackを常時接続します。この接続は一定時間ごとに切れ・再接続するのが正常動作です。ただし、この再接続の仕組みに問題があるとメッセージが届かなくなります。

まず確認：ログでどのパターンか特定する

問題が発生したら、まずログを確認します。原因のパターンによって対処法が異なるため、ログの読み方を覚えておくことが最短の解決策につながります。

ログファイルの場所（ローカル）

# メインログ（最新）~/.openclaw/logs/gateway.log# 日付別ログ/tmp/openclaw/openclaw-YYYY-MM-DD.log

ログをリアルタイムで流す場合は以下のコマンドを使います。

tail -f /tmp/openclaw/openclaw-$(date +%Y-%m-%d).log

ログで確認すべき5つのキーワード

ログの中で以下のキーワードを検索することで、問題のパターンを絞り込めます。

キーワード	意味	対応パターン
stale-socket	WebSocket接続が切れ、再接続が発生	パターン1
ツール無効化 または グループチャットコンテキスト	ツールが無効化されたセッションで実行	パターン2
watchdog timeout	エージェントプロセスが10分間無応答	パターン3
typing TTL reached	入力中インジケータがタイムアウト	パターン3
cron: job execution timed out	cronジョブが制限時間内に完了しなかった	パターン4

該当するキーワードが見つかったら、対応するパターンの対処法に進んでください。

パターン1：stale-socketによる再接続ループ

症状: ゲートウェイのプロセスは起動中なのに、Slackから返信が来ない。ログを見ると35分ごとに stale-socket の記録がある。

症状のログ例

[slack] stale-socket detected, reconnecting...[slack] socket mode connected[slack] stale-socket detected, reconnecting...

このように再接続を繰り返しているが、メッセージへの返信（delivered reply to channel）が記録されない状態です。

原因：WebSocketの自動切断タイミング

Slack Socket Modeは一定時間（約35分）でWebSocketを切断し、再接続する設計になっています。通常は再接続後も正常に動作しますが、OpenClawのバージョンが古い場合や、設定ファイルに不整合があると、再接続後のメッセージ受信に失敗するケースがあります。

あるメディア運営者の事例では、OpenClaw 2026.3.8のまま長期間使い続けた結果、stale-socketの再接続ループが頻発し、Slackからの指示がエージェントに届かない状態が発生しました。

対処法：バージョンアップとゲートウェイ再起動

Step 1: OpenClawのバージョンを確認する

openclaw --version

Step 2: 最新バージョンにアップデートする

npm update -g @openclaw/openclaw

Step 3: ゲートウェイを再起動する

# ゲートウェイを停止pkill -f openclaw-gateway# ゲートウェイを再起動openclaw gateway start

Step 4: Slack接続を確認する

openclaw status

slack: ok と表示されれば正常です。

---

Claude Codeを使った業務自動化について、個別指導で対応しています。OpenClawの設定から自動化ワークフロー構築まで、「何から始めれば良いかわからない」という段階からサポートします。

Claude Code個別指導の無料相談はこちら →

---

パターン2：ツール無効化（グループチャットコンテキスト問題）

症状: Slackからの通常の返信はできているが、cronジョブ（定期実行タスク）が機能しない。ログに「ツールが無効化されている」「グループチャットコンテキスト」の記録がある。

これはOpenClaw特有の問題で、cronジョブが「古い（stale）セッション」を再利用した際に発生します。

症状のログ例

このセッションはグループチャットコンテキストで実行されており、シェルコマンドやファイル操作などのツールが無効になっています

このエラーが出ると、cronジョブでファイル操作・コマンド実行・スクリプト起動ができなくなります。

原因：staleセッションのキャッシュ

OpenClawはパフォーマンス最適化のため、過去のセッションをキャッシュします。しかし、ツールが無効化されたセッションのキャッシュが残ると、新しいcronジョブ実行時にそのstaleセッションが再利用され、ツール無効状態が引き継がれます。

実際の事例では、ある自動化担当者がGoogle Search Consoleのデータ取得cronを設定したところ、2026年3月19日以降ほぼ毎回失敗するようになりました。原因を調査すると、59件のstaleセッションが蓄積されており、その大部分がツール無効状態になっていました。

対処法：staleセッション全削除コマンド

Step 1: 現在のセッション数を確認する

openclaw sessions list | wc -l

Step 2: staleセッションを全削除する

openclaw sessions clean --all

または手動で削除する場合:

# セッションファイルの場所ls ~/.openclaw/sessions/# 全削除rm -rf ~/.openclaw/sessions/*

Step 3: ゲートウェイを再起動して新しいセッションで起動する

pkill -f openclaw-gatewayopenclaw gateway start

再発防止のポイント: cronジョブの設定に sessionTarget: isolated を追加することで、各cronジョブが独立した新しいセッションで実行され、staleセッションの影響を受けなくなります。

{  "jobs": [    {      "name": "seo-report",      "schedule": "0 9 * * *",      "sessionTarget": "isolated",      "prompt": "..."    }  ]}

パターン3：セッション腐敗によるスタック（watchdogタイムアウト）

症状: ゲートウェイは動いており、Slackのメッセージも受信しているが、2分経過しても返信がない。ログに watchdog timeout や typing TTL reached がある。

症状：watchdog timeout / typing TTL reached

00:09:59 watchdog timeout: model=sonnet (pid=12345) - 約10分間出力なしtyping TTL reached (2m); stopping typing indicator

watchdog（番犬）タイムアウトとは、エージェントプロセスが一定時間内に何も出力しなかった場合に強制終了する仕組みです。タイムアウトした場合、Slackには返信が送られません。

原因その1：長大なコンテキスト（コンパクション）

Claude Codeとの会話が長くなると、トークン数の上限に近づき「コンパクション（圧縮）」が発生します。この処理に時間がかかり、watchdogタイムアウトに達することがあります。

対処法は セッションをリセットすることです。新しいセッションで起動すると、コンテキストが軽くなり、レスポンスが速くなります。

原因その2：Slackにアップされたファイルをローカルで探すループ

これは珍しいが実際に発生したケースです。ユーザーがSlackにPDFファイルをアップロードした際、OpenClawがそのファイルをローカルディスクで探し始め、find ~ -name "*.pdf" を15個以上並行実行してシステムがハングしました。

ログでは以下のような find コマンドが大量に記録されます。

find ~ -name "*.pdf"find /Users -name "*Anthropic*.pdf"pdfinfo /Users/.../large-file.pdf

Slackにアップされたファイルはローカルには存在しないため、この検索は永遠に終わりません。

対処法：プロセスkillとゲートウェイ再起動

Step 1: スタックしたClaude CLIプロセスを特定する

ps aux | grep claude

Step 2: プロセスを停止する

# スタックしたエージェントプロセスをkillkill -9 [PID]

Step 3: ゲートウェイを再起動する

pkill -f openclaw-gatewayopenclaw gateway start

ポイントSlackにアップされたファイルを処理させたい場合は、「このファイルはSlack上にある。ローカルには存在しないため、内容を直接読み取ってほしい」のように明示的に指示することで、ローカル検索ループを防げます。

パターン4：cronジョブのタイムアウト

症状: cronジョブは定刻に起動しているが、Slackへの結果通知が届かない。ログに cron: job execution timed out がある。

症状：cron: job execution timed out

cron: job execution timed out after 600s: ga4-seo-reportcron: job execution timed out after 600s: shukatsu-search-console

OpenClawのcronジョブにはデフォルトで600秒（10分）のタイムアウトが設定されています。データ取得・記事執筆・レポート生成など、処理に時間がかかるタスクでは、この上限に引っかかることがあります。

対処法：タイムアウトの延長設定

~/.openclaw/cron/jobs.json を開き、対象ジョブに timeoutSeconds を追加します。

{  "jobs": [    {      "name": "ga4-seo-report",      "schedule": "0 9 * * *",      "timeoutSeconds": 1200,      "prompt": "..."    }  ]}

処理内容に応じた推奨タイムアウト値の目安です。

タスク内容	推奨タイムアウト
データ取得・集計	1200秒（20分）
記事執筆・要約	1800秒（30分）
複数ステップのワークフロー	3600秒（60分）

設定変更後は、ゲートウェイの再起動は不要です。次回の定刻実行から新しいタイムアウト値が適用されます。手動実行でテストする場合は以下のコマンドを使います。

openclaw cron run [ジョブ名]

複数のcronが同時実行されるクラッシュの防止策

複数のcronジョブが同じ時間に起動すると、リソース競合でクラッシュすることがあります。maxConcurrentRuns を設定し、同時実行数を制限します。

{  "maxConcurrentRuns": 2,  "jobs": [...]}

また、cronスケジュールをずらすことで同時起動を避けられます。

# NG：全部9時に起動0 9 * * * ga4-report0 9 * * * gsc-report0 9 * * * news-writer# OK：5分ずつずらす0 9 * * *  ga4-report5 9 * * *  gsc-report10 9 * * * news-writer

再発防止のための3つの設定

一度解決した後も、同じ問題が再発しないための予防的設定を紹介します。

OpenClawを定期的にバージョンアップする

OpenClawは活発に開発されており、バグフィックスが頻繁に行われています。古いバージョンのまま使い続けると、修正済みの問題が再発することがあります。

# バージョン確認openclaw --version# アップデートnpm update -g @openclaw/openclaw# アップデート後はゲートウェイを再起動openclaw gateway restart

sessionTarget: isolated をcronジョブに設定する

前述のとおり、sessionTarget: isolated を各cronジョブに設定することで、staleセッションの影響を受けない独立した実行環境が確保されます。これはパターン2の根本的な予防策です。

cronスケジュールを分散させる

同時実行による競合を防ぐため、cronジョブのスケジュールを最低5分以上ずらします。ジョブの処理時間を把握した上で、前のジョブが完了してから次のジョブが起動するように設計するのが理想です。

よくある質問

Q. OpenClawのゲートウェイを再起動するコマンドは？

OpenClawのゲートウェイを再起動するには、以下の手順を実行します。

# プロセスを停止pkill -f openclaw-gateway# ゲートウェイを起動openclaw gateway start# 状態を確認openclaw status

slack: ok が表示されれば、Slack接続が確立されています。

Q. staleセッションとは何ですか？どう削除しますか？

staleセッションとは、すでに使われなくなった古い会話コンテキストのことです。これが大量に蓄積されると、cronジョブが古いセッションを誤って再利用し、ツールが無効な状態で実行されることがあります。

削除方法:

openclaw sessions clean --all

定期的に（週1回など）実行することをおすすめします。

Q. ローカルのOpenClawとmoltworkerの違いは？

moltworkerは、OpenClawを使って複数のエージェントインスタンスを管理するためのラッパーツールです。ローカルのOpenClawはシングルエージェントで動作するのに対し、moltworkerは「mainエージェント（Claude Code担当）」「codexエージェント（コーディング担当）」のように複数のAIモデルを目的別に使い分ける構成を取ります。

トラブルシューティングの手順は基本的に同じですが、moltworkerを使っている場合はポートが複数あること（Claude Code: 18789、Codex: 18790など）に注意が必要です。

まとめ

OpenClawでSlackからClaude Codeが返信しない場合の原因は、次の4パターンに分類されます。

パターン	ログのキーワード	対処法
stale-socket再接続ループ	stale-socket detected	バージョンアップ＋ゲートウェイ再起動
ツール無効化	グループチャットコンテキスト	staleセッション全削除＋ゲートウェイ再起動
セッション腐敗・スタック	watchdog timeout, typing TTL	スタックプロセスkill＋ゲートウェイ再起動
cronジョブタイムアウト	job execution timed out	timeoutSecondsの延長設定

まずはログを確認してパターンを特定し、対応する手順を実行してください。再発防止には、バージョンを最新に保つ・staleセッションを定期削除する・cronジョブにsessionTarget: isolatedを設定するの3点が有効です。

---

Claude Codeの導入・活用をサポートします

株式会社Nexaでは、Claude Codeを活用した業務自動化の個別指導・企業研修を提供しています。OpenClawの設定・カスタムスキル開発・cronによる自動化構築など、非エンジニアの方でも実践できるよう丁寧にサポートします。「何から始めればいいかわからない」という段階からご支援いたします。

Claude Code個別指導の詳細・無料相談はこちら →

---