Java仮想スレッド入門｜仕組みと使い方

Java 21で正式導入された仮想スレッド（Virtual Threads）は、スレッドプールの管理から開発者を解放する軽量スレッド機構です。

この記事では、仮想スレッドの仕組み・従来スレッドとの違い・具体的な使い方・Pinningなどの注意点をコード例付きで解説します。

私は長年Javaのサーバーサイド開発に携わってきましたが、スレッドプールの最適化に数日を費やしたり、原因不明のメモリ不足に頭を抱えたりした経験は一度や二度ではありません。

仮想スレッドを使えば、シンプルな同期コードのまま数百万の同時接続をさばけるようになります。

「リクエストが増えるとサーバーが重くなるのは仕方ない」と諦めていませんか。この記事を最後まで読めば、その原因と解決策が明確になります。

仮想スレッドとは？Java 21の軽量スレッドの全体像

仮想スレッドは、Javaの実行環境（JVM）が管理する軽量なスレッドです。

従来のJavaにおいて、スレッドはオペレーティングシステム（OS）のスレッドと1対1で結びついていました。

しかし、仮想スレッドはこの制約を取り払い、1つのOSスレッド上で数万、あるいは数百万ものスレッドを走らせることを可能にします。

仮想スレッドの登場は、Javaの並行処理における最大の転換点です。

これまで並列度を高めようとすると、メモリ消費量やコンテキストスイッチのコストが壁になっていました。

仮想スレッドは、スレッド自体をJVM上の「オブジェクト」として扱うことで、これらのコストを劇的に抑えています。

つまり、開発者はスレッドが貴重な資源であることを忘れて、必要な分だけ自由にスレッドを作成できるようになったのです。

スレッドを自由に生成できるこの仕組みが、モダンなJava開発の新しい標準です。

そもそも仮想スレッドは何を解決する仕組みなのか

仮想スレッドは、スケーラビリティと開発効率のトレードオフを解決します。

これまでは、高いスケーラビリティを得るために、リアクティブプログラミングのような難解な非同期コードを書く必要がありました。

仮想スレッドを使えば、なじみのある「1リクエスト1スレッド」のシンプルな同期コードのまま、大量の同時接続をさばけるようになります。

複雑なコールバック地獄から解放されることが、最大のメリットです。

従来のスレッドモデル（プラットフォームスレッド）の限界

従来のスレッドは、1つあたり大きなスタック領域を予約します（既定値は Linux x64 で1MB、手元の macOS arm64・Java 21 では2MB）。

そのため、1つのプロセスで作れるスレッド数には、メモリやOSの設定による上限があります（手元の macOS・Java 21 では、OSのスレッド数の上限により約4,000本で作成に失敗しました）。

また、OSレベルのコンテキストスイッチが発生するため、頻繁にスレッドを切り替えるとオーバーヘッドが無視できなくなります。

この「OSスレッドの重さ」が、Javaアプリケーションの同時並行数を制限する大きなボトルネックでした。

なぜJava 21で仮想スレッドが本格導入されたのか

現代のサーバーアプリケーションには、かつてないほどの同時接続性能が求められています。

マイクロサービス化が進み、1つのリクエストを処理するために複数のAPIやデータベースへアクセスする機会が増えました。

このような待ち時間が多い処理において、従来のスレッドモデルではスレッドがアイドル状態で放置され、貴重な計算資源が無駄になっていたのです。

Javaが今後もエンタープライズ領域で生き残るためには、この非効率を解消する必要がありました。

仮想スレッドの導入背景には、Go言語のGoroutineやErlangの軽量プロセスといった成功例の影響もあります。

他の言語が軽量スレッドによって高いスケーラビリティを実現する中、Javaも同様の、あるいはそれ以上の仕組みを取り込む必要がありました。

長年温められてきた「Project Loom」がJava 21でようやく形になったのは、堅牢さを維持しつつ現代のクラウドネイティブな環境に適応させるためだったのです。

その後もJava 24でsynchronizedによるピン留め問題の根本修正（JEP 491）、Java 25でScoped Valuesの正式化とStructured Concurrencyの再設計が行われ、仮想スレッドのエコシステムは着実に成熟しています。

高並行処理が当たり前になった現代のサーバー事情

現在のWebサービスでは、数万人のユーザーが同時にアクセスすることは珍しくありません。

