【RAG】Mac mini M4 Pro + Difyで社内ヘルプデスクを構築する2025(前編)
この記事について
別記事で「仕事でMac mini M4 Proを買うから、空き時間でLoRA学習やるぞ」という話を書いた。
そんなわけで、こっちが本題。社内ヘルプデスク向けRAGシステムの構築計画をまとめる。
社内の機密情報を扱う関係で外部SaaSには出せないため、LAN内にRAGを構築する方針になった。開発効率と実用性を最優先し、ゼロからコードを書くのではなく、ローコード開発基盤Difyを採用する。
1. システム構成図
| 項目 | 内容 |
|---|---|
| ハードウェア | Mac mini M4 Pro (24GB) |
| 基盤ソフトウェア | Docker (Difyを動かすために必須) |
| アプリケーション | Dify (チャットボット作成・管理ツール) |
AIモデルの選択肢
| 案 | 構成 | メリット | デメリット |
|---|---|---|---|
| A (推奨) | 外部API (OpenAI / Anthropic) | 賢い、メモリ食わない | 月額コスト、データ外部送信 |
| B (機密重視) | ローカルLLM (Ollama + Qwen2.5-14B) | データ漏洩なし | メモリ約10GB使用、調整が難しい |
2. なぜ2025年版Difyなのか
2025年12月時点の最新版Difyを使う。この1年(2024年末〜2025年末)のAI業界の進化は凄まじく、Difyの機能も別物レベルに進化している。
「社内ヘルプデスク」を作る上で、2024年版とは決定的に違う(便利になった)ポイントを4つに絞って解説する。
2-1. RAGの検索精度が段違い(GraphRAG)
2024年版では「キーワード検索」や「ベクトル検索」が主流だったが、最新版ではGraphRAG的な機能が強化・統合されている。
厳密にはGraphRAGとナレッジグラフは異なる概念だが、「情報同士の関係性を活用する検索」という点で共通している。詳しく知りたい方はMicrosoft Researchの解説記事が参考になる。
| 時期 | 挙動 |
|---|---|
| 2024年版 | 「エラーコード E-001」で検索 → その単語が含まれるページが出るだけ |
| 2025年版 | 「E-001」と「経理システム」と「再起動」の関係性を理解して検索 |
マニュアルが散らばっていても、AIが情報を繋ぎ合わせて回答するため、「トンチンカンな回答」が激減する。
2-2. エージェント機能の強化
以前は「質問に答えるだけ」だったが、最新版は「自律的に考える(Agentic Workflow)」能力が強化されている。
| 時期 | 挙動 |
|---|---|
| 2024年版 | 検索して無ければ「分かりません」 |
| 2025年版 | 1. 検索してみる → 2. 情報が足りなければユーザーに聞き返す → 3. 再検索 → 4. それでもダメなら「人間に繋ぎます」 |
この「聞き返し」や「再考」のロジックを、Dify上で簡単に組めるようになっている。
2-3. 画像(スクリーンショット)対応
マルチモーダルが標準になった。
- ユーザーがエラー画面のスクショを貼り付けて「これ何?」と聞ける
- Ollama(ローカルLLM)でも、LlavaやQwen-VLなどの視覚モデルを使えば、社外に画像を出さずに解析可能
2-4. ローカルLLM (Ollama) との連携安定化
2024年当時は「Ollama対応」といっても実験的な部分があったが、今は完全にネイティブ対応レベル。
- Function Calling対応: ローカルLLM(Qwen2.5など)を使っても、API版と同じように「社内DB検索ツール」や「Slack通知ツール」を正確に叩けるようになっている
- M4 Proの恩恵: 「賢いエージェント挙動」を外部APIなしの完全ローカルで実現しやすくなっている
3. 導入ステップ
仕事として成果を出すための最短ルート。
フェーズ1:環境構築(初日)
Macが届いたらまず行う土台作り。
Docker Desktop for Mac のインストール
Difyを動かすために必須。公式サイトからダウンロードしてインストールするだけ。
Dify のインストール
ターミナルで以下を実行。
git clone https://github.com/langgenius/dify.git
cd dify/docker
cp .env.example .env
docker compose up -d
これでブラウザ(http://localhost/install)から管理画面にアクセス可能になる。
重要: 必ず公式GitHubの最新の docker-compose.yml を使うこと。ネット上の古い記事(2024年前半のもの)をコピペすると動かない機能がある。
ネットワーク固定
社内LANから他の人がアクセスできるよう、MacのIPアドレスを固定する。
フェーズ2:プロトタイプ作成(〜1週間)
ここで「ちゃんと動くもの」を作る。
モデルの接続
Difyの設定画面でLLMを登録する。
仕事のアドバイス: 最初は外部APIを使うことを強く推奨。ローカルLLMより圧倒的に賢いため、「AIが馬鹿だから使えない」という初期評価を避けられる。
| モデル | 価格 (入力/出力) | 用途 |
|---|---|---|
| GPT-5.1 | 10 per 1M tokens | 最安クラス |
| Gemini 2.5 Pro | 10 per 1M tokens | 最安クラス、Google派 |
| Gemini 3 Pro | 12 per 1M tokens | 最新、200K超は割高 |
| Claude Sonnet 4.5 | 15 per 1M tokens | Anthropic派 |
| Claude Opus 4.5 | 25 per 1M tokens | 画像解析や複雑な推論 |
ナレッジ(マニュアル)の登録
PDFやWordの社内規定、トラブルシューティング集をDifyにアップロード。自動で「ベクトル化(検索できる形に変換)」される。
フェーズ3:ロジック実装(「人間へ転送」機能)
今回の肝となる機能。Difyの「ワークフロー」機能で作る。
フロー構築
[開始] → [知識検索(RAG)] → [LLM回答生成] → [分岐]
分岐条件の追加 (IF/ELSE)
- 条件: 「回答の確信度が低い」または「ユーザーが『役に立たない』ボタンを押した」
- TRUE (解決不能): [HTTPリクエスト] ノードへ進む。Slack/TeamsのWebhookを叩き、情シス担当者へ通知を飛ばす
- FALSE (解決): そのまま終了
4. M4 Pro (24GB) での運用ルール
24GBメモリでの運用目安。
| 構成 | メモリ使用量 | 備考 |
|---|---|---|
| Dify (Docker) のみ | 約4-6GB | 常時起動OK |
| Dify + ローカルLLM (Qwen2.5-14B) | 約14-16GB | 業務時間中の推奨構成 |
| Dify + ローカルLLM + 同時アクセス多数 | 約18-20GB | まだ余裕あり |
5. ランニングコスト
API利用時(案A)
- GPT-5.1 / Gemini 2.5 Pro: 入力10 per 1M tokens
- Gemini 3 Pro: 入力12 per 1M tokens
- Claude Sonnet 4.5: 入力15 per 1M tokens
- 月1000問 × 平均2000トークンとして、最安クラスで月$3-8程度
ローカルLLM時(案B)= 電気代のみ
- Mac mini M4 Pro の最大消費電力: 約65W
- フル稼働24時間×30日: 約46kWh → 約1,400円/月(30円/kWh計算)
- 現実的な使用(平均30W): 約650円/月
ローカルLLMなら「月数百円の電気代だけ」で運用できる。
6. 開発者へのアドバイス
まあ仕事なんで誰かに説明せにゃならんこともある。 そういうときは以下の手順をおすすめする。
「まずはAPI版で高精度なものを見せる」
ローカルLLMは調整が難しい。まずはAPIを使って「このシステムは便利だ」と認めさせ、その後に「コスト削減とセキュリティのためにローカル化(M4 Pro活用)を進めます」と言うほうが、たぶん納得感高い。
「ローカルLLMは14Bまで」
32B以上のモデルはM4 Proのメモリでは実用速度が出ない。「反応が遅い」とクレームになるので、欲張らずQwen2.5-14BやMistral-Nemo-12Bなど軽量・高性能なモデルを選ぶこと。
「切り替えたら性能落ちたぞ!」と言われたら
ローカルLLMはどうしてもAPIより性能が落ちる。更新頻度も違うし、これは仕方ない。
「ははは!やっぱAPIの方がいいですよね!」で済む環境ならそれでいい。でも現実にはセキュリティやコストの問題でそうもいかない人が多いはず。
そういうときは「コストとリスクのバランスはそちらで判断してください。こちらはどちらでも対応できます」と投げるしかない。技術者が決める話じゃない。
おまけ:「どうしてもローカルで性能上げろ」と言われたら
※ただしマシンは今のままで
かなりの無茶振りだが、「応答速度を犠牲にしていいですか?」という前提で進めるしかない。
- 32B〜70Bモデルを使う(Qwen2.5-32Bなど)
- メモリに収まりきらないので、推論がディスクスワップしながら動く
- 1回答に数十秒〜数分かかる覚悟が必要
「リアルタイム応答は諦めて、夜間バッチ処理で回答を生成しておく」みたいな運用に切り替えるなら、まあ不可能ではない。ただ、それヘルプデスクとして機能するのか?という話になる。
素直にマシン増強(メモリ64GB以上)か、APIに戻すことを勧めるべき。
まとめ
- Dify + Mac mini M4 Proで社内完結のRAGヘルプデスクは十分実現可能
- 2025年版DifyはGraphRAGやエージェント機能が強化されており、1年前とは別物
- 最初はAPIで成功体験を作り、徐々にローカル化するのが現実的な進め方
Mac miniが届いたら実際に構築してみる。後編では実際の導入手順と検証結果を報告予定。