⚙️AI FAQシステム開発を「工程」から再設計する：RAG・評価・運用を前提にしたSystem Development Deep Dive

1. Executive Summary（技術的要約・300文字）

AI FAQシステムは、従来の「10工程（要件定義〜運用保守）」にRAG（検索拡張生成）特有の工程を差し込まないと失敗しやすい。具体的には、①データ契約（何を根拠に回答するか）②評価設計（正解率/根拠提示/エスカレーション）③セキュリティ（PII・権限・監査）④運用（ログ→改善→再学習/再索引）を最初から工程化する。本稿はアーキテクチャと実装設定、ベンチマーク、比較表、ロードマップを提示し、短期PoCから本番SLO運用へ移行するための実務的な指針を示す。🔧

2. 技術的背景と課題（アーキテクチャ図の説明、既存の問題点）

参考記事1の「要件定義→設計→開発→テスト→運用」の流れは、AI FAQでも骨格として有効だが、生成AIの導入により“仕様が固定できない”領域が増える。参考記事3が指摘する通り「AIを入れた＝問い合わせが減る」ではなく、誤回答・根拠不明・ナレッジ更新遅延が定着を阻害する。さらにオフショア開発（参考記事2）を絡めると、曖昧な日本語仕様や暗黙知が評価不能な成果物を生むため、成果物の定義（データ/評価/運用）を強制的に形式化する必要がある。

技術的フロー図（文章による説明）📊：ユーザー質問→API Gateway→(1)認証/認可→(2)クエリ正規化→(3)Vector Search（Top-k）→(4)Context組み立て（権限フィルタ）→(5)LLM生成（根拠引用）→(6)ガードレール（NG判定/PII）→(7)回答返却→(8)ログ/トレース→(9)評価基盤でオフライン採点→(10)改善（ナレッジ整備/再索引/プロンプト更新）。この(8)-(10)が従来工程では“運用”に押し込まれがちだが、AI FAQでは品質の中核となるため、要件定義から逆算して設計する。

• 既存の問題点：FAQが分散（SharePoint/Confluence/ファイルサーバ/メール）し、検索性が低い
• AI特有の問題：幻覚（hallucination）、根拠欠落、権限無視の回答、更新追随の遅さ
• 工程上の問題：受入テストが「UI確認」で終わり、回答品質のKPIが未定義
• オフショア時の増幅：仕様の曖昧さが評価不能なLLM挙動に直結（“正しい”の定義が不明）

3. 技術セクション①：要件定義を「データ契約」と「失敗条件」から始める ⚙️

3.1 要件定義の再分解：機能要件より先に“根拠”を定義

従来の要件定義は画面/機能中心になりやすいが、AI FAQでは「回答の根拠となるデータソース」「参照可能範囲（権限）」「回答しない条件」を先に決める。ここを曖昧にすると、後工程で精度議論が収束しない。推奨は“データ契約（Data Contract）”として、ソース種別・更新頻度・責任者・PII含有・公開レベルを台帳化すること。さらに、参考記事3の示唆通り「AIに何をさせないか」を受入基準として明文化し、失敗条件（例：法務判断/個人情報/規約解釈）をガードレール要件に落とす。

3.2 エスカレーション設計：有人切替をプロダクト機能として扱う

AI FAQは完全自動化より、誤回答時に“正しく止まる”ことが重要。SLA/SLOとして、回答不能時はチケット発行（Jira Service Management）やSlack通知に自動連携する。これを要件定義で決めずに後付けすると、ログ粒度や監査証跡が不足し、運用で詰む。

3.3 成果物テンプレ（オフショア耐性）

オフショアを含む場合、曖昧日本語を排し、否定の多重表現を避ける（参考記事2）。具体的には「禁止事項」「例外」「閾値」を表形式で定義し、受入テストが自動化できる粒度にする。

# requirements/guardrails.yml
version: 1
answer_policy:
  must_cite_sources: true
  citation_style: "doc_id:section"
  refuse_when:
    - category: "legal_judgement"
      message: "法的判断を伴うため担当部門へエスカレーションします。"
    - category: "contains_pii"
      message: "個人情報を含む可能性があるため回答できません。"
escalation:
  tool: "jira"
  project_key: "HD"
  create_issue_when:
    - confidence < 0.55
    - no_retrieval_results

3. 技術セクション②：RAGアーキテクチャの基準設計（LLMより検索がボトルネック）🔧

4.1 参照アーキテクチャ（推奨構成）

