Canonicalは2026年8月19日、英ブリストル大学とCからRustへの自動翻訳を研究する3年間の博士プロジェクトに資金を出すと発表した。UK Research and Innovation（UKRI）も資金面で支え、数十万行規模のCリポジトリを、安全で挙動が一致し、保守できるRustへ変換する基盤を目指す。研究は2026年後半に始まる予定だ。

ただし、AppArmorやsnap-confineをRustへ置き換える製品計画が決まったわけではない。Canonicalが試そうとしているのは、LLMにコードを書かせることより難しい課題である。大規模なCコードを意味のある単位に分け、生成物を疑い、元の挙動を保つ証拠が得られるまで検証と修復を回せるか。その成否が、この研究の価値を決める。

AD

コンパイルできても移行は終わらない

既存の変換器は大量のCコードを処理できるが、Cの構造をそのままRustへ運びがちだ。代表例のC2Rustも、変換結果を「入力Cを忠実に写し、unsafeを含む非慣用的なRust」と説明し、安全で慣用的なRustへ仕上げるには追加作業が要ると明記している。機能を保つことを優先した中間生成物であり、そのまま保守を引き継げる完成品ではない。

LLMは逆の長所を持つ。範囲を絞った関数なら、所有権や借用を使ったRustらしい表現へ組み替えられる。しかし、数十万行のリポジトリでは、型、依存関係、挙動を一度に見渡せない。見た目が自然でコンパイルも通るコードが、元のプログラムと同じ仕事をする保証もない。

この違いは安全性の意味にも関わる。安全なRust（safe Rust）の範囲に収めれば、コンパイラは不正なメモリアクセスの多くを防げる。それでも、権限判定の間違いや仕様の読み違い、元コードからの挙動ずれは残り得る。CをRustへ移す目的は、unsafeという語を消すことではなく、既存の知識を失わずに保守可能な設計へ移し替えることにある。

Canonicalはすでに、Rust製のuutils coreutilsとsudo-rsをUbuntuへ採用してきた。ただし両者は、成熟した人手開発の再実装である。今回の自動翻訳研究は、はるかに不確かな生成物を同じ採用水準まで引き上げられるかを測る試みになる。

翻訳の成否を決める4段階

ブリストル大学のMeng Wang教授が研究を率い、同大学のCristina David博士とCanonicalのエンジニアリング担当VP Jon Seagerが共同指導する。博士課程の学生にはAlex Wood氏が選ばれた。計画は、機械学習にプログラム解析、テスト、形式手法を組み合わせるニューロシンボリック方式を採る。

段階 役割 失敗すると何が起きるか
スケジューリング 型や依存関係を失わない単位にリポジトリを分割し、翻訳順を決める 別の場所にある前提を見落とし、個々の関数では正しく見える誤訳を生む
翻訳 既存のCからRustへの翻訳例で学習または調整したLLMが、Rustの抽象化で意図を表す Cの構造を写しただけのコードか、もっともらしい別実装になる
検証 C版とRust版の挙動を比べ、ファジングや等価性検証を試す テストした入力でしか正しさを確認できない
デバッグと修復 検証失敗の原因を絞り、記号的なプログラム修復で該当箇所を直す 全体を書き直す反復になり、修正が別の挙動を壊す

4段階のうち、LLMが担うのは翻訳の一部である。分割方法が悪ければ必要な文脈が欠け、テストが弱ければ誤訳を見逃す。修復ループが局所化できなければ、変換規模が大きくなるほど変更の影響を追えなくなる。Canonicalが生成コードを「望む挙動を保つ証拠が出るまで信頼しない」とするのは、そのためだ。

難題は検証側にもある。Cには未定義動作や処理系依存の挙動があり、何を「同じ」とみなすかが決まらない場合もある。ポインタの多いAPIや並行処理では、Rustらしいデータ構造へ変えた結果と元の実装をどう対応づけるかが難しい。外部ライブラリとの境界やOS固有の処理まで入れば、単体テストの一致では足りない。

AD

なぜAppArmorとsnap-confineなのか

AppArmorとsnap-confineは、研究用の小さな題材ではない。AppArmorはUbuntuで使われるLinux Security Moduleの実装で、プロファイルに基づいてプロセスの権限を制限する。snap-confineはSnapアプリの実行環境を組み立て、AppArmorプロファイル、seccompフィルター、マウント名前空間を有効にする内部ツールだ。

どちらも、OSとアプリの境界で「何を許し、何を拒むか」を扱う。長年の改修で、ビルドシステムの複雑さやプラットフォーム固有の挙動が蓄積している。めったに通らないエラー経路にも、過去の不具合から得た知識が埋め込まれている。関数ごとに翻訳して既存テストを通す方法では、離れたモジュール間の前提や運用時の例外を落としかねない。

だからこそ、ケーススタディには価値がある。ただしCanonicalは、生成されたRustで両ソフトウェアを置き換える約束ではないと明記した。対象範囲や評価用の版、採用判断の基準も未発表である。研究が成功しても、成果は分割手法や検証技術、翻訳データセットにとどまる可能性がある。

100件中15件から先へ進んだ研究と、残る検証の壁

2025年公開のCRUST-Benchは、100件のCリポジトリに人手で設計した安全なRustのインターフェースとテストを組み合わせた。論文で評価した当時、最良だったOpenAI o1でも、単発生成で解けたのは15件だった。リポジトリ全体の依存関係を扱い、コンパイルとテストを同時に通す難しさが数字に表れている。

その後のプレプリントは前進を報告している。2026年6月のRebootは、6,000〜23,000行のCで書かれた6つのインタプリタを安全なRustへ変換し、各プロジェクトで1〜11回の短い人手介入が必要だったと報告する。Rebootは関数単位で切る代わりに、機能を一つずつ外した完全に動く中間版を作り、単純な版から機能を戻しながら翻訳と検証を進めた。大規模コードをどう分けるかというCanonicalの課題に、別の方向から答えた例である。

ただしRebootでは、開発中に与えたテストは全件通ったのに、モデルへ見せていない検証テストの通過率は62〜92%に下がった。既知のテストを満たすことと、未知の入力でも元の挙動を保つことは同じではない。これは著者によるプレプリント段階の結果で、AppArmorやsnap-confineへそのまま当てはめることもできない。

Canonicalの研究が数十万行を処理できても、翻訳行数だけでは成功と呼べない。確認すべきなのは、どの挙動を基準にしたか、未提示テストや複数環境でどこまで一致したか、unsafeと外部境界をどう管理したかである。さらに、性能を保ち、必要な人手を測り、既存の保守担当者が引き継げるコードになったかも公表してほしい。これらの証拠が揃って初めて、自動翻訳はUbuntuのセキュリティ境界へ近づける。