Notion 3.5 Developer Platform とは何ですか？

Notion が2026年5月13日にリリースしたバージョン 3.5 の中核機能で、Notion ワークスペースを「AI エージェントのハブ」に進化させる3要素のセットです。①Workers（TypeScript で書いた custom code を Notion のホスト sandbox 上で動かす hosted runtime）、②External Agents API（Claude Code、Codex、Cursor、Decagon などの外部エージェントを Notion 内に first-class workspace participants として常駐させる仕組み）、③Database Sync（外部 API データソースを Notion データベースにリアルタイム同期）。CLI ツール `ntn` も同時公開され、developer.notion.com で公式ドキュメントが整備されています。Workers は2026年8月11日から Notion credit 課金が始まる予定で、それまではベータ期間として無料で試せます。

Notion Workers の sandbox 制限はどのくらい厳しいですか？

Notion Workers は secure sandbox 内で動作する hosted TypeScript runtime で、以下の制限があります。①実行時間 30秒タイムアウト（長時間バッチ処理には不向き）、②メモリ 128MB 上限（大量データの一括処理は分割が必要）、③outbound HTTP は approved domains のみ（任意の外部 API を叩くには事前許可が必要）、④単一 TypeScript ファイルとして `ntn workers deploy` でデプロイする構造。これらの制約は AWS Lambda の最小単位や Cloudflare Workers と類似していて、軽量な「Notion 内ツール」の実装には十分。ただし、長時間 batch や大きな ML inference は Workers 外で実装してから Webhook で結果を Notion に書き戻す構成が現実的です。

External Agent API はどのエージェントに対応していますか？

2026年5月13日リリース時点の公式パートナーは Claude Code（Anthropic）、Codex（OpenAI）、Cursor、Decagon の4社です。Notion 公式ブログでは「more to come」とされており、追加パートナー拡大が予告されています。各エージェントは Notion ページ内でチャット参加、データベースから自動タスク割り当て、他エージェントへのハンドオフ、結果書き戻し、をすべて Notion を coordination layer として実行できます。認証は External Agent 側が OAuth、CLI/Worker 開発側が Personal Access Token (PAT) の2系統です。なお、External Agents API は private beta（waitlist 制）で、申請後の承認制。一方 Workers は public beta で誰でもすぐ試せる、という非対称な公開状態です。

Database Sync で具体的に何ができますか？

外部の API データソースを Notion データベースにリアルタイム同期できます。Notion 公式が例として挙げているのは Zendesk（チケット）、Salesforce（取引・顧客）、Postgres（任意のテーブル）、Strava（運動ログ）、Spotify（再生履歴）など。同期は裏で Workers が走る設計で、開発者が `ntn workers new my-sync` でワーカーを書く形になります。これにより「Salesforce の取引データを Notion のチーム DB で見ながら、Claude Code に追加分析させる」「Postgres のアプリログを Notion で経営層が見て、Codex が改善タスクを生成する」のような業務フローが Notion 内で完結します。データソース側に API があれば何でも繋げる柔軟性が強みです。

Workers の料金はどう変わりますか？

現在（2026年5月時点）はベータ期間で完全無料です。Notion 公式によれば、2026年8月11日から Workers が Notion credit ベースの課金に切り替わります。credit の具体単価はまだ公表されていませんが、AWS Lambda や Cloudflare Workers と類似の「実行時間 × 呼び出し回数」ベースになる可能性が高いと予想されます。利用には Notion の Business（$15/user/month）または Enterprise プランの加入が必要で、Free / Plus プランでは Workers は使えません。8月10日までの約3ヶ月間が「無料で本気で試せる期間」なので、社内ツール開発・PoC の駆け込み導入には現在が最適なタイミングと言えます。

Claude Code を Notion に常駐させる手順は？

現時点では External Agents API が waitlist 制のため、フル統合はまだ承認待ちが必要です。先行して試せるのは Notion MCP Server を使った Claude Code 接続で、これは公式 docs（developers.notion.com）に手順があります。具体的には、①Claude Code 内で `/mcp` コマンドを実行して OAuth フロー、②Notion ワークスペース側で MCP インテグレーションを承認、③Claude Code が Notion ページ・データベースを読み書きできる状態に。これにより External Agents API 本体の承認を待つ間に「Notion を Claude Code から操作する」基本動作は試せます。本記事のステップ6で具体的なコマンドと設定を整理します。

Workers と External Agent API のどちらを優先すべきですか？

