文書管理システムを入れたのに探せない｜既存DMS・共有フォルダとAIエージェントの違いと、つなぐか入れ替えるかの判断

入れたのに、結局は詳しい人に聞いて探している

文書管理システムを導入しても、探せない状態は残ります。製品の中に文書は入っていて、フォルダの階層も権限も設定されている。それでも、担当者は目的の文書をシステムから見つけられず、過去に扱った人へ聞きに行きます。共有フォルダしか使っていない会社でも同じことが起きます。

原因を検索の性能に求めると、たいてい打ち手を外します。文書管理システムの検索は、ファイル名・作成者・更新日・登録時に入れた分類のような属性で候補を絞るようにできています。属性が正しく入っていれば速く正確に絞れます。逆に言えば、入っていなければ絞れません。そして登録の手間は現場が負うため、分類は空欄のまま、ファイル名は付けた人の癖のまま溜まっていきます。

もう一つの原因は、探している側の問いの形です。「どこにあるか分かっている文書を取りに行く」問いなら属性で足ります。しかし現場が抱えるのは「この条件の記載がある契約書はどれか」「前に似た事情で作った稟議はあるか」という、文書の中身に対する問いです。属性の検索はここに答えられません。

属性で絞る方式と、本文の意味から探す方式

AIエージェントを使った検索は、文書の本文を読み取って、意味の近さで候補を並べます。属性の検索とは前提から違うため、同じ「検索」という言葉で比べると判断を誤ります。

比べる点	属性とフォルダ階層で絞る方式	本文の意味から探す方式
探す手がかり	ファイル名・登録時の分類・作成者・日付・置き場	文書の本文と、そこに書かれた条件や経緯
事前に必要な作業	登録のたびに分類と属性を入れる	文書を取り込んで処理する（属性の入力は必須ではない）
得意な問い	どこにあるか見当が付いている文書を取りに行く	条件に合う記述がどの文書にあるかを探す
苦手な問い	中身の条件を手がかりにした問い	「最新版はどれか」のような、文書の外の事情で決まる問い
探し当てられない原因	属性が空欄、分類の付け方が部署ごとに違う	元の文書が古い、同じ主題の文書が複数あって区別が付かない
結果の見え方	条件に一致した文書の一覧	該当箇所を含む回答と、根拠になった文書

表の下2行が、進め方を決めるときに効いてきます。属性の検索が外れる原因は入力の欠落で、意味で探す方式が外れる原因は元の文書の側にあります。 前者は登録の運用を直せば改善しますが、後者は検索の仕組みをいくら調整しても、古い版や重複した文書が残っている限り直りません。

つまり、意味で探す方式を載せても、置き場と版の管理が崩れていれば的を外した回答が返ります。この関係は「AIエージェントによる文書管理の設計」で扱った「置く側」と「探す側」の分担そのもので、探す側だけを新しくしても置く側の問題は消えません。

属性で絞る方式は登録時の入力に支えられ、意味で探す方式は元の文書の状態に支えられる。
人が確かめる工程はどちらにも残る。

つなぐか、入れ替えるか、併用するか

既存の文書管理システムや共有フォルダがある状態で取れる進め方は、大きく3つです。どれを選んでも、探せない状態を作っていた原因のうち置き場の整理は残るため、先に整理してから選ぶ順番にはなりません。

進め方	何をするか	選びやすい条件
既存を残して検索だけ載せる	既存システムと共有フォルダを保管先として残し、横断して探す仕組みを上に置く	既存製品が保管と権限の管理として機能していて、不満が探す側に集中している
段階的に入れ替える	種類や部署の単位で保管先を移し、移した範囲から新しい仕組みで扱う	既存製品の契約が更新時期にある、または保管先自体が古く保守が続かない
併用する	既存を正本の保管先として残しつつ、新しい仕組みにも一部を置いて両方を運用する	部署や地域で扱いが分かれていて、一度に片方へ寄せられない

3つの差は、作業量よりも正本をどちらに置くかに出ます。検索だけ載せる場合、正本は既存システムに残り続けます。入れ替える場合は移した時点で正本が移ります。併用は、正本の所在が文書ごとに分かれた状態を運用で維持することになり、どちらにあるかを判断する手間が日々発生します。

以下、3つで発生する作業を項目ごとに見ます。どれも情報システム部門が主に負う作業です。

閲覧権限の引き継ぎで起きること

権限は3つの進め方で扱いが最も分かれます。

検索だけ載せる場合、権限は既存システムに残ります。新しい仕組み側は、問い合わせた人がその文書を見てよいかを既存システムに照会するか、既存の権限設定を写して使います。ここで注意が要るのは、検索結果の一覧や要約に、本文を見られない人へ内容が漏れる経路があることです。 文書そのものを開かせなくても、見つけられること自体が情報になる場合があります。設計の選択肢は「社内AI検索の閲覧権限をどう守るか」にまとめてあります。

入れ替える場合は、権限を移す作業が発生します。既存システムの権限が個人名で1件ずつ付いていると、移し先で同じ状態を作ることになり、移行の直後から古い設定を抱えます。移す前に、役割や部署のグループへ付け替える整理を挟むほうが後が軽くなります。移行のタイミングは、整理する機会としては都合が良い部類です。

