Notion AIマスターコース　Notion Agent、Custom Agents、Workersまで全部解説

どうも おかしん です。

Notion AIの機能が、だいぶ増えてきました。

以前のNotion AIは、ページ上で文章を書いたり、要約したり、翻訳したりする機能として見ることが多かったと思います。いまはそこに、Notion Agent、Enterprise Search、AI Meeting Notes、Custom Agents、Workers、MCP connections、AI Connectors、Notion credits まで入ってきており、初期の頃とは別物です。

このテーマは、シンジが以前書いた企業導入する生成AIの史上最強はNotion AIだと思う安いしの続きとしても読めます。あの記事では、「まずNotionを仕事場にして、その上にNotion AIを乗せる」という考え方が整理されています。本稿では、その前提に立ったうえで、Notion Agent、Custom Agents、Workers、MCP、Creditsまで、実際に試した手順やスクショも交えながら、使い方、使い分け、権限、コスト、管理者が見るべきポイントを整理します。

前提として、この記事は2026年6月11日時点の公開情報と手元確認をもとにしています。Notion AI、Custom Agents、Workersまわりは変更が速いため、料金、対象プラン、beta/alpha表記、UIの表示は変更される可能性があります。最新の情報はNotion公式ヘルプをご確認ください。

長い記事なので、先に読み方を示します。

• Notion AIをまず日常で使いたい人は、基本機能、検索と調査、AI Meeting Notes、Notion Agentまでの前半
• 情シスやSaaS管理者は、Custom Agents以降、特に「コストとCreditsの考え方」と「管理者が見るべき設定」
• コードで拡張したい開発者は、「Workersの使い方とCustom Agents連携」

進め方としては、まず個人のNotion AgentとAI Meeting Notesで試し、次にチームの小さな定型業務でCustom Agentを1つ作り、WorkersやMCPは本当に必要になってから足す、という順番をおすすめします。詳しくはまとめで再掲します。

Notion AIは何ができるようになったのか

まず全体像です。

Notion公式のNotion AIヘルプでは、Notion AIはNotionワークスペースに組み込まれ、知識の検索やタスク完了を支援するものとして説明されており、もはや単なる文章生成機能ではありません。

大きく分けると、Notion AI関連機能は次のレイヤーで見ると分かりやすいです。

この整理で見ると、Notion AIは「AIチャット」ではなく、Notion上の業務データを使って、調べる、書く、判断する、実行するための機能群になっています。

一方で、できることが増えるほど、管理者が見るべき範囲も広がります。AIがページを読むだけなら入力情報の管理が中心です。しかし、AgentやCustom Agentsがページやデータベースを編集し、外部サービスに接続し、Workersを呼び出すようになると、権限、承認、ログ、コスト、停止手順まで含めて考える必要があります。

Notion AI以前に、なぜNotionを社内基盤にするのか

Notion AIの話をすると、そもそもNotionをまだ使っていない組織では「なぜNotionなのか」という話になります。

Notion AIを考えるときに大事なのは、AI単体ではなく、Notionに業務コンテキストが残っているかです。議事録、プロジェクトDB、問い合わせDB、手順書、社内FAQ、意思決定メモがNotionにあるほど、AgentやCustom Agentsは「社内の仕事」を手伝いやすくなります。

この話はNotion AI固有というより、AI時代の業務基盤全体の話です。詳しくは、AI時代の業務基盤は、モデルではなく『AIに渡せる業務コンテキスト』で決まるで整理していますので、そちらをご覧ください。

まずはNotion AIの基本機能を押さえる

最初に、日常利用のNotion AIです。

Notion AIの基本機能は、ページの中で文章を扱う機能です。公式ヘルプでは、テキストを選択したり、ページ上でスペースキーを押したりして、文章の編集、要約、翻訳、表やアウトラインの作成、ブレストなどに使えると説明されています。

たとえば、次のような使い方です。

• 議事録を短く要約する
• 箇条書きを読みやすい文章に直す
• 長い説明を短くする
• 英語のリリースノートを日本語に翻訳する
• ページの内容から表を作る
• ドラフトのトーンを整える

これらは「人間がいま開いているページを読み、文章作業を助ける」機能です。まずはこのあたりから触ると、Notion AIの感覚をつかみやすいと思います。

例えば「平文の文章を構造化して箇条書きにする」などが代表的な利用用途です。

AI blocks

AI blocksは、ページ内にAIで生成されるブロックを置く機能です。公式ヘルプでは、/AI Block から、ページの要約、キーポイント、カスタム出力などを生成できると説明されています。

普通のAIチャットと違い、AI blocksはページ上に残ります。たとえば「このページの決定事項」「今週の更新サマリ」「未解決の論点」のようなブロックを置いておくと、ページを開く人がすぐ状況を把握できます。

ただし、AI blocksは便利なぶん、情報の正しさを固定したものに見せてしまうことがあります。重要な手順、契約条件、セキュリティ判断に使う場合は、AIが作った要約であること、最終確認者が誰か、いつ確認したかを残した方が安全です。

AIブロックの良さは、再利用可能なことです。例えば問い合わせが溜め込まれるDBがあったとして、テンプレートにAIブロックを埋め込んでおけば、そのDBにページが作成されるたびに「考えられる原因」や「問い合わせ内容のまとめ」がボタン一発で自動生成される状態を作ることができます

データベースとAI Autofill

Notion AIはデータベースでも使えます。公式ヘルプでは、データベース作成、プロパティ作成、Autofillによるプロパティ入力、数式の作成や編集にも触れられています。

実務では、ここがかなり使いやすいところです。

たとえば、問い合わせ管理DBに「分類」「緊急度」「要約」「次のアクション」のようなプロパティを作り、AIに補助させることができます。営業メモなら「顧客課題」「競合」「次回確認事項」、採用メモなら「候補者の強み」「懸念」「次アクション」のように整理できます。

ただし、AI Autofillはあくまで補助です。分類や要約をそのまま業務判断に使うと、間違いが紛れます。人間がレビューするプロパティと、自動で参考情報として使うプロパティを分けるのが現実的です。

画像生成

Notion AIには画像生成・編集もあります。公式ヘルプでは、Business / Enterprise プランで利用可能で、ワークスペースオーナーや管理者が有効化を制御できると説明されています。また、beta中の制限として、ユーザーごとに24時間あたり10回、30日あたり30回の画像生成または編集という上限が示されています。

ブログ記事や社内資料では、簡単な図解や概念メモを作るのに向いています。Notion上でのワークショップ資料や補助図として使いやすい機能です。

検索と調査を強くする

Notion AIの強さは、Notion内のページだけでなく、接続した外部アプリやWebも含めて検索・調査できるところです。

公式ヘルプでは、Enterprise SearchはNotionワークスペース内のアクセス可能なページ、Notion AI Connectorsで接続したSlackやGoogle Driveなどのアプリ、Web情報を使って回答できると説明されています。

Gleanとの違いや、Notion AI Connectorsをエンタープライズサーチとしてどう見るかは、弊社ブログの現代的なエンタープライズサーチはGleanかNotionの2択、で、どっちがいいか決着をつけたでも整理されています。この記事では製品比較そのものではなく、Notion AI側の機能としてEnterprise SearchとAI Connectorsをどう扱うかに絞ります。

ここは、普通の検索とかなり違います。

検索窓にキーワードを入れてリンク一覧を見るのではなく、「このプロジェクトの最新状況は」「この問い合わせが増えている理由は」「このプロジェクトで参加者がつまずきそうなところは」のような問いで使えます。

AI Connectors

Notion AI Connectorsは、外部アプリの情報をNotion AIから検索・参照できるようにする仕組みです。公式ヘルプのナビゲーション上でも、GitHub、Google Drive、Linear、Jira、Microsoft Teams、SharePoint、OneDrive、Slack、Box、Asana、Salesforce、Notion Mail、Notion Calendar、Outlook、Google Calendar、Gmailなどが並んでいます。