特にIoTやリアルタイム通知などの分野では、長時間コネクションを維持する処理が増えています。

OSスレッドを消費し続ける従来の手法では、こうした高並行な要求に応えることが物理的に不可能になっていました。

仮想スレッドは、このような現代的な負荷パターンに対応するための必然的な進化です。

Project Loomが目指していた設計思想

Project Loomの根底には「コードの書きやすさを犠牲にせず、パフォーマンスを最大化する」という思想があります。

既存のライブラリやデバッグ手法をそのまま使いつつ、スレッドのコストだけを下げることが目標でした。

つまり、新しいプログラミングモデルを学ぶ必要はなく、これまでの知識を活かしたまま、より高性能なシステムを構築できるように設計されているのです。

仮想スレッドの仕組みをイメージで理解する

仮想スレッドの仕組みを理解するコツは「仕事をする人」と「机」の関係で考えることです。

OSスレッドが「作業机」だとすると、仮想スレッドはそこに座って仕事をする「タスク」のようなもの。

従来のJavaでは1つの机に1人しか座れず、その人が休憩（I/O待ち）している間も机は占有されていました。

仮想スレッドでは、誰かが休憩に入ると、即座に別の人がその机を使って作業を再開します。

この仕組みにより、少数の「作業机（OSスレッド）」を使い回して、膨大な数の「タスク（仮想スレッド）」を効率よく片付けることが可能です。

この「机の貸し借り」をJVMが自動で行ってくれるため、開発者は裏側の複雑な制御を意識する必要がありません。

メモリ上にはタスクのデータだけが保持され、実際にCPUを動かすときだけOSスレッドへ割り当てられるのです。

OSスレッドと仮想スレッドの関係

仮想スレッドは、プラットフォームスレッド（OSスレッド）の上で実行されます。

1つのプラットフォームスレッドが、複数の仮想スレッドを次々と切り替えて処理する「多対多」のマッピング構造です。

仮想スレッドがI/O操作などでブロックされると、JVMはそれをプラットフォームスレッドから切り離します。

空いたプラットフォームスレッドは、すぐに別の仮想スレッドの実行へ回される仕組みです。

キャリアスレッドへのマウント・アンマウントの流れ

仮想スレッドを実際に実行しているプラットフォームスレッドのことを「キャリアスレッド」と呼びます。

JVM内のスケジューラが、どの仮想スレッドをどのキャリアスレッドに乗せるかを管理しています。

仮想スレッドをキャリアスレッドに載せることを「マウント」、I/O待ちなどで降ろすことを「アンマウント」と呼びます。標準のスケジューラはForkJoinPoolで、キャリアスレッドの数はデフォルトでCPUコア数と同じです。

このスケジューリングは先取り式ではなく、協力的なマルチタスクに近い挙動をします。

ブロッキング操作が発生した瞬間に制御権が移るため、効率的なリソース活用が実現できるのです。

1つのキャリアスレッド上で、2つの仮想スレッドがマウント・アンマウントを繰り返す流れを図にすると、次のようになります。

ポイントは、仮想スレッドAがI/Oを待っている間もキャリアスレッドは遊ばず、仮想スレッドBの処理に使われている点です。再開時のAは、別のキャリアスレッドにマウントされることもあります。

仮想スレッドを使うと何が変わるのか（メリット）

最大のメリットは、スレッドプールの管理という苦行から解放されることです。

これまでは「スレッドを何個用意すれば最適か」という難しい計算に追われていました。

仮想スレッドなら、タスクごとにスレッドを使い捨てにしても問題ありません。

ExecutorServiceでスレッド数を固定する必要がなくなり、コードは劇的にシンプルになります。この解放感は、一度味わうと元には戻れません。

また、デバッグやプロファイリングが容易になる点も見逃せません。

非同期ライブラリを使うと、スタックトレースが途切れてしまい原因究明が困難になることがよくありました。

仮想スレッドは「同期的な書き方」を維持するため、エラー時のスタックトレースが上から下まで綺麗に繋がります。

開発者の生産性を維持したまま、システムの限界性能を引き上げられるのは強力な利点です。

スレッド数を気にせず書けるコードになる

仮想スレッドを使えば、1,000,000個のスレッドを同時に立ち上げることも現実的です。

