RAG構築|先に決めるのは検索の道具ではなく、資料のどこまでを1件にするか

自動車部品のプレス加工をする会社で、客先からの技術問い合わせに答える社内チャットをRAGで構築した記録です。抽出結果の形を2日で29回直しても質問に噛み合わず、効いたのは「1項目=1事実」という1行でした。RAGを構築するとき最初に決めるものを書きます。
rag-hiyou-1entry-1fact リード図解

冷蔵庫でいちばん場所を取っているのは、いつも大きなタッパーです。日曜の夜に、きんぴらと煮物と卵焼きを、その1つに詰め込みます。

木曜の夜に、卵焼きだけ食べたくなります。ところが、卵焼きだけを取り出す方法がありません。蓋を開けて、上のきんぴらをどけて、その下を掘ることになります。

そこで、中身が見える透明なタッパーに買い替えました。それでも、木曜の夜に掘る手間は1分も減っていません。

このタッパーの話は、AIが社内資料から答えを探すときにもつながります。社内にある資料をAIに読ませて、聞かれたことに答えさせる作り方が広がってきました。RAG(Retrieval-Augmented Generation/検索で補強した文章生成)と呼ばれています。手元の資料の中から関係のありそうな箇所を探し、その中身をもとにAIに答えを書かせるやり方のことです。

RAGを構築したいという相談は、たいてい「ベクトルDBは何を使いますか」から始まります。ベクトルDBというのは、資料を意味の近さで探せる形にして置いておく保存先のことです。予算の話も、その保存先をどれにするかから始まります。

先に一行だけ置きます。RAGの構築で最初に決めるのは、資料を探す方法ではありません。資料の、どこまでを1件として切り出すかです。

資料を探す道具(検索器)は、質問に対して関係性が近いものを持ってくるものです。ベクトルDBはその代表になります。一方、あらゆる知識を1件として切り出すものは、探される側(検索対象)の形を決めることになります。ここが質問の形と合っていないと、検索器が正しく探しても、聞いていないことまでくっついて返ってきます。

僕も、探す道具から構築して失敗しました。資料から中身を拾い出す処理を、2日のあいだに29回書き直しています。それでも、聞かれた1件に、その1件だけを返すことができていません。

この話に出てくる事業

rag-hiyou-1entry-1fact 図解 1

この話で扱うのは、大手部品メーカーと僕の会社が組んで立ち上げた新規事業の試作品(MVP、必要最小限の機能で価値を試すもの)です。そのひとつが、自動車部品のプレス加工(金型で材料を押して成形する加工)をする会社で、社外から届く技術問い合わせに社内の担当者が答えるためのチャットです。使うのはその加工会社の中だけで、僕の会社はそのチャットを開発する役割です。加工会社のほうは、車メーカーに直接納める一次サプライヤー(部品の供給会社)の、さらに下請けにあたる二次サプライヤーになります。150トンと300トンのプレス機で、シートレール(自動車の座席を前後に動かすレール)の受け金具やブラケット(部品を固定・支持する金具)を製造しています。

質問してくるのは社外です。加工会社に発注している一次サプライヤーの、設計担当と調達担当から届きます。届く質問は、たとえば次のようなものになります。

「板厚1.2ミリの材料で、曲げ半径はどこまで詰められますか」。「指定のSPCCが手配できないのですが、SPHCで代替できますか」。

SPCCもSPHCも、プレスに使う鋼板の種類です。また、tは板厚を表す記号で、t1.2は板厚1.2ミリを指します。曲げ半径は曲げた部分の内側の丸み、バリは切断面に残る突起です。抜き方向は、材料をどちら側から打ち抜くかを表します。板厚と曲げ半径の組み合わせは、割れるか割れないかを分けます。

答えるのは社内の技術営業2名です。答えの元になる資料も社内にあります。加工条件や品質の基準をまとめた加工基準書と、金型ごとの情報をまとめた金型台帳の注意書きと、過去に返した回答メール。PDFとExcelと紙が混ざっています。

つまり、質問だけが社外から来て、回答も資料探しも社内の技術営業2名が行う、という形です。そして、どの資料をどの順で辿るかは、この2名の頭の中にしかありません。だから、この技術問い合わせへの回答にAIを入れることにしました。チャットを開くのも、この2名だけです。今日は、RAGを構築するときに最初に決めるものは何か、という話をしていこうと思います。

前置きはさておき、本題に入ります。

