NASと社内Webアプリでつくる文書管理・AI検索の構築ガイド

社内の共有資料が増え、手作業の台帳だけでは更新が追いつかなくなったら、NAS、社内Webアプリ、文書データベース、AI検索を分けて設計します。

基本は「NASをファイルの保管場所、Webアプリを操作と権限の入口、文書DBを検索用の目次、AIを回答補助」にする構成です。AIへNAS全体の閲覧権限を与える構成にはしません。

対象となる会社と課題

社員のPC
  ↓
社内Webアプリ
  ↓ 認証・権限判定
文書インデックスDB
  ↓ 許可された候補だけ取得
NASの文書
  ↓ 必要な文書だけ
AI検索・回答補助

NASは文書本体を保存します。Webアプリはログイン、検索、アップロード、移動、削除、履歴確認を担当します。文書DBには要約、キーワード、状態、所有部署、機密区分などを保存します。

役割	閲覧	追加・修正	移動	削除	権限変更
閲覧者	可	不可	不可	不可	不可
編集者	可	可	可	不可	不可
管理者	可	可	可	可	担当範囲のみ
システム管理者	可	可	可	可	可

例として、経理フォルダは経理部が編集、代表者が閲覧、その他の部署は非表示とします。詳細はアクセス制御（権限管理）の考え方で整理します。

通常の検索で見えない資料を、AIだけが検索できる状態にしてはいけません。質問を受けたら、最初に利用者の権限を確認し、許可された文書だけを候補にします。その候補から関連性を判断し、必要な本文だけをAIへ渡します。

利用者を認証
  ↓
閲覧可能な部署・フォルダを取得
  ↓
文書インデックスを検索
  ↓
許可された候補だけ本文取得
  ↓
AIが回答案と参照資料を表示
  ↓
利用者が原文を確認

移動や名称変更もWebアプリ経由にすれば、NASのファイル操作とDBのパス更新を同時に行えます。ただし、導入後もNASを直接変更できる経路が残る場合は、差分検出と再同期が必要です。

文書の紹介や限定的なダウンロードならCMSでも対応できます。しかし、NAS操作、細かな権限、ファイルロック、版管理、監査ログ、大量文書の検索を一体化する場合は、専用Webアプリの方が責任範囲を設計しやすくなります。

構成例は、社内ネットワーク上のWebサーバー、PHPや別のバックエンド、MariaDBまたはPostgreSQL、NASのSMB接続、検索インデックスです。製品名から決めるのではなく、利用人数、文書数、権限、停止時の影響、保守担当者から選びます。

社内文書管理とAI検索は、AI機能から作り始めるものではありません。先に認証、権限、文書の所有者、更新、削除・復元、監査ログを整え、その上に検索とAI回答を載せます。小さな台帳で運用を確かめてから段階的に機能を増やすと、過剰な開発と情報漏えいの両方を避けやすくなります。