PostgreSQL特有の高度な関数をAIで効率的に生成するためのプロンプト集

PostgreSQLの潜在能力を引き出す：AIに「標準SQL」を卒業させるプロンプトエンジニアリング実践

2026年1月5日更新 2026年3月20日約13分で読めます

文字サイズ:

PostgreSQLの潜在能力を引き出す：AIに「標準SQL」を卒業させるプロンプトエンジニアリング実践

データベースのポテンシャルを、AIは本当に引き出せているでしょうか。

開発現場でChatGPTやClaudeにSQLを生成させる際、「確かに動くものの、MySQLでも動くような『教科書通りの標準SQL』になっている」という課題に直面することがあります。

特にPostgreSQLを採用しているプロジェクトでは、この違和感は顕著です。強力なJSONB型や高度なWindow関数、再帰CTE（共通テーブル式）が利用可能な環境であるにもかかわらず、AIが出力するのは冗長なサブクエリや、アプリケーション側での処理を前提とした単純なSELECT文になりがちです。

よりPostgreSQLに適したクエリを求めて修正指示を出しても、存在しない関数を出力するハルシネーションや構文エラーが発生し、結果的に公式ドキュメントを参照しながら手動で書き直した方が早かった、というケースも少なくありません。

近年のAIモデルは飛躍的な進化を遂げています。ChatGPTの最新環境では長大な文脈の理解や複雑なツール実行が可能になり、Claudeでもタスクの複雑度に応じて思考の深さを自動調整する機能や、膨大なコンテキストを処理する能力が標準搭載されています。それにもかかわらず期待通りのSQLが出力されないのは、AIの能力不足ではなく、「指示の出し方（プロンプト）」が単純な一問一答を前提とした、標準SQL向きのままになっているからです。

AIの推論能力が劇的に向上した現在、単発の質問を投げる従来の手法から、詳細なスキーマ情報やシステム要件をコンテキストとして与え、自律的なエージェントとして活用するワークフローへの移行が不可欠です。

本記事では、AIを「汎用的なSQLライター」から「PostgreSQL専任のデータベースアーキテクト」へと変貌させるための、実践的なプロンプト設計術を解説します。これは実際の開発現場で有効性が確認されており、開発効率とクエリパフォーマンスの双方を改善できるアプローチです。

PostgreSQLの高度な機能を、進化したAIと共に最大限に活用する手法を体系的に紐解きます。

この学習パスについて：汎用SQLの限界をAIと突破する

まず、なぜAIは「PostgreSQLらしさ」を無視するのでしょうか。

なぜAIは「PostgreSQLらしさ」を無視するのか

理由は明確で、LLM（大規模言語モデル）の学習データには、特定のRDBMSに依存しない「標準SQL」のサンプルが圧倒的に多いからです。さらに、インターネット上の技術記事の多くがMySQLやSQLiteをベースに記述されていることも影響しています。

そのため、特に指定がなければ、AIは「最も一般的で、どのデータベースでも動作する可能性が高い安全策」として標準SQLを選択します。しかし、実務レベルのシステム開発において、この「安全策」はしばしば「非効率」と同義になります。

例えば、階層構造を持つデータを取得する場合、標準SQLでは自己結合（Self Join）を繰り返す必要がありますが、PostgreSQLであれば再帰CTEを用いることで簡潔に記述できます。JSONデータの検索においても、テキストとしてLIKE検索を行う場合と、GINインデックスが有効なJSONB演算子を使用する場合とでは、パフォーマンスに大きな差が生じます。

本ガイドのゴール：AIを「Postgresエキスパート」に変える

このガイドでは、以下の4つのステップを通じて、AIに対する指示の解像度を高めていきます。

コンテキスト定義: AIにPostgreSQL環境であることを正確に認識させる。
分析クエリ生成: CTEやWindow関数を活用し、可読性と性能を両立させる。
非構造化データ: JSONBや配列型など、NoSQL的な機能を正確に操作させる。
ロジック実装: PL/pgSQLによるストアドプロシージャやトリガーを実装する。

各ステップにおいて、実践的なプロンプトのテンプレートとその意図を論理的に解説します。これらの手法を適用することで、AIとの対話をシニアDBAとの技術的なディスカッションと同等のレベルに引き上げることが可能になります。