① 教科書どおりに、資料を切ってAIに項目と値へ直させた

rag-hiyou-1entry-1fact 図解 2

教科書に載っている手順は、素直です。資料を適当な長さに切る(チャンキング)。切った断片をAIに読ませて、コンピューターが検索できる項目と値の形に直させる(エンベッディング)。質問が来たら、近いものを探してAIに渡す。

そのとおりに構築しました。加工基準書のPDFを段落で切り、断片ごとにAIへ渡して、項目と値の組み合わせに直させます。最初の抽出結果(AIが資料から拾い出した結果)が返ってきたのは、着手から3日後でした。

試しに、加工基準書の一文をそのまま渡してみます。「SPCC t1.2、曲げ半径は0.5t以上、バリは0.05ミリ以下、抜きは表面側から」。返ってきたのは、この一文をまるごと1件として、その中に材質・曲げ半径・バリ・抜き方向の4つをぶら下げた形でした。

技術営業の2名に見せたときの手ごたえは、いま思うと良すぎました。1名はその場で、自分がよく聞かれる質問を3件打ち込んでいます。3件とも、それらしい答えが返りました。

この段階では、構築方法を間違えたとはまったく思っていませんでした。

② 資料を増やしたら、返ってくる形が毎回変わった

rag-hiyou-1entry-1fact 図解 3

ところが、読ませる資料を増やした途端に、返ってくる形が安定しなくなりました。

ここでいう「形」とは、AIの出力をこちらのプログラムで読み込めるようにした、項目と値の並べ方です。崩れ方を書き出します。返ってくるはずの形は、項目と値が1件ずつ並んだ一覧です。ところが、一覧ではなく、分類名で束ねた形で返ってきます。項目名の呼び方も、こちらが指定した名前ではなく、AIが選んだ別の名前に変わります。一覧全体をくくる括弧が無いまま、いきなり1件目の中身から始まることもあります。

いちばん厄介だったのは、文章が途中でぷつりと切れる返り方でした。括弧が閉じないまま終わるので、こちらの読み込みが失敗します。しかも、失敗したという知らせは出ません。しばらく「AIの調子が悪い」と誤診していました。

原因は、AIが一度に書き出せる長さの上限でした。AIは文章を「トークン」という単位で数えますが、日本語は同じ内容でも英語の2倍から8倍のトークンを使います。そしてAIを呼び出すための開発キット(SDK)の初期値は8192トークンです。加工基準書1ページ分を項目と値に直した結果すら、この長さには入りきりません。いまは8倍の65536トークンに上げてあります。

直した回数を数えました。2026年3月26日と27日の2日間で、抽出を担う1本のプログラムを29回書き直しています。うち18回は、動かなくなったものを元に戻すための修正でした。1日あたり15回近くです。書き直しては壊し、また書き直していました。

③ 直した29回を並べたら、答えの中身をほとんど触っていなかった

rag-hiyou-1entry-1fact 図解 4

29回の書き直しを、古い順に読み返しました。

分けてみると、抽出した中身そのものを良くしようとした修正は6回だけです。残る23回は、返ってきた形の後始末でした。束ねた形で返ってきたときに備える処理、項目名が違ったときに備える処理、くくる括弧が無いときに備える処理、途中で切れた文章を括弧の数だけ足して閉じ直す処理。2日分の修正のうち、8割が抽出した中身以外の修正でした。

形を整える処理を足しては、その日のうちに消しています。AIは、もとの文章をそのまま返してくれません。そこで、こちらが渡した文章と突き合わせて原文を復元する処理を書き、同じ日のうちに削除しました。返す形をAIに強制する指定も、ある種類のAI(モデル)で動かないという理由で1日目に取りやめ、2日目に戻しています。

ここまでは、まだ「そういうものか」で済ませていました。

引っかかったのは、形が整った日の出力を読み直したときです。「150トンのプレス4台、300トンのプレス2台」と書いてある一文が、抽出結果では「プレス機を数台」に丸まっていました。数値が落ちた状態で、形だけが正しく整っています。

つまり、形の後始末をどれだけ足しても、中身のほうは落ち続けていました。ここで、手をつけた順番のほうが悪かったのではないか、と思いはじめました。

④ 原因を1つに絞る

rag-hiyou-1entry-1fact 図解 5

構築に失敗した理由として思い当たることは、いくつもあります。切り方が雑だったこと、モデルの設定を触りすぎたこと、検索を後回しにしたこと。

