NotionのToken Town：5回の再構築、100以上のツール、MCP vs CLI、そしてソフトウェア工場の未来 — NotionのSimon Last & Sarah Sachs

Notion（ノーション）は、2022年後半にGPT-4へのアクセスを得た直後からエージェント機能の開発を開始していた。しかし、当時はツール呼び出しの標準規格が存在せず、コンテキストウィンドウは短く、モデルの性能も不十分だった。Notionは独自のツール呼び出しフレームワークを設計し、ファインチューニングにも取り組んだが、製品として満足できる品質に達するまでに、機能を4〜5回にわたって再構築する必要があった。転機が訪れたのは2024年初頭、Claude 3.5 Sonnetや3.7 Sonnetといったモデルの登場である。これにより、エージェントの信頼性が飛躍的に向上し、Notionは「Custom Agents」として製品化に成功した。本エピソードでは、NotionのAIエンジニアリングを統括するSarah Sachs（サラ・サックス）と、AI基盤のアーキテクチャを主導するSimon Last（サイモン・ラスト）が、この長期にわたる開発の舞台裏、組織設計、評価（eval）哲学、そしてエージェントネイティブな未来像について詳細に語っている。

NotionのAI戦略の核心は、「Agent Lab（エージェント・ラボ）」のテーゼにある。これは、単に最先端のモデルをラップする「ラッパー」としての製品ではなく、人間のコラボレーションの本質を理解し、その上で適切なプロダクトシステムを構築するという考え方だ。Sarahはこれを、AWSの上に成り立つDatadogの関係に例える。AWSのCloudWatchも存在するが、Datadogは顧客がどのように可観測性を求めているかの専門家である。同様にNotionは、人々がどのようにコラボレーションしたいかの専門家であり、その専門性こそが持続可能な競争優位性（moat）であると主張する。この視点は、モデルが進化する方向性を読み、製品を準備しておく「川の流れを読む」戦略と、モデルの限界に逆らって無理に泳がないという規律によって支えられている。

0:00エージェント開発の歴史と「4〜5回の再構築」

Notionのエージェント開発は、2022年後半にGPT-4へのアクセスを得た直後から始まった。当時は「エージェント」という言葉すら一般的ではなく、「アシスタント」と呼ばれていた。最初の試みは、Notionの全機能にアクセスできるツールをモデルに与え、バックグラウンドで自律的に作業させるというものだった。しかし、この試みは何度も失敗に終わった。その原因は、ツール呼び出し（function calling）の標準が存在しなかったこと、コンテキストウィンドウが短すぎたこと、そしてモデル自体が「愚かだった」ことにある。Simonは、当時はMosaicMLやOpenAIと提携し、Notion独自の関数を呼び出すためのファインチューニングを試みたが、モデルが複数ターンにわたってツールを正しく使い続けることができなかったと振り返る。

最初のバージョンは、あらゆる操作をJavaScriptコードで記述させるコーディングエージェントだった。しかし、当時のモデルはコード生成の能力が低く、実用に耐えなかった。次に、ツール呼び出しの標準が存在しなかったため、独自のXMLフォーマットを開発した。このXMLはNotionのデータモデル（ブロック構造）を完全に表現できるように設計されたが、モデルがこのフォーマットを学習しておらず、プロンプトで教え込む必要があった。この経験から、Simonは「モデルが何を望んでいるかを理解し、それに合わせる」という重要な教訓を得た。その結果、XMLからMarkdownへと移行し、データベースクエリについてもNotion APIの複雑なJSONフォーマットを捨て、モデルが得意とするSQLiteクエリを採用した。この「モデルに複雑さを押し付けない」という哲学が、その後の開発の基盤となっている。

8:07組織設計と「Token Town」の文化：低エゴとスウォーム

