AI作業・調査メモ (2026/6/11)

OpenClaw 2026.6.5 アップデートを適用したところ、Google認証エラーとなって動作しない

auth or provider access failed for google. Run /auth google to refresh
credentials; if you already re-authed, switch models/providers because this
account may still be blocked for inference.

openclaw onboard でGoogle認証APIKeyの登録含め再設定を実施

モデルの再設定

onboardを実行したことにより、Modelが「google/gemini-3.1-pro-preview」に戻ってしまっていたので、AIに依頼して「gemini-3.5-flash」に再設定

API課金軽減施策の適用チェック

下の「GoogleAPIの課金が跳ね上がることへの対策」で管理画面以外のAIで設定してもらったものが、元の通り適用されていることをAIに再度チェック依頼。

AI自身に原因調査を依頼した結果

詳しく何が起きていたのか、タイムラインと共にご説明しますね。 —

何が起きていたのか？（技術的な理由）
今回のアップデートにより、OpenClawの「認証プロファイル（APIキーなど）」と「認証ステート」の管理方法が新しくなりました。

アップデート前:「openclawインストールディレクトリ」/agents/main/agent/auth-profiles.json という JSONファイル にAPIキーが平文（または暗号化）で保存されていました。
アップデート後:
Node.jsの新しい標準機能（node:sqlite）を利用した SQLiteデータベース (openclaw-agent.sqlite) で管理する仕様にアップグレードされました。

しかし、アップデート時に古い JSONファイルから新しい SQLiteデータベースへの自動移行（マイグレーション）が行われなかったため、アップデート完了直後は「APIキーが登録されていない（空っぽの）状態」になってしまっていました。
—

⏱️ 発生したことのタイムライン
ログから今回の流れが綺麗に見えました：

05:53 JST — アップデートが完了。
05:55 JST — 自動タスクが起動するも、新DBが空だったため No API key found for provider “google”（認証エラー）が発生。
06:15 JST — APIキーを再登録してくださったことで、新しいデータベース（openclaw-agent.sqlite）にデータが正しく書き込まれ、復旧！

今回の件を踏まえて、今後OpenClawのアップデートを行う際に気を付けると良いポイントをまとめました！

#### 1. 事前バックアップの仕組みは現状で「完璧」です！👏
作成済みのアップデートのシェルは、アップデートを始める前に自動的にバックアップを呼び出し、暗号化されたtar.gzバックアップを保存するようになっています。
万が一、データベースが破損したり設定ファイルが初期化されても、ここから古い設定を100%復旧できるため、この仕組みは今後も絶対に維持しましょう！

#### 2. アップデート直後の「診断コマンド」の実行
アップデート後にサービスが再起動したら、自動タスクが走ったり会話でエラーになる前に、以下のコマンドをターミナルで叩いて接続テストをするのがおすすめです。
openclaw models status
（APIキーが正しく認識されているか、モデルが有効かが一目でわかります）
openclaw doctor
（システム全体に不整合がないか自動チェックしてくれます）

#### 3. 認証が消えたら agent フォルダを覗く
もしまた「認証エラー」が出た場合は、「openclawインストールディレクトリ」/agents/main/agent/ の中身を確認してみてください。今回のように古い auth-profiles.json が残っていれば、その中のキーをそのまま再登録すれば良いだけなので、焦らず対応できます💡

→これ、AIはこう言っていましたが、脆弱性対応でDB格納に変わったわけなので、不要なら退避した方がよいと思われ。無効なキーならそのままでもいいかもですが。

 

---

 

特定のチャンネルでDiscordのAIからの返答にチャンネルの設定情報が載ってくるようになる。他のチャンネルは問題ない。

途中の会話でチャンネル設定に関する会話をした後の場合は、チャンネルを/resetまたは/newでクリアする。

GoogleAPIの課金が跳ね上がることへの対策

これ、最初に試行錯誤でやっていると1万くらいすぐいくよな・・・

４．Discord会話履歴（セッション）のスリム化 【効果：最大】

• 現在の状況: 適用中（非常に良好）
• 詳細: 以前、小説1冊分（約30万トークン）にまで肥大化していた会話履歴を一度リセット（大掃除）しましたが、現在のこの会話セッションは非常にクリーンでスリムな状態をキープしています。
• 効果: 毎回のお返事にかかるトークン消費量が劇的に抑えられているため、1回のご発言あたりのコストは当時と比べて1/100以下（ほぼ数銭レベル）に節約されています。

５．Discordのアクセス制限（ホワイトリスト） 【効果：大（誤課金防止）】

• 現在の状況: 適用中
• 詳細: 設定ファイル（openclaw.json）を確認したところ、グループポリシーが allowlist に設定されており、反応する対象は〇〇さんのみにしっかりと制限されています。
• 効果: 他の参加者の方がいくら私に話しかけたりメンションを送ったりしても、私は完全にスルー（無視）しますので、他の方の書き込みによって裏でAPI料金が勝手に発生する心配は100%ありません！

６．自動ハートビート（生存確認）のAPI呼び出し無効化 【効果：大（チリツモ防止）】

