スキャン版マニュアルと写真添付チケット：ナレッジグラフが22分のサポート検索を終わらせる仕組み

重要なポイント

• 12,000文書のサポートライブラリの70%にはテキスト層がない — 従業員460名のポンプ製造業者にとって、約126,000ページがキーワード検索からも、テキストのみのベクトルインデックスからも見えません。
• Perplexityのpplx-embed-v2-lateはMADQAで92.4%の回答精度に到達 — 2026年10月7日リリースのこのモデル群は、OCRパイプラインなしでレンダリング済みPDFページを直接検索し、18,000ページ超・実環境のPDF 800件にわたる500の質問にエージェントが回答しました。
• 0.6Bのクエリエンコーダは9Bモデルで構築したインデックスを照会できる — 共有embedding空間が、オフラインの高コストなページ索引付けと低コストなライブ照会をペアにします。0.6BモデルはMITライセンスの594Mパラメータです。
• LinkedInのGraphRAG本番デプロイメントは検索精度を77.6%改善 — ナレッジグラフの構造的エッジこそ、ベクトルインデックスが見られないものです。
• ページ引用ルールが失敗モードを変える — 文書ページ・品番・シリアル範囲を伴わない回答はエージェントから出ません。検証できないものは、顧客へ出荷する代わりに人へエスカレーションします。

中堅のポンプ・水道設備機器メーカーが毎週受ける950件のチケットのうち、300件は製品クレームではありません。文書に関する質問です。1998年製シリアル43-11092のSP-200にどのインペラが適合するか、O&Mマニュアルのトルク表をどのサービスブリティンが後継するか、2014年改訂版ではどのガスケット材が指定されているか — いずれも名板の写真かマニュアルページのスキャン画像を添付して届きます。こうした質問の背後にある技術ライブラリは12,000文書・約180,000ページを保有し、その約70%はテキスト層のない1970年代以来のスキャン紙で、Zendeskの検索インデックスはそのどれも読めません。

コストは二つの待ち行列に現れます。社内では、6名のテクニカルサポートスタッフが文書関連の質問1件につき平均22分の手動検索をこなします — PDFを次々と開き、スマートフォンの写真をポンプ曲線と目視で照合します。社外では、ディーラーや販売店がサポート宛のメールを出し、返信まで中央値14時間待ちます。2名のシニア技術者がエスカレートされた文書関連質問の55%を担当し、他人の検索作業として週約19時間を吸収しています。そして最悪の失敗は遅い方ではありません。読み間違えた回路図は誤ったカートリッジを出荷させ、補充サイクルと2回目の訪問を引き起こし、この会社に昨年、輸送と補充処理だけで約3.8万ドルを失わせました。

本稿は三層構えの解決策 — 文書ライブラリ上のページ単位ナレッジグラフ、OCRステップなしでレンダリング済みPDFページを検索するレイトインタラクション埋め込み、そして正確なページを添付して回答するエージェントフロー — を、それぞれの一次ソースである Perplexityの2026年10月7日の発表 と LinkedInのGraphRAG本番デプロイメント に紐付けながら描きます。

問題：誰もが検索をやめたライブラリ

紙の時代を持つすべての製造業者がこのライブラリを持っています。直近5年分のマニュアルはデジタル生まれです。それ以前のすべてはスキャナー経由でやって来ました。ポンプ曲線、配線図、分解部品図、寸法表。テキストが判読できるページもあれば、穴あけ、折り線、余白の手書きメモが入った劣化スキャンも多い。検索可能な30%が易しい部分であり、残り70%はファイル名だけでラベルされた画像の壁です。だからこそ、キーワード検索もテキストのみのベクトルインデックスも同じ方法で失敗します。両者とも、存在しないテキストを必要とするからです。

