なんとなく、あれ、最近のNotionってなんか使いにくい？と感じている人が増えてきているようなのだけど、じつはAI時代においてNotionの強みが打ち消されてしまってきているという話だと思っているので、その解説記事を書く。

最初に結論

なぜNotionはAI 時代の勝者とならないのか、という問いに最初に答えると、次のようになる。

  • NotionのBlock構造がAIへの知識供給への妨げになっているから
  • 成果物とドキュメントが近いところにあるのが重要になったから。Notionは遠い、Devinは近い
  • ドキュメンテーションは、人と人とがコラボレーションするより、人とAI、またはAIが自動的に作成したほうが効率がよくなったから

NotionのBlockとはなにか

NotionのBlock構造とはなにか。少し詳しいひとは「Notionのリッチテキストを表現できるデータ構造である」と答えるかも知れない。それで正しいのだが、NotionのBlockとは、実はNotionのビジョンであり、ビジネスモデルなのである、というところから話を展開したい。

Notionの1ドキュメント=Pageというのは、「ブロック」という最小単位の集合でできている。テキスト、画像、テーブルなど、すべてのオブジェクトが「ブロック」という最小単位の集合でできている。

Notionを、ブロックが無限に入った箱だと想像してみてください。作りたいものを、何でも好きなように作りましょう。LEGOのお城がたくさんのLEGOブロックでできているように、Notionのページはたくさんの「ブロック」を組み合わせて作り上げられます
https://www.notion.com/ja/help/what-is-a-block
ブロックとは – Notion (ノーション)ヘルプセンター
Notionを、ブロックが無限に入った箱だと想像してみてください。作りたいものを、何でも好きなように作りましょう。LEGOのお城がたくさんのLEGOブロックでできているように、Notionのページはたくさんの「ブロック」を組み合わせて作り上げられます 🧱
Notion

ごくシンプルな例だと、Notionの中で「見出しレベル2」として定義された緑色の見出し」は次のようなデータ構造になる。

{
  "heading_2": {
    "rich_text": [
      {
        "type": "text",
        "text": {
          "content": "これは見出しです",
          "link": null
        },
        "annotations": {
          "bold": false,
          "italic": false,
          "strikethrough": false,
          "underline": false,
          "code": false,
          "color": "green"
        },
        "plain_text": "これは見出しです",
        "href": null
      }
    ],
    "color": "default"
  }
}

結局データ構造の話なのか、と思うかもしれないが、Blockが重要である、という話は、じつはNotionのCEOをはじめとする経営チームみずから繰り返し強調してきたことでもある。

Notion Story (Notion Founding Story, Founder, How Was Notion Built, Valuation Total Users, Revenue) - Notionavenue
Discover the success story of Notion, the all-in-one workspace tool that has become a go-to for personal productivity and team collaboration. Read about its founding, how it was built, its valuation, total users, and revenue in this comprehensive breakdown.
Notion AvenueGiorgia Dalla Valle
Notion’s product-market fit journey
Akshay Kothari, COO and co-founder of Notion, discusses the company’s path to product-market fit.
Sandhya Hegde

なぜNotionにとってBlockがデータ構造以上に重要な位置づけなのか、それはNotionユーザーへの価値提供と直結しているからである。どういうことか。

次の画像はNotionのブロック一覧の一部であるが、じつにさまざまなブロックが提供されている。

0:00
/0:13

ユーザーはこの1つ1つのブロックを "LEGOのように" 組み合わせられるので、1つブロックが増えるたびに1つ便利になる、という以上の、掛け算の価値が創出される仕組みになっている。

💡
BlockはNotionの発明品なのか？

このデータ構造そのものはNotionの発明品や、専売特許ではないと思う。乱暴にいえば、要するにHTML+CSSのJSON化なのだ。ただし、このような複雑なデータ構造をNotionアプリというユーザーインターフェースで完璧に隠蔽したこと、データの同期をリアルタイムで行い、多人数のコラボレーションが可能になるまでのユーザー体験を高い次元で完成させたのはNotionの発明だと考えている。

これは私見だが、Notionがここまで偉大なプロダクトとなったのは、データ構造とプロダクトのコアバリューが垂直統合されていること、さらには開発チームの在り方、ひいては経営までもが垂直統合されていることにあると考えている。さらに余談であるが、こうしたアプローチは（偉大な先行事例がありながら）日本国内ではほとんど見ることがないし、スタートアップの優位性として評価されることもないのだろうと思うと歯がゆい気持ちである。

