0. 目的

ユーザーに「良い質問（分析の切り口）」を考えさせず、システム側が 状況に応じた質問候補を提示し、ユーザーは選ぶだけで分析を開始できるようにする。

• 目標：ゼロ入力でも分析開始できる（テンプレ質問＋パラメータ選択）
• 目標：質問の選択後、nlq-dev が DeciKGにCypherを投げて根拠付き結果を得る
• 非目標：DeciKGにサジェスト生成をやらせない（DeciKGは実行器）

---

1. 全体アーキテクチャ（責務分離）

1.1 nlq-dev（Suggestion Orchestrator）

• サジェスト候補の生成
• UI表示用の「質問カード」組み立て
• パラメータ選択（期間/組織/担当/カテゴリ等）
• Cypher生成（テンプレ or NL→Cypherは将来）
• 実行結果の要約・説明（根拠の構造化）
• 実行ログと効果測定（クリック率、採用率）

1.2 DeciKG（Query Executor）

• Cypher を受け取り、Neo4jで実行
• 結果と根拠（ノード/リレーションのパス、集計値）を返す
• 更新・学習・提案は担当しない

---

2. サジェストの基本型（Suggestion Types）

サジェストは以下の型の組み合わせで作る。営業/製造/販売購買に依存しない。

Type A: 状態サマリからの「次の一手」

• “今この対象はどうなっている？”の確認 → 次のアクション候補を提示
• 例：案件一覧→「上位の根拠を見る」「担当別に比較」「期間で推移」

Type B: 例外・逸脱の検知（Anomaly）

• 平常から外れた対象を抽出して提示（アラート型）
• 例：活動が急減、進捗が止まった、品質指標が悪化、納期遅延兆候

Type C: 成功/失敗パターン（Outcome-driven recipe）

• 過去の結果ラベル（成功/失敗/遅延/返品など）を教師として特徴を抽出
• “語彙”がなくても、まずは 構造・数量・頻度で成立

Type D: 探索（Discovery）

• “近いが見ていない関係”や “関連が強そうな組” を提示
• 例：顧客×活動、工程×不良、仕入先×納期、在庫×欠品

---

3. サジェストカード仕様（UI/データ構造）

3.1 SuggestionCard（最小フィールド）

• id: stable id（テンプレID + パラメータハッシュ）
• title: 1行（例：「フォロー優先の対象を確認」）
• description: 2–3行（何が分かるか）
• type: A/B/C/D
• intent: rank | compare | explain | trend | drilldown
• params_schema: UIで選べるパラメータ定義
• cypher_template: パラメータ差し込み式（v0.1はテンプレ推奨）
• result_contract: 結果の形（表/ランキング/グラフ/説明パネル）
• evidence_contract: 根拠の形（集計値・パス・サンプル）

3.2 パラメータ（共通）

• scope: company/site/plant/org（組織スコープ）
• time_range: period/date（期間）
• actor: user/rep/operator/buyer（主体）
• entity_filter: entity type / status / category
• thresholds: 上位N、最小件数、比率など

---

4. 具体例（抽象テンプレ）—そのまま実装できる形

以下は「ビジネス領域に依存しないテンプレ」です。
実データのラベル名や関係名は DomainGuide/マッピングで差し替える想定。

---

例1：フォロー優先（Rank）

カード

• title: 「フォロー優先の対象（停滞×シグナルあり）」
• type: B（逸脱）
• intent: rank
• 使いどころ：営業案件、製造オーダ、購買発注、サポートチケット

ロジック（抽象）

• Target（例：Opportunity / WorkOrder / PurchaseOrder / Ticket）
• Signal（進捗・兆候・イベントの集合）
• Activity（コミュニケーション/作業ログ）
• “SignalがあるのにActivityが少ない/止まっている”を上位化

パラメータ

• time_range, scope, top_n, signal_min, activity_max

---

例2：リスクアラート（Explain）

カード

• title: 「失敗・遅延に近いパターンの対象」
• type: C（Outcome-driven）
• intent: rank + explain
• 使いどころ：失注/遅延/不良/返品/欠品など “結果ラベル” がある領域

ロジック（抽象）

• Outcome（成功/失敗/遅延など）
• 過去の失敗に多い特徴（例：Signal停止、Activity減、QualityEvent増）をスコア化
• 上位対象の “根拠” を同時に提示

パラメータ

• time_range, scope, outcome_type, top_n

---

例3：案件化前（もしくは作業開始前）の温度（Rank）

カード