Sarah Sachsが率いるAIチームの文化は、彼女が「Token Town」と呼ぶ独特の原則に基づいている。最も重要なのは、リーダーシップの役割はアイデアを出すことや技術的な決定を下すことではなく、チーム全員が目的を理解し、優先順位をつけるためのリソースを提供し、自分たちが重要だと考えることに取り組むための手段を与えることだという考え方だ。彼女は「最高のアイデアのほとんどはプロトタイプから生まれる」と語り、すべてのアイデアが自分やプロダクトパートナーの承認を通過しなければならないという階層的な構造は、チームの速度を損なうと指摘する。

この文化を支えるのが、「自分たちのコードを削除することに抵抗がない」低エゴのチームである。Notionでは、AIチームのハーネス（エージェントを動かすための基盤システム）はこれまでに3〜4回再構築されている。これは、モデルの進化に合わせてアーキテクチャを根本から見直す必要があるからだ。Sarahは、この文化はSimonとIvan（NotionのCTO）から来ているとし、新しいメンバーが「これは自分が書いたコードだから変えたくない」と言い出さない環境が自然に形成されていると説明する。また、組織構造は「出荷した後」に決めるという原則も重要で、プロジェクトの境界は非常に緩く、エンジニアは正式な報告ラインとは異なるチームで働くことが日常的に行われている。セキュリティレビューも、開発の初期段階から巻き込むことで、後になってから発生する摩擦を大幅に削減している。

16:39評価（Eval）と「Model Behavior Engineer」という新しい役割

Notionの評価哲学は、単なる品質保証を超えている。Sarahは、評価を「テスト」と同列に語ることを戒め、3つの異なるレイヤーを定義する。第一に、CI（継続的インテグレーション）に組み込まれた回帰テストであり、これは一定の確率内でパスしなければならない。第二に、製品をローンチするための「ローンチ品質評価」であり、特定のユーザージャーニーにおいて80〜90%のパス率を目標とする。そして第三に、最も興味深い「フロンティア/ヘッドルーム評価」である。これは意図的にパス率を30%程度に設定した評価で、モデルの能力がどこに向かっているのかを把握するために設計されている。NotionはAnthropicやOpenAIと協力し、この「Notion's Last Exam（Notion版ラスト試験）」の構築に専任のチームを割り当てている。

この評価体系を支えるのが、「Model Behavior Engineer（MBE）」という新しい役割である。MBEは、ソフトウェアエンジニアリングのバックグラウンドを持たない人材も積極的に採用している。その起源は、SimonがGoogle Sheetsで手動で評価を行っていた時代に遡り、言語学の博士課程中退者やスタンフォード大学の比較文学専攻の新卒者など、多様なバックグラウンドを持つ人材が集まった。彼らの役割は、モデルの出力を手動で検査することから始まり、現在ではエージェントを使って評価自体を自動生成したり、LLMジャッジ（モデルによる評価）を構築したりするまでに進化している。Sarahは、この役割はデータサイエンティスト、プロダクトマネージャー、プロンプトエンジニアの要素を併せ持ち、モデルの能力の限界を見極める「職人技と直感」が求められると説明する。Notionは、この評価システム自体を「エージェントハーネス」として捉え、エージェントがデータセットのダウンロードから評価の実行、失敗の分析、修正の実装までをエンドツーエンドで行えるようにする取り組みを進めている。

36:48MCP vs CLI：Notionのツール統合戦略

エージェントが外部サービスと連携する方法として、MCP（Model Context Protocol）とCLI（コマンドラインインターフェース）の2つのアプローチが存在する。Simonは、CLIに対して明確な強気の姿勢を示す。その理由は、CLIがターミナル環境で動作するため、ページネーションやカーソル移動といった高度な操作が可能であり、プログレッシブディスクロージャー（段階的な情報開示）が本質的に備わっている点にある。さらに重要なのは、CLIが「自己ブートストラップ可能」であることだ。エージェントがツールの実行中に問題に遭遇した場合、同じ環境内でコードを修正し、デバッグし、自分自身を修復できる。例えば、エージェントがブラウザを持っていなければ、自分でChromium APIをラップしたブラウザツールを100行のコードで生成できる。一方、Chrome DevTools MCPでは、トランスポートが壊れた場合、エージェントは自分を修復する手段を失う。

