Dify × 公式Notion MCPで研究室の議事録AIを作り直した話

研究室のミーティングでは、過去の議論や担当タスクを確認する場面がよくあります。

例えば、

• 前回のミーティングで何を決めたか
• 教授からどのような指摘を受けたか
• 誰にどのタスクが割り当てられたか
• 次回までに確認することは何だったか

といった内容です。

議事録自体はNotionに残しています。

ただ、議事録が残っていても、

「前回何を決めたっけ？」

「この話、前にもしていた気がするけど、いつだったっけ？」

と、結局ミーティングのたびに過去の議事録を探すところから始まることがあります。

特に、ミーティングが増えてくると、
議事録が存在することと、必要な情報をすぐ取り出せることは別だと感じました。

そこで今回は、

Notionに保存している研究室の議事録へ、自然言語で質問できるチャットボット

をDifyとNotion MCPで作りました。

実際には以前にも同じものを作ろうとしています。

前回の記事はこちらです。

Dify × Notion MCPで研究室の議事録AIチャットボットを作ろうとして詰まった話

前回は、自分でNode.js / Expressを使ってMCPサーバーを作りました。

しかし、

• MCPの初期化処理で詰まる
• Notion検索はできてもページ本文まで読めない
• AIが検索キーワードを細かくしすぎる
• 議事録QAだけならDifyのKnowledge機能の方が簡単なのではないか

など、いろいろ課題が残りました。

その後、改めて調べてみると、
Notion公式のMCPサーバーが利用できるようになっていました。

そこで今回は、

自前のMCPサーバーをやめて、公式Notion MCP Serverを使って作り直す

ことにしました。

なお、この記事で使用している議事録、人物名、質問、タスクなどは、
すべて検証用に作成したモックデータです。

実在する研究室の議事録や研究内容をそのまま使用しているわけではありません。

---

今回作ったもの

最終的な構成は、かなりシンプルになりました。

ユーザー
  ↓
Dify Agent
  ↓
Notion MCP Server
  ↓
Notion
  ↓
研究室の議事録DB

MCP ServerはRender上で動かしています。

もう少し詳しく書くと、以下です。

教授 / 自分
    ↓
Dify Webアプリ
    ↓
Authorization: Bearer <AUTH_TOKEN>
    ↓
Render
    ↓
公式 Notion MCP Server
    ↓
NOTION_TOKEN
    ↓
Notion
    ↓
議事録DB

前回は、

Dify
 ↓
自作MCPサーバー（Express）
 ↓
Notion API

という構成でした。

今回は、

Dify
 ↓
公式Notion MCP Server
 ↓
Notion

になっています。

自前でMCPのプロトコル部分を実装しなくてよくなったのが、
前回との一番大きな違いです。

---

今回はDifyのナレッジを使っていない

前回の記事では、

議事録へ質問するだけなら、DifyのKnowledge機能の方が向いているのでは？

という結論になりました。

実際、議事録のPDFやテキストを読み込ませて、
その内容について質問するだけならKnowledge方式はかなりシンプルだと思います。

ただ、今回はもう一度MCP方式を選びました。

理由は、

Notionを情報の正本として、その時点の内容を直接取得したかったから

です。

Knowledge方式の場合は、
基本的にはDify側へデータを取り込み、そのデータを検索する構成になります。

一方、今回やりたかったのは、

Notionの議事録を更新する
       ↓
次の質問では、その更新された内容を参照する

という形です。

議事録を更新するたびに、

「Dify側にも同期しないと」

と考えたくありませんでした。

そのため今回は、

質問
 ↓
その場でNotionを検索
 ↓
対象ページを取得
 ↓
回答

というMCP方式にしました。

つまり、

「議事録だけを参照したいからMCPにした」わけではありません。

参照範囲を議事録だけにすること自体は、
Knowledge方式でも実現できます。

今回は、

• Notionをそのまま情報源にしたい
• 同期処理を増やしたくない
• Notion側の最新情報を取得したい
• MCPを使ったAgent構成をもう一度試したい

