T最新テックトレンド

NotionのAI戦略：カスタムエージェント、評価、そして仕事の未来への深い洞察

Latent Space
0:00--:--

近年、人工知能の急速な進化は、ビジネスのあり方、ひいては私たちの働き方そのものを根本から変えようとしています。その最前線で、ワークスペースプラットフォームとして多くのユーザーに支持されるNotionが、いかにこの変革の波を捉え、独自のAI戦略を展開しているのか。今回は、NotionのSarah SachsとSimon Lastが語った最新の洞察をもとに、カスタムエージェント、評価システム、そして未来の働き方に関する彼らのビジョンを深掘りします。

Notionは単なるツール提供者ではなく、人々がエンタープライズレベルの仕事を行う上での「最高のシステム・オブ・レコード（System of Record）」となることを目指しています。この壮大な目標を達成するため、彼らはAI技術をどのように統合し、どのような課題に直面し、それを乗り越えてきたのでしょうか。本記事では、NotionのAI開発における哲学、技術的な変遷、革新的な評価フレームワーク、そして組織文化が技術革新に与える影響について、詳細かつ専門的に解説します。

1. NotionのAI開発哲学と進化：なぜ今、カスタムエージェントなのか

NotionのAIへの取り組みは、GPT-4の初期アクセスを得た2022年後半に遡ります。当時のNotionチームは、「アシスタント」という言葉で呼ばれるエージェントが、Notionのあらゆるツールにアクセスし、バックグラウンドでユーザーの作業を代行するというビジョンを抱いていました。しかし、この初期の試みは「時期尚早」と判断されます。

1.1 「時期尚早」だった初期の挑戦とモデルの限界

なぜ初期の試みは成功しなかったのでしょうか？Simon Lastはその理由をいくつか挙げています。 まず、モデル自体の未熟さです。当時のモデルは、Notionのような複雑なシステムが提供する多数のツールを効果的に呼び出すための「ファンクションコーリング」の概念すら確立されていませんでした。Notionは自社でツール呼び出しフレームワークを設計し、モデルをファインチューニングしようと試みましたが、モデルの「理解力」が追いつかず、堅牢な動作を実現できませんでした。 次に、コンテキスト長の制限です。当時のモデルは、長大な会話履歴や複雑な指示を保持するのに十分なコンテキスト長を持たず、エージェントがタスクを遂行する上で必要な情報をすぐに忘れてしまう傾向がありました。 これらの技術的な壁に何度もぶつかりながらも、Notionチームは「うまくいく兆し」を常に感じていました。そして、約1年前、AnthropicのSonnet 3.6や3.7といった新世代モデルの登場が、Notionのエージェント開発における大きな転換点となります。これらのモデルは、ツール呼び出し機能と改善された推論能力を提供し、Notionが目指すエージェントの実現可能性を大きく高めました。

しかし、技術的な問題だけでなく、Notionならではの課題もありました。特に、製品インターフェースの設計と権限管理です。バックグラウンドで動作するカスタムエージェントは、特定のSlackチャンネルのグループやNotionドキュメントにアクセスする際に、複雑な権限の組み合わせが発生します。管理者ユーザーがこれらの権限を正確に理解し、適切に管理できるような製品体験を構築するには、何度も試行錯誤が必要でした。エージェントがアクセスできる情報と、特定のユーザーグループがアクセスできる情報の「交差点」を明確にし、安全性を確保することは、特にエンタープライズ顧客にとっては極めて重要です。

1.2 Notion独自のアプローチ：「川の流れを読むスキル」と製品先行開発

NotionのAI開発を特徴づけるのは、その独特の哲学です。Sarah Sachsは、フロンティア技術に取り組む上で不可欠な2つのスキルを強調します。

  1. 「上流に逆らって泳がない」直感力: モデルの現在の能力に対して無理に押し付けようとせず、ボトルネックがモデル自体にあるのか、それとも情報提供の方法やインフラ設定にあるのかを迅速に見極める能力。Notionは、モデルがまだ対応できない機能に固執せず、早期に方向転換する柔軟性を持っています。
  2. 「川の流れを読む」先見性: モデルの能力がまだ不十分であっても、将来的にその方向へ進化するであろうという確信に基づいて、先行して製品開発を進める能力。これにより、モデルが成熟した際に、Notionは既に準備ができており、すぐに市場に投入できる状態になります。

