Genspark Clawのスコープバグ・クレジット大量消費が再発した話：認証ループの根本原因をClawが自力で特定・修正するまで

※ この記事は、Genspark Clawのクレジットが意図せず大量消費される問題を追った調査シリーズの第3回です。過去2回の記事をご存知でない方に向けて、まず簡単に背景を説明します。

Gensparkには「Claw」と呼ばれるAIエージェント機能があり、オプションとして「Cloud Computer」というLinux仮想マシンが付属しています。このCloud Computerは、ブラウザを閉じた後もバックグラウンドで動き続けるのですが、何らかのきっかけで内部の処理が壊れた状態になると、AI（LLM）を何度も呼び出し続け、気づかないうちにクレジットを大量消費するという問題が起きます。第1回でその原因を特定し、第2回で対処して消費量を97%削減しました。そして今回、同じ問題が再発しました。

・第1回：Genspark Clawのクレジットが勝手に消える問題を調査した話
・第2回：Gensparkクレジット消費97%削減までの記録

なお、この時期からGensparkで追加クレジット購入ができなくなりました（詳細は別記事で書く予定です）。残高が減る一方で補充ができない状況になったため、クレジットの無駄な消費を防ぐことは以前にも増して切実な問題になっています。

また始まった、と気づいた瞬間

4月上旬の時点ではクレジット消費がほぼゼロで安定していたため、「ようやく落ち着いた」と判断していました。前回の対処（処理の停止・キューの削除・スケジュールの整理）が効いていたのです。ただし、あの対処はあくまで「問題を止める」ものであって、「根本原因を直す」ものではありませんでした。その後、通常利用のために処理を再起動していたため、同じ条件が整えば再発することは分かっていました。

4月10日、昼休みから夕方にかけての数時間でクレジットが800以上消費されていることに気づきました。前回記事で問題視していた消費ペースを明らかに上回っており、再び同じ問題が起きていることはすぐに分かりました。

この記事のまとめ

Gensparkのクレジット消費が気になっている方、Claw（AIエージェント）を使い始めたばかりの方に向けて、この記事では次のことをまとめています。

まず、Gensparkのクレジットが消える、蒸発するというような同じ問題が繰り返し起きるのかという根本原因が今回の調査で初めて明確になりました。GensparkのClawに組み込まれたプログラムに設計上のミスがあり、それがクレジットを無駄に消費し続ける状態を引き起こしていたのです。

次に、その修正を行ったのが私ではなくClaw自身だったという点が今回の大きな特徴です。Clawがターミナル（コマンド操作画面）を使って自分のプログラムのミスを特定し、修正しました。

また、「Clawのチャット画面に入力する」か「ターミナルに直接入力する」かでクレジット消費に大きな差が出るという、Clawを使う上で知っておくべき実用的な話もまとめています。私自身、この違いを意識せずに無駄なクレジットを使ってしまった反省も含めて書いています。

最後に、再発しても自動で検知・停止できる仕組みの作り方を具体的に紹介しています。

前回との違い：「止める」から「再発防止」へ

今回の調査を終えてみると、前回と今回の最大の違いは対処のアプローチにありました。エラーの内容自体は同じだったものの、今回は原因をコードレベルまで掘り下げることができ、問題を「止める」のではなく「直す」という対応ができました。

調査プロセス：4つのステップ

Step 1：何が動いているかを確認する

まずCloud Computerのターミナルで、現在動いているプロセスを確認しました。

ps aux | grep -E "openclaw|claw|genspark" | grep -v grep

結果として、openclaw-gateway・wp-bridge・websockifyの3つが稼働中でした。一見正常に見える状態です。ここで興味深かったのは、Clawがこの出力を自分で読み解いて「何か問題があって確認されましたか？」と聞いてきたことです。Clawはターミナルを通じて自分自身のプロセスの状態を把握できます。

Step 2：エラーログで何が起きているか確認する

次に、gatewayが今日の昼以降に何をしていたかをログで確認しました。

journalctl --user -u openclaw-gateway --since "2026-04-10 12:00" | grep -E "error|restart|failed|auth|retry|genspark-im" | tail -50

