Atsushi Nakatsugawa
May 26, 2026
2 min read
AI Migrates Code. Reviewing It Is Another Story.の意訳です。
3年前、私は非常に大きな差分を生むコード移行を進めていました。私のプリンシパルエンジニアは懸念を示し、「レビューしやすくするために、このPRをもっと小さなPRに分割できないか」と尋ねました。
私は、それが移行に伴うPRであるため、普段提出する他のPRよりもはるかに大きくなるのだと説明しました。
移行に伴うPRは珍しいものではありません。ReactからAngularへ移行する場合もあれば、古くなった技術スタックをモダナイズする場合もあり、企業が移行に取り組む理由はさまざまです。ただしAI以前は、こうした取り組みには非常に多くの時間がかかり、通常はレビューが難しい巨大な差分が生まれていました。
移行作業そのものに加えて、組織が直面する大きな課題の1つは、こうしたPRをどのように効果的にレビューするかを見極めることです。
私自身の移行経験は、現在のようなエージェント型コーディングツールや高度なモデルが登場する前のものでした。当時は、移行内容を生成すること自体が難所でした。現在は、AIによってその障壁は大きく下がりました。そしてボトルネックは、まったく別のものへ移りつつあります。移行によって必然的に生じる、大規模で複雑な差分のレビューです。
最近、世界中が目にした移行の中でも特に大きな事例の1つが、BunがZigからRustへ書き直されたことです。数日間で、およそ2,000ファイルにわたり100万行を超えるコードが変更されました。
そうです。数日間です。
Bunの場合、プロジェクトは小規模に始まり、理解しやすくスケールさせやすい言語を選びました。最近では、プロジェクトのスケールが難しくなり、メモリリークの問題にも直面していました。これが、BunがZigからRustへ移行した多くの理由の1つでした。
何千人もの人が驚き、中には怒った人もいました。移行そのものがAIによって書かれていたからです。ユーザーの不満は理解できます。しかし、この出来事は、今後この規模の移行がより一般的になるという議論のきっかけにもなりました。
AIコーディングエージェントは、どの言語でもプログラミングできます。これにより、移行をめぐる議論全体が変わります。以前は、チームは自分たちがコードを書き慣れている言語やフレームワークを選んでいました。また、これから使う、あるいはすでに使っているツールに合わせて人材を採用することもありました。
徐々に、構文そのものの重要性は下がりつつあります。その一方で、プログラミング全体における原則や基礎は、これまで以上に重要になっています。『Clean Code』で知られるUncle Bob Martinは、最近X（旧Twitter）に次のように投稿しました。
https://x.com/unclebobmartin/status/2055016815047164304
『Clean Code』は、決して構文について書かれた本ではなく、常に構造について書いています。第2版では、複数の言語で同じ原則を適用することで、その点をさらに明確にしています。エージェントを操る私たちが構文から目を離したとしても、構造から目を離すわけではありません。だからこそ『Clean Code』の原則は、依然として通用します。
AIエージェントはプログラミング言語に依存しませんが、PRのレビュープロセスは、組織やOSSプロジェクトにとって依然として課題です。特に、慣れていない言語で何が変更されたのかを理解するのは困難です。
もちろん、構文はいまでもある程度重要です。しかし、何がデリバリーされようとしているのかを理解し、PRレビューの中で議論することは、多くの開発者がいまも苦労している部分です。そしてPRはますます大きくなっているため、この問題は時間とともに深刻化しています。
長年にわたり、PRレビュー画面は小さなPRを前提としていました。開発者がレビュー中に何が変わったのかを理解できるようにするためです。
開発者として、GitHubが登場する前の世界を想像するのは難しいものです。私はいまでも、同僚にメールでパッチを送っていた頃を覚えています。GitHubが登場し、ブラウザ上で差分を確認できるようになったことで、個人としてだけでなく、チームとしてのコードデリバリー体験も変わりました。
現在、AIがコードの大部分を書いていることにより、PRのサイズが大きくなり続けていることは誰もが知っています。この新しい現実にもかかわらず、差分は20年近くにわたってデフォルトのレビューインターフェースであり続けています。
皆が話題にしているBunのPRを見てみましょう。そのPRには1,300件以上のディスカッションがありますが、それらはすべて隠れています。スレッド内の有用な議論は、展開しない限り表示されません。
もちろん、この規模の書き換えは印象的ですし、AIが移行において実現できる可能性を示しています。しかし、より難しい課題は、どのプログラミング言語であっても、レビュアーが大規模に移行されたコードを理解できるようにすることです。
私たちには、そうした変更の意図を説明できる詳細なビューが必要です。CodeRabbitではこの課題に取り組んでおり、私はそのことに大きな期待を寄せています。
少し正直に考えてみてください。PRレビューをするとき、どれくらいコードを読んでいますか？
レビュアーが大きなPRを1行ずつ読み、何が変わったのかを理解するだけの余裕を持てないことはよくあります。私は20年近くコードを書き、レビューしてきましたが、コードをレビューするときには意図を見て、そのコードが正しい問題を解決しているかを確認します。
多くの人も同じことをしています。PRがなぜ開かれているのか、どの問題を解決しようとしているのかを確認します。場合によっては、その変更がコードベースにどのような影響を与えるかについて、より多くの文脈を持っていることもあります。その場合はCI/CDパイプラインを確認し、承認するかコメントを残します。
つまり、PRレビューのプロセスを考えると、最も重要なのは意図と文脈です。CodeRabbitでは、コンテキストエンジニアリングへのアプローチを日々改善しており、このプロセスに専任するSMEもいます。
CodeRabbit Reviewでは、開発者がPRをレビューするために必要なものを提供します。変更の背後にある意図と文脈を含めて確認できるようにしています。
コード変更に関する文脈と意図は、コードがある場所に留まります。これにより、コードレビュー時のコンテキスト切り替え時に行き来するのを避けられます。
CodeRabbit Reviewは、どの変更をまとめてレビューすべきかを把握し、変更をスタック化します。これにより、PRを見る人がよりよい文脈で変更を理解しやすくなり、作業も進めやすくなります。
PRコメントが議論の中で埋もれてしまうことはよくあります。CodeRabbit Reviewは、そうした状況での移動を支援し、コメントをファイルのすぐ隣に配置します。見つけやすくすることで、レビュープロセスを高速化します。
オープンソースの世界は、AIによってより速く動くようになっています。OSSメンテナーは、これまで以上に速くバグ修正を出荷し、変更を検証できます。しかし、私たちがユーザーと交わしてきた会話では、大きなPRについてユーザーと議論することは依然として課題です。CodeRabbit Reviewはこのユースケースに対応でき、メンテナーがより大きなPRの変更を、より短い時間で理解できるようにします。
次にキューに入っている大きなPRで、CodeRabbit Reviewを試してみてください。CodeRabbit Reviewは、すべてのCodeRabbitユーザーに期間限定で無料提供されています。CodeRabbitのPRサマリーコメント内にあるReview Change Stackをクリックすると利用できます。
