kioku

外観

kioku ロードマップ / レビュー反映 ​

Claude Fable によるコードレビュー（2026-07-03）を「即対応 / 保留 / 機能アイデア」に整理したもの。 保留・アイデアは後で一緒に優先度を決める。

✅ 即対応済（2026-07-03、このコミット群） ​

#指摘対応
品質2complete_task が完全一致で、1字違うと完了扱いにならない正規化（空白除去＋小文字化）＋部分一致に。完了時は meta.json の正式文言に寄せて記録（mcp.ts taskMatch）
品質3追記.jsonl の read-modify-write が同時書き込みで片方消える1追記=1ファイル（追記_<ms>_<rand>.json）に変更。読取り側で結合、ロック不要（mcp.ts）
品質6検索スニペットが要約冒頭300字＝定型ヘッダで情報量が低い「## 概要」節を優先抽出（parse.ts snippetOf、search.ts）
品質5テストゼロparse.ts に純粋関数を切出し＋vitest 10件（parseName/extractJson/snippetOf/py-ts定数同期）
品質4legacy が現役ファイルと混在（process_inbox.sh は死んだパス参照）tools/legacy/ へ退避（削除せず・README付き）
🔴3(推定)文字起こし全文を保存しておらず一次情報が消える音声/テキスト由来は transcript.txt を会議フォルダに保存（index.ts）。※将来の全文二層検索の土台

🟡 保留（設計判断が要る・後で一緒に） ​

  • 固有名詞辞書の Drive 外出し（品質1）: 今は index.ts にハードコード。drive 直下に 辞書.md を置き処理時に読めば、田村さん・笠松さんも編集できデプロイ不要に。要判断: 形式（md表？key:value？）／ホットリロード頻度／ハードコードとの merge か置換か。※m1_pipeline.py の重複辞書は legacy 退避で解消済。
  • タスクに安定 ID（品質2の理想形）: meta.json 生成時にタスクへ連番 ID を振れば、完了突合が文言依存でなくなる。summarize の出力スキーマ変更＋complete_task/list_tasks 改修が要る。今回の正規化＋部分一致で当面の実用性は確保したので、恒久対策として保留。
  • 全文（transcript）の二層検索（機能 A1）: transcript.txt は保存開始したので、これをチャンク embed すれば「要約レベル＋発言レベル」の2層検索に。「田村さんが正確には何と言った？」が引ける。埋め込みコスト・Vectorize名前空間設計が要検討。

🔴 重大バグ（受領・2026-07-03 対応済 / 一部保留） ​

Fable の 🔴1〜4 を受領し即対応（commit a658479）。

#指摘対応
🔴1投入口名が Worker と upload で不一致→パイプライン分断急性は当日修正済＋Drive実4フォルダ rename 済＋sync test。恒久対策として投入口を prefix 一致で探す（findChildByPrefix／kioku_upload.py も）＝完全一致依存を解消
🔴2PDF拡張子が落ちず種別が「資料.pdf」当日 parseName に PDF strip 追加済＋テスト
🔴3失敗ファイルが3分ごと無限リトライ＝課金ランナウェイ.retryN で試行回数を管理し3回で 失敗フォルダへ隔離（retryCount/bumpRetry/MAX_RETRIES）。transcript.txt も保存済
🔴4uploadText が常に新規作成→同名重複upsert 化（findFile→上書き or 作成）。リトライ時の _要約.md/meta.json 重複を解消

🔴由来の保留（後で一緒に）:

  • summarize を structured outputs（json_schema）＋ stop_reason チェックに: 正規表現での JSON 抽出（extractJson）を廃し、パース失敗という"毎回再現する失敗"の芽を断つ（🔴3 の根治）。ツール強制 or 新フォーマットの実装判断が要る。
  • モデル更新（claude-sonnet-5 等）: Fable 曰く 8/31 まで $2/$10 の導入価格で sonnet-4-6（$3/$15）より安く賢い。ただしモデルIDの実在をこちらで未確認→採用前に要検証（現行は claude-sonnet-4-6 のまま）。
  • 同日・同種別が2本（臨時が2回 等）: フォルダキー 日付_種別 が衝突し upsert だと後勝ち上書き。恒久対策は連番/時刻サフィックスでキー一意化（データモデル変更）。
  • SA鍵を端末から外す（見えた断片）: 鍵が益子端末（kioku_upload.py）にある。Worker にアップロード端点を作れば端末から鍵を外せる（商品化で必須）。アーキ変更なので D12 マルチテナント化と合わせて検討。

🔴 データ整合性（md↔Vectorize 同期の穴・2026-07-07 受領 / 未対応） ​

