Notion AI APIでできること・できないこと｜業務連携の現実的な設計

「Notion AI API」と検索する人の多くは、NotionのデータベースやページをAIで要約、分類、下書き作成したいはずです。

たとえば、次のようなことです。

• 問い合わせDBをAIで分類する
• 議事録からタスクを抽出する
• FAQ候補を下書きする
• 採用応募の内容を要約する
• 顧客メモから次アクションを作る
• Notion更新をWebhookで受け、外部AI処理へ渡す

ただし、最初に分けるべきことがあります。

Notion AIとNotion APIは同じものではありません。

Notion公式のAIページでは、Notion AIはNotion内のページ、ドキュメント、タスク、データベースで直接作業できるAI機能として説明されています。ワークスペースや接続済みアプリのコンテキストを使って、検索、文書作成、会議メモ、データベースの自動入力などに使えます。

Notion公式：Notion AI

一方、Notion公式APIドキュメントでは、Notion APIはページ、データベース、データソース、ユーザー、コメントなどを読み書きするための接続APIとして説明されています。接続ごとに、読み取り、更新、挿入、コメント読み取りなどの能力と、アクセスできるページやDBを設定します。

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

つまり、実務で外部AI連携を作るときは、次のように考えるのが安全です。

役割	使うもの
Notion内でAIを使う	Notion AI
NotionのページやDBを外部から読む・書く	Notion API
Notionの変更を外部処理へ渡す	Webhook
要約、分類、下書き、構造化を外部で行う	OpenAI APIなどの外部AI API
最終判断、承認、顧客返信	人の確認

Notion AI APIという名前で一つの魔法の入口を探すより、Notion API、Webhook、外部AI、人の確認を分けて設計する方が、業務では安全です。

この記事では、Notion AI APIでできること・できないことを、Notion AIとNotion APIの違い、Notion APIで扱える情報、外部AIで処理する構成、Webhookとの組み合わせ、人の確認、セキュリティ、実装しない方がよい処理に分けて整理します。

Notion Webhook連携の考え方はこちら
Notionインテグレーションの基本はこちら
NotionとChatGPT連携の考え方はこちら

先に結論：Notion AIを外から呼ぶより、外部AI処理をNotionに戻す

現実的な業務連携は、次の構成です。

段階	役割
Notion DB	問い合わせ、議事録、タスク、FAQ候補を持つ
Webhook	対象データの追加や更新を外部処理へ知らせる
Notion API	ページ、DBプロパティ、本文、コメントなどを取得・更新する
外部AI API	要約、分類、抽出、下書き、構造化を行う
確認ビュー	AI結果を人が確認する
Notion更新	確認済みの分類、要約、タスク、FAQ候補を戻す

この構成なら、Notionを業務DBとして使いながら、AI処理を外部で柔軟に組めます。

ただし、AI結果は最終結果ではありません。

AIに任せる	人が確認する
問い合わせ分類候補	正式な対応方針
議事録要約	決定事項、責任者、期限
FAQ下書き	公開可否、表現、正確性
タスク抽出	担当者、期限、優先度
メール返信案	顧客への正式返信
リスク検知	法務、契約、個人情報判断

NotionとAIを連携する目的は、人の確認を消すことではありません。

人が見るべきものを整理し、下書きや分類の時間を減らすことです。

まずNotion AIとNotion APIを分ける

Notion AIは、Notion内で使うAI機能です。

公式ページでは、Notion AIはページ、ドキュメント、タスク、データベースで直接作業でき、ワークスペースや接続済みアプリのコンテキストを使って作業を進めると説明されています。

一方で、Notion APIは、外部アプリやコードがNotionのページやDBにアクセスするための仕組みです。

