データベース内部で実行計画を選択する際には、膨大な選択肢がある。エンジニアのロハン・バンサル氏は、これをLLMで効率化できないかと考えた。しかも利用しようとしたのは、巨大な最先端モデルではなく、自身でも動かせる規模の小型モデルだ。バンサル氏が選択したのは、4B規模の小型LLMだった。

　バンサル氏は2026年9月16日、自身のWebサイトに「Training a 4B model to produce 81% faster query plans than Postgres」という記事を公開した。

　バンサル氏はこの記事で、「PostgreSQL」に標準搭載されるクエリオプティマイザーを、小型LLMで効率化する手法について研究し、その過程と結果を公表した。クエリオプティマイザーは、PostgreSQLが利用されるようになって以降、長い年月をかけて改良されてきた重要な仕組みだ。だが、バンサル氏は、2015年に発表された論文と、さらにその10年後に発表された論文を踏まえ、クエリ最適化にはさらに改善の余地があると考えた。

　バンサル氏は、PostgreSQLの実行計画を決めるクエリ最適化処理は「非常に難しい」と指摘する。クエリオプティマイザーが実行するタスクの一つとして「結合順序付け」が挙げられるが、その処理は「NP困難」（問題の規模が大きくなるほど、最適解を現実的な時間で求めるのが極めて難しくなる性質）だという。

　同氏はその記事で、「IMDbデータセット」を使ったシンプルなクエリを紹介した。「2000年代に最も多くの映像作品を手掛けた日本企業は？」というクエリでは、3つの表の結合順序や結合アルゴリズム、スキャン方式などを組み合わせると、実行計画の候補は4608通りになる。さらに表が増えれば候補は爆発的に増加し、12の表を結合する例では約726垓通りに達するという。

　ただ、この数が示すように、PostgreSQLが全てのプラン候補を実行して比較することは現実的ではない。そこでクエリオプティマイザーは、データの列にどのような値がどれくらい存在するかといった統計情報から、処理する行数やコストを推定してプランを選択する。ただし、推定には限界があり、この推定が誤っていると、後続の推定も連鎖的に悪化する問題が発生するという。

　そこでバンサル氏は、LLMにクエリを与え、より高速なプランを生成させる実験を行った。実験には、Qwen系の小型言語モデル「Qwen3.8-4B-Distill」が使われた。これは「Qwen 3.5 4B」をベースに作られた蒸留モデルで、4B規模の軽量でコンパクトなLLMだ。バンサル氏は当初、自宅のGPU（RTX 3090）で4Bモデルを動かし、後半は学習を高速化するためクラウドGPUをレンタルして併用した。クエリの実測は自宅のPostgreSQL環境で行った。

　そして、バンサル氏が考案したのは、LLMに直接プランを生成させるのではなく、PostgreSQLにヒントを与える仕組みだ。PostgreSQLには「pg_hint_plan」という拡張機能があり、コメントでヒントを書くことで、結合順序や結合アルゴリズムを指定できる。バンサル氏は、小型LLMとPostgreSQLを連携させるエージェント基盤「qo-agent」を構築した。

　qo-agentは、クエリを受け取ると、テーブル構造や列の統計情報、PostgreSQLが選択した標準プランなどをLLMに調べさせる。LLMはその情報を基に、表の結合順序や結合方式、スキャン方式などを指定した候補を作成する。その指示は、SQLにヒントとしてPostgreSQLに与えられる。qo-agentは候補の計画を実行し、標準プランとの速度差をLLMに伝える。LLMはその結果を参照しながら別の候補を試し、最終的に採用する計画を選択するという、ほぼ自律的に動くエージェントというわけだ。

　実験では、学習前の小型LLMはバンサル氏が望む処理をほとんどこなせなかった。クエリ最適化の性能を評価するベンチマーク「Join Order Benchmark」が使われたが、それに含まれる113クエリのうち、81件で有効な候補を1つも作れなかったという。

　そこでバンサル氏は、高性能な大規模モデル「GPT-6 Astra」が同じ問題に取り組んだ約400件の過程を教材にして「教師あり学習」（SFT）を実施した。つまり、小型モデルに、調査の進め方や正しい形式で候補を作る方法をまねさせたのだ。その後、モデル自身に複数の実行計画を作らせ、実測で速かった試行を強化し、遅い試行や無効な試行を弱める「強化学習」（RL）を実行した。

