Vectaraで社内AIの作り話を見張る方法｜点数を合否にしない

「社内資料を読ませたAIの回答に、資料にない数字がときどき混ざる。全部を人が読み直すなら、AIを入れた意味がない」「作り話を自動で見つける仕組みがあると聞いたが、その点数を信じて回答を出してよいのか分からない」——社内向けのAIを動かし始めた情報システムやAI導入の担当者から、続けて上がってくる声です。作り話の検出は、AIの回答を自動で合格・不合格に振り分ける機械ではありません。本当は、人が読むべき回答に、優先順位を付けるための目印です。この記事では、社内文書に基づく回答の基盤と、作り話の検出モデルHHEMを提供する Vectara を例に、点数の使い方、閾値の決め方、どの業務で効くか、ベンダー自身が出す評価をどう扱うかを整理します。

Vectara は、社内文書に基づいて答える仕組みと、作り話の検出を持つ会社

Vectara は、社内の文書を検索し、その結果に基づいてAIに回答させる仕組み（RAG）を企業向けに提供してきた米国の会社です。2026年10月時点の公式サイトでは、自らを「管理されたAIエージェントを動かす企業向けAI基盤」と説明し、文書の取り込みと解析、検索と根拠づけ、エージェントの組み立てという三つの層で機能を紹介しています。根拠づけの層の中に、作り話の検出と評価が置かれています。

目を引くのは、置き方の選択肢です。公式サイトでは、同社が管理するクラウドのほか、自社が契約するクラウドの専用区画（Amazon・Azure・グーグルのクラウド）、自社のデータセンター、外部のネットワークにつながない環境まで選べると説明しています。回答を作るAIのモデルも、同社のモデルのほか、Claude、Gemini、Llama などを持ち込めるとしています。最近の公式サイトは半導体などの製造業の技術文書の検索を前面に出しており、汎用のチャットではなく、社内の専門文書に基づく回答を固い業界で使う方向に寄せていることが読み取れます。

この記事で扱うのは、そのうち作り話の検出の部分です。Vectara の基盤を丸ごと入れる判断と、検出モデルだけを使う判断は別のものです。検出モデルには、自社の環境で動かせる公開版があるため、すでに別の仕組みで社内向けAIを動かしている会社でも、見張り役だけを足すという選択ができます。どちらの入り方をするかで、データの流れも費用も変わります。

HHEM が測っているのは「渡した資料に書いてあるか」だけ

HHEM は、二つの文章の組を受け取り、後の文章が前の文章に裏付けられている見込みを0から1の点数で返すモデルです。前の文章には検索で見つけた社内資料を、後の文章にはAIが作った回答や要約を入れます。公開版の説明では、0は後の文章が前の文章にまったく裏付けられていないこと、1は完全に裏付けられていることを意味するとしています。

公開版の説明には、誤解しやすい性質が二つ書かれています。一つは向きがあることです。「米国を訪れた」という資料に対して「アイオワ州を訪れた」という回答は作り話と判定されますが、逆の組み合わせなら食い違いなしと判定されます。もう一つは、世の中では正しいことでも、資料に書いていなければ作り話の側に数えることです。資料に「フランスの首都はベルリン」と書いてあれば、「フランスの首都はパリ」という回答は作り話と判定されます。

この性質は、社内向けのAIにとってむしろ都合がよい面があります。社内のAIに求めるのは、一般常識で答えることではなく、自社の資料に書いてある範囲で答えることだからです。ただし裏返せば、資料が古い、資料同士が矛盾している、そもそも必要な資料が検索で拾えていない、といった問題はこの点数には現れません。点数が高い回答でも、拾った資料が間違っていれば回答も間違っています。

公開版と商用版：どちらを使うかで判断が変わる

HHEM には二つの版があります。公開版（2.1）は、Hugging Face で公開され、Apache 2.0 のライセンスで商用にも使えるモデルです。グーグルの公開モデルを土台に調整した小さなモデルで、公式の説明では32ビットの精度で600メガバイト未満のメモリで動き、一般的なCPUで2,000トークンの入力をおよそ1.5秒で処理できるとしています。自社のサーバーで動かせば、資料も回答も社外に出ません。

