利用部門からのデータ抽出依頼に、集計の案と結果の説明の下書きを作る

処理の起点を決める

依頼フォームが提出されたときが起点です。

フォームの設計が、この構成の半分を決めます。 次を必須項目にしてください。

「用途」と「機密区分」を必須にしてください。 自由記述の依頼文だけでは、個人情報を含む抽出が紛れ込みます。

半自動化では、次を追加します。

• 前回と同じ依頼の場合、過去のSQLを提示する
• 繰り返し依頼されているものを月次で集計し、定型化の候補として挙げる

2つ目が長期的に効きます。 同じ依頼が3か月続けば、BIツールのダッシュボードにすべきものです。

入力データを集める

「データ辞書」がこの構成の中核です。 テーブル定義だけでは足りません。

この表を作ることが、この構成でいちばん時間がかかり、いちばん効きます。 現在、担当者の頭の中にあるものです。

「個人情報を含む列の一覧」も必ず作ってください。 氏名、住所、電話番号、メールアドレス、生年月日、マイナンバー、口座番号。列名で機械的に検査できる状態にしてください。

データの取得方法を決める

テーブル定義： データ基盤のメタデータから自動で取得し、説明文は人が書きます。 自動取得だけでは、列名と型しか分かりません。

最小構成では、よく使う30〜50テーブルの定義書を Claude のプロジェクトにアップロードします。 プロジェクトに置いた文書は、そのプロジェクト内の会話で読ませられるため、毎回貼り直す必要がありません。

半自動化では、依頼文から関連しそうなテーブルを絞ってから渡します。 400テーブルすべてを渡すことはできません。テーブル名と説明文だけの一覧で候補を選び、選ばれたテーブルの詳細な定義を渡すという2段階にしてください。

実行の権限： 読み取り専用のサービスアカウントで実行します。BigQuery では、roles/bigquery.jobUser（プロジェクト内でクエリを含むジョブを実行する権限）と roles/bigquery.dataViewer（データセットのメタデータの取得と、テーブルデータのクエリ・エクスポート・レプリケート） の組み合わせで、データを変更せずにクエリを実行できます。

書き込み権限を持つアカウントで実行しないでください。 生成された案に DELETE や CREATE OR REPLACE が混ざる可能性は、ゼロにはできません。権限で防ぐのが確実です。

スキャン量の見積もり： 実行前にドライランを行います。APIでは JobConfiguration の dryRun を true に設定します。bq コマンドでは --dry_run フラグです。

bq query --use_legacy_sql=false --dry_run 'SELECT ...'

ドライランはクエリを実行しないため、課金されません。 返ってきたスキャン予定バイト数を使えば、実行前に費用を見積もれます。 BigQuery のオンデマンド課金は、読み取ったバイト数に基づきます。

ドライランの限界を2つ押さえてください。

• 行レベルセキュリティでマスクされたテーブルに対するドライランは、サイドチャネル攻撃を防ぐため、常に0バイトを返します。 このテーブルでは費用の見積もりに使えません
• 外部データソースを参照するフェデレーテッドクエリでは、行が返る場合でも0バイトという下限値が報告されることがあります

閾値を決めてください。 「ドライランで1TBを超えたら、担当者の確認を必須にする」といった運用にします。

AIへ渡す前に整形する

1. 依頼文の分解 … 対象、期間、粒度、条件に分けます
2. 業務用語の引き当て … データ辞書で列に対応付けます
3. 過去の類似依頼の検索 … 同じ依頼が過去にないかを探します
4. テーブル候補の絞り込み … 関連しそうなテーブルを20件程度に絞ります
5. 権限の確認 … 依頼者が見てよい範囲かを確認します
6. 機密区分の確認 … 個人情報を含む依頼かを判定します

3番目を必ず入れてください。 「先月と同じものを」という依頼は毎月来ます。過去のSQLがあれば、期間を変えるだけです。

5番目を省かないでください。 依頼者が見てよいデータかどうかは、依頼の内容ではなく、依頼者の権限で決まります。 「営業の人が全社の人件費を知りたい」という依頼は、技術的には簡単ですが、出してよいかは別の話です。

AIに処理させる

AIに次のことをさせないでください。

「テーブル定義にない列を使わせない」ことが、実装上いちばん多く発生する問題です。 生成AIは、それらしい列名を作ります。customer_name があるように見えて、実際は cust_nm かもしれません。定義に存在する列だけを使うよう明示し、存在しない列を使った案は機械的に弾いてください。

「結果の数字を解釈させない」ことも重要です。 「前月比15%増で好調です」という一文が報告書に混ざると、誰の判断なのか分からなくなります。 説明の下書きは、数字が何を含み、何を含まないかにとどめてください。

指示内容を固定する

曖昧な点の洗い出し：

あなたは、データ抽出依頼を受け付ける担当者です。
依頼文から、決まっていない点を洗い出してください。

【厳守事項】
- 決まっていない点を、あなたの推測で埋めないでください。
  「おそらく暦月でしょう」と書かないでください。
- 聞き返しは1回でまとめてください。
  優先度の高い順に並べ、5点以内にしてください。
- 依頼者が答えやすいよう、選択肢を示してください。
  （例：「先月」は 暦月 / 会計月 のどちらですか）
- データ辞書に複数の解釈がある用語は、必ず挙げてください。

