一般的なAIモデルにスロークエリのチューニングを依頼すると、安易に FORCE INDEX や結合ヒント（Join Hint）を提案してきます。単一クエリの一時的な実行速度は向上するかもしれませんが、大規模な本番環境を運用した経験を持つエンジニアであれば、このアプローチがいかに危険であるかを熟知しています。 GiipのAI Harnessは、クエリの生成およびチューニングにおいて クエリヒントの使用を原則として禁止 しています。30年以上にわたりミッションクリティカルな大規模サービスを運用する中で培われたエンジニアリング原則が、AIの行動範囲（Harness）として厳格に統制されているためです。 1. 同一スキーマであっても、データ分布（Distribution）は生き物です まったく同じテーブルスキーマであっても、国やサービスの特性、トラフィックの流入経路によって、データボリュームやカーディナリティ（Cardinality）は大きく異なります。 選択度（Selectivity）の逆転: データ量が少ない段階では最適だった Index Seek + Key Lookup も、データが数千万件規模に膨張したり特定条件への偏り（データスキュー）が生じたりすると、膨大なRandom I/Oを誘発してデータベース全体を麻痺させます。 CBO（コストベースオプティマイザ）の自律性の担保: 一定の転換点（Tipping Point）を超えると、むしろ Index Scan や Clustered Index/Table Scan による Sequential I/O のほうが圧倒的に高速かつ安定します。 クエリヒントはオプティマイザの正常な判断を強制的に遮断し、サービスの成長に伴って自己適応（Self-adapting）する機会を永久に奪ってしまいます。 2. インデックスのライフサイクルとアプリケーションの危険な結合 大規模データベースは絶えず進化します。ビジネス要件に合わせて新しい複合インデックスを作成し、I/Oコストを削減するために重複・未使用（Unused）インデックスを整理・削除するDDL作業は日常茶飯事です。 런타임 에러 유발: ソースコードやクエリ内に特定のインデックスヒントがハードコードされていると、DBAがインデッ...