OpenRewrite 与 AI／LLM 的整合调查

执行摘要

本次调查从四个角度技术性梳理了 OpenRewrite 与 AI/LLM 的整合：1) AI 辅助的 Recipe 编写（Moderne CLI 的 AI Skills），2) LLM → Recipe 的混合工作流（以 Java/Spring 升级为例），3) 在 Recipe 执行中通过 sidecar 调用 LLM（Moderne 平台架构），4) Recipe → LLM 的辅助工具集合（rewrite-prethink）。主要结论：Moderne 提出以 Skill、LST（Lossless Semantic Trees）为核心、并通过 Python sidecar（使用 Gradio）在 CPU worker 上运行 Hugging Face 的 OSS 模型的实用架构[^1][^2]；OpenRewrite 负责确定性变换，LLM 用于补偿非确定性残差（如构建失败），Duolingo 的实践案例对此模式提供了实证支持[^3]；rewrite-prethink 提供生成可信上下文（CSV/Markdown/CALM JSON）并自动化代理配置的模块，适合作为 LLM 代理的上下文预处理层[^4]。

查询类型判定

• 类型：技术深度调研（Query Type 3），重点是体系结构、实现细节和代码级引用。

目录

1. AI 辅助的 Recipe 编写（Moderne CLI 的 AI Skills）
2. LLM → Recipe 的混合工作流（Java/Spring 升级示例）
3. 在 Recipe 执行中以 sidecar 调用 LLM 的设计（Moderne 平台）
4. Recipe → LLM 的辅助工具：rewrite-prethink 深度分析
5. 结论与建议
6. 置信度评估

1. AI 辅助的 Recipe 编写（Moderne CLI 的 AI Skills）

概述：Moderne 提供 “AI Skills”（例如 create-recipe、run-recipe、analyze-impact、以及文档中称作 create-organization 的 setup-target 对应功能），这些技能以面向代理的方式提供，通常在代理环境（如 Claude Code）中以斜杠命令调用，用来生成、运行和分析 OpenRewrite 的 recipe[^5][^6]。

主要功能：

• create-recipe：建议使用何种 recipe 类型（声明式 YAML、Refaster、或 Java 实现），并能输出 recipe 模板与 RewriteTest 测试骨架[^6]。
• run-recipe：对已存在或开发中 recipe 的运行、调试和诊断支援（支持“已有 recipe 模式”与“开发模式”）[^6]。
• analyze-impact：聚合 recipe 运行数据并产出可视化与管理报告（例如 Sankey、treemap、以及基于 Marp 的 Markdown 报告）[^6]。
• setup-target/create-organization：生成 repos.csv、按组织/技术分组并指导同步（如 mod git sync csv）[^6]。

架构与运行注记：

• Skills 以静态资源（如 SKILL.md）形式分发，CLI 将其安装到代理可读取的位置，代理在其运行环境中读取这些技能并按指令与 Moderne 后端（或本地 CLI）交互执行变换[^6]。
• 博客中示例提到 mod config moderne skills update 作为技能更新的命令示例，但公开文档未提供完整的参数/manifest 规范，需以实际 CLI 输出为准[^5][^6]。

限制：

• 关于 CLI 参数、manifest 架构等详细规范，公开文档并不完整；在实际部署前应以 mod --help 或官方 docs 为准验证具体字段与行为[^5]。

2. LLM → Recipe：混合工作流（以 Spring Boot / Java 升级为例）

概述：实践中常采用“先用 OpenRewrite 执行能确定的变换，再把剩余的、难以确定的差异交由 LLM 解析并生成修正”的混合方法。Duolingo 的 Golden Path 升级案例是公开的代表性实例，描述了将 LLM 与 OpenRewrite 组合成端到端升级自动化流程的思路与经验教训[^3]。

典型工作流：

1. 用 YAML 定义升级计划（按步骤列出要升级的组件及顺序）。
2. 对每一阶段执行 OpenRewrite recipe（recipeList），并运行构建/测试进行验证。3) 对构建失败或不能用确定性规则修复的问题，调用 LLM 进行原因分析与补救建议；LLM 产出差分或具体修复建议后再次验证。4) 验证通过则由系统自动创建 PR 并进入下一步骤，失败则人工干预或回滚[^3]。

