VercelがNotionを活用し、全社規模でリリースを加速させた方法

Vercelの多くのチームにとって、Notionは単なるツールではなく、エージェントを構築し、連携させ、実際に運用するプラットフォームそのものになりました。この取り組みの土台を作ったのは、同社のスピーディーなリリース文化を支えるShipOpsチームです。その中心にいるのが、技術プログラムマネージャーであり、自ら「チーフNotionオフィサー」を名乗るBrian Emerickです。彼は、共通の基盤である「Launch Calendar（リリースカレンダー）」を軸に、次々と連携するエージェント群を構築してきました。

Vercelにおいて、プロダクトをリリースする際のルールは徹底しています。ドキュメントを作成し、変更履歴をまとめ、Launch Calendarに登録する、の3点です。このカレンダーは、全社で共有されている単一のNotionデータベースです。「何を、いつリリースするか」を一元管理しており、エンジニア、マーケター、カスタマーサポートが常に同じ情報を共有するための、まさにリリースの背骨として機能しています。

理屈の上ではシンプルですが、運用が続くにつれてデータベースは肥大化していきました。気づけばプロパティの数は50件近くにのぼり、関係者全員のあらゆるニーズを詰め込んだ巨大なものになっていたのです。チームはまず、この状況を打開しようと条件分岐を活用したNotionフォームを作成しました。これにより入力は多少楽になりましたが、それでも結局はフォームを埋める作業であることに変わりはありませんでした。

そこで次の一手として開発されたのが、カスタムエージェントの「Ship」です。Slack上で対話するだけで、Launch Calendarへの登録を完了させてくれます。もう、複雑なフォームと格闘する必要はありません。リリースの名称や日付、あるいは作業中のリンクなど、手元にある情報をそのままエージェントに投げれば、あとはAIが「直接受け取った情報」「文脈から推測した内容」「まだ確認が必要な点」を整理して、残りの項目を埋めてくれます。登録が終わると、Slackのスレッドにカレンダーのリンクを自動で共有してくれる仕組みです。狙いは、情報登録を圧倒的に速くすること。そして、これまでは手間がかかるために見過ごされていたような小さなリリースも、漏らさずデータベースに記録できるようにすることです。

Shipの登場で、情報の登録に関する課題は解決しました。しかし、データベースへの登録は、プロセスの半分に過ぎません。次に必要だったのは、リリースの情報を社内の適切なメンバーへ確実に届け、それぞれが普段使い慣れているツール上で、すぐに行動に移せる状態を作ることでした。

その架け橋となるのが、もう一つのエージェント「Ship-DX」です。カレンダー上で新しいリリースが登録されたり、内容が更新されたりすると、Ship-DXが即座に動き出します。ドキュメント担当やコミュニティ担当といった開発者体験 (DX) に携わる各チームのために、タスク管理ツールのLinearへ対応するチケットを自動で作成するのです。このエージェントはNotionから詳細を読み取ると、チケットの説明文を書き起こし、期限を設定し、必要に応じてサブタスクまで切り分けます。そして、各タスクを適切なチームへと自動で割り振っていきます。さらに、共有のSlackスレッドでリリースの責任者に通知を送り、関係する各DXチームとのスムーズな連携を促します。もし後からNotion側の情報が書き換えられても、Ship-DXがLinearのチケットを自動で更新してくれるうえ、「何が、なぜ変更されたのか」という丁寧なコメントまで添えてくれます。

この仕組みを実現するために、BrianのチームはNotionワーカーを活用しました。ワーカーがLinearへ直接命令（GraphQLコール）を送ってテンプレートからチケットを作成し、その後の追記やコメントなどのやり取りはLinear MCPに引き継ぐという構成です。これは、今起きている大きな変化の一端に過ぎません。Notionがさまざまなツールを結びつけるハブとなり、そのぎゃppyをワーカーが埋めることで、あらゆるワークフローがスムーズに回り始めるのです。

この考え方は、リリースの事後処理にも活かされています。毎朝、エージェントの「Ship Closer」が動き出し、Vercelの公開されている変更履歴と、Launch Calendarを照らし合わせます。そして、予定されていたリリースが、実際にその日に行われたかを自ら判断するのです。リリースが確認できれば、カレンダーを自動でリリース済みとして更新します。もし確証が持てない場合は、すぐには動かず、少し様子を見ます（毎日同じ人にしつこく通知しないよう、あらかじめ猶予期間が設けられています）。その後、関係者全員が参加しているSlackスレッドでフォローアップを入れます。これは、Vercelが大切にしている、「オープンに仕事をする (Work in public)」という大きな原則にもかなっています。プロセスをオープンにすることで、リリースに関わる誰もが、常に最新の状況を把握できるのです。「Ship Closer」は、特定のタスクをこなすための小さなエージェントに過ぎません。しかし、そのおかげで、誰もがそのタスクをわざわざ覚えておく必要がなくなりました。

VercelのGTM (Go-To-Market) エンジニアリング部門を率いるDrew Bredvickのチームは、AIを駆使して営業やマーケティングの成約率を高めるためのツール開発に特化しています。彼らのスタイルはShipOpsチームとは異なり、自社のインフラ上で動くフルカスタムのエージェントを直接コードで書き上げるというものです。

しかし、開発を突き詰めていくほどに、意外な事実が浮かび上がってきました。すべてを機能させていたのは、他ならぬNotionだったのです。チームが作るエージェントは、大きく5つの要素（トリガー、トークン、コンピューティング、プロンプト、実行状況の可視化）で構成されています。この中で最も重要なのが「プロンプト」です。プロンプトはエージェントの賢さを左右する核心部であり、常に微調整を繰り返す必要があります。しかし長い間、この肝心なプロンプトは、ソースコードの中に埋もれていました。

VercelのCROであるNick Bogatyが、ある営業エージェントの判断基準について疑問を持ったとき、すぐに納得のいく答えを出すことはできませんでした。AIの思考ロジックがGitHubの奥深くに眠っていたからです。エンジニア以外はその中身を見ることもできず、内容を少し変えるだけでも、プルリクエストやレビュー、そしてシステム全体のデプロイといった工程を踏まなければなりませんでした。エージェントの振る舞いを修正するたびに、バグ修正と同じような手間と時間がかかっていたのです。

この課題を解決するため、チームはユーザー側で調整可能なプロンプトをすべてNotionへ移行しました。今では、営業部門のリーダーがドキュメントを開いて直接プロンプトを書き換えるだけで、次回の実行時からエージェントが新しい指示を反映して動き出します。エンジニアの手を借りる必要はもうありません。その結果、改善のサイクルは丸一日からわずか5分へと短縮されました。何より、プログラミングではなくビジネスの現場を熟知している人たちが、自らの手でエージェントの知能を研ぎ澄ませられるようになったのです。

Vercelのすべてのエージェントが、Notionの上だけで動いているわけではありません。しかし、社内のあらゆるチームが、それぞれの目的や理由から「Notionなしではもはや仕組みが回らない」と感じるようになっています。あるエージェントにとって、Notionは自在に仕組みを描けるキャンバスであり、また別のエージェントにとっては、AIの精度と正しさを支える知識とロジックの基盤となっているのです。

Brianのチームが「Ship-DX」で確立したこの成功パターンは広がりを見せており、料金改定や法務、その他のパートナーチーム向けにも、同様のエージェント開発が進んでいます。誰よりも速くプロダクトを届けることを誇りとするVercelにおいて、この圧倒的な推進力は決して偶然生まれたものではありません。それは、自分たちがまず何を作るべきかを正しく理解するところから始まったのです。