01
一件の問い合わせに、仕様書と適合表を開いて照合するのに数十分かかる
「この製品にこの部品は使えるか」に答えるため、PDFの仕様書とExcelの適合表を順番に開き、条件を照らし合わせている。
製造業の型番・仕様・適合情報を、探せる知識に変える
「この部品は、この製品に使えるか」に、根拠つきですぐ答えられますか
型番・仕様・適合・後継関係をたどって回答し、元の仕様書と該当箇所まで示す社内ナレッジ検索を作ります。文書検索で十分な質問にはそのまま答え、関係をたどらないと答えられない質問のためだけに製品・部品・型番・仕様の関係を構造化します。
まず問い合わせが集中している1製品群。実際に来ている質問で検索精度を確認し、単純な文書検索で足りるならGraphRAGは使いません。
最初の対象
1製品群
検証期間
6〜8週間
検証費用の目安
250〜450万円程度
01PAIN POINTS
こんな状態になっていませんか
この状況で相談をいただくことが多い順に挙げています
02
旧型番の後継品を聞かれ、回答が翌日になる
営業が技術部門に確認を回し、技術部門が資料を探して戻す。顧客を待たせている。
03
適合表のExcelが部門ごとに複数あり、どれが最新か分からない
問い合わせの回答がメールに散らばっていて、同じ質問に別々の担当者が別々の答えをしたことがある。
04
ベテラン担当者にしか答えられない質問が、何件あるか把握できていない
製品の歴史と例外条件を知っている人に質問が集中し、その人の退職や異動が不安になっている。
なぜ、製造業で「探せない」が起きやすいのか
情報が無いのではなく、つながっていない
型番の体系そのものが関係を持っています。製品は世代を重ねて後継品に置き換わり、部品は複数の製品に使われ、適合は製造ロットやバージョンで変わります。
一つの質問に答えるのに、三つか四つの資料をまたぐのが普通
仕様書には「ただし〜の場合を除く」という例外条件が書かれていて、その例外の判断に別の資料が要ります。関係の一つひとつが別の文書にあります。
横断をこなせる人は限られていて、その人に問い合わせが集中する
製品の歴史と例外を知っている人ほど他の仕事も抱えています。その人が退職や異動で抜けると、回答の質と速さが一気に落ちます。
普通のRAGは、関係をたどる質問に弱い
一般的なRAGは意味の近い文章を探すのが得意です。「対応部品→適用条件→後継部品」のように複数の関係をたどる質問では、文章の類似度だけでは足りない場合があります。
BEFORE / AFTER
資料を順番に開いて照合する作業を、関係をたどる検索に変える
仕様書はPDF、適合表はExcel、旧製品情報は基幹システム、例外条件はベテランの頭の中。情報は社内にあります。つながっていないだけです。
1
今の状態
一件の質問に、三つか四つの資料をまたぐ
「この製品にこの部品は使えるか」に答えるため、仕様書と適合表を開き、後継関係を基幹で確認し、例外はベテランに聞く。回答が翌日になることもある。
2
Beekleの設計
関係をたどる質問のためだけに構造化する
製品・型番・部品・後継品・適合条件・関連仕様書の関係をナレッジグラフとして持ち、文書検索で足りる部分はそのまま文書として検索する。回答には根拠の仕様書と該当箇所を必ず添える。
3
導入後
一次担当者が根拠つきで答えられる
営業が顧客の前で質問を打ち、根拠の仕様書とともに答えを得る。実際の質問で作った評価セットで精度を測り続け、仕様書の改訂は版管理で反映する。
✓
ベテランにしか答えられなかった質問が、根拠つきで一次担当者から返せるようになります。
普通のRAGだけでは難しい質問がある
FAQも文書検索も間違っていない。問題は質問が関係をたどる形をしていること
1
情報が無いわけではありません
2
一般的なRAG（検索拡張生成）は、質問に意味の近い文章を探して、それをもとに回答を作ります
3
一方で「A製品に対応する部品はどれで、その部品の適用条件は何で、その部品が廃番なら後継部品は何か」のように、複数の関係をたどる質問では、文章…
情報が無いわけではありません。つながっていないのです。
POINT 02
一般的なRAG（検索拡張生成）は、質問に意味の近い文章を探して、それをもとに回答を作ります。「ABC-100の定格電圧は」のように、答えが一つの文書の一か所に書いてある質問には強い。
POINT 03
一方で「A製品に対応する部品はどれで、その部品の適用条件は何で、その部品が廃番なら後継部品は何か」のように、複数の関係をたどる質問では、文章の類似度だけでは足りない場合があります。関係の一つひとつは別の文書に書かれていて、それらを正しい順序で結ばないと答えが出ないからです。Beekleは実案件で、実際のデータ量ではベクトル検索だけでは精度が保てない場面に当たり、グラフ構造を組み合わせた検索に切り替えた経験があります。
POINT 04
FAQやキーワード検索が悪いわけではありません。商品数が少なく、質問の型が限られているなら、FAQで十分に回答できます。問題は、質問が関係をたどる形をしていて、その関係が仕様書のPDF、適合表のExcel、基幹システム、過去の問い合わせメール、ベテランの記憶に散っている場合です。
SERVICE PACKAGE
約束 × 工程 × 成果物を、最初に明確にする
「支援します」だけでは、何を買うのか分かりません。このサービスでどこまで進め、何が手元に残るかを先に共有します。
PROMISE / 約束
文書検索で足りる質問はそのまま、関係をたどらないと答えられない質問のためだけに製品・部品・型番・仕様を構造化し、根拠の仕様書つきで答えられる状態まで作ります。
PROCESS / 工程
- 1.目的・業務ヒアリング（As-Is/To-Be）
- 2.業務を1つ選ぶ
- 3.要求・ストーリー化と受入条件
- 4.動くデモ（PoC）で確かめる
- 5.小さく本番に載せて測る
- 6.運用しながら広げる
DELIVERABLES / 成果物
- ✓問い合わせの分類（文書検索で解ける／関係をたどる）
- ✓製品・型番・部品・後継・適合条件の関係整理
- ✓根拠つきの検索・回答システム
- ✓実際の質問で作った評価セットと正答率
- ✓改訂反映・版管理・権限の運用手順
- ✓導入前後の指標の比較
SCOPE / 前提・境界
回答をそのまま顧客に自動送信する設計にはしません。担当者が根拠を確認したうえで回答する運用を前提にします。FAQで足りる規模ならGraphRAGは使いません。
どういう仕組みで実現するか
AI USE CASE DESIGN
AIで効く業務を、要件と評価基準で見極める
モデル選定より先に、どの業務をどう変え、何をもって使えると判断するかを確定します。
INPUT
業務フロー
判断基準
例外処理
評価基準
CONNECT
CONNECT
ユースケース設計
CONNECT
DELIVERABLES
✓
動く試作品
✓
社内説明できる材料
1
聞く
徹底ヒアリング
背景・業務・例外を聞き出す
2
絞る
ユースケース確定
効果が出る範囲に絞る
3
描く
設計図に落とす
構造・権限・評価基準を決める
なぜ、作る前に決めるのか
AI開発が止まるのは、モデルの選び間違いだけが理由ではありません。どの業務のどの手間を減らすか、何をもって使えると判断するかを先に決めておくと、動いたけれど本番に進めない、という止まり方を避けられます。決めた基準は、そのまま社内説明の材料になります。
02WHY BEEKLE
なぜBeekleなら、関係をたどる検索を本番で動かせるのか
GraphRAGを売る会社ではなく、要件定義から入り、本番運用まで見てきた開発会社としてお答えします。
01
要件定義から入る。AI・DXが失敗する原因の大半はモデルではなく要件のズレ
誰が、どの場面で、何を見て判断しているかが決まらないまま作り始めると、動くものはできても使われません。ヒアリングでいまの業務の流れ（As-Is）を書き出し、あるべき流れ（To-Be）との差分からアクターとユースケースを定義してから作ります。要求を洗い出して「作る・後回し・作らない」に絞り、作るものだけをユーザーストーリーと受入条件（Gherkin）に落とします。ChatGPTなどのAI検索で要件定義について尋ねたとき、Beekleの記事が最も多く引用されている領域です。
02
関係をたどる検索を、本番で運用している
カスタマーサポート向けのナレッジ検索では、実際のデータ量ではベクトル検索だけでは精度が保てない場面に当たり、メタデータ・全文・ベクトル・グラフ近傍・主張単位の5経路を統合して回答後に根拠を検証するHybrid GraphRAGに切り替え、Neo4jのナレッジグラフとともに自社のVPS上で運用しています。データの更新と削除、権限、マルチテナント、検索精度の評価、再埋め込み、顧客クラウドでの運用まで実案件で扱い、Milvusの開発元であるZillizの日本チームとも技術的な意見交換を行っています。
03
PM on Railsで、要求から動作の証拠までを一本でつなぐ
要求カード、ユースケース、ユーザーストーリー、受入条件、実装タスク、テスト結果を切れ目なくつなぐ自社開発のツールを、自社の案件だけでなく外部のお客様の案件でも使っています。「何を作ると言ったか」と「何が動いているか」が常に照合できるので、途中で要件が増えても、どこに影響するかがその場で分かります。
04
製造業のDXプロジェクトに、要件整理から約1年伴走した
要件整理から提案依頼書（RFP）の作成を代行し、そのまま要件定義・デザイン・業務整理・開発まで担当しました。型番の適合検索そのものを製造業に納めた事例はこれからで、その点は正直にお伝えします。持っているのは、製造業の業務と資料の実態を知っていることと、関係をたどる検索を本番で動かしてきた経験です。
05
動くものを先に見せる（ゼロスタート）
要件を言葉だけで固めず、ヒアリングの直後に動くプロトタイプを作って画面で確かめます。お客様のヒアリング議事録から提案依頼書を生成し、そのまま1日で動作するデモまで進めて「イメージとずれていない」と評価された案件があります。最初の動くデモは0円で作り、そこから先に進めるかを判断していただけます。
06
立ち上げと立て直しが速い。速さは要件を先に固めるから出る
大手商社の新規事業プラットフォームを1週間で動く状態にし、他社で約3か月停滞していたアプリを引き継いで3週間で完成させ、発注元が外部委託したセキュリティチェックを指摘なく一度で通過しました。別の案件では、1,100万円超が投じられて止まっていた業務システムを引き継ぎ、既存の資料とコードを確認して約3日余りで要件を再構成し、約2週間の開発サイクル終了時点で管理上の進捗を約60%まで進めています。
この流れを支えているのが、自社開発のPM on Railsです
PM on Railsとは、もともとBeekle社内で回していた開発の進め方を、AIエージェントで動くようにした仕組みです。打ち合わせで出た要望、決まった条件、作業、確認結果を1か所でつなぐため、仕様が変わってもどこに影響するかを追えます。外部のお客様の案件でも使っています。
PM on Railsの公開サイトを見る（外部提供は準備中）03CASE STUDIES
関係する実績を、事実の範囲で挙げます
この業界での納入実績と、持ち込める経験を分けて書いています
カスタマーサポートのAIナレッジ検索（Hybrid GraphRAG）
課題
問い合わせ履歴やマニュアルが大量にあるのに、キーワード検索では言い回しの違いを取りこぼし、複数文書にまたがる手順や例外対応を追えませんでした。
解決策
メタデータ・全文・ベクトル・グラフ近傍・対応根拠の複数経路を統合し、引用元を示しながら自然文の質問に答えるHybrid GraphRAGを構築しました。ナレッジグラフはNeo4jで構築し、実データを投入して自社のVPS上で運用を続けています。
成果
- 言い回しが違っても答えに届く
- 複数文書をまたぐ手順を追える
- 資料にないことは断定しない
Beekleだからできたこと
通常のベクトル検索だけでは実際のデータ量で精度とスケールに限界が出ると分かっていたため、最初から関係をたどれる構成を選びました。型番と部品の適合関係をたどる検索は、この構成の延長にあります。
技術スタック・構成
- アーキテクチャ: Hybrid GraphRAG（ベクトル＋グラフ＋全文の統合検索）
- グラフDB: Neo4j（文書・概念・手順・対応内容を関連付け）
- 検索統合: RRF（Reciprocal Rank Fusion）で複数経路のスコアを統合
- フェーズ: デモ開発（PoC）から開始し、その後に実データを投入してVPS上で運用継続中
製造業のDXプロジェクトに、要件整理から開発まで約1年伴走
課題
補助金申請の要件として提案依頼書（RFP）の提出が必要で、その前段の要件整理から手が足りていませんでした。
解決策
要件整理とRFPの作成を代行し、そのまま要件定義、デザイン、業務（BPO）の整理、バックエンド・フロントエンドの開発まで一貫して担当しました。
成果
- RFP作成から開発まで一貫
- 約1年の伴走
- 製造業の資料と業務の実態を把握
Beekleだからできたこと
型番の適合検索そのものを製造業に納めた事例はこれからで、その点は正直にお伝えします。持っているのは、製造業の業務と資料の実態を要件整理の段階から見てきた経験と、関係をたどる検索を本番で運用してきた経験です。
04SOLUTIONS
Beekleではこうする
ヒアリングとAs-Is/To-Beから入り、1業務に絞って実装し、測ってから広げます
SOLUTION 01
ヒアリングから始め、質問を「文書検索で解けるもの」と「関係をたどるもの」に分ける
最初に確認するのはAIモデルではなく、実際の問い合わせです。担当者に一件の質問に答える手順をそのままたどってもらい、どの資料をどの順に開き、何と何を照合し、どこで迷うかを現状として書き出します。そのうえで「営業が顧客の前でこの質問を打ち、根拠の仕様書とともに3分以内に答えを得る」というあるべき場面をユースケースとして定義し、構造化する範囲をそこから逆算して決めます。
構造化の範囲が最小になる
実際の質問で精度を測れる
ベテランの手順が残る
SOLUTION 02
必要な部分だけ構造化し、回答には必ず根拠を残す
関係をたどる質問のために、製品、型番、部品、後継品、適合条件、関連仕様書の関係を整理し、ナレッジグラフとして持ちます。全部の情報をグラフにはせず、文書検索で足りる部分はそのまま文書として検索します。「使えます」「後継品はXYZ-200です」という回答文だけを返す設計にはせず、どの仕様書のどの箇所を根拠にしたか、どの適合条件を確認したかを一緒に表示します。
既存の適合表Excelを入力元に使える
担当者が根拠を見て確認できる
社外回答の前提が守られる
SOLUTION 03
更新方法と評価データを最初から設計する
仕様書の改訂、後継品の追加、適合表の更新があったとき、検索側にどう反映するかを最初に決めます。古い版と新しい版が同時に検索対象に残らないようにする版管理、部門や取引先による閲覧権限もこの段階で入れます。実際に来た質問と担当者が確認した正答のペアを数十件作り、検索の精度をこの評価セットで測り続けます。
半年後に古い仕様を答えない
精度の改善を感覚でなく数字で判断
権限設計が後付けにならない
05FEATURES
このサービスで引き受ける範囲
ヒアリングから、動く仕組みと運用まで
問い合わせのヒアリングと分類
過去の問い合わせを集めて質問の型を分類し、文書検索で解けるものと関係をたどらないと解けないものの比率を出します。
製品・型番・部品・適合条件の構造化
既存の適合表Excelや品目マスタを入力元に、関係をたどる質問に必要な部分だけをナレッジグラフにします。
根拠つきの検索と回答
回答とともに、根拠の仕様書と該当箇所、確認した適合条件を表示します。担当者が確認したうえで社外に回答する運用が前提です。
改訂反映・版管理・権限・評価セット
仕様書改訂の反映手順、旧版の排除、部門・取引先別の閲覧権限、実際の質問で作った評価セットによる継続測定。
何を測るか
回答精度だけでなく、実際の業務時間が減っているかを確認する
1
1件の問い合わせ回答にかかる時間
2
ベテランへのエスカレーション件数
3
回答後の修正件数
導入前に現状値を取り、導入後に同じ定義で測ります。
01
1件の問い合わせ回答にかかる時間
資料を開いて照合する時間が短くなるか。
02
ベテランへのエスカレーション件数
一次担当者で完結する比率。
03
回答後の修正件数
誤回答が減るか。
04
評価セットでの正答率
実際の質問数十件に対する検索精度。導入後も継続して測ります。
向いている会社、向いていない会社
先に線を引いておきます
1
向いている会社
2
向いていない会社
製品・部品の点数が多く、型番に世代や後継関係があり、適合条件の問い合わせが日常的に来る会社に向いています。
01
向いている会社
製品・部品の点数が多く、型番に世代や後継関係がある。型番や後継品、適合条件の問い合わせが日常的に来る。適合条件が製品バージョンやロットで変わる。ベテラン担当者に質問が集中していて、退職や異動が不安。仕様書や適合表がPDFやExcelで社内に存在している。
02
向いていない会社
商品数が少なく、FAQだけで十分に回答できている（GraphRAGまで作る必要はありません）。仕様や適合の情報が文書として存在せず、すべて個人の記憶にしかない（先に文書化から始めることをお勧めします）。検索の回答をそのまま顧客に自動送信したい（根拠を人が確認する運用を前提にしています）。
費用・期間の考え方
モデルケースと、段階ごとの目安
1
業務整理・初期設計（1〜2週間）
2
1業務の検証・実装（4〜8週間、150〜400万円程度）
3
高難度PoC（6〜12週間、300〜600万円程度）
費用は「業務整理」「1業務の検証・実装」「本番展開」「継続改善」の段階に分けて見積もります。投資判断は「削減できる時間×人件費 −（導入費＋運用費）」がプラスに転じる回収期間で見ます。他社の削減率を当てはめるのではなく、動くデモの段階で御社の業務にどれだけ効くかを確かめてから、本番展開の投資を判断していただきます。
POINT 02
モデルケース: 1製品群の型番・部品・仕様書を検索できるようにする（6〜8週間、250〜450万円程度）。製品数が多く、問い合わせ担当者が仕様書、Excelの適合表、旧製品資料を横断して回答している会社を想定します。最初は全製品を対象にせず、一つの製品群について製品、型番、部品、後継品、適合条件、関連仕様書を整理します。そのうえで「この製品にこの部品は使えるか」「旧型番Aの後継品は何か」「この条件ではどの仕様が適用されるか」という、実際に現場で発生している質問を使って検索精度を確認します。単純な文書検索で十分なら、無理にGraphRAGは使いません。費用に影響するのはデータ量より、情報同士の関係の複雑さです
POINT 03
製品群の追加、基幹システム連携、権限、履歴、問い合わせ画面を加えた本番展開の目安は600〜1,200万円程度です。
POINT 04
別料金になるもの: 御社クラウドやオンプレへの構築費とクラウド利用料、LLMのAPI利用料（月額の従量）、紙資料の電子化やOCR、正本が決まっていない資料の整理作業、APIの無い既存システムとの連携開発、導入後の保守と精度改善（月額）。
POINT 05
上記は、Beekleの過去の開発案件をもとにしたモデルケースです。実際の費用と期間は、対象業務、利用するデータ、既存システムとの連携、精度要件、権限・セキュリティ要件によって変わります。最初から全社導入するのではなく、投資対効果を確認しやすい一業務から始めることを基本としています。
01
業務整理・初期設計（1〜2週間）
実データと業務を確認し、改善対象を決めます。費用は案件内で設計します。
02
1業務の検証・実装（4〜8週間、150〜400万円程度）
一つの業務を実際に動かします。
03
高難度PoC（6〜12週間、300〜600万円程度）
GraphRAG、複雑なデータ、評価設計などが要る場合。
04
本番展開（2〜6か月程度、500〜1,500万円以上）
権限、連携、監視、運用まで含めます。
05
継続改善（月単位、個別見積もり）
評価結果から改善と拡張を続けます。
発注の流れ
相談から本番運用まで、どう進めるか
AI開発は、作る前にどれだけ業務を理解し、ユースケースと評価基準を固められるかで決まります。Beekleはヒアリングから入り、設計した範囲だけを小さく検証して本番化します。
- 1
STEP 1
ヒアリングでユースケースを確定する
現場の作業、判断基準、例外処理、使っているデータを聞き出します。「AIで何か」ではなく、どの業務をどう変えるかまで絞り込みます。
- 2
STEP 2
知識構造・権限・評価基準を設計する
RAGなら文書同士の関係や根拠提示、エージェントなら任せる範囲・承認・ログを設計します。評価データと合格基準も先に決めます。
- 3
STEP 3
設計したユースケースをPoCで検証する
いきなり大きく作らず、決めたユースケースだけを動く形にします。現場で使えるか、削減時間・精度・確認工数・運用負荷を見ながら検証します。
- 4
STEP 4
効果が見込めれば実導入
PoCで効果が確認できたら本番化し、現場で使われる状態まで伴走します。期待した効果が見込めなければ、ここで撤退も判断できます。PoC止まりや過剰投資を避けられるのが、この進め方の狙いです。
✓
技術検証で終わらせず、業務で使える設計に落とす。ここがBeekleの強みです。
06RELATED COLUMNS
もっと詳しく知りたい方へ
このサービスの背景にあるデータ活用の考え方
07FAQ
発注前によくある質問
発注前に確認されやすい論点をまとめています
Q 仕様書がPDFで、適合表がExcelです。このままで始められますか？ +
始められます。PDFは文書検索の対象に、Excelの適合表は関係を構造化する入力元として使います。整理されていない状態そのものが課題なので、業務整理の段階でどの資料が正なのかを一緒に確認します。
Q GraphRAGやナレッジグラフは必須ですか？ +
必須ではありません。文書検索で答えられる質問にはそのまま答えます。関係をたどらないと答えられない質問の比率が高い場合にだけ、その部分を構造化します。業務整理で質問を分類してから決めます。
Q 回答が間違っていたら、誰が責任を持ちますか？ +
検索結果には根拠の仕様書と該当箇所を必ず表示し、担当者が確認したうえで社外に回答する運用を前提にしています。AIの回答をそのまま顧客に送る設計にはしません。あわせて、実際の質問で作った評価セットで正答率を継続的に測ります。
Q 仕様書が改訂されたら、検索にどう反映されますか？ +
改訂の反映手順と版管理を最初の設計に含めます。古い版と新しい版が同時に検索対象に残らないようにし、いつ差し替わったかを追えるようにします。
Q 基幹システムの品目マスタと連携できますか？ +
できます。APIがあればAPI経由で、無い場合はエクスポートやデータベース参照などの方法を確認して設計します。検証段階では連携を最小にし、本番展開で本格的につなぐことが多いです。
Q 社外の取引先にも使わせたいのですが。 +
可能ですが、取引先ごとに見せられる情報が違うため、権限設計が本番展開の中心になります。まず社内利用で精度と運用を固めてから、取引先向けを検討することをお勧めします。
問い合わせの前に
普段のAIへ、合うか聞いてみてください
営業資料だけでは、自社に合うか判断しにくいことがあります。社内の制約や今の状況を知っているAIに聞くと、合う理由と合わない理由が先に見えます。
いま来ている問い合わせを、まず分類してみませんか
過去数か月の問い合わせをお預かりできれば、文書検索で解けるものと、関係をたどらないと解けないものの比率をお伝えします。そこから最初に対象にする製品群と概算をご提案します。