RAG構築の手順7つ｜チャンク分割と検索精度の上げ方

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

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

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

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

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

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

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

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

この話に出てくる事業

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

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

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

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

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

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

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

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

「教科書どおりに、資料を切ってAIに項目と値へ直させた」を図解したスライド｜教科書に載っている手順は、素直です

RAG構築の基本をすでにご存じの方は、② 資料を増やしたら、返ってくる形が毎回変わったから読み進められます。

RAG（検索拡張生成）とは

RAGとは、質問が来たときに、手元の資料から関連する箇所を検索して取り出し、それを添えて生成AIに答えさせる仕組みです。Retrieval-Augmented Generation の頭文字を取っています。

やっていることを言い換えると、「知識を問う問題」を「資料を読んで答える問題」に変えているのがRAGです。モデルが覚えているかどうかに頼らず、その場で渡した資料の中から答えさせます。

RAGが必要とされる背景

生成AIをそのまま社内で使おうとすると、次の3つで止まります。

社内の固有情報を知らない — 学習データに自社の資料が入っていない
知識が古い — 学習した時点より後のことは答えられない
根拠を示せない — 合っていても、どこに書いてあったかを返せない

3つ目が、業務で使えるかどうかを分けます。社内の問い合わせに答えさせる用途では、「正しいこと」より「どの資料の何ページか」を返せることのほうが求められます。

RAGとファインチューニングの違い

	何を変えるか	知識を更新するとき	向いていること
RAG	モデルの外にある資料	資料を差し替えるだけ	社内の事実を、根拠つきで答えさせる
ファインチューニング	モデルそのもの	学習をやり直す	答え方の形式や口調をそろえる

「知識を足したい」ならRAG、「言い方を変えたい」ならファインチューニングです。社内文書を覚えさせたいという相談は、ほとんどがRAG側の話になります。

RAGの仕組み — 準備段階と利用段階

RAGは、実行の前後で2つの段階に分かれます。

段階	いつ動くか	やること
準備（インデックス作成）	事前に1回、以後は更新のたびに	資料を集め、分割し、ベクトルに変換して保存する
利用（検索と生成）	質問が来るたびに	質問をベクトルに変換し、近い断片を探し、生成AIに添えて答えさせる

構築で時間を使うのは、ほぼ準備段階です。利用段階の実装は既製の部品で組めますが、準備段階は自社の資料の形に合わせるしかありません。

RAGの構成要素

部品は5つです。どれを買い、どれを自分で作るかを先に決めてください。

データソース — 社内文書、マニュアル、FAQ、基幹システムの出力
分割の処理（チャンキング） — 資料を検索できる単位に切る
埋め込みモデル（Embedding） — 文章を数値の並びに変換する
ベクトルデータベース — 変換した結果を保存し、近いものを探す
生成AI（LLM） — 取り出した断片を読んで答えを書く

5つのうち、精度に効くのは2つ目です。埋め込みモデルやベクトルDBを高性能なものに替えても、切り方が合っていなければ、探しに行く先が変わりません。

RAG構築の手順（全体像）

	やること	終わったと言える状態
1. 要件定義とデータ戦略	誰の、どの質問に答えるかを決める	答えるべき質問が実物で並んでいる
2. データの選定とクレンジング	使う資料を決め、形を整える	対象の資料が一覧になっている
3. 分割と構造化	検索できる単位に切る	切った結果を目で見て確かめた
4. 埋め込みと格納	ベクトル化してDBに入れる	検索が動く
5. 検索とLLMの連携	取り出した断片を渡して答えさせる	回答が返る
6. 評価と改善	想定質問で正解率を測る	数字で前後を比べられる
7. 運用設計と保守	更新、権限、監視を決める	資料の更新が回る

1と3を軽く済ませると、6でやり直しになります。評価の段になって「そもそも何に答えられれば合格か」が決まっていないと、改善の方向が決められません。