この哲学の具体例として、Sarahは過去のトランスクリプション機能開発の苦労を挙げます。Notionは、単なる機能の「ラッパー」ではないという強い信念を持っています。彼らはDataDogとAWSの比喩を用いてこの点を説明します。AWSがクラウドストレージという基盤を提供し、DataDogがその上でオブザーバビリティという専門性を提供するように、NotionはLLMという基盤の上で、人々がどのように協働し、仕事をしたいかを深く理解することに専門性を置いています。これは、単に既存のAIモデルを組み込むだけでなく、Notionのコアであるコラボレーションとワークフローの文脈でAIの価値を最大化するという、彼らの明確な戦略を示しています。

1.3 AGIへの展望と「ソフトウェアファクトリー」の構想

Notionは、単に現在のAI機能を製品に統合するだけでなく、その先のAGI（汎用人工知能）の可能性にも目を向けています。Simon Lastは、「コーディングエージェントがAGIの核となる」という考えを提唱します。エージェントが自身のソフトウェアと能力をブートストラップし、デバッグし、保守できるようになる未来を描いているのです。

このビジョンを具体化したのが、彼らが「ソフトウェアファクトリー」と呼ぶ構想です。これは、複数のエージェントが協調して、ソフトウェアの開発、デバッグ、マージ、レビュー、メンテナンスといった一連のワークフローを可能な限り自動化するシステムです。Notionは、このようなエージェントが協調して働く環境を社内でも構築しようと試みています。

この構想は、Notionのコア製品が持つ水平性と、ユーザーの多様なニーズへの対応という課題にも繋がります。Notionは非常に水平なプラットフォームであるため、顧客の幅広い要望に応えつつ、それらを使いやすいプリミティブに分解し、システム全体をクリーンに保つ必要があります。しかし、Notionチームは単に「クールなツール」を作ることに集中するのではなく、ユーザーが「メールの選別」や「PDFエクスポート」といった日々の業務を効率的に行えるような、明確なユーザー体験に焦点を当てています。これは、技術的な面白さだけでなく、実用的な価値提供を重視するNotionの姿勢を表しています。

2. カスタムエージェントの核心機能とビジネスインパクト

Notionのカスタムエージェントは、発表以来大きな反響を呼んでいます。単なるチャットボットではなく、Notionの強力なデータベースやツール群と連携し、ユーザーのワークフローを自動化する能力がその魅力です。

2.1 利用事例と「Resilient Collector」デモ

カスタムエージェントの具体的な利用事例は多岐にわたります。例えば、社内では以下のような活用がされています。

  • バグトリアージ: Slackに報告されたバグをカスタムエージェントが自動的に適切なチームにルーティングし、タスクデータベースに登録、関連Slackチャンネルに通知する。これにより、バグを見落とすことなく、迅速な対応が可能になります。
  • 顧客フィードバックのトリアージ: 顧客からのフィードバックをエージェントが分析し、適切なチームに振り分けたり、関連情報を収集したりする。
  • 情報収集とプロファイルの充実: 顧客やパートナーに関する情報をWebから検索し、Notionデータベースに自動的に追加・更新する。

ポッドキャストのホストであるSwyxは、自身のコワーキングスペース「Kernel Labs」の入居者募集のために、カスタムエージェント「Resilient Collector」を15分でセットアップしたデモを紹介しています。このエージェントは、Webフォームからの申し込みメールをトリガーに、Notionデータベースに新しい行を作成し、Web検索で応募者のプロフィールを充実させます。これにより、手動での情報収集やトリアージの時間を大幅に削減できます。

これらの事例が示すのは、カスタムエージェントが「人々のプロセスを置き換える」ことで、仕事の効率を劇的に向上させるということです。これは、決して人間を置き換えるものではなく、人間がより付加価値の高い仕事に集中できる環境を創出することを意味します。

2.2 権限管理とセキュリティ：エンタープライズ利用の基盤

カスタムエージェントの導入において、Notionが最も重視している点の一つが、その強固な権限モデルとセキュリティです。エージェントがバックグラウンドで動作し、企業データにアクセスするため、厳格な権限管理は不可欠です。

Notionのカスタムエージェントは、デフォルトではいかなる権限も持っていません。ユーザーはエージェントに対し、明示的に必要な権限（例: メールを「読む」権限は与えるが、「送信する」権限は与えない）を付与する必要があります。これにより、ユーザーはエージェントの動作を信頼し、安全に利用できます。企業がHIPAAやGDPRといった規制に準拠するためにも、この詳細な権限管理は極めて重要です。Notionは、ベンダーとの契約、セキュリティレビュー、コンプライアンス要件への対応を開発の初期段階から組み込み、エンタープライズレベルでの安全な利用を保証しています。

2.3 エージェント間の連携とメモリ管理