ただ、原因を絞ると1つでした。

資料の、どこまでを1件として切り出すかを、決めていなかったことです。

さきほどの一文に戻ります。「SPCC t1.2、曲げ半径は0.5t以上、バリは0.05ミリ以下、抜きは表面側から」。人が読めば4つの事実です。ところが、この一文をひとかたまりのまま保存すると、機械にとっては1件になります。

だから「バリの上限はいくつですか」と聞かれると、曲げ半径と抜き方向がくっついて返ります。「曲げ半径はどこまでですか」と聞けば、バリの話が混ざります。検索の精度の問題ではありません。保存した単位が、質問の単位と噛み合っていないだけです。

そして、1件に収まらない量の事実を1件へ押し込むと、AIは収まるように要約します。「プレス機を数台」は、その要約結果でした。

⑤ 抽出の指示に、1行だけ足した

rag-hiyou-1entry-1fact 図解 6

直したのは1箇所です。資料から中身を拾い出すようAIに渡している指示に、次の1行を足しました。

「1項目=1事実。『150トンのプレス4台』と『300トンのプレス2台』は、別々の1件にする」。

取りこぼしを止める1行も、その隣に並べています。「全ての数値、時間、条件、名称を抽出する。『〜など』でまとめない」。

資料を探す道具は、1つも足していません。文章を意味の近さで比べられる形に変換する処理も、その置き場所になるベクトルDBも、最後まで作らないままです。つまり、検索器を1つも足さずに直っています。

割った結果、さきほどの一文は4件になりました。材質、曲げ半径、バリ、抜き方向。1件ずつ引けます。

⑥ あとで知った ── その割り方には名前がありました

rag-hiyou-1entry-1fact 図解 7

しばらくして、検索の単位そのものを扱った論文を読み、同じ考え方が示されていることを知りました。

Tong Chen ほかの「Dense X Retrieval: What Retrieval Granularity Should We Use?」です。2023年12月に、論文を公開するサイト arXiv へ投稿され(arXiv:2312.06648)、自然言語処理(人の言葉をコンピューターで扱う技術)の国際会議 EMNLP の2024年本会議に採録されています。

そこでは、何を1件として保存するかが検索の成否を分ける、と正面から書かれていました。そして、その単位に名前が付いています。命題(proposition)です。

定義はこうです。「atomic expressions within text, each encapsulating a distinct factoid and presented in a concise, self-contained natural language format」。文章の中の、それ以上割れない表現。1つの事実だけを含み、短く、それ単体で意味が通る形、という意味になります。

結果のほうは、こう書かれています。「indexing a corpus by fine-grained units such as propositions significantly outperforms passage-level units in retrieval tasks」。命題のような細かい単位で索引(質問に合うものを探すための一覧)を作ると、段落の単位を明らかに上回る、という意味です。

僕が足した1行は、この命題を作るための指示でした。新しい理屈は、ひとつも要りませんでした。

⑦ 割ってみて、何が良くなって、何を失ったか

rag-hiyou-1entry-1fact 図解 8

割ってから、技術営業の手元で変わったことがあります。聞かれた1件に、その1件だけが返るようになりました。「バリの上限はいくつですか」に、曲げ半径がくっついてきません。

ただ、代償があります。3件書いておきます。

1件目。AIが取り出す件数が、数倍になりました。 1つのかたまりが4件に割れるので、同じ資料から出てくる件数も数倍になります。人が目を通す量が、そのまま増えます。

2件目。人が承認する画面が要るようになりました。 割り方が正しいかどうかは、割った結果だけを見ても判断できません。だから、もとの文章を一字一句そのまま残し、その横に割った結果を並べて、1件ずつ承認できるようにしました。作る手間で言うと、AIに割らせる処理そのものより、人が確かめて直すための画面のほうが4倍以上かかっています。割る側が1本のプログラムで555行なのに対して、確かめる側は5本で2,454行です。中身を割った代償は、ほとんどここに出ました。

3件目。2件目で作った承認の画面に、抜けがありました。押した承認が、保存先に1件も残っていません。 承認を押すと、画面はその場で承認済みの見た目に変わります。ところが翌日に開くと、承認のボタンが全部戻っています。

