Postgres データベースを眺めながら「ただ質問できればいいのに」と思ったことがあるなら、この記事はあなたのためのものです。Postgres インスタンスを Tablize に接続し、自然な日本語で質問し、答えを保存して実行し続ける方法を紹介します。
合計時間：約 5 分。Postgres 接続文字列（Supabase プロジェクトでもセルフホスト RDS インスタンスでも何でも）と無料の Tablize ワークスペースが必要です。
ステップ 1：Postgres に読み取り専用ロールを作成（90 秒）
データベースに直接触れるのはこの部分だけです。Tablize にクエリさせたいスキーマへの読み取り専用アクセスを持つ Postgres ロールを作成します。それ以外は何も。Tablize を完全に信頼しているとしても、読み取り専用が適切なデフォルトです — エージェントは間違いを犯し、DROP TABLE は「permission denied」よりも復旧が困難だからです。
psql か好みの SQL クライアントで実行：
-- Tablize 専用のロールを作成
CREATE ROLE tablize_ro LOGIN PASSWORD 'use-a-long-random-password';
-- データベースへの接続権限を付与
GRANT CONNECT ON DATABASE your_db TO tablize_ro;
-- Tablize に見せたいスキーマへの USAGE 権限
GRANT USAGE ON SCHEMA public TO tablize_ro;
-- 既存の全テーブルへの SELECT 権限
GRANT SELECT ON ALL TABLES IN SCHEMA public TO tablize_ro;
-- このスキーマに今後作成されるテーブルにも
ALTER DEFAULT PRIVILEGES IN SCHEMA public
GRANT SELECT ON TABLES TO tablize_ro;公開したいスキーマが複数ある場合は、各スキーマに対して USAGE/SELECT/ALTER DEFAULT PRIVILEGES ブロックを繰り返します。隠したいスキーマ（internal や migrations など）がある場合は、単に USAGE を付与しなければ済みます。
Tablize 用の接続文字列はこのようになります：
postgresql://tablize_ro:use-a-long-random-password@your-host:5432/your_dbステップ 2：Tablize で接続（60 秒）
Tablize ワークスペースを開き、サイドバーの 連携 に移動し、Postgres をクリック。接続文字列を貼り付け、「Test connection」を押します。Postgres に到達でき、認証情報が機能すれば、緑のチェックが表示されます。
その後 Tablize は自動スキーマ内省を実行します — 各テーブルを巡回し、カラム名と型を読み取り、軽量な表現を保存します。これがエージェントがスキーマを先に説明させずに質問に答えられる理由です。内省は読み取り専用で、接続時に一度実行され、その後テーブルが変わったときに増分的に実行されます。
数十テーブルのデータベースなら約 10 秒。数千テーブルのものなら 1 分くらい。いずれにせよ待つ必要はありません — エージェントがバックグラウンドでインデックス化している間にチャットタブを開いて入力を始められます。
ステップ 3：最初の質問をする（30 秒）
新しいチャットを開きます。具体的なことを入力します。「データを見せて」と言わないでください — それは曖昧すぎます。ジュニアアナリストならすぐ理解できるようなものを試してください：
"過去 90 日間の総注文額で上位 10 顧客を表示してください。
注文数と平均注文額も合わせて。"エージェントは：
- スキーマを見て、顧客テーブルと注文テーブルを特定します（命名が曖昧な場合は推測してあなたに伝えます）。
- SQL を書きます — 通常は
JOIN+GROUP BY+ORDER BY ... LIMIT 10。 - 実行前に SQL を見せます。結合キーが間違っていれば編集できます。問題なければ実行を押します。
- 読み取り専用ロールに対してクエリを実行します。
- 結果テーブルを表示し、何が興味深いかの 1〜2 文の要約を書きます。
全体で通常 5〜15 秒。エージェントが新しいテーブルで初めて作業するときは、直感を構築するため遅くなります。3 つ目の質問までには高速になります。
ステップ 4：生成された SQL を見て編集する
これが信頼にとって重要な部分です。Tablize は SQL を隠しません。すべてのクエリが完全に表示され、シンタックスハイライトされ、編集可能です。SQL がわかるなら、エージェントが書いたものを読んで信頼するか判断できます。SQL がわからなくても、ロジックを問い詰めるフォローアップ質問ができます — 「ここでなぜ LEFT JOIN を使ったの？」 — そして自然な日本語で答えが返ってきます。
よくあるパターン：エージェントが書いたクエリが ほぼ 望むものだけれど、カットオフ日が間違っていたり、間違った次元でグループ化していたり。再プロンプトする代わりに、SQL を直接編集して再実行できます。エージェントはあなたの編集を新しい真実の源として扱い、次の関連質問で記憶します。
SQL が本当に奇妙なことをしている場合 — 例えば見覚えのないウィンドウ関数 — エージェントに説明を求めてください。説明します。生成された SQL の自然な日本語による説明は、このカテゴリ全体の過小評価された勝利の 1 つです。
ステップ 5：答えを保存して実行し続ける
これが Data Agent の形を「データベースツール付き ChatGPT」と区別するステップです。エージェントの応答の下部に、Keep バーとオプションが表示されます：
- 📝 レポートとして保存 — この分析をオンデマンドで再実行される markdown レポートに変える。
- 💾 スクリプトとして保存 — SQL や Python を別パラメータで実行できる再利用可能なスクリプトとして保存。
- 🔍 ウォッチ — 条件を設定し、トリガーされたら通知。
- 📱 ダッシュボードを構築 — この分析を中心とした小さなダッシュボードを生成。
上位 10 顧客の例では、レポートとして保存 に週次スケジュールが自然な動きです。レポートはサイドバーの レポート の下に表示され、月曜日 9 時（または選んだ時間）に新鮮なデータで再実行され、受信箱に届きます。
コードを書いたり何かを構築したりせずに、単発の質問を定期ブリーフに変えました。
次に何を聞くか
最初の質問が機能したら、次の 5 つの質問が異なる筋肉を動かします：
- ファネル：「ランディングページから最初のアクションまでのユーザーサインアップファネルを、過去 8 週間の週次で見せてください。」
- コホート：「過去 12 か月のサインアップコホート別の 12 か月リテンションを見せてください。」
- 異常：「過去 30 日で行数が 50% 以上増加したテーブルはありますか？」
- 構築：「users テーブルの CRUD 管理画面を、検索とロールフィルター付きで構築してください。」
- ウォッチ：「過去 1 時間のログイン失敗回数が 100 を超えたら通知してください。」
これらはそれぞれエージェントの異なる部分を運動させます。コホートは実際の分析パターンでの SQL の腕前をテスト。異常はスキーマメタデータを内省する能力をテスト。構築はコード生成をテスト。ウォッチはスケジューリングと通知の配管をテスト。
よくある落とし穴
新規ユーザーがハマる点：
スキーマは思っているものとは違う。 created というカラムが実はステータスフィールドで、created_at というカラムがタイムスタンプだったりします。エージェントは命名で推測し、時々間違えます。クエリ結果が奇妙に見えたら、まず SQL を確認 — 結合キーやフィルターカラムがずれているかもしれません。
読み取り専用は速いという意味ではない。 適切なインデックスのない 1 億行のイベントテーブルがあれば、それに対する結合は遅くなります。Tablize は長時間実行クエリをタイムアウトさせてデータベースを保護します — これに遭遇したら、修正は通常 Tablize ではなくインデックスの追加です。
エージェントは破壊的な操作の前に必ず尋ねます。 いずれにせよ読み取り専用ロールからは DROP TABLE できませんが、書き込みアクセスがあっても、変更前に Confirmation Center を経由します。間違った質問が間違った行動を引き起こす状況はありません。
次は何か
1 つの分析が保存されたら、次の自然なステップはそれを連鎖させること — レポートの上にウォッチを構築するか、保存したスクリプトからダッシュボードを生成するか。Keep ループが差別化要因であり、一度それをやれば、形を理解できます。
自分の Postgres で Tablize を無料で試す →
関連記事：