当サイトではアフィリエイトプログラムを利用して商品を紹介しています。掲載リンクからご購入いただいた場合、当サイトに報酬が発生することがあります。

Notionの外部連携で「ページが見つかりません」と出たとき|エラーは原因を教えてくれない

黒い門にかかった南京錠。Notionの外部連携で権限が足りずアクセスできないことを表したアイキャッチ

Notionを外部のツールとつなぐとき、最初にぶつかるのがこのエラーです。

Could not find page with ID: ...——ページが見つかりません、というやつですね。

検索すると「インテグレーションにページを共有してください」という答えが山ほど出てきます。それで直ることも多いのですが、共有しても直らないときに、次に何を見ればいいのかが書かれていません。

実際にNotionのAPIを叩いて、どんなときに何が返ってくるのかを測りました。結論を先に言うと、このエラーメッセージは原因を区別していません。だから、メッセージを読んでも切り分けられません。

エラーメッセージは、原因を区別してくれない

まず、いちばん誤解を生んでいるところから。

存在しないIDでも「共有を確認しろ」と言われる

実験として、明らかに存在しないIDを指定して、ページを取りに行きました。全部ゼロのIDです。

返ってきたのは404で、メッセージはこうでした。「そのIDのページが見つかりません。関連するページとデータベースがインテグレーションに共有されているか確認してください」。

存在しないIDなのに、共有を確認しろと言われます。そもそも存在しないのだから、共有のしようがありません。

つまり、404は3つの状態をまとめている

このメッセージが返るとき、実際には次のどれかが起きています。どれであっても同じ文面です。

  • そのIDのページが存在しない(打ち間違い、別ワークスペースのID)
  • 存在するが、インテグレーションに共有されていない
  • 存在して共有もされているが、IDをコピーする場所を間違えている

共有したのに直らない、という相談の多くは1つ目か3つ目です。ところがメッセージが2つ目しか示唆しないので、共有の設定を何度もやり直すことになります。

切り分けは、この順番でやる

メッセージが当てにならないので、自分で順番に潰します。上から順にやると、たいてい3つ目までで原因が分かります。

1. IDの形式を疑う前に、形式は気にしなくていい

最初に安心してほしいのがここです。IDはハイフンありでも、ハイフンなしでも、どちらでも通りました。

ハイフンを入れた32桁と、ハイフンを抜いた32桁の両方で同じページを取りに行って、どちらも成功しています。「ハイフンの有無が原因かもしれない」という線は、最初に消していいということです。

気をつけるのは、前後に空白や改行が混ざっていないかだけです。URLからコピーすると、末尾に余計な文字が付いてくることがあります。

2. ページなのか、データベースなのかを確かめる

ここが3つ目の原因、つまり「IDをコピーする場所を間違えている」に効きます。

Notionのデータベースと、その中の1行(ページ)は、見た目が似ているのにAPIでは別物です。取り違えると、専用のエラーが返ります。

データベースのIDを、ページを取るAPIに渡したときの返りがこれでした。404ではなく400で、メッセージは「指定されたIDはデータベースであってページではありません。データベース取得のAPIを使ってください」。

逆に、ページのIDをデータベース取得のAPIに渡すと、「指定されたIDはページであってデータベースではありません」と返ります。

つまり400が返ったら、共有の問題ではありません。エンドポイントを取り違えているだけなので、呼び出し先を変えれば直ります。ここは親切に教えてくれる部分です。

3. 共有されているかを、検索で確かめる

404のままなら、次は共有です。ただし共有の設定画面を見に行く前に、APIの検索を1回叩くほうが早い。

検索のAPIは、インテグレーションに共有されているものしか返しません。逆に言えば、検索して出てくれば共有済み、出てこなければ未共有です。ページ名の一部で検索すれば、数秒で判定できます。

この方法のいいところは、共有の設定画面を開かずに、プログラム側から確認できることです。連携がうまくいかないときに、まずこれを流すと切り分けが速くなります。

4. ゴミ箱に入っていないかを確かめる

意外に多いのがこれです。誰かがページを削除していて、でもゴミ箱には残っている状態。

この場合、APIからは普通に取得できてしまいます。エラーにならないので、かえって気づきにくい。詳しくは後半で書きます。

返ってきたコードで、見る場所が決まる

切り分けを表にすると、こうなります。まず何番が返ったかを見れば、疑う先が1つに絞れます。

返り 意味 次に見る場所
400 ページとデータベースの取り違え 呼び出しているエンドポイント。共有は無関係
404 存在しない/未共有/IDの写し間違い 検索APIで名前を引く。出れば共有済み
200だが中身が変 ゴミ箱に入っている 削除済みの項目がオンになっていないか

この表の1行目を知っているだけで、詰まる時間がかなり減ります。400は共有と無関係なのに、エラーが出ると反射的に共有設定を見に行ってしまうからです。

