目錄
2026年8月、r/Notionにかなり興味深いProduct Requestが投稿されました。NotionにPageへ直接置けるAI Search Componentを追加し、Workspace Searchを使うたびにGlobal Entry Pointからやり直さなくても済むようにしてほしい、という要望です。この種のRequestは今回が初めてではなく、以前からOfficialの埋め込み型Search Barを求める声はありました。Notion AIがWorkspace内の質問へ答え、Connected Appsを横断して情報を探せるようになった現在、要望が一段進むのは自然です。Enterprise Searchですでに特定Page、Teamspace、SourceへScopeを限定できるなら、そのScope自体をProject Pageへ固定し、検索入口を作業Contextと一緒に残せないのか、ということです。
同じ日、r/NotionではGenerative AIに依然として安定したLong-term Knowledge Layerが足りないという不満も投稿されました。構築したKnowledgeを自然に継続利用できない、Private Knowledgeを完全には接続しにくい、毎回Contextを整理し直す必要がある、以前話した内容を時間が経つともう一度探さなければならない、といった問題です。同じ内容は投稿者自身によってr/ChatGPTにも投稿されていたため、より正確に言えば、2人のNotionユーザーが別々に同じCaseを提示したのではなく、1人のユーザーが同じProblem Setを複数のAI Communityへ持ち込んだ形です。これらを一緒に見ると、実際に問題になっているのは「ModelのMemoryが十分か」だけではなく、Contextを誰が管理するかです。Productivity Toolにとって、AIがすべてを永久に記憶する必要はないかもしれません。仕事を始めるたびに「この質問ではどのData Setを探すべきか」が分かれば、いわゆるMemory Problemの多くはまずRetrieval Layerから解決できます。
Notion Enterprise Searchは現在どこまでできる？
Search Scopeはすでに特定PageやTeamspaceまで絞り込める
NotionのEnterprise Searchは現在BusinessとEnterprise Planで提供され、主な入口はHomeにあります。Notion Workspaceだけでなく、接続したSlack、Google Drive、Microsoft Teams、Jiraなどを検索でき、Web Searchも追加できます。WorkspaceやConnected AppsのDataを使って回答した場合はSourceも表示され、Original Contentへ戻って確認できます。また、毎回Workspace全体を検索する必要もありません。特定PageやPersonをContextとして追加したり、Page、Teamspace、Personを指定したり、SourcesからWorkspace、特定Connected Appだけを残したり、Workspace内の範囲を特定PageやTeamspaceまでさらに狭めたりできます。
Modelについても、現在Enterprise SearchではOpenAIのGPT、AnthropicのClaude、GoogleのGeminiを切り替えられます。ただし、Modelごとに利用できるData Sourcesが完全に同じとは限らないため、Model Nameだけを見てSearch Capabilityまで同一だと考えることはできません。つまりCommunityが本当に足りないと感じているのは「Search Scopeを絞る機能」そのものではなく、一度設定したScopeを特定Pageの固定Interfaceとして保存する機能です。現在はEnterprise Searchを開くたびにContextやScopeを指定し直す必要があります。あるProjectで長期的にProject Brief、Decision Log、Meeting Notes、関連Documentsだけを検索するのであれば、その設定をProject Homeへ残しておきたいと考えるのは自然です。
NotionにはすでにAI Blockがある。ただしInteractive Search Boxではない
AI BlockはPageへ置けて、Contextも指定できる
「埋め込み型AI Search」を議論するとき、Notionにはすでに/AI Blockがあることは見落とされやすいポイントです。AI BlockはPageへ直接挿入でき、現在のPage Contentを処理するだけでなく、作成時にPromptを設定し、WorkspaceやConnected Apps内のContext、Search Sourcesも指定できます。設定後にGenerateを押すと現在のDataに基づいて結果を生成し、その後情報を更新したい場合はもう一度Generateします。
例えばProject HomeにAI Blockを置き、Requirements、Decision Log、Meeting Notesをもとに、未確定のDecisions、Progress Risks、Next Stepsをまとめるよう固定できます。各Projectで似たNeedがあるなら、AI BlockをDatabase Templateへ入れ、新しく作成するProject Pageが同じPromptとContext Designを最初から持つようにもできます。これはすでに「AIがPageについてくる」状態にかなり近いものです。ただしCommunityが本当に求めているものとはまだ違います。AI Blockはどちらかといえば「固定Question＋固定Data Sources＋手動で再GenerateするOutput」であり、各ViewerがPage内から自由に別のQuestionを入力し、Follow-upを続けられ、しかもSearch Scopeは事前設定済み、というEnterprise Search Widgetではありません。
言い換えると、NotionはすでにこのRequestの半分まで実装しています。Fixed Contextは実現できています。足りないのは、設定済みContextの中で自由に質問できるQuery Interfaceです。
なぜ「Search ScopeがPageについてくる」と毎回Global Searchから始めるより便利なのか？
ScopeはRetrieval Qualityへ影響するが、小さければ小さいほど良いわけではない
Retrieval-Augmented GenerationのArchitectureでは、回答品質はModel Capabilityだけで決まりません。その前段階でRetrievalがどのDataを取り出したかも重要です。例えばCompany Workspaceに5年分のProject Pagesが蓄積され、同じProject Nameが過去にも使われていた場合、全Dataから「このProjectのDelivery Dateはいつ？」と聞けば、旧Specification、Historical Project、似た名前のDocumentsまでCandidateに入る可能性があります。Search Entry Pointが現在のProject Pageにあり、Default Contextが正しいProjectを指していれば、こうしたIrrelevant ContentがRetrievalへ入り込む確率は自然に下がります。
ただし、Search Scopeが狭いほど回答が必ず正確になるわけではありません。本当に必要なAnswerがCompany-wide Policy、別Teamspace、あるいはSlack上のDecisionに存在する場合もあります。Scopeを狭く固定しすぎれば、必要なEvidenceまで排除してしまいます。より適切なのは、ScopeをIntentの一部として扱うことです。「このClientが前回確認した内容は何か」と聞くならClient Pageは自然なStarting Pointです。一方、「会社共通のPricing Policyは何か」と聞く場合、単一Projectだけを検索するべきではありません。
つまりPage-based AI Searchの本当の価値は、Search Scopeを永遠に最小化することではありません。最もよく使うContextを事前設定しておき、質問するたびに「今どの仕事をしているのか」をSystemへ説明し直さなくてよくなることです。
「Permanent Memory」はModel自身が覚える以外に、Knowledge Layerでも処理できる
Storage・Retrieval・Memoryは実際には3つの別問題
8月20日のDiscussionでは、AIにPermanent Storageがない、Private Knowledgeへ自然につながらない、覚えたあとまた忘れる、Chatsをまたいだ完全なCross-chat Memoryがない、Contextの作成、Chat保存、Dataの再発見が毎回面倒、といった複数のProblemが一緒に語られていました。こうしたUser Experienceは理解しやすいものですが、System Designの観点ではStorage、Retrieval、Memoryという3つの異なる問題が混ざっています。
Storageが解決するのはDataがそもそも保存されているかどうかです。Retrievalは必要なときに正しいDataを再び見つけられるかを扱います。MemoryはModelが過去のInteractionやPreferenceをConversationをまたいで保持できるかという問題です。Notionが比較的強いのは最初の2層です。Pages、Databases、Files、Connected AppsはもともとKnowledge Storageであり、Enterprise SearchがRetrievalを担当し、Modelはその上でRetrieved Contextを読んで回答を組み立てます。このArchitectureなら、Modelへ「昨年のMeetingを永遠に記憶して」と要求する必要はありません。そのMeetingが今も存在し、今日必要になったとき正しく取り出せればよいのです。
Project Pageへ固定できるAI Search Widgetが改善するのもこのLayerです。ModelへPermanent Memoryを追加するのではなく、Retrieval Entry Pointを仕事が発生する場所へ残します。
Permissionは確かにEmbedded AI Searchで処理すべき問題だが、Notionがまだ作っていない理由とは断定できない
Enterprise Searchはすでに現在のSearcherのPermissionに応じてFilterする
A、B、Cの3つのDocumentsを閲覧できる人がAI Search Blockを作り、そのPageを見る別ユーザーにはBしか閲覧権限がない場合、現実的なDesign Questionが発生します。Search ResultはCreatorのPermissionで生成するべきか、それともViewerのPermissionで生成するべきか。ただし、この問題から「NotionはPermissionが複雑だからEmbedded Searchをまだ実装していない」と推論することはできません。
現在のEnterprise SearchにはすでにPermission-aware Retrievalがあります。Search Resultsは現在QueryしているUserがNotionやConnected Appsで持つAccess Rightsに応じてFilterされ、もともとアクセス権のないContentがEnterprise Searchへ入っただけで突然見えるようになることはありません。将来Interactive Page Search Widgetが実装されるとしても、合理的なのは各QueryをCurrent ViewerのPermissionに基づいて再実行することです。同じWidgetでもUserによって見えるContentが異なるのは、Permission-aware Searchとして自然な結果です。
一方、注意が必要なのは現在のAI Blockです。AI Blockが生成したTextは、生成後には通常のPage Contentになります。Creatorが自分だけアクセスできるSensitive Dataを使ってSummaryを生成し、そのPageをSource Documentへアクセスできない人へShareした場合、Shareされるのはすでに生成済みのTextです。Underlying DocumentのPermissionが違うからといって、そのGenerated Textまで自動的に消えるわけではありません。そのためCompany Environmentで固定AI Blockを使う場合、Generated Contentも一般Page Contentとして確認する必要があります。Source DocumentにPermissionがあるから、Generated Textも自動的に同じRestrictionを継承すると考えることはできません。
CostはProduct Designへ影響する可能性があるが、Pageへ埋め込むことと毎回AIを実行することは同じではない
もう一つありがちな推論は、50個のProject PagesにAI Search Widgetを置けば、Pageを開くたびにModel Callが発生し、Costが高くなるというものです。しかしEmbedded Searchが必ずそのように動くわけではありません。Search BoxはUserが実際にQuestionを入力したときだけ実行を開始できます。現在のEnterprise Searchと同じです。
現行AI Blockもすでにこの点を示しています。Pageを開くたびに自動Recomputeされるわけではなく、UserがGenerateを押したときにだけ更新されます。そのため「Pageへ埋め込む＝Page LoadのたびにAI Usageを1回消費する」と決めつけることはできません。将来的にInteractive Search Blockが実装されれば、Cache、Usage Allowance、Concurrency、ViewerごとのQuery Historyなどを別途設計する必要はあるでしょう。ただしNotionは、それらが現在この機能を提供していない理由だとは公表していません。記事側でOfficial Reasonを先回りして作る必要はありません。
Workspaceが大きくなるほどAI Searchは必ず悪くなる？
問題はDataが多いことより、どれがCurrentでAuthoritativeなのか分からないこと
同じ週のr/Notionには「Systemを作りすぎた」というDiscussionがいくつかあり、この問題の補足として使えます。ただし「Pagesが増えるほどAIは必ず不正確になる」と直接結論づけることはできません。Notionを6年間使っているUserの一人は、Writing、Tasks、Inventories、FinancesのほとんどをNotionへ置き、以前は新しいStructuresを作り続けることも楽しんでいたものの、最近になって自分とNotionの関係を考え直し始めたと書いています。ただしそのDiscussionにはPrivacy、Local-first、Generative AIへのProduct Directionへの懸念も含まれており、単純に「Systemが大きくなりすぎたから使いにくい」と要約することはできません。
別のHabit Tracker投稿はもっと単純です。投稿者は週末を使ってTrackerを作ったものの11日で開かなくなりました。しかしCommentsでは、自分のTrackerを2年、あるいは5年継続して使っているという人もいました。そのため、一人のAbandonment ExperienceからHabit Trackingは本質的に続かないと証明することはできません。より合理的な結論は、Structureが長期的に残るかどうかはActual NeedとMaintenance Costに依存するということです。
AI Searchとの関係も、「Dataが多い＝Noiseが多い」と単純化する必要はありません。Large Knowledge Baseでも十分機能します。本当に問題になるのは、同じTopicについて複数Versionが存在するのに、明確なStatus、Owner、Date、Source of Truthがない状態です。この場合、人間でもRetrieval Systemでも、どのInformationを現在採用するべきか判断しにくくなります。
Small Notion Databaseはなぜ理解しやすいことが多い？
共通点は「小さいほど良い」ではなく、Purposeをすぐ説明できること
今週、大学1年生のUserが、小規模なResearchのためTikTok Creator AccountsをExcelで収集していたところ、Notionへ移したらInformationを整理しやすく、あとから探し直しやすくなったと共有しました。Commentsでも、Databaseはいくらでも複雑にできるが、Needが出る前にすべての機能を作る必要はないと指摘されています。Vehicle Maintenance TrackerもScopeが明確な別の例です。作者はCommunity Feedbackを受け、「前回のTire Rotationから何Miles走行したか」などのFieldsを追加しましたが、System全体はService Log、Insurance、Warranty、Fuel、Reminders、TCOといったVehicle Managementの範囲に留まり、すべてのLife Managementを扱うDashboardへ膨張していません。
別のUserは、家族のCancer Treatment InformationをNotionで管理しており、Appointments、Medical Reports、Treatment Progress、Doctorへ聞くQuestionsなどを整理していました。以前はNotionを過度に複雑化した経験もあるものの、今回はNeedが明確だからこそ、本当に残すべきDataが分かりやすかったと説明しています。これらのCasesが支持しているのは「Databaseは必ず小さくするべき」という結論ではありません。それぞれのDatabaseが「何のProblemを扱っているか」をすぐ説明できるほうがよい、ということです。Purposeが明確であれば、人間が自分でDataを探す場合も、AIへどこを検索するべきか指定する場合も簡単になります。
Interactive AI Search Widgetがまだない今、何ができる？
一時的なQuestionならEnterprise SearchでScopeを絞る
単発で「このProjectで最終確認されたDelivery Dateはいつ？」と聞きたいだけなら、最も直接的なのはEnterprise Searchを使い、Scopeを現在のProject PageやTeamspaceへ指定してからQueryを始める方法です。NotionはすでにこのSearch Granularityをサポートしているため、毎回Full Workspace、すべてのConnected Apps、Webを検索する必要はありません。また、Promptへ「Project Aだけ見て」と書くだけよりも明確です。ScopeそのものがSearch Interfaceの一部として設定されるからです。
毎回聞く固定QuestionはAI Blockにしてしまう
毎週ほぼ同じQuestionを聞くのであれば、新しいSearch Widgetを待つ必要はありません。例えばProject内のUnresolved Decisionsを整理する、OwnerがいないAction Itemsを探す、Clientの直近数回のMeetingsの結論をまとめる、といった用途です。Project TemplateへAI Blockを追加し、Contextを必要なPagesやConnected Sourcesへ向け、Promptを設定しておけば、更新が必要なときにGenerateを1回押すだけです。これは別PageでPrompt Listを管理するより、本当のEmbedded AIに近い使い方です。Prompt、Context、Outputがすべて仕事が起きる同じPageに残るからです。
Project Homeに明確なContext Entry Pointを作り、すべてのDataを1Pageへ移さない
Project PageにProject Context Sectionを固定し、現在有効なBrief、Decision Log、Deliverables、Meeting Notes、主要Database Viewsをまとめておく方法もあります。目的はすべてのDataを再度Copyすることではなく、「このProjectで現在参照すべきSources」を明確に示すことです。AIだけでなく、人間にとっても本当のSource of Truthを探しやすくなり、Enterprise SearchやAI BlockもこのPageをStarting Contextとして使いやすくなります。
Old DataはまずStatusを付ける。AIのために「何か月開いていないか」だけで大量削除しない
3か月開いていないからといって、そのDataが無効になったとは限りません。Decision Records、Legal Documents、Research Data、Historical Projectsなどは日常的に開かなくても、本当に必要なときには価値があります。そのため「最近使ったか」だけを基準に大量削除することは、AI Searchを改善する一般的方法ではありません。
より安全なのはCurrent、Archived、SupersededなどのStatusを用意し、旧Versionがどの新Documentによって置き換えられたかを明示することです。必要に応じてArchiveへ移し、Page Titleも内容が分かるように書きます。Retrievalにとって、「これは何のDocumentか」「現在も有効か」「正式Versionはどれか」が分かることは、Workspaceを単純に少ないPagesだけへ減らすことより重要な場合があります。
Embedded AI Searchで本当に足りないのは、Scopeを保存できる自由Query Entry Point
現在のNotionにはすでに3つのPuzzle Pieceがあります。Enterprise SearchはWorkspace、Connected Apps、Webを検索でき、Scopeを特定PageやTeamspaceまで絞れます。AI BlockはPage内に存在し、PromptとContextを保存してGenerateできます。Notion AgentはWorkspace Contextの中でさらにContentを作成・変更できます。
Official Product Documentationにまだ存在しないのは、最初の2つを直接組み合わせたものです。Project Pageへ埋め込めて、Scopeは事前設定済み、それでも各Userが自由に異なるQuestionを入力し、Follow-upを続けられるEnterprise Search Blockです。Community Requestが一見「Search Boxを1つ追加してほしい」だけに見えながら合理的なのはこのためです。欲しいのは新しいModelではなく、Ask AI Buttonをもう一つ追加することでもありません。ContextをPageと一緒に保存し、Questionのたびに「今どの仕事をしているのか」をもう一度指定しなくてよくすることです。
OfficialにこのComponentが登場するまでは、Fixed QuestionsはAI Blockへ任せ、Ad hoc QuestionsはEnterprise Searchを使い、Workspace自体ではCurrent、Archived、Owner、Date、Source of Truthを明確にしておく方法が現実的です。Modelが半年前のConversationを永久に覚えているかどうかはControlしにくい問題です。しかし「今日のこのQuestionでは、どのDataを探しに行くべきか」なら、少なくともScopeを先に設計できます。
よくある質問 FAQ
現在、Enterprise Searchと完全に同等で、Pageへ直接埋め込み、各Userが固定Scopeの中で自由に異なるQuestionを入力できるOfficial Search Componentは確認できません。ただしNotionにはすでにAI Blockがあり、Pageへ直接配置し、Prompt、Context、Search Sourcesを事前設定して、UserがGenerateを押すことで結果を更新できます。そのため「Page内にContextual AIがまったくない」という説明は正確ではありません。本当に足りないのは、自由に質問できるInteractive Search Interfaceです。
AI Blockは固定Questionに向いています。例えば毎回Project Risk、Pending Decisions、Meeting Summaryを整理する場合、PromptとContextを事前設定し、必要なときにGenerateし直せます。Enterprise SearchはAd hoc Question向きで、Userが毎回異なるQuestionを入力し、必要に応じてScopeを調整できます。簡単に言えば、AI BlockはFixed Templateに近く、Enterprise SearchはFree-form Searchに近い機能です。
できます。Enterprise Searchでは特定Page、Person、TeamspaceをContextへ追加したり、Sourcesを調整してWorkspace内の特定範囲やConnected Appへ絞ったりできます。そのため「Scopeを限定する機能」自体が不足しているわけではありません。Communityが求めているのは、そのScopeを特定Pageへ固定し、毎回再設定しなくても使えるようにすることです。
必ずしもそうではありません。Scopeを小さくすると、3年前の同名ProjectなどIrrelevant DocumentsがRetrievalへ混ざる可能性を減らせます。しかし必要なInformationがCompany Policy、別Teamspace、Slackなどに存在する場合、Scopeが狭すぎるとEvidenceを取り逃がします。Scopeは単純に小さくするのではなく、Question自体に合わせることが重要です。
必ずしも下がりません。Data Volumeそのものより問題になりやすいのは、同じTopicに複数Versionが存在し、どれが現在有効なのか分からない状態です。Owner、Date、Status、Source of Truthが明確なら、Large Knowledge Baseでも十分検索できます。むしろRetrievalはより豊富なHistorical Dataを利用できる場合があります。
「何日開いていないか」だけを基準に削除することはおすすめできません。Historical Decisions、Research Data、Contracts、Past Projectsなどは普段開かなくても必要になることがあります。より適切なのは、古いContentをArchivedやSupersededとしてMarkし、現在有効なVersionを明確にすることです。人間とAIの両方がHistorical RecordとCurrent Sourceを区別しやすくなります。