「あの部品、どこで使われてたっけ」「この不具合、どこまで波及するんだろう」――製造業の現場には、こうした問いに答えるドメイン知識が眠っているものの、多くは特定の担当者の頭の中にとどまり、十分に活かしきれていません。AIに聞けばすぐ正確な答えが返ってくる仕組みは作れないか。そう考えて浮かんだのが「グラフDB」という技術でした。南国ソフトの非エンジニアが、手探りで可能性を探る検討過程を正直に共有していきます。
第1回:なぜ今グラフDBなのか
「あの部品、どこで使われてたっけ」「この不具合、どこまで波及するんだろう」――こうした問いは、現場で長年繰り返されてきました。設計の経緯、過去の不具合とその対策、工程間の依存関係……製造業の現場には何かしらドメイン知識は蓄積されているのに、その活用は、特定の担当者に聞かないと分からないなど属人的になってしまい十分に活用しきれてないケースが見受けられます。
この属人化したナレッジを、AIに聞けばすぐに正確な答えが返ってくる状態に変えられないか――そう考えたときに選択肢として浮かんできたのが「グラフDB」という技術です。このブログの記事シリーズでは、南国ソフトの非エンジニアが、グラフDBの可能性についての検討過程を、正直に共有していきたいと思います。
通常の管理方法（RDB）で、各データの関係性から辿り分析する場合
製造現場の「つながり」は、普段はExcelやRDB(リレーショナルデータベース)で管理されていることがほとんどだと思います。
例えば、不具合を取り上げた際、よくあるケースとして一連の不具合関係情報（No.、報告者、不具合症状、対策実施状況）を、一つのテーブル形式で管理しているケースが多いと感じています。その際、不具合が発生した部品だけを追跡するケースならいいのですが、その部品がどの製品に使われたか、またその出荷状況まで追跡しようとすると、非常に手間がかかり、話が変わってきます。
この追跡を普段利用されているRDBを使用して、「この不具合、どこまで波及するんだろう」の問いに答えるには、
不具合現象テーブル（→原因テーブル→対策テーブル）と辿り、「何が原因で、どう対処したか」を押さえたうえで、さらに原因となった部品を手がかりにBOM→製品テーブル→出荷実績テーブル→顧客マスタ……と、特定の部品を元にテーブル同士辿る（次々にJOIN(結合)していく）必要があります。
一方で、AIですぐ答えられるようにしたい――そう考えたときに浮かぶのが生成AIを使用したRAG(検索拡張生成)があります。そこで次に、グラフDBに興味を持ったきっかけとなった、生成AIとRDBによるRAGシステムで技術検証した際に直面した問題をご紹介します。
精度が出なかったAI+RAGによるボット
ChatGPTが全盛期だった数年前に、ある製造業のお客様向けに、サポートサイトの問合せ対応を生成AI＋RAGシステムで出来ないか検討しました。まずは簡単なPoCを作成する為、問合せ内容の要約と、回答内容の要約をベクトル化、ベクトル検索（類似検索）を行い、類似度が高い以前の回答内容から、回答を生成するPoCを作成しました。
結果として、十分な回答精度がでないことが分かりました。原因はいくつかありますが主に以下の様な原因でした。
- 質問、回答の両方又は一方の文章が長文になると、本来ヒットさせたい重要キーワードが他文字列に埋もれて、類似検索精度が落ちる
- 質問、問合せの両方又は一方の文書の書きっぷりによる揺れ（質問形式、体言止めなど）により、類似検索精度が落ちる
※両方ともデータの正規化不足に関連します
加えて、当時はまだ登録データの件数自体が少ない段階だったので、今後データが増えていったとき、精度がさらに落ちてしまうのではないかという懸念が拭えませんでした。
そんな折、社内のエンジニアが「登録件数が増えても精度が落ちにくい仕組み」としてグラフDBを挙げ、グラフDBに興味を持ち、このシリーズを始めるきっかけになっています。
調べてみて分かった、グラフDBの可能性
グラフDBについて、調べていくうちに気づいた点、可能性を挙げます。
改めてグラフDBについてですが、グラフDBは、「ノード（事象・モノ）」と「エッジ（関係）」でデータを表現するデータベースです。事象やモノをノードとして持ち、関係性をエッジで結ぶことで、関係性をそのままデータとして表現できます。
AIの活用の幅が広がっていく中で、ダッシュボード等の統計的な処理の見える化だけでなく、属人化したデータを組織の資産をより活かそうとする際、「関係を辿って答える」という性質を持つグラフDBは、候補として上がってくる技術だと考えています。
ここからはRDBと比較し、グラフDBの優位性がありそうな点を挙げます。
- 複雑な関係性を辿る際には、RDBでは複数のテーブル結合などの処理が必要になる一方で、グラフDBは、シンプルな指示で 最初からエッジでつながっているため、何重ものつながりでも比較的高速にたどり着けるようです。前述にも関係しますが、グラフDBなら「不具合A→原因C→対策D」という経路自体がデータとして残るため、その因果関係が正しいかを、一目で関係が確認できます。
- 次に、複数の段階をまたぐ質問への強さです。「この部品の不具合は、他のどの製品ライン・どの顧客まで影響するか」といった多段階の質問は、通常のベクトルRAGでは正答率が6割に届かないという調査結果がある一方、グラフを併用した方式では9割を超えるという報告もあります。関係性が絡む複雑な問い合わせほど、差が開くようです。
※出典: Lettria「VectorRAG vs GraphRAG: A Convincing Comparison」https://www.lettria.com/blogpost/vectorrag-vs-graphrag-a-convincing-comparison
- さらに、AIの判断プロセスを図として可視化できる点も見逃せません。品質保証やリコール判断のように、AIの判断根拠を人に説明する必要がある場面では、この「ブラックボックスでない」性質が、AI活用を組織として承認していくための前提条件になり得ると感じています。
もちろん、これらはまだ調べた範囲での話であり、実際に自分たちの手で確かめたわけではありません。
このシリーズで検証していくこと
ここまでが、グラフDBに興味を持ち、調べてみて感じていることの整理です。次回からは、実際にグラフDBを触って前述の検証をしたいと思ってます。不具合などの業務で身近なデータを題材に、ノードやエッジといった考え方について、実際に手を動かしながら確かめ、想像より簡単だった部分、意外と悩んだ部分を、書いていくつもりです。その先で、製造業の現場にどう活きそうかというアイデアにもつなげていきたいと思っています。
このシリーズは、あくまで検討の途中経過を共有するものです。同じような「つながりを辿りたい」もどかしさを抱えている方と、一緒に考えていければと思っています。
また、技術解説ではないので個人的な感想などもちりばめてますので、至らない点はご容赦ください.
南国ソフトでは、お客様のデータやAIをはじめとしたPoCのご相談を承っています。
「AIを使ってこの業務課題を解決できないか」「グラフDBやRDBなどのシステムについて聞いてみたい」という方は、お気軽にお問合せください。