という理由でMCPを選びました。

---

構築

1. Notion Integrationを作る

まずNotion側でIntegrationを作成しました。

今回は研究室の議事録を読むだけなので、
Integrationの権限も読み取りだけにします。

今回有効にしたのは、

コンテンツを読み取る

のみです。

以下は無効にしました。

コンテンツを更新する
コンテンツを挿入する

また、このIntegrationからアクセスできるページも、
研究室の議事録DBだけに限定しています。

つまり、

Notion Workspace
 ├─ 他のページ        ← アクセス不可
 ├─ 個人ページ        ← アクセス不可
 └─ 議事録DB          ← 読み取りのみ

という状態にしています。

AI側のプロンプトで、

書き込まないでください

とお願いするだけではなく、

Notion側の権限そのものをRead Onlyにしている

という点は重要だと思いました。

---

2. 公式Notion MCP Serverをローカルで動かす

前回はMCP Server自体をExpressで自作しました。

今回はNotion公式のMCP Serverを使います。

GitHubはこちらです。

まずはRenderへデプロイする前に、
ローカルで動くことを確認しました。

NOTION_TOKEN を環境変数に設定した上で、

npx -y @notionhq/notion-mcp-server --transport http

を実行します。

自分の環境では、以下のようにMCP Serverが起動しました。

MCP Server listening on 127.0.0.1:3000
Endpoint: http://127.0.0.1:3000/mcp
Authentication: Bearer token required

前回は、

• initialize
• notifications/initialized
• tools/list
• tools/call

などを自前で処理する必要がありました。

今回は公式MCP Server側が処理してくれるため、
MCPの通信部分を自分で実装する必要がありません。

前回かなり苦労した部分だったので、
ここはかなり楽になりました。

---

3. Renderへデプロイする

ローカルで動作したので、
次は外部からDifyがアクセスできるようにRenderへデプロイしました。

今回は、自分のリポジトリにMCP Serverをコピーするのではなく、
Notion公式のGitHubリポジトリをRenderから直接利用しました。

最初はDockerで試して失敗した

最初はDockerでデプロイしようとしました。

しかし、自分の環境では正常に起動できませんでした。

Docker側を追い続けてもよかったのですが、
今回の目的はDockerの検証ではありません。

そのため、普通にNode.jsのWeb Serviceとして動かすことにしました。

結果的にはこちらで問題なく動きました。

---

Renderの設定

自分の環境では、以下の設定にしました。

Runtime

Node

Build Command

npm ci && npm run build

Start Command

node bin/cli.mjs --transport http --host 0.0.0.0 --port $PORT

Environment Variables

NOTION_TOKEN=<Notion Integration Token>
AUTH_TOKEN=<DifyからMCP Serverへ接続するためのToken>
NODE_VERSION=22.16.0

実際のTokenはGitHubや記事には載せません。

デプロイ後、Renderのログに以下のような表示が出れば起動成功です。

MCP Server listening on 0.0.0.0:10000
Endpoint: http://127.0.0.1:10000/mcp
Health check: http://127.0.0.1:10000/health
Authentication: Bearer token required

Difyから使用するURLは、

https://<RenderのサービスURL>/mcp

です。

前回はSSEを使って、

/sse
/message

というエンドポイントを用意していました。

今回はStreamable HTTPの、

/mcp

だけで接続します。

---

4. AUTH_TOKENとNOTION_TOKENを分ける

今回、Tokenが2種類あります。

最初は少し分かりにくかったので整理します。

Dify
 ↓
AUTH_TOKEN
 ↓
MCP Server
 ↓
NOTION_TOKEN
 ↓
Notion

AUTH_TOKEN

DifyからRender上のMCP ServerへアクセスするためのTokenです。

Dify → MCP Server

の認証に使います。

NOTION_TOKEN

MCP ServerからNotionへアクセスするためのTokenです。

MCP Server → Notion

の認証に使います。

つまり役割が違います。

