Level 0：企業課題・要件定義

AI基盤の構築は、GPUの選定からは始まりません。「どんな質問に、どの精度で、誰に対して答える必要があるのか」 が決まっていなければ、モデルもGPUもServingも選べないからです。

このLevelでは、vLLMもQwenも登場しません。扱うのは、企業の課題・機能要件・非機能要件・評価指標の4つだけです。

1. 現在の企業状況

架空企業 Nortia株式会社 を題材にします。

項目	値
社員数	1,000人
AI利用想定者	500人
ピーク同時利用	20〜50人
対象文書	約10万件
データ量	約500GB
機密区分	一部機密（人事・法務・未公開の事業計画）
利用時間帯	8:00〜22:00
目標応答時間	約5秒以内

社内文書は、次の4システムに分散しています。

社内ナレッジの現状

SharePoint ──── 就業規則・稟議・各種規程
GitHub ──────── 設計書・README・ADR
社内Wiki ─────── FAQ・運用手順書
障害管理システム ── 過去障害・対応履歴

  ↑ 横断検索する手段がない

2. 発生した課題

情報が「無い」のではなく、「あるのに辿り着けない」状態です。

• 規程の最新版がSharePointのどのフォルダにあるか分からず、古いPDFを参照してしまう
• 設計書はGitHubにあるが、非エンジニアは検索方法を知らない
• 同じ質問が繰り返しヘルプデスクへ届く
• 過去に発生した障害と同じ事象を、毎回ゼロから調査している
• ベテラン社員に聞くのが最速、という属人化が起きている

この状態を一文にすると、次の要望になります。

社内情報を横断検索して、根拠付きで答えてくれる仕組みが欲しい。

3. 要件

機能要件

ID	要件	内容
FR-1	自然文で質問できる	検索キーワードではなく、業務上の疑問をそのまま入力できる
FR-2	社内文書を横断検索できる	4システムの文書を、利用者が意識せず横断して検索する
FR-3	根拠を提示する	回答に、参照した文書名・該当箇所・更新日を併記する
FR-4	権限に応じて文書を制限する	閲覧権限のない文書は、検索結果にも回答にも含めない
FR-5	回答不能を明示する	根拠が見つからない場合、推測せず「分からない」と返す

FR-3とFR-5は、社内利用では特に重要です。根拠のない流暢な回答は、業務では誤情報と同じ扱いになります。

非機能要件

分類	目標値	根拠
性能	初回応答（TTFT）2秒以内、回答完了約5秒以内	検索代替として使われるには、待たされない体感が必要
スループット	ピーク20〜50人の同時リクエストを処理	500人の利用者の朝夕ピークを想定
可用性	稼働時間帯8:00〜22:00で99.5%	基幹業務ではないため、24/365は求めない
セキュリティ	機密文書を外部サービスへ送信しない	人事・法務資料を含むため
権限	検索の時点でACLを適用する	回答から隠す方式は情報漏洩とみなされる
監査	質問・参照文書・回答を90日以上保管	情報漏洩調査と品質改善の両方に必要
コスト	年間の運用費に上限を設ける	効果が不確実な段階で青天井の投資はできない
運用	専任1人＋兼任2人で運用可能な範囲	AI専門チームは存在しない

4. 選択肢

「生成AIを入れる」と決める前に、課題（情報に辿り着けない）に対する打ち手を並べます。

1. 全文検索基盤の強化 — 4システムを1つの検索インデックスへ集約する
2. ナレッジポータルの整備 — 人手で情報を整理し、入口を1つにする
3. 生成AI＋RAG — 自然文の質問に、社内文書を根拠として回答する
4. 現状維持＋運用改善 — 命名規則とフォルダ構成のルールを徹底する

5. 技術比較

打ち手	解決できること	解決できないこと	初期コスト	運用負荷
全文検索の強化	文書の所在が分かる	「結局どれを読めばよいか」は利用者が判断する	中	低
ナレッジポータル	主要情報への導線が整う	更新が人手依存で、いずれ陳腐化する	低	高
生成AI＋RAG	質問に対する答えと根拠を直接得る	根拠のない回答（ハルシネーション）のリスクが残る	高	中〜高
現状維持	追加投資が不要	課題そのものは解決しない	なし	現状維持

全文検索の強化は、費用対効果では最有力です。しかし今回の課題の中心は「探すのに時間がかかる」ではなく、「読んで判断するのに時間がかかる」ことでした。ヘルプデスクへ届く質問の多くは「規程のどこに書いてあるか」ではなく「私のケースはどう扱われるのか」であり、文書一覧を返すだけでは解決しません。

6. 採用判断

生成AI＋RAG（根拠付き回答）を目指す方針を採用します。

ただしこの段階で決めたのはここまでです。以下は意図的に未決定のままにします。

• どのLLMを使うか
• 外部API・Managed・Self-hostのどれか
• どのGPUが必要か
• Vector DBに何を使うか

7. Architecture

この段階のアーキテクチャは、製品名の入らない論理構成にとどめます。

              社員（質問）
                   │
                   ↓
          ┌─────────────────┐
          │  質問応答UI       │
          └────────┬────────┘
                   ↓
             本人確認・権限判定
                   ↓
          ┌─────────────────┐
          │ 文書検索（ACL適用） │
          └────────┬────────┘
                   ↓
          ┌─────────────────┐
          │ 回答生成（根拠付き）│
          └────────┬────────┘
                   ↓
            回答 ＋ 出典 ＋ 監査ログ

箱の中身（何で実装するか）は空白のままで構いません。空白のまま関係者と合意できることが、この段階のゴールです。

8. 実装

このLevelでコードは書きません。代わりに、後続Levelの入力となる3つの成果物を作ります。

成果物	内容	用途
文書インベントリ	システム別の文書数・容量・形式・更新頻度・機密区分・ACLの持ち方	Level 5のRAG設計、Level 6の権限設計
想定質問リスト	ヘルプデスク実績から抽出した頻出質問100件と、その正解・出典	評価データセットの原型
非機能要件シート	上記の目標値と根拠、および測定方法	Level 4のPoC合否判定、Level 9のサイジング

文書インベントリで特に重要なのは、「その文書の閲覧権限が、今どこに定義されているか」 を記録することです。SharePointのサイト権限なのか、GitHubのリポジトリ権限なのか、あるいはファイルサーバーのフォルダ権限なのか。ここが曖昧なままRAGを作ると、Level 6で権限モデルを一から作り直すことになります。

9. Benchmark / Evaluation

まだ何も動いていない段階ですが、評価指標は先に決めます。動いてから決めると、都合のよい指標が選ばれるためです。

指標	測定方法	初期目標
正答率	想定質問100件に対する回答の人手評価	80%以上
出典提示率	回答に有効な出典が含まれる割合	95%以上
誤答率	誤った内容を断定的に述べた割合	3%以下
応答時間	TTFTと回答完了までの時間	2秒 / 5秒
情報到達時間	利用者が答えに辿り着くまでの時間（利用者調査）	導入前比で50%削減

10. 残った課題

• 「機密文書を外部へ送信しない」を満たす実現方式が未決定（外部API / Managed / Self-host）
• 応答5秒以内が技術的に達成可能かどうか、実測データがない
• 必要なGPUの規模もコストも見積もれていない
• 権限情報を4システムからどう集約するかが未検討

11. 次のLevelへ

Level 1：生成AIの導入方式を決めるでは、外部API・Managed・Self-hostの3方式を、機密性・レイテンシ・コスト・運用能力の観点で比較します。

「Self-hostが優れているから選ぶ」のではありません。今回の要件だからこの方式になる、という導出過程がテーマです。