ただし、Connectorsを増やすほど便利になる一方で、検索対象が広がります。管理者は次を確認した方がよいです。

• どのアプリを接続しているか
• 誰が接続できるか
• 読み取りだけか、書き込みもあるか
• 個人メールや個人カレンダーが対象になるか
• 退職者、異動者、ゲストの権限がどう扱われるか
• AIが回答に使った根拠を追えるか

検索系のAIは、利用者から見ると「便利な社内検索」です。しかし管理者から見ると、アクセス権とデータ分類の設計です。

AI Meeting Notesを使う

AI Meeting Notesも、Notion AI関連で外せない機能です。

AI Meeting Notes公式ヘルプでは、会議を文字起こしし、要約やインサイトを引き出す機能として説明されています。Notion AIから検索できる会議メモとして残るので、会議が多いチームではかなり便利です。

メモタブの使い方

実際に使うときに大事なのは、メモタブの使い方です。AI Meeting Notesは会議の文字起こしや要約を作れますが、最後に実務で使える議事録へまとめるには、人間が会議中に残したメモがかなり効きます。

たとえば、決定事項、未決事項、補足背景、参加者の温度感、次回までに確認することをメモタブへ書いておくと、最後の要約が単なる発話の圧縮ではなく、会議後に使える議事録に近づきます。AIに全部任せるというより、会議中の人間のメモをAIが整理し直す、という使い方の方が強いです。

使いどころ

使いどころは分かりやすいです。

• 定例会議の要約
• 決定事項の抽出
• アクションアイテム化
• 欠席者向けの共有
• 次回会議の論点整理

導入前に決めるルール

一方で、会議メモは機密情報の塊です。顧客名、契約条件、採用、評価、インシデント、法務相談、経営判断が含まれることがあります。AI Meeting Notesを有効にする前に、少なくとも次を決めた方がよいです。

• どの会議で使ってよいか
• 参加者への通知や同意をどう扱うか
• 文字起こしや音声の保存設定をどうするか
• 誰が会議メモを閲覧できるか
• 外部参加者がいる会議で使ってよいか
• 議事録をAIが要約した後、誰が確定版にするか

便利さだけで見ると、AI Meeting Notesはすぐ使いたくなります。ただ、組織で使うなら「録音・文字起こし・要約・共有」のルールを先に決める方が安全です。

Notion Agentの使い方

次にNotion Agentです。

ここで扱うNotion Agentは、後続で説明するCustom Agentsとは別物です。Custom Agentsがチームで共有し、トリガーやTools and accessを持たせて動かすエージェントだとすると、Notion Agentは各ユーザーが普段使う個人側のAgentです。

Notion Agent公式ヘルプでは、Notion AgentはNotion内のAIチームメイトとして説明されています。ページやデータベースを作成・編集し、ワークスペースや接続アプリの文脈を使って複数ステップの作業を扱えます。

Notion Agentは、ワークスペースや接続アプリの情報を使って、ページ作成、編集、データベース作成、データ分析などを手伝えます。ただし、ユーザーと同じ権限で動くため、ユーザーが見られないページはAgentも見られません。

Notion Agentでできること

実務で使いやすいのは、次のような作業です。

最初に試すなら、「Notion Agentにサンプルページを読ませ、章立て、ToDo、確認事項を作らせる」くらいが良いと思います。操作結果が分かりやすく、社内情報の写り込みも制御しやすいからです。

モデル選択は会話開始前に決める

Notion Agentでは、会話を始める時にも会話の途中にも、使うモデルを選択できます（2026年6月9日時点。以前は会話の途中で切り替えられない時期もありました）。ただし、これは私の実感ですが、会話中のモデルの切り替えがプラスの結果をもたらすことはほぼありません。特に公式に説明がされているわけではありませんが、会話途中のモデルの切り替えはパフォーマンスが下がることがあります。

デフォルトは Auto ですが、Auto で始めた場合に裏でどのモデルが使われているかは基本的には分かりません。複雑な調査、長文整理、ページやDBをまたぐ作業では、会話を始める前に GPT-5.5 か Opus 4.8 へ切り替えるのが大事です。忘れて Auto で始めてしまったら、新しい会話でモデルを選び直すくらいでよいと思います。

モデル選択は「性能の切り替え」だけではありません。公式ヘルプでも、選んだモデルによってはワークスペースや接続アプリの情報を参照できない場合があると説明されています。実際にあった例としてはAutoモデルでは先ほど紹介したAI Meeting Notesの文字起こしセクションにアクセスできないといったことがありました。

また、選択肢に並ぶモデル自体も変わります。たとえば2026年6月9日に追加されたClaude Fable 5は、管理者が有効化しないと選択肢に表示されないオプトイン方式です。背景にあるデータ保持の扱いは、後述の「管理者が見るべき設定」で説明します。

UIは変わりやすいので、実際に使うときは画面上の表示名を確認してください。

コンテキスト注入

Notion AIのチャット画面には、全ての要素が「ブロック」という単位で扱われるNotionならではのコンテキスト注入体験があります。

チャット画面の文字入力フィールドの上部には、今この会話において明示的にコンテキストとして扱われている範囲がどこなのかが表示されます。

例えば特定の見出しをクリックしたり、テキストを選択状態にすることで、ここの状態が変わります。

また、Notionには @ によって、特定のページをメンションすることが出来ますが、それがこのチャット画面上でも可能です。@メンションされたページはどんどんコンテキストに追加されていきます。

私はこの機能は、Notionのブロック構造を活かした、他のAIツールには無い体験だと感じています。

Plan Mode

Notion Agentを実務で使うなら、Plan Modeはかなり重要です。

Notionの説明では、Agentが実行前に変更内容をレビュー・承認できるようにする設定として扱われています。AIにページやDBを編集させる場合、いきなり実行させるより、まず計画を出させて人間が確認する方が安全です。

私は、最初の導入では「読む、要約する、下書きする」は比較的自由に使い、「DB更新、ページ作成、外部送信、メール送信」は承認を挟む、くらいの線引きから始めるのがよいと思います。

InstructionsとSkills

Notion Agentには、InstructionsとSkillsがあります。

Instructionsは、Agentに「どう振る舞ってほしいか」「何を優先してほしいか」を伝えるためのものです。Instructions for Notion Agentでは、InstructionsはNotion Agentに常時適用されるデフォルト設定のようなものとして説明されています。

イメージとしては、ChatGPTの個人設定、Claudeのカスタム指示、開発環境に置く AGENTS.md や CLAUDE.md に近いです。Notionの場合は、それをNotionページとして保存し、用途ごとに複数作って切り替えられます。問い合わせ対応用、議事録整理用、SaaS導入相談レビュー用のInstructionsを作っておくと、同じNotion Agentでも作業に合わせて振る舞いを変えられます。

この切り替えの軽さは、Notion AIならではの強みだと思います。ChatGPTやClaudeにも個人設定やプロジェクト設定はありますし、CodexやClaude Codeにも AGENTS.md や CLAUDE.md のような仕組みはあります。ただ、Notionのように設定そのものをページやDBで管理し、用途別に並べて、必要なときに選び直す体験はかなりスムーズです。これは、Notionというアプリケーションの強みがそのままAIに乗っている部分です。

Skills for Notion Agentでは、Skillsは必要なときに実行できる保存済みプロンプトとして説明されています。重要なのは、InstructionsもSkillsもNotionページとして扱えることです。つまり、普通のNotionページやデータベースと同じように、一覧化し、共有し、権限を付け、レビュー日を持たせられます。

