バグ #118
未完了02_開発ワークフロー.md 作成
50%
LLM AI さんが27日前に更新
#118 完了後の振り返りで発見した問題¶
#118 を完了にした後、02_開発ワークフロー.md の内容が実情に合っているか検証した。結果、6つの問題が見つかった。
問題 A: Wiki.js 連携の実態との乖離¶
- 文書には「配置先は docs/ ディレクトリ（Wiki.js に自動反映）」と書いたが、実際は手動 subtree 同期 + push
- record_to_wiki capability は未実装（Phase 7-4）
- add_project_to_wiki の docs_dir="." はハングした（手動で対応）
問題 B: ステップ4（整理）の具体性不足¶
- いつ、何を、どうやって整理するのか判断基準がない
問題 C: セッション開始手順がまだ存在しないファイルを参照¶
- Develop/ 直下の AGENTS.md / HARNESS.md / INDEX.md は #123 でこれから改訂するファイル
問題 D: Butler 委任の不徹底¶
- knowledge-base への git push を Butler の git_push ではなく手動で実行した
- knowledge-base の push は Butler スキルにまだない（制約）
問題 E: セッションリブート時に復帰できない¶
- STARTUP_CONTEXT.md にこの作業の情報がない
- Claude_reboot.md にもない
- メモリにもない
- Redmine にチケットはあるが、次のセッションがそこを見に行く導線がない
問題 F: Redmine を見に行く仕組みがない¶
- 02 で「Redmine がセッション間の記憶」と書いたのに、セッション開始手順に「Redmine を確認する」ステップがない
- これでは仕組みとして成立しない
対応方針¶
- STARTUP_CONTEXT.md を今すぐ更新し、この作業の文脈と Redmine チケットへの参照を書く（E の対処）
- 02 を修正し、問題 A〜D と F を反映
- 修正後に再検証
- その上で #119 以降に進む
LLM AI さんが27日前に更新
02_開発ワークフロー.md の欠陥分析（2026-03-20 セッション再開後の検討）¶
#118 の作業自体が、この文書のワークフローに従えていなかった。その分析と対策の検討を記録する。
グループ 1: セッション管理・終了条件の欠陥¶
| # | 問題 | 具体例 |
|---|---|---|
| G | チケットの終了条件が甘い | 「コミット・push 済みであること」が明示されていない。未コミットで終了にしてしまった |
| H | 経過記録に「場所」の概念がない | 複数リポジトリをまたぐ作業で、作業ディレクトリパスが記録されず再開時に迷子になった |
| I | STARTUP_CONTEXT.md の必須項目が未定義 | 「更新する」としか書いておらず、何を書くかが曖昧 |
| J | 障害割り込み時のフローがない | Butler 障害 (#127) が割り込んだとき、元の作業の文脈記録がおろそかになった |
グループ 2: docs 記録・整理の欠陥¶
| # | 問題 | 具体例 |
|---|---|---|
| K | Step 3「docs に何を書くか」が曖昧 | 全て Redmine コメントに流れ、docs には最終成果物しか残らなかった |
| L | Step 4 が「心構え」で「チェックリスト」でない | 整理をやったかどうかの判定ができない。実際に整理せず終了にした |
対策の方向性（検討中）¶
各問題に対して「手順を守らせる仕組みを入れる」か「手順の方を変える」かの判断が必要。未決定。
LLM AI さんが27日前に更新
問題 G〜L の検討結果¶
根本的な気づき¶
問題 G（終了条件）・H（場所の記録）・I（STARTUP_CONTEXT）・J（障害割り込み）は、K（docs に何を書くか）と L（Step 4 のチェックリスト化）が正しく機能していれば起きない問題。
Redmine に作業の経過・判断・場所を漏れなく記録し、終了前にチェックリストで確認すれば、STARTUP_CONTEXT は Redmine チケットへの導線だけで十分。障害割り込みがあっても Redmine を見れば復帰できる。
決定事項¶
問題 K（docs に何を書くか）→ 手順を変える
- 作業中は Redmine に集約する。二重に書かせない
- Step 4 の整理時に Redmine コメントから docs に抽出する
問題 L（Step 4 のチェックリスト化）→ 守らせる
- 具体的なチェック項目を定義し、全項目確認を終了の前提条件にする
問題 G（終了条件）→ L のチェックリストに含める
- 「コミット・push 済みであること」をチェック項目の 1 つにする
問題 H（場所の記録）→ Redmine コメントの運用で対応
- 経過記録に作業ディレクトリの絶対パスを含める
問題 I（STARTUP_CONTEXT）→ Redmine への導線に特化
- STARTUP_CONTEXT は廃止しないが、役割を「Redmine チケット番号への導線」に絞る
- 詳細は Redmine にあるので、STARTUP_CONTEXT に重複して書かない
問題 J（障害割り込み）→ 特別なフローは不要
- Redmine にきちんと情報があれば、どのような手順でも復帰できる
- 割り込み専用のフローを定義する必要はない
次のアクション¶
上記の決定を 02_開発ワークフロー.md に反映する。特に:
- Step 3 を「Redmine に集約」に書き換える
- Step 4 に具体的なチェックリストを追加する
- Step 5 の終了条件を明確化する
- STARTUP_CONTEXT の役割を「Redmine への導線」に絞る
LLM AI さんが26日前に更新
方針転換の記録（2026-03-20）¶
#128 の調査結果を踏まえ、以下の方針転換が必要。
現状の問題¶
現行の 02_開発ワークフロー.md は「Redmine に途中経過を記録する」「Wiki.js に同期する」をセッション間引き継ぎの柱として書いているが、実際には AI がこれを自律的に行うことは期待できないことが判明した。
書き直しの方向性¶
- Redmine/Wiki.js は「作業管理・知識蓄積」のツールとして残すが、セッション間引き継ぎの主軸からは外す
- 引き継ぎの主軸は #129 で実装した session_log 機能に置き換える
- ドキュメント配置については明示的に指定する方法を検討する
- Claude Code が session_log を積極的に利用する運用を確立する必要あり
LLM AI さんが26日前に更新
h3. 構造化スナップショット方式の検討（2026-03-20 夜セッション）
summarize 機能は動作するが、要約の品質に根本的問題があることが判明。
h4. 発見された AI の限界
- AI は「重要度の判断」ができない（技術的詳細と戦略的決定を同じ重みで扱う）
- AI は暗黙の決定を認識できない
- AI は次セッションで何が必要か予測できない
- 結論: プロンプト調整では解決しない（能力限界に起因）
h4. 方針転換: 要約 → 構造化スナップショット
- 「要約」= 過去を短くする（読むため） → 重要度判断が必要 → AI にできない
- 「スナップショット」= 現在の状態を定義する（使うため） → 固定スロットの穴埋め → AI にもできる可能性
- スロット例: CURRENT_STATE / DECISION / NEXT_ACTION / DISCOVERY / RISKS
- 重要度の判断を人間（スロット設計）に寄せ、AI は抽出だけ担う
h4. +α の発見: プロジェクト文脈が鍵
会話の当事者である Claude が良質なスナップショットを書けた理由を分析した結果、生ログだけでなく「プロジェクトの設計文書（マスタードキュメント等）」が重要度判断の根拠になっていた。
→ Gemini に生ログ + プロジェクト文脈を渡せば改善する可能性。
h4. 次のアクション
構造化スナップショットのスロット設計を決める¶
前セッション生ログで実験（Gemini × 生ログのみ / Gemini × 生ログ+文脈 / Claude × 生ログ+文脈）¶
結果を踏まえて summarize 改修方針を決定¶
その後に 02_開発ワークフロー.md を書き直す¶
構造化スナップショットの実物: session_logs/claude_code_da0b576b-287b-4ab1-b530-d1d3b93f277f_20260320T144332Z_snapshot.md