【人間が上かAIが上か？】Next.jsバグ修正経験者、DeepWikiと対決する

## この記事は？

今回の記事は、かつて1年前くらいに Next.js の issue を漁って、PRを出そうと奮闘していてなんとか1件だけバグ修正ができた自分が、deepwiki とコード理解で対決してみよう！という内容です。

https://qiita.com/YmBIgo/items/45c8c3dfbc83e6fb57d7 

> 最近 DeepWiki が話題だけど、果たして本当に人間のコード理解を超えているのか？自分の手で検証してみたくなった…

というのが今回の動機です。
AIが勝つか人間が勝つか。気になる方は見てみてください。

※ 自分も Next.js を見るのは久しぶりなので、間違っている箇所があるかもしれません、もしあったら暖かくご指摘ください

## まず DeepWiki とは？

「[DeepWiki](https://deepwiki.org/)」は、Cognition Labs（AI開発アシスタント「Devin」の開発元）によって開発された、GitHubリポジトリをAIの力で自動的にウィキ形式のドキュメントに変換する無料のプラットフォームです。開発者が複雑なコードベースを迅速に理解しやすくすることを目的としています。

https://deepwiki.org/

https://huggingface.co/blog/lynn-mikami/deepwiki-ja

## Next.js の概略

DeepWiki の説明はここにあります。

https://deepwiki.com/vercel/next.js/1-next.js-overview

Next.jsは、大きく主に使う機能を分類すると、build (zero-config関係), server (サーバー側・rscやpage-router, app-router などがある), client (chunk の切り替えなどしている…記憶があります) に分かれています。
自分は server を中心に見ていたので development server の部分をピックアップして対決してみたいと思います！

## DeepWiki vs 自分：Next.js サーバー理解の比較レビュー２番勝負

今回の勝負は２番勝負で、

1. サーバーの全体の流れのフロー図化の綺麗さの勝負
2. 人間が選んだユースケースでの記述の勝負

にすることにしました（自分にもブランクがあるので...）

#### サーバーの全体の流れのフロー図化の綺麗さの勝負

まずは自分の過去の記憶を引きづりだしながら、Next.js の server の流れを書くことにしました。

https://qiita.com/YmBIgo/items/5d3b8407a69c4247150f

自分で書いた上の記事も参考に、昔の記憶を呼び覚ましコードを少し読んだら、Next.js の server の流れは以下のように書けました（自分の画力が足りないかもです）。

```mermaid
sequenceDiagram
    participant User
    participant NextJsEntryPoint
    participant RouteMatcher
    participant LoadComponent
    participant Renderer

    User->>NextJsEntryPoint: リクエスト送信
    alt base-server/next-server/next-dev-server:
    NextJsEntryPoint->>RouteMatcher: route match（route-matcher.ts）
    RouteMatcher-->>RouteMatcher: マッチ結果
    RouteMatcher->>LoadComponent: findComponent（server内）
    LoadComponent-->>LoadComponent: コンポーネント取得
    LoadComponent->>Renderer: render.ts / app/app-render.ts
    Renderer-->>NextJsEntryPoint: HTMLレスポンス返却
    end
    NextJsEntryPoint-->>User: HTMLやChunk返却
```

これに、dev環境だと webpackによるhot-reloadでファイルに変更が入るたびに routeのデータの作り直しなどをしていたはずです。

このお絵描きが、DeepWikiだとこうなりました。

![スクリーンショット 2025-05-11 20.51.15.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/92647/793eecf0-1976-4bae-b60c-12ef07c81fcd.png)

render.ts や app-render.ts や cache がより詳しくなっていますね。DeepWikiは、なかなかいい図を書きますね。

完敗です。

ただ１つだけ言い訳をさせてください。RSCの実装だと、コードジャンプした先が uglifyされた React の RSC のコードだったりしたので、app-render.tsは読むのが難しかったのです。
ここら辺で奮闘した過去は

https://qiita.com/YmBIgo/items/264f6ec7a05d1a120306

らへんにも載っています。

#### 人間が選んだユースケースでの記述の勝負

全体は見通せていそうなので、次は自分から問いを立てて勝負してみてみることにします。
ここでは「development server が hot-reloadをするときに、routeを追加などしたら、どのようにそれを更新しているか」を分かっているかを起点に見てみます。

先に答えを言うと、hot-reloadした時（upgradeHandler）に

https://github.com/vercel/next.js/blob/3f2a3647ee619c92f2d576b83dfde748003a7f31/packages/next/src/server/lib/router-server.ts#L689

resolveRoutes をし直す（handleRouteが重要）ことで、

https://github.com/vercel/next.js/blob/3f2a3647ee619c92f2d576b83dfde748003a7f31/packages/next/src/server/lib/router-utils/resolve-routes.ts#L104

更新を実行しているはずです。

---

DeepWiki の結果を見てみましょう！
DeepWiki の該当箇所はここっぽいです。

![スクリーンショット 2025-05-11 21.42.08.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/92647/01eddefc-7fbf-4233-8d40-12083d9b63eb.png)

や

![スクリーンショット 2025-05-11 21.44.16.png](https://qiita-image-store.s3.ap-northeast-1.amazonaws.com/0/92647/b456cc71-d373-46ce-bb64-fb7c15365382.png)

これらのコードをよく見てみると、resolveRoutesがinvokeRenderからも呼ばれていると言う衝撃の事実が発覚しました。

まぁ自分の言っている「Hot-reload(HMR)」の部分は記述は少ないですからね...
今回はかろうじて、私の勝ち...と言うわけにはいきませんね。教えてもらったのですから。。。まぁ今回は引き分けということで（無理矢理）。

## 感想

ここまで、１敗１引き分けという結果（自称）になりましたが、まぁ広い視点でのアーキテクチャなどの整理がすごいできていますね。
自分は細かいところから読んでいたので、正直アーキテクチャはあまり理解できていなかったので、そこらへんで住み分けして使えていければいいのかなと思いました。

ちょっと、routing 周りの複雑な仕様でも挑戦したかったのですが、ちょっとブランクが長く、かつちょっと今も根気強く読める気がしなかったので、割愛させてくださいmm

## まとめ：DeepWikiはどう使えるか？

- アーキテクチャ把握には非常に有効
- ユースケースや細部挙動はまだ人間の読解が必要かも
- 自分の理解補助として「併用」が最適

## 今後の展望
- 他のOSS（例：Kubernetesやargo-cdなど）でもDeepWikiとの比較をしてみたい

ここまで長文に付き合ってくださり、ありがとうございます！