ラオス語で質問したのに英語で返ってきた——当社がラオスで AI チャットボットを初めて構築したとき、最初にぶつかった壁がこれだった。世界の主要 LLM にとってラオス語は「ほぼ知らない言語」であり、英語と同じアプローチでは実用レベルに届かない。本記事では、当社がラオス向けプロジェクトで実際に採用している RAG（検索拡張生成）+ LLM のアーキテクチャをもとに、ラオス語 LLM の選定基準、構築手順、品質評価の自動化までをステップバイステップで解説する。ラオス語で「使える」チャットボットを作りたい方への実践ガイドだ。

英語のチャットボットなら API を叩いてプロンプトを書けば動く。しかしラオス語では同じアプローチが通用しない。その原因は言語そのものの特性と、LLM の学習データの偏りにある。

LLM の多言語性能は学習コーパスに含まれるテキスト量にほぼ比例する。Common Crawl のデータ比率を見ると、英語が約 46% を占めるのに対し、ラオス語は 0.01% 未満だ。4,000 倍以上の格差がそのまま応答品質の差として現れる。

当社がラオスで最初の AI プロジェクトを立ち上げた際、汎用 LLM にラオス語で業務マニュアルの要約を依頼したところ、固有名詞の誤変換と文法崩れが頻発した。「ທະນາຄານແຫ່ງ ສປປ ລາວ」（ラオス中央銀行）が「ラオスの銀行」に丸められ、どの銀行を指しているのか判別不能になるケースもあった。英語なら問題なく動くプロンプトがラオス語では機能しない——これが低リソース言語の現実だ。

ラオス語には単語間にスペースがなく、明確な文末記号もない。英語なら "I love cats" が 3 トークンで済むところ、ラオス語の "ຂ້ອຍຮັກແມວ" は BPE（Byte Pair Encoding）トークナイザーで 10 トークン以上に分割されることがある。

これが実務に及ぼす影響は 2 つだ。

• コンテキスト窓の圧迫: 同じ情報量でも英語の 2〜3 倍のトークンを消費する。会話が長くなるほど過去の文脈が押し出されて応答品質が落ちる
• テキスト分割の困難: RAG 用の文書分割（チャンキング）で、単語の途中や文の途中で切れる「分割ミス」が高頻度で発生する。英語向けの sentence splitter はラオス語ではほぼ機能しない

ラオス語の LLM 性能が低いなら、「質問をまず英語に翻訳 → 英語で検索・推論 → 結果をラオス語に翻訳」すればよいのでは——と考える人は多い。当社も初期にこの方式を試した。

結果は散々だった。

• ラオス語 → 英語の翻訳精度がそもそも低い: 「ສິນເຊື່ອ」（信用貸付）が "credit" に丸められ、金融の文脈が消失する。ラオスの法律用語・行政用語は英語に直訳できないものが多い
• 二重翻訳でレイテンシが 2〜3 秒加算: チャットボットの応答に 5 秒以上かかると、ユーザーの離脱率が急増する
• 固有名詞が英訳で崩壊: ラオスの地名（ルアンパバーン県の村名等）や機関名が翻訳を往復するうちに変形し、元に戻らない

この経験から、当社はラオス語テキストをラオス語のまま処理するアプローチ——つまり RAG によるナレッジ補完——に方針を転換した。

チャットボットの品質は LLM の選定でほぼ決まる。しかし「ラオス語対応」を謳うベンチマークは存在しないに等しい。自分で検証するしかない。

当社では以下の 4 軸でラオス語の LLM 性能を評価した。

1. 日常会話の自然さ: 基本的な質疑応答が文法的に正しく、自然に成立するか
2. 専門用語の正確性: 金融・行政・IT 分野のラオス語用語を正しく扱えるか
3. 指示追従性: 「ラオス語で回答せよ」「参照情報のみに基づいて回答せよ」という制約を守れるか
4. コスト効率: ラオス語はトークン膨張するため、英語の 2〜3 倍のコストがかかる。それを踏まえた実質コスト

検証にはラオス語の業務 FAQ（50 問）を用意し、各モデルに同一条件で回答させた。

2025 年時点の主要モデルの検証結果をまとめる。

※ 価格は時期により変動する。ラオス語はトークン膨張により、実質コストは英語の 2〜3 倍になる。

全モデルに共通するのは、ラオス語単体では専門領域の質問に正確に答えられないという点だ。どのモデルを選んでも RAG によるナレッジ補完は必須になる。

当社のチャットボット基盤では AWS Bedrock 経由の Claude Sonnet を採用している。決め手は 3 つだ。

