deployment-advisor

デプロイメントアドバイザー

概要

インフラにおける最も高くつく過ちは、間違ったサービスを選ぶことではありません。必要のないサービスを選ぶことです。外部依存関係はどれも、請求、障害発生箇所、そして新たに読まなければならないドキュメントを増やします。2番目に高くつく過ちは、ユーザーのマシンですでに稼働しているものを無視することです。

基本原則： 何か新しいものを提案する前に、ユーザーがすでに使っているものを活用し、プロジェクトの実際の要件を満たす最もシンプルなスタックを推奨します。

例外なし。回避策なし。近道なし。

最優先の指針

NO TECHNOLOGY RECOMMENDATION WITHOUT CHECKING WHAT THE USER ALREADY HAS

ユーザーがすでに使用しているツール、ランタイム、サービス、実行中のプロセスを調査していないなら、それは助言ではなく推測です。推測はお金と時間を無駄にします。

使用するタイミング

必須：

• 新しいプロジェクトのセットアップ（「どのデータベースを使うべきですか？」「どこでホスティングすればよいですか？」）
• 外部サービスを含むアーキテクチャ上の判断
• スケーリングに関する相談（「もっと多くのトラフィックを処理する必要があります」）
• コスト最適化（「AWS の請求額が高すぎます」）
• 移行計画（「X から Y に切り替えるべきですか？」）
• データベース、ホスティング、認証、ストレージ、バックグラウンドジョブに関する質問

省略可能：

• ユーザーがすでにスタックを選定しており、実装の支援を求めている
• 既存のデプロイ環境でのバグ修正
• デプロイ済みサービスの軽微な設定変更
• ユーザーが明確に「X を使いたいので、セットアップを手伝ってください」と伝えている（その判断を尊重します）

認知上の落とし穴

よくある思い込み	実際のところ
「今は誰もが Supabase を使っています」	適切なツールはトレンドではなく、プロジェクトによって決まります。SQLite は多くの人が考える以上の処理に対応できます。
「クラウドのほうが常に優れています」	多くのワークロードでは、月額 50 ドルのサーバーレスより月額 4 ドルの VPS のほうが有利です。トラフィックが安定している場合は固定費が適しています。
「サービスが多いほどプロフェッショナルです」	サービスはどれも依存関係であり、請求であり、障害発生箇所です。可動部分が少ないほど、問題が起きる箇所も少なくなります。
「マイクロサービスが必要です」	ほとんどのプロジェクトはモノリスにすべきです。マイクロサービスが解決するのは技術的な問題ではなく、組織的な問題です。
「Docker は必須です」	コンテナ化しなくても問題なくデプロイできるプロジェクトは数多くあります。Docker は、小規模なチームには不要かもしれない複雑さを加えます。
「サーバーレスのほうが安価です」	サーバーレスは、トラフィック量が少なく変動する場合には安価です。負荷が安定しているなら、すでに借りているアイドル状態のキャパシティに割増料金を払うことになります。
「マネージドサービスなら時間を節約できます」	運用の時間は節約できますが、ベンダーロックイン、コスト、API の範囲が増えます。トレードオフ全体を計算してください。

判断フレームワーク

何かを推奨する前に、次の 4 つのステップを順番に完了してください。

ステップ 1：プロジェクトの要件を評価する

いつか必要になるかもしれないものではなく、プロジェクトが実際に必要としているものを特定します。

Classify each requirement as:
- REQUIRED NOW: The project cannot launch without it
- REQUIRED SOON: Needed within the first month post-launch
- NICE TO HAVE: Would be useful but the project works without it
- SPECULATIVE: "We might need this eventually"

Only recommend infrastructure for REQUIRED NOW and REQUIRED SOON.
Everything else is premature optimization.

評価すべき一般的なプロジェクト要件：

要件	確認する質問
データベース	データ量はどのくらいですか？同時接続ユーザー数は何人ですか？読み取り中心ですか、それとも書き込み中心ですか？リレーショナルですか、それともドキュメント型ですか？
認証	ユーザー数は何人ですか？ソーシャルログインは必要ですか？ロールベースのアクセス制御は必要ですか？エンタープライズ SSO は必要ですか？
ファイルストレージ	ファイルのサイズはどのくらいですか？ファイル数はいくつですか？公開ですか、それとも非公開ですか？CDN は必要ですか？
バックグラウンドジョブ	実行頻度はどのくらいですか？実行時間はどのくらいですか？リトライ処理は必要ですか？
リアルタイム通信	WebSocket ですか？サーバー送信イベントですか？ポーリングで十分ですか？
メール	トランザクションメールのみですか？マーケティングメールも必要ですか？月間送信量はどのくらいですか？
決済	単発決済ですか？サブスクリプションですか？分配機能付きのマーケットプレイスですか？
検索	全文検索ですか？ファセット検索ですか？データベースで対応できますか？