さらに便利なのは、Instructionsの中で「この作業ではこのSkillを使う」と指定できることです。たとえば、問い合わせ対応用のInstructionsに、分類用Skill、返信案作成Skill、FAQ更新候補作成Skillを使うように書いておくと、個人のNotion Agentでも業務ごとの型をかなり揃えやすくなります。

たとえば、業務利用の型として次のようなInstructionsを作れます。

あなたは情シス問い合わせ対応を支援するアシスタントです。
回答では、まず問い合わせの分類、緊急度、確認すべき追加情報を分けてください。
次に、利用者へ返す返信案と、情シス担当者向けのNext Actionを作成してください。
社内ルールが不足している場合は、推測で断定せず「確認が必要」と明記してください。

この作業では、必要に応じて次のSkillsを使ってください。
- 問い合わせ分類Skill
- 返信案作成Skill
- FAQ更新候補作成Skill

これをNotion DBで管理すると、かなり便利です。Type を Instructions / Skill で分け、Use case、Owner、Status、Last reviewed を持たせておけば、チーム内で「どの業務ではどのInstructionsとSkillsを使うか」を配布しやすくなります。

ここで注意したいのは、ページ自体の編集権限です。公式ヘルプでも、他の人がInstructionsページやSkillページを編集できる場合、その変更がAgentの応答やSkillの動作に影響すると説明されています。チームで使うものは、誰が編集できるかを決めておくべきです。

実践1: 標準エージェントの設定をページとして配布する

普通のチャット機能だけを詳しく説明しても、Notion AIらしさは伝わりにくいです。最初に見せたいのは、Notion AgentのInstructionsとSkillsをNotionページとして管理し、作業ごとに切り替えられることです。

なお、本稿の実践1〜3は、情シス問い合わせ対応という1つの業務に絞って進めます。SaaS導入相談レビューやFAQ更新も本文の例として登場しますが、同じ型で作れるため、実践としては扱いません。

Instructions for Notion Agentでは、Instructionsは個人用Notion Agentの応答方針、トーン、フォーマット、守るべきルールを指定するものとして説明されています。既存ページをInstructionsとして使うこともできます。

ここで重要なのは、Instructionsは「配布しやすい」が、「共有しただけで他の人のAgent設定が自動で変わるわけではない」ことです。公式ヘルプでは、利用できるActive Instructions pageは1つで、複数のInstructionsページを作成し、必要に応じて切り替えられると説明されています。

設定集DBを作る

実践では、まずNotion内に「エージェント設定集」DBを作ります。InstructionsページとSkillページを同じDBで管理しておくと、どの業務で何を使うかを一覧しやすくなります。

Instructionsページを作る

次に、問い合わせ対応用のInstructionsページを作ります。

目的:
情シス問い合わせを分類し、利用者への返信案と担当者向けNext Actionを作る。

前提:
- 社内ルールが不明な場合は断定しない
- セキュリティ、契約、費用に関わる判断は人間確認を必須にする
- 回答は「分類」「緊急度」「不足情報」「返信案」「Next Action」に分ける

出力形式:
1. 分類
2. 緊急度
3. 不足情報
4. 利用者への返信案
5. 担当者向けNext Action

使うSkills:
- 問い合わせ分類Skill
- 返信案作成Skill
- FAQ更新候補作成Skill

Notion Agentに設定する

最後に、そのページをNotion AgentのInstructionsとして設定します。公式ヘルプでは、ページのメニューから Use with AI → Use as AI Instruction を選べると説明されています。別のInstructionsに切り替える場合も、対象ページから Set as Notion AI Instructions を選びます。日本語の場合はページのメニューから AIで使用 → AIの指示として使用 です。

他にも方法はあります。Notion画面右下のNotionAIチャット画面からアイコンをクリックし、既存のページを使用する を選択することでInstructionsに設定できます

Skillを設定する

Skillページは、同じように対象ページのメニューから Use with AI → Use as AI Skill で設定します。

一度スキルとして設定してしまえば、これまで紹介した様々なNotion AIの機能の中で @ で呼び出すことが出来るほか、右クリックメニューなどから呼び出すことができます。

Instructionsを設定し、関連するSkillsも用意しておくと、AI活用に慣れている人が設計した型を、チームの他メンバーが再利用できます。各自がゼロからプロンプトを考えなくても、問い合わせ対応、議事録整理、FAQ更新、SaaS導入相談レビューのような業務ごとに、一定の品質でNotion Agentを使い始められます。

Custom Agentsの使い方

ここからが、Notion AIを業務自動化として見るうえで大きいところです。

Custom Agents公式ヘルプでは、Custom Agentsはチームの繰り返し業務を自動化する共有ワークフローとして説明されています。

公式情報では、Custom AgentsはNotionページやデータベース、特定の接続アプリを読み、スケジュールやワークスペースイベントで実行され、レポート投稿、バグ起票、レコード更新、メッセージ送信などのアクションを取れると説明されています。また、Notion Agentと違い、トリガーやスケジュールに基づいてバックグラウンド実行する設計であることも明記されています。

カスタムエージェント単体の料金、権限、運用設計は、弊社ブログのNotion AIカスタムエージェントとは？情シスが知るべき料金・権限・運用設計【2026年6月最新】でも詳しく整理されています。本稿では、その内容を含めて、Notion Agent、Custom Agents、Workers、MCPまでをNotion AI全体の流れとして接続します。

Notion Agentとの違いを整理すると、次の通りです。

Custom Agentを作るときの考え方

Custom Agentは、AIだからといって最初から大きな業務を任せない方がよいです。最初は、次のように小さく作るのが現実的です。

1. 対象業務を1つに絞る
2. 入力元を1つか2つに絞る
3. 出力先を1つに決める
4. 書き込み操作を最小限にする
5. 最初は人間確認を入れる
6. Activity logで実行結果を見る
7. コストと実行頻度を見て広げる

たとえば最初の例なら、「問い合わせ管理DBを読み、分類、返信案、Next Actionを作る」くらいがよいです。対象DBが明確で、出力先も1ページにできます。公開記事用のスクショも、サンプルデータだけで撮れます。

実践2: 問い合わせ対応Custom Agentを作る

標準のNotion AgentとInstructionsは、利用者がその場で呼び出して使うものです。次に、同じ問い合わせ対応をCustom Agent化します。

AI Autofillとの違い

ここで、前半のAI Autofillを思い出した方もいると思います。分類や緊急度をAIで埋めるだけなら、Autofillでもできます。それでもここでCustom Agentを使うのは、次の差があるからです。

• Autofillはプロパティ単位の補完で、参照できる文脈も限られます。Custom Agentは、情シスFAQと問い合わせ対応ルールという複数のページを根拠として読み、分類、緊急度、返信案、Next Actionを一貫した判断で作れます
• Autofillの出力はプロパティ値だけです。Custom Agentは、コメント、ページ作成、通知のような、プロパティ以外のアクションを取れます
• Custom AgentはトリガーやRecurringでバックグラウンド実行され、Agent単位でアクセス範囲、実行ログ、コストを管理できます

この差をデモとして見せるため、本稿のCustom Agentには「プロパティを埋める」だけでなく、「緊急度を高と判定したら担当者へエスカレーションコメントを残す」という、Autofillにはできないアクションを1つ持たせます。

サンプルDBを用意する

ここでは、サンプルのNotion DBを3つ用意します。

問い合わせ管理DBには、最初は次のプロパティを置きます。

Instructionsを書く

Custom AgentのInstructionsには、標準Agentで作った問い合わせ対応Instructionsをそのまま転用せず、バックグラウンド実行を前提に書き直します。

あなたは情シス問い合わせ対応のCustom Agentです。
問い合わせ管理DBのNewまたはReviewingの項目を読み、情シスFAQと問い合わせ対応ルールを参照して、分類、緊急度、不足情報、返信案、Next Actionを作成し、該当ページの各プロパティに書き込んでください。
緊急度を高と判定した場合は、該当ページに判断根拠とエスカレーション先をまとめたコメントを残し、情シス担当者へメンションしてください。