併用する場合は、同じ文書が両方にある状態で権限の設定が二重になります。片方だけ直した状態が生まれやすく、後から検出するのは難しくなります。併用を選ぶなら、どちらの設定を正とするかを文書の種類ごとに決めておきます。

分類とメタデータの付け直しは、どこまで必要か

既存システムに入力済みの分類やメタデータは、進め方によって価値が変わります。

検索だけ載せる場合、既存の属性は絞り込みの条件として使えます。意味で探す仕組みと組み合わせると、「この取引先の契約書の中で、この条件の記載があるもの」という問いに答えられます。属性が入っている文書については、付け直す必要はありません。 入っていない文書は、本文から属性を取り出して補う形になります。

入れ替える場合、移行先の分類体系が既存と違うなら、対応表を作って変換します。ここで持ち込む分類をそのままにするか、この機会に整理するかは判断が分かれます。部署ごとに分類の付け方が違っている場合、そのまま移すと違いも一緒に移ります。共有フォルダに積み上がった文書の分類を付け直す進め方は「共有フォルダ・ファイルサーバの整理をAIで進める」を参照してください。

併用する場合は、両方の分類体系を維持することになります。片方に新しい区分を足したときに、もう片方へ反映する手順が要ります。運用として一番重くなるのはこの項目です。

保管期限の管理をどちらに持たせるか

保管期限は、どちらか一方に持たせます。両方に持たせると、満了の判定が食い違ったときにどちらが正しいか決められません。

進め方	期限の管理を持つ側	発生する作業
既存を残して検索だけ載せる	既存システム	期限切れの文書を検索の対象から外す条件を作る
段階的に入れ替える	移行の完了した範囲は新しい側	移行中は範囲ごとにどちらが持つかを一覧で管理する
併用する	文書の種類ごとに決めて固定する	種類と保管先の対応表を作り、例外の登録を止める

検索だけ載せる場合に必要なのは、期限が切れた文書、廃棄が決まった文書を検索の対象から外すことです。外れていないと、廃棄したはずの文書が回答の根拠として出てきます。出典が添えられている分、読んだ人は有効な文書として扱います。削除の反映が遅れる仕組みは、期限の管理を持っている側の意味を打ち消します。

保管年数そのものをAIに判断させない点は、どの進め方でも共通です。年数は法令と社内規程で決まる値なので、表を作って引かせます。起算日の取り方と廃棄前の確認の範囲は「文書の保存期間と廃棄をAIで管理する」にあります。

情シスが負う運用の重さを比べる

導入時の作業量より、その後に毎月・毎年かかる手間で差が出ます。

運用の項目	検索だけ載せる	段階的に入れ替える	併用する
保守する仕組みの数	2つ（既存＋検索）	移行中は2つ、完了後は1つ	2つが続く
権限の確認	既存側で1回	移行済みの範囲を確認する	両方を突き合わせる
新しい文書の置き場の案内	変えなくてよい	移行の進み方に合わせて案内を更新する	どちらへ置くかを毎回案内する
現場からの問い合わせ	探し方が変わる分だけ増える	移行の前後で一時的に増える	置き場の問い合わせが続く
止まったときの影響	検索が止まっても文書は既存側で取れる	移行中に止まると範囲が分からなくなる	片側が止まっても業務は続くが、正本の判断が要る
撤退のしやすさ	検索を止めれば元に戻る	移行済みの範囲は戻せない	どちらかに寄せる判断が要る

最後の2行が、最初の一歩としての選びやすさを分けます。検索だけ載せる形は、合わなければ止めれば元の状態に戻ります。入れ替えは、移した範囲について後戻りの手段がありません。取り返しの付かなさが違うので、判断に使える材料が揃っていない段階では、戻せる側から試すほうが安全です。

一方で、既存システムの保守が続かない、利用者が増えるたびに費用が上がる、といった事情があるなら、検索を載せても根本は変わりません。この場合は入れ替えの検討に入ります。

自社の条件で、どれを選ぶか

判断の材料になるのは、現状の測り方です。次の順に確かめます。

直近1か月の「文書が見つからない」問い合わせを数え、問いの形を分ける置き場が分からない問いか、中身の条件を手がかりにした問いかで分けます。後者が多ければ、意味で探す方式が効く余地があります
既存システムに入っている文書の割合を数える社内の文書の多くが製品の外の共有フォルダやメールにあるなら、製品側を直しても探せない範囲は残ります
既存製品の契約と保守の状況を確認する更新時期が近い、保守が終わる、費用が利用者数で増える、のいずれかに当たるなら入れ替えが選択肢に入ります
閲覧権限の付け方を確認する個人名で1件ずつ付いているなら、どの進め方でも先に整理が要ります
保管期限の管理が既存システムで機能しているかを確認する期限が入っていない、入っていても誰も見ていないなら、移す価値のある機能は権限だけになります

1と2で「中身への問いが多く、文書は製品の外にも散らばっている」なら、検索を載せる進め方が合います。3で契約や保守の事情が重なるなら、入れ替えの検討へ進みます。併用は、どちらかを選べない事情があるときの形であり、選択肢として並べるものではありません。

