ローカルPCで全部動かす開発から、クラウド（VPS / EC2など）も併用する開発へ移るときに強いのが、Docker / Cursor / Remote-SSH の組み合わせです。
結論から言うと、この構成は「速く・再現性高く・複数案件を並行しやすい」一方で、「リソース不足・ネットワーク依存・運用の癖」がデメリットになりがちです。
この記事では、それぞれのツールの役割と、導入判断に必要なメリット・デメリットを整理します。
まず全体像：この3つは何を解決する？
- Docker：開発環境をコンテナ化して、OS差・依存関係差を消す（再現性）
- Cursor：AI支援が強いエディタで、実装スピードを上げる（生産性）
- Remote-SSH：ローカルではなくリモート環境で開発できる（性能・統一環境・チーム向き）
ざっくり言うと、
- 「環境差で詰まる」を Docker が減らし
- 「調査と実装が遅い」を Cursor が短縮し
- 「ローカルが重い・環境を統一したい」を Remote-SSH が解決します
Docker のメリット・デメリット
Dockerのメリット
1) 環境差が消える（再現性が強い）
- 「自分のPCでは動くのに、本番で動かない」を減らせる
- PHP / Node / DB / Redis など複数サービスがいても、同じ構成を再現できる
2) 案件を分離できる（複数案件に強い）
- 案件AはPHP8.2、案件BはPHP8.1…みたいな共存が楽
- 依存関係の衝突が起きにくい
3) チーム化しやすい
- docker compose up で誰でも同じ環境を立ち上げられる
- 新メンバーの立ち上がりが速い
4) ローカルPCの破壊を防げる
- ホストOSの環境を汚しにくい
- “入れたものを戻せない”事故が減る
Dockerのデメリット
1) ローカルが重くなる（特にMac + Docker Desktop）
- CPU / メモリを食う
- DBや検索系（Elasticsearch等）を積むと一気に辛い
- ファイル同期が遅くなることもある（特に大量ファイル）
2) ネットワークとポートの罠
- localhost:8001 が別のサービスと衝突
- プロキシ / リダイレクト / HSTS / キャッシュで「ブラウザだけ挙動が違う」も起きがち
- コンテナ間通信、ホストとの接続など、慣れないと混乱する
3) 永続化（volume）と移行が難しい
- Docker Desktopの移行・バックアップが分かりづらい
- volumeが増えるほど「どれが大事？」となる
- “消したらDBも消えた”が起きる
4) 本番と完全一致はしないこともある
- ローカルはDocker、本番はKubernetes/別構成…などでズレが出る
- ファイル権限やストレージの差で詰まることがある
Dockerが向いている人
- 複数案件を並行する
- チーム開発・引き継ぎが多い
- DB/Redis/Queueなど周辺サービス込みで動かしたい
Dockerがしんどくなりやすい人
- ローカルPCが非力（メモリ少なめ）
- とにかく早く軽くコードを書きたいのが最優先
- volume運用やネットワークに時間をかけたくない
Cursor のメリット・デメリット（AIエディタとして）
Cursorのメリット
1) 実装スピードが上がる
- 「やりたいこと」を説明 → 叩き台生成 → 手直し、が速い
- 既存コードの改修（リファクタ / 例外処理追加 / テスト追加）に強い
2) 調査コストが下がる
- エラーの原因推定
- ログや設定から「怪しいポイント」を挙げる
- 仕様書・READMEの整備も進む
3) “理解しながら進む”がやりやすい
- 「このファイルの責務は？」
- 「この処理は何を保証してる？」
- みたいな問いに強い
Cursorのデメリット
1) AI任せにすると品質が落ちる
- “それっぽい”コードを出すことがある
- セキュリティ・境界条件・性能面は人のチェック必須
- 「動くけど保守できない」が生まれやすい
2) 大規模変更はレビューが必須
- 一括変更は便利だが、差分が大きくなる
- 影響範囲の読み違いが起きる
3) リモート開発時に重くなることがある
- Remote-SSH と組み合わせると、言語サーバや解析が重くなりがち
- リモート側スペックが低いと体感が落ちる
Cursorが向いている人
- 仕様書から実装へ落とすのが多い
- “速度”を最優先したい
- ドキュメント整備も並行したい
Cursor運用のコツ
- AIの提案は「採用」ではなく「下書き」扱いにする
- 重要箇所はテスト or 最低限の検証をセットにする
- 大きい変更は「小さく分けて」適用する
Remote-SSH のメリット・デメリット（リモート開発）
Remote-SSHのメリット
1) ローカルを軽くできる（性能をリモートに逃がせる）
- ローカルPCの負荷が減る
- Dockerもリモートで回せるので、Macが軽くなることが多い
2) 開発環境を統一しやすい
- チームで同じOS/同じミドルウェアに寄せられる
- OS差のバグが減る
3) サーバ寄りの案件に強い
- Nginx/SSL/cron/queue など、実運用に近い形で作業できる
- 本番を意識した検証がしやすい
Remote-SSHのデメリット
1) ネットワーク依存（回線が悪いと即つらい）
- ラグや切断があると作業効率が落ちる
- 出先・移動中に弱い
2) リモート側のスペック不足で不安定になる
- 小さいインスタンスだと、言語サーバ＋Docker＋エディタで落ちやすい
- インストールがタイムアウトなどが起きることもある
3) セキュリティ運用が必須
- SSH鍵管理、FW設定、fail2ban、権限設計など
- 「開発が速い」代わりに「守りの運用」が必要になる
4) コストが増える場合がある
- リモートに開発用サーバを用意するなら月額が発生
- インスタンスを上げるほど快適だがコストも上がる
Remote-SSHが向いている人
- ローカルが重い/限界
- Docker込みで統一環境を作りたい
- サーバ寄りの開発（Web/インフラ寄り）が多い
この3つを組み合わせた時の“強み”と“落とし穴”
組み合わせの強み（理想形）
- Dockerで「環境差」をなくす
- Remote-SSHで「重さ」をリモートへ逃がす
- Cursorで「実装速度」を上げる
つまり、再現性 × パワー × 生産性のフルセットになります。
よくある落とし穴（現場で詰まりやすいポイント）
1) リモートのメモリ不足でCursorが重い
- 言語サーバ（PHP/TS）やDockerが同時に動く
- 対策：リモートのスペックを上げる／コンテナを絞る／解析機能を調整する
2) ポート/リダイレクト/HSTSで挙動が崩れる
- 「ブラウザだけ別ポートに飛ぶ」「HTTPS強制」など
- 対策：開発用ドメインを分ける、ブラウザのHSTS/キャッシュを整理、Proxy設定を統一
3) volumeが増えて移行・バックアップが辛い
- 対策：DBはダンプ運用を用意（定期的にexport）、重要volumeを明確にする
4) セキュリティを後回しにしがち
- 対策：鍵運用・権限分離・FW・ログ監視だけは最初に整える
おすすめ運用（迷ったらこの形）
運用パターンA：ローカル重い → リモートに寄せる
- リモート：Docker + DB + アプリ
- ローカル：Cursor（Remote-SSH接続のみ） → 一番“体感が軽い”ことが多い
運用パターンB：オフライン作業もしたい → ローカルDocker中心
- ローカル：Docker + Cursor
- リモート：検証環境（本番相当）だけ → 回線に左右されにくい
運用パターンC：チーム開発 → 共有の開発サーバ＋Docker
- 開発サーバを統一して、全員がRemote-SSH
- composeで環境固定 → オンボーディング最速
まとめ：メリット・デメリットを理解すると最強構成になる
- Docker：環境差を消して再現性を上げる（ただし重い/移行が面倒）
- Cursor：実装スピードと調査効率が上がる（ただし最終責任は人）
- Remote-SSH：ローカル負荷を逃がして環境統一できる（ただし回線・セキュリティ・コストが増える）
この3つは「なんとなく導入」だと詰まりやすいですが、役割を分けて設計すると、開発速度と安定性が両立できます。
