社内規約RAGチャットボット システム設計プラン
最終更新: 2026-03-01 レビュー反映済み: code-review-specialist による設計レビュー(2026-02-28)
概要
社員が社内規約・福利厚生・ルールを自由に問い合わせできる社内ポータル。 メインコンテンツとして、ローカルLLM(Ollama)を使ったRAGチャットボットを実装する。
絶対条件: データを社外に出さない(完全ローカル動作) 将来方針: パッケージ販売を見据え、拡張性・移植性を重視する v1.0方針: 各企業に個別Dockerインスタンスを構築するシングルテナント方式(マルチテナントは将来ロードマップに予約)
競合ポジション
競合分析
最終更新: 2026-03-01
カテゴリA: オンプレ/ローカル型AIドキュメント検索(直接競合)
カテゴリB: SaaS型ナレッジ管理(間接競合・データクラウド送出)
カテゴリC: 日本市場特化(最重要競合)
カテゴリD: Microsoft/Googleエコシステム
競合脅威マトリクス
最大の競合脅威
- スマキテ(新日本法規) — 同一ターゲット(社内規約・就業規則)で国産SaaS。弱点:データ社外送出・SaaS前提
- Dify + ローカルLLM — 無料・Docker対応・日本語サポート。弱点:汎用PFで規約特化機能なし
- Microsoft 365 Copilot — 既存M365導入企業への侵食リスク。弱点:高額・クラウド前提
差別化ポイント(競合不在領域)
まとめ: 「完全ローカル × 日本語特化 × 社内規約バージョン管理」を満たす直接競合は存在しない。 差別化を守るには日本語RAG精度の継続改善(Phase 9)と規約管理機能の充実が鍵。 最大潜在脅威はDify: 無料・Docker対応・日本語対応が改善中のため動向注視が必要。
マシン構成・実行環境
採用機種の選定経緯(PC比較)
詳細比較(Mac Studio M3 Ultra・Mac Pro・NVIDIA GPU含む)は PLAN_08 Hardware を参照。
LLM推論速度の最大のボトルネックは メモリ帯域幅。帯域が広いほどトークン生成が速い。
採用理由(#5 Mac Studio M4 Max 48GB): M4 Max の 546 GB/s 帯域で gemma3:27b が 30〜40 tok/s を確保。同価格帯の Mac mini M4 Pro 64GB(#3)と比べて LLM 速度が約2倍。予算・性能・メモリ余裕のバランスが最良。
LLMモデル比較(採用ハードウェア前提)
LLMが使えるメモリ上限の試算(48GB中): 48GB − システム9GB − Embedding2.5GB − Reranker2GB − FastAPI1GB − PostgreSQL0.5GB − ChromaDB1GB ≈ ~32GB
モデル変更は容易:
ollama pull <model>→.envのOLLAMA_MODELを変更 → FastAPI 再起動のみ。Embeddingモデルと異なりDBへの影響はゼロ。 詳細な比較・切り替え手順は PLAN_02 を参照。
ハードウェア
採用構成:AIはホスト直接起動、DBはDocker
Mac上のDockerはLinux VMを経由するためMetal GPU(MPS/Neural Engine)にアクセスできない。 LLM推論・Embedding・Rerankerすべてがホスト直接起動必須。PostgreSQL・ChromaDBはDockerで管理。
メモリ配分の概算(48GB中)
⚠️ 本番マルチワーカー時の注意: Gunicorn + Uvicornで複数ワーカーを起動すると、各ワーカーがEmbedding/Rerankerを個別にロードする。4ワーカー時はEmbedding+Rerankerだけで(2.5+2.0)×4=18GB。gemma3:27bは17GB固定。合計35GB → 48GBで余裕13GB。→ Phase 10でモデル共有設計が必要(詳細はPhase 10 TODO参照)。
💡 速度について: M4 Max は546 GB/s帯域のため
gemma3:27bで30〜40 tok/sを確保。速度優先ならgemma3:12b(~8GB, ~55-60 tok/s)も選択肢。