• title: 「まだ対象化していないのに温度が高い相手/地点」
• type: A/B
• intent: rank
• 使いどころ：顧客/仕入先/ライン/設備/品目

ロジック（抽象）

• ActorOrContext（Partner/Supplier/Machine/Product）
• SignalOrTextStat（PhraseStatやイベント統計）
• Target がまだ紐づいていないものを抽出してランキング

パラメータ

• time_range, scope, top_n, min_signals

---

例4：担当者/組織の比較（Compare）

カード

• title: 「担当者/拠点別の活動量×成果を比較」
• type: A
• intent: compare
• 使いどころ：営業担当、製造ライン、購買担当、倉庫

ロジック（抽象）

• Actorごとに、Target数、Activity数、Outcome率などを集計
• “平均との差” を根拠として提示

パラメータ

• time_range, scope, group_by（actor/org/plant）

---

例5：根拠のドリルダウン（Explain/Drilldown）

カード

• title: 「この対象が上位に出た理由を説明」
• type: A
• intent: explain
• 使いどころ：すべて（ランキングの次の画面）

ロジック（抽象）

• 1対象を選んで、関連する Signal/Activity/Outcome のサマリ＋代表サンプルを提示
• 例：関連イベントの直近10件、シグナル上位5件、関係パス

パラメータ

• target_id（選択）、time_range（任意）

---

5. “語彙ベース提案”の扱い（将来拡張）

PhraseStat等に phrase_text/label がある場合は、サジェスト文に語彙を入れられる。
ただし領域が変わる（製造・購買）ので、設計は **「語彙はオプション」**にする。

5.1 推奨：二層構造

• Layer1（必須）：構造・数量・頻度で提案（領域に依存しない）
• Layer2（任意）：テキスト/embedding がある場合のみ語彙を足す

5.2 語彙の例（抽象）

• 営業：価格/決裁/競合/セキュリティ/連携…
• 製造：不良/手戻り/段取り/停止/遅延…
• 購買：納期/欠品/単価/代替/MOQ…

実装上は「語彙辞書」ではなく、テキストがある場合に限り

• 頻出フレーズ top-k
• Outcome差分フレーズ top-k
• クラスタ代表語
  を抽出してカード文言に差し込む。

---

6. 実装チェックリスト（nlq-dev側）

v0.1（テンプレ方式で即リリース可能）

• SuggestionCard schema 実装
• テンプレ10本（A/B/C/Dを混ぜる）
• パラメータUI（期間/スコープ/上位N）
• Cypherテンプレレンダリング
• 実行結果の共通表示（ランキング表＋根拠パネル）
• 実行ログ（card_id、採用、実行時間、結果件数）

v0.2（データに合わせて賢く）

• 分布から threshold を自動提案（分位点）
• Outcome差分の特徴量抽出（構造/数量）
• 代表サンプル（イベント/フレーズ）を根拠として添付

v1.0（NL→Cypherへ）

• Schema introspection の部分注入（対象周辺のみ）
• allowlist / read-only / validation loop
• 失敗時のリカバリ（テンプレへのフォールバック）

---

7. 追加で用意しておくと「あとで思い出せる」メモ

• サジェストは **“ユーザーに考えさせない”**のが目的
  → まずテンプレで勝つ。NL→Cypherは後から。
• DomainGuide/ラベル差し替えが前提なので、テンプレは **抽象ノード（Target/Signal/Outcome/Activity/Context）**で設計する。
• PhraseStatのようなテキスト系は「あるなら使う」だが、なくても成立するサジェストを先に揃える。

---

必要なら次のステップとして、上のテンプレを 「Target/Signal/Outcome/Activity/Context」マッピング表（業務領域ごとの差し替え表）にして、営業/製造/購買の3種類で例を並べた“実装用チートシート”も作れます。

今は質問をするテキストボックスとSQLや表グラフを表示するのをタブで切り分けるようなUIです。これを実現したとして、これを最適化するようなUIはどのようなもので、プロンプト的なつくりはどのようになるでしょうか。上記はバックエンドして作るとして、フロント側の仕様を教えてください。そのままデザイナとコーダーに伝わるように。いまの仕組みを踏襲するのもありですが、まったく新しいUIにしてもよいかなと思います。サジェスト機能があるのなら。

以下は デザイナ／コーダーにそのまま渡せるレベルで、サジェスト前提の「最適化UI仕様（v0.1）」です。
（いまの「質問テキストボックス＋SQL/表/グラフをタブで切り分け」も踏襲できるように、互換ルートも残しています。）

---

NLQ UI 仕様案（Suggestion-first / Query-first 併用）