手順1｜要件定義とデータ戦略

先に決めるのは技術ではなく、答えるべき質問の実物です。現場が実際に投げている質問を、20〜30件そのまま集めてください。

集めた質問は、そのまま後の評価データになります。想像で作った質問で評価すると、本番で来る質問と形が違い、「テストでは通るのに現場では外す」状態になります。

手順2｜データソースの選定とクレンジング

対象の資料を決めます。PDF、Word、社内Wiki、表計算、基幹システムからの出力。形式ごとに、取り出し方が変わります。

クレンジングで効くのは3つです。古い版を外すこと、目次やヘッダーフッターなど中身でない部分を落とすこと、同じ内容の重複を1つにまとめること。重複が残ると、検索が同じ内容を何件も返して、渡せる情報の幅が狭くなります。

手順3｜文書の分割（チャンキング）と構造化

資料を、検索できる単位に切ります。切った1件が、そのまま「検索で当たる最小の単位」になります。

大きく切りすぎると、1件の中に関係のない内容が混ざり、検索が当たっても余計な文章まで渡すことになります。小さく切りすぎると、前後の文脈が切れて、その断片だけを読んでも意味が取れなくなります。

チャンク分割の4つの方法

方法	切り方	向いている資料
文字数で切る	固定長＋前後の重なり（オーバーラップ）	形式がばらばらな文書。まず試す方法
トークン数で切る	モデルが読む単位で数える	渡せる量の上限を厳密に管理したいとき
文書の構造で切る	見出し・章・箇条書きの単位	見出しが整っているマニュアルや規程
分割専用のモデルで切る	意味のまとまりを推定させる	構造が無く、文章が続く資料

どの方法でも、メタデータを一緒に持たせてください。出典のファイル名、章の見出し、版の日付、参照してよい部署。これらを断片に付けておくと、検索の絞り込みにも、回答の根拠表示にも、権限の制御にも使えます。後から付け直すのは、作り直しと同じ手間になります。

手順4｜埋め込み（ベクトル化）とデータベースへの格納

切った断片を、埋め込みモデルで数値の並び（ベクトル）に変換し、ベクトルデータベースに保存します。ベクトルの次元数はモデルごとに決まっており、途中でモデルを替えると、全件を作り直すことになります。

日本語の資料では、日本語で評価されている埋め込みモデルを選んでください。英語で高い評価のモデルが、日本語の同義語や表記ゆれで期待どおりに動くとは限りません。

手順5｜検索と生成AIの連携

質問をベクトルに変換し、近い断片を上位から数件取り出して、生成AIに「この範囲から答えてください」と添えて渡します。

ここで決める値は2つです。何件取り出すか（上位いくつか）と、資料に無いときに何と答えさせるか。2つ目を決めていないと、資料に無いことを推測で埋めた回答が返ります。

検索の精度を上げる3つの手立て

ハイブリッド検索 — 意味の近さだけでなく、キーワードの一致も併用する。型番・法令番号・固有名詞に効く
リランキング — 検索で取り出した候補を、別のモデルで質問との関連順に並べ直す。上位に正解が来る率が上がる
質問の書き換え — 曖昧な質問を、検索に当たる形へ変換してから探す（仮の回答を作って検索するHyDEなどの手法がある）

3つとも、切り方が合っていることが前提です。当たってほしい内容が1件の中に埋もれていると、並べ直しても、書き換えても、上位に出てきません。

手順6｜評価と改善

手順1で集めた質問に対して、正しい根拠が検索で取れているかと回答が合っているかを分けて測ります。

この2つを分けないと、直す場所が決まりません。根拠が取れていないなら分割か検索の問題、根拠は取れているのに答えが違うなら渡し方かプロンプトの問題です。

手順7｜運用設計と保守

資料が更新されたときに、いつ・誰が・どうやって取り込み直すか。ここを決めていないRAGは、半年で古い答えを返す仕組みになります。

