前回までの記事では、
-
SnowflakeでJSONが全滅した話
-
VARIANTやLATERAL FLATTENの実践テクニック
を書きました。
本記事では、金融データ活用チャレンジで実際に構築した「評価自動化パイプライン」の設計思想と実装ログをまとめます。
単なる実装紹介ではなく、
なぜこの設計にしたのか
どんな制約があり、どうトレードオフしたのか
まで掘り下げます。
目的：提案書を“データ化”して評価ループを回す
やりたかったのはシンプルです。
10社分の提案書をAIに採点させ、
改善点を抽出し、修正 → 再評価を回す。
しかし、LLM単体では以下の課題がありました。
-
出力履歴がセッション依存
-
横断比較ができない
-
改善履歴が構造化されない
-
トークン上限にすぐ達する
そこで、
Snowflakeをハブにした評価パイプライン
を構築しました。
全体構成（3レイヤー）
[Layer1] 入力
Obsidian（Markdown提案書）
↓
[Layer2] データ基盤
Snowflake
- DRAFT_DOCS
- DOC_EVAL_CONTEST
↓
[Layer3] 評価
Cortex（一次評価）
Claude（高精度レビュー）
↓
Cursorで修正 → 再評価
ポイントは、
LLMを単体で使わず、データ基盤に組み込んだこと
です。
実装アプローチ
① 段階的拡張戦略
最初にやらかしたのは、
❌ 長文JSONを10社同時生成
結果：
-
出力truncate
-
JSONパース失敗
-
eval=NULL
そこで設計変更。
採用戦略
-
まず短いJSON（5観点のA/B/C）で全件成功
-
基準提案書のみ長文生成
-
必要に応じて展開
成功率100%を先に作る設計に切り替えました。
② VARIANTによる評価のデータ化
CREATE TABLE DOC_EVAL_CONTEST (
doc_id STRING,
raw_text STRING,
eval VARIANT,
created_at TIMESTAMP_TZ
);
評価結果をVARIANTで保持することで：
-
JSON構造のまま保存
-
eval:overall.rank のように参照可能
-
LATERAL FLATTENで配列展開
-
横断比較が可能
評価そのものをデータ化できました。
③ Prompt Pack化
評価結果をCursorに貼れる形式へ変換。
SELECT
'## 評価結果: ' || doc_id || '\n' ||
'総合評価: ' || eval:overall.rank || '\n' ||
LISTAGG(
'- ' || f.value:instruction,
'\n'
) WITHIN GROUP (ORDER BY f.index)
FROM DOC_EVAL_CONTEST,
LATERAL FLATTEN(input => eval:fixes) f
GROUP BY doc_id, eval:overall.rank;
Snowflake内でレビュー結果を整形し、
Cursorで即修正できるループを構築。
コスト最適化ログ
トークン最適化
当初見積：
1社10万トークン × 10社 = 100万トークン
実績：
6社で約10.8万トークン
＝1社約1.8万トークン
→ 約83%削減
手法
-
冒頭400行のみ読み取り
-
バッチ処理（4社＋6社）
-
テンプレート固定化
バッチ処理の効果
| 項目 | 当初 | 実績 |
|---|---|---|
| DBアクセス | 10回 | 2回 |
| 処理時間 | 約300分 | 約110分 |
約1/3に短縮。
LLMは高価なI/O。
前後の設計でコストは劇的に変わります。
設計上の意思決定とトレードオフ
なぜSnowflakeをハブにしたか
LLM単体では：
-
履歴が残らない
-
比較ができない
-
再利用性が低い
Snowflakeに載せることで：
-
評価をデータ化
-
横断分析可能
-
改善履歴を保存
-
再評価を自動化
ツールから「基盤」に昇格しました。
なぜCortex＋Claude併用なのか
-
Cortex：データ近接、完結性
-
Claude：品質高いがトークン制限あり
役割分担：
-
Cortexで一次評価
-
Claudeで高精度レビュー
-
Snowflakeで履歴管理
制約を分離する設計です。
なぜ段階的拡張なのか
LLMは長文×大量に弱い。
いきなり完璧を狙うと壊れる。
成功率を先に作る設計が安定しました。
転用可能な設計パターン
このパターンは提案書に限りません。
-
レポート自動レビュー
-
内部監査文書評価
-
IR資料分析
-
契約書レビュー
-
コードレビュー補助
本質は、
文章を評価 → 構造化 → 改善ループ
の自動化です。
設計の本質
今回学んだのは、
LLMを使うことではなく、
LLMをどこに置くかが設計
ということでした。
単体利用は便利。
基盤に組み込むとシステムになる。
Snowflake × LLM は、
「LLMをデータ基盤に接続する設計」
で初めて真価を発揮します。
シリーズまとめ
-
JSON全滅からの復旧
-
VARIANTとタグ戦略
-
評価パイプライン設計と最適化
中級者の方へ。
もしLLMを“ツール”として使っているなら、
次は“基盤に組み込む”視点で設計してみると世界が変わります。