数眼智能AI：LLMにウェブ解析・リアルタイム検索・文書OCRを足すデータ基盤

エージェントを作っていると、必ず同じ壁に当たる。モデルは十分に賢いのに、読ませたいページが見えていないのだ。知識が学習時点で止まっているか、HTMLがナビゲーションと広告に埋もれているか、決め手の資料がスキャンPDFとしてしか存在しないか。数眼智能AIが狙うのはこの隙間である。モデルを訓練するのではなく、外界をモデルが飲み込める形に整える配管を売っている。導入する価値があるかは3点で決まる。抽出結果が本当にきれいな構造化データか、検索結果が検証可能な出典まで辿れるか、必要な並列数で遅延が保てるか。

公式の位置づけは「大規模モデル時代のインテリジェントデータ基盤」であり、技術方針は「視覚＋コード」のデュアルモーダルと説明される。一方はレンダリング後のページをコンピュータビジョンで理解し、もう一方はコードのロジックで構造を抽出し、両者が互いに検証し合う。この組み合わせが狙うのは従来のスクレイピングの弱点、すなわちクライアント側で描画されるため単純なHTTP取得では見えないページと、レイアウト変更で壊れる脆いセレクタである。ベンダーは自社システムが300以上の領域、数億件級の構造化データを覆い、広告ノイズを除去すると述べている。

製品群は3層に分かれる。最下層がウェブ解析・検索・OCRの3つのデータインターフェース、中間層が複数モデルの集約呼び出し、対話型エージェント、深掘り調査、MCPワークフロー連携をまとめたモデル広場、周辺にデータセットサービスとBI分析基盤がある。多くの開発チームが実際に使うのは最下層の2〜3本であり、残りは同じベンダーの隣接機能として個別に評価すればよい。

中核機能の仕組み

ウェブ解析：レンダリング後のページを読めるテキストに戻す

対象URLを送ると、構造化MarkdownまたはJSONが返る。価値は「取得できること」ではなく、取得後にクリーニング規則を書かなくて済む点にある。本文、見出し階層、表は可能な限り保たれ、広告とナビゲーションは除かれる。検索拡張生成のパイプラインでは、この工程がチャンク品質の上限を決め、チャンク品質が検索精度の上限を決める。汚い入力は埋め込み空間で似ているのに役に立たない断片を生むだけだ。動的レンダリングや複雑なレイアウトに対応するとの説明は、純粋なDOM解析に対する視覚解析の意味そのものである。

リアルタイム検索：出典に遡れる検索層

検索APIはモデルによる利用を前提に設計され、リンクの羅列ではなく関連度で採点された構造化済みの断片を返す。情報源はニュース、百科事典、学術資料、メディアプラットフォームなどに及び、大規模なクロールと自社構築のサイトアーカイブに対して継続更新される。調査系アプリでの差は参照範囲に出る。ベンダーは深掘り調査モードが通常検索の7倍のページを参照すると述べており、これは長いコンテキストと主張の突き合わせの余地を意味する。

文書OCR：文字だけでなく階層を保つ

PDFやスキャン画像を渡すと、エンジンは本文、表、数式を抽出し、文書構造を保ったMarkdownとJSONとして出力する。難しいのは個々の文字の認識ではなく、組織の復元である。どの行が見出しで、どの表が3ページにまたがり、数式のどの記号が下付きなのか。階層は下流で効く。ナレッジベースは見出し階層で分割するため、構造を失えば固定文字数で切るしかなく、文と表が途中で断ち切られる。

モデル広場とMCP：モデル呼び出しとデータ注入を同じ層に

モデル広場は複数ベンダーのモデルを1つの窓口に集約し、課金と応答形式を統一する。開発側が複数の配備を維持せずに済む。MCP連携は検索と解析を標準インターフェースでAIワークフローに注入するため、すでにこのプロトコルを使うチームはツール呼び出しのロジックを書き直さずに済む。両者を重ねる実務上の意味は、データ側とモデル側の設定を同じ場所に置けることだ。別々の連携による別々の障害点が減る。

導入の手順

