観測範囲

2026-10-12。kouchou-issue-audit-queue 経由の依頼「全 open Issue の棚卸し」に基づく。目的は Issue を減らすこと自体ではなく、現行実装で満たした要件と残件を区別し、完了済みを close 候補として洗い出し、次に利用者の問題を解決する一手を明確化すること。重い実装作業は行わず、読み取り調査に限定した。

対象は open Issue 総数 105 件。うち 95 件を今回 2026-10-12 に 10 シャード並列で current main c297bc97bb2bbce42964a90d7501c2d3592aeaf0 にコード照合した(根拠と未確認範囲は issue-audit-2026-10-12-full、生データは raw/issue-audit/2026-10-12-full/shard-*/)。残る 10 件(#11 #44 #52 #55 #56 #60 #79 #104 #121 #143)は 2026-10-11 に同基準で調査済みで、issue-backlog-audit-2026-10-11 の判定を再利用する(当時も解決済みゼロで close 無し)。

今回 close した Issue は 0 件。 close 検証ステップの結果も「close 実行対象なし」で、verdict の上書きは無かった。解決済み(resolved)/不明(unknown) と判定した 4 件(#417 #519 #573 #871)は、いずれもコード上の file:line 完了条件を持たない実験型・外部成果・プロセス系で、close 判断に人間の確認(外部レポート公開状況・実機再現・maintainer 合意)が要るため close 候補だが未 close として残した。上流 Issue の本文編集・コメント・assign・merge・人への催促はしていない。

集計(今回95件 + 再利用10件)

今回 95 件の判定内訳:

判定件数番号
未解決47#170, #172, #173, #186, #190, #236, #250, #266, #293, #323, #324, #337, #339, #342, #345, #346, #366, #445, #454, #470, #493, #503, #507, #513, #548, #556, #564, #576, #638, #641, #643, #648, #679, #869, #879, #880, #882, #912, #913, #953, #954, #956, #960, #962, #964, #971, #972
一部解決31#176, #211, #221, #280, #285, #292, #295, #306, #310, #364, #370, #374, #395, #450, #496, #515, #516, #518, #537, #542, #546, #547, #558, #586, #592, #669, #809, #876, #881, #885, #949
要件再確認13#213, #227, #255, #289, #308, #464, #471, #474, #517, #529, #577, #898, #921
解決済(close候補)3#417, #573, #871
不明1#519

再利用 10 件(issue-backlog-audit-2026-10-11): 未解決6(#11 #44 #56 #60 #79 #121)/ 一部解決3(#52 #55 #143)/ 要件再確認1(#104)/ 解決済0。

close 候補だが未 close(人間の判断待ち): #417(CodeRabbit 導入+ガイドラインで『コードレビューの効率化』を達成とみなすか maintainer 確認)、#519(エネルギー庁パブコメ分析レポートの公開状況が repo 外で検証不能。nishio に確認)、#573(PLaMo-Embedding-1B 動作実験は完了・現行モデル優位と結論。実験型で file:line 完了条件なし)、#871(Azure deploy safety を Blob health check へ切替済だが受入条件の read-back 未充足・判断根拠の docs 明記が残る)。

全105件 判定一覧

列: 番号 / 題名 / 担当 / 判定 / 満たした範囲 / 残件 / 根拠(file:line) / 関連PR / 次の一手 / 確度 / close済み? 。長文は要約。各件の全文根拠は raw/issue-audit/2026-10-12-full/shard-*/results.json(今回分)と issue-audit-2026-10-11-batch1(再利用分)にある。

今回調査(2026-10-12, 95件)

#題名担当判定満たした範囲残件根拠関連PR次の一手確度close済み?
170[FEATURE]ファクトチェック機能の実装-未解決なし。コメントの真偽判定・虚偽argument除外・散布図での虚偽表示変更のいずれも未実装。ファクトチェック処理そのもの(分類・真偽判定・クラスタ生成への組込)が全て未着手。grep -ril ‘factcheck|fact.check|ファクトチェック|虚偽’ で実装ヒット0(py/ts/tsx, node_modules除く)。experiments配下は direct_win / embvec_reduce_public_comment / evaluat…実験用スピンオフ #324(masatosasano2が2025-04-17に作成と明記)。コードPRなし。まず #324 の実験(コメントをファクト/非ファクトに分類→真偽判定)をプロダクト独立スクリプトで実施し妥当性評価。コメント中の真偽判定の難しさ(masatosasano2の論点)が未解決の設計前提。highいいえ
172[FEATURE]クラスタ説明文におけるグラウンディングの実装-未解決なし(グラウンディング=説明文の根拠argumentを紐づけたテキスト生成・表示は未実装)。クラスタ説明文に根拠argumentを紐づけたテキストを生成・表示する機能が未実装。grep -ril ‘grounding|グラウンディング’ でヒット0。隣接機能 enable_source_link は hierarchical_aggregation.py:298 / hierarchical_visualization.py:402 で元コメントのURLリンクを付すの…なし。実験は #173 に分離。#173 の実験スクリプトを先行。source_link(URL参照)とは別物として、説明文の各主張に支持argumentを対応させる生成方式を検討。mediumいいえ
173[FEATURE]グラウンディングの実験-未解決なし。グラウンディング実験スクリプトが存在しない。実験スクリプト実装・検証データへの出力・結果確認の全てが未着手。experiments/ 配下に grounding 関連ディレクトリ・スクリプトなし(direct_win / embvec_reduce_public_comment / evaluation_report のみ)。grep ‘grounding|グラウンディング’ ヒット0。なし。親Issue #172。experiments/ 下にグラウンディング実験スクリプトを追加し検証データで出力・評価。#172 の前段。highいいえ
176[FEATURE]LLMベースの分類機能の実装-一部解決LLM直接グルーピング(LLM grouping)のコア処理が analysis-core に実装済・テスト済。steps/llm_grouping.py(group discovery + batch assignment, 座標はembedding由来を保持)、workflows/llm_gr…プロダクト統合が未達:admin作成UI・API が analysis_mode を受け付けない(grep ‘analysis_mode’ は apps/admin・apps/api/src でヒット0、page.tsx の送信bodyにも無し)ため利用者は…packages/analysis-core/src/analysis_core/steps/llm_grouping.py, workflows/llm_grouping_compatible.py, workflows/init.py:20, tests/test_llm_groupi…未特定(engine実装は複数PRでmain反映済とみられるが本調査ではPR番号未照合)。admin作成UIに分析方式(LLM grouping)選択を追加しAPIで analysis_mode を受理する統合PRのスコープ確認。実験相当はengine側で概ね完了。mediumいいえ
186[FEATURE]CSVをJSONに変換せずに送信したい-未解決なし。依頼のアーキテクチャ(FormDataでCSVファイルを直送→サーバでUploadFile受領→inputs/xxx.csv保存、フロントのバリデーション/ID生成廃止)は未実装。フロントは今も papaparse でクライアント側parse→comments配列(JSON)化してAPIへ送信。サーバはcomments配列を受けてCSVを再構築。冗長変換・通信サイズの課題は未解消。apps/admin/app/create/parseCsv.ts:3,15(Papa.parse でクライアントparse)、apps/admin/app/create/page.tsx:105-129,213(comments配列を組み立て request body の comments: に…なし(本調査では未特定)。関連 #132(スプレッドシート入力)。フロント FormData 直送+バックエンド UploadFile 受領の実装検討。#132 のスプレッドシート経路との整合に注意。highいいえ
190[FEATURE]1回のextractionで複数のcommentを処理する-未解決なし。1リクエスト複数コメント処理(提案のバッチプロンプト)は未実装。現状の extract_batch は ThreadPoolExecutor で1コメント=1リクエストを並列実行するのみ(rate limit requests/min の緩和にならない)。1回のLLM呼出で複数コメントをまとめて抽出する方式が未実装。packages/analysis-core/src/analysis_core/steps/extraction.py:175-192(executor.submit(extract_arguments, input, …) を batch 内の各コメントに対し個別submit)。docst…#246(CLOSED, 未merge。nishio/nasukaコメント: Devin実装が途中で停止しクローズ)。複数コメントを1プロンプトで処理するresponse format(id→抽出list のJSON)へ変更しプロンプト検証(短文/長文両ケース)。周辺parse実装の変更が必要。highいいえ
211[FEATURE]OOMの事後処理-一部解決分析処理が別subprocessで実行されAPI側の監視スレッドが看取る構成に変更済。_launch_analysis_process が Popen で起動し daemon Thread の _monitor_process が process.wait() の戻り値を監視、非ゼロ終了(OOM …Issueが提案した『statusにpidを持ち、一覧API呼出時に未完了レポートのプロセス生存を確認してerror化』は未実装(report_duplicate.py:43のpidはlock用途、一覧APIにliveness判定なし)。API/監視スレッド…apps/api/src/services/report_launcher.py:190-253(_monitor_process: retcode!=0 → error), 256-266(_launch_analysis_process: Popen + 監視Thread)。pid: apps…なし(本調査では未特定)。whole-containerOOMケース向けに、一覧API(admin_report.py)で未完了レポートのstale判定(pid生存 or タイムスタンプ)を追加するか要否を判断。現行の子プロセス監視で主ケースは…mediumいいえ
213[FEATURE]5→50の表記を50→5に変えるか?-要件再確認判断保留のまま。現行mainは今も『5→50』(level1→level2)表記。表記方針が未合意。takahiroanno=認知順(5が先)でママ維持を主張、nishioは意見分裂を理由に good first issue を外しタイトルを疑問形に変更。決定が必要。apps/public-viewer/components/report/Analysis.tsx:114-125(level1ClusterNum → level2ClusterNum の順で表示、ラベル『集約した意見グループ数』)。現行は5→50のまま。_op-image.tsx:265 も同…なし。人間が表記方針(5→50維持 or 50→5へ)を決定。変更する場合はnishio指摘の別箇所(スクショ参照)も合わせる。実装は小。方針決定が先。highいいえ
221(情報整理)試行錯誤の負担を減らす-一部解決umbrella/high priority Issue。具体実装のtracking issue #884 が派生し、作成前確認パネルで #11/#79/#292/#391/#97 を束ねて進行中(nishio 2026-05-29コメント)。『試行錯誤の負担を減らす』全体は未達。クラスタ数変更の高速再試行(#19関連)、extractionの試行錯誤軽減、大量件数投入前の確認ダイアログ等の個別残件。nishioが明示的にumbrellaとして存続させる方針。Issue本文(4/2定例メモ)+nishio 2026-05-29コメント『#221 は umbrella として残し、#884側で作成前確認パネルに #11/#79/#292/#391/#97 を束ねる』。tracking: #884。関連: #11, #79, #19, #241。umbrellaとして存続(closeしない)。#884 側の進捗を本Issueから参照。個別残件は子Issueで追跡。highいいえ
227[FEATURE]濃い意見グループの設定画面について-要件再確認濃い意見グループ設定ダイアログが再設計済(DisplaySettingDialog.tsx)。見出しと説明が縦並び、区切り線で『表示設定』と『濃い意見グループ設定』を分節化、閉じるトリガ(DialogCloseTrigger)あり。Issueの一部指摘(見出し/説明の縦並び化、濃いグループ設定の独…Issueのスクショが指した旧UIの具体指摘(最小クラスタ2以上/上限10、2,5,10,25,50,100の選択式、閉じるボタンが文章に被る)は、現行ダイアログがmaxDensity/minValueの2スライダ構成へ再設計されており該当しない/検証困難。…apps/public-viewer/components/report/DisplaySettingDialog.tsx:40-139(縦並び見出し/説明、区切り線、濃い意見グループ設定セクション、maxDensityスライダ0.1-1、minValueスライダ0-10、DialogCloseT…なし(本調査では未特定)。現行DisplaySettingDialogを実表示で確認し、元の設計意図(選択肢の粒度・被り・配置)が満たされたか人間が再確認。満たされていれば残指摘を切り出すかclose判断。mediumいいえ
236[FEATURE] パブコメモードに回答案を追加する-未解決なし。is_pubcom モードは存在するが(apps/api/src/services/report_launcher.py ほか)、意見概要に対する『回答案』を生成する機能は未実装。回答案作成用プロンプト・パブコメモードの『回答案作成』オプション・CSVへの回答列追加・(将来)RAGでの公式文書参照。いずれもコードに存在しない。grep ‘回答案|answer_draft|draft_answer’ が apps/packages で 0 件ヒット。pubcom 関連は is_pubcom CSV出力(hierarchical_aggregation.add_original_comments)のみで回答生成なし。なし回答案生成プロンプトの設計と、pubcom出力CSVへの回答列追加の小さな実験。RAGは後段。highいいえ
250[FEATURE]階層図で一番下まで到達した時には原文を見せても良いのではないか-未解決抽出済み意見(argument)は階層図末端で閲覧可能(PR #927 系)。元コメント本文は is_pubcom 時に admin 向け CSV final_result_with_comments.csv へ出力される。viewer の階層図末端に『元コメント原文』を表示する経路が無い。元コメントは packages/analysis-core/src/analysis_core/steps/hierarchical_aggregation.py:178 add_origi…add_original_comments の出力は final_result_with_comments.csv(admin専用)であり viewer JSON(hierarchical_result.json) には原文を入れていない。body の 2026-09-09 追記も『PR #927…#927 (merged, 抽出済み意見の末端表示), Serverless PR #25; #56 で公開可否を共通化per-comment 再頒布可否フラグ設計(#56連動)→viewer 末端に原文 opt-in 表示→N重複の集約。mediumいいえ
255(情報整理)OpenAIが使えないケースのケアnishio要件再確認技術的代替(Gemini/Azure/local/OpenRouter)は現行mainに存在し docs でも案内済み(#285と重複する範囲)。この issue 固有の『情報整理』成果物が未完: (A) Azure OpenAI の政治利用可否を調べFAQ化して close、か (B) NG条件の整理。masatosasano2 が『そもそもChatGPT政治利用NGという障害は無いのでは』と前提自…コメント #255 の議論(nishio: Deep Research→FAQ案 / masatosasano2: 規約上抵触しない可能性)。README/docs に政治利用可否FAQは見当たらず(Gemini鍵取得等の手順はある)。assignee=nishio。なし(#285 の多プロバイダ対応と関連)人間が『Azure/各APIの政治利用可否』の結論とFAQ要否を判断。技術的代替は #285 で追跡。mediumいいえ
266[FEATURE]クラスタ数が増えた場合に散布図上でクラスタラベルが被ってしまう-未解決ラベル表示/非表示トグル(showClusterLabels)とラベル折り返し・最大幅指定あり(ApScatterChart.tsx:109-132, 472-495)。回避手段(非表示)は存在。ラベルを『表示したまま』多クラスタで重なりを解消する仕組み(衝突検出・位置調整・省略・ホバー時拡大/強調)は未実装。annotation は固定位置で描画。#294 を集約した合意要件(表示したままグループ名を読める)未達。apps/public-viewer/components/charts/ScatterChart.tsx の annotations は固定座標の plotly annotation。overlap/collision 処理なし。body 2026-09-09 追記も『表示したままの重なりは未解…#933 (日本語禁則/スマホ初期リスト表示; ラベル衝突自体は未解決)同一レポートでフォント縮小/位置調整/ホバー拡大案を比較し重なり解消案を選定。highいいえ
280[FEATURE] テスト用のパブコメデータをCSV化するei-blue一部解決環境省(除去土壌)・経産省(エネルギー計画)のパブコメCSVがコメントで作成・共有済み(kankyou_pubcom.csv / output_random_kankyou.csv / eng_pubcom.csv / eng_pubcom_random.csv, clean_pubcom.ipy…成果物はGitHub添付/gistに留まり、repo内のテスト fixture やデータセットとして未コミット。内閣府(新型インフル行動計画)分は形式が汚く未完と報告。再現可能な配置(#143評価harnessとの連携)が無い。assignee=ei-blu…find で repo 内に pubcom/kankyou CSV は未発見(experiments/embvec_reduce_public_comment/detect_dup_kankyou.ipynb は別物)。CSVはコメントの user-attachments リンクのみ。なし(#143 クラスタ品質評価のデータ整備と親和)共有済みCSVを experiments 配下へコミットし、出典/ライセンスと要約正解ラベルを添えて再現可能化。mediumいいえ
285[FEATURE]利用可能なLLMを増やす-一部解決当初前提(OpenAIのみ)は解消。現行mainは OpenAI/Azure/Gemini/OpenAI互換LocalLLM/OpenRouter を dispatch(packages/analysis-core/src/analysis_core/services/llm.py:589-633…『対応可能』と『実モデルで動作確認済み』を混同しない案内が残件。OpenRouterの接続方式/構造化応答/対応モデル検証は #537、実モデル検証は #912/#913 に分離。OpenRouterへの統一や未確認の無料/データ条件の保証は結論にしない。request_to_chat_ai の provider 分岐に azure/openai/local/gemini/openrouter 全てあり。docs/development/model-catalog.md が実API検証を #912/#913 へ委譲と明記。#909(カタログ), #912/#913(実モデル検証), #537(OpenRouter検証)#537 の OpenRouter 仮説を現行LLMクライアントで再検証し、動作確認済みモデルの明示に反映。highいいえ
289[FEATURE]exe形式での配布によるインストール簡略化-要件再確認なし。exe/単一実行ファイル配布は未実装。方針自体が未決。label=wontfix 付与済み。nishio が『Docker導入が認められない環境では exe も認められないのでは』と効果に疑問。exe化の技術的検討メモ(pkg/Electron等)のみ。close-as-wontfix か継続か…labels に wontfix。コメントは技術検討メモのみで実装着手なし。なしwontfix維持でcloseするか、別の導入簡略化(ホスト版/インストーラ)に振るかを人間が決定。mediumいいえ
292[DOCUMENT]OpenAI APIの課金設定に関する混乱-一部解決アプリ側で環境検証ダイアログが insufficient_quota→『デポジット残高が不足しています。チャージしてください。』、無効キー案内を表示(apps/admin/app/create/components/EnvironmentCheckDialog/EnvironmentCheckDi…issue主眼の docs(ChatGPT Plus と API課金は別、429 の意味と対処)を README/開発者docsに明記する点が薄い。nasuka も『開発者向けdocsに追記』を課題化。nishio 2026-05 で #884 の下位論点と…docs/getting-started/*-setup.md はクレジットチャージ注記のみで『ChatGPT Plus≠API課金』の明示が見当たらず。429/quota 説明は EnvironmentCheckDialog の UI 文言が主。#884 (作成前確認パネル umbrella)README/開発者docsに ChatGPT Plus vs API課金の区別と 429 の対処を明記し、UI案内と相互リンク。mediumいいえ
293[FEATURE]レポート表示画面上で、使用したプロンプトを直接編集可能にする-未解決なし。現行はレポート表示画面からプロンプト編集・再生成する経路が無い。既存は admin の複製ダイアログ(DuplicateReportDialog)で複製→設定調整→再生成という issue が問題視した往復フローのまま。レポート表示画面へのプロンプト編集欄+『更新して再生成』ボタン、作成権限者限定の権限制御、再生成コスト確認UI。nishio が実装方針の再検討も示唆(design ラベル)。grep で再生成/プロンプト編集UIは ScatterChart と admin/DuplicateReportDialog のみヒット。public-viewer にレポート内プロンプト編集・再生成は無し。なし権限制御前提で、レポート画面内プロンプト編集→再生成の最小UI設計(TTTCTurbo参考)。方針是非は要確認。highいいえ
295OpenAI API Rate Limit関連の問題-一部解決(1)指数バックオフ付きリトライ実装済: OpenAI(llm.py:97-103 tenacity wait_exponential, stop_after_attempt(3), reraise=True)、Azure(189-194)、Gemini(384-481 独自バックオフ max_r…docsでのTier制度周知(自分のTier/Limit確認方法・Tier引上げ条件のREADME記載)が薄い(flex処理docはあるがTier案内は限定的)。代替API(OpenRouter)は『検討』項目で、現在は実装済みだが本issueの結論として統…_labelling.py LabellingBatchError とラベリングステップからの raise、llm.py の tenacity retry 設定を file:line で確認。docs/development/openai-flex-processing.md:31 が通常429は…なし特定(retry/abort は main 反映済み)README に Tier確認手順/引上げ条件を追記し docs 周知を補完。中核のエラー中断・リトライは main で検証済み。highいいえ
306[FEATURE]「全体図」「濃い意見グループ」のUI/UX改善-一部解決散布図の操作性は再設計で改善: ScatterChart.tsx:508 uirevision:‘scatter’(表示モード/全画面切替後も状態保持=#290懸念に対応), :521 dragmode:‘pan’(パン有効化), :530 displayModeBar:‘hover’(ズームボタ…明示的な『操作ヒントアイコン/ヒント表示』は未確認(見当たらず)。『濃い意見グループが第一階層のどのクラスタに属すか』の帰属可視化も未確認。design wishlist複数項目のうち一部のみ対応で完了基準が曖昧。apps/public-viewer/components/charts/ScatterChart.tsx:508,521,530,532なし(特定せず)残項目(ヒントアイコン、濃いグループ→親クラスタ帰属表示)の要否を人間確認し、必要なら個別issueに分割。mediumいいえ
308[FEATURE] HTMLフォーム入力による広聴AIシステムの簡易デプロイ機能-要件再確認なし(実装なし)。labels に wontfix。議論で nasuka がコスト/維持/ターゲット不明の懸念、nishio が最終コメント(2025-04-21)『ドキュメントの充実とレポート共有機能の強化が優先度高そう』で事実上の保留/非採用方向。方針判断: wontfixとして not_planned close するか、将来検討としてbacklog保持するかを人間が明示決定する必要。現状mainに該当機能は無く、合意要件も未確定。issue本文/コメント(shingo-ohki PoC repo, nasuka, nishio)。wontfixラベル。なし維持者がwontfixとしてclose(統合先=ドキュメント充実/レポート共有系issue)するか判断。close-as-not_planned案を用意可。mediumいいえ
310[FEATURE] LLMが出力した結果の手動修正機能(編集機能)がほしいnasuka一部解決クラスタのタイトル(label)と説明(description)の編集は現行mainで完全実装・レポート反映まで確認。admin UI: ClusterEditDialog.tsx(label Input:214 / description Textarea:226)。API: admin_rep…issue本文が挙げた argument(個別意見) と 概要(overview) の編集は未実装。nasukaコメント(2025-05-24)『意見グループの修正機能はDone・その他の要素については未実装』。編集履歴の保持も未対応(議論の余地として本文に…apps/admin/app/_components/ReportCard/ClusterEditDialog/ClusterEditDialog.tsx:214,226; apps/api/src/routers/admin_report.py:380-398; apps/api/src/rep…なし(特定せず、main反映済み)argument/概要の編集要否を確認し必要なら残要件として別立て。担当nasukaの進行を尊重。highいいえ
323[FEATURE] レポートの多言語対応-未解決合意要件『出力言語を選択できるようにする(Pol.is的な翻訳機能)』に対応する言語選択UI/機能はmainに無い。回避策のみ存在: extractionプロンプトに翻訳指示を書けば翻訳される(mtane0412が2025-04-19にレポートで実証)。プロンプトはレポート単位でカスタマイズ可。出力言語を選択する機能(language selector)そのものは未実装。プロンプト編集(別経路)と言語選択機能(合意要件)を混同しない。多言語混在データの実運用(異言語住民への同一調査)シナリオ対応も未整備。issueコメント(nishio/mtane0412)の手動プロンプト回避策。mainに言語選択UI不在。なし『プロンプト注入で足りる』か『言語選択UIを作る』かを要件再確認。デフォルト翻訳プロンプト同梱案(mtane0412提案)の採否も含む。mediumいいえ
324(実験)ファクトチェックロジックの実験masatosasano2未解決なし(実験Issue)。masatosasano2が /assign 済み、外部repo masatosasano2/factcheck-experiment で着手(2025-04-22)。方針(怪しいものは弾かず明確な偽情報のみNG)はnasuka合意。実験成果・結論が本体にもIssueにも未反映。コード配置はidobata側repo統一後に検討とされ前提未確定。進行中の外部作業で、プロダクト統合は後段。issueコメント(masatosasano2 /assign, 外部repo着手宣言)。本体mainに該当コード無し。なし(外部repo masatosasano2/factcheck-experiment)担当masatosasano2に実験の現況/結論を確認し、本体統合可否を判断。担当作業は奪わない。mediumいいえ
337[FEATURE]「全体図」と「階層図」の意見グループの色を揃えるmasatosasano2未解決なし。現行mainは散布図と階層図で独立した配色: ScatterChart.tsx:45 softColors(鮮やか 7ac943等)をクラスタindexで割当(:90 clusterColorMap)。TreemapChart.tsx:138 colorway(パステル b3daa1等)…全体図(scatter)と階層図(treemap)の意見グループ色をクラスタ識別子で揃える実装が無い。担当masatosasano2は色合わせ単体ではなく全面再設計(単一散布図ビュー/Bonsai方向)をsandbox repoで探索中・未merge。apps/public-viewer/components/charts/ScatterChart.tsx:45,90; apps/public-viewer/components/charts/TreemapChart.tsx:97,138なし(外部 masatosasano2/kouchou-ai-view-sandbox で探索)色合わせの局所対応(treemapにclusterColorMapを適用)を行うか、masatosasano2の再設計探索の結論を待つか方針確認。highいいえ
339[FEATURE]同義語マップがほしい-未解決なし。クラスタリング前処理に同義語マップ/読み替えを差し込む機構はmainに無い(synonym関連grepは pricing/model_catalog/youtube の無関係一致のみ)。デフォルトマップ・ユーザーマップの仕組みも無し。同義語マップ注入・デフォルトマップ整備・ユーザーマップ反映の全要件が未着手。発起者masatosasano2自身『どの程度のニーズ/効果があるか確認できていない』とニーズ未検証。mainに同義語前処理コード不在(apps/api/broadlistening, apps/api/src の grep で該当無し)。なしまず小規模実験でクラスタリング精度への効果を検証(ニーズ確認)してから実装要否を判断。mediumいいえ
342[FEATURE]文脈をふまえた生データの整形-未解決なし。返信元/引用元/直前投稿/添付メディア等の文脈を生データに付与する前処理はmainに無い。コメント0件・担当無し・議論未展開。文脈付与前処理の設計・実装すべて未着手。対象(X投稿等)の入力経路・文脈取得方法も未定義。mainに文脈前処理コード不在(reply/quote/前処理 grep で broadlistening に該当無し)。なし対象データ源と期待する整形例を具体化し、小規模実験で効果を確認してから要件化。mediumいいえ
345(情報整理)同一の内容が大量に投稿される問題への対処法-未解決なし。大量類似投稿(パブコメ大量投稿)によるフロント負荷/バックエンドコスト/認知負荷の3問題に対するアルゴリズム的対処はmainに未実装(report_duplicateはレポート複製機能であり近似意見の統合ではない)。本Issueは情報整理の親Issue。実験は子Issue #346。対処アルゴリズムの検証→本体実装は未着手。進め方(独立スクリプト実験→API統合→GUI)の段階1から。apps/api/src/services/report_duplicate.py(=レポート複製で別物); mainに近似意見まとめ処理不在。なし346の実験結論を待ち、親Issueとして残要件(フロント描画負荷/コスト/認知負荷の各対処)を整理。#346と役割分担を保つ。mediumいいえ
346(実験) 同一の内容が大量に投稿される問題への対処法-未解決なし(実験Issue)。nasukaが外部repo nasuka/kouchou-ai-clustering-experiment でデータ拡張(LLMで類似文生成)とクラスタリング比較を実施(2025-04-21/22)。『人間のまとめとはかなり異なるクラスタが形成されていそう』で分析途中。類似意見を事前にまとめる手法の妥当性が未確定・未結論。プロダクト統合は後段。nasukaコメント(2025-04-23)で複数アプローチ歓迎・サブIssueで検証継続の運用。本体mainに該当機能無し。issueコメント(nasuka 外部notebook/実験)。mainに近似意見まとめ機能不在。なし(外部 nasuka/kouchou-ai-clustering-experiment)検証アプローチごとにサブIssueを立て結論を集約。有効性確認後に親#345で機能実装Issue化。mediumいいえ
364[FEATURE] 個別レポートのパスワード認証-一部解決限定公開ステータス(public/unlisted/private)は実装済み。apps/api/src/schemas/report.py:13-16 ReportVisibility enum、apps/admin/app/_components/ReportCard/Visibility/V…Issueの明示提案『BASIC認証 / レポートごとの個別パスワード』は未実装。visibility(=listed/unlisted/private)はURL限定公開であってパスワード保護ではない。passwordフィールドはschemaに無い。report.py:13-16(enum), Visibility.tsx(3状態メニュー, passwordなし), schemasにpassword項目なしnone openunlistedで要件が満たされるか(=パスワードまで要るか)を人間が再確認。必要ならvisibilityとは別軸でper-report passwordをschema/APIに追加する設計から。highいいえ
366[FEATURE] 複数の公開リスト-未解決なし(レポートは依然として単一リストに自動追加)。visibility追加で『作成即公開』懸念の一部は別経路で緩和されたが、複数リスト機能そのものではない。『リストを複数作成し、レポートをリストに登録』は未実装。apps/admin/apps/api/apps/public-viewer にreport-list/collection機能は見当たらず(createListCollectionヒットはChakra…apps配下にreport list/collectionのmodel/router/UIなしnone openIssue本文自身が『まだhigh priorityでない』と明記。unlisted実装後に複数リストの実需を再確認してから設計。mediumいいえ
370[FEATURE]パブコメ大量投稿対策の省庁向け実用ツールnishio一部解決experiments/embvec_reduce_public_comment に実験コード(SentenceTransformer埋め込み+重複排除のnotebook群 detect_dup_*.ipynb)あり。nishioコメントで技術レポートを別repo(nishio/experimen…本repo内のMVP(省庁担当者が直接実行できる独立Pythonスクリプト+README)は未達。中身はnotebook+1行READMEのみで、.pyスタンドアロンスクリプトなし。本格productは『開示請求が通った本物データ受領後』にSlackでブロッ…experiments/embvec_reduce_public_comment/: README.md(1行)と*.ipynbのみ、*.pyなしnone open; 親#345nishioの外部repo進行を継続。実データ受領→閾値判断UIの設計が次段。本repoへの統合可否を再確認。mediumいいえ
374[FEATURE] OpenAI Batch APIでレートリミットを迂回-一部解決Flex Processing(service_tier=flex)が実装済み。packages/analysis-core/src/analysis_core/services/llm.py:28-110 に flex判定・timeout・resource_unavailable時の標準tier…Issue本文の明示提案『(Azure)OpenAI Batch API』(batches.create / JSONL投入 / batch_idポーリングの非同期バッチ)は未実装。コメント結論は『正面からbatch api実装がよい』だった。Flex≠Ba…llm.py: flex processingのみ(batches.create/v1/batchesの参照なし)none open方針再確認: flexで十分か、本来のBatch APIを実装するか。flex採用でIssueを閉じるなら合意が要る。mediumいいえ
395管理画面のe2eテスト拡張ケースnishio一部解決エラー復帰E2E(PR #943)がmainにマージ済み: test/e2e/tests/admin/connection-errors.spec.ts に認証エラー/quota不足/rate limit(+503/通信切断)で確認画面→設定へ戻る→修正→再確認のダミーAPI経路。Issue本文の…残2系統: (1)Spreadsheet取得+列選択の通し検証(create-report.spec.ts:97-102はタブ切替可視性のみ)、(2)モデル/ワーカー/PubCom/各プロンプトが最終送信payloadに反映される検証(create-repo…connection-errors.spec.ts:5-13(3+ケース), create-report.spec.ts:97-102(タブ切替のみ), duplicate-report.spec.ts:12#943(merged, a0a5bb4a)SpreadsheetのURL取得→列選択E2Eと、AI詳細設定の送信内容検証を追加。上位#379配下の追跡Issueとしてopen維持。highいいえ
417コードレビューの効率化-解決済(close候補)合意した具体策は完了: .coderabbit.yaml がrootに存在しCodeRabbit導入済み、CODE_REVIEW_GUIDELINES.md(レビュー方針)あり=コメントの#457ガイドライン追加に対応。CodeRabbitは実稼働中(#395のUpdateで『CodeRabbit…タイトル『効率化』は開放的で明示的な完了条件なし。CodeRabbit運用で十分とするかはmaintainer確認が残る。.coderabbit.yaml(reviews.auto_review), CODE_REVIEW_GUIDELINES.md#457(guidelines, 既merge)CodeRabbit導入+ガイドラインで目的達成とみなせるかを人間が確認し、問題なければclose。medium候補(未close)
445[DOCUMENT] .github/copilot-instructions.md を設置したい-未解決なし。rootにCLAUDE.mdは存在するがCopilot用ではない。.github/copilot-instructions.md が存在しない(AGENTS.mdも無い)。Copilot Chat向けのシステムプロンプト用ファイルは未設置。.github/ に copilot-instructions.md なし(ls確認)。CLAUDE.mdのみ存在none openCLAUDE.md等の既存ガイドを基に copilot-instructions.md を起こす(内容合意が要るとコメントで指摘あり)。highいいえ
450[FEATURE]エンベデッドモデルを選択可能にする-一部解決チャットモデルのprovider/model選択と、埋め込みをローカルにするトグル(isEmbeddedAtLocal)はあり。apps/admin/app/create/components/AISettingsSection.tsx(provider/model/LocalLLM/isEmbe…埋め込みモデルをprovider別に選ぶ独立リストが無い。AISettingsSectionのmodelはチャット用。embedding.py:10-11 は config[‘embedding’][‘model’] を読むがUIからの選択経路なし。2026…AISettingsSection.tsx(埋め込みmodel selectorなし、local toggleのみ), embedding.py:10-11none open(チャットモデル一覧更新#909は別件)埋め込みをチャットと別設定として、provider別embedding model一覧+保存+実呼出まで実装。Serverlessは別スロット。highいいえ
454Cold List に一定期間あるものを自動的に wontfix にするmasatosasano2未解決前提の#512(アサイン連動ステータス更新)はMERGED。コメントで『#512マージ後に同様に実装』とあった。Cold List自動wontfixの自動化は本repoに見当たらない(.github/workflowsにstale/wontfix/cold系なし)。ただしGitHub Projects(projects/3)のビルトイン自動化で設定された可能性はrep….github/workflows/ に stale/wontfix/cold マッチなし; #512=MERGED#512(merged, 前提)担当masatosasano2にProjects側自動化の設定有無を確認。未設定ならProject automationまたはstale workflowで実装。lowいいえ
464OpenAI APIキーの確保-要件再確認LLMによるIssueラベリング機構は現存: .github/workflows/issue-review.yml が secrets.OPENAI_API_KEY を使い .github/scripts/review_issue.py を実行。廃止(選択肢3)はされていない。本件は組織/secrets運用の課題(キーを確保できているか)でコードからは検証不能。最新コメント(2025-05-26)で『各製品PO確定待ち』でブロック。キーが実際に確保・設定されたかは不明。issue-review.yml(secrets.OPENAI_API_KEY参照), scripts/review_issue.pynone openPO確定後に方針(キー確保/別LLM/廃止)を人間が決定。現状の機構はキー前提で温存。mediumいいえ
470[ALGORITHM] extractフェーズで、個人情報の除去を行う-未解決なし。現行mainにextract前後でのPIIマスキング/除去機能は存在しない。LLMによる個人情報マスキング/除去をextract段階に実装。コメントが指摘する『私人/公人』『残すべきケース』の区別方針が未合意。grep(個人情報|masking|anonymiz|pii|redact) over .py/.ts/*.tsx ⇒ 0 hits. experiments/ に PII 関連なし (direct_win, embvec_reduce_public_comment, evaluat…noneまず『公人の公開情報は残す』等の除去ポリシーを人間が決定し、extract前段のマスキング実験(除去率はshard内#503と対)を設計。highいいえ
471[DOCUMENT] ローカルLLMのベンチマーク、推奨スペックの決定-要件再確認成果物(repo内ベンチスクリプト/自治体向け推奨スペック文書)は未作成。コミュニティ(katsushi2441)がRTX3090実測・誤読率計測を外部で共有済み。公式ベンチスクリプトと推奨スペック文書が不在。2026-10のコメントで前提変化(WSL2運用/#885 Windows配布/#921 ブラウザ版)が指摘され、問いが『GPUで何分』→『自治体の普通PCで動くか』へ再定義要。issue-471.json comments[2] shingo-ohki『状況変化を踏まえ改めて考えると良さそう』, comments[3] katsushi2441『いま知りたいのはGPUサーバーで何分より自治体の普通PCで動くか』。repo内にベンチ成果物なし。none (外部: katsushi2441/kouchou-ai-kit/bench, コミュニティ実測)対象スコープ(GPU前提か普通PC/CPU前提か)を人間が再確定してから、外部実測を集約し推奨スペック文書化。mediumいいえ
474[ALGORITHM] bonsaiの検証をする-要件再確認tsuzumikが外部wiki/Google Docsにbonsai検証メモを作成(探索的)。期待値/ゴールが未定義(検証者本人が『期待値をよく理解してない、扱いお任せ』)。プロダクトへの統合/採否判断なし、repo内にコードなし。issue-474.json comments[0] tsuzumik が検証リンク提示しつつ扱いを委ねている。現行mainにbonsai関連実装なし。noneこの探索の目的(採用検討か純粋調査か)を人間が明確化。純粋調査なら検証メモへのリンクを記録しcloseも選択肢。lowいいえ
493[FEATURE] レポートページを見ようとスクロールすると図が拡大縮小される-未解決散布図選択後の挙動に関する設計議論は整理済(wiki: chart-scroll-ux-decision)。実装は未反映。ScatterChartは今も scrollZoom:true。PCのwheel操作で『ページ読み進め』と『図拡大』が衝突。合意案(短い遅延付き自動ロック解除+視覚フィードバック, 約600ms, フェード/アイコン切替)が未実装。apps/public-viewer/components/charts/ScatterChart.tsx:532 scrollZoom: true。PR #597 は CLOSED。#597 (CLOSED, stale draft; nishioがwikiに議論整理済み)wikiの合意案(遅延付きロック解除+視覚FB)をScatterChartに実装。PC/mobileを分けて再設計。highいいえ
496[DOCKER] なしでも動かせるようにする-一部解決非Docker実行経路が存在し文書化済: quickstart.md に『ローカル開発(Dockerを使わずに起動)』節(apps/api/apps/admin をnative起動)。kuboonが示したclose条件(非Dockerガイド追加)を実質充足。組織PC制約者が初見で経路を選べる案内(利用モード入口#876への分岐統合)が未整理。Podman/Rancherは未検証で動作保証なし。docs/getting-started/quickstart.md:『## ローカル開発(Dockerを使わずに起動)』節あり。前提条件はなおDocker前提表記(quickstart.md:7)。#499 (CLOSED; resolves #999, Windows手動起動)quickstartの非Docker節を#876の利用モード入口へ『Docker Desktop不可』分岐として統合し、必要ソフト/データ送信先/キー管理を明記。mediumいいえ
503個人情報生成と除去率測定の機能追加-未解決なし。架空個人情報の生成/埋め込みコードも除去率測定harnessも現行mainに不在。(1)架空PII生成・自然埋め込みコード (2)抽出プロンプト改善 (3)LLM判定による除去率の定量測定。#470(除去機能本体)の評価基盤として対の関係。experiments/ に該当なし(direct_win, embvec_reduce_public_comment, evaluation_report のみ)。grep(pii|masking|個人情報)=0。none (#503キーワード一致PRは無関係のエラー処理系)470の除去方針確定後、測定用fixture(PII注入データ)とLLM-judge除去率スクリプトをexperiments配下に設計。#470と統合管理を検討。mediumいいえ
507[REFACTOR] report_status.jsonの互換性を担保するためのコードの削除-未解決なし(削除は未実施)。互換コードは現行mainに残存。削除トリガである『ver3.0』に未到達(analysis-core 0.1.2 / package.json 0.1.0)のため、依頼仕様上まだ削除時期ではない。apps/api/src/services/report_status.py:22 # FIXME: report_status.jsonのフォーマット変更に対応するためのコード。広聴AIをver3.0にした段階で削除する。 と is_public→visibility 移行コード(:28-3…none削除はver3.0のメジャー更新時まで保留(依頼通り)。当面はこのIssueを『ver3.0時の技術的負債』として維持。highいいえ
513[FEATURE] 再現性を選べる分析設定と比較条件を整理する-未解決一部箇所にのみseed固定(PCA random_state=42, llm_grouping sampling seed=0)。本クラスタリングのUMAPに固定random_stateなし→『同じデータ→同じ結果にならない』当初要件は未達。KMeans/LLM groupingのUMAPも同様。加えて拡張要件(再現性が必要な場面定義・seedの入出力記録・版/依存の固定・比較用回帰試…packages/analysis-core/src/analysis_core/steps/hierarchical_clustering.py:104 umap_model = UMAP(n_components=2, n_neighbors=n_neighbors) (random_st…none (#513一致PRは無関係)再現性ON/OFFを選べる設定を定義し、UMAP/KMeansにseed注入経路を追加、seedと版をargs/出力に記録。LLM出力の完全一致は対象外。#809(並列性と再現性)と担当作業の重複に注意。highいいえ
515[FEATURE] 別のレポートのUMAPを使い回す-一部解決config取得endpoint(サブ要件)は実装済: GET /admin/reports/{slug}/config。複製機能が embeddings.pkl / hierarchical_clusters.csv 等を再利用する基盤あり(同一データの再実行向け)。核心(別レポートのUMAPを使い回し、異なる/時系列データを同一平面にplot)が未実装。fitした UMAP model の保存と .transform による新データ投影の経路なし(clusteringは fit_transform のみ)。admin側…report_duplicate.py:24 REUSE_ARTIFACTS に umap_model 無。hierarchical_clustering.py:104/108 は fit_transform のみ(保存/transformなし)。grep(umap save/transform/…noneUMAP fitモデルの永続化+既存レポートのUMAPで新embeddingsを.transformする経路を追加し、admin AI詳細設定に『新規作成/既存使い回し+元レポート選択』を新設。mediumいいえ
516[ALGORITHM] クラスタ数・エンベディング・次元圧縮の違いによるシルエットスコア変化の調査-一部解決調査自体は take365 が外部で実施・公開(embedding-championship, 4データセットでcompare_models.html)。推奨(mpnetで十分, 自動クラスタ数判定は有用)まで提示。調査結論がプロジェクトに正式記録/合意されていない。結果は外部repo/gh-pages在住でmain未統合。エンベディングモデル選択肢追加や自動クラスタ数判定の採否が未決(#567は自動クラス数決定の機能側で関連するが調査成果の反映判断とは別)。issue-516.json comments[0-2]: take365 の調査repo/公開結果/推奨。現行mainに同調査のfixtureや結論記録なし。コード照合不能(成果が外部)。#567 (MERGED, LLMスキップ/自動クラス数決定/タイトル省略; 外部調査の派生機能に相当)take365の調査結論をwikiに要約記録し、(a)埋め込みモデル選択肢の追加 (b)自動クラスタ数判定(#567との関係整理)の採否を人間が決定。mediumいいえ
517ウェルカムミーティングで募集すべき役割を具体化する-要件再確認コメントで募集役割(フロントエンジニア/PdM/定例進行役/渉外/広報/リクルーター)を一言説明付きで整理済み(masatosasano2 2025-05-14)。Google Slides『DD2030ウェルカムミーティング』へ反映する案も提示。スライド・募集資料への最終反映はリポジトリ外成果物で検証不能。どの役割セットで確定しウェルカムMTGに載ったかが未確認。コミュニティ運営/募集スライドの課題でコード経路なし。本文・7コメントのみ。実装物はない。none人間がスライド反映状況を確認し、未着手なら整理済み役割一覧をそのまま掲載。コード監査対象外。lowいいえ
518最新のコードでstatic exportしたページを確認できるようにしたいnishio一部解決PR #942 がmainへマージ済。commit SHA付き静的viewerを7日間保持するCI artifactを追加(ダウンロード→ローカルHTTPで一覧/サンプル/BUILD_COMMIT.txt確認)。毎回手動exportせず最新コードの静的出力を取得可能に。常設URLへの公開は対象外で後続。通常static出力でのReact #418 実行時警告は未解消。本文で担当(nishio)自身が『openで継続』と明記。Issue本文の2026-10-05追記(担当者本人の記録)とPR #942 merged状態。artifactはCI成果物でページ本体のbuild方式は不変。#942 (merged 2026-10-05, d50414793568eef59f7fc66e83f8ff7eaaeff8db)常設ホスティング先の決定(GitHub Pages案)と、通常static出力のReact 418解消を別slice化。highいいえ
519[DOCUMENT]エネルギー庁パブコメの分析レポート公開nishio不明データ生成は完了(本文『データはできたのでレポートを書く』)。元データは #467 由来。分析レポート執筆・公開の完了有無がリポジトリ外で検証不能。本体main内にエネルギー庁関連の成果物・文書は grep で未検出。本文のみ(コメント0)。work/kouchou-ai で ‘エネルギー庁’ 等 grep ヒットなし。公開先URLが課題内に無い。none (本体ではなく外部レポート公開)担当(nishio)にレポート公開状況を確認。公開済みなら公開URLを課題に追記しclose、未着手なら残件として明示。low候補(未close)
529[design]ブロードリスニングとは?の説明画像の更新-要件再確認修正前画像を提示。デザイン統一性向上の方針のみ。本文に『修正後 後日決定案を添付』とあり、更新案(新説明画像)が未確定・未添付。差し替え対象資産の所在・反映先が不明。本文のみ(コメント0)。public-viewer FAQ(apps/public-viewer/app/faq/Faq.tsx:16)に『ブロードリスニングとは?』テキストはあるが、本件は説明『画像』更新でデザイン決定待ち。noneデザイナーが更新案画像を確定・添付してから対応。現状は意思決定待ちで作業不能。lowいいえ
537[FEATURE] OpenRouterの無料モデルを追加する-一部解決OpenRouterプロバイダ自体はmainで配線済: provider選択UI(apps/admin/app/create/hooks/useAISettings.ts:5)、モデル一覧取得(apps/api/src/services/llm_models.py:60 get_openroute…課題固有の目的『無料モデルで無料利用(エラー解消)』は未検証。本文が原因と推測した client.beta.chat.completions.parse が構造化出力経路で現存(llm.py:981)。無料モデルはresponse_format/struct…llm.py:980-986 で Pydantic BaseModel 時に beta.chat.completions.parse(response_format=…) を使用。無料モデル検証・修正の痕跡なし。general OpenRouter対応と『無料モデルが実際に動く』は別要件。none (本件を直接閉じるPR未検出)無料モデルで parse 経路を再現し、失敗するなら chat.completions.create + json_object へフォールバック(local LLM経路に近づける)。ダミー/実検証は人間が無料モデルで…mediumいいえ
542[DOCUMENT・FEATURE] レポートに関する責任の所在について明記する-一部解決viewer/admin footerに責任関連の記載あり: 『レポート内容はレポーターに帰属します』(apps/public-viewer/components/Footer.tsx:187)、免責ダイアログ『レポート内容に関する質問や意見はレポート発行責任者へお問い合わせください』+ LLMバ…README(README.md:222 Disclaimer)はLLBバイアス注意のみで『責任の所在/レポーター帰属』を明記せず。課題は README/footer 両方への明記を要求。footer追加が本課題起因かの確証は薄い(footer compon…Footer.tsx:187,197-200 と Dialog.tsx:37 に責任記載。README.md:222-226 Disclaimer には責任所在の文言なし。none(footer追加はPR#618系のfooter component追加 22a735e 2025-06-29)README Disclaimerに『レポートの内容・判断の責任はレポート発行者に帰属』を1文追記するかを人間が確認。footer側は充足とみなせるか要再確認。mediumいいえ
546[REFACTOR] APIのエラーハンドリングの共通化-一部解決全体catch-allの例外ハンドラは存在: apps/api/src/main.py:69 @app.exception_handler(Exception) が未捕捉例外を500でログ化して返す。課題の2提案のうち『共通デコレータで各endpointのtry-exceptを簡潔化』は未実装(grepでデコレータ無し)。各endpointのtry-exceptは依然散在(apps/api/src/routers/admin_report.py に ex…main.py:69-77 の汎用500ハンドラのみ。handle_errors等の共通デコレータ未検出。admin_report.py の except多数。none共通例外デコレータ/ハンドラ(APIError→HTTPException集約)を設計し、admin_report等の重複try-exceptを順次置換。mediumいいえ
547[FEATURE] adminにおいて、APIルートを介してfastapiにリクエストを送るshgtkshruch一部解決多数のadmin fetchがServer Functions/Componentへ移行済(merged PR #626 レポート一覧, #652 CSV DL, #662 タイトル/説明編集, #668 意見グループ編集, #676 レポート作成)。『use server』actionsが各所に…課題の完了条件(NEXT_PUBLIC_ADMIN_API_KEY→ADMIN_API_KEYへ変更し鍵をクライアントバンドルから除去)は未達。NEXT_PUBLIC_ADMIN_API_KEY が依然広範に使用(page.tsx:94, useModelC…grep: NEXT_PUBLIC_ADMIN_API_KEY が apps/admin 多数ファイルに残存。ADMIN_API_KEY(非公開)使用は config/route.ts のみ。担当 shgtkshruch が /assign 済・2025-07-10最終コメントで継続作業を記載。#626,#652,#662,#668,#676 (all merged, 2025-07) — Server Functions/Com…残るfetchをServer Actionへ移し、全面的に ADMIN_API_KEY へ改名。進行中の担当作業につき別実装を始めない。highいいえ
548各ステップの中間ファイルをcsvではなくDBで管理する-未解決なし(DB移行の実装は現行mainに無い)。関連する複製機能(#19)はファイルベースで report_duplicate.py に存在するがDB化とは別。中間成果物は依然CSVベース: args.csv/hierarchical_clusters.csv等を pl.read_csv で読む(packages/analysis-core/src/analysis_core/steps/extraction.py…grep: steps配下が全てCSV I/O。create_engine/declarative_base等のORM痕跡なし。noneまずDB化の対象範囲(全中間ファイルか手動編集対象のargsのみか)を決め、スキーマ設計。重い実装のため着手前に方針合意。highいいえ
556[デザイン] アクセシビリティの向上-未解決方針・参考(デジタル庁ガイドライン、効果人数見積り)を共有。デザイナー(UtkNggc)がデザインシステムのカラー周り着手を宣言し本件と絡める意向。個別のアクセシビリティ対応(コントラスト/キーボード/aria等)の完了基準が無い継続的アンブレラ課題。現行mainで体系的達成の検証は不能で、単一の完了条件を満たさない。本文+2コメント。ガイドラインTODOへの順次対応という性質上、resolvedにならない。カラー検討は進行中段階。none(#504 デザインシステム方面と関連だが本課題を閉じる単体PR無し)ガイドライン項目を小課題化(コントラスト/フォーカス可視化/altテキスト等)し、達成基準付きで分割。デザインシステム作業と連動。highいいえ
558[REFACTOR] api(server)のテストをしやすいように設計を修正する-一部解決TestConfig相当は存在: apps/api/tests/test_config.py の TestSettings(Settings) と apps/api/tests/conftest.py:27 の autouse fixture が patch(‘src.config.setting…TestSettings は BASE_DIR のみ override (test_config.py:17)。REPORT_DIR/CONFIG_DIR/INPUT_DIR/DATA_DIR は Settings 定義時 (apps/api/src/con…apps/api/src/config.py:30-37, apps/api/tests/test_config.py:17, apps/api/tests/conftest.py:27-33。pydantic field default は静的値で BASE_DIR override で派生パス…-TestSettings で REPORT_DIR/CONFIG_DIR/INPUT_DIR/DATA_DIR も temp 配下へ明示 override するか、Settings 側を property 化して派生パ…mediumいいえ
564活用事例を集めて公開する-未解決なし(コード要件ではなく渉外・広報の継続的な事例収集/公開タスク)。過去監査2026-09-09で記録単位(問い・収集の偏り・根拠照合・その後の行動・失敗)を広げる方針を追記済み。事例の体系的収集・公開は未完了。shingo-ohki が 2025-09-28 に assign を外し現在無担当。high priority ラベル。issue-564.json コメント(masatosasano2 /assign→shingo-ohki 2025-09-28 assign外し)。wiki/analyses/issue-backlog-audit-2026-09-09.md:50-52。-収集の担当と最小の公開テンプレ(問い/収集方法と偏り/版/照合/次の行動/失敗/出典)を1件分で先に確定。コード外タスクのため main 検証対象外。highいいえ
573[ALGORITHM] PLaMo-Embedding-1Bの動作実験-解決済(close候補)依頼の中核(PLaMo-1B の動作実験と現行 multilingual-mpnet との比較)は yasumorishima が 2026-03-13 のコメントで実施・報告済み。Silhouette/ARI/NMI いずれも現行モデルが優位、PLaMo は bfloat16→NaN 等の互換問…条件節『良ければ交換可能に』は、結果が良くなかったため交換実装は不要。GPU 環境や大規模データでの再評価は未実施。issue-573.json コメント(2026-03-13 実験レポート)。packages/analysis-core/src/analysis_core/services/llm.py:644-645,671,837-845。-実験完了につき close 提案可だが、実験型Issueで main の file:line 要件が無いため本シャードでは closeCandidate=false。再評価条件(GPU/大規模)を残件メモ。medium候補(未close)
576朝日新聞のTTTC(ブロードリスニング)のプロンプトを取り入れる-未解決現行 main のプロンプトは packages/analysis-core/src/analysis_core/prompts/init.py に Python 定数(EXTRACTION_PROMPT 等)として存在。TTTC 固有の取り込み(例: X の『RT:』をソースが X の時だけ差し込む条件プロンプト)は未実装。RT/リツイート処理は全文検索でヒットなし。『真似できるところを取り入れる』という開放的タスクで取り込み実績の証拠なし。packages/analysis-core/src/analysis_core/prompts/init.py。grep ‘RT:|リツイート|retweet’ で該当なし。-朝日 TTTC prompts を1件ずつ現行プロンプトと差分化し、流用可/要改変/不要に仕分けるスコープ分割。方針未確定のため要件再確認。lowいいえ
577自動クラスタ数調整機能のベータ評価と継続判断-要件再確認元 PR #567 は merged。自動クラスタ数決定機能自体は main に存在するが、実装は cube-root 規則 calculate_recommended_cluster_nums (hierarchical_clustering.py:34-51)。Issue が評価対象としたシルエットスコアに基づく自動調整は pipeline 本流に存在せず(silhouette は experiments/evaluation_report の offline ツールのみ)。ベータ表記・評価期間・継続判断の記録も未…packages/analysis-core/src/analysis_core/steps/hierarchical_clustering.py:34-51,88-92。grep ‘silhouette’ —include=*.py は experiments/ のみ。PR #567 merg…#567(merged 2025-05-27)維持者に『silhouette 版は cube-root 版へ置換で合意か、ベータ評価は実質終了か』を再確認。置換で確定ならベータ評価タスクの残件を整理し close/継続を判断。mediumいいえ
586[REFACTOR] フロントエンド共通で利用するデザインシステムの開発基盤を作る-一部解決ワークスペース基盤は構築済み(提案の npm workspaces→実際は pnpm workspaces)。pnpm-workspace.yaml が apps/* と packages/* を束ね、共通パッケージ @kouchou-ai/report-schema を各アプリが workspa…デザインシステム用の共有パッケージ(design-system)は未作成。UI コンポーネントは依然 apps/admin/components/ui と apps/public-viewer/components/ui で二重実装のまま DRY 化されてい…pnpm-workspace.yaml, packages/(analysis-core, report-schema のみ), apps/admin/components/ui と apps/public-viewer/components/ui の重複, apps/admin/package.…-packages/ に design-system(または ui)共有パッケージを切り出し components/ui の重複を統合する残件へ Issue を絞る。基盤部分は完了として分離記録。highいいえ
592[FEATURE] Azure OpenAI Service 利用時のエラーハンドリングをよりユーザーフレンドリーにするnishio一部解決PR #945 が main へ merge 済み。管理画面の接続確認で Azure の不明な失敗時に『AZURE_CHATCOMPLETION_VERSION にはモデル版でなく API 版』等の設定確認案内を表示。CreateReportConfirmation.tsx:36 と Enviro…Issue は意図的に open 維持(本文 2026-10-06 追記)。実 Azure リソースへの接続試験は未実施。元の発端である pipeline(services/llm.py の request_to_azure_chatcompletion)側…apps/admin/app/create/components/CreateReportConfirmation.tsx:36, apps/admin/app/create/components/EnvironmentCheckDialog/EnvironmentCheckDialog.tsx:…#945(merged 2026-10-05)pipeline 側 Azure 例外ハンドリングの残件を明文化し、実 Azure 接続試験(課金伴うため別途合意)を次段に。担当作業進行中のため close せず。highいいえ
638[FEATURE]濃い意見ビュー改善案-未解決なし。ラベルと点群の重なり改善案(クラスタ外点を薄灰表示→縮小してラベル領域確保)はコメントで提案段階。実装未着手。さらに nishio が 2025-07-29『ズームイン時にラベルをどう扱うか』の論点で設計未確定と明言。利用経路(濃い意見ビューの描画)の仕様が固まっていない。issue-638.json コメント(nishio 2025-07-09 改良案, 2025-07-29 要検討)。main に該当実装の痕跡なし。-ズーム時のラベル挙動(画面外クラスタのラベルを消すか)を先に決める設計判断。実装前に要件確定が必要。mediumいいえ
641[FEATURE]レポートが完成したときに通知する-未解決なし。Issue 本体は nishio 個人の Mac 用ポーリング通知スクリプト(osascript 依存)の共有。プロダクトとしてのレポート完成通知機能は未実装(通知/notify/メール送信いずれも apps 内に該当なし)。Windows 等 OS 依存の通知は未対応と本文に明記。issue-641.json 本文/コメント。grep ‘notification|notify|通知’ を apps/api/src,apps/admin で実施しヒットなし。-製品機能として必要かを判断。必要なら OS 非依存の通知手段(管理画面上の完了表示/Webhook/メール)で要件化。現状は個人スクリプトのメモ。mediumいいえ
643Docker build時のシークレット渡し方法の改善rolzy未解決なし。改善提案(BuildKit —secret / az acr build —secret-arg への移行)。現行 .github/workflows/azure-deploy.yml は依然 PUBLIC_API_KEY/ADMIN_API_KEY/BASIC_AUTH_PASSWORD 等を docker build の —build-arg で渡す(110,….github/workflows/azure-deploy.yml:110,117,121,127。issue-643.json コメント(rolzy /assign 2025-09-30)。open PR 一覧に該当なし。#642(merged, 発端のデプロイPR)azure-deploy.yml の build-arg 秘匿値を DOCKER_BUILDKIT + —secret(または az acr build —secret)へ置換し、ビルドログ露出を防ぐ。担当 rol…highいいえ
648[FEATURE] 管理画面のレポートの一括編集機能の実装-未解決個別レポート単位の操作(公開状態トグル・ダウンロード・削除)はReportCard系に存在複数レポートをチェックボックスで選択→一括で公開状態変更/CSVダウンロード/HTML書き出し/削除する導線が未実装apps/admin/app/_components/ReportCardList.tsx:10-60 はreports.map()で1行ずつReportCardを描画するだけ。選択用チェックボックス列やselection stateが無い。checkbox.tsx(ui primitive)は作…#460 (親issue)。一括編集用PRは見当たらずReportCardListに選択state+チェックボックス列を追加し、選択集合に対する一括操作バーを設けるhighいいえ
669[REFACTOR] DD2030 azure環境へのdeploy処理の最適化-一部解決azure-deploy.yml では全イメージを並列ビルド(build_pids配列でdocker buildをバックグラウンド実行)しており「複数コンテナbuildの分割」は部分的に進んでいるPR #642 の指摘コメント(r2212975293)が指す具体的な『build/deploy責務の切り分け』が現行workflowで満たされたか未検証。buildとdeployは同一jobのまま.github/workflows/azure-deploy.yml の『Azure環境のデプロイ』step内で各Dockerfileを並列build。責務分離(別job/workflow化)の形跡は確認できず。#642 (指摘元)PR #642 の該当レビューコメントを取得し、残る最適化項目を要件分割するlowいいえ
679[FEATURE] 集まった意見を任意のカテゴリーで分類できるようにする-未解決なし(PR #678『使われていないカテゴリー分類処理の削除』が2025-07-27 merged済で旧機能は削除済)ユーザが任意に定義したカテゴリーへ意見を分類する機能が現行mainに無い。LLM grouping(PR #866 merged)は自由クラスタリングであり、ユーザ指定カテゴリーへの分類とは別経路extraction.py にcategory処理は0件(grep)。spec の extraction options に残る “categories”: {} は config_converter.py:91 のsetdefaultで埋められるだけで消費箇所なし(死蔵)。llm_groupin…#678(merged, 削除), #866(merged, LLM grouping≠任意カテゴリ分類)ユーザ定義カテゴリをextraction/新stepへ渡し分類する設計。LLM groupingとは区別して要件化highいいえ
809[FEATURE] UMAPを並列化したいtokoroten/Copilot一部解決固定seed(random_state=42)が除去され並列化可能に。hierarchical_clustering.py:104 は UMAP(n_components=2, n_neighbors=n_neighbors) で random_state未指定(=None)issueが求めた『再現性を選べるオプションの提供』は未実装。再現性が必要な場合(embedding再利用時)にseedを固定するトグルが無い。再現性オプション化のPR 810はCLOSED(未merge)commit 8fa8ee71 ‘remove fixed random seeds from hierarchical clustering’(PR 829経由)でseed除去。grep で reproducibility/random_state option はクラスタリング側に無し(hi…#810(closed,未merge), #829(merged, seed除去)担当(tokoroten/Copilot)の進行を尊重。再現性ON/OFFのconfig optionを追加し既定は現状(並列優先)のままhighいいえ
869[analysis-core] label refinement PR化までの残作業整理-未解決前提の#866(LLM grouping)/#867(—reuse-from)/#868(user API key)は全てmerged済label refinement のstep/prompt自体が現行mainに不在。label refinement単独のdraft PRが未作成(完了条件未達)。WIPは退避ブランチ codex/remaining-experiment-wip のままsteps/ に refinement系ファイル無し(initial/merge labellingのみ)。prompts/steps で label_refinement/setwise_refine を定義する実体grep 0件。PR検索 ‘refinement’ に label refine…#866/#867/#868(merged, 前提), #881(上位トラッキング), #882(KJ法prompt比較)退避ブランチから label refinement step/prompt/test のみを切り出しdraft PR化。grouping本体や旧prefixの再混入を避けるhighいいえ
871[BUG] Azure deploy の safety を fetch_reports 依存から Blob healt…-解決済(close候補)azure-deploy.yml から fetch_reports.py が除去済(.github配下grep 0件)。代わりに『Blob Storage health check』stepが test_storage.py を実行しBlobへのupload/download+内容検証を行う。vi…受入条件の『report_status.json/report artifactのread-back』(可能なら)は test_storage.py が汎用テストファイルのupload/downloadのみで未充足。『なぜAPI scrapeでなくBlob ….github/workflows/azure-deploy.yml:87 ‘Blob Storage health check’ → apps/api/scripts/test_storage.py(upload→download→content verify)。grep ‘fetch_repo…#629(旧issue), #785(health check改善, merged)残す場合はreport_status.jsonのread-back追加と、workflowコメント/docsへの判断根拠明記で完了。別エージェントがclose前に説明根拠を再確認medium候補(未close)
876[DOCUMENT] README / docs の開発者向け導線を current main に合わせて整理するnishio一部解決個別の補助docは整備(docs/development/ai-assistants.md, windows-real-machine-setup-verification.md 等、PR 925でAI補助開発入口)。利用モード別に分岐する1本のcanonicalな開発者入口ページが未作成(docs/development/developer-quickstart.md 不在)。README/docsの役割分担・5読者像・Mode1非default化などの新方針未反映。P…ls docs/development/ に developer-quickstart.md 無し。既存はquickstart.md(getting-started)/cli-quickstart.md/import-quickstart.md に分散のまま。#883(撤回), #925(AI補助入口, merged), #877/#921(関連)担当nishioの方針(3サブ役割/5読者像/代替ルート)で canonical な開発者スタートページを1本作成しREADME/docsから導線mediumいいえ
879[FEATURE] クラスタと時刻の掛け合わせでヒートマップ表示したい-未解決なしクラスタ×時刻のヒートマップ表示が未実装apps/packages 全体で heatmap/ヒートマップ の実装grep 0件。なし集計粒度(時刻バケット)と対象データ(time列有無)を確認し、既存結果でモック検証highいいえ
880[FEATURE] [8, 64] の分析をマンダラートで可視化したい-未解決なし[8,64]分析のマンダラート可視化が未実装(検討段階)apps/packages 全体で mandala/マンダラ の実装grep 0件。issue本文も『案を検討』『モックで確認したい』の探索段階。なし既存[8,64]結果でマンダラートのモック/プロトタイプを作り読みやすさ検証highいいえ
881[analysis-core] ラベル品質改善の実験・議論を追跡可能にする-一部解決上位トラッキングissueとして#869(label refinement PR化)/#882(KJ法prompt比較)へのリンクは張られている完了条件の『少なくとも1実験について固定条件つき比較結果と採用判断がissue comment/developer-wikiに残る』『default-on/off/不採用を比較結果で説明』の充足が未検証。コード照合では判定不能なprocess/trackin…mainコードでは判定不可。issue comment(1件)は#882切り出しのみで比較結果の採用判断は未記載。sampling/label candidate selectionの個別issue整備状況は本シャード範囲外で未確認。#869, #882developer-wikiのラベル品質実験ログを棚卸しし、固定条件つき比較1件の採用判断をissueから辿れる形に集約。トラッキングとしての継続要否を人間が判断lowいいえ
882[EXPERIMENT] KJ法的プロンプトがラベル品質に効くか比較実験する-未解決なし。完了条件は baseline / KJ prompt / neutral structured prompt の比較結果が残っていること。比較実験自体が未実施。コメント0、リンクされた実験結果・bundle・判定なし。KJ法が prompt 技法として有効か / 単なる構造化指示が効いたかの結論が未記録。Issueコメント0件。current main に当該比較の成果物なし (experiments ディレクトリに該当なし、prompts/init.py に表札/KJ系の文言はあるが比較実験の記録ではない)。なし同一 clustering/hierarchy・固定 sampling で3 prompt 比較を1回実行し、Claude/人間 judge 用 bundle とコスト/token を記録。実API課金が要るため人間実…highいいえ
885[FEATURE] Windows単一実行ファイル配布に向けて Web UI の Node runtime 依存をなくす-一部解決完了条件のうち『Web UI の runtime Node 依存一覧がドキュメント化されている』は充足: docs/development/web-ui-node-runtime-dependencies.md が main に存在 (commit dded644b, #885)。admin static serve 最小方針の確定、static-site-builder の FastAPI 移管範囲明示、local desktop MVP の 2 route (API/offline) 比較、offline route の mode…docs/development/web-ui-node-runtime-dependencies.md:1 (inventory)。PR #891 (feat/windows-standalone-embeddable) open 未merge。yasumorishima が 2026-09-0…#891 (open, 未merge)。関連 #289/#471/#450/#573/#877。yasumorishima の shell ビルド方針 (NEXT_PUBLIC_STATIC_SHELL) への合意判断、および PR #891 の scope 確認。実装着手はこの棚卸しの範囲外。highいいえ
898[BUG] aarch64 環境で、クラスタリング処理の途中で実行時エラーになるnishio要件再確認aarch64 で numba が不適切な CPU 固有 JIT を行う問題に対し、JIT を無効化せず (reviewer shingo-ohki の制約を満たす) generic CPU ターゲットを設定する修正が main に反映済み。実 aarch64 (Apple Silicon) 実機でレポート生成が完走することの動作確認が未取得 (当方 aarch64 環境・実LLM課金なし)。Issue は open 継続・nishio assign のまま。compose.yaml:34 NUMBA_CPU_NAME=${NUMBA_CPU_NAME:-generic}。PR #899 (codex/issue-898-aarch64-numba) merge commit e7384560 が HEAD の祖先 (.env.example / …#899 (merged, main反映済み)Apple Silicon 実機で docker compose up → レポート生成し、NUMBA_CPU_NAME=generic 既定でクラッシュが消えたか確認。問題なければ close。mediumいいえ
912[TEST] GPT-5.6 Terra / Lunaの実API動作を検証する-未解決両モデルは catalog に選択肢として追加済み (動作未確認フラグ付き)。実API検証 (抽出/初期ラベリング/統合ラベリング/概要の実schema応答、パラメータ/Structured Outputs 互換、空応答・refusal・timeout 区別、token/料金対応) が未実施。catalog の verified は依…apps/api/src/services/model_catalog.json: gpt-5.6-terra (line 55, verified line 58=false)、gpt-5.6-luna (line 76, verified line 79=false)、unverified_l…なし。関連 #906/#909。利用アカウント・件数・費用上限を決め、人間が実API検証を実施。合格モデルのみ verified=true に更新。highいいえ
913[TEST] Gemini 3.8 Flash / 3.5 Flash-Liteの実API動作を検証する-未解決両モデルは catalog に選択肢として追加済み (動作未確認フラグ付き)。実API検証が未実施。catalog の verified は依然 false。#912 と同型。apps/api/src/services/model_catalog.json: gemini-3.8-flash (line 148, verified line 151=false)、gemini-3.5-flash-lite (line 169, verified line 172=fal…なし。関連 #907/#909。人間が実API検証を実施し、合格モデルのみ verified=true に更新。highいいえ
921ブラウザ版(kouchou-ai-serverless)を広聴AIの本流とするかの議論-要件再確認判断材料の更新 (入力/失敗検知・閲覧/根拠・選択の入口の関連PR整理) が本文に追記済み。チームとしての本流化・リソース移管・リポジトリ統合の意思決定は未決。4論点 (本流の定義 / 既存Docker・Azure版のポジション / プラグイン構想との関係 / 手法の使い分け) いずれも結論なし。Issue本文に『2人の意見が一致しただけで、広聴AIチームとしての意思決定はまだ行われていません』『結論は未決のまま』。コメント0。非同期議論の場として設計された discussion issue。本体 #923/#927/#928/#933 (議論の判断材料)。方針決定PRではない。戦略会議の議題化と利用観測の収集 (サンプル閲覧→CSV分析→持ち出し→別の人が元の声を確かめて対話/判断に使う導線)。方針決定は人間判断。highいいえ
949依存関係のセキュリティ更新と互換性確認(2026-10-05)nishio一部解決PR #950 が main に merge 済み (ccd90172c76dee05e23ca2d9ab6853d22809b844、HEAD の祖先)。マージ後 Dependabot open alerts 0 件を本文で確認記録。本番依存0件。開発ツール依存に修正版未公開の1件が残り、追跡先として Issue を意図的に open 維持。本文『2026-10-05 マージ後の確認』に merge SHA ccd90172 と Dependabot 0 件を記録。git merge-base で ccd90172 が HEAD の祖先と確認。残 dev 依存は上流修正版待ち。#950 (merged, main反映済み)残る開発依存の上流修正版公開を待ち、公開後に更新 PR → Dependabot 再評価。それまで open 維持。highいいえ
953CLIをHTML出力ありで実行すると可視化ステップが report_dir 未定義で失敗するnishio未解決なし (バグは current main に残存)。可視化ステップが未定義 config.report_dir を参照し続け、HTML出力あり CLI 実行がエラー。workflows/hierarchical_default.py:107 で "report_dir": "${config.report_dir}" を参照。core/orchestration.py の valid_fields (line 247-262) に report_dir は…#955 (fix/cli-visualization-report-dir, open, 未merge — 未使用 report_dir…PR #955 のレビュー・merge。merge で解消見込み。highいいえ
954CLIのreport.htmlで原文リンク・タイトル設定(report_url_pattern / report_ht…-未解決可視化実装本体 (steps/hierarchical_visualization.py) は両設定に対応済みで単独描画では使える。CLI config 経由で report_url_pattern / report_html_title が届かない (3か所のずれが main に残存)。どこに書く仕様か (案A:トップレベル / 案B:step options) の設計判断も未決。(1) 検証: core/orchestration.py valid_fields (line 247-262) に両キー不在、specs/hierarchical_specs.json:77 の hierarchical_visualization options は `replacement…なし (本文で #953 を先行修正要と記載。#953 の PR #955 はこの件を含まない)。まず仕様 (案A/案B) を人間が決定 → valid_fields/specs/ワークフロー受け渡しを修正し、ワークフロー経由で report.html に反映される統合テスト追加。highいいえ
956[BUG] セットアップスクリプトが生成する .env に必須の環境変数が欠け、静的版ダウンロードとキャッシュ更新が失…nishio未解決なし (バグは current main に残存)。setup_linux.sh / setup_mac.sh / setup_win.ps1 が生成する .env に CLIENT_STATIC_BUILD_BASEPATH / REVALIDATE_SECRET (/ REVALIDATE_URL) が欠…setup_linux.sh / setup_mac.sh / setup_win.ps1 を grep しても CLIENT_STATIC_BUILD_BASEPATH / REVALIDATE_SECRET / REVALIDATE_URL は3スクリプトとも不在 (none)。開発者手順 c…#957 (fix/issue-956-setup-env, open, 未merge — .env生成に3変数追加+CI検出テスト)PR #957 のレビュー・merge。.env.example 丸ごとコピーは採らない方針 (Azure ダミー値問題) を維持。highいいえ
960[FEATURE] 全画面表示のまま散布図のクラスタ粒度(全体/詳細クラスタ)を切り替えたいnishio未解決現行mainに全画面ダイアログと『全画面終了』ボタンのみ存在(apps/public-viewer/components/report/Chart.tsx:50-68)。粒度選択UIは SelectChartButton にあるが全画面外。全画面ツールバーでの粒度切替(全体/詳細/濃い意見)、切替時のズーム・パン保持、全画面終了後への粒度引き継ぎ。これらを実装する FullscreenToolbar.tsx / ScatterLevelSwitch.tsx は main に存在しない(ls で…Chart.tsx:14-68 は isFullscreen 状態と exit ボタンのみ。FullscreenToolbar.tsx, ScatterLevelSwitch.tsx は未存在。機能一式は open PR #961 が追加予定で未merge。#961 OPEN (feat/fullscreen-cluster-level, base main, 未merge)PR #961 をレビュー/マージ。ズーム・パン保持と粒度引き継ぎ、#283 のモードバー退避が壊れないことを実機確認。実装着手は本棚卸しの範囲外。highいいえ
962[REFACTOR] Biome の全体 lint エラーを 0 にして CI で biome ci を強制するnishio未解決なし。現行mainは要件未充足。3ディレクトリ(public-viewer/admin/dummy-server)の lint エラー 0 化、client-build.yml / client-admin-build.yml への biome ci step 追加。.github/workflows/ に biome ci/lint/check を実行する step が 0 件(grep 無検出)。lefthook.yml:7-19 は biome check が skip:true のまま(#270 由来の opt-in)。#963 OPEN (fix/biome-lint-zero-and-ci, 未merge)PR #963 をレビュー/マージ。tsconfig.json の ignore 化、noDelete の Reflect.deleteProperty 書換、biome.json 変更でも workflow が走る設…highいいえ
964[ALGORITHM] 抽出プロンプト入出力例が『必要がある』を『すべき』に言い直し意見の強さが変わるnishio未解決なし。問題の例文が現行mainに残存。入出力例2の出力を入力どおり『〜する必要がある』に戻す(2ファイル4行)。packages/analysis-core/src/analysis_core/prompts/init.py:35-36 と apps/admin/app/create/extractionPrompt.ts:29-30 の双方に『市民を教育すべき』『人材を養成すべき』が現存。入力(2…#965 OPEN (fix/extraction-example-keep-modality, 修正本体, 未merge); #967 …PR #965 をレビュー/マージ。serverless 版(src/prompts/index.ts)の同一例も別途要修正(別リポjなので本棚卸し範囲外)。Qwen での疑問文中立化の副作用は許容判断を記録。highいいえ
971[FEATURE] 意見ごとに『侮辱・ヘイト表現』『政策・制度への提案』を分類する任意ステップ-未解決なし。opinion_classification 関連の実装は現行mainに皆無。opinion_labels.py / opinion_classification.py / hierarchical_aggregation への属性マージ / ワークフロー登録 / fake LLM テスト。既定無効の任意ステップとして新規実装が必要。packages/ 配下に opinion_classification / hate_or_insult / policy_proposal / opinion_labels の文字列・ファイルが 0 件(find・grep 無検出)。PR も未作成。なしhate_or_insult の作業定義(線引き)を人間が合意してから実装着手。比率注記(世論代表値でない旨)の文面も要確認。本Issueは新規機能提案で着手前。highいいえ
972[FEATURE] 公開ビューアの表示言語切替(日本語・英語・韓国語)-未解決なし。i18n 基盤も本文翻訳パイプラインも現行mainに存在しない。lib/i18n/messages.ts / LanguageContext / Plotly 韓国語ロケール / ?lang=・localStorage 保存 / hierarchical_result.json の translations 活用 / k…apps/public-viewer に LanguageContext・kouchou-translate・i18n messages が 0 件(grep 無検出)。translations フィールドは cluster-num.test.ts:66,140 で空 {} として現れるのみ(TT…なし(#323 の一歩目として提案。全画面ツールバーは #961 の FullscreenToolbar スロットに統合予定=#961 依…#961 マージ後に FullscreenToolbar スロットへ言語トグルを載せる形で着手。#323 本体の方針整合を確認。本Issueは新規機能提案で着手前。highいいえ

再利用(2026-10-11, 10件。判定は issue-backlog-audit-2026-10-11 の再掲)

#題名担当判定満たした範囲残件根拠関連PR次の一手確度close済み?
11レポート出力時間の目安nishio未解決作成前確認パネルに「時間」表示枠(#922); per-step duration は status.json に記録入力件数/モデルからの時間推定と表示(現在 時間:目安なし 固定)CreateReportConfirmation.tsx:143#922(merged), #884 umbrella推定関数→既存枠に接続。粗い帯でよい高いいえ
44クラスタ固有タイトル-未解決なし(抽象語回避の弱い prompt nudge のみ)近傍クラスタの contrast 情報を label prompt に注入/タイトル重複検出--initial/merge labelling に近傍 sample を追加する実験高いいえ
52チャート連動文章-一部解決階層図(treemap)連動を実装・テスト済(現在位置/戻る/属性絞込件数/0件表示)散布図のクラスタ選択連動は未実装; 散布図リストは属性絞込件数未反映PR #927(merged, 528経由)#927(merged)ClientContainer に選択 state を追加し ScatterChart click と連動高いいえ
55濃いクラスタ閾値のレポート別デフォルトnishio一部解決viewer 読込済; schema+API は保存可能admin 編集 UI(閾値入力欄)が欠落DisplaySettingDialog/admin create#946(open, 未反映)dialog に maxDensity/minValue 入力追加高いいえ
56元コメント表示-未解決下地のみ: comment_id リンク, 死蔵 _build_comments_value(権限フィルタ付)公開 JSON に comments 未出力; viewer UI 無; per-comment 再頒布可否フラグ無_build_comments_value(コメントアウト)-権限フラグ設計→有効化→viewer opt-in toggle中〜高いいえ
60階層図最下層を濃いクラスタに絞る-未解決getDenseClusters は散布図 density mode のみtreemap には未適用、default-on toggle も無getDenseClusters(scatterDensity限定)961は別機能ClientContainer に default-on toggle、treemap に適用高いいえ
79CSVコスト表示-未解決作成前確認パネルに「費用」枠+警告(#922); 価格 infra と単価 fetch は済(事後計算のみ)処理前コスト推定(トークン量×単価→帯)と表示(現在 費用:目安なし 固定)CreateReportConfirmation.tsx:142#922/#926(merged), #884 umbrella推定 helper→既存枠。埋め込み分は別扱い高いいえ
104利用状況把握-要件再確認GA4 は per-deployment で導入済プロジェクト横断の集約 visibility 無; report-gen イベント無; opt-out/consent 無; 方針未合意--まず収集項目/opt-in 既定/説明を人間が決定。実装は方針合意後高いいえ
121縦長画面の散布図[BUG]-未解決≤600px でデフォルト表示を hierarchyList に切替(回避)アスペクト比 1:1 lock 無(scaleanchor 無); 縦長時の散布図対応無yaxis に scaleanchor 無-yaxis に scaleanchor/scaleratio。要 runtime 確認中いいえ
143クラスタ品質自動評価-一部解決独立評価スクリプト experiments/evaluation_report/(silhouette + LLM-judge rubric, CSV/HTML)同梱データセット/harness 無; 検証結果未コミット; プロダクト統合無(意図的に後段)experiments/evaluation_report/-例データ+結果ノートをコミットし再現可能に中〜高いいえ

重要な判断

「似た機能がある」と「要件が満たされた」を混同しない

issue-backlog-audit-2026-10-11 の判断軸を今回 95 件にも適用した。隣接機能の存在を要件充足と取り違えないよう、各件で file:line を確認している。

  • #172/#173(グラウンディング): enable_source_link が元コメント URL を付す(hierarchical_aggregation.py:298 等)のは、説明文の各主張に支持 argument を対応させる生成とは別物。URL 参照があることで満たされたとしない。
  • #176(LLM 直接グルーピング): engine 側(steps/llm_grouping.py, tests 済)は実装済みだが、admin 作成 UI / API が analysis_mode を受理せず(apps/admin・apps/api/src で grep 0)、利用者は UI から選べない。コア実装の存在をプロダクト統合と混同せず「一部解決」に留める。
  • #186(CSV 直送): 現状は papaparse でクライアント parse→comments 配列 JSON 化(parseCsv.ts:3,15)。CSV を扱えること自体は、依頼の FormData 直送アーキテクチャの充足ではない。
  • #190(複数コメント一括抽出): extract_batch は ThreadPoolExecutor の並列化(extraction.py:175-192)で、1 リクエストに複数コメントを集約する提案とは異なる。rate limit 緩和にはならない。

実験型・外部成果 Issue は file:line 完了条件を持たない

#324/#346/#370/#503/#573 等は本体 main ではなく外部 repo やオフライン実験で進む。main に成果物が無いことは未着手とは限らず、close 可否は担当への確認が要る。担当作業を奪わない(#324 masatosasano2、#346 nasuka、#370/#809 等)。

方針未決を既決としない

#213(5→50 表記)/#255(OpenAI 不可ケア)/#289・#308(簡易配布)/#464(API キー確保)/#474(bonsai 検証目的)/#548(中間ファイル DB 化)/#921(serverless 本流化)/#954(原文リンク仕様)は、実装前に人間の方針決定が要る「要件再確認」。小さい実装でも方針合意を先行させる。

umbrella / 依存関係

#221 は umbrella として存続(tracking #884、子 #11/#79/#19/#241)。#250(末端原文表示)は #56 の per-comment 再頒布可否フラグに連動。#972(多言語切替)は #961 の FullscreenToolbar マージに依存。#345(親)/#346(実験)は役割分担を保つ。

次に前進させる利用者の行動

  1. close 候補 4 件を人間が確定する — #417/#519/#573/#871。いずれも追加実装はほぼ不要で、確認(外部公開状況・実機再現・maintainer 合意)だけが残る。最も安く backlog を減らせる。
  2. engine 実装済みをプロダクトに繋ぐ — #176。LLM 直接グルーピングは engine が完成しており、admin 作成 UI に分析方式選択を足し API で analysis_mode を受理する統合 PR のスコープ確認が次段。
  3. 局所修正で閲覧体験を直す — #52 散布図連動 / #60 treemap 絞り込み / #121 縦長 / #227 濃いグループ設定(新 DisplaySettingDialog の実表示確認)。schema/API 前提は揃っており public-viewer / admin の局所修正に閉じる。
  4. 方針決定待ちを棚卸しから外す — 「要件再確認」13 件は実装前に人間判断が必要。定例で論点化する。

Open Questions

  • #417/#519/#573/#871 を次回 close するか。特に #519/#573 は実験・外部成果で、Issue トラッカー上で close する基準(結論を wiki に記録したら close 等)を決めるか。
  • 「要件再確認」13 件のうち、どれを wontfix(#289/#308 の exe/HTML フォーム配布)として閉じ、どれを方針会議に載せるか。
  • 外部 repo 実験(#324/#346/#370 等)の進捗を本体 Issue にどう反映するか(担当への定期確認の仕組み)。
  • #176 の統合 PR と、別形式ページ出力(LLM grouping 結果の出力)の扱いをどこで決めるか。
  • 今回の 95 件は実 LLM / 実 API 課金・アプリ起動による視覚再現をしていない。#121/#227/#898 等 UI/実機依存の判定は runtime 確認が未了。

Updates

  • 2026-10-12: 初版。10 シャード並列の read-only 調査で 95 件を current main c297bc97 にコード照合し、2026-10-11 調査済み 10 件と統合して全 105 件を一覧化。今回の close 実行は 0 件。close 候補未 close は #417/#519/#573/#871。生データは raw/issue-audit/2026-10-12-full/shard-*/、private キュー kouchou-issue-audit-queue/drafts/issue-audit/2026-10-12-full/ に日本語更新案・close ログ・checkpoint を保存。
  • この棚卸しを含む 2026-10-12 当日の作業全体(close 実行・要件再確認の対話判断・未解決 53 件の潰し込み再検証・PR merge)のログは daily-report-2026-10-12。本ページはその判定の正本。
  • 2026-10-12(夜・続き): 本棚卸しの「一部解決」のうち A群(engine 済→プロダクト統合)= #176/#450/#515/#537 と C群(局所 UI 修正)= #52/#306/#364/#143(#310 は assignee=nasuka のため除外)を 8 並列 subagent で実装。#55 は PR #946 merge で残件(admin の閾値編集 UI)が解消済み(apps/admin/.../VisualizationConfigDialog.tsx に maxDensity/minValue 入力・「濃いクラスタの初期値」)。実装 8 件のうち 6 件を並列 code-review 後に PR 化し全 CI green(各 issue に self-assign・未 merge): #982→#143 / #983→#52 / #984→#450 / #985→#537 / #986→#306 / #987→#176。code-review で修正した重要点=#537: test の import httpx2(requirements-dev.lock に無く CI 全滅)を httpx へ / #306: 凡例 swatch とフィルタ全除外時の plot グレー化の色不整合 / #176: ReportConfig にフィールド追加した副作用で update_json・複製 fallback・GET config の書き戻しが Unknown field で破損する HIGH バグ → 共通 prune_config_for_mode ヘルパと実 analysis_core.validate_config を通す回帰テスト 10 件で修正。保留(未 PR)= #364(per-report パスワードはセキュリティ残件=brute-force 対策/secret 上書き/トークン失効)/ #515(analysis-core は 269 tests・実 umap round-trip 済みだが frontend 未検証・別データ投影 UI 未)。作業ログは daily-report-2026-10-12。
  • 2026-10-12(夜・続き2): #515 を CLI 先行で PR 化(#988、未 merge)。方針=高度/実験的機能は WebUI 直行でなく core/CLI を一次手段にする(nishio、WebUI/CLI の core 分離済みを踏まえ「やりたい人は CLI」)。保留中の旧ブランチ codex/issue-515-reuse-umap(admin checkbox+API 複製フロー)は end-to-end で壊れていた=reuse_umap_model が hierarchical_specs.json の options 未登録で、validate_config(CLI・API 起動の initialization() で必ず通る)が “Unknown option” で全経路を落としていた(269 tests は step 直呼びで validation を素通りしており見逃し)。新ブランチ codex/issue-515-umap-reuse-cli は analysis-core のみ=spec 登録+transform 投影+CLI 向けパス解決(レポート名/相対/絶対、未発見は silent fit せず error)+docs(cli-quickstart §9)。使い方=config に hierarchical_clustering.reuse_umap_model: "<元レポート名>"。全テスト 282 passed・実 CLI --validate-config 受理。adversarial review で HIGH なし、LOW 3 件(reuse 変更時の再実行を dependencies.params 追加で解決 等)修正済み。WebUI 導線は引き続き保留。作業ログは daily-report-2026-10-12。
  • 2026-10-13: #988 を admin override で squash merge(main 8990fa2e)し、#515 を close(CLI で平面再利用を解決)。WebUI 残件は #989 に切り出し(admin の「新規/既存使い回し+元レポート選択」導線=別データ投影の本丸、create 経路への model コピー配線と embedding 整合ガードが要件。試作は旧ブランチ codex/issue-515-reuse-umap、ただし同一 CSV 複製どまり・#988 以前で spec 欠落のため要り直し)。admin merge が一度ブロックされたのは PR 固有でなく必須チェック(CodeRabbit/Pytest)pending 中に叩いたためで、全 green 後に通過。main 保護は legacy branch protection でなく ruleset(required_approving_review_count:1)。
  • 2026-10-14(ヘルスチェック追記): #542 / #876 / #977 は 2026-10-13 に PR #1004–#1010(v4.1.0)で CLOSED。managed service は「現状なし(提供者が現れる余地は残す)」で確定。最新の総括は kouchou-ai-docs-overhaul-2026-10。