---
title: "ruby on rails を vscode で開発する環境構築【2026年版】拡張機能・デバッグ・Dev Container"
url: "https://www.issoh.co.jp/tech/details/2878/"
published: 2024-07-02
updated: 2026-07-17
categories: ["Ruby on Rails"]
publisher: "株式会社一創"
---

# ruby on rails を vscode で開発する環境構築【2026年版】拡張機能・デバッグ・Dev Container

ruby on rails の開発でエディタに迷ったら、まず選ぶべきは vscode です。無料で軽く、Ruby用の言語サーバーやデバッガが公式に整備され、Dev Container を使えばチーム全員の環境を1ファイルで揃えられます。本記事は、Windows（WSL2）/ macOS を前提に、2026年6月時点で現役の拡張機能・設定キー・デバッグ構成だけに絞って、ruby on rails の vscode 環境を最短で組み上げる手順をまとめます。古い記事に多い Solargraph 前提や旧式の launch.json は、現行の推奨に置き換えて解説します。

## まとめ：2026年の推奨は「公式Ruby LSP＋rdbg＋Dev Container」

結論を先に示します。ruby on rails を vscode で開発するなら、言語機能は Shopify製の公式拡張 `Ruby LSP`、デバッグは `ruby/debug`（rdbgコマンド）と拡張 `vscode-rdbg`、環境の統一は Rails 7.2 以降に同梱された `Dev Container` を使う、という3点が現行の標準構成です。かつて定番だった旧 `Ruby` 拡張や `Solargraph` 単体構成は、今は第一選択ではありません。Windows では RubyInstaller を直接使うより WSL2 上で組むほうがトラブルが少なく、本記事もこの前提で進めます。以降で、拡張の入れ方・`settings.json`／`launch.json` の具体値・つまずきやすい箇所を順に見ていきます。

## vscodeでrails開発に必要な拡張機能（2026年の現行構成）

最初に拡張機能を確定させます。ここを古い情報のまま進めると、補完が二重に効いて重くなったり、デバッグが起動しなかったりします。2026年6月時点で入れるべきものは多くありません。

### 言語機能の中核：公式「Ruby LSP」（Shopify製）

コード補完・定義ジャンプ・フォーマット・診断を担う中核が、Shopifyが開発する公式言語サーバー `Ruby LSP` です。VS Code Marketplace では拡張ID `Shopify.ruby-lsp` として配布されています。かつてサーバーとVS Code拡張は別リポジトリでしたが、重複報告やドキュメント分散を解消するため、現在は `Shopify/ruby-lsp` のmonorepoに統合されています。型注釈を必須とせず、注釈なしでもできるだけ正確に機能を提供する設計が特徴です。インストール後は、プロジェクトの Gemfile に `ruby-lsp` を加えるか、拡張がグローバルに用意する方式かを選べます（最新の導入方法は公式で確認してください）。

### Solargraphと公式Ruby LSPの使い分け

「Solargraphはもう不要なのか」という疑問に立場をはっきりさせます。新規に組むなら `Ruby LSP` を第一選択にしてください。Solargraph（`castwide/solargraph`）は今も現役で更新されていますが、補完精度を高めるには YARD ドキュメントや型情報の整備が前提になりやすく、初期セットアップの手間が増えます。一方の Ruby LSP は型注釈なしでの精度を狙う設計で、Rails標準の構成にそのまま乗りやすいのが利点です。既存プロジェクトが Solargraph 前提で安定稼働しているなら無理に剥がす必要はありませんが、両方を同時に有効化すると補完が競合するため、どちらか一方に寄せるのが鉄則です。

### あわせて入れる拡張とエディタ設定

言語機能以外で実用的なのは、Railsのルーティングやビューを横断しやすくする補助拡張と、ファイルツリーやGit操作系です。ただし機能が重複する拡張を盛りすぎると補完が干渉するため、最初は Ruby LSP とデバッガの2本に絞り、必要を感じてから足すのが安全です。`settings.json` には保存時整形を有効化する最小設定を入れておくと、チーム内のスタイル差を抑えられます。

| 用途             | 拡張／ツール                    | 拡張ID（Marketplace）        |
| -------------- | ------------------------- | ------------------------ |
| 言語機能（補完・定義・整形） | Ruby LSP                  | Shopify.ruby-lsp         |
| デバッグ           | VSCode rdbg Ruby Debugger | KoichiSasada.vscode-rdbg |
| 旧来の言語サーバー（任意）  | Ruby Solargraph           | castwide.solargraph      |

表のうち上2つが現行の標準です。3つ目は既存環境の互換のために挙げており、新規導入では基本的に不要です。バージョン番号は変動が速いため、各拡張ページで最新を確認してください。

## WindowsでのRails環境構築（WSL2を前提にしたインストール手順）

