結論（先出し） — まず何をすべきか（Action）
ポイント：最初にやるべきは「代表リポジトリで1週間のパイロット」を回して、起動時間・コスト・開発体験を実測することです。理由は、仕様表だけでは運用コストやワークフロー適合性が見えないため。推奨の優先度は次の通りですp:（1）GitHub中心・小〜中規模ならCodespaces、（2）複数クラウド／セルフホスト重視ならGitpod、（3）AWS VPC/IAM統合が最重要ならCloud9。
選定の決定基準（Point）
Point：何を最優先にするかを決めれば、候補を素早く絞れます。
Reason：クラウドIDE選択は単に機能比較だけでなく、統合、セキュリティ、運用コストで差が出るからです。
Example/Evidence：代表的な基準とチェック項目を示します。
- 技術要件：必要言語・ビルドツール、devcontainer対応の有無。
- セキュリティ：データ所在、暗号化方式、SAML/SSO互換性、VPC接続の可否。
- 運用負荷：テンプレート管理、プリビルド運用、ロール管理の容易さ。
- コスト構造：時間課金か固定か、ストレージ・ビルドの課金有無。
- 開発体験：VS Code互換性、起動速度、ファイルI/O レイテンシ。
Recommendation：まず自社の最重要基準（例：セキュリティ＞コスト）を1つ決めてから、下の比較表と照らしてください。
主要3サービスの比較（SWOT＋決定マトリクス）
Point：各サービスの強み・弱みを短く示し、用途別の推奨を提示します。
Reason：実務では“強みの一致”が成功の鍵です。下は要点の要約です。
| 項目 | GitHub Codespaces | Gitpod | AWS Cloud9 |
|---|---|---|---|
| Strengths | GitHub統合が深く、devcontainer公式サポート。VS Code互換。 | マルチクラウド・セルフホスト対応、プリビルドで起動短縮。 | AWS内でのIAM/VPC統合が容易。既存AWS利用企業向け。 |
| Weaknesses | GitHub依存。AWS/GCPとのネイティブ統合は限定的。 | 外部ホスト利用だとデータ所在がベンダーに依存。運用負荷あり。 | コンテナ標準サポートや拡張互換に制限がある場合あり。 |
| コスト/運用 | 時間課金＋ストレージ。小規模なら導入障壁が低い。 | 時間課金＋セルフホストで最適化可能。ただし運用人件が必要。 | EC2ベースのインスタンス費用。長時間稼働は割高になり得る。 |
Example/Decision Scenarios：
- OSSやGitHub中心の小〜中規模チーム：Codespacesが最短導入パス。
- 複数クラウド・オンプレ連携・セルフホストが必須：Gitpod。
- AWS中心でVPC内部リソースと安全に接続したい：Cloud9。
Recommendation：表を元に自社最重要基準と照合し、候補を1〜2に絞ったうえでパイロットへ進んでください。
導入手順（PREPで簡潔）
Point：テンプレ化→権限設計→小規模パイロットの順に進めると失敗が少ないです。
Reason：全社一斉導入はテンプレ不備や権限ミスで混乱を招くため。
Example（ステップ）：
- 要件定義：代表リポジトリ、外部依存（DB、シークレット）、SAML/SSOの有無をリスト化。
- テンプレート作成：devcontainer.json、Dockerfile、初期スクリプトを作る。プリビルドの可否を検討。
- 権限設計：誰が作成・停止・課金管理をするかをIAMまたはOrganizationで設定。
- パイロット（2〜5名、1週間〜1ヶ月）：起動時間・コスト・開発体験の計測を必ず行う。
- 展開：パイロット結果を反映したテンプレと運用ルールをドキュメント化して全社導入。
Recommendation：自動停止のルール、必須拡張のリスト、コストアラートは導入初期に必ず設定してください。
計測例と失敗事例（信頼性向上のために）
Point：具体的な計測項目を持つことで、導入後のズレを事前に潰せます。
Reason：ベンダー仕様だけでは実運用負荷やランニングコストが見えないため。
Example（必須計測項目・サンプル）：
- 初回起動時間（devcontainerのダウンロード＋セットアップ完了まで） — 目標：<30秒〜数分（コードベース依存）。
- プリビルド成功率：高いほど日常起動が安定。
- 平均稼働時間／日、1ユーザー当たりの月間コスト（時間課金×稼働時間＋ストレージ） — 簡易試算テンプレをパイロットで埋めてください。
失敗事例：あるSaaS企業はCloud9を選択したが、コアワークフローがGitHub Actionsに連動しており、Codespacesの方がワークフローに合致していた。原因は決定基準の重み付け不足。
Recommendation：決定前に最低1週間のパイロットを行い、上の計測項目を埋めることを強く推奨します。
FAQ（よくある質問）
Q. データはどこに保管されますか？
A. サービスにより異なります。Codespaces/Gitpodはベンダーのクラウドストレージを使う場合が多く、Cloud9はAWS上（EBS等）を利用することが一般的です。機密データを扱う場合は保存場所と暗号化方式を必ず確認してください。
Q. ローカルとの同期はどう扱うべきですか？
A. 多くはGitベースの同期で、リアルタイムのファイル同期は限定的です。大きなファイルやバイナリは別保存を検討し、事前にワークフローで試験してください。
Q. パイロットは何名で何日が適切ですか？
A. 2〜5名、最低1週間〜1ヶ月の期間が目安です。フロント・バックエンド・インフラを混ぜると実用的な評価になります。
行動提案（CTA）
まずやること（今すぐできる1行）：代表リポジトリでdevcontainerを作り、各サービスで1週間のパイロットを実施してください。計測項目（起動時間・プリビルド成功率・月間コスト）をテンプレに記録し、結果を元に候補を最終決定しましょう。
アフィリエイトについて：当記事にはアフィリエイトリンクが含まれます（紹介料を受け取る場合があります）。中立的な比較提供を第一にしています。
サービス詳細・申し込み（公式ページで最新情報を確認してください）：
GitHub Codespaces の詳細・申し込み（アフィリエイト）
最終更新：2026-10-01。この記事の計測例は一般例です。導入前に必ずご自身の環境でパイロットを行ってください。