自明な解決策 —「アーカイブをOCRすればよい」— は、いつもの死に方をしました。OCRの誤りは劣化スキャン上で複合し、事業価値がある箇所に落ちます。ポンプ曲線の軸は無意味な文字列に変わり、寸法表はずれ、部品表の列は融合します。これこそPerplexityチームが「高価で損失が大きい」と呼ぶ、まず解析してから検索するパイプラインであり — 検索がページを見る前に「レイアウト、表構造、図、空間的関係」を捨て去ります。このライブラリのOCR再構築は6桁の見積もりが出され、二度と資金化されませんでした。

ベクトル検索のパイロットは別の理由で失敗しました。embedding済みテキストは、正しいポンプ曲線の「形」を間違ったリビジョンについて返し、顧客の機械と一致しないマニュアルのガスケット仕様を返したのです。ベクトルインデックスの中に、あるインペラが別のインペラを後継することや、あるトルク表が特定のシリアル範囲で撤回されたことを見出す仕組みはありません。もっともらしく、確信に満ちて誤っている — まさに誤った部品を出荷させる回答です。アシスタントは棚上げされ、2名のシニア技術者がシステム・オブ・レコードであり続けました。当サイトの以前のサポート・ナレッジグラフ記事は、ソフトウェア文書で同じ失敗モードを示します。スキャンされたハードウェアライブラリでは、誤った回避策ではなく誤ったページを選び出します。

エージェントオーケストレーションの解決策：ページの下にグラフ、ページの上に埋め込み

機能するパターンは、各層にそれぞれの得意なことだけをさせます。

レイヤー1 — ページ単位のナレッジグラフ。 すべての文書がノードになり、文書内の各ページもノードになります。レンダリング画像は一度だけ保存します。部品、ポンプ機種、シリアル範囲、リビジョンがノードであり、エッジは質問に答える事実です。マニュアル4412はモデルSP-200を文書化する。ページ118にインペラ表がある。インペラ88-114はシリアル43-0850超で88-114Aを後継する。ブリティン91-07はページ40のトルク表を撤回する。そしてNetSuiteの注文履歴から — シリアル43-11092は1998年に特定のディーラーへ出荷され、その所有者はサービス契約を保有している。これらのどれも、ページがテキストであることを要求しません。グラフは、会社がすでに保持しているカタログ、注文記録、リビジョンカードから構築します。

レイヤー2 — レンダリング済みページ上のページ単位埋め込み。 スキャンされた70%はOCRを必要としません。2026年10月7日にリリースされたPerplexityのpplx-embed-v2-late系列は、「OCRや解析済みテキストを必要とせず、レンダリング済みPDFページを直接検索するtext-to-image検索を扱います」。両サイズ — 0.6Bと9B、MITライセンスでHugging Faceに公開 — はトークンごとに1個の128次元ベクトルを生成し、ColBERT流のMaxSimでスコアリングします。これがポンプの質問に必要な細部を保ちます。「インペラ」「SP-200」、描かれた軸径は、同じレンダリング済みページの別々の領域に一致するのです。MADQA — 実環境の異種PDF 800件、18,000ページ超、一般知識では答えられないよう書かれた500問題 — では、9Bモデルが92.4%、0.6Bモデルが90.1%を正答します。ビジュアル文書ベンチマークViDoRe(v3)では、0.6Bモデルがアクティブパラメータ数の5倍を持つモデルに匹敵します。両モデルは単一のembedding空間を共有するため、ライブラリは9Bモデルで一度だけ索引付けされ、チケットのライブ照会は0.6Bエンコーダを通ります。これは、ベンダーではなく自社の管理下にあるハードウェア上で完全に実行できるという細部であり、マニュアルが顧客サイトの機密を伴うときに重要になります。