制約:
- 情シスFAQまたは問い合わせ対応ルールに根拠がない内容は断定しない
- セキュリティ、契約、費用、アカウント権限変更は人間確認を必須にする
- 利用者へ送信する文面は返信案として作るだけで、自動送信しない
- コメントとメンションは社内のエスカレーション用途に限り、利用者への連絡には使わない

標準Agent版との違いは、3行目のエスカレーションコメントです。プロパティを埋めるだけならAutofillでも近いことができますが、ページへのコメントとメンションは、Custom Agentに明示的なアクションとして持たせる部分です。

Tools and accessを設定する

Tools and accessでは、問い合わせ管理DB、情シスFAQ、問い合わせ対応ルールだけを明示的に追加します。Instructions本文にページリンクを書いただけでは、Custom Agentのアクセス権限にはなりません。ここを分けて理解するのが重要です。

もう1つ、Web accessは意図的にオフのままにしています。SaaSの一般的なエラーならWebで調べさせた方が早いのでは、と思うかもしれません。ただ、このAgentは「FAQまたは問い合わせ対応ルールに根拠がない内容は断定しない」という制約を持ち、FAQに無い問い合わせは不足情報として人間に返す設計です。Webアクセスを足すだけだと、この制約と矛盾します。一次対応を楽にする目的でWebも調べさせたいなら、「Web調査の結果は出典付きの参考情報としてNext Actionに添え、返信案の根拠には使わない」のように制約ごと書き直せば成立します。権限はInstructionsの設計とセットで変える、というのがここでのポイントです。

Triggerを決める

Triggerは、最初から複雑にしません。まずは問い合わせ管理DBにページが追加されたとき、または毎日1回のRecurringで動かすくらいにします。新規問い合わせは Status = New で入ってくるため、プロパティ更新ではなくページ作成をトリガーにすれば十分で、1件につき1回だけ動く分かりやすい挙動になります。いきなり自動送信や外部書き込みまで広げるのではなく、返信案とNext Actionを作り、人間が確認するところから始めます。

発展: Slackと問い合わせ管理をシームレスにつなぐ

ここまでの実践2は、問い合わせが問い合わせ管理DBに入るところから始めました。ただ、実際の問い合わせの入口はSlackであることが多いはずです。Custom AgentsはSlackのメッセージやリアクションをトリガーにでき、Slackへのメッセージ送信もアクションとして持てるため、同じ構成を次のように発展させられます。

1. Slackの問い合わせチャンネルへの投稿をトリガーにする
2. Custom Agentが問い合わせ管理DBにページを起票する
3. そのまま情シスFAQと問い合わせ対応ルールを読み、分類、緊急度、返信案、Next Actionを埋める
4. 起票したNotionページのリンクをSlack側へ返し、Notion側にも元のSlackメッセージへのリンクを残す

この構成の狙いは、Slack上のフローなコミュニケーションと、Notion上のストックなチケット管理を双方向につなぐことです。Slackから見れば、問い合わせを投げるだけでチケットのURLが返ってきます。Notionのチケットから見れば、元のSlackスレッドへ戻って会話の文脈を確認できます。「Slackで聞いたきり流れて、Notionに起票されない」という分断を、人間の転記作業なしで埋める形です。

Webの情報も使って回答させたい場合は、先ほど書いたとおり、Web accessの権限とInstructionsの制約をセットで書き直します。また、この発展型ではAgentの出力先がNotionの外へ広がるため、誤投稿したときの影響範囲と停止手順を決めてから動かすべきです。

Triggers

Custom Agentsのトリガーには、Recurring、Notion triggers、Slack triggersがあります。公式ヘルプでは、毎日・毎週・毎月などのスケジュール実行、ページ作成、DBプロパティ更新、コメント追加、Slackメッセージやリアクションなどが例示されています。

トリガー設計では、頻度と条件が肝です。

毎分動くエージェントは、便利そうに見えてコストとノイズを増やします。まずは毎日1回、または特定のステータスに変わったときだけ動かすくらいから始める方が扱いやすいです。

Tools and access

Custom Agentsでは、Tools and accessで何を読めるか、何に接続できるかを設定します。公式ヘルプによると、Agentは明示的にアクセスを与えたコンテンツだけを使います。

ここは管理上の最重要ポイントです。InstructionsにページURLを書いても、それだけでTools and accessに追加されるわけではありません。逆に、Tools and accessで広く権限を与えすぎると、Agentが想定より広い情報を参照できるようになります。

Custom Agentは、Notionページやデータベース、Web access、Slack、Mail、Calendarなどのconnected apps、MCP connectionsをTools and accessで持てます。ただし、Custom Agent単体が任意の外部APIを直接fetchして、APIキーやOAuthをコードで扱うわけではありません。外部サービスを使わせたい場合は、基本的にはNotion側のnative connected appsかMCP connectionsとしてAgentに渡します。

私なら、最初は次の原則で設計します。

• Agentごとに目的を1つにする
• 対象ページやDBを明示的に指定する
• Pages shared with everyone in Notion のような広い範囲は慎重に使う
• Web accessは必要なAgentだけONにする
• 書き込みできる外部接続は最初は避ける
• 実行ログを見てから範囲を広げる

ここまでを設定しておけば、Custom Agentがどの業務のために、どこまで読めて、何を実行できるかを説明しやすくなります。

MCPは「どちら向きの接続か」で整理する

MCPまわりは、同じ「MCP」という言葉が逆向きの2つの文脈で使われるため、混乱しやすいところです。

• MCP connectionsは、Custom Agentから外部MCPサーバーを呼ぶための接続です。外部ツールをAgentの道具として持たせる、Notionから外への向きです
• Notion MCPは、Claude CodeやChatGPTのような外部AIツールからNotionを読み書きするための仕組みです。外からNotionへの向きです

外部ツールをAgentに持たせたいならMCP connections、外部AIからNotionを扱いたいならNotion MCP、社内APIやREST APIをコードで扱いたいなら後述のWorkers、と分けると理解しやすいです。

Workersの使い方とCustom Agents連携

Notion Workersは、Custom Agentsとは別物です。

Notion Workers公式ドキュメントでは、WorkersはNotionを拡張する小さなNode/TypeScriptプログラムとして説明されています。Notion CLIでデプロイし、Notion側でホスト・実行されます。用途としては、外部データの同期、Custom Agentsが呼べるツール、外部サービスからのWebhook受信が挙げられています。

ここで重要なのは、WorkersをAWS LambdaやGitHub Actionsの汎用的な代替として見ないことです。単なる定期バッチ、CI、GitHub起点の処理なら、GitHub ActionsやLambdaで十分なことが多いです。

Workersの強みは、Notion AI / Custom Agentの作業文脈の中に、コード実行を自然に置けることです。

Custom Agentは、Notion内のページ、データベース、社内ルール、過去事例を読んで判断します。一方で、Workerは決まった計算、検証、外部API呼び出し、Webhook処理、同期処理を実行します。つまり、Custom Agentは「Notion上の業務コンテキストを読む側」、Workerは「その文脈の中で必要な確定処理を実行する側」です。

たとえば、Notion DBにSaaS導入相談や社内問い合わせが入ってきたとします。Custom Agentは、Notion内にある社内ルール、過去の相談、FAQ、チェックリストを読んで、分類やNext Actionを考えます。そのうえで、Worker toolを呼び、想定費用の計算、必須項目の検証、外部サービス上の情報確認、チケット作成などを実行できます。