これまでは「スレッドは高価なもの」という常識があり、再利用するためのプール管理が必須でした。

しかし、これからは必要な時に必要なだけ生成し、終わったら捨てるという使い方が基本になります。

リソース制約を気にせず、ロジックの記述に集中できる環境が整いました。

非同期処理をシンプルな同期コードで表現できる

CompletableFutureやリアクティブ系のライブラリを駆使していた処理が、シンプルな逐次実行コードで書けるようになります。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    var future1 = executor.submit(() -> fetchData(1));
    var future2 = executor.submit(() -> fetchData(2));
    // get()でブロックしてもOSスレッドは無駄にならない
    var result = future1.get() + future2.get();
}

見た目はブロッキングでも、裏側では非ブロッキングに動作します。

サーバーアプリケーションのスケーラビリティ向上

スループットの向上が期待できる点も重要です。

特に、データベースへのクエリ発行や外部APIの呼び出しなど、待ち時間が多いアプリケーションで真価を発揮します。

スレッドがブロックされている間のリソース消費が極小化されるため、同じスペックのサーバーでもより多くのリクエストを同時に処理できるようになります。

これはインフラコストの削減にも直結する大きなメリットです。

仮想スレッドにも注意点はある

魔法のような仮想スレッドですが、何でも解決する銀の弾丸ではありません。最も注意すべきなのは、CPUに負荷をかけ続ける「CPUバウンド」な処理です。

仮想スレッドは、あくまで「待ち時間」を有効活用するための仕組み。

計算処理そのものを速くするわけではないため、複雑な計算を大量の仮想スレッドで回しても速くはなりません。むしろ計算中の仮想スレッドがキャリアスレッドを占有し続け、I/O待ちの仮想スレッドの出番を遅らせる原因になります。

また、既存のコードとの相性にも気を配る必要があります。代表例が次の「ピン留め」です。

synchronizedのピン留め（Pinning）とJava 24での解消

Java 21〜23では、synchronizedブロック内でブロッキングI/Oを行うと、仮想スレッドがキャリアスレッドからアンマウントできず固定（ピン留め）され、そのキャリアスレッドを他の仮想スレッドが使えなくなります。これを「Pinning」と呼びます。

Java 21〜23で仮想スレッドの恩恵をフルに受けるには、synchronizedをReentrantLockへ書き換えるのが定番の対策でした。

この問題はJava 24のJEP 491で解消され、synchronizedの中でブロックしても仮想スレッドはアンマウントできるようになりました。Java 24以降（LTSならJava 25）を使うなら、ピン留め対策のためのReentrantLockへの書き換えは基本的に不要です。

ただしJEP 491の後も、ネイティブメソッドやForeign Function & Memory API経由の呼び出し中にブロックした場合や、クラスの初期化・ロード中にブロックした場合はピン留めが残ります。どちらも頻度は低いものの、JNIを使う古いライブラリでは意識しておきましょう。

ピン留めが起きているかどうかは、JDK Flight Recorder（JFR）のjdk.VirtualThreadPinnedイベントで確認できます。Java 21〜23で使えたシステムプロパティ-Djdk.tracePinnedThreadsは、Java 24で削除されています。

すべての処理が高速になるわけではない理由

仮想スレッドは「並行性」を高めるものであり、単一タスクの「実行速度」を上げるものではありません。

むしろ、スレッドの管理オーバーヘッドがわずかに追加されるため、単一の処理時間はプラットフォームスレッドより微増する場合もあります。

多くのタスクを「同時に」効率よく回すことが目的であることを忘れてはいけません。用途を間違えると、期待した効果は得られないでしょう。

ブロッキングI/Oと仮想スレッドの相性

仮想スレッドはブロッキングI/Oと相性が良いです。

標準ライブラリの多くが、仮想スレッドで実行された場合に「スレッドをブロックせずに譲り合う」ように修正されています。

しかし、JNIを介したネイティブコード内でのブロックや、一部の古いドライバではこの挙動が機能しない場合があります。

自分が使っているライブラリが仮想スレッドに適応しているか、確認する習慣が必要です。

ThreadLocal・コネクションプール利用時の注意点

ThreadLocalの多用には注意が必要です。

仮想スレッドは大量に生成されるため、各スレッドで巨大なオブジェクトをThreadLocalに保持すると、あっという間にメモリを食いつぶします。

