Post AI時代のリファクタリング実践記 / Refactoring in the post AI era

2026/10/15
Sotas×カミナシ×estie｜AIのスピードに開発組織はどう追いつくのか？
https://sotas.connpass.com/event/398322/

Post AI時代のリファクタリング実践記

鈴木　健太郎（すずけん）
エンジニアリングマネージャー

Transcript

1. Post AI時代の リファクタリング実践記 2026.10.15 AI時代の開発⽣産性とリアーキテクチャ すずけん / @szk3
2. はじめに ⾃⼰紹介 経歴 前職でフロント‧バックエンド‧インフラ‧ネイティブアプリ ‧EMを⼀通り経験。AWS移⾏やCCoEの組成を牽引。2022年10⽉ にカミナシに⼊社。 カミナシでの仕事 クラウド‧インフラのIC、サービスチームでの開発を経て、新規 株式会社カミナシ エンジニアリングマネージャー 事業「カミナシ 設備保全」でプレイングマネージャー型のEMを実 践中。 鈴⽊ 健太郎（すずけん） ：@szk3 2
3. はじめに 今⽇伝えたいこと 1 Post AI時代の⼤規模リファクタリングは、挑戦的に計画できるようになった 2 リファクタリング作業そのものが、コンテキストとハーネスを育てる⼟壌になる 4
4. Q. みなさん、リファクタリングに まとまった時間を取れていますか？ 5
5. Post AI時代のリファクタリング実践記 リファクタリングスプリントとは 私たちのチームでは、サービス開発のロードマップにあらかじめリファクタリング期間を計画し、 実施のたびに経営層とも合意して⾏っています。 リファクタリングスプリント ⼤きなリリース後に機能開発をいったん⽌めて、将来のサービス開発の⾜かせに なりそうな課題を、サービスチーム全体で先回りして解消する期間 ※ ⼩さな VoC 対応やバグ修正は⽌めないよ リファクタリングスプリントのことを、チームでは「挑戦的にしゃがむ」と呼んでいます。 6
6. Post AI時代のリファクタリング実践記 チームにおけるリファクタリングスプリントの歴史 Pre AI Pre AI Post AI 1回⽬ 2回⽬ 3回⽬ 2024年秋 2025年 2026年 β版リリース後 正式リリース後 前回から約1年後 実質2週間 約1.5ヶ⽉ 約2.5ヶ⽉ / 前回から＋1名 7
7. Post AI時代のリファクタリング実践記 Pre AI 時代の主要な課題が、Post AI 時代に全部終わった Pre AI 時代は、期間内に終わるか⾒通せない重い改修が、どうしても後回しになっていた 主要な課題 1回⽬（Pre AI） 2回⽬（Pre AI） 3回⽬（Post AI） APIシナリオテストの拡充 ⼤枠のみ 着⼿したが未完了 完了 拡充は時間切れ ユースケース層への切り出し 時間切れで未着⼿ ⾒送り 完了 DIの導⼊ 時間切れで未着⼿ ⾒送り 完了 結果 AIで実⾏が速くなり、2回⾒送ってきた重い改修までやりきれた 8
8. Post AI時代のリファクタリング実践記 リファクタリングスプリントの⽬的 今回は、⽬的をこの2つに絞った 1 現状⾒える景⾊から、開発ルールを再設計する 2 サービス開発に、⽣成AIをオンボーディングする 9
9. Post AI時代のリファクタリング実践記 ⽬的ごとにやったこと コードを直すだけでなく、AI が働く環境も⼀緒に整えた 1 開発ルールの再設計 2 サービス開発への⽣成AIのオンボーディング Backend に usecase 層を追加 コンテキスト‧ハーネスの整備 トランザクション境界は Unit of Work に ※1 rules、スキル、ディレクトリ別 CLAUDE.md、Hooks Frontend のレイヤー構成を⾒直し LLMの出⼒を機械的に判定 ディレクトリと命名をそろえ、依存の逸脱は CIで検知 APIシナリオテスト、E2E、単体テスト、静的解析 テストしやすい構造に作り直し ⾃動PRレビューの導⼊ Backend は DI導⼊、Frontend はロジックを Hooks‧純粋関数へ Claude Code を採⽤（Codex も含めて検証して選定） 次の開発を実装しやすくする仕組みの導⼊ ツール群の統⼀ マルチプロダクトの推進と、体験負債の解消に向けた先⾏投資 AWSのモックは moto、コマンドは mise、Git フックは Lefthook ※1 もともと usecase 層を置いていなかったのは、依存の⽅向さえ⼀⽅向なら過度なレイヤー分けは不要と判断していたため（KISS‧YAGNI）。 当時は AI を使っておらず、肥⼤化してから分ければよいと考えていた 10
10. Post AI時代のリファクタリング実践記 最初にやったのは、5分類での Design Doc づくり 各領域ごとに整理して、計69件の Design Doc を書いた Backend Frontend Context Engineering Workflows Infra 17件 18件 12件 17件 5件 ① Design Doc を書く ② Issue に移す ③ 優先順位をつけて割り振る 分類ごとの担当者が、やりたいこ 合意した Design Doc から、対応す Issue に優先順位をつけ、担当者を とを洗い出し、決めたフォーマッ るものを GitHub Issue に移して 割り振っていった トに沿って AI と起票した いった 11
11. Post AI時代のリファクタリング実践記 実装は、AIによるリファクタリングとコンテキスト整備を同時に進めた 割り振った Issue を、この流れで進めていった ① 先にチェックを固める テストとスキル‧ルールで、 同時に進めた ④ 構造を機械で守る ③ コンテキストエンジ ニアリング dependency-cruiser や 中⾝を変えても、振る舞いが変 ② AIによるリファクタ リング わらないことを保証 usecase 層の追加などレ ディレクトリ 構造を崩させない イヤーを組み直す CLAUDE.md‧rules‧ス go-arch-lint などをCIで回し、 キルを置く 12
12. 具体例：Backend の APIシナリオテスト エンジニア1⼈が約2週間で、40,000⾏のテストを作り直した 課題： APIシナリオテストはあったが、⼀部が⽋けていたり、作り⽅が揺れていたりした 40,000行超 100ファイル以上（1ファイル＝1API） 約2週間 作り直しにかかった期間 1人 API ごとに、このサイクルを回した 1．⼈が決める 2．AI に任せる 3．スキルに残す 何を確かめるか（テスト 書く‧実⾏する‧直す。 AI の間違いを、次に同じ ケース）を洗い出し、承 API 単位でサブエージェン 間違いをしない形で残す 認する トに分担 次の API へ。また「1．⼈が決める」に戻る 最後までやりきったエンジニアの数 この期間に、テスト作成のスキルが複数⽣まれ、今も⽇常的に使っている 詳しくはチームのブログで：kaminashi-developer.hatenablog.jp/entry/claude-code-api-test-skills 13
13. 具体例：Frontend のテスト戦略 Frontend テストの配分をひっくり返した 課題： APIをモックするテストが⼀番厚く、E2Eとほぼ同じことを確かめていた 以前（E2Eを書くコストが⾼かった頃） いま（AIでE2Eを書けるようになってから） E2E：⼀部の画⾯だけ E2E（Playwright） 画⾯の主要フロー、バリデーション、未ログイン時のリダイレクト インテグレーション インテグレーション：なし ページを描画し、APIをモックして確かめる ユニット（Vitest） ユニット：関数単位 コンポーネントから Hooks‧純粋関数へ切り出して網羅 中間が⼀番厚い E2Eが⼀番厚い 詳しくはチームのブログで：kaminashi-developer.hatenablog.jp/entry/2026/06/30/frontend-testing 14
14. Post AI時代のリファクタリング実践記 結果 計画していた課題は全て完了し、当初の⽬的も達成。開発スピードと質が向上した。 中⾝は、リファクタリングというより、 ほぼリプレイスのレベルで変わった 残っていた宿題 ⽬的① 開発ルールの再設計 ⽬的② ⽣成AIのオンボーディング 全部完了 構造がそろった AIが前提になった Pre AI 時代に2回⾒送った レイヤー構成と命名をそろえ、 コンテキスト‧ハーネスと usecase 層‧DI‧テスト拡充 依存の逸脱は CI で検知 ⾃動PRレビューを整備 15
15. まとめ 16
16. まとめ コンテキストとハーネスは、構造を組み直すときが作りやすい リファクタリングしながらドッグフーディングできるので、投資対効果が⾼い LLM（F）に渡すコンテキスト（X）を最適化して、テストで検証された結果（Y）の質を⾼め、その妥当性を機械的に判断できるようにする Y = F(X) 同じコンテキストやプロンプトを渡しても、AIの出⼒は揺らぐ。 だから、LLM（F）だけに頼らない X を整える Y を機械的に確かめる Y を次の X にする AIが間違えにくくなる 間違いをすぐ⾒つける 増幅する⽅向を間違えない CLAUDE.md‧rules‧スキル 静的解析‧APIシナリオテスト コンテキスト / ハーネスを、 E2E‧単体テスト AIの間違いから⾒直し続ける 枠組みの出典：松本淳太郎‧サカモト『プロフェッショナルAI駆動開発』（技術評論社、2026） 17
17. まとめ 今⽇伝えたかった2つと、その先にあるもの ① 計画するとき AIで実⾏が速くなった分、 ⼤規模なリファクタリングも、挑戦的に計画できるようになった ② 進めるとき リファクタリング作業そのものが、 コンテキストとハーネスを育てる⼟壌になる だから、Post AI時代のリファクタリングは、変更容易性を上げるだけでなく、 チーム単位でAIドリブンな開発スタイルへのシフトを促す 18
18. 株式会社カミナシ https://kaminashi.jp