Skip to main content

概要

search_notes は、キーワードに一致したノートを主要ドキュメント(ワンページャー、カスタム)とともに返します。決定事項やアクションアイテムなど、ノートの内容まで確認したいときに使用してください。 軽量なメタデータのみの一覧表示(例: 「フォルダ X にはどのノートがありますか」)には、代わりに list_notes を使用してください。 使用する場面
  • 「OKR Q2 についてチームは何を決めたのか?」
  • 「この決定のソースノートはどこか?」
  • 「네이버 に言及しているノートを見せて。」
動作
  • キーワード必須。結果は全文検索の関連度(同点の場合は createdAt の降順)で並べ替えられます。
  • 一致した各ノートには、主要ドキュメント(ワンページャー、カスタム)がインラインで付きます。
  • ドキュメントのコンテンツから HTML を除去します。5,000 文字を超えるドキュメントは打ち切られ、フラグが付きます。
  • 検索インデックスが利用できない場合は、通常のレスポンスに degraded: true、空の notesdegradedReason を含めて返します。
workspace-scoped key で呼び出すと、キーワードが一致していても個人フォルダのノートは結果から外れます(システムAPIキーが読み取るノートの範囲)。
list_notes より重い。 各結果にはドキュメントのコンテンツが含まれます(ノートあたり ~1,500 トークン)。デフォルトのページサイズは 10、最大 30 です。メタデータのみが必要な場合は list_notes を使用してください。

パラメータ

keyword (required)

検索語です。サーバー側でトークン化され、韓国語テキストは形態素解析されます(例: 네이버[네, 버])。空または空白のみのキーワードは 400 を返します。 キーワード検索は、user-scoped と workspace-scoped のどちらの API key も受け付けます。workspaceGuid を省略するとアクセスできるすべてのワークスペースを横断して検索します。workspace-scoped API key は接続されたワークスペースのみを検索します。特定のワークスペースに限定するには workspaceGuid を渡してください。

filter.folderId (optional)

list_notes と同じ意味です。再帰的なフォルダ範囲で、サーバー側で認可されます。

filter.createdAtFrom / filter.createdAtTo (optional)

createdAt に対する半開区間 [from, to) の範囲フィルタです。どちらも末尾が Z の ISO 8601 UTC 日時を受け付けます。関連度順の検索結果件数が制限される前に適用されます。 年・月・日の条件は、ユーザーのタイムゾーンの境界を UTC に変換してください。たとえば韓国標準時の 2025 年 7〜8 月は、createdAtFrom: "2025-06-30T15:00:00Z"createdAtTo: "2025-08-31T15:00:00Z" です。

pagination (optional)

{ cursor, size }。デフォルト size: 10、最大 30。この上限は、結果あたりのコストが高いこと(各ノートがドキュメントを伴うこと)を反映しています。

レスポンス形式

成功レスポンス

フィールドの説明:
templateTitle で判別しないでください。 これは表示用ラベルであり、enum ではありません。ブール値のチェック(「これはワンページャーか?」)には、既知の管理済みテンプレート ID に対して templateId を使用するか、両方のフィールドを提示して UI にラベルで選ばせてください。

縮退レスポンス

検索インデックスが利用できない場合、レスポンスは degraded=true を設定し、空の notes 配列を返します。
degradedReason は次のいずれかです。
  • search_index_unavailable — この環境では検索インデックスが無効になっています。
  • search_index_degraded — クエリの途中で検索インデックスがエラーを投げました。
リトライを延期したり結果を適切に解釈したりできるよう、これを LLM/ユーザーに提示してください。

使用例

例 1: トピック検索

リクエスト:
OKR に言及する最も関連度の高いノート 10 件を、それぞれの主要ドキュメントをインラインで付けて返します。

例 2: フォルダ限定の韓国語キーワード

リクエスト:
フォルダ 455765(とその子孫)の中だけで 네이버 を検索します。韓国語の形態素解析はサーバー側で実行されます。

例 3: 日付で区切った深い検索

リクエスト:

ベストプラクティス

まず list_notes を使って、どのノートが一致するかを見つけてください。LLM が答えるためにドキュメントの内容をなお必要とする場合は、同じキーワードで search_notes に切り替えます。これが最も安価な段階的開示のパスです。
フォルダ限定の検索は、関連度の空間が小さくなるため、より高速で、より良くランク付けされた結果を返します。まず list_notes(filter.folderId) と組み合わせてフォルダ候補を見つけてください。
深い検索 endpoint は現在 nextCursor: null を返します。30 件の結果で足りない場合は、ページネーションするのではなく、キーワードを絞り込む(より具体的に)か、folderId/dateRange で範囲を限定してください。
degraded=true のレスポンスは正直です。検索インデックスが実行できなかったのです。空の notes 配列を「一致なし」と扱わないでください。代わりに、リトライのタイミングを適切に計れるよう、縮退をユーザー/LLM に提示してください。

よくあるエラー

空のキーワード

keyword は最低 1 文字以上である必要があります(zod min(1))。空のキーワードは、カスタムエラーコードではなく MCP 標準の validation エラーで拒否されます。

トークン使用量

ノートあたり(ドキュメント付き): 平均 ~1,500 トークン。打ち切られたドキュメントは、元のサイズにかかわらず ~1,500 トークンで頭打ちになります。
get_note_transcript(会議 1 時間あたり ~3,000–5,000 トークン)と比べてsearch_notes は通常 10 倍コンパクトで、同じ重要な決定事項をカバーする、整理されたドキュメントを返します。話された言葉そのものが必要なときにのみトランスクリプトを使ってください。