[[slack-dev-kouchouai-2026-q1]] を読むと、2026-Q1 の広聴AIは「機能を足している」のではなく、分析手法を差し替えられるプラットフォームへ移る途中 だったことが見える。ここでは Slack から読める実装意図を整理する。

1. レポート再利用は「便利機能」ではなく分析比較の前提

slack-dev-kouchouai-2026-q1 より、nishio は 2026-01-21 週に「違う分析を比較したいなら、入力データや extraction, embedding の再利用がセットで欲しくなる」と書いている。
同 source の 2026-02-04 週では「同一データ、同一抽出、同一埋め込み」の条件でクラスタリング手法の違いを見せられることが、再利用機能の意味として語られている。

つまり再利用機能は、単に計算節約や「前のレポートを複製する」ためではなく、分析 plugin を比較実験できる土台 として先に必要だった。「複製」ではなく「再利用」 と言い換えたのも、この設計意図に合う。

2. plugin 化のUX目標は「エンジニアが差し込み、非エンジニアが使う」

slack-dev-kouchouai-2026-q1 2026-01-21 週では、TTTC から引き継いだ理想として「非エンジニアがレポート作成をエンジニアに依頼せずに実行できること」が再確認されている。
そのために入力 plugin を作れば、エンジニアは目的に合う plugin を差し込み、非エンジニアは管理画面に統合された UI から使える、という分業が意図されている。

この観点では plugin system は「拡張ポイントを増やす」だけでなく、エンジニアが一度ギャップを埋めれば、以後は非エンジニアが自走できる UX を作るための仕組み である。

3. 分析 plugin は input / visualization よりもまだ exploratory

slack-dev-kouchouai-2026-q1 2026-01-14 週では、入力と可視化は既に複数実例があり「何が共通で何が変わるか」が見えやすい一方、分析プロセスは「今やっと変えることが可能になった段階」で、どう変えるニーズがあるかはまだ観察中だと述べられている。

したがって、analysis plugin は docs で中心的に語られていても、当時の意図は「既に固まった抽象化」ではなく、変えられる状態にしたうえで実需を見に行く ものだった。run_workflow() が実装済みでも production で dormant なのは、source-code とも整合する。

4. LLM grouping 系分類は「まず既存構造に寄せて入れる」方針

slack-dev-kouchouai-2026-q1 2026-02-11 週では、LLM groupingを extraction, embedding の後ろに差し込む案が語られている。ここでの狙いは、位置情報の制約を将来外したいとしつつも、まずは既存のパイプラインや可視化と両立する形で分析プロセス切り替え部分を検証する ことだった。

2026-02-25 週ではさらに、

  • 現状
  • クラスタリング部分を LLM ベースに変える枝
  • その亜種として既存のカテゴリーツリーを与える枝

という 3 段の整理が明示される。自治体から「事業計画や予算のカテゴリ分けに合わせたい」というフィードバックがあったことも同週に記録されており、taxonomy-guided classification は抽象アイデアではなく、具体的ユーザ要求に紐づいていた。

5. embedding は理論上必須ではないが、移行上は便利な足場

slack-dev-kouchouai-2026-q1 2026-02-25 週では、embedding の後で分岐するのは「実装の楽さとか後での可視化」を考えた判断であり、論理的に embedding が必須なわけではないと説明されている。
同じ文脈で、embedding は「距離」という分類基準を与え、LLM クラスタリングは「分類ツリー」によって分類基準を与える、と整理される。

ここから読めるのは、LLM grouping 系分類は embedding パイプラインの単なる置換ではなく、分類基準そのものを距離空間から tree / taxonomy に移す試み だということ。

6. 可視化は分析方式から疎結合であるべき

slack-dev-kouchouai-2026-q1 2026-01-28 週では、LLM 直接グルーピングアプローチは分析の選択肢として十分あり得るが、自然な散布図は出せないと書かれている。
そのため、散布図を前提にメイン分析を入れ替えるのではなく、管理者が可視化方式を選択可能にすることで、散布図を作れない分析も同じプラットフォーム上で扱えるようにする のが意図だった。

これは plugin-system の「3 軸 plugin」構想に対応しているが、Slack の記述の方が理由をはっきり示している。可視化分離は抽象論ではなく、LLM grouping 系分析を受け入れるための必要条件 だった。

Open Questions

  • taxonomy-guided LLM classification は意図として明確だが、main コードや open PR にどこまで落ちているかは別観測が必要
  • analysis を GUI で切り替えるか、管理者設定ファイルだけにするかは 2026-01 時点で保留

Updates

  • 2026-05-17: #2_開発_広聴ai の 2026-Q1 ログから初回整理