出てきたのは前回とまったく同じパターンでした。

[genspark-im] channel exited: auth is not defined
[genspark-im] auto-restart attempt 1/10 in 5s

「auth is not defined（認証情報が定義されていない）」というエラーが出るたびに、5秒→11秒→20秒→42秒と待ち時間を延ばしながら最大10回まで自動で再接続を試みるサイクルが繰り返されていました。この再接続のたびにLLMが呼ばれ、クレジットが消費されます。今回はさらに別のエラーも確認できました。

outboundState already populated by another account — multi-account is NOT supported

前回の調査ではトークン（認証キー）の期限切れが原因と推測していましたが、今回の調査でより深いところに問題があることが分かりました。

Step 3：Clawが自分でバグを特定・修正する

ここが今回の記事で最も印象的な部分です。私がログを見せて「これが原因では？」と誘導したわけではなく、Clawが自発的に動きました。まず認証キー（GSKトークン）自体が有効かどうかを確認し、キーは正常だと確かめた上で「問題は別の場所にある」と判断し、自分のプラグインのソースコードを読み始めました。

対象ファイルは /home/work/.openclaw/workspace/plugins/genspark-im/src/index.ts です。Clawが特定したバグは、プログラムの変数スコープ（変数がどの範囲で有効かというルール）に関するミスでした。簡単に言うと、「ある処理の中でしか使えない変数」を、その外側から参照しようとしていたために、変数が未定義のままエラーになり続けていた、という構造です。

具体的には、runMonitor という処理の中で auth という変数を参照していますが、この変数は refreshToken() 関数の内部スコープにしか存在しません。runMonitor が実行される時点では auth がまだ定義されていないためエラーになります。ただし、Genspark CLIのバージョンが変わればコードの構造も変わり得るため、ここでは行番号ではなく関数名・変数名で記載しています。

Clawはこの箇所を特定した上で、auth への参照を初回の認証完了後に移動させる修正を施し（firstAuth フラグを追加）、gatewayを完全再起動しました。再起動後のログに Authenticated: chat_id=... という成功の記録が確認でき、修正が有効だと分かりました。

自分のプラグインのバグをターミナルを使って自力で読み解き、修正して再起動するという一連の流れを自律的に完結させたことは、Clawがターミナルアクセスを持つことの実用的な価値を改めて示していると感じました。

Step 4：配信キューとスケジュールを確認する

delivery-queue（処理待ちのタスクが溜まる場所）は空で正常でした。スケジュール設定（jobs.json）に登録されていた4件のタスクはいずれも意図したものです。一方、前回の対処で週1回に変更したはずのシステムの自動アップデート設定が、再び毎日実行のスケジュールに戻っていました。Genspark CLIのアップデート時に設定が上書きされたと考えられます。

チャット画面とターミナル：どちらに入力するかでコストが変わる

今回、私自身が失敗して気づいたことがあります。watchdogスクリプト（後述）を作成した際、そのスクリプトの内容をClawのチャット画面に貼り付けてしまいました。するとClawがその内容を「新しいタスクの指示」として解釈し、LLMが呼ばれてクレジットが消費されました（おそらく数十クレジット程度）。

同じ内容をターミナルに直接貼り付ければ、LinuxがローカルでBashコマンドとして処理するため、クレジット消費はゼロ（か、ほぼゼロ）です。

Clawを使い始める段階でこの違いを理解しておくと、無駄なクレジット消費をかなり防げます。判断の基準はシンプルで、「AIに考えてほしいこと」はチャット画面に、「コンピューターにそのまま実行させたいこと」はターミナルに入力する、ということです。

設定ファイルの編集、スクリプトの設置、ファイルのコピーといった「AIの判断が不要な作業」は、ターミナルに直接コマンドを貼り付けるのが正解です。チャット画面に入力した瞬間、LLMが動きます。

再発防止策：今回追加したもの

watchdogスクリプトの設置

認証ループが再発しても自動で検知・停止できるよう、以下のスクリプトをターミナルに直接設置しました。「watchdog（番犬）」という名のとおり、異常が起きていないかを定期的に見張る仕組みです。