話を本筋に戻す。

なぜBlockはAIリーダブルではないのか

マシンリーダブルという言葉は馴染みがあると思う。よく引き合いに出されるのがDXの文脈で、日本のDX化が遅れている理由のひとつとして、さまざまな重要データがマシンリーダブルではない、ということが指摘されている。XMLやJSON、HTML、CSVのような適切な構造化データであればよいが、いわゆる神エクセルのようなデータフォーマットは、ヒューマンリーダブル（これもあやしいが、、、）であってもマシンリーダブルではない。

AI時代においてはどうだろう。AIは曖昧なデータ構造の意味解釈に優れているので、例えばXMLやJSONの構造が多少INVALIDであっても読んでくれる可能性が高い。神エクセルについては、もしかするとエクセルそのものよりもスクショを提供してOCRで読んでもらったほうが人の解釈に近いかもしれない。さておき。

NotionのBlockは100%マシンリーダブルである。にも関わらずAIリーダブルではないと評するのは、情報に対して構造が複雑すぎることと、それにともなうコンテクスト長の長大化にある。

例えば、ごくシンプルな見出しと箇条書きで構成される文章があったとする。

## これは見出しです

- 箇条書きひとつめ
- 箇条書きふたつめ

これをNotionのブロック構造で表現すると（おおむね）次のようになる。

[
  {
    "object": "block",
    // "id": "...", (実際のブロックID)
    "type": "heading_2", // H2見出しに対応
    "heading_2": {
      "rich_text": [
        {
          "type": "text",
          "text": {
            "content": "これは見出しです",
            "link": null
          },
          "annotations": { // 太字、イタリックなどの書式設定
            "bold": false,
            "italic": false,
            "strikethrough": false,
            "underline": false,
            "code": false,
            "color": "default"
          },
          "plain_text": "これは見出しです",
          "href": null
        }
      ],
      "is_toggleable": false, // トグル可能か否か
      "color": "default" // 文字色
    }
    // ... その他のメタデータ
  },
  {
    "object": "block",
    // "id": "...", (実際のブロックID)
    "type": "bulleted_list_item", // 箇条書きリストの項目に対応
    "bulleted_list_item": {
      "rich_text": [
        {
          "type": "text",
          "text": {
            "content": "箇条書きひとつめ",
            "link": null
          },
          "annotations": {
            "bold": false,
            "italic": false,
            "strikethrough": false,
            "underline": false,
            "code": false,
            "color": "default"
          },
          "plain_text": "箇条書きひとつめ",
          "href": null
        }
      ],
      "color": "default"
    }
    // ... その他のメタデータ
  },
  {
    "object": "block",
    // "id": "...", (実際のブロックID)
    "type": "bulleted_list_item", // 箇条書きリストの項目に対応
    "bulleted_list_item": {
      "rich_text": [
        {
          "type": "text",
          "text": {
            "content": "箇条書きふたつめ",
            "link": null
          },
          "annotations": {
            "bold": false,
            "italic": false,
            "strikethrough": false,
            "underline": false,
            "code": false,
            "color": "default"
          },
          "plain_text": "箇条書きふたつめ",
          "href": null
        }
      ],
      "color": "default"
    }
    // ... その他のメタデータ
  }
]

お分かりいただけるだろうか。Notionが裏で扱っているデータはこれほど複雑なのである。

参考までに、HTMLで表現した例を示しておく。

<h2 class="text-2xl font-bold mb-4">これは見出しです</h2>
<ul class="list-disc pl-5 space-y-1">
  <li>箇条書きひとつめ</li>
  <li>箇条書きふたつめ</li>
</ul>

これらを、OpenAI APIの提供するTokenizerにかけて比べてみる。結果を以下にまとめる（TokenizerはGPT-4oを利用）

フォーマット トークン 文字数
Notion Block (JSON) 609 1994
Markdown 29 34
HTML 71 133

もちろん、スタイリングと構造化文書を分離して扱うのがMarkdownの特徴であるから、Markdownが軽量なのは言うまでもないことである。HTML例も、Notionの表現力と比べると簡素であり、Notionにとってフェアな比較にはなっていない点は差し引いて考えておく必要がある。

しかしながら、Notionが扱っているデータは、HTMLやMarkdownと比較したときに5倍から10倍程度の量になっている。非常にシンプルな見出しや箇条書きですらこれなので、より複雑なBlockの場合、さらに増える。トークン、ざっくり言うと文字量が多ければ多いほど、AIのコストは嵩み、入出力が遅くなる。最近は受け入れ可能なコンテクスト長が拡大傾向にはあるが、あくまでコストと引き換えに、である。

