本ブログは 株式会社JAPANNEXT 様、 クラスメソッド株式会社 、Amazon Web Services Japan 合同会社が三社共同で執筆いたしました。 みなさん、こんにちは。ソリューションアーキテクトの田中里絵です。 AI を活用して日常業務を効率化していきたい、と多くのお客様からお聞きします。一方で、AI ツールを導入するだけではなかなかうまくいかず、これまで馴染んできた業務プロセスと AI ツールをいかに統合させていくのかに悩んでいる、というお声もいただきます。 本記事では、JAPANNEXT 様が Amazon Connect Customer と Amazon Bedrock を活用し、二つの部門で電話対応業務を刷新した事例を紹介します。ツールを導入するだけでなく、現場でどう使われるか、将来の IT 基盤にどう繋げるかを、お客様、パートナー、AWS の三社でワクワクしながら議論して仕組みづくりをしました。ぜひ楽しんでお読みください。 株式会社 JAPANNEXT について JAPANNEXT 様は、千葉県いすみ市に本社を置く液晶ディスプレイ（液晶モニター）メーカーです。2016 年に JAPANNEXT ブランドのモニターを発売し、ブランド 10 周年を迎えられました。大型ディスプレイ、4K ディスプレイ、ゲーミングモニター、モバイルモニターなど多様なラインナップの製品を提供されていて、良いものを最高のコストパフォーマンスで届けるという考え方が製品づくりの軸になっています。年間 150 を超える新製品を発売するスピーディーなビジネスが強みです。 事業拠点は、統合により廃校となったいすみ市の小学校を利活用した本社です。このユニークな本社に加え、いすみ鉄道の菜の花保全活動への協賛や、リファビッシュ品（再生品）をふるさと納税の返礼品として提供する取り組みなど、テクノロジーと地域活性化の両輪で事業を展開されています。 写真：本社エントランス（左）、学校の雰囲気が残る社屋内 – 想いをつないで （中央）、リフレッシュルーム – ON／OFF 両方全力で（右） JAPANNEXT 様が直面していた課題と背景 多様な製品ラインナップを持つ JAPANNEXT 様には、購入前の製品選定のご相談から設置方法、保証や修理まで、多様な問い合わせが寄せられます。従来、1 日あたり平均 80 件の営業問い合わせを、5 名の営業アシスタント様が固定電話を介して受けていました。担当者の不在でお客様をお待たせしたり、適切な担当者へのルーティングに時間がかかったりするため、問い合わせがつながるまでに数分を要していました。また、伝言やチーム内での情報連携は属人的に行われていたため、誰が、いつ、どんな問い合わせを受けているのかをチームとして把握しきれないという課題もありました。 購入後のお問い合わせを受けるカスタマーサポートでも、情報連携に関する課題を抱えていました。エージェントは受電後にお客様対応を行い、内容を記録して CRM に入力しますが、これに 1 件あたり 15 分を要し、記録の粒度も担当者によりまちまちでした。このために問い合わせ内容がデータとして蓄積されづらく、対応の振り返りや傾向の把握が進みづらい状況にありました。重要度の高いお問い合わせをスーパーバイザーに即時連携したい場面でも、通話終了後に記録・共有する業務フローでは 10 分程度のタイムラグが避けられませんでした。 これらの課題を解決するため、既存 PBX システムの更改は 2024 年ごろから検討に挙がっていました。しかしながら、着信時に発信元のお客様情報が CRM の画面に自動で表示される連携機能を日常的に利用しており、次期システムでも同等の体験を実現できるかが重要な要件となり、技術選定を難しくしていました。さらに、既存 CRM の更改も考慮する必要があり、相互に連携するシステムをどう入れ替えていくかの整理も必要な状況でした。 ソリューション選定の経緯 技術選定の中心に据えたのは、2 つの方針です。1 つは、クラウド型のコンタクトセンターを採用し、物理的な電話デバイスから PC 上のソフトウェアを介した受電へ切り替えること。もう 1 つは、対応内容の記録と連携に、AI による文字起こしを活用することです。 この方針のもとで選定したのが、クラウド型のコンタクトセンターサービスである Amazon Connect Customer でした。オンプレミスの PBX 基盤や固定電話を必要とせず、問い合わせを自動でルーティングし効率的に対応を振り分けられること、通話の文字起こしや感情分析といった AI 通話分析機能（Amazon Connect Customer Contact Lens）をフルマネージドで使えること、そして従量課金により低価格でスタートできることが、選定のポイントとなりました。 選定の過程で重要な論点になったのが、課題の段でも触れた CRM との連携です。お客様の中でも議論を重ね、ユーザーからみて従来と同等以上の体験が得られると確認できたことで、最終的には CRM 自体の更改も同時に進めることを決断されました。 AWS パートナーとの協業 Amazon Connect Customer、Amazon Bedrock、新 CRM との導入支援と連携を総合的にお願いできる導入パートナーとして、AWS プレミアティアサービスパートナーであるクラスメソッドとの協業を決定し、AWS サービスの設計とともに CRM 更改も含めたプロジェクト計画を進めていきました。 本プロジェクトの技術リードの大野様は次のように述べています。 「AWS の知見、AI に対する知見、細かな要件のすり合わせに加え、CRM の更改も見据えた支援をしてくれるという点が非常に大きなポイントでした。」 ソリューションの構成 営業支援のユースケースでは、Amazon Bedrock が要約機能を担いました。Amazon Connect Customer の文字起こしと Amazon Bedrock によるカスタマイズされた要約を組み合わせて、AWS Lambda で担当者が日常的に使っているチャットツールへ連携し、イベントドリブンアーキテクチャによって終話後数分で届きます。必須の要件として残ったお客様情報の表示は、CRM から Amazon Connect に定期連携するロジックを追加で作成しました。 この構成の設計を主導したクラスメソッド様は、設計の狙いを次のように語っています。 「本プロジェクトで最も重視したのは、『CRM が変わっても、継続活用できる設計にする』という点でした。Amazon Connect Customer との連携を疎結合に設計することで、CRM に依存しない柔軟な環境を実現しています。 通話要約のモデルは、精度と運用面を総合的に考慮して Claude を提案しました。大野様が日常的に活用され、JAPANNEXT 様の社内指針でも推奨されていたことが重なり、現場に最も馴染みやすい選択になったと感じています。 また、オペレーターの役割と状況を丁寧にヒアリングし、ルーティングプロファイルを部門ごとに分離することを提案しました。営業時間外の対応についても、カレンダー管理や追加手順を共有することで、お客様が自走して運用を続けられる体制を整えました。」 図：営業部門で利用する新システムのアーキテクチャー概要 導入の成果 先行して運用を開始した営業部門では、初日から前向きなフィードバックが得られました。具体的には、次のような効果が生まれています。 1 日の電話対応件数が 15 % 増加 担当者への電話引き継ぎに要していた時間が、自動ルーティング機能によりゼロに 不在着信や業務時間外の着信も可視化され、引き継ぎ漏れがゼロに 1 件あたりの対応時間短縮の結果、担当者の残業時間が 15 % 削減 数字に表れない変化もあります。対応そのものに集中できるようになり、通話しながらの情報検索や応対品質の振り返りも可能になったことで、単なる問い合わせへの受け答えにとどまらず、情報収集や分析など顧客体験を高める取り組みに時間を割く余裕が生まれています。 プロジェクトを推進された大野様は、SE の視点から効果をこう分析されています。 「Amazon Connect Customer を導入してから、記録に追われなくなったことで、電話対応とエスカレーション判断を、担当者がいずれも落ち着いて対応できるようになりました。就業時間に目途が付きやすくなり、働きやすさも向上したとフィードバックを得られています。また、物理的な電話が撤廃されたことで、執務室の静音化という副次効果もありました」 リーダー業務には、問い合わせ対応に加え外部との調整作業がありますが、導入後はこの業務にも変化が生まれました。主運用部門担当の高野様、植村様およびチームリーダー押尾様からは、次のような声が寄せられています。 「電話のピーク対応処理が従来の80件程度から100件／日可能になり、加えて受話できなかった問い合わせもガイドによりメール問い合わせ担当へ振り替わるため、業務量が平準化されました。これにより担当者がリーダーのサポートも出来るようになりました。またチームリーダーは本業務と問い合わせ対応のサポートも並行作業で可能となりました。今までは不可能か、とても難しかったことです。」 また、営業部門での成果を受け、フェーズ 2 としてカスタマーサポート部門への展開を進めました。開発段階から現場担当者を交えてクラスメソッド様と要件定義を重ね、標準的な機能を中心に活用してカスタマイズを最小限にするために、運用側の見直しも含めた機能の選定や社内調整を積み重ねました。 この要件定義に参加したコーチングリーダーの本良様は、その経験を次のように語っています。 「現場の意見を取りまとめ、クラスメソッド様のエンジニアと密に会話を重ねることで、要望がかたちになっていきました。ユーザーとシステム、両方の立場や悩みを経験できたことも大きな収穫です。この仕組みは、カスタマーサポートとシステム部門がワンチームで築き上げたものです。」 写真：プロジェクトにご尽力された高野様（写真左）、本良様（写真右） お客様の声と今後のお取り組み 一連の取り組みについて、伊丹様、剣持様、大野様から、それぞれ次のような声をいただいています。 伊丹様「単に業務効率が向上しただけではなく、問い合わせ内容が漏れなく記録されることで、今後の営業活動の分析やさらなる向上が見込めるようになりました。これから本格化するカスタマーサポートへの展開にも、大いに期待しています。」 剣持様「JAPANNEXT では、毎年 150～200 機種の新商品を発売し、市場に無いものでもチャレンジして製品開発、発売を行っています。それを支える社内システムは自社開発が基本姿勢ですが、クラスメソッド様、Amazon Web Services Japan 様との連携で新しい仕組みをスピーディーに構築することが出来ました。あわせてカスタマーサポートも刷新し、これまで担当者ごとに散在していた顧客との接点が、営業組織全体で共有できる情報基盤になりました。今後はこの基盤を活かし、外部の有識者の知見も取り入れながら、新たな顧客開拓につなげていきます。」 大野様「本共創の立ち上げを経験したことで、JAPANNEXT 社内全体で『新しい考え方がないか？』といったことを考える雰囲気が醸成され始めました。単に効率改善のためだけのプロジェクトに留まらず、仕組みづくりに様々なステークホルダーを交えて取り組めたことが最大の成果でした。」 クラスメソッド様からは、次のようなフィードバックをいただいています。 「単なるツールの入れ替えではなく、業務課題そのものに向き合いながら仕組みを作り上げられた点が良かったと考えております。電話対応の現場で何が起きているかを丁寧にヒアリングし、ツールと業務プロセスを一緒に設計することで、担当者が『記録に追われる仕事』から解放される仕組みが生まれました。今後も JAPANNEXT 様の業務改善に継続的に伴走していきます。」 今後 JAPANNEXT 様は、RMA（返品や交換）の一連の作業を担うチームにも、Amazon Connect Customer の利用を広げていく想定です。また、本プロジェクトで導入された CRM のさらなる活用や、クラウドに蓄積され始めたデータをビジネスに活用を目指して継続的にお取り組みをしていくご想定です。 まとめ 本事例では、業務の目的に立ち返って、機能と運用の両面から設計を重ねたことが、初日から現場に定着する仕組みにつながりました。AI 活用を検討される際は、ツールの選定とあわせて、現場の運用にどう溶け込ませるかの議論に、ぜひ時間をかけてみてください。AWS へのご相談もお待ちしています。 コンタクトセンターの業務刷新や AI 活用に興味を持たれた方は、 Amazon Connect Customer の製品ページ や、 Amazon Bedrock の製品ページ をご覧ください。 株式会社JAPANNEXT : General Manager 伊丹 利政 氏（写真中央左）、Senior System Engineer 大野 浩司 氏（写真中央右）、Head of Sales & Marketing 剣持 開 氏（写真右から2番目） クラスメソッド株式会社 : 営業 平田 梨紗（写真右） Amazon Web Services Japan : アカウントマネージャー 倉知 達哉（写真左）、ソリューションアーキテクト 田中 里絵（写真左から2番目） ソリューションアーキテクト　田中里絵

