0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

複数のAIから連携して読み書きできる「AI会話データベース」をNotionに作った話

0
Posted at

スクリーンショット 2026-07-12 11.23.23.png

複数のAIから読み書きできる「AI会話データベース」をNotionに作った

何に困って、何をつくったか

  • Claude / ChatGPT / Cursor を並行して使っていると、会話ログがサービスごとに分断されて、その上後から探せない。端末もAIのアカウントもばらけている
  • そこで、Youtubeのあるチャンネルで紹介されていた情報を参考にして、Notionに「AI会話ログ」DBを1つ作り、各AIからMCP経由で読み書きできるようにした
  • DBのスキーマ設計もレコード登録もAI自身にやらせるので、こちらは自然言語で頼むだけ
  • 「どのAIとの会話か」を列で持たせておくと、AIをまたいだ知見の引き継ぎができる(Cursorに「Claudeと話した内容をNotionから読んで」とか頼めるのだよ)

背景:AIが増えるほど、会話が迷子になる

自分はインフラ寄りのエンジニアをしていて、

  • サーバー(CentOS / Ubuntu、Proxmox VE と VMware ESXi AWS混在)の運用
  • CVEが出るたびの影響調査・パッチ適用のトリアージ
  • AWS周りの設定、Terraformなど運用スクリプトのコーディング

といった作業を、Claude / ChatGPT / Cursor(2端末・複数アカウント) を使い分けながら進めています。

この体制でしばらく経ち困ったのがこれです。

「あのCVEの調査、どのAIとどこで話したっけ?」

  • カーネルCVEの影響範囲は Claude と詰めた
  • 検証スクリプトは Cursor で書いた
  • Postfix周りの相談は ChatGPT でもClaudeでもやった

……という状態になり、知見が3つのサービスに散らばって、しかも横断検索する手段がない。さらに困るのは、Cursorで作業しているときに「Claudeとの会話で決めた方針」を参照したいのに、コピペするしかないこと。

そこで、AIの外側に共通の記憶置き場を1つ作るという方針にしました。それが Notion の「AI会話ログ」DBです。

構成としてはこうなります。

          ┌─────────┐   ┌──────────┐   ┌────────┐
          │ Claude  │   │ ChatGPT  │   │ Cursor │
          └────┬────┘   └────┬─────┘   └───┬────┘
               │  MCP / コネクタ           │
               └────────────┬──────────────┘
                            ▼
                 ┌──────────────────────┐
                 │  Notion「AI会話ログ」DB │
                 │  タイトル / AI / 日付   │
                 │  トピック / 概要 / URL  │
                 └──────────────────────┘

ポイントは、Notion側は「ただのDB」でしかないということ。AI固有の仕組みを使わないので、明日また新しいAIが増えても、そこにMCPを繋げば同じ輪に入れます。


Step 1. Claude から Notion に接続する

まずは1つのAIで動かします。Claude(Web/デスクトップ)の場合、設定 → コネクタ から Notion を追加してOAuth認証するだけ。

接続できたかどうかは、こう聞くのが手っ取り早いです。

notionに接続できるか試して

Claudeが notion-get-users などを叩いて、ワークスペースのユーザー情報を返してくれれば疎通OK。

注意(後で必ずハマるところ)
Notion側の「コネクトの管理」で、対象のページ/DBにそのインテグレーションを接続しておく必要があります。閲覧だけできて書き込みで失敗する場合、たいてい構文ではなく権限(後述)。


Step 2. DBは「AIに作らせる」

ここが一番ラクなところで、スキーマを自分で設計してポチポチ作る必要はありません。目的を伝えれば提案してくれますし、大体の枠組みを手動で作っておけば、あとからAIがよしなに修正してくれます。自分で作るのがかったるければ

ここで調べたことの履歴を、Notionでデータベースにして管理したい。
プライベート領域に作って。スキーマ案があれば提案して。

実際に返ってきた案がこれでした(ほぼそのまま採用)。そもそも自分はこれまでNotionを使ったことがないので、お任せ。

プロパティ 用途
タイトル Title 会話(セッション)の見出し
日付 Date 会話した日
トピック Multi-select インフラ / セキュリティ / 開発 / メール基盤 / その他
概要 Text 何を話して何が結論だったか
主な成果物 Text 作ったスクリプト、決めた方針など
参考URL URL 元の会話スレッドへのリンク

