kintoneのルックアップで見つからない「類似案件」を抽出！生成AIとn8nで過去見積から単価根拠を出す

kintoneのルックアップで似た案件を引けると思ったのに、目当ての単価が出てこない

kintoneに過去の見積を溜めている担当者なら、個別受注の見積を作るとき、まず考えるのは「前に似たような案件をやったはずだ」ということでしょう。
仕様や数量帯、発注元が近い過去の見積を引っぱり出せれば、単価の当たりはすぐつきます。

過去の見積は、kintoneにきちんと溜まっています。
だからこそ、ルックアップを設定して過去見積から似た案件を呼び出そうと考えたはずです。

ところが、いざ引こうとすると目当ての案件が出てきません。
「あのときの、あれに近い案件」という探し方が、思うようにいかないのです。

結局、一覧を開いて目でスクロールし、記憶を頼りに近そうな案件を探す作業に戻ってしまいます。
せっかくデータは貯めているのに、一番ほしい「似た案件の単価」だけが引き出せません。

その壁を生成AIとn8nでどう越えるのかが、この記事のテーマです。

曖昧な「似ている」を扱えるのは生成AI。n8nと組めば単価根拠まで返せる

先に結論をお伝えします。
ルックアップでは扱えなかった曖昧な「似ている」は、生成AIに過去見積を読ませることで扱えるようになります。

そしてn8nを組み合わせれば、新しい引き合いを入り口にして「類似案件の単価レンジと、その根拠」までを自動で返す仕組みが作れるのです。

n8nは、kintoneと生成AIなどの外部サービスをノーコードでつなぐ自動化ツールです。
基本的な仕組みは【超入門】n8nとは？kintoneと生成AI連携のはじめかたで解説しているので、n8nそのものが初めての方はそちらを先にご覧ください。

完成したワークフローは、新しい引き合いの情報を受け取り、kintoneの過去見積を生成AIにわたし、似た案件を見つけて単価レンジと根拠を返す、という一続きの流れになります。
まずこの全体像を見てから、なぜルックアップでは足りないのかという詰まりの話に入りましょう。

bm133-ss-01-n8n

ワークフローの中身は、あとの「単価レンジと根拠を組み立てる」の章で、要になる設定だけを見ていきます。

過去見積が資産に変わるのは、一品一様の見積で「似ている」を扱えたとき

そもそも、なぜルックアップの完全一致では困るのでしょうか。
理由は、個別受注の見積が一品一様だからです。

量産品と違い、個別受注では毎回どこかの仕様が少しずつ変わります。
材質・寸法・数量帯・納期条件のどこかが、毎回違うのです。

完全に同じ案件は、ほとんど二度と来ません。
だからこそ、過去見積を「完全に同じ案件」として引こうとすると、ヒットしないのが当たり前になります。
逆に言えば、「似ている」を扱えて初めて、溜めてきた過去見積が使える資産に変わるのです。

そしてこの「似ている案件の単価をどう決めるか」という判断は、これまで担当者の経験のなかに蓄積されてきた部分でもあります。
今回の企画のもとになった一次情報でも、その勘所を持つ担当者の異動や退職のときに、判断の蓄積が引き継ぎにくいという声がありました。

単価という数字は見積データに残っても、「なぜその単価にしたか」という根拠は、数字の欄には残らないのです。

補足しておくと、この仕組みはSIerに大がかりな開発を発注する話ではありません。
すでに使っているkintoneと、月額数千円規模から始められるn8nのようなノーコード連携ツールの範囲で組めます。

ただし、連携ツールの料金に加えて、生成AIを呼び出すたびに、その回数に応じた利用料も別途かかります。
いずれの料金も改定されることがあるため、導入時に最新の料金を確認してください。

とはいえ、これまで担当者が目視検索や記憶頼みに費やしていた時間と比べれば、投資に見合うかどうかは自社の見積件数しだいで判断できるはずです。