【データ辞書】
{data_dictionary}

【依頼文】
{request_text}

集計の案の作成：

あなたは、データ抽出の集計案を書く担当者です。
テーブル定義に基づいて、集計の案を書いてください。

【厳守事項】
- クエリを実行しないでください。案を書くだけです。
- データを変更する文を書かないでください。
  INSERT / UPDATE / DELETE / MERGE / CREATE / DROP / TRUNCATE を
  使わないでください。SELECT のみで書いてください。
- テーブル定義に存在しない列名・テーブル名を使わないでください。
  必要な列が定義にない場合は、missing_columns に書いて、
  案は作らないでください。
- 機密区分で「個人情報を含まない」とされた依頼では、
  個人情報を含む列の一覧にある列を使わないでください。
  「参考のため」に列を追加しないでください。
- SELECT * を使わないでください。必要な列を明示してください。
- 案の前提（期間の定義、除外した条件、結合の粒度）を
  assumptions に日本語で書いてください。
  SQLのコメントではなく、別項目として書いてください。
- 結果の数字を解釈しないでください。
  「増加傾向です」「好調です」と書かないでください。
- 結合によって行が増える可能性がある場合は、
  duplication_risk に、どの結合で何が重複しうるかを書いてください。

【テーブル定義】
{table_definitions}

【データ辞書】
{data_dictionary}

【個人情報を含む列の一覧】
{pii_columns}

【依頼内容（確認済み）】
{clarified_request}

**「SELECT * を使わない」を明示してください。 BigQuery の費用は読み取ったバイト数で決まります。必要な列だけを指定することが、費用に直結します。**

「結合による重複」を必ず書かせてください。 1対多の結合で行が増え、合計金額が実際の何倍にもなるのは、この種の集計で最も多い誤りです。AIも人も間違えます。 明示的に挙げさせておけば、レビューで見る場所が分かります。

出力形式を固定する

{
  "request_id": "",
  "clarifications_needed": [
    {
      "point": "",
      "options": [],
      "why_it_matters": ""
    }
  ],
  "candidate_tables": [
    {
      "table": "",
      "reason": ""
    }
  ],
  "sql_draft": "",
  "assumptions": [],
  "duplication_risk": [],
  "missing_columns": [],
  "pii_columns_used": [],
  "similar_past_requests": [],
  "confidence": "high | medium | low"
}

実行前の検査（プログラム）の出力：

{
  "request_id": "",
  "syntax_valid": false,
  "statement_type": "",
  "contains_write_statement": false,
  "unknown_identifiers": [],
  "pii_columns_detected": [],
  "dry_run_bytes": 0,
  "dry_run_reliable": true,
  "estimated_cost": 0,
  "exceeds_threshold": false
}

dry_run_reliable を必ず持たせてください。 行レベルセキュリティでマスクされたテーブルを含む場合、ドライランは常に0バイトを返します。 0バイトを「安全」と読むと、実際には巨大なスキャンが走ります。 対象テーブルに行レベルセキュリティが設定されているかを確認し、設定されていれば dry_run_reliable を false にしてください。

contains_write_statement と unknown_identifiers は、AIの出力を信じない検査です。 プロンプトで禁止していても、機械で確かめてください。

assumptions は、依頼者に渡す説明の材料になります。 「会計月で集計」「キャンセル分を除外」「税抜」が書かれていれば、数字が合わないときに原因を追えます。

システムへ連携する

最小構成では連携はありません。依頼文とテーブル定義を生成AIのプロジェクトで扱い、案を人が実行します。

半自動化では、次をつなぎます。

実行を自動化しないでください。 レビューを挟む構成にします。レビューなしで実行してよいのは、「過去に実行したSQLの期間だけを変えたもの」に限定してください。 それも、期間の変更が機械的に検証できる場合だけです。

結果ファイルの受け渡しにも注意してください。 CSVをメールに添付する運用は、誤送信の経路になります。 権限管理された保管場所に置き、リンクで渡してください。

人が確認する

実行の判断は、必ずデータ担当が行います。

4番目の「結合による重複」を必ず見てください。 金額の合計が正しいかどうかは、結果を見ただけでは分かりません。 1対多の結合で3倍になっていても、それらしい数字に見えます。 結合の粒度を確かめる工程を、省略できない手順にしてください。

7番目は技術の話ではありません。 「出せるか」と「出してよいか」は別です。依頼者の権限で判断してください。

例外に対処する

記録を残す

• 依頼文と、聞き返しの内容・回答
• 生成された案（SQL）と、その前提
• データ担当が修正した内容と、修正前後
• 実行したSQL（実際に実行したもの）
• ドライランのスキャン量と、実際のスキャン量
• 結果の説明の下書きと、確定した説明
• pii_columns_detected が出た依頼と、その承認の記録
• 定型化の候補として挙げた依頼

「実際に実行したSQL」を必ず残してください。 案ではなく、実行したものです。後から「この数字はどう出したのか」を問われたとき、これがなければ答えられません。

「データ担当が修正した内容」が、この構成を育てる材料です。 どの種類の依頼でよく修正されているかが分かれば、データ辞書に足すべき記述が見えます。

「同じ依頼の繰り返し」を数えてください。 3か月続いている依頼は、この構成で処理し続けるべきものではありません。 BIツールのダッシュボードにすれば、依頼そのものがなくなります。