GridJapan Open source MIT v1.5.0

Windows 常駐の RAG サーバー

Google Drive の共有フォルダをセマンティック検索できるようにし、MCP（Model Context Protocol）経由で Claude Cowork / Claude Desktop / 任意の MCP クライアントから遠隔検索する。

GridJapan が自社の業務で日々運用している本番のソースを、そのまま MIT で公開しています。製品の販売ページではありません。

GitHub でソースを見る 開発の相談

search 840ms — 条件: warm / AWS API Gateway 経由 / リランカー込み / RTX 4070 SUPER。測定条件と CPU との比較

できること

社内の Drive を、Claude から検索できる状態にする

社内 Google Drive の資料（数万件）を横断的に検索し、別 PC の Claude Cowork から遠隔で呼び出すために構築したものです。

Index

共有フォルダを自動で索引

Google Drive の共有フォルダ群を、構造認識チャンク＋ベクトルで索引します。変更検知は Drive の Changes API で、有効化したドライブを 4 ワーカー並列で常時追跡します。

Search

セマンティック検索とリランク

PostgreSQL 17 + pgvector に格納し、BGE-m3 の cross-encoder で Top-K を並び替えます（ENABLE_RERANKER=1）。埋め込みは 768 次元。

Remote

MCP 経由で遠隔から

Streamable HTTP + Basic Auth の MCP サーバーを公開し、別マシンの Claude Cowork / Claude Desktop / 任意の MCP クライアントから検索できます。クエリログ付き。

Operate

常駐運用向けの画面と仕組み

Web モニターと Electron ミニモニター、日次 7 + 週次 4 世代のバックアップ、品質を定量監視する Eval Suite。障害時はゾンビ GC と多重起動防止が効きます。

このページについて

公開しているもの、していないもの

WinServerRAG は、GridJapan が自社で日々運用している Windows 常駐 RAG サーバーのソースを MIT で公開したものです。このブランチのコードは、実際に業務で使っている本番のコピーです。

本ページは製品の販売ページではありません。構成・実測性能・セキュリティ設計を公開することと、同種の AI × 業務システム開発のご相談窓口を兼ねています。この 2 つを兼ねていることを、隠さずに書いておきます。

導入事例・価格・他製品との比較は掲載していません。手元にある事実は、自社運用の実物と、その測定値だけです。

構成

実際に動いている画面

下の 2 枚は、運用中の管理画面のスクリーンショットです。

WinServerRAG Web Monitor の画面。GPU 利用率、ワーカーカード、共有フォルダ一覧、MCP 検索設定タブが 1 画面に並んでいる
Web Monitor（http://127.0.0.1:17600/）。GPU 利用率・worker カード・ドライブ一覧・MCP 検索設定タブを 1 画面に。FastAPI 上で動く SPA で、Mini Monitor と同じ /api/stats を裏で叩いています。
WinServerRAG Mini Monitor の画面。Daemon 状態、ビルド進捗、FD 数、DB サイズ、Worker pill が縦に並んだ小窓

Mini Monitor

always-on-top の小窓（360×400）。デーモンの状態を常時見ておくためのものです。

  • Daemon 状態 / ビルド進捗 / FD 数 / DB サイズ / Worker pill を 250ms ポーリングで表示
  • Pause / Resume と Monitor 起動を Electron 内 IPC で操作
  • Daemon の状態は sc query を 5 秒間隔で直接見るため、API が停止していても正しく表示される

アーキテクチャ

Google Drive 共有フォルダ
Changes API で差分検知
rag_daemon
N threads（既定 4）／構造認識チャンク＋埋め込み
PostgreSQL 17 + pgvector
ドライブごとに分離スキーマ fd_<drive_id>.documents／VECTOR(768)
control_api（FastAPI）
127.0.0.1:17600
Web Monitor
localhost
Mini Monitor
Electron・常駐
MCP server /mcp
Basic Auth + Streamable HTTP
Claude Cowork
別マシンから遠隔

出典: README（アーキテクチャ図・画面の説明）

性能

CPU から GPU に替えたときの実測値

同じクエリ・同じ DB で比較したものです。環境は RTX 4070 SUPER（12GB VRAM）。

項目CPU only（OMP=1）GPU（RTX 4070 SUPER）改善倍率
search warm3〜13 秒840 ms4〜15 倍
search cold23 秒17.7 秒1.3 倍
フルビルド（221 files）6〜8 分5 分1.2〜1.6 倍
GPU 使用率 ピーク—78%—
VRAM ピーク—7 GB（12 GB 中）—
消費電力（推論中）CPU 200W 級122 W—

