001JAPANESE TEXTILE COMPANY · 2025–2026
日本語とタイ語で答えるRAGナレッジエージェント。セルフテスト1.0中0.9
0.9
セルフテスト、1.0中
大阪に本社、タイに工場を持つ繊維メーカーが求めたのは、日本語でも英語でもタイ語でも、質問をひとつ投げれば出典つきの答えが返ることでした。Kuroko Labs はそのためのナレッジエージェントを構築しました。プランナーが質問を分解し、7系統の検索が並列に走り、ひとつのランキングに束ねたうえで、言語モデルが出典つきの答えを書きます。単純な質問は4秒未満、複数文書にまたがる分析は35秒未満で返りました。100シナリオのセルフテストで1.0中0.9。2025年から2026年6月まで稼働し、その後お客様の重点は会議と認証に移りました。
5
AIプロバイダー
Anthropic, OpenAI, Cohere, Mistral, Unstructured.io
7
検索チャネル
ベクトル、全文、表データ、メール、グラフ、エンティティ、カンバン
4
応答ティア
Flash 4秒未満から Deep 35秒未満まで
2
対応言語
日本語、タイ語
0.9
セルフテストスコア
稼働中のシステムに対する100シナリオ、重複除外後83件
01、課題
資料は揃っていました。見つけられなかっただけです。
お客様はタイの工場でファッションブランド向けに縫製し、経営は大阪から行っています。指示は日本語、工場からの報告はタイ語か英語。そのあいだに、SharePoint、メール、数十シートのExcelが横たわっていました。
それでも探し方は「人に聞く」でした。ある品番の単価が要る人は同僚3人に尋ね、最後に届くのは古い版のファイル。SharePointの検索はあまり役に立ちません。日本語には空白がなく、生産と打っても、同じ話題の「生産管理」は出てこないからです。
言語の境目は会社の真ん中を通っていました。大阪はタイ語の検品報告を読めず、工場は日本語の指示書を読めません。
欲しかったのはチャットボットではありません。質問した言語で、3言語の資料すべてから、出典つきの答えが返ることでした。
∞
散らばった保管
SharePoint、メール、会議の文字起こし、数十シートのExcel
2
言語の壁
日本語とタイ語に共通の索引がなく、日本語には空白もありません
!
探し方は人に聞く
Slackで1時間やり取りして、届いたのは古い版のファイル
0
共通の保管場所がない
2か国、2つの業務言語、共通の保管場所なし
02、ソリューション
日本語とタイ語の社内文書検索は、どう作るのか
単純なベクトル検索では足りませんでした。Kuroko Labs は3段階のRAGパイプラインを組みました。プランナーが質問を分解し、最大7系統の検索が並列に走ってひとつのランキングに束ねられ、4段階の応答ティアが「どこまで深く、いくらまで掛けてよいか」を決めます。
第一段階はQuery Plannerです。小さなモデル（gpt-4o-mini）で、所要時間は300ミリ秒ほど。ブランドコード、製品タイプ、取引先名、Excelシートの定番の名前を知っていて、質問ごとに計画を作ります。ベクトル検索用に原語のままの検索文、全文検索用に日本語・英語・タイ語のキーワード列、検出した製品コードを絞り込み条件に、加えて質問の難易度。「mori-san」のような名前は社員名簿を引いて漢字表記に直しました。繰り返しの質問にはRedisのキャッシュが30ミリ秒未満で答えました。
第二段階は7系統の同時検索です。意味はpgvector、日本語の字面の一致はPGroonga、仕入先・製品・報告書のつながりはLightRAG。質問によって、表の行、メール、人物、タスクカードの検索が加わります。全体の所要時間は最も遅い系統の分だけで、合計ではありません。Reciprocal Rank Fusionがリストを束ね、1文書あたり最大3件に抑えて、1つのファイルが上位を独占しないようにしました。最後の選別はCohere Rerankです。40以上の語群を持つ日英辞書が、日本語の質問で英語の文書も引けるようにしました。
最も手こずったのは日本語の全文検索でした。PGroongaはテキストを2文字ずつ重ねた断片に分けます。「品質管理」で検索すると「品質管理報告書」も当たり、辞書も形態素解析も要りません。Supabase側の関数が日本語の助詞をOR条件に展開しました。日本語に慣れた利用者ほど、検索が拾ってくる範囲に驚いていました。
索引は4つのソースから作りました。SharePointはMicrosoft Graphの差分同期で、アクセス権ごと取り込み、SharePointで見られる範囲しか見えないようにしました。メールは二段階の関連度フィルターを通し、会議の文字起こしはWebhookで、あとはブラウザからのアップロード。Mistral OCRが最大35 MBのPDFをスキャンも含めて読み、日本語は800文字、ラテン文字は1,200文字ずつに切り、区切りは日本語の句点に合わせました。SHA-256の照合で、同じファイルを二度処理しない仕組みです。
PGROONGA TOKENBIGRAM
語の区切りがない日本語テキストを、どのように検索可能にするか
01
文書テキスト
02
Bigramインデックス 重なり合う2文字の断片（語ではありません）
03
検索クエリ
03、アーキテクチャ
プランナーからセルフテストまで、6つの部品
01QUERY PLANNER
質問ごとにひとつの計画
プランナー（gpt-4o-mini、温度0）が質問ごとにJSONの計画を作ります。原語の検索文、日本語・英語・タイ語のキーワード、絞り込み用の製品コード、当たりをつけたExcelシート、そして応答ティア。質問中の名前は漢字に直します。繰り返しはRedisキャッシュから30ミリ秒未満で返しました。
300
MS 設計レイテンシ（Redisキャッシュ：<30 ms）
02PARALLEL DISCOVERY
7系統の検索チャネル、ひとつのランキング
意味はHNSWインデックス付きのpgvector、字面の一致はMeCabなしのPGroonga TokenBigram、つながりはLightRAGのナレッジグラフ。質問に応じて表、メール、人物、タスクカードが加わります。Reciprocal Rank Fusion（k=60）がリストを束ね、1文書あたり最大3チャンク、最後はCohere Rerank v3.5が選びます。HyDEと同義語辞書が言語の境目を越えてヒットを拾いました。
7
並列検索チャネル数
03表データ
文脈つきのExcel行
Excelの各行は二重に持ちました。PGroonga向けのタブ区切りテキストと、モデル向けのHTMLテーブルです。ヒットしたら同じブロックのヘッダー行と前後の行も取り出し、モデルが1セルではなく表全体を見られるようにしました。文脈の上限はティアに応じて15,000文字から130,000文字まで広がります。
130K
Deepティアの文脈文字数
04SYNTHESIS
4段階の応答ティア
どの質問にも最も高いモデルを使う必要はありません。単純な事実はFlashで4秒未満、FastとStandardはClaude Haiku 4.5、複数文書の分析はDeepでClaude Sonnet 4.6が35秒未満。出力の上限と文脈窓はティアごとに広がります。最初の語はストリーミングで即座に出て、追加質問では既出の箇所を繰り返さず、給与や人事の話題はフィルターが止めました。
4
応答ティア、4秒未満から35秒未満まで
05INGESTION
4つのデータソース、ひとつの索引
SharePointはMicrosoft Graphの差分同期、アクセス権つき。メールは二段階の関連度フィルター。会議の文字起こしはWebhook。あとはブラウザからのアップロード。PDFは最大35 MBまでMistral OCR、XLSX・DOCX・PPTXはExcelJSとUnstructured.io。日本語は800文字、ラテン文字は1,200文字ずつ、重複はSHA-256で検出しました。
4
ソースコネクタ数
06FEEDBACK-LOOP
学習する企業プロファイル
利用者の修正をフィードバックから取り出し、プロンプトインジェクションを確認したうえで、以後の回答すべてに反映しました。再学習なしで覚えていく仕組みです。100問のセルフテストが実際の利用者として稼働中のシステムに走り、カテゴリごとにスコア、出典の網羅率、応答時間を測りました。サーキットブレーカー、再試行、プロバイダーごとの費用上限が運用を支えました。
100
セルフテストのシナリオ数
いちばん手強かったのはExcelです。「品番Xの現在の単価は」という質問は、数十シート、そして誰も揃えていないヘッダーを持つブックの中の1セルを指しています。だから各行を索引に二重に持ち、ヒットにはヘッダー行と前後の行を添えました。
回答の前に表はコンパクトなMarkdownへ変換し、トークンを3割ほど減らしました。途中で切れた10件より、完全な3件。回答の末尾には出典が付きます。「[原価計算 Q1.xlsx] 2025-03-15時点」のように。
ベクトル検索と全文検索が1文書で止まるところから、ナレッジグラフが始まります。LightRAGは取り込み時に拠点、仕入先、製品ライン、報告書と、そのあいだの関係を抜き出しました。誰が何を納め、誰が何を検査するか。複数文書にまたがる質問には、グラフ上の短い経路を回答に添えました。
下の図は製造ドメインを簡略化したものです。線はグラフが文書そのものから学んだ関係です。
5社のプロバイダーを使ったのは、それぞれに役割があるからです。埋め込みとプランナーはOpenAI、OCRはMistral、再ランキングはCohere、Office文書はUnstructured.io、回答はAnthropic。サーキットブレーカー、レート制限をふまえた再試行、プロバイダーごと・時間ごと・日ごとの費用上限が、運用を枠内に収めました。
LightRAG ナレッジグラフ、製造ドメインの例
QUERY
品質管理 → 海外工場の検品報告
エンティティ3件、リレーション2件、経路を1秒未満で解決
04、成果
稼働中のシステムで測ったセルフテスト、1.0中0.9
5
使ったAIプロバイダー
7
並列稼働する検索チャネル
2
インデックス上の言語数
0.9
セルフテスト、最大1.0
METRIK導入前導入後
ナレッジ検索SharePointを開いて回り、同僚3人に聞くひとつの質問に、出典付きのひとつの回答
言語の壁自分で訳すか、諦める日本語とタイ語が同じ索引に
Excelの調査シートを1枚ずつめくるヘッダー行と前後の行つきのヒット
会議のナレッジ会議が終わると蒸発する文字起こしが自動で索引に入る
出典への信頼追跡不能すべての回答にリンクと該当箇所
回答生成のコストどの質問にも最も高いモデル4ティア。Sonnetは必要なときだけ
数字で確かめました。セルフテストは100シナリオ、重複を除いて83件、単純な事実質問から会議の要約、メール検索、複数ブランドをまたぐ分析まで8カテゴリ。実際の利用者として稼働中のシステムに走らせました。結果は1.0中0.9、ほぼすべての回答に出典が付きました。資料に答えがない質問には、作り話をせず「ない」と答えました。
応答時間は質問しだいでした。繰り返しの事実質問はキャッシュから2秒未満、単純な参照は4秒未満、複数文書の分析はClaude Sonnet 4.6で35秒未満。最初の語はすぐに出て、残りが後から続きます。
品質は受け入れテストで終わりにせず、回し続けました。セルフテストが弱いカテゴリを利用者が気づく前に見つけ、フィードバックからの修正が以後の回答に入り、どの回答も出典文書と結びついたままでした。
この段階は2025年から2026年6月まで続きました。その後お客様は重点を会議の分析と認証の準備に移し、ナレッジエージェントは稼働中のダッシュボードから切り離されています。上の数値は稼働していた期間のものです。
“
AIは、私たちが必要としていたイネーブラーそのものでした。日本の従業員が日本語で質問すると、英語やタイ語の文書に基づいた回答が数秒で返ってきます。これにより、タイチームと日本チームのコミュニケーションが根本から最適化されました。CEO, JAPANESE MANUFACTURING COMPANY
TECH STACK
Claude Haiku 4.5
回答生成（Flash・Fast・Standardティア）
Claude Sonnet 4.6
回答生成（Deepティア）
gpt-4o-mini
プランナーと修正の抽出
OpenAI Embeddings
text-embedding-3-small (1536-D)
Cohere Rerank v3.5
最終リランキング
Mistral OCR
PDF解析（スキャン含む、最大35 MB）
Unstructured.io
DOCXとPPTX抽出
Supabase + pgvector
セマンティック検索、HNSWインデックス
PGroonga
日本語全文検索、TokenBigram
LightRAG
ナレッジグラフ、エンティティとリレーション
Microsoft Graph
SharePoint Delta同期、メール、アクセス権
会議の文字起こし
Webhook経由の会議文字起こし
Node.js + Express
バックエンド、PM2クラスター、SSEストリーミング
Redis
プランナーと回答のキャッシュ、レート制限
SSE
リアルタイムのトークンストリーミング
展望
第一段階ではまだ先の話だった会議の文字起こしとメールは、期間中に実用のソースになりました。その先に予定していたのは、質問ごとの費用の可視化、質問の判定の細分化、グラフの充実です。実際には別の道になりました。お客様がまず必要としたのは会議の分析で、その次がGOTS認証のトラッカーでした。この段階で作った漢字修正の学習と同義語辞書は、そちらで動き続けています。
次のステップ
同様のプロジェクトをご検討ですか？
お問い合わせ すべてのケーススタディこの事例についてよくあるご質問
RAGナレッジエージェントとは何ですか。+
自社の資料をまず検索し、見つかった箇所をもとに言語モデルが答えを書く仕組みです。出典が答えより先に決まるので、どの記述も確かめられます。この案件では、SharePoint、メール、会議の文字起こしが出典でした。
空白のない日本語で全文検索はどう成り立ちますか。+
PGroongaがテキストを2文字ずつ重ねた断片に分けます。「品質管理」で検索すれば「品質管理報告書」も当たり、語の切れ目を知る辞書は要りません。意味を拾うベクトル検索を並走させ、両方のリストをひとつのランキングに束ねました。
検索を7系統に分けた理由は何ですか。+
質問がそれぞれ違うからです。製品コードは字面の一致、つながりの質問はグラフ、単価は表の行とヘッダーが要ります。系統は並列に走り、最も遅いものが所要時間を決め、ひとつのランキングにまとめました。
品質はどう測りましたか。+
8カテゴリ100シナリオ、重複を除いて83件のセルフテストを、実際の利用者として稼働中のシステムに走らせました。総合で1.0中0.9。利用者からの修正は以後の回答に反映しました。
データは社外に出ましたか。+
索引と検索はEUサーバー上のSupabaseに置き、SharePointのアクセス権を利用者ごとに写しました。言語モデルは各社のAPIを呼んでいます。それが難しい場合、いまは同じ構成をローカルLLMで組めます。
この仕組みはいまも動いていますか。+
2026年6月で段階を終えました。お客様は重点を会議の分析とGOTS認証の準備に移し、ナレッジエージェントはダッシュボードから切り離しています。日本語検索と漢字修正の部品はそちらで使い続けています。
同じものを自社向けに作れますか。+
はい。部品は差し替えられ、変わるのはソースだけです。初回相談とポテンシャル分析は無料で、その後は固定価格です。詳しくは多言語ナレッジ検索のページをご覧ください。