目的次第ですが、結論から言うと「Workers を先に触り、External Agent API は waitlist 登録だけして待つ」が現実解です。理由は3つ。①Workers は public beta で今すぐ触れるが、External Agent API は private beta で承認待ち。②Workers で作る「カスタムツール」は External Agent API が来た時にそのままエージェントから呼べる設計なので、先行投資が無駄にならない。③Workers の credit 課金が8月11日から始まるので、無料期間中に最大限試すのが経済合理性に合う。逆に External Agent API は承認後に本格運用すれば良く、現時点での Worker 開発はそのまま将来の Agent ツール基盤になります。

2026.05.22 · 17分で読める

Notion 3.5 完全ガイド｜Workers・External Agent API で Claude Code 常駐【2026年5月版】

2026年5月13日、Notion がワークスペース上で外部 AI エージェントを first-class participants として動かす「Developer Platform 3.5」をリリースしました。Workers（TypeScript sandbox）、External Agents API（Claude Code・Codex・Cursor・Decagon との公式統合）、Database Sync（外部 API データソースを Notion DB へリアルタイム同期）の3要素がセットで提供され、Notion が単なるドキュメント・データベース・タスク管理ツールから「業務 AI エージェントのハブ」へ変質します。本記事では、Workers の sandbox 仕様（30秒タイムアウト・128MB メモリ・approved domains 制限）、External Agent API の認証フロー、Claude Code を Notion に常駐させる具体手順、そして2026年8月11日の credit 課金開始までの3ヶ月をどう使うかまで、運用者の視点で1万字で完全整理します。読了後、自社の Notion ワークスペースをエージェント・ハブ化する具体的なロードマップが描けます。

Notion が「エージェント・ハブ」に変わった日

2026年5月13日、Notion が Developer Platform 3.5 をリリースしました。リリースの中核は3つの新機能セットで、これらが組み合わさることで「Notion ワークスペース＝外部 AI エージェントが動く実行環境」へとプロダクトの位置づけが大きく変わりました。

Notion はこれまで、社内ドキュメント・データベース・タスク管理を統合した「Workspace as a single page」というポジションで成長してきました。しかし、AI エージェント時代の業務フローでは「ドキュメントを書く場所」と「エージェントが動く場所」が別々だと、情報の往復コストが大きくなります。Notion 3.5 はこの問題を「Notion をエージェントの coordination layer にする」というアプローチで解決しました。たとえるなら、これまで Notion が「会議室」だったのが、3.5 で「会議室＋作業現場＋外部スタッフ受付」を兼ね備えたハブに進化したようなものです。

Notion 3.5 Developer Platform の構造。Workers・External Agents API・Database Sync の3要素が Notion Workspace を「coordination layer」として包む設計。

この構造の特徴は、3要素が単独でも有用なうえに、組み合わせると相乗効果が出る点です。Workers で書いた「Salesforce の取引データを毎朝同期する」コードは Database Sync の実装本体になり、その同期データを Notion ページに表示すれば、External Agent API 経由で Claude Code に「今月の取引で異常値があるか分析して」と頼める。1つの Notion 内でデータ取得→可視化→AI 分析→結果書き戻し、が完結します。これが2026年後半の Notion の戦略的価値です。

この戦略変更がなぜ今このタイミングで起きたかと言うと、業界全体で MCP（Model Context Protocol）が事実上の標準になり、各 AI エージェントが「外部システムとの統合」を共通プロトコルで行うようになったからです。Anthropic の Code with Claude 2026 アップデートまとめでも見たとおり、Claude Code・Codex・Grok Build が全社揃って MCP に対応した今、Notion が「MCP の受け皿となるハブ」として動くのは時流に合った判断です。これまで Slack や Salesforce が握ってきた「業務ワークスペースのデファクト」枠を、Notion が AI エージェント時代の文脈で取りに行く動きと読めます。

Workers とは何か｜TypeScript Sandbox の仕組み

Notion Workers は、Notion がホストする TypeScript ランタイムです。公式ドキュメントによれば、ユーザーは TypeScript で書いた単一ファイルを CLI `ntn workers deploy` でデプロイすると、Notion 側の sandbox 上で実行される仕組みになっています。AWS Lambda や Cloudflare Workers と概念は同じですが、Notion API との統合が最初から組み込まれている点が独自です。

Sandbox 仕様｜30秒・128MB・approved domains 制限

Workers の sandbox は以下の制限を持っています。これらは Cloudflare Workers と類似のレンジで、「軽量な処理」を想定した設計です。

Notion Workers の主要制限。AWS Lambda（15分）や Cloudflare Workers（30秒）と比較すると、Notion は Cloudflare 寄りで「軽量・短時間」の処理を想定。

