Notionインテグレーションの基本｜API連携と外部サービス接続を安全に管理する

Notionインテグレーションを使うと、NotionをSlack、Googleカレンダー、フォーム、外部SaaS、自社スクリプト、業務システムにつなげられます。

ただし、会社で使う場合は「おすすめ連携アプリ一覧」を見るだけでは足りません。

外部連携は、Notionのページやデータベースに別のシステムから入る経路です。連携先、権限、対象DB、トークン、停止手順を決めないまま増やすと、便利さより管理不能の方が先に来ます。

Notion公式APIドキュメントでは、Notion connectionはワークスペースを外部ツールや自動化コードにつなぐ仕組みで、接続ごとに認証情報と権限があると説明されています。接続方式には、内部接続、公開接続、個人アクセストークンがあります。

Notion公式APIドキュメント：Overview

また、Notion内だけで完結するデータベースオートメーションもあります。公式ヘルプでは、DBに特定の変更があったときにトリガーとアクションを実行できると説明されています。

Notion公式ヘルプ：データベースオートメーション

つまり、Notion連携には少なくとも2つの設計があります。

• Notion内のDB更新や通知で完結させる
• APIや外部サービスを使ってNotion外へつなぐ

Notionインテグレーションは、連携先を増やす話ではなく、どの業務DBをどの範囲で外に開くかを設計する話です。

この記事では、Notionインテグレーションの基本を、API連携、Notion内自動化、権限、対象DB、トークン管理、外部サービス連携例、運用保守まで整理します。

Notionセキュリティの基本はこちら
Notionフォームの設計はこちら

先に結論：連携台帳を作ってから接続する

Notionインテグレーションは、接続する前に台帳を作ります。

最低限、次の項目を決めます。

項目	決めること
連携名	何のための接続か
連携方式	Notion内自動化、内部接続、公開接続、個人アクセストークン
対象DB	どのページ、データベースにアクセスさせるか
権限	読み取り、更新、挿入、コメント、ユーザー情報など
トークン管理者	誰が発行、保管、更新、停止を持つか
連携先	Slack、Google、Make、Zapier、自社API、基幹システムなど
更新方向	Notionから外部、外部からNotion、双方向
エラー通知先	失敗時に誰へ通知するか
最終確認日	今も必要な連携かを確認した日
停止条件	退職、契約終了、障害、使わなくなった時の止め方

この台帳がない連携は、作った直後は動いても、半年後に危なくなります。

特に危ないのは、次の状態です。

• 誰が作った連携か分からない
• どのDBにアクセスできるか分からない
• トークンが個人のメモやコードに残っている
• 退職者が作った個人トークンで動いている
• 外部サービス側の障害に気づけない
• Notionと外部DBのどちらが正か決まっていない

Notionを小さな業務システムとして使うなら、連携は「追加」ではなく「運用対象」として扱います。

インテグレーションとは

Notionのインテグレーションは、Notionを外部ツールやコードと接続する仕組みです。

公式APIドキュメントでは、接続ごとに、呼び出せるAPI、読める・書けるコンテンツ、認証方法を定義すると説明されています。

実務では、次の3種類を分けて考えます。

種類	向いている用途	注意点
内部接続	自社ワークスペース内の自動化、同期、通知、ダッシュボード	静的APIトークンを安全に保管する
公開接続	複数ワークスペースで使う外部アプリ、SaaS連携	OAuth、許可ページ、ユーザーごとの承認を考える
個人アクセストークン	個人のCLI、スクリプト、信頼できる作業補助	作成者の権限に依存し、退職や異動に弱い

内部接続は、1つのワークスペース内で使う社内用の接続です。公式ドキュメントでは、内部接続は単一ワークスペースにスコープされ、静的APIトークンで認証し、ページやDBに明示的にアクセス権を付与する必要があると説明されています。

Notion公式APIドキュメント：Internal connections

社内の通知や同期なら、まず内部接続から考えるのが現実的です。

一方で、個人アクセストークンは「その人として動く」性質があります。小さなスクリプトでは便利ですが、会社の継続運用には向きません。担当者が変わった時点で止まる、または止めるべきなのに残る危険があります。

API連携とNotion内自動化の違い

Notionで自動化したいとき、いきなりAPI連携にしない方がよい場合があります。

Notion内のデータベースオートメーションで済むなら、まずそれで足ります。

