DMMブックスのNext.js化を加速させるAI活用 / Migrating DMM Books to Next.js with AI

Think ! FrontEnd by DMM #10
https://dmm.connpass.com/event/397656/

スライド11の見出しで文字化けがおきています
正: AIの判断の余地を減らすかを基準にコンテキスト整備

Transcript

1. DMMブックスのNext.js化を加速させるAI活⽤ 電⼦書籍開発部 松下 健太郎 Think! FrontEnd #10 / 2026-08-28
2. ⾃⼰紹介 松下 健太郎 電⼦書籍開発部モダン開発グループ フロントエンドエンジニア 2016年新卒⼊社‧⾦沢在住 好きな仕事: リアーキテクト、パフォーマンスチューニング 趣味: 読書、カメラ、美術館巡り 最近読んだ本: ⾈を編む、さむわんへるつ
3. DMMブックスのNext.js化を進めている 昨年度に対応完了したページ例 トップページ 商品詳細ページ
4. DMMブックスのNext.js化を進めている • • • ⽬的 ◦ ユーザー体験向上 ◦ レガシーシステム脱却 状況 ◦ 昨年度 3ページを移⾏完了 ⼈⼿で移⾏ ◦ 今年度 8ページを移⾏予定 ⼈⼿ + AIで移⾏ ◦ 5⼈のフロントエンドエンジニアで対応を進めている 課題 ◦ ⼤量の移⾏を、品質を落とさずに効率よく進めること
5. 1ページの移⾏は画⾯移⾏とルーティング移⾏に分かれる 移⾏に必要な作業 画⾯ • 画⾯: React → Next.js 既存のReactコンポーネント資産を活かしつつ Next.js基盤へ移⾏ • React ルーティング: PHP → Next.js 従来のPHPサーバーのルーティング処理を Next.js基盤へ移⾏ ルーティング Next.jsへ統合 画⾯ & ルーティング PHP 移⾏⼿順書をもとに、各メンバーが作業 / 既存仕様どおりに動くよう移⾏
6. 画⾯移⾏では既存のReactコードを流⽤できる 移⾏のアプローチ 技術スタック‧設計の差異への対応 既存コードの書き換え作業がメイン データ取得 新規実装ではなく、すでに存在するコード資産 を活かした形で進めている。 全体共有の値 独⾃hook → TanStack Query グローバル変数 → hooks 経由で取得 想定される作業規模 1ページあたり 約10種類 の書き換え ※ 右記の記載内容は対応の⼀例 画⾯遷移 アンカー要素 → Next.js の Link その他 リポジトリ規約に合わせるための様々な対応が必要
7. 1ページの移⾏は4つのフェーズで進む 01 02 03 04 設計 実装‧レビュー 検証 リリース 移⾏対象を調査し、タ スク洗い出し‧実装⽅ 針を決める 画⾯とルーティングを 実装し、レビューする デグレードがないかを 様々な観点で確認 カナリアリリースで 安全にリリースを⾏う QA / 異常系 / トラッキ ング / UX / 脆弱性/ SEO → リリース判断
8. 今⽇のテーマ AI活⽤前提で実装‧レビューの進め⽅を ⾒直した話をします
9. 移⾏作業のAI活⽤⽅針をチームで決めた ⽬的 ⼤量のページ移⾏を、品質を落とさずに効率よく進める ⼿段 内容 狙い 移⾏スキルの作成 移⾏作業をスキル化し、実装を⾃動化する 実装⼯数を削減したい コンテキストの整備 リポジトリ規約をコンテキスト化し、 実装とレビューで参照する 成果物の品質を⼀定にしたい
10. 既存の移⾏⼿順書をスキル化した スキル 空ページ作成 Next.js基盤側に共通レイアウトを適⽤したページを作成 コピー 既存のReactコードをそのまま移動する 配置 規約に沿って既存コードをディレクトリを置き直す ⼊⼒ 出⼒ パス + ページ名 ページの雛形ファイル⼀式 作業対象ディレクトリ 移⾏元と同⼀構造のコピー 作業対象ディレクトリ アーキテクチャ規約準拠の配置 作業対象ディレクトリ 10種類の書き換え + 型エラー解消 ※ 再帰的に依存関係を確認して対応 適応 技術スタック差分の書き換えと、共通機能への繋ぎ直し (判断がいるところは⼈が⼊る) スキル ＝ 決まった作業⼿順を、AIが実⾏できる形にしたもの
11. AIの判断の余地を減らすかを基準にコンテキスト整備 区分 内容 どこに何を置くか （アーキテクチャ規約） 書いた 書いていない ⽤途別に使う関数‧ライブラリを指定する （⽇時の取り扱いやCookie操作、デバイス判定など） なぜ 置き場所が⼀意に決まる 実現⽅法が複数あるものを、1つに絞る Lintで担保できないルールだけ書く 機械で防げることは書かない なぜそうなったかの経緯 ⼈向けの説明は、AIには冗⻑ アーキテクチャ規約を中⼼で構成 規約 = ディレクトリを処理責務で分け、各レイヤーの責務‧禁⽌事項‧実装ルールを定めた⽂書 ※ 従来より規約はドキュメント化済み、それをベースに作成
12. 作業⽬的に応じて適切な情報を渡す形で運⽤ • 移⾏先のリポジトリにAGENTS.mdを作成 ◦ • 同じリポジトリを、作業⽬的の違う2チームが触る運⽤ ◦ • 実装‧レビューで同じものをAIが参照する形になっている エンハンス（機能改修） / 基盤提供（Next.js化）のチームが存在 作業⽬的に応じて適切な情報をAIに渡す形にしている ◦ リポジトリ規約はコンテキストに含む ▪ ◦ 作業内容が何であっても守るべきだから PRD‧ADR‧Issueは個別で渡す ▪ 作業⽬的や内容によって変わるものだから
13. 実際のページで移⾏トライアルを実施した • スキルとコンテキストを⽤意して、まず1ページで試した ◦ • Claude Code と Devin を、メンバーごとに割り振って試した ◦ • ⾒た観点：コスト‧作業時間‧完了できるか∕作業のしやすさ‧精度 チーム全員がスキルで実装できることを確認した 移⾏ツールとしてClaude Codeを選んだ ◦ 実装中にAIにフィードバックしながら、成果物を仕上げていくスタイルを好むメ ンバーが多かった トライアルで分かったこと → AIに作業を任せると、開発者1⼈でページ全体のコードを扱えるようになる
14. AIの能⼒を活かせるように、開発の進め⽅を⾒直す 従来の分担 AIができること 1⼈が画⾯の中の1機能を担当 ページ全体を読み解いて書き換えられる → AIに任せられるのも、その1機能の範囲だけ → 作業範囲が狭いままでは、能⼒を使い切れない 制約は AI ではなく、⼈⼿時代に決めた作業分担のほうにあった → AIが能⼒を発揮できる状態をどう作るかを考えた
15. 画⾯移⾏を機能で分けるのをやめ、ページを並⾏させた 従来（1ページの中を機能単位で分担） 現在（1ページ最⼤2名 × 3ページ並⾏） ページ A ページ A 画⾯移⾏ 機能 a 👤 機能 b 👤 機能 c 👤 ルーティング移⾏👤 ページ B 画⾯ 👤 画⾯ 👤 ルーティング ルーティング 👤 👤 ※ ページ B は、まだ着⼿できない 1ページの分担は、画⾯移⾏ ＋ ルーティング移⾏ の最⼤2名 ＝ 並⾏の単位が、ページ内の機能からページそのものに変わった ページ C 画⾯ 👤 ルーティング (兼任)
16. このやり⽅で2ページ移⾏を進めた 実際にやってみてどうだったか
17. 実装は「反復」だけど「定型」ではなかった 当初の想定 実際の状況 ⼿順書があるから、スキルに落とし込める 暗黙の判断やばらつきが多く、修正が多発 実装⼿順も、⽬指す成果物も、移⾏元コードの設計⽅ 針も似ているため、⾃動化が可能と予測していた • ページごとの実装のばらつき（コーディングス タイルや利⽤ライブラリ）をスキルが拾いきれ ない • ⼈⼿のときは開発者が「よしなに」やってい た、⼿順化されていない判断の繰り返しが浮き 彫りに 結論：反復だけど定型じゃない（定型の度合い＝分岐や考慮の少なさ） どうあるべきか（ゴール）は共通していたが、どうやるか（アプローチ）はページごとに異なっていた
18. スキルは使いどころを選ぶものだった • 2ページを並⾏で開発し終えたあと、AI活⽤をチームで振り返った • ページごとにばらつきがあり、スキルを全⾯的には使えない • ⾜りない部分は、⼈＋AI協業でカバーした ◦ • （コンテキスト＋対話で最終成果物まで作り込む） 開発者は熟練者が多く、AIとの対話で最終成果物まで作り込める ◦ スキルの出⼒は中間成果物。そこから仕上げる⼿間を考えると、 最初から最終成果物を⽬指したほうが速いと感じる場⾯があった → スキル利⽤は任意でよい、とチームで確認した
19. 1PRの差分が、ページ規模になった • 画⾯移⾏を細分化しないので、1PRの変更がページ規模になった • レビューを効率よく進める⼯夫は、以前からやっている ◦ ⼯程ごとにレビューできるように分けている （以前はコミット単位、いまはPR単位） ◦ 規約や仕様とのズレが⽣まれるのは書き換えの過程 → そこを重点的に⾒る • レビュー観点は、規約準拠 ∕ 既存仕様どおりかを⾒る • 開発者がコード品質を担保する役割は、変えていない
20. 以前と同じ精度で⾒るために、AIレビューを使い始めた Devin PlaybookによるAIレビュー 必須リポジトリのアーキテクチャ規約への準拠 任意作業ごとのレビュー観点を柔軟に指定 レビューの役割分担 差分増加でもレビュー観点は変えず、精度は落とさない 品質担保は開発者。AIは判断材料を出す役割に特化 実際のレビュー連携画⾯ (Slack / Devin)
21. 設計で作った仕様の洗い出しを、レビュー時も使う • 設計フェーズで、移⾏元から対象ページの仕様を洗い出している （Devin Playbook） • ◦ 本来の⽤途：移⾏規模の把握、⾒積もり、リファクタ要否の判断 ◦ 内容：コンポーネント⼀覧 ∕ 利⽤API ∕ ルーティングの処理 仕様洗い出しの資料をレビュー⽤Playbookにも渡す ◦ 移⾏元と移⾏先、2つのリポジトリを突き合わせるレビューになる
22. 品質を落とさず、並⾏して移⾏できるようになった 昨年度の移⾏体制 今年度の移⾏体制 ⼈⼿による逐次移⾏ ⼈⼿ ＋ AI による並⾏移⾏ 1ページずつ進める開発プロセス 最⼤ 3ページ を同時に並⾏して移⾏可能に 進捗状況（2026年度） ‧4⽉〜7⽉：2ページをリリース（今年度計画：8ページ） ※リリース後も安定稼働中 ‧現在：3ページの移⾏を並⾏して推進中 ※ 検証⼯程の⾒直し もあわせて実施し、開発プロセスの並⾏化に追従できる体制を構築
23. 1⼈が扱えるコード量を増やせたことが移⾏に効いた 対象 想定 実際 スキル ⼿順書があるから、実装を⾃動化できる 成果物の修正が頻発し、 ページごとの差分を拾いきれなかった コンテキスト 実装とレビューの精度を上げる 想定どおり効いた。 増えたコード量を⽀える⼟台になった 作業範囲 （当初は論点にしていなかった） ここが⼀番効いた。 1⼈が扱える量が増え、分担を変えることに繋がった スキルは、期待した範囲まで⾃動化できなかった。それでも移⾏は回った AIに合わせて作業範囲を広げ、増えたコード量をコンテキストで⽀えた ⼈⼿時代の分担のままでは、これは成⽴しなかった
24. 条件が変われば、⼿段も変わる • 今回の判断は、既存コードを流⽤でき、⼿順が確⽴していた条件で出たもの • この先には jQuery のページの移⾏を予定している • ◦ 既存コードの流⽤が効かない ◦ 移⾏の実績も、確⽴した⼿順もない ゼロから作るなら、逆にスキルが効くかもしれない → 今回のやり⽅が通じるかは、次のjQueryページ移⾏で試すことになる