30秒タイムアウトは「軽量な処理を即座に返す」用途には十分ですが、長時間バッチや大量データの ML inference には向きません。たとえるなら「短距離走者」のような走り方で、5000m を走らせるなら別ランナー（外部サーバー）を用意して、Workers は結果受け取り係に徹する設計が現実的です。実運用では、長時間処理は外部 Worker（AWS Lambda 等）で実行→ Notion Worker に Webhook で結果を渡す、というハイブリッド構成がよく見られるはずです。

もう1つ重要な制限が「approved domains への outbound HTTP のみ」というネットワーク制約です。Notion 側で事前に承認されたドメイン（major API サービスや Notion 自身の API）へのリクエストしか通らないため、自社の独自 API や社内サーバーへ直接アクセスする場合は、追加申請が必要になります。これはセキュリティ上の合理的な制約で、Worker から任意のドメインに POST できると suplly chain 攻撃のリスクが跳ね上がるため、Notion が意図的に「ホワイトリスト方式」を採用していると読めます。社内システム連携をする場合は、Notion 公式の Postgres コネクタや Webhook 経由で迂回する設計が必要です。

3つの capabilities｜syncs / tools / webhooks

Workers は単一 TypeScript ファイルとして書きますが、その中で3種類の capability を登録できます。

syncs: 外部 API データソースを Notion データベースに同期する処理。Database Sync の実装本体。
tools: External Agent から呼ばれる関数。Claude Code や Codex がエージェントとして動く時、Notion 内で実行可能な「決定論的ツール」として提供される。
webhooks: 外部システムからの POST を受けて Notion 内のアクションをトリガー。GitHub Actions・Slack・Zapier 連携の起点。

この3つを1つの Worker 内に混在させることもできます。たとえば「Salesforce の取引データを同期する sync」と「同期データを集計する tool」を同じ Worker に書いておけば、External Agent からの問い合わせに対して、最新データで即答できる構成になります。

External Agents API｜Claude Code・Codex を first-class 化

Developer Platform 3.5 のもう1つの核が External Agents API です。これは Claude Code（Anthropic）、Codex（OpenAI）、Cursor、Decagon の4社のエージェントを、Notion ワークスペースの「first-class participants」として扱う API です。

first-class participants が意味するもの

従来、AI エージェントを Notion で使う場合、ユーザーがブラウザの別タブで ChatGPT や Claude を開き、Notion ページから情報をコピーしてきて貼り付ける、という手動往復が必要でした。External Agents API はこれを変えます。具体的に外部エージェントが Notion 内でできるようになるのは以下のとおりです。

Notion ページ内で チャット参加（ユーザーと同列のメンバーとしてコメント・返信）
Notion データベースから タスクが自動割り当てされる（「assignee: Claude Code」のような形）
他エージェントへの ハンドオフ（リサーチは Claude、コード生成は Codex、UX レビューは Cursor、のような分業）
処理結果を Notion ページ・DB に 書き戻し（PR の draft 作成・分析レポート生成・ステータス更新）

これは Notion を「人間とエージェントが同じテーブルで作業する場所」に変えるアーキテクチャです。たとえるなら、これまで「Slack で人間が議論、別タブで AI に質問」だったのが、Notion 一箇所で「人間とエージェントが同時にコメントし合う」体験になる、という変化です。Claude Code Subagents 実践ガイドで扱った「エージェント分業」と思想は同じで、Notion 3.5 はそれを「人間とエージェントの境界が溶ける」レベルまで踏み込んだ形と言えます。

認証フロー｜OAuth + Personal Access Token

External Agents API の認証は2系統です。外部エージェント側は OAuth で Notion ワークスペースに接続し、ユーザーがインストール時に権限を承認します。一方、CLI / Worker 開発側は Personal Access Token (PAT) を使い、`ntn` CLI で `ntn auth login` してから Worker をデプロイします。

この2系統に分けた設計の意図は明確で、「エンドユーザーがエージェントを承認する OAuth」と「開発者が Worker を deploy する PAT」を分離することで、エンドユーザーの権限管理と開発者の効率を両立させています。Slack App と Slack CLI が別認証なのと似た構造です。

private beta（waitlist）の意味

注意点として、External Agents API は2026年5月13日時点で private beta（waitlist 制）です。誰でもすぐに使える Workers（public beta）と異なり、Notion 側の承認を待つ必要があります。これは外部エージェントが Notion 内で動く以上、セキュリティ・パフォーマンスの段階的検証が必要だからです。先行アクセスを得るには、Notion 公式の developer portal（app.notion.com/developers）から waitlist 登録する形になります。

