1. はじめに

普段の作業時間の記録にNotionを使っているのですが、作業時間をワンタップで記録したいのにNotionの標準UIだと操作が多くなりがちだと考えていました。

そこで、自分の使い方に特化したアプリを作ってNotionDBと連携させるアプリを個人開発していました。Next.js + Notion APIという構成で、自分のNotionワークスペースのDBを操作できる、自分専用のタスク管理アプリです。

しばらく自分だけで使っていたのですが、最低限の機能の実装ができたので他の人にも使用できる状態にしたいと考えています。

しかし現状は以下の通りです。

環境変数に自分のNotion Integration Tokenを直接書いている
環境変数に自分のDatabaseIDを直接書いている
アクセスした人が私のNotionを編集できてしまう状態のため、Googleログインで自分のアカウントだけアクセスを許可している

つまり、他人がログインできても、操作されるのは自分のNotionという状態です。これでは公開できません。

この記事は、開発中のアプリを他のユーザー自身のNotionを登録できるようにするまでの作業ログです。

2. 現状の課題

現状のアプリは、次のような構造になっています。

NOTION_TOKEN=ntn_xxxxxxx
DATABASE_ID=xxxxxxxxxx

GOOGLE_CLIENT_ID=xxx
GOOGLE_CLIENT_SECRET=xxx

他人がアプリにログインできたとしても、操作対象は私のNotionになってしまいます。また、Googleログインで自分のアカウントだけに絞っているのは他人に自分のNotionを触らせないためであり、複数ユーザー対応のための仕組みは何も入っていません。

3. 認証方式の検討

案A：ユーザーがNotion Integration Tokenを手動入力

ユーザー自身がNotion側でIntegrationを作成し、発行されたトークンをアプリに登録する方式

メリット：OAuthアプリの公開登録が不要で、実装がシンプル
デメリット：ユーザーがNotion Developer Portalでの作業を要求される

案B：Notion OAuthでログイン

Notionが公式に提供しているOAuth認証を使う方式。「Notionでログイン」ボタンをクリックすると、ユーザーは認証画面に飛ばされ、許可するとアクセストークンがアプリに渡される。

メリット：認証とトークン取得が同時に完了。ユーザーはボタンを押すだけ
デメリット：Notion Developer Portalで公開OAuthアプリを登録する必要がある

ユーザー体験を考えると、案Bが圧倒的に楽です。Notion Developer Portalでの作業はアプリ提供側が一度だけやれば済むので、ユーザーに負担を強いる案Aより明確に優れています。

~~また、現状すでにNextAuthでGoogleログインを実装しているので、Googleを Notion に差し替えるだけで実装できます。~~

（2026/7/7追記現在使用しているNextAuth v4ではNotion未対応のため、この方法では実装不可能です）

import NotionProvider from "next-auth/providers/notion";

これにより、Googleログインは廃止してNotionログインに一本化することにしました。

4. データ保存方針の検討

次に悩んだのが、取得したアクセストークンや選択されたDatabaseIDをどこに保存するかです。

比較

観点	セッション保存	外部DB
実装コスト	◎ 追加ライブラリ不要	△ DB設計・接続設定が必要
複数端末	△ 端末ごとに選び直し	◎ 自動復元
将来の拡張性	△ ユーザー設定を増やしにくい	◎ 設定項目を追加しやすい
障害リスク	◎ 外部依存なし	△ DBが落ちるとアプリに影響
維持コスト	◎ ゼロ	△ 無料枠を超えると課金
データの永続性	△ Cookie削除で消える	◎ 明示的に削除しない限り残る
セキュリティ管理	◎ NextAuthが管理	△ DB接続情報の管理が必要
ネイティブアプリ対応	✕ Cookie前提なので不可	◎ 問題なし

考慮した点は主に3つです。

1. 複数端末問題
私自身が複数端末（MacとiPhoneなど）からアプリを使うことを想定しています。セッション保存だと端末ごとにDBを選び直す必要がありますが、初回ログイン時に数秒選ぶだけなので許容範囲と判断しました。

2. アプリ化の予定
将来的にネイティブアプリ化する場合、セッション保存（Cookie前提）は使えなくなります。ただし、現時点では具体化していないので考慮から外しました。

3. シンプルさ優先
外部DBを入れると、DBのセットアップ、接続情報の管理、障害対応など、考慮事項が一気に増えます。今回はアプリが他人に使える状態にすることが目的なので、最小構成で進めることを優先しました。

5. 影響範囲の調査

認証まわり

src
├─ app
│  └─ api
│     └─ auth
│        └─ [...nextauth]
│           └─ route.ts 
└─ proxy.ts

Notionクライアント

src
└─ infra
   └─ notion
      └─ repositories
         ├─ getDBRecords.ts	
         ├─ getDBSchema.ts	
         ├─ getDBInfo.ts	
         ├─ postPage.ts	    
         └─ patchPage.ts	(既存レコードを更新)

呼び出し元

src
├─ app
│  ├─ page.tsx
│  └─ Calendar
│     └─ page.tsx	
└─ commons
   ├─ modal
   │  └─ utils
   │     └─ addData.ts
   └─ button
      └─ utils
         └─ pageDel.ts

6. まとめ

最終的な技術選定は以下のようになりました

認証

項目	選定	理由
認証プロバイダー	Notion OAuth（一本化）	認証とNotionトークン取得を同時に完結できる
認証ライブラリ	~~NextAuth v4（既存のまま）~~ -> Butter Authに移行	~~既存構成を活かせる~~ NotionProviderが標準対応

データ保存

項目	選定	理由
tokenの保存先	NextAuthセッション	外部DB不要でシンプル
DatabaseIDの保存先	NextAuthセッション

廃止

項目	理由
Google OAuth	Notion OAuthに一本化するため不要
固定の環境変数	セッション経由に変わるため不要

開発中のアプリのGitHubはこちら