Upgrade to Pro
— share decks privately, control downloads, hide ads and more …
Speaker Deck
Features
Speaker Deck
PRO
Sign in
Sign up for free
Search
Search
.mdc駆動ナレッジマネジメント/.mdc-driven knowledge management
Search
Yoda Keisuke
April 10, 2025
Technology
32
22k
.mdc駆動ナレッジマネジメント/.mdc-driven knowledge management
.mdc駆動ナレッジマネジメント→ 知識APIとしてのmcp serverまで
Loglass TECH TALK vol.5〜50名のエンジニア全員で挑むCursor活用の全貌〜 LT資料
Yoda Keisuke
April 10, 2025
Tweet
Share
More Decks by Yoda Keisuke
See All by Yoda Keisuke
Expertise as a Service via MCP
yodakeisuke
1
470
Code as Context 〜 1にコードで 2にリンタ 34がなくて 5にルール? 〜
yodakeisuke
0
440
Agent Rules as Domain Parser
yodakeisuke
1
1.3k
Reactのミニマム理解 〜UI = f(data)(state)+sideEffect〜
yodakeisuke
5
150
インフラ高級言語としてのAWS CDK〜"設定"より1段階ハイレベルな抽象化〜
yodakeisuke
1
100
Other Decks in Technology
See All in Technology
o11yで育てる、強い内製開発組織
_awache
3
100
全てGoで作るP2P対戦ゲーム入門
ponyo877
3
1.3k
OpenAI gpt-oss ファインチューニング入門
kmotohas
2
850
Geospatialの世界最前線を探る [2025年版]
dayjournal
3
470
Function calling機能をPLaMo2に実装するには / PFN LLMセミナー
pfn
PRO
0
820
職種別ミートアップで社内から盛り上げる アウトプット文化の醸成と関係強化/ #DevRelKaigi
nishiuma
2
120
研究開発部メンバーの働き⽅ / Sansan R&D Profile
sansan33
PRO
3
20k
【新卒研修資料】LLM・生成AI研修 / Large Language Model・Generative AI
brainpadpr
23
16k
Why React!?? Next.jsそしてReactを改めてイチから選ぶ
ypresto
10
4.1k
ACA でMAGI システムを社内で展開しようとした話
mappie_kochi
0
160
生成AIを活用したZennの取り組み事例
ryosukeigarashi
0
190
非同期処理実行基盤 Delayed脱出 → Solid Queue完全移行への旅路。
srockstyle
3
1.6k
Featured
See All Featured
[RailsConf 2023 Opening Keynote] The Magic of Rails
eileencodes
30
9.7k
A Tale of Four Properties
chriscoyier
160
23k
The Cult of Friendly URLs
andyhume
79
6.6k
Imperfection Machines: The Place of Print at Facebook
scottboms
269
13k
Balancing Empowerment & Direction
lara
4
670
Code Reviewing Like a Champion
maltzj
525
40k
Agile that works and the tools we love
rasmusluckow
331
21k
Done Done
chrislema
185
16k
Rebuilding a faster, lazier Slack
samanthasiow
84
9.2k
StorybookのUI Testing Handbookを読んだ
zakiyama
31
6.2k
KATA
mclloyd
32
14k
Building a Modern Day E-commerce SEO Strategy
aleyda
43
7.7k
Transcript
0 .mdc駆動ナレッジマネジメント → 知識APIとしてのmcp serverまで Loglass TECH TALK vol.5〜50名のエンジニア全員で挑むCursor活用の全貌〜 依田
啓佑 2025.4.10
1 サマリー Cursor rulesとは… ※ 本資料の図解の6割は claude先生に作成いただいております 従来的なナレッジマネジメント方法論の 最近の技術による実装 「組織」として
育てる https://amzn.asia/d/1o0hMOW (最近は別の新装版も出てます)
2 サマリー 開発関連知識管理の変遷
3 Agenda
4 Agenda 1.サマリー 2.why: なぜ知識を書くのか? 3.what: 何を書くのか? 4.how: どのように知識サイクルを回すのか? 5.when:
いつ、開発プロセスの中で利用されるか? 6.who, where: 誰が、どこで知識創造するのか? 7.今後の展望
5 なぜ知識を書くのか? ― 開発文脈のナレッジ蓄積の課題と .mdcによる進化可能性 ・見られない ・更新されない、メンテナンスコスト 半ば勝手に適用される -> 改善点が出る
-> 改善PRが出る コードと近い箇所にgit管理 指摘をまとめた学びをruleに出力させる 知識の陳腐化 その文脈で必要な知識が自動でコンテキストに含められる (完全ではないが) クエリをLLMが解釈してくれる 丁寧に言語化した分、良い結果が返る その場の知ってるか知らないかの知識の、言語化の強制 文脈に応じた解釈、使用 コンテキストに追加した後、適用すべきか自己判断 ・いつ何を見ればいいかわからない ・多すぎると検索の仕方がわからない 検索性の悪さ ・場合によって正解が違う知識 文脈依存性の解決難 ・コンテキスト整備がagent活用に直結 ・相対的に、ハイコンテキスト文化が不 利になっているのではないか ドキュメンテーションの復権
6 なぜ知識を書くのか?― Loglassのナレトラにおける課題 Loglassにおいても… ➢ FASTフレームワーク化の動的チーミングにお いて、チームへの人の出入りが激しい ➢ 新入社員の増加 既存メンバーの新規事業へ
の異動 ➢ 仕様の暗黙化による品質低下 ➢ コンテキスト整備した競合への開発速度劣後 口伝に頼らないナレトラが急がれる
7 Agenda 1.サマリー 2.why: なぜ知識を書くのか? 3.what: 何を書くのか? 4.how: どのように知識サイクルを回すのか? 5.when:
いつ、開発プロセスの中で利用されるか? 6.who, where: 誰が、どこで知識創造するのか? 7.今後の展望
8 何を書くのか? ― スコープ ※ 実際の社内ADRより抜粋 ➢ 規約・そのコードベース特有の知識・使用法 .mdc ➢
プロダクトコンテキスト等 .md ➢ より詳細な仕様 .feature(Gherkin記法による仕様記述)
9 何を書くのか? ― どこまで書くのか? 一般的知識 プロダクト特有 コード的知識 ドメイン的知識 書かない 書かない
書く 書く AIくん知っとるやろ系 それは教えられなきゃ知らないよね系 規約系(そのチーム内の合意) まあコードを読めばわかる系 型情報や関数名で表明されている知識 処理を追えばわかること コメントでの目的の補足 〜の原則などのベスプラの詳細 浅い部分のドメイン知識 有名ライブラリの使い方 固有のユビキタス言語の意味 社内デザインシステムの使い方 プロダクトやサブドメインの知識を凝 縮したサマリ コーディング・テスト規約 PR本文のテンプレ 関数型スタイルに寄せろ、のような指針
10 何を書くのか? ― 実際の.cursor/配下ディレクトリ 個人の好みが介在するruleは ➢ `local`のプレフィックス ➢ それをgitignore
11 何を書くのか? ― 実例: excel操作に関する知識 rule type: 適用の温度感 ✓ 基本manually
✓ 規約レベルのものはAuto Attached/ Agent Requested 本文 ✓ yaml形式などにはしていない ✓ 日本語(人間へのオンボも兼ねるので) (以下も追加してもよさそう) バージョン ✓ 評価・改善のためにあると便利そう タグ ✓ 何に関連する知識かのフック
12 Agenda 1.サマリー 2.why: なぜ知識を書くのか? 3.what: 何を書くのか? 4.how: どのように知識サイクルを回すのか? 5.when:
いつ、開発プロセスの中で利用されるか? 6.who, where: 誰が、どこで知識創造するのか? 7.今後の展望
13 どのように知識サイクルを回すのか? ― SECIモデルの実装と捉えた場合の.mdc 内面化/共同化 ・形式知->暗黙知 ・暗黙知の個人の内面化 表出化 ・暗黙知->形式知 ・図解化や言語化
連結化 ・知識 ×知識 ・体系化や掛け合わせ 評価 ・知識の評価・効果測定 ・SECIには含まれず? ① rule候補の発掘 ・AIの出したコードから学ぶ ・rule作りのモブ作業 ・ruleを見てベスプラを学習 ruleを媒体に知識が伝播 ② ruleを形式化 ・PRを出すことで暗黙知を言語化 ・git上で共有される ・cursorが適用すべきruleを拾う 自動適用される実用的な形で形式化 ④ ruleの評価・先鋭化 ・有効性の測定(ここが難しい..) ・機能しないものは捨てる コンテキストを汚しすぎない ③ ruleの体系化・創発 ・他の人のruleの改善 ・rule対する意見の競合->議論->止揚 ・知識の構造をまとめ直す ruleが組織の集合知として育つ SECIモデル
14 どのように知識サイクルを回すのか? ― loglassのruleのライフサイクルの中で実際に行なっている/試したいこと 俺たちの Cursor道は… まだ始まったばかり!
15 Agenda 1.サマリー 2.why: なぜ知識を書くのか? 3.what: 何を書くのか? 4.how: どのように知識サイクルを回すのか? 5.when:
いつ、開発プロセスの中で利用されるか? 6.who, where: 誰が、どこで知識創造するのか? 7.今後の展望
16 いつ.開発プロセスの中で使うか? ― 開発プロセスの中での使い所
17 Agenda 1.サマリー 2.why: なぜ知識を書くのか? 3.what: 何を書くのか? 4.how: どのように知識サイクルを回すのか? 5.when:
いつ、開発プロセスの中で利用されるか? 6.who, where: 誰が、どこで知識創造するのか? 7.今後の展望
18 誰が、どこで? ― SECIモデル「ミドルアップダウン」「場(Ba)」の概念
19 誰が、どこで? ― Loglassでは? https://comemo.nikkei.com/n/n26dc284dcd5a
20 Agenda 1.サマリー 2.why: なぜ知識を書くのか? 3.what: 何を書くのか? 4.how: どのように知識サイクルを回すのか? 5.when:
いつ、開発プロセスの中で利用されるか? 6.who, where: 誰が、どこで知識創造するのか? 7.今後の展望
21 .mdcのその先に― .mdcが育ち、知識APIと化す .mdcが育ったその先に…
22 .mdcのその先に ― docのmcp化を最近見かけるようになっている
23 自己紹介 株式会社ログラス エンジニア 依田 啓佑 Keisuke Yoda x: kei_output_1104
後で資料upします!
24
25