> For the complete documentation index, see [llms.txt](https://library.zoom.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://library.zoom.com/technical-library/ja/ai/ai-whitepaper/agentic-search.md).
# エージェント型検索
## **Agentic Searchとは何ですか？**
#### Agentic Searchは、Zoomコンテンツと接続されたエンタープライズデータソース全体にまたがる、統合された権限対応のコンテキスト層です
Agentic Searchは、エンタープライズ向けのナレッジ検索機能であり、Zoomネイティブのコンテンツと接続されたサードパーティのデータソース全体から関連情報を収集、インデックス化、関連付けし、クエリが照合される単一の組織ナレッジベースを形成します。従来の検索と異なるのは、1回のクエリで参照できる範囲の広さです。ミーティングの文字起こし、Team Chatメッセージ、企業のクラウドドライブに保存されたドキュメントが、すべて同じ結果に寄与し得ます。その結果の形は入口によって異なり、自然言語での要約応答であったり、別のモデルが推論できるように根拠付きソース資料を順位付けして並べたセットであったりしますが、またがるソースと、それらに対して適用される権限は変わりません。
Zoom内では、取得は、すでにプラットフォーム上に蓄積されている作業記録—ミーティング録画や文字起こし、ミーティング要約、Team Chatでの会話、そしてそれらと併せて作成されたドキュメント、メモ、その他のアーティファクト—にまたがります。Zoomの外では、取得は接続されたシステム・オブ・レコードとコンテンツリポジトリにも拡張され、Salesforce、Google Drive、OneDrive、SharePoint、Confluence、Box、ServiceNow、Workday、Zendesk、Seismicなどのサービスを含みます。インデックス作成がサポートされ有効化されている場合、これらのシステムのコンテンツはZoomネイティブ情報と並んでZoomの取得レイヤーに取り込まれ、質問は、それぞれを個別の条件で検索しなければならない孤立したリポジトリ群ではなく、単一の組織ナレッジに対して解決されます。
取得は全体を通じて権限対応です。各ソースシステムのアクセス制御は継承されて適用されるため、表示される情報—Zoomネイティブのものでもサードパーティのものでも—は、要求したユーザーまたはエージェントに適用可能な権限に基づいて制限されます。検索対象ソースを増やしても、個々のユーザーのアクセス範囲が広がることはありません。
#### 「Agentic Search」はインターフェースではなく機能を表します
Agentic Searchは、特定の画面やボタンというより、基盤となる機能として理解するのが最適です。同じ機能には複数の方法でアクセスできます。日常利用者向けにはZoomMateインターフェースから、アプリケーションやAIエージェント向けにはSearch API、Ask API、およびModel Context Protocol (MCP) から利用できます。どの入口を使っても、この用語が指すのは同じ中核機能、つまりソースをまたいで関連情報を取得し要約することです。
#### ZoomMateはAgentic Searchを使って、接続された組織ナレッジからインデックス化されたデータを取得し、その結果を自然言語の応答に要約します
日常利用者にとって、ZoomMateはAgentic Searchが日常業務になる場所です。予定されているミーティングの準備、過去の複数のミーティングにまたがる決定の想起、進行中のアクションアイテムに紐づくドキュメントの特定は、それぞれ個別にミーティング、チャット、ドキュメント、クラウドストレージ、CRMやチケット管理システムを検索するのではなく、1回のリクエストで解決できます。
#### MCPとSearch APIおよびAsk APIは、同じ取得機能をアプリケーションと外部AIエージェントへ拡張します
サードパーティのLLM上に構築されたものを含むアプリケーションと外部AIエージェントは、MCPを通じてAgentic Searchをツールとして呼び出します。アクセス制御は呼び出しとともに引き継がれるため、エージェントが取得する情報は、認証済みユーザーの権限に一致します。
Search APIは **Search API** 関連性の高い結果を順位付きで返し、生成は呼び出し元自身のモデルに委ねます。これは、生の根拠付きソース資料を望ましい出力とするケースに適しています。
Search APIは **Ask APIは** Zoom内で取得と生成の両方を実行し、自然言語で要約された引用付き回答を返します。
#### 常設インデックスとリクエスト時取得により、頻繁に変化するデータを最新の状態に保ちます
Agentic Searchは静的なインデックスに限定されません。コンテンツはベクトル化、インデックス化、キーワード付けされ、承認済みのサードパーティコンテンツは管理者スコープの増分同期によって取り込まれ、後続の効率的な取得に備えます。頻繁に変化するデータや、リクエスト時の鮮度が有効なデータは、インデックスから提供されるのではなく、MCPや同等のリアルタイム接続を通じて直接問い合わせることができます。
常設インデックスとリクエスト時取得を組み合わせることで、コンテキスト層は最終同期時点ではなく、接続されたシステムの現在の状態を反映します。
## **データソースとインデックス作成**
#### Zoomのインデックス作成アーキテクチャは、会話型AIの取得に専用設計されています
Zoomのインデックス作成アーキテクチャは、会話型AI向けに専用設計されており、ベクトル検索、コンテンツのチャンク分割、そして会話型システムがコンテキストを取得する方法に合わせて設計されたスキーマを採用しています。多くのエンタープライズ検索およびグラフ技術は、もともと別の目的、つまり生産性環境全体でドキュメント、人、メタデータ、その他のエンティティを結び付けることを前提に設計されていました。このアーキテクチャ上の違いは重要です。会話型AIが必要とするのは、主としてドキュメントやエンティティ間の関係をたどることではなく、ユーザーの質問に意味的に関連する特定の情報片を識別して取得することだからです。Zoomのアプローチは、この取得モデルに合わせてコンテンツを構造化しインデックス化するため、会話型のユースケースは別目的のシステムの上に後付けされた機能ではなく、中核的なアーキテクチャ上の考慮事項になります。
言い換えれば、図書館を個々の本で索引付けするのと、誰かが質問に答えるために実際に必要とするかもしれない箇所で索引付けするのとの違いです。
#### サードパーティコネクタは、管理者による有効化を条件に、Zoomのコンテキスト層を認可済みのサードパーティシステムへ拡張します
Agentic Searchは、Google Drive、OneDrive、Box、Salesforce、ServiceNow、Zendesk、Seismic、Confluence、SharePointなど、認可済みのサードパーティコネクタからのインデックス作成をサポートしており、現在のリリース状況に応じて追加のコネクタも利用できます。コネクタが利用可能であることは、そのコンテンツが自動的に検索可能になることを意味しません。Agentic Searchが取り込みを開始する前に、各ソースは管理者によって有効化される必要があります。この管理者ゲート式モデルは意図的なもので、インデックス作成の範囲を、組織が実際に許可した内容に合わせるよう設計されており、接続可能なすべてのシステムをデフォルトで公開しないようにしています。
#### インデックス作成の仕組み: 取り込みからクエリ可能なインデックスまで
コネクタが有効化されると、Agentic Searchは毎回ソースシステムを新たに照会するのではなく、承認済みコンテンツの検索可能なインデックスを構築します。処理は複数の段階を経て進みます:
1. **取り込み** — 承認済みコンテンツは、管理者が許可した範囲と接続ユーザーの権限に従って、接続先ソースから取得されます。クラウドドライブのようなファイルベースのソースでは、単にリンクされるだけではなく、処理のためにドキュメントコンテンツが取得されます。
2. **セグメント化** — 取得されたコンテンツは、ドキュメント全体ではなく、クエリに関連するドキュメントの特定部分を取得できるように、より小さな文章断片に分割されます。
3. **ベクトル化** — 各断片は埋め込みモデルを使って数値埋め込みに変換され、取得が完全一致の文言だけでなく意味でも照合できるようになります。
4. **キーワードインデックス** — コンテンツはキーワード照合用にもインデックス化されます。Search と Ask の両機能は、ベクトル類似度に加えてキーワード一致に依存しており、両者は代替ではなく連携して動作します。
5. **権限メタデータのインデックス** — ユーザーのアクセス情報はコンテンツと並んでインデックス化され、ソースシステム本来の権限から取得されます。そのため、クエリ時に権限対応のフィルタリングを適用できます。
その結果、顧客固有の取得インデックスが作成されます。ソースのコンテンツは共有ストアやテナント横断ストアではなく、その顧客向けにスコープされ、その顧客の権限によって管理される形式で保存されます。
#### 図とデータフローを参照できます
ZoomのAgentic Searchがサードパーティのアプリケーション、サービス、データソースにどのように接続するかを示す図—接続およびインデックス作成のデータフローを含む—は、 [Zoom AIホワイトペーパー](https://library.zoom.com/ai/ai-whitepaper/diagrams#zoommate-third-party-connections-and-indexing).
#### インデックス化される内容は、管理者がコネクタに対して許可する範囲によって決まります
インデックス化されるコンテンツは、管理者がコネクタに対して許可する範囲によって決まります。ソースが接続されると、インデックスは一度きりの取り込みではなく継続的な更新によって維持されます:
1. **初回同期**— 初回設定時に、コネクタは既存の履歴コンテンツを含む、対象範囲内コンテンツの完全同期を実行します。
2. **日次インデックス更新**— 一部のソースでは、コネクタが対象範囲内コンテンツを1日1回更新します。
3. **増分同期**— その他のソースでは、コネクタが1日を通して定期的に同期を実行し、毎回リポジトリ全体を再処理するのではなく、前回の同期以降に追加、変更、または更新されたコンテンツのみを処理します。
#### インデックス取得とリアルタイム取得は連携して動作します
Agentic Searchは2つの取得経路を使用し、どちらが適用されるかは、ソースがどのように接続されているか、そしてどのようなデータを保持しているかによって決まります。ユーザーや管理者が切り替える、クエリ単位やフォルダ単位の設定ではありません。
コンテンツが **アカウントレベルのデータソース** として管理者パネルで接続されると、顧客固有のインデックスに取り込まれ、そこから検索されます。これは非構造化コンテンツ—ドキュメント、ナレッジ記事、ファイル—に対するデフォルトの経路です。あらかじめ構築されたインデックスにより、クエリ時の取得が高速かつ効率的になり、組織全体で共有される検索可能なインデックスが作成されるためです。
コンテンツは **MCPまたはAPIを通じて、直接リアルタイムに** その他の場合に到達します。個人のメール、カレンダー、個人用クラウドストレージなど、個々のユーザーが認可する個人コネクタ、CRMオブジェクトデータのような構造化レコード、そしてリクエスト時の鮮度が有効な、頻繁に変化するその他のコンテンツがそれに当たります。個人コネクタは接続ユーザーがアクセスできるドキュメントのみを取得し、構造化データ接続はインデックスから提供されるのではなく、独自のユーザー認証と認可を伴います。
その経路は接続方法に従うため、同じ基盤アプリケーションでも設定に応じてどちらの方法でも利用できます。管理者が管理するデータソースとして接続されたクラウドストレージサービスは組織全体の検索向けにインデックス化されますが、個人のコネクタとして接続された同じサービスは、直接問い合わせられ、そのユーザー自身のアクセス範囲に限定されます。
#### 外部Agentic Search接続はModel Context Protocol (MCP) 上に構築されています
Zoomと外部モデル、ツール、データソースの間の接続は、モデルをツールとデータに結び付けるためのオープンなクライアント-サーバー標準であるModel Context Protocol (MCP) 上に構築されています。MCPサーバーはZoomのエッジで動作し、接続されたシステムからのリアルタイム取得と、ツールとしてAgentic Searchに到達する外部エージェントの両方に対して、取得リクエストを行うための一貫したインターフェースを提供します。この標準化されたトランスポートは、ソースごとの個別実装を共通の接続モデルに置き換えます。
#### インデックス作成時間は顧客、データ量、データタイプによって変わります
特定のコネクタが完全にインデックス化されるまでの所要時間に固定のタイムラインはありません。必要時間は、インデックス化されるデータ量と対象データの種類に応じて、顧客ごとに異なります。インデックス化対象のサードパーティプラットフォームによって課されるレート制限も要因の一つです。各ソースシステムは、一定時間内に取り込めるデータ量を制限しており、その制限はプラットフォーム、プラン階層、API設計によって異なります。大規模または頻繁に使用されるリポジトリについて初回インデックス作成を計画しているお客様は、当日中または同週中の完了ではなく、数週間単位の期間を見込むべきです。
#### インデックス作成容量はZoomMateのライセンス階層に応じて拡張し、組織レベルでプールされます
インデックス作成容量は、固定の全体配分ではなく、ライセンス階層に応じたものです。各ライセンスユーザーは、その階層に基づく席ごとの容量を提供し、それらの容量は組織全体で共有される単一の組織横断プールに集約され、個々のユーザーごとではなく組織全体に割り当てられます。
接続されたすべてのソースとすべてのユーザーにわたる総インデックス化コンテンツは、組織の合算プール内に収まる必要があります。つまり、大規模リポジトリをインデックス化する1人のユーザーが、他の全員が利用できるのと同じ共有容量を消費します。プールはライセンス席ごとに増加するため、組織の総容量は、すべてのライセンスユーザーが提供する容量の合計です。
たとえば、1ライセンスで1GBのストレージが付与される場合、25ライセンスならアカウントの総ストレージは25GBになります。100ユーザーなら100GBです。
大規模リポジトリ（Confluenceの大規模スペース、巨大なSharePointサイト、成熟したCRMインスタンスなど）をインデックス化する予定の組織は、ユーザーごとの利用パターンではなく、想定される総コンテンツ量に基づいてライセンス階層と席数を決定すべきです。追加のインデックス容量も利用できます。詳細はZoomアカウントチームにお問い合わせください。
#### ファイルサイズとファイルタイプは、インデックス化される内容に影響します
2つの別々のサイズ制限が適用され、動作も異なります:
* **64 MBの元ファイル上限（ダウンロード）:** ソースファイルの元のサイズが64 MBを超える場合、そのファイルはスキップされ、処理のためにダウンロードされません。
* **16 MBの処理済みコンテンツ上限（インデックス化）:** ダウンロードされたファイルは、統一された処理形式に変換されます。結果として生成された処理済みファイルが16 MBを超える場合、コンテンツの最初の16 MBのみがインデックス化され、残りはインデックス化されません。
2つの制限は失敗の仕方が異なります。元ファイルが大きすぎる場合は完全にスキップされますが、処理済みファイルが大きすぎる場合は除外ではなく切り詰められるため、冒頭のコンテンツは取得対象になりますが、後半のコンテンツは対象になりません。
また、インデックス化はサイズとは無関係にファイルタイプにも依存します。マルチメディアコンテンツ—オーディオ、ビデオ、画像—は、サイズにかかわらずインデックス化されません。これは、いずれのサイズ上限も評価される前に、統一された処理形式への変換時に除去されるためです。メタデータはすべてのドキュメントに対してインデックス化されますが、完全なコンテンツがインデックス化されるのは、サポートされる非メディアファイルタイプのみです。サポートされないタイプでも、ドキュメントはメタデータから発見できますが、内容は検索できません。
#### 管理者は現在、コンテンツがインデックス化される順序を制御できません
現在、管理者が接続されたソース内で、特定のフォルダ、スペース、またはコンテンツタイプを他より優先してインデックス化させる仕組みはありません。インデックス化は、有効化されたコネクタ内の対象コンテンツ全体で順次進みますが、順序付ける方法はないため、組織は最も価値の高いコンテンツを先行してインデックス化することはできず、最重要業務資料から始めるのではなく、リポジトリ全体にわたって徐々にカバレッジが広がると考えるべきです。
インデックス化を、任意の時刻や頻度で実行するようにスケジュールすることもできません。ソースが有効化されると、インデックス化は管理者が設定したスケジュールではなく独自のタイミングで実行されるため、特定のウィンドウに合わせて調整できるものではなく、完了したときに完了するバックグラウンドプロセスとして扱うのが最適です。
## **管理、権限、ガバナンス**
#### 管理者は接続するソースを制御でき、ユーザーは自分のアクセスを認証します
コネクタは管理者によって有効化され、組織内でインデックス化と検索に利用できるサードパーティシステムを管理者が決定します。コネクタを有効化するとソースは組織で利用可能になりますが、その内容へのアクセスが自動的に付与されるわけではありません。各ユーザーはソースへのアクセスを個別に認証する必要があり、認証後は取得権限がソースシステム内で既に持っている権限と一致するため、そこで既にアクセスできたものだけが表示されます。
#### 取得は権限対応で、読み取り専用です
Agentic Searchは各ソースシステムのアクセス制御を適用するよう設計されているため、回答にはユーザーがすでに閲覧を許可されているコンテンツのみが反映されます。同じ質問でも、サードパーティデータソース内でのそれぞれの権限に応じて、2人のユーザーが異なる結果を受け取る場合があります。取得は読み取り専用で、各ソースの保持ポリシーに従います。たとえば、Zoomのミーティングコンテンツは、検索レイヤーによって別途保持されるのではなく、適用される保持期間に従います。取得はクエリ時に統制され、権限対応であるため、生の文字起こしや記録を一括エクスポートする代替手段にもなり、アクセスを元のサードパーティソースに揃えたままにできます。
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://library.zoom.com/technical-library/ja/ai/ai-whitepaper/agentic-search.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.