実装そのものは、kintoneでアプリの作成・運用をした経験がある担当者であれば、勘所を掴みやすい範囲でしょう。
ただし、社内で手を動かす時間を確保できるかどうかは別の問題です。
この点は記事の最後で相談先をご案内します。

ルックアップで似た案件を探そうとして、手が止まる

実際にルックアップで似た案件を引こうとすると、大きく3つの壁にぶつかります。
技術的な理由を先に押さえておくと、あとの設計の話がつながりやすくなるはずです。

ルックアップは完全一致。「似ているが同じではない」案件は呼び出せない

最初の壁は、ルックアップの仕組みそのものにあります。
kintoneのルックアップは、指定したキー（品番や案件番号など）が一致するレコードを取得する機能です。

つまり、キーがぴったり合う1件を呼び出すための仕組みなのです。
「仕様が近い」「数量帯が近い」といった曖昧な条件で複数の候補を並べる用途には向いていません。

先ほど触れたとおり、個別受注の見積では完全に同じ案件がほぼ来ません。
すると、ルックアップで引けるキーがそもそも存在せず、似た案件を探すほど手作業の目視検索に逆戻りしてしまいます。
これが「データはあるのに引けない」の正体です。

ルックアップは完全一致で似た案件を引けないが、生成AIなら類似案件がヒットする比較図

過去見積をそのままAIに貼り付けても、条件がバラつき単価がぶれる

では、過去見積をまとめて生成AIに貼り付けて「似た案件を教えて」と頼めばよいのでしょうか。
ここに2つ目の壁があります。

見積レコードは、案件ごとに項目の粒度も書き方もバラバラなことが少なくありません。
ある案件は仕様を細かく書き、別の案件は「一式」でまとめている。
単価に値引き後の額を入れている案件もあれば、定価のまま残している案件もあります。

この状態のままAIにわたすと、AIは何をもって「似ている」と判断すればよいのか定まりません。
結果として、返ってくる単価の根拠が案件ごとにぶれてしまうのです。
整える前にわたすほど、それらしいのに信用できない答えが増えていきます。

AIに単価を出させると、それらしい数字を自信満々に言い切ってしまう

3つ目の壁は、生成AIの性質そのものにあります。
条件を整えてわたしても、AIは単価を「この案件は◯◯円です」と断定的に提示しがちです。

一見すると頼もしいのですが、その数字がどの過去案件を根拠にしているのかが曖昧なまま、それらしい額だけが返ってくることがあります。
この断定をそのまま採用すると、根拠の薄い単価で見積を出してしまいかねません。

AIに任せるほど、かえって単価を誤らせる危険があるのです。
この3つ目の壁が、あとの「単価を言い切らせない」設計に直結します。

過去見積を生成AIにわたし、n8nで単価レンジと根拠を組み立てる

3つの壁には、それぞれ対応する設計があります。
詰まりの1つずつに対応する対策を、実行順に見ていきましょう。
ここが、この記事でお伝えしたい勘所の中心です。

見積の3つの壁と、それぞれ1対1で対応する対策の対応図

仕様・数量・単価・値引きを、AIが読める形にそろえてからわたす

まず取り組むのは、2つ目の壁（条件のバラつき）への対策です。
生成AIにわたす前に、kintone側で見積の項目をそろえておきます。

具体的には、単価判断に効く仕様・数量・単価・値引きを、決まったフィールドに分けて持たせます。
「一式」でまとめず、AIが比較に使える粒度にそろえておくことがねらいです。
ここを整えておくほど、AIが「似ている」を判断する精度は安定します。

bm133-ss-02-kintone

n8nで「引き合い→類似検索→単価レンジと根拠の提示」を1本の流れにする

次に、1つ目の壁（ルックアップでは似た案件を引けない）への対策に移ります。
ここで、ルックアップに代わって類似検索を担うのが生成AIであり、その前後をつなぐのがn8nです。

