Relivio: デプロイ直後の15分を STABLE/WATCH/RISK で整理するツール

こんにちは。会社勤めをしながら、サイドプロジェクトとして開発ツールを作っています。デプロイ直後15分間の判断を整理する Relivio を共有します。

私にとってデプロイで気がかりなのは、デプロイそのものではなく直後の15分でした。CI は通っていて、ダッシュボードもおおむね正常なのに、エラーが少し増えたとき、これが今回のデプロイのせいなのか、もともとたまにあった揺らぎなのか、今すぐロールバックすべきなのかが、すぐには判断しきれません。

Relivio は既存のモニタリングを置き換えるツールではありません。モニタリングは平常時のシステム状態を広く見るのが得意で、Relivio は「今回のデプロイは今問題ないか」という一点だけを閉じる、狭いレイヤーです。

やることはシンプルです。既存のエラーログ、スタックトレース、例外タイプ、デプロイ情報を受け取り、デプロイ単位で 1 つの verdict を作ります。

• STABLE / WATCH / RISK の3段階判定
• 影響を受けた API の一覧
• 次のアクション (next action) を1行

1つの原則を強く守りました。使う側が新たに計測して送らなければならないデータは受け取りません。この線引きがないと、結局は小さな APM を作り直す方向に進んでしまうからです。

人はコンソールや Slack / Discord の通知で verdict を見て、エージェントは API や MCP サーバーで同じ verdict を読みます。デプロイ直後の判断記録を、あとで別のエージェントや未来の自分にも読めるようにするための構造です。

• すぐ試す（登録不要）: relivio.dev/demo
• Source / デモアプリ repo: github.com/lazypl82/relivio-demo-fastapi
• TypeScript SDK: npm relivio
• Python SDK: PyPI relivio
• MCP サーバーを含む
• 製品紹介: relivio.dev

まだ alpha で、最初のユーザーを獲得できていません。次の点が特に気になっています。

1. デプロイ直後の15分を別レイヤーとして扱うことは、実際に必要だと感じますか？ それとも既存のスタックで十分でしょうか？
2. STABLE / WATCH / RISK の3段階区分は、実務で使えそうでしょうか？（WATCH がいちばん自信ありません）
3. エージェントが verdict を MCP で読む構造は役に立つでしょうか？