# リース既存顧客深耕提案 — 運用ガイド

## 基本情報

| 項目 | 内容 |
|------|------|
| 業種 | リース |
| ユースケース | リース既存顧客深耕提案 |
| WFパターン (v3) | `start(6変数) → kr1(知識検索 top_k=4) → llm1(JSON抽出, temp=0.2, retry×2) → llm2(Markdown整形, temp=0.5, retry×2) → end` |
| RAG | あり (4文書: 稟議パターン/業種テンプレ/競合対比/脱炭素制度) |
| 検証結果 | v3 E2E pass (2026-05-26, 4,774文字, 4/4 keys hit, 顧客固有引用 9/10, 162.9s, 22,983tokens, gpt-5-mini) |
| デモURL例 | テスト実行時に自動生成 (cleanup ルールにより都度削除) |

## 概要

既存顧客の **過去のリース取引履歴** と **社内稟議履歴** を踏まえて、
今回検討中の物件に対する「次の一手」を以下4セクションで生成する営業提案支援エージェント。

1. **提案方針** — 戦略ストーリーと差別化ポイント（金利だけで戦わない論点を必ず含む）
2. **想定ニーズ** — 顕在ニーズ（入力中の根拠付き）と潜在ニーズ（経営層/現場/財務の3視点）
3. **トークスクリプト** — 営業現場で使えるQA形式 3-5本（過去稟議の固有事実を引用）
4. **提案書叩き台** — エグゼクティブサマリ／推奨スキーム／概算月額表／競合比較／次のステップ

## 既存UCとの差別化

| | 「リース営業提案書生成」 | 「リース既存顧客深耕提案」(本UC) |
|---|---|---|
| 想定顧客 | 新規見込み顧客 | 既存顧客（過去取引あり） |
| 主な入力 | 企業情報＋設備見積 | 顧客業種＋**過去取引履歴**＋**稟議履歴**＋今回検討物件 |
| 主な出力 | 提案書ドラフト | 提案方針／**ニーズ仮説**／**トークスクリプト**／提案書叩き台 |
| 営業現場での使い方 | 初回提案資料の即時生成 | 役員会前の戦略策定／反論対策の事前訓練 |

## デモ手順

1. DDF Web UI (`/dashboard`) を開く
2. 「リース既存顧客深耕提案」の「デモ生成」ボタンをクリック
3. 業種「リース」、UC「リース既存顧客深耕提案」が自動入力される
4. 「デモ生成開始」をクリック
5. 生成完了後、デモURLを顧客に共有

## テスト入力例（抜粋）

```
■既存顧客
株式会社みらい物流（中堅運送業／埼玉、420名、売上78億円）

■過去のリース取引履歴
2018年: 中型トラック12台（5年リース・1.8億円）— 再リース継続中
2020年: フォークリフト8台（4年・3,200万円）— 買取済み
2022年: WMS（5年・6,500万円）— 残り1年
2023年: 営業所什器（4年・1,200万円）

■今回検討中
・EV配送トラック15台（1.5億円）
・倉庫太陽光＋蓄電池（8,000万円）
・倉庫AMR 10台（6,000万円）
総額 約2.9億円

■社内稟議履歴
2018: CFOキャッシュフロー平準化評価で1回通過
2020: 当初却下→残価設定型に修正して通過
2022: 役員会「5年は長い」指摘→保守込みで通過
社長「環境投資はやる、ただし数値根拠を出せ」
CFO「3億超は役員会＋大株主説明が必要」

■競合
地場銀行系リース 金利1.7%
```

## 顧客への説明ポイント

- 「**過去の稟議パターン** を学習に使うので、その顧客固有の意思決定文脈を踏まえた提案ができます」
- 「営業担当が変わっても、過去の取引・稟議履歴さえ渡せば同じ品質の提案戦略が出力できます」
- 「Self-hostedなので、御社の顧客台帳/稟議データは外部に出ません」

## v3 アーキテクチャ

