概要
https://zenn.dev/hacobu/articles/4010bc5b9525af
詳細内容
## 生成AIで商談メモから「次の一手」を出す
https://zenn.dev/hacobu/articles/4010bc5b9525af
商談メモの非構造化データから要因分析と次アクションを導き出すため、BigQuery、Gemini、Lookerを組み合わせたシステム構築における課題と具体的な解決策を詳述します。
**Content Type**: Tutorial & Guide
**Scores**: Signal:4/5 | Depth:4/5 | Unique:3/5 | Practical:5/5 | Anti-Hype:4/5
**Main Journal**: 100/100 | **Annex Potential**: 100/100 | **Overall**: 80/100
**Topics**: [[LLMプロンプトエンジニアリング, BigQuery ML, データ前処理, パフォーマンス最適化, 商談メモ分析]]
本記事は、Salesforceの商談メモといった非構造化データから「よく出る論点・懸念・成功要因・次アクション」を抽出するシステムをBigQuery、Gemini、Lookerで構築した際の実装課題と解決策を解説しています。特に、LLM（Gemini）への直接的なプロンプトが日本語の分かち書きや出力の揺らぎ、JSONの崩れで不安定だった問題に対し、決定論的な特徴量算出とLLMによる意味づけを分業するハイブリッドアプローチが重要であると強調しています。
なぜこれが重要かというと、Webアプリケーションエンジニアが生成AIを既存のデータ基盤に組み込む際、生じるであろう実践的な課題と、その具体的な対処法を提示しているためです。著者は、数値化可能な要素（例：質問記号数、肯定／否定語の出現回数）はSQLで前処理し、意味づけの部分のみを最小限のJSONスキーマでLLMに抽出させる手法を提案。さらに、BigQuery MLとGemini連携における「レスポンスがない」「処理が重い」といった一般的な課題に対し、入力メモの長さを制限する`SUBSTR`関数、安定した出力を得るための`flatten_json_output=TRUE`、壊れたJSONを堅牢にパースする`REGEXP_EXTRACT`と`SAFE.PARSE_JSON`の活用、そしてプロンプトでの詳細な指示（例：JSONを1個のみ返す、`temperature=0`）など、具体的なSQLクエリと設定による解決策が示されています。また、性能問題に対しては、バッチ処理、2パス推論、中間テーブルの永続化、監視列の設置といった運用上の工夫も紹介されており、実務でLLMを活用する上での信頼性と安定性を高めるための実践的な知見が満載です。