Notionは使うべき？公式アンバサダー円谷さんの答えを議事録651件で確かめた

出典: AI時代の今、Notionって使うべき？公式アンバサダーの円谷さんに相談してみた。

Notionに全部入れるか、Obsidianなどの手元のファイルへ移すか。どちらかに決めようとすると、迷いますよね。円谷さんは、個人ではClaude CodeとNotionを併用し、会社の情報はNotionへ集めていると語りました。

円谷さん（動画の中で・字幕・3:21〜）

「両方使ってます」

「普段やったタスクの記録だったりとか毎日の日記だったりとか」

「そういうデータはローカルには一切残っていなくて」

「Notionのサーバーにクラウド上に保管されているっていう状態で」

円谷さんの整理を、私は「誰が編集するか」で言い直します。置き場は、そこで決めます。チームで編集する情報はNotion。AIと一緒に育てる資産は、手元のMarkdown。二刀流でも、それぞれに役目がある形です。

共同で書き足す情報なら、参加する人が同じ場所を開けることを大事にしたいです。AIと育てる資産なら、人間とAIが同じファイルを見ることを大事にします。速さだけでは決められません。

私の議事録は、Nootaの文字起こしから作り、Notionの議事録データベースへ追記する流れです。全651件で、記録上の未完了は0件。必要なページに限って、Obsidianの保管庫にも保存しています。

手元のMarkdownは、人間とAI秘書の凛ちゃんが同じ保管庫を見る形です。結果として、私の手元も二刀流の形でした。

円谷さんは個人のタスクと日記をローカルに残さない運用です。私の議事録は、必要なページだけ手元にも保存しています。

→ 編集する人で分ける

手元のメモ、議事録、タスクを並べ、「チームで編集するもの」と「AIと育てるもの」に分けてみよう。両方に当てはまる情報には、普段どちらを編集するかも一言書きます。

Reiさんが語った「ワンテンポのラグ」。自分の仕事では何秒になるのか、知りたいですよね。Notionの議事録651件の一覧と、その中の1ページの本文。AI秘書の凛ちゃんに頼んで、私のNotionを読み取り専用で測ってもらいました。

Reiさん（動画の中で・字幕・2:56〜）

「1個ラグがあるというか そのページ読みに行ってって言ってから」

「ワンテンポやっぱ挟まるっていうのがあるので」

「ラグがあるのかなって体感では 思っているっていう感じだと思ってます」

待ちは数字に出ました。ただ、私は一覧を読む時間と、本文を読む時間を分けて考えます。何を読ませるかで、待つ長さが違うからです。

議事録データベースの全651件を100件ずつ読み切るまで、呼び出しは7回、合計4.91秒。7回それぞれの所要時間は0.57〜0.99秒でした。一覧を取るだけなら、この長さで済みます。AIに一覧をたどらせる仕事なら、この待ちが毎回かかります。

最新の1ページは、本文が274ブロックありました。全部読むには6回の呼び出しが必要で、合計2.65秒でした。1回で読めるのは100ブロックまでです。入れ子の中身を読むには、追加の呼び出しも必要になります。

比べるため、同じ本文をテキストにした手元のファイルを開くと、0.00007秒。Notion側は通信を含み、手元側は書き出し済みのファイルを開いただけです。どちらも1ページ・1回の計測で、平均ではありません。

人が1ページを開く場面と、AIに何ページも続けて読ませる場面では、この差の重みが変わる。待つ時間は、積み上がります。

仮に651件すべてがこのページと同じ大きさで、順番に同じ時間で読めるなら、単純計算で約29分。全件の本文を読んで測った時間ではありません。

Reiさんが語ったのは体感のラグです。私のNotionでは、一覧4.91秒、1ページの本文2.65秒という数字になりました。

→ 1ページの秒数を取る