• 現在の状況: 適用中（完全に0円）
• 詳細: ワークスペースの HEARTBEAT.md ファイルが空（コメントのみ）であることを確認しました。
• 効果: OpenClawの仕様により、このファイルが空の間は30分ごとの定期生存確認によるAPIモデルの呼び出しがスキップされます。そのため、裏での自動的なAPI消費は完全にゼロ（0円）になっています。

7.google.ai.generativelanguage.v1main.GenerativeService.StreamGenerateContent の異常呼び出し対策

• google.ai.generativelanguage.v1main.GenerativeService.StreamGenerateContent が、1時間で合計1,321回呼び出されていた。

【考えられる具体的なシナリオ】

• プログラムの無限ループ（リトライループ）： API呼び出しエラーが発生した際に、プログラムがウェイト（待機時間）を置かずに即座に再試行を繰り返してしまった。
• チャットBotの自己応答ループ（自作自演）： Botが自身（または他のBot）の出力したメッセージをトリガーとして検知し、お互いに無限に返信し合ってしまった。

漏洩はないと思ったが、念のためGemini APIキーを再作成

作成した新キーを適用

openclaw models auth paste-api-key --provider google

または現在使用しているプロファイルIDを指定

openclaw models auth paste-api-key --provider google --profile-id google:defaut

新キーを貼り付けて適用

openclaw secrets reload

GCPの管理画面→「APIとサービス」

・許可しているアプリが「Gemini API」のみであることを確認

・呼び出し元のIPアドレスを固定

・「クォータとシステム制限（Quotas & system limits）」から

Request limit per model per minute for a project in the paid tier

をデフォルト1000→15に設定

8.GenerateContent input token count limit per model per minuteの異常消費対策

結論からお伝えすると、「GenerateContent input token count limit per model per minute」（分あたりの入力トークン数制限）を設定することは、課金対策として非常に大きな意味があります。 理由は主に以下の2点です。

1. 課金は「リクエスト回数」ではなく「トークン数」で決まるため

Geminiの課金体系は、リクエストの回数ではなく、送信・生成した「トークン数（入力・出力）」に比例します。 そのため、リクエスト数（RPM）だけに制限をかけていても、1回のリクエストで超巨大なファイルや長大なコンテキスト（ソースコード全体、長い動画、大量のログなど）を送信してしまうと、少ないリクエスト回数でも課金が急激に跳ね上がってしまいます。

2. 「巨大すぎるリクエスト」や「事故」の防波堤になる

入力トークン数制限（TPM制限）を設定しておくと、以下のようなケースで課金の爆発を物理的にブロックできます。

• スクリプトのバグなどで、意図せず超巨大なデータを短時間に何度も送信してしまった場合（ループ事故）
• 1回のリクエストが重くなりすぎて、意図しない規模のトークンを消費しそうになった場合

通常時のトークン消費量の目安

• 普段のチャット（1往復）: 約 5,000 〜 15,000 トークン （システムプロンプトや直近10〜20件程度の会話履歴を含めた場合）
• コードの相談や、少し長めのファイルを読ませる時: 約 20,000 〜 50,000 トークン

1分間に人間が手動で連投できる回数を考えても、通常は1分あたり多くて数万トークン程度に収まります。

おすすめのリミット設定値

#### プランA：安全・節約最優先（おすすめ！）

• 設定値：150,000 TPM (15万)
• こんな人向け: 普段の雑談、毎朝のクイズや英語レッスン、貴金属価格の通知がメインの場合。
• メリット: 普段の動作には100%影響しません。万が一スクリプトなどが無限ループで暴走しても、1分間あたりの被害を最小限（数円レベル）に抑えられます。

#### プランB：実用性とのバランス型（たまに開発や調べ物で酷使する時用）

• 設定値：300,000 〜 500,000 TPM (30万〜50万)
• こんな人向け: 複数の長大なソースコードを同時に読み込ませて議論したり、数十ページの技術ドキュメントを読ませて分析させたりすることがある場合。
• メリット: 重めの作業を連続でさせても「リミット到達エラー」にならず快適です。それでもデフォルトの上限（数百JST万〜千万トークンなど）に比べれば、十分強力な防波堤になります。

9.複数の対象についてWebの情報を取得まとめるときはトークンの肥大化を防ぐため、web_fetch は使用せず、web_search のスニペット（要約）情報のみでまとめる

参照リンクを付けるように、必要であれば自分で見に行く。

10.Gemini APIについて「gemini-3.5-flashをメインにし、エラー時やお安いチャンネルだけ2.5に逃がす」というフォールバック（二段構え）を設定する

AIに依頼。

11.高度な推論を必要としないDiscordの定期投稿スケジュールチャンネルをgemini-２.5-flashに変更する

対象チャンネルで

/model google/gemini-2.5-flash

と打つ。ただし、これは一時的な変更で、時間が経つと戻ってしまうため。AIにチャンネルを指定した2.5への固定を依頼するのもよい。2.5に固定されているチャンネルはsqlite3で以下のSQLをDBに対して実行することで、抽出できる。3.5デフォのままの場合は空白となっている。設定漏れ確認になかなか便利。

SELECT name, payload_model FROM cron_jobs;
週末のお子様向け時短レシピ提案|google/gemini-2.5-flash
ダニ除けシート取り換えアラート|google/gemini-2.5-flash