ホワイトペーパー

目次

• 1. 要旨（Executive Summary）
• 2. 背景と問題設定
• 3. 基本概念：AIとデータベースの再定義
• 4. 提案：軽量クエリDB / 擬似AI（Pseudo-AI Database）
• 5. コア技術
• 5.1 曖昧クエリ正規化（入力空間の圧縮）
• 5.2 ビット並列・分岐レス推論（bitset / popcount）
• 5.3 近傍探索（指紋化 + 候補抽出 + スコア補正）
• 5.4 出力合成（テンプレ + 条件分岐 + 根拠提示）
• 6. データ構造：構造共有・Index/Payload分離・Lazy-load
• 7. 実行環境：WASMランタイムと並列化
• 8. ビルド（生成）パイプラインと蒸留の位置づけ
• 9. 評価方法（性能・品質・安全性）
• 10. 適用領域とユースケース
• 11. 研究開発ロードマップ
• 12. 結論
• 付録A. 参考用スキーマ（案）
• 付録B. 用語集

1. 要旨（Executive Summary）

本書は、株式会社バースファクトリーの研究事業として、「軽量で極めて柔軟なクエリを持つデータベース」および「準AI / 擬似AI（Pseudo-AI）」の概念と技術的骨格を提示するものである。 提案するシステムは、機械学習モデル（LLMを含む）を実行時に使用しない。一方で、人間が自然言語で行う曖昧な問いに対し、AIに類似した応答（意図推定・候補提示・根拠提示・回答合成）を、決定論的な計算のみで実現する。 本研究の中核は次の3点に集約される。

• 入力空間の圧縮：曖昧な自然言語クエリを、正規化・同義語変換・クエリ型への写像によって「探索しやすい形」に折り畳む。
• 低計算量の探索：bitset / popcount を中心とした分岐レス推論と、指紋化（例：SimHash）を用いた近傍探索により、CPU上で高速にTop-K候補を得る。
• 軽量な生成：回答を「部品（テンプレ・注意・例外・根拠）」として保持し、条件分岐と合成で文章化することで、生成モデルなしに説明力を確保する。

また、大規模知識の取り扱いにおいては、Index/Payload分離とLazy-load、ならびに内容アドレス（ハッシュ）による構造共有を採用し、数十MBから数百MB規模の知識を、ブラウザ等のクライアント環境に段階的に蓄積させる。 本書は、(1)思想の固定、(2)技術の骨格提示、(3)実装と権利化（特許）に向けた論点整理を目的としており、以後の論文・特許申請・開発設計・実装指示の共通土台となる。

2. 背景と問題設定

現代のAI（特に大規模言語モデル）は、曖昧な自然言語を扱える点で強力である一方、推論コスト・運用コスト・規制対応・機密性の面で課題が残る。

• 計算コスト：GPU依存、推論の都度コストが発生し、利用回数に比例して費用が増大する。
• 運用制約：オンライン前提、レイテンシや障害に影響される。
• 統制：出力の非決定性、説明可能性の不足、監査や再現性の難しさ。
• データ統治：機密情報・個人情報を扱う領域では、外部API依存が難しい。

一方で、実務の問い合わせ・ナレッジ検索・手順案内といった用途では、入力の多様性は大きく見えても、意味的には反復パターンが多い。すなわち「曖昧さに耐える」ことは重要だが、必ずしも「汎用知能」までは必要ではないケースが多い。 本研究はこのギャップに着目し、AIの代替ではなく、AIが担っている役割の一部（曖昧クエリの吸収と柔軟応答）を、より軽量・決定論的な構造で再構成する。

3. 基本概念：AIとデータベースの再定義

本研究では、AIとデータベースを次のように捉え直す。 データベースとは「クエリと結果の対応関係（写像）の集合」である。 AIとは「曖昧なクエリに耐える巨大な写像を、近似的に実現する仕組み」である。 この見方に立てば、AIとDBの差は本質的には「曖昧さ耐性」である。入力（クエリ）の曖昧さを吸収し、適切な結果を返すことができるなら、その振る舞いはAIに類似する。 従来DBは厳密なクエリを前提とし、AIは曖昧なクエリを扱う。擬似AIはこの間を埋める：曖昧なクエリを、設計により「探索しやすい形」に変形し、決定論的探索で解を得る。