あわせて、回答に低い評価が付いた質問を集める仕組みを最初から入れてください。改善の材料は、運用の中でしか集まりません。

RAG構築のメリット1｜根拠つきで答えられる

取り出した断片をそのまま示せるため、「どの資料の、どこに書いてあるか」を回答に添えられます。確認できる回答は、確認できない回答よりも業務で使えます。

根拠の表示は、後から足すと作り直しになります。出典のメタデータを断片に持たせるかどうかは、分割の段階で決まるためです。

RAG構築のメリット2｜知識の更新に再学習が要らない

資料を差し替えて取り込み直せば、答える内容が変わります。モデルを学習し直す必要がありません。

更新の速さは、運用の設計次第です。取り込み直しが手作業だと、更新は結局止まります。自動で取り込む経路を、構築時に用意しておいてください。

RAG構築のメリット3｜問い合わせ対応の工数が減る

社内からの繰り返しの質問に、その場で回答が返ります。答えていた担当者の時間が空きます。

効果を測るなら、回答した件数ではなく「担当者へ回ってきた件数」で見てください。回答件数は導入直後に必ず増えますが、担当者への転送が減っていなければ、工数は減っていません。

落とし穴1｜チャンクの大きさが合っていない

もっとも多い詰まりです。大きすぎると余計な内容が混ざり、小さすぎると意味が取れません。

数字を先に決めず、切った結果を目で見てください。20件ほど印刷して読み、「この1件だけを読んで、質問に答えられるか」を確かめると、合っているかどうかがすぐ分かります。

落とし穴2｜類似検索だけでは届かない質問がある

「AとBの違いは」「一覧で出して」「例外はあるか」といった質問は、1つの断片の中に答えが無いため、意味の近さだけでは取れません。

対策は、ハイブリッド検索とリランキングの併用、そしてそもそもそういう質問に答える必要があるかを要件定義で決めておくことです。全部の質問に1つの仕組みで答えようとすると、どれも中途半端になります。

落とし穴3｜利用部門と作る側で、期待がずれる

作る側は検索の精度を見ていますが、利用部門は「自分がいつも聞いていることに答えられるか」を見ています。

ずれを防ぐのは、手順1で集める実物の質問です。現場の質問をそのまま評価データにしておくと、見せるときも同じ質問で見せられます。

アクセス権限とセキュリティ

全員に同じ資料を見せてよいとは限りません。人事、給与、原価、未公表の情報。断片にアクセス範囲のメタデータを持たせ、検索の段階で絞ります。

回答の段階で隠す方式にしないでください。生成AIに渡してから隠す形だと、渡した時点で情報が外に出ています。取り出す前に絞るのが原則です。

必要なデータ量・体制と、自社開発か外部委託か

データ量は多ければよいというものではありません。答えるべき質問に対応する記述が揃っているかが条件で、対象を絞れば少量でも成立します。

	向いているとき	注意
自社開発	対象の資料と業務を、社内が一番よく分かっている	埋め込み・検索・評価の知見が要る
外部委託	立ち上げを早くしたい	資料の中身の判断は外に出せない。「どこまでを1件とするか」は自社で決めることになる

委託する場合でも、評価用の質問リストは自社で作ってください。これが無いと、納品されたものが良いのかどうかを判定できません。

RAGの活用事例（どんな用途で使われているか）

社内ナレッジ検索 — 規程・マニュアル・過去の議事録を横断して探す
問い合わせ対応の一次回答 — 情シスや総務への繰り返しの質問
技術資料の参照 — 仕様書・基準書から条件を引く
属人化の解消 — 特定の人しか知らない手順を、資料から引けるようにする

どの用途でも、成否を分けるのは資料の側です。検索の道具を選ぶ前に、その資料が「探される形」になっているかを見てください。この記事の後半は、そこの話です。

RAG構築のよくある質問