しかし、MCPにも明確な利点がある。特に、狭く軽量なエージェントが必要な場合や、厳格な権限管理が求められる場合に有効だ。MCPは本質的に強いパーミッションモデルを持ち、エージェントが呼び出せるのは定義されたツールのみに限定される。CLIはAPIトークンの取り扱いなど、セキュリティ上の課題がより複雑になる。Sarahは、Notionとしての立場を明確にする。Notionはエンタープライズワークの「システム・オブ・レコード」であることを使命としており、MCPが業界で使われている限り、自社のMCPサーバーをサポートし続けると述べる。また、価格設定の観点からも、MCPとCLIの使い分けは重要だ。言語モデルに依存して決定的なタスクを実行させるのはトークンコストの無駄であり、CLIを使ってコードでAPIを呼び出す方がはるかに効率的で決定論的である。Notionは内部的に、ツール、エージェント、APIコールを抽象化する統一的なレイヤーを持ち、MCPと自社ビルドの両方を統一的に扱えるようにしている。

46:48エージェントハーネスの進化とプログレッシブディスクロージャー

Notionのエージェントハーネス（エージェントを駆動する基盤システム）は、5回の再構築を経て劇的に進化した。初期は、すべてのロジックを1つの巨大なプロンプトに詰め込み、少数のFew-shot例を与える方式だった。しかし、このアプローチはスケールしなかった。新しいツールを追加するたびにシステムプロンプトが肥大化し、モデルの品質が低下した。また、Few-shotの順序に敏感で、上位にある例ほどモデルに強く影響するという問題があり、プロンプトの編集は5〜6人の少数のエキスパートに限定されていた。転機は、Few-shotから「ツール定義」への移行と、プログレッシブディスクロージャーの導入だった。

現在のハーネスでは、各ツールは独立した定義を持ち、エージェントは必要に応じてツールを動的に検索・選択できる。これにより、ツールの所有権を各プロダクトチームに分散させることが可能になった。現在、Notionのエージェントは100以上のツールにアクセスできるが、システムプロンプトは可能な限り短く保たれている。Simonは、このプログレッシブディスクロージャーこそが、Notionが「トップ・オブ・ザ・クラス（クラスのトップ層）」に向けて製品を作るという哲学の現れだと説明する。つまり、誰でも簡単に使えるように抽象化するのではなく、パワーユーザーがシステムを深く理解し、カスタマイズできるようにすることを重視している。エージェント自身が自分のシステムプロンプトを生成し、失敗した場合は自分でデバッグして修正する「自己修復」機能も、この哲学の延長線上にある。設定画面とチャット画面を一体化した「Flippy」と呼ばれるUIも、エージェントとの対話を通じてすべての設定を行えるようにするための設計だ。

1:10:49Meeting Notes：データキャプチャとしての戦略的価値

Notion Meeting Notesは、単なる文字起こし・要約ツールではない。Sarahはこれを「データキャプチャ」の問題として捉えている。会議で交わされた会話は、組織にとって最も価値の高いシグナルの一つであり、それをNotionのシステム・オブ・レコードに取り込むことが、エージェントの性能を飛躍的に向上させる。例えば、Sarahは自身のパフォーマンスレビューを、マネージャーとの1on1のMeeting Notesを振り返ることで作成している。会議で話題にならなかったことは、おそらく重要ではなかったという判断だ。このように、Meeting Notesは単なる記録ではなく、組織の優先順位を可視化するツールとして機能する。

技術的には、Meeting NotesはNotionのエージェント基盤と深く統合されている。要約は単なるテンプレートではなく、エージェントが参加者を特定し、発言の中で言及された人物を認識してメンションする。これにより、例えば「Simonがこのプロジェクトについて話している」という通知がリアルタイムで届く。この機能は、人物間の類似性キャッシュやプロファイル情報を活用して実現されている。また、Meeting Notesの普及は、Notionの検索インフラに大きな負荷と変化をもたらした。テキスト量の爆発的な増加に対応するため、コンパクション（圧縮）技術が開発され、エージェントが長文コンテンツを効率的に処理できるようになった。Sarahは、Meeting NotesがNotionの最大の成長ループの一つであり、バイラルな採用と高いリテンションを生み出していると評価する。将来的には、カスタムエージェントが会議中にタスクデータベースを直接更新するなど、よりシームレスなワークフローが構想されている。