Notionのカスタムエージェントは、単体で動作するだけでなく、互いに連携してより複雑なワークフローを構築できます。この連携には主に2つの方法があります。

  1. データプリミティブによる連携: エージェントはNotionのページやデータベースをシステム・オブ・レコードとして利用し、互いに情報を共有できます。例えば、あるエージェントがデータベースに書き込んだ情報を、別のエージェントが監視して次のアクションをトリガーするといった連携が可能です。これは疎結合な連携であり、堅牢性に優れています。
  2. 直接呼び出しによる連携: Notionは、エージェントが他のエージェントを直接呼び出す機能をリリース予定です。これにより、より密結合で複雑なエージェント群を構築できます。無限ループの発生を防ぐための安全策も講じられています。

このエージェント間の連携機能の好例が、「マネージャーエージェント」の概念です。ある社内ユーザーが30以上のカスタムエージェントを運用した結果、毎日70件以上の通知に悩まされていました。これに対し、Simon Lastは、30のエージェントの上に「マネージャーエージェント」を配置することを提案しました。このマネージャーエージェントは、他のエージェントからの課題を監視・トリアージし、必要な場合にのみ人間に通知することで、通知数を5件にまで削減しました。これは、抽象化のレイヤーを追加することで、システム全体の複雑性を管理する優れたアプローチです。

また、Notionのエージェントには、特別な「メモリ」の概念が組み込まれていません。エージェントの「記憶」は、Notionのページやデータベースそのものとして扱われます。ユーザーはエージェントに特定のページへのアクセス権を与えることで、そのページをエージェントの長期記憶として機能させることができます。これにより、人間もエージェントも同じ情報源を参照・編集できるという、Notionならではのシームレスな体験が実現されます。

2.4 Notion Mailとその他統合：ユーザー体験の深化

Notionは、Notion MailやNotion Calendarといったネイティブサービスを開発していますが、同時にGmailなどの外部サービスとの連携も重視しています。これは、ユーザーにNotionのサービス利用を強制するのではなく、エージェントの能力を最大限に活用できる環境を提供するためです。

Notion Mailとの連携では、Notion Mailチームが直接ツールを構築し、レイテンシやパフォーマンス、品質を最適化します。一方、Gmailとの連携では、GmailのAPIを通じて利用可能なツールセットがMCP（後述）を介して提供されます。Notionは、ネイティブ統合を優先的に構築し、その後、より一般的な拡張へと移行するフェーズアウト戦略をとっています。

しかし、Notionは、単に既存のサービスを統合するだけでなく、ユーザー体験を根本から変革することを目指しています。例えば、エージェントがメールの自動ラベリングを行うことで、Inboxの管理を大幅に効率化できます。このように、エージェントは「メールアプリそのものを、事前にパッケージ化されたエージェントとして、Inboxを自動化するのに役立つもの」として捉えることができます。

3. Notionの技術的アプローチ：CLIとMCPの使い分け

NotionのAI開発におけるもう一つの重要な側面は、エージェントが外部ツールと連携するための異なるプロトコル、CLI（Command Line Interface）とMCP（Multi-tool Calling Protocol）に対する彼らの考え方です。両者は異なる特性を持ち、Notionはそれぞれの利点を理解し、適切に使い分けています。

3.1 CLI（Command Line Interface）の利点と課題

Simon Lastは、CLIに非常に期待を寄せています。その主な利点は以下の通りです。

  • ターミナル環境のパワー: CLIはターミナル環境で動作するため、長大な出力のページングや、プログレッシブディスクロージャー（必要な情報のみを段階的に表示する）といった強力な機能を利用できます。
  • 自己修正能力（Bootstrapping）: CLI環境では、エージェント自身がコードを生成、デバッグ、修正できます。例えば、エージェントがブラウザ機能を持たない場合、自身でブラウザツールを作成し、問題が発生すれば即座に修正を試みることができます。これは、エージェントが自身の能力を自律的に拡張し、維持できるという点で極めて強力です。
  • 直接的なコード実行: CLIは、エージェントが直接コードを記述し、実行することを可能にします。これにより、非常にオープンエンドで複雑なタスクにも対応できます。

しかし、CLIには課題もあります。特にセキュリティ面です。CLIはシステムへのより深いアクセスを可能にするため、APIトークンへのアクセスや、トークンの不正な持ち出し（exfiltration）といった新たなセキュリティリスクを生じさせます。これを適切に管理することは、非常に困難な問題です。

3.2 MCP（Multi-tool Calling Protocol）の利点と課題

