広聴AI 本体の設計判断を貫く core stance を 1 ページで明示する。2026-05-30 の対話で nishio が 広聴AI は定量分析のためのツールではない と整理した時点で確定。以後、設計判断はこのスタンスを起点に絞ること。
2 つの設計スタンス
定量分析スタンス (頻度分布で完結する設計)
「全体を把握する = 何が多く、何が少ないか を測る」という考え方。
- 出力はクラスタ + ラベル + サイズで完結
- クラスタ間の関係 (対立 / 補完 / 因果) は主成果物に含めない
- 散布図など空間的可視化は飾り。本体は頻度分布の一覧
- ユーザが見るのは集計結果。構造を読む責務は持たない
このスタンスを採るツールは存在するし、それで足りる用途もある。だが、広聴AI はこのスタンスではない。
構造把握スタンス (ユーザに構造を読ませる設計)
「全体を把握する = 個別意見の集積 ≠ 全体像。構造を読んでこそ全体把握」という考え方。
- 出力は単なる頻度分布ではなく、ユーザが構造を読み解くための装置
- 散布図 / クラスタ配置 / 階層 tree / drill-down は構造を読ませるための手段
- 構造を artifact として 明示的に抽出して描画する ことまでは含まない。ユーザが読む
- 全体傾向把握は数を数えることではなく、論点空間の輪郭を掴むこと
広聴AI = 構造把握スタンス
広聴AI 本体は構造把握スタンスで設計する。
Web UI / 標準 run が担う唯一の use-case 契約として 「全体傾向把握ユースケース」 (label-quality-redesign-reset-2026-05-30) を置いたが、これは定量分析的な「上位 N トピックの頻度を見る」装置を作ることを意味しない。全体傾向把握ユースケースも、構造把握スタンスで実現する ことが前提である。
tokoroten による operational な言い換えとして、全体傾向把握ユースケースは 「デカい見落とし、デカい違和感を見つける」 装置と表現できる。「全体傾向把握」より具体的で、何を見せ何を見せないかの判断軸として使いやすい。slack-stance-discussion-2026-05-30より
具体的に、広聴AI が構造把握スタンスを実現する手段:
- 散布図 (現状の主図): 意見空間の配置をそのまま読ませる装置
- クラスタ + ラベル + drill-down (現状): クラスタを起点に原文へ戻り構造を読ませる
- 階層 tree: 粗→細の階層構造を見せる
- semantic island map prototype (semantic-island-map-prototype-2026-05-26): クラスタ間とクラスタ内を分けて構造を読ませる検討中の主図候補
これらは「構造を artifact として抽出」していない。ユーザに構造を読ませる 装置として構造把握スタンスを実装している。
「定量分析ツールではない」の意味
このフレーズは「数を数えるなと言っている」のではない。「数を数えるだけで分かったことにするな」と言っている。
含意:
- クラスタサイズが大きいから重要だ、という単純な読みを product として promote しない
- ラベル + サイズの一覧で完結する UI 設計には倒さない (= 定量分析倒れを避ける)
- ただし副次的にはサイズもクラスタ ID も出る。「数えない」ではなく「数える だけ にしない」
reader は「読む人」ではなく「解説する人」
構造把握スタンスの評価軸として「reader が構造を読めるか」だけでなく、「reader が他者に構造を解説できるか / 指さしながら語れるか」 が加わる。reader は受動的に消費する人ではなく、政策担当 / 自治体 / 市民が 他者に向けて構造を (再) narrate する 主体である。レポートが「これを語ろう」というネタを提供できない場合、reader にとってお蔵入りになる。
この「解説する人」の代表例として、組織内デモ役 (橋渡し役) がいる。意思決定者 / 予算決定者に動くレポートを見せる役で、本人はエンジニアでもデータサイエンティストでもない場合が多い。広聴AI の現実の普及はこの層が担うので、構造把握の評価軸 (解説素材性 / 突合素材性) を満たすかどうかは特にこの読者で問われる。broadlistening-tool-ecosystem-vision の「読者像 3 像」も参照。
語りやすさの源を 1 つ言語化すると 「意外 = reader が事前に暗黙に持っていた分類との食い違いの発見」 である。reader は自分の mental model (賛成/反対、コスト/効果 など) を持って来訪し、それと current findings の差分が見えると「あ、これ語れる」になる。
ただし、「何を意外と思うか」は個別主観に依存するので、意外性そのものを product として保証する設計は採らない。product として狙えるのはその一段手前、「reader が自分の prior mental model と突き合わせやすい素材」を提供すること である。
- ❌ 意外性を生成する装置 (主観依存で保証不能)
- ✅ 突合素材を提供する装置 (主観は reader 側に置く)
散布図はこの意味で強い: reader 側で「自分の中で色分けしたら」「自分の分類なら何と名付けるか」「自分の粒度ならどう切るか」を重ね合わせやすい。一方クラスタ + ラベル + サイズの一覧 (定量分析倒れの想像形) はこの突合がしにくい。構造把握装置の design 判断は「突合しやすさ」を物差しとして使える。
なお「解説素材として強いレポートとは何か」「お蔵入りの境目」は個別主観依存なので、product 機能ではなく、別ツールや運用 / リテラシー側で扱う領域である。
構造把握装置の構造的限界 — 「止まる」現象
ohki-shingo の観察: 「広聴AI が生成したレポートを見て、インサイトを見つけられなくて、うーん、となってそこで止まる」。これは 構造把握装置の構造的帰結 として説明できる。reader 側に prior mental model がない、または prior model が current findings と一致している場合、突合材料があっても「差異 = 意外性」が生まれず、解説する動機が発生しない。slack-stance-discussion-2026-05-30より
含意: 構造把握装置を磨いても、prior model を持たない reader には届かない。これは product の限界として team alignment 済み (reader 側の能力 / 文脈に委ねる)。ohki-shingo が挙げた「すでにある総合計画に対して、意見がどうマッピングされるのか、されないのか」のような 明示的な prior model を持つ運用 が、構造把握装置が最も活きる場面である。
Web UI の UX 指針
Web UI の reader は自分のやりたいことを「全体傾向把握 / 構造把握 / 詳細探索」のような解像度で区別できないことが多い。したがって (やりたいこと) を選ばせる UI は機能しない。代わりに次の方針で設計する。slack-stance-discussion-2026-05-30より
- デフォルトモード として「デカい見落とし / デカい違和感を見つける」 (= 全体傾向把握ユースケース) ビューを提供する
- 反応を見て別 view を案内する事後誘導型 UX に倒す
- 「ざっくりモード (上位クラスタ少なめ、散布図向き) / 詳細モード (クラスタ多め、ツリービュー向き)」程度のモード切替は用意しうる
- ただし選択強制すると「どっちを選んだらいいですか」問題が生まれるので、サンプル分析結果カタログ で見比べ可能にする補助が要る
- ユーザカスタム prompt や複雑な分析手法選択は CLI 側 (broadlistening-tool-ecosystem-vision)
エコシステム — CLI と共有コミュニティ
構造把握スタンスを貫きつつ、artifact 抽出機能 (KJ 法 6 原則の #3 #4 #5 系) や少数意見救出系は別ツールに分業する、という基本方針 (label-quality-redesign-reset-2026-05-30) は、具体的には CLI に多様な実験機能を積み、コミュニティ内で試行錯誤と共有を促す 形で実装する。詳細は broadlistening-tool-ecosystem-vision を参照。
構造把握スタンスと「別ツールで補完」の分業
KJ 法的 6 原則 (kj-method-broadlistening-framing-2026-05-25) のうち #3 (表札の人間吟味) / #4 (少数残存) / #5 (構造を示す = 対立・因果) は、2026-05-30 の対話で 広聴AI 本体には入れず、別ツール群で将来的に補完する 方針となった。これは構造把握スタンス採用と矛盾しない。
整理:
- 広聴AI 本体 = 構造把握スタンスを貫く装置。ユーザに構造を読ませる UI / 可視化 / drill-down を持つ
- 別ツール = 構造把握スタンスの中で具体 artifact を抽出する装置。対立カード、因果図示、表札人間吟味、minority residual extraction など
- 両者は「構造把握スタンス」を共有しつつ、責務を分業する
つまり構造把握スタンス採用は「広聴AI が全部やる」を意味しない。広聴AI は構造把握の入口、artifact 抽出ツール群は構造把握の出口、というエコシステム設計。
派生する設計判断
構造把握スタンス確定により、以下の判断が自動的に方向づく。
- 散布図維持 (open-decisions A1): 散布図は構造把握スタンスの主要装置なので、より良い候補が見つかるまで温存。代替候補は構造把握として評価する
- semantic island map prototype の位置づけ: 構造把握用の主図候補として広聴AI 本体に入る可能性を持つ。「別ツール候補に倒れた」のではない
interpretation_artifactsstep を切るか (pipeline-step-addition-framing-2026-05-27 / thinking-targets 3-1): 構造把握スタンスだが、artifact 抽出は別ツール側なので、広聴AI 本体には入れない方向に倒れる- 継続関与 (thinking-targets 1 系の #6): 「構造を読ませる」装置を時間軸方向に拡張する設計として整合する。継続的に構造を読み続けるための支援は構造把握の延長
- 公開UI 7 要件 (public-ui-requirements-for-broadlistening): ohki-shingo の整理は構造把握寄り。スタンス確定により、公開UI 側の上位契約として整合性が増した
Open Questions
- 構造把握用の主図として散布図と semantic island map のどちらが筋がよいかは、prototype 評価結果待ち。判定基準は「ユーザが構造をどれだけ読めたか」(任意の operationalization は未定)
- 「ユーザに構造を読ませる」を product としてどこまで支援するか (例: 構造を読むための onboarding tutorial を入れるか、untrained user 向けの hint を出すか) は未決
- 「数えるだけにしない」を Web UI 上でどう visual に防ぐかは未決 (クラスタサイズを大きく出すと定量分析倒れを誘発する可能性)
- 別ツール群がエコシステム上どこに存在すべきかは未整理 (社内 / OSS / 個別開発)
Updates
- 2026-05-30: 用語を descriptive な日本語に揃え直した。
α / β スタンスを定量分析スタンス / 構造把握スタンスへ、β 装置を構造把握装置、β 評価軸を構造把握の評価軸、contract Aを全体傾向把握ユースケースなどに置換。短いラベルは時間が経つと文脈なしには読めなくなるため、内容で読める表現に統一 - 2026-05-31: 「reader は解説する人」セクションに 「組織内デモ役」(エンジニアでもデータサイエンティストでもない橋渡し役) を代表例として追記。広聴AI の現実の普及はこの層が担うので、構造把握の評価軸はこの読者で特に問われる
- 2026-05-30: Slack team channel での議論 (slack-stance-discussion-2026-05-30) を反映。(1) 全体傾向把握ユースケースの operational 言い換え「デカい見落とし / デカい違和感を見つける」を tokoroten が提示、(2) 「止まる」現象を構造把握装置の構造的限界として整理 (prior model がない reader には届かない、ohki-shingo 確認)、(3) Web UI の UX 指針としてデフォルトモード提供 + 反応事後誘導型を明文化、(4) エコシステム = CLI + 共有コミュニティ (broadlistening-tool-ecosystem-vision 新設) へ接続
- 2026-05-30: 「reader は解説する人」セクションを追加。構造把握装置の評価軸に「reader が他者に解説できるか」を加え、語りやすさの源を「事前 mental model との食い違い発見 = 意外性」と言語化。意外性は主観依存で product 範囲外、product として狙えるのは一段手前の「突合素材を提供する」という線引きを明示。散布図の構造把握装置としての強さもこの「突合しやすさ」で再評価できる
- 2026-05-30: 初版。2026-05-30 の thinking-targets 対話で nishio が構造把握スタンスを正解と明示し、
広聴AI は定量分析のためのツールではないという core stance を言語化したのを受けて作成。全体傾向把握ユースケース確定 (label-quality-redesign-reset-2026-05-30) との関係も整理