Notionは長い間、説明しやすいツールでした。ドキュメント、社内Wiki、議事録、軽いデータベース、プロジェクトページ。使い方は会社ごとに違っても、「業務の情報を置く場所」と言えばだいたい伝わりました。

ただ、最近のNotionはその説明だけでは足りません。

NotionはDeveloper Platform、API、Custom Agents、MCP integrations、External Agents、Workers、CLIの方向へ広がっています。ここで見るべき点は、Notionが急にZapierやMakeを置き換えるかどうかではありません。Notionの中には、AIエージェントが必要とする材料がもともと多いことです。ページ、データベース、意思決定メモ、担当者、状態、会議の背景、過去にその判断をした理由。そういうものが一か所に寄りやすい。

だから「NotionをAIの業務OSにすればいい」という話になりがちです。私はそこまで急がないほうがいいと考えます。ワークスペースは、AIが入ったから良くなるわけではありません。次に見る人が、何が変わり、なぜ変わり、誰が受け入れ、次に何をするのか分かるときに価値が出ます。

この記事の裏にあったワークスペースの問い

これは機能紹介ではなく、実務で手戻りが減るかを見るための記録です。NotionをAIエージェントの業務ハブに置く前に、記録、権限、MCP連携、承認、引き継ぎ、止める条件を実際の運用単位で分け、任せる仕事と人が見る仕事を決めます。重要なのは、どのAIが賢そうに見えるかではなく、次の人へ渡した後に作り直しが残らないかでした。

サンプルにしたNotionデータベース

基準にした仕事は具体的にしました。Slackの依頼がNotionのタスク、Google Sheetsの行、フォローアップメモにつながる仕事。そのうえで、入力、AIが触る範囲、確認する人、次に渡す場所を分けて見ました。Notion、Notion AI、Notion API、MCP、External Agents、Workersは、その流れを短くし、確認を重くしない場合にだけ意味があります。

エージェントハブと呼ぶ前に見たこと

見た点判断基準失敗のサイン
入力AIが扱えるだけの材料がそろっているか足りない文脈を質問せずに推測する
人の確認承認、修正、差し戻しが短時間でできるか担当者が最初から読み直す
引き渡し文書、表、チケット、業務flowへ渡せるか次の人が形式や意味を直す
再現性別の材料でも同じ手順で動くか1回目だけよく、2回目から崩れる

仕事を見えるようにしたレビュー項目

根拠確認したことなぜ重要か
入力Slackの依頼がNotionのタスク、Google Sheetsの行、フォローアップメモにつながる仕事。仕事はツール名ではなく、入ってくる材料から始まります
確認点誰が確認し、何を差し戻せるかを見ました確認者がいないと、自動化に見えるだけです
失敗メモSlackは動いているが、NotionとSheetsがずれて、どれが最新か分からない状況。うまくいかなかった実行を一つ残すと、範囲を絞れます

ワークスペースがずれた場所

弱いのは最初の回答ではありません。回答の後にある引き渡しです。このテーマでよく起きる失敗は、Slackは動いているが、NotionとSheetsがずれて、どれが最新か分からない状況。きれいな下書きは開始点であって、運用可能という証拠ではありません。

Notionに権限を広げる前の基準

私なら、まずSlackメッセージ、Notionタスク、Sheets行、担当者メモを残します。そのうえで、人が短時間で確認できるかを見ます。確認に毎回時間がかかるなら、モデルを変える前に自動化する範囲を狭めます。

Notionに次のステップを任せる前の確認

  • AIに渡す入力を一文で書く。
  • 結果を承認、修正、却下する人を決める。
  • 出力が次に行く場所を決める。
  • 成功例だけでなく、失敗例を一つ残す。
  • 生成速度ではなく確認時間を見る。
  • 次の人が毎回作り直すなら、その自動化はいったん止める。

確認した資料

変わりやすい情報は、公式文書、製品ページ、変わりやすい主張を支える出典メモを基準にしました。価格、モデル提供範囲、機能は動くので、意見と根拠を分けて扱います。

まず置く基準

私なら、NotionをAIがすべて実行する中央エンジンにはしません。AIが関わった仕事の記録面として使います。

役割はこう分けます。

Notionに残すものAIが準備するもの人が決めるもの
元ページ、プロジェクトの文脈、DB行、意思決定メモ要約、欠けている項目、下書き、振り分け案承認、最終文面、例外判断、戻しにくい変更

保守的に見えるかもしれませんが、実務ではこのほうが続きます。

AIエージェントがNotionデータベースを読み、次の行動を提案するなら、そのページには四つの情報が必要です。何を根拠にしたのか。何を変えようとしているのか。誰が承認するのか。間違っていたらどう戻すのか。この四つがなければ、便利な自動化ではなく、確認作業を誰かに押しつけただけになります。