一方、MCPは「狭く軽量なエージェント」に適しているとNotionは考えています。その主な利点は以下の通りです。

  • 強固な権限モデル: MCPは本質的に非常に強力な権限モデルを持っています。エージェントができることは、明確に定義されたツールを呼び出すことのみであり、それ以外のシステム操作はできません。これにより、CLIよりもセキュリティリスクを低減しやすくなります。
  • シンプルさと堅牢性: MCPは「愚かでシンプルなものだが、動作する」と評されています。特定のツール呼び出しに特化しているため、予期せぬ動作が少なく、比較的堅牢なシステムを構築しやすいです。
  • 長期的なサポートとエコシステム: Notionは、Notionがエンタープライズワークのシステム・オブ・レコードであるというコミットメントに基づき、MCPのサポートを継続します。他の開発者がMCPを使用している限り、Notionもその進化に貢献します。

MCPの課題としては、ツールのプログレッシブディスクロージャーの必要性が挙げられます。初期のMCP実装では、エージェントに全てのツールを一度に提示していたため、ツールが増えるにつれて性能や品質に問題が生じました。Notionは、これを改善するために、必要なツールのみをエージェントに提示する工夫を凝らしています。

3.3 Notionの使い分け戦略とコスト効率

Notionは、CLIとMCPを競合するものではなく、異なる抽象化レイヤーとして捉え、それぞれの強みを活かして使い分けています。

  • オープンエンドな課題へのCLI: コード生成や自己修正が必要な、よりオープンエンドな問題にはCLIの機能を利用します。
  • 軽量でセキュアなタスクへのMCP: 特定の定型的なタスクや、厳格な権限管理が必要なケースにはMCPを利用します。

この使い分けには、コスト効率も深く関わっています。Notionのカスタムエージェントは使用量ベースの価格設定を採用しており、無駄なトークン消費を避けることを重視しています。 Sarah Sachsは、決定論的なタスクに言語モデルを常に使用することや、サードパーティプロバイダーとのインターフェースに毎回LLMを介することの「無駄」を指摘します。CLIのようなコード実行パスであれば一度のコストで済むタスクを、MCPを通じてLLMに繰り返し処理させるのは非効率的であり、顧客にとってもNotionにとっても「悪いビジネス」だと考えています。

例えば、「ブラウザをゼロから構築するエージェント」は魅力的ですが、顧客がそのトークンコストを毎回支払うとすれば、既存の「Chrome DevTools MCP」を利用する方がはるかに効率的です。Notionは、どのタスクにどのプロトコル（API呼び出し、MCP、オープンエンドなコーディングエージェント）が最適かを見極め、品質とコストのバランスを考慮して適切なソリューションを提供することを目指しています。 Notionは、MCPを通じて多様な外部ツールとの接続を可能にしつつ、検索機能のようにNotionの核となる品質に直結する部分では、自社で統合ツールを開発し、より深い制御を行っています。これは、Notionが「ツール連携の抽象化レイヤー」を内部に持ち、MCPをその統合タイプの一つとして位置づけているためです。この柔軟なアーキテクチャが、NotionのAI戦略を支えています。

4. 評価（Evals）システムとモデルの行動理解：AI品質の守護者

AIシステムの品質と信頼性を確保するために、Notionは非常に洗練された「評価（Evals）システム」を構築しています。彼らは「Evals」という言葉が単なる「テスト」ではなく、より広範で多層的な概念であることを強調します。

4.1 Notionの多層的な評価フレームワーク

Notionの評価システムは、以下の3つの主要なレイヤーで構成されています。

  1. ユニットテスト/回帰テスト: CI/CDパイプラインに組み込まれ、一定の合格率を維持する必要があります。これは、基本的な機能が動作し続けることを保証するものです。
  2. ローンチ品質評価: 製品ローンチ前に特定のユーザー体験（例: メールトリアージ）について80%〜90%の合格率を目標とするものです。これは、実用的なレベルでの製品品質を保証します。
  3. フロンティアヘッドルーム評価: これは最も革新的な評価レイヤーで、Notionが「積極的に30%の合格率を目指す」と公言するものです。現在のモデルではまだ達成できない、将来的に実現したい高度な機能を評価するために設計されています。NotionはAnthropicやOpenAIといったフロンティアラボと協力し、モデルの進化を先読みするためのインサイトを得ています。

このフロンティアヘッドルーム評価は、「Notion's Last Exam」という概念に基づいています。これは、Notionの製品とユーザーの働き方に特化した、究極のAI能力試験です。一般的なベンチマーク（例: 人文学の試験）ではなく、Notion環境における複雑なコラボレーション、データベース操作、情報整理といったタスクをAIがどれだけこなせるかを測ります。この試験には、データサイエンティスト、モデル行動エンジニア、評価エンジニアが専属で従事しており、AIの「未来の能力」を常に探求しています。