Notion MCP は SQLライクな DDL でDBを作れるので、AIは内部的にこういうリクエストを投げているらしい。

CREATE TABLE (
  "タイトル"   TITLE,
  "日付"       DATE,
  "トピック"   MULTI_SELECT('Notion連携':purple, 'インフラ':blue,
                            'セキュリティ':red, '開発':green,
                            'メール基盤':yellow, 'その他':gray),
  "概要"       RICH_TEXT,
  "主な成果物" RICH_TEXT,
  "参考URL"    URL
)

後から列を足したくなったら、これも会話で足せます(実際「AI」列や「プロジェクト」列は後付けしました)。

ADD COLUMN "AI" SELECT('Claude':orange, 'ChatGPT':green, 'Cursor':blue);
ADD COLUMN "プロジェクト" RICH_TEXT;

記録の粒度は「1会話(セッション)=1レコード」に。メッセージ単位だと細かすぎて後から探せず、日単位だと粗すぎるので、スレッド単位がちょうどよかった。

過去の会話もまとめて流し込める

Claudeには過去チャットを検索するツール(conversation_search / recent_chats)があるので、

このプロジェクトにある過去の会話を、全部このDBに登録して

と頼めば、過去スレッドを1件ずつレコード化してくれます。自分の場合は約40スレッドが(ちょっと時間がかかってトークンは消費するけど)一気に入りました。

ただし実運用してわかった制約があります。

  • 過去に遡って登録するために検索できるのは「今いるプロジェクトのスコープ内」だけ。別プロジェクトの会話は、そのプロジェクトを開いて同じ依頼を繰り返す必要がある
  • conversation_search が返すのは**関連度の高い断片(チャンク)**であって、完全な逐語録ではない。なので本文には「会話抜粋(取得できた範囲)」と断り書きを入れて貼るのが誠実
  • 稀に、安全フィルタの都合で内容を取得できない過去スレッドもあるらしい(自分の場合1件該当)

Step 3. 他のAIからも同じDBに繋ぐ

ここからが本題です。同じNotion DBに、他のAIからも繋ぎます。

ChatGPT

Notionコネクタ(またはMCPサーバーの追加)から、同じNotionワークスペースを認証します。読み取りだけでなく書き込み権限を許可するのを忘れずに。

Cursor

Cursorは MCP 設定ファイルにリモートMCPサーバーを書くだけ。プロジェクト直下の .cursor/mcp.json(またはグローバルの ~/.cursor/mcp.json)に:

{
  "mcpServers": {
    "notion": {
      "url": "https://mcp.notion.com/mcp"
    }
  }
}

初回にブラウザでOAuth認証が走り、以降はCursorのAgentから notion-search / notion-fetch / notion-create-pages などが使えるようになります。

UIやエンドポイントの仕様は変わりやすいので、実際に設定するときは各サービスの最新ドキュメントを確認してください(本記事は2026年7月時点)。

端末・アカウントが複数でも問題ない

Cursorを2台の端末で、別アカウントで使っていても、Notion側のワークスペースが同じであれば同じDBを見に行きます。「どの端末で作業したか」は本質的に重要ではなく、知見がどこに集約されているかだけが重要になりますが、一応「Cursor」「Cursor2」とAI名を区別して、どの端末からかわかるようにしました。


Step 4. 「どのAIとの会話か」を判別できるようにする

全AIが同じDBに書き込むようになると、当然こうなります。

このレコード、誰(どのAI)が書いたやつだ?

なので、判別用の列を持たせます。自分は最終的にこの3点セットに落ち着きました。

役割
AI Claude / ChatGPT / Cursor / Cursor2(Select型。色分けすると一覧で一目瞭然)
プロジェクト Claudeのプロジェクト機能名や、案件名。作業の文脈でグルーピングできる
参考URL 元スレッドへのリンク。Claude/ChatGPTは会話URLが取れる

そして各AIに、運用ルールを1行のカスタム指示として入れておきます

会話をNotionの「AI会話ログ」DBに登録するときは、
必ず「AI」列に自分の名前(Claude / ChatGPT / Cursor /Cursor2)を入れること。

