Notionが、ワークスペースをAIエージェントの実行基盤として開放する開発者プラットフォームを発表した。議事録要約や顧客データから提案書を生成するエージェントをページ上のブロックとして配置・実行でき、外部APIや自作コードとの接続も可能になる。社内ドキュメントの「保管庫」が、業務AIの「ランタイム」へと役割を変える動きだ。
何が起きたか
TechCrunchの報道によれば、Notionは自社プラットフォーム上でサードパーティおよび社内開発のAIエージェントをホストできる仕組みを発表した。これまでのNotion AIは、要約・翻訳・文章生成といったページ内の支援機能が中心だったが、今回の発表でNotionは「エージェントを実装し、配布し、ユーザーのドキュメント文脈で動かす」ためのプラットフォームへ舵を切った。
具体的には、エージェントをページ内のブロックとして埋め込み、Notionデータベースのレコードや他ページのコンテンツを入力として受け取り、外部のSaaSやデータソースを参照しながら成果物（議事録の要約、営業提案書のドラフト、顧客分析レポートなど）を生成する流れになる。開発者は自作のロジックやコードを接続でき、汎用チャットUIではなく「業務ワークフローに埋め込まれたエージェント」として動作させられる。
なぜこのニュースが重要か
ここ1年、AIエージェント基盤の主戦場は「どこで動かすか」に移ってきた。OpenAIのGPTs、AnthropicのClaude with tools、SalesforceのAgentforce、Microsoft Copilot Studio——いずれも「業務データに最短距離でアクセスできる場所」をエージェントの母港にしようとする戦いである。
Notionの強みは、すでに多くの企業で議事録・仕様書・OKR・顧客メモといった「非構造化された業務文脈」がNotion上に集約されている点だ。RAG（Retrieval-Augmented Generation）の文脈で言えば、Notionは最初から良質なベクトル化対象データを抱えており、ユーザー認可・権限境界も既存のWorkspace権限モデルで処理できる。つまり、競合がコネクタ整備に苦戦している「最後の1マイル」を、Notionは構造的に持っている。
加えて、Anthropicが主導するMCP（Model Context Protocol）の普及により、エージェントがツールやデータソースに接続する標準化が進んでいる。Notionの今回の発表もこの潮流の延長線上にあり、特定ベンダーロックインを避けつつエコシステムを開く判断と読める。
エンジニア視点・技術深掘り・実装影響
実装者の関心は「どこまで自前ロジックを差し込めるか」に尽きる。報じられている範囲では、エージェントは外部APIコールと自作コードの実行をサポートし、Notionデータベース／ページをコンテキストとして読み書きできる。疑似コードで書けば、おそらく次のような形のハンドラ定義になるはずだ。
defineAgent({
name: "meeting-recap",
inputs: ["page:meeting_notes"],
tools: [notionDB("action_items"), slack.postMessage],
run: async (ctx) => {
const summary = await ctx.llm.summarize(ctx.inputs[0]);
await ctx.tools.notionDB.insert(summary.actions);
return ctx.block.render(summary);
},
});
ここで実務上気になる論点は4つ。
1. 権限境界とデータ漏洩。エージェントがWorkspace内のページを横断参照する際、Notionの既存のページ単位パーミッションがどこまで強制されるか。プロンプトインジェクション経由で本来見えないページを引き出す攻撃（いわゆるindirect prompt injection）への耐性は、SOC2やISO 27001を要求される企業導入で必ず問われる。
2. 観測可能性。エージェント実行のトレース、LLMコールのトークン消費、エラー時のリトライ挙動が標準でどこまで露出されるか。LangSmithやOpenTelemetry GenAI semantic conventionsとの接続性が、運用の現実解になる。
3. ベンダーロックインのリアル。エージェント定義がNotion独自DSLに閉じるのか、それともMCPやOpenAI Assistants API互換のポータブルな記述に寄せられるのか。後者であれば、Notion以外への移植余地が残る。
4. レイテンシとコスト。ページレンダリング時にエージェントが同期実行されるUXか、非同期ジョブとしてキューイングされるか。チームで数百ページに埋め込めば、LLM呼び出しコストは線形以上に膨らむ。キャッシュ戦略とトリガー設計が運用設計の肝になる。
経営者/読者として次に取るべき動き
短期的にやるべきは、棚卸しである。現在契約している議事録SaaS、ナレッジ検索ツール、社内チャットボット、簡易RPA——これらのうち、ユースケースが「Notion上の文書を入力にして、Notion上に成果物を出す」で完結するものは、統合候補になる。1ツールあたり月数千円〜数万円のSaaSが10本並んでいる組織であれば、統合効果は無視できない。
中期的には、自社固有の業務フロー——たとえば与信稟議、PR FAQ作成、インシデントレビュー——を「Notion上のエージェント」として実装する内製プロジェクトを1本立ち上げる価値がある。汎用ChatGPTに業務知識を都度貼り付ける運用は、再現性も監査性もない。エージェント化することで、プロンプトと文脈が資産として蓄積される。
ただし、全社の知的資産をひとつのプラットフォームに集約することのリスクも忘れてはいけない。Notionの可用性、価格改定、データエクスポート性——この3点は、契約前に必ず精査すべきだ。「ドキュメント基盤がランタイムになる」という変化は、SLAの意味も書き換えるからである。
動画でも詳しく
動画は記事冒頭の埋め込みからフル尺で視聴できます。