AIが自分で育てるナレッジカタログ

Transcript

1. KNOWLEDGE OPS AIが自分で育てる ナレッジカタログ データ出しのSlack相談窓口を支える「検証税」との戦い方 山﨑 （ゆっちゃん） 01
2. WHAT WE RUN Slackに常駐するAIが、社内の「データ相談窓口」 社員（営業・CS） Claude Slackで質問するだけ PC上に常駐するAI 社内データ Salesforce BigQuery Tableau 定型業務の自動実行だけでなく、専用機能のないその場限りの依頼にも答える。 今日の主役は後者です。 03
3. REAL OUTPUT 実物 — 「同業他社の他エリア採用実績まとめて」 営業メンバー 10:42 専用機能はありません。AIがその場で ◯◯業の企業に提案したいんだけど、他エリアで同業の採用実績って 社内データを横断検索して答えています。 ある？ • 関連キーワードで横断検索 同業の採用実績を横断検索しました。該当は1社のみです。 • 該当が1社なら盛らずに1社と開示 ・A社（他エリア）: 掲載◯ヶ月で採用2名（職種: ◯◯） • 使い方の提案まで返す ・同業の近接業種まで広げると+2社ヒットします • 企業名は匿名化 AI 10:43 提案では「同業実績1社」と正直に伝えつつ、近接業種の事例で補強 するのがおすすめです。広げて出しますか？ ※実際のやり取りを架空データで再構成したイメージ 04
4. THE PROBLEM でも、素のAIは平気で間違える — 「検証税」 40% 27.6% 35.5% 生成AIで節約した時間のうち テーブル選択の誤り 多段クエリの誤り 手戻りで失われる割合 答えは一瞬で出る。その答えの検証に人間の時間が溶ける。 これが「検証税」です。 出典: メルカリ na0氏「データエージェントのためのナレッジカタログ」（データ利活用分科会 #33, 2026） 05
5. WHY IT FAILS AIが知らないのは、SQLではなく「うちのルール」 間違いの正体は技術力不足ではなく、社内固有の暗黙知の欠落です。 データの在処を知らない 業務の判定ルールを知らない 「採用実績」はどのテーブル？ Salesforce？ BigQuery 「受注」は日付ではなく成立フラグで判定する。合計フィール ？ Tableau？ 似た名前の列が複数あるとき、正はどれ？ ドには使用禁止のものがある——現場が血で覚えたルール たち。 この暗黙知を機械が引ける形にして渡せば、検証税は下がるはず。 06
6. THE SOLUTION 作ったのは「地図」と「辞書」— ナレッジカタログ ナレッジカタログ 散在する生データ SF / BQ / Tableau / GA4 地図 = Catalog どこに・誰が・どの鮮度で 列名も定義もバラバラ 使うAI クエリを書く前に 地図と辞書を必ず引く 辞書 = Knowledge どう判定するのが正か ルールは YAML で構造化し、検証済み（verified）だけをAIに引かせます。 07
7. TWO MODES ルールの引き方は2つ — 焼き込むか、毎回引くか モードA — 定型業務 モードB — 定形外 開発時に織り込む 実行時に毎回引く 毎回同じ手順の業務は、ルールをスキル本体に焼き込む。 その場限りの依頼は、クエリを書く前に必ず逆引きコマンドで 実行が速い。 カタログを引く。 弱点: ルールが更新されると古くなる。 強み: ルール更新が即反映。 → 後述の「配線検査」で乖離を監視。 古い知識で答えることがない。 安定したルールはA、変わりやすいルールはB。使い分けが設計の肝です。 08
8. MODE B IN ACTION モードBの30秒 — クエリを書く前に、必ず引く 定形外の依頼 逆引き lookup-rules ルール準拠のクエリ Slackに届く 触るデータソース起点 SF / BQ / Tableau 回答 ナレッジカタログ 関連する verified ルールだけ返す 「引かずにクエリを書き始めない」は、AIの行動規約として強制。 関連ルールだけを返すので、コンテキストも汚しません。 09
9. ……と、ここまで話すと、必ずこう言われます。 「それ、維持が大変じゃない？」 ルールのYAML化、書式チェック、矛盾の検査、更新の反映…… たしかに、人間がやったら破綻します。 10
10. THE ANSWER 維持コストは、司書AIが払う 司書エージェント（AI） 人間（私） • ドラフト生成 — ルール候補をYAML化 • レビュー — ドラフトが業務的に正しいか見る • lint — 書式・必須項目を週次で検査 • 承認 — verified への昇格を判断する • 配線検査 — 登録と参照のズレを検知 • 矛盾監査 — ルール同士の衝突を隔週で検査 以上。定期検査の結果は、問題があったときだけAIからDMが 届きます。 品質の判断だけが人間の仕事。品質の作業は全部AIの仕事。 11
11. DETECTION 検知の実例 — 「ナレッジ化したのに同じミスが再発」を防ぐ 一番怖い事故は、ルールを登録したのに使う側がそれを引いていない状態。 登録済み＝安心、ではありません。実際に再発事故を経験しました。 配線検査（wiring-check）の仕組み 各ルールに「関係する話題」と「触るデータソース」の証拠を持たせ、司書AIが全スキルを走査。そのデータを実際にクエリしているのに、 ルールを参照していないものを「確定漏れ」として検出し、オーナーに通知します。 キーワード一致だけだと誤検知が数百件に膨張した失敗を経て、 「話題 × 物理的なデータ接触」のAND条件に落ち着きました。 12
12. HOW IT GROWS ルールはどう増えるか — 現場の「引っかかり」が起点 欠落を発見 止まって確認 司書がドラフト レビュー → 昇格 モードBの作業中に AIは勝手に登録しない 定義・根拠・出典を verified になった瞬間 「ルールが無い」 人間が承認 YAMLに構造化 全AIが参照開始 実務で引っかかったものだけが登録される——使われないルールが溜まらない構造です。 13
13. RESULTS 運用実績 — そして知見は定型スキルへ「昇格」する 75件 1人 verified ルール 運用者 （検証済みナレッジ） （+ 司書AI 1体） SALARY SURVEY ◯◯エリア 給与調査レポート 外部求人媒体 × 公的統計の横断集計・3職種 職種A 職種B 職種C ※アウトプットのイメージ（架空データ） モードBで繰り返される依頼は、蓄積したルールごと定型スキル（モードA）へ昇格。 右の給与調査レポートも、もとは定形外の依頼から生まれた自動生成スキルです。 14
14. SUMMARY まとめ • AIのデータ回答は「検証税」との戦い。原因は社内固有の暗黙知の欠落 • 暗黙知を「地図（Catalog）と辞書（Knowledge）」として機械可読に構造化した • 安定ルールは焼き込み（モードA）、変わりやすいルールは毎回引く（モードB） • 維持作業（ドラフト・lint・配線検査・矛盾監査）は司書AIが実行、人間は承認だけ • エンジニアでない事業側の1人でも、AIと二人三脚なら知識基盤は回せる 15
15. 知識の維持コストは、 AIが払える時代になった。 最後まで読んでいただきありがとうございました 山﨑（ゆっちゃん） 16