ステップ 2：システムのインベントリと照合する

ユーザーのシステムのインベントリを取得するため、godmode:environment-awareness を呼び出します。

Check for:
- Databases already installed (PostgreSQL, MySQL, SQLite, Redis, MongoDB)
- Container tools (Docker, Podman, containerd)
- Cloud CLIs (aws, gcloud, az, vercel, fly, railway, netlify)
- Runtime environments (Node.js, Python, Go, Rust, Java)
- Package managers and lockfiles (reveals the ecosystem)
- Running services (check ports 3000, 5432, 6379, 27017, 8080)
- Existing project dependencies (check package.json, requirements.txt, go.mod)
- .env files or config that reference existing services

ルール： ユーザーがすでに PostgreSQL を実行しているなら、データベースとして Supabase を推奨しないでください。Vercel CLI と Next.js プロジェクトがあるなら、ホスティングには Vercel が明らかな選択肢です。すでにあるものを活用してください。

ステップ 3：トレードオフを踏まえて選択肢を評価する

インフラ要件ごとに、トレードオフを率直に提示します。

ステップ 4：推奨事項の提示

以下の「推奨事項の提示」セクションにある構成で出力を整えてください。

スタック選定マトリックス

データベース

オプション	最適な用途	コスト	複雑さ	注意点
SQLite	単一サーバー、同時書き込みが100未満、読み取りが多い場合	無料	最小限	同時書き込みやレプリケーションには対応しておらず、ファイルベースです
PostgreSQL	複数ユーザー、リレーショナルデータ、複雑なクエリ、ACID が必要な場合	無料（セルフホスト）／月額 $0～15（マネージド）	中程度	サーバープロセスが必要で、大規模環境ではコネクションプーリングが必要です
Supabase	リアルタイム機能と認証が組み込まれた、運用管理不要の PostgreSQL が必要な場合	無料プラン／Pro は月額 $25	低（マネージド）	ベンダーロックイン、行レベルセキュリティの学習コスト
PlanetScale	大規模な MySQL、ブランチングのワークフロー、サーバーレスとの親和性が必要な場合	無料プラン／月額 $29	低（マネージド）	MySQL の方言、無料プランでは外部キーを使用できません
Redis	キャッシュ、セッション、pub/sub、リーダーボード	無料（セルフホスト）／月額 $0～5	低	プライマリデータベースには適しておらず、永続化の設定がない場合はデータ損失のリスクがあります
MongoDB	ドキュメント形式のデータ、柔軟なスキーマ、プロトタイピング	無料プラン（Atlas）／変動	中程度	スキーマの規律は引き続き必要で、結合は扱いにくいです

ホスティング

オプション	最適な用途	コスト	複雑さ	注意点
Vercel	Next.js、静的サイト、JAMstack、サーバーレス関数	無料プラン／Pro は月額 $20	最小限	ベンダーロックイン、サーバーレスの制限、ビルド時間の上限
VPS (Hetzner/DigitalOcean)	安定したトラフィック、完全な制御が必要な場合、Docker ワークロード	月額 $4～20	中程度（自分で管理）	稼働時間、セキュリティパッチ、バックアップは自分で管理します
Railway / Render	すばやいデプロイ、小規模チーム、データベースとアプリをまとめて運用する場合	無料プラン／月額 $5～20	低	コストが急増しやすく、VPS より制御性が低いです
Fly.io	グローバルなエッジデプロイ、コンテナ、世界各地での低レイテンシ	従量課金／基本料金は月額約 $5	中程度	新しいプラットフォームのため、デプロイのデバッグが難しい場合があります
AWS / GCP / Azure	エンタープライズ、複雑なインフラ、DevOps の経験があるチーム	大きく変動	高	想定外の請求、複雑さの急増、専任の運用知識が必要です
Cloudflare Pages/Workers	静的サイト、エッジコンピューティング、すでに Cloudflare を使用している場合	手厚い無料プラン	低～中程度	Worker の制限（CPU 時間、メモリ）、標準規格に準拠しないランタイム

認証

