2026 年 5 月 17 日、Hacker News で Bun が 6 日で Rust に書き換わった件 と JavaScriptランタイムのBun、Claudeを使って開発言語をZigからRustへ移行中 が広く議論されました。Bun は JavaScript ランタイムで、それまで Zig で実装されていたコア部分を、Claude Code の支援を受けて 6 日間で Rust に書き換えました。これは 「LLM による大規模言語移行が実用域に入った」ことを示す象徴的な事例です。
受託で中堅企業の基幹システムを担う立場では、これは 「20 年前の言語で書かれた基幹システムを現代の言語に移行する」案件が、現実的なコストで実行可能になったことを意味します。これまで TypeScript 6 移行ガイド や Zed 1.0 受託オンボーディング で扱った **「言語 / エディタの世代交代」の最終形として、「LLM 大規模言語移行」**は受託にとって最大級の市場です。本記事では弊社が提供する 「LLM 大規模言語移行 + 業務継続代行」 パッケージを整理します。
なぜ「LLM 大規模言語移行」が中堅企業の受託需要を爆発させるか
| 構造 | 人手による移行 | OSS 変換ツール | LLM 大規模移行（Claude Code） |
|---|---|---|---|
| 期間 | 1〜3 年 | 数ヶ月（一部のみ） | 数週間〜数ヶ月 |
| コスト | 数億円 | 数千万円 | 数千万円（人手 1/3） |
| 対応言語ペア | 任意 | 限定 | ほぼ任意 |
| ビジネスロジック保持 | 人手レビュー必須 | 失われやすい | テスト駆動で保持可 |
| 副次的なリファクタ | 別工数 | 不可 | 同時実行可 |
| ドキュメント生成 | 別工数 | 不可 | 同時生成可 |
| 失敗時のリスク | プロジェクト中止 | 部分移行で止まる | テスト網で早期検知 |
つまり中堅企業の **「20 年前の言語で書かれた基幹は触れない」問題が、「LLM + 受託運用」**で 数ヶ月単位で解消できる可能性が出てきます。
Bun 事例から読む「LLM 大規模言語移行」の核心
核心 1: 「テスト網」がないと LLM 移行は破綻する
Bun チームは 既存の Zig コードに対する大規模テスト網を保持していました。LLM が書く Rust コードを テストで即座に検証できたから 6 日で完了しました。テスト網のない基幹システムは、まず 「テストを書く」フェーズから始める必要があります。
核心 2: 「LLM 1 人に書かせる」ではなく「人間 + LLM チーム」
Bun の事例も 「LLM が単独で書いた」わけではなく、人間エンジニアが設計 / レビュー / 統合し、LLM が 大量の機械的変換を担いました。役割分担の設計が成功の鍵です。
核心 3: 「言語の置換え」ではなく「業務継続性の確保」
LLM 移行で最も難しいのは 「移行中も業務が止まらない」ことです。並行稼働 / シャドートラフィック / 段階的切替の運用設計が、技術以上に重要です。
受託で提供する「LLM 大規模言語移行 + 業務継続」5 フェーズ
フェーズ 1: 既存システム棚卸し + 移行可能性診断（3〜4 週間）
顧客の既存システムを **「言語 / 規模（LOC）/ 依存ライブラリ / テストカバレッジ / 業務クリティカル度」で分類します。「触れない聖域」と 「移行可能領域」**を線引きします。
フェーズ 2: 移行戦略策定（2〜3 週間）
- 移行先言語の選定（Rust / Go / TypeScript / Java など）
- 段階分割（モジュール単位 / 機能単位 / リファクタ範囲）
- テスト網整備計画
- 並行稼働 / 切替戦略
- LLM コスト見積もり
フェーズ 3: テスト網整備（4〜8 週間）
既存システムに対して 特性テスト（Characterization Test）+ ゴールデンマスター テストを整備します。LLM 移行の前提条件として最重要フェーズです。
フェーズ 4: LLM 移行実行（4〜12 週間）
- Claude Code / Codex / Cursor を組み合わせた移行チーム編成
- モジュール単位の移行
- レビュー + テスト合格 → マージ
- 段階的本番リリース
- 並行稼働 + シャドートラフィック
フェーズ 5: 移行後運用 + 知識移転（継続）
新言語での コーディング規約 / CI / ライブラリ管理 / モニタリングを整備し、顧客社内エンジニアへの知識移転を行います。
受託向け技術スタック標準セット
| レイヤ | 推奨技術 | 代替 |
|---|---|---|
| LLM 開発支援 | Claude Code / Codex CLI | Cursor |
| テスト網 | 特性テスト + Property Based Testing | スナップショットテスト |
| CI | GitHub Actions + 自動レビュー Bot | Jenkins / GitLab CI |
| 並行稼働 | フィーチャーフラグ + シャドートラフィック | ブルー / グリーンデプロイ |
| モニタリング | OpenTelemetry + Sentry | Datadog |
| コードレビュー | エージェント生成 PR レビュー | 人手のみ |
| ドキュメント生成 | LLM 駆動 ADR / README 自動更新 | 手動 |
これは TypeScript 6 移行ガイド で扱った 言語アップグレードの 「クロス言語版」として整理できます。また エージェント生成 PR レビュー の運用設計と組み合わせて初めて回ります。
どの案件に必要か / 不要か
| 必要な案件 | 不要な案件 |
|---|---|
| 基幹システムが 10〜30 年前の言語 | 既に現代言語で書かれている |
| 採用難で旧言語エンジニアが減少 | 旧言語エンジニアが豊富 |
| 機能追加コストが年々上昇 | 機能追加コストは安定 |
| 業務継続性を保ちながら移行 | 一気に書き直す体力あり |
| テスト網が部分的にある | テスト 0 件 |
受託契約に書く 6 つの条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| 対象範囲 | モジュール / 機能 / 全体 | 範囲固定 vs 段階拡大 |
| 目標言語 | Rust / Go / TS など | 採用 / 教育影響 |
| ビジネスロジック保証 | 特性テストで担保 | 受入テスト範囲 |
| 業務継続要件 | 並行稼働 / 切替方式 | ダウンタイム許容 |
| LLM コスト負担 | 受託 / 顧客 / 折半 | 想定 LLM 予算 |
| 知識移転 | 顧客社内へのトレーニング | 受託終了後の自立 |
価格モデル — LLM 大規模言語移行パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| 診断 | 200 万円〜（6 週間） | 既存システム棚卸し + 移行戦略 | レポート |
| Lite | 500 万円〜（3〜6 ヶ月） | 〜 5 万 LOC / 1 言語ペア | テスト網 + 部分移行 |
| Standard | 1,500 万円〜（6〜12 ヶ月） | 〜 30 万 LOC / 並行稼働あり | 全体移行 + 業務継続 |
| Enterprise | 3,500 万円〜（12〜24 ヶ月） | 30 万 LOC 以上 | + 全社展開 + 知識移転 |
別途 LLM 利用料（Claude / Codex）が 数十万〜数百万円 / 月規模で発生します。
顧客側 ROI 試算（旧言語 20 万 LOC / 年間保守 4,000 万円想定）
| 項目 | 移行しない | LLM 移行後 | 差分 |
|---|---|---|---|
| 年間保守 / バグ修正コスト | 4,000 万円 | 1,500 万円 | -2,500 万円 |
| 機能追加リードタイム | 平均 3 ヶ月 | 平均 1 ヶ月 | -2 ヶ月 |
| 採用 / 教育コスト | 年 1,200 万円 | 年 300 万円 | -900 万円 |
| 障害対応 MTTR | 平均 8h | 平均 2h | -6h |
| 年間効果（移行コスト除く） | — | — | 約 3,800 万円 |
| LLM 移行コスト（受託 + LLM 利用料） | 0 | 単発 2,500 万円 | -2,500 万円 |
| 2 年目以降の純効果 | — | — | 約 3,800 万円 / 年 |
Standard プランは 2 年目から黒字化し、3 年目以降は純利益が拡大します。
ハマりやすい 5 つの落とし穴
落とし穴 1: テスト網なしで LLM に移行させる
テストがない状態で LLM に書き換えさせると、「動くけど挙動が違う」コードが大量発生します。テスト網整備を必ず先行させます。
落とし穴 2: 「LLM に丸投げ」で人手レビューを削る
Bun の事例も人手レビューを 削っていません。LLM が書く → 人間がレビュー → テストの三層構造を崩しません。
落とし穴 3: 移行中に新機能を並行開発
旧コードに新機能を入れ続けると、移行先と差分が拡大し続ける地獄に陥ります。移行期間中は新機能凍結 or 二重実装を契約に明記します。
落とし穴 4: 切替方式を「ビッグバン」にする
全モジュール一気切替は 失敗時にロールバック不能です。フィーチャーフラグ + 段階切替を必須化します。
落とし穴 5: 知識移転を後回しに
受託終了後に 顧客が新言語でメンテできないと、再外注に永久依存します。移行と同時に社内エンジニア教育を契約に組み込みます。
90 日アクションプラン
| 週 | アクション |
|---|---|
| Week 1〜4 | 既存システム棚卸し + 移行可能性診断 |
| Week 5〜7 | 移行戦略策定 |
| Week 8〜13 | テスト網整備 + Lite モジュール移行開始 |
まとめ — 「20 年前の言語」を 6 日では無理でも数ヶ月で解く
Bun の事例は、**「LLM 大規模言語移行が現実的な工期で可能」な時代を示しました。中堅企業の基幹システムを預かる立場では、「旧言語の塩漬けか、巨額の書き換えか」の二択を超えて、「LLM + 受託運用」**による 計画的な現代化が選択肢になります。
弊社では 診断 / Lite / Standard / Enterprise の 4 段階で LLM 大規模言語移行パッケージを提供しています。「20 年前の言語の保守コストが膨らんで困る」「旧言語エンジニアの採用が困難」「LLM 移行を検討したいが失敗が怖い」というご相談は お問い合わせフォーム からお気軽にどうぞ。