Step 1：コンテキスト定義の型を習得する

プロンプトエンジニアリングの基本は「コンテキスト（文脈）」の提供ですが、SQL生成においてはこれがプロジェクトの成否を分ける重要な要素となります。
単に「このテーブルでクエリを作成して」と指示するだけでは不十分です。AIはテーブル名とカラム名しか把握できず、背後にある制約、インデックス、そして「どのバージョンのPostgreSQLを使用しているか」という前提条件を理解できないためです。

スキーマ情報の効率的な渡し方

よくある失敗例として、SELECT * FROM table LIMIT 5 の結果のみを提示するパターンが挙げられます。この方法では、データ型や外部キー制約といった重要なメタデータが伝わりません。

最も効果的なアプローチは、DDL（データ定義言語）を直接提供することですが、すべてを渡すとトークン制限に抵触するリスクがあります。ここで必要なのは、データの「構造」と「関係性」を抽出して伝えることです。

実務の現場では、以下のような「システムプロンプト（または会話の冒頭）」を設定することが推奨されます。

# Role
あなたはPostgreSQL 15のエキスパートDBAです。
標準SQLではなく、PostgreSQL特有の機能（JSONB, CTE, Window Functions, Lateral Joinsなど）を積極的に活用し、パフォーマンスと可読性の高いクエリを提案してください。

# Schema Context
以下のDDLに基づきます。

-- users table
CREATE TABLE users (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    profile JSONB,
    created_at TIMESTAMPTZ DEFAULT NOW()
);

-- orders table
CREATE TABLE orders (
    id SERIAL PRIMARY KEY,
    user_id UUID REFERENCES users(id),
    items JSONB, -- Array of objects
    total_amount NUMERIC(10, 2),
    status TEXT
);

-- Indexes
CREATE INDEX idx_users_profile ON users USING GIN (profile);

ポイント:

バージョン指定: PostgreSQL 15と明記することで、MERGE文や新しい正規表現関数などが利用可能であることをAIに認識させます。
特有機能の使用許可: 「標準SQLではなく～」という明示的な指示が、AIの制約を解除するトリガーとなります。
インデックス情報: この情報を提供するだけで、AIは「GINインデックスが存在するため @> 演算子を使用すべきだ」という論理的な判断を下せるようになります。

【演習】AIにDB設計思想を理解させる初期プロンプト作成

以下のプロンプトを比較することで、出力されるクエリの品質の違いが明確になります。

悪いプロンプト:

usersテーブルとordersテーブルを使って、先月のユーザーごとの売上合計を出して。

良いプロンプト（コンテキスト設定後）:

usersとordersテーブルを使用します。先月のユーザーごとの売上合計を集計してください。
ただし、usersテーブルのprofileカラム（JSONB）に含まれる "region" キーごとに集計を分けたいです。
パフォーマンスを考慮し、インデックスが効く書き方を優先してください。

前者の場合、AIは単純な GROUP BY を生成しますが、JSONの要素を抽出する際に profile->>'region' とテキストキャストするだけの、パフォーマンスに劣るクエリになりがちです。一方、後者の指示（かつインデックス情報が提供されている場合）であれば、AIは適切な演算子の選択や、状況に応じた式インデックスの提案まで自律的に行います。

Step 2：分析系クエリ（CTE・Window関数）の生成技法

Step 1：コンテキスト定義の型を習得する - Section Image

複雑な集計処理を実装する際、AIに完全に依存すると、過度にネストされたサブクエリが生成されることが頻繁に起こります。これは可読性を著しく低下させ、後の保守作業を困難にします。この課題を解決するために重要となるのが、CTE（Common Table Expressions：共通テーブル式） の利用を明示的に指示することです。

複雑な集計を論理ステップで分解させる

プロンプトエンジニアリングにおいて、複雑な課題を段階的に解決させるアプローチは非常に有効です。SQL生成においては、この体系的な思考プロセスを「CTEによる処理の分割」として応用します。

AIに対して論理的なステップを踏むよう促すことで、人間がコードを解釈する順序と一致した構成でSQLを出力させることが可能になります。

プロンプト例:

