要点

対象：古い業務システムの刷新を頼む会社

  1. 新旧の出力をスクリプトで突き合わせる
  2. 金額が空欄の注文で初めて違いが出た
  3. 人が判断する場面は6つ

code-modernizationは、Claude Code（Anthropic のAIにプログラムを書かせるツール）に入れて使うプラグイン（追加機能）です。Anthropic が公開し、古いシステム（レガシーシステム）の刷新を手伝います。1

この記事の目次（5節）
  1. code-modernizationでできること
  2. 検証のしくみ
  3. 比較のスクリプトを動かした結果
  4. 現行システムを動かせるかで変わること
  5. 開発会社に頼む前に確かめること

開発会社がこのプラグインで刷新を進めるなら、新旧の出力を比べたときの入力の一覧と、違ってよいと認めた箇所の記録を出してもらってください。ふつうの入力だけで比べると、違いが見えないまま「一致」になることがあるためです。

code-modernizationでできること

プログラミング言語は問いません。移行の進め方は、同じ技術の新しいバージョンへの更新、別の言語での書き直し（リライト）、設計からの作り直し（リビルド）の3つです。1

現行システムのコードには手を加えず、分析の結果と新しいコードを別のフォルダーに書き出します。1

工程は次のとおりです。1

工程成果物
準備動かす環境の確認結果
調査規模と複雑さの評価、依存関係の図
業務ルールの抽出業務ルールの一覧と、根拠のコードの行番号
業務ルールの確認誤りの疑いがあるルールを確かめ直した一覧
計画段階ごとの計画書
書き換え新しいコード
検証モジュール（機能のまとまり）ごとの判定
セキュリティ強化現行システムのセキュリティ点検の結果と、修正パッチの案

人が計画を承認するまで、プラグインは新しいコードを作りません。1

人が判断する場面 01 02 03 04 05 準備 業務ルールの確認 計画 検証 セキュリティ強化 環境と質問 一覧を見直す 段階ごとの案 新旧を比べる 点検とパッチ案 判断すること 5つの質問に 答える 疑いのある ルールを直す 計画を 承認する パッチを 適用する 違いを認めるか 決める 結果を承認する
人が判断する6つの場面と、その場面がある5つの工程です。検証の工程には判断が2つあります。

人が判断する場面は6つで、プラグインが代わりに決めることはありません。1

検証のしくみ

現行システムを動かせる場合は、同じ入力を新旧の両方に与え、出力が同じかをスクリプトで突き合わせます。日時のように実行のたびに変わる項目は、比較の対象から外します。1

一致したかどうかは、AIが判断するのではなく、スクリプトが出力を突き合わせて決めます。2

モジュールごとの判定は、比較の結果やテストの結果をもとに、次の3段階で出ます。1

  • PROVEN（新旧が同じ動きをすると確認できた）
  • PARTLY PROVEN（一部だけ確認できた。足りないものも示す）
  • NOT PROVEN（テストや比較が実行されなかった・違いがあった・テストが通らなかった、のいずれか）

既存のテストの入力に加えて、境界値や空欄を含む新しい入力を10件以上作って試します。1

比較のスクリプトを動かした結果

2026年10月15日に、このサイトの検証で code-modernization 1.0.0 をインストールし、比較のスクリプト（compare.py）だけを動かしました。AIが読み解いて書き換える工程は、この環境では動かせず、試していません。

現行システムの代わりに、送料を計算する Perl の架空のプログラム（約60行）を用意しました。会員の割引や離島の加算などの業務ルールを入れてあります。新システムには、これをプラグインを使わずに Python で書き直したものを使いました。

比べた入力現行（Perl）の出力新（Python）の出力比較の結果
1組目: ふつうの注文5件5行同じ5行一致
2組目: 会員の割引と離島の注文2件2行同じ2行一致
3組目: 商品の金額が空欄の注文1件送料1,100円の1行エラーで止まり、出力なし不一致

1組目と2組目だけなら、不一致はありませんでした。3組目を加えると、スクリプトは新システムの出力が無いことを不一致として見つけました。

違いを見つけたあとに判断すること

現行の Perl は、空欄の金額を0円として扱い、送料を付けていました。実際のシステムなら、現行のこの動きが仕様か不具合かはコードだけでは決められず、業務を知っている人が決めます。

このプラグインでは、違ってよいと認めるとき、人が理由を書いて記録します。2

現行システムを動かせるかで変わること

開発会社の作業環境で現行システムを動かせれば、新旧を同じ入力で比べられます。

本番でしか動かないシステムのように、現行システムを動かせない場合は、過去に記録した出力と比べるしかありません。このとき、判定は最も良くても PARTLY PROVEN です。1

業務ルールの抽出はAIが行うので、実行のたびに見つかるルールが変わることがあります。業務ルールの一覧は、人が確かめてから使うものとされています。1

開発会社に頼む前に確かめること

ライセンスは Apache 2.0 で、無料で使え、改変もできます。1

プラグイン自体の料金の記載はありません。ただ、大きなシステムでは、AIの作業が多くなるぶん Claude Code の利用量が増えます。1 見積もりでは、Claude Code の利用料が含まれているかを聞いてください。

claude.ai/code などのクラウドでの作業では、パソコンに入れたプラグインは読み込まれません。3 開発会社がクラウドで作業するなら、このプラグインをどう使うのかを聞いてください。

開発会社には、次の4点を確かめてください。

  1. 現行システムを動かして比べたか（PARTLY PROVEN なら、その理由）
  2. 比べた入力に、空欄や上限値などの境界値が入っているか
  3. 違ってよいと認めた箇所ごとに、誰がどんな理由で認めたかの記録があるか
  4. 抽出した業務ルールを、業務を知っている人が確かめたか

Claude Code をクラウドで動かすときの確認は、クラウドセッションの記事にまとめました。Claude Code に追加の仕組みを入れる前の確認は、Claude Codeのmodsの記事にあります。

AIが直したテストを人が確かめる話は、Playwrightのテストエージェントの記事で取り上げました。

出典

  1. Anthropic「code-modernization」README（claude-plugins-official）（参照 2026-10-15）
  2. Anthropic「code-modernization」scripts/compare.py（新旧の出力を比べる部品）（参照 2026-10-15）
  3. Claude Code「プラグインのインストールと管理」（公式文書）（参照 2026-10-15）