前回の構成では、
主にNotion API KeyだけをRenderへ設定していました。

今回はMCP Server自体にもBearer認証を付けているため、

外部からMCP Serverへアクセスする認証

と、

MCP ServerからNotionへアクセスする認証

を分けています。

---

5. DifyへMCP Serverを登録する

次にDify側です。

今回はDify Cloudを使用しています。

Difyの、

連携
↓
ツール
↓
MCP
↓
MCPサーバー（HTTP）を追加

から登録しました。

設定した内容は以下です。

サーバーURL:
https://<RenderのサービスURL>/mcp

ヘッダーには、

Authorization

を追加し、

Bearer <AUTH_TOKEN>

を設定します。

接続に成功すると、
自分の環境では24個のツールが認識されました。

---

6. 24個全部は使わせない

Notion MCPを登録すると、
多数のツールが利用できます。

ただし、今回は議事録を読むだけです。

そのため、Agentに全ツールを与えるのではなく、
必要な読み取り系ツールだけを追加しました。

今回主に使用したのは以下です。

API-post-search
API-retrieve-a-database
API-query-data-source
API-retrieve-page-markdown

Notion Integration自体もRead Onlyですが、
Dify側でも書き込み用ツールを渡していません。

つまり、

Dify側
→ 読み取りツールだけ

Notion側
→ Integration自体がRead Only

という構成にしています。

---

7. Dify Agentを作る

今回はDifyのAgentを使いました。

最初のシステムプロンプトはかなり単純でした。

あなたは研究室の議事録を参照して回答するアシスタントです。

研究室の過去の議論、ToDo、決定事項、担当者、教授からの指摘について質問された場合は、
必ずNotionの議事録を検索・取得してから回答してください。

議事録に書かれていない内容は推測しないでください。

回答には可能な限り、
・結論
・参照したミーティング日
・参照した議題名
・参照元のNotionページURL
を含めてください。

複数の議事録が関係する質問では、
必要に応じて複数ページを取得して比較してください。

これで動くと思っていました。

しかし、実際に試すと問題が起きました。

---

最初の質問で失敗した

検証用に以下の質問をしました。

2025年11月6日のミーティングで、
佐藤さんに割り当てられたタスクは何？

しかし、最初は期待した回答になりませんでした。

Difyのログを見ると、
AIが API-post-search を1回使っただけで、

該当する情報が見つかりませんでした

と回答していました。

MCP Serverへの接続自体はできています。

問題は、

AIがどのようにNotionを探すか

でした。

これは前回の自作MCPでも起きた問題です。

前回は、

2025年11月6日 ミーティング タスク 佐藤

のように細かすぎる検索語を作ってしまい、
対象ページが見つからないことがありました。

公式MCP Serverになっても、
Agent側がツールをどう使うかという問題は残ります。

---

システムプロンプトに検索手順を追加した

そこで、検索手順をもう少し具体的にしました。

【Notion検索の手順】

ユーザーが日付・担当者・ToDo・過去の議論について質問した場合、
API-post-search に日付や人名だけを直接渡して検索してはいけません。

まず API-post-search で「議事録」または
「研究室ミーティング議事録」を検索し、
対象の議事録データベースまたは議事録ページを見つけてください。

データベースが見つかった場合は、
API-retrieve-a-database と API-query-data-source を使用して、
日付などのプロパティから該当する議事録を特定してください。

対象ページが見つかったら、
必ず API-retrieve-page-markdown を使用して本文を読み、
本文・決定事項・ToDoを確認してから回答してください。

1回の検索で見つからなくても、
検索語を変えて最低2回は検索してください。

「見つかりませんでした」と回答するのは、
上記の検索と本文取得を試した後だけにしてください。

ここまで指示すると、
検索だけで終わらず、

検索する
 ↓
対象ページを見つける
 ↓
本文を読む
 ↓
回答する

という動きをするようになりました。

AIにツールを渡せば、
自動的にうまく使ってくれるわけではありません。

ツールの使い方自体をプロンプトで設計する必要がある