比較	Notion AI	Notion API
主な用途	Notion内で検索、作成、編集、要約、自動入力	外部システムからページやDBを読み書き
使う場所	Notionの画面、Notion内のAI機能	外部アプリ、スクリプト、連携基盤
扱う対象	Notion内の文脈、接続済みアプリの情報	APIでアクセス権を持つページ、DB、コメント等
設計の焦点	誰がNotion内でAIを使うか	どのDBに何の権限を渡すか
業務連携での役割	下書き、検索、自動入力の補助	データ取得、更新、Webhook連携の土台

「Notion AI APIで何でも自動化する」と考えると、要件が曖昧になります。

実装では、次のように分けます。

• Notion内で人が使うAI機能なのか
• 外部処理としてAIを呼びたいのか
• Notionのデータを外部AIに渡してよいのか
• AI結果をNotionに戻す前に誰が確認するのか

この分解をしないまま実装すると、権限、個人情報、誤分類、誤返信の問題が起きます。

Notion APIで扱える情報

Notion APIでは、Notionのページやデータベースを外部から扱えます。

公式ドキュメントでは、接続はページ、データベース、データソース、ファイルアップロード、コメント、コンテンツ検索、ユーザーなどを扱えると説明されています。また、接続やトークンには、読み取り、更新、挿入、コメント読み取りなどの能力があり、ページやDBにアクセス権が必要です。

業務連携では、次のように使います。

Notion側の情報	API連携での使い方
DBプロパティ	種別、ステータス、担当者、期限、AI処理状態を読む
ページ本文	議事録、問い合わせ本文、FAQ候補を取得する
コメント	レビューや差し戻し理由を扱う
ユーザー	担当者、確認者、通知先の判定に使う
Webhookイベント	変更を検知し、後続処理を起動する
ページ更新	AI結果や確認済み情報をNotionへ戻す

ただし、APIで読めるからといって、すべて外部AIへ渡してよいわけではありません。

渡しやすい情報	注意が必要な情報
問い合わせ種別、ステータス、本文の一部	氏名、メール、契約金額、添付ファイル
議事録の公開範囲内メモ	人事、労務、法務、医療、機密情報
FAQ候補、社内マニュアル	顧客別の機密、個人情報、未公開情報

API連携では、対象DB、対象プロパティ、外部AIへ渡す項目を絞ります。

Notionセキュリティの基本はこちら

外部AIで処理する構成

Notion外でAI処理を行う場合は、OpenAI APIなどの外部AI APIを使います。

OpenAI公式クイックスタートでは、APIキーを設定し、SDKなどからモデルへリクエストを送って応答を得る流れが説明されています。

OpenAI公式：Developer quickstart

Notionと外部AIの基本構成は、次の通りです。

処理	内容
1. Notionで受付	問い合わせ、議事録、FAQ候補がDBに入る
2. Webhookまたは定期処理	AI処理が必要なページを検知する
3. Notion APIで取得	必要なプロパティや本文だけ取得する
4. 外部AI APIで処理	要約、分類、抽出、下書きを作る
5. Notionへ戻す	AI結果、信頼度、処理ログを別プロパティに書く
6. 人が確認	確認済みにして正式反映する

DBには、AI処理用のプロパティを持たせます。

プロパティ	型	目的
AI処理状態	ステータス	未処理、処理中、要確認、確認済み、失敗
AI分類候補	セレクト、テキスト	問い合わせ種別やFAQカテゴリの候補
AI要約	テキスト	人が確認する短い要約
AI抽出タスク	リレーション、テキスト	議事録から抽出したタスク候補
AI信頼度	数値、セレクト	確認の優先度判断に使う
確認者	ユーザー	誰が結果を見るか
最終AI処理日	日付	再処理や棚卸しに使う
エラー概要	テキスト	失敗時の復旧に使う

重要なのは、AI結果を既存の正式プロパティに直接上書きしないことです。

たとえば、種別 をAIが直接変えるのではなく、まず AI分類候補 に入れます。人が確認してから 種別 に反映します。

Webhookとの組み合わせ

Webhookを使うと、Notion DBの更新を外部AI処理の入口にできます。

