この記事は、Cheng Huang氏が「AI coding agentsを使って、実際の本番級分散システムをどこまで作れるのか」をかなり本気で試した記録です。
作ったのは、Rustベースのmulti-Paxos consensus engine。
Paxosは、複数のサーバーが**“このデータの順番や内容で決めよう”**と合意するための仕組みで、分散システムの心臓部みたいなものです。
要するに、データを複数台で安全に一致させるための超重要技術です。
しかもこのプロジェクト、ただの研究お試しではありません。
AzureのRSL（Replicated State Library）、つまり多くのAzureサービスを支える基盤を、Rustで現代のハードウェア向けに作り直す、というかなり野心的な内容です。ここは素直にすごいと思います。AIでちょっとコード補助、というレベルではなく、本番級の分散システムを丸ごと組み上げているのがポイントです。
記事によると、全体で約3か月。
そのうち、
という、かなり異常値に見えるスピード感です。
もちろん、単純比較はできません。AIが全部を勝手に書いたわけではなく、著者自身が設計し、レビューし、方向づけしているからです。それでも、これはAI時代の開発の“伸びしろ”をかなり強く示していると思います。
さらに最終的には、130K行超、1300件以上のテスト、しかもテストがコードベースの65%以上を占めるという状態まで進んでいます。
テスト比率の高さは、分散システムではむしろ健全です。Paxosみたいなものは、ちょっとした不具合が大事故につながるので、ここをサボれないんですよね。
AzureのRSLは強力ですが、10年以上前の設計で、今のハードウェアやワークロードに完全には合っていないと著者は見ています。具体的には次の3点が課題でした。
No pipelining
1つの投票処理が進んでいる間は、新しい要求が待たされる。
つまり、並列にさばけず、遅延が増える。
No NVM support
NVMはnon-volatile memory、つまり電源を切っても内容が残る高速な記憶領域です。
今のデータセンターでは珍しくなく、うまく使えればコミット時間を大きく短縮できます。
Limited hardware awareness
RDMAのような現代の高速通信をあまり活かせない。
RDMAは、サーバー同士がCPU負荷を抑えつつ高速にメモリへアクセスする技術です。分散システムではかなり重要です。
この3つは、言い換えると**“昔は十分だったけど、今の環境だともったいない”**という話です。
著者はそこをRustとAIで一気に作り直そうとしたわけです。
著者はかなり多くのAIツールを使っています。
現在の主力はClaude CodeとCodex CLIで、VS Codeは差分確認や細かい編集に使っているとのこと。
個人的には、この“CLI中心の非同期ワークフロー”という話がかなり面白いです。エディタの中でずっと待つのではなく、タスクを投げて、別のことをしながら進める。AI時代の開発って、だんだん「自分で全部タイピングする仕事」から「うまく指揮する仕事」へ寄っていくんだな、と感じます。
さらに著者は、Anthropicのmax planに月100ドル払っていて、それが「寝る前にClaudeで何か始めないと損した気分になる」仕組みになっている、と率直に書いています。
このあたり、かなり人間くさい話で好きです。高いサブスクを“元を取るための行動促進装置”にする発想、わりと効くんですよね。
Codex CLIが来た後は、ChatGPT Plusをもう1つ追加して、曜日で使い分けていたそうです。力業だけど、現場感があります。
この記事の核心の1つが、code contractsです。
これは簡単に言うと、関数に対して
を明示する仕組みです。
テスト中はassertとして動かし、本番では無効化できるので、性能を落としすぎずに安全性を高められます。
著者は以前から.NETでこの考え方を使っていたそうですが、AIと組み合わせると一気に強くなると言っています。ここはかなり納得感があります。
人間が「なんとなくこの関数はこう動くはず」と思っている部分を、AIに言語化させることで、曖昧さを減らせるからです。
著者はcontractsを次の3段階で使っています。
AIにcontractsを書かせる
GPT-5 Highのcontractsが特に良かったそうです。
ただし、著者はレビューと修正を担当。
contractsからテストを生成する
postconditionごとにテストケースを作る。
これはAIが得意で、エッジケースをうまく拾う。
property-based testsに変換する
これはかなり強力です。
いろいろなランダム入力を大量に試して、contract違反を見つける。
つまり、「たまたま通るテスト」ではなく、「広い入力空間で壊れないか」を探れるわけです。
実際、AIが書いたcontractによって、Paxosの安全性に関わる微妙なバグが見つかったとのこと。
これは重要です。Paxosは「安全性」が命で、ここを崩すと、データ整合性が壊れる可能性があります。
つまりこのcontractは、本番事故の芽を、かなり早い段階で摘んだことになります。ここは本当に価値が大きいと思います。
次のテーマはSpec-Driven Development（SDD）です。
これはざっくり言うと、いきなりコードを書かずに、まず仕様を書き、設計を書き、タスクを書いて進めるやり方です。
著者は最初、かなり厳密なSDDで作っていたそうです。
でも、やっていくうちに「文書の整合性を保つのが大変すぎる」と感じたとのこと。これ、すごくわかります。仕様書、設計書、タスク一覧、実装が全部ズレないようにするのって、現実にはかなり重いんですよね。
そこで著者は、軽量版のSDDに切り替えました。
/specify で仕様markdownを作る/clarify でAIに自己批評させ、改善案や抜け漏れを出させるこの「1 user storyがAIにとってのちょうどいい作業単位」という感覚は、かなり実践的だと思います。
大きすぎるタスクはAIが迷いやすいし、小さすぎると管理が面倒。
その中間として user story を使うのは、AI時代の現実解っぽいです。
記事には、configuration changes の例として、
「新しい configuration の starting slot をどう決めるか？」
という質問が出てきます。
おすすめは A: ending_slot + 1 に固定。
理由は、スロット番号に穴を作らず、前の設定から次の設定へ連続性を保つためです。
こういう会話を見ると、AIが単にコードを書くだけでなく、設計の判断を一緒に詰める相棒になっているのがわかります。ここはかなり未来感があります。
正しさをある程度固めた後、著者は約3週間を性能チューニングに使っています。
ここでもAIがかなり活躍したそうです。
改善のサイクルはこうです。
この流れ、地味ですがとても強いです。
特にAIがPythonスクリプトを書いて、quantile（分位点）を出したり、ボトルネックを見つけたりするのは、かなり“今っぽい”使い方だと思います。
結果として見つかった問題は、たとえばこんなものです。
最終的な改善ポイントは、
といった、かなり王道の最適化です。
でもこれを安全にやれるのがRustの強みです。
C/C++でこれをやると「速くなったけど壊れた」が怖いですが、Rustならかなり安心して攻められる。著者もそこを高く評価しています。
Rust + AI + 性能改善は、相性がかなりいい組み合わせだと感じます。
記事の最後では、著者が「AIにここまで来てほしい」と思う点を3つ挙げています。
仕様は人間が定義するけれど、実装の完走はAIにもっと自律的にやってほしい。
今はまだ、途中で「続けて」「リファクタして」「テスト増やして」と人間が細かく指示する必要がある。
ここが減ると、かなり本物の“自律開発”に近づくはずです。
contractsをレビューした後の流れは、かなり自動化できそうだとしています。
具体的には、
などをAIが回し、本当に重大な問題だけ人間に知らせる形です。
これはかなり現実的な未来像だと思います。
性能改善も、もっと自動化できるはずだという話です。
候補を人間が出し、実験はAIが全部やる。
AlphaEvolveやOpenEvolveのような方向性に期待しているとのこと。
大規模コードベースにも同じ手法が広がる余地は十分ありそうです。
個人的にこの記事のいちばん面白いところは、AIを“魔法の自動生成器”としてではなく、設計・検証・性能改善を一緒に回す実務ツールとして扱っている点です。
特に印象的だったのは、
という3本柱です。
これは「AIがコードを書く」以上の話で、AIと人間の役割分担をどう設計するかという話になっています。
そして率直に言うと、Paxosみたいな難物を相手にして、ここまで実用的なやり方を積み上げているのはかなり刺激的です。
AI開発は“速くなる”だけじゃなく、書き方そのものが変わる。この記事はその変化を、かなり具体的に見せてくれる好例だと思います。
付録によると、現在は以下の状態です。
つまり、まだ完成途中ではあるものの、かなり本格的に前進している段階です。
こういう大規模プロジェクトで、AIをうまく“相棒化”できると、開発の速度も質もかなり変わるのだろうな、と感じます。