「RAGを全社導入してから1カ月経つけど、どうですか？　現場は活用していますか？」――。「……正直に申し上げると、使われていない部署も多いです。営業部では、AIの回答を基に値引き対応したところ、管理部からルール違反だと指摘されたケースも出ています」「そうなんです。AIが出した答えを信じて動いたのに、あとから『そんなルールはない』と言われても困ります。一体何を根拠に答えを出しているんですか？」

　この会話には、「とにかくRAGを入れれば何とかなる」という発想と、「現場の知識をそのまま放り込めばAIが理解してくれる」という期待が見え隠れします。この誤解は、RAGの導入初期にありがちな失敗の要因です。

　企業の情報システム部門を1人で担当する「ひとり情シス」担当者を支援するひとり情シス協会は2026年4月、ネオスの協賛を受けて「AIしくじりひとり情シス　中堅中小企業生成AI（RAG）プロジェクト中間報告」（以下、AIしくじりひとり情シス）を出版しました。同報告は、生成AI運用で“しくじり”を経験した5つの業種（食品製造・販売、卸売業、製造業、医療・介護事業、建築業）の企業事例を集めたものです。

RAG導入を「業務改革」ではなく単なる「ITツールの導入」と矮小化している

　RAGの導入や運用でしくじる企業の経営層に共通するのは、RAGを「導入すれば自動的に現場が楽になる魔法の杖」や「高度な全文検索エンジン」と短絡的に捉える姿勢です。

　創業50年を超えるある卸売業者は、長年放置されてきた「取引先ごとの関係性に基づく複雑な属人的判断」を、RAGを使ったシステムを導入するだけで解決できると誤解していました。しかし、卸売業の営業判断には、過去の経緯や業界の慣習、担当者同士の信頼関係など暗黙のルールが複雑に絡み合っています。同社の経営層はその複雑さを正面から扱わず、「とにかくRAGがデータを参照できるようになれば解決する」と安易に考えていました。

　建設業のある企業でも同様のことが起こっていました。ベテラン従業員の「足場の組み方の判断基準」「天候による作業中止の判断」などの「暗黙知」を、過去の施工基準書や安全マニュアルなどの書類を集めるだけで「RAGが適宜補ってくれる」と誤解していました。

　システムを業務フローのどこに組み込み、どの判断をAIに任せるかという「業務構造の再設計」は実施せず、RAGを「会話できるFAQ化」した結果、RAGを使ったシステムが生成する回答は現場の業務プロセスと乖離しました。若手現場監督からは、「結局ベテランに聞かなければ決断できない」と言われ、気が付いたら誰も使わないシステムになってしまいました。

　RAGを業務で有効活用するには、業務の中身と判断構造に踏み込む必要があります。経営層が、この課題をパラメーターやフローを整理すればいいと「ITの話」に矮小化し、業務の流れを見直さないままシステムを導入しても、現場の負担は減りません。「ツールを入れる」のと「仕事のやり方を変える」のは、別のことです。RAGを導入するということは、自社の判断構造の曖昧さに真正面から向き合う「経営課題」そのものと捉えなければ、プロジェクトは必ず壁にぶつかります。

RAGを「ITツール導入」と矮小化しない

　では、経営層は具体的に何を考えればいいのでしょうか。答えは明確です。「どの業務フローにRAGを組み込むか」「RAGを使ったシステムにどこまで回答や判断を委ねるか」「RAGが使われなかった場合の責任は誰が持つか」――。これらを経営層が自分ごととして考え始めた企業は、立て直しに成功しています。最初の設計が甘くても、経営層の認識が変わった瞬間からプロジェクトは動き始めるのです。

「データ量＝判断材料の多さ」と勘違い

　データを「入れること」と、RAGによって生成した回答を「業務判断に使えること」は別の話です。「うちにはマニュアルや記録がたくさんあるから、RAGの回答に基づいて判断しても問題ないはずだ」という思い込みは、RAGの導入や運用に失敗する企業に共通する特徴です。

　食品製造・販売会社の事例では、現場のチャット履歴を十分に整理しないままRAGの検索対象にしました。そこには、「ケースバイケース」「状況次第で柔軟に」といった表現が多く含まれていました。しかし、「どのような場合に」「何を基準に」柔軟に対応するのかという判断条件までは記録されていませんでした。

　人間同士であれば、「常連だから柔軟に対応する」という共通認識があった場合、「柔軟に」という一言だけでも、その背景にある条件を推測できることがあります。一方、RAGが参照できるのは記録された情報です。判断条件が明示されていなければ、「柔軟に」が具体的に何を意味するのかを判断できず、結果として曖昧な回答しか返せなくなります。

　医療・介護事業者の事例では「データ入れ過ぎ問題」がありました。同社では、「情報が多い」ことは「判断材料が多くなる」と勘違いし、事実記録だけでなく個人の感情メモや一時的な例外対応、さらには個人情報まで、整理・選別せずにRAGが参照できるようにしました。

　結果として、RAGが関連性の低い情報まで大量に取得し、LLMに渡すコンテキストが肥大化しました。その結果、重要な情報が大量の情報の中に埋もれ、LLMが十分に活用できない「Lost in the Middle」の問題も生じました。数秒で判断が求められる介護の現場において、「読む時間が取れない」「結論が分からない」と敬遠され、現場の負担を増やす結果となりました。

　この問題の根本には、「データの整理を誰がするのか」という役割の定義の曖昧さがあります。例えば、現場担当者は「情シスに渡せば何とかしてくれる」と考え、情シスは「もらったデータをそのままRAGの検索対象にすれば機能する」と期待する。経営層は「あとはAIがやる」と思っている――。このような思い込みが重なれば、誰も「現場知をRAGが参照できるように整理する」という作業を担いません。

　RAGを通じて正しい答えを生成できるようにするためには、曖昧なデータを「原則と例外」に分ける必要があります。さらに、RAGが参照できる内容に「翻訳」し、不要なノイズを削ぎ落とすという地味な人間側の作業が不可欠です。

　取材した全事例を思い返すと、この工程を省略した企業は、RAGを使いこなせませんでした。一方、この工程に正面から取り組んだ企業は途中から巻き返し、RAGを使いこなせるところまで挽回できました。

「情シスがひとりで抱え込む」構造的な問題

　RAGを使いこなせない企業に共通するのは、問題の発生源は経営層や現場にありながら、そのしわ寄せは情シスに集中してしまうという構造です。「うまくいかないのは情シスの設定が悪いから」「データの入れ方が間違っているんじゃないか」――。本来は組織全体の課題であるにもかかわらず、情シス担当者が矢面に立たされます。

　この状況は、担当者にとってストレスになるだけではありません。「何が正しいか分かっているのに、構造的な制約で行動できない」という苦痛が心をむしばみます。普段はIT投資に積極的ではない経営層の強い意気込みでスタートしたプロジェクトであればなおさらです。

担当者へのストレス

　では、この負担を解消するためにはどうすればいいでしょうか。

　それは、経営層がRAGの機能や役割を正しく認識し、関係者の業務負荷を十分把握しながら、データ整理という地道な作業に組織として向き合うことです。これができない限り、負担は解消されません。個人的にも、「データよりヒトのケアをお願いしたい」という気持ちです。

　しくじる企業の特徴として挙げた点は、「人間側の設計の問題」です。AIが悪いのではなく、AIに何を任せるかを決めなかった人間側に原因があります。

　次回は、RAGの導入にしくじる企業に共通する「慢心の構造」を紹介します。