优点与限制：

• 优点：把可确定的改动交给 OpenRewrite，可减少 LLM 引入的错误面；OpenRewrite 的 recipeList 易于映射 LLM 生成的高层计划。
• 限制：LLM 生成的修复需要额外的自动化验证（测试覆盖与静态分析），且完整、公开的端到端 OSS 实现较少，多数为企业内部或 SaaS 实作（例如 Moderne）[^3]。

引用示例：OpenRewrite 的 spring-boot-40.yml（含 recipeList）是把多个小变换串联的示例，说明 LLM 生成的计划能被映射为一系列 recipe 的事实[^7]。

3. Recipe 执行中通过 sidecar 调用 LLM 的架构（Moderne 平台）

架构要点（流程示意）：

• LST（Lossless Semantic Trees）在平台中被序列化并作为横向可扩展的工件存储；Recipe Worker 会读取并（短时间）解密 LST，然后在需要处抽取文本片段并把它们发送给本地运行的 Python sidecar（通过 Gradio 暴露的 HTTP 接口或类似 RPC）进行推理，返回结果后把修正合并回 LST，再生成 changeset 并通过 Connector/Changeset 服务提交为 PR/提交。

Mermaid 示意图（Markdown 中可渲染）：

flowchart TD
  U[用户/协调器] -->|请求| API[API 网关]
  API --> Worker[Recipe Worker]
  Worker -->|获取/解密| Connector["Connector / Artifact Repo"]
  Worker -->|文本片段| Sidecar["Python sidecar (Gradio) + HF 模型"]
  Sidecar -->|修正文本| Worker
  Worker --> Changeset["Changeset 服务"] --> SCM["Git/PR"]

关键细节：

• Sidecar：文章明确指出以 Python（使用 Gradio）作为 sidecar 运行模型，模型从 Hugging Face 下载并部署在 CPU 的 worker 节点上；典型做法是在基础镜像中包含主进程与 sidecar，使 sidecar 在第一次调用时载入模型以减少后续延迟[^2]。
• LST 与密钥：Worker 会通过 Connector/API Gateway 获取短期使用的对称密钥以解密 LST，处理完后销毁密钥，从而避免平台长期持有明文代码的设计（安全考量）[^2]。
• Sidecar API schema：博客说明“把文本发给 sidecar”，但并未公布确切的 JSON schema、HTTP 路径或错误代码，因此需要进一步获取示例实现或官方样式说明来完成生产级实现[^2]。

运维注意：

• 在 CPU 节点上运行模型需慎重选择模型大小（生成任务在 CPU 上常有高延迟），应结合批处理（batching）、轻量化模型或量化策略来满足吞吐/延迟目标[^2][^6]。

示例用例：fixMisencoded（修复误编码的法语注释）——流程包含注释提取、语言检测（如 xlm-roberta）、使用 SymSpell 生成纠错候选、再通过 sidecar 执行最终生成/修正并写回 LST[^2][^5]。

4. Recipe → LLM：rewrite-prethink 深度分析

