バイブコーディングでレガシーをモダナイズする（1/2）：20年もののC/C++アプリケーション

Fri, 16 Oct 2026 10:00:00 +0900

エージェントがレガシーC/C++の前で迷うのは、コードが複雑だからではなく、自分の作業が正しいかどうかを確かめる手段がないからです。モダナイゼーションの最初の投資先は、言語移行ではなく検証環境です。

チョン・ドヒョン - ROBOCO首席コンサルタント

バイブコーディング導入のコンサルティングをしていると、似たような悩みをよく耳にします。「うちのプロジェクトは複雑すぎて、エージェントが指示どおりに仕事をしてくれません」。最初は、ドメインが特殊なのか、プロンプトの書き方に問題があるのだろうと考えていました。しかし事例が積み重なるにつれて、共通点が見えてきました。こう話すチームのプロジェクトは、ほとんどが 20年以上前から続くC/C++のコードベース だったのです。

同じチームでも、新しく作ったPythonツールやWeb管理画面ではエージェントをうまく使いこなしていました。したがって、問題はチームの能力やエージェントそのものよりも、コードベースの側にあると考えるのが自然です。本記事では、こうしたレガシープロジェクトをバイブコーディングでモダナイズする方法を、公開事例と研究をもとに整理します。根拠資料は2026年10月15日時点で調査した公開事例・論文・ツールドキュメントであり、各数値は発表主体による自己報告である点もあわせてお断りしておきます。

本記事は、レガシーコードベースのモダナイゼーションを扱う2部作の1本目です。第1部ではC/C++で書かれたレガシーアプリケーションを扱い、第2部ではPHPで書かれたレガシーWebアプリケーションのモダナイゼーション戦略を扱います。

シリーズ：バイブコーディングでレガシーをモダナイズする

20年もののC/C++アプリケーション（本記事）
Webの歴史とともに積み重なったPHP

TL;DR

エージェントがレガシーC/C++で失敗する主な理由は、ビルドを再現できないこと、ポインタの所有権がコードに表れていないこと、変更を検証するテストがないことです（これは私のコンサルティング経験にもとづく解釈です）。
公開されている成功事例（Google giflib、Wiz fastText、Rukuzu）はいずれも、範囲の狭いモジュールを強力な検証とともに 置き換えています。数百万行を一度に別の言語へ翻訳した事例ではありません。
推奨するのは全面的な書き直しではなく、段階的なモダナイゼーションです。既存のコアはModern C++で安定化させ、境界が狭くメモリ欠陥の多いモジュールだけを選択的にRustなどへ移します。
エージェントは調査・変換・テスト・反復修正を担い、人は所有権の設計・互換性の判断・リリースに責任を持ちます。
最初の90日の目標は全面移行ではなく、代表的なモジュールを1つ本番移行し、同じ手順を繰り返せることを証明することです。

1. エージェントはなぜレガシーC/C++で迷うのか

コーディングエージェントは、コードを読み、修正し、ビルドとテストを実行して結果を確認するというループで仕事をします。このループの最後の段階である「確認」が塞がれると、エージェントは自分が修正したコードが正しいかどうかを知ることができません。私が現場で見てきた20年もののC/C++プロジェクトでは、このループが何か所も途切れていました。

第一に、ビルドを再現できません。 特定の開発者のPCに合わせたビルド設定、バージョンが固定されていないベンダーSDK、数十個のプリプロセッサマクロと条件付きコンパイルが絡み合っています。エージェントがクリーンな環境でビルドを実行できなければ、自分の変更がコンパイルできるかどうかすら確認できません。また、同じ関数でも、どのマクロが有効かによって実際にコンパイルされるコードが変わります。実際のコンパイルオプションなしにソースファイルだけを読んだエージェントは、存在しないコードパスを根拠に判断してしまいます。

第二に、ポインタの所有権がコードに表れていません。 古いC/C++コードでは、1つの T* が「このオブジェクトは自分が解放しなければならない」という意味の場合もあれば、「一時的に借りているだけ」という意味の場合もあります。その区別はコードではなく、20年前の作者の頭の中や、すでに失われたWikiの中にあります。エージェントがgrepで呼び出し箇所を見つけても、オブジェクトの破棄後にコールバックが実行されるのか、コンテナの再割り当てによって参照が無効になるのかまではわかりません。そのため、エージェントの修正はもっともらしく見えても、解放後使用（use-after-free）や二重解放を新たに生み出しかねません。

第三に、変更を検証するテストがありません。 テストがあったとしても、少数の正常系だけを扱っていることが多いです。人間の開発者はこの穴を経験と手動テストで埋めてきましたが、エージェントにはそのようなセーフティネットがありません。結果として、エージェントの生成速度は 検証されていない変更量 を増やすだけになります。

まとめると、これらのプロジェクトが「複雑すぎる」からエージェントが失敗するという診断は、半分しか正しくありません。より正確な診断は、エージェントが成否を判断する手段を持っていないということです。だからこそ、モダナイゼーションの最初の投資先は言語移行ではなく、エージェントがオリジナルと新しい実装をビルドし、同じ入力で比較できる検証環境 であるべきです。

2. 公開事例が実際に示していること

エージェントでC/C++をモダナイズした公開事例は、まだ多くありません。そして数字だけを切り出すと、誇張して受け取られやすいものです。以下の表は主要な事例をまとめたうえで、各数値が何を証明し、何を証明していないのかをあわせて記しています。

事例	移行元と移行先	発表された結果	この結果が証明していないこと
Google giflib¹	C 約3千行 → Rust	3千万個以上のGIFで回帰比較、2億回以上の差分ファジング、性能は中立	大規模アプリケーションを一括翻訳できること
Wiz fastText²	C++ 約2万行 → Go	2日間で5,434行のGo、保有するモデル検証テストに100%合格	すべてのAPI・プラットフォーム・学習機能の同等性
Loxation Rukuzu³	Kuzu C++ 約20万行 → Rust	報告時点で15個のcrate、2,700件以上のテスト	20万行全体の機能同等性の完了
Google IDの型変更⁴	32ビット → 64ビットIDへの横断的変更	変更595件のうち74.45%をLLMが生成、総作業時間を約50%削減と推定	言語の全面置き換えの効果
Bun⁵	Zig → Rust（C++ではない）	2週間未満で100万行以上を生成、既存CIをすべて通過	本番での同等性（通過後も回帰が19件見つかった）

これらの事例には繰り返し現れるパターンがあります。GoogleはSIMDやアセンブリを含まない小さなライブラリを選び、C ABI（バイナリレベルの呼び出し規約）をそのまま維持する置き換え実装を目標にしました。初期の変換後、FFI（言語間の呼び出し境界）のメモリ管理が健全でないという問題が見つかり、専門家がunsafeコードを直接レビューしました。Rukuzuは、既存のC++バックエンドと新しいRustバックエンドが同じ抽象インターフェースを実装するようにし、ビルドオプションでどちらかを選べるようにしました。どちらの事例も、まず置き換え可能な境界を作り、その境界の背後で新旧の実装を比較 しています。

Rust on ROBOCO

バイブコーディングでレガシーをモダナイズする（1/2）：20年もののC/C++アプリケーション

チョン・ドヒョン - ROBOCO首席コンサルタント

TL;DR

1. エージェントはなぜレガシーC/C++で迷うのか

2. 公開事例が実際に示していること