G-gen の奥田です。当記事は、Google Cloud Next 26 Tokyo の1日目に行われたカスタマーセッション「 CDP だけで顧客理解は不十分？Google Cloud と生活者データで実現する「Why 分析」最前線 」のレポートです。 他の Google Cloud Next Tokyo 26 の関連記事は Google Cloud Next Tokyo 26 カテゴリ の記事一覧からご覧いただけます。 セッションの概要 データはあるのに顧客が見えない データの量ではなく種類が足りない 再発する 5 つの症状 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 勘と経験がもつ 3 つの限界 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは ID 突合ではなく確率的な意味マッチング 処理の 4 ステップ 既存テーブルを変更せずに列が増える Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH 発見 2: Gemini による出力品質の独立検査 発見 3: 承認済みルーティンによる双方の資産保護 Why 分析の先にあるもの AI の均質化とブランドらしさ 業種を越えた共通フレームワークへ 関連記事 セッションの概要 当セッションでは、株式会社博報堂による発表が行われました。CDP（Customer Data Platform、顧客データを個人単位で統合管理する基盤）だけでは捉えられない「顧客が行動した理由（Why）」を、生活者データと BigQuery の機能を組み合わせて補完する手法が紹介されました。 セッションは以下の 5 章で構成されていました。 データはあるのに顧客が見えない Why を補ってきた「勘と経験」の正体 生活者データという「Why の辞書」と Why 分析の方法 Google Cloud だから実現できた 3 つの発見 Why 分析の先にあるもの 当記事では BigQuery の基礎的な説明は割愛します。BigQuery そのものについては、以下の記事を参照してください。 blog.g-gen.co.jp データはあるのに顧客が見えない データの量ではなく種類が足りない セッション前半では、多くの企業が直面する課題として「データ量は十分にあるが、データの種類が足りていない」という点が提示されました。 CDP に記録されるのは、会員属性、購買履歴、行動ログ、解約記録といった「What（結果）」のデータです。一方、価値観、生活文脈、意思決定の傾向、不安や願望といった「Why（原因）」は、CDP のどこにも記録されません。登壇者はこれを氷山にたとえ、水面上に見えるのが What、水面下に隠れているのが Why であると説明しました。 たとえば「妥協して選んだ」という本音は、購買履歴という結果データからは読み取れません。同じ商品を買った顧客でも、買った理由は三者三様です。 再発する 5 つの症状 この構造的な欠落が原因となり、データを精緻化しても再発する症状として、以下の 5 つが挙げられました。 セグメントの画一化 メッセージの一律化 LTV（Life Time Value、顧客生涯価値）向上の頭打ち 静かな離反の見落とし 新規獲得の非効率 登壇者は、CDP や CRM（Customer Relationship Management、顧客関係管理システム）の整備自体は不可欠な土台であり、ID 統合、行動ログの蓄積、施策の自動化という期待された役割は果たしていると強調しました。問題は、CDP だけではカバーできない領域（なぜ買ったのか、なぜ離れたのか、なぜ選んだのか）が存在することです。 Why を補ってきた「勘と経験」の正体 5W1H を同時に読む力 これまで Why の欠落を埋めてきたのは、マーケターの「勘と経験」でした。セッションでは、その正体は「5W1H を同時に読む力」であると定義されました。 ベテランマーケターは、Who（どんな生活状況か）、When（いま何が起きそうか）、Where（どこで接点を持つか）、Why（なぜその選択か）、How（どう情報収集し選ぶか）を、過去事例の蓄積による暗黙のパターンマッチで同時に推論しています。たとえば「40 代男性が SUV を購入した」という購買データから、「家族の安全を重視する層である」と言い当てる、といった推論です。 勘と経験がもつ 3 つの限界 一方で、この勘と経験には 3 つの構造的な限界があると指摘されました。 スケールしない: 顧客一人ひとりに勘と経験を働かせるのは物理的に不可能 引き継げない: ベテランの退職は「顧客理解資産」の消失を意味する 共有できない: 「なんとなく刺さる」という判断では合意形成が属人的になる 生活者データという「Why の辞書」と Why 分析の方法 Why の辞書とは この課題に対する解決策として、博報堂が保有する生活者データを「Why の辞書」として使用し、マーケターの脳内プロセスを機械化する手法が紹介されました。材料となるのは、圧倒的な量の Why の語彙と、生活者インサイト（購買行動の背後にある価値観や動機）を推論する技術の 2 つです。 博報堂独自の観点として、価値観、動機、幸福感といった軸（たとえば購入時の価値観として、価格、幸せ、機能性など）が生活者データの中で 5W1H により体系化されています。 ID 突合ではなく確率的な意味マッチング 特徴的なのは、顧客データと生活者データを ID 突合（異なるデータベース間で共通の ID をキーにレコードを結合すること）ではなく「確率的な意味マッチング」で接続する点です。これにより以下の 3 点が実現されます。 個人を特定しない 既存の CDP をそのまま使用できる Cookie 規制（サードパーティ Cookie によるトラッキングの制限）の影響を受けにくい 処理の 4 ステップ 処理は以下の 4 ステップで構成されます。 翻訳: 企業ごとに異なる顧客 CDP の項目を、生活者データの共通言語にマッピングする 数値化: 顧客データと生活者データを「意味の座標」上に配置し、意味の近さを距離として比較できるようにする 検索: 生活者データの中から、意味的に最も近い人を選ぶ 特徴付与: 生活者データに近い特徴を顧客データにも付与する 既存テーブルを変更せずに列が増える この手法の利点は、既存の顧客テーブルを変更する必要がないことです。顧客 ID、属性、購買金額といった従来の列はそのままに、以下のような生活者インサイトの列が追加されます。 価値観（なぜ買うのか。指名買い、コスパ重視など） 意思決定傾向（どう選ぶのか。SNS 影響、即決型など） ライフスタイル（どう生きるのか。都市型ライフ、子育て重視など） 既存の顧客データ基盤が、そのまま顧客理解基盤へ進化するという表現が用いられました。 Google Cloud だから実現できた 3 つの発見 Google Cloud を選定した理由 博報堂独自の生活者データを AI 時代に使用するには 3 つの条件が必要であり、Google Cloud はそのすべてを満たすと説明されました。 意味の近さを計算できる BigQuery が標準機能としてベクトル検索（テキストなどを数値ベクトルに変換し、意味の近さで検索する仕組み）を備えています。 マーケターが直接触れる SQL やダッシュボードで完結し、ノーコードまたはローコードで操作できるため、マーケター自身が仮説をすぐ検証できます。 データを動かさない 顧客データは企業環境から一切出さず、顧客環境内で処理が完結します。 実運用から得られた発見 発見 1: 直感を再現する VECTOR_SEARCH セッション後半では、実運用から得られた発見として次の3点が紹介されました。1 つ目は、マーケターの直感を SQL で再現できたことです。「この人は、こんな価値観の人と似ているな」というベテランマーケターの頭の中の処理は、これまで言語化も再現もできない暗黙知でした。この処理を、BigQuery の標準機能である VECTOR_SEARCH 関数への変換（SQL Translation）によって再現しています。 これにより「意味の近さ」が可視化され、感覚でしかなかった判断を数字として表現できるようになりました。 参考 : ベクトル検索の概要 発見 2: Gemini による出力品質の独立検査 2 つ目は、出力品質を Gemini で独立検査する仕組みです。付与されたインサイトが施策の判断材料になる以上、品質に責任を持つ必要があります。人間による品質検査には量的な限界があるため、Gemini による5観点の独立評価を、品質保証レイヤーとして組み込んでいます。これは LLM ジャッジ（Large Language Model による評価）と呼ばれる、大規模言語モデルに出力の良し悪しを判定させる手法です。5 観点は以下のとおりです。 一貫性: 矛盾するタグがないか 妥当性: その人らしいか 網羅性: 必要な観点があるか 不足検出: タグの抜けはないか 実用性: マーケティング施策に使えるか 発見 3: 承認済みルーティンによる双方の資産保護 3 つ目は、データを守りながらロジックも守る仕組みです。顧客データは企業環境から一切出さない一方で、博報堂の推論ロジックも公開しません。この双方の資産保護を、BigQuery の承認済みルーティン（Authorized Routine）で実現しています。承認済みルーティンは、呼び出し元に定義内容を開示せず、実行権限のみを付与できる機能です。 参考 : 承認済みルーティン Why 分析の先にあるもの AI の均質化とブランドらしさ 最終章では、AI エージェントが購買の意思決定を担う時代の展望が語られました。購買が AI エージェント経由になるほど、効率最適化により「どのブランドも同じ答え」に収束するリスク（AI の均質化）があります。 エージェントが最適解を出す時代では、生活者の「なぜ（Why）」への深い理解こそがブランドらしさの源泉であり、ブランドに求められるのは最適化ではなく「選ばれる理由」を持ち続けることである、と締めくくられました。 業種を越えた共通フレームワークへ また、この設計様式は博報堂だけの話ではない、という点も強調されました。ID 突合に依存しないポストクッキー時代（サードパーティ Cookie が使えなくなる時代）のマーケティング手法として、また「データを動かさず、処理を動かす」という厳格なデータガバナンス下で AI 利用を進めるための共通フレームワークとして、規制業界を含むデータを持つすべての企業に波及していくという展望が示されました。対象業種の例として、小売、金融、通信、旅行、メディアが挙げられました。 関連記事 blog.g-gen.co.jp 奥田 梨紗 (記事一覧) クラウドソリューション部データインテリジェンス課 Google Cloudの可能性に惹かれ、2024年4月G-genにジョイン。 Google Cloud Partner Top Engineer 2025&2026 Follow @risa_hochiminh

