Notionはツールであることをやめ、インフラストラクチャを目指す

Notionはツールであることをやめ、インフラストラクチャを目指す

あらゆる生産性プラットフォームには、一つのことをうまくこなすだけでは不十分になる瞬間がある。Notionはそのポイントに到達した。長年にわたりチームがメモ、Wiki、データベースを保存する場所として知られてきたこの企業は、アーキテクチャの大規模な再構成を発表したばかりだ。AIエージェントが動作し、指示を受け取り、コードを実行し、外部データをリアルタイムで同期できる環境へとワークスペースを変革する一連の機能が、その中心にある。

Clara MontesClara Montes2026年5月15日8
共有

Notionはツールであることをやめ、インフラを目指す

あらゆる生産性プラットフォームの歴史において、一つのことをうまくこなすだけでは十分でなくなる瞬間が訪れる。Notionはまさにその転換点に到達した。長年にわたりチームがメモ、Wiki、データベースを保管する場所として知られてきたこの企業は、そのアーキテクチャについて大規模な再編成を発表した。それは、人工知能エージェントが動作し、指示を受け取り、コードを実行し、外部データをリアルタイムで同期できる環境へとワークスペースを変容させる、一連の機能群である。

この発表は2026年5月13日、ライブ配信されたイベントで行われた。共同創業者兼最高経営責任者のIvan Zhaoは、注目に値する一言でそれを要約した。「Any data, any tool, any agent(あらゆるデータ、あらゆるツール、あらゆるエージェント)」。これはマーケティングのスローガンではない。ポジショニングの宣言である。Notionは、自社の限界がもはや生産性アプリケーションのそれではなく、システム、データ、エージェント間を調整する基盤レイヤーのそれであると表明しているのだ。

これが見出しを超えて重要な意味を持つ理由を理解するためには、具体的にどのような問題を解決しようとしていたのかを辿る必要がある。

働きに出られなかった百万のエージェントたち

2026年2月、NotionはカスタムAIエージェントを発表していた。それは、よくある質問に答えたり、ステータスの更新をまとめたり、繰り返しのワークフローを自動化したりできる、設定可能なアシスタントだった。その普及は目覚ましかった。わずか数ヶ月のうちに、顧客は百万を超えるエージェントを作成した。この数字が重要なのは、ワークスペース内における自動化の需要が潜在的なものではなく、すでに顕在化していたことを示唆しているからだ。ユーザーはすでに、これらのシステムに仕事を委任したいと望んでいた。

しかしエージェントには、実用的な有用性を制限する構造的な限界があった。外部データソースへの接続や、カスタムロジックの実行ができなかったのである。NotionのエージェントはZendeskのチケットの状態を読み取れず、Salesforceのデータで自身を更新することもできず、別のシステムで何かが変化したときにアクションを起動することもできなかった。それを解決するためにチームは、サードパーティの自動化プラットフォームを利用したり、自社インフラで動作する独自スクリプトを書いたりしなければならなかった。言い換えれば、Notionは情報の到達点ではあっても、プロセスの制御点ではなかったのだ。

新たなデベロッパープラットフォームは、その問題に三つの側面から取り組む。

第一はWorkersだ。これはクラウド上の実行環境であり、チームが外部インフラを必要とせず、隔離された環境に独自のコードをデプロイできる。WorkersはAPIを持つあらゆるデータベース(Salesforce、Zendesk、Postgresなど)からデータを同期し、カスタムロジックを持つツールを構築し、Webhookによってワークフローをトリガーすることを可能にする。重要なのは、Notionがコードの実行を許可するという事実ではない——他のサービスもそれはできた——、同じワークスペース内で、エージェントがすでに使用しているものと同じパーミッション制御と同じクレジットモデルのもとでそれを実現するという点だ。外部システムを統合する際の摩擦が大幅に低下する。

第二の側面は外部データベースの同期だ。これまで、CRMシステムやサポートプラットフォームからNotionにデータをインポートするには、手動のプロセスを踏むか、サードパーティのコネクタに依存する必要があった。新しいアーキテクチャにより、その同期は継続的かつ双方向に行えるようになる。Zhaoはこれを「Notionのデータベースをワークフローとエージェントのどちらも強化するためのキャンバスとして使う」可能性として説明した。彼が描写しているのは、Notion内におけるデータの役割の変化だ——静的なアーカイブから、自動化された意思決定のための能動的なソースへの変化である。

第三の側面は外部エージェントAPIだ。すでに独自のエージェント——社内で構築されたものやサードパーティ製のもの——を使用しているチームは、それらをNotionに接続できるようになった。ローンチ時点では四つの外部エージェントが対応している。Claude Code、Cursor、Codex、そしてDecagonだ。そのリストを拡大する計画がある。これが重要なのは、通常の論理を逆転させるからだ。NotionがすべてのAI機能を自社で構築するのではなく、専門化されたエージェントがそのワークスペース内で動作できる扉を開くことになる。

代償を払わせていた摩擦

NotionのCEOは、多くの企業が自社について大声では言わないことを認めた。「歴史的に、Notionは最も開発者向けのプラットフォームではありませんでした」。この認識は些細なことではない。長年にわたり、Notionの技術的なユーザーの間で最も多く記録されていた摩擦の一つは、まさにこの点だった。このプラットフォームはインターフェースとして強力ではあったが、プログラム可能なシステムとしては取り扱いにくかった。複雑なワークフローをNotionの上に構築できたであろうエンジニアリングチームは、視覚的な洗練さには劣るものの、よりオープンなツールをしばしば好んだのだ。