#!/bin/bash
# /home/work/.openclaw/watchdog.sh
ERROR_COUNT=$(journalctl --user -u openclaw-gateway --since "1 hour ago" 2>/dev/null | grep -c "auth is not defined")
if [ "$ERROR_COUNT" -gt 5 ]; then
    systemctl --user stop openclaw-gateway
    echo "$(date): gateway stopped due to auth loop ($ERROR_COUNT errors in 1h)" >> /home/work/.openclaw/watchdog.log
fi

このスクリプトはLinuxの標準コマンドのみで完結しているため、クレジット消費はゼロです。ユーザーcrontabに15分おきで登録しておくことで、認証ループが再発しても最大15分・40クレジット程度で自動停止できる計算になります。設置はチャット画面ではなくターミナルへの直接貼り付けで行いました。

修正ファイルのバックアップ

Clawが修正したソースファイルをバックアップとして保存しました。

cp /home/work/.openclaw/workspace/plugins/genspark-im/src/index.ts \
   /home/work/.openclaw/index.ts.patched.bak

このプラグインはTypeScriptのソースファイルをそのまま読み込んでいるため、ソースへの修正が直接有効になっています。Genspark CLIのアップデートや環境の再プロビジョニングで上書きされた場合も、バックアップがあれば diff コマンドで差分を確認し再適用することができます。

バグ修正後も消費が続いていた：HEARTBEAT.mdの見落とし

スコープバグの修正後も、夜になって残高を確認すると約130クレジット/時間のペースで消費が続いていることに気づきました。エラーログはクリーンで、スケジュールジョブも実行時刻はまだ先のはず。何が動いているのかを改めて調べました。

稼働中のサービスを確認すると、openclaw-browser.service（Chromium）が動いていることが分かりました。前回の調査では出てこなかったサービスです。ログを確認しましたが空で、設定を見るとVNC画面上でChromiumを起動するだけのスクリプトであり、LLMを呼ぶ仕組みではありませんでした。

次に確認したのが HEARTBEAT.md です。このファイルはClawが定期的に読み込み、タスクが記載されていればLLMを呼び出してその内容を処理するという仕組みになっています。ファイルの冒頭にも「空にしておけばAPIの呼び出しをスキップする」と明記されていました。

確認してみると、jobs.jsonへの移行後もHEARTBEAT.mdにPMP進捗確認のスケジュール日付がずらりと残ったままでした。これはバグではなく仕様通りの動作です。jobs.jsonで管理するよう移行した際に、HEARTBEAT.mdの記述を消し忘れたという「設定の二重管理・見落とし」が原因でした。

ターミナルから以下のコマンドでHEARTBEAT.mdをコメントのみの状態に書き換えました。

cat > /home/work/.openclaw/workspace/HEARTBEAT.md << 'EOF'
# HEARTBEAT.md
# Keep this file empty (or with only comments) to skip heartbeat API calls.
# Scheduled jobs are managed via cron/jobs.json
EOF

修正後、約40分後にクレジット消費がゼロになったことを確認しました。jobs.jsonに登録済みの4件のジョブは引き続き有効で、実行予定にも影響はありません。

Clawを使い始める際にHEARTBEAT.mdとjobs.jsonが並存する構造を把握しておくと、同じ見落としを防げます。スケジュール管理をjobs.jsonに一本化するなら、HEARTBEAT.mdはコメントのみにしておくのが正解です。

OS再起動のタイミングに注意

Cloud ComputerのログインUIに「System restart required」という表示が出ていますが、修正の有効性が確認できるまでは再起動しないことを推奨します。翌朝のクレジット残高を確認してから再起動を実施し、正常稼働を確かめるのが安全な手順です。

FAQ（よくある質問）

Q. チャット画面とターミナル、どちらに入力しても同じではないですか？