以下の要件を満たすSQLを作成してください。

要件:

直近3ヶ月の注文データを抽出する

ユーザーごとに購入総額を計算する

購入総額の上位10%のユーザーを特定する

その上位ユーザーの詳細情報を出力する

制約:

各ステップをCTE（WITH句）で定義し、論理的な流れを明確にすること。

サブクエリのネストは禁止。

Window関数 NTILE または PERCENT_RANK を活用すること。

このように処理手順を箇条書きで明確に示し、さらに「各手順をCTEとして定義する」という制約を加えることが重要です。これにより、AIは論理的なプロセスをコード構造に直接反映し、保守性の高いクエリを生成します。

Window関数を使ったランキング・移動平均の指示出し

PostgreSQLのWindow関数は強力な機能ですが、コンテキストが不足している場合、AIは GROUP BY を用いた集約処理で代替しようとする傾向があります。「行を集約せずに、各行に対して集計値を付与したい」という要件を明確に伝達する必要があります。

悪い出力例（AI任せ）:

-- 自己結合を使って移動平均を出そうとする（非効率かつ冗長）
SELECT t1.date, AVG(t2.value)
FROM metrics t1
JOIN metrics t2 ON t2.date BETWEEN t1.date - 6 AND t1.date
GROUP BY t1.date;

改善プロンプト:

日次売上の7日間移動平均を算出したいです。
自己結合は使用せず、Window関数 AVG() OVER (...) と ROWS BETWEEN フレーム句を使用して実装してください。

「フレーム句（ROWS BETWEEN）」のような専門用語をプロンプトに組み込むことで、AIに対して高度な技術的要件を提示していることを認識させます。その結果、より効率的で精度の高い構文が選択されるようになります。

Step 3：非構造化データと特殊型のハンドリング

この領域こそがPostgreSQLの真骨頂であり、同時にAIが適切な処理を省略しがちな部分でもあります。特にJSONB型の操作においては、明確な指示を与えない限り、単なるテキスト操作として処理されてしまうリスクがあります。

JSONB型へのクエリを生成させる特殊指示

JSONB型に対して、キーの存在確認や特定の値を含む行の抽出を行う場合、->>（テキストとして抽出）を使用するか、@>（包含演算子）を使用するかで、クエリのパフォーマンスは劇的に変化します。

プロンプトテンプレート:

タスク: logs テーブルの payload カラム（JSONB）から、特定の条件に一致する行を抽出する。

条件:

payload内の "event_type" が "error" であること。

かつ、"tags" 配列に "urgent" が含まれていること。

重要な制約:

payload ->> 'event_type' = 'error' のようなテキストキャストによる比較は避けてください（インデックスが効かないため）。

代わりに、JSONB包含演算子 @> を使用して、GINインデックスが利用可能なクエリにしてください。

ここで「インデックスが効かないため」という論理的な理由を付記することが重要です。AIは制約の背景にある理由を提示されることで、その条件をより厳格に遵守する傾向があります。

配列型や範囲型（Range Types）の活用

スケジュール管理や在庫管理などのシステムで有用な「範囲型（Range Types）」も、PostgreSQL特有の機能です。AIにこれらの機能を活用した設計を提案させるには、具体的なビジネス課題をベースに要件を提示するアプローチが有効です。

対話例:

会議室の予約システムを作っています。予約時間の重複を防ぐバリデーションをSQLで行いたいのですが、START_TIME <= END_TIME のような比較ロジックを自分で書くのは面倒です。
PostgreSQLの TSTZRANGE 型と && (overlap) 演算子、および EXCLUDE 制約を使って、DBレベルで重複を阻止するDDLとクエリを提示してください。

このように「型」と「演算子」を具体的に指定することで、AIは要件を満たす正確な実装例を出力します。

Step 4：PL/pgSQLによるロジック実装とデバッグ

Step 3：非構造化データと特殊型のハンドリング - Section Image

複雑なビジネスロジックをアプリケーション層ではなく、データベース層のストアドプロシージャ（PL/pgSQL）にカプセル化したいケースも存在します。しかし、PL/pgSQLの構文は独特であり、AIであっても DECLARE の位置やセミコロン（;）の有無といった細部で構文エラーを起こす傾向があります。