Database Sync｜外部 API を Notion に常時反映

Database Sync は、外部 API を持つあらゆるデータソースを Notion データベースに自動同期する機能です。Notion 公式ブログでは Zendesk、Salesforce、Postgres、Strava、Spotify などが例として挙げられていますが、実装の仕組み上「API を持つ任意のサービス」が対象になります。

Database Sync は Worker を経由して外部 API を Notion DB に常時同期する。同期データを External Agent が読んで分析・行動するのが3要素統合の基本パターン。

これまで「Notion で見たいデータ」を都度コピペしていた業務が、Database Sync を組めば「Notion を開けば常に最新の Salesforce 取引データが見える」状態になります。さらに External Agent と組み合わせれば、「最新データを見て Claude Code が異常検知して、Notion ページにアラートを書き込む」のような完全自動化が可能です。

注意点として、Database Sync の同期方式は2種類あります。定期 pull 型は Worker が一定間隔（cron 形式）で外部 API を叩いて差分を取得するパターンで、Salesforce や Strava のように頻繁に更新されないデータに向いています。一方、Webhook push 型は外部サービスがイベント発生時に Notion Worker に通知を送るパターンで、Zendesk の新規チケットや GitHub の PR 作成のような「即時反映が欲しい」データに向いています。実運用では1つの DB に対して両方を組み合わせる構成も可能で、たとえるなら「基本は1時間ごとに見回る巡回警備員（pull）+ 緊急時は通報で呼ばれる出動部隊（push）」のような二段構えになります。

料金構造｜8月11日 credit 課金開始までのタイムリミット

Notion 3.5 Developer Platform の料金は、機能ごとに状態が分かれています。ここを正しく理解しないと、無料枠の使い方を間違えます。

3要素ごとの公開状態と料金。Workers は3ヶ月の無料試行期間、External Agents API は waitlist 承認待ち、CLI は誰でも即利用可。

Business / Enterprise プラン必須

Workers と External Agents API を使うには、Notion Business（$15/user/month）または Enterprise プランの加入が必要です。Free / Plus プランでは Developer Platform 機能は使えません。これは、開発者向け機能が組織単位のガバナンスを前提としているためで、Salesforce や Postgres のようなエンタープライズ系データソース統合と整合性が取れる仕様です。

3ヶ月の無料試行期間をどう使うか

5月13日のリリースから8月11日の課金開始まで、約3ヶ月の無料試行期間があります。この期間は「無料で本気で試せる時期」で、特にこんなチームに有利です。

Business / Enterprise プランに既加入で、社内ツール開発の余地があるチーム
Claude Code・Codex を既に運用していて、Notion 連携の試作価値を見極めたいチーム
Salesforce・Postgres などの主要データソースを Notion で見たいチーム

3ヶ月という期間は、PoC（概念実証）には十分な長さです。最初の1ヶ月で Worker を1-2本書いて Database Sync を体験し、2ヶ月目で External Agent との結合パターンを試し、3ヶ月目で本番運用に耐えるか評価する、というロードマップが現実的です。ChatGPT Apps SDK の運用ガイドでも見たとおり、AI プラットフォームのベータ期間は「先行投資のチャンスでもあり、見極め期間でもある」という二面性があります。Notion 3.5 もまさにその段階で、無料期間中に運用パターンを確立できれば、課金開始後も予算化された運用に移行しやすくなります。

Claude Code を Notion に接続する手順

External Agents API はまだ waitlist 制ですが、Claude Code と Notion を繋ぐ方法は既に複数あります。本記事公開時点（2026年5月22日）で動く現実的な構成を整理します。

Notion MCP Server を使う最短経路

Notion は MCP（Model Context Protocol）サーバーを公式提供しており、これを Claude Code から接続するのが最短です。公式 docs に手順がありますが、要点は以下のとおりです。

Claude Code を起動して `/mcp` コマンドを実行
表示される URL（`https://mcp.notion.com/mcp`）を入力
OAuth フローで Notion ワークスペースに権限承認
Claude Code が Notion ページ・データベースを読み書きできる状態に

この方法だと External Agents API の承認を待つ必要がなく、今すぐ「Claude Code から Notion を操作する」体験ができます。実体験として、`/mcp` から OAuth 完了まで約3分。試行コストはほぼゼロです。XServer MCP × Claude Code 実装ガイドと同じ MCP 接続パターンなので、MCP に慣れている人は迷うことなく繋がります。

Worker 経由で「Claude Code 用ツール」を提供

