LLM連携による営業支援ダッシュボード開発ノート──PoCから本番運用までの全技術記録

プロジェクトの背景と目標設定

国内 SaaS 市場ではインサイドセールス活動を効率化するダッシュボード需要が急拡大しています。社内で既に保有している顧客データベース（PostgreSQL）と外部の CRM API、さらに生成 AI（LLM）を組み合わせることで、「確度の高いリードを優先表示し、提案文面を自動生成する」 プロダクトを新規開発することになりました。本記事では、PoC（概念実証）から本番運用開始までの実装メモを時系列で整理し、

• システム開発フローの作り方

• 費用対効果を最大化する技術選定

• システム 開発会社 選び方 予算 費用 相場 発注 の観点

を中心に解説します。

ステークホルダー整理と要件定義の勘所

まずは 要件定義 を行う段階で「誰がどの KPI を改善したいのか」を粒度高く可視化しました。営業部門・マーケ部門・情報システム部門の 3 役が並列で利益を求める場合、機能要求が発散しやすいため、

1. プロダクト目標を “SQL で 5 秒以内にリード温度を算出し、更新頻度 15 分以内” と限定

2. LLM 連携機能を “アイスブレイク文章素案を自動生成” にフォーカス

3. ダッシュボード UI は “Table + カスタムフィルタのみ” としてフェーズ分割

の 3 本柱でスコープを固定しました。システム設計段階で 機能フリーズ宣言 を出しておくことで、見積もり依頼後の追加改修コストを最小化できます。

技術選定：バックエンドは FastAPI × LangChain、フロントは Next.js

PoC フェーズで高速にプロトタイプを回すため、Python × FastAPI を採用しました。

• FastAPI … 型付きエンドポイント生成が速く、OpenAPI → Postman → 営業担当のフィードバックを即反映可能

• LangChain … LLM プロンプトテンプレートとメモリ管理を DSL 的に記述でき、AI プロンプトの A/B テストを自動化

• Next.js … ISR（Incremental Static Regeneration）によりダッシュボードの初回ロードを 200 ms 以内へ最適化

同時に MsgPack + WebSocket により、リアルタイムでリードスコア変動をプッシュ配信しました。
システム開発会社へ発注する際は「LangChain コンポーネントのカスタマイズ経験があるか」を RFP に必ず含めることで、失注リスクを下げられます。

コストシミュレーション：API コールと GPU 推論の費用構造

LLM 連携では 推論コスト がボトルネックです。本案件では以下 2 パターンの見積もりを取得しました。

費用対効果 を評価した結果、初期は API、利用量が 2.5 倍以上になった時点でオンプレ移行という二段構えロードマップを策定しました。開発会社選びの観点では「GPU 推論基盤を短期間で IaC 化できるか」を見極めるとよいでしょう。

開発フロー：GitHub Actions × Terraform Cloud で全自動化

インフラは Terraform Cloud 上に 3 つのワークスペース（dev / stg / prd） を用意し、PR マージ時に GitHub Actions が plan → apply を自動トリガーします。

