AI活用戦略

AIを差し替えられる会社は、モデルより先に「データの置き場」を設計している

Driveやデータベースに会社の知識を正本として集約し、版管理・メタデータ・権限・検索インデックスを分離して設計すれば、回答精度とガバナンスを高めながら、利用するLLMやAIエージェントを将来差し替えやすくなる。

2026年9月8日Prompthing編集部12 min

記事本文

要点：AIモデルを会社の知識基盤から分離し、正本データ・版管理・権限・検索層を整えることで、将来のLLMやAIエージェントの差し替えを容易にする。 AIを固定する構成と、会社の知識を残してAIを差し替える構成の比較図今使っているAIが、3年後も自社にとって最適だと言い切れるでしょうか。 ChatGPT、Claude、Gemini、Microsoftのエージェント、Amazon Bedrock。モデルやサービスはこれからも更新され、得意分野や価格、セキュリティ条件も変わります。そのたびに社内文書を登録し直し、プロンプトを作り直し、権限を設定し直すのであれば、AIを導入したはずが、特定サービスから動けない状態をつくってしまいます。長期運用で目指したいのは、AIを中心にデータを置く構成ではありません。 Google Drive、SharePoint、データベースなどに会社の知識を集約し、その上に検索・権限・接続の層を設け、利用するLLMやAIエージェントを差し替えられる構成です。ただし、ファイルを一つのフォルダーへ集めるだけでは不十分です。

なぜ、データを整えるとAIの回答が良くなるのか

AIは、社内フォルダー全体を人間のように眺め、常識的に正しい文書を選んでいるわけではありません。一般的なRAGでは、文書を小さな単位に分け、検索用の索引を作り、質問に関係しそうな断片を取り出してモデルへ渡します。OpenAIはVector Storeをデータの索引として使い、File Searchではメタデータによる絞り込みも提供しています。Googleも、データの取り込み、分割、Embedding、索引化、検索という流れをRAGの基本構成として説明しています。
OpenAI Retrieval / OpenAI File Search / Google Cloud RAG Engine つまり、回答の前段で「どの情報を取り出せたか」が重要です。 Anthropicの検証では、文書断片に周辺文脈を加え、キーワード検索を組み合わせることで、上位20件に必要情報が入らない割合が5.7%から2.9%へ減少しました。さらに再ランキングを加えた条件では1.9%まで下がっています。モデルを変えなくても、情報の渡し方で検索精度が大きく変わるという一例です。
Anthropic: Contextual Retrieval 反対に、次の状態では回答が不安定になります。

同じ規程の「最新版」「最終版」「本当の最終版」が混在している
下書きと承認済み文書を区別できない
見出しがなく、長いPDFの中で文脈が切れている
更新日、主管部署、適用範囲が分からない
閲覧権限とAIの検索対象が一致していない
元ファイルは更新されたのに、検索用索引が更新されていない AWSも、文書を検索しやすい単位へ分割し、Embeddingと索引を作る仕組みを説明しています。また、原本やメタデータを変更・削除した場合には、再解析、再分割、再Embedding、再索引化が必要だとしています。
Amazon Bedrockの文書分割 / データソースの同期

フォルダー構成は「AIのため」だけではない

フォルダーのツリー構造は、AIに直接知能を与えるものではありません。役割は、人間とシステムが「正しい情報を、正しい条件で、検索対象へ渡す」ための統制です。例えば、次のような構成です。

AI_KNOWLEDGE_BASE/
├─ 00_運用ルール/
│  ├─ AI利用範囲
│  ├─ 命名・版管理規則
│  └─ メタデータ定義
├─ 10_全社共通/
│  ├─ 規程
│  ├─ 業務標準
│  └─ 用語集
├─ 20_部署別/
│  ├─ 総務/
│  │  ├─ 01_業務手順
│  │  ├─ 02_FAQ
│  │  ├─ 03_様式・テンプレート
│  │  └─ 04_事例
│  ├─ 営業/
│  └─ 人事/
├─ 80_レビュー待ち/
├─ 90_旧版・アーカイブ/
└─ 99_AI閲覧禁止/

ここで重要なのは、フォルダー名だけで制御したつもりにならないことです。「99_AI閲覧禁止」という名称は人間には分かりやすくても、それ自体はアクセス制御ではありません。実際の共有権限、コネクターの対象範囲、検索インデックスへの登録除外を一致させる必要があります。 Microsoftも、知識ソースの取り込み時に文書分割、ベクトル化、メタデータ抽出、ACL同期を扱う一方、文書単位の権限は、対応するデータソースで明示的に設定・同期されている場合に限って適用されると説明しています。
Microsoft Foundry IQ FAQ

フォルダーと一緒に「文書台帳」を持つ

ファイル数が増えると、ツリー構造だけでは管理しきれません。そこで、Drive上のファイルとは別に、次の項目を持つ文書台帳をデータベース化します。

文書ID
文書名
主管部署・責任者
文書区分
ステータス（下書き／承認済み／廃止）
版番号
適用開始日・次回レビュー日
機密区分
AI参照可否
原本URL AIは「意味が近い」という理由だけで文書を選ぶのではなく、たとえば「承認済み」「総務部」「現行版」「AI参照可」という条件で候補を絞れます。これが、フォルダー構成とメタデータをセットで設計する理由です。

差し替えるのはAI。残すのは会社の知識

理想的な構成は、次の4層です。

正本データ層：Drive、SharePoint、データベース
統制層：文書ID、版管理、承認状態、権限、更新期限
接続・検索層：コネクター、RAG、検索インデックス、MCP
利用層：ChatGPT、Claude、Gemini、各種AIエージェント MCPは、AIアプリケーションと外部のデータ・ツールをつなぐためのオープンな標準です。このような接続規格を使えば、AI側の実装を会社の原本データから分離しやすくなります。
Model Context Protocol公式ドキュメントただし、「一度つないだら、どのAIにも無加工で交換できる」という意味ではありません。 Embeddingモデルや索引方式が変われば、再索引化や評価は必要です。GoogleのRAG参照構成でも、文書と質問のEmbeddingには同じモデルと設定を使う必要があると説明されています。
Google CloudのRAG参照構成だからこそ、検索インデックスは作り直せる派生物と考え、原本データと文書台帳を会社の資産として残します。新しいAIへ切り替えるときは、同じ原本から新しい索引を作り、同じ評価質問で回答精度、根拠提示、権限漏れを比較してから接続先を変える。この状態であれば、AIの進化を脅威ではなく、選択肢として受け取れます。

AI導入で、最初に選ぶべきものは何か

多くの企業は、最初にモデルを選びます。しかし長期的に残るのは、モデル名ではありません。 どの情報を正本とし、誰が更新し、どのAIが、どの条件で参照できるか。 この設計こそが残ります。 AIを長く運用するために先に整えるべきなのは、AIそのものではなく、会社の知識が迷わず流れる道ではないでしょうか。 #生成AI #AIエージェント #ナレッジマネジメント #RAG #データガバナンス #AI部署