エージェントがRust（およびその逆）にとって何を意味するか

LLMがプログラミング言語設計（者）に与える影響を冷静に評価しています。 プログラミング言語設計でキャリアを積んできた者として、LLMの台頭には確かに実存的な恐怖を感じる瞬間があります。 私がコーディングを始めたのは小学校5年生の頃で、5MHzで動作するx86マシンに、ハードディスクは5MB、RAMは512KB程度でした。 当時のコンピュータは本当に、本当に異なっていました。しかし、正直なところ、プログラミングはそうではありませんでした。 IDEやプログラミング言語などの進歩にもかかわらず、ファイルにコードを入力するという基本的な行為は、驚くほど一貫したままでした――数年前まで、すべてがひっくり返るまでは。 それは時にエキサイティングで力強いものでしたが、恐ろしく、混乱させるものでもありました。 私のプログラミングのスキルは重要なのでしょうか？ プログラミング言語設計のスキル（もしあれば）はどうでしょうか？ このブログ記事は、それらの質問に答えるための私の試みです。 サスペンスを長引かせないために、結論を先に述べましょう。 要するに、はい、プログラミングにおける人間の役割は依然としてあると私は信じています。 そして、はい、プログラミング言語設計は依然として関連性があると思います。 そして、当然ながら、私はRustがエージェント開発に非常に適しているとも考えています――しかし、それは私たちがそれをより良くできないという意味ではありません。 そして、この記事は最終的にそれについてのものです：Rustとエージェント開発がうまく機能する理由、そして私たちがそれらの強みをさらに強化できる場所。 これは、今週SPLASHの一部であるREBASEで発表した講演の、一種の「ブログ記事コンパニオンバージョン」です。 また、IWACOで発表した講演のスライド、「IWACO and Rust: hidden links revealed」も楽しめるかもしれません。これはもう少し回顧的なものでした（ただし、サウンドトラックはありません）。 いずれにせよ、これは素晴らしいカンファレンスになりました！ Jack HueyはRust Vision Docについて発表し、驚くべきことに、Steve KlabnikとDorian Scheidtは「LLMs as Collaborators in Language Specification and Design」を発表し、Rueの構築プロセスについて語りました。 Steveに再び会えて楽しかったです。 それに加えて、特にIWACOでは多くの素晴らしい研究が発表されました。 私はReachability TypesとInformation Borrowingに関する研究に特に感銘を受けました。 Hylo Langについても、特にプロジェクションのアプローチについて学ぶのがとても気に入りました。 賢くてクールです。 エージェント時代に人気のRust Amazonで最も重要なSlackチャンネル、#aws-memesより。 Rustは現在人気があります。非常に人気があります： ブレークアウト言語の中で、TypeScriptは stratospheric で、グラフから切り取られ、前年比+1200%の成長を遂げています。[..] 最近の成長率で2番目に速いのはRustです。 Metaのエンジニアは、今年これまでに、過去9年間を合わせたよりも2倍の量の社内Rustコードを書いています。— David Tolnay（強調は私） その一部は、エージェントが新しいことを試すのを非常に容易にするからです。 そして、その一部は、Rustがパフォーマンスが高いという評判を持っているためであり、もしどの言語を選んでも同じくらい簡単なら、実行時間が速くなる言語を選ぶのはなぜでしょうか？ しかし、私はRustが別の理由でも人気があると考えています：それはエージェントコーディングに非常に適しているからです。 もちろん、私がそう言うのは当然でしょう？ この記事のポイントは、（1）それがなぜそうなのかを論じ、次に（2）それをさらにうまく機能させるためにRustについて何を変更できるかを議論することです。 エージェントによる基盤ソフトウェア構築 効果的な「ソフトウェアファクトリー」には3つの柱があるように思えます： 設計：コードが何をすべきかを明確に特定し、指定する。 構築：意図したとおりにコードを作成する。 最適化：効率的に実行されるようにコードを最適化する。 これらの柱のどれも解決されていませんが、いくつかは他のものよりも進歩しています。 Rustと最適化：デフォルトで高速、必要に応じてノブを調整 Rustは「デフォルトで良好なパフォーマンス」を提供するように設計されており、慣用的なものが通常は最も速いものです。 しかし、Rustのもう一つの重要な部分は、必要に応じてさらにパフォーマンスを引き出すためのノブがあることです。 スタック割り当てかヒープ割り当てか、ポインタの間接参照がどこで発生するかを制御できます。 必要であれば、構造体のレイアウトを特定の方法で強制したり、非同期スタックフレームにボクシングを導入する場所を決定したりできます。 究極的には、インラインアセンブリを挿入することもできます。 過去には、「パフォーマンスノブのチューニング」方法を学ぶことは、一種のブラックアートでした。しかし、エージェントはそれをはるかに容易にしています。 エージェントは既存コードのパフォーマンスの微調整に非常に優れていることがわかりました。 たとえば、超高性能暗号アルゴリズムに取り組んでいる人々は、かつてはアセンブリコードを手でチューニングしていましたが、今ではその同じ仕事のためにエージェントに頼っていると私に語っています。 より日常的な例では、多くのネットワークサービスを構築している人々は、dial9のようなプロファイラを使用して、エージェントが長いポーリングやブロッキングのような非同期パフォーマンスの落とし穴を非常に効果的に診断できることを見つけています。 したがって、Rustのタスクは明確だと思います。 私たちは「カーネルには十分低レベルで、GUIには十分高レベル」という目標を継続します。 むしろ、エージェントを中心としたシフトにより、clone()やshare()のような明示的な呼び出しの形で「ノイズ」をもう少し許容できるようになったと思います――ただし、あまり多くは許容できません。なぜなら、コードの「ハッピーパス」は依然として明確で明白であるべきだからです。 特定のシナリオで重要な詳細（チャネルエンドポイントのクローンがいくつあるかを正確に追跡するなど）を表面化させながらもです。 プロファイラと組み合わせることで、コードを高速に実行するための効果的なフィードバックループが得られます： フローチャート LR コード -- ベンチマーク --> プロファイル プロファイル -- 分析 --> エージェント エージェント -- 提案 --> PR PR -- 改善 --> コード 信頼性は常に最優先 いつものように、良好なパフォーマンスの評判が人々をRustに惹きつけるものですが、彼らが留まりたいと思う理由は、Rustを使用すると「よりうまく機能するように見える」という感覚です。 基本的な理論は、Rustの型システムとガードレールがエージェントを軌道に乗せるのに役立つということです： コンパイルすればほぼ正しいRustは、エージェントにとって完璧な言語です。 — Greg Brockman (@gdb) 2026年1月2日 私はそこに真実があると思います：Rust、Ocaml、Haskellのような言語はすべてこの「コンパイルすれば動く」という感覚を共有しており、エージェントはそれから恩恵を受けると思います。 テストだけでは不十分、型システムが助けになる テストはバグの存在を示すことはできるが、その不在を示すことはできない。 — Edsger W. Dijkstra, 1970 エージェントがその作業を発表しているところ。 テストを書くことは、プログラムが正しいことを示すには決して十分ではありませんでした――しかし、エージェントを使えば、それはもはや十分ではありません。 私の最初の数回のテストはうまくいったように見え、次のテストが完全に狂ってしまうことがよくあります。 通常は、そのバグがどのように発生したのか想像もできないほど狂っています。 そして、私が掘り下げると、エージェントが私が表現しようとしていたロジックを完全に理解していなかったことに気づきます。 ここで型システムが真価を発揮します――特にRustのような高度な型システムです。 型システムは、エージェントを軌道に乗せるためのガードレールを提供します。 Rustでは、それらのガードレールは、「すべてのフィールドに正しい名前があるか」のような単純なものから、「ソケットを閉じる必要がない」といったことまで拡張されます。 型システムだけでは不十分 型システムはバグの不在を示すことはできるが、正しさの存在を示すことはできない。 — 私、同等の雄弁さを持つフレーズを考案するのに失敗。 10, 2026 はい、型システムは役立ちます！ しかし、それらには固有の限界があります。 型システムは、それに従えば（特定の種類の）間違いを回避できる単純なルールのセットです。 しかし、それらは正しいことをしているかどうかを教えてくれるのではなく、（特定の種類の）間違ったことをしていないことを教えてくれるだけです。 さらに進みたい場合は、証明システムが必要です――豊かなプロパティが積極的に真実であることを示すことができるシステムであり、単にバグを回避しているだけではないシステムです。 偶然ですが、RustにはVerus、Creusot、Aeneas、Kaniのような興味深い証明ツールがたくさんあります。 出発点として、コードがパニックフリーであることを証明できます。これにより多くのバグが排除されますが、それは依然として根本的には「型チェッカーのような」プロパティです（つまり、間違ったことを避けることができます）。 しかし、さらに進んで追加することもできます