4. 提案：軽量クエリDB / 擬似AI（Pseudo-AI Database）

本書では、提案するアーキテクチャを「Pseudo-AI Database（PADB）」と呼ぶ。PADBは、入力（in）と出力（out）の関係を、圧縮・共有・索引化されたデータ構造として保持し、実行時は軽量な探索と合成のみで応答する。

4.1 設計原則

• 決定論性：同一入力に対して同一出力（または同一候補集合）を返す。
• 低計算量：実行時にGPUや重い行列演算を必要としない。
• 説明可能性：候補・スコア・根拠をユーザに提示できる。
• 段階的知識：Index/Payload分離とLazy-loadで、知識を必要に応じて拡張する。
• 構造共有：共通部分（辞書・テンプレ・定型句・ルール）を共有し、差分で拡張する。

4.2 全体アーキテクチャ

PADBは大きく「ランタイム（WASM等）」「データ（パック）」「ビルド（生成）工程」に分かれる。 【図1：PADBの処理フロー（概念）】

User Query
   ↓
Normalize（正規化・同義語・型推定）
   ↓
Route（パック/意図の選定：bitset推論）
   ↓
Retrieve（近傍探索：指紋 + 候補抽出 + スコア補正）
   ↓
Assemble（回答合成：テンプレ + 条件分岐 + 根拠）
   ↓

Response（即答 + 追記で濃くする）

5. コア技術

5.1 曖昧クエリ正規化（入力空間の圧縮）

擬似AIの性能は、検索アルゴリズム以上に「正規化」に依存する。曖昧さの多くは、表記ゆれ・誤字・同義語・冗長表現に起因するためである。 本研究では、正規化を「入力空間の設計的圧縮」とみなし、次を段階的に適用する。

• 文字正規化：全半角、大小、記号、連続空白、数字表記などを統一する。
• 同義語正規化：ドメイン辞書により、語彙の揺れを代表語へ写像する（例：サインイン=ログイン）。
• クエリ型推定：定義/手順/比較/障害/規程など、有限個のクエリ型に写像し、探索空間を狭める。

この工程により、自由文の多様性を抑えつつ、探索と合成が当たりやすい表現へ変換する。

5.2 ビット並列・分岐レス推論（bitset / popcount）

ニューラルネットの文脈では、ゲートや活性を連続値（float等）で表現することが多い。しかし多くの判定・ルール適用は、本質的には真偽（1ビット）で十分である。 本研究では、クエリの特徴をbitsetとして表現し、ルールをビットマスクとして評価する。評価は分岐（if）を避け、ビット演算とpopcount（ビット数計数）で行う。これによりCPUワード幅で並列に多数の条件を処理でき、WASM上でも高速化しやすい。

【例：必須語/禁止語ルールの評価（概念）】
feature: u64[]  // クエリ特徴bitset
must:    u64[]  // 必須語マスク
forbid:  u64[]  // 禁止語マスク

ok_must   = ((feature & must) == must)     // 全部含む
ok_forbid = ((feature & forbid) == 0)      // 禁止語を含まない
score     = popcount(feature & boostMask)  // 追加スコア

この仕組みは、(a)意図推定、(b)パック選定（ルーティング）、(c)候補スコア補正、といった内部推論に適用できる。

5.3 近傍探索（指紋化 + 候補抽出 + スコア補正）

PADBは、クエリと知識エントリの「距離」を軽量に近似し、Top-K候補を返す。重いベクトル計算ではなく、指紋化（例：SimHash）と候補抽出（LSH的バケット）により、計算量を抑える。

• 指紋化：正規化されたテキストから、64bitまたは128bit程度の指紋を生成する。
• 候補抽出：指紋の一部をキーとしてバケット化し、近い候補のみを収集する（全件比較を避ける）。
• スコア補正：intent一致、必須語一致、否定語、数字/固有名詞一致などでスコアを調整する。

この構成により、曖昧クエリでも「それっぽい候補」が安定して上位に出る。さらに候補集合を提示することで、ユーザに探索余地と納得感を与える。

5.4 出力合成（テンプレ + 条件分岐 + 根拠提示）

LLMのような逐語生成を行わずとも、回答を部品化し合成することで、実用上十分な説明力を得られる。回答は一般に、結論・手順・注意・例外・参照（根拠）から構成できる。