ただし公開版の対応言語は英語です。日本語の社内資料と回答をそのまま入れても、意図どおりの点数になる保証はありません。日本語を含む11言語に対応しているのは商用版で、こちらは Vectara の基盤を通じてだけ使えると説明されています。Vectara の基盤で検索と回答を行う場合は、問い合わせのたびに点数が自動で返ってきます。基盤を使わずに点数だけを得るための専用の窓口（API）も、2025年4月に試験提供として案内されています。

もう一つ押さえておきたいのが、版の切り替わりです。公式の更新履歴では、2026年8月19日に、点数の計算の既定が商用版の2.3に変わり、引退した2.2の名前で呼んでも2.3が応答するようになったと告知しています。つまり、同じ呼び出し方のまま、裏で使われるモデルが変わることがあるということです。閾値を決めたときのモデルの版を記録しておき、版が変わったら閾値を確かめ直す手順を、運用の中に入れておく必要があります。

2026年の動き：実在と鮮度の確かめ方

海外の小さなツールを社内に入れるときは、会社が動いているか、製品が更新され続けているかを最初に確かめます。Vectara については、公式の更新履歴に2026年10月21日付の変更まで並んでおり、エージェントの評価や画像の受け渡しといった機能の追加が続いています。作り話の検出モデルを使って主要なAIモデルを並べた順位表も、公式の GitHub で2026年10月22日に更新されています。

作り話の検出の周辺では、2025年5月に、回答のどこが資料と食い違っているかを説明し、最小限の修正案を出す仕組み（作り話の修正役）を試験提供として発表しています。検出するだけでなく直すところまで踏み込む方向ですが、修正案もAIが作るものです。修正案を自動で差し替えず、食い違いの説明を人が読んで採否を決める使い方にとどめるのが安全です。

一方で、2026年10月時点で、日本法人や国内の販売代理店、日本語の窓口は公式の資料では確かめられませんでした。契約・請求・問い合わせは英語で進む前提で、社内の調達の手続きに乗るかを先に確かめます。公開版だけを使う場合は契約は不要ですが、そのぶん不具合の問い合わせ先もありません。自社で面倒を見る前提で使うことになります。

順位表とベンダー自身の評価は、参考値として扱う

Vectara の順位表は、AIモデルが文書を要約するときにどれだけ作り話を混ぜるかを比べたもので、海外の記事でもよく引用されます。公式の説明では、ニュース・科学・医療・法務などの7,700本を超える記事を各モデルに要約させ、商用版のHHEM 2.3で食い違いの割合を計算しています。2026年10月の更新では、最も低いモデルで1.8%という数字が並んでいます。

この数字を社内のモデル選びにそのまま使うのは避けます。理由は三つあります。第一に、作り話を判定しているのは Vectara 自身のモデルで、採点者と順位表の作り手が同じです。第二に、評価に使った記事は、過学習を避けるという理由で公開されていません。第三に、測っているのは要約という一つの作業だけで、社内の問い合わせ回答や資料作成とは条件が違います。公式も、要約の質は測っておらず、資料の文を抜き出すだけの要約なら満点になりうるので、この指標だけで判断すべきではないと書いています。

ベンダー自身の評価は、方向を知るための材料にはなります。たとえば、同じ会社のモデルでも版によって作り話の割合が大きく違う、回答を拒む割合も併せて見る必要がある、といった傾向はつかめます。ただし採用の根拠にするのは、自社の資料と自社の問いで測った結果だけと決めておきます。稟議の資料に順位表の数字を載せるなら、誰がどの条件で測った数字かを必ず併記します。

場面1：問い合わせへの回答の下書きを見張る

最も効果が見込みやすいのは、顧客や社内からの問い合わせに、AIが社内資料を検索して回答の下書きを作る場面です。たとえば、製品の仕様や保守の条件についての問い合わせに、マニュアルと契約の雛形から回答案を作らせ、担当者が確認して送る運用です。ここで作り話の点数を使うと、どの下書きを重点的に読むべきかが分かります。

運用の形は、点数で下書きを三つに分けることです。点数が十分に高い下書きは、担当者が根拠の資料と見比べて短時間で確認します。中ほどの下書きは、根拠の資料を開いて一文ずつ照らし合わせます。低い下書きは、そもそも回答に必要な資料が検索で拾えていない可能性が高いので、下書きを捨てて担当者が一から書くか、資料の側を足します。どの帯でも、顧客に送る前に人が読むことは変えません。点数が変えるのは、読む深さと時間の配分です。

