.mdc駆動ナレッジマネジメント/.mdc-driven knowledge management

.mdc駆動ナレッジマネジメント→ 知識APIとしてのmcp serverまで
Loglass TECH TALK vol.5〜50名のエンジニア全員で挑むCursor活用の全貌〜 LT資料

Transcript

1. 0 .mdc駆動ナレッジマネジメント → 知識APIとしてのmcp serverまで Loglass TECH TALK vol.5〜50名のエンジニア全員で挑むCursor活用の全貌〜 依田 啓佑 2025.4.10
2. 1 サマリー Cursor rulesとは… ※ 本資料の図解の６割は claude先生に作成いただいております 従来的なナレッジマネジメント方法論の 最近の技術による実装 「組織」として 育てる https://amzn.asia/d/1o0hMOW (最近は別の新装版も出てます)
3. 2 サマリー 開発関連知識管理の変遷
4. 3 Agenda
5. 4 Agenda 1.サマリー 2.why: なぜ知識を書くのか？ 3.what: 何を書くのか？ 4.how: どのように知識サイクルを回すのか？ 5.when: いつ、開発プロセスの中で利用されるか？ 6.who, where: 誰が、どこで知識創造するのか？ 7.今後の展望
6. 5 なぜ知識を書くのか？ ― 開発文脈のナレッジ蓄積の課題と .mdcによる進化可能性 ・見られない ・更新されない、メンテナンスコスト 半ば勝手に適用される -> 改善点が出る -> 改善PRが出る コードと近い箇所にgit管理 指摘をまとめた学びをruleに出力させる 知識の陳腐化 その文脈で必要な知識が自動でコンテキストに含められる (完全ではないが) クエリをLLMが解釈してくれる 丁寧に言語化した分、良い結果が返る その場の知ってるか知らないかの知識の、言語化の強制 文脈に応じた解釈、使用 コンテキストに追加した後、適用すべきか自己判断 ・いつ何を見ればいいかわからない ・多すぎると検索の仕方がわからない 検索性の悪さ ・場合によって正解が違う知識 文脈依存性の解決難 ・コンテキスト整備がagent活用に直結 ・相対的に、ハイコンテキスト文化が不 利になっているのではないか ドキュメンテーションの復権
7. 6 なぜ知識を書くのか？― Loglassのナレトラにおける課題 Loglassにおいても… ➢ FASTフレームワーク化の動的チーミングにお いて、チームへの人の出入りが激しい ➢ 新入社員の増加 既存メンバーの新規事業へ の異動 ➢ 仕様の暗黙化による品質低下 ➢ コンテキスト整備した競合への開発速度劣後 口伝に頼らないナレトラが急がれる
8. 7 Agenda 1.サマリー 2.why: なぜ知識を書くのか？ 3.what: 何を書くのか？ 4.how: どのように知識サイクルを回すのか？ 5.when: いつ、開発プロセスの中で利用されるか？ 6.who, where: 誰が、どこで知識創造するのか？ 7.今後の展望
9. 8 何を書くのか？ ― スコープ ※ 実際の社内ADRより抜粋 ➢ 規約・そのコードベース特有の知識・使用法 .mdc ➢ プロダクトコンテキスト等 .md ➢ より詳細な仕様 .feature(Gherkin記法による仕様記述)
10. 9 何を書くのか？ ― どこまで書くのか？ 一般的知識 プロダクト特有 コード的知識 ドメイン的知識 書かない 書かない 書く 書く AIくん知っとるやろ系 それは教えられなきゃ知らないよね系 規約系（そのチーム内の合意） まあコードを読めばわかる系 型情報や関数名で表明されている知識 処理を追えばわかること コメントでの目的の補足 〜の原則などのベスプラの詳細 浅い部分のドメイン知識 有名ライブラリの使い方 固有のユビキタス言語の意味 社内デザインシステムの使い方 プロダクトやサブドメインの知識を凝 縮したサマリ コーディング・テスト規約 PR本文のテンプレ 関数型スタイルに寄せろ、のような指針
11. 10 何を書くのか？ ― 実際の.cursor/配下ディレクトリ 個人の好みが介在するruleは ➢ `local`のプレフィックス ➢ それをgitignore
12. 11 何を書くのか？ ― 実例: excel操作に関する知識 rule type: 適用の温度感 ✓ 基本manually ✓ 規約レベルのものはAuto Attached/ Agent Requested 本文 ✓ yaml形式などにはしていない ✓ 日本語（人間へのオンボも兼ねるので） （以下も追加してもよさそう） バージョン ✓ 評価・改善のためにあると便利そう タグ ✓ 何に関連する知識かのフック
13. 12 Agenda 1.サマリー 2.why: なぜ知識を書くのか？ 3.what: 何を書くのか？ 4.how: どのように知識サイクルを回すのか？ 5.when: いつ、開発プロセスの中で利用されるか？ 6.who, where: 誰が、どこで知識創造するのか？ 7.今後の展望
14. 13 どのように知識サイクルを回すのか？ ― SECIモデルの実装と捉えた場合の.mdc 内面化/共同化 ・形式知->暗黙知 ・暗黙知の個人の内面化 表出化 ・暗黙知->形式知 ・図解化や言語化 連結化 ・知識 ×知識 ・体系化や掛け合わせ 評価 ・知識の評価・効果測定 ・SECIには含まれず？ ① rule候補の発掘 ・AIの出したコードから学ぶ ・rule作りのモブ作業 ・ruleを見てベスプラを学習 ruleを媒体に知識が伝播 ② ruleを形式化 ・PRを出すことで暗黙知を言語化 ・git上で共有される ・cursorが適用すべきruleを拾う 自動適用される実用的な形で形式化 ④ ruleの評価・先鋭化 ・有効性の測定（ここが難しい..） ・機能しないものは捨てる コンテキストを汚しすぎない ③ ruleの体系化・創発 ・他の人のruleの改善 ・rule対する意見の競合->議論->止揚 ・知識の構造をまとめ直す ruleが組織の集合知として育つ SECIモデル
15. 14 どのように知識サイクルを回すのか？ ― loglassのruleのライフサイクルの中で実際に行なっている/試したいこと 俺たちの Cursor道は… まだ始まったばかり！
16. 15 Agenda 1.サマリー 2.why: なぜ知識を書くのか？ 3.what: 何を書くのか？ 4.how: どのように知識サイクルを回すのか？ 5.when: いつ、開発プロセスの中で利用されるか？ 6.who, where: 誰が、どこで知識創造するのか？ 7.今後の展望
17. 16 いつ.開発プロセスの中で使うか？ ― 開発プロセスの中での使い所
18. 17 Agenda 1.サマリー 2.why: なぜ知識を書くのか？ 3.what: 何を書くのか？ 4.how: どのように知識サイクルを回すのか？ 5.when: いつ、開発プロセスの中で利用されるか？ 6.who, where: 誰が、どこで知識創造するのか？ 7.今後の展望
19. 18 誰が、どこで？ ― SECIモデル「ミドルアップダウン」「場(Ba)」の概念
20. 19 誰が、どこで？ ― Loglassでは？ https://comemo.nikkei.com/n/n26dc284dcd5a
21. 20 Agenda 1.サマリー 2.why: なぜ知識を書くのか？ 3.what: 何を書くのか？ 4.how: どのように知識サイクルを回すのか？ 5.when: いつ、開発プロセスの中で利用されるか？ 6.who, where: 誰が、どこで知識創造するのか？ 7.今後の展望
22. 21 .mdcのその先に― .mdcが育ち、知識APIと化す .mdcが育ったその先に…
23. 22 .mdcのその先に ― docのmcp化を最近見かけるようになっている
24. 23 自己紹介 株式会社ログラス エンジニア 依田 啓佑 Keisuke Yoda x: kei_output_1104 後で資料upします！