この構成が良いのは、業務コンテキストをNotionの外へ持ち出して、別途RAG基盤を作らなくてもよいことです。外部から同じことをやろうとすると、Notion APIでページを取得し、検索や権限や更新を考慮し、Azure OpenAI、Amazon Bedrock、OpenAI、AnthropicなどのAPIで推論し、最後にまたNotion APIで結果を書き戻す構成になります。作れますが、Notion内の業務文脈を扱うために、Notionの外側にもう一つAI基盤を作ることになります。

Notion AI / Custom Agentを使う場合は、Notion内の探索と判断をNotion AI側に任せられます。Workersはそこに、AIに任せたくない確定処理を足す部品として使えます。

外部API連携とタイムアウトを分けて考える

Workersで大きいのは、外部APIを叩けることです。公式ドキュメントにも、Workersは外部APIへのHTTPリクエスト、CLIで保存したsecrets、OAuth認証を使えると明記されています。つまり、Custom Agent側ではnative connected appsやMCP connectionsとして渡していた外部サービス連携を、Worker toolやsyncとしてコードで補えます。

たとえば、Custom AgentがNotion内の問い合わせ内容と社内ルールを読み、Workerが外部APIでSaaS台帳、契約情報、チケット情報、ステータスを確認する、という分担ができます。MCPサーバーが用意されていない社内APIや、単純なREST APIしかないサービスでも、Workersならコードでつなげられます。

ただし、外部APIが叩けるからといって、長い処理を1回のWorker runに詰め込む設計は避けた方がよいです。本稿確認時点の公開ドキュメントでは、Notion Workersの最大実行時間を示す具体的な数値は確認できません。

一方で、公式ドキュメントを見ると、Workersは長い処理を分割する前提で設計されています。Syncsでは、hasMoreとnextStateを返すことでruntimeが次のexecuteを呼び、数百件を超える同期はbatchに分けることが説明されています。大量データはdelta syncとbackfill syncを分け、外部APIにはpacerを使ってレート制限を避けます。Webhooksでは、NotionがHTTPリクエストに202 Acceptedを返した後にWorkerを非同期実行し、通常のエラーでは最大3回retryするとされています。

比較として、AWS Lambdaのtimeoutは最大900秒（15分）、GitHub Actionsのtimeout-minutesにもステップやジョブの上限があります。実行基盤を問わず、外部API連携を「時間内に終わる前提」で設計すると破綻しやすい、ということです。

Custom Agentから呼ぶWorker toolは、数秒から短時間で返せる「確認、計算、作成、更新」に絞る。重い同期や再集計は、Agentとの対話中に直接やらせず、syncやWebhook側へ逃がす。Webhookは外部サービス側のイベントIDで冪等性を持たせる。この分け方をしておくと、タイムアウト、リトライ、レート制限、二重実行に強くなります。

この観点では、Workersは「外部APIを自由に叩ける魔法の箱」ではなく、Notion AIの近くに置ける小さな実行部品です。長い処理は分割、再実行、冪等性で壊れにくくする。この設計まで含めて、Workersを使う価値があります。

Workers連携の代表パターン

WorkersとCustom Agentの連携は、きれいに2分類できるものではありません。トリガー、外部API、書き込み先、Agentに任せる判断の範囲によって、いろいろな形があります。

ただ、記事や勉強会で最初に見せるなら、次の2つはイメージしやすいです。違いは、「人間の判断や返答を助ける」のか、「Notion内の業務コンテキストを更新・保守する」のかです。

1つ目は、相談・申請のトリアージです。

NotionフォームやNotion DBに相談、申請、問い合わせが入ってきたときに、Custom AgentがNotion内の社内ルール、過去事例、FAQ、チェックリストを読み、分類、一次回答、Next Actionを作ります。Workerは、費用計算、必須項目チェック、外部サービス確認、チケット作成のような確定処理を担当します。出力は、担当者が次に判断しやすくなるための材料です。

2つ目は、業務コンテキストの更新・保守です。

AI Meeting Notes、Slack、外部SaaS、Notion DB更新などをきっかけに、Custom AgentがNotion内の台帳、タスク、FAQ、手順書を更新します。この場合、AIの役割は「返答すること」ではなく、古くなりやすい業務コンテキストを保守することです。

たとえば、AI Meeting Notesが作られたら、Custom Agentが決定事項やアクションアイテムを読み、プロジェクトDBやタスクDBを更新します。Slack上で障害対応の進捗が出たら、インシデントページの時系列や対応ステータスを更新します。SaaS導入相談が承認済みになったら、SaaS台帳、契約更新予定、運用手順ページを更新します。

Workersは、この更新処理の中で、AIに任せるべきではない部分を担います。たとえば、申請番号の採番、期限計算、ステータス更新、外部APIの結果取得、Webhookで受けたイベントの正規化、Notion DBへの書き込みなどです。

実装パターンとしては、Notion DBの更新やSlackイベントをきっかけにCustom Agentを動かし、必要に応じてWorker toolを呼ぶ形が考えられます。外部SaaSのWebhookを起点にする場合は、WorkerがWebhookを受け、まずNotion DBへイベントとして記録し、そのDB更新をCustom Agent側の処理につなげる構成にすると説明しやすいです。

この2つは網羅的な分類ではありません。ただ、ハンズオンでは「問い合わせをさばく」と「Notion内の情報を更新する」を並べると、Custom AgentとWorkersの分担が見えやすくなります。

実践3: Workersで問い合わせ対応を発展させる

最後に、問い合わせ対応Custom AgentへWorkersを足すと何が変わるかを見ます。

ここで使うのはCloudflare WorkersやAWS Lambdaではなく、Notion Workersです。Cloudflare WorkersやLambdaでも外部実行基盤は作れますが、本稿で見たいのは「Notion AI / Custom Agentの作業文脈から呼べる実行部品」としてのWorkersです。

Workerに切り出す処理

まず準備として、実践2の問い合わせ管理DBに日付プロパティ「対応期限」を1つ追加します。実践2の時点では人間が確認しながら使う前提だったので不要でしたが、実践3では分類と緊急度から対応期限を機械的に計算し、Workerに書き込ませるためです。

また、ここでは問い合わせはNotionフォーム経由で問い合わせ管理DBに入る前提とし、影響範囲、発生日時、利用端末をフォームの入力項目とします。checkRequiredFields が確認する「必須項目」は、この3つを指します。

そのうえで、Custom Agentにすべてを判断させるのではなく、次の処理をWorkerへ切り出します。なお、Custom Agentが呼び出すtoolと、外部サービスからのイベントを受けるWebhookハンドラは、Workerの中でも別の仕組みです。表の normalizeEvent だけはtoolではなくWebhookハンドラで、後述の「外部Webhookを扱う場合」で使います。

calculateSlaを実装する

実装イメージを1つだけ示します。calculateSla をtoolとして登録するコードです。

import { Worker } from "@notionhq/workers";
import { j } from "@notionhq/workers/schema-builder";

const worker = new Worker();
export default worker;

worker.tool("calculateSla", {
	title: "Calculate SLA",
	description:
		"問い合わせの分類と緊急度から対応期限を計算する。問い合わせのトリアージ時に使う。",
	schema: j.object({
		category: j.string().describe("問い合わせの分類。"),
		urgency: j.enum("高", "中", "低").describe("問い合わせの緊急度。"),
	}),
	hints: { readOnlyHint: true },
	execute: async ({ category, urgency }) => {
		const hours = urgency === "高" ? 4 : urgency === "中" ? 24 : 72;
		const dueDate = new Date(Date.now() + hours * 60 * 60 * 1000);
		return { category, urgency, dueDate: dueDate.toISOString() };
	},
});

書き方は公式のagent toolガイドに沿っています。j スキーマビルダーで入力を定義し、description には何をするtoolで、いつ使うべきかを書きます。hints: { readOnlyHint: true } は読み取り専用の宣言です。ガイド上の記載では、このhintのないtoolは書き込みtoolとして扱われ、デフォルトではCustom Agentが実行前にユーザーの許可を求めるとされています。つまり、calculateSla のような計算系は読み取り専用として自動実行を許し、updateTicketStatus のような書き込み系はhintを付けずに確認を挟む、という分け方が、そのまま実践2の線引きをコードへ持ち込む形になります。

