Agentic Development: どうスケールさせるのか？
最近の私の開発は、AI との対話で大きめの GitHub Issue を作り、それらの PR 作成 + AI レビューまで AI にやってもらって、最後に必要な箇所を人がレビューする、という進め方です。ループエンジニアリングやグラフエンジニアリングの考え方は、自分なりにある程度実践できていると思っています。
ただ、これをもっと大規模なソフトウェア開発にスケールさせようとなると、わからないことだらけです。エージェントの構成、タスクの単位、人の役割の設計などなど。そこで、最近話題になった AI を最大限に活用したソフトウェア開発事例をいくつか読んで再整理してみました。各記事毎に、概要と私の所感を残そうと思います。以下、本記事で取り上げるものです。
Bun: 専門家がフェーズを切り、各フェーズをワークフローで進める
まずは、Rewriting Bun in Rust。今年の 7 月にかなりバズった記事です。53 万行の Zig を 11 日で Rust に移し、差分は +100 万行、約 6,800 コミット、約 50 の Dynamic Workflow（Claude Code の機能で、内部でエージェントが実行するステップも含むワークフローを作成・実行するものです）を設計・実行して、ピークでは 64 の Claude が並列で動きました。リリース前の Fable 5 を使い、費用は API 価格で約 16.5 万ドルで、著者の見立てでは手作業なら 3 人で約 1 年かかる作業量です。段階的な移行コストが高いと判断して一括で移行しています。言語に依存しないテストを活用して移行の検証を進めたみたいです。
最初のステップは、1,448 の Zig ファイルを同数の Rust ファイルに変換することにした、と読み取りました。移行ルール（Rust の機能をどう使うか）を Claude と 3 時間議論して作り、3 ファイルで試行錯誤した後に 1,448 ファイルを移行しています。タスクの単位はファイルごとの変換で、これを並列に動かしていそうです。その後は、コンパイラエラーひとつひとつの修正をタスクの単位として、並列作業させています。次のステップは、既存のテストをローカルで全て Green にすることで、それぞれのテストファイルをタスクの単位として作業させています。最後に、これらのテストが各プラットフォーム用に用意されたテストを CI を通して実行しながら修正をした、という流れです。
各フェーズ・タスクで、2 つ以上の Adversarial review（敵対的なレビュー。なぜその計画やコードが動かないかを網羅的に指摘する。）を別コンテキストで実行して、修正のループを回したようです。ここは私も開発で同じようなことをやっていて、私の中のベストプラクティスと近いと感じました。
言語の移行をするという、一見わかりやすいゴールですが、単に数文 AI に指示するだけではなく、人が逐次的に（AIとの対話を通してだと思いますが）次のフェーズのスコープを切って AI にやらせる、の積み重ねで完遂しています。これは私も普段の経験から思うことがあり、それらしい計画は立ててくれるんだけど、考慮漏れがけっこうあったりして、ここはまだ専門家の知識や経験が重要そうです。
また、各フェーズも完全な Agentic ではなく、計画と実行を分けています。計画では対話的に小さな実験をして方法の目安をつけ、Dynamic Workflow（Claude Code の機能、前述）で Agentic なステップを持つワークフローを定義し、それを実行します。エージェンティックな性質や LLM の頭脳を生かしつつも、要所は押さえて実行させる、みたいなイメージでしょうか。こうするとブレが抑えられて比較・改善しやすく、エージェント自身によるワークフローの改善もやりやすくなる、と理解しました。
GitHub Copilot: 同じ移行でも、本番を止めない区切り方
Migrating the GitHub Copilot runtime to Rust, using Copilot。こちらも大きなニュースになった、今年の 9 月の記事です。こちらは TypeScript → Rust ですが、Bun とは対照的に、後方互換性を保ちながら（TypeScript の部品を「Rust を呼ぶ薄い層」に替えて古いコードを削除する）、128 の PR で（意外と少ないですね）少しずつ書き換えています。書き換え後の Rust は約 830,000 行で、主に 1 人の開発者が数か月（5月初旬から8月下旬？）で進めました。著者曰く、従来であればチーム全体で 1-2 年かかるプロジェクトだったようです。
こちらは様々なモデルを使ってやってたみたいで、使用したモデルも時間経過とともに変わっていることは読み取れますが、詳細はわかりません。ただ、Primary Agent と Subagent で役割を分けており、Subagent では Haiku や Gemini も多く表に出てきていたことから、おそらくコストも気にしながら進める必要があったのだと想像しました。session.ts という一番重いファイルの移行については詳細な説明があり、これは 15 フェーズに分けて、それぞれのフェーズで 5.6 Sol もしくは Opus 4.8 を使用して移行したそうです。
タスクの切り方については、かかった期間（４カ月弱？）と session.ts の移行の進め方を見るに、Bun の事例とは違って後方互換性や既存の開発エコシステムを保ちながら進めると判断したことによる制約も大きく、従来のソフトウェア開発の延長線上のような手法で進めたと理解しました。
レビューについては、Code review at scale というセクションで、レビューの観点や Rebase の対応などについた解説がされています。レビュー用エージェントの使用と、そのエージェントに与えたであろうプロンプトが載っており、上記の Adversarial review に近いことをやったのだと理解しました。
こちらの記事には最後に Lessons learned がついていますが、ここでフェーズ分けやゴールの明確さの重要性と E2E テストの重要さについて触れられていました。
両移行ケースにおいて、一人でこれだけの開発をやっていて、かつその進め方が専門知識や経験に大きく依存していそうなので、やはり現段階においては、個人の能力に AI でブーストがかかっている、という認識で良さそうです。個人の能力差による出力の差がどれほど変わっていくのかは、注視していきたいです。専門性が競争優位性にならない時代がくるかもと考えると、怖いなぁ。
Anthropic のコードレビュー: 人のボトルネックを最小化する
How the Claude Code team does code review。10月に書かれた、Claude Code の開発チームがどうレビューをしているのか、の記事です。Claude Code のコードの約 90% は Claude が書き、モノレポの 1 日のマージ数は 5 月の約 2,500 件から 9 月に 30,000 件を超えました。目標は「ほとんどの PR を人間 1 人以下でマージ。ただしリバート・障害は増やさない」で、指標は 1 PR あたりの承認数と人の待ち時間、ガードレールがリバート・障害率です。
コードレビューの役割を２つに整理しており、一つは問題を見つけること、２つめはチームメンバーの共通認識を作ること、としています。基本的な考え方として、人の時間や注意は貴重なリソースであり、それを最小化するように設計されているようで、この調整は私も最近困っているところです。
一つ目の役割について、まず Claude Code の変更がどのようにマージ・リリースされるのかが紹介されています。従来のソフトウェア開発と違う箇所は、Adversarial review に似た自動 AI レビューと、これとは独立したセキュリティ専用 AI レビュー、このあとの Risk-based approval という、人のレビューのありなしを決める機構です。課金や自動更新機構、CI 周りが Risky な例で上がっています。この機構は、ルールと LLM の組み合わせで実現されていそうですね。これらの機構をすり抜けてしまう問題もあるのですが、それらについてはオンコールの人が rollback の対応をし、どのレイヤで捕捉されておくべき問題だったかを考え、CLAUDE.md や skill、評価セットに戻して改善しているようです。レビューと修正のループにも上限があり、3 ラウンドを超えるとレビュアーが著者に方針の見直しを求めます。一晩で 50 ラウンド以上回った PR があり、指摘の約 6 割は最初からあったコードへのものだったそうです。
二つ目の役割について、そもそもチーム内の誰かがコードベース全体の意図を把握している必要がないと考えているし、Claude Code のチームもそういう状態だそうです。どうなっているか知りたいときは、Claude に聞けばよい、というスタンスです。これが受け入れられない業界やプロジェクトは多くあると思いますが、やはりケースバイケースでとれるリスクを戦略的に決め、こういった大胆なアプローチをとることが大幅な生産性改善につながるのだと思います。
エージェント構成という観点からレビューのスコープの分け方は気になりました。通常レビューとセキュリティレビューを分けているように、観点ごとに分けた方がうまくいき、まとめてスコープが大きくなると質が下がるのは、私も実感しています。ただ、なぜ分けるのかも、どう切るのかも記事にはありません。ここはエンジニアの経験が要るところで、モデルの進化に合わせて見直すしかなさそうです。
まとめ
3 つに共通していたのは、実装とレビューを別コンテキストに分けること、E2E での実行結果を評価する基準を用意すること、ゴールやフェーズの区切りと高リスクな判断を人が持つことでした。そして Anthropic では、失敗をそのままにせず、指示書や評価セットに戻してループ自体を直していました。私は、ここが一番大事なところだと感じました。
エージェントを並列に動かす規模になると、人の仕事は、コードを書くことよりも、エージェントのループを設計して直すことに寄っていきます。これは技術力だけでなく、「なんかおかしい」という違和感を、指示や仕組みに変える力が要る仕事です。言語化力といっても、頭の中の暗黙知を発揮させる力に近く、専門性が違和感の源で、言語化がそれを仕組みにする、という掛け算に見えます。私自身、頭の使い方がだいぶメタな方向に変わったと感じていて、これができないと、エージェントを使い切るのは難しそうです。
では、そのメタ思考ができる人がどれだけいるのかという話ですが、まず、LLM の進化は、（人がコントロールできている限りは）人間の経済活動に寄ってくるはずなので、メタ思考を手助けする聞き返しや、型の提示の方向に発展していくと思います。加えて、開発者全員にこの力が要るわけではありません。簡単なアプリを作れる人が大量に増えれば、生産性の上がる現場はたくさんあるはずです。ただ、そういった現場でも、専門性や言語化力、メタ思考力がある人の方が、やはり生産性が高いことは変わらないと思います。そして、今回のような大規模で並列の開発でループを直す力が要る場面ではこういったスキルは必須になると思います。冷静に考えてみたつもりですが、少し願望も入っているかもしれません。
ちなみに、ループを直すループを直す、と考え始めると、抽象度が 1 つ上がるたびに同じ問いが出てきます。私の無限ループは、まだ終わりそうにありません。
関連記事: AI開発は天才宇宙人のマネジメント・コードの見える化: 決定的な計算を活用する
コメント (0)
まだコメントはありません。最初のコメントを投稿しましょう！