図にすると、こういう順番です

「ページが見つかりません」が出たときの順番 ① 400が返っていないか 400ならエンドポイントの取り違え。共有は無関係 ② 検索APIで名前を引く 出てこなければ未共有。出てくれば共有済み ③ IDの前後の空白を消す ハイフンの有無は原因にならない ④ ゴミ箱を見る 消してもAPIは返す。エラーにならない 404のメッセージは 「共有を確認しろ」しか言わない 存在しないIDでも同じ文面が返る。 だから文面を読んでも原因は絞れない。 共有をやり直しても直らないときは、 たいてい①か③が原因。 ①と②はプログラムから判定できるので、 設定画面を開く前にここを流す。 実際にAPIを叩いて確かめた挙動です。
実際にNotion APIへ各パターンを投げて、返りを記録した結果です。

共有は、いちばん上の親に1回だけでいい

共有の範囲について、勘違いされやすいところがあります。

親に共有すれば、子も孫も見える

試しに、インテグレーションに共有した親ページの下に、子ページを作り、さらにその下に孫ページを作りました。子にも孫にも、個別の共有は一切していません。

結果は、子も孫も、そのまま取得できました。検索にも出てきます。

つまり共有は、そのページ以下すべてに効きます。ページを増やすたびに共有し直す必要はありません。

だから「連携用の親ページ」を1つ作るのが楽

この性質を踏まえると、設計はシンプルになります。外部ツールと同期させたいデータベースを、1つの親ページの下にまとめてしまう。そしてその親ページだけをインテグレーションに共有する。

あとからデータベースを増やしても、その親の下に作れば自動的に連携の対象になります。共有し忘れによるエラーが、構造的に起きなくなります。

逆に、あちこちのページに個別に共有していると、どこを共有したのかが分からなくなります。連携が増えるほど、この管理が重くなっていきます。

置き場所によって、こう変わる

どこを共有するかで、あとの手間と危険が変わります。

共有する場所 追加時の手間 見える範囲
連携用の親ページ1つ その下に作るだけ その親の配下だけ
データベースごとに個別 作るたびに共有 共有したものだけ
ワークスペースの最上位 不要 ほぼ全部

1行目が扱いやすさと安全のバランスが取れています。3行目は一見楽ですが、あとから増えたページも自動で対象になるので、時間が経つほど範囲が広がります。

裏を返すと、共有範囲は思ったより広い

便利な反面、これは注意すべき性質でもあります。

ワークスペースの上のほうにあるページを共有してしまうと、その配下にある全部が外部ツールから見えるようになります。あとから誰かがその下に機密のページを作れば、意識しないまま連携の対象に入ります。

共有するのは、できるだけ下の階層にする。「とりあえず一番上」は、あとで効いてきます。

削除したページは、連携先からは消えていない

ここは実際に外部ツールと同期していると刺さる話です。

ゴミ箱に入れても、APIからは取得できる

ページを1つ作って、削除しました。画面上はゴミ箱に入って、一覧から消えます。

その状態でAPIから取得したところ、エラーにならず、普通に返ってきました。中身も残っています。違いは、削除済みであることを示す項目がオンになっていることだけです。

同期先に消えたはずのデータが残る原因

外部ツール側で「削除されたら消す」という処理を入れていない場合、これが効いてきます。Notionで消したのに、連携先のスプレッドシートやデータベースには残り続けます。

しかもエラーは出ません。取得できてしまうので、処理は正常に流れます。気づくのは、数字が合わなくなったときです。

連携を組むときは、削除済みの項目を見て、そのときに同期先からも消す分岐を必ず入れておきます。取得できたかどうかだけで判断すると、この抜けに気づけません。

完全に消すと、今度は404になる

ゴミ箱から完全に削除すると、今度はIDが存在しなくなるので404が返ります。そしてそのメッセージは、最初に見たあの「共有を確認しろ」です。

つまり、連携先で急に404が出始めたら、共有を疑う前に誰かがゴミ箱を空にしていないかを確認したほうが早いことがあります。

インテグレーションから見えるのは、ページだけではない

権限の話です。トークンを外部のサービスに渡す前に、知っておいたほうがいいことがあります。

ワークスペースのメンバー一覧が取れる

ユーザー一覧のAPIを叩いてみたところ、ワークスペースに参加している人の名前が返ってきました。共有したページとは関係なく、です。

ページの共有範囲を絞っていても、誰が所属しているかは見えます。社名やチーム構成が分かる名前を使っている場合、それも含めて相手に渡ることになります。

他に入っているインテグレーションも見える

同じ一覧に、そのワークスペースに追加されている他のインテグレーションも並びました。名前もそのまま出ます。

どんなツールと連携しているかが分かる、ということです。競合のツール名が見えることもあります。

だから、トークンを渡す相手は選ぶ

ここまでを踏まえると、判断の基準はこうなります。

