作り直せるコードは迅速に 作り直せないDBは慎重に - AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話

Product Engineering Conference 2026 での登壇資料です。

Transcript

1. 作り直せるコードは迅速に 作り直せないDBは慎重に AI時代のプロダクトエンジニアが「判断の不可逆性」で開発速度を変える話 ⻄⽥貴之 (@kinosuke01) / GMOペパボ Product Engineering Conference 2026 1
2. ⾃⼰紹介 ロリポップ‧ムームードメイン事業部 ⻄⽥ 貴之 Takayuki Nishida 2020年 中途⼊社 • エンジニアリングリード • Webホスティング、ドメイン登録サービス、 ホームページ作成サービス、新規事業開発を担当 • 担当サービスを育てながら、⼈もAIも⼒を発揮 できる開発のしくみづくりに取り組んでいる • X : @kinosuke01 2
3. 今⽇話すサービス ロリポップ！ AIホームページ（旧：AIサイトエージェント） • Webサイト制作サービス • AIがヒアリング → 構成‧テーマ‧コンテンツを⼀括⽣成 → サイト公開 • ⽣成後も「トップのキャッチを変えて」など伝えれば、AIが編集を代⾏ • 2026年 リリース。現在サービスを育てているフェーズ。 3
4. 今⽇話すサービス ロリポップ！ レンタルサーバー、ゲームサーバー、VPN、AIネイティブなインフラ環境などを展開 4
5. アジェンダ 1. 判断の不可逆性 2. 可逆な領域 3. 不可逆な領域 4. 判断の不可逆性をリリースフローに組み込む 5
6. 1. 判断の不可逆性 6
7. １．判断の不可逆性 Amazon社 2015年度 株主への⼿紙（ジェフ‧ベゾス⽒） ⼀⽅通⾏のドア / Type 1 decision (=不可逆) 重⼤で後戻りができない意思決定。熟考と協議を重ねて体系的に決めるべき。 ⼆⽅通⾏のドア / Type 2 decision (=可逆) 変更が可能な意思決定。個⼈や少⼈数で迅速に下されるべき。 https://www.sec.gov/Archives/edgar/data/1018724/000119312516530910/d168744dex991.htm 7
8. １．判断の不可逆性 サービス開発での判断も、可逆と不可逆の2つに仕分ける 可逆な判断 不可逆な判断 例 UIの⽂⾔、画⾯遷移、 アルゴリズム、実装⽅式 DBスキーマ、外部公開API、 課⾦の状態遷移、ID体系 間違えたら 直せばいい 既存データの移⾏が必要 外部利⽤者の追従が必要 等 コスト やり直しコスト ≒ 実装コスト やり直しコスト >> 実装コスト AI時代の変化 実装コストが下がる ＝ ⼤きく効率化 実装以外のコストが⽀配的 ＝ 効率化が限定的 8
9. １．判断の不可逆性 可逆か不可逆か判断して、進め⽅を変える 可逆か不可逆の判断軸 • データ構造を変更したいとき、現実的にマイグレーションが可能か • 変更したいときに、他チームやユーザーへの調整が不要か • 取り消しできない事実が発⽣しないか（課⾦、インシデントなど） → ひとつでも No がついたら、不可逆。 可逆な領域：分析も実装も⾼速に回して、策を打つ 不可逆な領域：観測した事実から未来を⾒通して、策を打つ 9
10. 2. 可逆な領域 ファネル分析と仮説検証 10
11. ２．可逆な領域 エンジニア1名で、ユーザーの躓きを⾒つけて改善したい [お申込み] → [ヒアリング] → [サイト⽣成] → [エディタで調整] → [公開] → [ご契約] Q. ユーザーはどこで⼿が⽌まってしまうのか？ 11
12. ２．可逆な領域 集計分析を可能にする準備 Claude Code と データソースの接続 • 本番DBの分析⽤リードレプリカ + Metabase MCP サーバー • • ウェブサイトのデータがどこまでできたか Datadog MCP サーバー • どのページまでアクセスしたか 集計分析 • Claude Code に専⽤スキルを作成 (Skill Creator Pluginで作成) データへの接続さえ確⽴できれば、Claude Code で分析できる 12
13. ２．可逆な領域 ファネル分析：ユーザーの躓きは「ヒアリング」 ※ グラフの⼤きさはイメージです 申込 ヒアリング開始 サイト⽣成 ★ ここで最も⼤きく落ちる 編集開始 公開 ご契約 ヒアリングのページには多くの⽅がたどり着いているが、 ヒアリングフェーズを完了せずに抜けている⽅が多い。 13
14. ２．可逆な領域 仮説：チャット形式のヒアリングは⼿間なのでは？ 当時のヒアリングはチャットUIだった。 • 何をどう書けばいいか分からない • 打つのが⼿間（スマホだと特に） • 問い返しが続いて完了が⾒えない 選択肢から選ぶウィザードUIなら、 ⼿が動くのでは？ 14
15. ２．可逆な領域 判断軸と⾒合わせる • データ構造を変更したいとき、現実的にマイグレーションが可能か • 変更したいときに、他チームやユーザーへの調整が不要か • 取り消しできない事実が発⽣しないか（課⾦、インシデントなど） リリース間もないサービス。仮に失敗(通過率が悪化)しても戻せばいい。 → ウィザードUIを当⽇実装。当⽇リリース。A/Bテストで確かめる。
16. ２．可逆な領域 結果：チャットUIとウィザードUIでは統計的な有意差なし • 意外な結果ではあった • 最終的には、社内利⽤者のフィードバックを踏まえてウィザードUIにした • とはいえ、観測 → 仮説 → 実装 → 検定を、 AIを駆使してエンジニア1⼈で迅速にまわすことができた AIとデータを接続して、高速に仮説検証 16
17. 3. 不可逆な領域 先を⾒通したデータモデル 17
18. ３．不可逆な領域 ⽤語の整理：データモデル 層 決めること 概念データモデル 何が登場し、どう関係するか ユビキタス⾔語の定義と、その関係を明確にしたもの 論理データモデル 属性‧キー‧正規化 物理データモデル テーブル定義‧型‧インデックス データモデル：上記の3段階を包括したものとして話を進めたい。 18
19. ３．不可逆な領域 まずは、YAGNI原則について You Aren't Gonna Need It = 必要になるまで作らない 将来必要になるかもしれないものを、先回りして作らない。 • 「必要になるかも」の予測は、だいたい外れる。 • 使われないコードは、そのまま保守コストになる。ずっと。 • 要件は変わる。先に作ったものは、変わったときに邪魔になる。 → たしかに、それはそう。 19
20. ３．不可逆な領域 YAGNI原則は、不可逆な領域でも有効か？ 必ずしも有効とは⾔えない • YAGNIの前提：「必要になったときに作る」が容易。 • 変更発⽣時のコストが⾮対称に⼤きい場合に限り、 変更しやすい設計を最初から埋め込んでおくことが有効ではないか。 YAGNI原則を緩め、先を⾒通すポイント • 変更のコストが⼤きいか（実質変更できなくなるか） • 将来実装する可能性が⾼い機能か 20
21. ３．不可逆な領域 変更のコストが⼤きいところは？ 多数の依存が発⽣しうるエンティティ #例 User ├─ LoginService • Gravitating to rigidity: Patterns of schema evolution ‒ and its absence ‒ in the lives of tables での⾔及。 • 多数の依存が発⽣するエンティティは 変更するコストが⾼すぎて変更できない。 ├─ AccountService ├─ BillingService ├─ Analytics ├─ Admin └─ Reporting ... https://www.sciencedirect.com/science/article/abs/pii/S030643791630120X 21
22. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ マーケティングの概念で考えてみる • • Point of Parity（POP）： • 競合と同等であるべき要素「最低限これがないと選択肢に⼊らない」 • ≒ 必須機能 Point of Difference（POD）： • 競合と明確に違い、選ばれる理由になる要素 • ≒ 差別化機能 22
23. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 必須機能(POP)と差別化機能(POD)を⾒つける A社 B社 C社 D社 機能 α • • • • 必須機能(POP)候補 機能 β • • • • 必須機能(POP)候補 機能 γ • • • ✖ 必須機能(POP)に近い 機能 Δ ✖ • ✖ ✖ B社の差別化機能(POD)候補 ※ 本来はユーザーリサーチ等のデータも含めて総合的に判断 23
24. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 必須機能(POP) • 最低限これがないと、選択肢に⼊らない機能なので、 将来ではなく、いま設計して実装する • ロリポップ！AIホームページの例 • 独⾃ドメイン設定 • アクセス解析 • お問い合わせフォーム など 24
25. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 必須機能(POP)に近い機能 • 必須機能(POP)に変化していくものと考えられる。 • 企業は模倣し合うバイアスがあるため。 • Why Do Firms Imitate Each Other? → 模倣されやすい条件について⾔及。 • いずれ実装が必要になる可能性が⾼い。 • 実装時の変更コストが⾮対称に⼤きい場合に限り、 変更しやすい設計を最初から埋め込んでおくことが有効。 https://www.anderson.ucla.edu/faculty_pages/marvin.lieberman/docs/Why_Do_Firms_Imitate-AMR2 006.pdf 25
26. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 必須機能(POP)に近い機能 - AIホームページの例 • ドラフトファースト • 公開済みコンテンツを編集したら、その内容は⾮公開状態として保存され、明 ⽰的に公開操作するまで本番を上書きしない。 • ⾃動保存機能 • ドラフトファーストを前提に、明⽰的に保存操作しなくても、 コンテンツ編集したら⾮公開状態として保存する。 • 履歴から復元 • ⾮公開状態として保存した過去の履歴からサイトを復元ができる。 26
27. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 必須機能(POP)に近い機能 - AIホームページの例 • ウェブサイトという中核のエンティティ。多数の依存が発⽣しうる。 • ドラフトファースト / ⾃動保存機能 / 履歴から復元 を実装する前提で データモデリングした。 • ドラフトファースト機能に関しては、実際に実装した。 27
28. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 必須機能(POP)に近い機能 - AIホームページの例 28
29. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 差別化機能(POD)のデータモデル • 不確実性が⾼く、仮説検証で⾒出していく。 • 狙った指標を改善する変更は10〜20%程度しかない。 • A/Bテストの話。Online Experimentation: Benefits, Operational and Methodological Challenges, and Scaling Guide での⾔及。 • 先を⾒通すことが困難なので、YAGNI原則に従う。 https://hdsr.mitpress.mit.edu/pub/aj31wj81/release/1 29
30. ３．不可逆な領域 将来実装する可能性が⾼い機能か？ 種別 将来の実装可能性 備考 必須機能(POP) - ないと選ばれない 最初からデータモデリングも実装もする 必須機能(POP)に近い ⾼ 模倣バイアスで必須機能になりうる 実装しやすいように、 データモデリングしておく 差別化機能(POD) 低 不確実性が高い YAGNI原則に従う 30
31. ３．不可逆な領域 データモデリングで先を⾒通す まとめ • 基本的にYAGNI原則に従う。 • 例外的に、実装可能性が⾼い機能に紐づき、変更発⽣時のコストが⾮対称に⼤きい 場合に限り、実装が容易なデータモデルを最初から埋め込んでおくことが有効。 • 実装可能性が⾼い機能： • • 必須機能(POP)に近いもの。 変更発⽣時のコストが⾮対称に⼤きいもの： • 多数の依存が発⽣しうるエンティティ 31
32. 4. 判断の不可逆性を リリースフローに組み込む AIレビュー + オートマージ 32
33. ４．判断の不可逆性をリリースフローに組み込む まずは、可逆な領域の進め⽅をアップデート 変更が可能な意思決定。個⼈や少⼈数で迅速に下されるべき。 ↓ 個⼈や少⼈数がAIを駆使して迅速に意思決定。 ↓ ⼈は介在せず、AIが⾃律的に迅速に意思決定。 33
34. ４．判断の不可逆性をリリースフローに組み込む 可逆 / 不可逆の観点を、リリースフローに組み込む • • 可逆な領域： ◦ ⼈は介在せず、AIが⾃律的に迅速に意思決定。 ◦ → Claude Code Action にレビューさせ、approve されれば⾃動マージ。 不可逆な領域： ◦ 熟考と協議を重ねて体系的に決める。 ◦ → ⼈間レビューを必須。 ※ 前提として、CIによる lint‧test のチェックは全PRで通している。 34
35. ４．判断の不可逆性をリリースフローに組み込む リリースフローの事例の紹介 可逆なもの PR feature ▶ release PR ▶ develop AIがレビュー‧承認して オートマージ main 複数のfeatureを ⼈間が確認してマージ ▶ 本番環境 GitHub Actionsで 本番デプロイ 不可逆なもの（従来と同じ） feature ▶ ⼈間がレビューして マージ main ▶ 本番環境 GitHub Actionsで 本番デプロイ ※ 従来のリリースフローは維持したまま、拡張的な構成とした。 35
36. ４．判断の不可逆性をリリースフローに組み込む 可逆/不可逆の区別は、ファイルパスで判断 Claude Code にコンテキストを与えて判断させている 簡略化したコンテキスト PRは、別途指⽰がない限り、baseをdevelopブランチとして作成する。 例外：以下のリスクパスを含むPRの場合は、baseをmainとする。 - path/to リスクパスの例 なぜ不可逆か terraform/ k8s/ 壊すとインシデントにつながる prisma/ db/ データの消失リスク 現実的にマイグレーションが不可能になるリスク 36
37. ４．判断の不可逆性をリリースフローに組み込む 可逆のフロー (1) 1. developをbaseとしたPRが作られる。 2. 上記をトリガーとして、レビュー⽤のカスタムアクションを実⾏。 ◦ リスクパスが含まれている場合は、⼈間レビューをリクエスト。 ◦ そうでない場合は、Claude Code Actions (CCA) がレビューを実施。 ▪ CCAを呼び出し時に、レビュー観点をコンテキストとして与える。 3. レビュー結果がOKであれば、CCA が approve。 4. approve をトリガーに、カスタムアクションがdevelopブランチへマージ。 37
38. ４．判断の不可逆性をリリースフローに組み込む 可逆のフロー (1’) CCAに与えているレビュー観点 • FrontierCodeを拡張して作成。 • FrontierCodeとは、Cognition社が公開した 「AI製のPRをOSSメンテナがマージしたいと思うか？」を測るベンチマーク。 既存機能を壊していないか、テストが適切か等の複数の観点で評価する。 38
39. ４．判断の不可逆性をリリースフローに組み込む 可逆のフロー (2) 1. developに複数のPRがマージされる。 2. developブランチ作成や更新をトリガーに、 Github Actionsが develop->main 宛のPRを作成。 3. ⼈間が任意のタイミングでPRを確認してマージ(=リリース)。 39
40. ４．判断の不可逆性をリリースフローに組み込む どう推進したか：デフォルトをAIレビュー/オートマージとした • • デフォルトをAIレビュー/AIオートマージにした。 ◦ “PRは、別途指⽰がない限り、baseをdevelopブランチとして作成する” ◦ デフォルトを⼈間レビューにしたままだと、推進されない。 それで困る部分が出てきたら、困らない仕組み作りをする。 ◦ 機械的に良し悪しを判定 / レビュー観点の更新 / リスクパスの変更 など → 2026年8⽉のAI⾃律マージ率：おおむね 60％ (AIホームページ) 40
41. まとめ 41
42. まとめ 1. 判断の不可逆性 • 可逆か不可逆か判断し、進め⽅を変える。 2. 可逆な領域 • AIとデータを接続して、⾼速に仮説検証。 3. 不可逆な領域 • 先を⾒通したデータモデリングの考え⽅。 4. 判断の不可逆性をリリースフローに組み込む • 可逆な領域でAIレビュー/オートマージする事例。 ご清聴ありがとうございました！！ 42