症状（実際に発生）: 20260707_開発定例 が search_meetings には出るのに read_meeting/list_meetings に無い＝幽霊ベクトル（Drive の md フォルダだけ消え、Vectorize のベクトルが残存）。

根因: md（ソース）↔ Vectorize（索引）の同期が upsert 一方向のみで、削除・GC・照合削除のパスが worker/src 全体に存在しない（Vectorize 操作は search.ts:20／68 の .upsert() 2箇所だけ、deleteByIds は0件）。よって海馬パイプライン以外で 会議の要約/ を直接いじると両層が乖離する。/reindex は md→upsert のみで prune 無し（index.ts:249-259）＝消えた分を拾い直せない。

Drive直操作結果自動回復
フォルダ削除search に出るが read で404（幽霊）❌ reindex不可。deleteByIds か 同ID再upsert のみ
リネーム（ID変更）旧ID幽霊＋新ID未索引（二重）❌
フォルダ移動（益子→共有 等）旧 folder::id のまま可視スコープ固定❌
md本文を手で編集検索が旧内容・旧スニペット✅ /reindex
手でmd新規作成readできるがsearch不可（逆幽霊）✅ /reindex

同根の穴（正規経路でも起きる）: indexTranscript（search.ts:59-70）は ::0..M-1 を upsert するだけ。再処理で transcript が短くなると ::M..N-1 が幽霊化。上の「同日・同種別が2本（後勝ち上書き）」とも同根＝ライフサイクル（削除）管理の欠如。

対応案（設計判断が要る・後で一緒に）:

  • A（推奨）カスケード削除エンドポイント /delete?key=&folder=&id=（既存 /reindex 等と同じ REINDEX_KEY ガード形）: ①Drive の会議フォルダを trash ②kioku-meetings の folder::id を deleteByIds ③kioku-transcripts の folder::id::0..n を一括削除、をまとめて実行。運用を「Drive の 会議の要約/ を手で消さない・消すなら /delete」に。Vectorize の全id列挙が無い問題を回避できる。
    • 前提: transcript チャンク数を削除時に知る必要 → indexMeeting/indexTranscript 時に chunk 数を meta.json に記録しておく（列挙APIが無いため）。
  • B /reindex を真の照合に: upsert 済み id を KV 台帳に記録し「Drive に無い id」を prune。台帳の保守が要る。

受け入れ条件: 会議1件を削除操作すると search_meetings／read_meeting 双方から消え、transcript チャンクも残らない。 別途・即時（このチケットとは別）: 現存の 20260707 幽霊は「本物の7/7を 20260707_開発定例 の名で海馬へ再投入＝同ID upsert」で解消する。

🧭 機能アイデア（会議に縛らない・後で優先度付け） ​

「組織の記憶を 投入→整理→AIから引ける パイプ」として、入口/出口/深さ/商品化の4方向。

A. 記憶を深める: (1) transcript 二層検索 / (2) タスクの寿命追跡（持ち越し・停滞の可視化、安定ID前提） / (3) 発言者推定（役割辞書で Claude に推定させ要約に話者を残す）。

B. 入口を広げる: (4) Claude Code セッション要約の投入（"どうやって"の記憶） / (5) メール・Slack スレッド（Watchtower 連携） / (6) 音声メモ・独りブレスト / (7) 契約書・提案書（PDF対応済、種別辞書に足すだけ）。

C. 出口を広げる: (8) 週次ダイジェスト（cron 既存・全会議横断で決定/新タスク/持ち越し/期限接近を1枚→共有＋通知。低コスト高価値、有力候補） / (9) 会議前ブリーフ（Calendar 連携で前回経緯・未完タスクを開始前に） / (10) チケット自動起票（assignee=自分のタスクを .workaholic/tickets/ 草案に。D9的に自分repoのみ安全） / (11) Slack bot（非エンジニア・商品化デモ）。

D. 商品化（オンプレ機密会議ツール）: (12) マルチテナント下ごしらえ（EMAIL_TO_FOLDER/PERSON_FOLDERS を Drive 上 config に外出し→顧客テナント分離の原型） / (13) 機密マスキング層（顧客名・金額を検知しマスク版要約を並行生成） / (14) 会議の健康診断（会議時間・決定数・タスク消化率のメトリクス）。

レビュアーの優先度私見: 🔴修正 → その流れで transcript 保存が入り A1 が半完成 → 次に 8（週次ダイジェスト）と 10（チケット起票）。既存部品（cron・meta.json・workaholic）の組合せだけで作れ、「検索する道具」→「毎週勝手に働く道具」への転換点。