AIに読ませたいページを1つ選び、読み取りを始める直前から、本文を全部取得し終えるまでをタイマーで測ります。ページを開く時間と本文を取り切る時間を混ぜず、条件も一緒に残そう。

円谷さんは、約半年のObsidian運用からNotionへ戻ったという話でした。理由はNotion AIの進化と、Claude CodeからAPIで読めるようになったこと。では、その返事をAIへ丸ごと渡すと、どのくらいの量になるのでしょう。

円谷さん（動画の中で・字幕・8:06〜）

「Claude CodeからNotionのデータも読み込めるように」

「MCP使わずにAPI叩けるようにとかなってきたので」

「Notionの方がそもそもUIとして入力しやすかったので」

「やっぱり戻ってきたみたいな感じの歴史が」

Notionへ戻った理由は、使いたいAIから情報を読めること。ここは私も外せません。ただし、読めることと、AIへ渡す量は別の話です。

欲しいのが議事録の本文なら、本文のテキストにして渡します。ページを取り出す時のデータ一式と、読むための文章。その量を比べてから決めたい。

同じ1ページの本文を取得したAPIの返事は328,381バイトでした。本文のテキストだけなら42,805バイト、15,871文字でした。

同じ本文でも、APIの返事はテキストの約7.7倍。ページの属性、つまり議事録データベースの項目のデータは、別に14,857バイトありました。

接続できたら終わり、にはしたくありません。本文を要約したいのか、日付や分類も使いたいのか。仕事に必要なものを選んで渡します。そのために、まず大きさを見ます。

今回測ったのはバイト数と文字数です。トークン数は測っていないので、約7.7倍という数字をトークン数やAIの処理時間の倍率には置き換えません。

私が足したのは、実際の1ページで比べたデータ量です。この数字を見て、本文を読む仕事にはテキストを選びます。

→ 本文の大きさを見る

読ませたいページを1つ選び、本文をコピーしてテキストファイルに保存します。文字数を数えられるエディターで開き、文字数を確認。AIへ渡したい文章が、どこまで入っているかも見ておこう。

AIに頼んだ仕事が増えると、自分の仕事とどう並べて見るかが気になります。円谷さんは、AIに同時並行で3つ頼む場面もあるそうです。その管理のために作ったのが、Notionと双方向に同期する「Lanes」です。

円谷さん（動画の中で・字幕・12:53〜）

「自分で手を動かす仕事とAIにお願いする仕事が」

「ぐっちゃぐちゃに混じってて」

「AIに同時並行で3つ仕事をお願いしてるみたいなことが ざらにあったりして」

AIに頼む数が増えるほど、何を頼んだか分からなくなる。だから私なら、AIに頼んだ仕事を「頼んだ」「待ち」「戻った」の3つに分け、1か所へ書きます。

頼んだ内容を探し直す時間が増えると、委ねた仕事の管理が自分へ戻ってくる。任せている間も、自分の仕事と並べて見られる形にしたいのです。

円谷さんは、Notionに「AIフラグ」を作り、Claude Codeでアプリを作ったそうです。レーンに「AI」を設け、自分の仕事とAIへ任せた仕事を1本の画面で見る。裏側は同じ1つのNotionデータベースです。

表示する形を変えても、記録の置き場は1つです。この作り方がよいと思います。AIの仕事用に別の記録を増やすより、同じ一覧で見渡せる。

円谷さんはアプリと双方向同期で管理しています。私は、まず今日頼んだ仕事を3つの状態に分けて書きます。1行ずつでも、自分が次に何をすればよいかを見られる形にしたい。

→ 頼んだ仕事を並べる

今日AIに頼んだ仕事を思い出し、「頼んだ」「待ち」「戻った」のどれかを付けて1行ずつ書きます。戻った仕事には結果の置き場も添え、今使っているメモの1か所で見られるようにしよう。

円谷さんは、AI側の競争は激しくても、貯めたデータは5年10年で大きく変わらないと見ています。つなぐAIが変わっても、情報を使い続けられる置き場。その話に重ねたいのが、私が使わない同期を撤去した記録です。