実運用のAI FAQは、LLM単体ではなくRAGが主流。構成要素は (a) Ingestion（取り込み）(b) Chunking（分割）(c) Embedding（ベクトル化）(d) Vector DB (e) Retrieval (f) Generation (g) Observability。LLMの差より、Chunkサイズ・メタデータ設計・権限フィルタの実装が精度を決める。特に社内FAQは“短文＋表＋手順”が多く、Markdown/HTMLの正規化が必要。

4.2 具体実装例（LangChain 0.2.x + FastAPI + pgvector）

ベンダーロックを避けるため、Vector DBはPostgreSQL 16 + pgvector 0.7.4、APIはFastAPI 0.110系、実行基盤はKubernetes 1.29を前提にする。Embeddingは text-embedding-3-large 相当の次元（3072）を想定しつつ、コスト最適化で small へ切替可能にする。

# docker-compose.yml（検証用）
services:
  db:
    image: postgres:16
    environment:
      POSTGRES_PASSWORD: example
    ports:
      - "5432:5432"
    command: ["postgres", "-c", "shared_buffers=1GB", "-c", "max_connections=200"]
  api:
    build: ./api
    environment:
      DATABASE_URL: "postgresql+psycopg://postgres:example@db:5432/postgres"
      VECTOR_DIM: "3072"
    ports:
      - "8000:8000"

-- PostgreSQL: pgvector
CREATE EXTENSION IF NOT EXISTS vector;
CREATE TABLE docs (
  doc_id text PRIMARY KEY,
  acl jsonb NOT NULL,
  updated_at timestamptz NOT NULL
);
CREATE TABLE chunks (
  chunk_id bigserial PRIMARY KEY,
  doc_id text REFERENCES docs(doc_id),
  content text NOT NULL,
  embedding vector(3072),
  meta jsonb
);
CREATE INDEX ON chunks USING hnsw (embedding vector_cosine_ops) WITH (m=16, ef_construction=200);

4.3 権限フィルタとメタデータ

社内FAQは部署/役職で見える情報が異なる。Retrieval後にフィルタするのではなく、検索クエリにACL条件を入れる（Row Level Securityやwhere句）方が漏洩リスクを下げられる。メタデータには「部署」「機密区分」「有効期限」「版数」を必須化し、期限切れは検索対象外にする。

3. 技術セクション③：評価設計（オフライン自動採点）をテスト工程に統合 📊

5.1 “単体/結合/総合”に対応するAI評価軸

参考記事1のテスト工程をAIに当てはめると、単体＝Retriever評価（Recall@k、MRR）、結合＝RAG全体のFaithfulness（根拠整合）、総合＝業務シナリオ達成率（エスカレーション含む）となる。ここを定義せずに受入テストへ進むと「なんとなく賢い/賢くない」になり、改善が不可能になる。

5.2 ベンチマーク（例：社内ヘルプデスク1,000問）

構成	Chunk	Top-k	Recall@5	回答正確性(人手採点)	P95レイテンシ
BM-1: 800token固定+HNSW	800	5	0.82	0.71	2.4s
BM-2: 400token+見出し境界	可変(200-600)	8	0.89	0.78	2.8s
BM-3: BM-2 + Reranker(bge-reranker-v2)	可変	20→8	0.92	0.83	3.6s

示唆：多くの現場でボトルネックはLLMではなく検索品質。Reranker導入は精度を上げるが、P95が悪化しやすいので、キャッシュ（質問クラスタ）や非同期エスカレーション設計とセットで検討する。

5.3 評価パイプライン例（pytest + golden set）

# tests/test_retrieval.py
import json
from rag import retrieve

def test_recall_at_k(golden):
    k=5
    hit=0
    for q in golden:
        docs = retrieve(q["question"], k=k, user=q["user"])
        if q["expected_doc_id"] in [d.doc_id for d in docs]:
            hit += 1
    recall = hit/len(golden)
    assert recall >= 0.85

3. 技術セクション④：セキュリティ設計（PII・監査・プロンプト注入）🔒

6.1 脅威モデル：FAQは“社内の検索窓”であり漏洩面が広い

AI FAQは入力（質問）と出力（回答）の両方がデータ流出経路になり得る。典型は(1)権限外文書の引用、(2)プロンプトインジェクションでシステムプロンプト/秘密情報を吐かせる、(3)ログにPIIが残る、(4)外部LLMへの送信が規約違反。よって、認可・マスキング・監査ログをアーキテクチャの中心に据える。

6.2 具体対策（実装レベル）