リクエスト単位の情報（ユーザーIDなど）をメソッド間で受け渡すためにThreadLocalを使っているなら、Java 25で正式機能になったスコープ値（ScopedValue、JEP 506）が代替候補です。値は不変で、指定したスコープを抜けると束縛が自動で解除されます。

また、Java 21〜23では前述したsynchronizedによるピン留め問題もあります。

特にJDBCドライバなどの古いライブラリを使用する場合は、予期せぬボトルネックが発生しないか慎重に検証しなければなりません。

実務でよくハマるのが、コネクションプールライブラリ（HikariCPなど）との組み合わせです。

仮想スレッドが爆発的に増えてもコネクション数は有限なので、プールの取得待ちが長時間化するケースがあります。

こうした場面でもセマフォによる流量制御が有効です。

仮想スレッドはどんな場面で使うべきか

仮想スレッドが最も輝くのは、Web APIサーバーやマイクロサービスのような、ネットワークI/Oが中心となるアプリケーションです。

1つのリクエストに対して複数の外部サービスを呼び出し、レスポンスを待つ処理に最適です。

これまでなら非同期APIを組み合わせて複雑なチェーンを書いていた箇所を、素直なforループや逐次処理で記述できるようになります。

一方で、大量の数値計算や画像処理といった、CPUをフル回転させるタスクには向いていません。

こうした処理には、従来どおりスレッド数を制限したプラットフォームスレッドのプールを使うべきです。

なお、仮想スレッドは生成コストが非常に小さいため、プールして使い回すのではなく「タスクごとに新しく作って捨てる」のが前提の設計です（JEP 444）。

自分のアプリケーションが「待っている時間」が長いのか「計算している時間」が長いのかを見極めることが肝心です。

Webアプリ・APIサーバーでの典型的なユースケース

Spring Bootなどのフレームワークと組み合わせることで、リクエスト処理全体を仮想スレッド化できます。

これにより、スレッドプールの枯渇を恐れることなく、同期的なプログラミングモデルで高スループットなサービスを構築可能です。

特に、呼び出し先のマイクロサービスが低速な場合や、同時接続数が不規則に変動する環境で、仮想スレッドの安定性が際立ちます。

逆に従来スレッドや非同期が向いているケース

ビデオのエンコードや暗号化処理などのCPUヘビーなタスクは、プラットフォームスレッドのほうが適しています。

こうした処理では、スレッドを切り替えるメリットがなく、コア数に合わせたスレッドプールで並列度をはっきり決めて計算させるほうが扱いやすくなります（処理速度は仮想スレッドと大差ありません）。

また、すでにリアクティブスタック（Project Reactorなど）で完璧に構築され、安定稼働しているシステムを無理に仮想スレッドへ移行する必要もありません。

Java 21で仮想スレッドを使い始めるための最低限の知識

仮想スレッドを使い始めるのは驚くほど簡単です。基本的には、Executorsクラスに追加された新しいメソッドを呼び出すだけ。

既存のExecutorServiceインターフェースを実装しているため、タスクの投入方法はこれまでと変わりません。

Executors.newVirtualThreadPerTaskExecutor()を使えば、タスクごとに新しい仮想スレッドを割り当てるエグゼキューターが手に入ります。

ただし、既存コードの移行には少しだけ戦略が必要です。

すべてのプラットフォームスレッドを一度に仮想スレッドへ置き換えるのではなく、まずはI/O待ちが顕著なボトルネックから着手することをお勧めします。

また、スレッドプールの「最大数」で流量制御をしていた箇所は要注意です。

仮想スレッドには実質的な上限がないため、セマフォ（Semaphore）などを使って明示的に同時実行数を制御する設計が必要になります。

Thread.ofVirtual()で仮想スレッドを直接作成する

もっともシンプルな仮想スレッドの作成方法は、Thread.ofVirtual()を使うことです。

プラットフォームスレッドのThread.ofPlatform()と対になるAPIで、ビルダーパターンでスレッドを構築できます。

// 仮想スレッドを直接作成して起動
Thread vThread = Thread.ofVirtual()
    .name("my-virtual-thread")
    .start(() -> {
        System.out.println("Running on: " + Thread.currentThread());
    });
vThread.join();