やりたいこと	まず見る選択肢
新しい問い合わせをSlackに通知する	DBオートメーション、Slack連携
ステータス変更時に担当者を設定する	DBオートメーション
フォーム回答を受付DBに保存する	Notionフォーム
Notion DBの内容を外部システムへ同期する	API連携
外部SaaSの更新をNotionへ反映する	API連携、外部自動化サービス
基幹DB、会計、契約管理とつなぐ	専用システム側のAPI、監査ログ、権限設計

Notion内自動化は、軽い受付、通知、プロパティ更新に向いています。

API連携は、Notionの外へデータを出す、外部からNotionへ書き込む、または複数システムの同期を行うときに使います。

ただし、API連携を増やすほど責任範囲も増えます。

領域	Notion内自動化	API連携
設定場所	NotionのDBや自動化設定	Developer portal、外部サービス、コード
主な責任者	DB管理者、業務担当	管理者、開発者、外部サービス管理者
障害時の確認	Notion内の履歴や通知	ログ、APIエラー、認証、外部サービス状態
権限リスク	DBやページの共有範囲	トークン漏洩、対象DB拡大、外部側の保管
向いている業務	通知、担当設定、期限設定	同期、集計、外部処理、独自画面

「できるからAPIにする」ではなく、「Notion内で済むか、外に出す必要があるか」で判断します。

接続に渡す権限

Notion連携で最初に見るべきなのは権限です。

公式APIドキュメントでは、接続やトークンには、コンテンツの読み取り、更新、挿入、コメント読み取りなどの能力があると説明されています。また、接続がページやDBを操作するには、そのページやDBへのアクセスが必要です。

Notion公式ヘルプでも、ページ共有、一般アクセス、権限レベル、チームスペース、ゲスト、ページレベルアクセスが整理されています。

Notion公式ヘルプ：共有と権限管理

実務では、次のように考えます。

権限	使う場面	渡す前の確認
読み取り	外部ダッシュボード、検索、通知	機密情報や個人情報を読ませてよいか
更新	ステータス変更、担当設定、同期	人の判断を上書きしないか
挿入	外部フォーム、外部イベントの作成	不正データや重複が入らないか
コメント	レビュー通知、相談ログ	コメント内に社外秘が含まれないか
ユーザー情報	担当者割当、通知先判定	メンバー情報を外部に渡す必要があるか

原則は、最小権限です。

たとえば、問い合わせ受付の外部連携なら、全社ナレッジや顧客DBまで読ませる必要はありません。問い合わせDBへの挿入と、必要な通知だけで足ります。

タスク更新の連携なら、タスクDBだけに更新権限を渡し、議事録DBや顧客DBには触らせません。

「あとで便利そうだから広く渡す」は、Notion連携ではやめた方がよいです。

対象DBを限定する

APIトークンや外部サービスより先に、対象DBを限定します。

Notionはページ階層で情報をまとめやすい反面、親ページを共有すると子ページにも影響することがあります。公式の内部接続ドキュメントでも、親ページを共有すると子ページへのアクセスが継承されると説明されています。

連携用には、次のように入口DBを分けると管理しやすくなります。

DB	役割	連携の考え方
問い合わせDB	外部フォームやWebからの受付	外部からの挿入はここに限定する
タスクDB	担当、期限、進捗の更新	更新できるプロパティを絞る
通知ログDB	送信履歴、エラー、再送待ち	外部処理の結果を残す
連携台帳DB	連携名、権限、責任者	管理者だけが編集する
顧客マスタ	正式な顧客情報	Notionが原本か、外部CRMが原本かを決める

特に、顧客マスタ、契約、請求、会計、人事労務は注意が必要です。

Notionに参照用メモや作業タスクを置くのはよいですが、正式な原本や監査が必要な履歴は、CRM、契約管理、会計ソフト、人事労務システムに置く方が安定します。

Notionデータベースの作り方はこちら

トークン管理

Notion API連携では、トークン管理を軽く見ない方がよいです。

Notion公式のAPIキー管理ガイドでは、APIキーはNotionへの強い認証情報であり、漏洩するとワークスペースのデータや接続にリスクが出ると説明されています。また、APIキーをコードに直接書かず、環境変数やシークレット管理を使い、定期的なローテーションや棚卸しを行うことが推奨されています。

Notion公式APIドキュメント：Best practices for handling API keys

実務では、次のルールが必要です。