1. 指示追従性の安定性。RAG では検索結果をシステムプロンプトに注入する。このとき「提供されたコンテキストのみに基づいて回答せよ」という指示を LLM が守らないと、ハルシネーション（事実と異なる応答）が発生する。Claude はこの制約への追従性が最も高く、ラオス語のコンテキストでも逸脱が少なかった。

2. AWS エコシステムとの統合。Bedrock を使うことで IAM によるアクセス制御、CloudWatch によるログ監視、VPC 内からのプライベート接続が可能になる。当社のクライアントには金融機関が多く、データがリージョン外に出ないことは必須要件だった。

3. マルチモデル切り替えの柔軟性。Bedrock は Claude 以外にも Mistral、Llama、Amazon Nova を同一 API で呼び出せる。将来ラオス語に強いモデルが登場した際、コード変更なしで切り替えられる。

前章で確認した通り、どの LLM もラオス語単体では専門知識を持たない。RAG を組み合わせることで、この根本的な限界を補う。

RAG（Retrieval-Augmented Generation）は、ユーザーの質問に関連するドキュメントをベクトル検索で取得し、その内容を LLM のプロンプトに注入して回答を生成する手法だ。

LLM 単体と RAG の差はラオス語において特に顕著になる。

英語なら LLM 単体でもそれなりに回答できる質問が、ラオス語では全くできない。だからこそ RAG の効果がラオス語で最も大きくなる。

当社が採用しているパイプラインは以下の構成だ。

ユーザーの質問（ラオス語）
  ↓
[Embedding] テキストをベクトル化
  ↓
[Vector Search] Supabase pgvector で類似チャンク 50 件を取得
  ↓
[Reranking] 類似度スコアでフィルタ → 上位 5 件に絞り込み
  ↓
[LLM] AWS Bedrock Claude にコンテキスト + 質問を送信
  ↓
[Streaming] SSE で段階的に応答を配信
  ↓
[Auto Scoring] Mastra Evaluations で品質スコアを自動計測

ポイントはエンベディングと LLM で異なるモデルを使い分けている点だ。エンベディングには多言語対応・低コストのモデルを、応答生成には指示追従性の高い Claude を配置する。この組み合わせがコストと品質のバランスに優れている。

エンベディング（テキストのベクトル化）は RAG の検索精度を左右する最重要コンポーネントだ。

多言語対応のエンベディングモデルを使用すれば、ラオス語テキストもベクトル化できる。100 以上の言語をサポートするモデルであれば、ラオス語にも対応している。

ただし限界もある。ラオス語は学習データが少ないため、同義語や言い換えのベクトル距離が英語ほど正確でない。具体的には「ສິນເຊື່ອ」（信用貸付）と「ເງິນກູ້」（ローン）が同じ概念として近い距離に配置されないケースがある。この問題は、初期検索を広く取って（50 件）からリランキングで絞り込む（5 件）というパイプライン設計で緩和している。

ここからは具体的な構築手順を解説する。技術スタックは TypeScript + Next.js + Supabase + Mastra を前提とするが、アーキテクチャの考え方は他のスタックにも応用できる。

チャットボットが参照するナレッジ（業務マニュアル、FAQ、規約文書など）を準備し、検索可能な単位に分割する。

ラオス語のテキスト分割は最大の難所だ。 スペースで単語が区切られず、文末記号（「。」に相当するもの）もほぼ使われないため、英語向けの sentence splitter が機能しない。当社では Mastra RAG の分割戦略を以下のように使い分けている。

推奨設定: ラオス語文書には recursive（チャンクサイズ 512 トークン、オーバーラップ 50 トークン）を基本とする。オーバーラップを入れる理由は、分割位置がラオス語の文脈の途中に当たっても、前後のチャンクで内容が補完されるようにするためだ。

分割したテキストチャンクをベクトル化し、検索可能な状態で格納する。当社では Supabase の pgvector 拡張を使用している。

Supabase pgvector を選んだ理由は 3 つだ。

• テナント分離: PostgreSQL の RLS（Row Level Security）で、クライアントごとにナレッジを分離できる
• 追加コスト不要: 既存の Supabase プロジェクトに拡張を追加するだけ。Pinecone 等の外部サービスが不要
• SQL との統合: ベクトル検索と通常のフィルタ（言語コード、カテゴリ等）を 1 クエリで組み合わせられる

テーブル設計のポイントは言語コードをメタデータに含めることだ。ラオス語のナレッジのみ検索する場合は language = 'lo' でフィルタし、全言語横断で検索する場合はフィルタを外す——この切り替えが SQL の WHERE 句 1 行で実現できる。

