ふつうのFeature Flag実践入門

JJUG CCC 2026 Spring 2026-05-30
https://ccc2026spring.java-users.jp/

Transcript

1. ふつうのFeature Flag実践入門 JJUG CCC 2026 Spring @irof
2. 自己紹介 • irof （いろふ） • ふつうのプログラマ • 個人事業主、技術顧問業 • 大阪在住、関西Javaエンジニアの会運営 • TDD, DDD, CI/CD, アジャイル, モデリング
3. 本セッションの趣旨 • ありふれた悩み ◦ リリース時期が未定なfeatureブランチの取り扱い ◦ デプロイは影響の少ない深夜などに行う ◦ リリース障害の対応が不安定で綱渡り これらに使えるかもしれない道具や考え方を紹介します。 唯一絶対の万能解を示すものではありません。
4. 対象者 Javaアプリケーション開発経験があり、Feature Flagとの関わり 方として以下のいずれかに当てはまる人 • Feature Flagを知らない人 • 使ったことがある人 • なんとなく使っている人 • 活用していくヒントを探している人 みんなじゃん？
5. 今日の流れ 1. Feature Flagの目的と期待 2. Feature Flagの基本 3. 実装例 4. リリースと運用と落とし穴 5. まとめ
6. Feature Flagの目的と期待
7. Feature Flagとは
8. なにもの？ • コードを変更せず動作を変更する仕組み • Feature Flag、フィーチャーフラグ ◦ たまにフューチャーフラグと言われたり ◦ 未来向いてて良いと思う • フラグと言ったりトグルと言ったりする ◦ 同じものだけど区別する派閥もある • 再ビルドや再デプロイをしないのが基本 ◦ デプロイとリリースを切り離すのに使う
9. 何が嬉しいの？ • リリースが「フラグを切り替える」だけになる • リリースしないコードをマージできるようにする • フラグを活用してリリースの選択肢を仕込める ◦ 段階的ロールアウト ◦ A/Bテスト ◦ 緊急停止 ◦ ...
10. なぜいまこの話をするの？ • さまざまな技術の進歩で開発速度が上がりつづけている • 開発速度が上がるとデプロイやリリースも早く回したくなる • しかし、マージとデプロイとリリースが密結合な状態で高速回 転させるのは難しい • 特にリリースは軽量に即座に安全に行いたい • リリースに対する要求にFeature Flagが応えられる
11. 参考: デプロイ/リリース分離パターン例
12. Feature Flagに対する期待 役割によって期待値は違うものです
13. ここで扱う役割 いろんな役割がありますが、本セッションでは「ビジネス」と「エン ジニア」と置きます。 対立を助長する意図はありません。
14. ビジネスの期待 • リリースするかしないかのハンドルを握りたい • リリースにエンジニアの都合を考慮したくない • リリース後に何かあったらすぐ前の状態に戻したい • ユーザーの反応を見ながら学びたい（少し応用）
15. エンジニアの期待 • 長命ブランチの面倒を見るのに疲れた • コンフリクト解消にかかる労力を減らしたい • リリースを待たずにマージしたい • 深夜や休日などにリリース作業を行いたくない • デプロイから不確実性を減らしたい
16. 誰に何が嬉しいか
17. 主に嬉しいのはビジネス側 • ビジネスがリリースのハンドルを握れる価値は大きい ◦ （エンジニアに結構気を遣っているものでして……） • エンジニアの嬉しさは、それを支える手段
18. それに対するエンジニアの役割 • ビジネスを支える技術を提供するのがエンジニアの役割 • エンジニアが技術を持ち込んで現場に適用する ◦ 「これできるって聞いたよ」とか言われるとイラっとするよ ね ◦ いまだと「こんなのAIでやれるんでしょ？」とか…… • そもそもリリースの重量化は技術的な理由だったりする ◦ 年月や世間によって常識として扱われたりするけど ◦ 諦められてるのってなんか嫌じゃない？
19. Feature Flagの基本
20. 動作原理
21. 動作原理 • フラグを評価し、結果を受けて処理を分岐する • フラグはハードコードしない ◦ ハードコードしたら変更時に再ビルドとデプロイが必要に なる これだけ。とてもシンプル。
22. ぶっちゃけ、ただの分岐
23. 評価タイミング • なし（マージ時） ◦ 変更したコードをマージしたら変わる • ビルド時 ◦ ビルド時に評価する • 起動時 ◦ 起動時に一度だけ評価する • 実行時 ◦ 処理が実行されるたびにフラグを評価する
24. 評価タイミングとフェーズの関係
25. 評価タイミングとFeature Flag • 実行時評価がいわゆるFeature Flag • 起動時に一度評価するものは再起動が必要になる ◦ そのためFeature Flagに含まないことが多い ◦ けど本セッションではFeature Flagの枠で扱います • マージ時はフラグ関係ないので違う • ビルド時はめちゃ広げればだけど、流石にFeature Flagとは 違うなーって。おもった。
26. 考えること シンプルなものほど、考えることは多いもので
27. Feature Flagのテーマ • 何を目的とするか • フラグをいつ評価するか • フラグをどう判定するか • フラグをどのように管理するか • 切り替え対象の処理をどう設計するか
28. 何を目的とするか • Feature Flag全体に対する目的や期待は前述の通り • その上で、導入しようとしている特定のフラグの目的を考える • 「汎用的で何にでも使えるもの」は往々にして使いづらかった り限界があったりする • 眼前にあるシステムに合いそうなものを考えます
29. フラグをいつ評価するか • 先にあげた「評価タイミング」を選択する • システムの性質を業務面と実装面で把握して考える ◦ すでに採用している実装技術との兼ね合いもある • 実行時評価は柔軟だが、唯一絶対の解ではない ◦ たとえばパフォーマンスの問題
30. フラグをどう判定するか • true / false の値だけなら単に if で分岐すればOK • 三値以上持たせることも可能 ◦ フラグって名前やめろ • 設定値以外（たとえばユーザーのロールなど）による分岐も 可能 • どういう判定をしたいかを目的と照らして考えます • Feature Flagライブラリはここにフォーカスしている • これも「柔軟な方がいい」ものでもない
31. フラグをどのように管理するか • フラグの管理場所とかを考えます ◦ 内包するか、外部に置くか、とか。 • システムの作りや評価タイミング、判定方法により管理の条 件が決まってくる ◦ たとえば実行時判定なら実行環境から参照できる必要が ある
32. 切り替え対象の処理をどう設計するか • 単に if で囲めばいいだけ？ • 切り替え後が if で前が else ？ • 切り替えの実現手段や撤去も踏まえて考えていく
33. 補足: 柔軟性という毒 • 柔軟なのはいいこと ◦ とは限らない ◦ 柔軟性は不安定さにつながる ◦ （Java言語使いなら伝わる？） • 下手な柔軟性は期待に逆行する • Feature Flagは安定して動いて欲しい • 「Feature Flagのせいでトラブりました」←つらい ◦ こういうのが起こりづらい設計をしたい
34. 用途による種類の整理 認知度の高い話を押さえておく
35. 種類の例
36. ここで挙げられているもの • Release Toggles: リリースフラグ • Experiment Toggles: 実験フラグ • Ops Toggles: 運用フラグ • Permission Toggles: 権限フラグ 出典: https://martinfowler.com/articles/feature-toggles.html 本セッションでは紹介に留めます。
37. 注意: 「ぜんぶで4種類」ではない • 前図はlongevity × dynamism の2軸で整理したもの ◦ とうぜん、他の軸もありえる • 境界は曲線かつ破線 ◦ 厳密な区切りではない、という意図的な表現 ◦ たぶん。知らんけど。 • 2軸は四象限図にしがちだが、四象限で描いてしまうと「4つ ですべて」に見えるミスリードにつながる
38. 注意: 「これらに対応すればいい」ではない • カテゴライズは対象を理解するための切り口 • 「4種類に対応できるようにしよう！」は落とし穴 • いきなり全部はしくみも運用も半端になる • 仕組みは負債になりやすい ◦ 必要なところに必要なだけ持ち込む
39. 「よく知られたモデル」の使い方 • 下敷きにしつつ、コンテキストに合わせて調整する • そのまま適用しようとするとぎこちなくなりがち ◦ たとえばデザインパターンとか • とはいえ使わないのは勿体無い • 先に挙げた「考えること」と合わせるとか有効
40. 参考: モデリングのきほん
41. 導入前のポイント
42. ON/OFFの認識を揃える • ON=新処理、OFF=既存処理 とか • フラグは「どっちがONだっけ？」の混乱が生じがち ◦ Feature Flagに限った話ではない
43. 導入時はデフォルトOFF • 「ONにする」を意識的にやるのが良い • 切り替えを分離できているかを実践で検証できる機会 • デフォルトONのまま一度も切り替えられないフラグがたまに ある ◦ それはFeature Flagではないかも
44. 命名規則を考える • 複数のフラグを同時に見ると規則がほしくなる • 厳密さはシステムやチームなどコンテキスト依存 • 例としては「目的が分かる動詞+名詞」など ◦ 例: enable-checkout-v2 ◦ enable とかはノイズな場合もある • 期限付きの場合は日付を入れるとか
45. 向き不向きもある • Feature Flagはいつでも有効なものでもない ◦ むしろ使用しなくて済むときは避けた方がいい ◦ 必要悪に近い存在 • メリットが上回る時だけ採用するのが本筋 ◦ 一方でいきなりうまく使えるものでもない ◦ チームで運用するものなのでチーム力が必要
46. Feature Flagが向かないもの • 恒久的に残りそうな分岐 ◦ 汎用的な仕組みではなく特化した設計が合う ◦ OpsやPermissionをどう捉えるかは検討課題 • 強い整合性が必要な複数システムの同時切り替え ◦ Feature Flagの工夫で乗り越えるのは至難の業 ◦ 後ほど解決案を紹介します • セキュリティ境界や権限制御の中核 ◦ 汎用的な仕組みでなく（以下略 • その他なにかしらの代替としての濫用
47. いい塩梅で使おう • 対象を理解し、技術も理解し ◦ 必要な時に、必要なだけ。 • できたら苦労しない • 適切に使い分けるには知識と経験が要る ◦ 経験を積まないと分からない難しさも多い • やらないことはうまくならない ◦ やれるところから少しずつやっていこう ◦ 無理じゃない範囲で強引に使うのも一考
48. 実装例 4段階の成長モデル（一例）
49. 1st: PureJava 最小実装例
50. ただのif文
51. 1st: コメント • ここではフラグもハードコード • 抽象ブランチをFeature Flagと組み合わせる第一歩 • マージやコンフリクトの「時間を置いたら増していくリスク」は 回避できる • 「ここに分岐が増える」を評価する
52. 導入: 長命ブランチをFeature Flagで扱う • 長命ブランチを抽象ブランチとして取り込む • 抽象ブランチの切り替えにFeature Flagを使用する ◦ ドッグフーディングなど限定公開パターンを使う
53. 参考: 抽象ブランチとは • 変更を安全にmainブランチへ統合し続けるための手法 • コンフリクトやマージに伴うリスクを軽減する • 既存コードと新コードの間に抽象レイヤーを挟むなどし、両 者を共存させる • 万能解ではなく、以下の問題を持ち込む。 ◦ 同じ目的のコードが重複する ▪ 静的解析に警告されることも ◦ 変更が差分にならずdiffでレビューできない
54. 2nd: Spring Bootの基本機能
55. やること application.yml 等のプロパティファイルでフラグ値を管理 し、Environment や @Value、 @ConditionalOnProperty で参照する。 これにより2つの切り替えが実現できる。 1. 起動時にコンポーネントを差し換える 2. 実行時にフラグを参照して分岐する ただしどちらも変更は再起動が必要
56. 1. 起動時にコンポーネントを差し換える • @ConditionalOnProperty などを使い、フラグによって DIするコンポーネントを切り替える。 • @Profile はこれの特化実装
57. コンポーネント切り替えの実装例
58. 2. 実行時にフラグを参照して分岐する • 設定クラス（@ConfigurationProperties）などを通して フラグを参照できるようにする • 分岐側は設定されたインスタンスに問い合わせる • この実装だとフラグは起動時に決まるが、分岐側は「起動時 に決まっている」から分離される
59. フラグ参照の実装例
60. 2nd: コメント • フラグの管理はSpring Bootプロパティの管理に従う • 動的な変更への対応は難しい ◦ 再起動が必要 ◦ 変更は環境変数や起動時引数などを触る ◦ そのためデプロイとリリースが分離されない • フラグ値以外での判定は未解決 ◦ やるとしたら独自ロジック
61. 3rd: 2nd + OpenFeature
62. 構造
63. OpenFeatureとは • Feature Flag操作の標準仕様（CNCFプロジェクト） • フラグ管理サービスのベンダーロックインを避け、共通のイン ターフェースで操作可能 • 様々な言語のSDKがある ◦ Java SDKはもちろんある ◦ Spring Bootでの使用がドキュメントにある
64. 導入ステップ 1. 依存関係の追加（OpenFeature SDK + Provider） 2. プロバイダーの設定（Bean定義） 3. コード内での評価
65. 1. 依存関係の追加
66. 2. プロバイダーの設定
67. 3. コード内での利用
68. 3rd: コメント • 車輪の再発明でなくできた車輪を借りてこよう • Java以外でも使うならOpenFeatureは有力 ◦ SDKが利用可能なことが条件 • Providerの公開実装があれば楽できるかもだけど、なくても 結構簡単に作れる • Provider差し替えやフラグ以外の条件での評価と言った車輪 が実装されているので再発明を避けられる • 本番で使用するなら何をBean定義するかとかちゃんと設計し よう
69. 4th: 3rd + Wrapper
70. 構造のイメージ
71. OpenFeatureの直接使用を避けたい理由 • フラグキー（文字列）のハードコーディング ◦ typoのリスクがある ◦ 一覧化が別途必要になってくる ◦ 使用箇所を探すのがgrep • EvaluationContext の構築がノイジー ◦ 本来やりたい仕事ではない ◦ 分岐もそれなりにノイズなのに、より酷くなる • プロダクトコードの外部依存を局所化したい
72. 変更案: enum + ラッパー • フラグをenumで一元管理する • SDKを隠蔽するラッパーを作成する
73. 1. フラグを一元管理するenum
74. 2-1. SDKを隠蔽するラッパー
75. 2-2. 高レベルAPIの追加（オプション）
76. 3. Serviceでの利用
77. 4th: コメント • 独自レイヤーをOpenFeatureのような独立性を意識したコン ポーネントにさらに被せるのは微妙と感じる気持ちもわから なくはなくはなく……
78. 4段階のまとめ • プロダクトやチームのコンテキストにあったやり方を選択しよ う • この一本道でもない ◦ FeatureGate的なのを導入してからOpenFeatureを導入す るとかも有力 • 私は技術スタックを積むのには慎重派 ◦ 積む時も外しやすく設計する ◦ なので3rdは採用するにしても限定的
79. Feature Flagとテスト
80. テストの考え方 1/2 • 分岐網羅はしておきたい ◦ どちらも本番で動作するコード ◦ 呼ばれないコードは壊れても気づけない • テストの重複は許容する ◦ むしろ自然なこと • 廃止予定の処理も最後までテストを維持する ◦ 切り替え後も切り戻し先として現役
81. テストの考え方 2/2 • 組み合わせ網羅はこだわらない ◦ フラグが増えると指数で増えるが、運用される組み合わ せは限定的なはず ◦ フラグは直交するように設計する • 使わないフラグは積極的に削除 ◦ テストごと消せて負債が減る
82. テストでのフラグ制御 • 実装方法ごとにテストでの制御方法を確立しておく ◦ プロパティなら @TestPropertySource とか ◦ OpenFeatureはClient／Providerのどこをどのフェーズで テストするかとか ◦ デプロイして本番での切り替え方法も検証しておく • テストしやすさも実装方法の選択材料にする
83. 設計Tips
84. フラグどうしを依存させない • フラグ同士の依存は複雑化の原因 ◦ ぶっちゃけ制御不能 • どうしても必要なら設計を明示 ◦ 組み合わせた単一のフラグに置き換えた方が良いことも
85. 判定を局所化する • フラグ判定をコード内に分散させない • 入口で分岐し、内部を単純に • 1トランザクションでフラグは1度だけ評価する ◦ 途中で変わる前提にすると難度が跳ね上がる ◦ 外部プロバイダ評価はコストもある ▪ ループ内で繰り返し引かない
86. NG例: 同じフラグの複数回参照
87. NGの理由 • Feature Flagに限った話でもない ◦ パスが4つあるのがつらい • Feature Flagの実装によっては異なる結果になることも当然 ある • 1リクエスト内で変わってしまうと再現しにくい不具合になる ◦ これが期待する動作であることはまずない
88. 判定箇所と判定ロジックを分離する • 呼び出し側は「ONか？」を問い合わせるだけ • if (date > X && user.isBeta()) のような判定ロ ジックを散らばらせない • 判定ロジックは1箇所（ラッパー/ルーター）に集約する • 高レベルAPIの実装箇所を用意しておくのが FeatureGate の狙いの一つ
89. リリースと運用と落とし穴
90. リリースと運用
91. 並行稼働 • 処理を切り替えるフラグではなく、追加処理を有効化するフラ グとして導入 • ONにすると新しい処理 も 実行される ◦ 今までの処理も実行される • 結果の突き合わせなどを通して検証し、実績を持って切り替 える
92. 参考: 並行稼働のじっくりステップ • 現行処理のみ（新処理は動かない） • 並行（現行結果を採用） • 並行（新結果を採用） • 新処理のみ（現行処理は動かないが切り戻し可能） • フラグ廃止
93. ロールアウト戦略 • 現行処理と新処理をFeature Flagで切り替える場合に取りう る選択 • すこしずつ対象を増やして影響を見る • パフォーマンス対応を本番で低リスクに検証するなどの時に 採用する
94. Kill Switch • すぐにOFFにできる状態にしてリリースする • OFF -> ON がすぐ切り替えられるなら、ON -> OFFも 理屈 上は すぐできる • データも含めると案外難しいことも多い
95. 監視とメトリクス • フラグ導入による影響の感度を上げる ◦ エラーレートやレイテンシの変動など ◦ 実行時評価は特に重要 ◦ 影響を与えたくないなら起動時評価を採用する • フラグの変更とビジネスインパクトの関係を可視化（できたら いいな）
96. ログと監査 • フラグの変更管理 ◦ 監査ログを保持 • フラグの評価記録 ◦ ログやメトリクスを検討 ◦ 数が多くなると「使われてるっけ？」とかがしばしば起こる
97. 切り替えと切り戻しの落とし穴
98. ON/OFF混在を前提とできているか • 複数サーバー、複数リクエストは当たり前 • ON/OFF混在で動作するものである • 「ONにして以降はすべてON」と思い込まない ◦ フラグ解決後に処理が滞留しているかもしれない
99. ONにする際の注意 • 無停止リリースでは混在は常にありえる • 切り替えたときはONの処理とOFFの処理が同時に走る前提 で設計する • Feature Flagに限らず無停止デプロイならバージョン混在は 避けられない問題 • どうしても無理な場合に備えて停止も視野に入れておく ◦ 最後まで抵抗したい気持ちを持ちつつ
100. OFFにする際の注意 • 常に片道だけではなく戻しの切り替えも考慮する ◦ データ・状態の整合が崩れないことを確認する • 「ONで作ったデータがOFFでどう動くか」は検証漏れがち
101. DBマイグレーションとの兼ね合い • DBマイグレーションとFeature Flagは衝突しがち • これもFeature Flag固有の問題ではない ◦ リリースは常に切り戻しを想定すべき • Feature FlagはON/OFFが切り替わる前提 • 繰り返しになるが「ONで動くがOFFで動かない」は不可 • ずさんな移行が表面化しただけ
102. 参考: Expand/Contract での安全な移行 破壊的変更を避け、各段で両方が動く 1. Expand: 新カラム追加（後方互換） 2. 両書き: 新旧両方に書く 3. 読み先を新カラムへ切替（Feature Flagで制御） 4. Contract: 旧カラム削除（撤去とセット） 各段を個別にデプロイして切り戻せる状態を維持しながら進む
103. 分散環境の落とし穴
104. 分散環境での設計スメル • サービスを跨いで同じフラグを参照する • 切り替え時に処理中のものがどうなるか不定 ◦ 分散トランザクションに似た問題につながる • 複数のシステムが同じフラグに関心があるのは設計ミスの 気配がある
105. 跨ぐなら入口で制御する • A→Bのフローなら、フラグは上流（A）の入口でだけ評価 ◦ 下流（B）はフラグを直接参照せず、リクエストのされ方に 依存する ◦ 非同期メッセージングも同様 • 各サービスが同じフラグを参照しにいく設計にしない • 問題構造は先の1メソッド内で複数回参照と同じ
106. 下流システムの設計 • B側はフラグで処理を分けるより、エントリーポイントを分ける ◦ ストラングラーフィグパターン • どうしてもフラグが必要なら上流システムで取得したフラグを 引き継ぐ ◦ リクエストパラメタが増やせないならヘッダで渡すなど
107. フラグの撤去
108. フラグ撤去の運用 • 完了条件を決める • 期限を設定しチケットに紐付ける • 撤去タスクをリリース計画に含める • 作業を割り当て、監査ログを残す
109. 撤去を重視する • 超重要 • 導入時より撤去時の作業・リスクを最小化する設計を優先す る ◦ 「現行処理をifブロックに書いてreturnする」とか • 変更量が多いほど撤去の難度が上がる ◦ 難度が上がると事故のリスクが増える ▪ 撤去で事故を起こすと先が厳しくなる
110. 撤去しやすさ全振り例
111. まとめ
112. 話したつもりのこと • Feature Flagは、デプロイとリリースを分ける実践的な道具 ◦ とはいえ一足飛びにそこに至るのは難しい ◦ なので使いながらレベルをあげていく • 実態はただの分岐なので雑に使うとすぐ負債になる • 目的に合わせて選び、撤去まで見据えて導入する • 価値の本丸は「リリースを扱いやすくすること」 ◦ リリースのハンドルをビジネスに渡すのを目指す ◦ それを支える仕組みをあたりまえにする
113. 次のアクション
114. 初めて学ぶ人 • 前提 ◦ Feature Flag未使用、未検討 ◦ featureブランチで開発している • まず1つのfeatureブランチを抽象ブランチで統合してみる ◦ コードが統合できなければFeature Flagに至らない • マージとリリースを切り離す選択肢を持つ ◦ デプロイとリリースの分離はその先にある
115. なんとなく使っている人 • 前提 ◦ 使えてはいる • 現在の実現手段とそれでできていること／できていないこと を確認してみる • 今後できるとよさそうなことを考えてみる ◦ たとえば命名、期限、撤去などのルール作り • 問題が起こりそうな設計になっていないかを確認する
116. 活用していくヒントを探している人 • 前提 ◦ まちまち • なんかあった？ ◦ 教えて？
117. FAQ By Claude
118. Q1. 何から始めればいい？ Feature Flagを使い始めるなら何から手をつければいいです か？ まず1機能をフラグOFFのままmainブランチにマージする、いわ ゆる「抽象ブランチ」から始めるのがおすすめです。ライブラリは 後からでも導入できます。まずboolean enableNewFeature = false;のような単純なif文でいい。動かしてみて困ったことが出て きたタイミングでOpenFeatureなどを検討するので十分です。
119. Q2. 商用 vs 自前 商用サービスと自前実装はどう使い分ければよいですか？ Experiment flag（sticky bucketing）や複雑なターゲティングが必 要になった時点で商用サービスが現実的な選択肢になります。 Release flagやOps flagだけなら自前実装＋OpenFeatureで十分 なケースが多いです。最初から商用サービスを入れると「フラグ を使う習慣」より「ツールの習熟」が先になりがちなので、規模や 用途を見極めてから導入を検討するのがよいと思います。
120. Q3. テストは全組み合わせ必要？ テストはフラグのON/OFFの組み合わせすべてを書く必要があり ますか？ 全組み合わせを網羅する必要はありません。同時に運用される フラグは限られるので、実際に組み合わせて使うものだけをテス トすれば十分です。それよりも「ONとOFFそれぞれ単独でテスト が通ること」を守ることが重要です。呼ばれないコードは壊れても 気づけないので、両パスのテストを維持しましょう。
121. Q4. 撤去を習慣にするには？ フラグの撤去をチームに習慣づけるにはどうすればよいです か？ 「導入と同時に撤去チケットを切る」などプロセスに組み込むの が効果的です。完了条件や期限をフラグ作成時に決めてしま う。また定期的に（例えばスプリントレビューで）生きているフラグ 一覧を確認する習慣をチームに持たせると、放置が可視化され てフラグ墓場になりにくくなります。
122. Q5. DBマイグレーションとの兼ね合い DBマイグレーションとフラグを同時に扱う場合はどう考えればよ いですか？ マイグレーションはON/OFFどちらでも常に耐えられるスキーマ を保ちます。Feature Flagが問題を引き起こすのではなく、切り戻 しを想定していないマイグレーションが表面化するだけ。なので 切り戻しを真っ当に設計するのが根本的な対策です。DBリファク タリングのテクニックが有用です。