「うちは AWS でデータベースを動かしているから、サポート切れの話は関係ない」。中小企業の経営者から、よくこの言葉を聞きます。しかし2026年は、AWS・Google Cloud・Microsoft Azureのいずれを使っていても、MySQL 8.0を載せたまま放置すると追加料金か移行プロジェクトのどちらかが必ず発生する年です。3大クラウドの中で標準サポートが最も早く切れるのはAWS RDS（2026年7月31日）、続いてGoogle Cloud SQLとMicrosoft Azureの両者が2026年12月31日に終了します。本記事では、3大クラウドのサポート終了スケジュールを並べ、従業員10～100名規模の企業が今すぐ決めるべき判断軸を整理します。
なぜ今、MySQL 8.0サポート終了が経営課題なのか
MySQL 8.0は2018年4月にリリースされ、社内の業務システムや自社ECサイトの裏側で長年安定稼働してきました。多くの中小企業が会計・在庫・顧客管理の基盤としてMySQL 8.0を採用しており、「動いているから触らない」という運用が続いています。
ところが2026年4月21日、開発元のOracleはMySQL 8.0をSustaining Support（持続的サポート）へ移行しました。これは、新しいセキュリティ修正もバグ修正も提供されない段階です。さらに、3大クラウド事業者のマネージドDBサービスも、2026年中に標準サポートを順次終了します。
クラウド版を使っていれば自動で安全という話ではありません。標準サポート終了後は、追加料金を払って延命するか、より新しいバージョンへ移行するかの二択になります。経営者として「いつまでに、いくら払って、どう動くか」を決める時期に入りました。
主要クラウドDBaaSのサポート終了スケジュール一覧
3大クラウド事業者が公表しているMySQL 8.0のサポート終了予定を1つの表にまとめました。判断の出発点として、自社が利用している事業者の日付を確認してください。
| プラットフォーム | 標準サポート終了 | 拡張サポート（有償延命）終了 |
|---|---|---|
| Oracle MySQL（本家コミュニティ版） | 2026年4月21日 | 提供なし |
| AWS RDS for MySQL | 2026年7月31日 | 2029年7月31日 |
| Google Cloud SQL for MySQL | 2026年12月31日相当 | 2029年7月1日廃止 |
| Microsoft Azure Database for MySQL | 2026年12月31日 | 2027年1月1日課金開始 / 2029年5月31日終了 |
※執筆時点（2026年5月）の各社公式情報に基づきます。Aurora MySQL（AWSの互換版）はメジャー版番号が独立しており、AWS Aurora公式ドキュメントで個別確認が必要です。
注目すべきは、AWSが最速で2026年7月31日に標準サポートを終了する一方、有償延命を含めれば2029年7月31日まで稼働継続できる点です。3大クラウドのいずれも拡張サポートの最終期限は2029年5月～7月に集中しており、Extended Supportを含めればAWSが最長、AzureがやはりほぼAWS並みの期間を提供します。どのクラウドに載せているかで、無償猶予と有償延命の組み合わせ方が変わると押さえてください。
AWS RDS for MySQL ― 標準終了2026年7月31日、延長最長2029年7月31日の判断軸
AWSは3大クラウドの中で最も猶予が長く、Extended Support（拡張サポート）を購入することで2029年7月31日まで稼働を継続できます。一方で、Extended Supportは時間単位の追加料金が発生するため、放置するほどコストが積み上がります。
判断の分岐点は以下の3つです。
・2027年3月までに移行できる体力があるか: あるなら、追加料金を払う前にMySQL 8.4 LTSへの直接アップグレードを選択
・業務システムの改修が必要か: アプリケーションの互換性検証に半年以上かかるなら、Extended Supportで時間を買う
・Blue/Green Deployment機能を使えるか: ダウンタイムを最小化したい場合は必須の機能
5.7からアップグレードしてきた企業は、5.7→8.0→8.4と段階的に上げる必要があります。一足飛びに8.4へジャンプはできません。今動いているバージョンと、移行先の8.4 LTSとの差分を、まず社内のIT担当者に整理させることから始めてください。
AWS RDSの場合、Extended Supportの料金は時間あたりで課金されるため、インスタンスのvCPU数が多いほど月額負担が増えます。年額に換算すると、中規模のDBインスタンスでも数十万円規模の追加コストになるケースが多いです。
クラウドDBの内部構造や運用の勘所を社内で理解しておきたい方には、技術評論社の解説書が体系的でおすすめです。
MySQL運用・管理［実践］入門 ～安全かつ高速にデータを扱う内部構造・動作原理を学ぶ（技術評論社）（PR）
Google Cloud SQL for MySQL ― 標準終了2026年12月31日相当、廃止2029年7月1日
Google Cloud SQLは、AWSより標準サポートが長く、Azureとほぼ同時期に標準サポートを終えるスケジュールです。Google Cloud公式は「2025年5月1日以降、EOL到達済みのメジャーバージョンには拡張サポート料金を適用する」という一般ポリシーを示しています。MySQL 8.0についても、標準サポート終了後は同ポリシーに従い追加料金が発生する見込みです。正式な日程はGoogle Cloud公式ドキュメントで確認してください。最終的な廃止予定日は2029年7月1日です。
Cloud SQL利用企業の経営判断ポイントは、AWSと違ってMySQL 9.x系統がCloud SQLでは未対応である点です。事実上の選択肢は8.4 LTSへの移行に絞られます。逆に言えば、迷う余地が少なく決断しやすいとも言えます。
| 対応パターン | 推奨される企業規模・状況 |
|---|---|
| 2026年内に8.4 LTSへ移行 | 専任のインフラ担当がいる、または外部委託の予算がある |
| 標準サポート終了後に拡張サポートで延命 | 業務改修の優先度が高く、DB移行を後回しにしたい |
| 2029年6月までに必ず移行完了 | 廃止予定日があるため、これより後ろ倒しは不可 |
Microsoft Azure Database for MySQL ― 2026年12月31日終了、Extended2029年5月31日までの判断軸
Azure Database for MySQLは2026年12月31日に標準サポートを終了します。3大クラウドの中ではAWS（2026年7月31日終了）に次ぐ猶予期間で、最後発の終了日です。執筆時点（2026年5月）から見ても約7ヶ月の準備期間があります。
Microsoftは公式ドキュメント（2026年5月13日付）で、拡張サポートを2027年1月1日から開始し、2029年5月31日に終了することを明示しています。つまり標準サポート終了後の2027年1月から有償課金が始まり、最大で2029年5月までの延命が可能です。Extended Support期間まで含めればAWS RDS（2029年7月31日終了）とほぼ同等の猶予を確保できます。
注意点として、Azure Database for MySQL Single Serverはすでに2024年9月に廃止済みです。今稼働中のシステムは原則Flexible Serverに統一されており、Single Server時代の運用設計を引きずったまま延命を続けるとリスクが累積します。
判断の優先度を整理すると次のとおりです。
・最優先（今月～夏まで）: 自社のAzure MySQLバージョンとサポート終了日を確認
・次にやること: アプリケーション側の8.4互換性テスト
・2026年内のゴール: 8.4 LTSへの移行完了、または有償延命方針の確定
経営者が今すぐ決めるべき3つの判断
3大クラウド共通で、経営者として今すぐ決めるべき判断は次の3つです。技術判断はIT担当者や外部ベンダーに任せられますが、経営判断は社長自身の役割です。
判断1: 追加コストを払って延命するか、移行プロジェクトを動かすか。延命は短期的には楽ですが、毎年数十万～数百万円の追加コストが積み上がります。2～3年延命のトータルコストと、移行プロジェクトの一時的なコストを並べて比較してください。
判断2: 移行先を8.4 LTSにするか、9.7 LTSを待つか。9.7 LTSは2026年4月にリリースされたばかりで、本番投入実績はこれから積まれる段階です。安全策は8.4 LTS、先進策は9.7 LTSとなります。中小企業は基本的に8.4 LTSが無難です。
判断3: クラウド事業者を乗り換える機会と捉えるか。たとえばAzureからAWSへ移すなど、サポート期限の見直しと同時にクラウド再選定を行う企業もあります。データベース移行はサーバー移行のチャンスでもあるためです。
データベース設計そのものを棚卸ししたい場合は、ロングセラーの設計入門書が役立ちます。
達人に学ぶDB設計徹底指南書 第2版（翔泳社、ミック著）（PR）
よくある質問
Q1. サポートが切れても動くなら、そのまま使い続けてもいいですか。
動くことと安全に動くことは別です。Sustaining移行後はセキュリティ修正が止まり、新しい脆弱性が見つかっても修正が提供されません。情報漏えいや業務停止のリスクを取るかどうかの判断になります。
Q2. MySQL 8.4 LTSへのアップグレードは難しいですか。
8.0から8.4はマイナーチェンジに近く、SQLレベルの互換性は高く保たれています。とはいえ業務システム側の検証は必須です。本番投入前に必ずテスト環境でアプリケーションを動かしてください。
Q3. 拡張サポートの料金はどのくらいですか。
AWSの場合、vCPU時間あたりの追加料金で課金されます。具体的な単価は事業者の都度改定が入るため、AWS公式の料金ページで自社のインスタンスタイプの単価を確認してください。年間で数十万円から数百万円規模になる企業が多いです。
Q4. 自社で対応できる人材がいない場合、どうすればいいですか。
クラウドDBの移行支援を行うベンダーが多数存在します。IT導入補助金の対象にできるケースもあるため、見積もり段階で補助金活用の可否を確認するのが定石です。
Q5. Aurora MySQLを使っている場合は、本記事と同じスケジュールでいいですか。
いいえ、Aurora MySQLはバージョン番号が独立しています。Aurora MySQL v3（MySQL 8.0互換）の正確なサポート終了日はAWS Aurora公式ドキュメントで個別に確認してください。RDS本体とは別管理です。
本記事のまとめ
MySQL 8.0のサポート終了は、3大クラウドで2026年7月～12月に集中して訪れます。最速はAWS RDSの7月31日、Google CloudとAzureはいずれも12月31日です。経営者として決めるべきことは「延命するか移行するか」「8.4にするか9.7を待つか」「クラウドを乗り換える機会にするか」の3つです。技術判断は担当者に任せられますが、経営判断の決断を後回しにすると追加コストだけが積み上がります。今月中に自社の利用状況と終了日の確認を、社内のIT担当者へ指示することから始めてください。
中小企業のDXは、身近な業務改善から始まる
クラウドDBの選定や移行判断は、経営者にとって難しいテーマです。
中小企業のDXを身近な業務改善から始めたい方へ、メルマガで実践的なDX推進ノウハウをお届けしています。