4.2 Model Behavior Engineer（MBE）という新しい職種

Notionの評価システムの核となるのが、「Model Behavior Engineer (MBE)」というユニークな職種です。この職種は、もともとSimonがGoogle Sheets上でモデルの出力を手動で検査するために、言語学のPhD中退者や比較文学の新卒者といった多様なバックグラウンドを持つ人々を雇用したことから始まりました。

MBEの役割は時間とともに進化しています。

  • 初期: 主にモデルの出力を手動で検査し、「良い」「悪い」を判断する定性的な作業。
  • 現在: コーディングエージェントを構築し、自身で評価を記述したり、LLMをジャッジとして利用したりする。これにより、評価プロセスの自動化とスケーラビリティを高めています。MBEは、データサイエンティスト、プロダクトマネージャー、プロンプトエンジニアの要素を兼ね備えた職種であり、モデルが何ができて何ができないかを理解し、ヘッドルームを定義し、良いユーザー体験を設計する「クラフト」の感覚を持っています。

Notionは、MBEがソフトウェアエンジニアリングのバックグラウンドを必須としない独自のキャリアパスであると強く信じています。彼らは「はみ出し者（misfits）」を歓迎し、多様な視点と直感をAI開発に持ち込むことを重視しています。

4.3 エバルシステムをエージェントハーネスとして扱う

Notionはさらに一歩進んで、評価システム自体を「エージェントハーネス」として扱う構想を推進しています。つまり、エージェントがデータセットをダウンロードし、評価を実行し、失敗を分析し、デバッグし、修正を実装するといったエンドツーエンドのプロセスを自律的に行えるようにすることです。最終的には、人間がシステム全体を「観察」する役割に徹する未来を描いています。 これは、評価プロセスを単なるテストではなく、エージェント自身の「学習と改善のループ」と捉える革新的なアプローチです。Notionは、このアプローチによって開発速度と堅牢性を劇的に向上させています。

4.4 モデルの「退化」とプロバイダーとの連携

Notionは、大規模言語モデル（LLM）のプロバイダーから提供されるモデルの品質変動にも細心の注意を払っています。彼らは「秘匿された品質低下（secret degradation）」や、トラフィックの多い時間帯での速度低下や品質の変動（flickiness）を経験しています。特に、同じモデルが異なるベンダー（例: ファーストパーティ、Bedrock、Azureなど）を通じて提供される場合に、広告された品質と実際の品質に乖離があることを発見しています。

Notionは、外部のサブプロセッサーを利用してモデルの性能を詳細に分析し、回帰や最適化の状況を把握しています。また、フロンティアラボとの連携を通じて、モデルのプレリリース版を評価し、エンタープライズワークに特化したNotionのフィードバックに基づいて、モデルの出荷版に変更が加えられることもあります。これは、Notionが単なるモデル利用者ではなく、モデルの進化に影響を与える重要なパートナーであることを示しています。

5. 組織文化と開発プロセス：AI時代のエンジニアリング

NotionのAI開発の成功は、その技術力だけでなく、それを支える独自の組織文化と開発プロセスに深く根ざしています。

5.1 リーダーシップの役割と「自分のコードを削除する文化」

Sarah Sachsは、自身のリーダーシップの役割を「アイデアを出す人や技術的な専門家であること」とは考えていません。彼女の仕事は、全員が目標を理解し、優先順位付けに必要なリソースを持ち、自身のアイデアを推進する道筋を持っていることを保証することです。NotionのAIチームでは、最高のアイデアのほとんどは、ユーザーの問題を発見した開発者からのプロトタイプから生まれると信じられています。

Notionの文化において特に重要なのが、「自分のコードを削除することを厭わないチームを構築すること」です。AI分野は変化が速く、数ヶ月前には最先端だったコードがすぐに陳腐化することがあります。Notionは、ハーネス（エージェントの基盤となるフレームワーク）を何度も再構築しており、その度に大量のコードが削除されています。このようなプロセスは、多くの企業では摩擦を生じさせがちですが、Notionでは低エゴで、会社の利益を最優先する文化が根付いているため、スムーズに実行されます。この文化は、Simon LastやIvan Zhaoといった創業メンバーのオープンマインドな姿勢に直接由来しているとSarahは語ります。

Simon Lastもまた、常に「ゼロからやり直す」ことの重要性を強調します。6ヶ月ごとに全てを見直し、新しい技術が登場した際に、全てを書き直す覚悟で取り組むことで、常に最先端を走り続けることができると考えています。

5.2 「Simon Vortex」と「Demos over Memos」：迅速なプロトタイプ文化