という点は、前回から変わりませんでした。

---

Difyは「保存」だけでは公開版に反映されないことがある

もう1つ少し詰まったのが、
Difyの公開版です。

Agent編集画面では正しく動いているのに、
公開したWebアプリから質問すると、
以前のような回答が返ってきました。

原因は、

変更後のAgentを公開版へ反映していなかった

ことでした。

Difyでは編集内容自体は自動保存されますが、
公開Webアプリへ反映するには、

公開する
↓
更新を公開

が必要です。

変更後に挙動がおかしい場合は、
プロンプト以前に公開版が更新されているか確認した方がよさそうです。

---

使用モデルはGemini

LLMにはGemini APIを使用しました。

理由は前回と同じで、
個人の検証用途では無料枠を利用できるためです。

ただ、ここでも少し詰まりました。

---

Gemini 3.8

最初にDify上で選択できたGemini 3.8系を試しました。

しかし、自分の環境ではDify側にPythonのスタックトレースが表示され、
正常に回答できませんでした。

このときはエラー表示がすぐ消えてしまい、
最終的なエラーコードまで確認できませんでした。

そのため、

「Gemini 3.8自体が使えない」

とは判断していません。

あくまで、

今回のDify環境では正常に検証できなかった

という結果です。

---

Gemini 3.7

次に3.7を試しました。

こちらではエラー内容を確認できました。

503 UNAVAILABLE

This model is currently experiencing high demand.
Spikes in demand are usually temporary.
Please try again later.

モデル側が混雑していたようです。

---

Gemini 3.6

最終的にGemini 3.6 Flashへ変更しました。

すると、Notion MCPのツール呼び出しを含めて、
かなり安定して回答できるようになりました。

今回の検証では、
3.6を使用することにしました。

ただし、後で別の問題も起きました。

---

無料API枠は意外と早くなくなった

テストを何度も行っていると、
以下のエラーが出ました。

429 RESOURCE_EXHAUSTED

エラーを見ると、

GenerateRequestsPerDayPerProjectPerModel-FreeTier
quotaValue: 20
model: gemini-3.6-flash

となっていました。

自分の環境では、
その日の無料リクエスト上限に到達していました。

最初は、

「20回も質問していないのでは？」

と思いました。

しかし、Dify Agentでは、
ユーザーが1回質問しただけでも、

LLM
 ↓
どのツールを使うか判断

LLM
 ↓
検索結果を確認

LLM
 ↓
次のツールを判断

LLM
 ↓
最終回答

のように、
複数回モデルが呼ばれることがあります。

そのため、

ユーザーの質問1回
=
APIリクエスト1回

ではありません。

Agentを無料APIで試す場合は、
この点に注意した方がよさそうです。

---

モック議事録を用意してテストした

今回はAIで作成したモック議事録を2件用意しました。

大まかには、

2025年11月6日
研究室ミーティング議事録 001

と、

2026年1月15日
研究室ミーティング議事録 002

です。

中には、

• 研究進捗
• 教授からの指摘
• 決定事項
• ToDo
• 担当者
• 期限
• 次回までに確認すること

などを入れています。

単に1つの議事録から答えを探すだけでなく、
複数議事録をまたいだ質問もできるようにしました。

---

テスト結果

今回は10種類程度の質問を試しました。

1. 単一議事録からToDoを取得する

2025年11月6日のミーティングで、
佐藤さんに割り当てられたタスクは何？

結果として、

ユーザー履歴数別のPrecision/Recallを算出する
期限: 2025年12月19日
状態: 未着手

を取得できました。

さらに、
全員共通の進捗スライド作成タスクも取得できました。

---

2. 教授の指摘を探す

RAG関連研究について、
山田教授は何を指摘していた？

2025年11月6日と2026年1月15日の議事録を参照し、

• 単にRAGを使うだけでは新規性が弱い
• 研究室固有の議事録や実験ログを活用する
• 研究室内の継続的な議論や過去の意思決定を再利用する

といった内容を取得できました。

