NotionのToken Town：5つの再構築、100以上のツール、MCP対CLI、そしてソフトウェアファクトリーの未来 — NotionのSimon Last & Sarah Sachs | AIニュース最前線

ロンドンに参加できなかった方々、来週マイアミでお会いしましょう！ 知識作業のためのデカコーン企業であるNotionは、ChatGPT以前からAIツールの構築を進めており、2023年のQ&A機能、2024年の統合AI、そして2025年の会議ノートなど、多くのヒット作を生み出してきました。最後のMakeユーザーカンファレンスの終了時、Ryan NystromはNotion 3.0のカスタムエージェント（Custom Agents）を予告し、ついにエージェントラボのプレイブックを採用しました！ NotionのSarah SachsとSimon Lastが、カスタムエージェント（Custom Agents）の構築方法、なぜ正しく動作させるまでに数年と複数の再ビルドが必要だったのか、そして生産性ツールをエンタープライズワークのためのエージェントネイティブな記録システムに変えることが何を意味するのかについて、詳細に解説します。 私たちは、今日のソフトウェアにおいて最も野心的なAI製品取り組みの一つの背景にある、プロダクト、エンジニアリング、評価（evals）、価格設定、組織設計の決定を内部から探ります。2022年の初期のツール呼び出し（tool-calling）実験での失敗から、エージェントハーネス、プログレッシブツール開示、データキャプチャとしての会議ノート、そしてソフトウェア工場とエージェント型作業の長期ビジョンに至るまでを扱います。 私たちが議論する内容： - Notionカスタムエージェント（Custom Agents）のローンチに至るSarahとSimonの道のりと、その機能が本番環境で利用可能になるまでに4回または5回の再ビルドが必要だった理由 - 初期のエージェント試みが失敗した理由：ツール呼び出し（tool-calling）の標準化の欠如、短いコンテキストウィンドウ、信頼性の低いモデル、そしてモデルに露出されすぎた複雑さ - 「エージェントラボ」のテーゼ：単なるモデルのラップではなく、人々がどのように協力するかを理解し、最先端の能力（frontier capabilities）围绕する適切な製品システムを構築すること Notionがロードマップのタイミングをどう捉えているか：モデルの制約に逆らって泳ぐのではなく、モデルが準備できたときに製品が利用可能になるよう、十分に早い段階で構築すること なぜコーディングエージェントはAGIの核のように感じられるのか、そしてSpec（仕様策定）、コード記述、テスト、デバッグ、レビュー、コードベースの維持をエージェント同士で協力して行う「ソフトウェア工場」についてNotionがどのように考えているか SarahがNotionでAIエンジニアリングを率いている様子（「Token Townからのノート」）：アイデアの所有権よりも目標設定を重視し、自分の成果を削除することに抵抗のない低エゴ（自己主張の低い）チーム、そして急速に変化する機会に群がって対応するよう設計された文化 「Simon Vortex（ソモン・ヴォルテックス）」、社内ハッカソン、そしてなぜセキュリティ対策を後ではなく早期に導入するのか NotionがAIをどのように組織化しているか：中核的なAI機能とインフラ、製品パッケージングチーム、そしてすべてのプロダクト表面（ユーザーインターフェースや機能面）が人間だけでなくエージェントに対しても機能するよう、ますます強く求められている会社全体の指針 プロトタイプが社内でより簡単に作成可能になった理由、そして社員の誰もが毎日使用するツールであるNotion内で、「メモよりもデモ」が製品開発をどのように変化させているか Notionの評価（eval）哲学：回帰テスト、リリース品質の評価、そしてモデルの能力がどこに向かっているかを把握するためにあえて約30%の成功率に留める「フロンティア/ヘッドルーム」評価 「Model Behavior Engineer（モデル行動エンジニア）」とは何か、そしてなぜNotionは評価の作成、失敗分析、モデル理解を単なるソフトウェアエンジニアリングではなく、独立した機能として扱っているのか コーディングエージェント時代のソフトウェアエンジニアの役割の変化、そして新しい仕事がコードをタイプするものではなく、厳格な外部エージェントシステム、プルリクエスト（PR）、検証ループを監督するものに似ている理由 「ソフトウェア工場」がどのように機能すべきか：仕様、自己検証、バグフロー、サブエージェント、そして重要な不変条件を維持しつつ人間の介入を最小限に抑える方法 コワーキングスペースの入居者申請を処理するNotionカスタムエージェントのライブデモ：メールのトリアージ、ウェブ検索による申請者の情報充実、そして構造化データをNotionデータベースへの書き込み Noton内でのエージェントの組み合わせ：プリミティブとしての共有データベース、他のエージェントを呼び出すエージェント、数十人の専門的なエージェントを監督する「マネージャーエージェント」、そしてページとデータベースとして単純に実装されたメモリ MCP対CLIに関するNotionの見解：SimonがCLIの自己デバッグ機能に楽観的な理由、MCPが依然として意味をなす場所、そしてSarahが能力、決定論、権限付与、価格整合性についてどのように考えているか Notion内部のエージェントハーネスの進化：初期のJavaScriptコーディングエージェントからカスタムXMLへ、MarkdownやSQLライクな抽象化へ、ツール定義、プログレッシブ・ディスクロージャー、そしてはるかに短いシステムプロンプトへ Notionが「クラストップ」の教育を重視する理由：すべての人のために能力を過度に抽象化するのではなく、洗練された運用者を対象とした構築 エージェントのセットアップは現在どのように機能しているか：権限に関するガードレールを設けつつ、自身を設定し、自身の失敗を検証し、自身の指示を編集できるエージェント。 Notionがカスタムエージェントをどのように価格設定しているか：トークン、モデルタイプ、サービングティア、ウェブ検索、将来のサンドボックスコストを抽象化したものとしてのクレジット；なぜ使用量ベースの価格設定が必要だったのか；そして「自動」モードがどのように適切なモデルを適切なタスクにマッチさせようとしているか。 なぜNotionは基盤モデルのトレーニングに積極的でないのか、現在どこでファインチューニングや最適化を行っているのか、そして検索の多くが人間ではなくエージェントから行われるようになると、取得（retrieval）やランク付けが最も重要な投資領域の一つとなる理由。 なぜ「ミーティングノート」がNotionの最も強力な成長ループの一つになったのか：単なる文字起こしとしてだけでなく、検索、カスタムエージェント、フォローアップワークフロー、そして企業コラボレーションのための広範な記録システムを駆動する高信号データキャプチャとして。 なぜNotionはハードウェア自体を構築することよりも、コラボレーションデータが存在する場所になることに興味を持っているのか、そしてウェアラブルやその他のキャプチャデバイスが最終的にどのようにそのシステムにフィードバックする可能性があるか。 Sarah Sachs LinkedIn: https://www.linkedin.com/in/sarahmsachs X: https://x.com/sarahmsachs Simon Last LinkedIn: https://www.linkedin.com/in/simon-last-41404140 X: https://x.com/simonlast 完全なビデオエピソード タイムスタンプ 00:00:00 導入およびNotionカスタムエージェントのローンチ 00:01:17 なぜNotionはエージェントを4回、あるいは5回も再構築したのか 00:03:35 現在のモデルだけでなく、モデルが向かっている方向に向けて構築すること 00:05:32 エージェント・ラボの仮説、ラッパー、そしてプロダクトの直感 00:08:07 ユーザー・ジャーニー、リーダーシップ、そして低エゴのAIチーム 00:13:16 サイモン・ボルテックス、ハッカソン、そして早期のセキュリティ導入 00:16:39 チーム構成、メモよりデモ、そしてエージェント向けの構築 00:20:25 評価（Evals）、Notionの最終試験、そしてモデル・ビヘイビア・エンジニアの役割 00:27:37 エージェント・ハーネスとしての評価、そしてソフトウェアエンジニアの役割の変化 00:30:42 ソフトウェア・ファクトリー：仕様、検証、そしてエージェントのワークフロー 00:32:18 ライブデモ：コワーキングスペース向けのカスタムエージェント 00:35:08 エージェントの構成、マネージャー・エージェント、そしてページとしてのメモリ 00:38:15 Notion Mail、Gmail、ネイティブインテグレーション、そしてツール 00:39:43 MCP対CLI、そして機能のコスト 00:44:13 NotionがMCPを使用する場合と独自インテグレーションを構築する場合 00:47:43 Notionのエージェント・ハーネス再構築の歴史 00:55:35 パワーユーザー、公開ツール、そしてセットアップ・エージェント 00:58:01 自己修正型エージェント、権限、そして「flippy」 01:01:13 価格設定、クレジット、そして適切なモデルの自動選択 01:09:01 Notionが独自のフロンティアモデルをトレーニングしない理由 01:14:07 エージェント向けに構築された検索：取得、ランキング、そして検索 01:17:27 会議メモをデータキャプチャとワークフロー自動化として活用 01:21:18 ウェアラブル、ハードウェア、そして記録システムとしてのNotion 01:23:45 結びの言葉 トランスクリプト [00:00:00] アレッシオ：みなさん、こんにちは。Latent Spaceポッドキャストへようこそ。Kernel Labsの創業者であるアレッシオです。今日はLatent Spaceのエディターであるswyxをお迎えしています。 [00:00:11] swyx：こんにちは。こんにちは。アレッシオがシモンとサラ（Notion）のために用意してくれた美しいスタジオに戻ってきました。ようこそ。 [00:00:18] サラ・サックス：お招きいただきありがとうございます。 [00:00:19] アレッシオ：お招きいただきありがとうございます。はい。 [00:00:20] swyx：最近のカスタムエージェントのローンチ、ついに公開されましたね。いかがお感じですか？ [00:00:26] サラ・サックス：私たちはものをゆっくりとリリースします。なので、少しの間アルファ版（初期公開版）として提供しており、その時点では製品化に向けて準備を整えるチームと、次の機能を開発する別のチームがいます。 そのため、時にはこれらのローンチの満足感が少し遅れることもあります。なので、自分が行ったすべての作業を思い起こすのはとても良いことです。なぜなら、私たちは往々にして2つから3つのマイルストーン先を見据えてしまう癖があるからです。ああ、そうせざるを得ないのです。ご機嫌斜めにならず、油断してはいけませんから。しかし、人々がこれがいかに役立つかを理解してくれたのは素晴らしいことです。 そして、今日のAIツールの構築は、2年や3年前よりも全体的に容易になっていると思います。人々はそれを理解し始めているので、ユーザー教育という点では、無料トライアルやコンバージョンの観点から私たちの最も成功したローンチとなりました。本当に成功しました。はい。 しかし、構築すべきことはまだたくさんあります。 [00:01:12] swyx：3ヶ月間無料にすることで、それが助けになりますね。 [00:01:16] サラ・サックス：ええ。 [00:01:17] Simon Last：私にとって間違いなく非常に興奮する瞬間でした。おそらく4回目か5回目のリビルドですから。 [00:01:22] swyx：はい。 [00:01:23] Simon Last：つまり、 [00:01:24] swyx：あなたは20年、22年からこの構築を続けてきたわけですね。 [00:01:26] Simon Last：ええ、つまり、私たちがGPT-4へのアクセスを得た直後、2022年後半のことですが、最初に浮かんだアイデアの一つは、「よし、エージェントを作ろう」でした。当時は「アシスタント」という言葉を使っていましたが、まだ「エージェント」という用語は定着していませんでした。しかし、Notionが持つすべてのツールへのアクセスをエージェントに与え、バックグラウンドで動作させて作業を行わせるというアイデアでした。 そして私たちはそれを何度も試しましたが、時期尚早だったのです。うーん、 [00:01:48] swyx：そこをダブルクリックして詳しく説明してもらわないと。何が「時期尚早」だったのでしょうか？何が機能しなかったのですか？ [00:01:52] Sarah Sachs：ファンクション・コールリング（function calling）が登場する前であれば、私たちは問題ありませんでした。Frontier LabsやFireworksと連携して、Notionの関数に対するファンクション・コールリングモデルをファインチューニングしようとしていました。 これが私が参加した時期です。私は、Simonが休暇を取れるようにマネージャーが必要だったため、その役割を引き受けるために参加しました。そのため、それ以降の詳細についてはSimonに語っていただくのが適切でしょう。 [00:02:11] Simon Last：ええ、私たちは異なる時期に、慈善団体とOpenAIの両方とのパートナーシップを結びました。当時、私たちはツールという概念自体が存在していなかったため、試行錯誤を行っていました。 私たちは独自のツール呼び出しフレームワークのようなものを設計し、その後、複数のターンにわたってそれを使用するようにモデルをファインチューニングしようと試みました。うーん。そして、それが箱から出してすぐにうまく機能しなかったと思うんです。そうですよね。モデルがあまりにも賢くなく、コンテキストの長さも非常に短すぎました。 [00:02:37] アレシオ：そうです。 [00:02:37] サイモン・ラスト：うーん、はい。私たちは長期間にわたってそれに対して頭をぶつけ続けていました。 うーん、残念ながら、常にそれが機能しているような兆しはありましたが、うーん、それは有用で楽しいものとして使えるほど十分に堅牢には感じられませんでした。うーん。私が言うには、大きな突破口は去年の初め頃、おそらくソニック 3.6 または 7 だったと思います。そして、それが私たちが昨年リリースしたエージェントの開発を始めた時期です。 うーん。そして、その後、カスタムエージェントという似たような機能が登場しましたが、それはより時間がかかりました。なぜなら、私たちは信頼性を大幅に高める必要があったからです。実際にはバックグラウンドで実行されているためです。 [00:03:14] サラ・サックス：そして、権限や、このカスタムエージェントが X 人のグループと Slack チャンネルで共有され、Y 人のグループに公開されたドキュメントへのアクセス権を持つという理解に関するプロダクトインターフェースの問題があります。 そして、その交差する専門家たちにとって、Y が全員とは限りません。そこで、管理者が権限付与の複雑さを理解できるようにプロダクトをどのように構築するかについて、複数の試行錯誤を行いました。 [00:03:35] Alsesio：結局のところ、すべては難しいものです。はい。モデルが機能していない場合に、今後適切なペースでモデルの性能が向上することを期待して構築すべきだと判断し、そのロードマップにどのように反映させるかについて興味があります。同時に、2022年には多くの顧客を抱えていましたよね。 それはあなたが新興企業だったわけでも、ユーザー基盤がなかったわけでもありません。 [00:03:54] Simon Last：はい、常にバランスを取ることが重要だと考えています。つまり、先を見据えて将来の方向性に向けて構築するだけでなく、有用なものを提供することも重要です。そのため、常にそのバランスを保つよう努めています。 私たちはポートフォリオアプローチを取ります。複数のプロジェクトを同時に進めながら、すでにリリース済みの機能の維持や、既に良好に動作している新機能の提供にも注力しています。 そして、少し大胆なプロジェクトをいくつか抱えることも常に目指しています。 [00:04:23] Alsesio：現在、そのような大胆なプロジェクトは何ですか？具体的な作業内容を開示する必要はありませんが、18ヶ月後に「ああ、これは当然うまくいくはずだ」と言われるような、現在の取り組みについて知りたいです。 [00:04:35] Sarah Sachs：18ヶ月後ですね。 [00:04:37] Alsesio：はい、18ヶ月というのは、 [00:04:37] サラ・サックス：長い時間がかかりましたね。ええ、そうです。 [00:04:39] サイモン・ラスト：ええと、いくつかのことが起きていますね。私が明確になってきていると思うことの1つは、コーディングエージェントがEGI（エンタープライズ・グレード・インテリジェンス）のカーネル、つまりすべての基盤となっていることです。すべてがコーディングエージェントです。なるほど。それが1つの方向性だと考えています。 そして、その面白さは、エージェントが自らのソフトウェアや機能をブートストラップし、実際にデバッグして保守できる点です。そのため、私たちはこれについて非常に多くのことを考えています。また、私が本当に興奮しているもう1つのカテゴリは、「ソフトウェアファクトリー」とも呼ばれるものです。 人々はこの用語を使っています。基本的には、開発、デバッグ、マージ、レビュー、そしてコードベースとサービスの保守というワークフローを可能な限り自動化できるかどうかが問われています。なるほど。複数のエージェントが内部で連携して動作する中で、それがどのように機能するのかという点です。 [00:05:28] サラ・サックス：最初の質問を思い出してみてください。なぜこれほど時間がかかったのか？私は、何か変化があったと思います。 [00:05:32] swyx：私はそう言っていませんが、ええ。はい、どうぞ。 [00:05:34] サラ・サックス：なぜ、3年半の試行錯誤を経て何が変わったのか？ [00:05:37] swyx：それです。まさにその通りです。なぜなら、多くの人は「まだ機能していない」と言うからです。その後、推論モデルが登場し、ようやく機能するようになりました。 私はこう思いました。では、少し進みましょう [00:05:43] サラ・サックス：ビットです。つまり、それは一部分に過ぎませんが、私たちが考えるのは、ノーションが新しい機能ごとに他社と差別化される本当の理由は、フロンティア（最先端）な能力において重要な2つのスキルを持っていることです。1つ目は、逆流しないことです。 つまり、モデルの能力に無理やりぶつかっているのか、それとも適切な情報を与えていない、あるいは適切なインフラストラクチャが構築されていないのかを素早く見極めることです。これ自体が直感のスキルです。2つ目は、逆流していないとわかったとき、川の流れがどの方向かを見極め、製品についてどのように先読みし、まだ完璧でなくても構築を始めるかということです。そうすれば、その機能が提供された際に備えが整います。 对吧？これらのことは時に直感に反するように感じられることがあります。例えば、ツール呼び出しモデルが存在しないのに、それをファインチューニングしようとしてしまう場合です。重要なのは、それを長くやめないことですが、そこに何かがあることに気づくことです。私たちは過去に、川の流れに対して正しい方向へ泳いでいないと自覚した多くの事例がありました。 私は、ミーティングノートが完成する前に、複数のバージョンのトランスクリプション（文字起こし）があったと思います。ああ、それについて話さなきゃ [00:06:39] swyx：それについてです。はい。 [00:06:40] サラ・サックス：はい。ええと、私たちはフロンティアラボズ（Frontier Labs）との間で機能面において非常に密接にパートナーシップを組んでおり、さらにそれらの機能が進展するにつれて、強い確信を持つ必要があります。 Notionは、あなたが協力し、仕事を行うための最高の場所であるべきです。そして、私たちの働き方が変化した場合、その物語はどのように変わるのでしょうか？ はい。 [00:06:58] swyx：ええ、あなたはエージェントラボの thesis（論文/主張）のファンだと教えてくれましたが、これがまさにそれのことですね？ [00:07:02] サラ・サックス：その通りです。私はその thesis を多くの候補者に見せています。まるでマイクロクロームの自動入力のようなものです。 ええと、この時点では、私の最も頻繁に訪問するページの一つです。 [00:07:10] swyx：つまり、これはNotionで働くべき理由であり、OpenEye（オープンアイ）ではない理由对吧？私としては、 [00:07:14] サラ・サックス：ここが、それと異なる点です。 [00:07:16] swyx：ええ。 [00:07:16] サラ・サックス：そして、その理由です。単なるラッパーではありません。ますます多くの人々が、それが単なるラッパーではないことを理解していると思います。 [00:07:21] swyx：ええ。 [00:07:22] サラ・サックス：ええと、ちなみに、初期段階では、私たちが構築する機能の一部は既存の機能に対するラッパーです。もちろんそれはうまく機能しますが、それが最も重要な、ええと、私が言うには収益を驱动する製品ではありません。そして、必ずしもユーザーが必要とするものとは限りません。 [00:07:35] swyx：つまり、NotionはAWSのラッパーですが、そのラッパーはとても美しく、非常に磨き上げられています。 なので [00:07:40] Sarah Sachs：あの比喩、気に入りました。 [00:07:41] swyx：はい、私もです。 [00:07:42] Sarah Sachs：私が繰り返し使っている比喩は、AWSにおけるDatadogのような関係です。 [00:07:45] swyx：ええ、そうですよね。 [00:07:46] Sarah Sachs：つまり、Datadogはクラウドストレージなしでは存在し得なかったということです。その基盤が機能していることが本質的に重要なんですね。AWSにはCloudWatchという製品もありますが、Datadogは、ユーザーが立ち上げたプロダクトに対してどのような[観測性（observability）]を求めているかを理解する専門家です。 私たちが得意としているのは、人々がどのようにコラボレーションしたいかを理解することであり、まさにそこに私たちの専門性があります。 [00:08:04] swyx：完全に同意します。 [00:08:04] Sarah Sachs：私たちが使用するツールに関わらず、 [00:08:07] Alsesio：私は暗黙的（implicit）な専門知識と明示的（explicit）な専門知識について、どのように考えているか興味があります。Datadogは暗黙的と明示的な半々だと感じています。彼らは市場や業界全体にわたって、エンジニアリングチームが通常何を求めているかを理解しています。 Notionの場合、専門知識はむしろエッジ（末端）に寄っているように感じます。プラットフォームとして非常に水平方向に広がりがあるため、エンドユーザーが必ずしも同じではないからです。ええと、Datadogの場合、エンドユーザーは常にエンジニアリングリードやSRE（Site Reliability Engineering）関連の人物ですが、Notionの場合は何でもあり得ます。 そこで、その専門知識をどのようにプロダクトに落とし込むのか、そしてもちろん、AWSがNotionを構築することはできないという点について、どうお考えか興味があります。このケースではそれが機能しないからですけれども、 [00:08:44] Simon Last：形状が少し異なりますね。古典的な垂直SaaS（Vertical SaaS）では、データ構造もそのようなものだと考えています。彼らは個々の顧客を非常に深く理解しています。 それは狭い切り口ですが、Notionは常に超水平的（Horizontal）です。私たちの課題は、常にこれらのやや相反する2つの力のバランスを取ることでした。つまり、「顧客の声を聞き、彼らが望むものを作る」という広い切り口と、「彼らの要望を分解し、使いやすく優れたプリミティブ（基本要素）にし、コスト対効果 maximized にする」という視点のバランスです。 そして、システム全体を維持し、すべてを非常にクリーンで使いやすい状態に保つことです。 [00:09:22] Sarah Sachs：私たちは依然としてユーザージャーニー（User Journey）を持っています。つまり、コアに焦点を当てています。実は、私がチームの失敗だと考えるのは、「クールなものは何か？」「どのようなツールが？」という「クールなツール」に焦点を当てすぎた時です。 [00:09:31] Simon Last：うん、なるほど。 [00:09:31] Sarah Sachs：クールなツールに焦点を当てると、実際には最も開発速度が遅くなってしまうと思います。なぜなら、依然としてユーザージャーニーに何らかの焦点を当てる必要があるからです。 例えば、私たちは毎週金曜りに集まり、最もトークン消費量の多いカスタムエージェントのトランスクリプト（記録）のP99値を確認し、なぜうまくいかなかったのかを分析して、多くのタスクを切り捨てます。つまり、依然として「これは機能するはずだ」という焦点を持っています。「メールのトリアージ（仕分け）は機能するはずだ」といった具合に。うん、なるほど。

NotionのToken Town：5つの再構築、100以上のツール、MCP対CLI、そしてソフトウェアファクトリーの未来 — NotionのSimon Last & Sarah Sachs

背景や根拠まで確認しますか？

関連記事

調べる

選ぶ

サイト