レイヤー3 — 段落ではなく引用で終わるエージェントフロー。 Model Context Protocol（MCP）を話すコネクタモジュールが、Zendesk（チケット、依頼者、添付）、NetSuite（注文、シリアル履歴、保証状態）、グラフ照会ツールを包みます。フローはこうです。エージェントがチケットと写真添付を読み、埋め込みに候補となるレンダリング済みページを問い合わせ、次にグラフを辿って候補ページの主張を確認します — 正しいリビジョン、正しいシリアル範囲、正しい後継状態 — そして実物のPDFページを添付し、品番をテキストで示し、根拠を明示（「ブリティン91-07に基づき、ページ表はページ40」）して回答します。ガバナンスルールは一行であり、それが構造を支えます。ページ引用なし、送信なし — チケットは人へエスカレーションします。購入系の質問は、ライブの在庫可能性を保持するRFQエンジンへ引き渡され、価格付きの見積もりで解決を閉じます。ディーラー宛の要求はスコープを絞ったA2Aエージェント経由で委任され、検索とグラフの各ステップはモジュールコード標準のパターンに基づいて記録されます。実装ガイドはグラフそのものの構築を扱います。これは運用パターンであり、どんなアーカイブにも効く保証ではありません。

2名のシニア技術者は、別の高度でループにとどまります。安全に関わるものを承認し、フラグ付き低信頼キューをレビューし、グラフで裏付けられない事柄を処理します。彼らはライブラリの索引ではなくなります。

結果

同じチケット、二つの解決方法 — 今日の手動検索と、正確なページを添付して回答するエージェントフローの比較:

この形のデプロイをこの会社の規模で行った場合の代表的な目標、およびパターンが依拠するベンチマークのエビデンス:

指標	現状	エージェントオーケストレーションの目標
文書関連質問の初回応答	14時間（ディーラーメール中央値）	2分弱、ページ引用 + レンダリング添付
社内処理の中央値時間	22分の手動検索	3分 — 技術者が添付ページを検証
シニア技術者のエスカレーション負荷	文書関連質問の55%（週約19時間）	文書関連質問の20%未満
誤部品出荷	四半期9件（年3.8万ドル）	パイロット四半期1件
検索可能ページ	54,000（テキスト層のある30%）	約180,000、レンダリング済みページのままで

パターンを支えるエビデンス：実環境のスキャンPDF上のエージェントQAでOCRパイプラインなしに92.4%の精度、LinkedInで測定された77.6%の検索精度改善のグラフ構造検索、そしてサポート・ナレッジグラフ導入がソフトウェア側で実証したプロファイル（28時間の解決を7へ、エスカレーション45%を18%へ）。正直なスコープ表示：MADQAはベンチマークであり、すべてのアーカイブへの約束ではありません — だからこそ、引用ルールと人間レビューがループにとどまるのです。

より深い変化は、ライブラリの劣化が止まることです。どの文書がどれの後継か、どの部品がどれの代替か、どの機械がどのリビジョンを受けたかが、引退が近い二人の頭脳ではなくグラフに記録されます。

関連読み物

• カスタマーサポートの解決時間7時間：ナレッジグラフがチケット処理時間を75%削減する仕組み — ソフトウェア側の姉妹ユースケース
• GraphRAG実装ガイド：テキストドキュメントから本番環境のナレッジグラフ検索まで — ページ単位グラフを構築する5段階パイプライン
• カスタマーサポートのためのGraphRAG：ナレッジグラフがデータベースでは答えられない質問に答える方法 — 構造化検索がコストに見合うのはいつか

---

スキャン版が70%を占める12,000文書を持つポンプ製造業者は、文書検索のたびに22分を失い、どんなシステムもポンプ曲線を読めないために時折誤った部品を出荷します。ページ単位のナレッジグラフ、OCRなしでレンダリング済みページを検索する埋め込み、そして正確なページを添付して回答するエージェント — ページ引用なし送信なしで制限された — がライブラリを再び答えられるものにし、RFQエンジンが「どの部品が適合するか」を価格付きで確保された見積もりへ変えます。

スコープを絞った構築を依頼する

1週間のディスカバリー。構築の有無にかかわらず、システムインベントリ、ワークフローマップ、固定スコープを取得できます。