• テンプレ合成：定型文 + スロット（変数）埋め込みで文章化する。
• 条件分岐：ユーザ条件（法人/個人、地域、プラン等）により、注意や例外を切り替える。
• 根拠提示：参照エントリID、出典段落、関連候補などを表示可能にする（Explainモード）。

「即答（暫定）→ 追記で濃くする」という表示戦略により、体感レイテンシを小さくしつつ、ユーザの不安を抑える。

6. データ構造：構造共有・Index/Payload分離・Lazy-load

6.1 構造共有（内容アドレス化）

大規模知識をそのまま文章として保持すると重複が多く、更新差分も大きくなる。PADBでは、回答部品・定型句・辞書エントリ・ルールを小さなノードに分割し、内容ハッシュをIDとして参照する（内容アドレス化）。

• 同一内容は同一IDになるため、重複が自然に排除される。
• 差分更新では、変更ノードのみ追加すればよい。
• 複数のパック間で共通部品（辞書・テンプレ等）を共有できる。

6.2 Index/Payload分離

I/OとCPUのバランスを取る上で重要なのは、探索に必要な情報（Index）と、表示に必要な情報（Payload）を分離することである。

• Index層：指紋、バケット、intent、bitsetマスク、オフセット等（小さく、常駐させる）。
• Payload層：回答本文、手順詳細、根拠テキスト、例外一覧等（必要時に取得）。

IndexのみでTop-K候補を確定し、上位数件のPayloadのみを遅延取得することで、初期応答を高速化できる。

6.3 パック（Pack）とLazy-load

知識は用途・ドメインごとにパック化し、ブラウザ等のクライアントに段階的に蓄積させる。

• Core Pack：正規化辞書、ルーティング、汎用エントリ（数MB）。
• Domain Pack：特定領域のエントリ群（数十MB〜数百MB）。
• 差分配布：Packはバージョン管理し、更新時は差分の分配布可能にする。

パックは静的ファイルとして配布可能であり、Service WorkerやIndexedDB等のクライアント機構により、オフライン動作や再訪時ゼロI/Oを実現できる。

6.4 クラウド辞書（CAS/KV/CDN）によるLazy-load 2.0（Edge-Computed Hash）

Lazy-loadをさらに拡張し、巨大な辞書（回答部品、根拠、長文手順等）をクラウド上のストレージ/CDNに配置しつつ、クライアント（エッジ）側で参照キーを決定論的に計算する方式を導入する。本方式ではクラウド側が計算を担わず、Key→Object参照のみを提供するため、推論コストをI/Oへ置換できる。 鍵となるのは「セマンティックキー（意味ハッシュ）」である。セマンティックキーは、正規化済みクエリから特徴（bitset/指紋/意図・スロット）を生成し、固定長ビット列へ写像したもので、表記ゆれ・言い換えの差を吸収しつつ、近い問いが近いキーに写像されることを狙う。

• エッジ計算：Normalize→Featurize→（必要ならRoute）→セマンティックキー生成。
• クラウド辞書：セマンティックキー→候補ID集合（小さなIndex）、候補ID→Payload（本文/部品）の2層参照。
• 二段階キー：近似キー（セマンティックキー）と完全キー（内容ハッシュ）を併用し、衝突と重複を実務的に扱う。
• キャッシュ：Service Worker/IndexedDB等でホットなキーとPayloadを保持し、再訪時のI/Oをゼロに近づける。
• フォールバック：ネットワーク不可時やミス時はローカルPackの範囲で応答し、体験の破綻を防ぐ。

セマンティックキーは完全一致ではなく近傍探索の入口として用いる。候補ID集合を取得した後、クライアント側で指紋距離・必須語・否定などを用いてTop-Kを確定し、必要なPayloadのみを追加取得する。これにより、I/Oは「少数の参照」に抑えつつ、曖昧さ耐性を維持できる。 運用上は、辞書オブジェクトの署名・バージョン管理・差分配布を前提とし、キー生成仕様と辞書内容の互換性を維持する。また、クエリ由来の参照パターンが機密となる領域では、テナント単位の鍵（例：HMAC）や顧客環境内配備により情報漏えい面の懸念を低減する。

7. 実行環境：WASMランタイムと並列化