この場面で見落としやすいのが、点数が低い問い合わせの集計です。点数の低い下書きが特定の製品や話題に偏っているなら、それは回答の失敗ではなく、社内資料の欠けを示しています。月に一度、点数の低い問い合わせの話題を並べ、資料を足すべき場所を決める会議に回すと、見張りの仕組みが資料の改善にもつながります。

場面2：マーケ資料や記事の下書きで、数字の出どころを見張る

マーケ部門では、製品の資料、導入事例、比較表などの下書きをAIに作らせることが増えています。ここで問題になるのは、AIがもっともらしい数字や機能名を足してしまうことです。導入事例の削減時間、対応している連携先の数、価格の条件などが、元の資料にないまま書き込まれると、広告や営業資料として外に出たときに表示の問題になります。

この場面では、元にした資料（製品の仕様書、事例の取材メモ、料金表）を前の文章に、下書きの段落を後の文章に入れて点数を見ます。コツは、下書き全体ではなく段落や一文ごとに区切って点数を出すことです。全体の点数は、長い文章のどこか一か所の食い違いを薄めてしまいます。一文ごとに見れば、どの数字が資料にないかを指し示せます。

ここでは、HHEM の「世の中では正しくても資料になければ作り話と数える」性質が役に立ちます。担当者の記憶では正しい数字でも、根拠の資料に書いていなければ点数が下がるので、出どころを資料に書き足すか、数字を消すかの判断を迫られます。外に出す文章の数字は、すべて社内の資料にたどれる状態にしておく、という規律を守るための道具として使えます。ただし日本語の下書きで使うなら、公開版ではなく商用版が前提になります。

場面3：社内検索の要約で、読み飛ばしてよい回答を絞る

三つめは、社員が社内規程や過去の企画書を検索し、AIが要約して答える場面です。問い合わせへの回答と違い、ここでは一つひとつの回答を人が確認する体制は取れません。そこで点数を、回答を読む社員への目印として使います。点数が低い回答には「根拠の資料と食い違う可能性があります。元の資料を確認してください」と表示し、根拠の資料へのリンクを並べる、といった使い方です。

このとき、点数の数字そのものを社員に見せるかは慎重に決めます。0.82のような数字を見せると、多くの人は「82%正しい」と受け取ります。公式の説明では、0.95は要約に作り話が含まれていない見込みが95%という意味だとしていますが、これは平均的な見込みであって、目の前の回答の正しさを保証するものではありません。社員に見せるのは数字ではなく、確認を促す表示と根拠の資料にとどめるほうが誤解が少なくなります。

社内検索で注意したいのは、点数が高いことと、規程として最新であることは別だという点です。改定前の規程と改定後の規程が両方検索に引っかかれば、AIは古いほうを根拠に、資料どおりの回答を作るかもしれません。点数はそれを見抜けません。文書の版を管理し、廃止した規程を検索の対象から外す作業は、見張りの仕組みとは別に必要です。

点数を合否に使わない理由

点数で回答を自動的に通す・止めると決めたくなる気持ちは分かります。しかし、そうした使い方には三つの落とし穴があります。第一に、点数は回答全体についての一つの見込みなので、長い回答の中の一か所の誤りが、ほかの正しい部分に埋もれることがあります。第二に、資料が間違っている、資料が足りないといった問題は点数に現れません。第三に、モデルの版や対象の言語が変わると、同じ回答でも点数が動きます。

• 点数0.5以上の回答は、人の確認なしで顧客に自動で送る
• 点数が高かったことを理由に、回答の誤りについての責任を検出の仕組みに帰す
• 社員向けの画面に点数をそのまま表示し、「この回答は82%正しい」と読ませる
• 公開版を日本語の回答にそのまま使い、英語での評価の数字を根拠に精度を説明する
• ベンダーの順位表で上位のモデルを選んだことを、作り話の対策と位置づけて追加の確認をやめる

合否に使わない代わりに、点数には三つの役割を与えます。人が読む順番を決めること、人の確認を省けない回答を確実に拾うこと、点数の低い回答の偏りから資料の欠けを見つけることです。判断するのは人で、点数はその判断の材料を早く届けるためのものという位置づけを、運用の手順書に明記しておきます。