たとえば、問い合わせDBで AI処理状態 が 未処理 になったらWebhookを送る。受信APIがNotion APIで本文を取得し、外部AI APIで分類し、結果をNotionに戻す。最後に担当者が確認する。

流れは次の通りです。

段階	注意点
Webhook送信	送信条件を絞る。何でも送らない
受信API	認証、重複確認、対象DB確認を行う
Notion API取得	必要な項目だけ取得する
AI処理	要約、分類、抽出に用途を限定する
Notion更新	AI結果は候補として別プロパティに戻す
人の確認	正式分類、返信、承認は人が決める

Webhook連携では、ログが必要です。

ログ項目	目的
ページID	対象を追えるようにする
AI処理ID	外部AI処理と照合する
入力範囲	どのプロパティを渡したか
出力概要	何が返ったか
エラー	失敗理由を残す
再実行回数	無限再実行を防ぐ
確認者	誰が結果を見たか

人の確認が必要な場面

AI連携で最も危ないのは、AI結果をそのまま正式処理にしてしまうことです。

次の処理は、人の確認を残します。

AIができること	人が確認すること
問い合わせを分類する	顧客への対応方針、返信文
議事録からタスク候補を出す	担当者、期限、優先度
FAQ下書きを作る	正確性、公開範囲、表現
契約相談を要約する	法的判断、契約条件
採用応募を要約する	評価、合否、個人情報の扱い
クレームを検知する	エスカレーション判断

Notion DBでは、確認ビューを作ります。

ビュー	フィルター
AI要確認	AI処理状態が要確認
AI失敗	AI処理状態が失敗
高リスク	種別が契約、個人情報、金額、クレーム
確認済み	AI処理状態が確認済み
再処理待ち	再実行フラグがチェック済み

AIの出力は、作業を速くするための下書きです。

業務責任をAIに移すものではありません。

セキュリティと権限

Notionと外部AIをつなぐと、情報の流れが増えます。

見るべきポイントは、次の通りです。

項目	確認すること
対象DB	外部AIへ渡してよいDBか
対象プロパティ	どの項目を渡すか
個人情報	氏名、メール、添付、契約情報を含むか
APIトークン	Notion APIキー、OpenAI APIキーをどこに保管するか
ログ	入力全文をログに残していないか
保管期間	AI処理結果やログをいつ削除するか
権限	誰がAI結果、エラー、入力元を見られるか
外部サービス	データ利用条件、保存、削除、契約を確認する

APIキーはNotionページやSlackに貼りません。

本番用、検証用を分け、環境変数やシークレット管理に置きます。

また、AIに渡す入力は最小限にします。

問い合わせ全文が必要ない分類なら、件名、種別候補、本文の一部で足りる場合があります。議事録からタスクを抽出する場合も、参加者の個人情報や顧客名を必要以上に渡さない設計を検討します。

実装しない方がよい処理

NotionとAIをつなぐと、何でも自動化したくなります。

しかし、次の処理は慎重に扱います。

実装しない方がよい処理	理由
顧客への自動返信	誤回答、契約条件、表現リスクがある
承認可否の自動決定	判断責任をAIに渡せない
契約、労務、会計の確定処理	正式記録と監査が必要
個人情報の大量AI処理	保管、同意、削除、アクセス制御が必要
Notionの正式プロパティをAIが直接上書き	誤分類時の復旧が難しい
双方向同期とAI更新を同時に行う	競合、上書き、重複が起きやすい

最初に作るなら、次のような用途に絞ります。

最初に向く用途	理由
問い合わせ分類候補	人が確認しやすく、効果が出やすい
議事録要約	下書き用途として使いやすい
タスク抽出候補	担当者が確認して使える
FAQ下書き	公開前レビューを置きやすい
日報要約	社内利用で始めやすい

Notion AI APIという言葉に引っ張られず、Notion APIでデータを扱い、外部AI APIで下書きを作り、人が確認してNotionに戻す。

この分担にすると、Notionを小さな業務システムとして使いながら、AI連携のリスクを抑えられます。