東京・シンガポール・台北・ロサンゼルスの専用サーバーで構築するプライベート AI サポートナレッジベース（RAG）

越境ビジネスで社内向け AI カスタマーサポート・ナレッジベース（RAG）を運用する最も現実的な方法は、ドキュメント・ベクトルデータベース・チャット履歴を自社で管理する専用サーバーに置き、埋め込みと回答生成のときだけ公式の LLM API を呼び出す構成です。IMIDC は東京（日本）、シンガポール、台北（台湾）、ロサンゼルス（米国）で専用サーバーを提供しており、いずれも OpenAI・Anthropic Claude・Google Gemini の API が公式に利用できる地域なので、顧客データをサービス対象地域内に保てます。

サポート用 RAG ナレッジベースの仕組み

RAG（検索拡張生成）はモデルの記憶ではなく自社ドキュメントを根拠に回答させるため、誤回答を減らし、ポリシーに沿った応対ができます。

流れはシンプルです。マニュアル、FAQ、返品ポリシー、製品仕様書、過去チケットの解決内容をチャンクに分割し、それぞれをベクトル（埋め込み）に変換してベクトル DB に保存します。質問が来たら質問文もベクトル化して近いチャンクを検索し、そのチャンクと質問だけを LLM に渡して、出典付きの回答を作らせます。

• 取り込み：PDF、DOCX、HTML、Markdown、Zendesk／Freshdesk のエクスポート、Notion や Confluence。
• 検索：ベクトル検索＋キーワード検索のハイブリッド。言語・製品・権限でフィルタ。
• 生成：LLM が下書きしオペレーターが承認、またはウィジェットで直接回答。

日本語・英語・中国語の問い合わせを扱う越境 EC 事業者なら、多言語インデックス 1 つで全チャネルに対応できます。

SaaS ではなく専用サーバーを選ぶ理由

ドキュメント量が多い、データ管理要件が厳しい、問い合わせ量が安定している——そんな場合は、メモリ・ディスク・コストが固定で、送ると決めたチャンク以外はデータがサーバー外に出ない専用サーバーが有利です。

鍵になるのはメモリです。1536 次元・float32 のベクトル 100 万件で生データだけで約 6 GB、さらにインデックス分が加わります。Qdrant も pgvector もインデックスが RAM に載っているときに最も高速です。64〜128 GB の RAM を積んだ専用サーバーなら、ベクトル、PostgreSQL、取り込み処理、キャッシュを余裕を持って載せられ、小型 VPS のような他ユーザーの影響も受けません。

ロケーション選び：東京・シンガポール・台北・ロサンゼルス

顧客と法的義務がある地域に、かつ AI API が公式提供されている地域に置くのが原則です。

リファレンス構成と Docker Compose

最初はコンテナ 3 つで十分です：ベクトル DB、メタデータとチャット履歴用の PostgreSQL、そして自社の取り込み／チャット API。

先に Docker をインストール（ヘルプセンターの Docker 導入ガイド参照）し、以下のファイルを作成します。ポートはすべて 127.0.0.1 にバインドし、外部公開は Nginx＋HTTPS 経由のみとします。

# docker-compose.yml - private RAG stack (all ports bound to localhost)
services:
  qdrant:
    image: qdrant/qdrant:v1.12.4
    restart: unless-stopped
    volumes:
      - ./qdrant_storage:/qdrant/storage
    ports:
      - "127.0.0.1:6333:6333"
    environment:
      QDRANT__SERVICE__API_KEY: ${QDRANT_API_KEY}

  postgres:
    image: pgvector/pgvector:pg16
    restart: unless-stopped
    environment:
      POSTGRES_USER: rag
      POSTGRES_PASSWORD: ${PG_PASSWORD}
      POSTGRES_DB: kb
    volumes:
      - ./pgdata:/var/lib/postgresql/data
    ports:
      - "127.0.0.1:5432:5432"

  rag-api:
    build: ./rag-api          # your ingestion + retrieval + chat service
    restart: unless-stopped
    env_file: .env            # OPENAI_API_KEY / ANTHROPIC_API_KEY / GEMINI_API_KEY
    depends_on: [qdrant, postgres]
    ports:
      - "127.0.0.1:8080:8080" # publish through Nginx + HTTPS only

# .env (chmod 600, never commit)
QDRANT_API_KEY=change-me-long-random
PG_PASSWORD=change-me-long-random
OPENAI_API_KEY=sk-...
ANTHROPIC_API_KEY=sk-ant-...
EMBED_MODEL=text-embedding-3-small
CHUNK_TOKENS=500
CHUNK_OVERLAP=60

DB を 1 つにまとめたい場合は Qdrant を外し、pgvector でメタデータとベクトルを管理します。

