「生成AIを入れろと言われたが、自社のマニュアルや過去のトラブル報告を読ませたい」。タイやベトナムの日系工場から、この相談が増えています。そのための仕組みがRAG構築です。ただし最初にお伝えしたいことがあります。対象の文書が数十ファイルしかないなら、RAGは作らないほうが速く、安く済みます。本記事では、そもそも作るべきかの判定から、費用の内訳、日本語の技術文書をタイ語で検索させる設計、そして失敗しやすい落とし穴までを、工場の実務に沿って整理します。
RAG構築を始める前に、そもそも作らずに済まないかを確かめる
最初に、多くの記事が書かない話から始めます。RAGは、作らないで済むなら作らないほうがよい仕組みです。
LLMを開発しているAnthropicは、自社の技術解説のなかで明確な基準を示しています（global）。ナレッジベースが20万トークン、資料にして約500ページ程度より小さいのであれば、検索システムを組まずに、ナレッジベース全体をプロンプトに入れてしまえばよい、という基準です。プロンプトキャッシュという仕組みを併用すれば、そのほうが応答が速く、費用も安く、複雑な検索の作り込みが不要になる、と説明されています。
20万トークンを約500ページで割ると、1ページあたり約400トークンという換算になります。手元のマニュアルを思い浮かべてください。A4で50ページの設備取扱説明書が10冊あって、ようやくこの水準です。つまり「作業標準書を10本だけ引けるようにしたい」「品質規程のPDFが30ファイルある」という段階なら、RAG構築という重い投資に踏み込む前に、まずは対象文書をまとめてLLMに読ませる方式で試すほうが合理的です。
ひとつ注意点があります。トークン数は言語によって効率が変わり、一般に日本語やタイ語は英語より同じ内容でもトークンを多く消費しやすい傾向があります。500ページという目安は英語の資料を前提とした概算と考え、日本語やタイ語の文書では余裕を持って見積もってください。厳密に判断したい場合は、実際の文書をトークン数え上げのツールにかけて実測するのが確実です。
RAGが必要になる3つの条件
では、どういうときにRAG構築が必要になるのか。判定は次の3条件で足ります。ひとつでも当てはまるなら、検索を組む価値があります。
- 文書量が閾値を超えている。上記の目安を大きく超え、対象が数百ファイル、数千ページの規模になっている場合。プロンプトに入りきらないため、必要な部分だけを取り出す仕組みが要ります。
- 文書の更新頻度が高い。作業標準書が毎月改訂される、トラブル報告が毎週増える、という状態では、文書を差し替えるだけで回答が変わる仕組みが必要です。
- アクセス権限の出し分けが必要。品質部門しか見てはいけない検査記録、購買しか見られない単価表がある場合、質問者ごとに参照範囲を変える必要があります。これは検索層でしか実装できません。
3番目は見落とされがちですが、実務上いちばん重い条件です。全社員が同じ文書を見てよい環境なら設計は単純ですが、日系工場では「日本人駐在員は見られるがローカルスタッフには非公開」という文書が現実に存在します。この出し分けが要るかどうかで、後述する費用は大きく変わります。
なお、生成AI導入そのものの全体像、対象業務の選び方や社内体制の作り方については、生成AI導入の進め方と費用で横断的に整理しています。本記事はその中の「自社データをLLMに繋ぐ層」を掘り下げた内容です。
RAGとは何か：検索・文脈付与・生成の3段で理解する
RAGとは Retrieval-Augmented Generation の略で、日本語では「検索で補強した生成」と訳されます。仕組みは3段しかありません。
第1段は検索です。 利用者の質問を受け取り、社内文書のなかから関連しそうな部分を探します。ここでは文書はあらかじめ適度な長さの断片、いわゆるチャンクに分割され、意味の近さを数値で表した埋め込みベクトルとして保存されています。質問も同じ方式でベクトル化し、近いものを上位から取り出します。
第2段は文脈付与です。 取り出した断片を、質問と一緒にLLMへ渡します。「この資料を参照して、次の質問に答えてください」という形です。
第3段は生成です。 LLMが渡された資料の範囲で回答を組み立て、どの文書のどこを根拠にしたかを添えて返します。
重要なのは、この方式ではLLMが社内文書を「覚えている」わけではないという点です。毎回その場で参照しているだけです。だから文書を直せば回答も直ります。改訂した作業標準書を差し替えれば、翌日から新しい手順で答えるようになります。
ファインチューニングとの違い
「LLMに社内データを学習させる」と聞くと、ファインチューニングを思い浮かべる方もいます。3つの方式を整理すると次のようになります。
| 方式 | 何をするか | 文書を更新したとき | 向いている用途 |
|---|---|---|---|
| プロンプトに全文投入 | 文書をそのまま毎回渡す | 渡す文書を差し替えるだけ | 文書量が小さく、更新も権限分けも単純な場合 |
| RAG構築 | 検索して関連部分だけ渡す | 元文書を差し替えれば反映される | 文書量が多い、更新が頻繁、権限の出し分けが要る |
| ファインチューニング | モデル自体を追加学習させる | 学習をやり直す必要がある | 回答の文体や形式を固定したい場合 |
社内マニュアルの検索という目的に対しては、ファインチューニングは相性がよくありません。事実を覚えさせる手段としては更新コストが高く、しかも「どの文書を根拠にしたか」を示せなくなるためです。工場の現場では根拠の提示が欠かせないので、事実の参照はRAG、文体の統一はプロンプトの指示、という役割分担が実務的です。
工場でRAGが効く業務と、効かない業務
RAG構築の失敗でよくあるのが、そもそも向いていない業務に当ててしまうケースです。境界をはっきりさせておきます。
効く業務（文書に答えが書いてある領域）
- 設備保全マニュアルの検索。「この型番の充填機でアラームE042が出たときの初動」を、複数冊の取扱説明書を横断して探す用途。
- 過去トラブル・不具合報告の横断検索。同じ不良が過去にどう処置されたかを、年度をまたいで探す用途。属人化した知見の掘り起こしに効きます。
- 作業標準書・社内規程の問い合わせ。「有給の申請期限」「工具の持ち出し手順」といった、規程を読めば分かるが誰も読まない類の質問。
- 部品・図面の仕様確認。材質、公差、代替品の可否など、仕様書に記載のある情報の確認。
- 顧客からの技術問い合わせの一次回答案作成。過去の回答実績と仕様書をもとに、担当者が確認して送る前の下書きを作る用途。
効かない業務（数値と現在値の領域）
- 生産実績や在庫数の集計。「先月のライン別稼働率」「現在の部品在庫」は、文書ではなくデータベースの数値です。これはBIツールや生産管理システムの領分で、RAGに聞かせると誤った数字を返す原因になります。数値の集計は、集計する仕組みの側で解くのが筋です。
- リアルタイムの設備状態。「3号機は今動いているか」はIoTによる稼働監視の仕事です。設備からの信号取得と可視化については工場IoT稼働監視の導入で解説しています。
- 承認や記録そのもの。日報の提出、点検記録の保存はワークフローの仕事です。紙の帳票が残っている場合は、電子帳票によるペーパーレス化を先に進めるほうが順序として正しくなります。
線引きの原則はひとつです。答えが文章として文書に書いてあるならRAG、答えが数値としてシステムに入っているならBIや基幹システム。この切り分けを最初にしておかないと、「AIなのに在庫数も答えられないのか」という評価につながります。
RAG構築の費用は5層に分けて見積もる
ここからが本記事の中核です。RAG構築の費用は、一括の見積書として眺めても判断できません。次の5層に分けて見ると、自社でどこが膨らむかが見えます。
| 層 | 内容 | 工場での重さ |
|---|---|---|
| 第1層 | 文書の電子化・前処理（紙、スキャンPDF、図面、Excel） | 最も重くなりやすい |
| 第2層 | 検索基盤（ベクトルDB、埋め込み、インデックス作成） | 比較的軽い |
| 第3層 | アプリ・UI（チャット画面、Teamsや社内ポータルへの組み込み） | 中程度 |
| 第4層 | 既存システム連携とアクセス権限設計 | 重い。見落とされやすい |
| 第5層 | 運用（LLM利用料、文書更新の反映、精度改善の社内工数） | 継続的に発生 |
第1層が工場では最大になる理由
一般的なRAGの解説記事は、第2層のベクトルDBや埋め込みの話から始まります。しかし工場の現実は違います。参照したい文書が、そもそも検索できる形になっていないのです。
保全マニュアルは製造メーカーから受け取った紙のバインダー。図面はスキャンしたPDFで、中身は画像であり文字として認識されていない。過去のトラブル報告はExcelのセルに長文が押し込まれ、写真が貼り付けられている。品質記録は手書きの帳票をスキャンしたもの。この状態からスタートする工場は珍しくありません。
RAGは文字を検索する仕組みなので、画像のままのPDFは検索対象になりません。ここでOCRによる文字起こしが必要になります。日本語とタイ語が混在した手書き帳票の読み取り精度をどう確保するかは、それ自体が別のプロジェクトになる規模の話です。この前工程についてはAI-OCRによるバックオフィス自動化で扱っています。
文字起こしが終わっても、まだ前処理は続きます。同じ設備の取扱説明書が3世代分あって、どれが現行かが分からない。改訂履歴が本文に埋め込まれていて、旧手順と新手順が同じファイルに同居している。こうした整理は、外注先には判断できません。どれが有効な文書かを決められるのは自社の担当者だけだからです。
日本国内の費用相場（Japan-specific）
日本国内のRAG構築費用について、公開されている相場は次のとおりです。以下はすべて日本国内の事例に基づく数値です。
| 区分 | 金額 | 期間 |
|---|---|---|
| PoC（実証） | 100〜300万円 | 2〜6週間 |
| 本番構築 | 300〜1,000万円 | 2〜4か月 |
| 月額運用 | 10〜50万円 | 継続 |
さらに費目別の内訳も公開されています（Japan-specific）。ここで注目していただきたいのは、明示された3費目を足しても総額に届かないという点です。
| 費目 | PoC | 本番構築 | 対応する層 |
|---|---|---|---|
| データ整備 | 30〜50万円 | 100〜150万円 | 第1層 |
| ベクトルDB | 10万円 | 60万円 | 第2層 |
| UI・チャット画面 | 20〜50万円 | 50〜200万円 | 第3層 |
| 上記3費目の小計 | 60〜110万円 | 210〜410万円 | 第1〜3層 |
| 総額との差 | 40〜190万円 | 90〜590万円 | 第4層と要件定義・PM |
小計は、PoCが下限30＋10＋20で60万円、上限50＋10＋50で110万円。本番が下限100＋60＋50で210万円、上限150＋60＋200で410万円です。総額のPoC100〜300万円、本番300〜1,000万円と突き合わせると、差額はPoCで40〜190万円、本番で90〜590万円になります。ここは下限どうし・上限どうしを突き合わせた計算です。総額が下限に近く、かつ各費目が上限に近い案件では、この差額はほとんど残りません。
この差額の中身を出典は費目として分解していませんが、入るとすれば要件定義、プロジェクト管理、そして第4層の既存システム連携とアクセス権限設計でしょう。本番構築では、上限側で見れば総額の半分以上がここに乗る計算になります。ベクトルDBが60万円で、権限設計と連携がそれ以上、という構造を頭に入れておいてください。
海外の費用相場（global）
海外のRAG開発費用の相場も見ておきます。以下はグローバル市場の水準で、米ドル建てです。出典に為替レートの記載がないため、円換算はしていません。
| 区分 | 金額 |
|---|---|
| 単純なRAG | 15,000〜25,000米ドル |
| 本番RAG | 40,000〜80,000米ドル |
| オンプレミスのエンタープライズRAG | 80,000〜150,000米ドル以上 |
両端で割ってみます。本番RAGは単純なRAGの2.7〜3.2倍（下限どうしで40,000÷15,000＝約2.7倍、上限どうしで80,000÷25,000＝3.2倍）。オンプレミスのエンタープライズRAGは本番RAGのさらに、下限どうしで2.0倍、上限どうしで約1.9倍（80,000÷40,000＝2.0倍、150,000÷80,000＝約1.9倍）です。ただしオンプレミス帯は出典が「150,000米ドル以上」と上限を開けているため、実際の倍率はこれより大きくなり得ます。
そしてこの出典も、最大のコスト要因はLLMそのものではなく、アクセス制御層、既存システム連携、コンプライアンス対応だと明言しています。日本国内の内訳から読み取れる構造と一致します。LLMのAPI利用料を心配するより先に、権限設計に予算を置くべきだということです。
稟議書には第1〜4層を投資額、第5層を年間運用費として書く
社内で予算を通すときの書き方を決めておきます。層分けをした意味は、ここで効きます。
- 投資額（初期費用）＝第1層＋第2層＋第3層＋第4層（要件定義・PMを含む）。文書の電子化、検索基盤、UI、連携と権限設計まで。
- 年間運用費＝第5層のみ。LLM利用料、文書更新の反映作業、精度改善にかかる社内工数。
この定義を混ぜると稟議が崩れます。よくある事故が、投資額に月額運用費の初年度分を含めておきながら、ROIの計算では運用費を別途引く、という二重計上です。
日本国内の公開事例で確認します（Japan-specific）。従業員300名の企業が情報システム部門のFAQを対象にした例では、PoCが100万円で2週間、本番構築が600万円で3か月、月額運用が約20万円でした。この定義に当てはめると次のようになります。
- 投資額（第1〜4層）＝ PoC 100万円 ＋ 本番 600万円 ＝ 700万円
- 年間運用費（第5層）＝ 20万円 × 12か月 ＝ 240万円
- 3年間の総保有コスト ＝ 700万円 ＋ 240万円 × 3年 ＝ 1,420万円
- 5年間の総保有コスト ＝ 700万円 ＋ 240万円 × 5年 ＝ 1,900万円
回収年数の式は、投資額 ÷（年間削減額 − 年間運用費）です。この例なら 700万円 ÷（年間削減額 − 240万円）になります。ここで大事なのは、年間削減額が240万円を下回った瞬間、回収年数の計算そのものが成立しなくなるという点です。投資の回収以前に、運用費だけで赤字になります。
仮に年間削減額を480万円と置いた場合、700 ÷（480 − 240）＝ 約2.9年で回収という計算になります。ただしこの480万円は出典のある数値ではなく、式の形を示すために置いた仮の値です。自社で稟議を書くときは、対象業務の検索にかかっている時間を実測し、この欄を自社の数字で埋めてください。実測に基づかない削減額は、稟議のレビューで崩れます。
なお、月額10〜50万円という日本国内の相場に、文書更新や精度改善の社内工数が含まれているかは出典に明記がありません。第5層には社内の人件費が乗ることを前提に、担当者の稼働を別途見込んでおくのが安全です。
「精度が出ない」の正体は検索側にある
PoCが終わったあと、いちばん多い評価が「思ったほど賢くない」です。原因を切り分けると、その大半は生成側ではなく検索側にあります。LLMは渡された資料の範囲でしか答えられないので、そもそも正しい資料が渡っていなければ、どれだけ高性能なモデルでも正答しません。
Contextual Retrieval、BM25併用、リランキングの3段
検索側の改善について、Anthropicが公開している実測値があります（global）。いずれもベースラインは「埋め込みのみの従来型RAG」で、上位20チャンクを取り出したときの検索失敗率を比較したものです。
| 手法 | 検索失敗率 | ベースラインからの削減 |
|---|---|---|
| ベースライン（埋め込みのみのRAG） | 5.7% | — |
| Contextual Embeddings | 3.7% | 35%削減 |
| Contextual Embeddings ＋ Contextual BM25 | 2.9% | 49%削減 |
| さらにリランキングを追加 | 1.9% | 67%削減 |
計算を確認しておきます。5.7%が3.7%になれば 1 − 3.7 ÷ 5.7 ＝ 約35%の削減。2.9%なら 1 − 2.9 ÷ 5.7 ＝ 約49%の削減。1.9%なら 1 − 1.9 ÷ 5.7 ＝ 約67%の削減です。
ここは読み違えの多い箇所です。これは検索の失敗率が67%減ったという意味であり、回答の精度が67%上がったという意味ではありません。失敗率は5.7%から1.9%へ、3.8ポイント下がっただけとも言えます。ベンダーの提案書に「精度が67%向上」と書かれていたら、何をベースラインに何を測ったのかを確認してください。
3つの手法を実務の言葉に置き換えると、次のようになります。
- Contextual Embeddingsは、各チャンクに「この断片は何の文書のどの文脈か」という短い説明を付けてから埋め込む手法です。「圧力を0.3MPaに調整する」という断片だけでは何の設備か分かりませんが、「充填機Bの日常点検手順のうち圧力調整の項」という文脈が付けば引けるようになります。
- BM25の併用は、意味の近さによる検索に、従来型のキーワード一致検索を組み合わせる手法です。型番や品番のような、意味では引けないが文字列としては一致する語に効きます。工場の文書ではこれが重要です。
- リランキングは、いったん多めに取り出した候補を、別のモデルで質問との関連度順に並べ直す工程です。
チャンク分割の失敗例
工場の文書で頻発する分割の事故を挙げておきます。
- 表が途中で切れる。仕様一覧表がチャンク境界で分断され、ヘッダー行と数値行が別々の断片になる。結果、数値だけが取り出されて何の項目か分からなくなります。
- 図面の注記が本文から分離する。「※材質変更は品証承認要」といった注記が、対象の図から切り離されて保存される。
- 改訂履歴が本文に混ざる。旧手順の記述が現行手順として取り出される。これは前処理で旧版を除外していないことが原因です。
- 見出しの階層が失われる。「4.2 異常時の処置」という見出しが本文と切り離され、どの章の処置なのか分からなくなる。
対策は、機械的な文字数での分割をやめ、見出し構造や表の単位で区切ることです。そのうえで、表はチャンク内に丸ごと収めるか、行ごとにヘッダーを複製して保持します。
「答えられない」と言わせる設計
現場で信頼される仕組みにするために、次の3点を最初に決めてください。
- 根拠文書へのリンクを常に返す。回答の下に、参照した文書名とページを表示し、原文を開けるようにします。回答が正しいかを人が確認できることが、現場での採用可否を分けます。
- 該当文書が見つからないときは、推測させずに「該当する記載が見つかりませんでした」と返す。これは指示文の設計と、検索スコアの下限を決めることで実装します。もっともらしい嘘を返す仕組みは、一度でも現場に出ると信頼を失います。
- 回答の断定度を業務に合わせる。安全に関わる手順では、回答に加えて「作業前に原本を確認してください」という定型文を添える設計にします。
日本語のマニュアルをタイ語で検索させる設計
タイやベトナムの工場に特有で、他社の解説記事がほとんど扱わない論点がここです。技術文書は日本語または英語、質問する作業者はタイ語・ベトナム語・ミャンマー語、という言語のねじれをどう設計するか。
翻訳をどの層で行うか、3案の比較
方式は3つあります。
| 案 | 仕組み | 初期費用 | 更新の手間 | 精度の傾向 |
|---|---|---|---|---|
| 案1 文書を翻訳して二重に持つ | 日本語文書をタイ語に翻訳し、両方をインデックス化 | 高い。翻訳量に比例 | 重い。原本改訂のたびに再翻訳と再インデックス | 訳が正しければ最も安定。訳の品質に依存 |
| 案2 質問を翻訳して検索 | タイ語の質問を日本語に機械翻訳してから検索 | 低い | 軽い。文書は原本のまま | 質問文の翻訳品質に左右される。専門用語で崩れやすい |
| 案3 多言語埋め込みで直接検索 | 言語をまたいで意味を近づける埋め込みモデルで直接照合 | 中程度 | 軽い。文書は原本のまま | 一般語には強い。型番や社内固有語には弱い |
現実的な解は、この3案から1つを選ぶのではなく組み合わせることです。基本は案2と案3の併用、つまり質問を日本語にも翻訳したうえで、多言語埋め込みによる直接検索と並行して候補を集め、リランキングで統合します。そのうえで、安全教育資料や緊急時対応手順など、誤読が事故に直結する文書に限って案1で正式なタイ語版を持つ。全文書を翻訳して二重管理する方式は、初期費用も更新の手間も文書量に比例して増えるため、対象を絞る判断が要ります。
タイ語には単語の区切りがない
検索の設計で見落とされるのが、タイ語の書記法です。タイ語は単語と単語の間に空白を置きません。文がつながった文字列として書かれるため、キーワード検索を行うには、まず単語の境界を推定する分かち書き、いわゆる word segmentation の処理が必要になります。
日本語も同様に空白で区切りませんが、日本語向けの形態素解析は検索製品に組み込まれていることが多いのに対し、タイ語の分かち書きに対応した検索設定は、既定のままでは有効になっていない場合があります。前節で触れたBM25のようなキーワード一致検索を併用するとき、タイ語側の分かち書きが機能していないと、タイ語の検索だけが極端に当たらないという状態になります。多言語で使う仕組みでは、言語ごとに検索の効きを個別に評価してください。日本語で試して「よく動く」と判断し、タイ語では試していない、という進め方が典型的な失敗です。
ベトナム語には空白がありますが、これは単語ではなく音節の区切りです。たとえば máy nén khí（エアコンプレッサー）は3音節で1語です。空白で区切る既定のトークナイザーをそのまま使うと語が分解され、キーワード検索が意図どおりに効きません。複合語の辞書を持たせるか、N-gramで補うかの判断が要ります。さらに、声調記号を含む表記のゆれと、記号を省いた入力が混在します。表記の正規化を前処理に入れておくと安定します。
型番・略語・固有名詞は翻訳させない
多言語化でもっとも壊れやすいのがここです。機械翻訳をそのまま通すと、設備の型番や社内の略語まで訳されてしまうことがあります。型番が訳されると、その文字列はもうインデックス上のどの語とも一致しません。
対策は、翻訳の対象外にする語のリストを作ることです。設備型番、品番、図番、社内システム名、部署の略称、規格名。この用語集は自社で作るしかありませんが、一度作れば翻訳、検索、回答生成のすべてで使い回せます。RAG構築のなかで、費用対効果がもっとも分かりやすい作業のひとつです。
回答は質問者の言語で、根拠は原語のリンクで
運用の型として推奨しているのは次の形です。
- 回答本文は、質問された言語で返す。タイ語で聞かれたらタイ語で答える。
- 根拠文書は、翻訳せず原語のまま、リンクとして示す。日本語の保全マニュアルなら日本語のPDFへのリンクを表示する。
- 該当箇所の引用は、原文と訳を並べて出す。訳だけを出すと、現場で原本と突き合わせたときに確認できません。
こうしておくと、作業者は自分の言語で概要をつかみ、疑問があれば原本にあたれます。日本人の管理者が同じ画面を見たときにも、どの文書のどこを見て答えたのかが分かります。多言語チャットボットとして運用する際、この「原語リンクを残す」設計が、翻訳の誤りが事故につながる経路を断つ実務的な手当てになります。
タイでRAGを構築するときの制度とデータの論点
タイ国内でRAGを構築する場合の前提を整理します（Thailand-specific）。
タイの法的な土台はPDPA、AI法は草案段階
タイは2026年時点で、単独のAI法をまだ施行していません。ETDA（電子取引開発機構）が過去の草案をリスクベースの単一のAI枠組みに統合する作業を進めており、禁止リスクや高リスクの分類、影響評価の義務化、自動意思決定への規制強化が想定されています。ただし現時点では成立しておらず、成立済みとして社内資料に書かないでください。
したがって、現時点で遵守の土台になるのは PDPA（個人情報保護法） です。RAG構築の文脈では、ナレッジベースに個人データが混入していないかが論点になります。今後AIの枠組みが整備されれば追加の義務が生じ得るため、設計時点で「どの文書を、どこに、誰の権限で保存しているか」を説明できる状態にしておくと、制度変更への対応が軽くなります。制度の細部と自社への適用可否は、所管当局または現地の専門家に書面で確認してください。
人事・健康・給与の文書はナレッジに混ぜない
実務上の切り分けとして、次の文書はRAGの対象から外すことを既定にしてください。
- 従業員の人事評価、異動、懲戒に関する記録
- 健康診断結果、医療関連の記録
- 給与、賞与、個人の労働時間の明細
- 採用応募者の履歴書、面接記録
これらは検索できると便利に見えますが、いったんインデックスに入れると、権限設計の失敗が即座に個人データの漏えいになります。「便利そうだから全部入れる」が最も危険な判断です。どうしても対象にしたい場合は、別のインデックスとして完全に分離し、参照できる担当者を限定した別システムとして構築してください。
データの保存先リージョン
日系工場では、本社IT方針が「データは日本国内または特定リージョンに保管すること」と定めている一方、現地では別の要件が課されることがあります。RAGでは、文書の原本、抽出したテキスト、埋め込みベクトル、そして質問と回答のログという4種類のデータがそれぞれどこに置かれるかを個別に確認する必要があります。LLMのAPIリージョンだけを確認して済ませないでください。 ベクトルDBとログの保存先が別リージョンになっている構成は珍しくありません。
タイの現在地を示す数値
タイ企業のデジタル化の水準について、参考になる調査があります（Thailand-specific）。Thailand Digital Outlook 2026 調査（全国の事業者834社が対象）では、事業者のデジタル成熟度の平均が4点満点で2.12となり、初めて「中位」に到達しました。2025年の1.56からの上昇で、上げ幅は0.56ポイント、伸び率にして約36%です。ただし4点満点の2.12は、達成度でいえば約53%にとどまります。弱い領域として挙げられているのは、デジタル製品・サービスの開発とR&Dです。
一方、AIを実際に業務へ組み込んでいるタイ企業は約18%にとどまるという調査結果もあります（ETDAの調査ベース、Thailand-specific）。裏を返せば、8割強はまだ組み込んでいません。
さらに、製造業の組織の約65%が「データ品質への懸念」をAI導入の大きな障壁として挙げています（Thailand-specific）。これは本記事の第1層、つまり文書の電子化・前処理が最大のコストになるという指摘と、同じ現実を別の角度から示した数字です。データが整っていないという認識自体は、すでに現場に共有されています。
ベトナムでRAGを構築するときの制度とデータの論点
ベトナムはタイと状況が異なります（Vietnam-specific）。
ベトナムのAI法は2026年3月に施行済み
ベトナム国会は2025年12月に東南アジアで初となる単独のAI法を可決し、2026年3月に施行しました。リスク分類、説明責任、高影響AIシステムに対するガバナンス義務が導入されています。
RAG構築との関係で押さえるべきは、自社の用途がどのリスク区分に当たるかという判断です。社内マニュアルの検索補助であれば影響は限定的と考えられますが、その回答が人事評価や採用の判断に使われる、あるいは安全に直結する作業指示として使われる場合、扱いは変わり得ます。法令番号や具体的な手続き、優遇措置の有無については、所管当局または現地の専門家に書面で確認してください。 本記事では制度の細部には踏み込みません。
説明責任の義務があるということは、「どの文書を根拠に、どのモデルが、いつ、その回答を出したか」を記録として残せる構成が求められる可能性があるということです。前述した「根拠文書へのリンクを常に返す」設計は、現場の信頼を得るためだけでなく、この観点からも合理的です。
ベトナム企業の93%が導入・検討、全社展開は13.8%
Deloitteの調査によると、ベトナム企業の93%がAIを導入または検討しており、これは東南アジアで最も高い水準です。一方で、全社規模で展開できているのは13.8%にとどまります（いずれもVietnam-specific）。
この2つの数字の差が79.2ポイントあること、そして導入・検討している企業のうち全社展開に到達したのは 13.8 ÷ 93 ＝ 約15%にすぎないことが、実態を表しています。PoC止まりが常態なのです。
なぜPoCで止まるのか。本記事の費用構造に戻ると理由が見えます。PoCで作るのは第1層から第3層の一部、つまり少数の文書を整えてチャット画面を付けたところまでです。全社展開の壁は第4層、既存システム連携とアクセス権限設計にあります。ここは部門ごとの権限を棚卸しし、人事異動に追随する仕組みを作る必要があり、技術というより組織の作業です。PoCの予算感で全社展開に進もうとすると、この層で止まります。
RAG構築が失敗する6パターン
これまでの内容を、失敗の型として6つにまとめます。
- 文書を整理しないまま全部入れる。旧版と現行版が混在したまま投入し、旧手順が回答されて信頼を失う。対策は、対象文書の棚卸しと版管理を第1層の作業として工数に計上することです。
- アクセス権限の設計を後回しにする。PoCでは全員が全文書を見られる設定で作り、本番で権限を入れようとして作り直しになる。費用の内訳から分かるとおり、権限設計は最も重い層のひとつです。最初から設計に含めてください。
- PoCの評価基準がない。「使ってみた感想」で判定しようとすると、意見が分かれて結論が出ません。後述する評価データを先に作ることで解決します。
- 文書更新の担当者を決めていない。稼働から半年で文書が古くなり、誰も直さないまま回答の質が落ちる。第5層に文書更新の工数を明記し、担当部署を決めてから稼働してください。
- 「AIが間違えた」で検討が止まる。RAGは正答率100%の仕組みではありません。重要なのは、間違いが起きたときに原因を検索側と生成側に切り分け、チャンク分割や検索手法を直せる体制があるかです。1回の誤答で全体を止めるのではなく、誤答を記録して改善に回す運用を最初に決めておきます。
- 内製と外注の線引きが曖昧。「全部お任せ」でも「全部自社で」でもうまくいきません。次章で線引きを示します。
内製と外注の線引きと、ベンダーに投げる8つの質問
自社にしかできないこと
- 対象文書の選定と版の確定。どれが現行手順かを判断できるのは現場だけです。
- 評価データの作成。実際に現場から出る質問と、その正解にあたる文書箇所の対応表。これも自社の知識がないと作れません。
- アクセス権限の方針決定。誰にどこまで見せるかは、経営と人事の判断です。
- 用語集の整備。翻訳させない型番・略語のリスト。
外注に向くこと
- 検索基盤の構築（ベクトルDB、埋め込み、インデックス設計）
- 権限制御の実装（方針は自社、実装は外部）
- 既存システムとの連携（生産管理システム、文書管理システム、認証基盤）
- チャンク分割の設計と検索手法のチューニング
- OCRを含む電子化工程の実行
タイ国内でのベンダー選定については、タイのシステム開発会社の選び方も併せてご覧ください。
ベンダーに投げる8つの質問
提案を受けるときに確認しておく項目です。
- 精度をどう測りますか。 何問の評価データで、どの指標を使いますか。検索の失敗率と回答の正しさを分けて報告してもらえますか。
- ベースラインは何ですか。 「精度が向上」という説明の比較対象を明示してください。
- アクセス権限はどの方式で実装しますか。 検索の時点で絞り込むのか、取得後に除外するのか。人事異動への追随はどうしますか。
- 文書を更新したとき、回答へ反映されるまでの手順と時間は。 自動ですか、手作業ですか。誰が実行しますか。
- タイ語やベトナム語での検索精度を、日本語と分けて評価してもらえますか。 分かち書きの処理は入っていますか。
- データの保存先はどこですか。 文書原本、抽出テキスト、ベクトル、質問と回答のログの4種類それぞれについて答えてください。
- 答えられないときの挙動はどう設計されていますか。 推測を返さない仕組みは入っていますか。
- 契約を終了する場合、何が手元に残りますか。 整備済みの文書、抽出テキスト、評価データ、用語集を引き取れますか。特定の製品に固定されない形で持ち出せますか。
8番目は特に重要です。RAG構築でいちばん価値が高い資産は、検索基盤ではなく整備された文書と評価データです。これが自社に残る契約になっているかを確認してください。
RAG構築を4ステップで進める
進め方は4ステップに整理できます。
ステップ1 対象業務を1つに絞る
複数部門の要望をまとめて取り込むと、文書の種類も権限も一気に複雑になります。最初は1業務です。選ぶ基準は、文書がすでに電子化されている割合が高く、質問の頻度が高く、権限の出し分けが単純なもの。設備保全マニュアルの検索か、社内規程の問い合わせが選ばれることが多い領域です。
ステップ2 評価データ30問を先に作る
PoCを始める前に、現場から実際に出る質問を30問集め、それぞれの正解にあたる文書名と該当箇所を書き出してください。これがRAG構築で最も重要な準備です。
30問には、次の種類を混ぜます。
- 素直に一箇所を見れば答えられる質問
- 複数の文書を突き合わせないと答えられない質問
- 文書に答えが書かれていない質問（「該当する記載が見つかりません」と返るのが正解）
- 型番や略語を含む質問
- タイ語やベトナム語で書かれた質問
このデータがないPoCは、成否を判定できません。逆にこれさえあれば、複数ベンダーの提案を同じ土俵で比較でき、稼働後も改善の効果を測り続けられます。作成には現場の担当者の時間が要りますが、外注できない作業です。
ステップ3 PoCで判定する
限定した文書と限定した利用者で試し、ステップ2の30問で採点します。判定は「便利だったか」ではなく、何問正しく答えられ、何問で誤った文書を引き、何問で正しく「分からない」と答えたかです。誤答については、検索で正しい文書が取れていなかったのか、取れていたのに回答が誤ったのかを切り分けて記録します。前者なら検索側の改善、後者なら指示文や分割の見直しです。
期間の目安は、日本国内の相場で2〜6週間とされています（Japan-specific）。
ステップ4 本番構築と運用開始
本番では、第4層の既存システム連携とアクセス権限設計が主な作業になります。並行して、第5層の運用体制を決めます。文書更新の担当者、誤答が報告されたときの受け皿、評価データを定期的に回して精度を確認する頻度。この3つを決めずに稼働すると、半年後に使われなくなります。
期間の目安は、日本国内の相場で2〜4か月とされています（Japan-specific）。
RAG構築に関するよくある質問
RAGとは何ですか
RAG（Retrieval-Augmented Generation）は、質問に対して自社の文書から関連部分を検索し、それをLLMに渡して回答を作らせる仕組みです。LLMが社内文書を記憶するのではなく、毎回参照する方式のため、文書を更新すれば回答も更新されます。根拠となった文書を提示できる点も、社内利用では重要な特性です。
RAG構築の費用はいくらですか
日本国内の相場では、PoCが100〜300万円、本番構築が300〜1,000万円、月額運用が10〜50万円とされています（Japan-specific）。海外の相場では、単純なRAGが15,000〜25,000米ドル、本番RAGが40,000〜80,000米ドル、オンプレミスのエンタープライズRAGが80,000〜150,000米ドル以上です（global）。ただし工場の場合、文書が紙やスキャン画像のままであれば、第1層の電子化・前処理が上振れします。稟議には第1〜4層を投資額、第5層を年間運用費として分けて記載してください。
RAGとファインチューニング、どちらを選ぶべきですか
社内文書の検索が目的なら、まずRAGです。ファインチューニングは文書を更新するたびに学習をやり直す必要があり、根拠文書を示せません。一方、回答の文体や出力形式を固定したい場合にはファインチューニングが有効な場面もあります。事実の参照はRAG、表現の統一は指示文かファインチューニング、という役割分担が実務的です。
社内のマニュアルが紙しかない場合でもRAGは作れますか
作れますが、電子化が先です。紙やスキャン画像のPDFは文字として検索できないため、OCRによる文字起こしが必要になります。この工程が第1層にあたり、工場では費用の中心になりやすい部分です。手書きや日本語とタイ語の混在がある帳票では、読み取り精度の確認から始めてください。対象を絞り、頻繁に参照される文書から順に電子化するのが現実的な進め方です。
タイ語で質問して日本語のマニュアルを検索できますか
できますが、設計が要ります。方式は3つあり、文書を翻訳して二重に持つ案、質問を翻訳して検索する案、多言語埋め込みで直接検索する案です。実務では後者2つを併用し、安全に直結する文書だけ正式なタイ語版を持つ形が現実的です。加えて、タイ語は単語間に空白がないため分かち書きの処理が必要で、これが入っていないとタイ語だけ検索が当たらない状態になります。型番や略語を翻訳させない用語集の整備も併せて行ってください。
RAG構築にはどのくらいの期間がかかりますか
日本国内の相場では、PoCが2〜6週間、本番構築が2〜4か月とされています（Japan-specific）。従業員300名の企業が情報システム部門のFAQを対象にした事例では、PoCが2週間、本番構築が3か月でした。ただしこれは文書がすでに電子化されている前提の期間です。紙やスキャン画像からの電子化が必要な場合は、その工程を別途見込んでください。
まとめ：RAG構築の要点
本記事の要点を、費用の5層に沿って整理します。
- 第1層（文書の電子化・前処理）。工場では最も重くなりやすい層です。紙、スキャンPDF、図面、Excelの整理と版の確定は自社にしかできません。着手前に、そもそも対象が20万トークン、約500ページ未満ならRAGを作らずプロンプトに入れる選択肢を検討してください（global）。
- 第2層（検索基盤）。日本国内の内訳では、ベクトルDBは本番で60万円という水準です（Japan-specific）。ここは相対的に軽い層です。
- 第3層（アプリ・UI）。既存の業務ツールへ組み込むほど定着します。
- 第4層（既存システム連携とアクセス権限設計）。日本国内の内訳の差額、および海外の出典が示すコスト要因の中心がここです。全社展開が止まるのもこの層です。
- 第5層（運用）。LLM利用料、文書更新、精度改善の社内工数。稟議では投資額と分け、年間運用費として計上します。
精度については、改善の主戦場は検索側です。Contextual Embeddings、BM25の併用、リランキングを順に重ねると、埋め込みのみのRAGをベースラインとして検索失敗率が5.7%から1.9%へ、67%削減されたという実測があります（global）。これは失敗率の削減であって、精度が67%上がるという意味ではありません。
そして多言語です。タイやベトナムの工場では、技術文書と作業者の言語が一致しません。翻訳をどの層で行うかを3案から選び、タイ語の分かち書きに対応し、型番と略語は翻訳させない。回答は質問者の言語で返し、根拠は原語のリンクで示す。ここまで設計して、はじめて現場で使われる仕組みになります。
制度面では、タイはPDPAが土台でAI法は草案段階（Thailand-specific）、ベトナムはAI法が2026年3月に施行済み（Vietnam-specific）と状況が異なります。細部は所管当局または現地の専門家に書面で確認してください。
RAG構築を検討されていて、どの文書から着手すべきかの切り分けだけでも整理したい、という段階でも構いません。手元の文書がRAGを作るべき規模なのか、それともプロンプトに入れて済む規模なのかを一緒に確認するところから始められます。多言語での検索設計や、既存の生産管理システムとの連携範囲についてのご相談も承っています。お問い合わせはこちらからご連絡ください。
参考情報
- Anthropic「Introducing Contextual Retrieval」 https://www.anthropic.com/news/contextual-retrieval
- GXO「RAG構築費用の内訳」（2026-04-14） https://gxo.co.jp/column/rag-implementation-cost-breakdown-2026
- AITIP「RAG構築の手順・費用相場」 https://aitip.jp/rag-construction/
- ScalaCode「RAG Development Cost」 https://www.scalacode.com/blog/rag-development-cost/
- Bangkok Post「AI adoption helps Thai firms become digitally mature」 https://www.bangkokpost.com/business/general/3283789/ai-adoption-helps-thai-firms-become-digitally-mature
- Bangkok Post「Data quality concerns a barrier to adoption of AI」 https://www.bangkokpost.com/business/general/3051260/data-quality-concerns-a-barrier-to-adoption-of-ai
- DataGuidance「Thailand: ETDA announces AI 2026 strategy to promote trust」 https://www.dataguidance.com/news/thailand-etda-announces-ai-2026-strategy-promote-trust
- Vietnam Briefing「Vietnam’s AI Law: Regulatory Milestone and Business Implications」 https://www.vietnam-briefing.com/news/vietnams-ai-law-regulatory-milestone-business-implications.html/