PADBのランタイムは、WebAssembly（WASM）上での実行を主眼に設計する。目的は、クライアント環境での高速・安全・移植性の確保である。

7.1 ランタイムの責務

• 正規化（Normalize）：文字正規化、同義語変換、クエリ型推定。
• 特徴抽出（Featurize）：bitset生成、指紋生成。
• ルーティング（Route）：bitsetルールで対象パック/意図を推定。
• 探索（Retrieve）：候補抽出とTop-Kスコアリング。
• 説明（Explain）：候補スコア、根拠参照、内部状態の表示用データを生成。

7.2 並列化戦略（Worker / Threads）

マルチコア活用は、(a)パック横断探索の並列化、(b)候補スコアリングの並列化、(c)バックグラウンドでのプリフェッチ/解凍、に効果がある。

• 基本：Web Workerにより並列実行し、UIスレッドの負荷を最小化する（広い互換性）。
• 拡張：実行環境が許す場合、共有メモリ（SharedArrayBuffer等）とWASMスレッドを用いて高速化する。
• フォールバック：共有メモリが使えない環境でも動作する設計を維持する。

7.3 I/O設計（スループットと体感）

クライアント実行では、I/O（ネットワーク/ストレージ）とCPUのバランスが支配的となる。PADBはIndex/Payload分離とLazy-loadにより、初期I/OをIndexに限定し、PayloadはTop-K確定後に必要分のみ取得する。 さらに、(1)圧縮（brotli等）、(2)チャンク分割、(3)キャッシュ、(4)差分更新により、I/Oを抑制し、体感レイテンシを最小化する。 Lazy-load 2.0（6.4）では、Indexはクライアントでセマンティックキーを生成し、候補ID集合やPayloadをクラウド辞書（CDN/KV/オブジェクトストレージ）から参照する。このとき支配要因は「往復回数」と「キャッシュヒット率」であり、Top-K確定前に大きなPayloadを取らない設計、バッチ取得、ホットキーの事前取得により体感を安定させる。

7.4 エッジ計算×クラウド辞書：体感性能の設計要点

エッジ計算×クラウド辞書は、クラウド推論を避けながら大規模知識を扱うためのアーキテクチャである。設計上は、(a)キー解決（候補ID取得）と(b)Payload取得を分離し、(a)のI/Oを極小化して即答を実現し、(b)は必要に応じて遅延させる。

• 参照回数を抑える：候補ID集合は1オブジェクト（または少数）に束ね、Top-KのPayloadもまとめて取得できる形式を優先する。
• キャッシュを前提にする：ホットなキー/候補ID集合/上位Payloadを優先的に保持し、P95の体感を改善する。
• 互換性を管理する：キー生成仕様（Normalize/Featurize/Route）と辞書バージョンを結合し、参照先の不整合を防ぐ。
• 安全性を担保する：辞書オブジェクトは署名・整合性検証し、汚染（Poisoning）や改ざんを検出可能にする。

8. ビルド（生成）パイプラインと蒸留の位置づけ

PADBは実行時に学習を行わない代わりに、ビルド時に「in/out写像（クエリと結果の対応）」を高密度に構築する。したがって、品質と効率を左右するのはビルド工程である。

8.1 ビルド工程（概念）

• Ingest：原資料（FAQ、規程、マニュアル、ログ等）を取り込み、単位（セクション/段落/手順）へ分割する。
• Normalize Spec：ドメイン辞書（同義語、略語、固有名詞）とクエリ型を定義する。
• Generate：代表クエリ（canonical）と、その言い換え集合を生成し、意図（intent）とスロット（変数）を付与する。
• Index/Pack：指紋、bitsetルール、参照構造を生成し、Index/Payload分離のパックとして出力する。
• Verify：テストクエリに対する回帰、カバレッジ（穴）検出、サイズ/速度制約チェックを行う。
• Publish：署名・バージョン付け・差分生成により配布可能な形にする。

8.2 蒸留の位置づけ：モデル学習ではなく「写像密度の向上」

近年、強い教師（大規模モデル等）から高品質な出力を得て、より軽い仕組みに知識を移す「蒸留」という考え方が広まっている。PADBでは蒸留を、学生モデルの学習ではなく、in/out写像（クエリ集合と応答部品）の生成に用いる。