この差は現実のコストを生んでいた。高度な自動化を必要とするクライアントは、Notionをスタックのほかのシステムとつなぐために、追加のインフラレイヤー——Zapier、Make、n8n、AWS Lambda上のスクリプト——に費用を払うことになっていた。それはワークスペースを断片化させ、追加の障害点をもたらし、そして何より、Notionを自動化された意思決定のサイクルの外に置き続けた。データはNotionに存在したが、アクションは別の場所で起きていたのだ。

新しいプラットフォームは、その差を縮めようとしている。WorkersがNotion内で動作することで、実行環境は内部に移される。コードはもはや切り離されたLambda関数の中に存在するのではなく、データ、エージェント、ユーザーが存在するのと同じコンテキストの中に存在するようになる。その「同一配置」には具体的な結果が伴う。統合の遅延を減らし、パーミッションモデルを簡略化し、顧客の観点からは、かつて複数のプロバイダーとの複数の契約だったものを一つの請求書に集約する。

WorkersがAugust 2026年8月まで無料である点は、プラットフォーム普及における典型的な戦術的判断だ。収益化の前に実際のユースケースの創出を加速させるために、実験コストを下げるのである。チームがその期間にWorkers上で有意義なワークフローを構築すれば、その後——いかなる他の環境への——移行コストは、Notionにアカウントを固定するのに十分なほど高くなる。

アプリケーションが調整レイヤーに変わるとき

アプリケーションとインフラ基盤プラットフォームの違いは、単なる意味論の問題ではない。アプリケーションは、それを開くユーザーのために問題を解決する。調整プラットフォームは、誰もそれを見ていないときでも問題を解決する——自律的に同期し、実行し、接続し、更新する。価値はもはやインターフェースにあるのではなく、バックグラウンドで実行されるプロセスにある。

Notionはその跳躍を試みている。問われるべき具体的な問いは、今日ZapierやMake、あるいはより高度な統合サービスが調整している仕事のうち、どれほどの部分をNotionの新しいアーキテクチャが吸収できるのか、そしてそれがどのような価格で実現されるか、ということだ。

この賭けに根拠があることを示すシグナルは存在する。エージェントモデルは、これらの機能が存在する以前にすでに牽引力を示していた。数ヶ月のうちに作成された百万のエージェントは、虚栄の指標ではない。それは、チームが制限があるとはいえNotion内で自動化を設定することをいとわなかったことを示している。これはNotion上で運用することへの意欲がすでに存在していたことを示唆している。欠けていたのは、それを完全な形で実現するためのアーキテクチャだったのだ。

しかし調整プラットフォームの普及には特有のダイナミクスがある。その価値はローンチの瞬間には活性化せず、アクティブな統合の数が臨界量を超えたときに初めて活性化するのだ。Salesforceと同期した一つのデータベースは役に立つ。Salesforce、Zendesk、Postgres、さらに四つの内部ソースと同期し、それらのデータを読み取って意思決定を行うエージェントがあり、その結果に対してカスタムロジックを実行するWorkersが存在するデータベース——それはインフラだ。その二つの状態の差は技術的なものではない。蓄積された普及の差である。

外部エージェントのカタログの拡大は、今後数ヶ月のうちにこの戦略の成否を示す最も雄弁な指標になるだろう。ローンチ時の四つのパートナーは、控えめな出発点だ。六ヶ月後にその数が大幅に増加していなければ、「エージェントのハブ」という語りは、実際に稼働している現実としてよりも、意図の宣言として記憶されることになるだろう。

ユーザーがかつて契約していたものと、今や契約できるもの

Notionのユーザーがこれまで契約していたものと、新しいプラットフォームが提案するものとの間には、明確な差がある。以前は、ドキュメント、データベース、チームのタスクを集約する共有スペースを契約していた。それは情報の断片化を減らす能力において価値があった——十のツールを検索する代わりに、すべてが一か所にあるという価値だ。

新しいプラットフォームが提案するものは異なる。ユーザーは情報を集約するだけでなく、その情報が自動的に最新の状態に保たれること、エージェントが人間の介入なしにその情報に基づいて行動すること、そしてそれらのアクションにロジックを与えるビジネスコードが、データが存在するのと同じ環境で動作することを契約できる。情報の集約からプロセスの調整へのステップは、知覚される価値という観点からは、カテゴリーの跳躍だ。

Notionが、そのステップを非技術的なチームにとっても十分に円滑なものにすることに成功すれば——そしてZhaoが「コードを書く必要はない。プログラミングエージェントがあなたの代わりにやってくれる」と明示的に述べた事実は、それが賭けであることを示唆している——生産性プラットフォームとしては数少ない何かを達成したことになる。ユーザーがツールをより多く使うようになるだけでなく、使うのをやめることがより高コストになるという状況だ。それは美しいデザインによる囲い込みではない。機能的な依存による囲い込みだ。そして企業向けソフトウェアの市場において、それは最も持続性のある形の顧客維持として存在している。

共有

関連記事