ストアドプロシージャ・関数の要件定義プロンプト

PL/pgSQLのコードを生成させる際は、「入力」「処理」「出力」「例外処理」といった要素を体系的に構造化して提示します。

プロンプトテンプレート:

以下の仕様でPL/pgSQL関数を作成してください。

1. 関数名: `update_inventory_stock`
2. 引数: `p_item_id UUID`, `p_quantity INT`
3. 戻り値: 更新後の在庫数 (INT)
4. 処理ロジック:
   - 対象アイテムの現在在庫を取得（行ロック `FOR UPDATE` を使用すること）。
   - 在庫が不足している場合は、カスタム例外 `insufficient_stock` を発生させる。
   - 在庫を更新し、`inventory_log` テーブルに履歴をINSERTする。
5. 例外処理:
   - その他のエラーが発生した場合は、エラー内容を `RAISE NOTICE` で出力して再スローする。

特に FOR UPDATE を用いた排他制御などは、明示的に指示しないとAIが実装を省略するリスクがあります。データ整合性を担保するためのトランザクション制御に関するキーワードは、必ずプロンプトに含めるようにします。

エラー発生時の「自己修正」プロンプトチェーン

生成されたPL/pgSQLを実行してエラーが発生した場合、単にエラーメッセージをフィードバックするだけでなく、以下のようなアプローチをとります。

以下のエラーが発生しました。
[エラーメッセージ]

原因を分析し、修正したコードを提示してください。
また、なぜそのエラーが起きたのか、PostgreSQLの仕様に基づいて解説してください。

エラーの「解説」を要求することで、AIは自身が生成したコードの論理的な再検証（Self-Correction）を行うため、修正案の精度が大幅に向上します。

実践リソース：コピーして使えるプロンプトテンプレート集

Step 2：分析系クエリ（CTE・Window関数）の生成技法 - Section Image 3

最後に、実際のプロジェクトですぐに活用できるプロンプトのテンプレートを紹介します。これらを開発プロセスに組み込むことで、作業効率の向上が期待できます。

1. クエリ最適化（EXPLAIN ANALYZE）

実行計画を解析させ、論理的なチューニング案を提示させるためのプロンプトです。

以下のSQLクエリと、その `EXPLAIN (ANALYZE, BUFFERS)` の結果を分析してください。

[SQLクエリ]
...

[実行計画]
...

依頼事項:
1. ボトルネックとなっている処理（Seq Scan、高いCostなど）を特定してください。
2. PostgreSQL特有の機能（インデックス種別、パラメータチューニング、クエリ書き換え）を用いた具体的な改善案を3つ提示してください。
3. それぞれの改善案で期待される効果を推定してください。

2. 他RDBMSからの移行（MySQL to PostgreSQL）

以下のMySQL用クエリを、PostgreSQL用に最適化して書き換えてください。

[MySQLクエリ]
...

変換ルール:
- `IFNULL` は `COALESCE` に変更。
- バッククォート（`）はダブルクォート（"）に変更、または削除。
- MySQL特有の非標準的なGROUP BY（フルグループ化されていないもの）がある場合は、適切に修正してください。
- 文字列結合は `CONCAT` ではなく `||` 演算子を使用。

次のステップ：AI駆動開発の習慣化

AIにPostgreSQL特有のコードを生成させることは、単なる作業の「自動化」にとどまりません。それは、開発者自身がPostgreSQLのアーキテクチャを深く理解し、AIに対して適切な「要件」を定義するプロセスでもあります。

AIが提案したコードを通じて、これまで知らなかった効率的な関数やアプローチを発見することもあります。これこそが、AI駆動開発がもたらす真の価値と言えます。

プロジェクトのROIを最大化するためにも、プロンプト設計において「PostgreSQLの特性を活かす」という視点を組み込んでみてください。AIを単なるツールとしてではなく、高度な技術パートナーとして活用することで、システム開発の品質と効率は飛躍的に向上するはずです。

PostgreSQLの潜在能力を引き出す：AIに「標準SQL」を卒業させるプロンプトエンジニアリング実践 - Conclusion Image

コメントは1週間で消えます

コメントを読み込み中...