Notionが通常の自動化ツールと違う位置

Zapier、Make、n8nのようなツールは、システム間でイベントを動かすのが得意です。行が変わったらWebhookを送る。メッセージを出す。チケットを作る。担当者を入れる。これは今後も必要です。

Notionは別の場所にいます。多くのチームで、仕事を自分たちに説明する場所になります。プロダクト要件、リリースメモ、アカウントプラン、調査メモ、議事録、採用計画、運用チェックリスト、ベンダー評価、予算メモ。こうした情報は、きれいなイベントログではありません。半分だけ構造化された業務の文脈です。

AIエージェントはこの文脈を必要とします。単なるトリガーと項目マッピングだけでは足りません。なぜその仕事が発生したのか、先月どのルールを決めたのか、どの例外を認めたのか、もう議論し直してはいけない決定は何か。そこまで近くにあると使いやすい。

Notionが面白いのはここです。文書にAIが付くことより、文書、データベース、意思決定の跡が近い場所でエージェントが動けることのほうが大きい。

実際に置くもの

私が導入するなら、派手なエージェントから始めません。まずAIの作業を確認できる記録を作ります。

最初は業務受付データベースです。大きなプロセス管理表ではなく、小さくて十分です。

項目使う理由
依頼内容人が読める業務の中身
出所Slack、メール、議事録、フォーム、外部資料
担当者承認または差し戻しできる人
AIの役割読み取り、下書き、分類、更新、エスカレーション
レビュー状態新規、下書き、承認、差し戻し、保留
根拠リンクAIが参照したページ、ファイル、メッセージ
例外理由通常ルートで処理できなかった理由
次の行動次に動く人またはシステム

地味な項目です。しかし業務自動化は、こういう地味な項目で持ちます。後で問題が起きたとき、なぜそうなったかを追えるからです。

次に、意思決定ページのテンプレートを置きます。最低限、三つだけ答えられればいい。

  1. 何が変わったか。
  2. どの根拠を使ったか。
  3. 誰が受け入れたか。

最後に、エージェントの運用ルールページを作ります。承認なしでできること、下書きまでのこと、絶対に変えてはいけないことを書いておきます。これがないと、最初の失敗のあとで人は記憶をもとに言い合うことになります。

Notionに任せないもの

時間制限が強い実行業務は、Notionだけに置きません。返金、障害対応、請求支払い、コンプライアンス対応、権限変更のようなものは、本来のシステムで管理します。Notionは理由と引き継ぎを残す場所にしたほうが安全です。

Notionを第二のCRM、第二のチケットシステム、第二の経理ツールにするのも避けたいところです。最初は柔軟に見えます。三か月後には同期と責任分界の問題になります。

すでに正式なシステムがあるなら、Notionは説明と運用ビューを持つ。静かに競合するシステムにしない。この線引きは大事です。

現場での判断

私は、Notionを選ぶ場面と選ばない場面を先に分けます。業務の文脈が散らばっていて、人が最後に判断し、根拠リンクを残す必要があるならNotionは向いています。反対に、秒単位の処理、支払い、権限変更、障害対応のように外部影響がすぐ出る仕事では、Notionを標準経路にしません。

本番運用に入れるなら、まず読み取り専用です。次に下書き。次に低リスクの状態変更。この順番です。最初からAIに自由な更新を許すと、あとで人が全部見直すことになります。Notionを選ぶ理由は実行速度ではなく、判断の跡を残せることです。

最初に出すなら週次レビュー

私なら週次プロジェクトレビューから始めます。

エージェントはプロジェクトデータベースと関連ページを読みます。スケジュールや予算を勝手に変えません。代わりにレビュー用ページを作ります。

  • 担当者が空欄のプロジェクト
  • AIが更新したが、人が承認していないページ
  • 30日以上前の決定なのに、まだ現在の作業に影響しているもの
  • 次の行動がないまま止まっている項目
  • 顧客、ベンダー、費用、法務に関係する記述

担当者はその下書きを読み、直し、受け入れ、次の行動を決めます。

派手ではありません。そこが良い点です。AIには必要な文脈を渡しつつ、判断は人が持っています。エージェントが誤解した場合でも、どのページを根拠にしたのかを追えます。

数週間安定したら、低リスクの書き込みを一つだけ許します。たとえば担当者が空欄なら、レビュー状態を「担当者要」に変える程度です。その場合も変更履歴は残します。

MCPと外部エージェントが効く場所

MCPは、エージェントがツールやデータへ届く方法をそろえるための流れです。NotionのMCPやCustom Agentsの方向が重要なのは、Notionが「AIに要約される文書置き場」から「外部エージェントが業務文脈を読んで更新できる面」へ変わる可能性があるからです。

これは大きな変化です。別の環境にいるエージェントがNotionの文脈を取りに行き、ページを作り、データベースを更新し、Notionを継続的な業務記録として使えるようになります。