-- pgvector alternative: one table, one HNSW index
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE chunks (
  id bigserial PRIMARY KEY,
  doc_id text NOT NULL,
  lang text,
  acl text[],                -- which teams/customers may see it
  content text NOT NULL,
  embedding vector(1536)
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops);

数百万件を超える規模やペイロードフィルタ・量子化が必要なら Qdrant、すでに PostgreSQL を運用しているチームなら pgvector が手軽です。取り込み前に API への疎通を確認しましょう。

# confirm the API endpoints are reachable from this server
curl -s -o /dev/null -w "%{http_code}\n" https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY"
curl -s -o /dev/null -w "%{http_code}\n" https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" -H "anthropic-version: 2023-06-01"

回答精度を左右するドキュメント取り込み

回答品質はモデルよりもチャンク分割とメタデータで決まります。

1. ソースの整形：ナビゲーションやヘッダー、重複定型文を除去。PDF はレイアウト認識ツールでテキスト化。
2. 構造で分割：見出し単位で 300〜600 トークン、少しオーバーラップ。表は分割しない。
3. メタデータ付与：文書 ID、言語、製品、版、更新日、ACL。
4. 個人情報のマスキング：過去チケットは埋め込み前に氏名・電話・住所・注文番号を除去。
5. 差分更新：チャンクごとにハッシュを取り、変更分だけ夜間 cron で再埋め込み。
6. 評価：実際の質問 50〜100 件と想定回答を用意し、変更のたびに再テスト。

顧客データを域内に保つ（APPI／PDPA の基本）

DB を域内に置くのは有効ですが、LLM API に送ったテキストはプロバイダー側で処理されるため、外に出るデータを最小化し記録しておく必要があります。

• 原本・ベクトル・チャットログは顧客地域の IMIDC サーバーに保存し、ディスクとバックアップを暗号化。
• API に送るのは検索結果のチャンクと質問だけ。DB 丸ごとは送らず、個人情報は可能な限り除去。
• CPU で動くオープンソースの多言語埋め込みモデル（BGE、E5 系など）を使えば、埋め込みはサーバー内で完結し、API 呼び出しは回答生成のみになります。
• 各社 API のデータ保持・学習利用の規約を確認し、エンタープライズ向けやゼロ保持オプションがあれば活用。
• 日本の個人情報保護法とシンガポール PDPA には、外国の事業者への個人データ提供に関する規定があります。プライバシーポリシーと記録を更新しましょう。

本記事は一般的な情報であり、法的助言ではありません。具体的な義務は専門家にご確認ください。

最適な IMIDC 構成の選び方

ベクトル件数と同時アクセス数で構成を決め、顧客に最も近い拠点を選びます。

• PoC（20 万チャンク以下・単一ブランド）：台北のエントリー専用サーバー（$199/月〜）または東京、RAM 32 GB＋NVMe。
• 本番サポート窓口（100〜500 万チャンク・多言語）：RAM 64〜128 GB、NVMe 2 本の RAID 1、東京またはシンガポール。
• 北米向けストア：ロサンゼルス専用サーバー（$499/月〜）。
• マルチリージョン：地域ごとにインデックスを分け（日本は東京、米国はロサンゼルス）データを域内に。

シンガポールのサーバーや RAM／ディスクのカスタム構成は IMIDC 営業が対応します。他社からの移行には無料のサーバー移行サービスもご利用いただけます。

よくある質問

日本やシンガポールでプライベート RAG ナレッジベースを動かすならどのサーバー会社がいい？

IMIDC は東京とシンガポールで現地ネイティブ IP 付きの専用サーバーを提供しており、どちらも OpenAI・Claude・Gemini API の公式提供地域です。ベクトル DB とドキュメントを自社ハードウェアに置き、固定月額で運用できます。

香港のサーバーで RAG チャットボットを動かせますか？

OpenAI・Claude・Gemini API を使う場合はできません。これらは香港、中国本土、ロシアでは公式に提供されていません。API ベースの AI 用途には東京・シンガポール・台北・ロサンゼルスを選んでください。

Qdrant や pgvector にはどれくらいの RAM が必要？

1536 次元ベクトル 100 万件あたり約 6 GB（インデックス別）なので、HNSW や他のコンポーネントを含め 2 倍程度を見込みます。Qdrant のスカラー量子化を使えばベクトルのメモリを約 4 分の 1 にできます。

東京にサーバーを置けば個人情報保護法に準拠したことになりますか？

設置場所だけで準拠にはなりません。域内保存は管理を簡単にしますが、利用目的の特定、通知、API 事業者へ送るデータの安全管理措置が必要です。本記事は法的助言ではありません。

サポート用ナレッジベースの構築を始めませんか。東京の専用サーバー、台北の専用サーバー、ロサンゼルスの専用サーバーを比較いただくか、シンガポールや大容量メモリ構成は IMIDC 営業へお問い合わせください。既存のお客様は チケット でサイジングのご相談も可能です。