Claudeならプロジェクトのカスタムインストラクション、ChatGPTならカスタム指示、Cursorなら .cursorrules / Rules に書いておけば、以降は自動で埋まります。

ちなみに初期は「Cursor: 〜」「ChatGPT: 〜」とタイトル先頭にプレフィックスを付けて運用していたのですが、タイトルで判別するのは検索・フィルタに弱いので、専用列に切り出すのをおすすめします。


Step 5. AIをまたいで知見を連携させる

ここまで来ると、当初の目的が達成できます。

Cursorでコードを書いているとき:

Notionの「AI会話ログ」DBから、CVE-XXXX-XXXXX 関連のレコードを検索して、
決まっている対応方針を踏まえた上で検証スクリプトを書いて

Cursorは Claude との会話で決まった方針をNotionから読み取り、それに沿ったコードを書きます。コピペによる文脈の運び直しが不要になったのが、体感としていちばんいい感じ。履歴がどこかにいってしまったと、あちこちのAIの会話歴を探す必要もなし。

ChatGPTに相談するとき:

Notionの「AI会話ログ」DBで、プロジェクト=「脆弱性対応」のレコードを一通り読んで、
未完了のタスクだけ一覧にして

Claudeに引き継ぐとき:

Notionの会話ログのうち、AI=Cursor のレコードを見て、
先週書いたスクリプトの続きから作業したい

要するに、Notion DBが「AI共通の長期記憶」になり、各AIはそこに読み書きする短期記憶のワーカーになるという役割分担。AIを乗り換えても、知見は残るというわけ。


サンプル:実際のDB一覧

こんな感じで、複数AIの会話が1つのテーブルに集合します(内容はサンプルに置き換えています)。

qiita-image-store.s3.ap-northeast-1.amazonaws.com_0_190485_c67cf7de-100c-4d1d-94ce-ba0a4e9b3b5e.avif

「AI」列で色分けされているので、どの知見をどのAIと作ったかが一覧で追えます。Notion側では「AI」でグルーピングしたビューや、「トピック」でフィルタしたビューも作っておくと便利です。


実運用のTips

1. 書き込み失敗は、たいてい構文ではなく権限

insert_content などで「No approval received」系のエラーが出たときは、SQLやプロパティ名を疑う前に Notion側のインテグレーション接続設定を見てください。自分の場合、DB側を「複数のAIから書き込める」設定に直したら一発で通りました

2. 日付プロパティは型プレフィックスが要る

Notion MCP でページを作るとき、日付は素直に "日付": "2026-07-12" では入りません。

{
  "date:日付:start": "2026-07-12",
  "date:日付:is_datetime": 0
}

3. Multi-select はJSON文字列で渡す

{"トピック": '["セキュリティ","インフラ"]'}

4. SQLの戻り値のページIDはハイフンなし

notion-query-data-sources で取れるページIDは 397c73ad13fc8135b316f1aff6cfc5db のようにハイフンなしで返ってきます。notion-update-page に渡すときは UUID形式(8-4-4-4-12)に整形が必要らしい。

5. 一括登録はレート制限に当たる

細かい話だけど40件・100件と一気に投げるとレート制限で落ちます。バッチを分けて、間に少し待ちを入れる方針にしてもらうのがいい(AIに「レート制限に配慮して分割して」と伝えれば調整してくれる)。しつこいけどトークン消費に注意。

6. 機密情報は入れない

これは当然ですが、サーバーのホスト名・IP・認証情報などはそのままDBに書かないルールにしておくべき。複数のAIサービスからアクセスされる場所なので、記事化・共有の可能性も含めて、書く粒度は最初に決めておくのがいい。


まとめ

Before After
会話がClaude/ChatGPT/Cursorに分散 Notionの1DBに集約
「どこで話したっけ?」で毎回探す タイトル・トピック・日付で横断検索
AIをまたぐ文脈はコピペで運ぶ 各AIがDBを直接読む
AIを乗り換えると知見がゼロリセット 知見はNotion側に残る

AIの記憶に頼るのをやめて、AIの外側に記憶を置く。 そして、その記憶の管理自体もAIにやらせる。これだけで、複数AI運用のストレスがかなり減った。

Notion MCP が使えるAIなら同じ仕組みに乗せられるので、使っているAIが3つ以上ある人にはおすすめ。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?