営業オントロジーの作り方と、エージェントからの辿り方 ── ナレッジワークの現場から

油井 誠 (Makoto Yui) / 株式会社ナレッジワーク エキスパートAIエンジニア

※2026/9/28開催「Encraft #26 オントロジー解体新書」の登壇資料です
https://knowledgework.connpass.com/event/403127/

＜セッション概要＞
ナレッジワークでは営業情報をAIエージェント向けのオントロジーとして扱う取り組みを進めていますが、今回はそのうち、社内共有された営業資料と、AI商談記録に残る録画の要約・文字起こしを扱う2つをご紹介します。それぞれ「資料に何が書いてあるか」「商談で何が話されたか」を入り口に、オントロジーを自動で組み立てています。

分類に使う語彙（商材・顧客課題・訴求テーマ、業界、ソリューション、営業アクション）はすべて事前に定義したマスタに接地させ、生成AIに作らせるのは資料や商談から取り出した事実の側だけに限定しています。

本セッションでは、スキーマの全体像を簡単にお示ししたうえで、エージェントが「この課題に効くページ」「同じ課題が出ている別商談」を数ホップの探索だけで辿る実例をご紹介します。

＜プロフィール＞
NAISTにて博士（工学）取得。日本学術振興会特別研究員、オランダCWI客員研究員、産業技術総合研究所 主任研究員を経て、トレジャーデータ株式会社シニアプリンシパルエンジニア。2026年7月より株式会社ナレッジワーク エキスパートAIエンジニア、プレイングマネージャとしてAgent OSチームを率いる。オープンソースの機械学習ライブラリ Apache Hivemall の開発者。IPA未踏ソフトウェア創造事業スーパークリエータ。
X: @myui

Transcript