ただし運用の問題はなくなりません。むしろ重要になります。

  • どのページを読めるのか。
  • どのデータベースを更新できるのか。
  • どの項目は下書きまでなのか。
  • どの変更には人の名前が必要なのか。
  • 営業時間外に止めるべき操作は何か。
  • 元ページとDB項目が食い違ったら、どちらを優先するのか。

このあたりは発表文より地味です。しかしここを外すと、便利な自動化ではなく静かな混乱になります。

2週間で試すなら

チームに導入するなら、私は2週間だけ範囲を絞ります。

1週目は読み取り専用です。エージェントは選んだプロジェクトページと一つのデータベースだけを読みます。レビュー用ページの下書きは作れますが、DB項目は変えられません。チームは、レビュー時間が減ったか、根拠リンクが足りているか、人が結局すべて開き直したかを確認します。

2週目は低リスクの書き込みを一つだけ開けます。「レビュー状態」や「担当者未設定」くらいです。期限、予算、顧客への約束、権限、公開文書は触らせません。書き込みには必ずページ上の跡を残します。

成功基準は、きれいな要約ではありません。そこは簡単です。見るべきものは次です。

  • レビュー時間が実際に減ったか。
  • 担当者抜けを拾えたか。
  • 大きな修正なしで受け入れた下書きがいくつあったか。
  • 差し戻した提案がいくつあったか。
  • 担当者が原文を全部開き直したか。

最後が多いなら、まだ早い。モデルが良くても、運用設計が弱い状態です。

中止基準

次のサインが出たら範囲を狭めます。

サインよくある原因
レビュー担当が毎回すべての原文を開くAIの出力がまだ信頼されていない
AIページは増えるが担当者がいない文書は増えたが決定が増えていない
どの項目をAIが変えたか分からない追跡できる形になっていない
終わった決定を何度も開く情報の優先順位が決まっていない
Notionが別システムを丸写しする隠れた運用システムが生まれている

こういう失敗は大きな音を立てないことが多いです。だから危ない。質の低いNotionエージェント設計は、事故よりも「誰も信じないきれいなページ」を増やします。

私の判断

NotionはAIエージェントのハブになり得ます。ただし魔法の実行ボタンとしてではなく、業務記録として見る場合です。

最初から自律実行を任せる必要はありません。文脈を集め、下書きを作り、根拠を付け、次の担当者へ渡す。まずはそこです。AIに仕事を増やす前に、人が短い時間で確認できる状態を作るほうが先です。

担当者、出所、状態、意思決定ページ、レビュー規則があるNotionなら、エージェントは速度を上げられます。半端なページが積まれたNotionなら、エージェントは整理ではなく複製を速くします。

残すべき文脈はNotionへ。実行は本来のシステムへ。AIには次の動きを準備させる。その動きを人が受け入れるまでは、権限を広げない。私はこの順番で進めます。

よくある質問

NotionはZapier、Make、n8nの代わりになりますか。

私は代替とは考えません。トリガー、分岐、リトライ、システム間の実行には自動化ツールが必要です。Notionはその周辺の文脈、意思決定、引き継ぎを持つ場所として使うほうが合います。

AIエージェントにNotionデータベースを編集させてもよいですか。

最初は避けます。読み取りと下書きから始め、信頼できるようになったら低リスクの項目を一つずつ開けます。変更履歴は必須です。

MCPは必須ですか。

必須ではありません。Notion APIでもページ作成やデータベース参照はできます。外部エージェントがNotionや他のツールと一貫した方法でつながる必要が出たとき、MCPの意味が大きくなります。

最初に試すなら何がよいですか。

プロジェクトデータベースを一つ選びます。担当者抜け、古い決定、止まった項目、根拠リンクを集めて週次レビューの下書きを作らせます。レビュー時間が減り、リスクが隠れないなら次に進めます。

業務フロー

このガイドがつながる業務フロー

読んでいるガイドが、どの業務フローに関係するのかを確認できます。

ツールスタック選定 チームの運用成熟度に合うスタックを選びます。

自動化プラットフォーム、アプリビルダー、エージェントビルダー、会計ツール、汎用AIアシスタントを比較するルートです。

関連トピックを見る
向いている場合
単体ツール購入、社内ワークフロー構築、広いプラットフォーム導入で迷うチーム
向かない場合
判断基準よりも手順書が先に必要な場合は、実装型の記事の方が向いています。
関連ガイド

参照した公開情報

報道内容、公式文書、政策背景、製品情報、変わる可能性のある主張を確認するために参照した公開情報です。

次のステップ

このガイドを運用チェックリストに変える。

まずリソースで業務フローを点検し、現在のプロセスと引き継ぎポイントを整理してからツールを比較します。

ワークフロー 更新を報告