こんにちは、keitaです。
自分が情シスの仕事をするようになってから常に使っているNotion。しかし、これまでドキュメント関係がNotionだけにまとまっているということはほぼほぼありませんでした。
たとえば、
- ドキュメントをNotionに残すようになった経緯はSlack
- 会議の議事録や要約データはGoogle Drive
- 個人的な資料の置き場はOneDrive
などといった具合にデータが散らばり、「どこに何があるかわからない」「結局どれが最新なのか分からない」という状態が続いていました。同じような会社は、少なくないと思います。
この問題を解決するために社内Wikiやドキュメント管理ツールを検討する企業は多く、その候補としてよく挙がるのがNotionです。
ただ、Notionを入れただけでは情報は集まりません。置き場所を決めることと、そこに集まることは別だからです。だからこそ、いまNotionを使うなら「文書をきれいに整理できるツール」として見るだけではなく、「情報が集まったときに何をしたいか・何ができるか」までを視野に入れて考えるのが良いと思います。
この記事では、
- Notionは社内で使えているが、AIエージェントはまだ入れていない方
- Notionはあるが情報が散らばっていて、エージェントを動かす前に何をすべきか知りたい方
に向けて、AIエージェントがあることでNotionでできることがどう変わるのかを整理します。
なお、この記事では、標準搭載のNotion Agentと、業務ごとに指示や参照範囲を設定して作るCustom Agentsを、まとめて「エージェント」と書いています。区別が必要な箇所では、それぞれの名称で書きます。
エージェントが効くかどうかは、情報の持ち方で決まる
エージェントが業務で使いものになるかどうかは、機能の多さではなく、参照する情報をどういう形で持てるかで決まると考えています。
「AIが使えるかどうか」自体は、もう差になりません。Notionと同じように社内のドキュメントを扱うツールには、それぞれAIが用意されています。
たとえば、
- Confluence — Rovo
- Google Workspace — Gemini
- Microsoft 365 — Copilot
のような組み合わせです。
社内ドキュメントを参照して回答を作るところまでは、多くのSaaSで実現できるようになっています。
そこで見るべきなのは、次の3点です。
- 文書と構造化データが同じ製品の中にあるか
- 情報どうしを関連付けられるか
- エージェントの参照範囲を業務単位で絞れるか
上の図は、社内のSaaS申請ルールを変えた場合に、先ほどの3点がどう働くかを示したものです。この場面で扱う情報は、次の3種類です。
- 決めた経緯：会議の議事録
- 新しい申請方法：手順書
- 実際の申請内容：申請DBに蓄積
同じ製品の中にあるか。形式はばらばらですが、すべてNotionの中に置けます。
関連付けられるか。手順書と議事録をそれぞれデータベースで管理し、リレーションで結んでおくと、手順書から「なぜこのルールになったんだっけ？」までたどれる状態になります。
参照範囲を絞れるか。そのうえで、エージェントごとに参照範囲を指定できます。問い合わせ対応のエージェントには、正式な手順書と解決済みの事例だけを渡し、検討中だった旧案のメモは外す。参照させる範囲を業務単位で決められることが、回答の安定につながります。
こうしておくと、申請方法を聞かれたときも、ルールの経緯を聞かれたときも、AIエージェントが同じNotionの中から根拠を探せる状態になります。
ここに挙げた3点は、Notionだけができることではありません。他の製品でも、組み合わせや設定しだいで近い形は作れます。見たいのは、実現できるかどうかよりも、文書とデータとAIの結びつきを、日々の運用の中で無理なく保てるかどうかです。なお、各製品の機能は更新が速いため、最終的な比較は各社の最新情報で確認してください。
Notionを使う目的は、社内Wikiをもう1つ増やすことではありません。人とAIが同じ業務情報を参照し、仕事を進められる基盤を作ることです。
汎用AIだけでは、会社の仕事に詳しくならない
生成AIへ一般的な質問をすると、幅広い知識から回答を得られます。しかし、そのAIは自社固有の仕事を最初から知っているわけではありません。
たとえば、次のような情報です。
- 自社の申請・承認ルール
- 利用しているSaaSと管理担当者
- 顧客ごとのプロジェクト状況
- 過去の会議で決めたこと
- 社内で承認されている手順
- 問い合わせに対する過去の回答
- 例外対応を行った理由
これらを毎回プロンプトへ貼り付ける運用は手間がかかり、情報の更新や権限管理も追いつかなくなります。もっとも、いまはChatGPTやClaudeにも社内のドキュメントへつなぐコネクタがあり、貼り付けなくても参照させることはできます。
Notion AIも同じで、SlackやGoogle Drive、SharePointなどのコネクタがあり、Notionの外にある情報も検索できます（Business / Enterpriseプラン、設定はワークスペースのオーナー）。すべてをNotionへ移さなくても、AIが探せる範囲は広げられます。
探す精度が実際どのくらいかは、弊社代表のシンジさんが同じ質問をGleanとNotion AIの両方に投げ、ブラインドで評価した現代的なエンタープライズサーチはGleanかNotionの2択、で、どっちがいいか決着をつけたにまとめています。
ただし、Notion AIがコネクタ越しに外部の情報でできるのは、探して回答に使うところまでです。Google Driveのスプレッドシートは検索の対象にはなっても、中のデータを計算に使うことはできません。手順書と議事録のデータベースをリレーションで結ぶ、議事録からタスクを起票する、対応状況を更新するといった操作は、Notionの中にある情報にしか行えません。
業務情報をNotionに置き、ページやデータベースの関係を整理しておくほど、エージェントに任せられることが増えます。
ここが、単体のAIチャットを導入する場合と、Notionを業務基盤として導入する場合の違いです。
エージェントがいるNotionでできること
エージェントと聞くと、何でも自動で判断して実行する仕組みを想像するかもしれません。
しかし、企業で最初に考えておきたいのは大規模な自動化ではなく、日常業務で行う「情報を探す」「内容を整理する」「確認点を洗い出す」といった小さな作業です。
その小さな作業がどこにあるのか、人がやってきた作業と対応させて並べてみます。
| これまで人がやっていたこと | エージェントに任せられること |
|---|---|
| 手順書を探して問い合わせに答える。古い手順書がないか巡回する | 関連する手順書を参照して回答案を作り、確認期限を過ぎたページや矛盾の候補を抽出する |
| 議事録を読み返してタスクを転記し、複数のページから進捗報告を作る | 決定事項・担当者・期限の候補を整理し、報告の下書きを作る |
| 申請や資料の抜け漏れを確認して聞き直す | 不足項目や抜け漏れを検出し、質問案と確認事項を作る |
ただし、AIへ仕事を丸ごと渡すわけではありません。人が時間を使っていた準備や整理をエージェントに任せ、承認、例外判断、責任を伴う操作は、今後も人が担う領域です。
社内で動かしてみた2つの活用例
ここからは、社内のNotionで実際に作った2つの仕組みを紹介します。情報をNotionに集めるだけでも探す手間は減りますが、その先で何が変わるかの話です。作り方の詳細はそれぞれ別記事にまとめているので、ここでは概要と、動かして分かったことだけ書きます。
活用例1：議事録からタスクを起票する
会議の記録と要約は、AI ミーティングノートを使えばNotionに残ります。
ただ、残った議事録の中の「やること」は、誰かが読み返してタスクへ転記しなければ動き出しません。会議の数が増えるほど、この転記が後回しになります。
そこで社内では、この要約完了をトリガーにカスタムエージェントを起動し、議事録から依頼事項を拾ってタスクDBへ起票する仕組みを作りました。議事録の要約が終わるとエージェントが動き、タスクDBへ起票して、最後に人が確認する流れです。
同じ音声を同じ指示で流しても、結果は同じになるとは限りませんでした。起票すべきでない項目まで起票されることもあれば、指示どおりになることもあります。
一方で「メンバーとして見つからない名前を担当者に設定しない」という指示は守られていました。確かめれば済む指示は守られ、判断が必要な指示は揺れる。文字起こしの誤認識もそのままタスクに入るので、最終確認は人が行う前提で組んでいます。
作り方と分かったことの詳細は【検証】Notionの議事録からタスクを自動起票するトリガーを試してみたにまとめています。
活用例2：社内問い合わせの一次回答
情シスやコーポレート部門には、同じような問い合わせが繰り返し届きます。FAQや手順書があっても、利用者が適切なページを見つけられるとは限りません。
問い合わせに対して、担当者は都度ページを探して回答文を作ることになり、その担当者が会議中や不在のときは、質問した側がそのまま待つことになります。
そこで社内では、Slackへ届く問い合わせを問い合わせDBへ集約し、カスタムエージェントが一次回答をSlackへ返す仕組みを作りました。参照させるのは「解決」かつ「人手確認済み」の事例だけに絞り、アカウント発行や権限付与など責任を伴う領域は回答させず、担当者へエスカレーションする設計です。
立ち上げ直後は参照できる過去事例がありません。そこで、類似事例が3件以上あれば過去事例を主な根拠に、少なければ公式情報も合わせて回答案を作る、と件数で切り替えています。回答には「過去にはこの対応で解決したようです」と書かせ、今回も解決すると断定させません。
これで、手順としてNotionに情報がある問い合わせは、担当者の手が空くのを待たずに答えが出ます。 担当者側も、白紙から回答文を書くのではなく、出ている回答を確認して必要なら補うところから始められます。判断や責任を伴うものは人に残したまま、待ち時間だけを削れるのが、この切り分けの効きどころです。
作り方と設定の詳細はSlack × Notionカスタムエージェントで、情シスの問い合わせ窓口に一次回答を任せてみたにまとめています。
Notionを入れれば、すぐにエージェントが働けるわけではない
ここまでの2つの例は、いずれも参照範囲や指示を決めたうえで動いています。
エージェントを有効にすれば情報が集まるわけではありません。集まっていて、決めごとがあるから働けます。
うまく回らない原因は、機能の不足よりも、どのページが正なのか、誰が更新するのかが決まっていないことにあるように思います。そしてエージェントを入れると、この曖昧さがそのまま回答の曖昧さとして出てきます。
人が読むときは「たぶんこちらが新しい」と補完できますが、エージェントが同じ判断をするとは限りません。古いほうを根拠にすることもあれば、足りない部分を推測で埋めることもあります。
そうならないために、先に決めておきたいのは次の3点です。
- 正本とステータス
- 責任者と最終確認日
- 参照範囲と、人へ戻す条件
上の図の左と右の違いは、先ほどの3点を判断基準として情報に持たせたかどうかです。
正本を決め、ステータスを持たせる
同じテーマのページが複数あると、どれを根拠にすべきか判断しづらくなります。正式な手順書や正本となるデータベースを決めます。
あわせて、検討メモや下書きが正式なルールと同じ場所にある場合は、「下書き」「確認済み」「廃止」などのステータスを持たせておくと、人もエージェントもどれが正式な情報かを判別できます。
責任者と最終確認日を持たせる
誰も更新しないナレッジは、時間とともに古くなります。
ページやデータベースごとに責任者と最終確認日を持たせておくと、情報が曖昧なときに誰へ確認すればいいか、そのページがいつ確認されたものかがすぐ分かります。
参照範囲を絞り、人へ戻す条件を決める
便利だからとワークスペース全体を参照させるのではなく、業務に必要なページとデータベースだけを与えます。
そのうえで、セキュリティ、契約、費用、権限変更、社外送信など影響の大きい判断は、人間が確認する条件として明示しておきます。
この情報設計と運用設計があって、初めてエージェントが安定して業務を支援できます。
Notion AIの利用条件と費用
ここまでの決めごとと並行して、Notion AI自体の利用条件も確認しておく必要があります。
権限設計や運用体制まで含めた整理はNotion AIカスタムエージェントとは？情シスが知るべき料金・権限・運用設計にまとめています。
揃えておく4つの場所と、最初の1業務
最初から複雑な構成を作る必要はありません。まずは次の4つを用意すると、Notionの基本機能とAI活用をつなげやすくなります。まだ揃っていなければエージェントを動かす前にここから作り、すでにあるなら4つが互いに関連付けられているかを確認します。
| 場所 | 入れる情報 | 将来のAI活用 |
|---|---|---|
| 社内Wiki | 会社ルール、手順書、FAQ | 検索、回答案、確認事項の作成 |
| 議事録DB | 会議メモ、決定事項 | 要約、タスク抽出、次回論点の整理 |
| タスク・プロジェクトDB | 担当者、期限、状態 | 進捗集約、停滞タスクの抽出 |
| 申請・問い合わせDB | 依頼内容、回答、対応履歴 | 分類、不足確認、回答下書き |
この4つをNotionのページとデータベースとして関連付けておくと、エージェントが業務全体の文脈を追え、起票や更新まで任せられるようになります。
対象は「1チーム・1業務・1エージェント」から
最初から全社の情報を移行し、複数のエージェントを動かす進め方はおすすめしません。まずは、次の条件に当てはまる業務を1つ選びます。
すべてを満たす必要はなく、当てはまる数が多いほど小さく試しやすくなります。
- 毎週または毎月繰り返している
- 必要な入力と期待する出力が分かる
- 参照するページやDBを限定できる
- 失敗しても人が修正できる
- 効果を時間や件数で測れる
たとえば、社内問い合わせの回答案作成、申請の不足情報チェック、週次プロジェクト報告の下書き、会議後のアクションアイテム整理、手順書の確認期限チェックなどが該当します。
進め方は、次の5段階に分けます。
- 1チームで情報の置き場所を決める
- 手順書、FAQ、議事録、タスクをNotionへ集める
- Notion AIで検索、要約、下書きを試す
- 繰り返し業務を1つだけエージェント化する
- 効果、誤り、権限、コストを確認して広げる
成功したかどうかは、「エージェントを作れたか」ではなく、問い合わせ対応時間、申請の差し戻し回数、報告作成時間などが減ったかで判断します。
まとめ
Notionは、ドキュメントや社内Wikiを作るためだけの製品ではなくなっています。ナレッジ、議事録、タスク、申請、プロジェクト情報を同じ場所に集め、文書と構造化データをリレーションで結び、その上でAIエージェントに支援させるところまでが、同じワークスペースの中で完結します。
ただ、これらはエージェントを有効にした時点で手に入るものではありません。エージェントが根拠にできるのは、Notionと接続先にある情報だけです。どのページが正なのか、誰が更新するのか、どこまでをAIに任せてどこから人が判断するのか。ここが決まっていなければ、情報は集まらず、返ってくる答えも曖昧になります。この決めごとは、どの製品を選んでも必要になります。
だからこそ、決めごとを先に用意しておくことが、Notionのメリットを取りこぼさない一番の近道になります。 最初に挙げた「無理なく保てるか」という点では、Notionはこうした決めごとをページとデータベースの属性としてそのまま持たせられるので、受け皿を作る作業がそのまま日々の運用になります。
まずは1つのチームで、1つの繰り返し業務から。そこで受け皿を作れれば、あとは同じやり方を広げていくだけです。
