ChatGPT APIでSQL連携する前に『回答契約』を定義する方法｜RAG実装の精度向上【2026年版】

ひとことで言うと

ChatGPT APIをSQLデータベースと連携させるとき、「どのような質問にどんな形式で答えるのか」を事前に定義する『回答契約』を設計することで、不正なクエリ生成やハルシネーション（作られた情報）を防ぎ、生成精度を大きく向上させることができます。

『回答契約』とは何か

定義の意味

『回答契約』とは、AIが生成するSQL クエリや応答の形式・範囲・制限を事前に明確に定義すること。データベース接続前のこの設計ステップにより、ChatGPT APIの動作が予測可能になり、セキュリティも精度も向上します。

RAG実装での一般的な落とし穴

多くの開発者は、ChatGPT APIがデータベースに接続できるようになったら、すぐにクエリを投げてしまいます。しかし実際には以下のような問題が発生しやすいです。

• 不適切なSQL生成: 削除・更新クエリまで生成される可能性
• ハルシネーション: データベースに存在しないカラム名やテーブル名でクエリを組み立てる
• パフォーマンス悪化: 結合条件を忘れたクエリや、大量のデータを返すクエリが生成される
• 結果解釈の間違い: クエリは成功しても、その結果をAIが誤解釈して不正確な日本語応答を生成する

こうした問題は、接続前に『回答契約』で「何ができて、何ができないか」を明確に定義することで、ほぼすべて予防できます。

『回答契約』を定義する3つの要素

1. 許可するクエリの種類を限定する

ChatGPT APIには、「SELECT（読み取り）のみ許可」というように、実行可能なクエリタイプを制限するプロンプト指示を組み込みます。

具体的には：

• 許可: SELECT（データ読み取り）
• 禁止: INSERT（データ追加）、UPDATE（データ変更）、DELETE（データ削除）、DROP（テーブル削除）

この制限をプロンプトに明記することで、APIが誤ってデータベースを破壊するリスクが低下します。

2. アクセス可能なテーブル・カラムを明示する

『回答契約』では、ChatGPT APIが参照できるテーブルとカラムを明確に列挙します。

例えば、以下のように指定します。

利用可能なテーブル：
- users（ユーザー情報）
  カラム: user_id, name, email, created_at
- orders（注文情報）
  カラム: order_id, user_id, product_id, quantity, order_date
- products（商品情報）
  カラム: product_id, name, price, stock

この明示により、AIが存在しないカラムを参照しようとするハルシネーションが大幅に減少します。

3. クエリの実行条件と応答形式を定義する

『回答契約』には、以下のような実行ルールも含めます。

• WHERE句の必須化: ユーザーが「全員の注文を取得」と言った場合でも、必ずWHERE句をつけて、デフォルトでは「過去30日間の注文」に制限するなど
• 結果サイズの上限: 1クエリあたりの返却行数を1000行以下に制限
• 時間制限: 実行時間が5秒を超えるクエリは自動的に中止

このようなルールをプロンプトに組み込むことで、予期しないパフォーマンス低下やタイムアウトを防ぎます。

• 応答形式の統一: クエリの結果をJSON形式で返す、あるいはテーブル形式で返すなど、一貫した形式を指定

『回答契約』の実装例

プロンプト内での定義方法

ChatGPT APIに『回答契約』を組み込むときは、システムプロンプト（API呼び出し時の system ロールメッセージ）に以下のように記述します。

あなたはデータベース分析アシスタントです。

【回答契約】
1. 実行許可: SELECT のみ
2. 利用可能テーブル:
   - users (user_id, name, email)
   - orders (order_id, user_id, total_amount, created_at)
3. WHERE句は必須：user_id は 10000 以下に限定
4. 返却行数は最大500行まで
5. 回答形式は JSON 形式で、必ず以下の構造:
   {
     "query": "実行したSQL",
     "columns": ["カラム1", "カラム2"],
     "result": [[データ行]],
     "summary": "結果の日本語説明"
   }

この定義により、APIの動作が格段に予測可能になります。

ハルシネーション防止の具体策

スキーマ検証プロセス

『回答契約』定義後、さらに以下のプロセスを加えることで、ハルシネーションを排除できます。

1. ChatGPT が生成したSQL を即座には実行しない
2. 別の検証ステップで、生成されたSQLが『回答契約』に違反していないかチェック
3. 違反が見つかれば、APIに「修正してください」と返す

例えば、次のような検証ロジックを実装します。

生成されたクエリが以下を満たしているか確認：
- SELECT のみ？（INSERT/UPDATE/DELETE 検出 → 拒否）
- 許可テーブル内のみ参照？（未許可テーブル名検出 → 拒否）
- WHERE句に user_id 条件がある？（ない → 拒否）
- LIMIT が1000以下か？（超過 → 修正提案）

このチェックは、ChatGPT APIの外側で実装することで、人間の意思でフィルタリングできます。

既存のRAG実装との違い

従来のRAG実装

多くの企業が採用している「RAG」（情報検索を組み込んだ生成AI）実装では：

• ユーザーが質問をする
• 質問に関連するドキュメントをベクトルデータベースから検索
• 検索結果をプロンプトに混ぜて、ChatGPT APIに送信
• 最終的な応答をユーザーに返す

という流れが基本です。

『回答契約』アプローチの利点

『回答契約』を組み込んだアプローチでは：

• 事前の境界設定: APIが実行できる操作を最初から制限しているため、事後的なエラーハンドリングが少なくなる
• 精度向上: テーブル・カラム情報をあらかじめプロンプトに含めるため、ハルシネーション率が低下
• 保守性向上: 新しいテーブルを追加する際も、『回答契約』を更新するだけで良い
• 監査性向上: どの権限範囲でどの操作が可能かが明白になるため、セキュリティ監査に対応しやすい

実装時の注意点

過度な制限は避ける

『回答契約』は強力ですが、制限が強すぎるとユーザーが欲しい情報にたどり着けなくなります。以下のバランスを意識してください。

• セキュリティ要件と機能要件の両立
• パフォーマンス制約と実用性の調整

定期的な見直し

ビジネス要件やデータベース構造が変わったら、『回答契約』も更新する必要があります。四半期ごと、または大きな機能追加時には必ず見直してください。

AIの誤り判定

ChatGPT APIが『回答契約』に違反するクエリを生成する場合、その原因をさかのぼる必要があります。

• プロンプトが不明確？ → より具体的に書き直す
• テーブル構造が複雑？ → 簡潔なスキーマドキュメントを作成してプロンプトに含める
• APIのトークン制限？ → より短くまとめたプロンプトに変更

まとめと結論

ChatGPT APIをSQLデータベースと連携させる際、『回答契約』の定義は必須のステップです。これは技術的な実装ではなく、「何ができるか」の設計思想です。

『回答契約』によって：

• セキュリティが向上: データベースの破壊やアクセス権限外のデータ参照が防止される
• 精度が向上: ハルシネーションが大幅に減少し、生成されるSQL の信頼性が上がる
• 保守性が向上: スキーマ変更時の対応がシンプルになり、ドキュメント化がしやすくなる

実装の最初の段階で少し時間をかけて『回答契約』を設計することで、長期的には開発コスト削減と品質向上につながります。

あわせて読みたい

• ハルシネーションとは？AIが嘘をつく5つの原因と防ぎ方【初心者向け】
• プロンプトとは？ChatGPT・Claudeで質問の質を上げる5つのコツ
• MCPとは？Model Context Protocolを5分で理解【図解・初心者向け】