1. Encraft #26 オントロジー解体新書 営業オントロジーの作り方と、 エージェントからの辿り方 ── ナレッジワークの現場から 株式会社ナレッジワーク エキスパートAIエンジニア 油井 誠 @myui kws l ide-ex te r na l -26 081 4 -43 c71 695
2. 自己紹介 経歴 NAIST にて博士（工学）取得 日本学術振興会 特別研究員 オランダ CWI 客員研究員 産業技術総合研究所 主任研究員 トレジャーデータ株式会社 シニアプリンシパルエンジニア 油井 誠 2026年7月〜 株式会社ナレッジワーク エキスパートAIエンジニア プレイングマネージャとして Agent OS チームを率いる Makoto Yui @myui 株式会社ナレッジワーク エキスパートAIエンジニア © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 Apache Hivemall 開発者 IPA 未踏スーパークリエータ オープンソースの機械学習ライブラリ 未踏ソフトウェア創造事業 2
3. なぜオントロジーか 業務理解のための羅針盤 ・作る過程で業務理解が必然的に求められる ・その機会こそトップダウン構成の価値 探索のための索引 ・語彙を整備して名前の揺れをなくす ・ここが全文検索・意味索引との違い オントロジーは業務理解の羅針盤であり、探索のための索引です © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 3
4. アクションから逆算するスキーマ設計 ① 意思決定の 棚卸し ② ユースケースの ヒアリング • 頻度×重要性で積み 上げる • アクションにつなが るものを選ぶ • 社内のFDEやコンサ ルの人にエージェン トの使われ方を聞く ③ 業務スキーマの 設計 • Object / Link と持た せるプロパティを決 める ④ 語彙の 接地 • 営業プロセスマッ プ・ソリューション マップをマスタにす る 何をやるかを決めてから、スキーマ設計に取りかかります © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 4
5. 設計で決めた3つのこと 語彙はマスタに接地 ・分類語彙はすべて事前定義 ・LLMが作るのは事実の側だけ ・営業コンサルの知見を語彙に DBはPostgres グラフはシンプルに ・ノードの次数は増やさない ・代わりにメタデータを厚くする ・高次数は管理も利用も難しい ・実体は単なるproperty graph ・LLMはSQLを書くのが得意 ・GraphQLは今のところ不要 ・将来はSQL/PGQ（PG19）も視野 語彙を固め、グラフはシンプルに保ちます © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 5
6. グラフDBではなくPostgresを選んだ理由 グラフDB 実体は単なるproperty graph。運用に慣れたPostgres上の社内実装をそのまま使い、それで 十分だった GraphQL / mem0 最初は迷ったが不採用。スキーマが固定なのでエージェントがSQLを直接書け、今のところ 不便はない クエリ LLMはCypherよりSQLが得意。joinは増えるが、次数を増やさない設計とLRUキャッシュで 吸収する 抽出コスト mem0も最新版はspaCy＋規則でentityを抽出する方向。LLMに全部を任せない ※ 将来Postgresから移行する可能性はあるが、今のところ必要性は感じていない © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -bd 018 e12 6
7. （自動構成される）営業オントロジー ─ 2系統のIngestion 社内共有 Ingestion 資料に「何が書いてあるか」 AI商談記録 Ingestion 商談で「何が話されたか」 入力 社内共有された営業資料（画像 / テキスト） 商談録画の要約・文字起こし＋CRM連携情報 語彙マスタ （＝問いの入口） Strategy語彙 / seedマスタ（JSIC業界ほか） → 顧客課題・業界・商材から引く ソリューションマップ / 営業プロセスマップ → 顧客課題・営業アクション・商談から引く 入力の異なる2系統が、同じObject / Linkのグラフに書き込みます © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 7
8. 【社内共有 Ingestion】オントロジースキーマ 抽出元の資料 ページ構成部品 Strategy語彙マスタ seedマスタ（参照のみ） describes / mentions knowledge targets （資料） for / about offering 商材 分類ノードの出所（マスタ） industry 業界 Strategy語彙 ─ offering / issue / theme run開始時に表を凍結。語彙の質がそのまま抽出 の質を決める account 企業 composed_of addresses artifact_component （ページ部品・範囲） promotes 抽出生成エンティティ seedマスタ ─ industry ほか industry 119（JSIC準拠）。マスタに無ければ Linkごと落とす issue 顧客課題 theme 訴求テーマ 抽出で生成 ─ knowledge / account 企業名の表記ゆれは別名マスタで名寄せする Linkを持たないObjectは引けないため、 Ingestionで必ずLinkを張ります © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 ※ pptx などのスライド資料は、VLM でページ画像を読み取ってオントロジーを抽出 8
9. 利用例① 課題から「効くページ」を引く（社内共有） シナリオ 金融のお客様から「現場が提案資料を探せない」と相談された。使える資料と見せるべきページを提示したい 質問 「金融のお客様が『現場が提案資料を探せない』と 言っている。使える資料と見せるべきページは？」 Agentが辿ったリンク（1 hopごとに絞り込む） issue ナレッジ探索の非効率 思考 回答 ① 課題文を Strategy 語彙の issue に正規化 ② issue に addresses が張られたページ部品へ ③ 部品が属する資料本体へ上がり、業界で絞る ListSalesOntologyLinks(dst=…, linkType=…) この課題には2本の資料が使えます ・〇〇株式会社向け 提案資料 v3 ／ p.12–14 ・△△信用金庫向け 提案資料 v2 ／ p.4 いずれも同じ issue に addresses が張られた部品 addresses（逆） 効くページ部品へ 12件 artifact_component 該当ページ部品 composed_of（逆） 資料本体へ 5件 knowledge 提案資料 targets 対象業界で絞る 2件 industry 金融業 顧客課題1件から、効くページと資料本体を3 hopで引けます © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 9
10. 【AI商談記録 Ingestion】オントロジースキーマ CRM / SFDC連携エンティテ ィ 録画（meeting_recorded） LLM解析イベント 事前定義マスタ CRM / SFDC連携 opportunity contact target_event context_* / suggested_* issue_mentioned 課題への言及 target_ solution solution ソリューションマップ lead meeting_recorded AI商談記録の録画 account belongs_to → account target_event performed_by sales_activity_performed 営業アクションの実施 target_ sales_action sales_action 営業プロセスマップ 解析イベントはLLMが抽出し、マスタ語彙は生成しない user KWユーザ 課題の同一性は、共有された solution ノードで表します © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 ※ solution / sales_action へのマッピングは、低コスト化のため商談要約を CPU でも動く埋め込み（ruri-v3-310m）で実施 10
11. 利用例② 同じ課題が出た別商談を引く（AI商談記録） シナリオ ある商談で挙がった課題が、他のどのミーティングでも語られているかを知りたい 質問 「この商談であがった課題が言及された別の ミーティングを、課題ごとに1件教えて」 Agentが辿ったリンク（クエリ2本を連結） 1 思考 ① 商談に紐づくミーティングから、言及された 課題イベントを経て solution へ（3 hop） ② solution から逆引きし、同じ課題が語られた 別のミーティングを特定（2 hop） opportunity 起点の商談 suggested_opportunity（逆） meeting_recorded 元の商談記録 target_event（逆） issue_mentioned 言及された課題 回答 9件の課題で、別のミーティングが見つかりました 例：AI機能実装 → Zoom商談 2025-06-04 データコンサル → Teams商談 2025-07-15 ※課題ごとの集約と元商談の除外は後処理 target_solution solution 共通課題 2 target_solution（逆） issue_mentioned 同じ課題の別イベント target_event meeting_recorded 別のミーティング 共有された solution を介して、別商談まで5 hopで辿れます © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 11
12. ぶつかった壁と、これから ①権限 ACLを後から入れた。全ノード / リンクにオリジンID（ナレッジID・商談ID）を持たせ、ア クセス時に権限をlazyに評価するdelegate設計で対応 ②コスト 1社で月80,000件の商談をLLMに通すのは厳しい。SaaS標準の粗利70%の中で、オントロジ ー構築に原価をいくらかけられるか ③更新 9割以上が追記のため、appendから対応。スキーマ変更への追従、データソースとの同期、 権限の追従に現在対応中 権限は最初から設計に入れておくべきでした © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 12
13. まとめ 単なる索引 業務から逆算したオントロジー ・索引が先で、問いは後から考える ・語彙が揺れて同じものが分裂する ・業務理解は使う人の頭に残るため 次の構造に繋げる設計が別途必要 ・問いが先で、スキーマは後から作る ・マスタ語彙に接地し揺れを防ぐ ・業務理解がスキーマに埋め込まれ 数 hopでActionの材料となる オントロジーの価値は、語彙とアクションで決まります © Knowledge Work Inc. kws l ide-ex te r na l -26 081 4 -fc28 d311 13
14. kws l ide-ex te r na l -26 081 4 -c4 d6b f d3