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