職員35名規模の税理士法人を例に考えてみます。6年前にSharePointを入れて、顧問先別・年度別・案件別の3階層フォルダがおおむね定着している事務所です。アクセス権は顧問先ごとに担当チームへ絞り、機密度ラベルは「マル秘・社外秘・通常」の3段階で運用されてきました。
この状態からAI検索の導入を考えると、片方で足りるという整理が二通り立ちます。「DMSを入れているのだからAI検索はいらない」と、「ChatGPTで検索できているのだからDMSと統合しなくてよい」です。どちらも一理あります。ただDMSとAI検索は担っている役割が違うので、片方だけの運用はどこかで限界に当たります。本稿では、その役割差と、両者を併用するときに契約・権限の側で決めておく項目を整理します。
DMSが担っているのは保管・整理・統制
DMSの中核は、文書のライフサイクル管理です。保管場所の一元化、フォルダ単位の権限制御、バージョン管理、保持・削除ポリシー、監査ログ、機密度ラベル、外部共有制御といった機能が中心です。SharePointとOneDriveに関するMicrosoft公式ドキュメントでも、「保持ポリシー」「機密度ラベル」「データ損失防止 (DLP)」「コンテンツ検索」が文書管理基盤の主要な構成要素として説明されています。
士業事務所の文脈で言うと、DMSはおおむね次のような役割を担います。
- 顧問先AのフォルダにはA担当チームしかアクセスできない構造を維持する
- 契約書ドラフトの過去版を遡って参照できる版管理を残す
- 退職者アカウントを停止すれば、その方が触っていた文書のアクセス権も外れる
- 機密度ラベルが、顧問先資料に自動で付与される
DMSは、守秘義務・個人情報保護を担保する基盤として機能します。フルテキスト検索やメタデータ検索の機能も備わっていますが、「契約書X条の競業避止義務の書き方について、過去の類似ひな形と比較して論点を出してほしい」という、人が読み込んで初めて成り立つ問いには、DMS単体では応えにくいところがあります。「該当しそうな文書を絞り込んで、人が読む」までが守備範囲です。
AI検索が担っているのは探索・要約・回答
AI検索の中核は、複数の文書を横断してクエリに答えるところにあります。LLMが文書を意味的に理解し、関連箇所を抽出し、要約や比較を生成する仕組みです。Microsoft 365 Copilotを例にすると、Microsoft公式ドキュメントでは、CopilotがMicrosoft Graph経由で利用者がアクセス権を持つ文書・メール・チャットを参照し、セマンティックインデックスを用いて関連性の高い情報を取得した上で、LLMが応答を生成する流れが説明されています。
この仕組みには、設計上の前提が二つ埋まっています。
AI検索の多くは「利用者がアクセス権を持つ範囲」に限定して動きます。Microsoft Copilotのデータ・プライバシー・セキュリティに関するMicrosoft公式ドキュメントでは、Copilotが提示するのは個々の利用者が少なくとも表示権限を持つ組織データに限られる、と説明されています。
そして回答の品質は、裏側のインデックス、つまり元になる文書群の整理状態に依存します。古いひな形・退職者のメモ・重複した議事録が混ざったまま検索対象になっていると、AIはそれらも根拠として回答を組み立てます。AI検索が速くするのは「探す」「読む」「要約する」「答える」工程であって、その下のデータ基盤を整える工程ではありません。
両者は補完関係にある
| 観点 | DMS | AI検索 |
|---|---|---|
| 主目的 | 保管・整理・統制 | 探索・要約・回答 |
| 得意領域 | 権限境界、バージョン、保持期間、機密度ラベル | 横断検索、関連箇所抽出、自然文応答 |
| 利用者の負荷 | フォルダやファイル名で当たりをつけて開く | 自然文の問いに根拠付きで答えてくれる |
| 出力品質の前提 | 文書を置く運用ルールの定着 | DMS側の整理状態（権限・鮮度・重複） |
| 守秘・統制 | 設計の中核 | DMS側の統制を引き継ぐ前提 |
DMSは「正しいものが正しい場所に置かれている状態」を維持する役割です。アクセス権・バージョン・保持期間・機密度ラベルといった部分はLLM側で制御するものではありません。LLMは与えられたインデックスから関連箇所を返してくれる仕組みなので、そのインデックスが守秘義務を満たしているか、顧問先間で情報が混ざっていないか、改正前の古い情報が紛れていないか、といった判定は、文書管理基盤側で先に解決しておく必要があります。
逆にAI検索は、DMSの中に整然と置かれた数万ファイルの中から、必要な情報を一瞬で引き出したり、複数の議事録を読み比べて論点を並べたりといった、認知負荷を下げる役割を担います。DMS単体だと「フォルダを開いて、ファイル名で当たりをつけて、開いて、読む」工程が必要ですが、AI検索を重ねると「自然文で質問して、根拠付きで回答が返る」運用になっていきます。
役割を分けて見ると、着手の順番が決まります。権限が混ざっている、古い情報の判別がつかない、顧問先データが分離されていない。このいずれかに当たるなら、先に整えるのはDMS側です。逆順にすると、AI検索の出力品質を上げようとしても原因がDMS側にあるため、AI検索の設定では届きません。
併用の組み合わせ方
DMSとAI検索の組み合わせ方は3つに分かれます。
DMS内蔵のAIを使う形
SharePointとMicrosoft 365 Copilotのように、文書管理基盤のベンダーが提供しているAI機能をそのまま使う形です。Microsoft公式ドキュメントによると、CopilotはMicrosoft Graphと統合され、利用者の権限境界を尊重した上で応答を生成する設計になっています。導入のしやすさはありますが、ライセンスコスト、対応アプリの範囲、テナント設定の前提（SharePointの権限見直しや過剰共有の整理など）を満たしておく必要があります。Microsoft自身も、Copilot導入前にSharePoint Advanced Managementで権限を整える運用を案内しています。
DMSに外部RAGを接続する形
既存のDMS（Box、Google Workspace、自前のNASなど）に対して、外部のRAG基盤（自社構築やGleanなどのサービス）を接続する形です。柔軟性が出る一方、権限同期、インデックス更新タイミング、機密度ラベルの伝搬といった設計と運用の手数は、DMS内蔵AIより多くなりやすいです。守秘義務の重い士業領域では、走らせる前に設計レビューを挟む判断が要る構成です。
AI検索だけで運用する形
ChatGPTやCopilot Chatに毎回コピペで投げる形、またはNotion AIやGoogleドライブのAI機能だけで使う形です。手軽に始められる反面、権限境界・保持期間・監査ログが曖昧なまま運用が走ることもあり、顧問先情報を扱う通常業務へ広く適用する形には向きにくく、個人タスクのドラフト用途など、範囲を絞る運用設計になります。
どの形が合うかは、扱う文書の機密度・職員数・既存サブスクリプション・事務所内ルールの成熟度によって変わります。「他事務所がCopilotを入れているから」「とりあえずNotion AIで」と決めて走ると、後から再構築の手間がかかる場面も出てきます。
セキュリティ・コンプライアンスの観点
DMSとAI検索を併用する場面では、セキュリティ・コンプライアンスの設計が独立した論点として残ります。
個人情報の安全管理措置
個人情報保護委員会のガイドライン（通則編）では、個人データを取り扱う事業者は「組織的・人的・物理的・技術的」の4つの観点で安全管理措置を講じることが整理されています。AI検索を入れたことで、アクセス制御が緩んでいないか、ログが取れなくなっていないか、学習に使われる契約に切り替わっていないか、といった点を、導入の段階で確認しておく流れがあります。
委託先の監督
同ガイドラインでは、個人データの取扱いを委託する場合に、委託元へ「適切な委託先の選定」「委託契約の締結」「委託先における個人データ取扱状況の把握」の3つが求められています。選定にあたっては、委託先の安全管理措置が委託元に求められるものと少なくとも同等であることを、あらかじめ確認する必要があるとされています。AI検索基盤の提供事業者は、事実上「個人データ取扱いの委託先」に該当する場面が多いので、契約条件、サブプロセッサー（再委託先）の範囲、データの保持と削除、学習利用の有無は、契約前に確認しておく対象になります。Microsoft 365 Copilotに関するMicrosoft公式ドキュメントでは、AnthropicをMicrosoftのサブプロセッサーとして組み込んだ旨が記載されていて、サブプロセッサーが追加された際の取り扱いは契約上の論点として残りやすいところです。
AI事業者ガイドラインとの整合
総務省の掲載ページで公開されている「AI事業者ガイドライン」（第1.2版、令和8年3月31日公表）では、AIを開発・提供・利用する主体それぞれに対して、安全性・公平性・プライバシー保護・透明性といった観点で配慮事項が整理されています。士業事務所は通常「利用者」の立場に該当しますが、顧問先にAI由来のアウトプットを提供する場面では、ハルシネーションが混ざったときの責任分界を、顧問契約・利用規約レベルで整理しておく流れもあります。
機密度ラベルとDLPの連動
Microsoft公式ドキュメントでは、Microsoft Purview Information Protectionで暗号化された文書について、Copilotが利用者に付与された利用権限を尊重すると説明されています。暗号化は機密度ラベルやInformation Rights Management (IRM) によって適用されます。DMS側でラベル運用が定着していれば、AI検索側にも統制が伝わる構造になります。逆にDMS側のラベルが形骸化していると、AI検索を入れた瞬間に「機密文書が要約として出力され、それがチャット履歴に残る」場面が出やすくなります。
自所への落とし方
冒頭の事務所の状況からAI検索の併用を検討するなら、順序は3段階です。
まず、DMS側の整理状態を点検します。顧問先別アクセス権、退職者アカウント、「リンクを知っている全員」共有、全社共有フォルダの4点について、現状の整理レベルを5段階で自己評価する方法があります。3以下が含まれていれば、そこがAI検索の導入前に整える対象です。
次に、併用の形を選びます。既存サブスクリプション、職員数、機密度の分布から、上で並べた3つのうちどれが自所に近いかを決めていきます。複数の形を並走させると管理の手数が増えるので、初期はひとつに絞ります。
その上で、契約条件を整理します。学習利用の有無、サブプロセッサー、保持期間、データの所在、監査ログの提供範囲を、ベンダーの公式ドキュメントと契約書で突き合わせます。画面に書かれた仕様と契約条項にずれがあるとき、優先されるのは契約条項です。読む順序も契約条項が先です。
DMSが整っていない段階でAI検索を載せると、後から再設計の手間が増えます。整えてから載せる順序なら、出力の安定に必要な前提が先に埋まります。
DMSとAI検索は、片方だけで完結する領域ではありません。権限境界・機密度ラベル・保持期間・サブプロセッサーの整理が先で、AI検索はその上に重ねます。この順序が出力の安定の前提です。自所のDMS整備状況や、併用の形を選ぶところで論点を一緒に並べたいテーマがあれば、状況をお聞かせください。
参考
- Microsoft Learn「What is Microsoft 365 Copilot?」: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-overview
- Microsoft Learn「Data, Privacy, and Security for Microsoft Copilot」: https://learn.microsoft.com/en-us/copilot/microsoft-365/microsoft-365-copilot-privacy
- Microsoft Learn「Introduction to SharePoint and OneDrive in Microsoft 365 for administrators」: https://learn.microsoft.com/en-us/sharepoint/introduction
- 個人情報保護委員会「個人情報の保護に関する法律についてのガイドライン（通則編）」: https://www.ppc.go.jp/personalinfo/legal/guidelines_tsusoku/
- 総務省「AI事業者ガイドライン」掲載ページ（第1.2版、令和8年3月31日公表）: https://www.soumu.go.jp/main_sosiki/kenkyu/ai_network/02ryutsu20_04000019.html