はじめに 本記事は、2026年3月10日に開催された Elastic{ON} Tokyo での発表「 『定型』を許さない製造業データへの挑戦 」の内容をもとにした連載の第2回です。 第1回：ビジュアル情報を活かす 第2回（本記事）：分断されたデータを繋ぐ 第3回：止めずに進化させる 前回は、製造業の検索に「ビジュアル」が外せないこと、Elasticsearch の kNN 検索を使った類似図面検索について書きました。 今回は、次に立ちはだかる「データ規模と結合」の壁について掘り下げます。複数のデータソースを横断した検索を、どうやって高速に実現しているかという話です。 「探索」に必要なデータ横断 前回も触れた通り、私たちが実現したいのは「探索」です。たとえば調達部門が「より良い発注」を目指す場合、こういうプロセスを一気通貫で回したい。 発注予定の図面に対して、視覚的に似た過去の図面を検索する 見つかった図面に紐づく発注実績をシステム横断で確認する 集まった情報をもとに今回の発注額を適正化する この②「システム横断での実績確認」が、技術的にはかなり重い問題を含んでいます。 製造業データの「分断」 製造業の現場には、PLM、EDI、SCM、CRM といった業務ドメインごとのシステムが並んでいます。それぞれの業務には最適化されていますが、システム間でデータが分断されているのが常です。 この分断を解決するために ERP が導入されてきました。ただ、ERP はあくまで組織の「管理」が目的のシステムです。前回書いた「ビジュアルな情報をビジュアルなまま扱う」という発想にはなっていないので、ERP に実績データが集まっても、現場が判断の拠り所にする「モノの形」とは切り離されたまま。分断は形を変えて残り続けます。 CADDi Drawer は、こうしたバラバラのデータソースを統合し、一つの画面から横断的に探索できるようにするプロダクトです。 データ規模と「結合」の壁 日本の製造業は数十年、時には100年を超える歴史があり、蓄積されたデータは膨大です。図面だけで100万枚以上、受発注実績は1,000万レコード以上。仕様書やトラブル記録などの非定型な文書も含めるとさらに増えます。 これらを統合して扱うとき、RDB のようにテーブルを繋ぎ合わせる素朴な結合をやると、組み合わせは10兆件規模に達します。インデックスがなければ全件走査になるので、対話的な速度は到底出ません。 では、図面と実績をデータ種別ごとに別のインデックスに入れればいいかというと、それだけでは不十分です。片方のインデックスで検索した結果をもう片方と突き合わせる必要があり、突き合わせ側はインデックスが効かず全件走査に落ちるケースが出てきます。クエリの絞り込みが弱い場合や結合キーの値の種類が少なく多対多の組み合わせが膨らむ場合、この突き合わせのコストが支配的になって応答速度が崩れます。 この10兆通りの組み合わせを、検索エンジンが得意な形にどう落とし込むか。ここがアーキテクチャ上の大きな問題でした。 複数インデックス構造による解決 私たちがとったのは、複数のデータソースを統合したうえで、用途別のインデックス群を構築するアプローチです。 万能なインデックスは作れない 私たちも最初は「すべての要件を満たすインデックスをどう設計するか」と考えていましたが、うまくいきませんでした。 データソースごとにインデックスを分けると、前述の通りクエリ時の突き合わせで全件走査が走って遅いという課題があります。その一方で非正規化して複合インデックスにまとめれば検索は速くなりますが、あるデータソースの1レコードを変えただけで紐づく全ドキュメントに波及して大量更新が走る。検索を速くすると更新が重くなるし、その逆もまた然りで、一つのインデックスでは両立しません。 なので発想を変えて、万能なインデックスを作ろうとするのをやめました。代わりに要件を分解して、用途ごとに別のインデックスを持たせています。例えば、データソースごとにオンライン更新が走るインデックスと、データ鮮度には多少の遅延があるもののデータソースを横断して検索できるインデックスを分けて持つ、といった具合です。 動的なインデックス選択 ここで鍵になるのが、クエリ実行時の制御層です。ユーザーから投げられたクエリの内容をシステムが解析し、そのとき最も効率的なインデックスを自動で選択します。 単一データソース内の検索ならそのデータソースのインデックスを使い、複数データソースにまたがる検索なら横断用のインデックスを使う。こうした切り替えが裏側で動いています。 ユーザーから見ると、データがどこにあるか、どのインデックスが使われているかは一切見えません。透過的な検索体験を維持したまま、裏では用途に応じた最適化が走っている、という構成です。 類似検索 × フィルタリングの両立 データソース横断検索の難しさは、「類似検索」と「フィルタリング」を組み合わせたときに顕著になります。 そして現場では、この掛け合わせがないと使い物になりません。「この図面に似た形のもの」を探すだけでなく、「その中で、今取引のある会社に発注したことがあるものだけ」に瞬時に絞り込めなければ、実際の比較検討には使えないからです。 なぜ難しいのか 類似検索（kNN）はベクトル空間上の距離計算、フィルタリングは転置インデックスによる構造化データの絞り込みで、それぞれ背後のデータ構造もアルゴリズムも違います。素朴に組み合わせると、どちらかの速度が犠牲になります。 さらに、フィルタリング対象のデータが別のデータソースに由来する場合（発注実績は ERP、図面はファイルサーバーなど）、結合処理のコストも乗ってきます。 どう解決したか kNN 検索とフィルター条件を同一クエリ内で組み合わせることで、ベクトル検索の結果に対して構造化データの絞り込みをかけています。 加えて、前述の横断検索用インデックスで図面と実績の関連を事前に非正規化しているため、検索時のデータソース間結合は発生しません。 Elasticsearch が kNN とフィルタを同一クエリ内で同時実行できることと、事前結合による非正規化インデックスの組み合わせで、類似検索とデータソース横断のフィルタリングをサブセカンドで安定して返せるようになりました。 アーキテクチャの全体像 データが取り込まれてからユーザーに届くまでの流れを整理します。 PLM、ERP、ファイルサーバーなど複数のデータソースからデータを収集する AI による図面解析、メタデータの抽出、ベクトル化などの処理を行う 用途別のインデックスにデータを振り分ける ユーザーのクエリを解析し、最適なインデックスを動的に選択する サブセカンドで結果を返し、ファセットやハイライトとともに表示する 図面と実績は更新頻度も構造も違うデータですが、探索に最適な形に統合・変換してインデックスし続けることで、ユーザーはデータの所在を意識せずにあらゆる情報を横断できます。 まとめ 製造業のデータを素朴に結合すると10兆件規模の組み合わせになる。これをどう捌くかが今回のテーマでした。 私たちの答えは、用途別に最適化した複数のインデックスと、クエリに応じてそれらを動的に選択する制御層です。特に、非正規化による事前結合で検索時の結合コストをなくしたことと、Elasticsearch が kNN とフィルターをネイティブに統合できることが、類似検索とフィルタリングの両立を可能にしています。 ただ、ここまで作り込んだインデックス構造も、現場の変化に追従できなければ意味がありません。次回の最終回では、このインデックスを「サービスを止めずに進化させ続ける」ための仕組みについて書きます。