概述：rewrite-prethink 是 OpenRewrite 的模块，负责把代码库中发现的结构化信息（DataTables）导出为 .moderne/context/*.csv 与说明 Markdown，并能生成符合 FINOS CALM 的架构 JSON，以及把这些上下文自动插入到代理配置文档（如 CLAUDE.md）中，从而为 LLM 编码代理生成可信上下文[^4]。

主要实现要点（文件级引用）：

• ExportContext.java：聚合 DataTable 并生成 CSV/Markdown。实现位于 openrewrite/rewrite-prethink: src/main/java/org/openrewrite/prethink/ExportContext.java（含 CSV 导出与 Markdown 生成逻辑）[^4]。
• GenerateCalmArchitecture.java：从 DataTable 生成 CALM 规范的 JSON（calm-architecture.json），包含节点/关系构建逻辑（CalmBuilder）[^4]。
• UpdateAgentConfig.java：读取 .moderne/context/*.md 并按模板生成或更新代理配置文档（例如 CLAUDE.md、.github/copilot-instructions.md）[^4]。

优点与局限：

• 优点：将上下文结构化并标准化（CSV、CALM JSON），能显著降低传递给 LLM 的噪声并提高提示质量与可验证性。
• 局限：rewrite-prethink 本身并不会直接调用 LLM；它依赖外部的“发现”Recipe 将行写入 DataTable，因此项目需提供相应的发现器/producer recipe 来填充上下文数据；同时模板可能需针对具体代理进一步调整[^4]。

5. 结论与建议

1. 推荐采用“OpenRewrite（确定性）优先 → LLM（非确定性剩余问题）”的混合方法以平衡自动化规模与安全性（Duolingo 案例为参考）[^3]。
2. Moderne 平台提供了 LST + sidecar 的可行架构用于在多仓库场景下对接 LLM，但公开文档缺少 API schema、Dockerfile / k8s manifest 与 connector/key 的序列图；部署前应索取这些实现细节或先做一轮原型验证（PoC）来量化延迟与成本[^2]。
3. rewrite-prethink 值得作为为 LLM 生成“可信上下文”的前置层使用，但需要为目标代码库补充 discovery recipes 来填充 DataTables，且需对生成的代理模板进行适配与审阅[^4]。

6. 置信度评估

• 高置信（直接有出处）：Moderne 博客关于 sidecar/Gradio/Hugging Face/CPU 策略的描述[^2]；rewrite-prethink 的源码实现（ExportContext、GenerateCalmArchitecture、UpdateAgentConfig）[^4]；OpenRewrite 的 recipeList 与运行方式（官方文档）[^7]。
• 中置信（基于文档推断）：CLI 的具体 flag/manifest 细节（博客给出示例命令但未暴露完整规范）、sidecar 的精确 API schema 或公开的 Dockerfile/k8s manifest（文档未包含）[^5][^2]。
• 低置信（推测）：某些 CLI 名称或参数在公开 Web 上未找到 exact match，已用常见模式提供过渡性示例，应以真实 CLI/帮助输出为准[^5]。

附注（主要参考）

[^1]: Moderne 博客：”AI-Powered Recipe Authoring with Agent Skills and OpenRewrite” — https://www.moderne.ai/blog/ai-powered-openrewrite-recipe-authoring-with-claude-skill
[^2]: Moderne 博客：”AI-assisted refactoring in the Moderne Platform” — https://www.moderne.ai/blog/ai-assisted-refactoring-in-the-moderne-platform
[^3]: Duolingo 博客：”Automating JVM Golden Path” — https://blog.duolingo.com/automating-jvm-golden-path/
[^4]: openrewrite/rewrite-prethink 仓库：ExportContext、GenerateCalmArchitecture、UpdateAgentConfig 实现（参见 src/main/java/org/openrewrite/prethink/*） — https://github.com/openrewrite/rewrite-prethink
[^5]: moderneinc/moderne-docs（agent tools / skills） — https://github.com/moderneinc/moderne-docs/blob/main/docs/user-documentation/agent-tools/skills.md
[^6]: Moderne 博客（关于 create-recipe/run-recipe/analyze-impact/create-organization 的描述） — https://www.moderne.ai/blog/ai-powered-openrewrite-recipe-authoring-with-claude-skill
[^7]: OpenRewrite 文档 — Spring Boot 升级 recipe 列表示例: https://docs.openrewrite.org/recipes/java/spring/boot4/upgradespringboot_4_0-community-edition

本文件由研究编排代理翻译并保存。如需进一步针对 sidecar API、connector/key 流程或实际部署示例（Dockerfile/k8s）做 PoC，我可以继续基于该方向发起后续调研或编写示例。

To Copilot CLI:

/research OpenRewriteとAI/LLMの統合について包括的に調査してください。以下の4つの側面をすべてカバーしてください：

1. AI支援によるRecipe作成

   • Moderne CLIに組み込まれた4つのAI Skills（/moderne:create-recipe、/moderne:run-recipe、/moderne:analyze-impact、/moderne:setup-target）
   • Claude Code用のModerneプラグイン導入方法（mod config moderne skills update）
   • 公式ドキュメント：https://www.moderne.ai/blog/ai-powered-openrewrite-recipe-authoring-with-claude-skill

2. LLM → Recipe：LLMが分析・計画を行い、Recipeが変換を実行する分工モデル

   • Spring BootやJavaアップグレードにおけるLLMとOpenRewriteのハイブリッドアプローチ
   • 自然言語からの移行計画生成とRecipe実行の組み合わせ

3. Recipe実行中にsidecarでLLMを呼び出す方式

   • Moderne PlatformにおけるPython sidecarとOSS LLMの統合アーキテクチャ
   • RecipeがLSTからデータを取得し、LLMに渡し、結果をLSTに戻す処理フロー
   • CPUワーカーノードでOSS LLM（Hugging Face）を実行する設計
   • 具体的なユースケース（misencoded French修復など）
   • 公式ドキュメント：https://www.moderne.ai/blog/ai-assisted-refactoring-in-the-moderne-platform

4. Recipe → LLM：rewrite-prethinkプロジェクト

   • LLM coding agentsのための信頼できるコンテキスト生成ツール
   • FINOS CALM Architectureによるアーキテクチャ図生成
   • Data Tablesによるコード構造のCSV/Markdownエクスポート
   • エージェント設定ファイル（CLAUDE.md、.cursorrules等）の自動更新機能
   • GitHub：https://github.com/openrewrite/rewrite-prethink

以上の4つの側面について、各技術のアーキテクチャ、主要な機能、具体的なユースケース、制限事項を含めて詳細に調査し、最後に調査結果を「OpenRewrite と AI／LLM の統合調査.md」という名前で Markdown ファイルとして出力してください。

Best regards,
Andrew

To Andrew:

OpenRewriteとAI／LLMの統合調査

Executive Summary

本調査は OpenRewrite と AI/LLM を組み合わせた4つの観点（1. AI支援Recipe作成（Moderne CLIのAI Skills）、2. LLM→Recipeハイブリッド（Java/Springアップグレード）、3. Recipe実行中のsidecarでのLLM呼び出し（Moderne Platform）、4. Recipe→LLMの補助ツール群（rewrite-prethink））を技術的に整理した。主要成果：Moderne はSkillベースのエージェント統合とLST（Lossless Semantic Trees）を核にサイドカー経由でOSSモデル（Hugging Face）をCPU上で運用するアーキテクチャを提示しており[^1][^2]。OpenRewrite は決定論的変換を担い、LLMは非決定論的残差（ビルドエラーなど）を補う役割で組み合わせる実例（Duolingo 事例）が確認できた[^3]。rewrite-prethink は LLM エージェント向けに信頼できるコンテキスト生成（CSV/Markdown/Calm JSON）とエージェント設定自動化を提供するモジュールである[^4].

Query classification

• タイプ: 技術的ディープダイブ（Query Type 3）。アーキテクチャ、実装箇所、コード参照を重視した分析を実施。

目次

1. AI支援によるRecipe作成（Moderne CLI AI Skills）
2. LLM → Recipe ハイブリッドワークフロー（Java/Spring 例）
3. Recipe実行中のsidecarでLLMを呼ぶ設計（Moderne Platform）
4. Recipe → LLM 補助ツール群（rewrite-prethink）
5. 結論と推奨
6. Confidence Assessment

1. AI支援によるRecipe作成（Moderne CLI AI Skills）

概要: Moderne は “AI Skills”（例: create-recipe, run-recipe, analyze-impact, create-organization/setup-target 相当）をエージェント向けに提供し、エージェント（Claude Code 等）の中からスラッシュコマンドで呼び出してレシピ生成・実行・影響分析を行うワークフローを提供する[^5][^6].

主な機能:

• create-recipe: レシピ雛形（YAML/Refaster/Java）、RewriteTest の骨格を生成する補助[^6].
• run-recipe: 既成レシピまたは開発中レシピの実行支援と診断出力の提供（開発/既存モード）[^6].
• analyze-impact: 実行データの集約・可視化（Sankey等）とマネジメント用レポート生成の支援[^6].
• setup-target/create-organization: 対象リポジトリ集合（repos.csv）作成・同期の支援[^6].

運用/アーキテクチャ注記:

• Skills は SKILL.md 等の静的リソースとして CLI が配布し、各エージェントの市場/ディレクトリに配置される（エージェントがその場で読み解く）[^6].
• CLI 側でスキルのインストールや更新コマンド（ブログは mod config moderne skills update を例示）を示すが、実際のフラグや manifest 仕様は docs を参照する必要あり[^5][^6].

制限事項:

• 公開ドキュメントはコマンド例の全フラグ仕様や manifest スキーマを網羅していないため、正確な CLI 引数は実環境の mod --help 等で確認が必要[^5].

2. LLM → Recipe：ハイブリッドモデル（Spring Boot / Java アップグレード）

概要: OpenRewrite の決定的なレシピ群で可能な修正をまず適用し、残ったビルドエラーやサービス固有の問題を LLM が解析・修正するハイブリッド手法が実運用事例として確認された（Duolingo の Golden Path）[^3].

典型ワークフロー:

1. YAML でアップグレード計画（ステップ列）を定義（どのコンポーネントを何順で実行）[^3].
2. 各ステップで OpenRewrite レシピ（recipeList）を実行、ビルド検証を行う[^3][^7].
3. ビルドエラーや手作業が必要なケースを LLM に渡して解析・差分生成 → 検証ループ（再ビルド）[^3].
4. 成功したら PR を作成して次ステップへ移行（段階的適用）[^3].

利点・制約:

• 利点: 決定論的変換を先に行うことで LLM の誤りリスクを限定できる。OpenRewrite の recipeList 構造は LLM の計画と自然にマッピング可能[^3][^7].
• 制約: LLM の出力の妥当性検証（テストカバレッジ・静的解析との組合せ）、一貫性・hallucination の問題、完全自動化のOSS実装が少ない点（多くは社内ワークフロー）[^3].

引用例（OpenRewrite recipe）: spring-boot-40.yml の recipeList を参照[^7].

3. Recipe実行中にsidecarでLLMを呼び出す方式（Moderne Platform）

アーキテクチャ要点（Mermaid 図）:

flowchart TD
  U[User/Orchestrator] -->|request| API[API Gateway]
  API --> Worker[Recipe Worker]
  Worker -->|fetch / decrypt| Connector["Connector / Artifact Repo"]
  Worker -->|text chunks| Sidecar["Python sidecar (Gradio) + HF model"]
  Sidecar -->|predicted text| Worker
  Worker --> Changeset["Changeset service"] --> SCM["Git/PR"]

詳細:

• LST（Lossless Semantic Trees）をアーティファクトとして保存・集約し、Worker が LST を復号して走査する。必要箇所のみを sidecar に渡し、返却された修正を LST に差し戻して changeset を生成する流れである[^2].
• Sidecar は Python（Gradio）でホストされ、Hugging Face からダウンロードしたOSSモデルを CPU ベースワーカーノードにデプロイする設計を明示している。モデルロードはコールドスタート対策として最初の呼び出しで行い、以降再利用するパターンが示唆される[^2].

運用面の注意点:

• CPU上で動くモデルを選定する必要があり、生成系のレイテンシは高くなるためバッチ/非同期処理が推奨される[^2][^6].
• Sidecar と Worker 間の JSON schema や認証・エンドポイント仕様は公開されておらず追跡が必要（記事は Gradio を言及するが API スキーマは not-found）[^2].
• セキュリティ：Worker は LST 復号用の鍵を短時間のみ取得して破棄する設計が明記されている（Moderne 管理ドキュメント）[^2].

代表ユースケース: fixMisencoded（誤エンコードのフランス語コメント修正）—言語検出（xlm-roberta）→SymSpellで修正候補→sidecarで生成→差分適用の例が紹介されている[^2][^5].

4. Recipe → LLM：rewrite-prethink（OpenRewrite の補助ツール群）

概要: rewrite-prethink はソースコードから「信頼できる」「構造化された」コンテキストを生成して LLM に与えるためのモジュールで、DataTable（CSV）出力、CALM 準拠 JSON、エージェント設定（CLAUDE.md 等）の自動更新機能を備える[^4].

主要コンポーネント（実装ファイル参照）:

• ExportContext.java — DataTable を集約し .moderne/context/*.csv と説明 Markdown を生成するレシピ[^4].
  • 実装: openrewrite/rewrite-prethink:src/main/java/org/openrewrite/prethink/ExportContext.java#L1-L220[^4].
• GenerateCalmArchitecture.java — DataTable から FINOS CALM 準拠 JSON を生成するビルダを実装[^4].
  • 実装: openrewrite/rewrite-prethink:src/main/java/org/openrewrite/prethink/calm/GenerateCalmArchitecture.java#L1-L740[^4].
• UpdateAgentConfig.java — .moderne/context/*.md をテンプレートに差し込み、CLAUDE.md 等を自動更新する機能を提供[^4].
  • 実装: openrewrite/rewrite-prethink:src/main/java/org/openrewrite/prethink/UpdateAgentConfig.java#L1-L200[^4].

利点:

• LLM に渡すコンテキストが構造化され、不要なノイズを減らすことで精度向上と hallucination の低減が期待できる[^4].

制限:

• rewrite-prethink 自体は LLM 呼び出しを行わず、DataTable の供給（発見用レシピ）は別途用意する必要がある（利用側で discovery recipes を作成）[^4].

5. 結論と推奨

1. 実運用では “決定論的な OpenRewrite レシピ → LLM による残差修正” のハイブリッドが現実的で安全性と効率のバランスが良い（Duolingo 事例）[^3].
2. Moderne のアプローチは LST と sidecar を組み合わせた実用的アーキテクチャを示しており、fixMisencoded のような具体例は参考になるが、実際の API schema / Dockerfile / k8s manifest 等は公開されていないため導入前に追加調査またはプロトタイプ検証が必要[^2][^5].
3. rewrite-prethink を使えば LLM に与えるコンテキストの質・一貫性が高まり、エージェント設定の自動化まで繋げられるため、大規模横断リファクタリングプロジェクトの前段パイプラインとして有用である[^4].

Confidence Assessment

• 高信頼（直接的出典あり）: Moderne の blog 記述（sidecar/Gradio/Hugging Face/CPU方針）[^2]; rewrite-prethink の実装ファイル（ExportContext, GenerateCalmArchitecture, UpdateAgentConfig）[^4]; OpenRewrite recipeList と実行方法（公式 docs）[^7].
• 中程度（推定・テンプレート）: CLI の正確なフラグ名や mod コマンドの全パラメータ（ブログは示唆するが manifest schema は未公開）、sidecar の API schema / Dockerfile / k8s マニフェスト（not found）[^5][^2].
• 低信頼（憶測）: mod config moderne skills update の内部実装詳細（公開ソースから exact match が見つからないためテンプレートでの推定を含む）[^5].

付録: 参考（抜粋フットノート）

[^1]: Moderne ブログ: “AI-Powered Recipe Authoring with Agent Skills and OpenRewrite” — https://www.moderne.ai/blog/ai-powered-openrewrite-recipe-authoring-with-claude-skill
[^2]: Moderne ブログ: “AI-assisted refactoring in the Moderne Platform” — https://www.moderne.ai/blog/ai-assisted-refactoring-in-the-moderne-platform
[^3]: Duolingo ブログ: “Automating JVM Golden Path” — https://blog.duolingo.com/automating-jvm-golden-path/
[^4]: openrewrite/rewrite-prethink repository — ExportContext, GenerateCalmArchitecture, UpdateAgentConfig implementations: https://github.com/openrewrite/rewrite-prethink (see src/main/java/org/openrewrite/prethink/*)
[^5]: moderneinc/moderne-docs (agent tools / skills) — https://github.com/moderneinc/moderne-docs/blob/main/docs/user-documentation/agent-tools/skills.md
[^6]: Moderne blog (create-recipe/run-recipe/analyze-impact/create-organization descriptions) — https://www.moderne.ai/blog/ai-powered-openrewrite-recipe-authoring-with-claude-skill
[^7]: OpenRewrite docs — Spring Boot upgrader recipe list example: https://docs.openrewrite.org/recipes/java/spring/boot4/upgradespringboot_4_0-community-edition

Report generated by research orchestration agent. 保存先パスは別途表示されます。

Best regards,
Copilot CLI

To Claude Code:

/deep-research OpenRewriteとAI/LLMの統合について包括的に調査してください。

Best regards,
Andrew

To Andrew:

追補：Deep Research 検証レポート（2026-05-30）

本セクションは /deep-research ワークフロー（101エージェント、19ソース、25クレーム敵対的検証）による追加調査結果である。上記の手動調査で得られた4つの観点に加え、最新の動向と独立検証による信頼性評価を提供する。

検証手法

• 5角度分解: Broad overview / 全体像, Research foundations / 技術基盤, Recent developments / 最新動向, Implementation guide / 実装手法, Limitations & critique / 限界と批判
• 19ソース取得 → 82クレーム抽出 → 25クレーム検証
• 3票制敵対的検証: 各クレームに対し3つの独立した検証エージェントが反証を試み、2/3以上で棄却されたクレームは不採用（12件確認 / 13件棄却）

✅ 検証通過した追加の発見

Finding A: ハイブリッド戦略の定量的優位性（信頼度: High, Vote: 3-0）

TalTech大学の修士論文（Karl-Erik Hein, 2025年5月）は、LLM単独・AST単独・ハイブリッドの3アプローチを定量比較した初の学術研究である：

第7章結論（原文引用）:

「最も成功するモダナイゼーションは、AST自動化を中核的反復的リファクタリングに、LLMを複雑な構文変換に、手動監視を検証に組み合わせる」

Duolingo Engineering Blog（2025年12月）も同一の結論に到達している：

“Don’t over-rely on AI. Learn to love determinism.”
「OpenRewriteレシピで強固な出発点に到達し、AIはギャップを埋めるためにのみ使用」

🔗 TalTech修士論文 · Duolingo Blog

Finding B: Moderne CLI MCPサーバの6エージェント自動検出（信頼度: High, Vote: 3-0）

Moderne CLIに内蔵された Model Context Protocol (MCP) サーバ は、以下の6つのAIコーディングエージェントの設定ディレクトリを自動検出し、MCPサーバ設定とAIスキルを自動インストールする：

MCPサーバは **Lossless Semantic Tree (LST)**（型付きツリー表現）を構築し、コンパイラレベルのコード理解をAIエージェントに提供する。公開ツール：

• run_recipe — リポジトリに対するOpenRewriteレシピの直接実行
• search_recipes — 3,500以上のレシピカタログの意味的検索
• learn_recipe — レシピの動作と使い方の説明取得
• query_datatable — コードベースの構造化データへのクエリ

Thoughtworks Technology Radar（2026年4月）もLSTベースのエージェントツーリングを「worth exploring」と評価。

🔗 Moderne MCP Docs · Moderne Blog (2026/04)

Finding C: 3つのAI/LLM統合アーキテクチャパターン（信頼度: Medium, Vote: 2-1）

Moderne Platformは2024年から2025年にかけて3つの異なる統合パターンを実装・製品化した：

1
2
3
4
5
6
7
8
9
10
11

パターン1: Human ↔ AI インタラクション
  └─ 埋め込みベースのAI意味検索 (BAAI bge-small-en-v1.5 + FAISS)
  └─ レシピカタログの知的探索（3,500+レシピ）

パターン2: Computer → AI 呼び出し
  └─ 決定論的OpenRewriteレシピがAIモデルをsidecar経由で呼び出す
  └─ 例: メソッドクラスタリング、自然言語コメント修正（上記セクション3の内容と一致）

パターン3: AI → Computer ツール使用
  └─ AIチャットボットがOpenRewriteレシピを検証可能な「ツール」として使用
  └─ ハルシネーション抑制 — AIの出力を決定論的レシピで検証・実行

⚠️ 信頼度 Medium の理由: 主要ソースがすべてModerne社ブログであり、独立した第三者検証が不足。また検証投票が2-1（1票が棄権相当）のクレームを含む。

🔗 Moderne AI Blog (2024/04) · LST Blog (2024/07) · Fintech事例 (2025/06)

Finding D: rewrite-ai モジュールの登場（信頼度: High, Vote: 3-0）

OpenRewrite 8.69.0（2025年12月16日リリース）で rewrite-ai モジュールがデビューした。これはOpenRewriteがAI対応をネイティブに組み込み始めた転換点である：

• Maven Central: io.moderne.recipe:rewrite-ai — v0.1.0 → v0.3.4（2026年5月現在、活発に開発中）
• コードベース内の AI/LLMアセット（使用エージェント、ライブラリ、モデル）の発見・インベントリ 機能を提供
• 前リリース8.68.1（2025-12-05）と8.67.0（2025-11-20）にはAI関連アーティファクトの言及なし
• チェンジログの「New Artifacts」セクションで唯一の新アーティファクトとして掲載

⚠️ 正確な収載レシピ数や機能範囲については検証で棄却されたクレームがあり（後述）、詳細は未確定。

🔗 OpenRewrite 8.69.0 Changelog

❌ 検証で棄却された主なクレーム

以下のクレームは3票制の敵対的検証で2/3以上の反証票を得たため、本レポートでは不採用とした：

⚠️ 注意事項と限界

1. 情報鮮度: MCPサーバ、rewrite-aiモジュール、エージェントスキルはいずれも2025年12月〜2026年の新機能であり、現在も活発に開発中。本レポートの記述は2026年5月時点のスナップショットである。
2. ソースの偏り: アーキテクチャパターン（Finding C）の主要ソースはModerne社ブログ。TalTech論文は学術的だがサンプルサイズが小規模（2サービス・1移行パス・1 LLMモデル）であり、一般化には注意が必要。
3. 実運用データの欠如: Duolingo以外に、実運用環境での大規模なOpenRewrite+AIハイブリッド導入の定量的データは見つからなかった。多くの導入事例は社内限定またはModerne社のSaaS内で行われていると推測される。

🔮 未解決の研究課題

1. rewrite-aiの正確な機能範囲: FindAgentsInUse, FindLibrariesInUse, FindModelsInUse 以外のレシピは存在するか？AI駆動のコード変換機能は将来的に追加されるのか？
2. MCPサーバ経由のレシピ実行の品質評価: AIエージェントが誤ったレシピを選択・実行するケースの頻度と影響は定量化されているか？
3. 決定論的優先アプローチの一般化可能性: Duolingoの手法は非JVM言語や小規模チームでも同様に有効か？
4. ハルシネーション低減の定量化: レシピをツールとして使用することでAIのハルシネーションは実際にどの程度減少するか？Moderne Platformのツール呼び出しアーキテクチャにおける定量的評価は？

📚 追加ソース一覧（品質評価付き）

総合的な結論

上記の手動調査（セクション1〜4）とDeep Research検証（本追補）の結果は高い一貫性を示している：

1. ハイブリッド戦略の優位性は学術研究（TalTech）と実運用（Duolingo）の両面から独立に確認された。これは上記セクション2・5の結論を強化する。
2. Moderne CLIのAI Skills（4つ） と MCPサーバ は、上記セクション1の内容をさらに具体化するものであり、6エージェント自動検出という運用面の詳細が追加された。
3. 3つの統合パターン（Finding C）は、上記セクション3・4で個別に論じたsidecarアーキテクチャとrewrite-prethinkを統一的に位置づけるフレームワークを提供する。
4. rewrite-aiモジュール（2025年12月〜）は、OpenRewriteがAIを「使う側」から「検出・管理する側」へと進化していることを示す新たな展開である。

最終推奨: 決定論的OpenRewriteを基盤とし、LLMを残差修正に限定するハイブリッドアプローチが現時点で最も堅牢な戦略である。Moderne CLIのMCPサーバとAI Skillsはこの戦略を運用化する有力な手段だが、公開された定量的品質評価が不足しているため、導入前に自社コードベースでのPoC評価を推奨する。

本セクションは /deep-research ワークフロー（wf_954c675d-9f4, 2026-05-30実行）により生成・検証された。統計: 5角度 → 19ソース → 82クレーム抽出 → 25クレーム検証 → 12確認/13棄却 → 5件に統合。エージェント101回呼出、実行時間約21分。

Best regards,
Claude Code