Notionの開発プロセスには、いくつかの特徴的な要素があります。

  • Simon Vortex: Simon Lastが主導する、スクラッチワークラボのようなプロジェクトです。ここでは、ベテランエンジニアが一時的に参加し、非常に高い速度でプロトタイプを構築します。方向性は日々変化することもありますが、これは迅速な実験と学習を可能にするための意図的なアプローチです。管理境界は緩やかで、プロジェクトの必要に応じて人員が流動的に配置されます。
  • Demos over Memos: デザイナーのBrian Lovinが提唱したコンセプトで、「メモよりもデモを重視する」という考え方です。Notionのデザイナーは、もはやモックアップではなく、完全に機能するプロトタイプを直接構築します。エンジニアにとっても、プロトタイプとは実際に機能する「フィーチャーフラグ」として提供されるレベルのものです。

このプロトタイプ文化は、Notionが自社製品の最大のユーザーであるという事実に支えられています。Notionの全従業員（IT、人事、調達など全て）は、開発中の多数のフィーチャーフラグがオンになったNotionのインスタンスを日常的に使用しています。これにより、新しいプロトタイプに対するフィードバックが迅速に得られ、実用性が検証されます。

このような文化は、従業員の好奇心と情熱を最大限に引き出すことにも繋がります。Notionは、スケジュールされたハッカソンだけでなく、従業員が週末に個人的な興味から開発したプロトタイプであっても、それが重要であればすぐに公式プロジェクトとして取り上げる柔軟性を持っています。画像生成機能も、元々はデータベースチームのエンジニアが個人的なプロジェクトとして始めたものが、全社的なサポートを受けて製品化された事例です。

5.3 チーム構成とエンジニアの役割変化

NotionのAIチームは、以下の異なる役割を持つチームで構成されています。

  • コアAI機能・インフラチーム: Sarah Sachsが管理する約50名のチームで、AIの基盤技術とインフラを担当します。
  • パッケージングパートナーチーム: カスタムエージェント、会議メモ、チャットといったユーザーインターフェースへのAI機能の統合を担当する約30〜40名のチーム。
  • 製品サービスチーム: Notionの各製品サービス（エディター、データベースなど）を担当するチームで、これらのチームもエージェントが使用する「ツール」の所有者となります。例えば、NotionのデータベースのSQLエンジンを構築したチームは、エージェントがSQLクエリを実行する際のパフォーマンスも担当します。

Notionは、将来的にはトラフィックの大部分が人間ではなくエージェントからのものになると予測しています。そのため、全ての製品エンジニアリングチームに対し、人間とエージェントの両方の顧客のために製品を構築することを求めています。

この変化は、エンジニアの役割にも大きな影響を与えています。Simon Lastは、ソフトウェアエンジニアの役割が「コードを記述する能力」から「デリゲートし、コンテキストスイッチを行う能力」へと変化していると指摘します。これは、マネージャーが経験する「アイデンティティの危機」に似ています。AIがコード生成やデバッグの一部を担うようになると、人間はシステム全体を観察し、設計し、保守する、より抽象度の高い役割に移行するのです。

Notionが構想する「ソフトウェアファクトリー」は、まさにこの変化を体現しています。仕様層としてMarkdownファイル（またはNotionページ）を利用し、自己検証ループ（テスト）を徹底することで、バグが発生した際にサブエージェントがPRを作成し、レビューされ、マージ・デプロイされるという、高度に自動化された開発ワークフローを目指しています。

6. 未来へのビジョン：エージェント駆動型ワークプレイス

Notionは、AIエージェントが仕事のやり方を根本から変革する未来を見据えています。そのビジョンは、Notionプラットフォーム全体がエージェントによって駆動されるワークプレイスへと進化することです。

6.1 Notionの抽象化レイヤーの進化

