
※こちらの記事は2025年10月2日noteに投稿した内容です。
Difyは高機能なAIアプリケーション開発プラットフォームのひとつとして人気を集めています。これまでもバージョンアップを重ねて、新機能も次々と追加されています。しかしバージョンアップの際には仕様が変更される場合もあり、仕様変更に伴うデータ移行でレコードの削除や破損が起きて不具合が生じる場合があります。
今回Geminiを使ったLLMノードでエラーが生じたので原因を調査していたところ、APIキーの認証設定でもエラーが出てAPIキーの削除や再設定などの操作ができなくなっていました。
エラーの原因となっているレコードをデータベースから削除し、APIキーを再設定することで不具合が解消されましたので作業の流れを備忘録として残しておきます。
何回かAPIキーを再設定している段階でUI上には表示されず、データベース上にはレコードが複数登録されてしまっていたので、今回はGeminiに関する設定を全て削除してクリーンな状態でAPIキーを再設定しました。
※Dify 1.9.1、Plugin-daemon 0.3.1の動作環境で行っております。
※作業前にはイメージ保存をお忘れなく。
0. エラーの確認と作業の流れ
LLMノードでのエラーとAPIキー認証設定でのエラーを確認します。
LLMノードでのエラー

Run failed: [google] Error: req_id: f3a9d27eed PluginInvokeError: {"args":{},"error_type":"ClientError","message":"400 INVALID_ARGUMENT. {'error': {'code': 400, 'message': 'API key expired. Please renew the API key.', 'status': 'INVALID_ARGUMENT', 'details': [{'@type': 'type.googleapis.com/google.rpc.ErrorInfo', 'reason': 'API_KEY_INVALID', 'domain': 'googleapis.com', 'metadata': {'service': 'generativelanguage.googleapis.com'}}, {'@type': 'type.googleapis.com/google.rpc.LocalizedMessage', 'locale': 'en-US', 'message': 'API key expired. Please renew the API key.'}]}}"}
LLMノードでのエラー内容からエラーの原因がAPIキーにあることがわかるのでAPIキーの再設定を試みます。
※新しいAPIキーを再設定してエラーが解消する場合もあります。
APIキー認証設定でのエラー

Credential with id 0198f073-cbf4-7622-98d0-dd4ed778e5b9 not found.
エラーの内容から認証に関するIDが見つからないことが原因であることがわかります。今回はGeminiに関するレコードを全て削除するのでIDを控える必要はありませんが、問題のあるAPIキーのレコードを個別に削除する場合はIDを控えてデータベースより削除してください。
作業の流れ
1.データベースからGeminiに関するレコードを全削除
2.キャッシュとコンテナの完全リセット
3.ブラウザのキャッシュクリア
4.プラグインからGeminiの削除と再インストール
5.Gemini APIキーの再設定
1. データベースからGeminiに関するレコードを全削除
PostgreSQLに接続します。
# PostgreSQLに接続
cd /root/dify/docker
docker exec -it docker-db-1 psql -U postgres -d dify
Gemini関連の全レコードを削除します。
-- Gemini関連の全レコードを削除
DELETE FROM provider_credentials WHERE provider_name = 'langgenius/gemini/google';
DELETE FROM provider_credentials WHERE provider_name LIKE '%gemini%';
-- 削除確認(0 rowsになればOK)
SELECT COUNT(*) FROM provider_credentials WHERE provider_name LIKE '%gemini%';
-- 他のテーブルも確認して削除
DELETE FROM provider_model_credentials WHERE provider_name LIKE '%gemini%';
DELETE FROM provider_model_settings WHERE provider_name LIKE '%gemini%';
DELETE FROM provider_models WHERE provider_name LIKE '%gemini%';
DELETE FROM providers WHERE provider_name LIKE '%gemini%';
DELETE FROM tenant_preferred_model_providers WHERE provider_name LIKE '%gemini%';
-- 最終確認
SELECT * FROM provider_credentials WHERE provider_name LIKE '%gemini%';
\q
2. キャッシュとコンテナの完全リセット
Redisキャッシュをクリアしてコンテナを再起動します。
# Redisキャッシュをクリア
docker exec -it docker-redis-1 redis-cli FLUSHALL
# 全コンテナを再起動
cd /root/dify/docker
docker compose restart
# 起動確認
docker ps
docker logs docker-api-1 --tail 30
3. ブラウザのキャッシュクリア
Ctrl + Shift + Delete → 全てのキャッシュとCookieを削除
これでGemini関連の設定が完全に削除されます。その後、モデルプロバイダー画面でGeminiが「設定中」セクションから消えていることを確認します。
4. プラグインからGeminiの削除と再インストール
モデルプロバイダー画面でGeminiが「設定中」セクションに残っている場合は、プラグインからGeminiを削除して再インストールします。

5. Gemini APIキーの再設定
新しいAPIキーを取得して設定します。
※既存のAPIキーを再設定できるかもしれませんが動作確認はしていません。

APIキーの保存が正常に行われれば作業完了です。チャットフロー・ワークフローのLLMノードで動作確認してください。
今回の問題の原因とまとめ
- バージョンアップ時のマイグレーション不具合
- データベース内に古い認証情報ID(0198f073-cbf4-7622-98d0-dd4ed778e5b9)が残存
- UIがこの存在しない認証情報を参照してエラー
- 解決方法
- データベースから破損レコードを削除
- プラグインの再インストール
今回はGemini APIでの不具合を例にしましたが、他のモデルの場合はそれぞれのモデル名などに置き換えてお試しください。