過去の自分が最強の先生に！？Dify×チャット履歴DBで挑戦したRAGシステム構築の記録

2025年8月22日 00:14

こんにちは！YaroTechです。

「あれ、前にも同じ問題解決したはずなのに...どうやったっけ？」
「過去のアイデア、どこにメモしたかな...」
「このエラー、確か以前も遭遇したような...」

そんな経験ありませんか？

私も42日間のnote連続投稿の中で、何度も「過去の自分」に助けを求めたくなる瞬間がありました。そして今日、Day36で作ったチャット履歴DBとDay42で構築したDifyを組み合わせて、過去の自分を先生にするRAGシステムに挑戦しました！

結論から言うと...完璧には動作しませんでしたが、その過程で得られた知見と解決への道筋を共有します。

🖥️ 実行環境

PC: Surface Laptop 7th Edition
CPU: Snapdragon X Elite (ARM64)
OS: Windows 11 Pro 24H2
Dify: v1.7.2（Docker版）
チャット履歴: Claudeエクスポート（226チャット、64MB）
Python: 3.11
Docker Desktop: WSL2バックエンド

🎯 この記事で得られること

Claudeのチャット履歴をエクスポートする方法
DifyのWorkflow機能での知識検索実装手順
ARM版Windows特有の注意点
うまくいかなかった時のトラブルシューティング
代替案としてのSQLiteデータベース活用法

📊 実際の挑戦結果

想定: 過去の解決策を瞬時に検索できるシステム
現実: 知識検索は動作したが、LLMへの連携で苦戦
学び: Difyの変数連携の重要性を痛感
次の一手: SQLiteデータベースの活用で解決可能

🚀 実践内容

ステップ1: Claudeからチャット履歴をエクスポート

まず、Claudeの設定画面から全チャット履歴をエクスポートしました。

1. Claude設定 → データ管理
2. 「エクスポート」をクリック
3. ZIPファイルをダウンロード（約64MB）
4. 解凍すると3つのJSONファイル
   - conversations.json（チャット履歴）
   - projects.json（プロジェクト情報）
   - users.json（ユーザー情報）

発見した問題点：

エクスポートされたJSONの構造が特殊
`chat_messages`フィールドにメッセージが格納
すべてのメッセージの`sender`が`human`として記録される

ステップ2: データ構造の調査とCSV変換

エクスポートされたデータを調査したところ、予想外の構造でした：

# 調査スクリプトの結果
チャット総数: 226
メッセージを含むチャット数: 222/226
ファイルサイズ: 64.32 MB

# 問題：すべてのsenderが'human'
# Assistantの応答が区別できない！

そこで、複数の変換スクリプトをクロ助（ClaudeDesktop）が作成：

シンプル版（`export_dify_simple.py`）
詳細版（`export_for_dify.py`）
修正版（`export_dify_fixed.py`）

しかし、Human/Assistantの区別ができないという根本的な問題が残りました。
※変換スクリプトを公開してほしい方はコメントで「公開希望」としてください。

ステップ3: DifyでのWorkflow構築

Difyで以下のようなWorkflowを構築しました：

開始 → 知識検索 → LLM → 回答

設定内容：

Knowledge作成
- 名前：Personal Chat History
- CSVファイルをアップロード
- Chunking: Paragraph（500 tokens）
Workflow設計
- 開始ノード：ユーザー入力を受け取る
- 知識検索ノード：Knowledgeから関連情報を検索
- LLMノード：検索結果を基に回答生成
- 回答ノード：結果を出力

ステップ4: 遭遇した問題と試行錯誤

問題1: 知識検索は動作するが、LLMが結果を受け取れない

画面左側には検索結果（#22556、#21046など）が表示されるのに、LLMは「情報が取得できませんでした」と回答。

試した解決策：

System Promptに`{{#1734.result#}}`を追加
Input Variablesで`context`変数を設定
デバッグ用プロンプトで変数の受け渡しを確認

問題2: MCPを「Minecraft」と誤解

知識ベースに正しくデータが入っているのに、MCPを「Minecraft Coder Pack」と解釈してしまう現象が発生。

⚠️ つまずきポイントと解決策

問題1: Claudeエクスポートの構造問題

症状: すべてのメッセージが`sender: human`として記録される

解決策:

メッセージの長さで推定（500文字以上をAssistantと仮定）
または、SQLiteデータベースを使用（推奨）

問題2: 変数の受け渡し問題

症状: 知識検索の結果がLLMに渡らない

解決策:　LLMのコンテキストで知識検索の出力変数を指定したら、一応受け渡しはできていそうです。

LLMノードの設定:
Input Variables:
  context: {{#知識検索ノードID.result#}}
System Prompt:
  検索結果: {{context}}

問題3: ARM版での処理速度

症状: Knowledgeのインデックス作成が遅い

解決策:

Docker Desktopのメモリ割り当てを6GBに増加
他のブラウザタブを閉じてメモリを節約

💡 代替案：SQLiteデータベースの活用

Claudeエクスポートの問題を回避するため、Day36で作成したSQLiteデータベースを使う方法が最も確実です：

# SQLiteからのエクスポート
def export_from_sqlite():
    conn = sqlite3.connect('chat_history.db')
    query = """
    SELECT 
        c.chat_name as title,
        m.content as content
    FROM messages m
    JOIN chats c ON m.chat_id = c.id
    WHERE m.role = 'assistant'
    AND length(m.content) > 100
    """
    # CSV出力処理...

この方法なら：

Human/Assistantが正確に区別される
既に構造化されたデータを活用できる
Day36の成果を有効活用

🔗 関連記事

今回の実装に関連する過去記事もぜひご覧ください：

Day36: チャット履歴DBで過去の自分から学ぶ！SQLiteで作る最強の知識管理システム

Day42: ARM版Windows完全対応！Difyで作る自分専用AI統合プラットフォーム

📝 まとめと今後の展望

今回のRAGシステム構築は、完璧には動作しませんでしたが、多くの学びがありました：

学んだこと：

Difyの変数連携の重要性
Claudeエクスポート形式の制限
Workflowデバッグの方法
SQLiteデータベースの有用性

今後の改善点：

SQLiteデータベースを直接使用する方法の確立
Chatbot型での再実装
より詳細なデバッグ手法の習得

失敗も含めて、すべてが学びです。完璧でなくても、挑戦することに意味があります。

木曜日のラストスパート、諦めずに次の方法を試していきます！

🚀 次回予告

明日Day44は金曜日！気を取り直して、新たな挑戦です。

「Dify×Gmail連携で作る最強AI秘書！メール自動返信＆スケジュール管理」をお届けします。

今日の経験を活かして、より実践的なシステムを構築します。金曜日の定時退社を目指して！

お楽しみに！

#Dify #RAG #知識管理 #AI活用 #チャット履歴 #トラブルシューティング #ClaudeDesktop #ARM64 #YaroTech #note43日目