---

3. 複数議事録を時系列でまとめる

佐藤さんの研究について、
11月の指摘と1月の進捗を時系列でまとめて

この質問では、

11月
教授から「ユーザーを履歴数で分割して分析する」と指摘
 ↓
1月
実際に履歴数別で分析
 ↓
履歴の多いユーザーでは改善
履歴の少ないユーザーでは改善幅が小さい
 ↓
新たにメタ情報や人気度特徴量を試すよう指摘

という流れまで取得できました。

単純な検索だけではなく、
複数ページを横断して時系列に整理できています。

---

4. 方針の変化を聞く

11月から1月にかけて、
RAGチャットボットの方針はどう変わった？

これについても、

11月
研究室固有の議事録を利用する方針

↓

1月
実際にNotion + Difyでプロトタイプを作成

↓

日付・議題名・参照元などを表示する方針へ

と、複数議事録の内容をまとめることができました。

---

5. 人を起点にタスクを探す

田中さんが担当している作業を、
参照元の日付付きで教えて

この質問でも、
11月と1月の議事録から担当内容を取得できました。

---

6. 「最新」を判断させる

佐藤さんの研究について、
最新の山田教授の指摘は何？

最新の2026年1月15日の議事録を選び、

コールドスタート層について、

メタ情報や人気度特徴量を追加した条件でも評価する

という指摘を取得できました。

---

7. 決定事項をまとめる

2026年1月15日のミーティングで、
チャットボットについて決まった改善点をまとめて

回答では、

• 参照元の日付・議題を明確にする
• Notion側のプロパティを追加する
• ToDoや決定事項を読みやすく表示する
• 複数議事録を横断した質問をテストする

などを整理できました。

---

8. 複数議事録全体からまとめる

山田教授がチャットボットに求めていることを、
過去の議事録全体から整理して

このようなかなり抽象的な質問でも、
複数の議事録を参照しながら回答できました。

---

9. わざと間違った質問をする

ハルシネーションの確認として、
議事録に存在しない内容も聞いてみました。

鈴木さんがCNNの実験を担当していたよね？

これに対して、

いいえ。
鈴木さんが担当しているのはRAG関連研究の調査です。

議事録内にCNNの実験を担当しているという記載はありません。

という回答になりました。

ユーザーの質問に含まれる前提をそのまま肯定せず、
議事録を確認して否定できたのはよかったです。

---

10. 「前回」のような曖昧な表現

前回の会議で、
次回までに確認することは何だった？

これについても、
直近の2026年1月15日の議事録を参照し、

次回までに確認する項目を取得できました。

---

ただし、完全に正確というわけではなかった

全体としてはかなりうまく動きました。

ただ、細かく確認すると誤りもありました。

例えば、

佐藤さんの研究について、
11月の指摘と1月の進捗を時系列でまとめて

という質問では、

元の議事録で、

期限: 2026年1月22日

となっているタスクを、

期限: 2026年1月23日

と回答したことがありました。

つまり、

Notionから正しいページを取得できていても、
最終的な文章生成で値を変えてしまう可能性はある

ということです。

また、

• 教授の発言
• 他のメンバーの提案
• 決定事項

をまとめて回答するときに、
誰の発言なのかを少し強く解釈してしまうケースもありました。

そのため現在は、
システムプロンプトに以下のような制約も追加する予定です。

日付、期限、数値、担当者、状態などの具体的な値は、
取得した議事録に記載されている値をそのまま使用する。

推測や補完によって変更しない。

誰かの「指摘」「発言」「要望」として回答する場合は、
議事録でその人物の発言として明示されている内容だけを扱う。

決定事項、ToDo、メモ、他の参加者の提案を、
特定の人物の発言として言い換えない。

検索精度だけでなく、

検索後にLLMがどう要約するか

も確認する必要があります。

---

前回と比べて何が変わったか

前回と今回を整理すると、
かなり構成が変わりました。