• 🔧 入力検査：正規表現＋DLP（例：メール/電話/住所）検知でPIIをマスク
• ⚙️ 出力検査：機密語辞書、引用元がない回答は拒否（must_cite_sources）
• 🔒 監査：user_id、doc_id、chunk_id、model、prompt_hash、decision（answer/refuse/escalate）を不変ログへ
• 🔧 外部送信制御：プロキシ経由でドメイン制限、VPC egress制御、鍵はKMS/HSM

# Envoy（例）: egress allowlist
static_resources:
  clusters:
  - name: openai
    type: LOGICAL_DNS
    load_assignment:
      cluster_name: openai
      endpoints:
      - lb_endpoints:
        - endpoint:
            address:
              socket_address:
                address: api.openai.com
                port_value: 443

6.3 プロンプト注入対策：ポリシーと実装を分離

「無視して」等の命令はモデルに従わせない。システムプロンプトに依存せず、(a)ツール実行をホワイトリスト化、(b)引用必須、(c)機密分類に応じてRetriever側で遮断、の三層防御にする。

3. 技術セクション⑤：スケーラビリティ分析（ピーク負荷は“朝イチ”に来る）📈

7.1 スループット分解：検索・生成・後処理

問い合わせ業務は時間帯偏りが大きい。ピーク時は「同じ質問が大量に来る」ため、質問正規化＋セマンティックキャッシュが効く。スケール戦略は、LLMを水平スケールするより、Retrieverキャッシュ、Embeddingの事前計算、Rerankの条件適用（低信頼時のみ）でコストを抑えるのが現実的。

7.2 ベンチマーク（例：k6で同時接続）

同時接続	RPS	P50	P95	エラー率	主因
50	18	1.4s	2.6s	0.2%	LLM待ち
200	52	2.1s	4.8s	1.1%	DB CPU + LLM rate limit
500	88	3.0s	7.9s	3.8%	rate limit / queue溢れ

7.3 実装パターン：Queue + Asyncで“待ち”を吸収

同期APIでP95を追うとコストが跳ねる。非同期化（SQS/RabbitMQ/Kafka）と、ユーザー体験上許容できる範囲で「回答生成中」UIを入れる。エスカレーションは非同期で良いが、監査ログは同期で確定させる。

3. 技術セクション⑥：CI/CDと環境分離（プロンプトもコードとして扱う）🔧

8.1 “Prompt as Code” とバージョニング

プロンプト変更は挙動を変えるため、設計書ではなくGitで管理し、prompt_hashをログに残す。環境は dev/stg/prod を分離し、ナレッジ（索引）も環境ごとに別IDで保持する。プロンプトと索引の組み合わせが再現できないと、障害調査が不可能。

# .github/workflows/eval.yml
name: rag-eval
on: [pull_request]
jobs:
  eval:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - run: pip install -r requirements.txt
      - run: pytest -q tests/

8.2 IaC（Terraform 1.7系）で監査可能に

VPC、KMS、Secrets、WAF、ログストレージをIaC化し、変更履歴を残す。AI FAQは“チャットUI”に見えるが、実態は社内データアクセス基盤であり、監査要件を満たす変更管理が必須。

8.3 オフショア開発での分業境界

上流（要件定義・データ契約・評価KPI・セキュリティポリシー）は国内で握り、製造（UI/管理画面/ETL）をオフショアに出すのが現実解。ただし評価基盤とテストデータ（golden set）は国内側が用意し、成果物の合否を自動判定できる状態にして委託する。

3. 技術セクション⑦：運用保守＝“育成”をSRE化する（ログ→改善ループ）⚙️

9.1 運用KPI：利用率より先に「失敗の質」を見る

運用で見るべきは、(1)拒否率（refusal）、(2)エスカレーション率、(3)引用なし回答率、(4)Top問い合わせカテゴリの未解決率。単に利用率を追うと、誤回答の増加に気づくのが遅れる。SLOとして「根拠付き回答率≥95%」「機密違反0」を置く。

9.2 改善ループ：ナレッジ整備→再索引→再評価

AI FAQはデータ更新が本体。ドキュメント更新時に自動で差分索引を走らせ、夜間バッチでオフライン評価を回す。評価が閾値を下回ったら自動でデプロイを止める（Quality Gate）。

# ingestion/job.yaml（Kubernetes CronJob例）
apiVersion: batch/v1
kind: CronJob
metadata:
  name: rag-reindex