閾値の決め方：公式の目安0.5から始めて、自社の回答で決め直す

公式の説明では、閾値は0.5を最初の目安にすることを勧めています。ただしこれは出発点で、自社の資料と問いに合った値は自社で測るしかありません。決め方の手順は次のとおりです。

点数の帯（例）	回答の扱い	人の確認	記録すること
下の線より低い	下書きとして使わない。資料の欠けを疑う	担当者が一から書く	問いの話題と、拾えた資料
二本の線の間	下書きとして使う	根拠の資料と一文ずつ照らす	直した箇所と理由
上の線より高い	下書きとして使う	根拠の資料と見比べて短く確認	確認者と日付

採点に使う組の選び方にも注意が要ります。普段の問いだけを集めると、ほとんどの回答が資料どおりになり、作り話の回答が数件しか含まれません。それでは下の線をどこに引いても、正しく拾えたかどうかを判断できません。過去に誤りが見つかった回答や、数字・日付・固有名詞を含む回答を意図して多めに混ぜると、線の位置による拾い漏れの違いが見えるようになります。採点は一人ではなく二人で行い、判断が割れた組は話し合って決め、その理由も残しておくと、次の見直しで基準がぶれにくくなります。

表の帯は例であり、点数の値そのものは自社の採点結果で決めます。人の採点と点数が大きくずれる組は、捨てずに残して次の見直しに使います。どういう回答で点数が当てにならないかを知ることが、閾値そのものよりも運用の役に立ちます。

何が社外に出るか：公開版と商用版でデータの流れが違う

データの流れは、どちらの版を使うかで大きく変わります。公開版を自社のサーバーで動かすなら、資料も回答も社外には出ません。モデルのファイルを一度取得すれば、外部とつながない環境でも動かせます。社外に出せない資料を扱う部署で、英語の文書が中心なら、まず公開版で試す価値があります。

商用版を使う場合は、点数を計算するために、回答と根拠の資料の両方が Vectara の仕組みに送られます。社内規程、契約の雛形、顧客からの問い合わせの文面などが含まれうるので、見張りの仕組みのために、見張られる側の資料がすべて社外に渡ることになります。Vectara の基盤そのものを自社のクラウドの専用区画や自社のデータセンターに置く選択肢もありますが、その場合は契約の形も費用も変わります。

• 商用版の利用前に、送った資料と回答の保存期間、AIの学習に使われるかどうか、保存される国を、公式の安全面の資料と契約書で確かめる
• 問い合わせの文面に顧客の個人情報が含まれる場合、外部の事業者への提供にあたるかを、個人情報の担当と確認する
• 点数の記録（ログ）にも回答と資料の一部が残る。記録を見られる人と保存期間を、回答そのものと同じ基準で決める

確かめた内容は、回答を受け取った担当者名と日付とともに社内の台帳に残します。2026年10月時点の公式サイトでは、信頼と安全についての案内のページが用意されています。そこで分からない点は提供元に問い合わせ、回答を文書で受け取っておきます。

誰の権限で動くか：閾値を変えられる人を限る

見張りの仕組みを入れると、新しく三つの権限が生まれます。点数を計算する窓口を呼び出すための鍵、閾値や表示の設定を変える権限、点数と回答の記録を見る権限です。いちばん見落とされやすいのが、閾値を変える権限です。閾値を下げれば、人の確認が必要な回答が減り、現場の負担が軽く見えるからです。

閾値の変更は、運用の担当者が一人で決められないようにします。変更には、対象の業務の責任者の承認と、変更前後の採点結果の比較を必須にすると決め、変更の履歴を残します。鍵は個人ではなく仕組みの用途ごとに発行し、担当者の異動や退職のときに止められるようにしておきます。

記録を見る権限も絞ります。点数の記録には、問い合わせの文面や社内資料の一部が残るため、回答の品質を分析したい担当者が、本来見られない部署の資料まで読めてしまうことがあります。記録の閲覧は、回答の元になった資料の閲覧権限と同じ範囲に合わせるのが原則です。

費用の増え方と、公開版の運用の手間

