はじめに

こんにちは。RightTouch のAIエンジニアの原田です。

今回は、弊社の取り組みについてお話しする機会をいただき、ファインディ株式会社様が主催する「AI Engineering Summit 2025」に、弊社の CTO である籔と共に登壇させていただきました。

弊社は組織の規模としては決して大きくはなく、限られたリソースの中で価値となるロジックを着実に作っていくにはどうすればいいか、日々試行錯誤を繰り返しています。

特にプロダクトのロジック開発を担当するいわゆるAIエンジニアやデータサイエンティストとしての役割を持つメンバーは私を含めて2人しかいませんが、日々色々な物事と向き合ってロジックの開発をしています。

今回の登壇では、こうした環境下で私たちが大切にしているロジックの開発思想を、同じくプロダクト開発に従事されているみなさんに共有したいという思いからお伝えしました。

本 note では、この登壇の模様を振り返りながら、当日の様子や発表内容、そしてイベント全体を通じて感じたことを自身の視点からレポートしたいと思います。

AI Engineering Summit とは

AI/LLM プロダクト開発の実践者たちの集う場所

「AI Engineering Summit」は、その名の通り AI を研究対象としてだけでなくプロダクトに実装し価値を届けるための「エンジニアリング」に焦点を当てた、国内でも屈指の技術カンファレンスです。

今年のテーマは「LLM・AI エージェントの活用と開発の最前線」でした。

Siri の共同創業者であるアダム・チェイヤー氏による基調講演をはじめ、名だたる企業の CTO や第一線のエンジニアたちが集結し、まさに技術の最先端がぶつかり合う場でした。

本イベントはオンラインで開催されましたが、事前エントリーは 2300 人を超えていたと伺っており、当日は 2700 人を超える参加者がいたと聞いています。AI という技術が単なるバズワードから、いかにしてビジネス価値に繋げるかという実践的な「How」のフェーズへと業界全体の関心が移行していることを肌で感じました。

登壇したセッションは 13:00~13:40 分の枠で、その枠では 3 つの Room に分かれたオンライン配信だったので、弊社の登壇枠もおそらく 300 ~ 500 名以上の方にご覧いただけていたのではと思います。

当日の登壇の雰囲気

配信の雰囲気

スクリーンショット2025-07-2417.36.56.png

当日は Vimeo を使ったオンライン配信でした。オフィスでは、チームのメンバーが会議室に集まって「鑑賞会」を開いてくれていました。

社内 Slack にはリアルタイムで応援の絵文字やコメントが飛び交っており、私自身は自宅から参加しましたが皆さんのサポートを強く感じることができました。

当日のスライドやアーカイブは下記をご覧ください。
https://findy-tools.io/events/338cda12e34be8dde254

登壇内容

ここからは、当日お話しした内容の核心部分をより深く掘り下げていきたいと思います。

セッションタイトルは「生成 AI はカスタマーサポートをどう変えるか？ - 顧客価値に繋げる非構造データとの向き合い方-」というタイトルで、技術先行ではなくあくまで顧客価値を起点とした AI ロジック開発の思想と実践についてお話ししました。

カスタマーサポートの課題と非構造化データ

まず、弊社が事業を展開するカスタマーサポート領域の特性について説明しました。この領域では、顧客との応対履歴、オペレーターが参照する業務ドキュメント（マニュアルや FAQ）、さらには通話音声といった多種多様な「非構造化データ」が日々大量に生まれています。

そして、顧客が抱える本質的な課題は単一のデータソースに存在するわけではありません。例えば、「ある製品の特定機能に関する問い合わせが増えている」という事実は応対履歴データだけを見ていてもわかりません。その問い合わせに対して、オペレーターがどのマニュアルのどの部分を参照して苦労しているのかという業務ドキュメントの利用状況や、電話応対の時の音声データを組み合わせることで、初めて課題の全体像が浮かび上がってきます。

このように、複数の非構造化データが複雑に絡み合った中からいかにして顧客課題を正確に捉えプロダクトの価値へと昇華させるかを考える必要があり、これはロジックを考える上での重要な前提です。

弊社の 2 つの事例に見るロジック開発の思想

あらゆるロジックを考える上でLLMの存在は当然無視できません。また、非構造化データの扱いはLLM の登場により劇的に容易になりました。

