長年の業務システム設計やAIエージェント開発の現場において、B2B領域で最も頻繁に直面し、かつ最も解決が難しい課題の一つが「言葉の壁」です。
ここで言う「言葉の壁」とは、英語や日本語といった自然言語の違いではありません。「汎用的なLLMが学習した言葉」と「特定の企業や業界だけで通じる言葉」の間の深い溝のことです。
多くの組織がRAG（検索拡張生成）を導入し、社内ドキュメントを検索できるようにすれば、AIは魔法のように賢くなると期待します。しかし、現実はそう甘くありません。検索結果には正しいドキュメントが含まれているのに、LLMがその内容を誤解釈したり、社内特有の略語を一般的な意味で捉えてトンチンカンな回答を生成したりする。
「プロンプトに用語集をコピペすればいいのでは？」
そう考える方もいるでしょう。小規模なプロトタイプならそれでも動くかもしれません。しかし、数千、数万の専門用語を抱えるエンタープライズ環境において、そのアプローチは破綻します。トークン制限、レイテンシ、そして何より「文脈の欠落」が壁となるからです。
今回は、単なる辞書登録ではない、システムとして自動化・最適化された「コンテキスト設計」のアーキテクチャについて、実践的なノウハウを共有します。AIに言葉の意味だけでなく、その背景にある「関係性」を理解させるためのデータ構造と実装ルート。これを理解し、まずは手を動かして検証することで、AIプロジェクトは「実験」から「実用」へと大きく前進するはずです。
1. 専門ドメインにおける「言葉の壁」とコンテキスト設計の必要性
GPT-4oなどの旧モデルから、100万トークン規模の長大なコンテキストを処理できる最新のGPTシリーズ（GPT-5.4ファミリーなど）へと進化し、Claudeシリーズも高度な推論能力を獲得しています。このようにLLMの性能が飛躍的に向上しても、組織固有の「製品コード」や「プロジェクト名」を正確に扱う場面では、依然として予期せぬエラーが発生するケースは珍しくありません。
まずはLLMが言葉を処理するメカニズムの限界を紐解き、なぜモデルの進化だけでは解決できないのか、そして外部からの知識注入（コンテキスト設計）が不可欠となる技術的な背景を論理的に整理しましょう。
汎用LLMが専門用語を誤解するメカニズム
入力されるテキストは、LLMの内部で「トークン」と呼ばれる数値の列に変換されて処理されます。このトークン化（Tokenization）のプロセスにこそ、専門用語を正確に理解するための最初の障壁が存在します。
一般的なLLMのトークナイザーは、インターネット上に存在する膨大なテキストデータ（Webページ、書籍、Wikipediaなど）の統計的な分布に基づいて学習されています。その結果、「Apple」や「Computer」といった一般的な英単語、あるいは日常的に使用される日本語の単語は、1つのまとまったトークンとして極めて効率的に処理されます。
しかし、組織独自の製品名（例えば X-99 Alpha）や、業界特有の専門用語（例えば化学物質の Methylchloroisothiazolinone）を入力した場合は挙動が異なります。これらは一般的な学習データに頻出しないため、トークナイザーによって無意味なサブワード（部分文字列）へと細切れに分解される傾向があります。
- 人間が認識する単語:
Methylchloroisothiazolinone - LLM内部でのトークン分割例:
Meth+yl+chloro+iso+thi+azol+inone
このように細分化された状態では、LLMにとってそれは「ひとつの意味を持った概念」ではなく、「統計的に出現確率の低い文字の羅列」として認識されやすくなります。結果として、その単語が本来持っている固有の意味情報やドメイン知識が希釈され、文脈を正確に捉え損ねるリスクが急増する構造になっています。
トークン化の弊害と意味情報の欠落
さらに実務の現場で直面しやすいのが「多義語」に起因する問題です。例えば、製造業のプロセス設計において「Wafer（ウェハー）」という単語を使用した場合、文脈の与え方が不十分だと、LLMが「お菓子のウエハース」に関連する一般的な意味ベクトルに引きずられ、半導体基板に関する技術的な説明の中に不適切な比喩表現を混入させてしまう現象が報告されています。
これは、LLMがその単語を「特定の専門領域における専門用語」として強く定義づけるためのコンテキストを保持していないために発生します。汎用モデルは常に「確率的に最も妥当な次の単語」を予測しますが、その確率はあくまで一般的なインターネット上の分布に依存します。専門性の高いドメインにおいては、この「一般的な確率分布」そのものが、正確な推論を妨げるノイズとして作用します。
こうした課題に対処するため、実務の現場では、Claudeシリーズなどで見られるように、プロジェクト固有の定義ファイル（CLAUDE.mdなど）やシステムプロンプトを用いて、事前にドメイン知識や制約事項を明示的に与えるアプローチが推奨される傾向にあります（最新の推奨ワークフローや詳細な設定方法については、必ず公式ドキュメントをご確認ください）。
ファインチューニング対コンテキスト注入のコスト比較
専門用語の理解精度を向上させる手段として、「自社データを用いたファインチューニング（追加学習）」を検討する組織は少なくありません。モデル自体の重みを更新すれば、特定のドメインにおけるトークンの扱いや用語の理解力は確かに向上します。
しかし、多くのエンタープライズ環境において、ファインチューニングを最初の選択肢として採用することには経営的視点からも慎重な判断が求められます。その主な理由は以下の3点に集約されます。
- コストとリードタイム: 高品質な学習データセットの構築と、計算リソース（GPUなど）の確保に多大な投資が必要となります。
- 情報の鮮度維持: 組織内の用語や製品仕様は日々更新されます。新しい情報が発生するたびにモデルを再学習させる運用は、アジャイルな開発環境において現実的なアプローチとは言えません。
- 忘却（Catastrophic Forgetting）: 特定の専門領域にモデルを過剰に適応させることで、元々備わっていた高度な汎用言語能力や論理推論能力がトレードオフとして低下するリスクを伴います。
対して、ここで提唱する「コンテキスト設計（RAG + 用語集注入）」というアプローチは、モデルの重みには一切手を加えず、入力時（プロンプト）に動的かつ正確な知識を補完します。特に最新のGPTシリーズが100万トークン規模のコンテキストウィンドウをサポートするようになった現在、膨大な用語集や知識グラフを直接プロンプト内に展開する手法の優位性は飛躍的に高まっています。
これは「静的知識（学習済みモデル）」と「動的知識（外部から注入するコンテキスト）」の役割分担を明確に切り離すアーキテクチャ設計であり、コストパフォーマンスとメンテナンス性の両面において、変化の激しい現代のビジネス環境に最も適した選択肢と言えます。なお、利用可能なコンテキスト長やAPIの最新の料金体系については、各プロバイダーの公式サイトで最新情報をご確認ください。
2. コンテキスト注入システムの全体アーキテクチャ
では、具体的にどのようなシステムを組めばよいのでしょうか。単にプロンプトにテキストを連結するだけのスクリプトではありません。エンタープライズレベルで運用可能な「コンテキスト注入パイプライン」の全体像を描きます。まずはプロトタイプとして小さく作り、検証を重ねていくことが重要です。
用語集管理システム（TMS）とLLMの連携フロー
システムは大きく分けて「管理プレーン」と「推論プレーン」の2つで構成します。
管理プレーン（TMS: Terminology Management System）:
- 用語、定義、同義語、関係性を管理するマスターデータベース。
- ドメインエキスパートがGUIで編集し、承認フローを経て確定データをAPIで提供します。データガバナンスの観点からも、この一元管理は不可欠です。
- ここでのデータは構造化（JSON/Graph）されており、バージョン管理されます。
推論プレーン（Inference Pipeline）:
- ユーザーからのクエリを受け取り、リアルタイムで必要なコンテキストを構築してLLMに投げる実行環境。
クエリ解析・用語抽出・プロンプト生成の3層構造
推論プレーンの中身をさらに分解すると、以下の3つのステップが重要になります。
Step 1: エンティティ抽出（Entity Extraction）
- ユーザーの入力文から、専門用語候補を特定します。ここでは、単純なキーワードマッチングだけでなく、Named Entity Recognition (NER) モデルや、軽量なLLMを用いて「用語らしきもの」を抽出します。
- 例：「KnowledgeFlowの導入コストを知りたい」→ 抽出：
KnowledgeFlow
Step 2: コンテキスト検索（Context Retrieval）
- 抽出されたエンティティをキーにして、TMSから定義情報を取得します。ここで重要なのは、単語そのものの定義だけでなく、「関連する用語」や「使用上の注意」もあわせて取得することです。
Step 3: 動的プロンプト構築（Dynamic Prompt Construction）
- 取得した情報を、LLMが理解しやすい形式（後述）に整形し、システムプロンプトやユーザープロンプトの一部として注入します。
RAG（検索拡張生成）パイプラインへの組み込みポイント
多くの組織で導入が進むRAG（ドキュメント検索）と、この用語集注入はどう共存すべきでしょうか。
推奨するアーキテクチャは「用語集ファースト、ドキュメントセカンド」です。
まず用語集を参照してクエリ内の専門用語の意味を確定させます。その「定義情報」を使って、ドキュメント検索（ベクトル検索）のクエリを拡張（Query Expansion）するのです。
例えば、ユーザーが「KFの仕様は？」と聞いたとします。いきなりドキュメントを検索しても、「KF」が何かわからなければノイズがヒットします。用語集で KF = KnowledgeFlow という同義語定義を取得し、検索クエリを「KnowledgeFlow 仕様」に変換してからドキュメントを探す。このワンクッションが、検索精度（Recall/Precision）を劇的に向上させます。
3. AIに伝わる「構造化用語集」のデータモデリング
システムがあっても、肝心のデータが「Excelの表」レベルではAIには伝わりません。人間用の辞書とAI用の辞書は設計思想が異なります。AIには曖昧さを排除した構造化データが必要です。
Key-Value型辞書からの脱却：JSON-LDとRDFの活用
単なる 用語: 定義 のペアではなく、属性を持たせたオブジェクトとして管理します。JSON-LD（JSON for Linking Data）の形式を推奨します。これにより、将来的にはナレッジグラフへの拡張も容易になります。
以下は、プロトタイプ開発でもすぐに試せる用語データのスキーマ例です。
{
"@context": "http://schema.org/",
"@type": "DefinedTerm",
"termCode": "PROD-001",
"name": "KnowledgeFlow",
"description": "B2B企業向けのAI駆動型ナレッジプラットフォーム。RAGと用語集管理を統合したソリューション。",
"synonyms": ["KF", "ナレッジフロー", "K-Flow"],
"category": "SaaS Product",
"attributes": {
"releaseDate": "2023-10",
"targetUser": "Enterprise"
},
"relatedTerms": [
{
"term": "RAG",
"relationship": "usesTechnology"
},
{
"term": "Context Injection",
"relationship": "coreFeature"
}
],
"disambiguation": "水流シミュレーションソフトの'KnowledgeFlow'とは別物です。"
}
同義語・略語・多義語の管理スキーマ設計
上記のJSON例で特に重要なのが synonyms（同義語）と disambiguation（曖昧性解消）のフィールドです。
- Synonyms: ユーザーは正式名称で検索してくれません。「KF」「あのツール」など、揺らぎを吸収するために必須です。
- Disambiguation: 社内用語が一般的用語と被る場合（例：「Galaxy」がスマホではなく社内サーバーのコードネームである場合など）、明示的に「〜ではない」と否定する情報を入れることで、LLMのハルシネーション（幻覚）を強力に抑制できます。倫理的かつ信頼性の高いAIを構築する上で、この制御は極めて重要です。
関係性の定義：『is-a』『part-of』関係の記述
用語は孤立して存在しません。relatedTerms 配列を使って、用語間の関係をグラフ構造として定義します。
- is-a (継承関係):
KnowledgeFlowis aSaaS Product. - part-of (構成関係):
Vector Databaseis part ofKnowledgeFlow.
この関係性をコンテキストとして渡すことで、LLMは「KnowledgeFlowについて教えて」と聞かれた時に、「SaaS製品としての特徴」や「構成要素であるVector Database」についても推論のスコープを広げることが可能になります。これが「知識グラフ（Knowledge Graph）」的アプローチの第一歩です。
4. 動的コンテキスト注入（Injection）の実装パターン
データ構造が決まったら、次はいかにしてそれをプロンプトに流し込むかです。ここでは「精度」と「コスト（トークン消費量）」のトレードオフを考慮した実装パターンを解説します。まずはReplitやGitHub Copilotを活用して、素早くモックアップを構築してみることをお勧めします。
キーワードマッチング方式 vs ベクトル類似度方式
用語を特定する方法には2つの流派があります。
完全一致（Exact Match） / 辞書ベース:
- Aho-Corasick法などの高速な文字列探索アルゴリズムを使用。
- メリット: 確実性が高い。型番や製品コードなど、一文字でも違うと意味が変わるものに最適。
- デメリット: 表記揺れに弱い（辞書に登録がないとヒットしない）。
ベクトル検索（Semantic Search）:
- 入力クエリを用語集のベクトルインデックスと照合。
- メリット: 表記揺れや、「〜みたいなやつ」という曖昧な表現でもヒットする。
- デメリット: 閾値設定が難しく、関係ない用語まで拾ってしまうリスクがある。
推奨する「ハイブリッド・インジェクション」:
まず完全一致で確定的な用語を拾います。次に、残った部分についてベクトル検索を行い、類似度の高い用語を候補として抽出します。これにより、精度と柔軟性を両立させます。
コンテキストウィンドウへの最適配置戦略
抽出した用語定義をプロンプトのどこに置くかは、LLMの注目度（Attention）に影響します。
一般的な傾向として、プロンプトの先頭（System Prompt直下）または末尾（User Query直前）に配置された情報が最も重視される傾向があります（Lost in the Middle現象）。
以下のようなプロンプトテンプレートを設計します。
## System Role
あなたは弊社のAIアシスタントです。以下の「ドメイン用語集」の定義を厳密に遵守して回答してください。
## Domain Glossary
<glossary>
<term name="KnowledgeFlow">
<def>B2B企業向けのAI駆動型ナレッジプラットフォーム...</def>
<note>水流ソフトではないことに注意</note>
</term>
<term name="RAG">
<def>...</def>
</term>
</glossary>
## User Query
{{user_input}}
XMLタグ（<glossary>, <term>）を使用することで、LLMに対して「ここからここまでが用語定義である」という構造を明確に伝えます。これにより、通常の指示テキストと用語定義が混同されるのを防ぎます。
関連用語の芋づる式取得（グラフ探索）の実装
高度な実装として、抽出された用語の「隣接ノード」もコンテキストに含める手法があります。
例えば、「KnowledgeFlow」がクエリに含まれていた場合、その定義だけでなく、relatedTerms にある「RAG」や「Context Injection」の定義も一緒にプロンプトに含めます。
これにより、ユーザーが直接言及していなくても、背景知識として必要な情報を先回りしてLLMに提供でき、回答の深みが格段に増します。ただし、トークン数を圧迫しないよう、探索の深さ（Hop数）は1〜2程度に制限するのが定石です。
5. 運用と評価：用語集のライフサイクル管理
システムを構築して終わりではありません。言葉は生き物であり、ビジネスの変化とともに進化します。最後に、持続可能な運用のためのLLMOps（LLM運用基盤）の視点を提供します。
LLMの回答ログからの未知語検出ループ
用語集をメンテナンスする際、ドメインエキスパートがゼロから思い出すのは困難です。最も効率的なのは、ユーザーとAIの対話ログを活用することです。
- ユーザーのクエリ内で、用語集にヒットしなかった名詞句を抽出する。
- その出現頻度をカウントする。
- 頻出する「未知語」をリストアップし、管理者に「これを用語集に追加しますか？」とレコメンドする。
この「未知語検出ループ」を自動化することで、用語集は現場のニーズに合わせて勝手に育っていきます。
ドメインエキスパートによる定義のレビュー体制
AIエンジニアだけで用語集を作るのは危険です。定義の正確性を担保できるのは、現場の人間だけだからです。
しかし、現場の人間にJSONを書かせるわけにはいきません。直感的なGUI（管理画面）を提供し、エンジニアは裏側のスキーマ設計に徹する。この役割分担がプロジェクト成功の鍵です。
コンテキスト注入効果の定量評価指標（回答正確性、幻覚率）
コンテキスト設計の効果はどう測定すべきでしょうか。以下の指標を定点観測することを推奨します。
- Terminology Coverage (用語カバー率): ユーザー入力に含まれる専門用語のうち、用語集で定義されている割合。
- Definition Adherence (定義遵守率): 生成された回答が、注入された定義と矛盾していないかを、別のLLM（Evaluator）を使って判定させます。
- Hallucination Rate (幻覚率): 専門用語に対して誤った説明をした割合。
これらをダッシュボード化し、用語集の更新前後でスコアがどう変化したかを追跡します。数値が改善していれば、コンテキスト設計は正しく機能していると言えます。
まとめ：コンテキスト設計は「AIへの教育」そのもの
ここまで、ドメイン特化型AIのためのコンテキスト設計について、アーキテクチャの視点から解説してきました。
- トークン化の壁を理解し、外部知識として補完する戦略をとる。
- 構造化データ（JSON/Graph）で用語の意味と関係性を定義する。
- 動的注入パイプラインで、必要な時に必要な知識だけをLLMに渡す。
- 運用ループを回し、用語集を常に最新の状態に保つ。
これらは、単なるシステムのチューニング作業ではありません。組織の文化、知識、暗黙知を言語化し、AIという新しい同僚に丁寧に教えていく「教育」そのものです。
しかし、これら全てのアーキテクチャ（用語抽出、ベクトル検索、グラフ管理、注入ロジック、評価ループ）を自社でスクラッチ開発するのは、エンジニアリングリソースの観点から現実的でない場合も多いでしょう。特に、用語集のGUI管理や、RAGとの高度な連携部分は、車輪の再発明になりがちです。まずは既存のツールやプロトタイプ開発を通じて仮説を検証し、ビジネスへの最短距離を描くことが、AIプロジェクトを成功に導く確実なアプローチとなります。
コメント