Java 21で実行すると、次のように出力されます（スレッド番号やワーカー名は環境によって変わります）。

Running on: VirtualThread[#25,my-virtual-thread]/runnable@ForkJoinPool-1-worker-1

Thread.ofVirtual()で作成したスレッドはisVirtual()がtrueを返します。

最後のjoin()は省略できません。仮想スレッドは常にデーモンスレッドとして扱われる（isDaemon()が常にtrue）ため、join()で待たずにmainメソッドが終わると、処理の途中でもJVMごと終了してしまいます。

デーモンスレッドの仕組みやJVMが終了する条件は、デーモンスレッドとは？プロセスとの違いを図解で詳しく解説しています。

名前を付けておくとデバッグ時にスレッドダンプで識別しやすくなるため、実務では.name()の指定を推奨します。

newVirtualThreadPerTaskExecutor()の基本的な使い方

実務ではThread.ofVirtual()よりもExecutorService経由で仮想スレッドを扱うのが一般的です。

try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
    executor.submit(() -> {
        // ここに処理を書く
        System.out.println("Hello from Virtual Thread!");
    });
}

try-with-resources構文を使うことで、すべてのタスクが完了するのを安全に待機できます。

Spring Bootで仮想スレッドを有効にする方法

Spring Boot 3.2以降では、application.propertiesに1行追加するだけで、すべてのリクエスト処理を仮想スレッド上で実行できます。

# application.properties
spring.threads.virtual.enabled=true

この設定を有効にすると、Tomcatのリクエスト処理スレッドが従来のプラットフォームスレッドから仮想スレッドに切り替わります。

コードの変更は不要で、既存のControllerやServiceクラスがそのまま仮想スレッド上で動作します。

既存コードをどう移行・併用するかの考え方

移行の第一歩は、スレッドプールの定義を仮想スレッド用に差し替えることです。

しかし、前述の通り流量制限がなくなるため、接続先のデータベースや外部APIがパンクしないよう注意してください。

共有リソースへのアクセスを制限するには、スレッドプールに頼るのではなく、Semaphoreを活用するのがスマートなやり方です。

新旧のスレッドモデルは共存可能なので、適材適所で使い分ける姿勢が大切です。

セマフォで同時実行数を制御する

仮想スレッドには実質的なスレッド数の上限がないため、従来「スレッドプールの最大数」で行っていた流量制御が効かなくなります。

データベース接続数や外部API呼び出しのレート制限を守るには、Semaphoreを使って明示的に同時実行数を絞る必要があります。

import java.util.concurrent.Executors;
import java.util.concurrent.Semaphore;
import java.util.concurrent.atomic.AtomicInteger;

public class SemaphoreDemo {
    static final Semaphore semaphore = new Semaphore(10); // 同時に10件まで
    static final AtomicInteger running = new AtomicInteger();
    static final AtomicInteger maxRunning = new AtomicInteger();

    public static void main(String[] args) {
        try (var executor = Executors.newVirtualThreadPerTaskExecutor()) {
            for (int i = 0; i < 1000; i++) {
                executor.submit(() -> {
                    semaphore.acquire(); // 空きが出るまで待つ（仮想スレッドはここでアンマウントされる）
                    try {
                        callExternalApi(); // DB接続や外部APIの代わり
                    } finally {
                        semaphore.release();
                    }
                    return null; // Callableとして扱わせ、acquire()の検査例外を許容する
                });
            }
        } // ここで1000タスクすべての完了を待つ
        System.out.println("最大同時実行数: " + maxRunning.get());
    }

    static void callExternalApi() throws InterruptedException {
        int now = running.incrementAndGet();
        maxRunning.accumulateAndGet(now, Math::max);
        Thread.sleep(50); // I/O待ちを模擬
        running.decrementAndGet();
    }
}

acquire()は検査例外のInterruptedExceptionを投げるため、ラムダの最後でreturn null;としてCallable扱いにしています（Runnableのままだとコンパイルエラーになります）。Java 21で実行すると、1000件のタスクを投入しても同時実行数は10件に収まります。

最大同時実行数: 10

Oracle公式ドキュメントでも、仮想スレッド移行時の流量制御にはセマフォの利用を推奨しています。

スレッドプールの代替としてではなく、リソース保護の専用機構としてセマフォを使い分ける設計がポイントです。