Q. RAGの構築には、どのくらいのデータ量が必要ですか。
量より、答えるべき質問に対応する記述が揃っているかです。対象を1つの業務に絞れば、数十ファイルでも成立します。逆に、量があっても古い版と重複が混ざっていると精度は下がります。

Q. RAGとファインチューニングは、何が違いますか。
RAGはモデルの外にある資料を差し替えて知識を更新し、ファインチューニングはモデルそのものを学習し直します。社内の事実を根拠つきで答えさせたいならRAGです。

Q. 精度が上がりません。どこから直せばよいですか。
「正しい根拠が検索で取れているか」と「回答が合っているか」を分けて測ってください。根拠が取れていないなら分割か検索、根拠は取れているのに答えが違うなら渡し方の問題です。

Q. チャンクの大きさは、どのくらいが適切ですか。
資料によって変わるため、数字だけでは決まりません。切った結果を20件ほど読み、「この1件だけで質問に答えられるか」で判断してください。

Q. 社外に見せられない資料も扱えますか。
扱えます。ただし断片にアクセス範囲を持たせ、検索の段階で絞るのが原則です。生成AIへ渡してから隠す方式は、渡した時点で外に出ています。

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

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

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

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

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

ここまでが、RAG構築の教科書どおりの整理です。資料を集め、切って、ベクトルにして、探して、渡す。手順としては、これで揃っています。

この記事の後半で扱うのは、この手順どおりに構築したRAGで、資料を増やしていったときに何を直し続けることになったかです。直した回数を数えたら、直していた場所が偏っていました。

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

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

ここでいう「形」とは、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回を並べたら、答えの中身をほとんど触っていなかった

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

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

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

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

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

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

④ 原因を1つに絞る

「原因を1つに絞る」を図解したスライド｜構築に失敗した理由として思い当たることは、いくつもあります

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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行は、この命題を作るための指示でした。新しい理屈は、ひとつも要りませんでした。

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

「割ってみて、何が良くなって、何を失ったか」を図解したスライド｜割ってから、技術営業の手元で変わったことがあります

割ってから、技術営業の手元で変わったことがあります。聞かれた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を構築する順番を確かめるとき、使っているのはこの4つだけです。

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

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

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

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

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

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

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

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

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

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

以上です。

RAG構築のよくある質問（まとめ）

RAGの構築には、どのくらいのデータ量が必要ですか？

量そのものより、答えるべき質問に対応する記述が資料の中に揃っているかが条件です。対象を1つの業務に絞れば数十ファイルでも成立します。逆に、量があっても古い版と重複が混ざっていると、検索が同じ内容を何件も返して精度が下がります。まず現場が実際に投げている質問を20〜30件集め、それに答えられる資料だけを対象にしてください。

RAGとファインチューニングは、何が違いますか？

RAGはモデルの外にある資料を検索して添えるため、資料を差し替えるだけで知識を更新できます。ファインチューニングはモデルそのものを学習し直すので、更新のたびに学習をやり直します。社内の事実を根拠つきで答えさせたいならRAG、答え方の形式や口調をそろえたいならファインチューニングです。

RAGの精度が上がりません。どこから直せばよいですか？

「正しい根拠が検索で取れているか」と「回答が合っているか」を分けて測ってください。根拠が取れていないなら分割（チャンキング）か検索の問題で、ハイブリッド検索やリランキングが効きます。根拠は取れているのに答えが違うなら、渡し方やプロンプトの問題です。この2つを分けないと直す場所が決まりません。

RAGのチャンク（分割）の大きさは、どのくらいが適切ですか？

資料によって変わるため、数字だけでは決まりません。切った結果を20件ほど読み、「この1件だけを読んで質問に答えられるか」で判断してください。大きすぎると1件の中に関係のない内容が混ざり、小さすぎると前後の文脈が切れて意味が取れなくなります。あわせて出典・見出し・版の日付などのメタデータを断片に持たせておくと、絞り込みと根拠表示の両方に使えます。