意味で探す仕組みを社内データに当てる方式の選び分け（社内文書を読ませるか、学習させるか）は「ファインチューニングとは？RAGとの違い」を参照してください。社内文書の横断検索そのものの設計は「社内文書検索をAIで横断する」にまとめてあります。

着手の順序

どの進め方でも、最初の3つは共通です。

文書が見つからない問い合わせを1か月分数え、問いの形で分ける
文書がどこに何件あるかを、既存システムの中と外に分けて数える
閲覧権限の付け方を確認し、個人名で付いている文書の件数を出す
対象を1種類か1部署に絞り、検索を載せる形で試す
試した範囲で、探せなかった問いを記録し、原因を検索の側か元の文書の側かで分ける
元の文書の側が原因なら、その範囲の置き場と版の整理へ戻る
既存製品の契約や保守の事情が重なる場合に限り、入れ替えの範囲と順序を決める

5で原因を分けるのが要点です。探せない原因が元の文書の側にあるのに仕組みを入れ替えると、移した先で同じことが起きます。 移行の前にこの区別を付けておくと、入れ替えるかどうかの判断が根拠を持ちます。

まとめ：既存の文書管理システムとAIエージェントのどちらを取るか

探せない原因は検索の性能ではなく、属性で絞る方式が登録時の入力に依存していること。空欄のままでは絞れない
属性で絞る方式が外れる原因は入力の欠落、意味で探す方式が外れる原因は元の文書の側にある。後者は仕組みを調整しても直らない
取れる進め方は3つ。既存を残して検索を載せるか、段階的に入れ替えるか、両方を併用するか。差は作業量より正本をどちらに置くかに出る
権限は、検索を載せるなら既存側に残る。入れ替えるなら移す作業が要り、その前に個人名の付与をグループへ整理しておく
既存の分類やメタデータは、検索を載せる場合は絞り込みの条件として使える。入れ替えるときだけ対応表と付け直しが要る
保管期限はどちらか一方に持たせる。廃棄した文書を検索の対象から外す反映が遅れると、期限の管理が意味を持たなくなる
運用の重さは、保守する仕組みの数と撤退のしやすさで比べる。併用は両方が続くため一番重い
判断の前に、問い合わせの形・文書の所在・契約の状況・権限の付け方・期限の運用の5つを測る

Augueでは、社内に散らばった文書を横断して探せるようにする仕組みの開発に対応しており、既存の文書管理システムを残したまま載せるか、移行まで含めて設計するかの切り分けから一緒に進められます。自社の現状でどちらを取るか整理したい方は、是非ご相談ください。

自社専用のAIエージェントを作りませんか？

作るか既製品を使うか、費用の目安から相談できます。使うほど育ち、成果が続くAIエージェントの開発をご支援します。開発の進め方と事例はサービス資料でご覧いただけます。

資料をダウンロードする無料相談に申し込む

よくある質問

導入済みの文書管理システムのベンダーがAI検索の機能を出すと言っています。待つべきですか？

提供時期と対象範囲が文書で示されているなら待つ判断は成立します。確認したいのは、検索の対象が製品の中に入っている文書だけなのか、製品の外にある共有フォルダやメールの添付まで含むのかという点です。社内の文書が製品の外にも置かれている場合、製品側の機能が出ても探せない範囲は残ります。その範囲の量を先に数えておくと、待つ間に何を進めるかが決まります。

どれくらいの期間と体制で始められますか？

対象を1部署か1種類に絞って検索を載せるだけなら、数週間から2か月程度の幅で試せる規模になります。人手がかかるのは仕組みより前の工程で、対象の文書がどこに何件あるかを数える作業と、閲覧権限の現状を整理する作業です。情報システム部門の担当が1人、対象部署で質問と回答を確認する人が1人いれば始められます。

費用は既存の文書管理システムを更新するのと比べてどうなりますか？

一律の目安は出せません。既存製品の契約形態、対象文書の件数、検索のために文書を処理する量で変わるためです。比べるなら、既存製品の年間費用に対して、検索を載せた場合の追加費用と、入れ替えた場合の移行作業の人件費を並べます。移行の人件費は権限の確認と分類の付け直しに集中するので、その2つの対象件数を数えると見積もりの精度が上がります。

クラウドストレージの標準の検索機能では足りませんか？

ファイル名と作成者、更新日で当たりが付く探し方であれば足ります。足りなくなるのは、文書の中に書かれた条件で探すときです。標準の全文検索は語が一致した文書を返すため、社内の言い換えや略称が混ざると漏れます。どちらの探し方が多いかは、直近の問い合わせ内容を1か月分数えると分かります。

使わなくなった古い文書は移行の対象に含めるべきですか？

最初は外すほうが進みます。件数の大半を占めるうえ、参照されるのは一部に偏るためです。直近で参照された文書と、保存期限が残っている文書を先に対象とし、残りは照会が起きた種類から取り込みます。含める範囲を広げるほど、分類の付け直しと権限の確認の作業量が増えます。