デプロイ前には、ローカルで動きを確認できます。

ntn workers exec calculateSla --local -d '{"category":"アカウント","urgency":"高"}'
ntn workers deploy

デプロイ後、AgentのTools and accessにこのtoolを追加すれば、Custom Agentから呼べるようになります。残りのtoolにも触れておくと、lookupDeviceAssignment のように外部APIを呼ぶtoolでは、認証情報をworker secretsとして保存し、execute の中で process.env から読みます。GitHubやGoogleのようにユーザー認可が必要なAPIにはOAuthを使う、というのがガイド上の整理です。先ほどの「外部API連携とタイムアウトを分けて考える」で書いたとおり、tool内の外部API呼び出しは短時間で返せる確認に絞ります。また、updateTicketStatus のように既存ページを更新するtoolでは、execute の第2引数で渡されるNotion API clientを使います。これは次の節で説明します。

実行の流れ

実行の流れはこうです。

flowchart TD
	A["問い合わせ管理DBに新しい問い合わせが入る（Notionフォーム経由）"] --> B["Custom AgentがFAQと対応ルールを読む"]
	B --> C["checkRequiredFieldsで必須項目を、lookupDeviceAssignmentで端末の貸与状況を、calculateSlaで対応期限を確認する"]
	C --> D["Custom Agentが分類、返信案、Next Actionを作る"]
	D --> E["updateTicketStatusがStatusをNewからReviewingへ進め、対応期限を書き込む"]

この形にすると、AgentとWorkerの分担がひと目で分かります。自動で書き込むのは、NewからReviewingへの遷移と対応期限だけです。WaitingやDoneへの遷移、利用者への返信は人間が行います。実践2で決めた「返信案は作るだけで自動送信しない」という線引きは、Workersを足した後も変えません。問い合わせ対応を例にすると、標準AgentのInstructions、Custom Agent、Workersの違いを段階的に説明できます。

外部Webhookを扱う場合

外部Webhookを扱う場合は、Workerが外部イベントを受け、normalizeEvent で日時やIDの形式を整えたうえで、まずNotion DBへイベントとして記録します。たとえば、資産管理SaaSの貸与状況変更や、チケットツールのステータス変更がきっかけになります。その後、Custom AgentがそのDB更新を見て、Notion内のFAQ、ルール、過去事例をもとに、何を更新すべきか判断します。これは単なる外部データ同期ではなく、Notion内の業務コンテキストを保守する流れです。

WorkersはNotionを直接いじる特権SDKではない

ただし、Workersを使えばNotion内部を特権的に直接操作できる、というわけではありません。

Using Notion API from a workerでは、各capabilityのexecute関数にcontext.notionとしてNotion API clientが渡されると説明されています。これは公式の@notionhq/client SDKです。既存ページや既存DBを更新する場合は、基本的にはこのNotion API clientを使います。

execute: async (input, { notion }) => {
  await notion.pages.update({
    page_id: input.pageId,
    properties: {
      Status: { select: { name: "Done" } },
    },
  });
}

大きいのは、Custom Agentから呼ばれるtoolの場合、Notion API clientがCustom Agentと同じ権限で動くことです。Workerが独自に全権限を持つのではなく、Agentに与えたアクセス範囲の中でNotionを扱います。

Sync用途では、もう少しWorkersらしい仕組みがあります。Syncs公式ガイドでは、worker.database()でWorker管理DBを宣言し、worker.sync()がupsertやdeleteのchangesを返すことで、Notion側がDB作成、スケジュール実行、状態管理を担う仕組みが説明されています。ただし、2026年6月時点のドキュメントでは、syncはWorker管理DBを対象としており、既存DBへのsyncはcoming soonとされています。

LambdaやGitHub Actionsと何が違うのか

Workersのメリットを、外部実行基盤と比べると次のようになります。

逆に、GitHubのCI、単なる定期実行、重いバックエンド処理、Notionと関係の薄いジョブをWorkersでやる必要は薄いです。Workersの価値は、実行基盤として何でもできることではなく、Notion AIの近くにあることです。

たとえば、次のように分けられます。

Workersがあると、Custom Agentsの使い道が広がります。外部APIを呼ぶ、決まった計算をする、Webhookを受ける、Notion DBへ同期する、といった処理をWorker側へ切り出せるからです。

ただし、Workersは開発者向けの機能です。コード、CLI、Secrets、OAuth、外部API、エラー処理、実行ログを扱います。Notionを普段使っている人がすぐ触るというより、情シス、BizOps、開発者、AIコーディングエージェントを使える人が組み合わせる領域です。

コストとCreditsの考え方

Notion AIの記事で、コストは避けて通れません。

特にCustom AgentsとWorkersは、通常のNotion AI機能とは分けて見た方がよいです。

Custom Agentsの料金ヘルプによると、Notion creditsはBusiness / Enterprise プランで利用できるrecurring add-onです。Custom Agentsはタスクを実行するたびにcreditsを使い、複雑なタスクほど多くのcreditsを使う傾向があります。

公式情報では、Notion creditsは月額10ドルで1,000 credits、ワークスペース単位で共有、月次リセットで、未使用分は翌月に繰り越されません。管理者はNotion credits dashboardから購入・利用状況確認ができます。

また、Custom Agentsの課金は、2026年5月4日以降の次のmonthly service dateからbillingとcredit usageが始まるとされています。

Custom Agentsのコストを見る

Custom Agentsのコストは、単純な「1回いくら」だけでは見づらいです。次の要素で変わります。

• どれくらい複雑なタスクか
• どれくらい多くのページやDBを読むか
• 何ステップ実行するか
• どのモデルを使うか
• どれくらい頻繁に実行するか
• Workerや外部ツールを呼ぶか

実務で見積もるなら、まず次の式で考えるとよいです。

月間消費credits = Agentの実行回数 × 1回あたりのcredits消費 + Worker run数 × 1 runあたりのcredits消費
月間コスト = 月間消費credits × credits単価（1,000 creditsあたり10ドル）

Custom Agentsのコストは、PoCの段階で実際の利用量を測るのが一番です。最初から全社展開するのではなく、1つのAgent、1つのDB、1日1回の実行で始め、credits dashboardで見てから広げるのが安全です。

費用按分とクレジット購入量の考え方

Notion creditsはワークスペース単位で共有されるため、最初からユーザー単位で厳密に按分しようとすると、運用が重くなります。

私は、まずユーザー単位ではなく、Agent単位、業務単位、部門オーナー単位で見るのが現実的だと思います。理由は、Custom Agentは個人が1回使うチャットではなく、共有されたAgentがスケジュールやトリガーで動くことが多いからです。

クレジット購入量は、最初から全社分を大きく買うより、PoCの1〜2か月で実測する方が説得力があります。Custom Agentsの料金ヘルプでは、管理者がcredits dashboardでAgentごとの利用状況を確認できると案内されています。なお、エージェント単位でクレジット上限を設定する機能は公式ヘルプでは確認できず、公式に記載があるのは、管理者による個別エージェントの手動無効化と、ワークスペース全体のクレジット不足時の自動一時停止です。

上申資料に入れるなら、次のような形が扱いやすいです。

初期購入量 = PoC対象Agent数 × 想定月間実行回数 × 実測credits/回 × 安全係数

たとえば、最初は「情シス問い合わせ分類」「週次プロジェクトレポート」「会議準備サマリ」のように3つ以内に絞ります。それぞれにowner、対象DB、実行頻度、月次上限、停止条件を持たせ、1か月後にcredits dashboardで見直します。

