2026 年 5 月、InfoQ で MySQL 9.7: First Major LTS Since 8.4 Brings Enterprise Features to Community Edition が公開されました。8.4 LTS 以来となる初の Major LTS であり、これまで Enterprise Edition の有償サブスクリプション限定だった暗号化・監査・スレッドプール・パスワード強度検証が Community Edition で標準提供されることが大きな転換点です。
弊社の受託現場では、「AWS Aurora には乗せられない（オンプレ要件・コスト制約）」「でも MySQL 5.7 / 8.0 のままでは監査要件を満たせない」というご相談が中堅 SMB 企業から増えています。本記事では MySQL 9.7 LTS を活用した受託モダナイゼーションの設計指針を整理します。
なぜ「9.7 LTS」が転換点なのか
MySQL は 8.4 以降、Innovation Release（短命） と LTS Release（5 年サポート） の 2 トラックで運用されています。9.x 系の Innovation Release が 1 年以上続いた末の 9.7 LTS は、「攻めの新機能を Community で使える」という意味で、商用案件で待たれていたリリースです。
Enterprise → Community に降りてきた主要機能
| 機能 | 8.4 まで | 9.7 LTS |
|---|---|---|
| TDE（Transparent Data Encryption） | Enterprise のみ | Community で利用可 |
| Audit Log | Enterprise のみ | Community で利用可 |
| Thread Pool | Enterprise のみ | Community で利用可 |
| Password Validation Component | Enterprise のみ | Community で利用可 |
| Vector データ型 | 非搭載 | 9.x 系で正式搭載済（AI 連携に活用可） |
特に TDE と Audit Log の Community 化は、ISMS / Pマーク / SOC 2 のクライアントに 「商用 DB ライセンス料を払わずに監査要件を満たす」 道を開きました。これは SCS セキュリティ評価ガイド で扱った “受託の監査対応” の前提を大きく変えます。
受託案件での適用シナリオ 3 パターン
パターン 1: 5.7 / 8.0 EOL 駆け込み移行
MySQL 5.7 は 2023 年に EOL、8.0 も 2026 年 4 月で Extended Support 終了しました。「動いているから触らない」で来た案件は、セキュリティパッチ供給が止まった瞬間に 「動いているのに脆弱」 状態になります。
- 想定リードタイム: 移行設計 + テスト + 切替で 3 〜 6 ヶ月
- 典型予算レンジ: 200 万 〜 800 万円（DB 規模・連携システム数次第）
- 必要な棚卸し: 既存クエリの SQL モード差分、デプリケーションされた構文、文字コード（utf8mb3 → utf8mb4）
パターン 2: Oracle / SQL Server からの脱却
ライセンス更新タイミングで 「商用 DB をやめたい」 という相談は引き続き多く、9.7 LTS の TDE / Audit Log Community 化で 「監査要件を理由に商用 DB を維持する」 言い訳が消えました。
- 想定リードタイム: アセスメント + 移行 + 並行運用で 6 〜 12 ヶ月
- 典型予算レンジ: 1,500 万 〜 5,000 万円（ストアドプロシージャ移行が支配的）
- 判断ポイント: PL/SQL や T-SQL のロジック資産がどの程度あるか、移行で書き直すか保守を継続するか
パターン 3: AI 連携前提の DB 刷新
9.x 系で導入された Vector データ型は、RAG（Retrieval Augmented Generation）系の AI アプリで 「ベクトル DB を別建てしない」 選択肢を生みました。中堅企業の社内ナレッジ検索を MySQL 1 本で完結させる ことが現実的な範囲に入ってきています。
これは 既存 SaaS API を MCP サーバー化する設計パターン で扱った “AI と既存資産の接続” を DB 層で実装する流れと整合します。
移行設計の標準ロードマップ
受託案件で MySQL 9.7 LTS への移行を組むときの標準的なステップを整理しました。
[Phase 0: アセスメント] 4 週間
├ 既存 DB の棚卸し（バージョン・拡張・サイズ・依存システム）
├ クエリ互換性チェック（mysqlsh upgrade checker）
└ 移行計画 + 予算合意
[Phase 1: 並行環境構築] 6 〜 8 週間
├ 9.7 環境のセットアップ（TDE / Audit Log 有効化）
├ レプリケーション設定（既存→新環境）
└ アプリ側の接続テスト + 性能ベンチ
[Phase 2: 切替リハーサル] 2 〜 4 週間
├ 切替手順書の作成
├ ロールバック手順の事前検証
└ 関係者ステークホルダー説明
[Phase 3: 本番切替] 1 〜 2 週間
├ 切替実施（メンテナンスウィンドウ）
├ 切替後監視（72 時間体制）
└ 旧環境の保管期間設定
[Phase 4: 並行運用解除] 4 〜 8 週間
├ 旧環境の停止判断
├ バックアップ世代の確認
└ 移行プロジェクト完了報告Phase 0 のアセスメントを独立した契約にすることで、移行できるかどうかの判断自体を案件化できます。これは 「丸ごと移行」を最初から提案するよりも、顧客の意思決定コストが下がるため、商談化率が高い構造です。
受託契約に書く 9.7 LTS 移行条項
| 条項 | 内容 | 顧客が確認すべきこと |
|---|---|---|
| サポート終了期日 | 9.7 LTS の EOL（2031 年想定）と次期 LTS への再移行 | 5 年後の予算化 |
| TDE 鍵管理 | 鍵の保管場所・ローテーション頻度・喪失時の対応 | 内部統制要件 |
| Audit Log 保管 | 保管期間・保管先・閲覧権限・削除手順 | 法定保存期間 |
| ロールバック条件 | 切替後の問題発生時の戻し条件と費用負担 | 失敗時のリスク |
| データ移行検証 | 件数突合・チェックサム検証・サンプル目視確認 | 完全性証明 |
特に TDE 鍵管理は、「鍵を失うとデータ全損」 の致命的リスクがあるため、契約で 保管者・冗長化・喪失時の保険を明文化することが必須です。
価格モデル — 9.7 LTS 移行受託パッケージ
| プラン | 金額 | 対象 | 内容 |
|---|---|---|---|
| Assessment | 80 万円〜 | 全規模 | アセスメント + 移行計画書 |
| Lite Migration | 300 万円〜 | DB サイズ 100GB 未満 | 5.7/8.0 → 9.7 への移行 |
| Standard Migration | 800 万円〜 | DB サイズ 1TB 未満 | 並行運用 + リハーサル付き |
| Enterprise Migration | 2,000 万円〜 | 商用 DB からの脱却 | ストアド移行含む包括移行 |
ハマりやすい 4 つの落とし穴
落とし穴 1: SQL モードの暗黙差分
MySQL 5.7 → 8.0 → 9.x で デフォルトの sql_mode が厳しくなっており、ゼロ日付・暗黙の型変換・GROUP BY の非集約列など、動いていたクエリが新環境で落ちることがあります。Phase 0 で mysqlsh upgrade checker を必ず通します。
落とし穴 2: 文字コード混在
utf8mb3 と utf8mb4 が混在した状態で 9.x に移行すると、絵文字 4 バイト文字で 「文字化け」または「エラー」 が発生します。全テーブル utf8mb4 に統一してから移行します。
落とし穴 3: レプリケーションフォーマット
GTID ベースのレプリケーションで 「ステートメントベース」 が残っていると、9.x の厳格化で停止します。Row Based Replication に統一してから切替します。
落とし穴 4: Audit Log の容量爆発
Audit Log を有効化すると 本番ワークロードで日次数 GB になることがあり、ログ転送先のディスク逼迫で監査自体が機能停止します。保管先と保管期間の事前設計が必須です。
まとめ — 「商用 DB 維持の言い訳」が消えた 2026
MySQL 9.7 LTS で TDE / Audit Log / Thread Pool が Community Edition に降りてきたことで、「監査要件があるから Enterprise Edition / 商用 DB を維持」という従来の判断軸が大きく変わりました。受託の現場で 「来年の更新でどうする？」 という相談が来たら、9.7 LTS への移行は最有力候補です。
弊社では Assessment / Lite / Standard / Enterprise の 4 段階で MySQL 9.7 LTS 移行受託パッケージを提供しています。「5.7 / 8.0 のままで監査要件が厳しくなった」「商用 DB をやめたい」というご相談は お問い合わせフォーム からお気軽にどうぞ。
