MySQL 9.7 LTS で受託 DB を更新する — Community Edition で実現する SMB モダナイゼーション 2026

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 に降りてきた主要機能

特に 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 ヶ月
• 規模を左右する要因: DB 規模、連携システム数、メンテナンスウィンドウの取りやすさ
• 必要な棚卸し: 既存クエリの SQL モード差分、デプリケーションされた構文、文字コード（utf8mb3 → utf8mb4）

パターン 2: Oracle / SQL Server からの脱却

ライセンス更新タイミングで 「商用 DB をやめたい」 という相談は引き続き多く、9.7 LTS の TDE / Audit Log Community 化で 「監査要件を理由に商用 DB を維持する」 言い訳が消えました。

• 想定リードタイム: アセスメント + 移行 + 並行運用で 6 〜 12 ヶ月
• 規模を左右する要因: ストアドプロシージャの資産量が支配的。ロジックが DB 側に厚く寄っているほど工期も検証範囲も膨らむ
• 判断ポイント: 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 移行条項

特に TDE 鍵管理は、「鍵を失うとデータ全損」 の致命的リスクがあるため、契約で 保管者・冗長化・喪失時の保険を明文化することが必須です。

ハマりやすい 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 への移行は最有力候補です。

ただし、移行の重さは「MySQL 9.7 にする」という一点では決まりません。DB のサイズ、ストアドに寄せたロジックの厚み、止められる時間の長さ——この 3 つの組み合わせで、必要な工程も体制もまるで別物になります。だからこそ本記事では Phase 0 のアセスメントを独立させることを勧めました。まず自社の DB に upgrade checker を通し、何が引っかかるかを見てみてください。その結果を持ち込んでいただければ、どこから手を付けるべきかを一緒に切り分けられます。お問い合わせはこちらから。

Sources

• MySQL 9.7: First Major LTS Since 8.4 Brings Enterprise Features to Community Edition（InfoQ）
• SCS セキュリティ評価ガイド（GH Media）
• 既存 SaaS API を MCP サーバー化する設計パターン（GH Media）
• AWS Aurora Serverless v4 受託 DB モダナイゼーション（GH Media）