しかし、弊社では「LLM に丸投げすれば全てが解決する」という安易な考え方を採用しません。その思想を体現する 2 つの具体的な開発事例を紹介しました。

事例 1：業務ドキュメントの検索

顧客の業務によっては、オペレーターが参照するドキュメント検索において 1 秒以下の応答速度と高い検索精度が求められます。このような要件下で、一般的に用いられる RAG（Retrieval-Augmented Generation）のような LLM が検索結果を解釈・生成するアーキテクチャはレイテンシの観点から最適とは言えません。

そこで、RAG や Reranker といった技術に頼らずベクトル検索そのものの性能を極限まで高めるアプローチを選択しました。ここで最も重要かつ困難なのが、巨大なドキュメントを検索クエリと適切にマッチするように分割する「チャンキング」の戦略を立てることであり、既存のライブラリをただ適用すれば済む話ではありません。

クエリと検索対象の関係性を深く洞察しどう分割すれば意味的にもっともヒットしやすくなるかを、実際のドキュメントデータを一つ一つ目で見て以下を自分の頭で考え抜く必要があります。

この着実な戦略設計こそが、技術選定以上にロジックの価値を決定づける核心部分であると考えています。

事例 2：堅牢なドキュメント構造化

もう一つの事例は、顧客が作成した多種多様なフォーマットの業務ドキュメント（Office ファイルなど）を、プロダクトで活用可能な構造化データに変換する課題です。

当初、マルチモーダルな LLM の能力に期待しその活用を試みました。確かにその性能には目を見張るものがありましたが、複雑なレイアウトのドキュメントに対して安定した結果を得ることや、なぜ特定の抽出に失敗したのかをデバッグすることの難しさに直面しました。プロダクトとして提供するには、この「ブラックボックス性」は致命的です。

そこでロジックの方針を転換しました。まず、基本的な要素（テキストブロック、表、画像など）の抽出には LLM を使わず、従来の画像処理やレイアウト解析といった、確実でデバッグ可能なデータ解析技術を組み合わせたロジックを構築しました。その上で、確実に抽出できた要素間の意味的・位置的な関係性を解釈しグルーピングして構造化する部分に限定して LLM を活用したのです。

この 2 つの事例は、偶然選ばれたものではありません。前者は特定の業務要件（速度）を満たすために LLM 的なアプローチを意図的に回避した例であり、後者は別の業務要件（堅牢性・デバッグ容易性）を満たすために一度は試した LLM から戦略的に後退した例です。

これらは表裏一体であり、「最新技術に飛びつくのではなく、制御可能性を最優先に考え課題解決のために最適な手段を主体的に選択する」という私たちのロジック開発に対する姿勢を示しています。

顧客価値の絶対的優先

では、なぜこういった一見大変に見えるアプローチを積極的に実行するのかですが、その理由はロジック開発における優先順位にあります。

ロジック開発においては、理解すべき要素を「① 顧客の業務」「② 課題・データ」「③ 技術」の 3 つに分類し、① を最優先事項としています。

顧客がプロダクトにお金を払うのは、その裏側でどんなに高度な AI 技術が使われているかに対してではありません。自分たちの業務がどれだけ効率化・高度化されるかという「価値」に対してです。したがって、ロジック開発は常に「この機能は顧客の業務をどう変えるのか？」という問いからスタートします。

この視点に立つと、業務における具体的なアプローチと目標も以下のように自ずと明確になります。

顧客へのデモでは、技術の凄さではなく価値が確実に伝わること。
そこから得られるフィードバックを最速でロジックに反映し、業務解像度を上げ続けること。
データを直接見て、データにないエッジケースまで想像を巡らせること。
そして、「万能な技術」という幻想を捨て、実用性を第一に考えたロジックを構築すること。

そして、このアプローチこそが顧客課題をプロダクトの本質的な価値へと確実に繋げる唯一の道だと信じています。

LLM との規律ある向き合い方

最後に、こうした思想に基づいた上での LLM との向き合い方についてフレームワークを提示しました。

まず、LLM を採用するか否かを常に意識的に判断します。LLM が真価を発揮するのは、従来のルールベースや統計的モデリングでは扱いきれなかった複雑な「構造化」の課題です。一方で、生成結果に数学的な根拠が求められる課題や品質が厳格に問われる領域では、依然として古典的なアプローチが重要です。

