AI時代にこそRustだと思う話
はじめに
- 本記事は AI時代にこそTDDだと思う話 https://zenn.dev/akfm/articles/tdd-with-copilot を
パクってオマージュしてタイトルをつけたが、特にそれには言及しない。 - 本記事はRustを好きで使用している人間が書くポジショントークということを前提に読んでほしい。また、現状でRustを選択するべきだという主張をする記事ではなく、長期的に見るとRustとAIの組み合わせは親和性が高くなるのではないかという個人的予想を記載しているのみである。
- 本記事は自分用に雑に書いていた箇条書きメモをo1と対話しながら人に見せられる構造にまとめたものであり、文章構成に不自然な点が残っているかもしれない。
背景: AIの発達とプログラム責任の問題
昨今はAIによるプログラム生成の力に拍車がかかっている。いまやAIがあれば、品質度外視ではあるが素人でもコードを生成して成果物を残し、量産することすらことが可能になっている。しかし、AIが発達して人間が直接プログラミングをしなくてよくなったとしても、最終的な責任を人間が取る必要があるという点はこれからも変わらないと思われる。よって今後も成果物の最終的なチェックは人間が行うだろうが、そこで私が懸念しているのは、このままAIによってプログラムの生産活動のハードルが極端に低くなれば、コード量が肥大化し、結果的に人間が集中してチェック可能な範囲を超えることである。そうした状況への対策として、AIだけでは担保できないコードの安全性チェックをコンパイラによる静的型検査に一部任せることで、人間による監査をしなければいけない範囲を減らすことができる。Rustはその用途にうってつけである。
AIがあればコードを把握する必要もなくなるのか
このように、コードの把握が不要になる未来を想定する人もいるが、私はそうなるとは思わない。仮にコードの把握が不要になるとすると、以下のような問題が起きると考えている。
- 生成されたコードに悪意のあるコードが含まれていることに気づけない
- 実際にそういった意図的にAIモデルに脆弱性を含む回答を生成させるように学習データを操作する攻撃は Data Poisoning という名称で存在する
- 自動テストでこういったものを検知するのは難しい
- コードを把握する人材コストより攻撃を受けて認知したあとに対応するコスト（障害からの回復用の人員コスト、情報漏えい時の賠償金、etc...）のほうが安く、企業経営上のメリットがある場合にはコードの把握はしなくても良いかもしれないが、まあそうなることはないだろう
- コードの把握をしなくてもよいほど網羅されているテストケースの用意に難航する
- コードの把握をしない時代の、プログラミング脳をAIという外部に委託しているエンジニアは十分に網羅されているテストケースを用意できるのか？
- エラーやバグの内容に応じてAIに追加の指示をするにも、コードの前提や周辺知識がなければ状況を正しく伝えられない
- 最近はこんなに雑で抽象的な指示でも理解してくれるのかとAIに驚かされることも多々あるため、AIモデルの進化次第で必ずしもこれは問題にならない
- 開発した成果物に対して（セキュリティなどの非機能要件を含めて全てについて）人間や法人が(賠償)責任をとらなくて良い社会が来たら把握しなくても良くなるかもしれない
- 誰も人間が責任をとらなくても良い社会に、私も含めた大半の非合理な人間の感情がついていけるとは思えない
- その頃にはAIによって今と社会構造が完全に変わってしまっているだろうから予想がつかずなんとも言えない
参考
なぜRustか
Rustがもつ重要な利点として、所有権システムやunsafeなコードの分離による生ポインタ排除といったメモリ安全性を強固にする言語仕様や、静的型検査を乗り越えてコンパイルを通さなければ成果物を残すことができないという強制力がある。AIが複雑なコードでも“正しく”生成できるようになったときには、“メモリ安全”をコンパイラで縛る必要性が今より下がる可能性もあるが、今の社会システムでは「正しく生成された」かの責任を結局は人間が取ることになる。もちろん、法的・契約的な責任の所在や範囲、監査体制なども絡んでくるため、コンパイラによる型検査がどこまで人間の責任を軽減できるかは明確ではない。重要なのは「人間が負荷をかける必要がある部分を限定する」という点であり、その点においてはRustが大きな役割を果たす。責任問題をコンパイラに丸投げすることはできなくとも、“コンパイラが担保している範囲”を明確化しやすいのは監査フローの最適化につながる。さらに、並行・並列処理の安全性をコンパイル時に高い精度で保証できる点も、AIが膨大なコードを生産する時代には有効だろう。
また、現在のところRustを採用しない理由として、Rustを使える開発者人口の少なさ（とそれによる採用事例の少なさ）、学習コストの高さがよく挙げられる。
私はこの2つをAIが解決してくれると考えている。AIによる学習支援、教育に与える影響に大きな期待がもてることは言うまでもないが、聞けば答えてくれるメンターとしての使い方だけでなく、AIを使用すれば既存言語との相互なコード変換の自動化なども期待できるため、知っている言語を通じてRustを理解することができる。Rustへの学習ハードルが下がると開発者が流入し、採用事例も増える。また、AIがコンパイルエラーに立ち向かう仲間になってくれるのも心強く、精神的な負荷も下がる。
静的型検査が強い他言語ではダメなのか
（限定的ではあっても）安全性をコンパイル時に担保する機能や強制力を持つ言語であれば、Rust以外でも今後は十分に通用すると考えられる。しかしRustには、同じ方向性の他言語よりも言語自体の成長、開発者人口や採用事例の増加、アメリカ政府のような巨大組織からの推奨といった「勢い」がある。（主観も多分に含まれている）
AIがメモリ関連バグを自動で回避できるようになったとしても、言語仕様レベルで安全が保証されることには十分な価値がある。加えて、cargoやcrates.ioといった豊富なエコシステム、活発なコミュニティの支援、業界の主要プレイヤーへの広がりなど、Rustならではの強みが存在する。これら総合的な要素が、AI時代にもRustを選びやすい理由につながるのではないかと期待している。
Rustの欠点
一方でRustには、コンパイル時間の長さという欠点がある。変更のフィードバックの速さが重要なファクターであることはこれまでと変わらないが、AIにより大小問わず変更のハードルが低くなった分、他言語を差し置いてRustを選択するのであれば、他言語のように高速に修正して高速にフィードバックを得る開発体験が求められる。その際、Rustのコンパイルの遅さは足を引っ張る要因になるかもしれない。開発者自身がコンパイル時間を短縮する工夫を凝らす必要があるほか、Rust本体のさらなる進化による緩和も期待される。もっとも、AIが全自動で高速にコードを書ける世界が到来したら、コンパイル時間よりもデバッグ・実行時エラーの検証フローの方がボトルネックになる可能性があるとも言えるため、一概に致命的な問題とも断言できない。
RustとAIの今後
使用者が多くデータの豊富な言語と比べると、Rustは学習データがまだ少なく、精度の向上が求められている。しかし、Rustが使われるプロジェクトが増えればAIの訓練データも増加し、今後は精度が着実に向上する可能性がある。また、仮にデータセットが少ない段階であっても、AIは人間の予想を超えた成果を出すのではないかと期待させられるような実例もある。
以下は一例で、moldのバグをChatGPTが発見し、修正につながったというつい先日のエピソードである。
こうした事例を踏まえると、現状のデータ量や学習精度にかかわらず、AIとRustの協調が大いに進化していくのも期待してよいのではという気にさせられる。
まとめ
AIの台頭により、プログラミングの生産活動は大幅に変化すると考えられるが、最終的な責任を人間が負う必要性は依然として残るだろう。そこで、コンパイラによる静的型検査を活用して安全性を担保し、人間のチェック範囲を狭めることは非常に有効なアプローチだと考えられる。Rustの所有権システムなどの強力な言語仕様、充実したエコシステム、そして増え続けるコミュニティの勢いは、AI時代においても“Rustを選びやすい理由”につながるはずだ。
もちろん、コンパイル時間の遅さや学習データの不足といった課題はある。しかし、ツールチェーンの進化や採用事例の増加を通じて、これらの問題は緩和されていくのではないか。結果として、“Rust × AI”の組み合わせは長期的に見て人間の負荷を軽減しつつ、安全で効率の良い開発を実現する上で大きな可能性を秘めていると考えている。
参考資料
これは個人の意見だが、今の AIコード生成に向いてる言語は TypeScript / Scala / C# あたりの抽象度だと思う。
型システムが強力になって非人間的な数理モデルが強くなって、また推論しすぎて型シグネチャのヒントが減り、 C や Rust みたいにシステムプログラミングに近づくと、非人間的なコンピュータのデータ抽象が強くなる。推論が強い言語にとっては悲しいことに、明示的に型を書くほど精度が上がる。
逆に言えば、Compiler の Language Service が AI と対話するための、AIに優しいエラー出力を持つようになれば、その言語を学習したサンプル数が足りなくても高速に修正イテレーションを回して高品質なコードを生成できるだろう。なんならエラーのための Embedding Vector なんかを内部で持つようになっててもおかしくない。
Discussion