この記事のまとめ
Contents
- Genspark Clawで自分では何もしていないのに、毎日2,000クレジット以上が消えていた
- 原因はバックグラウンドで動き続けるサービスの認証エラーループ、送信失敗ジョブの残留、意図せず動き続けていたCronジョブの3つ
- ターミナルから対処したところ、翌日の消費量は約60クレジットまで激減（97%削減）
- さらに調査すると、Genspark側が登録した自動アップデートジョブが毎日深夜に動いていることも判明
- 完全解決ではないが、「知らない間にクレジットが全滅する」事態は脱した
何が起きていたか：まず現象を整理する
昨日のポスト「Gensparkのクレジットが毎日消える問題の原因調査と対処法」に詳しくまとめましたが、月初のクレジットリセット直後で10,000クレジットあるはずのところが、何もしていないのに4月2日の夜に確認したところ残クレジットが6,151、さらにその翌日の4月3日朝には残り4,050に減っていたという状況でした。
4月1〜2日の2日間で、月初のリセット直後でクレジットが約3,849も消費されていました。自分では何も作業していないのにです。4月3日には1日だけで約2,100クレジットが消え、残高は6,151から4,050へ。
これに危機感を覚え、GensparkやClaudeの力を借りて対応した結果、嬉しいことに4月4日午後にGensparkのダッシュボードを開いてクレジット残高を確認したところ、前日比で約60クレジットしか減っていませんでした。
この問題について調査した昨日の記事はこちらです。もう少し詳しいやり方なども含めて確認したい方は合わせてこの記事も参照してください。
👉 「Gensparkのクレジットが毎日消える問題の原因調査と対処法」
昨日までの1日あたりの消費量は、約2,100クレジットでした。たった1日の対処で、消費量が約97%削減されました。何をしたのか、順を追って説明します。
そもそも何が起きていたのか
Genspark Plusプランに加入すると、月に10,000クレジットが付与されます。僕はさらにGenspark Claw（年間プラン）も契約しており、4月1日に月次のクレジットがリセットされました。
平均2,000クレジットが浪費されているのを簡単に確認すると、GensparkのUsageダッシュボードには「LLMs: 59.49%」と表示されており、AIの言語モデルが何度も呼び出されていることは分かりました。しかし自分では何のタスクも実行していません。
本記事は、その後の対処結果の報告です。昨日の記事を読んでいなくても、この記事だけである程度状況と対処法が分かるように書いています。
なぜこういうことが起きるのか：Genspark Clawの構造
Genspark Clawの大きな特徴のひとつが、「Cloud Computer」という仮想のLinuxマシンが付属していることです。これにより、AIエージェントがブラウザ操作・ファイル管理・LINEやSlackへのメッセージ送信などを自動でこなしてくれます。
問題は、このマシンがユーザーがGensparkを開いていない間も、ずっと動き続けているという点です。裏側でサービスが常時稼働しており、何らかのエラーや設定の不具合があると、ユーザーが気づかないうちにクレジットを消費し続けることがあります。
今回の問題は、まさにこの「常時稼働」の構造から生まれていました。
ターミナルで何をしたか：3つの対処と追加発見
Genspark ClawのCloud Computerには、ブラウザから「ターミナル」にアクセスできます。黒い画面にコマンドを打ち込む、あの環境です。
難しそうに聞こえますが、コマンドはコピー＆ペーストするだけで動きます。返ってきた結果の意味が分からなければ、そのままGensparkやClaudeに貼り付けて「これはどういう意味ですか？」と聞けば教えてもらえます。ターミナルの開き方は、Gensparkのダッシュボードから「Cloud Computer」を開き、画面内の「Terminal」をクリックするだけです。
対処①：openclaw-gatewayを止める
最も効果が大きかった対処です。
openclaw-gatewayというサービスが、裏側で何度も再起動を繰り返していました。原因はLINEチャンネルの認証トークンが切れていたことで、接続を試みるたびに失敗し、失敗するたびに自動で再起動がかかり、再起動のたびにAIが呼び出される、という悪循環が続いていました。
しかも、このサービスはGensparkを使っていない時間も含めてマシンが起動している限り自動で動き続ける設定になっています。
以下のコマンドをターミナルに貼り付けて実行することで、このサービスを止めることができます。
systemctl --user stop openclaw-gateway
systemctl --user disable openclaw-gateway
実行後、以下のコマンドで状態を確認します。
systemctl --user status openclaw-gateway
Active: inactive (dead)と表示されていれば、サービスは停止しています。
注意： この操作によって、Genspark ClawのAIエージェント機能全体が止まります。自動タスクや外部サービスとの連携を使っている場合は、それらも停止します。
対処②：delivery-queueのファイルを削除する
Genspark Clawには、送信しようとして失敗したタスクを一時的に保管しておく「delivery-queue（配送待ちのキュー）」という場所があります。
僕の環境では、3月23日に送ろうとしたLINEメッセージがエラーで失敗した状態のまま、このキューに詰まり続けていました。サービスが起動するたびに「また送ろう」と試み、また失敗する、という繰り返しになっていたわけです。
ls -la /home/work/.openclaw/delivery-queue/
このコマンドでフォルダの中身を確認できます。.jsonという拡張子のファイルが残っていたら、詰まったジョブがあります。以下で削除できます。
rm /home/work/.openclaw/delivery-queue/*.json
対処③：Cronジョブの設定をリセットする
Genspark Clawには、「毎日〇時にこのタスクを実行する」というスケジュール設定（Cronジョブ）があります。
Gensparkのダッシュボード上では「無効化済み」と表示されていた複数のジョブが、実際には動き続けていました。毎朝LINEにメッセージが届いていたのがその証拠です（自分はWhatsAppがメインなのでほとんど気づいていませんでした）。
ローカルの設定ファイルを空にすることで、この問題に対処しました。
# 念のため現在の設定をバックアップ
cp /home/work/.openclaw/cron/jobs.json \
/home/work/.openclaw/cron/jobs.json.bak
# 設定を空にする
cat > /home/work/.openclaw/cron/jobs.json << 'EOF'
{
"version": 1,
"jobs": []
}
EOF
追加で判明したこと：自動アップデートジョブが毎日動いていた
対処①〜③を実施した後も、1日約60クレジットの消費が残っていたため、さらに調査を続けたところ、別の原因が見つかりました。
以下のコマンドを実行したところ、
sudo crontab -l
こんな設定が出てきました。
3 1 * * * /usr/bin/npm install -g @genspark/cli@latest @anthropic-ai/claude-code@latest @openai/codex@latest
毎日深夜1時3分に、Genspark関連の3つのCLIツールを自動アップデートするジョブが動いていました。Gensparkのセットアップ時に自動で登録されたと思われます。このアップデート処理が何らかのLLM呼び出しを伴っている可能性があります。
毎日更新する必要はないと判断し、週1回（月曜日のみ）に変更しました。
sudo crontab -e
エディタが開いたら、* * *の部分を* * 1に変更して保存します。nanoエディタが開いた場合は、Ctrl+Oで保存、Ctrl+Xで終了です。
# 変更前（毎日）
3 1 * * * /usr/bin/npm install -g ...
# 変更後（毎週月曜日のみ）
3 1 * * 1 /usr/bin/npm install -g ...
対処の結果：97%削減、でも完全解決ではない
| 消費クレジット/日 | |
|---|---|
| 対処前（4月2〜3日） | 約2,100 |
| 対処後（4月3〜4日） | 約60 |
| 削減率 | 約97% |
4月4日朝に確認したクレジット残高はスクリーンショットのとおりで、前日比の減少は約60クレジットにとどまっていました。また、毎朝届いていたLINEへの自動メッセージも、今朝は届いていません。
一方で、1日60クレジット前後の消費は残っています。これは自動アップデートジョブが原因の可能性が高く、週1回に変更したことで今後は7分の1程度に抑えられると見込んでいます。
根本的な解決には、Genspark側のサービス改善が必要です。具体的には、クレジット消費の詳細な履歴をダッシュボードで確認できるようにすること、エラーが発生した際にループを自動停止してユーザーに通知する仕組みを持つこと、UIでの設定変更がサーバー側にも確実に反映されるようにすること、の3点です。
同じ症状が出たら試すべき6つの手順
同じ問題に直面している方向けに、確認と対処の手順をまとめます。コマンドはコピー＆ペーストするだけで実行できます。意味が分からなくても、結果をそのままAIに貼り付けて解析してもらえれば大丈夫です。
手順1：クレジットを消費しているプロセスを探す
ps aux | grep -E "openclaw|claw|genspark" | grep -v grep
openclaw-gatewayが表示されたら、それがクレジット消費の主な原因である可能性があります。
手順2：エラーログを確認する
journalctl --user -u openclaw-gateway --since "today" | grep -E "error|restart|failed" | tail -30
以下のようなログが繰り返し出ていたら、認証エラーのループが起きています。
[genspark-im] channel exited: auth is not defined
[genspark-im] auto-restart attempt 1/10 in 5s
[health-monitor] restarting (reason: stopped)
手順3：delivery-queueに詰まったジョブがないか確認・削除する
# 確認
ls -la /home/work/.openclaw/delivery-queue/
# 詰まっているファイルがあれば削除
rm /home/work/.openclaw/delivery-queue/*.json
手順4：Cronジョブの設定を確認する
# Clawの設定
cat /home/work/.openclaw/cron/jobs.json
# システムレベルの自動タスク
sudo crontab -l
見覚えのないジョブが毎日実行されていたら要注意です。
手順5：openclaw-gatewayを停止する
systemctl --user stop openclaw-gateway
systemctl --user disable openclaw-gateway
# 停止確認
systemctl --user status openclaw-gateway
Active: inactive (dead)と表示されれば停止しています。
手順6：rootのcrontabを週1回に変更する
sudo crontab -e
* * *（毎日）を* * 1（月曜のみ）に変更して保存します。
まとめ：ほぼ解決、しばらく様子見
ターミナルを使った3つの対処によって、1日2,100クレジットだった消費が約60にまで減りました。数字で見ると97%の削減です。完全解決とは言えませんが、ひとまず「知らない間にクレジットが全部消えてしまう」という最悪の事態は脱することができました。
同じような問題に悩んでいる方がいれば、ぜひこの記事の手順を試してみてください。また、Gensparkサポートへのフィードバックを送ることも重要だと思っています。ユーザーからの声が積み重なることで、サービス改善につながっていくはずです。
引き続き状況を確認して、変化があれば追記します。
タグ：Genspark, Genspark Claw, AIエージェント, クレジット消費, Cloud Computer, Linux, 生産性, AI活用
本記事の執筆にはAIアシスタント（Claude）を活用しています。
北海道・帯広市出身。国際関係学を専攻し、アメリカとスウェーデンへの留学経験、マレーシア、スイス、中国、フィリピンなど複数の国での勤務・生活経験を持つ。現在はグローバルに展開する医療機器メーカーにおいて国際プロジェクトマネジメントを専門とし、異文化間の業務遂行と組織運営を主たる領域としている。
製造業での経験に加え、150を超える国・地域から35,000名が参加した2015年の第23回世界スカウトジャンボリーでは、大会主要責任者として参加各国との折衝、世界スカウト機構（WOSM）との窓口、およびリスク対応などを担った。以前は東日本大震災をはじめとする国内各地の自然災害において、災害ボランティアセンターの立ち上げ・運営支援にも携わった。
旅行・生産性・テクノロジー・グローバルキャリアをテーマに、自身の学習と思考の整理を兼ねて書いているブログです。内容が読んでくださる方の参考になれば幸いです。
hiroshi.todayをもっと見る
購読すると最新の投稿がメールで送信されます。