```
start (6変数)
  ├ industry              (paragraph, required)
  ├ past_deals            (paragraph, required)
  ├ target_assets         (paragraph, required)
  ├ approval_history      (paragraph, required)
  ├ competitor_info       (paragraph, optional)
  └ query                 (paragraph, optional)  ← ナレッジ検索焦点
   │
   ▼
kr1: 知識検索 (knowledge-retrieval)
  - dataset_ids: [__KR_0__] (4文書: 稟議パターン/業種テンプレ/競合対比/脱炭素制度)
  - retrieval_mode: single, top_k: 4
  - query_variable_selector: [start, query]
   │
   ▼
llm1: 顧客分析・構造化JSON抽出
  - model: gpt-5-mini, temperature: 0.2
  - 入力: 5変数 + {{#kr1.result#}}
  - 出力: customer_profile / past_deals_summary / current_proposal_targets /
          approval_constraints / manifest_needs / latent_needs / proposal_strategy /
          talk_scripts / proposal_outline を厳密JSONで返す
  - retry_config: retry_count=2, retry_interval=200ms
   │
   ▼
llm2: 提案書叩き台 Markdown 整形
  - model: gpt-5-mini, temperature: 0.5
  - JSON を読み取り、4セクション固定構成のMarkdownに整形
  - retry_config: retry_count=2, retry_interval=200ms
   │
   ▼
end (result: Markdown)
```

### v1 → v2 → v3 進化

| 観点 | v1 | v2 | v3 |
|---|---|---|---|
| 入力 | query 単一 | 5変数 | 6変数(+検索焦点) |
| LLM | 1段(0.6) | 2段(0.2/0.5) | 2段+RAG |
| 出力 | Markdownのみ | +中間JSON | +業界知見引用 |
| 障害耐性 | なし | retry×2 | retry×2 |
| 時間/トークン | 69.5s / 10K | 117.2s / 19K | 162.9s / 23K |
| 顧客固有引用 | 高 | 高 | 高(9/10) |
| 業界事例引用 | なし | なし | **明示的に引用** |
| 参考UC | — | 銀行/不正疑い報告 | +生命保険/約款QA(RAG) |

### ナレッジベース構成

`knowledge/` 配下4ファイル (検索時 top_k=4 で全文書ヒット):

| ファイル | 内容 | 主な利用シーン |
|---|---|---|
| `稟議通過パターン事例集.txt` | 車両/倉庫自動化/環境設備/IT/役員会閾値別の通過パターン | トークスクリプトの反論対応 |
| `業種別リース活用テンプレート.txt` | 物流/製造/医療/小売/建設の典型パッケージ | 推奨スキームの構成 |
| `競合対比_銀行系vs専門系.txt` | 金利以外の差別化7観点 | 競合比較セクション |
| `脱炭素関連制度2026.txt` | EV/太陽光/蓄電池/省人化の補助金・税制 | 期待効果セクションの数値根拠 |

## AI品質評価コメント

v3 E2E pass (2026-05-26)。同じみらい物流入力に対し、162.9秒で4,774文字を生成。
顧客固有事実の引用品質は v2 と同等を維持しつつ、RAG により業界横断ナレッジが自然に織り込まれた:

- **トークスクリプト**: 「業界事例ではEV車両はバッテリー残価リスクに対し容量保証(年率劣化スライド)を付けると稟議が通りやすくなっています(社内ナレッジ)」のように **固有事実+業界事例の二段引用**
- **提案書叩き台**: 「社内ナレッジに基づく対応」「PoC段階導入が有効(社内ナレッジ)」のように検索結果を根拠として明示
- **想定ニーズ**: 潜在ニーズの推察根拠に「社内ナレッジ: 物件・期間別の分割契約で各案件を閾値未満に抑えるテクニックが有効」を引用

v2 と比べて時間1.4倍・トークン1.2倍のオーバーヘッドだが、業界知見の自動引用は競合(銀行系リース提案ツール)に対する大きな差別化となる。

## デプロイ上の注意

本UCは `postprocess_yaml()` を **通してはいけない**。理由: `_force_start_query_var` が start variables を `query` 単一に強制書き換えてしまい、6変数構成が壊れる。

デプロイ時は手動で `__KR_0__` placeholder を実 dataset_id に置換する:

```python
yaml_content = yaml_raw.replace("__KR_0__", dataset_id)
app_id = dify.import_workflow(yaml_content)
```

参照: `scripts/test_leasing_deepening.py` (E2E スモークテストスクリプト)。
`orchestrator.run_pipeline()` 経由の fast-path は `_find_verified_yaml` が bundle layout 未対応のため効かない (既知問題)。

## 次のステップ（受託提案）

1. 顧客の実データ（CRM/Salesforce/独自台帳）でカスタマイズデモ（POC: 5-10万円）
2. 過去稟議の社内ナレッジをRAG化（KR添付に切替）して精度向上
3. CRM連携（Salesforce、kintone、独自台帳）でワンクリック実行化
4. 提案書PDF自動生成（Markdown→PDFパイプライン）の追加