コンテキスト駆動PJ（Context-Driven Project）初期構想
これから自分のPJで実施しようとしている構想を書く。
初期構想なのでこれを叩き台にして活動していく。
何をどう使うか？どう実現するのか？はメンバーに以下を共有して進めていきたい。
背景
仕様駆動開発（Specification-Driven Development, SDD）を進める前に、PJのあらゆる意思決定や議論の経緯を永続化された事実として残す仕組みが必要だと感じている。
メール・Teams・Backlog・Gitなどに分散した情報をLLMが参照可能なプロジェクトコンテキストとしてMarkdown形式でNASに貯める。
この構想を「コンテキスト駆動PJ（Context-Driven Project）」と呼ぶことにする。
目的
- PJメンバーの記憶や属人的な情報共有に依存せず、すべての事実を後から参照可能にする。
- LLMを通してPM・Devsが過去の決定や背景を即座に再利用できる。
- 仕様の確認、コードレビュー、ドキュメント更新を“コンテキストに基づいて”半自動で行えるようにする。
アーキテクチャ概要
[Teams / Backlog / Mail / Git / Meeting]
↓
（変換 + メタ付与）
↓
NAS上のContext Store（Markdown）
↓
LLMによる参照・検索
↓
仕様策定 / 自動QA / レビュー支援
コンテキストストア設計
/context-store
├── 2025-10/
│ ├── 2025-10-22_meeting_architecture.md
│ ├── 2025-10-23_email_customer_feedback.md
│ └── 2025-10-23_backlog_task_sync.md
├── decisions/
│ ├── db_schema_design_decisions.md
│ └── api_auth_policy_changes.md
├── specs/
│ └── draft_v1_api_spec_from_context.md
└── meta/
└── index.yaml
コンテキスト管理フォーマット例
# Context: 2025-10-22 Architecture Meeting
## Source
Teams Meeting – Project Alpha
## Participants
- PM: Yamada
- Devs: Tonegawa, Sato
## Decisions
- Move Lambda functions into VPC for DB access.
- Keep NAT Gateway shared for staging.
## Background
Lambda inside private subnet required for security; RDS is private-only.
## Action Items
- [x] Tonegawa: confirm ENI attachment settings.
- [ ] Sato: benchmark VPC latency.
## Tags
#network #lambda #rds #vpc
マインドセット転換の必要性
この仕組みを機能させるには、PJメンバー全員が**「記録を後で使う前提で書く」**マインドセットに変わる必要がある。
単なる議事録ではなく、未来のPM・Dev・LLMが再利用できる「事実の最小単位（原子ノート）」として書く。
原子ノートの特徴
- 決定・根拠・影響を1トピック1ファイルでまとめる
-
type、tags、owner、dateをfront-matterで管理 - LLMが参照しやすい階層構造（H1=トピック, H2=根拠, H2=関連）
コンテキスト肥大化と精度低下の懸念
すべてのログをLLMに渡すと精度が落ちる。
そのため、PMやDevsなど、ロールに応じて必要なコンテキストだけを抽出する仕組みが不可欠。
このかくロールに応じて作り出された個別のコンテキストをContextPackと呼ぶ。
これはKiroのSteeringに近いものと思っている。
ただしより広範でロングスパンのプロジェクトコンテキストを含む。
抽出の考え方
- タグ・期間・重要度・ファイル種別でフィルタリング
- BM25＋埋め込みベースのハイブリッド検索やナレッジグラフを組み合わせる
- トークン予算内で要約・統合
- 「決定40%」「根拠30%」「最近の変更20%」「リンク10%」など配分ルールを設ける
ナレッジグラフを含むContext Packの作り方
目的
Context Packは単なる検索結果ではなく、意味的に関連する情報の構造化ビューであるべき。
BM25+で抽出したMarkdownノートに加え、ナレッジグラフを用いて関連情報を意味的に拡張する。
構造例
## Context Pack: RDS Proxy 設計変更
### Core Documents
- ADR-0008: RDS Proxy導入の背景と決定
- Meeting Note: 2025-09-12 Database Architecture Meeting
- Spec Change: api/db_proxy_v2.yaml
### Related Concepts (from Knowledge Graph)
- **RDS Proxy** → 関連: Lambda, ENI, ConnectionPool
- **Security Group Policy** → 関連: VPC Isolation, NAT Latency
- **Performance Issue** → 関連: ConnectionReuse, Failover
### Context Summary
RDS Proxy導入によりLambdaからRDS接続の再利用性が向上。
ただしENI増加に伴いCold Startが発生。対策としてstg環境では共有NATを継続。
効果
- 語彙的な検索精度（BM25+）と意味的つながり（ナレッジグラフ）の両立
- LLMが「関連する背景」まで含めて思考できるため、仕様策定・レビュー時の文脈再現性が高まる
GitのPushをコンテキストにする
背景
GitのPushは、PJにおける事実の発生イベントであり、会議や議事録と同等の文脈を持つ。
「何が、いつ、誰によって、なぜ変更されたか」は、そのまま仕様変更の背景情報になる。
コンテキスト化の例
# Context: Git Merge - main (2025-10-24)
## Source
Repository: harmony-tune-backend
Commit Range: 9f2d3b1..a7bce10
## Summary
- feat(auth): Add refresh token endpoint
- fix(api): Adjust connection timeout for RDS Proxy
## Related
- ADR: ADR-0007-auth-design.md
- Spec Section: api.auth, infra.db
## Decision Impact
Refresh Token導入により認証仕様が更新。
RDS Proxy接続パラメータ変更に伴い既存Lambda設定も調整が必要。
意義
GitのPushをコンテキストに含めることで、コード変更の背後にある意図や設計上の位置づけをLLMが理解できる。
仕様書更新・レビュー・テスト生成などの自動化トリガにもなる。
何をコンテキストにすべきか？の取捨選択
必要性
コンテキストが肥大化すると、LLMの応答精度が下がる。
したがって「すべてを残す」ではなく、「再利用価値のある事実だけを残す」という設計思想が重要。
判断基準
| 区分 | 残すべき情報 | 残さない情報 |
|---|---|---|
| 決定 | 会議で合意された事項、ADR、設計方針 | 未確定の雑談・個人意見 |
| 背景 | 決定に至った理由・根拠 | 感想や一時的な議論 |
| 変更 | mainへのマージ、仕様変更 | 一時ブランチやWIPコミット |
| ナレッジ | 再利用可能な議論・分析 | チケット進捗やリマインド |
| メタ情報 | タグ、ADRリンク、担当者 | システム通知、ログ |
原則
- Fact over Discussion：事実・決定・根拠を残す
- Atomicity：1トピック1ファイル
- Tag-driven retrieval：タグで抽出可能にする
- Temporal pruning：古い不要な情報はアーカイブ化
運用プロセス
| 役割 | 説明 |
|---|---|
| Context Curator | 週1で重複/矛盾を整理し、タグ辞書を管理 |
| Ingest Bot | Teams・Backlog・Git・メールを自動でMarkdown化 |
| Digest Bot | 毎朝 Daily/Weekly 要約を生成 |
| Review | ADRはPR形式で2名承認必須 |
今後の展望
- Context Pack生成を自動化し、ChatGPTなどのLLMにAPI経由で提供
- GitのPush内容から仕様書を自動更新する仕組みを統合
- ナレッジグラフを活用して「LLMがPJの記憶をもつ」状態を実現
- 仕様書・テストケース・リスク分析を“文脈駆動”で再生成できる環境を構築する
- 人材の流動性に適応した新しい組織のあり方を模索する
と、ここまで威勢よく書いてきたがナレッジグラフやRAGについては情報を漁ったりして最新動向や自分たちに合ったやり方を見つけていきたいと思いますまる。(まるに丸をつけるな)