こんにちは。アシスタント 兼 広報のEimiです。
Notion AIの「カスタムエージェント」、もう業務で使い始めていますか？
「日報を自動でまとめる」「Slackの質問に社内ナレッジをもとに答える」「データベースの更新をきっかけに次の作業を進める」など、使い方だけ見るとかなり便利です。Notionを日常的に使っている会社ほど、カスタムエージェントは“AI担当者をNotionの中に置く”ような体験に近づいていきます。
一方で、情シスやコーポレートITの立場では、便利さだけでは判断できません。
- 誰がカスタムエージェントを作ってよいのか
- どのページ・データベース・外部ツールまで見せてよいのか
- エージェントが誤った回答や編集をした場合、誰が責任を持つのか
- Notionクレジットの消費をどう見積もり、どう止めるのか
- 全社展開するとき、現場と管理側の負荷をどう抑えるのか
この記事では、Notion AIカスタムエージェントを「便利そうな新機能」ではなく「企業で運用するAI」として捉え、情シスが押さえるべき判断軸を整理します。
【この記事の結論】
- Notion AIカスタムエージェントは、Notion内のページ・データベース・接続ツールをまたいで、トリガーやスケジュールに応じて自律的に動く「チーム用AIエージェント」です。
- 情シス／コーポレートITが見るべき本質は、機能の便利さよりも、権限・コスト・ログ・責任分界をどう運用に落とすかです。
- 2026年5月4日以降、カスタムエージェントはNotionクレジットを消費する利用量ベースの課金へ移行しました。ただし実際の課金・消費開始日は、各ワークスペースの月次サービス日によって変わります。
- 最も注意すべき点は、カスタムエージェントが「作成者本人として動くAI」ではなく、独自の権限を持つチームメンバーのように動くAIであることです。
- 導入の正攻法は、いきなり全社展開ではなく、可視化 → ポリシー策定 → 技術的コントロール → 教育・監視の順で小さく始めることです。
Notion AIカスタムエージェントとは？
Notion AIカスタムエージェントとは、Notion内の情報や接続ツールを使い、あらかじめ設定した指示・権限・トリガーに沿って自律的に作業するAIエージェントです。
従来のNotion AIは、人がその場で質問したり、文章作成を依頼したりする「呼び出すAI」が中心でした。カスタムエージェントはそこから一歩進み、特定の業務を継続的に担当する「任せるAI」に近い位置づけです。
たとえば、次のような使い方が想定できます。
- 毎朝、指定データベースから更新情報を集めて日次レポートを作る
- Slackで寄せられた質問に、Notion内のナレッジをもとに一次回答する
- 問い合わせ内容を分類し、担当チームやステータスをデータベースに反映する
- 議事録や顧客対応メモから、次アクションや確認事項を抽出する
- 定期的にデータベースを確認し、未対応・期限超過の項目を通知する
つまり、カスタムエージェントは単なる文章生成AIではありません。Notionのページ、データベース、コメント、接続アプリをまたいで、「業務の流れ」に組み込めるAIです。
従来のNotion AIとの違い
従来のNotion AIとカスタムエージェントの違いは、「誰の権限で、いつ、どの範囲で動くか」にあります。
| 観点 | 従来のNotion AI / Notion Agent | カスタムエージェント |
|---|---|---|
| 起動方法 | ユーザーがチャットやページ上で呼び出す | ユーザー操作に加え、スケジュールやイベントをきっかけに起動できる |
| 動くタイミング | 基本的にその場の依頼に応じて動く | 公開後、バックグラウンドで継続的に動く |
| 権限の考え方 | 原則としてユーザー本人が見られる範囲を前提に動く | エージェントごとに許可されたページ・DB・接続ツールへアクセスする |
| 共有時の注意点 | 個人利用の延長で考えやすい | エージェントを共有すると、利用者がエージェントの見える情報を引き出せる可能性がある |
| 情シスの論点 | 利用ルール、データ入力の注意 | 作成権限、アクセス範囲、クレジット、ログ、責任分界 |
ここが非常に重要です。
カスタムエージェントは「作った人の代わりに少し便利なことをするAI」ではなく、独自に許可された範囲で動くチーム用AIです。共有設計を誤ると、本人には見えないはずの情報に、エージェント経由でアクセスできてしまう可能性があります。
何ができる？代表的なユースケース
カスタムエージェントは、繰り返し発生する情報整理・分類・通知・レポート作成と相性がよい機能です。
1. 社内ヘルプデスクの一次回答
社内規程、利用ガイド、FAQ、手順書を参照し、SlackやNotion上の質問に一次回答します。
向いている例：
- 「経費精算の締め日はいつ？」
- 「入社時に必要なアカウント申請は？」
- 「Notionのページ共有ルールは？」
注意点：
- 人事・労務・法務・セキュリティに関わる回答は、最終確認者を決める
- 回答元となるナレッジを最新に保つ
- 参照できるページを必要最小限に絞る
2. データベース更新を起点にした業務整理
Notionデータベースのページ作成・更新をきっかけに、内容を分類したり、担当者確認用のメモを作ったりできます。
向いている例：
- 問い合わせDBに新規行が追加されたら、カテゴリ案と優先度案を入れる
- ブログ記事DBの下書きを確認し、SEO観点の改善点をAI Notesにまとめる
- 商談メモから次回確認事項を抽出する
注意点：
- 自動更新するプロパティと、人が確認するプロパティを分ける
- 外部公開・顧客送信につながる処理は、承認ステップを挟む
3. 定期レポート作成
日次・週次・月次などのスケジュールで、指定された情報を集約し、レポートを作成します。
向いている例：
- 週次のプロジェクト進捗まとめ
- 未対応タスクの一覧化
- コンテンツ制作状況のレポート
- イベント準備の残タスク整理
注意点：
- レポートの読み手、目的、判断に使う指標を先に決める
- 「AIがまとめた内容」と「人が確認した内容」を区別する
4. Slack・外部ツールと組み合わせたワークフロー
Notionだけでなく、Slackなどの接続ツールと組み合わせることで、現場のコミュニケーションに近い場所で動かせます。
向いている例：
- Slackの特定チャンネルに投稿された質問を拾い、NotionのFAQをもとに回答案を作る
- イベント準備チャンネルの投稿をもとに、Notionの進行管理DBへ確認事項を反映する
- 顧客対応メモをNotionに蓄積し、後から検索・再利用しやすくする
注意点：
- Slack上の発言には未確定情報が含まれる
- チャンネル単位でアクセス範囲を慎重に設計する
- 外部送信や顧客返信は、原則として人の確認を挟む
料金体系：Notionクレジットで何が変わったか
カスタムエージェント導入時に、情シスが必ず確認すべきなのが料金です。
2026年5月4日以降、カスタムエージェントはNotionクレジットを消費する利用量ベースの課金へ移行しました。NotionクレジットはBusinessプランとEnterpriseプランで利用できる追加枠で、カスタムエージェントがタスクを実行するたびに消費されます。
（以下の料金・クレジット仕様は、2026年6月2日時点のNotion公式ヘルプに基づきます。価格・仕様は変更される場合があります。）
押さえるべきポイント
| 項目 | 内容 |
|---|---|
| 対象 | Businessプラン、Enterpriseプラン |
| 課金単位 | 月次のNotionクレジット |
| 価格の目安 | 月額 1,000クレジットあたり10ドル |
| 消費タイミング | カスタムエージェントがタスクを実行するたびに消費 |
| 消費量 | 複雑なタスクほど多くなる傾向 |
| 共有範囲 | ワークスペース全体で共有 |
| リセット | 毎月リセット（未使用分のロールオーバー＝繰り越しは不可） |
「5月4日から全員が即課金」ではない
ここは誤解しやすいポイントです。
カスタムエージェントの有料化は2026年5月4日以降ですが、実際にクレジット消費や請求が始まる日は、各ワークスペースの月次サービス日（monthly service date）によって異なります。月次サービス日とは、月次／年次のNotionサブスクリプションを開始した日に基づく基準日で、クレジットのリセットや変更が反映されるタイミングです。
Notion公式は、エージェントは5月4日以降に到来する最初の月次サービス日まで無料で動き続けると説明しています。たとえば月次サービス日が5月9日のワークスペースであれば、クレジット消費・課金の開始も5月9日から、という考え方になります（正確な日付はクレジットダッシュボードで確認できます）。
もう一つ重要なのが、クレジットが不足した場合の挙動です。クレジットが足りないと、カスタムエージェントは次の月次サービス日に自動的に一時停止し、管理者がクレジットを追加するか、クレジットがリセットされるまで停止したままになります（公式ヘルプ）。
コスト管理で見るべき3つの数字
カスタムエージェントのコストは、単純な月額ライセンス費と違い、利用状況によって変動します。情シスは、少なくとも次の3つを見ておく必要があります。
- 実行回数：どのエージェントが、何回動いているか
- クレジット消費量：どのエージェントが、どれくらい消費しているか
- 月次サービス日までの消費ペース：今のペースで月末まで足りるか
Notionのクレジットダッシュボードでは、ワークスペース全体の消費状況、エージェントごとの実行回数・消費量、月次サービス日までの見込みを確認できます。
コスト暴走を防ぐ設定
カスタムエージェントは便利な一方、トリガー設定を誤ると想定以上に実行される可能性があります。対策として、次のような設定を検討します。
- エージェントごとのクレジット上限を設定する（2026年5月5日に管理者向けのガードレール機能が追加されました）
- Enterpriseでは、ワークスペース単位のクレジット上限設定も検討する（公式リリースノートに記載）
- クレジット上限に近づいた際のプロアクティブアラートを活用する
- 高頻度で動くトリガーは、対象データベースや条件（特定のステータス・キーワード・ビューなど）でフィルタして絞る
- 複雑すぎる処理は分割し、人の確認を挟む
- 月次レビューで「使われていないエージェント」「高コストなエージェント」を棚卸しする
なお、消費量の目安として、Notion公式は週次のステータス更新エージェント（Status update agent）相当の例として「月60回の実行で、おおよそ4.80〜10.80ドル程度」を挙げています。これは特定ユースケースの数値で、エージェントの種類によって幅があります（公式の他の例では1回あたり約0.03〜0.30ドル）。実際の消費はエージェントが読む情報量・使うツール・処理ステップ・実行頻度・使用モデルによって変わるため、最初の1〜2請求サイクルで実消費を観察してから調整するのが確実です。
最重要：カスタムエージェントの権限設計
カスタムエージェント導入で最も重要なのは、料金よりも権限設計です。
Notionのカスタムエージェントには、大きく2種類の権限があります。
| 権限の種類 | 意味 | 確認すべきこと |
|---|---|---|
| エージェントがアクセスできる範囲 | エージェントに許可するNotionページ、データベース、接続アプリ | 必要最小限になっているか |
| エージェントを使える人 | そのエージェントを誰に共有し、どの操作を許可するか | 利用者がエージェント経由で見える情報を理解しているか |
この2つは必ずセットで考える必要があります。
たとえば、経理チーム向けのエージェントに予算管理ページへのアクセスを許可したとします。そのエージェントを広い範囲に共有すると、利用者本人には予算管理ページの権限がなくても、エージェント経由で情報を取得できる可能性があります。
つまり、カスタムエージェントの共有は、単なる「便利なBotの共有」ではありません。エージェントが見える情報への入口を共有する行為です。
作成権限は段階的に開放する
カスタムエージェントを全員が自由に作れる状態にすると、次のような問題が起きやすくなります。
- 似た用途のエージェントが乱立する
- 参照範囲が広すぎるエージェントが作られる
- 退職・異動後にオーナー不明のエージェントが残る
- クレジット消費の原因が追いにくくなる
- 業務上の責任分界が曖昧になる
Notionでは、管理者がカスタムエージェントを作成できる範囲を制御できます（全員／ワークスペースオーナーのみ／指定メンバー。公式ヘルプの表記は「everyone／workspace owners only／selected members」です。グループ単位で指定できるかは、利用中のワークスペースの設定画面でご確認ください）。最初から全社開放するのではなく、次のように段階的に進めるのが現実的です。
| フェーズ | 作成できる人 | 目的 |
|---|---|---|
| 検証 | 情シス、AI推進、業務改善チームなど少人数 | 安全な設定・費用感・有効なユースケースを確認する |
| 部門PoC | 選定した部門の代表者 | 現場業務に合う使い方を試す |
| 限定展開 | 申請・レビューを通過した作成者 | 乱立を防ぎながら利用範囲を広げる |
| 全社展開 | ルールと監視体制が整った範囲 | 成功パターンを標準化する |
情シスが詰まりやすい4つの論点
カスタムエージェントの導入で情シスが詰まるのは、機能の理解ではなく運用設計です。代表的な論点は4つあります。
論点1：ガバナンス
誰が作成でき、誰が承認し、誰が棚卸しするのかを決める必要があります。
確認すべきこと：
- 作成権限を誰に付与するか
- 作成時の申請・レビューをどうするか
- エージェント名、用途、オーナー、参照範囲をどう記録するか
- 不要になったエージェントを誰が停止・削除するか
- 定期棚卸しの頻度をどうするか
おすすめの運用：
- 最初は作成者を限定する
- エージェント台帳を作る
- 目的・参照範囲・オーナー・クレジット上限を記録する
- 月1回または四半期に1回、棚卸しする
論点2：責任分界
カスタムエージェントは自律的に動きますが、責任までAIに移るわけではありません。業務上の責任は、エージェントを設計・利用する組織側に残ります。
確認すべきこと：
- AIの出力をそのまま使ってよい業務はどこまでか
- 人の確認が必須な業務は何か
- 顧客・取引先・社外公開に影響する処理をどう扱うか
- 誤回答・誤更新が起きた場合、誰が確認し、誰が修正するか
おすすめの線引き：
| 業務 | AIに任せやすい範囲 | 人の確認が必要な範囲 |
|---|---|---|
| 社内FAQ | 一次回答案の作成 | 規程・法務・人事判断を含む回答 |
| ブログ・広報 | 構成案、SEO改善案、下書き | 公開前の事実確認、表現確認、最終承認 |
| 顧客対応 | 議事録整理、確認事項抽出 | 顧客への正式回答、契約・費用に関わる内容 |
| セキュリティ | チェックリスト作成、ログ要約 | インシデント判断、外部報告、権限変更 |
論点3：コスト管理
カスタムエージェントは利用量ベースの課金です。便利だからといって無制限に動かすと、想定以上のクレジットを消費する可能性があります。
確認すべきこと：
- どのエージェントが最もクレジットを使っているか
- 実行頻度は業務価値に見合っているか
- 月次サービス日までに足りる見込みか
- 低価値・高コストなエージェントを止める基準はあるか
おすすめの運用：
- エージェントごとに月次上限を設定する
- 最初の1か月は「検証予算」として消費を観察する
- 高頻度トリガーは条件を絞る
- 「自動化で削減できた時間」と「消費クレジット」をセットで見る
論点4：展開設計
AI導入で失敗しやすいのは、最初から全社一斉に広げるパターンです。便利な機能ほど、現場からの期待値が高くなり、管理側のサポート負荷も増えます。
確認すべきこと：
- どの部門・業務から始めるか
- 成功の定義を何にするか
- 現場の問い合わせを誰が受けるか
- 既存の業務フローとどう接続するか
おすすめの進め方：
- 効果が測りやすい業務から始める
- 失敗しても影響が小さい範囲で試す
- 成功パターンをテンプレート化する
- 部門ごとに「作成者」と「レビュワー」を置く
運用に落とす4ステップ
ここからは、実際に社内導入する場合の進め方です。
ステップ1：可視化
まずは、現状を把握します。
確認すること：
- すでに作られているカスタムエージェントの一覧
- それぞれの目的、オーナー、作成者
- アクセス可能なページ・データベース・接続ツール
- 実行回数、クレジット消費量
- 社外影響のある処理が含まれているか
この段階で大切なのは、いきなり禁止や制限から入らないことです。まずは「誰が、何のために、どの範囲で使っているか」を見える化します。
ステップ2：ポリシー策定
次に、使ってよい範囲とレビュー基準を決めます。
最低限決めたい項目：
- 作成できる人
- 利用できる部門・用途
- 参照してよいデータの種類
- 外部送信・顧客対応・公開物に使う場合の承認ルール
- クレジット上限
- ログ確認の頻度
- 停止・削除の基準
社内ルールとしては、細かすぎる長文よりも、現場が判断しやすいチェックリスト形式がおすすめです。
ステップ3：技術的コントロール
ポリシーを決めたら、Notion側の設定に落とします。
設定例：
- 作成権限をワークスペースオーナーまたは指定メンバーに制限する
- エージェントごとにアクセスできるページ・DBを限定する
- エージェントごとのクレジット上限を設定する
- Enterpriseではワークスペース単位のクレジット上限も検討する
- 実行ログ・使用状況ダッシュボードを定期的に確認する
- 必要に応じて、DLP・SIEM・CASBなど既存のセキュリティ基盤と組み合わせる
- 監査ログ（Settings > Audit log）で、エージェント・ユーザー・日付・アクション種別ごとに実行履歴を確認する（Enterprise）
- ページ／DBの所有者は、エージェント本体への権限がなくても自分のリソースからエージェントを外せることを周知する
- 機微データや外部・非信頼コンテンツを扱うエージェントでは、プロンプトインジェクション耐性の観点から大型モデルを選ぶ（小型モデルは脆弱な可能性がある）。元プロンプトにない外部URLをエージェントが生成した場合に実行前確認を求める仕組み（URL confirmation）も活用する
ここで重要なのは、「ルールを作ったから大丈夫」ではなく、設定で効かせることです。
ステップ4：教育と継続監視
最後に、運用を回し続けます。
実施すること：
- 作成者向けのミニガイドを用意する
- よくある失敗例を共有する
- 月次でクレジット消費と実行ログを見る
- 不要なエージェントを停止する
- 成功したエージェントはテンプレート化する
- 社内FAQやナレッジを最新化する
カスタムエージェントは、作って終わりではありません。業務フローや社内ナレッジが変われば、エージェントの指示・参照範囲・トリガーも見直す必要があります。
導入前チェックリスト
カスタムエージェントを本格導入する前に、最低限このチェックリストを確認しておくと安心です。
- 作成権限を付与する人・グループが決まっている
- エージェントごとのオーナーを記録する場所がある
- 参照してよいページ・データベースの範囲が決まっている
- 顧客対応・社外公開・契約・費用に関わる処理は人が確認する
- エージェントごとのクレジット上限を設定している
- 使用状況ダッシュボードを見る担当者が決まっている
- 実行ログを確認する頻度が決まっている
- 不要なエージェントを停止・削除する基準がある
- 退職・異動時にエージェントの所有権移管を確認する（所有者不在が7日続くと停止。Settings > Members > Recently Left から移管）
- 現場向けの利用ルールが1ページにまとまっている
- 最初のPoC対象業務と成功指標が決まっている
当社クラウドネイティブの視点：ゼロトラストでAIを運用する
当社クラウドネイティブは、生成AIやAIエージェントに対して、「禁止ではなく、正しく使わせる」という考え方を重視しています。
便利なAIを全面禁止しても、現場は使いやすい外部サービスに流れます。結果として、管理されていないAI利用、いわゆるシャドーAIが増える可能性があります。
だからこそ、企業側がやるべきことは「使わせない」ではなく、安全に使える正規ルートを整えることです。
カスタムエージェントも同じです。
- 何を任せるか
- 何を見せるか
- どこで人が確認するか
- どのログを見るか
- どこで止めるか
これらを設計したうえで、権限・ログ・クレジット上限・承認フローを組み合わせる。これはゼロトラストの「決して信頼せず、常に検証する」という考え方に近い運用です。
AIエージェントを“信用して放置する”のではなく、検証可能な状態で活用する。これが、情シスがNotion AIカスタムエージェントを扱ううえでの基本姿勢になります。
まず始めるなら：おすすめPoC
最初のPoCとしておすすめなのは、次のような業務です。
| PoC候補 | おすすめ理由 | 注意点 |
|---|---|---|
| 社内FAQの一次回答 | 効果が見えやすく、問い合わせ削減につながりやすい | 参照ナレッジの鮮度管理が必要 |
| ブログ下書きレビュー | SEO・表現・抜け漏れ確認に使いやすい | 公開前の事実確認は人が行う |
| イベント準備の進行整理 | タスク・確認待ち・担当者の整理に向いている | 登壇者・会場・費用など外部影響のある情報は人が確認する |
| 週次プロジェクトレポート | 定期実行との相性がよい | レポートの読み手と判断項目を先に決める |
特に、ブログレビューやイベント準備の整理は、カスタムエージェントの価値を体感しやすい一方で、最終確認を人が担いやすいため、最初の検証に向いています。
まとめ
Notion AIカスタムエージェントは、Notionを「情報を置く場所」から「AIが業務を進める場所」へ進化させる機能です。
ただし、企業で使う場合は、便利さだけで導入を決めるのは危険です。
最後に、情シスが押さえるべきポイントを整理します。
- カスタムエージェントは、Notion内外の情報を使って自律的に動くチーム用AI
- 従来のNotion AIと違い、エージェントごとのアクセス権限と共有範囲を設計する必要がある
- 2026年5月4日以降、月次サービス日に応じてNotionクレジット消費が始まる
- 1,000クレジットあたり10ドルが目安で、ワークスペース全体で共有・毎月リセットされる
- 情シスの主要論点は、ガバナンス・責任分界・コスト管理・展開設計
- 導入は、可視化 → ポリシー策定 → 技術的コントロール → 教育・監視の順で進める
- ゼロトラストの考え方で、AIを信用して放置せず、検証可能な状態で活用する
「カスタムエージェントを使うかどうか」ではなく、これからは「どう安全に使わせるか」が問われます。
禁止ではなく、正しく使わせる。そのための設計が、情シスにとってのNotion AIカスタムエージェント導入の本質です。
よくある質問（FAQ）
Notion AIカスタムエージェントとは何ですか？
Notion内のページ、データベース、接続ツールを使い、トリガーやスケジュールに応じて自律的に作業するAIエージェントです。社内FAQの一次回答、データベース更新時の分類、定期レポート作成などに使えます。
無料プランやPlusプランでも使えますか？
カスタムエージェントの実行に必要なNotionクレジットは、BusinessプランとEnterpriseプラン向けの追加オプションです。そのため、FreeやPlusプランで試せるAI機能とは異なり、業務で継続利用する場合は実質的にBusiness以上のプランが前提になります。
カスタムエージェントの料金はいくらですか？
カスタムエージェントはNotionクレジットを消費します。目安として、月額1,000クレジットあたり10ドルです。クレジットはワークスペース全体で共有され、毎月リセットされます。実際の請求・消費開始日は、各ワークスペースの月次サービス日によって異なります。
カスタムエージェントは誰の権限で動きますか？
従来のNotion AIはユーザー本人の権限を前提に動きますが、カスタムエージェントはエージェントごとに許可されたページ、データベース、接続アプリへアクセスします。そのため、エージェントの共有範囲とアクセス範囲はセットで設計する必要があります。
共有すると何が危険ですか？
エージェントを共有すると、利用者本人には見えない情報でも、エージェントがアクセスできる情報を取得できる可能性があります。共有前に、エージェントが参照できるページ・DB・接続ツールを確認し、必要最小限に絞ることが重要です。
コストを抑えるにはどうすればよいですか？
エージェントごとのクレジット上限を設定し、トリガー条件を絞り、使用状況ダッシュボードで実行回数と消費量を定期的に確認します。高頻度で動くエージェントや、複雑な処理を行うエージェントは、特に消費量を見直しましょう。
クレジットが尽きるとエージェントはどうなりますか？
クレジットが不足すると、カスタムエージェントは次の月次サービス日に自動的に一時停止します。管理者がクレジットを追加購入するか、クレジットがリセットされると、エージェントは再開できます。
エージェント同士を連携させられますか？
筆者が確認した2026年6月時点では、エージェントが別のエージェントを直接呼び出す機能は提供されていません。ただし、データベースのプロパティ変更をトリガーにして次のエージェントを起動する、といった「間接連鎖」は設計できます（設定できるトリガーは公式ヘルプを参照）。ただし、次のエージェントに渡るのは「結果」だけで、「なぜそう判断したか」という根拠は引き継がれません。
情シスは最初に何をすべきですか？
最初にやるべきことは可視化です。誰がどのエージェントを作り、どの情報にアクセスし、どれくらいクレジットを消費しているかを確認します。そのうえで、作成権限、参照範囲、承認ルール、クレジット上限を決めます。
導入で失敗しやすいパターンは何ですか？
最初から全社一斉に開放することです。作成権限、コスト上限、レビュー体制がない状態で広げると、エージェントの乱立、権限過多、クレジット消費の増加、問い合わせ対応の増加が起きやすくなります。
どの業務から試すのがおすすめですか？
社内FAQ、ブログ下書きレビュー、イベント準備の進行整理、週次レポート作成などがおすすめです。効果が見えやすく、失敗しても外部影響が小さく、人の確認を挟みやすい業務から始めると安全です。
関連用語集
- カスタムエージェント（Custom Agents）：Notion上で、指示・権限・トリガーに沿って自律的に作業するAIエージェント
- Notionクレジット：カスタムエージェントの実行時に消費される利用量ベースの課金単位
- 月次サービス日：Notionの契約上、クレジットのリセットや変更が反映される基準日
- 責任分界：AIに任せる範囲と、人が確認・判断する範囲の線引き
- シャドーAI：企業が把握・管理していない状態で、従業員が個別にAIツールを利用すること
- ゼロトラスト：暗黙の信頼を置かず、ユーザー・デバイス・リソース単位で常に認証・認可を行うセキュリティの考え方。「決して信頼せず、常に検証する（never trust, always verify）」という標語で要約されることが多い（標語の初出はForrester、権威ある技術定義はNIST SP 800-207。参考：NIST）
- DLP（Data Loss Prevention）：機密情報や個人情報の外部流出を防ぐ仕組み
- SIEM：ログを集約・分析し、セキュリティ上の異常を検知する仕組み
- CASB：クラウドサービス利用を可視化・制御するセキュリティ基盤
- MCP（Model Context Protocol）：AIエージェントが外部ツールやデータソースと連携するためのオープン標準プロトコル（出典：公式ドキュメント）