Cursor_と_ai_engineering_summit_yabu_pdf8.png

そして、LLM を使うと決めた場合でも「課題分解アプローチ」を徹底します。登壇の中ではロジックの複雑度を 3 つのレベルで定義しました。

Level 1: 単一ツール（例：要約、翻訳）
Level 2: ワークフロー（例：抽出 → 分類 → 要約といった一連の処理）
Level 3: エージェント（状況に応じてツールやワークフローを自律的に選択・実行）

昨今話題の自律型エージェント（Level 3）も、決して魔法ではありません。

それは Level 1、Level 2 で一つ一つ精度を担保して作り上げた信頼性の高い「ツール」を LLM が適切に選択・オーケストレーションすることで初めて成立するものです。

複雑な課題を LLM に丸投げしうまくいかなかった時に「技術の限界」と結論づけるのは顧客に対する不誠実です。課題を粘り強く分解し確実な部品を一つ一つ丁寧に作り上げそれらを組み上げていく、この地道なプロセスこそが本質的な価値を生み出すというメッセージで発表を締め括りました。

質疑応答で感じた世の中のエンジニアの直面している課題感

発表の後、質疑応答の時間で想定よりも多くの質問をいただきました。

寄せられた質問は 15 件近くに及びましたが、質疑応答に応える中で世の中のエンジニアがロジック開発で直面している課題感についてリアルな声を聞くことができました。

以下は実際に質疑応答で実際に来た質問とそれに対する私たちの回答です。

「ハルシネーションリスクをどう回避しているか」

モデルのチューニングだけでなく、システム設計で解決する。出力の「出口」（FAQ や有人窓口への誘導など）を制御し、誤りの影響範囲を限定する。

LLM の思考過程での誤りは、ワークフローの中で個別に解決する。(籔)

「このマインドをどう社内に浸透させたか」

目に見える成果を通じて伝播する。ロジック開発者がこの思想を実務で体現し、その成果物を通じて組織に影響を与えていく。（原田）

「LLM からルールベースに戻した事例は何か」

まさに今回のドキュメント構造化の事例。複雑な実データに対するデバッグ容易性、信頼性、制御性を確保するため、純粋なマルチモーダル LLM からハイブリッドアプローチに移行した。特定の技術に固執せず、課題解決という目的に対して常に最適なツールを選択する。（原田）

「ロジックのアーキテクチャ設計はどうしているか」

「基盤化」を意識する。プロダクト戦略に基づき、プロダクト横断で汎用的に使いまわせるロジック部品を構築する。スケール、持続可能性、再利用性を見越して設計する。堅実なソフトウェア工学の規律こそが、高度な AI システムの土台となる。（籔）

これらの問いは、まさに私たちが日々向き合い、今回のプレゼンテーションで問題提起しようとしたテーマそのものでした。抽象的な技術論ではなく、実装の泥臭さや組織論にまで踏み込んだ質問の数々は、視聴者の多くが私たちと同じように AI をプロダクトに組み込む現場で格闘しているエンジニアであることを示唆していました。

自分たちの思想が決して独りよがりなものではなかったのだと深い手応えを感じました。

終わりに

今回の登壇は、 RightTouch で私たちが日々実践している顧客価値の実現を最優先する AI ロジック開発のスタンスと、その重要性を言語化し社外に発信する絶好の機会となりました。そして、質疑応答での対話はこのアプローチが間違っていなかったという確信を与えてくれました。

技術の流行り廃りに惑わされることなく、目の前の顧客、目の前のデータ、そして解くべき課題に真摯に向き合うという、「当たり前」を愚直にやり続けることの価値を改めて認識することができました。

これからも、この信念を持ち続けながら非構造化データという価値の源から顧客にとって本当に価値のあるロジックを掘り出し続けていきたいと思います。

最後になりましたが、このような貴重な機会をくださったファインディ株式会社様、そして発表に最後まで耳を傾けてくださった全ての視聴者の皆様に、心より感謝申し上げます。

ありがとうございました。

積極採用中！

RightTouchではカスタマーサポート市場の改革に挑むエンジニアを採用中です！

もし興味があれば、ぜひお話ししましょう！

「生成 AI はカスタマーサポートをどう変えるか？ - 顧客価値に繋げる非構造データとの向き合い方-」AI Engineering Summit 2025 登壇レポート