結論（先に示します）：GitHubに開発を集約できるならGitHub Codespacesが導入コストと立ち上がりの速さで最短です。マルチホストやポータビリティ重視ならGitpod、AWSリソース操作が主ならAWS Cloud9を推奨します。以下は判断基準・実務チェックリスト・PoC手順を含む実践ガイドです（本文にはアフィリエイトリンクが含まれます）。
注目点と理由（Attention → Interest）
ポイント：選定は「何を最優先にするか（統合性／ポータビリティ／AWS依存）」で決まります。理由は、設計思想の違いが運用コストとセキュリティリスクに直結するためです。
例／証拠：短時間でレビューやペアプロを行うチームでは、起動時間が30〜60秒の環境が生産性を大きく改善します（現場観測値）。一方、AWS内のリソース操作を頻繁に行う場合、VPC接続やIAM統合がスムーズなCloud9の恩恵が大きいです。
推奨アクション（Action）：まずは代表リポジトリで各サービスのPoCを行い、起動時間・稼働時間・イメージ更新頻度の3指標を2週間計測してください。下の「導入手順」で具体的に示します。
比較基準（何を測るか：費用・性能・セキュリティ・運用）
Point：実運用で差が出る4軸を必ず確認してください。
Reason：課金・レスポンス・アクセス管理・メンテ負荷は運用コストに直結します。
- コスト：時間単位の課金、有無のアイドル課金、自動停止の精度。参考想定：低スペックでSaaSは時間当たり0.02〜0.20 USD帯が多く、専用インスタンスはさらに高くなります（プランで差が大きいためPoCで試算を）。
- 性能：cold start（起動時間）、CPU/メモリ上限、イメージビルド時間。CI分離の有無でコストと速度が変わります。
- セキュリティ：シークレット注入方式、VPC／プライベート接続、監査ログ（CloudTrailやGitHub Audit Log）対応。
- 運用負荷：セルフホストの有無、イメージ管理フロー、ユーザーライフサイクル管理（SSO・SCIM）。
Recommendation：導入前に最低限、平均起動時間（cold／warm）・想定月間稼働時間・イメージ更新回数を測り、見積もりを作ること。
サービス比較（SWOT と推奨）
Point：ここでは実務観点でのSWOTと短い推奨を示します。
Reason：単なる機能比較でなく、運用とリスクを踏まえた選択が重要です。
GitHub Codespaces
Point：GitHubにリポジトリを集約するチームに最短導入を提供します。
Reason：devcontainer がそのまま使え、GitHub Actionsとの統合が強力なためセットアップが速いです。
Example／Evidence：devcontainer で定義された拡張やポートフォワーディングがほぼそのまま反映されるため、環境差が減ります。注意点として大規模ビルドを直接行うとコスト高になるケースがあります（CIで分離推奨）。
Recommendation：GitHub中心であればPoC優先。自動停止と権限（Organization・SAML）を事前に設定してください。
Gitpod
Point：ポータビリティとマルチホスト対応が最大の強みです。
Reason：OCIベースのイメージで再現性が高く、GitHub/GitLab/Bitbucketを跨いだ運用が可能です。
Example／Evidence：OSSプロジェクトや外部コントリビュータを多く含むチームに適しており、セルフホストによりセキュリティ制御を強化できます。ただしセルフホストは運用負荷が上がります。
Recommendation：ポータブル運用が必要で、運用要員が確保できるならGitpodを検討。イメージビルド時間とストレージコストを見積もってください。
AWS Cloud9
Point：AWSリソース操作やサーバレス開発が主なワークロードに最適です。
Reason：IAM、VPC、Lambda など既存のAWS環境との親和性が高いからです。
Example／Evidence：Cloud9 は既存のIAMロールを付与してEC2から直接リソース操作が可能。反面、クラウド間の移行は手間がかかります。権限設定を誤ると不要なアクセス権が生まれるため最小権限で設定することが重要です。
Recommendation：AWSベース開発と既存アカウント統合が目的ならCloud9のPoCを推奨。CloudTrailでアクセス監査を必ず有効にしてください。
短い決定マトリクス（参考）
| 軸 | Codespaces | Gitpod | Cloud9 |
|---|---|---|---|
| 統合 | GitHub密結合 | 多ホスト対応 | AWS密結合 |
| ポータビリティ | 低 | 高 | 低 |
| 運用負荷 | 低（SaaS） | 中（セルフ高） | 中 |
| セキュリティ制御 | GitHub側依存 | 柔軟／セルフで強化可 | AWSで詳細制御可 |
導入手順（PoCチェックリスト／Prevent失敗）
Point：スモールスタート＋計測が失敗を防ぎます。
Reason：事前に指標を定めないとコストや運用問題が見えづらいためです。
- ステップ1（準備）— 代表リポジトリ1つを選定し、devcontainer/Dockerfileを整理。計測用のスプレッドシートを用意（起動時間、ビルド時間、月間稼働時間）。
- ステップ2（起動試験）— 各サービスでワークスペースを起動（cold/warmをそれぞれ3回測定）。平均値を記録。
- ステップ3（コスト試算）— 平均起動時間×稼働時間＋ストレージ/月を想定して見積もり。自動停止がない場合のアイドル課金を含めること。
- ステップ4（セキュリティ）— シークレット注入の流れ（.env, GitHub Secrets, AWS Secrets Manager）とアクセスログ設定を確認。
- ステップ5（運用）— イメージ更新フロー、ユーザー招待と退職時の削除手順、アラート（コスト超過）の設定を確立。
失敗例と対策：自動停止を設定しておらずアイドルで課金が発生→対策：自動停止＋月次コストアラートを導入。イメージビルドが遅くCIが停滞→対策：キャッシュ戦略とCI分離。
FAQとよくある落とし穴
Q：どれが最も安い？ A：利用パターン次第。短時間断続利用は自動停止があるサービスが有利。常時稼働は専用インスタンスや予約枠を検討。
Q：オンプレの開発者を移行できるか？ A：可能。ただしVPN、認証フロー、ローカルデバイス依存ツールの代替が必要になる場合があります。
Q：シークレットや機密コードの扱いは？ A：トークンは環境変数ではなくシークレット管理機能を使い、権限は最小権限で。監査ログを必ず有効にしてください。
行動提案（Action）：まずは無料トライアルで代表リポジトリを起動して、起動時間・ビルド時間・想定稼働時間を記録してください。計測結果を持って社内でコスト比較表を作ると意思決定が早くなります。
アフィリエイト／開示：当記事にはアフィリエイトリンクが含まれており、リンク経由でサービス加入があった場合に紹介手数料を得ることがあります。掲載情報は執筆時点の公表情報と筆者の現場経験に基づきますが、最終的な料金や仕様は公式ドキュメントでご確認ください。
もしご希望なら、あなたのスタック（言語、CI、代表的な依存）を教えてください。devcontainer の具体例やPoCの測定シート（テンプレート）を送ります。