ベテランの頭の中にしか、
正解がない。
これは「マニュアルがない」問題ではありません。
文書はあるのに、文書に聞けないというお困りごとです。
探すより人に聞く方が速い限り、知識は人に貼りついたまま動きません。
こういう言い方で相談が来ます
どれも症状です。原因はまだ言えていません。
「あの人に聞かないと分からない。あの人が休むと止まる。」
「マニュアルは作った。誰も読んでいない。」
「辞めた担当者の案件が、もう追えない。」
「新人が同じことを何度も聞いてくる。教える側の時間がない。」
「過去にやった似た案件があるはずだが、どこにあるか分からない。」
「ベテランが来年で定年。何を引き継げばいいのかも整理できていない。」
これは何の問題か
探すコストが、人に聞くコストより高い状態。
だから知識は人に貼りついたまま、動かない。
人は合理的に動きます。探すのに5分かかるなら、30秒で答えてくれる隣の席のベテランに聞きます。 誰も悪くありません。そのたびにベテランの時間が削られ、知識はその人の中に留まり続ける——というだけです。
なぜ「マニュアル整備」では解けないのか
1. 書いても、探せない
ファイルサーバに300本のPDFがあっても、いま必要な一行がどのファイルの何ページかは分かりません。 ファイル名で探すには、答えを先に知っている必要があります。
2. 一度書いて、更新されない
作った直後がいちばん正しく、そこから古くなる一方です。古い記述が混じっていると分かると、 人は文書全体を信用しなくなり、また聞くようになります。
3. そもそも書けていないものがある
「この条件のときはこうする」という判断は、ベテラン本人も言語化していないことが多い。 本人にとっては当たり前すぎて、書くべき知識だと認識されていません。
直すべきは、文書の量ではなく文書への入口です。
「探す」を「聞く」に変えられれば、人に聞く理由がなくなります。 そのうえで、書かれていない判断を書き出していく——順番はこちらです。 先に全部を書き出そうとすると、ほぼ確実に途中で止まります。
このままだと、こういうことが起きます
ベテランの時間が細切れになる
一番手が速い人が、一日中質問に答えて自分の仕事が進まない状態になります。
新人が立ち上がらない
聞ける相手が忙しいと、待っている時間がそのまま立ち上がりの遅れになります。
退職で知識が消える
引き継ぎ資料に書けるのは、本人が知識だと認識できたものだけです。
同じ失敗を繰り返す
過去に一度やった対処が探せないので、毎回ゼロから考えることになります。
属人的な品質のばらつき
誰が担当したかで結果が変わるのに、その差を説明できません。
人を採っても回らない
教える側の時間が確保できないので、人数を増やしても現場の負荷が下がりません。
「探す」を「聞く」に変える。
PDFを登録して、日本語で質問する。答えと一緒に 「どの文書の何ページに書いてあるか」が返ってきます。 出典が付いているので、疑わしいときは元の文書をその場で確認できます。
この仕組みを RAG（検索拡張生成） と呼びます。 AIが答えを作る前に手元の文書から根拠を探し、そこだけを見て答える——という順序にすることで、 書いていないことをもっともらしく答えてしまう事故を抑えます。
PDFを登録
マニュアル・カタログ・仕様書・過去の報告書
文章を細かく分ける
検索できる単位に切り、意味をベクトルに変換して保存
質問から根拠を探す
聞かれた内容に近い箇所だけを文書から取り出す
出典付きで答える
取り出した箇所だけを見て答え、何ページかを添える
RAGは万能ではありません。ここを先に書いておきます
- —文書に書いていないことは答えられません。ベテランの頭の中にあって一度も書かれていない判断は、出てきません。
- —古い文書が混じっていれば、古い答えが返ります。どれが現行版かは人が決める必要があります。
- —だから実際の作業は「よく聞かれることを先に書き出す」ところから始まります。全部は要りません。頻度の高い順に上から30個ほどで体感が変わります。
- —この書き出しを一緒にやるところが、伴走の中身のいちばん大きい部分です。道具を置いて終わりにはなりません。
公開しているデモについて
題材は家電の取扱説明書です。自社で組んで、このサーバで動かしています。 ご自身のPDFをアップロードして試すこともできますが、 機密文書はアップロードしないでください。検証用の環境です。
聞かれる側の時間が、戻ってきます
属人化がなくなるとは言いません。変わるのは「人に聞かなくても済む範囲」の広さです。
ベテランが自分の仕事に戻れる
同じ質問への回答が減るので、細切れになっていた時間がまとまります。
新人が待たなくなる
聞ける相手が忙しくても、先に自分で確かめられます。
答えの根拠が残る
出典が付いているので、「誰が言ったか」ではなく「どこに書いてあるか」で話せます。
書き出す優先順位が決まる
実際に何を聞かれているかが記録として残るので、次に書くべきものが分かります。
辞めた人の案件を追える
過去の報告書や仕様書に問いを投げられるようになります。
こういう会社に当てはまります
共通しているのは「判断に前例が要る仕事」であることです。
仕様書・図面・過去の報告書が溜まっている（製造・建設・設備）
製品の型番ごとに対応が違う（保守・修理・サポート）
規程や手順書が多く、更新もされている（医療・介護・金融・士業）
問い合わせ対応に同じ質問が繰り返し来る
ベテランの退職・定年が数年内に控えている
担当者が替わるたびに引き継ぎで止まる
よくいただく質問
マニュアルを整備すれば解決しませんか
整備しても、探すのに5分かかるなら人は聞きます。隣の席のベテランに聞けば30秒で済むからです。 マニュアルが読まれない原因はやる気ではなく、探すコストが聞くコストより高いという構造です。 だから直すべきは文書の量ではなく、文書への入口です。
RAGとは何ですか
検索拡張生成（Retrieval-Augmented Generation）の略です。AIが答えを作る前に、手元の文書から根拠となる箇所を検索し、 そこだけを見て答える仕組みです。答えと一緒に「どの文書の何ページか」を返せるので、 書いていないことをもっともらしく答えてしまう事故を抑えられます。
RAGを入れれば属人化はなくなりますか
なくなりません。RAGは文書に書いてあることしか答えられないので、 ベテランの頭の中にあって一度も書かれていない判断は出てきません。 だから実際の作業は「よく聞かれることを先に書き出す」ところから始まります。 全部を書き出す必要はなく、聞かれる頻度の高い順に上から30個ほどで体感が変わります。
社内の文書を外部のAIに渡すことになりますか
何をどこまで外に出すかは設計で決められます。文書の保管と検索の部分を自社サーバ内に置き、 文章の生成だけを外部に投げる構成も、全部を自社側に閉じる構成も取れます。 扱う情報の性質に合わせて、最初にここを決めてから作ります。
デモはどんな文書で試せますか
公開しているデモは家電の取扱説明書を題材にしています。ご自身のPDFをアップロードして試すこともできます。 機密文書はアップロードしないでください。検証用の環境です。
紙の書類しかない場合はどうなりますか
スキャンして文字を読み取る工程が先に入ります。印刷された文書なら実用的な精度で読めますが、 手書きや古い青焼きは精度が落ちます。ここは実物を数枚お見せいただければ、その場で見通しをお伝えできます。
自社の文書で、聞ける形にしてみる
初回の棚卸しは無料です。30分オンラインで、いま何を何回聞かれているか・文書がどこにどんな形であるかを教えてください。「RAGで効くのか、その前に書き出しが要るのか」の見立てをお返しするところまでが無料の範囲です。
- 1 下のフォームを送る。箇条書き1行で構いません
- 2 30分オンライン。資料の準備は不要。いつもの帳票をそのまま見せてください
- 3 見立てを無料でお返し。進める場合の概算費用もこのとき出します
お困りごとシリーズ
台帳をぜんぶ見る症状ではなく「これは何の問題なのか」を定義し、実際に見えるようにしたところまでを1本ずつ書いています。
人を増やしても、現場が楽にならない
人手不足ではなく、時間帯ごとの配置が見えていない
見せられるもの：168時間 配置ビュー 02案件の利益が、締めてからしか分からない
見積・原価・入金が別の場所にあり、突き合わせが月末しかできない
見せられるもの：Mercury-Linkベテランの頭の中にしか、正解がない
文書がないのではなく、文書に聞けない
どのお困りごとから入っても、進め方は同じです。 経営のお困りごとに伴走する進め方 にまとめています。