1. UIコンセプト

ゴール

• ユーザーが「質問を考えなくても」分析開始できる
• 自然文入力は “上級者のショートカット” に格下げ（消さない）
• 1回の実行で「結果」「根拠」「次の一手」が必ず出る

画面構成（推奨）

2ペイン + 右ドロワー（最も運用しやすい）

• 左：質問/サジェスト/条件（入力・提案・絞り込み）
• 中央：結果ビュー（表/グラフ/ネットワーク/要約）
• 右：根拠・実行詳細（Cypher/SQL/統計/ログ）

---

2. 画面レイアウト（デザイナー向け）

2.1 ヘッダー（固定）

• タイトル：Analytics
• 右上：
  • Scope（会社/拠点/プロジェクト等）
  • 期間（Quick: 7日/30日/四半期 + カレンダー）
  • 保存（Save View）
  • 履歴（History）
  • 設定（Advanced）

2.2 左ペイン：Query Composer（入力領域）

セクションA：モード切替（トグル）

• Suggest（推奨） / Ask（自由入力） / Build（フィルタ組立：将来）

初期は Suggest をデフォルト。

セクションB：Suggest（カード一覧）

• カードは 10〜15枚（カテゴリ別に折りたたみ）
  • Follow / Risk / Compare / Trend / Discover
• カード要素：
  • Title（1行）
  • Description（2行）
  • Tag（type: A/B/C/D）
  • 必須パラメータ（chipsで表示：期間/担当/対象 等）
  • CTA：Run

セクションC：Ask（自由入力）

• 1行入力＋拡張（Enterで実行）
• 下に “候補の補助” を出す：
  • 「こう言い換えると精度が上がる」候補
  • 「曖昧な条件（期間/対象/スコープ）を補う」質問

セクションD：Parameters（共通の条件）

カードでも自由入力でも共通で効くフィルタ：

• Scope（Company/Plant/Org）
• TimeRange（必須）
• Actor（任意：担当者/部署）
• Limit（TopN）
• Advanced（閾値：min_signal, max_activity など）※最初は隠す

---

3. 中央：Resultビュー（コーダー向けコンポーネント構成）

3.1 結果タブ（旧UI互換）

中央ペイン上部にタブ（今の仕組みを踏襲可能）：

• Summary（必須）
• Table
• Chart
• Graph（Neo4jネットワーク）
• Details

“SQLタブ”は右ドロワーに移動推奨（一般ユーザーは見ないため）

3.2 Summary（必須：常に出す）

カード/質問の実行結果の要約を固定の型で表示：

• ① 結果件数・対象・期間
• ② 上位3件のハイライト
• ③ 根拠の短文（例：Signal多い/Activity少ない 等）
• ④ 注意（欠損、データ品質、制約）
• ⑤ 次の一手（関連サジェスト 3つ）

3.3 Table

• ランキング or 一覧（ソート・フィルタ・ページング）
• クリックで Drilldown（右ドロワー＋中央の詳細へ）

3.4 Chart

• 自動選択：
  • 時系列なら line
  • 比較なら bar
  • 構成比なら stacked
• 手動切替も可能（dropdown）

3.5 Graph（Neo4j）

• ノードを中心に「根拠パス」を可視化
• 初期表示は重くしない（最大ノード数制限）
• 「Expand」ボタンで周辺展開

---

4. 右ドロワー：Evidence & Execution（根拠・実行詳細）

4.1 Evidence（一般ユーザー向け）

• “なぜこれが出たか” を構造化表示
  • Related Signals（件数/種類）
  • Related Activities（EmailEvent等）
  • PhraseStats（ある場合のみ）
  • Outcome（ある場合のみ）
• “欠損”があればここで明示
  • 例：EmailEvent without opp link: 83

4.2 Execution（開発者/上級者向け）

• Cypher（コピー）
• SQL（ある場合）
• Timings（生成/実行/描画）
• Version（schema hash / prompt version）
• Warnings/Errors（ユーザー向け要約＋内部詳細）

---

5. 動線（ユーザー体験）

5.1 新規ユーザー（最重要）

1. Suggestタブを開く（デフォルト）
2. カードを選ぶ
3. 期間とスコープだけ選ぶ
4. Run
5. Summaryで理解 → Next Suggestions をクリック

→ 自然文入力ゼロで回る

5.2 上級者

1. Askタブで自然文入力
2. 足りない条件は UI が補完（期間・対象）
3. 実行
4. ExecutionでCypher/SQL確認

---

6. フロントのAPI契約（最低限）