NotionのAI開発の歴史は、いかにモデルの能力を最大限に引き出すための抽象化レイヤーを構築してきたかの歴史でもあります。Simon Lastは、彼らが「ハーネス」を5回も再構築してきた経験を語ります。

  • 初期 (2022年後半): 最初の試みは「コーディングエージェント」でした。JavaScript APIを与え、エージェントがコードを書くことでツールと対話する方式でしたが、当時のモデルはコード生成が苦手だったため失敗しました。
  • XMLベースのツール呼び出し: 次に、ツール呼び出しの概念がなかったため、NotionブロックにロスレスにマッピングできるXML形式を自社で開発しました。しかし、モデルがXML形式を理解できず、ツールの使い勝手も悪かったため、これも失敗しました。
  • Markdownへの移行: 大きな学習として、「モデルが望むものを提供する」という原則を確立しました。モデルがMarkdownに強いことを利用し、NotionフレーバーのMarkdownを作成しました。これにより、完全なロスレス変換よりも、モデルの理解度を優先するようになりました。
  • SQLiteへの移行: データベースへのクエリに関しても同様です。Notion APIの複雑なJSON形式を捨て、モデルが得意とするSQLiteクエリ形式を採用しました。Notionの基盤はPostgresですが、SQLデータベースのクラスターを抽象化する既存のプロジェクトがあったため、SQLite形式への変換はスムーズでした。
  • Few-shotプロンプトからの脱却とツール定義: 初期のエージェントはFew-shotプロンプトに依存していましたが、ツールが増えるにつれて管理が困難になり、品質も不安定になりました。Notionは、ツールの目標（goal-driven）を記述する形式に移行し、Few-shotプロンプトの使用を段階的に廃止しました。これにより、ツール所有権を各チームに分散させ、開発速度を大幅に向上させることができました。

現在、Notionはエージェントに100以上のツールを提供しており、これらのツールはエージェントに直接質問すれば公開される透明性も持っています。Notionは「クラスのトップを教える」という哲学に基づき、パワーユーザーがエージェントの仕組みを深く理解し、最大限に活用できるような製品設計を心がけています。そのため、過度な抽象化は避け、エージェントの「解釈可能性」を重視しています。

6.2 価格設定戦略：価値ベースの思考と「Auto」モデルの役割

Notionのカスタムエージェントの価格設定は、従来のトークン課金とは異なる「Notionクレジット」を導入しています。これは、トークン使用量だけでなく、ファインチューニングされたオープンソースモデルのGPU使用料、Web検索の費用、サンドボックスのホスティング費用など、多様なコスト要因を抽象化するためです。また、エンタープライズ顧客への割引やセールスプロセスとの連携も考慮されています。

Notionは、タスクの「価値」に基づいて価格設定を行う可能性も議論しましたが、何が複雑で価値が高いかを正確に判断することが難しいため、現時点では導入していません。しかし、彼らの基本的なコミットメントは「顧客が公正な取引を得る」ことです。

ここで興味深いのが、「Auto」モデルの役割です。Notionは、ユーザーが最も高価なモデル（例: Opus）を常に使用することが最適ではないことを理解しています。多くのタスクは、それほど高度な推論能力を必要としません。Notionの「Auto」モデルは、タスクに最適なモデルを自動的に選択することで、顧客のコストとNotionのインフラ負担を最適化します。Notionは、ユーザーに対して、高価なモデルの使用が本当に必要かどうかを促すようなUI/UXも提供しています。

Notionは、フロンティアラボが提供するモデルが「インテリジェンス・価格・レイテンシ」のトライアングル全体をカバーしているわけではないという現状を認識しています。多くのモデルが能力と価格の高い端に集中しがちです。そのためNotionは、オープンソースモデルへの投資を通じて、このトライアングルの「空白」を埋めようとしています。オープンソースモデルが数ヶ月前の推論モデルレベルに達していると見ており、Notion's Last Examに協力することで、これらのモデルの性能向上を支援しています。

6.3 将来的なモデルトレーニングと検索システムの進化

Notionは、自社で基盤モデルをトレーニングすることには慎重な姿勢を示しています。その代わりに、以下のような領域での投資を検討しています。

  • 企業特化型ファインチューニング: 大規模な企業顧客が、自社のコンテキストや人材に特化したモデルをファインチューニングできるような機能の提供。これにより、モデルの品質が大幅に向上する可能性があります。
  • ツール理解のファインチューニング: Notionのツールが頻繁に更新されるため、ツールの理解に特化したモデルのファインチューニングは、その更新速度に追いつくことが困難です。しかし、ツールの検索や選択を効率化するためのファインチューニングは検討の余地があります。
  • リトリーバル（検索）のモデルトレーニング: 現在、Notionの検索トラフィックの大部分はエージェントからのものであり、そのクエリ構造や求められる結果の性質は人間とは異なります。そのためNotionは、エージェントによる検索に最適化されたリトリーバルモデルやランキングエンジンの開発に注力しています。これは、Notionのブロックモデルや会議メモといった独自のデータ構造に合わせて、インデックス作成やスニペットの選択方法を再考する大規模な取り組みです。

Notionは、「エージェントは自らを仕事から自動化することもある」という考え方を持っています。つまり、エージェントが自動的にコードを書き、それが恒久的なソリューションとして導入されれば、もはやエージェントの助けは不要になるという状況です。Notionは、フロンティアラボが単に「より賢く、より高価なモデル」を提供することにインセンティブがあるのに対し、Notionは「タスクに最適なツール」を提供することにインセンティブがあるという根本的な違いを強調します。

