Recal.dev

RecalはGoogle Calendar、Outlookなどのサービスに単一のエンドポイント群を提供するため、ユーザーがどのカレンダーを接続したかに関係なく同じリクエストが機能する。メタイベントはさらに進んで、1つの共有IDで接続済みのすべてのカレンダーを操作できる。1回の呼び出し。すべてのカレンダー。プロバイダーごとにコードを分岐させるのに疲れたチームにとって、これが核心の魅力だ。

スタックに応じて3通りの方法で統合できる。REST APIはWebhook対応と明確なエラーコードを備えた標準的なパターンに従い、SDKはnpmでインストールでき、Promiseベースの呼び出しを伴うTypeScriptの型を提供し、MCPはカレンダー操作をLLMが使えるツール呼び出しに変える。最後の選択肢こそ、エージェント開発者が集まる理由だ。合うものを選べばよい。3つとも同じデータモデルに乗っているため、1つの道に永遠に縛られることはない。

スケジューリングのエンドポイントは、日付範囲にわたるユーザーの空き枠を返し、会議間の間隔、枠の長さ、1日ごとに許される最早と最遅の時刻を設定できる。つまり「Alexは明日9時から17時の間いつ空いているか」と尋ねれば、生のカレンダーの雑音ではなく予約可能な時間帯が返ってくる。開発者がよく間違えるタイムゾーンの計算を処理する。1時間ずれるバグはもう終わりだ。時刻の誤りに関するサポートチケットも減る。

ユーザーのトークンへのアクセスは常に保たれ、チームはこれを柔軟性の保証として打ち出している。実際には、他のプロバイダーに移行したり、Recalに許可を求めずに基盤のカレンダーデータを自分で読んだりできるということだ。閉じたプラットフォームで痛い目を見た者にとって、これは真剣に検討する理由になる。ロックインなし。人質に取られるデータなし。

同社によれば、Webhookはミリ秒で発火し、一括操作は数千件の予定を処理する。ユーザーが自分の側で何かを変えると、あなたのシステムは延々とポーリングする代わりにそれを知る。これでリクエストを節約できる。レート制限も節約できる。インフラはCloudflare Workersによるエッジコンピューティングで動作するため、リクエストは1つの中央リージョンを経由せずユーザーの近くで処理される。

組織はユーザーを別々のワークスペースにまとめる。多くの顧客アカウントを管理するB2Bプロダクトではこれが重要になる。ユーザーを組織に割り当て、1つのダッシュボードからカレンダー接続を監視する。単純な消費者向けアプリなら省いてよい。チームを扱い始めると、避けるのが難しくなる。

ダッシュボードは予約パターン、ピーク時間、APIリクエスト量を追跡する。どの連携が稼働中で、どこにトラフィックが流れているかを見られるため、コストを見積もる時や、ユーザーが予約ボタンの不具合を訴える前に本番環境で切れたOAuth接続に気づく時に役立つ。普通は後から付け足される種類の可視性であり、最初から備わっているものではない。