NotionのAIエージェントがコードを実行できるようになった — 30秒サンドボックスの正体

Notionが4月14日にリリースしたNotion 3.4 Part 2の目玉は、「Workers for Agents」だ。Custom AgentsにJavaScript/TypeScriptの実行環境を渡す機能で、要するにNotionのAIエージェントが自分でコードを書いて動かせるようになった。

さらに4月17日には、メールとカレンダーを設定画面から直接接続できるようになり、AIエージェントが会議のスケジュール調整やメール下書きまで横断的に処理できる環境が整った。

メモアプリが開発環境と秘書を兼ね始めている。

Workers for Agents — コード実行の仕組み

Workers for Agentsは、Notion AIエージェントがJavaScriptやTypeScriptのコードを動かせるサンドボックスだ。ファンクションコーリングに近い考え方で、エージェントが会話の中で必要に応じてWorkerを呼び出し、計算やデータ処理を実行する。

裏側ではVercel Sandbox（Firecracker microVM）が使われている。エージェントが「このデータを集計して」と判断すると、エフェメラルなmicroVMが立ち上がり、コードを実行し、結果を返して消える。永続的な状態は持たない。

制約は明確に設けられている。

• 実行時間: 30秒でタイムアウト
• メモリ: 128MB
• 外部通信: 許可されたドメインのみ。ドメインホワイトリストで制御
• 認証情報: ネットワークレベルで注入される。実行環境にはクレデンシャルが一切入らない

最後の点が設計としてうまい。プロンプトインジェクションでコード実行を乗っ取られても、認証情報はサンドボックスの外にあるため漏洩しない。セキュリティの最も危険なベクトルをアーキテクチャレベルで潰している。

現時点ではNotion Developer Portalからのオプトイン制で、本番ワークフローへの適用は推奨されていない。ランタイム制限とドメインホワイトリストは一般公開までに変更される可能性がある。

30秒のサンドボックスで何ができるか

30秒・128MBと聞くと「大したことできないのでは」と思うかもしれない。実際、重い機械学習モデルを動かしたり、大量のファイル処理をするのは無理だ。バックエンドサーバーの代替にはならない。

ただ、Notionのエージェントが日常的に必要とする処理は、この制約で十分カバーできる。

たとえば、データベースの数値をAPIで取得して加工する。CSVをパースして特定のフォーマットに変換する。外部APIからデータを取り込んでNotionのページに整形して書き出す。こうした「ちょっとした計算やデータ変換」はテキスト生成だけのAIではできなかった処理だ。

正直に言えば、これはSlack BotやZapierのコードステップでもできることだ。しかし「Notionの中で、エージェントの判断で自動実行される」という統合度が違う。ワークフローのためにツールを跨がなくていい。

Mail & Calendar統合 — エージェントが秘書になる

4月17日のアップデートで、設定画面にMail & Calendar用のタブが追加された。Notion Calendar、Google Calendar、Apple Calendarを接続でき、Custom Agentsがカレンダーとメールを横断的に操作できるようになった。

具体的には、Custom Agentsに「来週、チーム全員の空き時間を見つけてミーティングを設定して」と頼むと、参加者のカレンダーを確認し、タイムゾーンと勤務時間を考慮し、空いている枠を見つけて会議を設定する。調整がうまくいかない場合はSlackで確認を取ることもできる。

メールについても同様だ。Notion Mailを接続すれば、エージェントが受信メールの内容を踏まえて返信の下書きを作成する。

ここで効いてくるのがWorkers for Agentsとの組み合わせだ。たとえば「今週のミーティング一覧を取得して、議事録がまだないものをリストアップし、参加者にリマインドメールを下書きして」という指示。カレンダーAPIの呼び出し、データのフィルタリング、メール生成が一つのエージェントの中で完結する。テキスト生成だけでは不可能だった処理が、コード実行によって可能になる。

Views API — 開発者向けの地味だが大きな変更

もうひとつ、開発者にとって嬉しいのがViews APIの追加だ。8つの新しいエンドポイントが公開され、データベースのビューをプログラムから管理できるようになった。

これまでNotionのAPIではページやブロックの操作はできたが、ビューの作成・更新・削除はできなかった。ダッシュボードビューの自動生成やビュー設定の一括変更ができなかったのだ。このブロッカーが外れた。

地味な変更に見えるが、Notion上にダッシュボードを自動構築するようなインテグレーションが作れるようになる意味は大きい。

正直な評価

Workers for Agentsは設計として筋がいい。Firecracker microVMによるエフェメラル実行、認証情報のネットワークレベル注入、ドメインホワイトリスト。セキュリティを「約束」ではなく「構造」で担保しようとしている。

一方で、まだプレビュー段階であることは忘れてはいけない。30秒のタイムアウトは一般公開時に変わるかもしれないし、現状ではJavaScript/TypeScript限定だ。Pythonが使えないのはデータ分析系のユースケースにはやや痛い。

Mail & Calendar統合も、現時点ではNotion CalendarやNotion Mailを使っていることが前提になる。Google CalendarやApple Calendarとの接続は可能だが、Outlookはまだ対応していない。企業ユーザーの多くがOutlook環境にいることを考えると、本格的な普及はOutlook対応待ちになるかもしれない。

それでも、方向性は明確だ。Notionは「情報を書く場所」から「情報を使って仕事をする場所」に変わろうとしている。3.3のCustom Agents、3.4のダッシュボード、そして今回のWorkers for AgentsとMail & Calendar統合。半年前のNotionとは、もはや別のプロダクトだ。

注目すべきポイント

Workers for Agentsが一般公開されたとき、最も影響を受けるのはZapierやMakeで「Notionと外部サービスの橋渡し」をしているユーザーだろう。エージェントがコードを実行できるなら、外部連携ツールを挟む理由が減る。NotionがiPaaS市場を食い始める構図になる。

もうひとつ気になるのは、Notion Developer Portalの位置づけだ。Workersの公開で、Notionは「使うツール」から「上にビルドするプラットフォーム」に一歩踏み出した。Views APIの8エンドポイント追加もその延長線にある。

• Notion 3.4 Part 2 リリースノート
• Mail & Calendar統合