Claude開発・移行2026年7月16日

Anthropicが公開した「100万行のコード移行」6ステップ、非エンジニアが読むべき理由

Anthropicの発表ページ — 提供元の発表ページ（出典：Anthropic）

Anthropicが2026年7月16日、Claude Codeを使った大規模なコード移行の実践ガイドを公開しました。JavaScriptランタイム「Bun」を別のプログラミング言語に書き換えた事例では、100万行のコードが2週間かからずに出来上がっています。ただ、この記事で本当に読む価値があるのは行数ではなく、「AIの出した成果物を人が直すのではなく、成果物を生んだ手順のほうを直す」という進め方の部分です。コードを書かない仕事でも、AIに量のある作業を任せるなら同じ話になります。

何が変わったか

公開されたのは、Anthropicが社内で実際にやった大規模なコード移行の手順書です。プログラムを別の言語に書き換える作業を、AIエージェントに大量に並列で走らせて完了させた記録と、そのための6ステップがまとめられています。

代表例が、JavaScriptランタイム「Bun」をZigというプログラミング言語からRustに書き換えたケースです。公表されている数字は次のとおりです。

●100万行のコードが2週間かからずに出来上がった
●マージ前の時点で、既存のテストスイートは100%通過。マージ後に19件の不具合が出て、いずれも修正済み
●使ったトークンは、キャッシュを使わない入力が59億、出力が6億9,000万。API料金に換算すると約16万5,000ドル
●移行後の実測として、ベンチマークでのメモリ使用量が6,745MBから609MBに減り、バイナリは19%小さく、性能は2〜5%向上

もう1件、AnthropicのMike Krieger氏がPythonのコードベースを16万5,000行のTypeScriptに移行した事例も紹介されています。こちらは週末のうちに完了し、8つのフェーズゲート（工程ごとの通過判定）、3回の敵対的レビュー、最後に7つの実利用シナリオでの挙動一致チェックを挟んでいます。結果として、リリースごとに30分かかっていたコンパイルが約2秒に、起動は6倍速くなったとされています。

公開された6ステップは次の流れです。

1ルールブック・依存関係マップ・ギャップ一覧を作る（翻訳の方針、ファイル同士のつながり、そのまま訳せず作り直しが要る箇所を先に洗い出す）
2ルールを実地で試す（サンプルだけで小さく移行し、本番前に問題を炙り出す）
3全部を翻訳する（実装は小さいモデル、レビューは大きいモデル、という組み合わせで並列に回し、自信のない箇所はTODOとして印を付ける）
4コンパイルを通す（機械的なエラーは修正担当のエージェントに潰させる）
5スモークテストを流す（まず動くか、落ちないかを確認する）
6挙動を一致させる（元のコードと移行後のコードで、テストの結果が揃うまで詰める）

記事の核心はこの一文です。「コードを直すのではなく、そのコードを生んだプロセス（ループ）を直す」。1件ずつ手で直しに行くのではなく、同じ間違いが起きた原因をルールブック側に書き足して流し直す、という進め方です。

Claudeの入力画面。入力欄の下で「チャット」と「Cowork」を切り替えます。（出典：Claude（Anthropic）の画面）

業務での使いどころ

開発の話に見えますが、構造としては「決まったルールで大量に変換する仕事」の進め方そのものです。中小企業の現場でも、同じ形の作業はあります。

●向く仕事：正解の判定を機械側でできるもの。旧フォーマットの帳票を新フォーマットに直す、古い商品コード表記を新体系に置き換える、社内マニュアルを新しい用語ルールで書き換える、といった「数が多く、判断基準が明文化できる」作業
●向かない仕事：正解が人の合意でしか決まらないもの。値決め、人事評価、顧客への謝罪文の方針など。数を捌く話ではないので、この進め方の利点が出ない

参考になるのは3点目の「レビューを別に立てる」と、記事にある「コンパイラ、差分、テストスイートといったスクリプトに審判をさせる」という考え方です。人が全件を目視する代わりに、合っているかを機械的に判定できる仕組みを先に用意しておく。業務に置き換えるなら、変換前後の件数・合計金額・必須項目の欠けをExcelの関数で突き合わせる、といった程度でも成立します。

そして最初にやることは、AIに作業させることではなく「ルールブックを書くこと」です。ここを飛ばすと、出てきたものを1件ずつ直す作業に戻ってしまいます。

1変換のルールを文章にする（例外もここに書く）
2サンプル5〜10件だけAIに処理させ、ルールの穴を見つける
3見つかった穴をルールブックに書き足す
4全件を処理させる
5変換前後を機械的に突き合わせ、ズレた件だけを見る

ルールブックを先に作らせるプロンプト

これから【作業内容：例）旧フォーマットの見積書を新フォーマットに書き換える】を、大量に（約○件）行います。
いきなり作業を始めず、まず「ルールブック」を作ってください。

出力してほしいもの:
1. 変換ルール一覧（元の項目 → 変換後の項目 → 変換のしかた）
2. 例外・迷いそうなケースの一覧と、それぞれの扱い方
3. ルールだけでは決められず、私に判断を仰ぐ必要がある論点のリスト
4. 変換後に「正しく変換できたか」を機械的に確認する方法（突き合わせる項目・数値）

条件:
・私が渡していない情報を推測で埋めないでください
・判断がつかない箇所は勝手に決めず、3のリストに入れてください

--- 元データのサンプル ---
（ここに数件貼り付け）

3番目の「私に判断を仰ぐ論点」を出させるのが要点です。ここを先に潰しておくと、全件処理したあとで方針がひっくり返る事故が減ります。

試すときに気をつけること

公開されているのは開発向けの事例で、コストも小さくありません

紹介されているのはAnthropicの社内エンジニアによるプログラム移行の事例です。Bunの事例で使ったトークンはAPI料金換算で約16万5,000ドルとされています。この記事から持ち帰れるのは金額や行数ではなく、「ルールを先に固める」「判定は機械にさせる」「間違いは成果物ではなく手順のほうを直す」という進め方の部分です。

●テストが100%通った状態でマージしたあとにも19件の不具合が出ています。機械チェックを通ったからといって完了ではなく、本番投入後に見つかる前提で戻せる形にしておく
●社内データをAIに通す場合は、情報の取り扱いルールを先に確認する。まずは社外に出ない資料から試す
●全件をまとめて流す前に、必ず数件で試してルールの穴を潰す。ここを飛ばすと、間違いも同じ規模で量産される
●元データは必ず残す。上書きせず、変換後は別ファイルに出す