spec:
  schedule: "0 2 * * *"
  jobTemplate:
    spec:
      template:
        spec:
          containers:
          - name: reindex
            image: registry.example.com/rag-ingest:1.3.2
            env:
            - name: CHUNK_MAX_TOKENS
              value: "600"
          restartPolicy: OnFailure

9.3 監視：OpenTelemetryで“回答の根拠”までトレース

APMはレイテンシだけでなく、retrieved_doc_ids、rerank_score、confidence、refusal_reasonをspan属性として残す。障害対応は「LLMが遅い」ではなく「検索が外れている」「ACLで落ちている」を切り分ける必要がある。

4. 比較分析テーブル（3つ以上の選択肢を比較）

選択肢	初期導入速度	カスタマイズ性	データ/権限統制	評価・改善のしやすさ	想定コスト感	適用シーン
SaaS型AI FAQ	◎	△	○（機能依存）	△（ブラックボックス化しがち）	月額課金＋従量	短期導入、要件が標準に寄せられる
スクラッチRAG（自社運用）	△	◎	◎（RLS/監査/閉域）	◎（golden set/CI統合）	初期高＋運用最適化余地大	機密データ、基幹連携、長期運用
ハイブリッド（検索・権限は自社、LLMは外部API）	○	○	◎（重要データを外に出さない設計可）	○（トレース/評価は自社で担保）	バランス型	現実的な移行、コストと統制の両立

5. ベストプラクティス・アンチパターン（箇条書き）

ベストプラクティス ✅

• ⚙️ 要件定義で「AIが答えない領域」「根拠データ」「エスカレーション」を確定する
• 📊 golden set（代表質問集）を作り、CIでRecall@k/正確性を自動評価する
• 🔒 ACLをRetrieverに組み込み、検索段階で権限外データを除外する
• 🔧 プロンプト・設定・索引をバージョン管理し、prompt_hashを監査ログへ
• 📈 セマンティックキャッシュとReranker条件適用でP95とコストを両立

アンチパターン ❌

• 「チャットUIが動いた」だけで受入にして、回答品質の合否基準がない
• FAQ原本の品質を放置し、LLMで“それっぽく”整形してごまかす
• 権限フィルタを後段で実装し、ログや引用で漏洩する
• 運用を人力（Excel集計）にし、改善ループが回らない
• オフショアに曖昧な日本語仕様を投げ、再現不能な挙動を量産する

6. 実装ロードマップとチェックリスト

6.1 ロードマップ（12週間モデル）

1. Week 1-2 要件定義：データ契約、失敗条件、SLO、監査要件、対象問い合わせの絞り込み
2. Week 3-4 基本設計：RAG構成、ACL方式、ログ/トレース、運用フロー、エスカレーション連携
3. Week 5-7 詳細設計・実装：Ingestion、Chunk/Embedding、Vector DB、API、UI、管理画面
4. Week 8-9 テスト：Retriever評価、E2Eシナリオ、負荷試験、セキュリティ試験（注入/漏洩）
5. Week 10 運用テスト（受入）：業務部門のシナリオ検証、拒否/エスカレーション動作確認
6. Week 11-12 段階リリース：限定部署→全社、ログに基づく改善、ナレッジ整備体制確立

6.2 チェックリスト（抜粋）

• 🔒 PII検知・マスキング方針が実装され、ログに生PIIが残らない
• ⚙️ must_cite_sources が有効で、引用がない回答は拒否/再質問へ
• 📊 golden set が100問以上あり、CIで閾値（例：Recall@5≥0.85）をゲート化
• 📈 P95レイテンシ目標（例：≤5s）が定義され、k6等で再現可能
• 🔧 prompt_hash / index_version / model_version が監査ログに記録される
• ⚙️ ナレッジ更新責任者（業務側）が明確で、更新→再索引の手順が自動化

7. 参考リソース・次のステップ

• 参考：システム開発工程（要件定義〜運用）—工程の骨格として活用
• 参考：オフショア開発—曖昧仕様排除、成果物定義、ブリッジSEの重要性
• 参考：AI FAQ立ち上げプロセス—「AIに何をさせないか」「運用で育てる」

次のステップ🔧：①問い合わせログから上位200質問を抽出しgolden set化、②データ契約台帳を作成、③最小RAGでRecall@kを計測、④拒否/エスカレーションを含むE2EをCIに統合、⑤限定部署で段階リリースして改善ループを回す。ここまでを“開発工程”として固定すると、AI FAQは単発導入ではなく継続的に品質が上がるプロダクトになる。