CursorのSubagent機能が正式リリースされました。これを自分のリポジトリで試してみたくなり、素振り開発をすることにしました。
開発の動機
このサイト（yamotty.me）は、Markdownファイルをホストするだけの静的サイトです。Next.jsで構築されていますが、データベースもAPIも持っていません。シンプルで運用が楽な反面、少し物足りなさもありました。
そこで今回、データベースとAPIバックエンドを必要とする機能を追加してみることにしました。ソフトウェアエンジニアリングの入門としては若干難易度が高いですが、Cursorがどこまでサポートしてくれるのか試すにはちょうど良い題材だと思いました。
具体で言うと、ニュースレター機能を実装しました。読者がメールアドレスを登録すると、新しい記事の公開時や外部サービス (note, Podcast, しずかなインターネット) 更新時に通知が届き、月末にはダイジェストメールが届くというよくある仕組みです。
こうした仕組みを提供するSaaSは多数ありますが、自分の居場所を自分でコントロールしたい私としては、ニュースレターの自前化は良い題材です。
技術構成とスタック
- Supabase: PostgreSQLベースのBaaS。購読者データを管理
- Resend: モダンなメール配信サービス。React Emailでテンプレートを書ける
- Vercel: 既存のホスティング。SupabaseとのIntegrationが便利
- GitHub Actions: RSSフェッチと月次ダイジェスト送信の自動化
これらのSupabaseやResendは以前から使ってみたいと思っていたので、この希望をCursorに伝え、アーキテクチャに反映してもらいました。
構築したサブエージェント構成
.cursor/agents/ ディレクトリに5つの専門エージェントを配置しています。
.cursor/agents/
├── pm.md # プロダクトマネージャー
├── designer.md # UI/UXデザイナー
├── engineer.md # フロントエンドエンジニア
├── backend.md # バックエンドエンジニア
└── qa.md # QAエンジニア
各エージェントには役割・思考タグ・完了定義（DoD）を定義しています。
| エージェント | 役割 | 思考タグ |
|---|---|---|
| PM | 要件定義、ユーザーストーリー、優先順位付け | <pm_thought> |
| Designer | UI設計、Tailwindクラス設計、アクセシビリティ | <design_thought> |
| Engineer | React/Next.js実装、型安全性、SOLID原則 | <dev_thought> |
| Backend | DB設計、API設計、インフラ構成 | <backend_thought> |
| QA | テスト計画、エッジケース検証、品質保証 | <qa_thought> |
.cursorrules にはオーケストレーションのフローを定義しています。ユーザーからの指示に対して、まず <orchestrator_plan> で計画を立て、その後各エージェントが順次思考・出力する流れです。
<orchestrator_plan>
<context_analysis>技術スタックとプロジェクト構造の特定</context_analysis>
<task_analysis>ユーザーの要求分析</task_analysis>
<workflow>
<step agent="PM">要件定義と受入基準の策定</step>
<step agent="Backend">DB・API・インフラ設計</step>
<step agent="Designer">UIコンポーネント設計</step>
<step agent="Engineer">フロントエンド実装</step>
<step agent="QA">テスト計画・品質保証</step>
</workflow>
</orchestrator_plan>
この構成により、Cursorが各フェーズで適切なペルソナとして振る舞い、それぞれの専門性に基づいた出力を生成してくれ…ているはずです。まだまだ不慣れなのであっているかわかりませんが。
プランニングでの往復
今回は一定複雑な開発だったこともあり、プランニングでの往復を多くしました。
プロジェクトが大きくなると、LLMはタスクの分解が甘いという弱点があります。
たとえば「メール送信機能を実装」というタスクには、確認メール・ウェルカムメール・記事通知・ダイジェストといった複数のテンプレートが含まれますが、最初の分解ではそこまで細かくなりませんでした。
また、セキュリティ面（SQLインジェクション対策、レート制限、メールバリデーション）やスケーラビリティの観点も、こちらから明示的に指示を出しました。
プランニングフェーズで以下のような往復をしました：
- 初期プランの提示 → 事前のリファクタリングを計画したうえで、UIを固めてからバックエンド構築に進みたいと伝える
- メールテンプレートの詳細設計 → Markdownで編集しやすい形を要求
- セキュリティ要件の追加 → 不正なメールアドレスやSQLインジェクション対策
- スケーラビリティの検討 → サーバーレス前提でコスト最適化
このあたりは人間がディレクションする必要がありました。
実装はスムーズ
プランニングが固まった後の実装は、驚くほどスムーズでした。
サブエージェントを使ったオーケストレーションにより、PM・Designer・Engineer・Backend・QAの各ペルソナが適切に機能しました。特に以下の点が印象的でした：
- Supabaseの初期設定: RLSポリシーやトリガーを含むSQLを一発で生成
- React Emailのテンプレート: スタイリングまで含めて動作するコードが出力された
- GitHub Actionsの設定: cronジョブやシークレットの扱いも適切だった
もちろん細かい調整は必要でした。メール内の画像サイズがレイアウトを崩す問題や、トークン有効期限のロジックにバグがあったりしました。ただ、これらもBugbotの指摘やテスト実行を通じて発見・修正できました。
所感
Cursor Subagentは、複雑な開発でも十分に実用的だと感じました。ただし、以下の点は人間の役割として残ります：
- 要件の明確化: 何を作りたいか、どういう制約があるかを言語化する
- アーキテクチャの判断: 技術選定やトレードオフの意思決定
- 品質基準の設定: セキュリティ、パフォーマンス、UXの水準
これらを明確に伝えられれば、実装の大部分はAIに任せられる時代になりつつあります。
昨今、多数のAIツールが登場・進化を続けています。ただ、道具は道具として使い込まないと手に馴染んでいきません。
私は昨年からCursorを使い続けてきましたが、少しずつ「こう伝えればうまくいく」「ここは自分で判断すべき」という感覚が身についてきました。今回の開発も、その延長線上にあります。継続的に使い込むことで初めて見えてくるものがあるなと実感しています。
