OpenRewriteのLSTとレシピで段階的にコードを変える
このプロジェクトは「Automated mass refactoring of source code. It consists of an auto-refactoring engine that runs prepackaged, open source refactoring recipes for common framework migrations, security fixes, and stylistic consistency tasks-reducing your coding effort from hours or days to minutes.」を基盤として、実践的に使えるオープンソース実装を提供し、再利用可能なツールチェーンと統合手段を備えています。
ひと目でわかる
- これは何？
- Javaを中心に複数言語の構文解析と再利用可能なレシピを組み合わせるオープンソースのリファクタリング基盤を、適用範囲と境界から検討する。
- 誰に向いている？
- OpenRewriteは、単一リポジトリのJava移行や依存関係修正を、差分としてレビューできるチームに向きます。まず対象ビルドを再現し、MavenまたはGradleで一つのレシピを実行してコンパイルとテストの差分を確かめてください。
- 商用利用できる？
- できます。Apache-2.0 は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 1 日前です。
- 何の言語で書かれている？
- 主に Java です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
レシピ結果をレビュー可能にする
変更前のコミット、実行したレシピ名、変更後の差分を残し、MavenまたはGradleのビルドとテストを同じ環境で再実行します。LSTを使う変換でも、反射や独自コードの意味までは自動判定できない場合があります。レビュー担当者が差分の意図を説明できる単位で適用します。
差分を戻せる移行単位
レシピ実行は専用ブランチで行い、変更ファイル数、コンパイル結果、テスト結果を一組で保存します。失敗した変換を手動修正で隠さず、入力例をレシピのテストへ戻せる運用なら、更新版でも同じ判断を繰り返せます。大きな移行ではモジュール単位の適用結果も比較します。
一つのリポジトリに一つの変換を当てる入口
OpenRewriteはソースコードの自動リファクタリングエンジンです。READMEは、フレームワーク移行、セキュリティ修正、スタイル統一向けのオープンソースレシピを実行し、手作業の変更量を減らす仕組みとして説明しています。ここでの価値は、変換をレシピとして名前付きで再実行できる点にあります。
Java向けにはOpenRewrite Gradle PluginとOpenRewrite Maven Pluginが案内され、単一リポジトリに一度に一つのレシピを実行できます。導入を判断する際は、大規模な一括変更を想像するより、対象モジュール、レシピ、生成差分を小さく固定する方がREADMEの使い方に沿います。
Lossless Semantic Treeが型情報を保持する
レシピはソースを読み、Lossless Semantic Tree、つまりLSTとしてメモリ上に構築された型認識モデルを使います。READMEは、LSTがコードの意味を扱うモデルであり、レシピ実行のたびに作られると説明しています。単純な文字列置換ではなく、型や構造を使った変換の土台です。
この説明は変更が必ず正しいことを保証しません。検証ではレシピ適用前後の差分、コンパイル、テスト、フォーマッタの結果を分けて確認します。独自レシピを作る場合も、サンプル入力で意図したノードだけが変わることを確認してから対象範囲を広げるのが妥当です。
Java以外はパーサーと実行条件を分けて見る
READMEにはJava、Kotlin、Groovy、JavaScript/TypeScript、Python、C#向けのパーサーとベースレシピが挙げられています。ただし、追加言語のパーサーがオープンソースであることと、レシピを実行できることは同じではありません。追加言語への実行にはModerneのライセンスが必要だと明記されています。
この境界は採用時の費用と運用設計に直結します。Javaだけを自前のGradleまたはMavenで処理するのか、複数言語・複数リポジトリをサービスで扱うのかを分けます。READMEのsupported languagesとlicensingのページを、使うレシピ単位で照合してください。
カスタムレシピは移行知識をコード化する
OpenRewriteのレシピはカスタマイズでき、既存レシピを調整したり新しいレシピを書いたりできます。これは同じ変換を複数ブランチや複数回の移行で再現したい場合に意味があります。作業者の判断を消す機能ではなく、判断した変換規則を実行可能な形に固定する機能です。
実務では、変更対象を表す検索条件、変更後の期待形、例外となるコードをテストケースに置きます。レシピの結果をそのまま本番ブランチへ入れず、生成差分をレビューし、ビルドが落ちた箇所を対象から外すかレシピを直します。READMEは個別プロジェクトのテスト手順までは規定していません。
Moderneのバッチ処理は別の運用面を持つ
OpenRewriteの基盤は一度に一つのリポジトリを移行する設計です。READMEでは、Moderneが同じレシピを数百から数千のリポジトリへ実行する商用プラットフォームとして紹介されています。影響分析、セキュリティ修正、コーディングエージェント向けの検索と変更も、サービス側の説明です。
ModerneはLSTを一度構築してシリアライズし、リポジトリやチーム間で再利用すると記載されています。Prethink、Trigrep、ローカルMCPサーバーへの言及もありますが、これらをコアOSSのローカル実行機能と混同しないことが必要です。データの保管場所や組織横断の権限は、READMEだけでは決まりません。
Apache-2.0のコアとレシピのライセンス
READMEはコアフレームワークがApache2ライセンスで、常にオープンソースだと説明しています。一方、カタログにある多くのレシピがOSSであることと、すべてのレシピの条件が同じであることは別問題です。ライセンスページをレシピごとに確認する必要があります。
更新時はmainブランチとリリース版を固定し、対象ビルドで同じレシピを再実行します。現在の素材ではv8.91.2が最新リリースとして記録されています。ドキュメントのquickstart、Maven Plugin、Gradle Pluginを参照し、変更差分とテスト結果を保存できるチームなら採用候補になります。
編集部の結論
OpenRewriteは、単一リポジトリのJava移行や依存関係修正を、差分としてレビューできるチームに向きます。まず対象ビルドを再現し、MavenまたはGradleで一つのレシピを実行してコンパイルとテストの差分を確かめてください。多数リポジトリへの一括処理や追加言語の実行はModerneのライセンス条件が関わるため、OSSの基盤機能とサービス機能を分けて判断します。
コミュニティノート