6.4 会議メモ（Meeting Notes）とデータキャプチャの重要性

会議メモ機能は、Notionの成長における最大の推進力の一つであり、AIエージェントの能力を最大限に引き出すための重要なデータ源となっています。

  • エンゲージメントと定着率の向上: 会議メモ機能は、その高い定着率とバイラルな普及率から、ユーザーにとって非常に価値のある機能であることが証明されています。
  • システム・オブ・レコードの強化: 会議メモは、Notionが「システム・オブ・レコード」となる上で不可欠な要素です。ユーザーは、一対一のミーティング議事録を全てNotionに保存し、それを自己評価やパフォーマンスレビューに活用します。これにより、Notionは個人の仕事の優先順位付けに関する豊富なシグナルを蓄積できます。
  • エージェントのデータフライホイール: 会議メモによって生成される大量のトランスクリプトは、Notionエージェントにとって極めて価値の高い「データフライホイール」となります。エージェントはこれらのコンテンツを学習し、より賢く、より関連性の高い情報を提供できるようになります。

Notionのチームは、エージェントを活用して会議プロセス全体を自動化しています。カスタムエージェントがSlackやGitHubの情報を基に会議の予習資料を作成し、会議中は人間が議論に集中します。会議後には、別のカスタムエージェントが決定事項に基づいてタスクを自動的に作成し、関係者にSlackメッセージを送信します。 さらに、会議メモ機能は、会話中に言及された人物を自動的にアットメンションする機能も備えています。これは、エージェントが発言者を識別し、Notionの「人物プロファイル」と照合することで実現されます。将来的に、この機能はカスタムエージェントと直接連携し、会議中に議論されたタスクをリアルタイムでデータベースに更新するといった高度なシナリオへと進化する可能性があります。

6.5 物理的なデバイスとの連携：Notionの立ち位置

OpenAIがハードウェアに参入する可能性が示唆される中、Notionは物理的なウェアラブルデバイスとの連携についても検討しています。彼らは、ミーティングの内容をリアルタイムで記録するウェアラブルなど、このプロダクトカテゴリ全体に期待を寄せています。

しかし、Notionは自社でハードウェアを製造することには消極的です。彼らの役割は、「会議メモをキャプチャするための最高のウェアラブルを構築すること」ではなく、「会議メモが最も適切に保存され、活用される最高の場所を構築すること」だと明確に認識しています。そのため、Notionはウェアラブルデバイスを開発する企業と積極的にパートナーシップを結び、Notionエージェントがそれらのデバイスから取り込まれたデータを活用し、CRM検索やコンファレンスでの情報提供といったユースケースをサポートできるようにすることを目指しています。 これは、NotionのAI戦略が、自社の強みであるワークスペースプラットフォームに集中し、外部のフロンティア技術を柔軟に取り込みながら、ユーザーへの価値提供を最大化するという、明確な方向性を持っていることを示しています。

結論：Notionが描く仕事の未来

Notionは、AIエージェントを単なる一時的な機能強化と捉えるのではなく、仕事のあり方そのものを変革する戦略的投資と位置づけています。彼らは、初期の技術的課題を乗り越え、独自の開発哲学と評価システム、そしてアジャイルな組織文化を通じて、カスタムエージェントを強力な製品へと進化させてきました。

Notionが描く未来は、エージェントが私たちの日常業務の大部分を自動化し、人間はより創造的で戦略的な仕事に集中できる「エージェント駆動型ワークプレイス」です。この未来において、Notionは、エージェント間のシームレスな連携を可能にするシステム・オブ・レコードとなり、最も効率的で、安全で、かつコスト効率の良い方法でAIの力を活用できるプラットフォームとしての役割を果たすでしょう。

NotionのAI戦略は、技術革新の波に乗りながらも、ユーザーの実際のニーズとビジネスへの価値提供に深く根ざしています。彼らは、LLMの能力を最大限に引き出すための抽象化の芸術を追求し、モデルの進化を先読みしながら、常に製品を再構築する柔軟性を持っています。そして、Model Behavior Engineerのような新しい職種を創造し、多様な才能と好奇心を持つ人々をAI開発の最前線に引き入れることで、未来のエンジニアリングチームのあり方を示しています。

Notionが構築しているのは、単なるソフトウェア製品ではありません。それは、AI時代における新しい働き方、新しいコラボレーションの形、そして新しい価値創造のモデルを具現化するものです。彼らの挑戦は、私たちが仕事とどのように関わり、テクノロジーとどのように共存していくかという問いに対する、具体的な答えを示しています。

← 一覧に戻る