原因は、承認結果を書き込む処理の順番でした。画面の見た目を切り替えた直後に「書き込んでよいか」を読み直すので、承認情報がまだ反映されていない空のデータを読みます。プログラムの判定は毎回「否」になり、保存先へは一度も書きに行っていませんでした。人が承認を押した項目は49件あるのに、承認済みとして残っていたのは0件です。人が確かめた記録は、どこにも残っていませんでした。 直したのは2026年6月22日です。

この不具合が見つかりにくかったのは、承認した直後の画面に異常が現れなかったからです。「AIが割って、人が承認して、それが残る」のうち、承認結果を保存する最後の処理だけが動いておらず、使っている技術営業からは見分けられませんでした。

⑧ 現場で構築するなら、この4つの問い

rag-hiyou-1entry-1fact 図解 9

RAGを構築する順番を確かめるとき、使っているのはこの4つだけです。

確かめること通っている通っていない
1件に、事実が1つだけ入っているか割り終わっている。次へ進んでよいここから直す。 検索器はまだ触らない
原文が一字一句そのまま横にあるか人が承認できる承認できない。割った結果だけでは正誤を判断できない
数値と条件が「〜など」に丸まっていないか抽出が効いている「全ての数値、時間、条件、名称を抽出する」の1行を、抽出の指示に足す
AIの答えが途中で切れていないか書き出せる長さが足りている一度に書き出せる長さの上限を上げる。日本語は英語の2倍から8倍のトークンを使う

4つのうち、いちばん効くのは1行目です。ここが通らないうちに検索器を足すと、検索器は正しく動いたうえで、混ざったかたまりを返します。 そして「精度が出ないので、もっと良い検索器を」という次の見積もりが始まります。

この4つの問いは、扱っている資料には依存しません。加工基準書でも、就業規則でも、保守マニュアルでも同じです。

⑨ この順番が効き続ける理由

rag-hiyou-1entry-1fact 図解 10

モデルが賢くなっても、この順番は変わらないと考えています。

モデルの賢さで解けるのは、資料を割ったあとに、質問に合う1件を選ぶ判断だからです。どこで割るのが正しいかは、その資料を使っている人にしか決められません。「曲げ半径とバリを別々に引きたい」のか、「材質ごとにまとめて見たい」のかは、聞かれ方で変わります。聞かれ方は、現場の中にしかありません。

一方で、検索器の性能は年々上がります。こちらは、待っていれば良くなる部分です。だから、人が決めるしかないほうから先に手をつけたほうが、賢くなるほど得をします。順番を逆にすると、賢くなるたびに検索器を入れ替えて、そのたびに同じ混ざったかたまりを返されます。

この整形と検索の切り分けを実際の資料に当てる話は、社内GPT・RAG構築のページに整理しています。手元の資料をどこまで割ればよいか決めかねている場合は、こちらからご相談ください。

タッパーは、いまも大きいものを使っています。透明のも、ラベルシールも、買ったままです。

今朝も、きんぴらと煮物を同じ1つに詰めました。木曜の夜に掘るのは分かっているのですが、洗い物が1つで済むので。

以上です。

You May Also Like

社内RAGが“使われない”本当の理由 ― 精度を上げても誰も使わないシステムの正体

社内GPT・RAGを作ったのに使われない――その原因は、実は検索精度ではありません。「マニュアルより、あの先輩に聞いたほうが早い」。人がそう動く理由から、使われるRAGの作り方までを、一つのプロジェクトを追いかけて書きました。
View Post

MCPとは?検索画面を作るのをやめてMCP接続にした

MCPとはModel Context Protocolの略で、AIと社内の道具やデータを繋ぐための共通の作法です。社内ナレッジを全社に開くために専用のフロントエンドを作ろうとしていましたが、初期フェーズではそれを見送り、MCP接続を主軸にする設計変更をしました。理由は画面が要らないからではありません。画面を作ると、そこに認証も権限も検索体験も全部くっついてくるからです。残したのはAPIキーの発行とフォルダごとの権限管理だけでした。何を作らないと決めたのかを書きます。
View Post

店舗DXの進め方|アプリを入れても、誰も触らなかった理由

店舗DXとは、店舗の業務や購買体験をデジタルで作り変える取り組みです。アパレル店舗に試着予約アプリを入れて、まったく使われなかったところから話を始めます。原因は機能ではなく、置いた場所の隣に店員が立っていたことでした。顧客が迷っている時間に伴走する設計へ切り替えると、同じ機能が動き出します。売場で何分迷っているかを測るところから、そのまま使えるチェックシートまで置きます。
View Post