項目	前回	今回
MCP Server	自作	公式Notion MCP Server
実装	Node.js / Express	公式実装を利用
通信	SSE	Streamable HTTP
エンドポイント	/sse /message	/mcp
MCP初期化処理	自分で対応	公式Server側
Notion認証	Notion API Key	NOTION_TOKEN
MCP Server認証	ほぼなし	AUTH_TOKEN
Notion権限	議事録DB	議事録DB + Read Only
検索	自作 search_notion	公式MCPのツール
ページ本文取得	自作が必要	retrieve-page-markdown
Dify	MCP接続	MCP HTTP接続
結果	接続できたがQAは不十分	複数議事録QAまで動作

特に大きかったのは、

「MCP Serverを自分で作る」部分をほぼなくせたこと

です。

前回はMCPそのものを動かすことでかなり時間を使いました。

今回は、

Notion
Render
Dify
Agentのプロンプト

の設定に集中できました。

---

公式MCPを使ってもエージェント設計は必要だった

今回作り直して、
前回から変わった部分と変わらなかった部分がありました。

公式MCP Serverを使うことで、

• MCP初期化
• JSON-RPC
• Notion APIとの接続
• 各種ツール実装

などはかなり楽になりました。

一方で、

どのツールを使うか
どんなキーワードで検索するか
どのページを読むか
いつ再検索するか
取得結果をどう回答へ使うか

はAgent側の問題です。

ここは公式MCPを使っても自動では解決しません。

今回も最初は、

検索1回
↓
見つからない
↓
終了

という動きをしました。

そのため、

MCP Serverの実装が楽になっても、エージェントのツール利用設計は必要

だと感じました。

---

結局、ChatGPTのNotion連携でよくない？

ここまで作っておいてですが、
一番思ったのはこれです。

個人で使うだけなら、ChatGPTのNotion連携でよいケースもかなり多いと思います。

自分のNotionへChatGPTを接続して、
過去のページについて質問するだけなら、
わざわざ、

Render
MCP Server
Dify
Gemini API

まで用意する必要がないケースもあります。

さらに今回、

「ChatGPTから間違えてNotionを書き換えられたら怖い」

とも考えました。

ただ、今回の運用では、
教授のNotionアカウント自体を議事録DBの読み取り権限にしています。

そのため、
教授側のNotion権限を適切に設定しておけば、
書き込みについてもNotion側で制限できます。

そう考えると、

自分だけで使う
↓
ChatGPT + Notion連携

の方がシンプルな場合は多そうです。

---

では、今回の構成を作る意味はあるのか

それでも、
今回のような専用チャットボットが使えそうな場面はあると思います。

例えば、

利用者
「Notionの連携設定とか分からない」
「AIのモデルとか分からない」
「とりあえずURLだけ欲しい」

という場合です。

今回の構成なら、
管理する側で、

• 参照するNotion DB
• 使用するMCPツール
• システムプロンプト
• 使用するモデル
• 回答形式

を設定しておき、

利用者には、

このURLを開いて質問してください

だけで使ってもらうことができます。

つまり、

ChatGPT + Notion

は、

利用者自身がAIとNotionを接続して使う

のに向いていて、

今回の、

Dify + Notion MCP

は、

管理者が設定した専用のAIを複数人へ渡す

用途では意味がありそうです。

研究室でも、

教授にDifyやMCPの設定方法をすべて説明するより、

このURLから過去の議事録について質問できます

と渡せる方が簡単です。

---

情報管理には注意する

今回は検証のため、
AIで作成したモック議事録を使用しました。

実際の研究室の議事録には、

• 未公開の研究内容
• 個人情報
• 論文投稿前の内容
• 共同研究に関する情報
• 特許につながる可能性のあるアイデア

などが含まれる可能性があります。

そのため、
実データへ切り替える前には、

• Notion側の共有範囲
• Notion Integrationの権限
• MCP Serverの認証
• 使用するLLM APIのデータ取り扱い
• ログに何が保存されるか
• Dify Webアプリの公開範囲・アクセス制御

などを確認する必要があります。

今回、

