Visual Studio Code（以下 VS Code）で Kotlin 開発はできるのか？
結論から言うと、可能だが前提条件と割り切りが必要です。
Kotlin は JetBrains 製言語であり、開発体験の完成度は IntelliJ IDEA が圧倒的に高いのが事実です。
一方で、VS Code でも Kotlin/JVM + Gradle という構成に寄せれば、小〜中規模の開発やCLIツール、学習用途では十分に実用レベルで運用できます。
本記事では、
- 現時点で「正しい」構成
- よくある誤解
- 将来性のあるが未成熟な要素
を明確に切り分けて解説します。
前提整理：VS CodeでKotlinを使う際の現実
まず重要な前提です。
- Kotlin公式は VS Code を第一級IDEとしては扱っていない
- Kotlinの言語サポートは Language Server（LSP）頼み
- Gradle主導で開発を回す前提にしないと破綻しやすい
つまり、VS Code で Kotlin を使う場合は「IDEに全部任せる」のではなく、「ビルドはGradle、編集はVS Code」という役割分担が現実解です。
必須要件①：JDKのインストール（最重要）
Kotlin/JVM 開発では JDKが必須です。
VS Code の拡張や Language Server も内部で Java を使用します。
推奨構成
- JDK 17 または 21（LTS）
- OpenJDK 系（Temurin など）
確認コマンド
java -version
環境変数（Windows）
JAVA_HOMEを設定%JAVA_HOME%\binを PATH に追加
ここがズレていると
「補完が効かない」「LSPが起動しない」
といった問題が高確率で発生します。
必須要件②：Gradleを前提にする（事実上必須）
VS CodeでKotlinを扱うなら、Gradleを使わない選択肢はほぼありません。
なぜGradleが必須なのか
- 依存関係管理
- 実行・テスト・デバッグ
- Kotlinコンパイラのバージョン管理
これらを IDEに依存せず一元管理できるからです。
推奨構成
- Gradle Wrapper（
gradlew）必須 build.gradle.kts（Kotlin DSL）
典型的なディレクトリ構成
src/
├─ main/kotlin
└─ test/kotlin
build.gradle.kts
VS CodeのKotlin拡張：現時点での正解
結論
現実的に使えるのは「コミュニティ製拡張」です。
実用ライン：fwcd Kotlin拡張
VS Code Marketplace にある Kotlin（fwcd） 拡張は、以下を提供します。
- Kotlin Language Server
- コード補完
- エラー診断
- デバッグ（Debug Adapter）
2026年時点で、実務に耐える唯一の選択肢
注意点
- JetBrains公式ではない
- 大規模プロジェクトでは動作が重くなることがある
とはいえ、「VS CodeでKotlinを書く」なら事実上これ一択という評価は現在も変わっていません。
公式 Kotlin LSP について（重要な注意）
JetBrainsは 公式 Kotlin Language Server（kotlin-lsp） を公開していますが、
- pre-alpha（実験段階）
- VS Code Marketplace で安定配布されていない
- GitHubから手動導入が必要
- 対応範囲・安定性がまだ限定的
正確な位置づけ
- 「今すぐ乗り換えるべき本命」
- 「将来の公式サポート候補」
現時点では
検証用・研究用
実務の主軸に据えるのは非推奨
が正確な評価です。
Kotlinコンパイラ（kotlinc）は必要か？
結論
- Gradle運用なら必須ではない
- ただし入れておくと便利
kotlincが役立つ場面
- 単一ファイルの即実行
- 学習用途
- LSPトラブル時の切り分け
Gradleを使う場合でも、kotlincをPATHに通しておくとデバッグが楽です。
実行とデバッグ：正しいやり方
実行（applicationプラグイン）
./gradlew run
デバッグ（公式に推奨される方法）
./gradlew run --debug-jvm
これは Gradle の JavaExec タスクに対してJVMがデバッガ接続待ち状態になる公式オプションです。
VS Code側
- Java Attach デバッグ設定で接続
- デフォルトポートは 5005 が一般的
補足（重要）
- Spring Boot の場合は
runではなくbootRun - attach 対象のタスクは プロジェクトによって異なる
Dev Containersは「補助輪」として有効
VS Codeの強みである Dev Containers は、
- JDK
- Gradle
- VS Code拡張
を 完全に固定できる点で非常に有効です。
ただし、
- Kotlin LSP自体が未成熟
- Dev Containersだから安定するわけではない
ため、環境再現性を高める手段 LSP問題の万能薬ではないという認識が正確です。
よくある誤解まとめ（重要）
| 誤解 | 正しい理解 |
|---|---|
| VS CodeでもIntelliJ並みに書ける | ❌ 役割分担が必要 |
| 公式LSPがあるから安心 | ❌ pre-alpha |
| kotlincは必須 | ❌ Gradleなら不要 |
| IDEで実行・デバッグする | ❌ Gradle主導 |
最終的な推奨構成
- JDK 17 or 21
- Gradle + Wrapper
- VS Code + fwcd Kotlin拡張
- 実行・デバッグは Gradleタスク中心
- 公式 Kotlin LSP は 検証用途のみ
まとめ
VS CodeでのKotlin開発は、
- 「IDE完結型」
- 「Gradle主導・エディタ補助」
という前提に立てば、十分に現実的です。
特に
- CLIツール
- 学習用途
- 小規模バックエンド
では、VS Codeの軽快さを活かした運用が可能です。
以上、VScodeによるKotlinの開発環境構築についてでした。
最後までお読みいただき、ありがとうございました。
