JA
元のREODEキャラクターを整えた顔：紺のヘッドセットとシアンのレンズを着けて笑う、クリーム色とピンクのウーパールーパー
展示室へ戻る

REODE

Code migration

修正の前に、共通の原因を。

Java/Springのコード移行エージェントです。

2026.03 — 2026.04

業務プロジェクト · 移行と検証の体系

  • CLI実装済み · 業務

修正の根拠と受け入れ条件を分けた移行ループ

元のビルドの状態を記録してルールベースの変換を適用し、修正の前にソースとPOMの証拠を集めます。モデルが編集した後も、ビルド、テスト、テストの完全性を再び確認し、上限や停滞で終わった実行は成功と分けて報告します。

ルールベースの変換とモデルによる修正を組み合わせ、変更したコードをビルドとテストで確認します。業務プロジェクトです。

リポジトリでのREODE作業。pinxlabへの参加期間 March 16, 2026 to May 26, 2026

業務で使うCLIツールです。

修正ループ構成図 · 非公開の実装記録に基づく
REODE移行の修正ループ元のビルド状態をベースラインとして残し、ルールベースの変換を適用して、ビルドとテストで結果を検証します。失敗すると、修正の前にソース、アノテーション、POMの証拠を集め、既知のパターンを決定論的に修正して再ビルドします。再ビルドが通ればモデルは呼び出さず、失敗すれば集めた証拠と修正指示でモデルが修正し、結果を再び検証します。反復上限や停滞で終わった実行は測定に進みますが成功には数えず、スコアカードは5つの受け入れ条件をすべて満たしたときだけ等級を付けます。ソース · POM非公開の移行入力スコアカード · 等級デプロイではない失敗 · 停滞の報告成功に数えない原本の確認原本の状態 · compile実行状態ベースライン · 不明な値は未測定復旧記録修正前のチェックポイント同じエラーの過去の修正変換計画 → ルールベースの変換修正前の探索原因の証拠 · ソース3件 · POM決定論的な修正既知のパターンを修正再ビルドの確認モデルによる修正証拠 · 指示で修正検証build · test · 反復+1次の段階継続 · 測定 · 最大3回測定ルールの比率 · テスト · カバレッジ5つの受け入れ条件入力 · ベースライン復旧記録変換 · 修正検証 · 終了1ソース · POM2原本のcompile3ルール変換4build · test5結果 · 反復回数6通過 · 上限 · 停滞7ベースラインとの比較8等級付け1結果 · 反復回数2失敗 · 再試行3修正前に保存4証拠 · エラーのグループ5通過 · LLMを省略6再ビルドの失敗7過去の修正8再検証1通過 · 上限 · 停滞2ベースラインとの比較3等級付け4削除 · 除外 · 失敗5上限 · 停滞による終了

ルール変換

元の状態をベースラインとして残し、ルール変換の後にビルドとテストで検証して、測定まで進みます。

  1. ソース · POMソース · POM原本の状態 · compile原本の確認

    移行するJava/SpringのソースとPOMを受け取ります。顧客のコードと画面は表示しません。

  2. 原本の状態 · compile原本の確認原本のcompileベースライン · 不明な値は未測定実行状態

    変換の前にランタイムを選んで原本をcompileするため、もともと壊れていたビルドはベースラインに残ります。ベースラインのテストとカバレッジの既定値は測定値ではありません。

  3. 原本の状態 · compile原本の確認ルール変換計画 → ルールベースの変換変換

    実行グラフは、原本の確認 → 変換計画 → ルールベースの変換 → 検証と進みます。ルールで扱える変換を先に適用します。

  4. 計画 → ルールベースの変換変換build · testbuild · test · 反復+1検証

    変換したコードをビルドとテストで検証し、反復回数を1つ増やします。結果は実行状態に戻ります。

  5. build · test · 反復+1検証結果 · 反復回数継続 · 測定 · 最大3回次の段階

    ビルドの成否、テスト通過率、反復回数で次の段階を決めます。

  6. 継続 · 測定 · 最大3回次の段階通過 · 上限 · 停滞ルールの比率 · テスト · カバレッジ測定

    ビルドとテストの両方が通ったとき、反復上限に達したとき、または停滞が検出されたとき（未実施なら一度復旧を試みた後）、実行は測定に進みます。測定に進むことは成功を意味しません。

  7. ベースライン · 不明な値は未測定実行状態ベースラインとの比較ルールの比率 · テスト · カバレッジ測定

    測定は実行状態に保持されたベースラインを読み取ります。新たなベースライン実行ではありません。

  8. 5つの受け入れ条件測定等級付けスコアカード · 等級

    ビルドの成功、テスト通過率100%、カバレッジの変化が−5以上（ベースラインが分かっている場合のみ）、削除されたテスト0件、surefireの除外0件。5つすべてを満たしたときだけ等級を付けます。

原因に基づく修正

