使われるナレッジを目指して / Aiming_for_Highly_Utilized_Knowledge

LLM時代における社内ナレッジの運用設計に関するスライドです 。ナレッジが一元化されていないと 、仕様の散逸や属人化 、AI出力の不安定化を招くと指摘しています 。その解決策として、ナレッジ更新を日々の業務フローに組み込み 、成果物の品質と連動させて自然な更新動機を生むフィードバックループの構築を提案しています 。さらに、情報を「鮮度」と「普遍性」の軸で適切に分類し 、部署ごとの乱立を防いで共通の一次資料（SSOT）を維持する原則を解説 。人間とAIが同じ正解に一意に到達でき 、開発プロセス全体に染み込むナレッジの展望を示しています 。

Transcript

1. 　 使われるナレッジを⽬指して ~ ⼈もAIも迷わないナレッジアーキテクチャ ~ 2026.05.25
2. 　 2 ◆ 担当プロダクト：freee振込 ◆ 経歴： - 2024.03.31 ⽴命館⼤学⼤学院 情報理⼯学研究科 修了 - 2024.04.01 フリー株式会社⼊社 フリー株式会社の新卒QAエンジニアの１⼈で、現在は freee振込プロダクトを担当。 川端宏知（tonchan） QAエンジニア Hiroto Kawabata
3. 3 • なぜナレッジが必要なのか • ワークさせるためのナレッジ設計 • 使われるナレッジへ • 今後の展望 アジェンダ
4. 　 なぜナレッジが必要なのか
5. 　 5 みなさん、こんな場⾯に⼼当たり、ありませんか？ • 同じ機能の話なのに⼈‧AIによって⽤語が違う（申請、依頼、予約…） • 仕様書を探すと、3 箇所に違うバージョンがある • 新メンバーへの説明が毎回⼝頭で、⼈によって内容がぶれる こんな経験ありませんか？ これらは全て「チームの共有知識（コンテキスト）が⼀元化されていない」ことが原因です
6. 　 6 ナレッジをなぜ必要とするのか
7. 　 7 AIとMCPの登場により、ナレッジを改めて⼀元管理することのメリットはあるのか？ → MCPはあくまでデータにアクセスするだけで、ナレッジが補完する役割が必要 AI活⽤におけるMCPとナレッジの関係 MCPだけではダメな理由 • WikiやチャットをMCPで集めることは可能 • しかし⽣データはバラついておりコンテキ スト不⾜ • どれが最新で正解かをAIは判断させるコス トが⾼い • 結果として出⼒のブレや品質の不安定化を 招く ナレッジが補完すること • 集めたデータを整理‧統合して置く場所を 提供 • これが⼀次資料であると⼈間が明⽰ • ⽤語‧構造‧判断基準が⼀意に定まる • AIも⼈間も同じ場所を⾒て同じ答えに到達 可能
8. 　 8 ナレッジを整備すると、⼈間の組織にも効きます。 • オンボーディングが早くなる ◦ ⼝頭説明ではなく、ナレッジを読んでもらえばよい • 属⼈化が減る ◦ 「あの⼈に聞く」が「あれを読む」に変わる • チーム間の判断基準が揃う ◦ 重篤度‧テスト戦略‧⽤語が共通化する 「ナレッジ整備」は、AI 投資であると同時に、組織への投資でもある AI のためだけではない
9. 　 ワークさせるための ナレッジ設計
10. 　 10 ではなぜ、ナレッジが整備されないのか。それは以下の問題がよく発⽣するためです。。。 ナレッジの保守運⽤の難しさ 起きがちな問題 構造的な原因 ナレッジが古くなる 仕様変更時に更新が後回しになる メンテできる⼈が限られる 全体像を理解した⼈しか触れない（属⼈化） ⼯数に⾒合わない 「ナレッジ整備」はアウトカムがわかりづらく、 評価されにくい作業 情報が⽭盾する 上書きと追記が混ざり、どっちが正かわからない 結局放置される 上記の積み重ねで信頼を失う 「古くて間違ったナレッジ」は、 「ナレッジがないこと」より有害になる
11. 　 11 ⼈が動かない原因の構造分解 なぜ誰もナレッジをメンテしないのか 特別な作業になっている ナレッジの更新が、⽇々の業務フローの外側にあるため後回しになる デメリットが⾒えない 情報が古くても、その場では誰も困らないように⾒えてしまう 動機や場所が判然としない 書いた⼈へのフィードバックが薄く、アーキテクチャがないため置き場所に迷う
12. 　 12 ナレッジを使わないと業務が回らない状態を作ることがポイント 1. すべての業務成果物の input としてナレッジを必須化 2. ナレッジが古いと成果物の品質が下がる状態にする 3. 業務に⽀障が出ることで⾃然な更新動機を発⽣させる 4. ナレッジを更新することで成果物の品質を維持‧向上させる このループを回すことでナレッジの保守運⽤を業務の⼀環にしてもらう 結論：フィードバックループで動機を作る
13. 　 使われるナレッジへ
14. 　 14 2つの軸（鮮度‧普遍性）で情報を適切に分類する 社内ナレッジの価値は、外から持ってきた知識を⾃社の⽂脈に接続した瞬間に⽣まれる。 ナレッジに残すもの‧残さないもの 鮮度の軸（Evergreen vs Snapshot） • Evergreen（常緑）: 現時点の正解として上書 き更新するもの（用語集、業務フロー、テスト戦 略） • Snapshot（記録）: 過去のある時点の記録とし て追記するもの（PRD、議事録、ポストモーテム） 普遍性の軸（汎⽤ vs ラスト1マイル） • 汎用知識: 一般的な技法など外で学べるもの は社内に残さない • ラスト1マイル: 自社固有の文脈や命名、運用 制約は徹底して社内に残す
15. 　 15 • ナレッジ運⽤の落とし⽳の⼀つが、「部署ごとにナレッジを作る」 こと ◦ QA は QA の Wiki、開発は開発の Wiki、SRE は SRE の Wiki… ◦ 同じプロダクトの話なのに、3 つのバージョンが存在する。 • 部署ごとのナレッジ乱⽴を防ぎ、共通の⼀次資料を育てる 職責を超えて同じナレッジを使う 現場部⾨層（⾃由な⽤途開発） • 現場部門がそれぞれの用途に合わせて自由に 活用 • 文脈に応じた自由な試行錯誤を許容する 中央層（共通資産の舗装） • 再利用価値のあるものだけを共通資産化する • 同じdomain（仕様）を職責を超えて全員が読 む
16. 　 16 1. Evergreen（現在の正解を上書き）∕ Snapshot（過去の記録を追 加のみ） に分ける 2. 情報の置き場所を明確に決める 3. 重複しない a. 同じ情報は1箇所だけ。必要ならリンクで参照。 4. ⽭盾は Evergreen が 正 a. domain/ > docs/ の優先順位 5. SSOT を維持する a. ⼈間とLLM Agent が⼀意に正解を特定できる状態を保つ ナレッジのアーキテクチャを⽀える 5 つの原則
17. 　 今後の展望
18. 　 18 • 要求分析‧要件定義‧仕様策定 ◦ 過去仕様との⼀貫性を担保し、ユビキタス⾔語で⼀貫した⽤語を使⽤ • ヘルプドキュメント‧外部展開 ◦ 社内で定義された正確な⽤語をそのまま社外向けドキュメントやサポートに展開 • エラー監視‧ログ分析‧運⽤ ◦ ドメイン知識に基づいた正確なログ解釈やリスク判定をAIと⼈間が共通で⾏う 開発プロセス全体に染み込むナレッジの展望
19. ご清聴ありがとうございました