GitHubで公開されているMicrosoftDocs/sql-docsの公式ドキュメントに、2026年4月29日付で「automatic-tuning-update」という更新が入りました。結論から言うと、この更新はGitHubそのものの新機能ではなく、SQL Server、Azure SQL Database、Azure SQL Managed Instance、Microsoft FabricのSQLデータベースに関係するsp_configure_automatic_tuningの説明を整理したものです。
特に確認すべき点は、FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKの扱いです。従来はAzure SQL DatabaseとMicrosoft FabricのSQLデータベース向けであることが強く見える記述でしたが、今回の更新では構文説明が一本化され、SQL Server 2022以降を含む適用範囲との関係を読み違えないことが重要になりました。
開発者、クラウド管理者、ソリューションアーキテクトは、単に「ドキュメントの日付が変わった」と見るのではなく、現在の運用環境で自動プラン修正、Query Store、拡張チェック、トレースフラグ12656をどう扱っているかを確認しておくべきです。
GitHubの公式ドキュメント更新「automatic-tuning-update」で何が変わったか
今回の更新は、GitHub上のMicrosoftDocs/sql-docsリポジトリに対するコミットです。対象ファイルは、SQL Serverドキュメントの次のページに対応するMarkdownファイルです。
docs/relational-databases/system-stored-procedures/sp-configure-automatic-tuning-transact-sql.md
変更内容としては、主に次の3点です。
| 確認項目 | 更新内容 | 実務上の意味 |
|---|---|---|
| ドキュメント日付 | ms.dateが06/23/2025から04/29/2026へ更新 | 2026年4月29日時点の説明として再確認すべきページになった |
| Syntaxの整理 | SQL Server 2022/Azure SQL Managed Instance向けとAzure SQL Database/Fabric向けに分かれていた構文説明が一本化 | FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKを含む構文の読み方に注意が必要 |
| オプション説明の修正 | FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKの説明から「Azure SQL DatabaseとFabricのみ」と読める限定表現が削除 | 適用対象全体、個別クエリ設定、SQL Server側のトレースフラグの関係を確認する必要がある |
今回の変更は、機能そのものの追加を大きく発表するような更新ではありません。しかし、運用チームにとっては「どの環境で、どの構成方法を使うべきか」を見直すきっかけになります。
まず押さえるべきsp_configure_automatic_tuningの役割
sp_configure_automatic_tuningは、自動チューニング機能のうち、自動プラン修正に関する設定を特定のquery_idに対して変更するためのストアドプロシージャです。
ここでいう自動プラン修正とは、クエリ実行プランの選択によって性能が悪化した場合に、Query Storeに記録された「最後に良好だったプラン」を使って性能低下を抑える仕組みです。
たとえば、次のような状況で関係します。
- ある日を境に、特定の検索処理だけ急に遅くなった
- 統計情報の更新後に、実行プランが変わって処理時間が悪化した
- パラメータースニッフィングの影響で、同じSQLなのに実行時間が大きくぶれる
- Azure SQL DatabaseやSQL ServerでQuery Storeを使って性能劣化を追跡している
sp_configure_automatic_tuningは、すべての自動チューニング設定を一括で切り替えるためのものではありません。特定のquery_idを対象に、自動プラン修正の対象に含めるか、除外するか、または拡張的な回帰チェックを適用するかを制御するためのものです。
今回の更新で特に重要なFORCE_LAST_GOOD_PLAN_EXTENDED_CHECK
今回のドキュメント更新で最も注目すべきキーワードは、FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKです。
これは、自動プラン修正に対して追加の時間ベースのプラン回帰チェックを使わせるためのオプションです。ドキュメント上では、プラン変更が検出された後、一定時間後に追加チェックを行うことで、短時間で終わるクエリだけに評価が偏ることを避ける説明になっています。
簡単に言えば、次のようなクエリをより慎重に評価したい場合に関係します。
| クエリの特徴 | 通常の評価で起きやすい問題 | 拡張チェックが役立つ可能性 |
|---|---|---|
| 実行時間が長いバッチ処理 | 早い段階の実行結果だけでは良し悪しを判断しにくい | 長めの実行傾向を考慮しやすくなる |
| タイムアウトしやすいレポート系クエリ | プラン変更後の悪化が遅れて見えることがある | プラン変更による影響を追加で確認できる |
| 実行回数が少ないが重要なクエリ | サンプルが少なく、判断が不安定になりやすい | 個別に対象クエリを指定して扱える |
| パラメーターによるばらつきが大きいクエリ | 一部の実行だけでは全体傾向を誤認する可能性がある | 回帰判定の偏りを減らす助けになる |
ただし、FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKを見たからといって、すぐに本番環境へ適用すべきという意味ではありません。自動プラン修正は性能改善に役立つ一方で、クエリの性質、Query Storeの設定、ワークロードの変動を理解せずに有効化すると、原因分析がしにくくなることがあります。
更新前後で読み違えやすいポイント
今回の更新は、文章量としては大きくありません。しかし、運用判断では読み違えが起きやすい内容です。
「GitHubの更新」だがGitHub機能の変更ではない
トピック名にGitHubが含まれているため、GitHub Actions、GitHub Copilot、GitHub Enterprise Cloudなどの更新と誤解しやすい点に注意してください。
今回の更新は、GitHub上で管理されているMicrosoft公式ドキュメントのコミットです。対象はGitHubサービスではなく、MicrosoftのSQL関連ドキュメントです。
そのため、確認すべき対象は次のようになります。
| 誤解しやすい見方 | 正しい確認対象 |
|---|---|
| GitHubの自動チューニング機能が更新された | SQL Server/Azure SQLの自動チューニング説明が更新された |
| GitHub Actionsの設定変更が必要 | Query Storeや自動プラン修正の設定確認が必要 |
| リポジトリ運用ルールの変更 | データベース性能管理の運用影響を確認 |
対象環境ごとに確認すべきポイント
sp_configure_automatic_tuningは、SQL Server、Azure SQL Database、Azure SQL Managed Instance、Microsoft FabricのSQLデータベースに関係します。ただし、使える機能や設定方法は環境によって違います。
SQL Server 2022以降を使っている場合
SQL Server 2022以降では、FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKの挙動をインスタンス全体に適用する方法として、グローバルトレースフラグ12656が関係します。
ここで重要なのは、個別クエリに対するsp_configure_automatic_tuningの設定と、インスタンス全体に影響するトレースフラグを混同しないことです。
確認すべき項目は次のとおりです。
| 確認項目 | 確認する理由 |
|---|---|
| SQL ServerのバージョンとCU | SQL Server 2022 CU4以降など、前提条件に関係するため |
| Query Storeが有効か | 自動プラン修正はQuery Storeの情報を使うため |
| トレースフラグ12656の利用有無 | 拡張チェックをインスタンス全体に適用している可能性があるため |
| 既存のプラン強制設定 | 手動のプラン強制と自動修正の関係を確認するため |
| 性能監視の指標 | 変更前後でCPU、duration、logical readsなどを比較するため |
特に、すでに本番環境でトレースフラグを使っている場合は、ドキュメント更新をきっかけに「なぜ有効化したのか」「対象クエリは何か」「解除条件はあるか」を運用手順書に残しておくと安全です。
Azure SQL Databaseを使っている場合
Azure SQL Databaseでは、自動チューニングはサーバーレベルまたはデータベースレベルで構成できます。FORCE_LAST_GOOD_PLANはAzureの既定値として有効になっているケースがあるため、「明示的に有効化していないから関係ない」と判断しないほうがよいです。
確認する順番は次のようにすると効率的です。
| 手順 | 確認内容 | 目的 |
|---|---|---|
| 1 | サーバーレベルの自動チューニング設定 | 多数のDBへ共通設定が反映されていないか確認 |
| 2 | データベース個別の上書き設定 | 一部DBだけ設定が異ならないか確認 |
| 3 | Query Storeの状態 | 読み取り専用や容量不足で機能が止まっていないか確認 |
| 4 | 対象クエリのquery_id | 個別設定の対象を特定 |
| 5 | 変更後の監視指標 | 自動修正による性能変化を確認 |
自動チューニングは便利ですが、ワークロードが頻繁に変わる環境では、原因が「アプリケーション変更」なのか「自動チューニングの影響」なのか切り分けが難しくなることがあります。リリース日、DB設定変更日、性能劣化の発生日を同じタイムラインで管理しておくと、障害対応が速くなります。
Azure SQL Managed Instanceを使っている場合
Azure SQL Managed Instanceでは、Azure SQL Databaseと似た機能を持つ一方で、ポータル上の設定やインデックス自動管理など、適用範囲が異なる部分があります。
特にFORCE_LAST_GOOD_PLANの構成はT-SQLで扱う前提になるため、Azure SQL Databaseと同じ操作手順をそのまま流用しないように注意が必要です。
運用チームでは、次の観点で確認するとよいでしょう。
- 自動チューニングをT-SQLで管理しているか
- ポータル操作を前提にした手順書になっていないか
- Query Storeの容量や読み取り書き込み状態を監視しているか
- パフォーマンス問題発生時に
query_idを追跡できるか
Microsoft FabricのSQLデータベースを使っている場合
Microsoft FabricのSQLデータベースでは、Azure SQL Databaseの機能説明と重なる部分があります。今回の更新でも、FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKの例にはAzure SQL DatabaseとMicrosoft FabricのSQLデータベースが示されています。
Fabricを利用している場合は、従来のSQL Server運用だけでなく、データ分析基盤全体のワークロードとして見ることが重要です。たとえば、BIレポートや分析処理のクエリが遅くなったとき、アプリケーション側だけでなくSQLデータベース側のプラン変更も確認対象になります。
実務で使う確認コマンド例
本番環境でいきなり設定を変更するのではなく、まずは現在の状態を確認します。
自動チューニング構成を確認する
SELECT *
FROM sys.database_automatic_tuning_configurations;このビューでは、現在のデータベースで有効になっている自動チューニング設定を確認できます。設定変更後の確認にも使います。
自動プラン修正で強制されているプランを探す
次の例は、Query Storeのプラン情報から自動プラン修正に関係するプランを確認するための出発点です。
SELECT
qry.query_id,
pl.plan_id,
pl.is_forced_plan,
pl.plan_forcing_type_desc
FROM sys.query_store_plan AS pl
INNER JOIN sys.query_store_query AS qry
ON qry.query_id = pl.query_id
WHERE pl.is_forced_plan = 1;実務では、ここに対象期間、アプリケーション名、クエリテキスト、実行時間などの条件を加えて絞り込みます。
特定クエリを自動プラン修正の対象から外す
自動プラン修正が特定のクエリに合わないと判断した場合、FORCE_LAST_GOOD_PLANをOFFにして、そのquery_idをAPCの監視対象から外すことができます。
EXECUTE sys.sp_configure_automatic_tuning
@option = 'FORCE_LAST_GOOD_PLAN',
@type = 'QUERY',
@type_value = 42,
@option_value = 'OFF';この操作は、単なる「機能無効化」ではありません。特定のクエリを自動プラン修正の考慮対象から外す操作です。対象のquery_idを誤ると、意図しないクエリに影響する可能性があります。
特定クエリに拡張チェックを適用する
長時間実行やタイムアウト傾向があるクエリに対して、拡張的な時間ベースの回帰チェックを適用したい場合は、次のように設定します。
EXECUTE sys.sp_configure_automatic_tuning
@option = 'FORCE_LAST_GOOD_PLAN_EXTENDED_CHECK',
@type = 'QUERY',
@type_value = 442,
@option_value = 'ON';この設定は、性能問題のあるクエリを「自動的に速くする魔法」ではありません。プラン変更後の評価をより慎重にするための設定です。設定前後で、平均実行時間、最大実行時間、CPU時間、読み取り量、タイムアウト件数を比較してください。
移行・運用準備で確認すべきチェックリスト
今回のGitHub公式ドキュメント更新を受けて、すぐに全環境へ設定変更を行う必要はありません。むしろ、現在の運用が公式ドキュメントの説明と矛盾していないかを確認することが先です。
| チェック項目 | 対象者 | 判断基準 |
|---|---|---|
| SQL Server/Azure SQL/Fabricのどれを使っているか | クラウド管理者、DBA | 環境ごとに設定方法と適用範囲が異なる |
| Query Storeが有効か | DBA、開発者 | 無効・読み取り専用・容量不足だと期待どおり動かない |
| 自動チューニングの現在値を把握しているか | 運用担当 | 障害時に原因切り分けができる |
FORCE_LAST_GOOD_PLANを使っているか | DBA | 自動プラン修正の影響範囲を確認する |
FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKを使う理由が明確か | アーキテクト | 長時間実行・タイムアウト傾向など根拠が必要 |
| トレースフラグ12656を使っているか | SQL Server管理者 | インスタンス全体への影響を確認する |
| 本番適用前に検証環境で比較したか | 技術意思決定者 | クエリ特性により効果が変わるため |
よくある失敗と回避策
query_idを固定的な識別子として過信する
query_idはQuery Store上の識別子です。環境、データベース、クエリの変更状況によって扱いが変わるため、別環境のquery_idをそのまま本番環境に流用するのは危険です。
検証環境と本番環境で同じSQLに見えても、Query Store上の識別子が一致するとは限りません。設定前に必ず対象クエリを確認してください。
自動チューニングを有効にすれば監視が不要になると考える
自動チューニングは監視の代替ではありません。むしろ、設定変更や自動修正が行われた結果を確認するために、監視の重要性は高まります。
最低限、次の指標は変更前後で比較できるようにしておくべきです。
- 平均実行時間
- 最大実行時間
- CPU時間
- 論理読み取り数
- タイムアウト件数
- プラン変更の発生時刻
- アプリケーションリリースの時刻
サーバーレベル設定とデータベース個別設定を混同する
Azure SQL Databaseでは、サーバーレベルの自動チューニング設定をデータベースが継承する場合があります。一方で、データベースごとに個別設定で上書きされていることもあります。
「サーバー側では有効なのに、特定DBだけ期待どおり動かない」という場合は、データベース個別の設定を確認してください。
ドキュメント更新だけで仕様変更と断定する
今回のコミットは、ドキュメントの記述整理を含む更新です。ドキュメントの表現が変わったからといって、必ずしも同日にサービス仕様やエンジン挙動が変わったとは限りません。
技術判断では、次の順番で確認すると安全です。
- GitHubのコミット差分を確認する
- Microsoft Learnの該当ページを確認する
- 自社環境のバージョン、CU、構成を確認する
- 検証環境で動作を確認する
- 本番反映の必要性を判断する
開発者が見るべき観点
開発者は、sp_configure_automatic_tuningをDBAだけの話として片付けないほうがよいです。実行プランの回帰は、アプリケーションのレスポンス悪化として現れることが多いためです。
特に、次のような機能を開発している場合は注意してください。
- 検索条件が多い一覧画面
- 月次・日次の集計処理
- 大量データを対象にした更新処理
- BIツールやレポート画面向けのクエリ
- パラメーターによって返却件数が大きく変わるAPI
開発側でできる対策は、SQLの実行時間をアプリケーションログに残すことです。DB側のQuery Store情報とアプリケーションログを突き合わせられると、プラン変更の影響を早く見つけられます。
クラウド管理者・アーキテクトが見るべき観点
クラウド管理者やソリューションアーキテクトは、機能の有効・無効だけでなく、ガバナンスとして整理する必要があります。
特に複数のAzure SQL DatabaseやSQL Serverインスタンスを管理している場合、次のルールを決めておくと運用が安定します。
| ルール | 具体例 |
|---|---|
| 設定変更の承認範囲 | 本番DBの自動チューニング設定はDBA承認を必須にする |
| 監視指標の標準化 | duration、CPU、logical reads、タイムアウトを共通指標にする |
| 例外管理 | 自動プラン修正から除外したquery_idと理由を記録する |
| 定期レビュー | 月次でQuery Store容量、強制プラン、回帰傾向を確認する |
| リリース連携 | アプリ変更日とDB設定変更日を同じ変更管理台帳に残す |
自動チューニングは、うまく使えば運用負荷を下げられます。しかし、設定理由を残さないまま変更すると、半年後に「なぜこのクエリだけ除外されているのか」が分からなくなります。設定値だけでなく、判断理由を残すことが重要です。
今回の更新を受けた実務アクション
今回の「automatic-tuning-update」を受けて、読者が次に取るべき行動は明確です。まずは設定変更ではなく、現状確認から始めてください。
おすすめの進め方は次のとおりです。
| 優先度 | やること | 目的 |
|---|---|---|
| 高 | MicrosoftDocs/sql-docsの該当コミットとMicrosoft Learnページを確認 | 更新内容の把握 |
| 高 | 自社環境がSQL Server、Azure SQL、Managed Instance、Fabricのどれか整理 | 適用範囲の確認 |
| 高 | sys.database_automatic_tuning_configurationsで現在値を確認 | 既存設定の棚卸し |
| 中 | Query Storeの状態と容量を確認 | 自動プラン修正の前提確認 |
| 中 | 強制プランや性能劣化クエリを洗い出す | 影響範囲の特定 |
| 中 | FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKを使う候補クエリを検証 | 長時間クエリへの適用判断 |
| 低 | 運用手順書と障害対応フローを更新 | 将来のトラブル防止 |
最も避けたいのは、「公式ドキュメントが更新されたから」といって、対象環境やクエリ特性を確認せずに設定を変更することです。今回の更新は、機能の理解を深め、既存運用を棚卸しするよいタイミングと捉えるのが現実的です。
GitHub上のMicrosoftDocs公式更新「automatic-tuning-update」は、GitHubサービスの新機能ではなく、SQL ServerやAzure SQLの自動チューニング、とくにsp_configure_automatic_tuningとFORCE_LAST_GOOD_PLAN_EXTENDED_CHECKに関するドキュメント更新です。
確認すべき要点は、構文説明の整理、FORCE_LAST_GOOD_PLAN_EXTENDED_CHECKの読み方、Query Storeを前提とした自動プラン修正の運用影響です。まずは自社環境の対象サービス、現在の自動チューニング設定、Query Storeの状態を確認しましょう。そのうえで、長時間実行やタイムアウトが問題になっている重要クエリについて、拡張チェックを検証環境で試すのが安全な進め方です。
コメント