修正の前に証拠を集め、決定論的な修正を先に行います。再ビルドが通ればモデルを飛ばし、通らなければ証拠と指示でモデルが修正し、結果を再び検証します。

  1. build · test · 反復+1検証結果 · 反復回数継続 · 測定 · 最大3回次の段階

    ビルドの成否、テスト通過率、反復回数で次の段階を決めます。

  2. 継続 · 測定 · 最大3回次の段階失敗 · 再試行原因の証拠 · ソース3件 · POM修正前の探索

    ビルドが失敗したかテスト通過率が100%未満で、反復上限（既定3回）に達していなければ、修正に進みます。

  3. 原因の証拠 · ソース3件 · POM修正前の探索修正前に保存修正前のチェックポイント復旧記録

    修正の前にチェックポイントを保存します。ベストエフォートのため、保存に失敗しても修正は止まらず、保存は成功の根拠にもなりません。

  4. 原因の証拠 · ソース3件 · POM修正前の探索証拠 · エラーのグループ既知のパターンを修正決定論的な修正

    失敗したJavaファイル、最大3件のソースの冒頭部分、アノテーション、POMとannotation processorの設定、深さ2までのimportを集めます。範囲を限ったサンプルであり、コードベース全体の理解ではありません。

  5. 再ビルドの確認決定論的な修正通過 · LLMを省略build · test · 反復+1検証

    既知のパターン（例：Lombokの設定）の決定論的な修正で再ビルドが通れば、モデルは呼び出しません。それでも実行は検証に戻るため、これは最終的な受け入れではありません。

  6. 再ビルドの確認決定論的な修正再ビルドの失敗証拠 · 指示で修正モデルによる修正

    再ビルドが失敗すると、集めた証拠と修正指示がモデルによる修正に渡されます。コードを読むと、一緒に渡されるエラー文は再ビルドの新しいエラーではなく最初のビルドのエラーなので、「残ったエラーだけが渡される」と読んではいけません。実行で再現した欠陥ではありません。

  7. 同じエラーの過去の修正復旧記録過去の修正証拠 · 指示で修正モデルによる修正

    同じエラーシグネチャで記録された過去の修正を照会して添付します。モデルの学習ではなく、入力に加わる記録です。

  8. 証拠 · 指示で修正モデルによる修正再検証build · test · 反復+1検証

    モデルは構造化されたarchitect/editor経路で、その経路が使えないときや復旧中はtool-useプロンプトで修正し、ビルドとテストで再び検証します。モデルの編集は、それ自体では通過したビルドではありません。

通過と停滞の区別

等級には5つの条件すべてが必要です。テストの削除や除外、上限や停滞による終了は成功に数えません。

  1. 継続 · 測定 · 最大3回次の段階通過 · 上限 · 停滞ルールの比率 · テスト · カバレッジ測定

    ビルドとテストの両方が通ったとき、反復上限に達したとき、または停滞が検出されたとき（未実施なら一度復旧を試みた後）、実行は測定に進みます。測定に進むことは成功を意味しません。

  2. ベースライン · 不明な値は未測定実行状態ベースラインとの比較ルールの比率 · テスト · カバレッジ測定

    測定は実行状態に保持されたベースラインを読み取ります。新たなベースライン実行ではありません。

  3. 5つの受け入れ条件測定等級付けスコアカード · 等級

    ビルドの成功、テスト通過率100%、カバレッジの変化が−5以上（ベースラインが分かっている場合のみ）、削除されたテスト0件、surefireの除外0件。5つすべてを満たしたときだけ等級を付けます。

  4. 5つの受け入れ条件測定削除 · 除外 · 失敗失敗 · 停滞の報告

    テストの削除やsurefireの除外で得た通過、ビルドやテストの失敗は失敗のままです。削除と除外の検査はGitやPOMを読めないと0件と数えるため、すべての違反を捕捉する証明ではありません。

  5. 継続 · 測定 · 最大3回次の段階上限 · 停滞による終了失敗 · 停滞の報告

    上限や停滞で終わった実行も測定は経ますが、成功としては報告しません。これは報告の区別であり、測定を飛ばす近道ではありません。

すべての接続を同じ太さで表示します。フローを選ぶと、その経路だけを番号付きで強調します。

  • 実線 · 入力、結果、記録の流れる方向
  • 破線 · 実行、判定、要求
  • 長い点線 · 観測と報告、判定とは別
  • 短い破線 · 失敗、停止、上限
  • 太い黒線 · 選んだフロー。番号は順序
  • ボックス · コードまたは状態の境界、見出しに名前
  • 内側のチップ · その境界の構成要素
  • 点線ボックス · その境界の外
  • オレンジの枠 · モデルが判断する場所
  • パイプラインの段階 · 修正
  • 検証 · ルーティング · 受け入れ条件
  • 状態 · 記録
  • 修正前の探索

非公開の実装記録と開発記録から作図しました。名前は公開用の一般名で、コードパスや顧客情報は載せていません。

再ビルド失敗後の入力
モデルによる修正は集めた証拠と修正指示を受け取りますが、一緒に渡されるエラー文は再ビルドの新しいエラーではなく、最初のビルドのエラーです。コードを読んで確認した点で、実行では再現しておらず、ソースも変更していません。
受け入れ条件の限界
カバレッジのベースラインが不明な場合、その条件は飛ばします。surefireの検査は、ベースラインとの差分ではなく現在のPOMの除外を数えます。削除と除外の検査は、GitやPOMを読めないと0件と数えます。
事例と数値
約40件のsetterエラーをLombokとPOMの設定という1つの原因にたどったのは、当時記録された診断です。処理量、精度、最終的な納品の数値ではありません。