GIIP AI Harnessがクエリヒント（Query Hint）を排除する理由

この文書の適用条件

そのまま実行できるコマンド

# 対象: アプリケーション・ストアドプロシージャのソースコードリポジトリ
# 権限: リポジトリの読み取り権限
# 変更作業: なし（検索のみ）
# Production 実行: 該当なし（手元またはCIで実行）

# 実行計画を強制する代表的なパターンを横断検索する
# WITH (INDEX(...)) / FORCESEEK / FORCESCAN / 明示的な結合ヒント(LOOP|HASH|MERGE) / OPTION(FORCE ORDER)
grep -RniE "with[[:space:]]*\([[:space:]]*index[[:space:]]*\(|forceseek|forcescan|force[[:space:]]*order|loop[[:space:]]+join|hash[[:space:]]+join|merge[[:space:]]+join" --include=*.sql --include=*.cs --include=*.ts .

-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server / Azure SQL
-- 権限: VIEW DEFINITION
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    o.name       AS object_name,
    o.type_desc  AS object_type
FROM sys.sql_modules AS m
INNER JOIN sys.objects AS o
        ON o.object_id = m.object_id
WHERE m.definition LIKE '%INDEX(%'
   OR m.definition LIKE '%FORCESEEK%'
   OR m.definition LIKE '%FORCESCAN%'
   OR m.definition LIKE '%FORCE ORDER%'
ORDER BY o.name;

-- 対象: SQL Server 2008 以降 / Amazon RDS for SQL Server / Azure SQL Managed Instance
-- 権限: VIEW SERVER STATE（Azure SQL Databaseの場合はVIEW DATABASE STATE）
-- 変更作業: なし（参照のみ）
-- Production 実行: 可能
SELECT
    OBJECT_NAME(i.object_id)   AS table_name,
    i.name                      AS index_name,
    ius.user_seeks,
    ius.user_scans,
    ius.user_lookups,
    ius.user_updates,
    ius.last_user_seek,
    ius.last_user_scan,
    ius.last_user_lookup
FROM sys.indexes AS i
LEFT JOIN sys.dm_db_index_usage_stats AS ius
       ON ius.object_id   = i.object_id
      AND ius.index_id    = i.index_id
      AND ius.database_id = DB_ID()
WHERE i.object_id = OBJECT_ID('dbo.SampleTable')
ORDER BY i.name;

結果の読み方

こういう状況で使います

• 同じ基盤AIモデルに同じスロークエリを渡しても、依頼するツールによって提案内容が違う
• AIが提案したFORCE INDEXや結合ヒントを適用した直後は速くなるが、データ量が増えた数か月後にCPUやI/Oが急増する
• 使用率指標だけを根拠に未使用と判断したインデックスを削除したら、特定のクエリ・ストアドプロシージャが直後に例外を起こした
• インデックスの再設計やDDL変更のたびにアプリケーション側との調整が必要になり、作業が滞る

考えられる原因（可能性の高い順）

1. 01

   データ分布の変化による選択度の逆転

   同じスキーマでも、国やサービス特性、流入経路によってデータ量とカーディナリティは変わります。データが少ない段階で最適だったIndex Seek + Key Lookupは、行数が数千万件規模に増えたり特定条件にデータが偏ったりすると大量のランダムI/Oを引き起こします。一定の閾値を超えると、Index ScanやClustered Index Scanによるシーケンシャルアクセスの方が速く安定することが少なくありません。ヒントはこの切り替えをCBOに判断させず固定してしまいます。

2. 02

   インデックスのライフサイクルとアプリケーションコードの危険な結合

   大規模なデータベースは複合インデックスの新設や、重複・未使用インデックスの整理を継続的に行います。特定のインデックスを指す記述がソースコードやストアドプロシージャに直書きされていると、そのインデックスを変更・削除した瞬間に本番で例外（インデックスが見つからない、など）が発生します。大規模サービスの現場では、使用率指標だけを根拠に未使用と判断したインデックスを削除した結果、特定のコード・クエリがそのインデックスを強制的に参照しており、直後に例外が発生する事例は決して珍しくありません。

3. 03

   モデルの差ではなくHarnessの差

   汎用の基盤モデルは目の前のクエリ文字列だけを見て局所的な最適化を試みます。GIIP AI Harnessは、特定インデックスの強制、静的なデータセットを前提としたチューニング、インデックス変更時にアプリケーションが壊れるリスクを避けるため、ヒントを使わずCBOの判断余地を残す制約をAIの行動範囲（Harness）に組み込んでいます。

確認手順

1. 1

   コードベース内の計画強制ヒントを横断検索する

   参照のみ

   上記のgrepパターンで、アプリケーション・ストアドプロシージャの双方からWITH (INDEX(...))、FORCESEEK/FORCESCAN、明示的な結合ヒント、FORCE ORDERを検索します。

2. 2

   インデックスの実使用統計を確認する

   参照のみ

   sys.dm_db_index_usage_statsで参照系・更新系の回数と最終参照日時を確認します。

3. 3

   DMVカウンタのリセット有無を確認する

   参照のみ

   直近のサービス再起動・フェイルオーバー・インスタンス再作成の日時を確認し、観測期間がその後に限られていないかを確認します。観測期間が短い場合、「使用率0」は判断材料として不十分です。

4. 4

   推定行数と実行計画の選択度を比較する

   参照のみ

   実行計画の推定行数と実際の行数を比較し、データ分布の偏りによる選択度の逆転が起きていないかを確認します。

5. 5

   Sargabilityを阻害する要素を確認する

   参照のみ

   WHERE句の列に対する関数適用や暗黙の型変換など、インデックスを使えなくする書き方が無いかを確認します。

対応方法

これで解決しない場合に確認すること

• 削除予定のインデックスが実行計画キャッシュに残っていないか確認したか

  sys.dm_exec_query_statsとsys.dm_exec_sql_textを組み合わせ、直近実行されたクエリの実行計画に対象インデックスへの参照が無いかを確認します。

• 同じパターンのヒントが他のリポジトリ・他のストアドプロシージャ群にも残っていないか横断確認したか

  1つのリポジトリで見つからなくても、別のバッチ処理や別チームが保守するストアドプロシージャに同じ書き方が残っている場合があります。

• 統計情報の更新日時が古くなっていないか確認したか

  CBOの判断はサンプリングされた統計情報に基づきます。統計が古いままでは、ヒントを外してもCBOが正しい選択度で判断できません。

この文書の根拠と限界

よくある質問

この文書がカバーする質問

• なぜAIによってSQLチューニングの提案内容が違うのか
• クエリヒントを使うとどんなリスクがあるか
• インデックスを削除する前に何を確認すればよいか

リスク表示の意味

• 参照のみデータと設定を変更しません。
• 低影響は限定的ですが、権限と負荷の確認が必要です。
• 中性能・ロック・コストに影響する可能性があります。
• 高障害・データ損失・復旧作業が発生する可能性があります。
• 専門家レビュー必須本番適用前に別途レビューが必須です。

GIIPの対応範囲

GIIP AI Harnessは、生成・提案するSQLにFORCE INDEXや明示的な結合順序ヒントを含めないことを設計上の制約としており、性能改善の提案はインデックス設計の見直しや統計情報の整備、クエリのSargability確保など、CBOの判断を阻害しない手段に限定しています。また、インデックスのライフサイクル変更（新設・統合・削除）を検討する際は、使用率統計の一時点の値だけでなく、対象インデックスを強制参照するコードが残っていないかの横断検索を組み合わせることを運用上の前提としています。

関連サービス

• データベース性能チューニング
• AIインフラ運用