もう1段進んだ方法として、Worker で「Claude Code 用のツール」を書いて、それを MCP server 経由で公開する構成があります。具体的には、Worker の tools capability で関数を登録し、ntn workers deploy でデプロイすると、その関数が MCP ツールとして利用可能になります。

この方法のメリットは、External Agents API が正式に来た時に「同じ Worker tool がそのままエージェントから呼べる」点です。先行投資が無駄にならない設計になっています。Claude Code Codex Plugin ガイドで扱った Plugin 構造とは別レイヤーですが、思想は同じ「再利用可能なツール基盤を作る」方向性です。

ベータ期間中に試すべき3つの構成

3ヶ月の無料期間で何を試すべきか、用途別の3つの構成パターンを提案します。どれも Worker と Notion MCP Server だけで完結するので、External Agents API の waitlist 承認を待つ必要がありません。

3パターンの選択肢。個人開発者は③からスタート、業務組織は①②でビジネスインパクトを早期に作るのが推奨。

パターン① 営業 DB 連携（業務インパクト最大）

Salesforce の取引データを Worker 経由で Notion DB に15分ごとに同期し、Claude Code から「今週の取引で前年同期比 -20% のものを抜き出して」のような分析を頼める構成。営業マネージャーが Notion を開いた瞬間に最新データを見られて、AI 分析も同じ画面で完結します。Salesforce API は安定しているので、Worker の制限（30秒・128MB）内で軽量に実装可能です。

パターン② サポート Bot（工数削減効果が高い）

Zendesk の新規チケットを Worker の Webhook で受けて、Notion DB に格納。さらに Worker tool として「類似チケット検索」関数を登録すれば、Claude Code から「このチケットと類似の過去事例を5件出して」と頼めます。サポートチームの返信作成時間が大きく短縮できる構成で、たとえるなら「ベテラン担当者が常時隣にいて過去対応を即引き出してくれる」ような効果です。

パターン③ 個人ダッシュボード（試行コスト最小）

GitHub の PR / Issue を Notion DB に同期し、Claude Code が新しい PR を見て要約コメントを Notion に書き込む構成。個人開発者向けで、難易度は最も低く、Worker 1本で完結します。「毎朝 Notion を開けば、自分のリポジトリの活動が一覧で見えて、要点も整理されている」状態が作れるので、複数プロジェクトを抱えている人ほど刺さります。

まとめ｜2026年後半の Notion 戦略

2026年5月13日の Notion 3.5 Developer Platform リリースは、Notion を「ドキュメント管理ツール」から「AI エージェントの coordination layer」へと再定義する戦略的アップデートでした。Workers（TypeScript sandbox）、External Agents API（Claude Code・Codex・Cursor・Decagon 公式統合）、Database Sync（外部 API リアルタイム同期）の3要素が組み合わさることで、これまで分散していた「ドキュメント・データ・エージェント」が Notion 一箇所に統合されます。

2026年5月時点の状況を整理すると、Workers と CLI は今すぐ誰でも触れる public beta、External Agents API は waitlist 承認待ちの private beta、という非対称な公開状態です。8月11日の Workers credit 課金開始までの約3ヶ月が「無料で本気で試せる期間」なので、Business / Enterprise プラン加入チームは今すぐ着手する経済合理性があります。

個人開発者・小規模チームの場合、まず Notion MCP Server で Claude Code と Notion を繋ぎ、続けて Worker を1本書いて GitHub PR の自動要約のような軽量タスクを試すのがスタートとして最適です。業務組織であれば Salesforce / Zendesk 同期の Worker を書いて、社内データ × AI エージェントの統合体験を3ヶ月で確立するのが現実的なロードマップになります。

External Agents API が GA する時期は未公表ですが、Workers で先行投資した「カスタムツール」はそのままエージェント基盤として再利用できる設計です。先行投資の損失はゼロ。Notion 3.5 を試すなら、今が最適なタイミングと言えます。

もう1点重要なのは、Notion 3.5 が示した「ワークスペース＝エージェント・ハブ」というモデルは、Slack や Asana、ClickUp などの競合 SaaS にも波及する可能性が高い点です。これらの競合も似た発表をする可能性は十分あり、その時には Notion が先行優位を取れるかどうかが分岐点になります。たとえるなら「クラウドストレージで Dropbox が先行したが、後追いの Google Drive / OneDrive にシェアを奪われた」歴史を思い出させる構図で、Notion がベータ期間中に開発者エコシステムをどれだけ獲得できるかがその後の勝敗を決めます。逆に言えば、開発者側にとっては「今このタイミングで Notion の Developer Platform に触れておく」ことが、業界全体のエージェント基盤を理解する近道になります。

参考リンク

← Blog一覧へ