経営向けには、「全社でAIを自由に使わせるための費用」ではなく、「特定業務の処理時間を減らすための検証費用」として出した方が説明しやすいです。便利さの説明だけでなく、実行回数の上限、月次上限、停止条件、対象業務をセットで出すと、従量課金への不安を下げられます。

Workersのコストを見る

Workers pricingの公式ヘルプによると、Workersはbeta中はBusiness / Enterprise プランで無料試用でき、2026年8月11日からNotion creditsが必要になる予定です。

Workersはrun単位で数えられます。公式ヘルプによると、典型的には1 runあたり0.0023ドルで、1,000 monthly Notion credits（月10ドル）あたり約4,348 runsです。

ここで気をつけたいのは、Custom Agentの1回の実行が、複数のWorker runを生むことです。公式ヘルプでも、Custom AgentがWorker tool callを複数回呼ぶ例が示されています。

たとえば、あるCustom Agentが1回の実行でWorkerを4回呼び、1日50回動くとします。この場合、Worker runは月間で次のようになります。

4 tool calls × 50 runs/day × 30 days = 6,000 Worker runs/month

Workers自体はAI推論ではなく、予測しやすい処理を実行するので、Custom Agentsより小さい単位でコストを見やすいです。ただし、Webhookのようにイベント数が多いものは急に増えます。Zendesk、GitHub、Stripe、Salesforceのようなイベント駆動の連携では、実行回数の上限やフィルタを設計しておく必要があります。

コストを抑える設計

Notion AI関連のコストを抑えるには、単に「使わない」ではなく、実行範囲を設計します。

• まず日次や週次で動かす
• すべてのDBではなく対象DBを絞る
• すべてのプロパティではなく必要なプロパティだけ読む
• ステータスやビューで対象レコードを絞る
• イベントごとの実行ではなくバッチ化する
• Workerのretryを無制限にしない
• Agentごとに月次の利用目安とオーナーを決める
• credits dashboardを定期的に見る

Notion AIでも、便利なエージェントを増やすほど、利用量、権限、支出を一緒に見る必要があります。

管理者が見るべき設定

Notion AIは、利用者にとっては便利な機能です。しかし、情シスやSaaS管理者から見ると、次の問いに答えられる必要があります。

• 誰がNotion AIを使えるか
• Web searchを許可するか
• 外部サイトアクセスに確認を必須にするか
• AI Connectorsを誰が接続できるか
• Custom Agentsを誰が作れるか
• Custom AgentsはどのページやDBを読めるか
• 書き込み操作に承認を入れるか
• Workersを誰が作成・実行できるか
• Creditsを誰が購入し、誰が利用量を見るか
• 実行ログをどこで確認するか

Notion公式ヘルプでは、ワークスペースオーナーが Settings からNotion AI設定を調整できると説明されています。Web searchをワークスペース全体で無効化したり、外部Webリクエスト前の確認を要求したり、AI ConnectorsやAI Meeting Notesの設定を扱ったりできます。

モデル選択の節で触れたClaude Fable 5は、有効化の判断自体が管理者の仕事になります。Notion公式の告知によると、Claude Fable 5はデフォルトのモデル群と異なり、Anthropic側が安全性監視のためにデータを保持します。そのため管理者が Settings → Notion AI から有効化するオプトイン方式になっています。本稿確認時点では、保持期間や条件に関するNotionヘルプ上の記載は確認できていません。LLMプロバイダー側のゼロリテンションを前提に社内整理してきた組織では、有効化の前に保持条件を確認し、機密データを扱う業務での利用可否を決めておく方が安全です。

Custom Agentsで確認すること

Custom Agents security featuresでは、Custom Agentsの独立権限、Agent Directory、作成制御、audit logs、AI analytics、共有時の警告などが説明されています。

先ほどの問いがワークスペース全体の設定だとすると、ここはAgent単位で確認する項目です。細かいセキュリティ論には広げず、運用で最低限見るものに絞ります。

外部接続の注意点

MCP connectionsやSlackなどをCustom Agentにつなぐ場合は、接続先と操作範囲を絞ります。prompt injection risksに関するNotion公式ヘルプでも、外部コンテンツや接続アプリを扱うAgentのリスクが説明されています。

最初は次を見るくらいで十分です。

• 信頼できるMCPサーバーだけを接続する
• 用途別にAgentを分ける
• Agentのアクセス範囲を最小化する
• 書き込みや外部送信は人間確認を挟む
• Audit logsやAI analyticsで実行状況を見る

まとめ

Notion AIは、文章生成だけの機能ではなくなっています。

ページ上で書く、直す、要約するところから始まり、Notion Agentでページやデータベースを操作し、Enterprise Searchでワークスペース内外を調査し、AI Meeting Notesで会議を残し、Custom Agentsでチームの定型業務を自動化し、Workersで外部データやWebhookとつなげる。ここまでが、いまのNotion AI関連機能の大きな流れです。

ただし、便利さだけで導入すると危ういです。

Custom AgentsとWorkersが入ると、AIは「答える」だけでなく「動く」ようになります。動くAIには、権限、実行範囲、ログ、承認、停止、コストの設計が必要です。

まずは、個人のNotion AgentとAI Meeting Notesで試す。次に、チームの小さな定型業務でCustom Agentを1つ作る。WorkersやMCPは、外部連携やコード実行が本当に必要になってから、最小権限で足していく。

この順番なら、Notion AIを「すごそうな機能」として眺めるのではなく、実務に入れられる道具として育てていけます。

FAQ

Notionをまだ使っていない組織でも、Notion AIから検討してよいですか？

検討してよいですが、Notion AIだけを単体で評価すると強みが見えにくいです。Notionの価値は、ドキュメント、Wiki、DB、タスク、議事録が1つのワークスペースに集約されることにあります。管理対象SaaSの削減、退職時のデータ回収、権限棚卸し、SSO、監査、外部共有統制が1箇所で済み、情報がデータベースとして構造化されて貯まるため、AI活用の土台になります。一方で自由度が高いぶん、放置すると無秩序になります。Notion導入で成果を出している組織は、ツールを入れただけの会社ではなく、チームスペース設計、DB設計、オーナー制度、権限設計に投資した会社です。まずはNotionを社内ナレッジと業務DBの基盤にできるかを見た方がよいです。

個人ワークスペースでの野良利用があります。有償導入はどう上申すればよいですか？

「便利だから」ではなく、「すでに発生しているリスクの統制」から入るのが通しやすいです。まず、CASBやSaaS管理ツールのログで野良利用の事実を可視化します。次に、放置リスクを示します。個人ワークスペースに会社情報が残る、退職時に回収できない、SSOやMFAを強制できない、監査ログがない、外部共有を把握できない、といった点です。そのうえで、SSO、ドメイン管理、監査、権限統制といった統制手段は有償プランの機能であり、「招き入れて統制する」には有償化が前提になることを説明し、Notion AIとCustom Agentsを全社ナレッジ活用基盤として位置づけます。経営向けには、「禁止するための投資ではなく、野良利用を統制下に入れてAI活用に転じるための投資」と整理すると伝わりやすいです。

Notion AIは全社一斉に導入すべきですか？

判断軸は「AI機能を配るか」ではなく、「全社ナレッジをNotionに集約する覚悟があるか」です。情報設計が崩れた状態でAIを入れても効果は出ないため、先にチームスペース、DB、オーナー制度、権限設計を整え、その上にAIを載せるのが成功パターンです。

コスト構造は分解できます。AI Meeting NotesやEnterprise Searchなどプランに含まれるAI機能はBusiness / Enterprise プランの固定費で、クレジット従量になるのはCustom Agentsだけです。「全社ライセンス＝固定費」「エージェント＝使った分だけ後から増やせる変動費」と分けて稟議を組めます。展開としては、ライセンスは全社に配り、エージェントの作成権限は最初は情シスや管理部門、業務改善担当に限定するのが安全です。作成権限の制限は公式機能で、全ワークスペースメンバー、ワークスペースオーナーのみ、オーナーと指定グループのみ、の3択で制御できます。

