# wiki/index.txt — AI 向けフルカタログ (auto-generated by scripts/build_index_txt.py)
# 人間向け curated navigation は index.md。本ファイルは AI が grep / 一覧読みするための物。
# Format: <stem>\t<type>\t<path>\t<summary>
# Regenerate: python3 scripts/build_index_txt.py

analysis-core-and-web-ui	concept	concepts/analysis-core-and-web-ui.md	Web UI が analysis-core を consumer として使い、Web は JSON、CLI は観察用HTMLを持つ理由
analysis-stance	concept	concepts/analysis-stance.md	広聴AI は構造把握スタンスのツールであって、定量分析スタンスのツールではない。クラスタサイズと頻度分布で全体を分かったことにする (定量分析倒れ) のではなく、ユーザに全体構造を読ませることを目的とする。Web UI が担う唯一の全体傾向把握ユースケース (= tokoroten 言い換えで『デカい見落とし / デカい違和感を見つける』) も、構造把握スタンスで実現する
architecture-overview	concept	concepts/architecture-overview.md	kouchou-ai のランタイム構成 — api / public-viewer / admin / static-site-builder / ollama の 5 サービス
broadlistening	concept	concepts/broadlistening.md	ブロードリスニング — 大規模自由記述意見を LLM で集約・クラスタリングし「意見の地図」を作る手法
cli	concept	concepts/cli.md	kouchou-analyze CLI と python -m analysis_core — pip install で使える
coding-agents	concept	concepts/coding-agents.md	Devin / Claude Code / Codex の協働運用 — kouchou-ai での AI コーディング実態
contributing	concept	concepts/contributing.md	コントリビュート手順 — Issue 起票・実装計画合意・PR・レビュー
deployment	concept	concepts/deployment.md	デプロイ — 公開 wiki では方針・課題・PR/issue の粒度に留め、Azure デモ環境の詳細は Google Drive 側で管理する
kouchou-ai	concept	concepts/kouchou-ai.md	広聴AI — DD2030 配下の OSS ブロードリスニング実装。CSV → 抽出 → 埋め込み → 階層クラスタリング → 可視化
llm-providers	concept	concepts/llm-providers.md	対応 LLM プロバイダ — OpenAI / Azure OpenAI / Gemini / OpenRouter / LocalLLM (Ollama/LM Studio 等)。Windows local 完結 route では Foundry Local / Chrome built-in AI / Windows AI APIs も候補だが、2026-05-31 時点では未実装
local-dev-setup	concept	concepts/local-dev-setup.md	ローカル開発環境構築 — docker compose 一発から、ネイティブ Rye/pnpm まで
meeting-report-2026-05-25	concept	concepts/meeting-report-2026-05-25.md	2026-05-25 定例で Codex が報告した内容のスナップショット
meeting-report-2026-06-01	concept	concepts/meeting-report-2026-06-01.md	2026-06-01 定例で Codex が報告した内容と議題候補のスナップショット
meeting-report-draft	concept	concepts/meeting-report-draft.md	次の定例会議で Codex が報告する内容の下書きページ。会議ごとに過去回を snapshot として archive へ rotate し、本ページは次回向けの差分のみ積み上げる
pipeline	concept	concepts/pipeline.md	解析パイプライン — extraction → embedding → 階層クラスタリング → ラベリング → 可視化
plugin-system	concept	concepts/plugin-system.md	入力／解析／可視化を plugin 化する設計。v5.0 の中核
testing	concept	concepts/testing.md	テスト体系 — pytest / Jest / Playwright と lint (ruff / Biome) の運用
thinking-targets	concept	concepts/thinking-targets.md	今、人間の思考と判断が要る論点を 1 ページに集めた思考ハブ。完了報告は meeting-report-draft、未着地論点の全体棚卸しは open-decisions、ここは『次に考えると進むもの』だけに絞る
usage-modes	concept	concepts/usage-modes.md	kouchou-ai の主要利用モード — 非専門家向け Web UI と、研究者・データサイエンティスト向け CLI / analysis-core を分けて捉えるための整理
wiki-driven-workflow	concept	concepts/wiki-driven-workflow.md	developer-wiki repo で文脈整理し、`work/kouchou-ai/` で実装確認し、最終的に `digitaldemocracy2030/kouchou-ai` へ PR を出す二層運用
anno	entity	entities/anno.md	安野たかひろ — DD2030 ボード、Devin の ACU credits 提供者
broad-listening-book	entity	entities/broad-listening-book.md	DD2030 書籍「選挙を変えたブロードリスニング」（インプレス、CC BY-NC 4.0）。設計判断・運用知見・将来開発の素材として開発向け参照源にも使う
dd2030	entity	entities/dd2030.md	デジタル民主主義2030 — kouchou-ai の親プロジェクト／組織
idobata	entity	entities/idobata.md	AI による 1-on-1 ディープインタビュー OSS。kouchou-ai と提案／PR データを連携
jigsaw-sensemaker	entity	entities/jigsaw-sensemaker.md	Jigsaw Sensemaker は、広義には LLM grouping に属する外部ツール / 分析アプローチとして扱う。LLM grouping 全体を Jigsaw と呼ぶと、一般カテゴリと固有名詞が混ざって混乱する
kuboon	entity	entities/kuboon.md	Ohkubo KOHEI — Outline self-host とドキュメント基盤運用
nasuka	entity	entities/nasuka.md	Nasuka Sumino (角野) — 元会議ファシリ、抽出プロンプト・limited-publish 等を実装
nishio	entity	entities/nishio.md	西尾泰和 — kouchou-ai のリファクタ／研究主導、本 Wiki のオーナー
ohki-shingo	entity	entities/ohki-shingo.md	大木真吾 — kouchou-ai メンテナ、Azure 環境・対外渉外の主担当
other-contributors	entity	entities/other-contributors.md	その他の主要コントリビュータ — kitaro, tanenobu, shirouchi, sasano ほか
polimoney	entity	entities/polimoney.md	政治資金可視化 OSS。kouchou-ai と兄弟プロジェクト
talk-to-the-city	entity	entities/talk-to-the-city.md	TTTC — kouchou-ai の上流。AI Objectives Institute 発、現在 archived
tokoroten	entity	entities/tokoroten.md	中山心太 — kouchou-ai メンテナ。LocalLLM、属性フィルタ、書籍主担当
analysis-core-web-ui-separation-decision-2026-05-23	source	sources/analysis-core-web-ui-separation-decision-2026-05-23.md	CLI は一般利用者に重く、WebUI は研究用途に重かったため core を切り出し、Web は JSON、CLI は観察用HTMLを持つという maintainer 判断メモ
azure-container-apps-docs-2026-06-01	source	sources/azure-container-apps-docs-2026-06-01.md	Azure Container Apps 公式 docs の apps / jobs / Consumption billing 周辺の要点。public-viewer の build/serve 分離と固定費判断の補助線
azure-demo-visibility-thread-resolution-2026-06-05	source	sources/azure-demo-visibility-thread-resolution-2026-06-05.md	2026-06-05 11:36 大木さんの返答と 12:18 nishio の決定。Azure デモ動線化 4 問について「Q1, Q2 賛成 / Q3 アイデアとしてはあり優先度低 / Q4 継続利用環境はあるとよいが提供主体・責任範囲の整理必要」、デモ環境の価値の再フレーム、dd2030 提供 API キーの container 設定除去という prerequisite が明示された
broad-listening-book-source	source	sources/broad-listening-book-source.md	DD2030 書籍「選挙を変えたブロードリスニング」原稿（CC BY-NC 4.0）を開発向け一次資料として要約。設計判断の出版時点の確定版・現場運用知見・将来開発の素材を含む
chrome-built-in-ai-docs-2026-05-31	source	sources/chrome-built-in-ai-docs-2026-05-31.md	Chrome Prompt API / built-in AI 公式 docs の要点。Gemini Nano を Chrome 内で使い、初回 model download 後は外部送信なしで動く一方、Chrome desktop・storage・RAM/CPU/GPU 条件と browser/API lifecycle への依存がある
clustering-research-survey-seeds-2026-05-25	source	sources/clustering-research-survey-seeds-2026-05-25.md	TTTC / 広聴AI の clustering 議論を外部研究で検証するための survey seed 集。UMAP 後 clustering、spectral clustering、BERTopic、可視化と分析の分離、評価軸
codeql-docs	source	sources/codeql-docs.md	GitHub / CodeQL 公式ドキュメントから見た CodeQL の役割と GitHub code scanning での位置づけ
codex-log-experiment-archive-cli-2026-06-02	source	sources/codex-log-experiment-archive-cli-2026-06-02.md	Codex が analysis-core CLI に実験結果アーカイブの first slice を実装した作業ログ。`--experiment-root` / `--experiment-id` で 1 回の pipeline output を `raw/experiments/<experiment_id>/` 形式へ保存する
codex-log-label-preference-bundle-2026-06-03	source	sources/codex-log-label-preference-bundle-2026-06-03.md	Codex が既存 LLM grouping 400 件 corpus から blind A/B label preference bundle を生成した作業ログ。`hierarchical_8_40` tree を固定し、`none` vs `setwise` の label variants を 24 questions にして `human_preference_questions.jsonl` と Markdown / HTML bundle を作った
codex-log-pr-887-deploy-investigation-2026-06-01	source	sources/codex-log-pr-887-deploy-investigation-2026-06-01.md	2026-06-01 17:47 / 19:33 (月曜日) の Codex 2 ターン会話ログ。nishio の「直ってなくないですか？」「az login したけど見れるようになった？」というひと言の問いに対し、Codex が false positive の根拠 (Turn 1) と SIGKILL/OOM の根拠 (Turn 2) を順に返した、runtime build 撤去エピソードの起点ログ
deepwiki-kouchou-ai	source	sources/deepwiki-kouchou-ai.md	DeepWiki が生成した kouchou-ai コードベース要約。構造把握には有用だが、最新実装との差分確認が必要
docker-desktop-license-2026-05-29	source	sources/docker-desktop-license-2026-05-29.md	2026-05-29 時点の Docker 公式文書確認。Docker Desktop は大規模 enterprise の商用利用や政府系 entity では paid subscription が必要になり得るため、自治体・大企業向け Windows 導線ではライセンス確認を前提にする必要がある
docker-engine-wsl2-alternative-2026-05-23	source	sources/docker-engine-wsl2-alternative-2026-05-23.md	nishio と外部 GPT の対話。Docker Desktop を避ける選択肢として、WSL2 Ubuntu の中に Docker Engine + Docker Compose plugin を直接入れる構成と、その UX コストおよび 2 本立て docs 案を整理したブレスト
github-actions-timeout-docs-2026-06-01	source	sources/github-actions-timeout-docs-2026-06-01.md	GitHub Actions 公式 docs の timeout-minutes / Actions limits 周辺の要点。Azure Deployment readiness poll の timeout 設計用
github-dev-docs	source	sources/github-dev-docs.md	kouchou-ai リポジトリと docs/development/ の開発者ドキュメント
gpt-kawakita-kj-method-broadlistening-2026-05-25	source	sources/gpt-kawakita-kj-method-broadlistening-2026-05-25.md	2026-05-25 の nishio ↔ 外部 GPT 対話。広聴AIを川喜田二郎の野外科学・KJ法に接続し、`混沌から公共的仮説を立ち上げる装置` として再定義。AI支援KJ法は自動化ではなく人間が混沌と向き合うための足場、という設計原則
gpt-llm-pairwise-spectral-small-n-brainstorm-2026-05-25	source	sources/gpt-llm-pairwise-spectral-small-n-brainstorm-2026-05-25.md	2026-05-25 の nishio ↔ 外部 GPT 対話。データ量が数十件規模の時、LLM に N:N 類似度を出させて spectral clustering する案を検討。LLM-as-pairwise-oracle + 対称化・校正・疎化した affinity graph + spectral/agglomerative の設計を推奨
gpt-mst-bridge-visualization-brainstorm-2026-05-25	source	sources/gpt-mst-bridge-visualization-brainstorm-2026-05-25.md	2026-05-25 の nishio ↔ 外部 GPT 対話。意味クラスタリングと 2D 散布図の衝突を、`クラスタ内 MST + クラスタ間 bridge edge + 2 段階 cluster-separated layout` という graph-drawing 系の設計で解く案を整理
gpt-umap-clustering-bertopic-deep-research-2026-05-25	source	sources/gpt-umap-clustering-bertopic-deep-research-2026-05-25.md	2026-05-25 の nishio ↔ 外部 GPT 対話。`UMAP -> clustering` の妥当性、可視化用 2D と clustering 用 15D〜25D の分離、`n_neighbors` の解釈、BERTopic の現代的位置づけを既存研究を引きながら整理
issue-493-pr-597-discussion	source	sources/issue-493-pr-597-discussion.md	`Issue #493` と `PR #597` で行われた ScatterChart スクロール誤操作対策の議論メモ
issue-731-windows-setup-mojibake	source	sources/issue-731-windows-setup-mojibake.md	GitHub issue #731 の再現ログ。Windows で `setup_win.bat` 実行時に日本語が文字化けするだけでなく、一部行が別コマンドとして解釈されてセットアップが停止することを示す
issue-830-pr-832-auto-cluster-defaults-2026-05-18	source	sources/issue-830-pr-832-auto-cluster-defaults-2026-05-18.md	`Issue #830` と `PR #832` で整理された、CLI / analysis-core のクラスタ数デフォルト見直しの観測メモ
issue-877-windows-setup-guide-scope-2026-05-29	source	sources/issue-877-windows-setup-guide-scope-2026-05-29.md	GitHub issue #877 とコメントの観測。Windows setup guide の API key / Docker Desktop / WSL2 / メモリ不足分岐を整理する issue だが、コメントにより Docker Desktop ライセンス・組織管理端末・生 Windows サポート境界の論点へ広がっている
kensuzuki-broad-listening-insight-types-2025-11-29	source	sources/kensuzuki-broad-listening-insight-types-2025-11-29.md	鈴木健 2025-11-29 ブログ。ブロードリスニングは用途ごとに欲しいインサイトが違い、TTTC / 広聴AI は主にアジェンダ発見向きだという整理
kouchou-ai-direction-2-2025-12-13	source	sources/kouchou-ai-direction-2-2025-12-13.md	2025-12-13 の『広聴AIの方向性について2』メモ。選択肢比較のうえで、書籍まで現行系を stable v4 として保ち、次世代化は別軸で進める判断が固まった
kouchou-ai-direction-2025-12-06	source	sources/kouchou-ai-direction-2025-12-06.md	2025-12-06 の『広聴AIの方向性について』メモ。現行散布図方式の限界、用途別のツール使い分け、GUI より設定ファイル、書籍に合わせた安定版という問題設定が明示された
label-refinement-judge-bundle-2026-05-25	source	sources/label-refinement-judge-bundle-2026-05-25.md	Claude Code や人間が同じ材料で top-level label set を比較できるよう、`[8,40]` の label refinement 候補 4 本を同一フォーマットで並べた judge bundle
llm-grouping-400-tree-label-corpus-2026-06-02	source	sources/llm-grouping-400-tree-label-corpus-2026-06-02.md	LLM grouping 400 件実験の既存 artifact を `raw/experiments/2026-06-02-llm-grouping-400-tree-label-corpus/` に台帳化した source。5 tree run、10 labelling run、5 judge run、4 observation を保存し、tree-label matrix bundle を作成した
llm-grouping-experiment-output-2026-05-25	source	sources/llm-grouping-experiment-output-2026-05-25.md	2026-05-25 に `analysis_mode=llm_grouping` を 400 件の日本語コメントで実行した観測。422 argument を 8 群へ分類でき、`report.html` も生成できたが、embedding 由来 2D 散布図との相性は悪かった
llm-grouping-implementation-observation-2026-05-25	source	sources/llm-grouping-implementation-observation-2026-05-25.md	2026-05-25 時点の current `main` 観測では、LLM grouping 計画文書は main に入り、実行経路は workflow canonical だが、`analysis_mode` 分岐・`analysis_capabilities`・viewer `requirements` は未実装
local-ai-hardware-procurement-market-notes-2026-05-31	source	sources/local-ai-hardware-procurement-market-notes-2026-05-31.md	2026-05-31 時点の local AI hardware 調達 route 検討用 source。RTX 5060 Ti 16GB / RTX 5070 Ti 16GB / RTX PRO 4000 Blackwell 24GB / Mac mini M4 Pro / Foundry Local 公式情報を、広聴AI local box 構想の判断材料として整理
local-ai-user-share-market-stats-2026-05-31	source	sources/local-ai-user-share-market-stats-2026-05-31.md	2026-05-31 時点で local AI runtime のユーザー到達率を推定するための外部統計メモ。Chrome desktop share、Steam Hardware Survey の RAM/CPU/VRAM、Gartner PC shipment、Canalys AI-capable PC forecast、Chrome Prompt API / Foundry Local / Phi Silica 公式要件を整理
marketing-strategy-mtg-2025-07-16	source	sources/marketing-strategy-mtg-2025-07-16.md	2025-07-16 朝 8時台のボード級『広聴AI マーケティング戦略 mtg』議事メモ。ユーザーターゲット・事例研究・パートナー戦略・プロダクト品質・OSS の射程を議論した単発会議
meeting-minutes-url-extraction-2026-05-25	source	sources/meeting-minutes-url-extraction-2026-05-25.md	議事メモ Google Doc の HTML export から、`txt` では落ちる URL を抽出して分類した棚卸し
meeting-minutes	source	sources/meeting-minutes.md	Google Doc 議事メモ — weekly kouchou-ai dev meeting minutes (2025-03 〜 2026-06, ~7600 lines, JP)
nextjs-dynamic-build-docs-2026-06-01	source	sources/nextjs-dynamic-build-docs-2026-06-01.md	Next.js 公式 docs の generateStaticParams / connection / route segment config 周辺の要点。public-viewer dynamic build を API なしで通す設計の補助線
nextjs-static-export-docs-2026-05-31	source	sources/nextjs-static-export-docs-2026-05-31.md	Next.js 公式 docs の static export / route handler 周辺の要点。静的 export は HTML/CSS/JS assets として配信できる一方、request-time server runtime に依存する機能は使えないため、Server Actions・request 依存 route・ISR/cache revalidate を使う current admin/public-viewer はそのままでは runtime Node なしにできない
nishio-amusement-park-map-metaphor-2026-06-03	source	sources/nishio-amusement-park-map-metaphor-2026-06-03.md	2026-06-03 に nishio が、広聴AI の出力（意見の地図）を読む体験を「遊園地の地図」に例えたメモ。俯瞰 → ゾーン選択 → drill in という reader の探索パターンを言語化
nishio-blind-human-label-presentation-context-2026-06-02	source	sources/nishio-blind-human-label-presentation-context-2026-06-02.md	2026-06-02 に nishio が、人間への A/B ラベル評価ではどのアルゴリズム由来かを隠して聞くべきであり、困難な full UI 評価をラベル単体・隣接ラベル集合・ラベルと代表例の分解テストとして扱う必要があると指摘したメモ
nishio-cli-pipeline-ideas-2026-06-02	source	sources/nishio-cli-pipeline-ideas-2026-06-02.md	2026-06-02 に nishio が、CLI で pipeline を試行錯誤して発展させる方向、マンダラート / 付箋ビュー、ラベル品質改善、その前段の品質 judge 改善をまとめたいと投げたメモ
nishio-clustering-labeling-comparison-corpus-2026-06-02	source	sources/nishio-clustering-labeling-comparison-corpus-2026-06-02.md	2026-06-02 に nishio が、各種 clustering method が作る tree と、その tree を入力にした各種 summarization / labelling process のラベルを蓄積・比較できるようにすべき、judge 改善以前に現状が曖昧すぎると指摘したメモ
nishio-docs-entry-restructure-discussion-2026-06-03	source	sources/nishio-docs-entry-restructure-discussion-2026-06-03.md	2026-06-03 nishio との対話。kouchou-ai 本体 docs が「セットアップから始まる」構造であることへの違和感と、デモ閲覧を入口にした spine 再設計、実験的機能カタログの提案
nishio-experiment-result-storage-question-2026-06-02	source	sources/nishio-experiment-result-storage-question-2026-06-02.md	2026-06-02 に nishio が、実験結果をどこにどのように蓄積するかという問題が宙に浮いていると指摘したメモ
nishio-human-pairwise-label-preference-before-judge-2026-06-02	source	sources/nishio-human-pairwise-label-preference-before-judge-2026-06-02.md	2026-06-02 に nishio が、人間は単独のラベルだけを見て十分に言語化して批判しにくいので、先にパラメータ違いのラベルを作り、人間にはどちらがよいかを聞くべきだと指摘したメモ
nishio-label-evaluation-improvement-plan-request-2026-06-03	source	sources/nishio-label-evaluation-improvement-plan-request-2026-06-03.md	2026-06-03 に nishio が、blind A/B preference と presentation context 分解まで整理したラベル品質評価の改善計画を Wiki に書くべきか確認したメモ
nishio-llm-grouping-terminology-correction-2026-06-02	source	sources/nishio-llm-grouping-terminology-correction-2026-06-02.md	2026-06-02 に nishio が、Jigsaw Sensemaker は LLM grouping の一例として説明し、LLM grouping 全体を Jigsaw と呼ぶ混乱は避けるべきだと指摘したメモ
nishio-one-factor-experiment-principle-2026-06-02	source	sources/nishio-one-factor-experiment-principle-2026-06-02.md	2026-06-02 に nishio が、実験をやってみることは大事だが、current main から一度に多くの要素を変えると解釈が難しいため、今後は 1 要素ずつ変えた実験にすべきだと指摘したメモ
nishio-slack-azure-demo-visibility-proposal-2026-06-04	source	sources/nishio-slack-azure-demo-visibility-proposal-2026-06-04.md	2026-06-04 22:00 / 22:29 nishio の dd2030 Slack 投稿。docs entry 3 段階 spine の改訂版と、Azure デモサイトを docs から動線化する具体案 4 問を Ohki さんに投げかけている
nishio-source-freshness-criterion-2026-06-02	source	sources/nishio-source-freshness-criterion-2026-06-02.md	2026-06-02 に nishio が、Wiki の情報鮮度は議事録をいつ時点まで読んだか、Slack をいつ時点まで読んだかを基準として明示すべきだと指摘したメモ
note-annotakahiro-broadlistening-resources-2025-02-05	source	sources/note-annotakahiro-broadlistening-resources-2025-02-05.md	安野たかひろ公式 note 2025-02-05。TTTC でブロードリスニングを実施するのに必要なヒト/モノ/カネを整理した実務ガイド。M-1 2024 分析 (NSK) の実コスト $230 も含む
open-issue-backlog-2026-05-19	source	sources/open-issue-backlog-2026-05-19.md	2026-05-19 時点の `digitaldemocracy2030/kouchou-ai` open issue 145 件を本文付きで読み、recent issue だけでなく古い backlog も含めて未解決問題の全体像を取るための source
open-issues-snapshot-2026-05-19	source	sources/open-issues-snapshot-2026-05-19.md	2026-05-19 時点の `digitaldemocracy2030/kouchou-ai` open issue を新しい順に読み、`analysis-core` CLI 整備と Web/静的公開まわりの事故修正に論点が集中していることを記録した snapshot
open-pr-observation-2026-05-18	source	sources/open-pr-observation-2026-05-18.md	2026-05-18 の open PR / review triage 実験で観測した head branch 更新挙動
open-pr-pipeline-step-observation-2026-05-28	source	sources/open-pr-pipeline-step-observation-2026-05-28.md	2026-05-28 時点の open PR 観測。pipeline step 追加判断に直接関係するのは `#866` LLM grouping、`#874` semantic island layout、補助的に `#867` reuse-from で、`#874` は named layout artifact として筋がある一方 CI は未通過
open-pr-snapshot-2026-05-18	source	sources/open-pr-snapshot-2026-05-18.md	2026-05-18 時点の `digitaldemocracy2030/kouchou-ai` open PR 一覧を、作者種別と stale 度合いを見るために取得したスナップショット
pr-722-filesystem-validation-observation-2026-05-19	source	sources/pr-722-filesystem-validation-observation-2026-05-19.md	`PR #722` は 2025-10-23 作成の draft open PR で、ファイルシステム実行の文書化と validation を追加するが、2026-05-19 時点では deprecated な旧 `server/...` 経路を増築している
pr-727-static-build-validation-observation-2026-05-19	source	sources/pr-727-static-build-validation-observation-2026-05-19.md	`PR #727` は「公開レポート 0 件時の静的 build エラー改善」を狙うが、2026-05-19 時点の patch には validation が実行されない不具合と API URL 解決のずれがある
pr-735-issue-685-observation-2026-05-19	source	sources/pr-735-issue-685-observation-2026-05-19.md	`PR #735` は `Issue #685` の症状に触れているが、2026-05-19 時点では draft / conflicting / stale frontend path 前提で、そのままは merge 不可という観測メモ
pr-801-react-override-observation-2026-05-19	source	sources/pr-801-react-override-observation-2026-05-19.md	`PR #801` は React version 統一の意図自体は妥当だが、2026-05-19 時点の current `main` に対しては `pnpm.overrides` を丸ごと置き換えて既存 `minimatch` override を消すため、そのままは merge 不可という観測メモ
pr-802-overview-config-observation-2026-05-19	source	sources/pr-802-overview-config-observation-2026-05-19.md	`PR #802` は `Overview` の1箇所だけを optional chaining 化するが、2026-05-19 時点の current `public-viewer` では `result.config` 前提が他にも多く、そのままでは欠損入力対応として不十分という観測メモ
pr-813-817-codeql-coderabbit-observation-2026-05-18	source	sources/pr-813-817-codeql-coderabbit-observation-2026-05-18.md	`PR #813` と `PR #817` を観測し、CodeQL / CodeRabbit 設定がどう入って何が意図だったかを整理したメモ
pr-814-static-export-error-observation-2026-05-19	source	sources/pr-814-static-export-error-observation-2026-05-19.md	`PR #814` の GitHub 状態と `apps/public-viewer` の差分を 2026-05-19 時点で観測したメモ
pr-823-review-observation-2026-05-18	source	sources/pr-823-review-observation-2026-05-18.md	`PR #822` / `#823` の review 時に local worktree と mock API で観測した `public-viewer` build 挙動と PR 運用上の注意
pr-824-admin-merge-observation-2026-05-18	source	sources/pr-824-admin-merge-observation-2026-05-18.md	`PR #824` merge 時に、checks success と `REVIEW_REQUIRED` が両立したまま admin merge できた観測メモ
pr-824-local-llm-https-observation-2026-05-19	source	sources/pr-824-local-llm-https-observation-2026-05-19.md	`PR #824` merge 後の current `main` では analysis 実行経路は full URL な LOCAL LLM を受け取れるが、admin の model list probe はまだ `host:port` + `http://` 前提という観測メモ
pr-825-standalone-html-observation-2026-05-19	source	sources/pr-825-standalone-html-observation-2026-05-19.md	`PR #825` merge 後の current `main` では `analysis-core` CLI が自己完結型 `report.html` を生成するが、Web の主経路はなお `hierarchical_result.json` + `public-viewer` であり HTML は CLI 向け観察用に留まるという観測メモ
pr-827-llm-grouping-capabilities-plan-2026-05-18	source	sources/pr-827-llm-grouping-capabilities-plan-2026-05-18.md	`PR #827` の計画メモ要約 — LLM grouping を viewer 互換で導入し、長期的には capability 自動判定へ移行する
pr-835-static-build-fail-fast-observation-2026-05-19	source	sources/pr-835-static-build-fail-fast-observation-2026-05-19.md	`PR #835` は `public-viewer` の static export 前提チェックを helper に整理し、公開レポート 0 件と `BUILD_SLUGS` 不一致を分けて fail-fast する draft PR
pr-840-workflow-defaultization-observation-2026-05-20	source	sources/pr-840-workflow-defaultization-observation-2026-05-20.md	draft PR #840 は `run_workflow()` default 化に向けて、初期 artifact・status 永続化・rerun artifact 再利用に加え、CLI/API 入口と duplicate/reuse rerun plan の integration 確認まで段階的に進めている
pr-849-agent-review-request-observation-2026-05-21	source	sources/pr-849-agent-review-request-observation-2026-05-21.md	`PR #849` では AI が人間 reviewer request を送れてしまったが、これは望ましい運用ではなく、review 依頼と承認要請は人間オーナーの明示判断に限るべきという観測メモ
pr-852-error-log-visibility-observation-2026-05-22	source	sources/pr-852-error-log-visibility-observation-2026-05-22.md	PR #852 で CodeRabbit を手動トリガーしたところ、draft PR のため自動 review は skip され、`@coderabbitai review` 後に review in progress 状態へ移行した。同時点で client-admin build が failure、他の主要 checks は概ね success だった
pr-887-production-deploy-observation-2026-06-01	source	sources/pr-887-production-deploy-observation-2026-06-01.md	PR #887 merge 後に、デプロイ成功判定と実反映状態がズレうることを公開可能な粒度で整理した観測メモ。実環境 URL・revision・ログ・resource 値などの詳細は公開しない
pypi-release-observation-2026-05-19	source	sources/pypi-release-observation-2026-05-19.md	`analysis-core-v0.1.1` / `v0.1.2` tag push で観測した PyPI publish workflow の実挙動
remaining-experiment-artifacts-snapshot-2026-05-29	source	sources/remaining-experiment-artifacts-snapshot-2026-05-29.md	`work/kouchou-ai/` に残っていた LLM grouping 系実験の入力・設定・出力 artifact と Next.js 生成差分を、branch `codex/remaining-experiment-artifacts-2026-05-29` commit `b56ac9b` として退避し、一次参照 clone は `main@6955202` へ戻した運用メモ
report-html-non-web-canonical-decision-2026-05-23	source	sources/report-html-non-web-canonical-decision-2026-05-23.md	`report.html` を Web canonical にせず、CLI / coding agent 向け観察用HTMLに留めると maintainer が 2026-05-23 に明示した判断メモ
report-slug-config-repro-2026-05-19	source	sources/report-slug-config-repro-2026-05-19.md	2026-05-19 時点の `/reports/{slug}` は通常生成物では `config` 付き JSON を返す一方、壊れた `hierarchical_result.json` を置くと `config` 欠損でも 200 で素通しするという再現メモ
role-model-papers-polis-birdwatch	source	sources/role-model-papers-polis-birdwatch.md	広聴AI紹介論文のロールモデルとして参照しやすい vTaiwan / Polis と Birdwatch / Community Notes 論文の要点
seed-reproducibility-history	source	sources/seed-reproducibility-history.md	UMAP / k-means の seed 固定と再現性要求の経緯 — 2025-03 の実装、2025-05 の再現性不満、2025-07 の再評価、2026-02 の PR #810
slack-dev-kouchouai-2025-q4	source	sources/slack-dev-kouchouai-2025-q4.md	`oss_weekly_reporter` の `#2_開発_広聴ai` 抜粋（2025-10-01 〜 2025-12-31）— 現行方式の限界認識、plugin 化、v4/v5 二段構え
slack-dev-kouchouai-2026-q1	source	sources/slack-dev-kouchouai-2026-q1.md	`oss_weekly_reporter` の `#2_開発_広聴ai` 抜粋（2026-01-14 〜 2026-03-04）— plugin 化、再利用、LLM grouping 系分類の設計意図
slack-flowchart-feedback-2026-05-30	source	sources/slack-flowchart-feedback-2026-05-30.md	2026-05-30 #2_開発_広聴ai Slack で decision flowchart 試作 (試作 A / 試作 B) に対する nishio / tokoroten の feedback。試作 A は最初の分岐が『データ量』であるべき + 『ラベル付きデータ』は jargon。試作 B はそもそも前提が違い、AI = wiki から把握できないほど platform 知識が抜けていた
slack-kouchouai-algorithm-dev	source	sources/slack-kouchouai-algorithm-dev.md	`oss_weekly_reporter` の `#2_開発_広聴ai_アルゴリズム開発` 抜粋（2025-04 〜 2026-03）— UMAP→k-means への批判、対立軸発見、LLM分類、可視化代替案
slack-label-algorithm-improvement-2026-05-30	source	sources/slack-label-algorithm-improvement-2026-05-30.md	2026-05-29〜30 の Slack アルゴリズム改善ログ。ラベル欠落 vs 冗長、random sampling / 全件入力、rep args 選定、評価ユースケース分岐が議論された
slack-local-llm-native-runtime-2026-05-31	source	sources/slack-local-llm-native-runtime-2026-05-31.md	2026-05-31 Slack で nishio と tokoroten が、API 契約不要の local LLM 実行可能性について、20B 級モデルの現実化と Chrome / Windows の native LLM support を使う方向を議論した
slack-niizuma-umap-kmeans-thread-2026-03-18	source	sources/slack-niizuma-umap-kmeans-thread-2026-03-18.md	`#2_開発_広聴ai_アルゴリズム開発` 2026-03-18〜2026-03-21 の新妻スレッド。UMAP後k-means批判、前段クラスタリング案、supervised UMAP、LLM直分類と説明責務
slack-public-ui-requirements-2026-05-23	source	sources/slack-public-ui-requirements-2026-05-23.md	2026-05-23 ごろの Slack で、nishio が散布図互換／散布図必須撤廃の二段構えを述べたのに対し、ohki-shingo が『公開UIに求められる要件』と『embedding 距離精度の非本質性』を整理した thread
slack-stance-discussion-2026-05-30	source	sources/slack-stance-discussion-2026-05-30.md	2026-05-30 #2_開発_広聴ai Slack で nishio / ohki-shingo / tokoroten が広聴AI のユースケース契約と analysis-stance を議論。全体傾向把握ユースケースの精密な言い換え (デカい見落とし / デカい違和感)、止まる現象の構造的説明、デフォルトモード UX 指針、CLI + コミュニティのエコシステムビジョンが出た
slack-tokoroten-spectral-clustering-notes-2026-q1	source	sources/slack-tokoroten-spectral-clustering-notes-2026-q1.md	2026-Q1 の tokoroten による spectral clustering メモ。TTTC は小さめ `n_neighbors` で紐状分離を作り、SpectralClustering で切っているのではないか、という読み
slack-windows-single-exe-2026-05-31	source	sources/slack-windows-single-exe-2026-05-31.md	2026-05-31 Slack で tokoroten と nishio が、Windows ユーザー向けには単一実行バイナリが望ましく、Node runtime を同梱する代わりに Web UI を SPA/static assets 化してサーバ側 wrapper を Python に寄せる案を議論した
source-code	source	sources/source-code.md	kouchou-ai リポジトリのソースコード本体 — docs だけでは見えない実装ギャップを取るための一次参照
tttc-spectral-clustering-code-observation-2026-05-25	source	sources/tttc-spectral-clustering-code-observation-2026-05-25.md	TTTC commit `5e0a439` と広聴AI commit `53f1209` の clustering 実装比較。TTTC は embedding を UMAP 2D に落としてから SpectralClustering を掛け、`n_neighbors` は `min(n_samples - 1, 10)`
weekly-log-2026-05-06	source	sources/weekly-log-2026-05-06.md	nishio/oss_weekly_reporter の週次ダンプ (2026-05-06 〜 2026-05-13) — Slack/GitHub の生ログ
weekly-log-2026-05-20	source	sources/weekly-log-2026-05-20.md	nishio/oss_weekly_reporter の週次ダンプ (2026-05-20 〜 2026-05-27) — kouchou-ai の refactor / Windows / CSP / LLM grouping と、Slack の公開UI・MST可視化・実験保存方針
wiki-maintenance-observation-2026-05-25	source	sources/wiki-maintenance-observation-2026-05-25.md	developer-wiki の graph 表示調整と main 直接 push 運用を 2026-05-25 の実作業から整理した観測メモ
wiki-pages-tooling-observation-2026-05-21	source	sources/wiki-pages-tooling-observation-2026-05-21.md	この developer-wiki repo の GitHub Pages 現状実装と Quartz 公式 docs を突き合わせた観測メモ
windows-distribution-gpt-brainstorm-2026-05-22	source	sources/windows-distribution-gpt-brainstorm-2026-05-22.md	nishio と外部 GPT の対話メモ。Windows ユーザー向け配布形態を `exe` 単体化か Docker Compose ランチャーか、また正規入口を Docker Desktop と WSL2 のどちらに据えるか、という 2 つの論点を整理したブレスト
windows-native-local-ai-docs-2026-05-31	source	sources/windows-native-local-ai-docs-2026-05-31.md	Microsoft 公式 docs から見た Windows native local AI の要点。Phi Silica は Copilot+ PC / NPU 向け Windows AI APIs、Foundry Local は Python SDK・OpenAI-compatible endpoint・embeddings・model lifecycle 管理を持つ local runtime で、広聴AIには Foundry Local が特に接続しやすい
windows-powershell-default-installation	source	sources/windows-powershell-default-installation.md	Microsoft Learn の PowerShell 公式ドキュメントより、Windows PowerShell 5.1 は Windows client 10 以降と Windows Server 2016 以降に既定でインストールされる、という事実確認
worktree-hygiene-observation-2026-05-20	source	sources/worktree-hygiene-observation-2026-05-20.md	`work/kouchou-ai/` の dirty は `issue-830` 本筋ではなく、別件 2 系統と local 生成物が混ざった状態で、`apps/api/uv.lock` ignore を `PR #839` で main に反映して整理した観測メモ
zenn-llm-as-a-judge-rubric-evaluation-2026-05-29	source	sources/zenn-llm-as-a-judge-rubric-evaluation-2026-05-29.md	Ubie Tech Blog の LLM-as-a-Judge / ルーブリック評価記事。抽象的な 1-5 点採点ではなく、true/false 可能な criteria に分解し、重要度ごとの points と negative criteria を持たせると、再現性と改善点の特定が上がるという実務向け整理
agent-sandboxing-strategy	analysis	analyses/agent-sandboxing-strategy.md	AI コーディングエージェント向けの開発環境分離方針 — host full access を標準にしない
analysis-core-extras-pr-scope	analysis	analyses/analysis-core-extras-pr-scope.md	`analysis-core` の extras 分割は独立 PR で切り出せるが、依存定義だけでなく eager import・CI・インストール導線を同時に整える必要がある
auto-cluster-defaults	analysis	analyses/auto-cluster-defaults.md	クラスタ数デフォルト問題の本質は「アルゴリズム選定」より「docs / 実装 / AI 利用経路の不一致」であり、`PR #832` はそのズレを縮める修正
azure-demo-public-visibility-proposal-2026-06-04	analysis	analyses/azure-demo-public-visibility-proposal-2026-06-04.md	Azure デモサイトを docs から動線化する 4 問と、2026-06-05 の大木さん返答 + nishio 決定。viewer 公開 / admin 共用 + 秘密情報禁止明示は進行、1 ヶ月専用試用環境は優先度低、365 日 SaaS は提供主体・責任範囲の整理項目化、で着地。あわせてデモ環境の価値を「データ投入の場所」から「使い方理解の参照環境」へ再フレームしている
book-release-development-plan-2026-09	analysis	analyses/book-release-development-plan-2026-09.md	2026-09 ごろの書籍リリースを前提にした開発計画案 — v4 回帰をテストで保証しつつ、発展性の高い v5 へ移行する
broad-listening-book-extractions	analysis	analyses/broad-listening-book-extractions.md	書籍「選挙を変えたブロードリスニング」から抽出した、今後の kouchou-ai 開発判断に効く知見の整理
broadlistening-tool-ecosystem-vision	analysis	analyses/broadlistening-tool-ecosystem-vision.md	広聴AI Web UI を simple な default モードに絞り、CLI に多様な実験機能を追加し、新しい分析手法が試行錯誤され共有されるコミュニティを育てる、という二段構造のエコシステムビジョン。analysis-stance で『別ツールで補完』とした空き地に対する nishio の答え
bug-issue-triage-2026-05-25	analysis	analyses/bug-issue-triage-2026-05-25.md	2026-05-25 に `bug` ラベルの open issue を current main で再点検したところ、`#666` `#584` `#177` は stale と判断でき、`#629` `#477` `#741` `#478` `#283` `#121` はなお現役論点として残った
chart-scroll-ux-decision	analysis	analyses/chart-scroll-ux-decision.md	ScatterChart のスクロール誤操作対策では、click-to-enable より「短い遅延付きの自動ロック解除」と視覚フィードバックが好まれ、preview 環境不足が実装収束を妨げた
cli-pipeline-experiment-roadmap-2026-06-02	analysis	analyses/cli-pipeline-experiment-roadmap-2026-06-02.md	CLI を pipeline 実験の場として使い、まず clustering tree と labelling output の比較コーパスを作り、label variants の A/B human preference を集めてから judge / evidence artifact / ラベル改善 / マンダラート・付箋ビューを順に育てるロードマップ。Web UI は simple に保ち、CLI で比較可能な artifact を貯めてから昇格判断する
clustering-deep-research-findings-2026-05-25	analysis	analyses/clustering-deep-research-findings-2026-05-25.md	[[clustering-research-survey-plan]] が立てた survey bucket への 2026-05-25 時点の deep-research 応答。`UMAP -> clustering` は否定されないが 2D 用と clustering 用は分離（15D〜25D 推奨）、BERTopic は完成品から backbone へ、数十件規模は LLM pairwise + spectral が筋という整理
clustering-labeling-comparison-corpus-2026-06-02	analysis	analyses/clustering-labeling-comparison-corpus-2026-06-02.md	品質 judge を改善する前に、dataset × clustering tree × labelling process × label output を蓄積する比較コーパスを作るべきという整理。採用判断に使う実験は 1 要素ずつ変え、人間には単独批評ではなく label variants の A/B preference を聞く
clustering-research-survey-plan	analysis	analyses/clustering-research-survey-plan.md	TTTC / 広聴AI の clustering 議論を外部研究で検証するには、`UMAP -> clustering`、spectral clustering、BERTopic、可視化と分析の分離、評価軸を別棚で読むべき
codeql-introduction-context	analysis	analyses/codeql-introduction-context.md	`PR #817` 文脈では、CodeQL は accidental な混入をきっかけに常設の security scan として整理された
codex-windows-environment-memo	analysis	analyses/codex-windows-environment-memo.md	Codex が Windows 環境で kouchou-ai / developer-wiki 作業を進めた時の環境構築メモ
current-open-issue-triage-2026-06-01	analysis	analyses/current-open-issue-triage-2026-06-01.md	2026-06-01 時点の open issue 124 件を subagent 5 分割で本文・コメントまで読み、current main と既存 wiki に照合した triage。短期優先は `#884` 作成前確認、`#885` Node runtime 排除、`#564/#696/#542` trust layer、`#877` Windows guide、`#881/#882/#869` ラベル品質実験で、`#871/#573/#558/#516/#513/#417/#379` などは close 候補
decision-flowchart-prototype-2026-05-30	analysis	analyses/decision-flowchart-prototype-2026-05-30.md	scikit-learn の estimator 選択チャートに着想を得て、広聴AI のユーザ向け / 環境構築向けの decision flowchart を Mermaid で試作。試作後に team feedback で初版の前提誤り (ラベル付きデータ jargon、Mac=Docker Desktop OK 飛躍など) を修正。ノードの意味区分は背景色ではなく明示的な文字ラベルで表現する
deploy-success-but-nothing-changed-story-2026-06-01	analysis	analyses/deploy-success-but-nothing-changed-story-2026-06-01.md	「デプロイ成功なのに画面が変わらない」という小さな違和感から、誰も触れずにいた古い設計の沼まで一日で遡って直してしまった出来事を、PR 番号や技術用語を出さずに前提知識ゼロの読者向けにストーリー化したもの。Wiki つき Coding Agent がなぜそういう動き方を続けられるのかをエピソードとして残す
development-priority-roadmap-2026-05-23	analysis	analyses/development-priority-roadmap-2026-05-23.md	2026-05-23 時点では、直近の優先順は Windows 初回導入の修復、ユーザー影響の大きい未解決バグ、公開・運用基盤の安定化、その後に説明責務と研究系改善を進めるのが妥当
digital-agency-legal-rag	analysis	analyses/digital-agency-legal-rag.md	2026-05-25 時点の wiki / meeting minutes には『デジタル庁の条文RAG』を直接説明する整理はなく、デジタル庁・eGov・一般的な RAG 活用の断片的な言及があるに留まる
experiment-result-storage-policy-2026-06-02	analysis	analyses/experiment-result-storage-policy-2026-06-02.md	実験結果の保存先を 3 層に分ける方針。`work/kouchou-ai/.../outputs/` は一時実行物、`raw/experiments/<experiment_id>/` は gitignored な一次 artifact snapshot、公開 wiki は manifest / summary / 判断だけを持つ。採用判断用実験では `factor_under_test` も記録する
experimental-features-catalog-proposal-2026-06-03	analysis	analyses/experimental-features-catalog-proposal-2026-06-03.md	LLM grouping / DivCon / Farbrain / マンダラート可視化など、CLI 内や個人 repo の実験的機能をフラットに集めるカタログを kouchou-ai 本体 docs 内に置く提案。個人 repo の stale 対策として「最終確認日」をエントリ必須項目にする
fetch-reports-deprecation-and-storage-health-2026-05-26	analysis	analyses/fetch-reports-deprecation-and-storage-health-2026-05-26.md	`fetch_reports.py` はストレージ機能が無かった時期の移行用バックアップとしては理解できるが、2026-05-26 時点の current main では Azure Blob sync/download が本線になっており、deploy 前バックアップの常設手段として残すより storage health check へ置き換える方が筋がよい
glossary	analysis	analyses/glossary.md	kouchou-ai 周辺の用語集 — 日本語特有・プロジェクト固有のショートハンド
gotchas	analysis	analyses/gotchas.md	非自明な落とし穴・ハマりどころの一覧 — 経験的に繰り返し発生する footgun
graph-visualization-proposal-2026-05-25	analysis	analyses/graph-visualization-proposal-2026-05-25.md	UMAP 2D に意味クラスタも可視化品質も背負わせる設計から抜け、`クラスタ内 MST + mutual kNN、クラスタ間 bridge edge、2 段階 cluster-separated layout` で graph drawing として可視化する案。既存 niizuma 批判への visualization 側の答えになりうる
hardware-procurement-local-ai-route-2026-05-31	analysis	analyses/hardware-procurement-local-ai-route-2026-05-31.md	広聴AIの API 契約不要 local 完結を、既存業務 PC ではなく hardware 調達込みで実現する route の整理。担当者 PC を高性能化するより、認定済み local box / appliance を 1 台置いて browser から使わせる方が現実的。単一 exe とは別物だが、自治体・組織向け pilot には筋が良い
hierarchical-status-semantics	analysis	analyses/hierarchical-status-semantics.md	`hierarchical_status.json` は branch 上で workflow path でもほぼ legacy 互換になったが、`current_job` の残し方や `duration` など一部に意味論差分が残る
human-pairwise-label-preference-experiment-2026-06-02	analysis	analyses/human-pairwise-label-preference-experiment-2026-06-02.md	ラベル品質実験では、人間に単独ラベルを批判させるのではなく、同じ tree / evidence から生成した複数ラベル案を algorithm 由来を隠した blind A/B で比較してもらう。困難な full UI 評価は label 単体・隣接ラベル集合・label と代表例に分解し、その pairwise preference を judge 較正データにする
issue-530-current-state	analysis	analyses/issue-530-current-state.md	Issue #530 の『`server/requirements.txt` を追加すべき』という処方箋は、2026-05-25 時点の current main には合っておらず、現行 repo では API 依存は `apps/api/requirements.lock` と `pyproject.toml` で管理されている
issue-707-current-state	analysis	analyses/issue-707-current-state.md	Issue #707 は 2026-05-21 に close され、backend の provider-aware verify 実装が current main で非再現だったことから、元報告は stale bug と判断された
issue-741-current-state-2026-05-26	analysis	analyses/issue-741-current-state-2026-05-26.md	Issue `#741` は 2026-05-26 時点で完全に stale ではないが、主因は当初想定の npm registry flaky よりも `main` への近接 push で deploy 更新が競合することに寄っており、公開 wiki では詳細ログに踏み込まず concurrency 課題として整理する
issue-820-current-state	analysis	analyses/issue-820-current-state.md	Issue #820 は 2026-05-21 時点で open のままで、静的エクスポート配信先における CSP 設定ガイド不足を追う issue としてまだ有効であり、app 側の dynamic CSP header 整備は `PR #848` merge により別経路で先に前進した
issue-877-windows-setup-guide-scope	analysis	analyses/issue-877-windows-setup-guide-scope.md	Issue #877 は Windows setup guide の文言修正だけでなく、Docker Desktop を標準入口にする範囲、組織管理端末で動かない場合の非サポート境界、WSL2 + Docker Engine を別ルートにするかを切り分ける issue として扱うのが妥当
issue-887-scattergl-csp-regression-2026-06-01	analysis	analyses/issue-887-scattergl-csp-regression-2026-06-01.md	PR #848 で入った env-aware CSP header と PR #887 の Plotly scattergl CSP 修正について、壊れた理由と早期検知できたテストを整理した考察
issue-priority-through-2026-09	analysis	analyses/issue-priority-through-2026-09.md	2026-05-19 時点の open issue を 9 月までの開発計画に引き直すと、最優先は `analysis-core` CLI の canonical path 固定と Web/静的公開の事故回避であり、純粋な新機能は後ろ倒しが妥当
issue-triage-open-remnants-2026-05-25	analysis	analyses/issue-triage-open-remnants-2026-05-25.md	2026-05-25 時点の current main で #79 #253 #391 #477 #537 #690 を open のまま残した理由。関連実装はあるが、Issue 本文の主要要件がまだ満たされていない
kj-method-broadlistening-framing-2026-05-25	analysis	analyses/kj-method-broadlistening-framing-2026-05-25.md	広聴AIを川喜田二郎の野外科学 / KJ法に接続すると、中心は要約ではなく `渾沌から公共的仮説を立ち上げる装置` になる。書籍 13.2.6 の `KJ法プロンプト` は prompt の話に留まらず product 設計原則として読み直せる
kouchou-ai-docs-entry-restructure-2026-06-03	analysis	analyses/kouchou-ai-docs-entry-restructure-2026-06-03.md	kouchou-ai 本体 docs の入口を「セットアップ」起点から「デモ閲覧 → 自分で作りたい人向け分岐 → 研究者・開発者向け分岐」という spine に組み替える提案。`getting-started/` というネーミング自体がバイアスを産んでいたという指摘も含む
kouchou-ai-paper-draft-ja	analysis	analyses/kouchou-ai-paper-draft-ja.md	広聴AI紹介論文の日本語下書き。まずは問題設定、システム、事例、評価、限界の骨組みを置く
kouchou-ai-paper-draft-strategy	analysis	analyses/kouchou-ai-paper-draft-strategy.md	広聴AI紹介論文の日本語下書きを wiki で育てる方針と、日本語先行か英語投稿かの比較
kouchou-ai-paper-evidence-map	analysis	analyses/kouchou-ai-paper-evidence-map.md	広聴AI紹介論文で想定する主張ごとに、既存の根拠、追加で必要な証拠、未解決ギャップを対応付けた表
kouchou-ai-scope-line-from-marketing-to-plugin-2026-06-03	analysis	analyses/kouchou-ai-scope-line-from-marketing-to-plugin-2026-06-03.md	『広聴AI のスコープはキーインサイト発見まで、その先は伴走パートナー』というスコープ線の系譜。2025-07-16 マーケ戦略 mtg を起点として、2025-11-29 鈴木健ブログ・2025-12-06 方向性会議を経て現在の plugin 化方針まで一貫している
label-coverage-policy-2026-05-29	analysis	analyses/label-coverage-policy-2026-05-29.md	label 設計の人間判断: ラベルは『目次』ではなく『要約』として、上位 2〜3 軸まではカバーする方向で整える。ただし評価基準はユースケース依存で、全体傾向把握と少数重要論点発見では sampling / rep args / judge の望ましい振る舞いが変わる。ラベルから dimension が落ちる根本原因の一つは、上流ラベリング入力が API 経由では最大30件、CLI/defaultでは10件のランダムサンプリングであることにもある
label-judge-mechanism-2026-05-25	analysis	analyses/label-judge-mechanism-2026-05-25.md	2026-05-25 時点のラベル品質 judge は OpenAI/GPT ベースの補助評価であり、`cluster 単位 judge` と `label set 全体 judge` は見ているものが違う。設計判断に使う前に Claude / 人間 judge で較正すべきである
label-quality-human-preference-improvement-plan-2026-06-03	analysis	analyses/label-quality-human-preference-improvement-plan-2026-06-03.md	ラベル品質改善の次の実務計画。既存 LLM grouping 400 件 corpus を探索材料に、`hierarchical_8_40` tree などを固定して label variants を作り、algorithm 由来を隠した A/B bundle で human preference を集め、その preference を再現する judge を較正してから evidence / labelling / tree の clean experiment へ進む。2026-06-03 に 7 件回した時点で、prompt few-shot 由来のテンプレ冗長度が confound と判明し、prompt 修正からやり直しに reset
label-quality-redesign-reset-2026-05-30	analysis	analyses/label-quality-redesign-reset-2026-05-30.md	label refinement 実験は現行実装のまま採用せず、ラベル品質改善をユースケース契約、上流入力 sampling、代表例 artifact、judge 較正、UI 表示責務に分けて仕切り直す。今回の refinement は polish-only で中身を見ず、全体傾向把握と少数重要論点発見のどちらを良くするかも未固定だった
label-quality-rubric-evaluation-2026-05-29	analysis	analyses/label-quality-rubric-evaluation-2026-05-29.md	クラスタラベル品質の judge は、抽象的な 1-5 点ではなく、binary criteria + weights + fatal penalty のルーブリック評価に分解するのがよい。まず `[8,40]` の既存 judge bundle で人間判断に合わせて較正し、標準 pipeline には入れず experimental artifact として回す
label-refinement-input-scope-2026-05-29	analysis	analyses/label-refinement-input-scope-2026-05-29.md	実験的に追加された hierarchical_label_refinement step は rep args を入力に取らず、上流ラベル + 子クラスタラベルだけを polish する設計になっている。これは『上流の merge_labelling が既に間違えたラベル』を refinement で救えない構造であり、polish が綺麗になるほど誤ラベルが固定化する危険を含む
labelling-prompt-few-shot-template-confound-2026-06-03	analysis	analyses/labelling-prompt-few-shot-template-confound-2026-06-03.md	2026-06-02 LLM grouping 400 件 corpus の human preference A/B (none vs setwise) を label_only で 7 件回した結果、全て『短い候補』が勝った。当初は labelling prompt の few-shot 例『AIによる業務効率の大幅向上とコスト効率化』が原因と整理したが、再調査で実は (1) INITIAL/MERGE labelling 段の few-shot template、(2) setwise_refine の length 制約なしによる elaboration、という 2 つの独立した issue が confound していたと判明。さらに length 制約付きの setwise_refine_short variant が既に存在していたことも分かり、仕切り直しの選択肢を 3 つに整理し直した
llm-grouping-background-history	analysis	analyses/llm-grouping-background-history.md	LLM 直接グルーピングの第2分析モードと散布図の緊張関係は、2025 4Q の『現行散布図方式の限界認識』から始まり、2026 Q1 に『可視化を分析から切り離す必要条件』として明文化されていた
llm-grouping-experiment	analysis	analyses/llm-grouping-experiment.md	LLM groupingの最初の実験は、`analysis_mode=llm_grouping` を 400 行の日本語コメントで回し、scatter 互換の見え方がどこまで耐えるかを観察するのがよい
llm-grouping-implementation-plan	analysis	analyses/llm-grouping-implementation-plan.md	LLM groupingを実装するなら、short term は workflow canonical path に `analysis_mode=llm_grouping` を差し込み viewer 互換を保ち、long term は `analysis_capabilities` と plugin `requirements` へ収束させるのが筋がよい
local-ai-runtime-user-share-estimate-2026-05-31	analysis	analyses/local-ai-runtime-user-share-estimate-2026-05-31.md	Chrome Prompt API / Foundry Local / Phi Silica などの local AI runtime を広聴AI Windows offline route に使う場合の到達率推定。Chrome Prompt API は一般 desktop では 45〜55% 程度の可能性があるが、自治体・組織貸与 PC では 20〜40% に落ちる見込み。Foundry Local は first spike 候補、Phi Silica / Copilot+ は当面 1〜5% 級の future option
nasuka-statements-retrospective-2026-05-25	analysis	analyses/nasuka-statements-retrospective-2026-05-25.md	nasuka の過去発言は、広聴AIを実利用に耐える市民参加インフラへ移すための運用・信頼・反復改善の視点として読める
niizuma-thread-algorithm-critique	analysis	analyses/niizuma-thread-algorithm-critique.md	新妻 thread は、UMAP後k-means批判そのものよりも『分析の筋の良さ』『散布図の見え方』『説明責務』が別問題だと露出させた点に価値がある
node-runtime-free-windows-exe-2026-05-31	analysis	analyses/node-runtime-free-windows-exe-2026-05-31.md	Windows 単一実行ファイル配布を再評価する前提として、Web UI の Node runtime を build-time の frontend assets に押し込み、runtime を Python/FastAPI + static assets に寄せる案は段階的には実現可能。MVP は外部 API route と API 契約不要の offline route を比較し、offline は自前 bundled-model だけでなく Chrome / Windows native local AI runtime も見るべき
non-nishio-human-pr-status	analysis	analyses/non-nishio-human-pr-status.md	2026-05-18 の stale cleanup 後、nishio 以外の人間 authored open PR は `shingo-ohki` の `#817` だけで、古い draft `#734` と `#597` は close 済み
npm-vs-pnpm	analysis	analyses/npm-vs-pnpm.md	なぜ pnpm 必須で npm 非対応か — plugin システムが要求する node_modules 分離
ohki-discussion-reflection-2026-05-25	analysis	analyses/ohki-discussion-reflection-2026-05-25.md	ohki-shingo との議論は、散布図互換の技術判断を、自治体利用で公開UIが担うべき説明責務へ引き戻したものとして読める
one-factor-experiment-principle-2026-06-02	analysis	analyses/one-factor-experiment-principle-2026-06-02.md	pipeline 実験は探索 corpus と採用判断用の clean experiment を分け、採用判断では current main baseline から `factor_under_test` を 1 つだけ変えるべきという実験設計原則。ラベル品質は単独批評ではなく A/B preference で人間評価し、複数要素変更 run は単独で winner 判定しない
open-decisions	analysis	analyses/open-decisions.md	未着地の論点・課題の整理 — 未定／方針決定済み未着手／着手済み未完了の三分類
phase3b-exit-criteria	analysis	analyses/phase3b-exit-criteria.md	Phase 3b を「完了」と書くには workflow path が production 入口として実用互換であることを示せば足り、status file の byte-level 完全互換までは必須ではない
pipeline-step-addition-framing-2026-05-27	analysis	analyses/pipeline-step-addition-framing-2026-05-27.md	直近研究で繰り返し出た pipeline step 追加案は、step 数ではなく「新しい成果物責務を first-class にするか」で判断するのが筋。境界・反例・bridge は独立成果物に、単なる label copy 改善は実験的 optional step に留める
pipeline-step-default-policy-decision-2026-05-28	analysis	analyses/pipeline-step-default-policy-decision-2026-05-28.md	PR #874 の semantic island layout 生成は実験的機能なので、現時点では標準パイプラインに追加せず、明示的に有効化する実験用経路として扱うという判断
pr-722-merge-assessment	analysis	analyses/pr-722-merge-assessment.md	`PR #722` は validation 強化の意図自体は理解できるが、2026-05-19 時点では deprecated shim を増築する stale patch なので、そのまま merge すべきではない
pr-727-merge-assessment	analysis	analyses/pr-727-merge-assessment.md	`PR #727` は問題設定自体は妥当だが、2026-05-19 時点の patch は validation が実際には動かず、API URL 解決も現行実装とずれているため、そのまま merge すべきではない
pr-735-merge-assessment	analysis	analyses/pr-735-merge-assessment.md	`PR #735` は `Issue #685` に触れる実問題を含むが、draft / conflicts / stale path 前提なので merge ではなく current tree への作り直しとして扱うべき
pr-801-merge-assessment	analysis	analyses/pr-801-merge-assessment.md	`PR #801` は React version 統一の狙いは妥当でも、current `main` では既存 `minimatch` override を消す stale patch になっているため、そのまま merge すべきではない
pr-802-merge-assessment	analysis	analyses/pr-802-merge-assessment.md	`PR #802` は crash を消す狙い自体は理解できるが、`Overview` の1箇所だけでは `result.config` 欠損への対処として不十分なので、そのまま merge すべきではない
pr-814-merge-assessment	analysis	analyses/pr-814-merge-assessment.md	`PR #814` は問題意識に沿った小さな修正だが、2026-05-19 時点では draft / review 未充足で即 merge ではなく、`BUILD_SLUGS` 経路の誤診断を先に詰めたい
pr-883-developer-quickstart-draft-2026-05-31	analysis	analyses/pr-883-developer-quickstart-draft-2026-05-31.md	PR #883 の developer-quickstart.md 再構成草案。5 読者像 (一般ユーザ / 自治体担当本人 / 組織内デモ役 / WebUI 開発者 / 分析者・研究者) ごとの推奨パス、利用主体先行の環境構築フロー、Mode 1 default 廃止、構造把握スタンスの紹介、代替ルート、を反映した全文。kouchou-ai repo の docs/development/developer-quickstart.md にそのまま置ける形
pr-883-restructuring-2026-05-31	analysis	analyses/pr-883-restructuring-2026-05-31.md	PR #883 developer-quickstart は merge を急がず、直近 1 週間で固まった整理 (利用主体先行分岐、platform 安定性ティア、Docker Desktop license の決定フロー上の重み、データ量前提、構造把握スタンス) を docs に取り込んでから書き直すべき。現状の 4 モード分岐は読者像と Mode 選択前提が暗黙のため、Docker Desktop が使えない人や自治体担当が詰む構造になっている
pr-887-pr-888-runtime-build-removal-episode-2026-06-01	analysis	analyses/pr-887-pr-888-runtime-build-removal-episode-2026-06-01.md	PR #887 の deploy success false positive を起点に、public-viewer の runtime build 撤去 (PR #888) と Dependabot 対応 (PR #889) まで 1 日で連続実行した過程を、PR 番号と検証ステップ込みで時系列に並べた技術エピソード資料
problem-list-from-open-issues-2026-05-19	analysis	analyses/problem-list-from-open-issues-2026-05-19.md	open issue 145 件から抽出すると、未解決なのは大量の個別要望ではなく、実行入口・失敗診断・公開運用・可視化・アルゴリズム・運用基盤など十数個の根本問題である
public-ui-requirements-for-broadlistening	analysis	analyses/public-ui-requirements-for-broadlistening.md	広聴結果の公開UIに求められる要件は『散布図かどうか』ではなく、量・観点・論点・個別意見への辿り、少数意見の埋没回避、恣意性の排除、次の問いの可視化。ohki-shingo の整理から導出
public-viewer-build-behavior	analysis	analyses/public-viewer-build-behavior.md	`apps/public-viewer` の build failure は Next.js bump 由来とは限らず、API 入力条件と `API_BASEPATH` 依存を切り分けて見る必要がある
public-viewer-build-serve-split-refactor-plan-2026-06-01	analysis	analyses/public-viewer-build-serve-split-refactor-plan-2026-06-01.md	public-viewer の build-time API 依存を dynamic hosting から外し、container 起動時 next build を撤去するための段階的リファクタ計画
public-viewer-runtime-build-history-2026-06-01	analysis	analyses/public-viewer-runtime-build-history-2026-06-01.md	public-viewer が container 起動後に next build する構成になった歴史的経緯と、deploy readiness 誤読リスクにつながった堆積を公開可能な粒度で整理
pypi-auto-release-requirements	analysis	analyses/pypi-auto-release-requirements.md	`kouchou-ai-analysis-core` の PyPI 自動更新に必要なのは tag 起点の GitHub Actions、PyPI 認証、package 専用の build/test 配線
pypi-release-timing-automation	analysis	analyses/pypi-release-timing-automation.md	PyPI リリースの『タイミング自体』を自動化するか否かの判断。現状の tag 起点 semi-auto を維持し、自動化を進めるなら Trusted Publishing と TestPyPI 経路の方が先
pypi-release-trigger	analysis	analyses/pypi-release-trigger.md	`analysis-core` の PyPI リリースは `analysis-core-v*` tag push 時に発生し、merge や main push だけでは起きない
refactoring-status	analysis	analyses/refactoring-status.md	v5 リファクタの実装状況 — Phase 0〜8 の主要移行は main で完了し、残るのは package 配布・status semantics・周辺 docs の follow-up
remaining-bug-issues-2026-05-26	analysis	analyses/remaining-bug-issues-2026-05-26.md	2026-05-26 時点で open の `[BUG]` タイトル issue と周辺ラベルを current `origin/main@e5ed74380b6a18bb3d1e7d5f6408c7f4b3b55381` で見直すと、`#741` だけが `bug` ラベルを保ち、`#121` `#283` `#478` は上位検討 issue `#872` の参考課題として bug ラベルを外し、`#731` は stale 寄りで再観測または close 判断が必要
remaining-issue-priority-2026-05-29	analysis	analyses/remaining-issue-priority-2026-05-29.md	2026-05-29 時点の open issue 121 件を全件メタデータ確認し、本文を古い high-priority / user-facing issue まで読み直すと、project-wide 優先は `#221` 試行錯誤負担削減と `#564` 活用事例公開であり、tactical next は進行中 PR 着地と Windows / cost / API 不安の解消である
report-slug-config-behavior	analysis	analyses/report-slug-config-behavior.md	`reports/:slug` は current 通常生成物なら `config` を返すが、router に validation が無いため壊れた成果物から `config` 欠損 payload を公開しうる
semantic-island-map-prototype-2026-05-26	analysis	analyses/semantic-island-map-prototype-2026-05-26.md	`LLM grouping` された 422 argument の 2D 可視化を `UMAP` / supervised UMAP / LDA / centroid-MDS で試した結果、embedding 由来散布図を主図にするより、cluster-first な semantic island map の方が要件に合うと分かった
slack-algorithm-themes	analysis	analyses/slack-algorithm-themes.md	`#2_開発_広聴ai_アルゴリズム開発` から読めるアルゴリズム設計判断 — UMAP後クラスタリング批判、分析と可視化の分離、対立軸・taxonomy・LLM分類
slack-design-intents-2025-q4	analysis	analyses/slack-design-intents-2025-q4.md	2025 4Q の `#2_開発_広聴ai` から読める設計意図の整理 — 現行方式の限界、long-context LLM 直接分類志向、JSON/YAML カスタマイズ、v4/v5 分離
slack-design-intents-2026-q1	analysis	analyses/slack-design-intents-2026-q1.md	2026-Q1 の `#2_開発_広聴ai` から読める実装意図の整理 — 再利用、plugin UX、LLM grouping 系分類、可視化分離
strategic-development-order-2026-05-23	analysis	analyses/strategic-development-order-2026-05-23.md	Issue 消化順ではなく、CLI / workflow / plugin / Web 配布を 3 層のプラットフォームとして見ると、先に固めるべきなのは `analysis-core` の共通基盤と plugin 実験の本番導線である
tokoroten-algorithm-discussion-retrospective	analysis	analyses/tokoroten-algorithm-discussion-retrospective.md	tokoroten とのアルゴリズム議論は、クラスタリング手法の優劣ではなく、散布図プロダクト・深い分析・説明責務・運用ワークフローを分け直す議論だった
tokoroten-spectral-clustering-reading	analysis	analyses/tokoroten-spectral-clustering-reading.md	tokoroten の spectral clustering メモは、TTTC を『高次元で正しく切る手法』ではなく『UMAP が作る 2D 形状を前提に切る散布図寄りの手法』として理解していた点が重要
trial-and-error-burden-reduction-2026-05-29	analysis	analyses/trial-and-error-burden-reduction-2026-05-29.md	`#221` 系は単一機能ではなく、作成前確認、API/billing preflight、入力検証、進捗可視化、再利用の5面で「怖くて試せない」「失敗理由が分からない」「やり直しが高い」を減らすテーマである
tttc-to-analysis-core-history	analysis	analyses/tttc-to-analysis-core-history.md	TTTC の clone / CUI 前提から、Web UI で包んだ広聴AI、さらに PyPI の analysis-core をサーバが呼ぶ現在形までの入口設計の変遷
umap-seed-history	analysis	analyses/umap-seed-history.md	UMAP / k-means の seed 固定は「完全再現性を実現した仕組み」ではなく、「見た目の揺れを少しでも抑えたい要求」から生まれ、後に並列性とのトレードオフとして見直された
versioning-strategy	analysis	analyses/versioning-strategy.md	v4 凍結 / v5 plugin 化のリリース戦略 — 書籍出版とのリスク調整
wiki-pages-publishing-stack	analysis	analyses/wiki-pages-publishing-stack.md	developer-wiki の GitHub Pages 配信は、現状の MkDocs adapter より Quartz を第一候補にした方が wiki の記法と公開体験が揃いやすい
windows-distribution-options	analysis	analyses/windows-distribution-options.md	非専門家 Windows ユーザー向けの kouchou-ai 配布形態を、`setup_win.*` スクリプト / ランチャー exe / デスクトップアプリ / 完全単体 exe の 4 段階で整理。2026-06-01 定例では、短期は手元 Windows 起動より Azure 体験環境を優先しつつ、Windows standalone と local LLM route は探索を続ける位置づけになった
windows-real-machine-e2e-lessons	analysis	analyses/windows-real-machine-e2e-lessons.md	Issue #860 / PR #862 の Windows 実機 E2E 構築で分かった self-hosted runner と Docker Desktop の落とし穴
windows-setup-encoding-decision	analysis	analyses/windows-setup-encoding-decision.md	Windows setup で日本語メッセージを扱う時、`.bat` 単体でコードページ差異を吸収するのは難しく、ASCII ランチャー + PowerShell 本体へ分離する判断が妥当、という理由整理
workflow-defaultization-blockers	analysis	analyses/workflow-defaultization-blockers.md	`run_workflow()` default 化を止めていた主 blocker は main で解消され、Phase 8 cleanup 後はいま何が follow-up だけ残っているかを切り分ける履歴ページ
worktree-hygiene	analysis	analyses/worktree-hygiene.md	`work/kouchou-ai/` は current issue の作業場として保ち、別件試作は dedicated worktree に逃がし、canonical でない local 生成物は ignore まで含めて早めに掃除した方が混乱が少ない