6.1 Suggest一覧取得

GET /suggestions?scope=...&locale=ja_JP
返却（例）：

• cards[]（id, title, description, type, params_schema, default_params, preview_query(optional)）

6.2 実行

POST /run
Request:

• mode: suggest | ask
• input_text（askのみ）
• suggestion_id（suggestのみ）
• params（共通：time_range, scope, actor, thresholds, topN）
• output: summary/table/chart/graph（要求するビュー）

Response（共通）：

• summary（テキスト＋メトリクス）
• table（columns/rows）
• chart_spec（簡易Vega or 独自フォーマット）
• graph（nodes/edges）
• evidence（counts + sample paths）
• execution（cypher/sql/timings/warnings/errors）

---

7. プロンプト（nlq-dev側設計の形：UIと噛み合う作り）

UIが Suggest-first なら、プロンプトは「自由生成」ではなく テンプレ＋可変部にします。

7.1 Suggestプロンプトの基本構造

• System: “読み取り専用。安全。結果はcontract形式で返す。”
• Developer: “このsuggestion_idの意図は○○。Target/Signal/Outcome/Activity/Contextのマッピングはこれ。”
• User: params（期間/スコープ/閾値）＋「返すべきビュー」指定

重要：UIが必要とする出力形式を固定

• summary（短文3つ）
• table（ランキング）
• evidence（根拠の件数＋代表サンプル）

7.2 Askプロンプトの基本構造

• 先に軽量分類：
  • 主語（Targetは何か）
  • 期間はあるか
  • スコープはあるか
• 足りなければ UIに質問を返す（“確認が必要”を返す）
  • 例：「期間が不明。直近30日でよいですか？」
• OKなら Cypher生成 → EXPLAIN → 修復1回 → 実行

---

8. 既存UIを踏襲する場合の最小改修案（保守的ルート）

いまの「入力＋タブ」を維持しつつサジェストを入れるなら：

• 入力欄の上に Suggestion の横スクロール（カード）を追加
• カードを押すと入力欄に自然文が埋まり、Runで実行
• 結果タブはそのまま
• 右側に “根拠” タブだけ追加（Cypher/SQLは既存タブでもOK）

→ 最小工数でサジェスト導入できる

---

9. デザイナーに渡す画面一覧（成果物）

1. Home / Suggestions
2. Result / Summary（＋Next Suggestions）
3. Result / Table + Drilldown
4. Result / Graph（根拠パス表示）
5. Ask mode（自然文＋補完）
6. History / Saved Views

---

10. 推奨案（結論）

• 新UIにするなら：2ペイン＋右ドロワー（Suggest-first）
• 現行踏襲なら：横スクロールカード追加＋根拠タブ追加（最小）

---

必要なら次に、あなたのプロジェクト流に合わせて「Figma用ワイヤーのテキスト指示」を作ります。
どっちの方向で行きますか？

• A) 新UI（Suggest-first 2ペイン）
• B) 現行踏襲（タブUIにサジェスト追加）

nlq-devと同じシステムの中ですが、もうDeciKGの中で作ってもいいかなと思いました。サジェスト版あります、オプション月２０万ですが、、みたいなサービスにして。

いいと思います。むしろ **「DeciKGを“質問を返す装置”に限定」**という当初方針を保ちつつも、商用オプションとして“Suggest（質問提案）”をDeciKGの同一システム内に同梱するのは、売り方としてすごく筋が良いです。

ポイントはこれです：

• コア（必須）：DeciKG = 実行器（Cypher/SQLを安全に実行して根拠を返す）
• 有償オプション：Suggest = 「次に聞くべき質問」を自動生成・自動更新・学習/ランキング
  → 価値がわかりやすい（“使える”をすぐ体験できる）
  → データ構造や業種が変わっても提供できる（抽象テンプレが効く）

以下、サービス設計／商品設計／実装設計を「そのまま開発に移れる」形でまとめます。

---

DeciKG Suggest Option（有償）仕様案 v0.1

1. 商品設計（メニュー）

プラン構成

• Core（標準）
  • 質問（自然文 or テンプレ）→ Cypher/SQL → 実行 → 結果＋根拠
  • 監査ログ、実行制限、セキュリティ
• Suggest Option（月20万）
  • サジェストカードの自動生成（テンプレ＋データ駆動）
  • サジェストの自動更新（毎日/毎週）
  • “成功/失敗パターン”など上位機能の段階解放
  • UIで「選ぶだけ」で分析開始（初心者向け導線）

オプションの価値（提案文そのまま使える）