自分で作った自動化に使うトークンなら、問題は小さい。一方で、外部のサービスに登録する形で渡すトークンは、ページの中身に加えて、メンバー構成と連携先の一覧まで渡していることになります。

信頼できる相手かどうかを、ページの共有範囲だけで判断しないほうがいいです。共有していないものまで見えています。

連携を始める前に決めておく3つ

ここからは、実際に組む前の準備です。あとから直すのが面倒な順に並べています。

1. 連携用の親ページを1つ作る

まず、ワークスペースに新しいページを1つ作ります。名前は「外部連携」など、用途が分かるものにします。

そのページを開いて、右上のメニューから接続の設定を開き、使うインテグレーションを追加します。これで共有は完了です。

あとは、外部ツールと同期させたいデータベースを、このページの下に作る、または移動します。すでにあるデータベースを移動する場合は、サイドバーでドラッグするか、ページのメニューから移動先を指定します。

移動したあと、必ず1回APIから取得して確認してください。移動が反映されるまで少し時間がかかることがあります。

2. トークンの置き場所を決める

インテグレーションのトークンは、そのワークスペースの共有範囲すべてにアクセスできる鍵です。パスワードと同じ扱いをします。

具体的には、ソースコードに直接書かない。環境変数か、パスワード管理ツールに置いて、そこから読み込む形にします。

特に気をつけるのが、GitHubなどにコードを上げるときです。一度上げてしまうと、消してもコミットの履歴に残ります。上げる前に、トークンが混ざっていないかを検索してください。

3. 削除をどう扱うかを決める

前半で書いたとおり、削除済みのページもAPIからは取得できます。だから、連携を組む時点で決めておきます。

削除済みの項目がオンのものを、同期先からも消すのか。それとも印を付けて残すのか。前者なら処理はシンプルですが、間違って消したときに連携先からも消えます。後者なら復旧しやすい代わりに、同期先が増え続けます。

どちらでもかまいませんが、決めずに組むと「消したのに残っている」状態になります。これがいちばん気づきにくい不具合です。

最初の1回は、小さく試す

いきなり本番のデータベースでつながずに、テスト用のページを親の下に1つ作って、そこで一通り試します。

取得できるか、検索に出るか、削除したらどう返るか。この3つを確認しておけば、本番で何か起きたときに、どこを見ればいいかが分かります。

よくある質問(FAQ)

共有したのに「ページが見つかりません」が直りません。

共有以外の原因の可能性が高いです。まず返ってきたのが404か400かを見てください。400ならエンドポイントの取り違えで、共有とは無関係です。404なら、検索のAPIでそのページ名を引いてみてください。出てくれば共有はできているので、IDの前後に余計な文字が入っていないかを確認します。

IDはハイフンありとなしのどちらで書くべきですか。

どちらでも通ります。ハイフンを入れた形と抜いた形の両方で同じページを取りに行って、どちらも成功しました。ハイフンの有無は原因になりません。ただし前後に空白や改行が混ざると失敗するので、そこだけ確認してください。

データベースの中の1行を取りたいのですが、どのAPIを使いますか。

データベースの中の行は、APIではページとして扱われます。ページ取得のAPIを使ってください。データベース自体のIDをページ取得に渡すと400が返り、「これはデータベースです」と教えてくれます。逆も同じで、取り違えは400で分かります。

子ページも1つずつ共有する必要がありますか。

必要ありません。親ページを共有すれば、その下にある子も孫も取得できます。実際に3階層作って、個別の共有なしで一番下まで取得できることを確認しました。連携用の親ページを1つ作って、その下にまとめるのがおすすめです。

Notionで削除したのに、連携先にデータが残ります。

削除してゴミ箱に入っただけのページは、APIから普通に取得できます。エラーにならないので、同期処理はそのまま流れます。取得したデータの中に削除済みを示す項目があるので、それを見て同期先からも消す分岐を入れてください。ゴミ箱から完全に削除すると、今度は404になります。

トークンを外部サービスに登録しても大丈夫ですか。

渡る範囲を理解したうえで判断してください。共有したページの中身に加えて、ワークスペースのメンバー一覧と、そのワークスペースに入っている他のインテグレーションの名前も取得できます。共有範囲を絞っていても、この2つは見えます。

共有するページは、どの階層にするのがいいですか。

できるだけ下の階層です。上のほうを共有すると、その配下すべてが対象になります。あとから誰かがその下に機密のページを作った場合、意識しないまま連携の対象に入ります。連携用の親ページを1つ作って、必要なものだけをその下に置く形が安全です。

まず、連携用の親ページを1つ作る

つなぐ前に置き場所を決めておくだけで、共有し忘れのエラーは起きなくなります。テスト用のページを1つ作って、取得・検索・削除の3つを試すところから始めてみてください。

Notionを使ってみる

上部へスクロール