AIに必要なのは「もっと知る力」ではなく、知ってよい範囲を証明する力

「この情報を知っているか」と「この情報を使ってよいか」は、同じ質問ではない。ところが多くのAIシステムは、検索で見つかった文章を、そのまま回答や操作の材料にしている。

ここに、生成AIの見落とされがちな危険がある。検索精度を上げるほど、エージェントは多くの情報に触れられるようになる。しかし、情報に触れられる範囲が広がることは、必ずしも知性が高まることを意味しない。むしろ、権限の境界が曖昧なまま検索能力だけが向上すると、誤答や情報漏洩の規模が拡大する。

本当に信頼できるAIを作るには、検索を単なる「関連情報の発見」と考えてはいけない。検索は、エージェントに何を見せ、何を信じさせ、何を実行させるかを決める統治の仕組みである。

検索の問題は、関連性ではなく境界の問題である

ベクトルデータベースは、文章の意味的な近さを手がかりに情報を探す。例えば、利用者が「製品チームの現在の課題」と入力すれば、「開発上の懸念」「プロダクト部門の障害」「今期のリリースリスク」といった表現を含む文書が、語句の一致がなくても候補になる。これは非常に強力だ。人間が同じ内容を別の言葉で書いても、検索対象にできるからである。

しかし、この便利さには構造的な弱点がある。意味が近いことと、アクセスしてよいことは別だからだ。

営業担当者が「大口顧客の解約リスク」を検索したとする。意味検索は、営業資料だけでなく、経営会議の議事録、人事上の懸念、法務部門の内部メモまで、内容が近いという理由で候補に入れるかもしれない。検索器は、その情報が利用者の権限に属するか、誰が作成したか、どの部署に限定されているか、いつまで有効かを、意味の近さだけから判断できない。

このとき問題になるのは、検索結果が少し不正確になることではない。AIが、権限のない情報を根拠としてもっともらしい判断をすることである。しかも回答文では、複数の文書が混ぜ合わされ、どの情報が決定的だったのかが見えにくくなる。利用者は自然な文章を読むが、その背後にあるアクセス判断を確認できない。

これは図書館に例えるとわかりやすい。ベクトル検索は、質問に合いそうな本を素早く棚から集める優秀な司書である。しかし、司書が「内容が近いから」という理由だけで、閲覧禁止の資料まで机に置いたら、検索能力はサービスではなく情報管理上の事故になる。

したがって、生成AIにおける検索の中心課題は、関連性の最大化ではない。関連性を、許可された範囲の中で最大化することである。

ナレッジグラフは、検索を「理由のある判断」に変える

ナレッジグラフが重要なのは、ベクトル検索より常に高速だからでも、すべての用途で優れているからでもない。より本質的な価値は、情報を孤立した文章の集合ではなく、対象と関係の構造として表現できることにある。

例えば、次のような関係を持つ企業データを考える。

佐藤さん → 所属する → 製品チーム
製品チーム → 担当する → 製品A
製品A → 利用する → 決済API
決済API → 管理する → インフラ部門

「製品チームにいる人だけを教えて」という問い合わせに対して、グラフは「人」というノードと「所属する」という関係をたどって答えられる。単に文章の中に「製品」と「人」が近くに登場したからではない。どの関係を通じて答えに至ったかを示せる。

この違いは、精度だけでなく、検証可能性を生む。回答が誤っていた場合、管理者は、人物の所属情報が間違っているのか、チームの定義が古いのか、関係の更新が反映されていないのかを調べられる。訂正すべき場所が見えるのである。

一方、ベクトル検索の内部では、文書が高次元の数値表現に変換される。似た情報を見つけるには優れているが、「なぜこの文書が選ばれたのか」「どの条件を満たしたから対象になったのか」を、人間が直接点検しにくい。これはブラックボックスという言葉だけでは足りない。誤りを修正するための接点が少ないという問題である。

グラフはこの問題を、検索結果を説明するだけでなく、検索の候補そのものに制約をかけることで解決できる。利用者の所属、文書の機密レベル、データの所有部門、契約上の利用範囲、情報の有効期限などを関係として表現すれば、検索は次のように変わる。