また、ドキュメントは読むだけではなく書くことも必要だ。AIがNotionのドキュメントを書くには、Blockという複雑な構造を正確に出力しなければならない。Notion MCPのユースケースが思ったよりも限定され効果を発揮していないように思えるのは、おそらくこのことと無関係ではない。

💡
AIによるNotionライティング

AIがNotionのデータ構造を直接取り扱う場合は、Blockの複雑さと向き合う必要がある。いっぽうで、AIがWebブラウザをつうじてNotionにドキュメントを記述するアプローチをとる場合、この限りではない（人間の使用感に近い）。しかし、ブラウザ操作系AIはレンダリングされた見た目を解釈するというよりHTML構造を解釈したほうが効率がよいため、やはりデータ構造がシンプルになっているほうが取り扱いやすいだろう。

AI時代のドキュメンテーション

最近面白い動きがある。生成AIの活用の場面として、自然言語（ドキュメント）からプログラミングができる、ということが非常に大きな可能性のある分野になっている。しかしごく最近は、コードから質の高いドキュメンテーションを生成する、というアプローチが拡がりはじめている。その筆頭がDevinのWiki機能だ。

Devin Wiki - Devin Docs
Architecture diagrams, documentation, links to sources, and more for all your repos
Devin Docs

Devin Wikiは、Devinが参照できるリポジトリのコードベースを解釈し、機能の解説をしたり、依存関係、アーキテクチャ図、システムフロー図の記述など、じつにさまざまな観点でドキュメントを生成してくれるものである。本稿執筆時点で、すでに人間が記述可能な質と量を凌駕しているようにも思える。仕様書が書ければプログラミングは不要になる、かに見えたが、プログラミングができれば形式的な仕様書を書く技能は不要になるかもしれない。自分でも何をいっているかよく分からない。

DevinにしてもCursorにしてもそうだが、AI時代の開発において、コードベース（成果物）とドキュメントが近くにある、AIに取り扱いやすくなっている、ということが大切になっている。AIがドキュメントを参照しながらコードを書き、書いたコードに合わせてドキュメントを更新する、というワークフローの生産性が非常に高いためだ。このワークフローは現状Notionではできないか、コストが高い。コストが高い理由は、データ構造がAIにとっては複雑であることと、Notionという独立した空間にあることにある。

データ構造だけに着目しても、ほとんど素のMarkdownに近いObsidianのようなアプローチのほうがAI時代には有利に働くだろう。コラボレーションを必要としない個人のナレッジベースであればなおのことそうで、実際にObsidianとAIを掛け合わせてナレッジベースとしている例も見聞きする。

Obsidian - Sharpen your thinking
The free and flexible app for your private thoughts.
Obsidian

ドキュメンテーションは重要であるが（強調！）、それ自体を販売したり公開するでもない場合、どこまでいっても中間生成物である。社内に完璧なドキュメントを整備しても、ユーザーの課題が解決するわけではない。にも関わらずドキュメンテーションの重要性が説かれているのは、プロダクトやチームの成長に必要不可欠であるから、ということに他ならないが、上述のDevin Wikiなどは、コードアーキテクチャが整備されていればあとからドキュメンテーションは生成可能であり、自動的にコードの変化に追従する陳腐化しないドキュメントの可能性を既に示唆している。NotionのドキュメントはAIが読み書きしにくく、手元にない。すなわち、AIフレンドリーではない。

NotionにおけるBlockの存在はただのデータ構造やAPI仕様ということにはとどまらずプロダクトの哲学にまで及んでいることから、データ構造を軽量にすればよい、というものではない可能性もある。例えば複雑にネストや埋め込みされたドキュメントをMarkdownに出力するにしても、どこまでをひとまとまりとして出力するか、という問題が付いて回る。これはNotionだけではなくNotion likeなリッチドキュメンテーションツール全般がはらんでいる課題でもある。

本稿では、恐れ多くもNotionのデータ構造という観点から、AI時代におけるNotionを取り巻く状況について私見を述べてみた。当然のことながらこれほど優れたプロダクトをつくるNotionのチームにおいては、ここで僕が考えたことなどとうに織り込み済みであると思う。Notionがこれからどのように進化していくのか、楽しみに待ちたい。