目指す変化
初めての利用者が環境構築で脱落せず、制約に合う版を選び、意見の多様性を理解し、元の声を確認して次の対話・判断へ渡せるようにする。成果指標はIssue消化数や機能数ではなく、この一連の行動が成立することとする。
serverless-relationship-2026-09-08より、dd2030の価値は単一コードベースの維持だけでなく、実践からの学びと参加の蓄積にある。以下はCodexが今回の開発に使う作業方針であり、チームの正式な製品方針決定ではない。#921は未決のまま保持する。
役割を配布・分析・データに分ける
| 利用者の必要 | 第一候補・検証先 | 条件・未検証事項 |
|---|---|---|
| まず既存の結果を読んで、クラスタを動かして理解したい | ブラウザ版のサンプル・インポート・再クラスタリング | 再ラベリングやベクトル再生成には追加処理が必要 |
| 個人がCSVから分析し結果ファイルを持ち出したい | ブラウザ版 | 利用モデルへの送信、キー管理、端末資源、保存先を説明する |
| 共通のキーを利用者に渡さず、継続して組織で管理したい | 既存版のサーバ構成を検討 | 認証・運用体制は別途設計。ブラウザ版のAzure接続対応はサーバ管理の代替ではない |
| 分析手法を交換し、反復・比較・自動実行したい | analysis-core / CLI / プラグイン | Web UI全体の維持と分析エンジンへの投資を区別する |
| 外部に意見を送信できない | 各版のローカルモデル経路を条件確認 | serverlessであるだけではデータ非送信にならない。LGWAN対応や完全オフライン動作を一律保証しない |
| 大量データを処理したい | 同一データで端末・サーバ双方を測定して選ぶ | 件数だけの足切りを未測定で決めない。文字量・埋め込み次元・メモリも記録する |
配布方式（ブラウザ/サーバ/CLI）と分析方式（embedding/LLM直接グルーピング）は独立に考える。ブラウザ版は独自の対話的分析も持ち、単なる機能削減版ではない。既存Pythonプラグインをそのままブラウザへ移すことはできない。
本流という語を三つの判断に分ける
- 入口: 初回利用はブラウザ版を第一に案内する案が有力。公開導線の正式変更は#921の判断と、初見利用の観測を根拠にする。
- 開発の重点: 当面、両版で繰り返し必要になる入力・失敗検知・元意見への参照・持ち出しを重視する。既存版への新しい便利機能は、ブラウザ版に既にあるか、固有の運用要件かを先に確認する。
- 所有・repo統合: 移管、保守責任、名称、公開先の判断を別にする。今の実装を進めるための前提にしない。
進行中の#918/#919/#920/#922は既存版向けの改善である。特に作成前確認はブラウザ版にも既存機能がある。今後の機能投資をどちらへ向けるかと、既存利用者の失敗・誤表示を直す保守は分けて扱う。
最初に共有するのは結果の契約
「同じJSON名」「同じ型名」は互換性を保証しない。serverless-relationship-2026-09-08で、現行版の生成物は元コメント参照を含まず、ブラウザ版は含むことを確認した。
- 表示: 意見、階層、座標、ラベルを読めるか。
- 根拠確認: 元コメントが含まれる時、意見IDから正しい原文・属性へ戻れるか。原文を含まない場合は、その不在を保持する。
- 再分析: 元データ、意見との多対多対応、埋め込み、プロンプトがどこまで残るか。表示用JSONだけで完全再実行できるとは約束しない。
- 公開: 原文入りファイルと公開用ファイルは同一視しない。互換化を理由に、既存版の公開JSONへ原文を自動追加しない。
共有候補はこの契約、合成データのfixture、失敗ケース、評価手順。Python/TypeScriptの実行コードを急いで一本化するより、実装が交換されても守る振る舞いを先に固定する。
開発順序と観測する結果
- 今回: ブラウザ版のID変換による元コメント参照破損を修正。先頭ゼロ・整数精度外・文字列IDについて、CSV正規化→集約→JSON保存/読込→再分析用復元で原文・属性対応が保たれる回帰テストを置く。
- 次の候補: ブラウザ版の抽出部分失敗を正常な0件と分ける。既存版#910の判断を参照し、失敗した入力が黙って欠落しないことを確認する。単純なコードコピーにはしない。
- 相互運用の評価: 現行版の実生成物を用い、表示・原文なし・再分析条件を別々に検証する。欠けたcomment_idを
undefinedというIDとして復元しない。公開用と再分析用の契約案に反映する。 - 初見利用の評価: 同意を得た利用者にサンプル閲覧→CSV投入→結果保存→他者の端末で閲覧を試してもらう。止まった箇所、介助の有無、初回成功、原文確認の可否を記録する。観測前に「ブラウザ版なら誰でも成功」と決めない。
これにより#921の次の判断材料は、抽象的な好みでなく「入口としてどこまで自力で使えるか」「どの制約で既存版へ案内するか」「持ち出して何が残るか」になる。
Open Questions
- 入口変更・保守責任・repo移管のチーム判断。今回の修正PRは#921を閉じない。
- 両版の公開ファイルと再分析データの区別、対応のない元コメント・多対多関係の表現。
- 初見利用の観測協力者と継続的なフィードバックの受け口。人への依頼は今回送っていない。
Updates
-
2026-09-08: 明示goalを設定し、役割整理と最初の参照保持修正に着手。
-
2026-09-08 17:24: [serverless PR #22](https://github.com/tokoroten/kouchou-ai-serverless/pull/22)を作成（`codex/preserve-comment-references`,
844f275、未merge）。元IDが変わらない安全な整数だけ数値で出力する。回帰テストは修正前に失敗し、修正後は全198テスト・全93ファイルのlint・TypeScript検査・本番ビルド成功。GitHub上のcheckは作成後の観測時点で未登録。保存済みの破損データは自動復旧しない。
2026-09-08 17:45: 今後の開発で再利用する判断（file back）
今回の会話と serverless-relationship-2026-09-08 の調査から、次の三点を残す。
- 利用者の行動から着手先を選ぶ。 Issueを選ぶ前に、誰のどの行動を成立させる変更か、ブラウザ版・既存Web UI・analysis-coreのどこがその入口かを確認する。別実装に既にある機能と、既存利用者のために必要な保守を区別する。「本流」は入口・開発重点・所有を分けて判断する。
- 互換性は実データが通る経路で検証する。 型定義やファイル名の一致だけでは足りない。生成→保存→読込→原文・属性への参照→再分析用復元まで、保持すべき意味を確かめる。今回のID破損はこの経路で再現できた。表示用データに原文がない場合、その不在を勝手に補完せず、公開範囲を維持する。
- 短期goalの完了と上位目的の達成を混同しない。 今回完了したのは役割整理・回帰テスト付き修正PR・Wikiへの記録まで。「初見利用者が自力で使える」「本流化が決まった」「完全な相互互換性がある」は未達・未検証。次のgoalは抽出部分失敗や原文なしJSONの扱いなど、上位目的へ近づく検証可能な範囲として設定する。
前回のPR状態・テスト結果は17:24の観測記録を参照する。このfile backではGitHubや実モデルを再観測していない。
2026-09-08 17:53: 次goalを不具合から選ぶ提案の見直し
ユーザーから「そうか？広い視野で考えて」と指摘された。直前の「次はserverlessの抽出部分失敗を修正する」という回答は、実装可能な課題を選んだだけで、今それが最大の障害かを確認していなかった。上記「次の候補」は保守候補として残すが、戦略上の次goalとして確定したものではない。
追加でdd2030-wikiの wiki/entities/coreloop.md、wiki/topics/local-government-broad-listening.md と meeting-municipality-user-research-scope-2026-06-30 を読解した。既存Wikiの観測時点に基づく目的・論点の参照であり、今回の議事録再取得や現場調査ではない。声の可視化後に対話・判断・応答へ接続すること、既存利用者に合う課題だけを探す偏りに注意することが、上位の判断軸となる。
次goal案は「一つの具体的な利用場面で、声の収集から分析・議論・応答までをたどり、dd2030が共同で改善する価値の大きい障害を特定し、その一箇所を改善・検証する」。既存事例で担当者・入力・判断・成果物・障害を整理し、不明な箇所は不明のまま残す。既存版・ブラウザ版・単純なLLM利用等をその仕事への適合で比較する。再現実験は技術的成立の検証であり、現場価値が実証されたとは扱わない。
serverlessを主役にすることも、既存版を組織運用向けに維持することも、結果の相互交換を最優先にすることも、利用場面で検証する仮説である。DD2030の共通資産はコードだけでなく、使い方・失敗例・比較材料・再利用できる実践手順となり得る。バグ修正の優先度は、この目的との因果関係を確認して決める。
2026-09-09 01:44: 実装と棚卸しから次の利用観測へつなぐ
other-issue-candidates-2026-09-07 / issue-backlog-audit-2026-09-09より、両版で同じCSVの失敗・復帰、階層図の件数・移動、合成データの状態別表示を確かめるところまで進めた。この経験から、共通資産として残す単位を「入力例、期待する挙動、失敗後の復帰、版ごとの差」とする。個々の実装・merge・CI状態は各記録の観測時点を参照する。
次の候補は、入口選択（#876 / #877 / #496）→分析前の費用・時間判断（#79 / #11）→元の声の照合と次の行動（#56 / #250 / #564 / #130）という利用の流れで評価する。見積もりの不明値を0円や確定時間にせず、原文を含まない公開データの境界を保つ。これらは開発候補と確認条件であり、今回のテストだけで初見利用や現場での成果を実証したとは扱わない。#921の入口・重点投資・所有の判断も未決として維持する。
Updates — 2026-10-05 live state再確認
catchup-2026-10-05より、Serverless #22〜#26は9月9日にMERGEDとなり、origin/main f4bb032の履歴にも存在する。上の未merge・Actions承認待ちは当時の記録で、現在は解消済み。元コメントID保持・CSV検証・読み方・ツリーマップ連動・抽出診断等を今後のbaselineに含める。#921はopen・コメントなしであり、本流化・所有/移管が決まったという意味ではない。依存更新#29 / #30 / #31 / 33のbuild失敗は別の保守課題。現在地は current-status-2026-10-05 を参照。