• 「ユーザーが質問を考える必要がない」
• 「担当者に依存せず分析が回る」
• 「成果に直結する“次の一手”が出る」

---

2. 技術設計（責務の切り分け）

同一システム内での分離（重要）

DeciKGの中に置くが、モジュールとしては分離しておく：

• decikg.core（実行器・検証器・安全ガード）
• decikg.suggest（有償：提案生成・更新・ランキング）
• decikg.ui（UI提供するなら：カード配信・履歴・保存ビュー）
• decikg.api（エンドポイント。feature flagで出し分け）

“Suggestを入れてもCoreが壊れない”が最重要です。

---

3. 機能要件（v0.1：すぐ売れる最小）

3.1 サジェストカード（固定テンプレ方式）

• カードは 10〜20枚のテンプレを用意（業種非依存の抽象テンプレ）
• 期間・スコープ・担当などのパラメータ差し替えで実行可能
• 各カードは “結果形式” を固定（Summary＋Tableが基本）

3.2 サジェストの配信

• GET /suggestions でカード一覧取得
• POST /run に suggestion_id と params を渡すと実行できる

3.3 ランキング（軽量）

• v0.1では「クリック率」「最近使われた」「組織で人気」程度のランキングでOK
• データ駆動の高度な推薦（成功パターン抽出など）は v0.2+

---

4. フロント仕様（Suggest Optionを売るUI）

Suggestを“見せる”UIがそのまま商材になります。

4.1 画面の入口（重要）

• Coreユーザーには：Suggest タブを 非表示 または “Locked”
• Option契約者には：Suggest タブが解放される

Locked 表示例（そのまま文言にできる）

• 「Suggest（質問提案）を有効化すると、選ぶだけで分析を開始できます」
• 「オプション：月額 200,000 円」
• ボタン：問い合わせ / デモを見る

4.2 Suggest画面（体験価値を最大化）

• カテゴリ：
  • Follow（次にやるべき）
  • Risk（危険兆候）
  • Compare（比較）
  • Trend（推移）
  • Discover（探索）
• カードを押すだけで実行
• 実行後：
  • Summary（要約）
  • Table（ランキング）
  • Evidence（根拠）
  • Next Suggestions（関連カード3つ）

ここが「質問できない人でも使える」UXの核。

---

5. バックエンド実装（DeciKG内に置く場合の構造）

5.1 DB（Postgres）に持つべきテーブル（最小）

• decikg_suggestion_template
  • template_id, title, description, type, params_schema, cypher_template, output_contract, enabled
• decikg_suggestion_event（効果測定）
  • event_id, user_id, template_id, params_hash, action(view/click/run/save), ts
• decikg_suggestion_instance（配信カード、v0.1は不要でもOK）
  • instance_id, template_id, generated_title, generated_description, params_default, rank_score, created_at

v0.1は template + event だけでも売れます。

5.2 Feature Flag / License

• SUGGEST_ENABLED=true/false
• SUGGEST_PLAN=core|option
• APIは SUGGEST_PLAN != option なら 403 or “locked payload” を返す

---

6. 実装ロードマップ（売れる順）

v0.1（今すぐ売る）

• テンプレ10〜20
• Suggestタブ＋カードUI
• 実行導線（Run→Summary/Table/Evidence）
• Locked導線（価格＋問い合わせ）

v0.2（差別化が強くなる）

• “結果ラベル（成功/失敗等）” がある場合の Recipe型提案
• “異常検知”の自動生成（急減/停止/急増）
• サジェストの自動更新（Cron）

v1.0（覇権）

• 自然文→Cypher生成＋バリデーションループ
• Graph探索の自動ガイド（根拠パス提案）
• “提案→実行→学習” の閉ループ

---

7. 重要な設計の注意（破綻しないために）

• Suggestは必ずテンプレで始める（LLM丸投げは後）
• UIの結果は 必ず固定フォーマット（Summary＋Table＋Evidence）
• どの業種でも成立するように、ノードは抽象化（Target/Signal/Outcome/Activity/Context）
• 有償部分は “カード生成・更新・ランキング” に寄せる（Core実行器は共通）

---

もし次の一歩として、

• 「Suggest Option：月20万」提案資料（1ページ）
• API定義（OpenAPI断片）
• テンプレ20本の雛形（抽象テンプレ）
• Figmaに渡すUI文言（Locked含む）

この4点をセットで作ると、実装と営業が同時に進められます。

どれから作りますか？（私はおすすめ順に テンプレ雛形 → UI文言 → API定義 → 1枚資料 です）