仕組み
「なぜその回答か」を、
仕組みから説明します。
御社の規約・マニュアルをどうナレッジツリーにし、会話中にAIがどう辿って答え、なぜRAG（類似検索）より取り違えにくいのか。VoiceCoreの技術的な仕組みを、包み隠さずご紹介します。
柱① コーパスの作り方
「問い合わせを受けるデータベース」は、こう作ります。
VoiceCore が参照する知識データベースは、御社がすでにお持ちの規約・マニュアル・FAQから作ります。新しいデータベースをゼロから用意していただく必要はありません。
Step 1 — 文書をお預かりする
既存の利用規約・マニュアル・FAQ・社内規程など、テキストで読める文書をお預かりします。Word/PDF/Markdownなど形式は問いません（テキスト化してご提供いただきます）。
Step 2 — ナレッジツリーへコンパイルする
お預かりした文書を、Corpus2Skill という手法でオフライン処理し、「階層ごとに要約を持つツリー構造」へ変換（コンパイル）します。たとえば「規約 → 解約手続き → 年額プラン → 解約条件」というように、文書の論点を目次のように階層化します。
Step 3 — 各階層に要約、葉に本文を配置する
ツリーの各階層には、その枝が何についての内容かを示す要約（SKILL.md）を置きます。一番下の葉（ノード）には、実際の文書本文（docID付き）が紐づきます。
Step 4 — 更新はコーパスの変更時だけ
規約やマニュアルを改定したときに、同じ手順でツリーを作り直します。会話のたびに検索インデックスを再構築するような重い処理はありません。
実際にどんな条件分岐を扱えるかは、活用事例でご覧いただけます。
柱③ なぜRAGより正確か
「似ている」で探すか、「どちらか」を選び切るか。
条件分岐の多い業務文書（年額/月額、雇用形態別の制度など）で事故が起きやすいのは、多くのAIが採用する検索方式（RAG）が「意味の近さ」で断片を拾う方式だからです。VoiceCoreは、ツリーを辿って「どちらか一方」を選び切る方式を採用しています。
RAGの弱点
RAG（検索拡張生成）は、質問文と文書の断片を「埋め込みベクトルの近さ」で比較し、似ている断片を複数拾って回答を組み立てます。「年額プランの解約」と「月額プランの解約」は言葉として非常に近いため、ベクトルの近さだけでは区別しづらく、条件分岐の多い文書ほど隣接した誤った断片を拾いやすくなります。しかも「なぜその断片を選んだか」を後から説明するのが難しく、誤りに気づきにくいという問題もあります。
VoiceCoreのツリー探索
VoiceCoreは、ナレッジをあらかじめ階層構造（ツリー）へコンパイルしておき、会話中は各階層の要約を読みながら「解約手続き」→「年額プランか、月額プランか」→「解約条件」というように、目次を辿るように一段ずつ絞り込みます。各段でAIは選んだ理由を言語化し、そのまま記録に残します。「似ている」ではなく「どちらか一方」を選び切る操作の連続なので、条件分岐での取り違えが構造的に起きにくくなります。
答えられないときは、答えない。
ツリーのどこにも該当する文書が見つからない場合、VoiceCoreは無理に断片をつなぎ合わせてそれらしい回答を作りません。「コーパス外の質問」として正直に保留し、あらためて確認する案内に切り替えます。何かしらの断片を必ず返してしまいがちなRAGに比べ、「わからないものはわからないと言う」ことができる設計は、ハルシネーション（もっともらしい誤答）を防ぐ上での重要な安全策です。
この探索手法は、論文 “Don't Retrieve, Navigate”（Sun, Wei, Hsieh, 2026）と、その実装であるオープンソースプロジェクト Corpus2Skill にもとづいています。
契約後の価値
足跡ログは、導入して終わりではありません。
探索が「どのノードを、どんな理由で選んだか」は、1回の会話ごとに記録されます。この記録は導入時の検証だけでなく、契約後も継続して確認できる価値です。
会員エリアでは、各会話の探索経路・選択理由・参照した文書ID・所要時間を確認できます。「なぜこの回答をしたのか」を、あとから人が読んで検証できることが、サポート業務の説明責任やコンプライアンス対応において重要になります。
足跡ログの実際の見え方は、体験会話（再現デモ）でご覧いただけます。
現在地