llm-grouping-background-history は「embedding を前提としない分析様式と散布図中心 product の緊張関係」を時系列で整理したものだが、そこで残っていた 「散布図が担っていた役割を別 view でどう代替するか」 は概念のままだった。
2026-05-23 の slack-public-ui-requirements-2026-05-23 で ohki-shingo がこの問いを明示的に分解し、公開UIに求められる要件 を 7 項目で言語化している。本ページはこの整理を、analysis_mode / view を独立化する設計判断に紐付けて記録するものである。
結論
広聴結果の公開UIに求められる要件は次の 7 項目に整理できる。これは embedding / 散布図とは独立で、long-context LLM 直接分類 / taxonomy-guided / 距離空間ベース のいずれの分析方式でも満たすべき view 側契約である。
- 量の可視化 — どのような声をどれくらい扱ったのか
- 整理の観点の可視化 — どういう観点で整理されたのか
- 主要論点の可視化 — 主要な論点は何か
- 個別意見への辿り — 元の個別意見まで辿れるのか
- 少数意見の埋没回避 — 少数意見や分類しにくい声が埋もれていないか
- 恣意性の排除 — 行政側が恣意的にまとめたように見えないか
- 次の問いの可視化 — 次に何を議論・深掘りすべきかが見えるか
slack-public-ui-requirements-2026-05-23より
なぜ現状の散布図が受け入れられているのか
ohki-shingo は 散布図そのものが本質ではない と整理している。受け入れられているのは、次の 5 要素を 1 画面に同時に出しやすいからである：
- 大量の意見が扱われていることが一目で分かる（→ 要件 1）
- 似た意見ごとに整理されているように見える（→ 要件 2 の暗黙提示）
- 全体像を探索できる（→ 要件 3）
- 要約やラベルだけでなく、個別意見にも戻れる（→ 要件 4）
- 行政側が恣意的にまとめたのではなく、透明性をもって公開しているように見える（→ 要件 6）
つまり散布図の価値は 距離の精密さではなく、これら要件の同時提示にある と読める。slack-public-ui-requirements-2026-05-23より
llm-grouping-background-history が辿った「散布図方式の限界」議論はクラスタリング精度・対立軸埋没・次元圧縮の弊害という 分析側 の限界が中心だったが、本ページの整理は view 側の役割 を切り出している。両者は補完関係にある。
embedding 距離精度の非本質性
要件を逆向きに使うと、view 側に求められる距離精度 の上限が分かる。
- クラスタ間の分離が見える: 必要（→ 要件 2, 3, 5）
- クラスタ内の距離精度: 不要（自然に近く表示されていれば十分）
slack-public-ui-requirements-2026-05-23より
これは llm-grouping-background-history が記録している 2026-Q1 の 「embedding は理論上必須ではないが、移行上は便利な足場」 という slack-design-intents-2026-q1 の判断と整合する。LLM grouping 系分析を散布図互換に射影するための x/y 計算は、semantic distance を高精度に再現する必要はなく、cluster grouping が視覚的に保たれていればよい ということになる。
これは短期の散布図互換案（pipeline の PR #827 計画にある analysis_mode=llm_grouping の x/y 互換）に対する技術的バーを大きく緩める。force-directed 配置・per-cluster local UMAP・LLM ラベルベースの 2D 配置などが、すべて「公開UIとして十分な距離精度を満たす」候補に入ってくる。
analysis_mode / view 独立化との対応
slack-design-intents-2026-q1 と llm-grouping-background-history では、可視化分離は
- 「LLM grouping 系分析を platform に受け入れるための必要条件」（必要性の議論）
として説明されてきた。本ページの 7 項目は、これに 「view 側の充足条件」 を補う。
つまり plugin-system の analysis_capabilities / requirements を設計する時、view plugin の契約は次の 2 層で考えられる：
- 下位契約（既存） — 入力データ構造（cluster tree / embedding 有無 / 個別 argument list など）と機械可読な capability
- 上位契約（本ページ） — 公開UIとして 7 要件を満たすこと
下位契約だけでは「散布図互換だが個別意見に戻れない view」「クラスタ可視化だが少数意見が埋もれる view」が plugin として通ってしまう。上位契約を docs / 設計レビュー側で明示しておくと、view plugin の追加・置換が「公開UIとしての役割を維持できるか」で判断しやすい。
構造把握スタンス / 全体傾向把握ユースケース / 別ツール分業との照合 (2026-05-30 追記)
2026-05-30 に確定した analysis-stance と label-quality-redesign-reset-2026-05-30 の整理 (構造把握スタンス、全体傾向把握ユースケース一本、KJ 原則 5 は別ツール補完) を 7 要件に重ねると、責務が次のように分かれる。
| # | 要件 | 担当 |
|---|---|---|
| 1 | 量の可視化 | 広聴AI 本体 |
| 2 | 整理の観点の可視化 | 広聴AI 本体 (構造把握装置として読ませる) |
| 3 | 主要論点の可視化 | 広聴AI 本体 (構造把握装置として読ませる) |
| 4 | 個別意見への辿り | 広聴AI 本体 |
| 5 | 少数意見の埋没回避 | 別ツール。全体傾向把握ユースケースは exhaustive partitioning に倒れ、minority residual artifact を作らない決定 (label-quality-redesign-reset-2026-05-30) なので広聴AI 本体は担わない |
| 6 | 恣意性の排除 | 広聴AI 本体 |
| 7 | 次の問いの可視化 | 別ツール。境界 / 反例 / bridge / 未解決カードのような interpretation_artifacts 領域は別ツール側 (pipeline-step-addition-framing-2026-05-27) |
つまり広聴AI 本体は 7 要件のうち 5 件 (1/2/3/4/6) を担う。残る 2 件 (5/7) はエコシステム上の別ツール群が担う想定で、本体に常時組み込まない。
これに加えて、構造把握装置の評価軸として 2 件追加 される (analysis-stance より):
- reader が他者に解説できる素材か (reader = 受動的な読み手ではなく、他者に構造を解説する narrator)
- reader の prior mental model と突き合わせやすい素材か (意外性そのものは主観依存で product 範囲外、突合の素材性は product 設計対象)
7 要件は ohki-shingo の整理として価値が残るが、広聴AI 本体の view 設計判断としては 「本体 5 件 + 構造把握の追加 2 軸」 で評価する方が現実に即する。
既存散布図ビューへの含意
現行の apps/client-statics の散布図中心ビューも、この 7 要件で評価できる：
| 要件 | 現行散布図ビューでの担保 |
|---|---|
| 量の可視化 | ◯（点の総数で量感が見える） |
| 整理の観点の可視化 | △（クラスタラベルはあるが、選んだ観点の根拠は弱い） |
| 主要論点の可視化 | △（クラスタ summary は出るが「論点」として整理されているとは限らない） |
| 個別意見への辿り | ◯（点クリックで原文に到達。ただし #710 -> PR #857 で長く壊れていた） |
| 少数意見の埋没回避 | × の傾向（次元圧縮で潰れやすい）llm-grouping-background-historyより |
| 恣意性の排除 | ◯（生意見と分類が同時に見えるため恣意性は弱く見える） |
| 次の問いの可視化 | × （明示的な「次に議論すべき論点」表示なし） |
現行ビューが「△・× を含みつつ、合計として受け入れられている」というのは、強力な要件と弱い要件の組み合わせで成立している、ということでもある。新 view を作る時は、強力な要件（4・6）を維持しつつ、弱い要件（5・7）を改善する方向に倒すと、公開UIとして「散布図より良い」と評価されやすい。
Open Questions
- 7 要件のうち、
#2 整理の観点の可視化と#7 次の問いの可視化は LLM 直接分類 / taxonomy-guided 分析の方が強そうだが、これは ohki-shingo の整理を実装契約に落とせば自然に出るのか、別途設計が要るのか - 自治体利用文脈での自答として整理されているが、選挙・市民参加・社内アンケートなど他文脈でも 7 要件は同じか、文脈ごとに weight が変わるか
- 短期の散布図互換案で、cluster grouping のみ保証する 2D 配置を行うとして、その配置の
決まり方を docs / レポート上でどう開示すれば「恣意性の排除」要件を満たすか - view plugin の契約として、本ページの 7 要件を docs に正式記述するなら、どのページが正本になるか（ここか plugin-system か broadlistening か）
Updates
- 2026-05-30: 用語を descriptive な日本語に統一 (
contract A→ 全体傾向把握ユースケース、β→ 構造把握スタンス / 構造把握装置 など) - 2026-05-30: 全体傾向把握ユースケース / 別ツール 分業 / 構造把握スタンスとの照合セクションを追加。7 要件のうち 5/7 は別ツール側、残り 5 件が広聴AI 本体、加えて構造把握の評価軸 (解説素材性 / 突合素材性) が 2 件加わる、と整理し直した
- 2026-05-23: 初版作成。
#2_開発_広聴aiの 2026-05-23 thread で ohki-shingo が整理した「散布図の受け入れ要因 5 要素」「公開UI 7 要件」「embedding 距離精度の非本質性」を、llm-grouping-background-history が残していた『散布図の役割を別 view でどう代替するか』への回答として再整理