ルール	内容
トークンを記事や議事録に貼らない	Notionページ、Slack、メール、コードレビューに直接書かない
.env をコミットしない	ローカル設定ファイルはGit管理から外す
本番と検証を分ける	同じトークンで検証と本番を動かさない
管理者を決める	誰が発行、更新、失効を行うかを明確にする
退職時に止める	個人トークンや外部サービスの接続を棚卸しする
定期確認する	最終確認日を持ち、不要な接続を削除する

小さな会社で起きやすいのは、最初に詳しい人が個人アカウントで作ったトークンが、そのまま本番運用になるケースです。

これは速いですが、継続運用には弱いです。

業務で使う連携は、個人の作業メモではなく、会社の運用台帳で管理します。

外部サービス連携例

Notion連携は、目的ごとに設計が変わります。

連携先	使い方	注意点
Slack	新規問い合わせ、期限切れ、ステータス変更の通知	通知だけで完了扱いにしない
Googleカレンダー	会議、面談、タスク期限との接続	Notionとカレンダーのどちらを正にするか決める
Googleフォーム、Notionフォーム	回答をDBへ集める	回答後の担当、期限、個人情報を設計する
Make、Zapier	ノーコードで外部SaaSとつなぐ	外部サービス側に渡すデータ範囲を確認する
自社API	受注、在庫、案件、顧客情報との連携	ログ、再実行、認証、障害通知が必要
CRM、会計、契約管理	原本システムとの参照・同期	Notionを正式原本にしない判断も必要

重要なのは、同期方向です。

同期方向	例	設計ポイント
Notionから外部	タスク完了をSlack通知、DB更新を自社APIへ送る	送信失敗時の再実行とログ
外部からNotion	フォーム回答、外部イベント、顧客メモをNotionへ作成	重複、入力チェック、担当者設定
双方向	カレンダー、案件進捗、顧客情報の相互更新	競合、どちらが正か、削除時の扱い

双方向同期は、見た目より難しいです。

Notionと外部システムの両方で編集できると、どちらを正にするか、同時更新をどう扱うか、削除を反映するか、エラー時に戻せるかが問題になります。

小さく始めるなら、まず一方向にします。

運用保守の注意

Notionインテグレーションは、作って終わりではありません。

次の運用を月次または四半期で見ます。

点検項目	確認すること
接続一覧	使っていない連携が残っていないか
対象DB	余計なDBや親ページまでアクセスさせていないか
権限	読み取りだけでよい連携に更新権限を渡していないか
トークン	個人管理、退職者管理、期限切れがないか
エラー	同期失敗、通知失敗、再送待ちが見えているか
外部サービス	契約終了、担当者変更、権限変更が反映されているか
原本	Notionと外部システムのどちらが正か崩れていないか

障害時の手順も必要です。

状況	対応
通知が来ない	Notion自動化、外部サービス、APIログ、権限を確認する
外部から書き込めない	対象DBアクセス、トークン、プロパティ名変更を確認する
重複データが増えた	一意キー、外部ID、再実行条件を確認する
退職者の連携が残った	個人トークンを失効し、会社管理の接続へ移す
機密DBに広くアクセスした	トークン停止、対象DB見直し、変更履歴確認を行う

Notion連携の保守で一番危ないのは、静かに失敗することです。

Slack通知が飛ばない、外部DBに反映されない、古いトークンで動き続ける、重複が積み上がる。こうした問題は、画面を見ただけでは分かりません。

そのため、通知ログDBや連携台帳DBを作り、最終成功日時、最終エラー、次回確認日を残します。

Notionに置くもの、外に出すもの

Notionは連携しやすいツールですが、すべての業務データの最終保管場所にする必要はありません。

Notionに置きやすい	外に出した方がよい
受付、タスク、議事録、FAQ、軽い案件管理	会計、契約、労務、厳密な顧客マスタ
進捗、担当、期限、確認ビュー	監査ログ、法的保存、権限階層が重い処理
外部システムへのリンク、作業メモ	大量データ、複雑な集計、厳密なAPI同期

Notionを業務システムとして使うなら、Notionに寄せる部分と、Notion外へ分ける部分を設計します。

インテグレーションは、その境界を越える仕組みです。

だからこそ、便利な連携を追加する前に、対象DB、権限、トークン、外部サービス、保守責任を決める必要があります。

最初に作るべきものは、連携アプリの一覧ではなく、連携台帳です。

Notion通知設定の基本はこちら