GSCで「ruby インストール windows11」「ruby on rails windows 開発 環境」の検索が多いことからも、Windowsユーザーの入口需要が大きい領域です。ここでの判断はひとつ。**WindowsではWSL2上にLinux環境を作り、その中でRubyとRailsを動かす**のが2026年の推奨です。RubyInstallerでネイティブに入れる方法もありますが、ネイティブ拡張gemのビルドやパス周りで詰まりやすく、本番のLinuxと挙動が乖離します。

### WSL2＋Linux側でのRuby導入とバージョン管理

WSL2でUbuntu等を有効化したら、Rubyのインストールはバージョン管理ツール経由が基本です。選択肢は `mise` と `rbenv` が代表的で、プロジェクトごとにRubyのバージョンを固定できます。Rails公式のDev Containerイメージも既定で `mise` を採用しており（`rbenv` にも切替可能）、新規ならmiseに寄せると公式構成と揃います。Rubyを入れたら `gem install rails` でRailsを導入し、`ruby -v` と `rails -v` でバージョンを確認します。出力されるバージョンが想定どおりかを必ず見てください。

```
ruby -v
rails -v
```

WindowsからWSL内のプロジェクトを開くときは、vscodeの「WSL」拡張でフォルダをLinux側のパスとして開きます。Windows側のドライブ（/mnt/c配下）に置くとファイルI/Oが遅くなりがちなので、Linuxホーム配下にプロジェクトを置くのが速度面で有利です。

### 初めてのRailsプロジェクト作成と起動確認

環境が整ったら、新規プロジェクトを作って起動まで確認します。データベースにPostgreSQLを使う場合は `-d postgresql` を付けます。

```
rails new myapp -d postgresql
cd myapp
rails db:create
rails server
```

ブラウザで `http://localhost:3000` を開き、Railsの初期ページが表示されれば成功です。`rails new` 直後のRailsバージョンは導入したRailsに依存するため、業務で版を固定したい場合はGemfileの `gem "rails"` を明示してから `bundle install` し直します。プロジェクトの自動生成に慣れていない場合は、[Railsジェネレータとは？基本的な使い方とその利点](/tech/details/2874/)でコード生成の基礎を押さえておくと、この後の開発が速くなります。

## vscodeでのRailsデバッグ設定（rdbgとlaunch.jsonの現行構成）

ここが古い記事との差が最も出る章です。以前の解説に多い `"type": "Ruby"` を使う launch.json は、旧拡張に依存した書き方で現行では動きません。2026年の標準は、Ruby公式のデバッガ `ruby/debug`（コマンド名 `rdbg`）と、VS Code拡張 `vscode-rdbg`（`KoichiSasada.vscode-rdbg`）の組み合わせです。

### debug gemの導入とrdbgの確認

まずプロジェクトに `debug` gem を入れ、`rdbg` コマンドがPATHに通っていることを確認します。Rails新規アプリでは development/test グループに `debug` が含まれていることが多いため、Gemfileを確認し、無ければ追加して `bundle install` します。拡張をインストールすると、何も設定しなくても `.rb` ファイルを開いた状態でF5キーから「現在のファイルをrdbgでデバッグ」を起動できます。

### launch.jsonでRailsサーバーをデバッグする設定

Railsサーバーにブレークポイントを張って止めたい場合は、`.vscode/launch.json` に `type` を `rdbg` とした構成を書きます。起動型（launch）と、別ターミナルで動かしたサーバーへ後から接続する接続型（attach）の2系統があります。下記は起動型でRailsサーバーを立ち上げる最小例です。

```
{
  "version": "0.2.0",
  "configurations": [
    {
      "type": "rdbg",
      "name": "Debug Rails server",
      "request": "launch",
      "command": "bin/rails",
      "script": "server",
      "args": [],
      "askParameters": false
    }
  ]
}
```

すでに `rdbg` を有効化して起動済みのサーバーへつなぐ接続型では、`"request": "attach"` と接続先（例 `localhost:12345`）を指定します。Dockerコンテナ内のRailsへ接続する場合もこのattach方式が基本で、コンテナ側でデバッグポートを開き、ホストのvscodeから接続します。`localfsMap` 等でコンテナとホストのパス対応を合わせる点が、つまずきやすい箇所です。

## Dev ContainerでチームのRails環境を統一する（Rails 7.2以降の同梱機能）

競合記事の多くがDockerの手書きDockerfile中心で止まっているのに対し、2026年に押さえるべき独自の論点がここです。**Rails 7.2以降は Dev Container をopt-inで同梱**しており、`rails new` 時のオプションだけで、vscodeがそのまま開ける開発コンテナ一式を生成できます。「各自のローカルにRubyを入れる」発想から、「コンテナ定義をリポジトリで共有する」発想への移行が、チーム開発での失敗を減らす近道です。

### rails newでDev Containerを生成する

新規作成時に `--devcontainer` を付けると、`.devcontainer` ディレクトリに `devcontainer.json` などの設定ファイルが追加されます。既存プロジェクトには `bin/rails devcontainer` で後付けできます。生成されるRubyイメージにはRuby本体とバージョン管理ツール（既定 `mise`、`rbenv` に変更可）、Gitなどが含まれます。

