言語選択は、ソフトウェア開発においてほとんど「取り消せない決断」として扱われてきた。移行コストが膨大になるからだ。しかしいま、その前提が崩れようとしている。
一週間で全移行が完了した
JavaScriptランタイムのBun、Claudeを使って開発言語をZigからRustへ移行中（Publickey、2026年5月12日）は、Bunの作者Jarred Sumner氏がAIを使ってZigからRustへの移行を進めている事例を伝えている。使用したのはAnthropicのClaude。約一週間でほぼ全作業が完了し、Linux・macOS・Windows（複数アーキテクチャ）のテストスイートをパスするところまで到達した。移行の動機は、「メモリリークやクラッシュの修正に費やす時間にうんざりした。言語レベルで防げる仕組みが欲しかった」というものだ。
なぜ言語移行は「現実解にならなかった」のか
これまで言語移行は、特にシステムソフトウェアでは現実的な選択肢にならなかった。数十万行規模のコードを別言語へ変換する作業は、数年単位のプロジェクトになるか、実質的に最初から書き直すことを意味したからだ。その重さゆえに、言語選択はほぼ不可逆な意思決定として扱われてきた。
AIはその構造を変えつつある。機械的なパターン変換——構文の対応、型の置き換え、APIマッピング——は、AIが特に得意とするタスクだ。Sumner氏がClaudeに渡した「Zig → Rust porting guide」は変換ルールを定義したドキュメントであり、AIはそのルールに従って大量のコードを処理した。ここでAIが担ったのは「変換の判断」ではなく「変換の実行」だ。
移行コストが変わると、何が変わるか
注目すべきは速さではない。「移行コストの構造が変わった」という事実だ。
移行コストが下がると、技術選択の可逆性が変わる。「まずZigで始めて、必要になればRustへ移る」という判断が現実的になれば、チームは最初の選択に縛られなくなる。スタートアップや小規模チームにとっても、最適な技術スタックを段階的に選び直せる余地が生まれる。
ただし一点、条件を見落としてはならない。AIによる変換が「動くコード」を出力することと、「正しく動くコード」であることは別だ。BunにはLinux・macOS・Windowsを横断するテストスイートがあり、それが品質の担保として機能した。移行コストを下げたのはAIだが、品質の根拠を持つのは依然としてエンジニアリングの構造そのものだ。
言語移行を現実解に変えたのはAIだが、その先の品質を保証できるかどうかは、変わらず人間が設計したテスト基盤にかかっている。
関連記事
参考文献
コメント