主張
「広聴AI（プロダクト）のスコープはキーインサイトの発見まで、その先（政策反映・市民満足度向上）は伴走パートナー側の仕事」 というスコープの線引きは、いま plugin-system や broadlistening-tool-ecosystem-vision で言語化されている戦略の前提になっているが、この線自体は 2025-07 のマーケ戦略 mtg ですでに明示されていた。1 年弱を挟んで一貫しており、後発のブログ・方向性議論・plugin 設計は、この線を別角度から再表現してきたと読める。
時系列
2025-07-16: マーケ戦略 mtg（marketing-strategy-mtg-2025-07-16）
- ボード級メンバーが集まる単発会議。現時点で wiki 上で確認できる、kouchou-ai スコープ線の最古の明示
- 主要主張:
- 政策反映までを射程に入れるなら、ツールだけでなく伴走支援やコンサル的な動きが必要
- だが伴走支援は OSS 開発の範疇ではない
- したがって**「広聴AI というツールが担うのはキーインサイトの発見まで、その先は導入パートナーと共に成功事例を作る」** という線引きを置く
- 参照モデルとして Polis（Colin 開発）と政策化（オードリー・タンのチーム）の役割分担 が引かれている
- このスコープ線と並んで、プロダクト改善ペルソナ ≠ マーケ ペルソナ、自治体ステークホルダーは首長 / 広聴課担当 / エンジニアに分かれる、(P0) SaaS 化（API key 登録で試せる） という方針もすでに置かれている
2025-11-29: 鈴木健ブログ（kensuzuki-broad-listening-insight-types-2025-11-29）
- 「ブロードリスニング」を 1 個の手法として扱うのではなく、欲しいインサイトの種類ごとに使う道具が違う、と整理
- 散布図・クラスタ俯瞰型（TTTC / 広聴AI）はアジェンダ発見向き、Polis は uncommon ground 向き、AI interview は政策深掘り向き、と用途分割
- これは 2025-07 の「広聴AI ＝キーインサイト発見まで」の言い換えとして読める。「広聴AI の射程外」が、用途別の他ツール（Polis / AI interview）として埋まる姿が初めて文章化された
2025-12-06: 広聴AI の方向性について（kouchou-ai-direction-2025-12-06）
- 鈴木健ブログを受けた最初の方向性議論
- 主張:
- 用途別に分析モードを分ける必要
- GUI ノードエディタは重すぎる、カスタマイズは JSON / YAML 的な config でやる方が現実的
- 書籍出版までにすべてを作り直さず、安定版を切って次世代実験を別軸で進める
- 「kouchou-ai 本体はキーインサイト発見モードを担い、それ以外の用途は別モード / 別実装で並行」という発想が、ここから versioning-strategy の v4 安定化 / v5 大規模リファクタへ繋がる
現在（2026-05 〜 06）: plugin-system と broadlistening-tool-ecosystem-vision
- plugin-system: 入力 / 解析 / 可視化を plugin として差し替え可能にする設計。
docs/development/why-plugin-system.mdは採用理由を「互換性を保ちたい vs 新機能を実験したい、というジレンマの打開策。技術的境界で関心を分離し、合意形成によらず並行進化を可能にする」と書いている - broadlistening-tool-ecosystem-vision: Web UI を simple な default モードに絞り、CLI に多様な実験を載せ、コミュニティで共有する二段構造のエコシステム
- ここまで来ると、2025-07 の 「ツール＝キーインサイト発見まで / 伴走＝パートナー」 という外向きの線引きが、「Web UI＝デカい違和感発見 / CLI＝分析者の実験 / コミュニティ＝共有の場」 という内向きの構造分割と入れ子になっている
一貫していること
- 広聴AI を万能ツールとして売らない、という意思は 2025-07 から現在まで一貫している
- スコープを切る目的は当初からマーケ側にあり（「成功事例を作るためにどこを射程にすればいいか」）、後で技術側の事情（pluginization / 互換性 / 並行進化）と整合した
- パートナーの位置づけも、2025-07 時点で具体名（Code for Japan / Polipoli / Polis 役割分担）まで挙がっており、そこから現在の dd2030 エコシステム（idobata / polimoney / decidim 連携）に繋がる
変化したこと
- 2025-07 では「広聴AI のエンジン品質は実用レベルに達していない（鈴木健 私見）」という現状認識が議論の前提だった。具体的には カテゴリ合体・カテゴリミス・ノイズ・キーインサイト発見の弱さ が挙げられていた。これは (P1) エンジン品質 課題として置かれ、その後 label-coverage-policy-2026-05-29 / label-refinement-input-scope-2026-05-29 / 階層ラベリングのリファクタなど 2026-Q2 のラベル品質関連の作業の根 になった
- 2025-07 では「(P2) UI / visualization 改善は優先度低」だったが、2026 では public-ui-requirements-for-broadlistening / ohki-discussion-reflection-2026-05-25 / chart-scroll-ux-decision など UI 系の論点が表に出てきている。これは「キーインサイト発見」スコープを維持したまま 発見をどう reader に渡すか の問題に重心が移ったため、と整理できる
- 2025-07 のペルソナは「自治体担当 / 首長 / 現場」の三層だった。2026 の broadlistening-tool-ecosystem-vision は「一般ユーザ / 組織内デモ役 / 分析者・研究者」の三像で、橋渡し役（=2025-07 でいう「広聴課担当・現場」に近い）が独立の像として明示されている。この『組織内デモ役』は 2025-07 時点では暗黙だった層
なぜこの系譜整理を残すか
- 現在進行形の議論（plugin / Web UI 簡素化 / CLI 拡張 / コミュニティ）が 新しい思想転換ではなく、2025-07 の線引きを技術側から再表現した結果だと見えると、設計判断のブレが減る
- 例えば「Web UI に高度オプションを足すか」という議論が来た時、2025-07 の「広聴AI のスコープはキーインサイト発見まで」と broadlistening-tool-ecosystem-vision の Web UI 簡素化判断が同じ線上にあると分かれば、選択は揺れにくい
- 同時に、2025-07 の「(P1) エンジン品質」課題（カテゴリ合体・ミス・ノイズ）がスコープ線とは独立に解くべき残課題である、という切り分けも明確になる。スコープを縮めても品質課題は消えない
Open Questions
- 2025-07 で挙がったパートナー候補（Code for Japan / Polipoli / decidim 連携）の現状は別途棚卸しが要る。3 年スパンと見立てられていた decidim 統合は今どこにあるか
- 「(P0) SaaS 化（API key 登録で試せる）」は 2025-07 時点で PR 提出済・レビュー待ちと記録されている。それが現在の Azure デモ環境 / SaaS 化議論にどう連続しているかは deployment / Azure デモ環境（Google Drive 管理）の文脈で別に整理が必要
- キーインサイト発見の品質（カテゴリ合体・ミス・ノイズ）の改善作業は、いまどこまで進んでいるか。2025-07 当時の「実用レベルに達していない」という鈴木健の評価は、2026-Q2 のラベル品質関連の作業を経てどう変わったか — これは clustering-labeling-comparison-corpus-2026-06-02 と human-pairwise-label-preference-experiment-2026-06-02 の評価結果がまとまった段階で再確認できる
Updates
- 2026-06-03: 2025-07-16 マーケ戦略 mtg の ingest をきっかけに初版作成。スコープ線が 1 年弱一貫していることを系譜として整理