症状：1日2,000クレジットが消えていく
Contents
先月（3月）は試したいことが多く、複数のAIサービスで追加クレジットを購入して使い倒していました。3月後半にそれらの作業が一段落したため、Gensparkについては月末のクレジット補給を静かに待っていた状況です。4月1日・2日は仕事が立て込んでいてGensparkをほとんど開く機会がなく、2日の夜にダッシュボードを確認すると、すでに多くのクレジットが減っていました。
Gensparkのダッシュボードを開くたびに、クレジットが減っている。タスクを実行した覚えはない。エージェントも止まっているはずなのに、数字は確実に下がっていく。
4月の請求サイクルが始まった直後から、この状況が続いています。4月1〜2日の2日間で約3,849クレジットが消費され、3日には残高が6,151から4,050へ、つまり1日だけで約2,100クレジットが消えていました。そしておそらく気づいたのがたまたまクレジットがリセットされたこのタイミングだったけれども、実際はおそらく3月にも毎日このぐらいのクレジットが浪費されていたんだと思います。
GensparkのUsageダッシュボードには「LLMs: 59.49%」と表示されています。明らかにAIの言語モデルが何度も呼び出されているのですが、自分では何もしていません。
これはバグなのか、仕様なのか。同じ状況に困っている方のために、自分が調査した経緯とわかったことをまとめておきます。なお、この記事を書いている時点では問題は完全には解決できていません。「こういうことが起きているらしい」という現時点の記録として読んでいただければと思います。
Genspark Clawとは：契約環境の前提
念のため、今回の環境を整理しておきます。
| プラン | 内容 |
|---|---|
| Genspark Plus | 月10,000クレジット（Apple App Store経由） |
| Genspark Claw（年間プラン） | Cloud Computer: Standard が付属 |
Genspark Clawの特徴は、「Cloud Computer」と呼ばれるLinux仮想マシンが付属している点です。これにより、AIエージェントがブラウザ操作・コード実行・ファイル管理・外部APIとの連携などを自動で行えます。
ただし、この「常時稼働のLinuxマシン」という構造が、クレジット消費の問題と深く関わっています。仮想マシン上では、ユーザーが意識していなくてもバックグラウンドでプロセスが動き続けることがあるからです。
ターミナルで確認できること：考えられる原因3つ
Genspark ClawのCloud Computerには、ブラウザからターミナルにアクセスできます。専門知識がなくても、いくつかのコマンドを実行するだけで「何が動いているか」をある程度確認できます。
ターミナルへのアクセス方法
Gensparkのダッシュボードから「Cloud Computer」を開き、画面内の「Terminal」をクリックすると、ブラウザ上でコマンドが打てる黒い画面が表示されます。ここに以下のコマンドをコピー＆ペーストして実行してください。返ってきた内容の理解ができないという方は、返ってきた内容もコピー＆ペーストして、GensparkやClaudeなどに解析してもらえれば十分対処ができると思います。
原因①：openclaw-gatewayの認証エラーループ（最有力）
まず、動いているプロセスを確認します。
ps aux | grep openclaw
実行すると、こんな表示が出てくるかもしれません。
work 454571 openclaw-gateway ← メモリ487MB消費、4月2日から起動中
openclaw-gatewayというプロセスが動いています。これはGenspark Clawの中核となるサービスで、AIエージェントやLINE・Slackなどの外部サービスとの連携を担っています。
次に、このプロセスのログを確認します。
journalctl --user -u openclaw-gateway --since "2026-04-01" | tail -100
このコマンドは「4月1日以降のopenclaw-gatewayのログを最新100行分表示する」という意味です。僕の環境では、こんな記録が延々と続いていました。
[genspark-im] channel exited: auth is not defined
[genspark-im] auto-restart attempt 1/10 in 5s
[genspark-im] auto-restart attempt 2/10 in 10s
[genspark-im] auto-restart attempt 3/10 in 21s
...
[health-monitor] restarting (reason: stopped)
LINEチャンネルの認証トークンが失効した状態で、genspark-imプラグインが接続を試み続け、失敗するたびにhealth-monitorが約10分おきに自動再起動をかけていました。この再起動のたびにLLMが呼び出され、クレジットが消費されていたと考えられます。
さらに確認してみると、openclaw-gatewayはsystemdサービスとして登録されており、マシンが起動するたびに自動起動する設定になっていました。
systemctl --user status openclaw-gateway
を実行して、Active: active (running)と表示されていれば、このサービスが現在も動いています。
原因②：delivery-queueに詰まったジョブの再送試行
次に、送信待ちのタスクが溜まっていないか確認します。
ls -la /home/work/.openclaw/delivery-queue/
このフォルダは、Clawが外部に送信しようとしてまだ完了していないタスクを一時保管している場所です。僕の環境では、3月23日に送信しようとしたLINEメッセージ（朝のブリーフィング）が400 - Bad Requestエラーで失敗し、3回リトライした状態のままキューに残留していました。
gatewayが起動するたびにこのキューを処理しようとするため、失敗→再起動→再試行のループが続いていたと考えられます。
原因③：UIで無効化したはずのCronジョブが動き続けている
設定ファイルを直接確認してみます。
cat /home/work/.openclaw/cron/jobs.json
Gensparkのダッシュボード上で「無効化済み」と表示されているCronジョブでも、このファイルに定義が残っています。そして僕の環境では、"enabled": falseになっているにもかかわらず、毎朝LINEにメッセージが届き続けていました。（自分はWhatsAppがメインのチャットツールなのでLineはあまり見ていない・・・）
ローカルの設定ファイルとは別に、Gensparkのサーバー側でスケジュールが管理されている可能性があります。UIで止めたつもりでも、サーバー側では動き続けているケースがあるということです。
ターミナルで調査できること自体は、実はメリット
調査を進めながら感じたのは、「これだけ確認できるなら、まだマシだ」ということでした。
多くのSaaSサービスでは、内部でどんな処理が走っているかをユーザーが調べる手段はほとんどありません。クレジットが減っても「ご利用明細はこちら」としか表示されず、何のためにいくら消費されたかは不透明なままです。Genspark本体でもクレジット消費の詳細は見ることが出来ないのですが、少なくともGenspark Clawではこれが具体的に確認出来るのです。
Genspark Clawの場合、Cloud Computerがある分だけ「のぞき窓」があります。ps auxでプロセスを確認し、journalctlでログを読み、lsでキューのファイルを確認できる。技術的な敷居はありますが、少なくとも「何かが動いている」という事実は確認できます。
ただし、それはあくまでローカル側の話です。クレジット消費の詳細な履歴（いつ・何が・何クレジット）をダッシュボードで確認できないという設計上の問題は、依然として残っています。「ターミナルで調べればわかる」と「ダッシュボードで誰でも確認できる」の間には、大きな差があります。
試せる4つの対処法
現時点で「これで確実に止まる」と言い切れる対処法はありませんが、自分が試した手順を共有します。
対処1：openclaw-gatewayを停止・無効化する（最優先）
# サービスを停止し、自動起動も無効化する
systemctl --user stop openclaw-gateway
systemctl --user disable openclaw-gateway
# 停止の確認
systemctl --user status openclaw-gateway
実行後、ステータスがActive: inactive (dead)と表示されれば停止しています。これがクレジット消費を抑える最も即効性のある手段だと考えています。
ただし、この操作によってGenspark ClawのAIエージェント機能全体が止まります。Clawを使ってWebブラウジングや外部API連携を行っている場合は、それらも停止しますのでご注意ください。
なお、VNCサービス（画面共有機能）も合わせて止めたい場合は以下を実行します。
systemctl --user stop openclaw-vnc
systemctl --user disable openclaw-vnc
対処2：delivery-queueのファイルを削除する
# 残っているファイルを確認
ls -la /home/work/.openclaw/delivery-queue/
# JSONファイルがあれば削除
rm /home/work/.openclaw/delivery-queue/*.json
# 削除後の確認
ls -la /home/work/.openclaw/delivery-queue/
削除後にfailed/というフォルダのみ残っていれば完了です。
対処3：Cronジョブの設定ファイルをクリアする
# 念のため現在の設定をバックアップ
cp /home/work/.openclaw/cron/jobs.json \
/home/work/.openclaw/cron/jobs.json.bak
# jobs.jsonをリセット（空の状態に書き換え）
cat > /home/work/.openclaw/cron/jobs.json << 'EOF'
{
"version": 1,
"jobs": []
}
EOF
# 確認
cat /home/work/.openclaw/cron/jobs.json
{ "version": 1, "jobs": [] }と表示されれば成功です。
対処4：Gensparkサポートに連絡する
上記の対処はあくまでローカル側の措置です。サーバー側でスケジュールが独立して管理されている場合、ローカルの変更だけでは不十分な可能性があります。
サポートへの連絡時には、以下の3点を伝えると状況が伝わりやすいと思います。
- UIで無効化したCronジョブが動き続けている
- genspark-imが認証エラーで再起動ループを繰り返していた
- delivery-queueにエラーで詰まったジョブが残留していた
結論：まだ調査中、確認を続けます
「何もしていないのにクレジットが減り続ける」という問題は、Genspark Clawのアーキテクチャ（常時稼働のLinux VM＋外部連携プラグイン）と、エラー検知・通知の仕組みの不足が組み合わさることで起きていると考えています。
Genspark Clawは、使いこなせば確かに強力なツールです。AIエージェントがLINEに連携し、スケジュールされたタスクを自動実行するという体験は、ひと言で言うと「自分の代わりに動いてくれる」感覚があります。だからこそ、「いつの間にかクレジットが尽きていた」という事態は避けたい。
クレジット消費の詳細な履歴を誰でも確認できる形にすること、エラーループが発生したら自動停止＋通知する仕組みを持つことは、Genspark側に改善してほしい点として率直に思っています。
この記事を書いた時点では、まだ完全な解決には至っていません。続報があれば追記します。同じ状況に遭遇した方がいれば、コメントでぜひ教えてください。
タグ：Genspark, Genspark Claw, AIエージェント, クレジット消費, Cloud Computer, Linux, 生産性, AI活用
北海道・帯広市出身。国際関係学を専攻し、アメリカとスウェーデンへの留学経験、マレーシア、スイス、中国、フィリピンなど複数の国での勤務・生活経験を持つ。現在はグローバルに展開する医療機器メーカーにおいて国際プロジェクトマネジメントを専門とし、異文化間の業務遂行と組織運営を主たる領域としている。
製造業での経験に加え、150を超える国・地域から35,000名が参加した2015年の第23回世界スカウトジャンボリーでは、大会主要責任者として参加各国との折衝、世界スカウト機構（WOSM）との窓口、およびリスク対応などを担った。以前は東日本大震災をはじめとする国内各地の自然災害において、災害ボランティアセンターの立ち上げ・運営支援にも携わった。
旅行・生産性・テクノロジー・グローバルキャリアをテーマに、自身の学習と思考の整理を兼ねて書いているブログです。内容が読んでくださる方の参考になれば幸いです。
hiroshi.todayをもっと見る
購読すると最新の投稿がメールで送信されます。