目次
社内の規程やマニュアル、「どこに書いてある？」を探すのはSIer案件なのか
「この手続き、規程のどこに書いてありましたっけ」。総務にこの質問が来るたびに、担当者は共有フォルダを開き、似たようなファイル名のWordやPDFを順番に開いて、目的の一文を探します。
マニュアルは部署ごとに作られ、改訂のたびに新しいファイルが増え、どれが最新かも定かではありません。こうした文書管理の分散が、「探す」という作業そのものに地味に時間を奪っていきます。
やっかいなのは、この「探す係」がたいてい特定の人に固定されてしまうことです。「あの規程のことは、あの人に聞けば早い」。そうやって属人化が進むと、その人が不在の日には社内の問い合わせが止まってしまいます。
こうした状況を前にすると、「AIに社内文書を全部読ませて、聞けば答えてくれるようにできないか」という発想が自然に出てきます。
ただ、ここで一度立ち止まりたくなるのが、「文書をAIに検索させる仕組みなんて、専門業者に頼む大がかりな開発案件になるのではないか」という先入観です。相談すれば大きな見積もりが返ってきそうで、相談自体をためらう声もあります。
本当にそうでしょうか。この記事では、kintoneと生成AIを使って社内文書のAI検索を自社で用意するときに、どこでつまずき、何を押さえれば信頼できる仕組みになるのかを整理します。
kintoneに集めてAIでつなげば、出典付きで即答できる。ただし本当の壁は精度ではない
規程やマニュアルをkintoneに集約し、生成AIによる検索（RAG）でつなげば、「育児休業の申請期限は」と自然文で聞くだけで、根拠となった文書名や条項を添えて答えを返す仕組みが作れます。 しかも、これはSIerに大規模な開発を発注しなくても、kintoneのアプリ作成ができる担当者の手が届く範囲から始められるのです。
ここで言うRAG（検索拡張生成）とは、AIに質問すると、まず社内文書の中から関連する箇所を検索して取り出し、その内容だけを根拠に回答を組み立てさせる仕組みのことです。
RAGそのものの作り方はkintoneユーザーのための生成AI実践大全やDifyとkintoneの連携で「自社データを理解して答える」AIチャットを作る記事で解説しているので、本記事では作り方の手順には深入りしません。
代わりに本記事で扱いたいのは、実際に社内文書のAI検索を用意しようとすると突き当たる、もう一段深い壁です。それは回答の精度そのものではなく、「AIの答えを、どこまで信じてよいか」という線引きにあります。
検索の精度を上げることばかりに気を取られると、この線引きの設計が抜け落ち、かえって使えない仕組みになりかねません。次の章から、なぜこの線引きが要になるのかを見ていきましょう。
なぜ「探す時間」と「あの人しか知らない」が消えないのか
社内文書の管理・検索が行き届かないままなのには、文書が生まれてきた経緯そのものに原因があります。規程やマニュアルは、必要になった部署が、必要になったタイミングで作ります。総務は就業規則を、製造部門は作業手順書を、それぞれ別の場所に置き、改訂も別々に進めるのが実情です。
結果として、社内文書は「一か所にまとまった台帳」ではなく「あちこちに散らばった断片」として積み上がっていきます。
キーワード検索が効きづらいのも、これと地続きの問題です。ファイル名やフォルダ構成が部署ごとにばらばらだと、そもそもどのファイルを開けばよいかの見当がつきません。
「有給」で検索したい規程が、文書側では「年次有給休暇」と書かれていれば、言葉が一致せず引っかからないこともあります。探す側は、文書側の言い回しを先回りして推測する必要に迫られ、ここで時間を取られてしまうのです。
だからこそ、「あの規程はあの人に聞く」という属人化が残り続けます。文書の在りかと中身を頭に入れている人に聞くのが、いちばん速いからです。
裏を返せば、文書を横断してまとめて検索できる状態を作れれば、探す時間と属人化は同時にほどけていきます。 市販の文書管理システムを導入するという選択肢もありますが、社内文書のAI検索が狙うのは、まさにこの「横断して探せる状態」を自社の道具で作ることです。
なお、この仕組みを誰が実装するのかも、あらかじめ切り分けておきましょう。kintoneへの文書の集約や画面の設定は、アプリ作成の経験がある担当者であれば無理なく手が届きます。
費用面でも、ワークフロー自動化に使うn8nはセルフホスト型なら無料で始められ、クラウド版でも有料プランから選べます。生成AIの利用料も、社内文書の検索という用途であれば、まずは小さく試せる規模から始められるでしょう。
一方で、社内にその手を動かす時間を確保できるかどうかは、技術の話とは別の体制の問題です。この点は記事の最後であらためて触れます。
「AIに読ませれば解決」でつまずく3つの落とし穴
社内文書のAI検索は、「文書を全部AIに読ませれば終わり」という単純な話ではありません。安易に組むと、次の3つの場所で必ずと言ってよいほどつまずきます。着手する順に見ていきましょう。
文書を渡さず汎用AIに聞くと、自社にない一般論を「あるかのように」返す
最初のつまずきは、手元の市販の汎用AIチャットに、社内文書を渡さないまま「うちの育児休業の規程は」と聞いてしまうことです。汎用AIは自社の規程を参照していないため、一般的な法律や世間一般の慣行をもとに、それらしい回答を組み立てます。しかも困ったことに、その回答は自信たっぷりの断定口調で返ってきます。
これがいわゆるハルシネーション、つまり「それらしい嘘」です。AIは「知りません」と言うより、手持ちの知識からもっともらしい文章を生成する方に傾きます。自社の規程で独自の条件を定めていても、それを知らないAIは一般論で上書きしてしまうのです。
読んだ人は、それが自社のルールなのか一般論なのか区別がつきません。社内文書の検索でいちばん怖いのは、精度が低いことではなく、間違いが本当らしく見えることにあります。
出典がない回答は照合できず、結局元の文書を探し直すことになる
2つめのつまずきは、出典を示さない回答です。仮にAIが正しい内容を答えたとしても、「どの文書の、どの条項に書いてあるか」を示せなければ、受け取った側はその正しさを確かめられません。
確かめられない回答は、実務では使えません。総務が問い合わせに答えるにも、根拠の条文を示せなければ、答えの正しさを確認する手段がないからです。
結局、答えの裏を取るために元の文書を探し直すことになり、AIに聞く前の「探す作業」がそっくり残ってしまいます。 これでは、時間を減らすはずの仕組みが、確認の手間を上乗せするだけに終わってしまいます。
規程を改訂したのに、AIが古い内容で答え続ける
3つめは、時間の経過とともに現れるつまずきです。社内文書は生き物で、規程は改訂され、マニュアルは更新されます。ところが、一度AIに読み込ませたきりにしておくと、AIは古い版の内容を根拠に答え続けます。
たとえば就業規則を改訂して申請期限が変わったのに、AIが参照しているのは旧版のまま、という状態です。
表面上はきちんと出典付きで答えてくるので、かえって古い情報だと気づきにくいという厄介さもあります。
文書を取り込む仕組みを作って満足してしまい、その後の更新への追従を設計に入れ忘れると、時間が経つほど回答と実物がずれていくのです。
「どこまで信じるか」を設計する3つの勘所
3つのつまずきは、裏返せばそのまま設計の勘所になります。「AIの答えをどこまで信じてよいか」を仕組みの側であらかじめ決めておく。それが、信頼できる社内文書検索と、それらしい嘘を返す危うい仕組みとの分かれ目です。先ほどの落とし穴と対応させながら、実行する順に見ていきましょう。
kintoneに集約し、RAGで「自社文書だけ」を根拠に答えさせる
最初の勘所は、AIが参照する範囲を「自社文書だけ」に閉じることです。規程・マニュアルをkintoneのアプリに集約し、生成AIにはそのkintone上の文書から検索して取り出した内容だけを根拠に答えさせます。 これがRAGの基本の形であり、汎用AIの一般論による上書きを防ぐ土台になります。
kintoneに集約する利点は、文書が散らばらず一か所に集まること、そしてアクセス権を文書ごとに設定できることです。参照させたくない文書はAIの検索対象から外すといった制御も、kintoneの権限の考え方の延長で組めます。
まずは、文書名・文書種別・版数・改訂日・所管部署・閲覧範囲・原本URL・添付ファイルを持つ「社内文書台帳」を作ります。画面では、文書の版数と改訂日、原本PDFがひと目で結び付く状態を確認してください。
<—①:kintone社内文書台帳—>
RAGチャットを実際に構築する手順は先ほどの連携記事に譲りますが、要は「AIに世界中の知識で答えさせるのではなく、自社の書庫の中だけで答えさせる」という発想の切り替えが起点になるのです。
回答に必ず出典（文書名・条項・ページ）を併記し、根拠がなければ「該当なし」と返す
2つめの勘所が、この記事でいちばんお伝えしたい要になります。回答には必ず、根拠にした文書名・条項・ページを併記させます。 そして、自社文書の中に根拠が見つからない問いには、無理に答えさせず「該当する記載は見つかりませんでした」と返させるのです。
出典を併記させると、受け取った側は示された条項を開いて、その場で裏を取れます。答えが正しいかどうかを、AIを信じるかどうかではなく、文書を見て判断できるようになる。これが「どこまで信じるか」の線引きを、仕組みとして担保するということです。
実装では、PDF本文を短い単位に分けるときに、本文だけでなく文書名・版数・原本URL・本文内の位置も一緒に保存します。次の画面では、n8nの「本文をチャンク化し出典を付与」ノードの設定と出力を確認し、回答側で出典を表示するための情報が残っていることを見てください。
<—②:出典メタデータを付けるノード—>
加えて、根拠がなければ「該当なし」と言わせる設計は、それらしい嘘が生まれる余地そのものを塞ぎます。 AIに「分からないときは分からないと言う」という振る舞いをあらかじめ約束させておくわけです。
この2つがそろって初めて、社内文書のAI検索は「確認の手間を上乗せする仕組み」から「安心して頼れる仕組み」へと変わります。
n8nで取込を定期・自動化し、更新のたびに再インデックスする
3つめの勘所は、文書の更新にAIを追従させることです。規程やマニュアルが改訂されたら、AIが参照する索引（インデックス）も作り直さなければなりません。これを手作業でやろうとすると必ず抜けが出るので、取り込みと索引の作り直しはn8nのようなワークフロー自動化ツールで定期的に回します。
具体的には、kintoneの文書アプリに更新があったら、その文書を取り込み直し、検索用の索引を作り直す、という一連の流れを自動で実行させます。こうしておけば、担当者が「AIの学習をやり直す」作業を意識しなくても、改訂した翌日には新しい内容で答えるようになるでしょう。
ワークフローは、更新通知を受けて最新版のレコードと添付PDFを取得し、本文を抽出・分割して埋め込みを作り、検索用ベクトルDBへ再登録する順に組みます。全体像を先に確認すると、どの設定が「改訂後も古い内容で答えない」ためのものかを追いやすくなります。
<—③:ワークフロー全体—>
文書管理を問い合わせ管理の自動化などと同じように、人が手を動かし続けなくても回る状態にしておくことが、長く使える仕組みの条件です。
出典付きで即答でき、更新にも追従する社内文書検索を自社の手で
ここまでの3つの勘所を組み込むと、社内文書は大きく変わります。共有フォルダの奥で眠っていた規程やマニュアルが、「育児休業の申請期限は」と聞けば、根拠の条項を添えて即座に答えが返る「使える検索」に変わるのです。
答えには出典が付いているので、その場で裏を取れます。文書を改訂すれば、翌日にはAIも新しい内容で答えます。「あの人に聞かないと分からない」という状態も、少しずつほどけていくはずです。
大事なのは、つまずく場所が3か所だと分かっていることです。つまずくのは、自社文書を参照していない一般論、出典のない回答、更新への未追従の3つでした。
この3つを先に押さえておけば、社内文書のAI検索は決して手の届かない開発案件ではなく、自社の手で組み立てられる仕組みになります。市販の文書管理システムを外部から買うのではなく、いま使っているkintoneを土台に、必要な部分だけを自分たちで作るという選び方です。
ただし、技術的に実現できることと、それを社内で実際に回せることは別の問題です。文書の集約やワークフローの構築には、当然ながら手を動かす時間が要ります。
そこに割ける人手が社内にあるかどうかは、技術とは切り離して考える論点になるでしょう。自社の文書構成や運用にあわせて、どこから手をつければよいか判断がつかない場合は、外部の相談先を頼るのも一つの手です。
まとめ
社内文書のAI検索でつまずくのは、精度そのものよりも「それらしい嘘」をどう防ぐかにあります。押さえるべき勘所は3つでした。
- kintoneに文書を集約し、RAGで自社文書だけを根拠に答えさせる
- 回答に必ず出典（文書名・条項・ページ）を併記し、根拠がなければ「該当なし」と返す
- n8nで取り込みと再インデックスを自動化し、文書の更新にAIを追従させる
この3つを組み込めば、「どこまで信じてよいか」が仕組みの側で担保され、探す時間と属人化を同時にほどく社内文書検索が、SIerに頼らず自社の手で作れます。
最後に
「自社の規程やマニュアルの構成だと、どこから手をつければいいのか」「うちの運用でも本当に回せるのか」。実際に組もうとすると、こうした個別の判断が必要になります。
自社の文書や体制にあわせた進め方に迷う場合は、ものづくりAI自動化ファクトリーの無料相談をご利用ください。kintoneと生成AIを組み合わせた社内文書検索の設計を、御社の状況にあわせて一緒に整理します。