目次
「前にもあったはずなのに」と言われて、検索しても出てこず困った
品質管理担当者から、新規の不良報告について相談を受けたときのことだ。
「これ、前にもあったはずなんですけど」
そう言われて、自分（DX推進担当）がkintoneの不良履歴アプリを開き、キーワードで検索してみる。ところが、該当しそうなレコードが出てこない。
しばらくして分かったことがある。表記が違うだけで、実は同じ不良だった。品質管理担当者は「かじり傷」と呼んでいたが、過去のレコードには「擦り傷」と記録されている。同じ現象を指す言葉が違うだけで、検索は素通りしてしまう。
自分は不良履歴の検索を任されている立場でもある。この見逃しをどう防ぐか、他人事ではいられない。
kintoneの不良履歴をキーワードで検索すれば、過去の再発は見つかるはずだ。そう思っていた前提が、この瞬間に崩れることになる。
kintoneの過去不良履歴とn8n×生成AIで、表記が違う同じ不良も意味的に照合できる
以下は顧客の本番環境ではなく、自社の検証環境で実際に試した記録である。
kintoneには「検索AI」という、複数アプリを横断してチャット形式で質問に答える公式のAI機能がある（kintone公式：検索AI、スタンダードコース・ワイドコース向け）。
ただしこれは「質問して回答を得る」ための機能だ。新規の不良報告に対して類似する過去レコードを一覧で拾い出す今回の用途には、そのままでは使えない。
標準の検索機能に加えて、キーワードをAND・OR・NOT条件で連結して検索できる仕組みも別途ある。
ただしこちらは2026年8月時点、APIラボで開発が検討されている実験的な機能であり、本番のkintone環境に標準搭載されているものではない。この仕組みも試してみたが、指定した検索語そのものと一致するデータを探す点は変わらない。表記ゆれの吸収までは対応しきれなかった。
「かじり傷」で検索しても、「擦り傷」というレコードはヒットしない。言葉が違えば、キーワード検索の土俵に乗らない。
そこで、新規の不良報告を受けた時点で、n8nがkintoneの過去不良履歴と生成AIを連携させて意味的に照合する仕組みを作った。「かじり傷」と入力しても、「擦り傷」の過去レコードが類似事例として挙がってくる状態まで実現できている。類似事例には、当時どんな是正処置を取ったかも一緒に提示する。
ただし、これは表記ゆれの吸収の勘所を知っていればの話だ。知らずに始めると、同義語の辞書を作っては直す作業だけで何度もやり直すことになる（この詰まりは後述する）。
kintoneの検索は表記ゆれに弱い。”言い回しが違う同じ現象”を拾えない。この弱点を埋めるのは、生成AIとn8nの役割だ。詰まった場所と、そこからどう抜けたかは、このあと具体的に開示する。
キーワード検索頼みの再発防止が、なぜ見逃しを生むのか
「前にもあったはずなのに、なぜ見逃したのか」。この疑問の答えは、キーワード検索という仕組みの性質そのものにある。
kintoneの標準検索も、APIラボの実験的な検索機能も、指定した検索語と一致するかどうかで判定する。完全に一致するか、部分的に一致するかの違いはあっても、「意味が近いかどうか」までは見ていない。
「かじり傷」と「擦り傷」は、現場では同じ不良を指す言葉として使われることがある。しかし検索システムから見れば、この2つは別々の文字列でしかない。報告者によって言葉の選び方が違うだけで、同じ不良履歴のはずのレコードが検索から漏れてしまう。
kintone側に不良履歴を蓄積していても、それだけでは再発検知は”仕組み”にならない。誰かが「これ、前にもあった気がする」と気づいて、初めて過去のレコードにたどり着ける。つまり再発検知が”気づき”という偶然に依存したままになる。
実装を誰が担うかにも触れておきたい。kintoneのアプリ作成に加えて、同義語辞書のメンテナンスを継続する作業、そしてn8nでのAPI連携や生成AIへの指示（プロンプト）を試行錯誤する作業、この両方に一定の時間を割ける体制であれば、この仕組みは自社の手で届く範囲にある。
表記ゆれの吸収を、固定リストの同義語辞書だけで済ませようとして詰まった
最初に試したのは、固定リストの同義語辞書を作って照合させるアプローチだった。「かじり傷」と「擦り傷」のように、想定できるペアをあらかじめリスト化しておき、検索時にこのリストを参照して同一の不良として扱う方式だ。
想定していたペアは拾えた。ところが、想定外の言い回しには対応できない。辞書に載っていない新しい表現が出てくるたびに、リストへの追加漏れが見つかる。追加しても、また別の言い回しで抜けが出る。この繰り返しが続いた。
不良の呼び方は、報告者の経験・部署・その場の言い回しによって細かく変わる。すべてのパターンを固定リストで網羅しようとすると、リストの管理そのものが終わらない作業になってしまう。
同義語辞書と生成AIを組み合わせるハイブリッド方式にたどり着いた
固定リストだけでは限界がある。そこで、同義語辞書は残しつつ、辞書で拾いきれない表現は生成AIに意味的な類似度判定を任せるハイブリッド方式に切り替えた。
役割分担はこうだ。よく使われる言い換え（「かじり傷」と「擦り傷」のような定番のペア）は辞書で高速に判定する。辞書にない未知の表現が来たときだけ、生成AIに「この不良報告と、過去のこのレコードは、同じ現象を指しているか」を意味のレベルで判定させる。
すべてを生成AIに任せるのではなく、判定できる範囲を辞書で先に絞り込んでおく。こうすることで、生成AIへの問い合わせ自体も減らせる。
この判定精度に持ち込むまでには、生成AIへの指示文（プロンプト）の調整も必要だった。単に「似ているか判定して」と聞くだけでは、表記の違いに引きずられて「別の不良」と判定されてしまう場面があり、判定基準を具体的に示す指示文に練り直す作業を挟んでいる。
この方式に落ち着くまで、数日かけて何度か作り直すサイクルを経た。固定リストだけのアプローチで詰まった後、ハイブリッド方式にたどり着くまでの試行錯誤に、それだけの時間がかかったことになる。
類似事例が見つかった際は、その事例だけでなく、当時どんな是正処置を取ったかもあわせて提示するように設計した。「前にもあった」と分かるだけでなく、「その時どう対処したか」まで一緒に出てくることで、再発防止の判断がその場で完結する。
「前にもあったはず」を、記憶に頼らず即座に確認できる状態になる
品質管理担当者から「これ、前にもあったはず」と相談を受けたときの場面に戻る。
今なら、新規の不良報告を受けた時点で、n8nと生成AIが過去の不良履歴を意味的に照合し、表記が違っていても類似事例を拾い出す。「かじり傷」で報告されても、「擦り傷」として記録されていた過去のレコードが、当時の是正処置とともに提示される。
再発防止が、担当者個人の記憶に頼る属人的な状態から、部門をまたいでも同じ精度で機能する仕組みに変わる。誰かが偶然「前にもあった気がする」と気づくのを待つ必要がなくなる。
ここで一つ切り分けておきたいことがある。技術的に実現できることと、社内の人員・時間でこの仕組みを運用として回せるかどうかは、別の論点だ。
ワークフローの構築自体は、kintoneのアプリ作成に加えて、辞書のメンテナンスとn8n・生成AIの試行錯誤に時間を割ける体制であれば届く範囲にある。ただし、それを継続的な運用として回せる体制が組めるかどうかは、会社ごとの事情による。
自社の環境・データの蓄積状況によって、詰まる場所も対策も変わってくる。技術的に実現できるかどうかも、運用として回せる体制があるかどうかも、判断がつかない場合は無料相談で個別に確認できる。
ものづくりAI自動化ファクトリーでは、こうしたkintone×生成AI×n8nの仕組みづくりを支援している。
関連記事
2026-08-24
freee for kintoneの勘定科目の入力を自動化！kintoneで条件ごとの科目判定を外付けするワークフロー
freee for kintoneを入れれば、kintoneの受注データから売上仕訳まで自動で作れる。そう期待して導入した経理担当の方は少なくないはずです。 ところが実際に月次の売上仕訳を起こしてみると、製品ごとの勘定科目だけは自動で決まらず、1件ずつ手作業で…
2026-08-19
Salesforceの受注をkintoneに入力する手間を削減！n8nで自動連携する仕組みを解説
営業はSalesforceで受注を管理し、生産管理はkintoneで工程を回しています。この2つが別々のシステムだと、受注が入るたびに、生産管理の担当者がSalesforceの画面を見ながらkintoneへ手作業で打ち直すことになりがちです。 本記事では、Sa…
2026-08-17
kintoneデータの手集計から脱却！n8n×Claudeで週報作成を半自動化する方法
kintoneで生産管理をしている現場では、生産実績のデータが毎日きちんと溜まっていきます。それなのに、週報だけは各ラインのExcelやCSVを人の手で集計している方が多いのではないでしょうか。 本記事では、kintoneに蓄積した実績をn8nで自動集計する方…