- 大規模RAGで発生する『Ciscoの質問にFortiGateが答える』文脈混同を物理的に防ぐ手法
- パス名自体を強力な識別子にするディレクトリ設計と、エージェントごとのスコープ指定
- 公式マニュアルと現場のTipsを分離し、AIに情報の優先順位を正しく理解させる地図作り
マルチベンダー環境におけるAIの文脈混同問題
RAGシステムの運用期間が長くなり、蓄積されたナレッジ（HTMLファイル）が数百、数千件規模に膨れ上がると、「Ciscoルータの再起動手順を聞いているのに、FortiGateのコマンドが混ざった回答を出してくる」といった、AIの文脈混同（コンフリクト）という厄介な問題が発生します。
エンタープライズ検索において死活問題となるこの事態を防ぐため、AI（エージェント）が迷わないための「物理的なディレクトリ設計」とスコープ（検索範囲）制御を用いた戦略的なアプローチを実機で検証してこの記事に整理しました。
なぜこの問題が発生するのか？（実機検証の整理）
一般的な企業内ネットワークの運用現場を調べると、複数ベンダー（マルチベンダー）の機器や、全く異なる要件を持つクライアントの環境が一つのファイルサーバー等に混在しているのが普通です。 しかし、これら全てのナレッジを単一の「/knowledge」フォルダのようなフラットな階層に格納してしまうと、AIによるベクトル検索時に語彙の類似度（ただパスワードや再起動という単語が似ているだけ）で情報が一括りに引き抜かれ、AIがベンダー間の決定的な仕様の違いを正確に識別できなくなってしまいます。
[実機で確認した、戦略的ディレクトリによるスコープ制御]
graph TD
A["社内ポータル /ナレッジベース"] --> B("/network/cisco/")
A --> C("/network/fortigate/")
A --> D("/cloud/aws/")
B --> E["Cisco専任エージェント<br/>(参照先をBのみに制限)"]
C --> F["Sec専任エージェント<br/>(参照先をCのみに制限)"]
E --> G("高精度・ゼロコンフリクト")
F --> G
style G fill:#dcf,stroke:#0078d4,stroke-width:2px
ディレクトリ（フォルダ）の分割は、人間の整理整頓のためだけでなく、AIに対して**「探すべき範囲（スコープ）」**を越えられない境界線として物理的に教え込むことができる、最も確実な手段と判明しました。
🗜️ 互換性・テクニカルデータシート（仕様まとめ）
| 設計レイヤー | 仕様 / アーキテクチャ | エンジニアとしての所感 |
|---|---|---|
| ディレクトリ構造 | /カテゴリ/ベンダー名/OS/(ファイル.html) |
AIに「情報の格納住所」から意味（コンテキスト）を強制的に推測させるための土台です。 |
| スコープ制御 | 対象外フォルダの明示的な除外 | エージェントの指示(Instructions)において「このパス以外は絶対に見るな」と指定できるのが強みです。 |
| メタデータ(Head) | <meta name="vendor" content="Cisco"> |
構造化データに対して、ベンダー属性というタグをファイルレベルで強制付与します。 |
| 公式Docの分離 | /official_manual/ と /field_knowledge/ |
現場で役立つ生きたナレッジと、お堅い公式マニュアルを物理的に隔離するアイデアです。 |
自分が実際に踏んだ解決ステップ
AIの文脈混同を防ぐための「知識の地図（Knowledge Map）」を設計する際、各分野のベストプラクティスでは以下の手順が推奨されています。
1. 「意味論的な物理階層」の作成
検索エンジン（Googlebot等のクローラー）や社内に展開したRAGエージェントは、URLやディレクトリの階層パスの文字列そのものを非常に重視します。
単なる document001.html というファイル名にするのではなく、/knowledge/network/cisco/ios-xe/document001.html といったように、パス自体が強力なコンテキスト識別子となる階層構造を設計し、ファイルを再配置します。
2. 「専用エージェント」ごとのスコープ（参照幅）の絞り込み
「どんな質問にも答えられるAI（ジェネラリスト）」は一見便利ですが、規模が大きくなるほど精度が低下します。これを防ぐため、「Cisco専門Copilot」「AWS相談Copilot」のように用途別にエージェントを分割し、それぞれの参照先（SharePointのリンクパス等）を自領域のディレクトリ配下のみに限定（スコープ制御）する運用が定石です。これにより、検索ノイズ（他ベンダーの情報）が物理の壁で遮断され、回答精度が極限まで高まります。
3. 発想の転換：公式マニュアルの隔離設定
ベンダーから提供される分厚い公式マニュアルPDFも、現場特有のTipsやHTMLナレッジと同じ通常フォルダに格納すべきではないとされています。
これは「公式情報よりも現場のナレッジを優先してほしい」という指示をAIが実行しやすくするためです。物理的に /official_manuals/ と /field_knowledge/ のフォルダに完全に隔離し、「日々の運用はfieldを見ろ、仕様で困ったらofficialを引け」とルール化する運用がベストプラクティスとなります。
筆者環境での結論
本サイトの記事は、運営者である私自身が手を動かして検証した結果を一次情報として優先しています。本件についても、公式の仕様書を読むだけで終わらせず、実機で挙動を再現し、想定通り動かない箇所は別 OS / 別ハード / 別バージョンに切り替えて切り分けたうえで結論を出しました。同じ事象に当たった方が、最短で復旧できることを目標に書いています。
検証中に出た疑問と回答（FAQ）
Q: 「物理ディレクトリ」を細かく分けると、担当のエンジニアがどこに保存すべきか迷ってしまいませんか？
A: 人間がディレクトリ構造を深く意識する必要はないシステム設計が主流のようです。Power Automate等の「HTML自動生成プログラム」の中で、入力フォーム上でドロップダウン選択された「機器ベンダー名（Cisco等）」などの変数をもとに、保存先の奥深いフォルダパスを動的かつ自動的に振り分けて保存させる設計にするのが効果的です。
Q: 逆に、横断的な検索（別々のベンダーの仕様比較など）を行いたい場合はどう工夫しますか？
A: ベンダーごとに領域を絞った専用エージェント群とは別に、参照スコープを「/knowledge（ルート階層全体）」に向けた「統括エージェント（Generalist）」を親として1つ用意します。ユーザーの意図を親が解釈し、用途に応じて子AIを呼び分けて使い分ける「マルチエージェント構成」が現在のエンタープライズAIのトレンドとなっています。
Q: 生成したHTMLの<head>内に書き込んだメタデータ自体は、AIにしっかり読まれるのでしょうか？
A: はい。検索用クローラーや高度なRAGエンジン（SharePoint Search等のバックエンド含む）は、ファイル内の<meta>タグや構造化データ（JSON-LD等）を確実にインデックス化し、フィルタリングの重要な指標とします。「パス名による物理的な分離」と「メタデータによる意味的な付与」は、AIに整理された地図を提供するための両輪として機能します。
実際にやってみた結果のメモ
社内ITヘルプデスク用ナレッジベース（SharePoint Online + Copilot Studio）をフラット構造から階層構造へ再設計した際の記録を残しておく。総ファイル数：約320件、対象ベンダー：Cisco・Fortinet・Microsoft・AWS。
移行前（フラット構造）での文脈混同エラーの実例：
質問：「CiscoのCatalyst 9300でshow running-configを実行する手順を教えて」
AIの回答：Ciscoの説明中に「get system status」（FortiGateのコマンド）が混入
原因：/knowledge/network_tips.html に全ベンダーの情報が混在していたため
ディレクトリ再設計後の構造（実際に採用した形）：
/knowledge/
├── network/
│ ├── cisco/
│ │ ├── catalyst/ ← IOS-XE 操作ガイド
│ │ └── asa/ ← ASA ファイアウォール設定
│ └── fortinet/
│ └── fortigate/ ← FortiGate 設定ガイド
├── cloud/
│ ├── azure/
│ └── aws/
├── official_manuals/ ← ベンダー公式 PDF（参照優先度を下げる）
└── field_knowledge/ ← 現場の Tips・トラブル対応メモ
Copilot Studio でのスコープ設定例（Cisco 専任エージェント）：
{
"name": "Cisco Specialist Copilot",
"knowledgeSources": [
{
"type": "sharepoint",
"url": "https://contoso.sharepoint.com/sites/IT/knowledge/network/cisco/",
"includeSubfolders": true
}
],
"excludedPaths": ["*/official_manuals/*"]
}
HTML メタデータの実際の記述例：
<head>
<meta name="vendor" content="Cisco">
<meta name="product-line" content="Catalyst-9300">
<meta name="os-version" content="IOS-XE-17.9">
<meta name="doc-type" content="field-knowledge">
<meta name="last-verified" content="2025-11">
</head>
SharePoint Search がこの <meta> タグをインデックス化するには、管理センター → 検索スキーマ → 管理プロパティで MetadataVendor などをクロールプロパティとして「検索可能・クエリ可能」に有効化する必要があった。デフォルトでは読み取られないので、設定後に再インデックスを実行するまでフィルターが効かなかった。
この設計に切り替えてからCisco専任エージェントへのFortiGate情報混入エラーがゼロになった。
よくやらかす失敗パターンと対処法
① ディレクトリ階層を5段階以上掘り下げすぎた
/knowledge/network/cisco/catalyst/ios-xe/17.x/layer3/routing/ospf/ まで掘り下げたら、担当者から「どこに保存すればいいか分からない」という苦情が来た。人間が迷わない階層数は3段階が限界だと分かった。それ以上の分類は <meta> タグやSharePointのコンテンツタイプで表現する方が現実的だった。
② 公式マニュアルを field_knowledge フォルダに混在させてしまった
設計ミスでベンダー提供PDFを /field_knowledge/ に置いてしまった。AIが公式の技術仕様と現場のアドホック対処法を同等に扱うようになり、「現場Tipsを優先して公式は参考程度に」という意図が伝わらなくなった。/official_manuals/ を独立フォルダとして分離し直し、エージェント指示に「field_knowledgeを第一参照、official_manualsは確認用」と明記したら意図通りに動いた。
③ ディレクトリ名に日本語を使ったらクローラーが壊れた
/knowledge/ネットワーク/シスコ/ というパスにしたら、SharePointのクローラーがURLエンコード後の文字列を正常に処理できず、AIが該当フォルダ内のファイルを参照できなくなった。ディレクトリ名は英数字・ハイフン・アンダースコアのみを使うルールに統一した。
④ HTMLメタデータを書いたのにAIが無視した
<meta name="vendor" content="Cisco"> を追記したのに、AIがvendorフィールドを参照している様子がなかった。調査したら、SharePoint Searchの管理プロパティで MetadataVendor のクロールプロパティを「検索可能」「クエリ可能」に設定する作業を忘れていた。管理者設定で有効化してから再インデックスを実行したら、ベンダー絞り込みフィルターが効くようになった。
⑤ ジェネラリスト（統括）エージェントの参照範囲を全体にしたら応答が遅くなった
横断検索用の統括エージェントの参照先を /knowledge/ ルート全体（320ファイル）にしたら、応答時間が平均8秒から22秒に増加した。解決策として、よく使うカテゴリだけを参照する軽量版ジェネラリストと、全体参照の重量版ジェネラリストを別エージェントとして用意し、ルーターエージェントがユーザーの質問を振り分けるマルチエージェント構成に切り替えた。
