「あの資料はどこにある？」を、AIに聞ける社内情報検索へ
企業の中には、すでに多くの情報があります。
就業規則。
業務マニュアル。
会議議事録。
社内通知。
過去の提案資料。
部門ごとの共有ファイル。
Teamsに残されたやり取り。
長年蓄積されたナレッジ。
しかし、情報が存在していることと、必要なときに使えることは同じではありません。
実際の業務では、
* どのフォルダにあるか分からない
* ファイル名を覚えていない
* 過去の会議で何が決まったか探せない
* 同じ質問を詳しい社員へ何度も聞いている
* 資料を見つけても、必要な箇所を読むのに時間がかかる
* 情報が複数の場所に分散している
といった問題が起こります。
特に組織が大きくなるほど、問題は「情報がないこと」ではなく、
情報はあるが、見つけられないこと
へ変わっていきます。
Sekimosoft合同会社では、こうした課題を題材に、社内規程、議事録、マニュアル、各種資料を横断的に検索し、AIが回答と根拠資料を提示する社内情報検索システムを開発しました。
単なるキーワード検索ではありません。
質問を入力すると、
**AIによる回答
＋
回答の根拠
＋
参照した資料
＋
該当箇所**
を確認できる仕組みです。
> 本事例について
>
> 本記事は、Sekimosoft合同会社が社内情報検索とナレッジ活用の課題を題材に開発した自社実証システムの事例です。
>
> 特定の顧客企業へ導入した事例ではありません。
>
> 約500名規模の組織利用を想定し、社内情報の横断検索、AIによる回答、根拠提示、会議決定事項の整理、アクセス権限、運用管理を考慮して設計・実装しています。
社内情報を探すために時間がかかると、
「もっと整理すればよい」
「検索の仕方を覚えればよい」
と思われることがあります。
しかし、情報が増えるほど、人の努力だけでは限界があります。
たとえば、一つの質問に対する答えが、
* 就業規則
* 部門マニュアル
* 過去の通知
* 会議議事録
に分散していることがあります。
あるいは、同じテーマについて、
* 古い資料
* 新しい資料
* 検討中の資料
* 正式決定後の資料
が同時に存在している場合もあります。
この状態では、ファイル名を検索できても、
結局、どの情報が正しいのかを人が読み比べる
必要があります。
そこで今回の開発では、
「ファイルを探す仕組み」
ではなく、
知りたいことに対して、根拠付きで答えを探す仕組み
を目指しました。
情報の保存場所を、利用者に意識させない
社内情報は、一か所に集まっているとは限りません。
想定した情報源には、
* Teams上の共有情報
* 社内共有フォルダ
* ファイルサーバー
* 外付けストレージから移行した文書
* Word
* Excel
* PowerPoint
* 会議議事録
* 社内規程
* 業務マニュアル
などがあります。
従来の検索では、
「この情報はTeamsにある」
「この資料は共有フォルダにある」
と、利用者が保存場所を知っている必要がありました。
今回のシステムでは、利用者は保存場所を意識しません。
検索画面に質問を入力すると、複数の情報源から関連する資料を横断的に探します。
たとえば、
> 在宅勤務の申請条件を教えて
と入力すると、
* 就業規則
* 在宅勤務規程
* 社内FAQ
* 関連通知
などから情報を探し、回答を作成します。
重要なのは、
どこにあるかを知っている人だけが情報へ到達できる状態を減らすこと
です。
従来のファイル検索では、適切なキーワードを入力する必要があります。
しかし、利用者が資料内で使われている正式な言葉を知っているとは限りません。
たとえば、
「育児のために勤務時間を短くしたい」
と知りたい人が、
「育児短時間勤務制度」
という正式名称を知らない場合があります。
そのため、今回のシステムでは、自然な質問文を使えるようにしました。
たとえば、
* 子どもの送迎がある場合、勤務時間を短くできますか
* 出張の申請は何日前まで必要ですか
* この設備の点検手順を教えてください
* 過去に似たトラブルはありましたか
* この案件について、前回の会議では何が決まりましたか
といった質問です。
AIは質問の意味をもとに、関連する情報を探します。
これにより、
資料の名前や正式な用語を知らなくても、必要な情報へ近づける
ようになります。
回答には、必ず根拠を付ける
社内情報検索で最も避けるべきなのは、
AIがそれらしい回答を出すが、正しいか確認できない状態
です。
特に、
* 社内規程
* 業務手順
* 品質管理
* 契約
* 安全管理
に関わる情報では、回答の根拠を確認できることが重要です。
そのため、今回のシステムでは、AI回答と一緒に、
* 参照した資料名
* 該当箇所
* 更新情報
* 元資料へのリンク
を表示します。
たとえば、
> 在宅勤務の申請条件は？
という質問に対して、
AIによる回答
在宅勤務は、対象業務と所属長の承認条件を満たす場合に申請できます。
根拠資料
* 在宅勤務規程
* 第○条
* 該当箇所
という形です。
利用者は、AIの回答を見た上で、必要に応じて元の資料を確認できます。
AIを、
最終的な正解を決める存在
ではなく、
正しい情報へ早く到達するための案内役
として使います。
社内情報検索で、特に効果が期待できるのが会議情報です。
会議議事録は多くの企業に存在します。
しかし、時間がたつと、
* いつ話したか分からない
* どの会議だったか分からない
* 途中の議論と最終決定が混ざっている
* 誰が次の対応者だったか分からない
という状態になります。
そこで今回のシステムでは、会議情報に対して、
> 新システム導入について、最終的に何が決まった？
と質問できるようにしました。
回答画面では、
決定事項
最終的に採用された方針。
見送られた案
検討したが採用しなかった案。
決定理由
なぜその判断になったか。
担当者
次の対応を行う人。
次のアクション
今後必要な作業。
を整理して表示します。
さらに、根拠となる議事録を確認できます。
これにより、
過去の会議を探す仕組み
から、
過去の意思決定を再利用する仕組み
へ変わります。
社内には、似た内容の資料が複数存在することがあります。
たとえば、
* 2024年度版
* 2025年度改定案
* 2025年度正式版
です。
AIが古い資料だけを参照すると、誤った案内につながる可能性があります。
そのため、検索結果では、
* 資料名
* 更新日時
* 文書種別
* 参照元
* 関連性
を確認できるようにします。
必要に応じて、
複数の資料が存在すること自体を利用者に知らせる
ことも重要です。
AIが一つの答えに無理にまとめるのではなく、
> 関連する資料が複数あります。最新の正式版はこちらです。
と案内できる設計にします。
AI検索でも、元のアクセス権限を超えさせない
全社向けの社内情報検索では、権限設計が重要です。
社内には、
* 全社員が見られる情報
* 部門限定情報
* プロジェクト限定情報
* 管理職限定情報
* 人事・経営などの機密情報
があります。
AIを導入したからといって、これらをすべて検索対象にしてはいけません。
今回の設計では、
利用者が元々閲覧できる情報だけを、検索とAI回答の対象にする
ことを基本とします。
たとえば、
一般社員が質問した場合は、全社公開情報と本人が所属する部門の情報だけ。
管理職は、権限に応じて追加情報を検索可能。
という形です。
例えると、
優秀な案内係を置いても、鍵のかかった部屋を勝手に開けさせない
設計です。
すべての社内情報を、同じ方法で扱う必要はありません。
たとえば、
一般社内情報
* マニュアル
* FAQ
* 社内制度
部門情報
* 部門固有の手順
* プロジェクト資料
機密性の高い情報
* 人事
* 経営
* 法務
* 個別契約
では、扱いを分ける必要があります。
データごとに、
* 検索対象にするか
* AI回答に利用するか
* 誰が利用できるか
* どこに保存するか
* どの程度ログを残すか
を決めます。
「全部AIに入れる」のではなく、
情報の種類ごとに利用ルールを設計する
ことが重要です。
社内AI検索では、
答えが見つからないことも重要な結果
です。
関連資料が存在しない場合。
資料同士で内容が矛盾している場合。
回答に必要な根拠が不足している場合。
このようなときに、AIが推測で答えるべきではありません。
そのため、
* 十分な根拠が見つからない
* 複数の資料で内容が異なる
* 担当部署への確認が必要
という状態を表示します。
たとえば、
> 確認できる正式な資料が見つかりませんでした。担当部署への確認を推奨します。
という形です。
社内利用では、
答える能力だけでなく、答えない判断
も重要です。
AI検索システムでは、利用回数だけを見ても十分ではありません。
運用側では、
* データソースの同期状況
* 取込失敗
* 更新日時
* 検索エラー
* 回答できなかった質問
* よく検索されるテーマ
* 参照されている資料
などを確認します。
特に重要なのは、
回答できなかった質問
です。
これを見ることで、
* 必要な資料が存在しない
* 資料はあるが整理されていない
* 社内ルールが明文化されていない
* 同じ質問が繰り返されている
といった問題が見えてきます。
つまり、AI検索は情報を探すだけではありません。
組織のナレッジ不足を発見する仕組み
にもなります。
約500名規模の組織で利用する場合でも、最初から全社の全情報を対象にする必要はありません。
むしろ、対象を絞って検証する方が安全です。
Phase 1：対象部門と情報を絞る
たとえば、
* 社内規程
* 業務マニュアル
* 一部の会議議事録
から始めます。
利用者も限定します。
Phase 2：検索品質を確認する
* 欲しい情報が見つかるか
* 根拠が正しいか
* 古い資料を参照していないか
* 回答時間は実用的か
* 利用者が元資料を確認できるか
を検証します。
Phase 3：権限と運用を検証する
* 部門ごとの閲覧制御
* 更新ルール
* 不要資料の扱い
* 管理者の確認方法
を整えます。
Phase 4：対象を拡張する
効果が確認できた範囲から、
* 部門
* データソース
* 利用者
* 検索テーマ
を広げます。
この方法によって、全社導入前に実用性とリスクを確認できます。
導入効果を確認する際、
「AIが何回答したか」
だけでは不十分です。
見るべきなのは、
* 情報探索にかかる時間が減ったか
* 同じ問い合わせが減ったか
* 会議の決定事項を探しやすくなったか
* ベテラン社員への質問集中が減ったか
* 新しい社員が必要な情報へ到達しやすくなったか
* 情報不足のテーマを発見できたか
です。
たとえば、
従来は資料探索に15分かかっていた。
AI検索によって数分で候補へ到達できるようになった。
同じ質問への社内問い合わせが減った。
といった変化です。
重要なのは、
AIを使った回数ではなく、仕事がどれだけ前に進んだか
です。
今回の社内情報検索システムは、次の流れで構成します。
社内規程・マニュアル・議事録・各種資料
↓
データソースごとに情報を取得
↓
検索対象として整理
↓
アクセス権限を反映
↓
利用者が自然文で質問
↓
関連情報を検索
↓
AIが回答を生成
↓
根拠資料と該当箇所を表示
↓
利用者が必要に応じて元資料を確認
↓
検索・回答状況を運用側で改善
重要なのは、
AIだけを導入しないこと
です。
データ。
権限。
検索。
回答。
根拠。
運用。
これらを一つの仕組みとして設計します。
情報を探す時間が減る。
それだけでも価値があります。
しかし、本当の効果はその先にあります。
過去の判断を再利用できる。
詳しい人だけが知っている状態を減らせる。
新しい社員が自分で調べられる。
同じ質問への繰り返し対応を減らせる。
情報が不足しているテーマを見つけられる。
つまり、
個人の記憶に依存していた知識を、組織で使える状態に変える
ことが目的です。
Sekimosoft合同会社は、AIがすべての質問へ自動回答することを目的にしていません。
重要なのは、
必要な情報へ、より早く、安全に、根拠を確認しながら到達できること
です。
AIは、分からないことを勝手に決める存在ではありません。
大量の情報から候補を探し、
内容を整理し、
根拠を示し、
人の判断を速くする。
そのための手段です。
AI社内検索・ナレッジ活用についてご相談ください
次のような課題がある場合は、ご相談ください。
* 社内資料が複数の場所に分散している
* 必要なファイルを探すのに時間がかかる
* 過去の会議で何が決まったか分からない
* 同じ質問が特定の社員へ集中している
* 社内規程やマニュアルをAIで検索したい
* Teamsや共有フォルダを横断して探したい
* AI回答に根拠資料を表示したい
* 部門や役職ごとの閲覧権限を守りたい
* 全社展開の前に小さく検証したい
最初から、すべての社内情報をAIへ接続する必要はありません。
まず、誰が、何を探すために時間を使っているのか。
そこから対象を絞ります。
Sekimosoft合同会社は、現状整理、情報源の選定、アクセス権限設計、AI検索、根拠提示、会議ナレッジ活用、PoC、段階導入、運用改善までを一気通貫で支援します。