まとめ：仮想スレッドの導入戦略と今後の展望

仮想スレッドはJavaの書き方を根本から変える可能性を秘めています。しかし、焦って本番環境のすべてを刷新する必要はありません。

まずは、社内のツールや小規模なバッチ処理から導入し、その挙動を観察することから始めましょう。

従来のデバッグツールやモニタリングツールが仮想スレッドをどう表示するのか、自分の目で確かめることが最大の学習になります。

私自身、最初は「本当に同期コードで大丈夫なのか」と疑っていましたが、実際に使ってみるとそのシンプルさと性能のバランスに驚かされました。

仮想スレッドは単なる新機能ではなく、Javaが培ってきた「シンプルで堅牢」という美徳を取り戻すための原点回帰だと感じています。

この技術をマスターすることは、今後10年のJava開発を生き抜くための必須スキルになるでしょう。

今すぐ本番投入すべきか、学習用途から始めるべきか

Java 21はLTS（長期サポート）版であり、2025年9月にリリースされたJava 25も次のLTSです。いずれも本番投入の土壌が整っています。

ただし、使用しているフレームワークやライブラリの対応状況を十分に確認してください。

例えば、Spring Boot 3.2以降（2026年10月時点の最新はSpring Boot 4.1系）であれば、設定一つで仮想スレッドを有効にできます。

まずは検証環境で負荷試験を行い、これまでのチューニングパラメータがどう変化するかを確認した上で、段階的に導入を進めるのが賢明です。

私が初めて仮想スレッドを検証したのは、外部API呼び出しが多い社内ツールでした。

スレッドプールサイズを200に設定していた処理を仮想スレッドに置き換えたところ、同じリクエスト数でもスレッドプールの枯渇エラーが完全に消え、レスポンスタイムも安定しました。

一方で、ThreadLocalに巨大なキャッシュを保持していた箇所ではメモリ使用量が急増し、Scoped Valuesへの書き換えが必要だったのは想定外でした。

仮想スレッドがJavaの設計思想に与える今後の影響

仮想スレッドの登場により、Javaは「非同期プログラミングの複雑さ」という呪縛から解き放たれました。

Java 25ではスコープ値（Scoped Values、JEP 506）が正式機能となり、構造化並行性（Structured Concurrency）も大幅に再設計されました。

ただし構造化並行性は、2026年9月15日にリリースされたJava 27でも第7プレビュー（JEP 533）の段階で、正式機能にはなっていません。本番コードで使うなら、正式化を待つのが無難です。

Javaは、誰が書いても読みやすく、かつ最高のパフォーマンスを発揮できる言語へと進化し続けています。

Java 21の仮想スレッドを使いこなせるようになれば、あなたのコードはもっと自由でパワフルになります。

まずは、手元のプロジェクトでnewVirtualThreadPerTaskExecutorを試してみてください。

その一歩が、モダンなJavaエンジニアへの大きな転換点になるはずです。

設定方法や具体的な移行プランについては、公式ドキュメントやこの記事のコード例を参考にしてみてください。

Java仮想スレッドに関するよくある質問

仮想スレッドとは何ですか？

仮想スレッドとは、Java 21で正式導入された軽量スレッド機構です。OSスレッドを直接使う従来のスレッドと異なり、JVMが管理する軽量なスレッドで、大量に生成してもメモリ・コンテキストスイッチのコストが小さいのが特徴です。

仮想スレッドの「ピン留め（Pinning）」問題とは何ですか？

仮想スレッドが特定条件下（synchronizedブロック内でのブロッキング操作等）でキャリアスレッドに固定され、軽量スレッドの利点が失われる現象です。Java 24（JEP 491）でsynchronizedブロック内のピン留めは解消されており、Java 24以降ではピン留め対策のためのReentrantLockへの書き換えは基本的に不要です。ネイティブメソッド呼び出し中やクラスのロード・初期化中のブロックでは現在もピン留めが起こります。

既存のスレッドプールを仮想スレッドに置き換えるべきですか？

I/O待ちが多い処理（DBアクセス・外部API呼び出し等）では置き換えメリットが大きいです。一方、CPU集約的な処理では従来スレッドと大差ないため、無理に全面置き換えする必要はありません。フレームワーク・ライブラリの対応状況も確認したうえで段階的に導入するのが安全です。