結びに

本エピソードが最も強く印象づけるのは、AIプロダクトの構築において「モデルの進化を待つ」ことと「先回りして準備する」ことの絶妙なバランスの重要性である。Notionは2022年からエージェントに取り組み、4〜5回の再構築を経てようやく製品として成立させた。この経験は、単に「Reasoningモデルが登場したからうまくいった」という単純な話ではない。モデルの能力が追いつくまでの間、Notionは独自のツール呼び出しフレームワークを設計し、ファインチューニングを試み、そして「モデルが何を望んでいるか」を徹底的に理解するプロセスを繰り返した。この「川の流れを読む」能力と、組織としての低エゴな文化こそが、Notionを単なる「ラッパー」から、真の「Agent Lab」へと押し上げている。

また、評価（eval）に対する考え方の深さも特筆に値する。単なる品質テストではなく、モデルの未来の能力を測る「フロンティア評価」を設定し、そのために「Model Behavior Engineer」という新しい職種を創設した。これは、AIプロダクトの開発がソフトウェアエンジニアリングだけでは完結しないことを示している。さらに、MCPとCLIの議論、Meeting Notesを「データキャプチャ」として捉える視点、そして「ソフトウェアファクトリー」という長期的なビジョンは、Notionが単なるプロダクティビティツールから、エージェントが人間と協働するための「システム・オブ・レコード」へと進化しようとしていることを明確に示している。このエピソードは、AIエンジニアにとって、製品戦略、組織設計、技術アーキテクチャのすべてにおいて、実践的な教訓に満ちている。

要点

• NotionのCustom Agentsは、2022年から開発が始まり、ツール呼び出しの標準不在やモデルの性能不足により、製品化までに4〜5回のアーキテクチャ再構築を経た。決定的なブレークスルーは2024年初頭のClaude 3.5 Sonnetの登場だった。
• NotionのAI戦略の核心は「Agent Lab」テーゼであり、AWS上のDatadogのアナロジーで説明される。Notionはモデルのラッパーではなく、人間のコラボレーションに関する専門知識を持つプラットフォームである。
• Sarah Sachsが率いるAIチームは「Token Town」文化を採用し、リーダーはアイデアを出すのではなく、目的を明確にし、チームが低エゴで「スウォーム（群がる）」できる環境を作る。コードを削除することへの抵抗感がなく、組織構造は出荷後に決める。
• Notionの評価体系は3層構造を持つ。回帰テスト、ローンチ品質評価、そして意図的にパス率30%に設定された「フロンティア/ヘッドルーム評価」である。後者はモデルの能力の未来を測るために設計されている。
• Notionは「Model Behavior Engineer（MBE）」という新しい職種を定義した。MBEはソフトウェアエンジニアリングのバックグラウンドを持たない人材も含み、モデルの行動分析、評価の設計、失敗のトリアージを担当する。
• Simon LastはCLIに強気であり、その自己ブートストラップ能力（エージェントが自分自身をデバッグ・修正できる点）を高く評価する。一方、MCPは狭く軽量なエージェントや厳格な権限管理が必要なユースケースに適している。Notionは両方をサポートする。
• Meeting Notesは単なる文字起こしツールではなく、組織の「データキャプチャ」として戦略的に位置づけられている。会議の内容をシステム・オブ・レコードに取り込むことで、エージェントの検索やワークフロー自動化の基盤となる。
• Notionは基盤モデルの訓練には消極的だが、検索とランキング（retrieval/ranking）には積極的に投資している。エージェントからの検索トラフィックが人間からのそれを上回り始めており、クエリの構造や求められる結果が人間向けとは根本的に異なるためである。