出典: docs/EVOLUTION.md Phase 4（同一クエリ・同一 DB での比較）。README 記載の warm search 840ms は、AWS API Gateway 経由・リランカー込み・RTX 4070 SUPER の条件です。

効いた場所

速くなったのはビルドではなく検索

ビルドは Google Drive API（Sheets / Docs / PDF）の I/O が支配的で、埋め込みを GPU にしても待ち時間が大半を占めるため頭打ちになりました。一方、検索時のリランカー（BAAI/bge-reranker-v2-m3）は候補 50 件 × クエリのペアを cross-encoder に通す処理で、これが CPU で重い。ここが GPU で捌けるようになり、warm 検索が 3 秒台から 840ms になりました（上の表の warm 行と同じ測定。AWS API Gateway 経由・リランカー込み・RTX 4070 SUPER）。

原因

CPU ビルドの PyTorch が入っていた

torch=2.11.0+cpu が入っており（pip の既定挙動）、torch.cuda.is_available() が False を返していました。物理 GPU は正常。cu124 ビルドに入れ替えたところ、_pick_device() が既に cuda.is_available() を見ていたためコード変更ゼロ、デーモン再起動だけで GPU に切り替わりました。

セキュリティ

権限の境界

管理者権限を要求するのはインストールの 1 回だけです。日常の運用に管理者権限は要りません。

1. インストール時

管理者権限は 1 回だけ

インストーラーが NSSM で 2 つのサービスを登録し、SDDL を設定し、ローカルグループ WinServerRAG Operators を作成します。

2. 日常運用

Operators グループのみ

付与するのは SERVICE_QUERY_STATUS と SERVICE_START のみで、SERVICE_STOP は付与しません。一般ユーザーや全認証ユーザーは起動できません。

3. ミニモニター

インストールは行わない

Electron の通常権限（UAC 不要）で動き、SDDL 緩和済みサービスの起動のみ可能。install 系コマンドは一切実行しません。

認証・分離

アクセス制御

  • MCP は Basic Auth（パスワードは PBKDF2-SHA256）
  • ドライブごとに PostgreSQL のスキーマを分離
  • AWS 側は IAM 最小権限
  • 管理 API は API_BEARER_TOKEN を設定可。空の場合は localhost のみ

耐障害性

多重起動・stale への対策

  • lockfile で多重起動防止（PID 生存確認、stale 検知）
  • pg_try_advisory_lock でプロセス跨ぎの排他制御
  • ゾンビ GC が stale worker 行を 30 秒ごとに回収
  • heartbeat が 120 秒を超えた worker は stale 判定

出典: README（セキュリティ境界・耐障害性）

MCP

提供されるツール

tool引数説明
list_drives—検索スコープのドライブ一覧
searchquery, n_results=10, owner?セマンティック検索
lookupurl特定 Drive URL の全文取得
stats—インデックス統計

接続手順は MCP.md にあります。

前提環境

OSWindows 11
DBPostgreSQL 17 + pgvector（Windows ネイティブ）
GPURTX 4070（CUDA 12.4）
Python3.12+
Embeddingparaphrase-multilingual-mpnet-base-v2（768 次元）
RerankerBGE-m3 cross-encoder（BAAI/bge-reranker-v2-m3）
管理 API127.0.0.1:17600
ワーカー数既定 4（DAEMON_WORKER_THREADS、UI から 1〜10 に変更可）

導入手順は README のクイックスタートを参照してください。インストーラーは GridWorldOrganization/GridWorldRAG の Releases で配布しています。

開発の相談

AI × 業務システムの開発を請け負っています

GridJapan は日本の小さなエンジニアリングショップです。このページで公開しているようなシステムを含め、以下のようなテーマでご相談を歓迎します。

  • 社内ナレッジを LLM / RAG 経由で検索できる仕組み
  • Claude / OpenAI / 独自 LLM の業務組み込み（MCP / Function Calling / Agent）
  • Windows サーバー上で動く AI システム（GPU 活用、常駐サービス化）
  • Google Workspace / Microsoft 365 など既存ツールとのネイティブ連携
  • 既存の業務データから RAG データセットを構築するパイプライン
tobisako@gridworld.co GitHub Issue で相談する