費用は、点数を出す回数と、渡す資料の長さに比例して増えていきます。商用版は Vectara の料金体系の中で提供され、公式サイトでは料金と置き方の選択肢を比べるページが用意されていますが、点数の計算だけの単価は2026年10月時点の表のページでは確かめられませんでした。見積もりを取るときは、問い合わせ1件あたりに渡す資料の量と、1か月の件数を先に数えておくと、話が早く進みます。

公開版は利用料がかからない代わりに、自社のサーバーの費用と運用の手間がかかります。公式の目安では、一般的なCPUで2,000トークンの入力におよそ1.5秒なので、問い合わせのたびにその場で点数を出すと、回答の表示が遅れることがあります。点数をすぐ必要としない場面では、まとめて夜間に計算する、マーケ資料の下書きのように時間に余裕のある業務から始める、といった工夫で費用と待ち時間を抑えられます。

どちらの版でも、費用が膨らみやすいのは一文ごとに点数を出す使い方です。精度は上がりますが、呼び出す回数は文の数だけ増えます。一文ごとの点数は外に出る文章に限り、社内検索の要約は回答単位、というように、業務ごとに細かさを変えておきます。

止め方とやめ方：見張り役は差し替えられる形で入れる

見張りの仕組みは、回答を作る仕組みとは別の工程として組み込むのが原則です。回答の作成、点数の計算、人の確認の三つを分けておけば、点数の計算だけを止めても業務は回ります。問題が起きたときに点数の計算を止めると、すべての回答が「人が一から確認する」扱いになるように設計しておくと、止めた日に誤った回答が素通りする事故を防げます。

やめるとき、あるいは別の検出の仕組みに乗り換えるときに資産として残るのは、人が採点した問いと回答の組です。これは Vectara に依存しないので、別の検出モデルやAIに採点させる方式に替えても、同じ組で精度を比べ直せます。ベンダーの点数ではなく、自社の採点の記録を資産として持つことが、ロックインを避けるいちばん確かな方法です。

商用版をやめる場合は、送った資料と回答、点数の記録が提供元の側に残っていないかを確かめ、削除の手順と証明の出し方を契約の段階で取り決めておきます。公開版をやめる場合は、自社のサーバーに残した記録の削除が中心になります。

よくある質問

日本語の社内資料に、公開版を使ってもよいですか

公開版の対応言語は英語と説明されています。日本語の資料と回答を入れても点数は出ますが、どの程度当てになるかは確かめられていません。使うなら、前述の手順で自社の日本語の回答を人が採点し、点数と照らして当てになるかを確かめてからにします。業務で常用するなら、日本語に対応した商用版か、別の手段を検討します。

点数が高ければ、人の確認を省いてよいですか

顧客や社外に出す文章では省きません。点数は資料と回答の食い違いの見込みであり、資料の正しさや最新かどうかは測っていないからです。社内検索の要約のように人が一つずつ確認できない場面では、確認を促す表示と根拠の資料を添えることで、読む人の確認に委ねます。

回答を作るAIに「根拠を示して」と指示すれば、見張りは不要ですか

根拠を書かせる指示は有効で、見張りと併用すべきものです。ただ、AIが示した根拠の資料と回答が本当に一致しているかは、別の仕組みか人が確かめる必要があります。AIに根拠を書かせ、その根拠と回答の一致を点数で確かめ、最後に人が判断するという三段で考えます。

まとめ

Vectara の作り話の検出モデルHHEMは、回答が渡した資料に裏付けられている見込みを点数にする道具です。資料の正しさも、回答の質も測っていません。だからこそ、点数を合否に使わず、人が読む順番を決め、確認を省けない回答を拾い、資料の欠けを見つけるために使います。公開版は自社の環境で動かせる一方で英語が前提、商用版は日本語に対応する一方で資料が社外に渡る、という違いを踏まえて入り方を決めてください。閾値は公式の目安0.5から始め、自社の回答を人が採点した結果で決め直し、モデルの版が変わるたびに確かめ直します。ベンダーの順位表は参考値にとどめ、自社で採点した問いと回答の組を、何より大事な資産として残していくことが、見張りの仕組みを長く使うための土台になります。

※本記事にはAIが活用されています。編集者が確認・編集し、可能な限り正確で最新の情報を提供するよう努めておりますが、情報の完全性、正確性、最新性、有用性等について保証するものではありません。本記事の内容に基づいて行動を取る場合は、読者ご自身の責任で行っていただくようお願いいたします。