Notion AIとNotion Agentは何が違いますか？

Notion AIは、Notionに組み込まれたAI機能全体を指す広い言葉です。Notion Agentはその中の機能で、チャットを通じてページやデータベースを作成・編集したり、ワークスペースや接続アプリの文脈を使って複数ステップの作業を行ったりします。

Notion AgentとCustom Agentsは何が違いますか？

一番の違いは権限です。Notion Agentは本人の権限で動き、本人が見られないものは見られません。Custom Agentsは独立した自分自身の権限を持つチームメンバーとして動き、明示的に付与されたリソースだけにアクセスします。使われ方の面では、Notion Agentは主にユーザーがその場で依頼して使う個人向けのAgentで、Custom Agentsはチームで共有し、スケジュールやDBイベント、Slackイベントなどをきっかけにバックグラウンドで動くAgentです。

注意したいのは、Custom Agentの利用者は、自分が直接アクセス権を持たないリソースの情報をエージェント経由で取得でき、エージェントに読み書き権限があれば編集もできることです。これは権限境界を越えて業務を進められるよう意図された設計ですが、そのぶん、通常のNotion AIより権限設計と監査が重要になります。

ClaudeやChatGPTとNotion Custom Agentsはどう使い分けますか？

一言でいうと、自分の作業を助けるならNotion Agent、チームの定型業務を自動化するならCustom Agents、非定型の思考やNotion外の作業ならClaudeやChatGPTです。Notion内のページやデータベースを使い、チームの定型業務を継続実行するならCustom Agentsが向いています。Notion外の調査、コード生成、複数ツールをまたぐ作業、モデル固有の強みを使う作業ならClaudeやChatGPTなど外部AIが向きます。外部AIからNotionを扱いたい場合は、Notion MCPを使う選択肢もあります。

Custom AgentsとWorkersは何が違いますか？

Custom AgentsはAIが文脈を読んで判断し、業務を進めるためのものです。WorkersはNode/TypeScriptで書くコード実行基盤で、外部データ同期、Webhook、Custom Agent用のツールなど、AIの推論を必要としない決まった処理を実行するために使います。使い分けの目安は、曖昧な判断、要約、文章生成はCustom Agents、間違えてはいけない処理、外部API連携、同期はWorkersです。「エージェントが何をすべきか判断し、Workersが特定のステップを確実に実行する」という組み合わせが基本形で、WorkersはCustom Agentsの手足にあたります。

Workersで外部サービスの認証情報はどう扱えばよいですか？

シークレットはCLIから環境変数として渡し、コードに直書きしない設計になっています。運用としては、Workerに渡すAPIキーは専用のサービスアカウントで最小権限のスコープに絞って発行する、個人のトークンを使い回さない、読み取り専用の連携から始めて基幹システムへの書き込みはbeta期間中は慎重に判断する、という原則から始めるのが安全です。

Custom Agentsはいくらかかりますか？

2026年6月7日時点の公式情報では、Custom AgentsはNotion creditsを使います。Notion creditsは月額10ドルで1,000 credits、ワークスペース単位で共有され、月次でリセットされます。実際の消費量は、タスクの複雑さ、実行回数、読み取る情報量、モデル、外部ツール利用などで変わります。

なお、従量課金でも青天井にはなりません。クレジットが不足するとCustom Agentsは自動的に一時停止し、月次リセットか追加購入まで動きません。使用量が80%と100%に達した時点で管理者にアプリ内とメールで通知が届き、サイクル途中の追加購入もできます。

Workersはいくらかかりますか？

2026年6月7日時点の公式情報では、Workersはbeta中は無料で試せますが、2026年8月11日からNotion creditsが必要になる予定です。典型的には1 runあたり0.0023ドル、10ドル分の1,000 monthly Notion creditsで約4,348 runsと説明されています。

Notion creditsの費用按分はどう考えればよいですか？

課金単位は人ではなくワークスペースなので、「ユーザー按分ではなくエージェント按分」が現実的です。共有Agentがスケジュールやトリガーで動く場合、個人単位の利用量にきれいに分けづらいからです。credits dashboardではエージェントごとに消費クレジット、実行数、ステータス、作成者の内訳を確認できるため、全エージェントにオーナー部署を必須化し、エージェント別の実績を月次でオーナー部署に紐づける運用ができます。社内FAQや規程検索のような全社共通系は共通費とし、特定部署の業務を大きく代替する大口エージェントだけを部署負担にします。人単位の厳密な配賦は管理コストが利用額を上回りやすいので、金額が小さいうちは追わないのが現実解です。

クレジット購入の稟議はどう組み立てればよいですか？

最初から大きく買わず、最小単位で買って実測するのがよいです。Custom Agentsの消費はタスクの複雑さ、参照量、モデルで変動するため、事前見積もりよりPoCで「1実行あたりの実績値」を取る方が確実です。ROIは「AIにいくら使うか」ではなく、「1実行◯円 × 削減できる人の◯分」のように、業務1回あたりの処理コストと削減時間で示します。さらに、クレジット不足時の自動一時停止と80%・100%通知という「止まる設計」をセットで伝えれば、「月◯ドルまで、超過は都度承認」という形の稟議にできます。

企業でAIツールを導入するとき、何を判断軸にすればよいですか？

判断軸は4つです。どのデータにアクセスするか、誰の権限で動くか（本人権限か独立権限か）、出力を人がレビューするか自動実行か、コストを測定・制御できるか。Notion AIの良さは「データがある場所にAIが来た」ことです。社内ナレッジを外部のAIツールへコピーせず、統制下のワークスペース内でAIが動くため、ガバナンスの追加コストが小さく済みます。ただしCustom Agentsは独立権限を持つため、Tools and accessの最小権限、Agent Directory、EnterpriseプランならAudit logsやContent searchでの監査を前提として設計する必要があります。

Notion AIを社内導入するとき、最初に見るべき設定は何ですか？

最初に見るべきなのは、Web search、AI Connectors、AI Meeting Notes、Custom Agents作成権限、Tools and access、Credits dashboard、Audit logsです。特にCustom AgentsやWorkersを使う場合は、誰が作れて、何を読めて、何を書き換えられて、いくら使って、どう止めるかを決める必要があります。

デフォルト設定は安全側に倒れています。新規エージェントはデフォルトではワークスペース全ページへのアクセスを持たず、全体アクセスは作成者が明示的に有効化して警告に同意する必要があります。また、ワークスペース全体に対しては閲覧（Can view）を超える権限を付与できません。この前提を踏まえて、Tools and accessの最小権限とエージェント単位の監査を運用ルールに落とし込むのがよいです。

Custom Agentsの作成者が退職したらどうなりますか？

エージェントは、オーナー不在が7日続くと停止します。退職者が持っていたエージェントは、Settings → Members の Recently Left タブから新しいオーナーへ移管でき、Public API経由の移管にも対応しています。人が辞めた後もAIだけが勝手に動き続けるのではなく、停止と移管のフローが用意されているため、入退社の統制にそのまま組み込めます。

Notion AIを社内に定着させるコツはありますか？

入口のユースケースとしては、AI Meeting Notesの要約配信、社内FAQ、議事録のアクション抽出、DBの自動分類、情シス問い合わせの一次回答、定期レポートあたりが手堅いです。浸透のさせ方としては、全社研修を1回やるより、各部署に1人チャンピオンを置き、その部署の実業務テンプレートを1つAI化して見せる方が定着します。AI導入の前半戦は、実はチームスペース、DB、オーナー制度、テンプレートといったデータ整備です。