オプション	最適な用途	コスト	複雑さ	注意点
NextAuth / Auth.js	Next.js プロジェクト、ソーシャルログイン、セルフホストでの制御が必要な場合	無料	中程度	設定の複雑さ、セッション方式の選択、移行の難しさ
Supabase Auth	すでにデータベースに Supabase を使用している場合	Supabase に含まれます	低	Supabase エコシステムに依存します
Clerk	洗練された UI コンポーネントとすばやい統合が必要な場合	無料プラン／月額 $25	低	MAU の増加に伴ってコストが上昇し、ベンダーロックインが発生します
Auth0	エンタープライズ SSO、コンプライアンス要件、大規模組織	無料プラン／月額 $23	中程度	複雑なダッシュボード、大規模環境での高コスト
独自実装	非常にシンプルな要件（API キー、単一の管理者）、または高度な専門知識がある場合	無料	高（セキュリティは自分で管理）	すべての脆弱性に対処する責任があります。何をしているか完全に理解していない限り、ユーザー向けの認証には使用しないでください。

ファイルストレージ

オプション	適しているケース	コスト	複雑さ	注意点
ローカルファイルシステム	開発用途のみ、単一サーバー、小さなファイル	無料	最小限	再デプロイ時に失われる、CDN がない、レプリケーションがない
Cloudflare R2	S3 互換、エグレス料金なし、すでに Cloudflare を利用している	無料枠／従量課金	低	比較的新しいサービスで、S3 よりエコシステムが小さい
AWS S3	業界標準、エンタープライズ、複雑なアクセス権限ポリシー	従量課金（エグレス料金が積み重なる）	中程度	隠れたコストはエグレス料金です。予算に含めてください。
Supabase Storage	すでに Supabase を利用している	Supabase に含まれる	低	Supabase に依存し、無料枠ではサイズ制限がある

バックグラウンドジョブ

オプション	適しているケース	コスト	複雑さ	注意点
シンプルな cron／setTimeout	定期タスク、少ない処理量、失敗を許容できる	無料	最小限	リトライ機能、ジョブキュー、永続化がない
BullMQ	Node.js プロジェクト、リトライやジョブスケジューリングが必要、Redis を利用できる	無料（Redis が必要）	中程度	Redis が必要で、モニタリングの設定を推奨
Inngest	イベント駆動型、サーバーレスとの親和性が高い、ステップ関数が必要	無料枠／有料	低〜中程度	ベンダーへの依存、新しいプラットフォーム
pg-boss	PostgreSQL プロジェクト、Redis を使いたくない、処理量が中程度	無料（既存の PostgreSQL を使用）	低〜中程度	データベースの負荷が増えるため、高スループットには不向き

判断フローチャート

digraph deployment_advisor {
    rankdir=TB;
    node [shape=box, style=filled];

    start [label="Infrastructure Decision\nNeeded", fillcolor=lightyellow, shape=doublecircle];
    inventory [label="Step 1: Assess Project Needs\nClassify as REQUIRED NOW\nREQUIRED SOON / NICE TO HAVE", fillcolor="#e3f2fd"];
    env_check [label="Step 2: System Inventory\nInvoke environment-awareness\nCheck installed tools + services", fillcolor="#e3f2fd"];
    already_have [label="Does the user already\nhave a suitable tool?", fillcolor="#fff3e0", shape=diamond];
    use_existing [label="Recommend existing tool\nExplain how it fits", fillcolor="#e8f5e9"];
    evaluate [label="Step 3: Evaluate Options\nCompare cost, complexity,\nfit for project size", fillcolor="#e3f2fd"];
    simple_check [label="Is the simplest option\nsufficient?", fillcolor="#fff3e0", shape=diamond];
    recommend_simple [label="Recommend simplest option\nNote when to upgrade", fillcolor="#e8f5e9"];
    recommend_scaled [label="Recommend scaled option\nExplain why simple\nis not enough", fillcolor="#e8f5e9"];
    present [label="Step 4: Present Recommendation\n+ Alternative\nwith honest trade-offs", fillcolor="#e8f5e9", shape=doublecircle];

    start -> inventory;
    inventory -> env_check;
    env_check -> already_have;
    already_have -> use_existing [label="yes"];
    already_have -> evaluate [label="no"];
    use_existing -> present;
    evaluate -> simple_check;
    simple_check -> recommend_simple [label="yes"];
    simple_check -> recommend_scaled [label="no"];
    recommend_simple -> present;
    recommend_scaled -> present;
}

MCP 統合の評価

プロジェクトのスタックを評価する際は、AI 連携が本当に価値をもたらすかどうかも検討してください。これは、目的もなく AI を追加することではありません。MCP サーバーや Claude との連携によって、実際の問題を解決できるケースを見極めることです。