• 教師の役割：代表クエリから、言い換え群・意図ラベル・スロット抽出・回答部品化を生成する。
• PADB側：生成されたin/outを重複排除し、構造共有してパックへコンパイルする。
• 経験蒸留（トレース蒸留）：実運用で観測されたクエリと採用回答の対を匿名化・監査可能な形で取り込み、写像（in/out）を増補する。これは『過去に使われたクエリと回答の再利用』であり、推論コストをストレージ参照へ置換する。
• 実行時：推論は検索と合成のみで、教師・モデルは不要（コスト・規制・再現性の観点で有利）。

8.3 コンプライアンスとデータ統治（方針）

蒸留や生成を用いる場合、利用規約・ライセンス・機密情報の扱いが重要となる。PADBの研究事業では、(a)権利・規約に適合する生成手段の選択、(b)顧客データの隔離（顧客環境内での生成を含む）、(c)生成物の監査可能性（出典追跡）を前提とする。

9. 評価方法（性能・品質・安全性）

PADBは「汎用知能」ではなく、用途に対する実用性能を評価する。評価は主として、速度・サイズ・再現性・カバレッジ・説明性で行う。

9.1 性能指標（例）

• 初期応答（P50/P95）：入力から暫定回答までのレイテンシ。
• Top-K確定時間：Index探索で候補集合が確定するまで。
• Payload取得時間：上位候補の詳細取得に要する追加時間。
• メモリ常駐量：Index常駐に必要なメモリ。
• パックサイズ：Core/Domainパックの総量、差分更新量。
• キー解決レイテンシ（P50/P95）：セマンティックキーから候補ID集合（小Index）を取得するまで。
• キャッシュ/CDNヒット率：IndexおよびPayloadのヒット率（オフライン時はローカルヒット率）。
• リクエスト数/クエリ：1クエリあたりのネットワーク往復回数（候補ID取得 + Payload取得）。
• 転送量/クエリ：平均および分位（P50/P95）の送受信バイト数。

9.2 品質指標（例）

• 命中率：テストクエリに対し、正解がTop-Kに含まれる割合。
• 頑健性：誤字・省略・言い換え・否定表現に対する性能低下。
• 説明可能性：根拠提示の有用性（人手評価）、再現性（同一入力で同一結果）。
• カバレッジ：意図（intent）×スロット空間の穴の検出と改善速度。

9.3 安全性とガードレール（例）

実行時に学習を行わない一方で、誤った知識（古い規程、誤記）を保持すれば誤応答となる。したがって、(1)バージョン管理、(2)出典追跡、(3)回帰テスト、(4)更新フローが重要となる。

9.4 整合性・実現性の検討（Lazy-load 2.0を含む）

本節では、提案構造が「決定論」「軽量」「柔軟」「説明可能」という設計原則と整合し、現実的なI/O・運用条件の下で実現可能であるかを確認する。

整合性（コンセプト面） ・AI様応答は、(a)入力正規化、(b)近傍探索、(c)テンプレ合成という決定論的処理の合成として定義される。クラウド辞書の導入は(b)(c)の参照先を拡張するだけであり、学習や確率的生成を導入しない。 ・蒸留（8.2）はモデル圧縮ではなく写像密度の向上であり、経験蒸留（実クエリ/採用回答の再利用）も同一の枠組みに収まる。

実現性（性能・I/O面） ・エッジ側計算はbitset/指紋/キー生成が中心で、CPUのみで十分実装可能である。支配要因はI/Oであり、Index/Payload分離とTop-K確定後取得により、初期転送量と往復回数を抑制できる。 ・クラウド辞書はAPI計算を必要とせず、CDN/オブジェクトストレージ等の参照で成立する。体感はキャッシュヒット率に依存するため、ホットキーの事前取得、候補ID集合の束ね、Payloadのバッチ取得を設計要件とする（7.4）。 ・オフライン/不達時はローカルPackへフォールバックすることで、機能の劣化はあっても破綻は避けられる。

リスクと緩和策（運用・安全性） ・キー衝突/誤参照：セマンティックキーは近似キーとして扱い、候補集合からローカル再スコアリングでTop-Kを確定する。内容ハッシュによる完全参照を併用する。 ・辞書汚染/改ざん：辞書オブジェクトの署名、バージョン固定、回帰テスト、出典追跡を必須とし、更新フローに監査を組み込む。 ・プライバシー：参照キーはクエリそのものではないが、推測可能性が残る。機密領域ではテナント単位の鍵（例：HMAC）や顧客環境内配備、暗号化保管を選択肢とする。

