--- title: "クラウド開発環境とは｜2026年の選び方とCloud9終了後の代替比較" url: "https://www.issoh.co.jp/tech/details/7580/" published: 2025-07-07 updated: 2026-10-02 categories: ["インフラ・クラウド"] publisher: "株式会社一創" --- # クラウド開発環境とは｜2026年の選び方とCloud9終了後の代替比較 クラウド開発環境（Cloud Development Environment、CDE）とは、ローカルPCにツールを入れなくても、ブラウザからエディタ・ターミナル・実行環境をまとめて使える開発基盤です。環境構築の手間がなく、どの端末からでも同じ環境に入れるのが利点ですが、サービスの勢力図は2024年から2026年にかけて大きく変わりました。長く定番だったAWS Cloud9は2024年7月25日に新規受付を終了し、GitpodはOnaへ転換、GoogleのProject IDXから改称したFirebase Studioも2026年6月22日に新規作成を止めています。この記事で比較するのは、GitHub CodespacesやAWS CloudShellなど現役のサービスの料金と特徴です。比較の前提として、クラウド開発環境の仕組みとローカル環境との違いを整理します。そのうえで、環境を定義するdevcontainer.jsonの設定例と、Cloud9利用者の移行手順まで2026年10月時点の公式情報で解説します。 ## まとめ：クラウド開発環境の要点と2026年10月時点の選び方・移行先 - クラウド開発環境は、ブラウザだけでコード編集・実行・共同作業ができる開発基盤。環境構築不要・端末非依存・チーム統一が主な利点。 - AWS Cloud9は2024年7月25日に新規受付終了、Firebase Studioは2026年6月22日に新規ワークスペース作成を停止し2027年3月22日に終了予定。どちらも新しく始める先には選べない。 - 個人・学習・GitHub中心のチームなら、無料枠のあるGitHub Codespacesが第一候補。 - AWS環境での作業なら、AWSがCloud9の移行先として案内するIDE Toolkits（ローカルVS Code＋AWS連携）かCloudShell（ブラウザの認証済みシェル）。 - コードを社外のクラウドに置けない企業は、Ona Enterprise・Coder・Google Cloud Workstationsのように自社VPC内で動かす型を選ぶ。 どのサービスを選んでも、環境の中身はdevcontainer.jsonというファイル1つで定義できます。定義ファイルをリポジトリに置いておけば、サービスが終了しても移行先で同じ環境を再現できる。これがサービスの改廃が続く今、いちばん効く備えです。 ## クラウド開発環境とは何か｜仕組みとローカル開発環境との違いを整理 クラウド開発環境は、エディタ・ターミナル・ランタイム・依存パッケージをクラウド上のコンテナや仮想マシンにまとめ、ブラウザやローカルのエディタから接続して操作する仕組みです。手元のPCに基本的に必要なのはブラウザだけで、CPUやメモリの負担を引き受けるのはクラウド側です。多くのサービスはVS Codeをブラウザで動かす形を取り、[Dev Containerの定義ファイルで言語やツールのバージョンを固定する仕組み](https://www.issoh.co.jp/tech/details/3728/)に対応しています。この定義の仕様は[Development Container Specificationのdevcontainer.jsonリファレンス](https://containers.dev/implementors/json%5Freference/)として公開されており、Codespaces・Ona・Coderなど複数のサービスが同じ形式を読み込みます。 ### ローカル開発環境との違い｜環境の置き場所・再現性・料金の3観点で比較 ローカル環境は自分のPC上に直接ツールを入れて動かす方式で、[WSL2のようにWindows上にLinux環境を作る](https://www.issoh.co.jp/tech/details/3410/)選択肢もあります。違いは「環境の置き場所」です。 | 観点 | ローカル開発環境 | クラウド開発環境 | | -------- | -------- | ------------- | | 環境の置き場所 | 手元のPC | クラウドのVMやコンテナ | | PCを替えたとき | 再構築が必要 | ログインすれば同じ環境 | | オフライン作業 | できる | できない | | 料金 | PC代のみ | 稼働時間とストレージで課金 | | 性能の上限 | PCのスペック | 選んだマシンのコア数 | クラウド開発環境はチーム全員の環境を揃えやすい一方、ネットワーク接続が前提で、稼働時間に応じた料金が発生します。基盤には[Dockerなどのコンテナ技術](https://www.issoh.co.jp/tech/details/6857/)が使われ、環境の再現性を支えています。 ### メリットと見落とされがちな注意点｜コスト・回線依存・コードの所在 最大のメリットは環境構築の省略です。新メンバーが参加した初日に、定義ファイルから同じ環境を起動できます。端末を選ばず、iPadや低スペックPCからでも高負荷なビルドを回せる点も実務的です。 注意点のうち、実務で最初に効いてくるのはコストです。稼働時間課金のサービスは消し忘れると無駄が出ます。Codespacesの場合、既定では操作が30分途絶えると自動停止しますが、停止中もストレージ料金は積み上がります。次に確認したいのがネットワーク依存です。回線が不安定な場合に起きるのは、入力の遅延や操作の停止です。最後がデータの所在で、ソースコードが外部クラウドに置かれるため、機密性の高いプロジェクトでは契約上の管理ポリシーを先に確認します。常時オフラインで作業する人や、外部にコードを置けない規約のチームには、ホスト型のクラウド開発環境は向きません。 ## 2024〜2026年のCloud9・Gitpod・Firebase Studioの改廃 クラウド開発環境を今選ぶうえで、直近の改廃を押さえておく必要があります。2025年以前の記事を頼りに選ぶ場合に注意したいのは、紹介されていても、すでに新規利用できないサービスがある点です。2年あまりで主要3サービスが新規受付を止めたという事実は、選定時に「終了したときの逃げ道」まで考えるべき理由にもなります。 ### AWS Cloud9は2024年7月25日に新規受付終了・既存利用者のみ継続 長く定番だったAWS Cloud9は、2024年7月25日付で新規顧客への提供を終了しました。既存ユーザーは引き続き利用できますが、AWSが明言しているのは、新機能を追加しないという方針です。移行先については、AWS公式ブログの[How to migrate from AWS Cloud9 to AWS IDE Toolkits or AWS CloudShell](https://aws.amazon.com/blogs/devops/how-to-migrate-from-aws-cloud9-to-aws-ide-toolkits-or-aws-cloudshell/)が、VS CodeやJetBrains向けのAWS IDE ToolkitsとAWS CloudShellの2つを案内しています。これから始める人はCloud9を選べないため、後述の代替から選びます。 ### Gitpod改めOna｜Gitpod Classicは2025年10月15日に提供終了 ブラウザIDEの草分けだったGitpodは、2025年9月にOnaへ改称し、AIエージェントの実行基盤へ軸足を移しました。Onaの告知[Gitpod Classic PAYG sunset on October 15th](https://ona.com/stories/gitpod-classic-payg-sunset)によると、従量課金のGitpod Classicは2025年10月15日に終了しています。環境定義も独自の.gitpod.ymlから、devcontainer.jsonとautomations.ymlの組み合わせへ切り替わりました。 料金はFree（同時3環境・最大4vCPU／16GB RAM）、Core（月20ドルから）、自社VPCへ展開するEnterpriseの3段で、2025年10月時点の告知内容です。個人が無料で触る入口は残っていますが、製品の重心はエージェント運用と企業の統制に移っており、「手軽なブラウザIDE」として選ぶ理由は薄れました。 ### Firebase Studio｜2026年6月22日作成停止・2027年3月22日終了 GoogleのProject IDXは2025年4月にFirebase Studioへ改称し、Geminiを組み込んだVS Codeベースの無料環境として広まりました。ところが公式の[Firebase Studio sunset and project migration](https://firebase.google.com/docs/studio/migrating-project)では、2026年3月19日にサンセットを発表し、2026年6月22日に新規ワークスペース作成と新規登録を停止、2027年3月22日にサービスを終了して残ったデータを完全に削除すると明記されています。移行先として案内されているのはGoogle AI StudioとGoogle Antigravityです。 Firestore・Authentication・App HostingなどFirebase本体のサービスは影響を受けず、デプロイ済みのアプリは動き続けます。消えるのは開発環境とワークスペースの中身だけなので、既存利用者に必要な対応は、コードをGitリポジトリへ退避することです。移行先の選び方と引き上げ手順は[Firebase Studioの2027年3月終了までの移行判断と引き上げ手順](https://www.issoh.co.jp/tech/details/16676/)で詳しく扱っています。 ## 主要なクラウド開発環境の比較表｜2026年10月時点の料金・提供形態・用途 現役で選べる主要サービスを、提供形態・料金・向くケースで整理します。料金は2026年10月時点の公式ページの記載で、改定されることがあるため契約前に各公式ページで最新額を確認してください。 | サービス | 提供形態 | 料金（目安） | 向くケース | | ------------------------ | ------------- | ------------------ | ------------ | | GitHub Codespaces | ホスト型・VS Code | 無料枠120コアアワー＋15GB／月 | 個人〜チーム開発全般 | | AWS CloudShell | ブラウザの簡易シェル | 無料（1GB／リージョン） | AWSの運用・CLI作業 | | AWS IDE Toolkits | ローカルIDE＋AWS連携 | 無料（OSS） | Cloud9からの移行 | | Ona（旧Gitpod） | ホスト型・自社VPC | Free／Core月20ドル〜 | エージェント併用の開発 | | Coder／Cloud Workstations | セルフホスト・マネージド | 要構築・別料金 | 企業の統制・機密重視 | | AWS Cloud9 | ホスト型・既存のみ | 新規受付終了 | 既存ユーザーの継続のみ | | Firebase Studio | ホスト型・既存のみ | 新規作成停止 | 2027年3月までに退避 | 無料で始めやすいのはCodespacesです。AWSを軸に開発するならCloudShellやIDE Toolkitsが手になじみます。ブラウザだけで書いてそのまま公開まで進めたい学習用途なら、[ブラウザだけで開発・公開できるReplit](https://www.issoh.co.jp/tech/details/4746/)も候補に入ります。各サービスを比較する際の具体的な確認事項は、以下の料金・提供形態・用途の説明のとおりです。 ### GitHub Codespaces｜無料枠120コアアワーと超過料金・自動停止の既定値 GitHubが提供するVS Codeベースのクラウド開発環境です。[GitHub Codespacesの課金ドキュメント](https://docs.github.com/en/billing/concepts/product-billing/github-codespaces)によると、個人のGitHub Freeには月120コアアワーと15GB-月のストレージ、GitHub Proには月180コアアワーと20GB-月が無料で付きます。コアアワーはコア数×稼働時間で数えるため、2コアマシンなら約60時間、4コアなら約30時間で無料枠を使い切ります。 超過分は2コアで1時間0.18ドル、4コアで0.36ドル、32コアで2.88ドルとコア数に比例し、ストレージは1GB-月あたり0.07ドルです。[タイムアウトの設定](https://docs.github.com/en/codespaces/setting-your-user-preferences/setting-your-timeout-period-for-github-codespaces)は既定30分で5〜240分の範囲で変えられ、停止したcodespaceは[自動削除の設定](https://docs.github.com/en/codespaces/setting-your-user-preferences/configuring-automatic-deletion-of-your-codespaces)に従い既定で30日後に消えます。リポジトリと直結してそのまま開発に入れるため、GitHubでコードを管理しているなら第一候補です。 ### AWS CloudShell・IDE Toolkits｜Cloud9移行先2種 CloudShellは、AWSマネジメントコンソールから開くブラウザ上のシェルで、AWS CLIが認証済みの状態ですぐ使え、追加料金はかかりません。[CloudShellのクォータと制限](https://docs.aws.amazon.com/cloudshell/latest/userguide/limits.html)によると、ホームディレクトリにはリージョンごとに1GBの永続ストレージが付き、最後のセッションから120日使わないと削除されます。操作が20〜30分途絶えるとセッションが切れ、連続しても約12時間で終了し、外部からの受信ポートは開けません。フルのエディタ用途ではなく、コマンド操作や短いスクリプト実行の場所と割り切るのが正しい使い方です。 IDE Toolkitsは、手元のVS CodeやJetBrains製IDEにAWS連携機能を足すオープンソースのプラグインで、ローカルの使い慣れたエディタからLambdaやS3などのリソースを扱えます。「ブラウザ完結」ではなくなる点は理解して選びます。ブラウザ完結にこだわるなら、Codespacesの中にAWS CLIを入れる構成（次の章の設定例）が現実的です。 ### Ona・Coder・Cloud Workstations｜企業の統制と自社運用 企業で統制を効かせたい場合は、自社のクラウドアカウント内に開発環境を置ける型が候補になります。[CoderはGitHubでソースが公開されたセルフホスト型](https://github.com/coder/coder)で、Terraformのテンプレートで環境を定義し、自社のKubernetesやVMの上で動かします。[Google Cloud Workstations](https://docs.cloud.google.com/workstations/docs/overview)はGoogle Cloudのマネージドサービスで、VPC内に開発環境を閉じ込められる提供形態です。OnaもEnterpriseプランで自社VPCへの展開に対応しています。 いずれも運用とコスト管理は自前になり、開発者が10人に満たない規模では基盤の維持費が開発環境を揃える効果を上回りがちです。この型を選ぶのは、ソースコードの社外持ち出しが規約で禁じられている場合か、開発者が数十人規模でイメージの統一と監査ログが必要な場合に限ります。 ## devcontainer.jsonの環境定義とCodespacesの起動手順・設定例 クラウド開発環境の中身は、リポジトリ直下の.devcontainerフォルダに置くdevcontainer.jsonで決まります。この1ファイルがあれば、Codespacesでも、ローカルのVS Codeでも、OnaやCoderでも同じ環境を立ち上げることが可能です。サービスの改廃が続く状況では、特定サービスの画面で手作業の設定を積むより、定義をファイルとしてリポジトリに残すほうが乗り換えに強くなります。 ### devcontainer.jsonの最小構成｜Node.js・AWS CLIの設定例 Node.js 22のイメージに、Dev Container Featuresの[aws-cli](https://github.com/devcontainers/features/tree/main/src/aws-cli)を足し、VS Code拡張のAWS Toolkitを自動で入れる設定です。Cloud9でNode.jsとAWS CLIを使っていた人が、ほぼ同じ道具立てをCodespacesで再現できます。 ``` // .devcontainer/devcontainer.json { "name": "node-aws", "image": "mcr.microsoft.com/devcontainers/javascript-node:22", "features": { "ghcr.io/devcontainers/features/aws-cli:1": {} }, "hostRequirements": { "cpus": 2 }, "forwardPorts": [3000], "postCreateCommand": "npm ci", "customizations": { "vscode": { "extensions": ["amazonwebservices.aws-toolkit-vscode"] } } } ``` hostRequirementsは必要な最小コア数の指定で、Codespacesはこれを下回るマシンを選択肢に出しません。postCreateCommandは環境の作成直後に1回だけ走るため、依存パッケージの導入をここに置くと新メンバーの初回起動で手順が要りません。コンテナ作成までのVS Code側の操作は[VS Codeで開発コンテナを作る手順とdevcontainer.jsonの設定](https://www.issoh.co.jp/tech/details/9565/)にまとめています。 ### gh codespace createで起動しアイドル停止と保持期間を指定する手順 ブラウザから作ると既定値のまま起動しますが、GitHub CLIの[gh codespace create](https://cli.github.com/manual/gh%5Fcodespace%5Fcreate)ならマシンの大きさ、アイドル停止までの時間、停止後の保持期間を作成時に決められます。止め忘れによる課金を防ぐには、この3つを最初に絞っておくのが確実です。 ``` # 2コアのマシンで作成し、15分無操作で停止、停止後72時間で自動削除 gh codespace create --repo your-org/your-repo --branch main \ --machine basicLinux32gb --idle-timeout 15m --retention-period 72h # 自分のcodespaceの一覧と状態を確認する gh codespace list # 作業を終えたら明示的に停止し、不要になったら削除する gh codespace stop -c gh codespace delete -c ``` –retention-periodの上限は30日で、保持中もストレージ料金は発生します。週に数回しか触らないリポジトリなら、保持期間を短くしてその都度作り直すほうが安く済みます。devcontainer.jsonさえリポジトリにあれば、作り直しにかかるのは起動待ちの数分だけです。 ## クラウド開発環境の選び方｜コードの置き場所・予算・統制で決める判断基準 選定は「コードの置き場所」と「予算」と「社外にコードを置けるか」の3点で大きく決まります。学習や個人開発では、まず無料枠の範囲で使い、足りなければ従量課金へ進むのが無駄がありません。 ### 用途別の第一候補｜個人学習・GitHub中心・AWS運用・機密案件の4類型 | 用途 | 第一候補 | 理由 | | -------------- | ------------------------ | ------------- | | 個人の学習・試作 | GitHub Codespaces | 月120コアアワーの無料枠 | | GitHub中心のチーム開発 | GitHub Codespaces | リポジトリと権限を共有 | | AWSの運用・CLI作業 | CloudShell＋IDE Toolkits | 認証済みで追加料金なし | | コードを社外に置けない案件 | Coder／Cloud Workstations | 自社VPC内で完結 | よくある失敗は、稼働時間課金のサービスでマシンを止め忘れ、想定外の料金が出るケースです。使い終わったらワークスペースを停止する運用と、アイドル停止の時間を最初に決めておきます。自社VPC内にクラウド開発環境を構築する場合や、Cloud9撤退後のAWS開発基盤をネットワーク・IAMの設計から整え直す場合は、[AWS・Google Cloud・Azureのインフラ構築サービス](https://www.issoh.co.jp/service/system/aws/)でご相談いただけます。 ### 採用を見送る場面｜オフライン作業・GPU常用・外部持ち出し禁止の案件 次の条件に当てはまるなら、ホスト型のクラウド開発環境は採用しません。移動中や工場内など回線のない場所で作業する時間が長い場合、GPUを毎日長時間使う機械学習の開発で従量課金が手元のワークステーション代を上回る場合、そして契約でソースコードの社外クラウドへの持ち出しが禁じられている場合です。 この3つのどれかに当たるなら、ローカル環境に戻すのが正解です。その場合もdevcontainer.jsonはそのまま使え、[Nixで開発環境を宣言的に揃えるDevbox](https://www.issoh.co.jp/tech/details/8323/)のような手段でもメンバー間の差を抑えられます。「クラウドかローカルか」より、「環境の定義をファイルとして持っているか」のほうが、チームの生産性への効き目は大きいからです。 ## AWS Cloud9利用者の移行手順｜Git退避から移行先の選択・環境削除まで 既存のCloud9を使い続けている場合も、新機能が止まっているため、いずれ別環境への移行を見据えておくと安全です。残っている環境の洗い出しから削除までのコマンド手順は、[AWS Cloud9の棚卸しと移行をCLIで進める手順](https://www.issoh.co.jp/tech/details/17722/)にまとめています。移行の流れは次の4段です。 1. Cloud9上のソースコードと設定ファイルをGitリポジトリ（GitHubなど）へ退避する 2. Cloud9で入れていた言語やツールを、devcontainer.jsonに書き起こしてリポジトリに入れる 3. ブラウザ完結を続けたいならGitHub Codespaces、手元のVS CodeでAWSを扱いたいならAWS IDE Toolkitsを入れる 4. AWS CLIの操作はCloudShellへ移し、動作を確かめてからCloud9環境とEC2インスタンスを削除する 手順1は、Cloud9のターミナルで次のように実行します。未コミットの変更や、.envのような秘密情報をうっかり公開リポジトリへ上げないよう、pushの前に.gitignoreを確認します。 ``` # Cloud9のターミナルで実行（リポジトリ未作成の作業フォルダの場合） cd ~/environment/my-app git init git add -A git status # .envや認証情報が含まれていないか確認する git commit -m "Cloud9から退避" git branch -M main git remote add origin https://github.com/your-org/my-app.git git push -u origin main ``` Cloud9のEC2環境はインスタンスとEBSボリュームの料金がかかり続けるため、移行を終えたら環境を削除して止めます。リポジトリさえ分離しておけば、移行先の選択肢は後からでも変えられます。 ## よくある質問 クラウド開発環境の選定や移行で寄せられる質問に、2026年10月時点の公式情報で答えます。 ### クラウド開発環境とはどういう環境ですか？ ローカルPCにツールを入れず、ブラウザからエディタ・ターミナル・実行環境をまとめて使える開発基盤です。CPUやメモリを負担するのはクラウド側で、手元に必要なのはブラウザだけです。多くがVS Codeをブラウザで動かす形を取り、devcontainer.jsonという定義ファイルで環境を固定できるため、チーム全員が同じ構成をすぐ再現できます。英語ではCloud Development Environment（CDE）と呼ばれます。 ### クラウド開発環境の例（サービス）には何がありますか？ 2026年10月時点で新規に始められる主なサービスは、GitHub Codespaces、AWS CloudShell、AWS IDE Toolkits、Ona（旧Gitpod）、企業向けのCoderやGoogle Cloud Workstationsです。AWS Cloud9は2024年7月25日に新規受付を終了し、Firebase Studio（旧Project IDX）も2026年6月22日に新規ワークスペースの作成を停止しました。古い比較記事に載っていても、この2つは新規の選択肢から外して考えます。 ### AWSで使える開発環境は何ですか？ AWS Cloud9は新規受付を終了したため、これからAWSで開発環境を用意するなら、AWS IDE Toolkits（VS CodeやJetBrainsにAWS連携を追加するプラグイン）かAWS CloudShell（ブラウザの認証済みシェル）が、AWS自身が案内する選択肢です。ブラウザ完結を重視するなら、GitHub CodespacesにAWS CLIを入れて使う方法もあります。用途がCLI中心ならCloudShell、エディタ中心ならIDE Toolkitsが向きます。 ### 無料で使えるクラウド開発環境はありますか？ あります。GitHub Codespacesは個人のGitHub Freeアカウントなら月120コアアワー（2コアで約60時間）と15GB-月のストレージが無料です。AWS CloudShellも追加料金なしで、リージョンごとに1GBの永続ストレージが付きます。OnaにもFreeプランがあります。以前は無料の定番だったFirebase Studioは、2026年6月22日から新規登録ができません。無料枠の超過はマシンの止め忘れで起きやすいため、アイドル停止の時間を短めに設定しておきます。 ### AWS Cloud9はまだ使えますか？ 既存ユーザーは引き続き利用できますが、2024年7月25日以降、新規の顧客は利用を開始できません。AWSはCloud9に新機能を追加しない方針で、セキュリティや可用性の維持に限定して運用しています。すでに使っている場合も、コードをGitリポジトリへ退避し、devcontainer.jsonで環境を書き起こしておくと、CodespacesやIDE Toolkitsへの移行が短時間で済みます。 ## 関連記事 - [Dev Container（devcontainer）のメリットとは｜Dockerで開発環境を統一する仕組みと設定【2026年版】](https://www.issoh.co.jp/tech/details/3728/)：クラウド開発環境の土台になる定義ファイルの考え方 - [AWS Cloud9は今も使えるか｜新規受付終了後の棚卸しと移行をCLIで進める手順](https://www.issoh.co.jp/tech/details/17722/)：Cloud9環境の洗い出しと削除のコマンド - [Firebase Studioとは｜2027年3月終了までの移行判断と引き上げ手順](https://www.issoh.co.jp/tech/details/16676/)：Firebase Studioからの退避先の選び方 - [WSLで開発環境を構築する手順｜.wslconfig調整とDocker連携・肥大化の対処](https://www.issoh.co.jp/tech/details/17354/)：ローカルに戻す場合のWindowsでの構築手順 - [Dockerとは｜仮想マシンとの違い・必要スペック・インストール手順を解説【2026年版】](https://www.issoh.co.jp/tech/details/6857/)：コンテナ技術の基礎 --- 出典: [クラウド開発環境とは｜2026年の選び方とCloud9終了後の代替比較]()（株式会社一創）