「質問に意味的に近い情報を探す」から、

「この利用者が、この目的で、この時点において、たどってよい関係の中から、質問に関係する情報を探す」へ。

この変化は、データベースの選択というより、AIに世界をどう見せるかという認識論の設計である。

最小権限は、セキュリティ原則であると同時に知性の原則である

エージェントの安全設計では、ファイルシステム、データベース、外部APIなどへの権限を制限することが基本になる。エージェントが使用するディレクトリを限定し、アクセスできるテーブルを必要なものだけに絞り、悪用への耐性が確認されたエンドポイントを使う。さらにサンドボックス化や多層防御によって、一つの防御が破られても被害が広がらないようにする。

これらは通常、セキュリティの話として理解される。しかし生成AIでは、最小権限は同時に推論品質を守る方法でもある。

人間の意思決定でも、情報が多ければ多いほど判断が良くなるとは限らない。無関係な情報、古い情報、権限の異なる情報が混じると、判断の根拠はむしろ濁る。AIの場合、追加情報を文脈として取り込む能力が高いため、この混濁が流暢な誤答として現れる。

例えば、購買エージェントに「この取引先との契約更新を承認して」と依頼したとする。エージェントが参照できる範囲に、過去の価格交渉記録、法務上の保留事項、別部署の非公開評価、個人情報を含むメールがすべて入っていたらどうなるか。エージェントは、より賢くなるどころか、目的に不要な情報を混ぜて判断する可能性がある。最悪の場合、非公開情報を根拠にした結論を、理由を説明せず実行する。

ここで重要なのは、権限を「操作」の直前だけで制御してはいけないということだ。書き込みを禁止していても、読み取りすぎれば問題は起こる。エージェントが機密情報を読んでしまえば、回答、要約、ログ、外部APIへの入力を通じて、情報が別の場所へ流出する可能性がある。

だから必要なのは、二種類の最小権限である。

1. 行動の最小権限: エージェントが実行できる操作を限定する。
2. 知識の最小権限: エージェントが判断材料として取得できる情報を限定する。

ナレッジグラフは、後者を構造化しやすい。利用者と資源の関係を記録し、許可された経路だけを探索対象にできるからだ。ただし、グラフを導入すれば自動的に安全になるわけではない。誤った関係、古い所属情報、過剰な権限設定がグラフに入れば、透明な誤りが高速に再利用される。

透明性は、安全性そのものではない。透明性とは、誤りを見つけて直せる状態である。

この区別は極めて重要だ。グラフは説明可能性と修正可能性を高めるが、認証、認可、データの品質管理、監査ログを代替しない。

信頼できるAIは「検索器」ではなく「境界付きの推論器」である

ここまでの議論から、検索システムを設計するための三層モデルを導ける。

第一層: 意味の層

利用者の質問と、候補情報の内容がどれほど近いかを判断する層である。ベクトル検索はここで力を発揮する。曖昧な質問、言い換え、長文の文脈、未知の表現を扱うのに向いている。

第二層: 構造の層

その情報が、誰、何、どの部署、どの製品、どの契約と関係しているかを判断する層である。ナレッジグラフはここで力を発揮する。関係、所属、依存、所有、時系列を明示し、回答の経路を追跡できる。

第三層: 統治の層

その利用者とエージェントが、目的に照らして何を閲覧し、何を実行してよいかを判断する層である。認証、認可、ポリシー、サンドボックス、監査、レート制限、多層防御がここに入る。

この三層を混同すると、設計上の誤解が生まれる。ベクトル検索に認可を任せたり、グラフの存在だけで安全だと思ったり、API側の制限だけで機密情報の漏洩を防げると考えたりするのは、その典型である。

実際には、三つを組み合わせるのが現実的だ。まず統治の層で、利用者とエージェントの許可範囲を確定する。次に構造の層で、許可範囲の中から関係上妥当な対象を絞る。その後で意味の層を使い、残った候補を質問との関連性で順位付けする。

順序が重要である。最初に全社データをベクトル検索し、後から権限のない結果を除外する方式では、漏洩リスクを完全には消せない。検索、キャッシュ、ログ、再ランキングのどこかに、除外前の情報が残る可能性があるからだ。