Notion Integration
→ 議事録DBだけ
→ Read Only

にしたのも、そのためです。

また、API Tokenや認証Tokenは、
記事・GitHub・スクリーンショットへ載せないように注意します。

---

今回学んだこと

今回作り直して感じたことは、
主に以下です。

1. 公式MCP Serverを使えるなら自作しない方がかなり楽だった

前回はMCP ServerをExpressで作ったため、
MCPそのものの実装でかなり詰まりました。

今回は公式実装を利用できたため、
アプリ側の構築へ集中できました。

MCPを勉強する目的なら自作にも意味がありますが、
単純にNotionと接続したいだけなら、
公式実装を使う方がかなり楽です。

---

2. MCPが動いてもAgentがうまく使えるとは限らない

MCPへの接続に成功しても、

AIが検索しない
検索1回で諦める
本文を読まずに回答する
検索語を細かくしすぎる

といった問題は起こります。

ツールだけでなく、
ツールを使うためのプロンプトも重要でした。

---

3. 「検索できた」と「正確に回答できた」は別

今回、
複数議事録を横断した回答までできました。

一方で、
期限が1日ずれるケースもありました。

つまり、

正しいページを取得する

ことと、

取得した内容を一字一句正確に回答する

ことは別です。

日付、期限、数値、担当者など、
間違えると困る値については、
より厳しくプロンプトを設定する必要があります。

---

4. モデルによってAgentの動きが変わる

今回、
モデルを変えるだけでも挙動が変わりました。

また、

• モデル側の混雑
• APIエラー
• 無料枠の上限

など、
自分のシステム以外の要因でも動かなくなることがあります。

AI Agentを実際に使う場合、
モデルの性能だけでなく、
安定性やAPI制限も考える必要があると感じました。

---

5. 専用AIを作る必要があるかは最初に考えた方がいい

今回一番大きな学びは、
これかもしれません。

作ること自体はできました。

ただ、

その問題、本当に専用システムを作る必要がある？

は最初に考えた方がいいです。

個人でNotionを検索したいだけなら、
既存のChatGPTのNotion連携などで十分かもしれません。

一方で、

• 複数人に同じ設定で使ってもらう
• 利用者に設定をさせたくない
• 参照範囲を管理側で固定したい
• 使用ツールを限定したい
• 回答ルールを統一したい

という場合には、
今回のような専用チャットボットにも意味があります。

---

まとめ

今回は、

Dify × 公式Notion MCPで研究室の議事録AIチャットボットを作り直しました。

前回は自作MCP Serverを使い、

Dify
↓
Express
↓
Notion API

という構成にしました。

接続自体はできたものの、
議事録QAとしてはうまく動かず、

「Knowledge方式の方がよいのでは？」

というところで終わりました。

今回は、

Dify Agent
↓
公式Notion MCP Server
↓
Notion議事録DB

へ構成を変更しました。

その結果、

• 特定日のToDo確認
• 教授の過去の指摘
• 最新の指摘
• 複数議事録をまたいだ時系列整理
• 過去からの方針変化
• 存在しない内容に対する否定

などまで回答できるようになりました。

一方で、

• Agentへのツール利用指示は必要
• LLMが日付や数値を間違える可能性がある
• モデルやAPI側のエラーも起こる
• 無料APIでは利用回数に制限がある
• 実データを扱う場合は情報管理が必要

といった課題も残っています。

そして、ここまで作ったあとで、

「個人で使うだけならChatGPTのNotion連携でよくない？」

とも思いました。

たぶん、それで十分なケースも多いです。

それでも今回のように、

設定済みの専用AIを、設定に詳しくない人へURLだけ渡して使ってもらう

という用途では、
Dify + MCPという構成も選択肢になると思います。

前回は「接続できたけれど議事録AIとしては不十分」というところで終わりました。

今回はようやく、

実際に議事録へ質問できるところまで作ることができました。

今後は実際の運用を想定しながら、
回答の正確性や情報管理についても確認していきたいと思います。