10. 適用領域とユースケース

PADBは、曖昧クエリ吸収と柔軟応答が必要だが、GPU/オンライン/非決定性が障害となる領域に適する。

• 企業内ナレッジ：社内規程、オンボーディング、手順書、問い合わせ一次対応。
• 製品サポート：FAQ、障害切り分け、手順案内（デバイス内完結）。
• 規制・機密領域：医療/金融/官公庁等で、外部推論が難しいケース。
• エッジ/IoT：回線が不安定、計算資源が限られる環境でのガイダンス。
• 教育/学習：誤りや根拠を説明できる、決定論的な学習支援。

また、UIとして「即答 + 候補提示 + 根拠提示」を組み合わせることで、ユーザは探索の主導権を維持しつつ、AI的な支援体験を得られる。

11. 研究開発ロードマップ

11.1 フェーズ1：公開デモ（WASM擬似AIランタイム）

• ブラウザ上で動作するPADBデモを公開する（LLM/GPU不要、決定論的）。
• Core Pack + 1つのDomain Packで、具体的なユースケース（例：企業内ナレッジ）を成立させる。
• Explainモードを備え、候補・根拠・内部状態を可視化する。
• （拡張）Edge-Computed Hash × クラウド辞書（CDN/KV）によるLazy-load 2.0を試験導入し、キャッシュ戦略と体感レイテンシを評価する。

11.2 フェーズ2：ビルド/検証ツールの体系化

• 原資料からパックを生成するビルド工程をCLI/SDK化する。
• 蒸留（写像生成）・重複排除・構造共有・差分更新を自動化する。
• 回帰試験・カバレッジ測定・安全ガードをパイプラインに組み込む。

11.3 フェーズ3：ライセンス提供

株式会社バースファクトリーは、本研究成果を「擬似AIランタイム + 生成/検証パイプライン」としてライセンス提供することを想定する。提供形態は、(a)クライアント組み込み、(b)オンプレ生成、(c)特定ドメインパック提供、等を含み得る。

12. 結論

本研究は、知性を「学習モデル」から切り離し、「クエリ-結果写像の設計と実装」として再構成する試みである。 PADBは、曖昧な自然言語クエリに対して、正規化・ビット並列推論・近傍探索・回答合成を組み合わせることで、軽量・決定論的・説明可能なAI様応答を実現する。 計算資源が貴重な時代において、CPUとI/Oを最適化し、必要な知識を段階的に持ち込む設計は、多くの領域で実用的価値を持つ。株式会社バースファクトリーは、本テーマを唯一の研究事業として継続し、デモ公開・論文化・特許化・実装の体系化へ展開する。

付録A. 参考用スキーマ（案）

本付録は理解補助のための例であり、実装は変更され得る。

【Entry（概念）】
{
  "id": "hash(payload)",                    // 内容ハッシュ（完全キー）
  "intent": "HOWTO",
  "aliases": ["ログインできない", "サインイン不可", "..."],
  "features": {
    "bitset_ref": "hash(bitset)",
    "fingerprint64": 1234567890,
    "semantic_key": "sk64-or-sk128-..."     // 近似キー（意味ハッシュ）
  },
  "answer_parts_ref": "hash(parts)",        // 構造共有された回答部品
  "payload_ref": {
    "local_offset": 1024,                  // ローカルPack内参照（任意）
    "cloud_object": "cas/<hash(payload)>"   // クラウド辞書参照（任意）
  },
  "signature": "sig(...)"                   // 署名（任意）
}
【SemanticKeyIndex（概念）】
{
  "semantic_key": "sk64-or-sk128-...",
  "candidates": [
    { "id": "hash(payload)", "score_hint": 0.92, "payload_ref": "cas/<hash(payload)>" },
    { "id": "hash(payload2)", "score_hint": 0.88, "payload_ref": "cas/<hash(payload2)>" }
  ],
  "version": "pack-vX",
  "signature": "sig(...)"
}

付録B. 用語集

© 2026 Versefactory, Inc. All rights reserved.