結論
前稿で、AnthropicのBun移植の報告を引いた ── 100万行のZig→Rustが2週間未満、既存テストの100%通過。本稿はその換算である。
方法が大規模で成立したなら、小規模では簡単になる。 中小企業の業務システムの独自部分は、多くがこの実証の10分の1から100分の1の規模しかない。行数で割れば、期間は週末、費用は桁が二つ下がる。そして業務システムより先に、もっと軽い対象がある ── Webサイトだ。挙動が最初から全部外に出ているので、テストの抽出は巡回一回で済む。 壁として残っているのは技術ではなく、「うちには無理だ」という想定のほうである。
事実 ── 実証された数字
Anthropicの技術ブログ(7月16日)が報告した数字を並べる。
Bunの移植。 JavaScriptランタイムBunの中核、100万行のZigをRustへ。2週間未満で完了し、既存テストスイートの100%が通った。マージ後に見つかった退行は19件で、すべて修正済み。API費用は約16.5万ドル ── 入力59億トークン、出力6.9億トークン。
個人の移植。 同じ記事にはもう一つの実例がある。一人の開発者が、16.5万行のPython製プロジェクトをTypeScriptへ、一つの週末で移した。8段階のフェーズゲートを置き、敵対的レビューを3巡回した。
方法はどちらも同じである。コードを直すのではなく、コードを作る工程(ループ)を直す。 翻訳→コンパイル→テスト→検証の輪を回し、「コンパイラ、差分、テストスイートといったスクリプトを審判にせよ」。作業キューはディスクから毎回作り直される機械的なものにする ── だから中断しても、いつでも再開できる。
換算 ── 5万行なら、どうなるか
中小企業の業務システム ── 販売管理、在庫、請求、生産管理 ── の独自部分は、多くが数千行から数万行である。5万行と置いて、実証された数字で割る。
規模。 Bunの20分の1。週末で済んだ個人の移植(16.5万行)と比べてさえ、3分の1しかない。
費用。 Bunは100万行で約16.5万ドル ── 1行あたり約0.17ドルである。単純比例なら5万行で約8千ドル、円で百万円強。ただしこれは上限に近い見積もりだ。ランタイムの中核は密度が最も高い部類のコードで、業務システムの判定・帳票・承認の流れはそれより薄い。さらに前稿までに書いたとおり、少し前のフロンティア級の重みが無償で開かれる時代である。数十万円台に収まる方が自然だろう。
期間。 16.5万行が週末なら、5万行は週末で足りる。実時間の大半はAIの実行であって、人の作業ではない。
見積もりの前提は書いておく。行数比例は粗い物差しであり、実際の工数を支配するのは行数ではなく、次節の「テストの有無」である。
手順 ── 違いは一つだけ
Bunの移植と業務システムの作り直しの手順は、ほとんど同じである。違いは出発点にある。Bunには既存のテストスイートがあった。業務システムには、普通ない。
だから最初の仕事はテストの抽出になる。これは前稿に書いた蒸留そのものだ ── 動いている現行システムに問いを投げ、答えを記録する。受注を入れたらこの伝票、締めたらこの残高。現行システムが教師モデルであり、記録した挙動が教材である。
以降は実証された手順をなぞればいい。
- 挙動をテストにする。 現行を止めずに、入出力を記録して自動テストに起こす。テストデータの多くはモデルが作れる。人が足すのは、実データの癖と、業務上ありえない組み合わせだけ。
- 審判をスクリプトに立てる。 新旧に同じ入力を与え、帳票・仕訳・残高の一致を差分で確かめる。審判は新旧を同じ土俵で採点できなければならない。
- 機械的な作業キューで進める。 画面一枚、帳票一本を単位に並べ、終わったものから消す。キューが毎回ディスクから作り直されるなら、中断はいつでもできて、再開に説明は要らない。
- ゲートと敵対的レビューを置く。 週末で済ませた個人の移植でも、8段階のゲートと3巡のレビューを省いていない。速さは検証を省くことからではなく、検証を自動にすることから来る。
- 並行運転で答え合わせをして、切り替える。 一致が続いた区画から順に現行を引退させる。
現行を止めずに一本ずつ進める実務は以前書いたとおりで、そこに今回、規模と費用の実証値が付いた形である。
Webサイトなら、もっと簡単だ
業務システムより先に、もっと軽い対象がある。Webサイトである。
Webサイトは、蒸留の観点では特別な位置にある。挙動が最初から全部外に出ている。 URLを与えればページが返る ── この入出力の対が、挙動のすべてだ。業務システムでは最初の仕事だったテストの抽出が、Webサイトでは巡回(クロール)一回で済む。教材が公開されているのだから、教師に問いを投げる手間すらない。
手順は三行で書ける。現行サイトを巡回して全ページを記録する。AIに同じ見た目・同じ構造の静的サイトとして作り直させる。新旧のページを差分で見比べ、一致したらDNSを切り替える。
規模の感覚も書いておく。CMSで動く会社サイトの「独自部分」は、テーマとプラグインの改修が数百〜数千行あるかどうかで、大半はベンダーのコード ── 写す必要のないものだ。写すのは見た目と内容、つまり挙動だけである。費用は前節の換算からさらに一桁下がり、期間は週末どころか半日の仕事になる。
得るものは移行だけではない。閉じ込めの実務に書いたとおり、静的サイトにはデータベースも、サーバ側の実行環境も、管理画面も、プラグイン更新の追いかけっこもない。破られても、ファイルが書き換わるだけである。 CMSの保守費と脆弱性対応が、切り替えた日から消える。
本サイトも、この手順の産物を抱えている。ASP.NET Coreで動いていた旧サイト(約450ページ)を、.NETを一切動かさない静的ファイル群として写し取り、同じドメイン配下で配信している。動的なフレームワークの上にあっても、中身は実質静的だった ── 写すべきは挙動だけ、の実例である。
観測点
事例。 数万行級の業務システムを、テスト抽出→AI再実装→並行運転の手順で作り直した事例が、費用数十万円台・期間週単位で報告されるか。
外れ条件。 テストを整備した数万行級の作り直しが、それでも月単位・数千万円級に留まり続けるなら、本稿の換算は外れである。外れたら、外れたと書く。
関連
- ブログ 蒸留は、AIだけの話ではない ── AIが業務システムをつくる ── 前稿。テストが挙動を写し取るという構造
- ブログ Fableの公開で業務システムは自社開発が有利に ── 現行を正解器にして止めずに作り直す実務
- ブログ AI時代に必要な人 ── ソフトが安くなれば、攻撃も安くなる ── ソフトのコストがゼロに向かう構造の側
- ブログ AIファーストを主導して先見の明があると言われながら ── 「Webを静的にする」を含む、閉じ込めの実務
参考
- Anthropic: AI code migration ── https://claude.com/blog/ai-code-migration