　このとき問題となったのが、実行時間の「揺らぎ」だった。同じクエリでも、OSやPostgreSQLのキャッシュ、同時実行されている他の処理などによってノイズが発生し、計測値が変化する。たまたま速く測定された計画を高く評価してしまえば、モデルに誤った学習を施す恐れがある。

　そこでバンサル氏は、複数のPostgreSQL環境を用意し、ノイズ発生の原因を追及した。最終的に「shared_buffers」を2GBに増やす設定にすることで、ノイズを劇的に減らすことに成功した。

　プランの精度を高めるため、報酬設計を改良しながら1200回もの強化学習が繰り返された。その結果、小型LLMが生成したプランがデフォルトのプランを上回るケースが113件中101件まで増え、1回当たりのプラン探索時間についても、幾何平均1.41倍の高速化を記録した。

　最終評価では、各クエリについて3回探索し、最大15候補の中から事前測定で最も速いプランを選択することとした。その結果、113件のクエリの幾何平均はPostgreSQLのデフォルトプランの1.81倍、全クエリの合計時間も1.81倍の高速化に成功すると同時に、平均44.7％の遅延削減も達成した。5％以上高速化できたプランは68件で、デフォルトプランを下回ったLLM生成プランはなかったという。4B規模の小型モデルが提案したプランが、PostgreSQLのデフォルトプランを安定して上回ることができたのは、大きな成果と言えるだろう。

　注目すべきは、そのコストの小ささだ。今回の実験にかかった費用は、H100を2基搭載した計算環境のレンタルに約800ドル、教師データを作るためのAPI利用に約400ドル、合計約1200ドルだった。時間をかけ、バンサル氏の手元にあったGPUだけで実験すれば、さらに費用を抑えられた可能性もあるという。

　なお、今回の実験は、IMDb由来のデータと重い結合処理のベンチマークを計測して得られた結果であり、別のデータベースや、日々内容が変化する業務データでも同じ性能が出るとは限らない。それでも、この実験結果は興味深い。少なくともデータベースのクエリ最適化は、LLMが自律的に学習して改善できる領域であることが示されたからだ。

　巨大な汎用（はんよう）AIに毎回仕事を頼むのではなく、その知識を小型モデルへ移し、自社の環境で得られる実測結果によって育てることが可能なことが分かった

　今後は、データベースの実行計画に限らず、設計や運用、物流など、試した結果の良しあしを数字で判断できる分野にも、同じ発想を応用できるかもしれない。

上司X：　4B規模の小型LLMにSQLの実行計画を任せたら、PostgreSQLのデフォルトクエリオプティマイザーより高速に実行できるプランを見つけた、という話だよ。

ブラックピット：　4Bというと、約40億パラメーターということですか。これでも小型なんですか？

上司X：　必ずしも、パラメーター数だけでLLMの能力は測れないけどな。ただ生成AIが急成長した2020年から2023年時点で、例えば、GPT-3は175B、つまり1750億パラメーターだったというから、規模は小さいと言えるだろう。

ブラックピット：　今では、クローズドモデルのパラメーター数はあまり公開されていませんよね。オープンウェイトモデルは公表する傾向にあるようです。

上司X：　オープンウェイトモデルは、自分のPCのローカル環境にあるGPUで動作させることもあるから、規模を明記していることが多いようだ。

ブラックピット：　Bansal氏も最初は自宅のGPU環境で4Bモデルを動かそうとしていたようですものね。学習のためにクラウドの大規模LLMやクラウドのH100も借りたみたいですけど。

上司X：　ああ、そのようだ。Bansal氏の実験とは関係なく、PostgreSQLの標準クエリオプティマイザーにAIを組み込む研究も進めているようだが、これについても小型LLMが補助して最適化するような形になりそうだということだよ。

ブラックピット：　僕の仕事にも小型AIを使ったエージェントを導入して最適化してもらいたいものです。僕より仕事が速かったら僕は不要ということで！

上司X：　いや、自分で自分を不要にする方向へ最適化するなよ（笑）。まあ、キミの話はともかくだ、今後、企業が持つ現場のデータを使って、小型AIを特定の仕事の専門家に育てるという発想は広がりそうだ。Bansal氏の実験のように、小型AIでも十分育てば、特定の仕事に活用できる。こういったことこそが本当の意味でのAI活用になるのかもしれないな。