ベクトル検索は「似ている順に返す」だけでは精度が足りない。ラオス語ではエンベディングの精度が英語ほど高くないため、関連性の低いチャンクが上位に混入しやすい。

当社のパイプラインは 2 段階でフィルタリングする。

1. 初期検索: pgvector で上位 50 件を広く取得
2. 類似度フィルタ + リランキング: コサイン類似度スコアでノイズを除去し、関連性で再順位付けした上位 5 件を LLM に渡す

なぜ 50 件も取るのか。ラオス語のエンベディングでは、本来 1 位であるべきチャンクが 20 位に埋もれることがある。「ສິນເຊື່ອ」で検索しても「ເງິນກູ້」を含むチャンクが上位に来ない、という同義語問題が原因だ。広く拾ってからリランキングで正しい順位に並べ替える方が、検索漏れが少ない。

検索結果を LLM に渡してラオス語で応答を生成する。ユーザー体験を考慮し、SSE（Server-Sent Events）によるストリーミング配信を採用する。

ストリーミングにより、TTFT（最初のトークンが表示されるまでの時間）を約 0.8 秒に短縮できる。RAG のコンテキスト注入で入力トークンが増えると、全文生成を待つ方式では 5〜10 秒かかるが、ストリーミングなら 1 秒以内に最初の文字が表示され始める。

ラオス語固有のシステムプロンプト設計:

ラオス語チャットボットでは、以下の指示をシステムプロンプトに明示する必要がある。

• 応答言語の固定: 「ユーザーがラオス語で質問した場合、必ずラオス語で回答せよ。検索結果が英語や日本語であっても、回答はラオス語に翻訳して出力すること」——この指示がないと、英語のナレッジを参照したとき LLM が英語で応答してしまう
• コンテキスト制約: 「提供された参照情報のみに基づいて回答せよ。情報がない場合はそう伝えること」——ラオス語のハルシネーション率は英語より高いため、制約の明示が不可欠
• 参照元の提示: 応答に使用したチャンクの出典を返すよう指示する。ユーザーが根拠を確認できることで、低リソース言語であっても信頼性を担保できる

チャットボットは「動いている」だけでは不十分だ。ナレッジの追加や LLM のアップデートで応答品質は常に変動する。

当社では Mastra Evaluations を使い、以下の 3 指標をリアルタイムで自動計測している。

評価にはメインの応答生成モデルとは別の LLM を使用する。「自分が生成した回答を自分で評価する」自己採点のバイアスを避けるためだ。

当社がラオス向けプロジェクトで経験した失敗パターンを共有する。いずれも事前に知っていれば回避できたものだ。

何が起きたか: ラオス語の業務マニュアルを sentence 戦略で分割したところ、文書全体が 1 チャンクになるか、逆にバイト単位でバラバラになるかの両極端な結果になった。原因は単純で、ラオス語には「。」に相当する文末記号がほぼ使われない。sentence splitter は文末記号を区切りとして動作するため、ラオス語のテキストではどこにも分割点を見つけられない。

どう直したか: recursive 戦略に切り替えた。改行と段落区切りをベースにチャンキングし、チャンクサイズ 512 トークン、オーバーラップ 50 トークンで設定した。ラオス語文書は段落ごとに改行が入っていることが多いため、この方式で実用的な分割ができる。

何が起きたか: ナレッジベースに英語と日本語のドキュメントも含まれていたため、ラオス語の質問に対して英語のチャンクがヒットし、LLM がそのまま英語で応答してしまうケースが頻発した。システムプロンプトに応答言語の指示を入れていなかったことが原因だ。

2 年前まで英語のみだった社内ナレッジを多言語化する過渡期に、この問題が集中的に発生した。ラオス語のナレッジが揃っていないセクションでは、英語のチャンクしかヒットしないため LLM が英語に引きずられる。

どう直したか: 2 つの対策を同時に実施した。(1) システムプロンプトに「ユーザーの言語と同じ言語で必ず回答すること」を明示追加。(2) ナレッジベースのメタデータに言語コードを付与し、ラオス語の質問にはラオス語のチャンクを優先的に検索するフィルタを実装した。

何が起きたか: マルチターンのラオス語会話で 20 メッセージ分のコンテキストを保持した結果、入力トークンが 15,000 を超え、応答品質が目に見えて劣化した。ラオス語は英語の 2〜3 倍のトークンを消費する。メッセージ 20 件は英語なら余裕でも、ラオス語ではコンテキスト窓の大半を食いつぶす。