name: Terraform CI
on:
  pull_request:
    paths: [infra/**]
jobs:
  plan:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: hashicorp/setup-terraform@v2
      - run: terraform plan -input=false
  apply:
    if: github.event.pull_request.merged == true
    needs: plan
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - run: terraform apply -auto-approve -input=false

これにより 人月 0.6 相当の運用工数 を削減。開発会社に見積もりを依頼する際は「CI/CD 構築をパッケージ化し、人月単価と切り離して提示してもらう」ことでコスト構造がクリアになります。

セキュリティ設計：SBOM と脆弱性 SLA を契約に埋め込む

生成 AI を扱うため、顧客リスト（個人情報相当）が外部流出しないよう SBOM（Software Bill Of Materials）を必須要件に設定。

• Syft で SBOM 生成 → S3 に保存

• Cosign で SBOM に署名

• Trivy で High 以上の CVE を検出した場合、自動で Slack 通知 & デプロイ中断

この仕組みを RFP に明記し「脆弱性発見から 24 時間以内にパッチ適用を保証できる開発会社」を条件に入札をかけました。結果として 3 社中 1 社に絞り込み、人月単価は平均より 12 % 高いものの 長期運用コストが 28 % 低い という試算を得ています。

UI/UX 改善サイクル：プロダクト分析とヒートマップ統合

ダッシュボードの クリックヒートマップ を PostHog で計測し、LLM 生成コンテンツのクリック率（CTR）と手入力メッセージの成約率を比較。

• 生成文面の開封率：47 %

• 手入力文面の開封率：42 %

• 成約率（資料請求）：生成 6.4 %、手入力 6.1 %

有意差 p < 0.05 を確認できたため、LLM を正式採用し、文面改善ループ を 1 日 3 回自動試行するタスクを Airflow で運用開始しました。
DX 観点での費用対効果は「営業 1 人あたり月 3.1 時間の文面作成削減」。これを年間人件費に換算すると、ダッシュボード開発費の 3.4 倍を 12 か月で回収できる計算です。

モニタリングとオブザーバビリティ設計

本番環境へ移行する際、可観測性 をどれだけ組み込めるかはサービス寿命を決定づけます。今回は Datadog を導入し、APM・ログ・メトリクスを 1 秒粒度で統合しました。特に注力したのは「LLM 推論レイテンシ」と「WebSocket 配信遅延」の相関です。

1. FastAPI の /infer エンドポイントに OpenTelemetry をインジェスト

2. LLM からのレスポンス時間を millisecond 単位でタグ付け

3. WebSocket 送信完了イベントを同一 TraceID で紐づけ

こうすることで「推論に 800 ms 以上かかったときは 97 % の確率で配信遅延が 1 秒を超える」というボトルネックが数値で可視化できました。閾値を超えた場合は Slack に PagerDuty 連携アラートを発報し、SRE がローリング再起動を実行できる運用フローを確立しています。

パフォーマンスチューニング事例――クエリ最適化とキャッシュ戦略

PoC では問題なかったクエリも、本番データ量が 10 倍になると途端に遅延が顕在化します。主な施策は以下の 3 点です。

• 累積ウィンドウ関数の分割：PostgreSQL 14 の ROWS BETWEEN 範囲を日次パーティションに分解し、I/O を 41 % 削減

• LLM キャッシュ：LangChain の LRUCache を Redis に置き換え、温度別プロンプト結果をキーに TTL 30 分キャッシュ

• WebSocket 圧縮：MessagePack 圧縮率を 52 % → 18 % に調整し、帯域を節約

これらにより平均レスポンスを 532 ms → 178 ms に短縮し、Core Web Vitals の INP 指標も「Good」判定へ到達しました。

自動テストと品質保証戦略

LLM 連携システム固有の課題は「期待値が確率分布で揺らぐ」点です。そこでテスト階層を 3 段で構築しました。

特にセマンティックテストでは、LLM が生成した文章を再度 GPT-4 に評価させ「顧客の業界／ニーズとの整合率が 80 点未満なら fail」と自動判定しています。CI で 1 回につき約 0.08 USD のコストですが、リグレッションを抑止できるメリットが大きく、QA 工数を 35 % 削減しました。

チーム運営とコミュニケーションプロトコル

リモート主体の 8 名スクラムで進め、開発会社と社内メンバーを完全に混成 しました。コミュニケーション設計は次の通りです。

• Sync：毎朝 10 分のデイリースクラム（Google Meet）

• Async：Issue／MR ベースで提案→レビュー→マージ。SaaS 側の営業要望は Notion API で自動チケット化

• 合意形成：技術選定やコスト増要件は ADR（Architecture Decision Record）テンプレで 24 時間レビュー

この運営プロトコルにより、ベロシティ変動を ±8 % に抑制でき、予定工数 51 人日の範囲で収まりました。

ロールアウト計画と社内教育

ステージングで 2 週間の Pilot 導入 を実施し、既存ワークフローに与える影響を定量化しました。教育施策は「30 分 e-Learning + 実操作 15 分」のマイクロラーニング形式で、テスト後のアンケート平均満足度は 4.6/5。要因は “AI 文面をクリック→コピー→送信” という 3 ステップで完結する UI を維持したことにあります。研修コストは 1 人あたり 2,400 円で済み、従来の対面研修より 78 % 削減できました。

運用フェーズの KPI 追跡と改善サイクル

本番稼働後は KPI を 3 層に分けてモニタリングしています。

1. システム健全性：APM レイテンシ 95 パーセンタイル < 250 ms

2. 営業プロセス：生成文面開封率 > 45 %、商談化率 > 7 %

3. ROI：AI 推論コスト / 受注粗利 < 0.05

月次レポートを Looker Studio で自動生成し、経営層レビューを 30 分に短縮。LLM プロンプトは週次で微調整し、リード属性ごとにトップ 5 のテンプレートを AB テストで入れ替えています。結果、導入 3 か月で 売上 +12 %、運用コスト ▲18 % を達成しました。

実コスト vs 予算差異分析

当初見積もり 1,280 万円（人月単価 120 万円 × 8.9 人月）に対し、実績は 1,336 万円（差異 +4.4 %）。増加要因は GPT-4o へのモデルアップグレード と Datadog メトリクス超過。一方、Terraform Cloud の利用で環境構築人月を 0.8→0.2 に圧縮し、増加分をほぼ相殺できました。

費用シミュレーションで確認すべきチェックリスト

• LLM 料金の為替変動 (USD 建て)

• APM 監視ツールのホスト課金

• CI/CD minutes 超過料金

• サードパーティ API のリクエスト従量課金

これを Excel テンプレート化して開発会社に提出させることで、隠れコストを可視化できます。

失敗談とリスクマネジメント

LLM の応答がまれに 不適切表現 を含み、営業メールに誤って送信される事故が発生。対策として

1. OpenAI の Moderation API をプリフィルタに追加

2. 「顧客名 + 業界名 + 禁止語」 ルールベースチェックを実装

3. NG 文面は自動で再生成し、人手レビューキューへ送付

これにより不適切率を 0.17 % → 0.008 % まで低減。想定外の応答をゼロにするには、LLM 単体でなく多層フィルタが必要 という教訓を得ました。

今後の拡張ロードマップと開発会社との契約更新

次フェーズでは 音声通話の自動要約 と 予測受注確率モデル を組み込み予定です。契約更新にあたり、

• 成果連動型フィー（新規受注粗利の 2 %）

• 月額保守（15 万円／月, 30 時間分インシデント対応含む）

のハイブリッド課金で合意しました。これにより開発会社のインセンティブを ROI に直接紐づけ、両社が継続的改善にコミットできる体制を構築しています。

まとめと次アクション

LLM 連携ダッシュボードは「既存データ × 生成 AI × 高速 UI」を軸に、半年で営業利益を 2 桁押し上げました。要点は以下の通りです。

• 要件定義：KPI を 3 階層で定量化し、スコープを固定

• 技術選定：FastAPI × LangChain × Next.js で高速ローンチ

• 費用対効果：LLM 推論コストをキャッシュ & オンプレ移行計画で最適化

• 開発会社選定：SBOM と GPU IaC 経験を RFP に盛り込む

• 運用改善：ヒートマップ / APM / KPI ダッシュボードで PDCA を高速回転

今後、生成 AI は API 料金低下とモデル多様化が進み、さらに導入ハードルが下がる見込みです。「小さく作り、早く回し、数字で語る」 を徹底し、システム開発依頼時の費用対効果を最大化しましょう。