円谷さん（動画の中で・字幕・19:04〜）

「データの部分っていうのは 5年10年であんま変わんないんじゃないかなみたいに思っていたりして」

「Notion上にデータ貯めるっていうのさえ徹底しておけば」

「接続する側がいかに変わろうとも NotionのAPI自体はずっと提供してくれると思うので」

円谷さん（動画の中で・字幕・19:38〜）

「世の中の9割の企業は Notion使っておけば間違いないかなと思ってます」

データを貯め、つなぐ側が変わっても使い続けられるように、私は置き場は少ないほうがよいと考えます。更新されないコピーが増えると、どこを見るかまで管理する必要が出てくるから。

円谷さんは、Notion APIは今後も提供されると見ています。企業の9割はNotionでよい、GitやGitHubで管理を回せる会社はNotionにこだわりすぎなくてよい、とも語っています。

5月7日に、Pulse DBからNotionへの同期を完全に撤去しました。同期先の12個のデータベースのうち10個が40日間更新されず、形骸化していた状態です。

私の判断で、AI秘書の凛ちゃんが同期状態のテーブル6,006行と自動便3本を削除し、同期スクリプトをアーカイブしました。この情報はPulse DBの単独運用へ。

議事録のNotionは続けています。

円谷さんはNotionへの集約を勧めました。私が重ねるのは、実際に使う置き場を残し、使わない同期をやめるという判断です。

→ 使わない転記を見つける

同じ情報を別の場所へ写している同期や転記を1つ選び、最後の更新と、使っている人を確認します。止める前に元の情報と戻し方を確かめ、続けるか止めるかを決めよう。

Reiさんの相談は、動画編集チームでローカルとNotionにスキルが散らばっていることでした。円谷さんは、仕事の背景情報を貯める場所と、AIに作業を教えるスキルの場所を別に考える、という整理でした。ここが置き場を決める最後の要点です。

円谷さん（動画の中で・字幕・22:36〜）

「スキルはマークダウンファイルでローカルマシンかつ」

「GitHub管理に全部寄せちゃった方がいいのかなって思いました」

情報とスキルの置き場は別に考えます。私なら、チームで編集する情報、AIと育てる資産、スキルの3行を書き、それぞれの置き場を決めます。

円谷さんは、スキルをローカルのMarkdownとGitHub管理へ寄せることを勧めました。ローカルのスキルからNotionのデータを加工できても、Notion AIのスキルで手元の動画を編集するのは難しい。どこにある仕事を動かすかが理由です。

私の手元には、人間とAI秘書の凛ちゃんが同じVault、同じフォルダ、同じMarkdownを見る設計があります。人間がObsidianから見ても、AIがCodexやClaudeから見ても同じ状態。AI秘書だけが別の場所へメモを持つ問題を避ける形です。

Gitは難しく、自分でも全知識の15%ほどしか知らないと円谷さんは語りました。チームならNotion、ローカル作業もあるなら混ぜるというReiさんのまとめが、いちばん現実的だと思います。自分の仕事に合わせて決めよう。

→ 置き場を3行で決める

「チームで編集するもの」「AIと育てるもの」「スキル」の3行を書き、それぞれ現在の置き場を添えます。同じものが複数にあるなら、普段どこを更新するかも書いて、見る先を決めよう。

私なら、置き場を選ぶ前に、誰が編集するかを決めます。チームで触る情報はNotion、AIと育てる資産は手元のMarkdown。スキルの置き場は別に考え、使わない同期は見直す。

今日の1手は、AIに読ませたいページを1つ選び、本文をテキストで書き出して文字数を見ることです。私の1ページは15,871文字でした。自分の情報の大きさが見えれば、丸ごと渡すか、必要な範囲を選ぶかも決めやすい。移し替える前に、1ページから始めよう。