RAG のコンテキスト（5 チャンク分、約 3,000〜5,000 トークン）を注入する余地がなくなり、検索結果が切り捨てられて「ナレッジを見ていない」回答が増えた。

どう直したか: 会話履歴の保持をメッセージ数ではなくトークン数上限で制御するよう変更した。当社では直近の会話履歴を最大 8,000 トークンに制限し、RAG コンテキスト用に十分な余裕を確保している。ラオス語の場合、これは実質 8〜10 メッセージ分に相当する。

チャットボットは構築して終わりではない。ナレッジの追加、LLM のバージョンアップ、ユーザーの質問パターンの変化——これらによって応答品質は常に変動する。

当社では Mastra の Live Evaluations 機能を使い、本番環境のチャット応答をリアルタイムでスコアリングしている。スコアリングは応答生成と非同期で実行されるため、ユーザーの体感速度には影響しない。

計測した 3 指標（Answer Relevancy / Faithfulness / Retrieval Precision）はデータベースに保存し、時系列で推移を追える。スコアの急激な低下はナレッジの欠損やモデルの挙動変化を示すシグナルだ。

全リクエストをスコアリングすると評価用 LLM のコストが膨らむ。当社では環境ごとにサンプリング率を変えている。

本番 10% でも 1 日 1,000 リクエストなら 100 件/日のスコアデータが蓄積される。週次で平均値を確認すれば品質の傾向は十分に把握できる。

指標ごとに改善アプローチが異なる。

Retrieval Precision が低い（< 0.6）: 検索が的外れなチャンクを返している。チャンクサイズの調整（512 → 256 トークンに縮小）、ラオス語ナレッジの追加、メタデータフィルタの見直しを検討する。ラオス語の場合、チャンクを小さくすると改善するケースが多い。

Faithfulness が低い（< 0.8）: LLM が検索結果にない情報を補完している。システムプロンプトの制約を強化するか、temperature を下げる（0.3 → 0.1）ことで対処する。ラオス語は LLM の学習データが少ないため、英語よりハルシネーションが起きやすい点に注意。

Answer Relevancy が低い（< 0.7）: 応答がユーザーの質問とずれている。まず Retrieval Precision を確認する。検索側に問題がなければ、プロンプトの改善（回答フォーマットの指定、質問の言い換え指示）に取り組む。

ある。むしろナレッジが少ないほど効果が実感しやすい。LLM 単体ではラオス語の専門知識がほぼないため、FAQ 50 件分のナレッジを入れるだけでも回答の正確性が劇的に変わる。「ゼロの状態に 50 件入れる」効果は、「1,000 件の状態に 50 件足す」効果より遥かに大きい。

扱える。ナレッジベースに各言語のドキュメントを格納し、メタデータの言語コードでフィルタリングすればよい。当社のシステムでは日本語・英語・タイ語・ラオス語の 4 言語を 1 つの RAG パイプラインで処理している。タイ語はラオス語と文字体系・文法が近縁のため、同じチャンキング戦略・エンベディングモデルで対応できる。

FAQ 対応レベル（ナレッジ 100 件以下）なら 2〜4 週間で構築可能。月額のインフラ・API コストは $200〜500 程度だ。業務システム連携を含む本格的なチャットボットは 2〜3 ヶ月、月額 $500〜2,000 が目安になる。コストの大部分は LLM の API 利用料であり、ラオス語はトークン膨張で英語の 2〜3 倍かかる点を予算に織り込む必要がある。

ラオス語は世界の主要 LLM にとって「ほぼ知らない言語」だ。だからこそ、RAG によるナレッジ補完が決定的な差を生む。適切なチャンキング戦略、リランキングによる検索精度の向上、品質の自動モニタリング——この 3 つを組み合わせることで、低リソース言語でも信頼性の高い応答が実現できる。

本記事で解説した 5 ステップを振り返る。

1. ラオス語の特性に合ったテキスト分割（recursive 戦略 + オーバーラップ）
2. Supabase pgvector によるベクトル DB 構築（言語コード付きメタデータ）
3. 50 件取得 → リランキング → 5 件の検索パイプライン
4. Bedrock Claude によるストリーミング応答 + 言語制御プロンプト
5. Mastra Evaluations による 3 指標の自動モニタリング

チャットボットの AI セキュリティ対策は「ラオス企業の AI セキュリティ対策チェックリスト」で詳しく解説している。AI 導入の全体像を把握したい方は「ラオス企業の AI 導入ガイド」も参考にしてほしい。