先に結論
Notion の personal access tokens で一番大きい変化は、token が増えたことではありません。
自分用の token と、チーム用の connection と、外部向け OAuth を分けて考えやすくなったこと が本質です。
2026-05-12 の changelog で、Notion は Developer portal を connections、Workers、personal access tokens の管理ハブとしてまとめました。PAT も、単なる裏口 token ではなく、CLI、Workers、個人スクリプト向けの user-scoped token としてはっきり位置づけられています。
先に答えを言うと、選び分けはこうです。
- 自分の CLI や簡単な script なら PAT
- チーム共通 automation なら internal connection
- 複数ユーザー向けの製品 なら public OAuth
この順番を先に決めるだけで、あとから token 運用をやり直す確率がかなり下がります。
Notion を agent hub としてどこまで直接つなぐかを広く見たいなら、Notion MCP vs ChatGPT apps vs Claude Projects vs Composio が前提になります。MCP や workflow 側まで含めて認証の置き場を比べたいなら、ChatGPT apps vs Zapier vs Make vs MCP【2026年版】 もつながります。
何が変わったのか
今回の更新で Notion は、Developer portal を 1つの入口として押し出しました。
changelog で明示されたのは次の3点です。
- Developer portal で connections、Workers、personal access tokens をまとめて管理できる
- PAT は user-scoped token として整理された
- Workspace admins は PAT の一覧確認と revoke、一部プランでは PAT 作成ポリシー制御 までできる
ここが大きいです。従来の「とりあえず token を発行して試す」流れから、誰の権限で動く token なのかを最初に選ぶ 流れへ寄っています。
しかも PAT docs では、用途がかなり具体的です。
- local scripts
- notebooks
- command-line tools
- Notion Workers development and deployment
- trusted third-party tools
つまり PAT は、広く何でも使う鍵ではなく、1人の Notion ユーザーとして動く開発者向け認証 だと読むほうがズレません。
PAT が向く場面
PAT は、自分の権限でそのまま動いてほしい場面に向きます。
CLI とローカル script
Notion docs でも最初に挙がるのが local scripts と command-line tools です。
この用途なら PAT は分かりやすいです。bot user を別に作らず、ページ共有も追加せず、そのまま自分の権限で API を叩けます。
まず試すだけなら、internal connection より軽いです。
Workers の初期開発
PAT docs では Workers access も capability として整理されました。
Workers overview を見ると、Notion Workers は Node と TypeScript で書いた小さなプログラムを ntn workers deploy で動かす仕組みです。sync、tool、webhook を持たせられるので、CLI と合わせて試作を回しやすいです。
ここでは PAT が効きます。自分の開発環境から Workers を作り、まず小さく動かす ところまでを 1 本の user-scoped token で始めやすいからです。
ただし、Workers capability を付けられることと、workspace で Workers が使えることは別です。実運用へ入る前に、plan や feature availability は別で見たほうが安全です。
trusted tool への個人接続
もう1つ向くのが、Notion token を貼って使う trusted tool です。
この時も PAT の説明は明確です。token は作成者の membership と page permissions を使います。つまり「自分が見えるものを、そのツールにも見せる」構造です。
逆に言うと、チーム共通の安定した接続 には向きません。作成者がページアクセスを失ったり、workspace を離れたりすると、PAT も同じように効かなくなるからです。
internal connection に切り替えるべき場面
PAT で始めても、早めに internal connection へ寄せたほうがいい場面があります。
一番分かりやすいのは、個人の自動化ではなく、チームの自動化になったとき です。
internal connection は、特定ユーザーではなく独立した bot user として動きます。ページは Add connections や Developer portal の Content access で共有し、その connection 自体に権限が残ります。
この設計の違いは大きいです。
- PAT は 人に権限がひもづく
- internal connection は connection に権限がひもづく
だから、次の条件に当てはまったら internal connection が自然です。
- 担当者が変わっても止めたくない
- 共有 database や dashboard を継続更新したい
- 誰かの個人 token で本番運用したくない
- page access を明示的に管理したい
Notion を dashboard や team hub として使っているなら、Notion Dashboard vs Airtable Interfaces vs ClickUp Dashboards のような共有基盤の記事ともつながります。共有基盤に対して個人 token のまま書き込み続ける運用は、長く見ると苦しくなりやすいです。
public OAuth が必要になる場面
PAT と internal connection のどちらでも足りないのが、外部向けの製品です。
Notion の public connections docs では、複数 workspace に配布する connection は OAuth を前提にしています。各ユーザーが認可し、それぞれの access token を受け取る構造です。
ここでは PAT を選ばないほうがいいです。PAT は docs にもある通り、product used by many Notion users の認証モデルには向きません。
選び方は単純です。
- 自分だけが使うなら PAT
- 自社 workspace 内だけなら internal connection
- 他社や複数ユーザーへ配るなら public OAuth
この境界を曖昧にすると、最初は早くても後で認証を作り直すことになります。
管理者が今決めるべきこと
今回の更新は、開発者だけでなく管理者向けの意味も大きいです。
PAT docs では、Workspace admins ができることとして次が明記されています。
- PAT の一覧確認
- active と revoked の状態確認
- name、creator、status での検索と filter
- revoke
- 誰が Notion API access 付き PAT を作れるかの policy 設定
特に大事なのは、既存 PAT も policy 変更の影響を受ける 点です。
もし admin が policy を変えて、そのメンバーが Notion API access 付き PAT を作れない状態になると、その人の既存 PAT も Notion API request で unauthorized を返します。
つまり管理者は、単に作成可否を決めるだけでは足りません。
1. 誰が作ってよいか
Free、Plus、Business、Enterprise で既定値が違います。特に Business と Enterprise は、誰に PAT 作成を許すかを設計しやすくなりました。
2. 失効前の更新フロー
PAT は 1 年で expire します。
この仕様は地味ですが大きいです。放置すると 1 年後に script や Worker が急に止まります。発行台帳、期限通知、再発行手順までは先に決めたほうがいいです。
3. revoke の責任者
退職、異動、委託終了、利用停止のときに、誰が revoke するかを曖昧にしないほうがいいです。PAT は user-scoped なので、人の出入りと一緒に管理する必要があります。
迷ったときの判断基準
迷ったら、まず「誰の権限で動くべきか」だけ見れば十分です。
| 使いたいもの | 最初の候補 | 理由 |
|---|---|---|
| 自分の CLI、notebook、ローカル script | PAT | 自分のページ権限をそのまま使える |
| チーム共通の sync、更新、自動化 | internal connection | bot user として独立して運用できる |
| 複数ユーザー向け SaaS、配布アプリ | public OAuth | ユーザーごとに認可と token 発行が必要 |
| Workers の試作 | PAT | CLI と一緒に最短で触りやすい |
| Workers の長期運用 | internal connection も検討 | 個人依存を減らしやすい |
比較を広げすぎなくても、ここだけ押さえれば十分前に進めます。
いま試すならどこから始めるべきか
一番無理がないのは、PAT で小さな script か CLI を 1 本動かすことです。
その次に、Workers の試作や、社内ツールへの trusted connection を試す。そこで「この自動化は個人の作業を越えた」と見えたら、internal connection に切り替える。この順番が自然です。
いきなり全部を 1 つの認証方式で済ませようとしないほうがいいです。今回の Notion 更新は、その切り分けをやりやすくするための整理だと見るのが一番実務的です。