1. 公式サイトでアカウントを登録し、APIキーを取得する。新規は500回の無料枠があり、予算を決める前に3つのAPIを一通り動かせる。
2. ウェブ解析は、自分が本当に重視するページで検証する。動的レンダリング、複雑な表、長文のページ分割を含む実URLを10〜20件選び、返ってきたMarkdownが必要な構造を保っているかを見る。公式のサンプルページだけで判断してはいけない。
3. OCRは先に境界サンプルを用意する。2段組のレイアウト、ページをまたぐ表、数式を含むスキャン画像である。構造の崩れはこうした資料に集中するため、公開前に見つけたほうが安く済む。
4. すでにDifyやCozeを使っているなら、サーバー側を書かずにエージェントのワークフロー内に組み込める。自前で連携する場合はRESTを直接呼び、人が確認するならMarkdown、プログラムが解析するならJSONを選ぶ。
5. 行政や金融など規制の強い領域向けに高並列のプライベート配置が用意されるが、提供形態、期間、費用は公開されていない。商談での確認が必要だ。

料金と枠

• 公開されている唯一の数字は新規アカウントの500回無料枠である。概念検証には足りるが、本番の流量には遠い。
• 課金はトークン単位の従量制で、ベンダーは競合の約3分の1の価格だとし、成功した呼び出しのみ課金すると述べる。成功のみの課金は、解析系では特に重要だ。ページ解析の失敗率は通常のテキストAPIより本質的に高い。
• 各APIの単価、数量による段階折扣、プライベート配置の見積、無料枠超過後の精算方法はいずれも非公開である。コスト試算の前にコンソールか営業経由で確認したい。

向いている利用者

• DifyやCozeでエージェントを組む開発者：クローラやプロキシプールを自前で維持せずに、ページ読取と検索を足したい場合。
• 検索拡張生成のナレッジベースを作るチーム：社内資料の多くがPDFやスキャンで、まず分割可能な階層テキストにする必要がある場合。
• コンテンツ集約や価格比較のアプリ：商品情報やニュースを継続的に取得・洗浄し、広告ノイズに敏感な場合。
• 金融・行政など規制の強い業界の技術チーム：データを域外に出さないプライベート配置を保ちつつ、リアルタイム検索も維持したい場合。

制約と注意点

• 性能値はすべてベンダー側の説明である。「平均応答1秒未満」「業界平均より40%高速」「エラー率0.01%未満」「価格は競合の3分の1」はいずれも第三者の基準がなく、測定条件やページ種別も示されていない。自社の対象サイトで実測すべきだ。
• 価格の透明性は限定的だ。500回の無料枠以外に、単価、並列上限、レート制限の方針、失敗した再試行の課金有無が公開資料にない。
• 準拠性の詳細は不明である。解析と検索は第三者のコンテンツに触れるため、著作権の境界、robotsの扱い、取得内容の保存期間と利用範囲を書面で確認する必要がある。取得物を再配布する場合は特に重要だ。
• 多言語の精度は明示されていない。公式は「複雑な中国語の場面を精確に処理する」と強調する。中国語サイトには利点だが、対象ページが他の言語中心なら別途検証が要る。
• 確認できる素材は公式スクリーンショット1点のみで、公開ページに製品画面の詳細図はないため、本記事に画像は掲載しない。画面と返却サンプルは公式コンソールで確認されたい。

よくある質問

数眼智能AIはモデルそのものですか

いいえ。データと集約の層である。基盤モデルは訓練せず、ウェブ解析、検索、文書OCRの3つのAPIと、複数モデルへ振り分けるモデル広場を提供する。土台のモデルは自分で選ぶ必要がある。

自前のクローラと比べて何が有利ですか

主に保守コストだ。自前のクローラは動的レンダリング、対ボット対策、セレクタの失効、本文の洗浄に対応する必要があり、一度の改版で全部壊れ得る。マネージドAPIはその負担を提供側に移す。代償は単価と制御性で、抽出規則への関与が弱くなり、特殊なページでの調整余地は限られる。

DifyやCozeに直接つなげますか

公式は両プラットフォームへの対応とエージェントワークフロー内での設定を述べている。プラグイン名と設定手順は各プラットフォームの実際の一覧で確認されたい。本記事では検証していない。

無料枠を使い切ったらどうなりますか

超過後の精算規則と単価は公開されていない。500回の枠内で検証を終え、成功時のみの課金かを確認したうえで見積を取ると、コスト試算のずれを避けられる。