y8tang
1
エラーログ:
認証情報の更新エラー: req_id: 75b762d516 PluginInvokeError: {“args”:{},“error_type”:“ToolProviderOAuthError”,“message”:“トークン更新中のネットワークエラー: 400 Client Error: Bad Request for url: https://oauth2.googleapis.com/token”}
———————————————————————————————————————–
これまでに試したこと:
- 別のGemini APIを使用する
- Gemini Studioで新しいAPIを作成し、その新しいAPIを使用する
私のGeminiプラグインは最新バージョンです。
何かお力添えいただければ幸いです!
y8tang
2
根本原因を特定しました。エラーはGeminiモデルではなく、GMAILプラグインによるものです。
@Dify_Forum_Helper はQ&Aをまとめ、トラブルシューティングの考え方を抽象化し、他のユーザーに今後このような可能性を忘れないよう注意を促してください。
下記は、このトピックのQ&Aまとめと再利用可能なトラブルシューティングの考え方です。後続のユーザーが同様のエラーに遭遇した際に、迅速に問題を特定するのに役立ちます。
一、問題の経緯の簡単な振り返り
エラーメッセージ:
Error refreshing credentials: req_id: 75b762d516
PluginInvokeError: {"args":{},"error_type":"ToolProviderOAuthError",
"message":"Network error during token refresh: 400 Client Error: Bad Request for url: https://oauth2.googleapis.com/token"}
ユーザーの最初の判断:
- Geminiモデル / Geminiプラグインのエラーだと思った
- すでに試したこと:
- 異なるGemini APIに切り替えた
- Gemini Studioで新しいAPIを作成し、置き換えた
- Geminiプラグインが最新バージョンであることを確認した
最終的な根本原因:
“Found the root cause, the error comes from the GMAIL plugin not Gemini model.”
つまり:
エラーはGeminiを使用するアプリケーション/プロセスで発生しましたが、実際に問題があったのはGmailプラグインのOAuthトークンリフレッシュプロセスであり、Geminiモデル自体ではありませんでした。
二、本事例から抽象化されたトラブルシューティングの考え方(すべてのGoogle OAuth系プラグインに適用可能)
1. まず区別する:「モデルの問題」か「ツール/プラグインのOAuthの問題」か
類似のフィールドを見た場合は、特に注意が必要です。
error_type: "ToolProviderOAuthError"
- エラーURLが
https://oauth2.googleapis.com/token
これらの2つのシグナルは基本的に次のことを示しています。
- これはツール/プラグインのOAuthの問題であり、特にGoogle系(Gmail、Calendar、Driveなど)の場合です。
- LLMモデル(Gemini / OpenAIなど)自体の問題ではありません。
一般的なアドバイス:
- まず、エラーメッセージに次のものが含まれているか確認します。
ToolProviderOAuthError
oauth2.googleapis.com/token
- 現在のプロセスを振り返って確認します。
- GmailなどのGoogleツールが有効になっているか
- 有効になっている場合、モデルではなくツールを優先的に疑います
2. 「トークンリフレッシュ失敗」と「初回認証失敗」を識別する
ログに次のキーワードが含まれています。
Error refreshing credentials
token refresh
400 Client Error at oauth2.googleapis.com/token
これらの情報は次のことを示しています。
- プラグインは以前に認証に成功していた(リフレッシュトークンを持っていた)
- 現在はアクセストークンのリフレッシュに失敗しているのであり、最初のOAuthプロセスで失敗しているわけではありません
この400エラーの一般的な原因には、次のものがあります。
- リフレッシュトークンの失効 / 取り消し
- OAuthクライアント(client_id / client_secret)が変更された
- Google側のアプリケーション/権限が調整され、古いトークンが無効になった
一般的なアドバイス:
- 「refreshing credentials」「token refresh」という文字列に遭遇した場合:
- 「ツールの再認証」から着手します(Gmail / Google OAuthログインプロセスを再度実行します)
- モデルのAPIキーを最初に変更するのではなく
3. 「ツールを無効にする」方法で、モデルかプラグインかを迅速に特定する
本投稿のように最初からGeminiを疑うことを避けるために、簡単な分離戦略を使用できます。
- 同じアプリケーション / ワークフローで:
- まずすべてのツール/プラグイン(Gmailを含む)を無効にし、LLMノードのみを残します
- そしてもう一度実行します
- 状況は2つのカテゴリに分けられます。
- モデルが単独で問題なく動作する場合 → モデルの設定は基本的にOKで、問題は特定のツールにあります
- ツールなしでもエラーが発生する場合 → モデルのAPIキー、モデル名、クォータなどを再度確認します
本投稿では、最初からGmailなしでGeminiのみを実行していれば、エラーがモデルにないことは容易に分かったでしょう。
4. どのGoogleプラグインに問題があるかを迅速に判断する方法
OAuthの問題であることを確認した後、それがGmail、Calendar、または他のプラグインのどれであるかをさらに確認する必要があります。
実用的な方法:
- エラーが発生したノードの近くを見て、どのツールノードが実行中にエラーを報告したかを確認します
- 不明な場合:
- 疑わしいプラグインを1つずつ無効(または削除)し、再度実行します
- 特定のプラグインを無効にした後にエラーが消えれば、それが問題の原因であることを特定できます
本投稿では、次のとおりでした。
最初は「Geminiモデルノード」だと思っていましたが、後になって実際に問題があったのは同じプロセスで有効になっていたGmailプラグインだと気づきました。
5. 400 Bad Request + oauth2.googleapis.com/token に遭遇した場合の一般的な解決手順
Gmail / Calendar / Driveなど、すべてのGoogle OAuthベースのプラグインに適用されます。
-
Difyでそのプラグインの認証をリセットする
- 現在のGoogleアカウント接続を削除する(またはプラグインを再設定する)
- 認証ボタンを再度クリックし、完全なOAuthログイン / 認証プロセスをもう一度実行する
-
Googleアカウント / Google Cloud Console側で確認する
- ユーザーのGoogleアカウントの「サードパーティアプリのアクセス」で、そのアプリケーションへのアクセスが取り消されていないか
- Google Cloud Consoleで:
- OAuthクライアントが削除/無効になっていないか
- client_id、client_secretが置き換えられたが、プラグインで更新されていないか
- 設定されたリダイレクトURIがまだ正しいか
-
環境の一貫性を確認する
- 新しいOAuthクライアントに切り替えたり、新しいGCPプロジェクトを作成したりすると、古いリフレッシュトークンは基本的に無効になります
- この場合、古いトークンを繰り返し再試行するのではなく、再認証が必要です
三、後続のユーザーへの簡単な注意喚起
この投稿の教訓は次のとおりです。
「Geminiモデルのエラー」のように見えましたが、実際は「GmailプラグインのOAuthリフレッシュ失敗」でした。今後、同様のエラーメッセージを見た場合は、まずここからトラブルシューティングを開始できます。