Search Candy

Search Candy

SearchCandy Labs · コーディング · ビジネス

Search Candy は SearchCandy Labs が提供する AI エージェント向けのホスト型検索レイヤー。Temporal Graph Memory が原文の一節をファイル名とバージョン付きで返し、LLM は一切呼ばない。

Search Candy の画面プレビュー

Search Candy について

About

Search Candy とは

Search Candy は AI エージェントのために作られた文書検索サービス。SearchCandy Labs は、一般的な検索パイプラインのチャンク分割を置き換えるものとして売り出している。テキストと Markdown のファイルを預けると、同社が Temporal Graph Memory(TGM)と呼ぶグラフが組み上がり、エージェントはそのグラフに問い合わせる。

狙いは追跡可能性にある。普通のベクトルストアでは文書が固定長のチャンクに刻まれ、チャンクは文の途中から始まることもあり、返ってきた答えがどのファイル由来かはほとんど分からない。Search Candy はファイルごとにひとつのまとまりを作り、一節を文末で切り、元の文言にファイル名とバージョン番号を添えて返す。出典を尋ねれば、類似度スコアではなく出どころが返る。

守備範囲は狭い。すでにエージェントを動かしている開発チーム向けの配管であって、チャット製品ではない。検索エンジンの中に生成モデルはなく、Search Candy が答えを書くことはない。扱えるのは今のところテキストと Markdown だけで、他の形式は導入時に変換する。

使い始める

  1. SearchCandy Labs のサイトから 30 分の打ち合わせを予約し、AI に必ず正解させたい質問を持ち込む。
  2. チームがアカウントを用意し、ログイン用のリンクをメールで送る。
  3. テキストか Markdown のファイルを追加し、各ファイルの受領記録を残す。
  4. Python ライブラリを接続し、既存の埋め込みモデルを続けたいなら自前のモデルを指定する。
  5. エージェントから問い合わせ、返ってきた一節とファイル名、バージョンを確認する。

AIツール情報

Search Candyの料金、対応プラットフォーム、性能を簡単に確認できます。

無料プランいいえ
有料プランCustom pricing, quoted after a pilot call
プラットフォームWeb (hosted API and Python library)
開発元SearchCandy Labs
カテゴリコーディング · ビジネス
リリース日Dec 2024
最終更新Oct 2026
サイト訪問数52
サイト世界ランキング11.6M
API提供状況はい

こんな人におすすめ

このツールが最も力を発揮するユーザー、タスク、シーン。

ユーザー

  • AI エージェントを作る開発者
  • 規程や契約書を大量に抱えるチーム
  • サポートやドキュメントの責任者

タスク

  • 回答に引用を付ける
  • 二段階の質問に答える
  • 先月 AI が何を見たかを監査する
  • チャンクサイズの調整をなくす

シーン

  • 最初の検索プロトタイプ
  • 版をまたぐ契約の確認
  • サポート担当へ根拠を渡す

主な機能

チャンクではなく文書グラフ

Search Candy は預かったファイルをそれぞれ独立したまとまりとして扱い、短いファイルは丸ごと残す。長い文書は文末で区切った一節に分かれ、どの一節も自分のファイルに繋がったままになる。引用が成り立つのはこの構造のためだ。結果は出自の文書を知っている。繋がりを最後まで失わないからだ。

二段構えの検索

ある事実が次の事実を指すとき、エンジンは直前に見つけた一節を使って検索をやり直す。7,405 問の公開二段階質問集 HotpotQA で、Search Candy は必要な一節が上位 20 件に入った割合を 98.4% と報告する。同じ文書を通常検索した場合は 94.8% だ。ベンダー公表の数字であり、自分の質問で試すべきものになる。

文書のバージョン履歴

文書のバージョン履歴は、最初のうちほとんどのチームが見落とす部分。ファイルの改訂はすべてグラフに残るので、過去の日付を指定すれば、エージェントがその日に受け取った一節を一字一句そのまま取り出せる。規程や価格、契約について答えるチームにとって、「3 月に AI は何を見たか」は推測ではなく問い合わせになる。

出典付きの逐語的な一節

結果は原文のまま返り、書き換えられることはない。どの一節にもファイルとバージョンが付く。根拠のない質問には not_covered という信号も付ける。誤答の代償が無回答より大きい場面では、この区別がものを言う。

検索の回路に LLM を置かない

検索エンジンは言語モデルを呼ばない。文書を漁ってもトークン課金は増えない。答えを書くのはエージェント側のモデルだ。問い合わせが多い社内アシスタントでは、この分担によって検索コストが件数に比例して膨らまない。

ホスト型の運用と自前の埋め込み

サービスは SearchCandy Labs が運用するので、デプロイするものはない。既存の埋め込みモデルを持ち込むこともでき、接続は Python ライブラリが担う。代わりに、ホスティングや権限、クラウドの選択は今のところベンダー任せになる。

メリットとデメリット

メリット

  • どの結果にもファイル名とバージョンが付くので、引用の確認は数秒で終わる。
  • 使える結果が出るまでに調整するチャンクサイズも重複幅も分割器もない。
  • バージョン履歴があるため過去の日付の質問に答えられる。多くのベクトルストアにはできない芸当だ。
  • 検索エンジンが LLM を呼ばないので、文書量がそのままトークン費用にならない。
  • 公開ベンチマークのページに、注意点と「引き分け」に終わった比較まで載せている。

デメリット

  • 現状はテキストと Markdown のみ。PDF やスキャンした契約書は導入時に変換が要る。
  • SOC 2 報告書も細かな権限管理も自社運用の選択肢もまだない。規制業種の購買には届かない。
  • 利用は商談から始まり、価格は非公開。日曜の夜にひとりで評価するわけにはいかない。
  • 自社の BEIR テストでは LangChain の標準構成と引き分けている。利点は追跡可能性と二段階検索にあり、上位 10 件の再現率ではない。

よくある質問

Search Candy がファイルから組み上げる構造のこと。各文書は独立したまとまりになり、その背後に版が積み重なり、一節は共通のチャンク山ではなくそのまとまりの中に入る。一節と出どころの繋がりを切らないための設計だ。