エスマットでエンジニアをしているpotix2です。最近、 社内の EKS クラスター上に Dify 環境を構築していたときに設定ミスから予想外の問題に遭遇しました。この問題解決に Cline を活用したところ、コードリーディングの効率が大幅に向上し、従来の方法よりも短時間で原因特定ができました。
この記事では、SRE のための Cline 活用法と、実際のトラブルシューティング事例について共有します。
1 分まとめ
- Cline に実行ログを与えると、関連するコードを素早く特定できる
- Dify 環境の構築時、複数コンポーネント間のキャッシュ問題を Cline で効率的に解決した
- SRE こそ Cline を活用すべき、コードリーディングの効率が大幅に向上する
Dify でのトラブル：見えない依存関係の謎
Dify は、ノーコード・ローコードで AI アプリケーションを開発できるオープンソースのプラットフォームです。Dify は生成 AI アプリケーションの構築・運用プラットフォームで、Next.js で構築されたフロントエンド、API サーバー、プラグインデーモンなど、複数のコンポーネントが別々のコードベースに分かれています。
今回の問題は次のような状況でした：
- プラグインデーモンの設定がローカルストレージを使用するように設定されていたため、Kubernetes Pod 再作成時にインストール済みプラグインが消えるという問題が発生
- ストレージ設定を S3 に変更し、プラグインを再インストールしようとしたところ「ファイルが見つからない」というエラーが発生
- ファイルの書き込みエラーであればストレージ設定のミスとすぐに判断できるが、なぜ読み込み操作でエラーが出るのか、その原因が不明
Cline によるコードリーディングの実践
ここで Cline の活用が効果的でした。具体的には、API サーバーのデバッグログから、プラグインデーモンと通信しているログを抜き出して Cline に与えました：
以下は、プラグインをインストールする操作をDifyのWebインターフェイスから行った時のAPIサーバーのログです。この情報をもとに、プラグインのインストールをした時の処理の流れをmermaidで図示してください。
2025-03-19 09:34:39,875.875 DEBUG - "POST /plugin/******/management/installation/fetch/batch HTTP/1.1" 200 40
2025-03-19 09:34:39,945.945 DEBUG - "GET /plugin/******/management/models?page=1&page_size=256 HTTP/1.1" 200 40
2025-03-19 09:34:39,960.960 DEBUG - "GET /plugin/******/management/models?page=1&page_size=256 HTTP/1.1" 200 40
2025-03-19 09:34:39,964.964 DEBUG - "GET /plugin/******/management/models?page=1&page_size=256 HTTP/1.1" 200 40
2025-03-19 09:34:40,901.901 DEBUG - "GET /plugin/******/management/fetch/manifest?plugin_unique_identifier=langgenius%2Fgithub%3A0.0.2%40e65720a2d2f06233dd8e8b194d3b1b82e601aacf8c786ab4f958528981798226 HTTP/1.1" 200 None
2025-03-19 09:34:40,927.927 DEBUG - "POST /plugin/******/management/install/identifiers HTTP/1.1" 200 110
2025-03-19 09:34:41,020.020 DEBUG - "GET /plugin/******/management/install/tasks?page=1&page_size=100 HTTP/1.1" 200 None
2025-03-19 09:34:41,026.026 DEBUG - "GET /plugin/******/management/install/tasks/2658fb94-c2c6-43ec-b704-47e3bff58fd7 HTTP/1.1" 200 842
このとき書いてもらった図はあまり役に立たなかったのですが、そのあとのやりとりでいくつかヒントを得ることができました。
この説明から、プラグインパッケージを API サーバー側からアップロードするようなことはしていないことがわかります。プラグインデーモンの機能としては存在していますが、その箇所は今回の問題とは関係なさそうということが判断できました。
さらにこの説明からプラグイン識別子を使って、プラグインマーケットからインストールしており、エラーが発生しているのは、その過程だということが推測できました。
以上のヒントからプラグインマーケットプレイスからのインストールをするフローに絞ってコードを読んでいったところ、興味深い仕様が見つかりました。
プラグインデーモンはパッケージをダウンロードすると、それをデータベースに記録します。再インストール時には、ダウンロードをスキップしてキャッシュ情報を使用します。
ローカルストレージから S3 に切り替えた後も、データベースにはダウンロード済み情報が残っていたため、ダウンロードがスキップされ S3 からファイルが見つからないエラーが発生しました。
データベースのキャッシュレコードを削除したことで、プラグインデーモンが再度パッケージをダウンロードし、問題は解決しました。
Cline はトラブルシューティングの最強ツール
この経験から、Cline は OSS プロダクトを運用している際のトラブルシューティングに非常に有用だと感じました。トラブルシューティングツールとして Cline を使うときのコツを次のようにまとめました。
実行ログをコンテキストとして与える
ChatGPT にエラーログを渡して原因を考察してもらうということをやったことがある人は結構いるんじゃないでしょうか？Cline を使うと、関連コードを参照しつつ実行ログの解析を行えるのでより原因を絞り込んで考察することができます。
エラーメッセージとコードの対応付け
具体的なエラーメッセージとスタックトレースがあれば、Cline は関連するコード箇所を高精度で特定できます。
複数のコードベースを横断する調査
Dify の例では、API サーバー、プラグインデーモン、Kubernetes マニフェストの 3 つのウィンドウを使い分けました。現状ではコンテキストウィンドウに限界があるため、複数のコードベースを一つの Cline に読み込ませるのではなく、別々のウィンドウで開いて人間が情報の仲介役として動く方が効率的です。将来的にはまとめて処理できる可能性もありますが、現時点ではこのアプローチが現実的です。
まとめ：トラブルシューティングの新しいアプローチ
Cline を活用したコードリーディングは、特にドキュメント化されていない仕様や複数コンポーネント間の相互作用を理解する上で効果的です。今回の Dify 構築における問題解決では、従来のコードリーディング方法と比較して作業時間を大幅に短縮できました。
最も価値を感じたのは、実行ログという「動的な情報」とソースコードという「静的な情報」を結びつけることで、問題の本質に素早くアプローチできる点です。特に SRE こそ Cline を積極的に活用すべきだと実感しています。普段からコードを書くことが少ない SRE にとって、障害対応時のコードリーディングはボトルネックになりがちですが、Cline はその課題を解消してくれます。
日々の運用業務では「なぜこのエラーが出るのか」という謎を解く時間が少なくありません。Cline は SRE の業務効率化に貢献するツールとして、今後の活用を検討する価値があるでしょう。
最後になりますが、私たちエスマットでは生成 AI を活用した新しい開発プロセスの構築に挑戦しています。気になる方はカジュアル面談でお話ししませんか？お気軽にご連絡ください。
IoT重量計スマートマットを活用した在庫管理・発注自動化DXソリューション「SmartMat Cloud」を運営しています。一緒に働く仲間を募集しています。 s-mat.co.jp/recruit
Discussion