```
rails new myapp --devcontainer
# 既存プロジェクトに後付けする場合
bin/rails devcontainer
```

vscodeでこのフォルダを開くと「コンテナで再度開く」が提案され、承認するとコンテナ内で開発が始まります。ホストにRubyやDBを直接入れずに済むため、OSやバージョンの差による「自分の環境だけ動かない」を構造的に防げます。Dev Containerそのものの考え方は[Dev Containerの概要と基本的な機能および利点について](/tech/details/3728/)で補えます。

### 手書きDockerとDev Containerの使い分け

「Dev Containerがあるなら、もうDockerfileは書かなくていいのか」という疑問には条件付きで答えます。学習や小規模では `rails new --devcontainer` の生成物で十分です。一方、本番イメージの最適化（マルチステージビルドや不要パッケージの削減）まで踏み込むなら、Dev Containerとは別に本番用Dockerfileを用意・調整する必要があります。開発はDev Container、配布は専用Dockerfile、と役割を分けるのが実務上きれいです。Dockerfileの記述自体に不安があれば、[Dockerfileとは何か？その基本的な役割と重要性について](/tech/details/3315/)で命令の意味から確認できます。

## つまずきやすい箇所と採用すべきでない構成

ここでは玉虫色を避け、避けるべきパターンを具体的に挙げます。

- **旧 launch.json（`"type": "Ruby"`）をコピーして使う**：旧拡張前提のため現行では起動しません。`"type": "rdbg"` に置き換えます。
- **Ruby LSP と Solargraph の同時有効化**：補完が競合し、候補が重複したり遅くなります。どちらか一方に寄せます。
- **WindowsネイティブにRubyInstallerだけで構築**：ネイティブ拡張gemのビルドや本番との差で詰まりやすく、学習用途を除き推奨しません。WSL2を使います。
- **WSLでWindows側ドライブ（/mnt/c）にプロジェクトを置く**：ファイルI/Oが遅くなります。Linuxホーム配下に置きます。

とくに最初の2つは、古い記事の手順をそのまま写したときに起きがちです。コードジャンプが効かない・デバッグが始まらないときは、まず拡張の重複とlaunch.jsonのtypeを疑ってください。Active Recordなどフレームワークの中核機能でブレークポイントが効くようになると、学習効率が大きく上がります。基礎は[Active Recordとは？その基礎と重要性を解説](/tech/details/2913/)を参照してください。

## よくある質問（FAQ）

### ruby on rails の vscode 拡張機能は結局どれを入れればいいですか？

2026年6月時点では、言語機能はShopify製の公式拡張「Ruby LSP」（ID: Shopify.ruby-lsp）、デバッグは「VSCode rdbg Ruby Debugger」（ID: KoichiSasada.vscode-rdbg）の2本が基本です。まずこの2つだけ入れ、補完が競合するため旧Ruby拡張やSolargraphとの併用は避けてください。必要を感じてから補助拡張を足すのが安全です。

### Solargraphはもう使わないほうがいいですか？

新規構築ではRuby LSPを優先してください。Solargraphは現役で更新が続いていますが、補完精度を高めるにはドキュメントや型情報の整備が前提になりやすく、初期設定の手間が増えます。既存プロジェクトで安定稼働しているなら無理に剥がす必要はありませんが、Ruby LSPと同時に有効化すると競合するため、一方に寄せるのが原則です。

### WindowsでRailsを開発するならWSL2は必須ですか？

必須ではありませんが、強く推奨します。RubyInstallerでネイティブに入れる方法もある一方、ネイティブ拡張gemのビルドやパス周りで詰まりやすく、本番のLinuxと挙動が乖離します。WSL2上のLinux環境で組めば、本番に近い構成で安定して開発でき、vscodeのWSL連携でそのまま編集・デバッグできます。

### vscodeでRailsサーバーにブレークポイントが効きません。

多くは launch.json の `type` が古い「Ruby」のままか、debug gem（rdbg）が入っていないことが原因です。`type` を `rdbg` に直し、Gemfileに `debug` を加えて `bundle install` し、`rdbg` がPATHにあるか確認してください。Dockerやコンテナ内のサーバーへ接続する場合は、attach方式とパス対応（localfsMap）の設定も見直します。あわせて、[Sonic Pi](https://www.issoh.co.jp/tech/details/3361/)についても解説しています。

## 関連記事

- [Railsジェネレータとは？基本的な使い方とその利点](/tech/details/2874/)
- [Active Recordとは？その基礎と重要性を解説](/tech/details/2913/)
- [Dev Containerの概要と基本的な機能および利点について](/tech/details/3728/)
- [Dockerfileとは何か？その基本的な役割と重要性について](/tech/details/3315/)
- [Rails APIとReactの連携方法：フロントエンドとバックエンドの統合](/tech/details/2905/)

---

出典: [ruby on rails を vscode で開発する環境構築【2026年版】拡張機能・デバッグ・Dev Container](<https://www.issoh.co.jp/tech/details/2878/>)（株式会社一創）