MCP 統合を検討するケース：

• ユーザーや社内チームが頻繁に問い合わせる API がある（MCP サーバーを使うと、Claude がその API を直接操作できます）
• コンテンツ管理、ナレッジベース、ドキュメントを扱う（Claude がユーザーによる情報の検索や要約を支援できます）
• 自然言語インターフェースによって操作性が向上する、複雑な管理業務がある
• プロジェクトのデータにアクセスできる AI エージェントがあれば、カスタマーサポートのワークフローが改善される

MCP 統合を提案しないケース：

• 複雑なクエリパターンがない、シンプルな CRUD アプリである
• AI を追加しても、ユーザーが実際に抱えている問題を解決できない
• ユーザーが AI 機能への関心を示していない
• 真の生産性向上ではなく、見せかけの機能になってしまう

MCP 統合が妥当な場合：

MCP Integration Opportunity:
- Use case: [specific problem it solves]
- Implementation: MCP server exposing [which endpoints/data]
- Effort: [estimate]
- Value: [what the user or their users gain]

推奨内容の提示

出力形式：

## Deployment Recommendation: [Project Name or Type]

### Project Requirements
- [Requirement 1]: REQUIRED NOW
- [Requirement 2]: REQUIRED SOON
- [Requirement 3]: NICE TO HAVE (defer)

### System Inventory
- Already installed: [tools, databases, CLIs detected]
- Running services: [ports, processes found]
- Project ecosystem: [framework, package manager, existing dependencies]

### Recommended Stack

| Layer | Choice | Reason |
|-------|--------|--------|
| Database | [choice] | [why — reference what user already has] |
| Hosting | [choice] | [why] |
| Auth | [choice] | [why] |
| [other] | [choice] | [why] |

Estimated monthly cost: $[X] (at current scale)

### Alternative Stack
[For when requirements change or scale increases]

| Layer | Choice | When to Switch |
|-------|--------|---------------|
| Database | [alt] | [trigger — e.g., "if concurrent users exceed 1000"] |
| Hosting | [alt] | [trigger] |

### What I Deliberately Did Not Recommend
- [Service X]: [why not — e.g., "overkill for this project size"]
- [Service Y]: [why not — e.g., "you do not have Docker installed and do not need it"]

推奨内容の詳しさはプロジェクトの規模に合わせてください。週末に作るプロジェクトなら、短い推奨内容で十分です。エンタープライズ向け SaaS なら、詳しく説明してください。

ガードレール

次のことは決してしないでください：

• ユーザーがすでに代替サービスをインストールしているか確認せずに、サービスを推奨する
• 無料の代替手段で要件を満たせるのに、有料サービスを提案する
• Docker を持っておらず、必要もないユーザーに Docker を勧める
• エンタープライズ向けクラウドが不要なプロジェクトで、AWS／GCP／Azure を既定の選択肢にする
• 1 つで十分なのに、複数のマネージドサービスを組み合わせる（Supabase で 3 つすべてをまかなえるのに、Supabase + Auth0 + 別のホスティングを使わない）
• 適合性ではなく、流行を理由に推奨する
• コストを無視する（月額の概算を必ず含める）
• モノリスにすべきプロジェクトにマイクロサービスを提案する

次のことを常に行ってください：

• 推奨を行う前に、環境の把握と確認を実施する
• 推奨するスタックを少なくとも 1 つと、代替案を少なくとも 1 つ提示する
• おおよその金額でも、コスト見積もりを含める
• シンプルな推奨案から代替案に切り替えるタイミングを説明する
• あえて推奨しなかったものと、その理由を述べる
• サービス数、コスト、複雑さを抑える方向を優先する
• ユーザーがすでにスタックを決めている場合は、その選択を尊重する

連携

このスキルは、インフラストラクチャに関する意思決定の場面で GodMode ワークフローと連携します。

• godmode:environment-awareness -- このスキルが必要とするシステムインベントリを提供します。推奨を行う前に必ず呼び出してください。
• godmode:rationale -- rationale は機能レベルで代替案を提示し、deployment-advisor はインフラストラクチャ固有の意思決定に関する分析を深めます。
• godmode:system-design -- アーキテクチャの意思決定で連携します。system-design はアプリケーションアーキテクチャを扱い、deployment-advisor はインフラストラクチャとサービスを扱います。
• godmode:project-bootstrap -- deployment-advisor はプロジェクトのセットアップ時に実行され、コードを書く前に初期スタックを確立します。
• godmode:security-protocol -- 認証とホスティングに関する推奨事項は、セキュリティ要件に準拠する必要があります。