n8nのワークフローは、新しい引き合いの情報を受け取るところから始めます。
そこからkintoneの過去見積を取得し、生成AIにわたして似た案件を選ばせ、その結果を単価レンジと根拠の形で返すのです。

引き合いから過去見積取得・生成AIによる類似検索・単価レンジと根拠の提示・人による最終判断までのワークフロー図

この一連の流れを1本のワークフローにまとめておけば、担当者は引き合いを入れるだけで済みます。
過去見積の取り出し方やAIへのわたし方は、kintone×n8nで貯まったデータを連携する方法の考え方が土台になります。

要になるのは、過去見積をどういう文脈でAIにわたすかを決めるノードです。
ここで「似ているとは何を指すのか（仕様なのか、数量なのか、発注元の業種なのか）」を指定しておくと、返ってくる類似案件の質が変わってきます。

bm133-ss-03-n8n

生成AIにkintoneのデータをわたす仕組みでは、どの範囲のデータを外部にわたすのかという情報の扱いにも気を配ってください。
この点はAI経由のkintoneデータ流出を防ぐ対策にまとめています。

単価は言い切らず「レンジ＋根拠」で返し、最終判断は人が持つ

最後は、3つ目の壁（AIの断定）への対策です。
AIには単価を1つの数字で言い切らせず、レンジ（幅）と、その根拠になった過去案件をセットで返させます。

たとえば「この引き合いは、仕様と数量が近い過去のA案件・B案件から見て、単価は◯◯円〜◯◯円の範囲。根拠はこの2案件」という形です。
こうすると、担当者は返ってきた根拠案件を確かめたうえで、最終的な単価を自分で決められます。

AIはあくまで似た案件と幅を示す役で、決めるのは人という切り分けです。
この設計にしておけば、AIの自信ありげな1つの数字に引っぱられて見積を誤ることを防げます。

完全一致に縛られず、過去見積が「似た案件の単価根拠」を語り出す

設計を終えると、過去見積の見え方は大きく変わります。

これまでは、ルックアップの完全一致に縛られて、溜めた過去見積が「引けないデータ」のまま眠っていました。
それが、生成AIによる類似提示を通して、「似た案件の単価は、この過去案件を根拠にこのくらい」と語り出すデータに変わるのです。

担当者の記憶をたどらなくても、過去見積そのものが単価の当たりと根拠を出してくれる状態になります。

もっとも、技術的に仕組みが作れることと、それを社内で回し続けられることは別の話です。
自社の見積項目や案件の特性によって、そろえるべきフィールドも、AIにわたす類似の基準も変わってきます。

まずは自社のデータで小さく試し、詰まる場所を見極めるところから始めるのが現実的でしょう。

まとめ

過去見積から似た案件の単価を引けないのは、次の3つの壁が理由でした。

  • ルックアップは完全一致のため、「似ているが同じではない」案件を呼び出せない
  • 過去見積を整えずにAIにわたすと、条件がバラつき単価の根拠がぶれる
  • AIは単価を断定しがちで、根拠の薄い数字をそのまま採用すると見積を誤る

越え方は、この3つと1対1で対応します。
AIが読める形に項目をそろえてからわたし、n8nで「引き合い→類似検索→単価レンジと根拠」を1本の流れにし、単価は言い切らせずレンジと根拠で返して最終判断は人が持ちます。

この設計で、完全一致に縛られていた過去見積が、似た案件の単価根拠を語るデータへと変わっていくのです。

最後に

過去見積をどうそろえるか、AIに「似ている」の基準をどう指定するかは、扱っている製品や案件の特性によって変わります。
自社のデータで組むとき、どこから手をつければよいか判断がつかない場合や、担当者の異動・退職の前に見積の根拠を組織へ残しておきたい場合は、無料の相談をご利用ください。

実際の見積データや業務の流れをうかがったうえで、自社に合った組み方を一緒に考えます。

kintone×生成AIの活用を、ほかのユースケースも含めて広く知りたい方は、kintoneユーザーのための生成AI実践大全もあわせてご覧ください。

関連記事