A. クレジット消費の観点では大きく異なります。チャット画面への入力はClawがAI（LLM）を使って解釈・処理するためクレジットが消費されます。一方、ターミナルへの入力はLinuxが直接コマンドとして処理するためクレジット消費はゼロです。設定ファイルの編集・スクリプトの設置・ファイルのコピーなど、AIの判断が不要な作業はターミナルへの直接入力が正解です。

Q. watchdogスクリプト自体もクレジットを消費しますか？

A. 消費しません。このスクリプトはLinuxの標準コマンド（journalctl・grep・systemctl）だけで完結しており、GensparkのAIを一切呼び出しません。15分おきに実行されてもクレジット消費はゼロです。

Q. HEARTBEAT.mdとjobs.jsonは何が違うのですか？

A. どちらもClawへの定期タスク指示に使えますが、仕組みが異なります。HEARTBEAT.mdはClawが定期的に読み込んでその場で解釈・実行するファイルで、記述があるだけでLLMが呼ばれます。jobs.jsonはスケジュール日時を指定して登録するジョブ管理ファイルで、指定日時まで実行されません。スケジュール管理はjobs.jsonに一本化し、HEARTBEAT.mdはコメントのみにしておくのが、クレジット消費を抑える上で無難な運用です。

Q. バグ修正後もクレジット消費が続く場合はどうすればいいですか？

A. まずHEARTBEAT.mdにタスク記述が残っていないかを確認してください（cat /home/work/.openclaw/workspace/HEARTBEAT.md）。次に稼働中のサービスを確認し（systemctl --user list-units --type=service --state=running）、想定外のものがないかをチェックします。それでも原因が特定できない場合は、gatewayのログで異常なパターンが繰り返されていないかを確認します（journalctl --user -u openclaw-gateway --since "today" | grep -E "error|restart|failed|auth" | tail -30）。

「止める」から「直す」、そして「自動で止まる仕組み」へ

振り返ると、この3記事はGensparkのクレジット消費問題への対応が一段階ずつ深化していく記録でもあります。第1回で原因を特定し、第2回でプロセスを止めることで97%削減を実現し、今回の第3回ではClaw自身がソースのバグを修正し、watchdogで「問題が起きても自動で止まる仕組み」を加えました。同じエラーが何度も再発したことに率直に言ってうんざりしましたが、その過程でClawが自律的にデバッグと修正を行う場面は、道具としての可能性という意味で興味深いものがありました。

一方で、Genspark側に必要な対応は変わっていないと思っています。アクション単位のクレジット履歴、エラー検知と自動停止、UIとサーバー設定の同期、そしてクレジット消費量をリアルタイムで外部から取得できるAPIやWebhookの提供、これらが実装されない限り、同じ構造的な問題は繰り返し発生するリスクがあります。特にAPIがあれば、Cloud Computer側で消費量を自律的に監視して異常時に自動停止するという仕組みが実現できます。現状のwatchdogスクリプトはエラーログの件数を代替指標にしていますが、クレジット消費の直接的な監視には届いていません。

なお、今回のような無駄なクレジット消費の繰り返しを受けて、Gensparkの追加クレジット購入を廃止することにしました。その経緯と判断については別記事でまとめる予定です。

※ この記事の調査・執筆にはAIアシスタント（Claude）を活用しています。

Please follow and like us:

Hiroshi

北海道・帯広市出身。国際関係学を専攻し、アメリカとスウェーデンへの留学経験、マレーシア、スイス、中国、フィリピンなど複数の国での勤務・生活経験を持つ。現在はグローバルに展開する医療機器メーカーにおいて国際プロジェクトマネジメントを専門とし、異文化間の業務遂行と組織運営を主たる領域としている。
製造業での経験に加え、150を超える国・地域から35,000名が参加した2015年の第23回世界スカウトジャンボリーでは、大会主要責任者として参加各国との折衝、世界スカウト機構（WOSM）との窓口、およびリスク対応などを担った。以前は東日本大震災をはじめとする国内各地の自然災害において、災害ボランティアセンターの立ち上げ・運営支援にも携わった。
旅行・生産性・テクノロジー・グローバルキャリアをテーマに、自身の学習と思考の整理を兼ねて書いているブログです。内容が読んでくださる方の参考になれば幸いです。