Canonicalは、CからRustへのAI翻訳をスポンサー - オープンソースがメモリ攻勢へ

Ubuntu、AI支援によるC→Rust自動変換プロジェクトを推進。目標は、単にコンパイルが通るコードではなく、真に安全なRustコードの実現。

具体的なケース

典型的なバグから始めよう：C言語で書かれたシステムデーモンにおけるバッファオーバーフロー。修正可能だが、6ヶ月後に再び異なる形で現れる可能性がある。なぜならCは機械的にこの種のエラーを防ぐことが保証できないからだ。今、同じコードがRustで書き直されたとしよう。そこではコンパイラがこのバグを構造的に不可能にする。これがCanonical（Ubuntuの開発元）が資金を提供して支援する野心的な取り組みだ：AIを活用して数百万行のCコードを安全なRustに自動的に翻訳するのだ。

なぜこれは簡単ではないのか

CからRustへの自動翻訳はすでに存在する。ツールのc2rustは何年も前からそれを行っている。問題は、生成されるRustが構文的には正しいが、至る所でunsafeであることだ。これはまさにメモリセーフティの観点から見ると、利点を完全に打ち消してしまう。構文は変わっても、セキュリティ保証は変わらないのだ。

Canonicalが支援するプロジェクトが目指すのは、慣用的で安全なRustだ。所有権、借用、ライフタイムのシステムを活用して、コンパイル時にセキュリティ不変条件を表現し検証するコードだ。これは根本的に難しい。なぜならCとRustは同じ思考モデルを持っていないからだ：

// C - 使用状況によってはuse-after-freeの可能性あり
char* get_value(struct Map* m, const char* key) {
 return hashmap_get(m, key); // mが変更されると無効なポインタの可能性
}

// Rust - コンパイラが借用中のmの変更を禁止
fn get_value<'a>(m: &'a HashMap<&str, String>, key: &str) -> Option<&'a String> {
 m.get(key) // ライフタイムの妥当性はコンパイラが保証
}

AIは、この2つの関数が機械的に等価ではないことを理解しなければならない。そして、素朴な翻訳ではunsafeブロックが生成されるだけで、真の移行にはならないのだ。

サブテキスト：オープンソースにおけるAI、次の行動

ここには、フリーソフトウェアを巡る議論の直接的な反響が見られる。Linus TorvaldsはLinuxカーネルに関して判断を下した：AI支援の貢献は歓迎される。反対者はフォークすればいい。Canonicalも同じ実用的な論理に従っている。AIを大規模な近代化ツールとして捉え、脅威とは見なさないのだ。

真の課題は人間による検証にある：誰が生成されたRustをレビューするのか？誰がCの元のセマンティクス、特に境界条件における動作が保持されていることを保証するのか？95%は正しいRustを生成し、5%は微妙に間違ったコードを生成するツールは、100% unsafeなコードよりも危険だ。なぜならそれは偽の保証を与えてしまうからだ。

期待されること

もしこのプロジェクトが約束を果たせば、システム層のRustへの移行が大幅に加速される。この移行はすでに進行中だ（Android、Windows、Linuxカーネル、OpenSSL）。CanonicalがUbuntuをターゲットにしているということは、数百万台のサーバーの低層レイヤーに直接影響するということだ。