AI Dialogue Log-Driven Task Management — Full Workflow from Idea to Completion
Part three of the author's personal development series: documenting how to transform AI dialogue logs directly into a trackable task management system.
Core concept: AI conversations generate numerous ideas and task threads — how to automatically consolidate "scattered insights" into a structured task pipeline? Covers the complete architecture from log summarization to task extraction, prioritization, and completion tracking. Claude Code assisted in drafting this article.
第一幕：ワークフローとタスク管理 — 対話ログからタスク完了まで一気通貫で回す
第一幕：ワークフローとタスク管理 — 対話ログからタスク完了まで一気通貫で回す
AI対話ログと開発記録をもとに Claude Code が下書きを作成し、私が加筆修正しました。
本記事は個人開発プロジェクトにおけるタスク管理の設計記録であり、一般最適を主張するものではありません。
前回の連載（第二部・第六幕）では、ローカルSLMパイプラインの部品を再利用して、意味的な重複除去を実現しました。
パイプラインの「部品」が安定すると、新しい問題に対して組み替えるだけで対応できる。
今回から第三部です。対話ログの要約パイプラインは動いている。ではその先は？ — 要約から生まれたアイディアを、どうやって「やるべきこと」に変えて、完了まで追跡するのか。16リポジトリに散らばるタスクを、どう一気通貫で管理しているのかを紹介します。
16リポジトリを横断するプロジェクトで、対話ログ → サマリ → アイディア → タスク → 実装 → 集約の循環を作った。
ハブとなる1つのリポジトリにタスクを集約し、プロジェクト全体で一意な ID を振ることで、「どこに何があるか」を追跡可能にしている。
この仕組み自体が、AI との対話から生まれた。
devour プロジェクト全体のタスク循環フローの紹介
ハブリポジトリ（devour-ideas-internal）の設計思想
dvr-ID タスク管理体系の設計と実データ
GitHub Issues や Jira との比較・推奨
各リポジトリの実装詳細（第二幕以降で扱う）
devour プロジェクトは、1人で16のリポジトリを運用している。
インフラ・自動化（ops-base, ops-claude-code）
対話ログ管理（ai-dialog, ai-dialog-summary）
その他（assets, templates, browser-tools...）
リポジトリが3つくらいなら、頭の中で管理できる。5つを超えると怪しくなる。16になると、「どのリポジトリで何をやる予定だったか」が分からなくなる。
AI と議論して「これやろう」と決めた。覚えているつもりだった。
あるリポジトリの issues.md に課題を書いた。別のリポジトリを触っているうちに忘れた。
アイディアを docs/ideas/ に書いた。でも、それをいつ誰がタスクにするのかは、どこにも書いていなかった。
でも「今やるべきこと」は、どこにもなかった。
情報は記録されているが、追跡されていない。 これが16リポジトリ運用の本質的な課題だった。
AI は発散を加速させる。対話するたびにアイディアが生まれ、やりたいことが増える。だからこそ、収束させる構造が必要になる。第三部はその構造の話だ。
この課題に対して、以下の循環フローを設計した。
対話ログの自動記録 → SLM パイプラインでサマリ生成
devour-ideas-internal にアイディアを記録
アイディアを昇格判定（ideas/ → design/）
dvr-ID を採番、対象リポジトリにタスクを展開
docs/tasks/ の該当タスクを完了に更新
devour-ideas-internal に完了を集約
└──→ Phase 1 へ（次のサイクルへ）
ポイントは、devour-ideas-internal がすべてのフェーズに関わること。
Phase 1-2: アイディアの蓄積場所
つまり、ideas-internal は起点であり終点。ハブリポジトリとして全体を把握する役割を持つ。
ai-dialog / ai-dialog-summary
docs/ideas/NN-YYYYMMDD.topic.md
ideas-internal → 各リポジトリ
dvr-ID — プロジェクト横断のタスク管理体系
GitHub Issues を使えばいい、という意見は当然ある。だが、devour には GitHub にないリポジトリもある（internal-first アーキテクチャで、ローカル Git サーバーが権威あるソース）。また、「リポジトリ A のアイディアが、リポジトリ B のタスクになる」という横断的な関係を追跡したい。
GitHub Issues はリポジトリ単位。必要なのはプロジェクト単位のIDだった。
dvr- — 固定プレフィクス（devour プロジェクト共通）
{category} — タスクの性質を示すカテゴリ
{NNN} — プロジェクト全体の連番（リポジトリを跨いでユニーク）
dvr-poc-014 マルチモーダル画像生成
dvr-feat-006 game_config.json 実装
dvr-fix-011 system プロンプト活用
dvr-docs-004 関連性マッピング
dvr-idea-018 コアメカニクス定義
カテゴリを分けたのは、「今プロジェクトがどこに力を使っているか」を把握するため。全部 feat なら攻めている。全部 fix なら守りに追われている。idea が増えてきたら発散期、ops が増えてきたら安定期。タスクの傾向がプロジェクトの健康状態を映す。
dvr-poc-001 の次が dvr-feat-002 になる。カテゴリごとに別系列にしなかったのは、シンプルさを優先したため。「次は何番？」と聞けば一つの数字が返る。
連番は ideas-internal の docs/tasks/README.md で一元管理する。
├── README.md ← index（タスク一覧・ステータス）
├── dvr-feat-006.md ← 個別タスクの詳細
└── done/ ← 完了済み
├── README.md ← 全体 index（全リポジトリを横断一覧）
各リポジトリは自分のタスクだけ管理する。ideas-internal がプロジェクト全体を横断的に一覧化する。
この構造を設計した直後に、実際にタスクを掘り起こしてみた。ソースは2つ：蓄積されたアイディア62件（docs/ideas/）と、16リポジトリの未解決課題（docs/issues.md）。