より安全な流れは次のようになる。

利用者の身元を確認する
      ↓
目的と操作の権限を確認する
      ↓
グラフで許可された対象と関係を絞る
      ↓
絞り込まれた範囲だけを意味検索する
      ↓
出典、関係、更新日時を付けて回答する
      ↓
書き込みや外部操作を別の認可で確認する

この構成では、ベクトルデータベースを排除していない。むしろ、得意な仕事に集中させている。ベクトル検索は「何が関連するか」を探し、グラフとポリシーは「何を候補にしてよいか」を決める。

実装で最初に設計すべきは、モデルではなく境界である

AI導入の議論では、どのモデルを使うか、どの埋め込みモデルが高精度か、どのベクトルデータベースが速いかが先に話題になりやすい。しかし企業内エージェントでは、最初に決めるべきなのはモデルではない。失敗したときに何が起こってはならないかである。

例えば、次の問いを先に定義する。

1. エージェントが絶対に見てはいけない情報は何か。
2. 見てもよいが、回答に直接使ってはいけない情報は何か。
3. 読み取りは許可されるが、書き込みは許可されない資源は何か。
4. どの判断に人間の承認が必要か。
5. 情報の所有者、更新日、機密レベルをどこで検証できるか。
6. 誤答や誤操作が起きたとき、どの経路をたどって原因を特定できるか。

そのうえで、システムを次のように分割するとよい。

データ境界では、部署、プロジェクト、顧客、地域、機密区分、保存期間を明示する。単に文書をチャンクに分割して埋め込むだけではなく、各断片に所有者と利用条件を付与する。

関係境界では、誰が何に所属し、何を管理し、どの情報を参照できるかをグラフとして定義する。関係には有効期限を持たせる。退職者や異動者の権限が、過去の埋め込みデータに残り続けることを防ぐためである。

操作境界では、読み取り、書き込み、削除、送信、承認を別々の権限として扱う。特に外部APIやデータベースへの書き込みは、読み取りとは別のエンドポイント、別の認可、別の監査を設けるべきだ。

説明境界では、回答に出典だけでなく、回答に至った関係と前提を残す。「この結論は、製品Aが製品チームの担当であり、佐藤さんがそのチームに所属しているという二つの関係に基づく」と示せれば、利用者は内容を検証できる。

もちろん、すべてをグラフ化する必要はない。頻繁に変わる自由形式の文章や、探索的な発想支援では、ベクトル検索の柔軟性が重要である。一方、所属、権限、所有、依存関係、契約条件、承認経路のように、誤りが業務上の責任につながる情報は、構造化する価値が高い。

判断基準は単純である。その情報の誤りを、誰かが説明し、訂正し、監査しなければならないか。答えが「はい」なら、意味検索だけに依存すべきではない。

Key Takeaways

1. 関連性と権限を分離する。質問に近い情報であることは、利用者に見せてよい理由にならない。
2. 最小権限を、操作だけでなく知識にも適用する。エージェントが読める情報の範囲を、目的単位で限定する。
3. 検索を三層で設計する。統治で許可範囲を決め、グラフで構造的な対象を絞り、ベクトル検索で意味的な順位を付ける。
4. 所属、所有、依存、承認、機密レベルを構造化する。誤りの説明と修正が必要な関係ほど、グラフに向いている。
5. 回答と操作に検証可能な経路を残す。出典、関係、更新日時、利用した権限、実行したAPIを監査できるようにする。

最も危険なAIは、明らかに間違った答えを返すAIではない。権限の境界を越えた情報を、正しそうな文章に変換し、誰もその混入経路を発見できないAIである。

だから、信頼できるAIの設計目標を「より多く知ること」と置いてはいけない。目指すべきは、必要なことだけを、許可された範囲で知り、その理由を示し、許可された行動だけを実行することである。

検索技術の成熟とは、AIが世界中の情報を拾えるようになることではない。どの世界を見せ、どの境界を越えさせず、どの関係を根拠として判断させるかを、設計者が明確にできるようになることだ。AIに与えるべきなのは、無限の視野ではない。責任を持って検証できる、境界付きの視野なのである。