kintoneの発注ミスの発見に生成AIを活用！kintone×n8n×生成AIで承認の前に違和感を見つける方法

kintoneの入力チェックを厳しくしても、なぜ発注ミスはなくならないのか

kintoneで発注申請を回していても、発注の単価を一桁間違えることがあります。数量に余計な「0」がついてしまう。前回とは違う条件のまま発注が確定してしまう。

購買や経理の現場で、発注ミスをゼロにできていると言い切れる会社は、むしろ少数派かもしれません。そして厄介なのは、こうしたミスが「承認」という関門をすり抜けて、そのまま発注として外に出ていってしまうことです。

損失やヒヤリハットが一度起きると、対策としてまず挙がりやすいのが「kintoneの入力チェックをもっと厳しくしよう」という発想です。必須項目を増やす。上限値を設定する。入力形式を細かく縛る。たしかに、これらは空欄や明らかな入力ミスを止める効果があります。

ところが、いくら入力チェックを足しても「前回と違う」「相場から外れる」という種類のミスは、なかなか減りません。

なぜでしょうか。この記事では、kintoneの発注申請と生成AI、そして外部連携ツールのn8nを組み合わせ、発注ミスの疑いを「承認する前に」自動で洗い出す考え方を解説します。入力チェックを強化する方向とは別の、もう一つの防ぎ方の話です。

発注申請が上がった瞬間に、過去実績と突き合わせて異常の疑いを出せる

kintoneに発注申請が保存された瞬間、n8nが過去の発注実績や見積、単価マスタを自動で照合します。そして「この単価は前回と違う」「この数量は過去のロットから見て多すぎる」といった異常の疑いを、生成AIが文脈込みで指摘する。承認者は、その「疑いの印」を確認するところから承認を始められます。

ここで大切なのは、これは自社で実際に組んでみた仕組みの解説だという点です。ただし、本番の発注業務でどこまで精度が出るかを見極める運用検証はこれからで、「必ずこう動く」という完成品の保証ではありません。

実際の発注品目や取引条件は会社ごとに違うため、そのまま当てはまるとは限りません。あくまで発想と組み立て方の話として読んでいただければと思います。

なぜこうした仕組みが必要になるのか。kintoneの入力チェックは、あらかじめ決めた固定のルールに沿って値を検査する仕組みです。ルールに書けるのは「空欄はだめ」「桁数はここまで」といった、その申請だけを見て判断できる条件に限られます。

一方で「前回この取引先といくらで取引したか」「過去の平均的な発注ロットと比べてどうか」という判断は、履歴と照合して初めて成り立ちます。この履歴の照合と、そこから「疑わしいかどうか」を推し量る推論こそ、n8nと生成AIに任せる部分です。

具体的な組み立ての考え方と、n8nで組んだ手順は、このあと順を追って説明します。

発注ミスの発見が、承認者個人の経験や勘に依存している

発注承認は、件数をまとめて処理していく業務です。1日に何件も申請が上がってくるなかで、承認者が1件ずつ過去の実績や相場を引っぱり出して照合する時間は、現実にはほとんど取れません。

結果として、ミスに気づけるかどうかは承認者本人の記憶や経験に委ねられます。「この取引先はいつもこのくらいの単価だったはず」という感覚を持っている担当者なら、違和感に気づけることもあるでしょう。しかし、その感覚は言葉にも仕組みにもなっていないため、担当者が変われば失われてしまいます。

属人化を減らし、誰が承認しても一定の水準でミスを拾える状態にしたい。これは、この記事が解こうとしている課題そのものです。

ここで、入力チェックが担える範囲をもう一度確認しておきます。kintoneの標準的な入力チェックが検査できるのは、空欄や桁数、上限値といった「入力の形式」までです。

「この取引先のこの品目は前回いくらだったか」という履歴に照らした判断は、固定のルールには書き込めません。この違いこそ、入力チェックを強化しても文脈のミスが残り続ける理由です。

なお、こうした仕組みを「誰が組むのか」も気になるところだと思います。kintoneのアプリ作成や運用ができる担当者であれば、構想そのものには手が届く範囲です。

ただし、社内でその時間を確保できるかどうかは別の問題です。技術的に可能かどうかと、実際に社内の人員・体制で回せるかどうかは、切り分けて考える必要があります。この点については、記事の最後にご相談先を案内します。

固定ルールのチェックがすり抜ける、発注ミスの典型的な場面

いずれも、固定ルールの入力チェックがすり抜けやすい典型的な組み合わせです。なぜ固定ルールで防げないのか。その技術的な理由は、kintoneの入力チェックの仕様そのものに根ざしています。

入力チェックをすり抜ける発注ミスの3つの典型場面。単価の更新漏れ、数量の桁ミス、取引先条件のズレ

前回のレコードを複製して起票し、単価だけ古いまま承認された

一つ目は、単価の更新漏れです。

購買担当が前回の発注レコードを複製して、新しい発注申請を作る。取引先も品目も同じなので、数量だけ書き換えて起票する。ところが、単価が前回から改定されていたことに気づかず、古い単価のまま申請してしまう。

このとき、必須項目はすべて埋まっていて、入力形式にも問題はありません。だから入力チェックには一切引っかからず、承認画面に上がってきます。承認者も件数が多く、金額の妥当性までは踏み込まずに承認する。結果として、数量に古い単価を掛けた金額で発注が確定し、あとから差額が発覚します。

なぜ入力チェックで止まらないのか。単価という「値」そのものは正しい形式で入っているからです。「前回と違う」という判断は、過去のレコードと突き合わせなければ下せません。この照合は、あとで説明するn8nの役割になります。

数量の桁を1つ多く入れても、上限内なら警告は出ない

二つ目は、数量の桁ミスです。

数量欄に「100」と入れるつもりが「1000」と入力してしまう。上限値のチェックを設定していても、上限を「1000」より大きく設定していれば、形式上は正常な入力として、そのまま通ってしまいます。

問題は、この「1000」が過去の発注ロットと比べて明らかに多いかどうかです。しかし、過去の平均的な発注量に照らして判断することは、固定のルールには書けません。

「この品目はいつも100前後」という履歴を知らなければ、桁が一つ多いことに機械は気づけません。ここは、生成AIに文脈込みで判定させる部分になります。

取引先ごとの前回条件との食い違いは、承認画面からは見えない

三つ目は、取引先ごとの条件のズレです。

同じ品目でも、取引先や時期によって単価や数量の条件は変わります。ある取引先とは「まとめ買いで割引」の条件だったのに、別の取引先の条件のまま発注してしまう。こうした食い違いは、金額だけを見ても異常とは判断できません。

さらに、kintoneの承認画面は基本的に「その申請一件」を表示するものです。「前回この取引先とどういう条件で取引したか」を横に並べて見せてはくれません。承認者が過去のやり取りを記憶していない限り、条件の食い違いには気づけない構造です。ここは、前回条件を承認画面に一緒に表示する工夫で補います。

承認の前に「文脈込みの異常」を洗い出す、kintone×n8n×生成AIの組み立て

ここまで見てきた三つのすり抜けに、一つずつ対応する設計を、処理が流れる順に説明します。全体像としては、kintoneの申請保存をきっかけに、n8nが履歴を集めて生成AIに判定させ、その結果をkintoneに書き戻す、という流れです。

kintoneの発注申請をn8nと生成AIで承認前にチェックする処理フロー図。申請保存から履歴照合、AI判定、承認画面への書き戻しまで

申請保存を起点に、n8nが「前回いくらだったか」を過去実績・単価マスタから引き当てる

出発点は、kintoneで発注申請が保存された瞬間です。

kintoneには、レコードの追加や更新をきっかけに外部へ通知するWebhookや、外部から情報を取得するREST APIといった連携の仕組みがあります。REST APIの仕様を確認できるのが、kintone REST APIの公式ドキュメントです。

今回の仕組みでは、申請が保存されたことをWebhookでn8nに伝え、そこからの履歴の取得にREST APIを使います。

通知を受けたn8nは、同じ取引先・同じ品目の過去の発注実績や見積、単価マスタを取得し、今回の申請内容と横に並べます。「前回いくらだったか」を、機械が承認者の代わりに引っぱり出してくるわけです。これが、一つ目の単価更新漏れに対する備えになります。

n8nがどんなツールで、kintoneとどう連携するのかは、【超入門】n8nとは？kintoneと生成AI連携のはじめかたで基礎から解説しました。n8n側でWebhookを受け取る仕組みは、n8n公式ドキュメントのWebhookノード解説を参照してください。

生成AIには「一致/不一致」ではなく「なぜ疑わしいか」を判定させる

次に、集めた履歴と今回の申請内容を、生成AIにわたして判定させます。

ここで単純な「値が一致するか・しないか」の判定にとどめてしまうと、桁が一つ多いケースや相場から外れるケースは拾いきれません。数値がぴったり一致していなくても正常な発注はいくらでもあるからです。

そこで生成AIには、過去の実績と今回の申請値を一緒にわたします。そのうえで「この申請は過去の傾向と比べて疑わしいか、疑わしいとすればなぜか」を、短い言葉で答えさせます。

「今回の単価は、前回のレコードの単価と異なる値だった」「数量が過去の平均ロットの約10倍になっている」といった具合に、理由つきで返させるのがポイントです。これが、二つ目の桁ミスや相場外れに対する備えになります。

文脈を踏まえた判断を生成AIに担わせる考え方は、kintoneユーザーのための生成AI実践大全でも掘り下げました。

取引先ごとの前回条件も、判定結果と一緒に承認画面へ書き戻す

判定が終わったら、その結果をkintoneの申請レコードに書き戻します。

生成AIが付けた「疑いの印」と、その理由。そして、照合に使った前回の取引条件。これらを申請レコードのフィールドやコメントに書き込んでおくのが、この工程の要点です。こうすることで、承認者はいつもの承認画面を開くだけで、機械の指摘と前回条件を並べて確認できます。

kintoneのステータス変更や保存をきっかけに、外部の処理結果をレコードへ反映する流れは、請求漏れを解消！kintoneのステータス変更でfreeeの請求書を自動発行するワークフローでも同じ考え方を使っています。これが、三つ目の「承認画面から前回条件が見えない」問題に対する備えです。

【実装担当向け】異常判定は止めるのではなく、承認者に判断材料を渡す設計にする

ここは実装を担当する方向けの補足なので、仕組みの全体像をつかみたいだけの場合は読み飛ばしても差し支えありません。

設計上、気をつけたいのは「AIが疑わしいと判定したら申請を自動で却下する」という作りにしないことです。生成AIの判定は万能ではなく、正常な発注を「疑わしい」と拾ってしまう誤検知も起こります。自動で止める設計にすると、誤検知のたびに業務が止まってしまう点が問題です。

そのため、AIの役割はあくまで「承認者に判断材料をわたすこと」にとどめます。疑いの印と理由を提示し、最終的に承認するかどうかは人が決める。この切り分けが、仕組みを現場で使い続けるための勘所です。

実際に組んだ手順は、このあとの章でスクリーンショットとあわせて紹介します。運用してみたときの精度や使用感については、検証が進んだ段階で改めて追記する予定です。

n8nでワークフローを組んだ手順

考え方は前章のとおりです。ここでは、n8nで組んだワークフローの画面を見ながら、どの画面のどこを設定するのかだけを押さえていきます。全体の流れだけ押さえれば十分で、細部の設定は実装担当に任せて差し支えありません。

全体像は、左から右へ4つのノードが一列に並んだ形です。前章の「受け取る、履歴を集める、判定する、書き戻す」という流れが、そのままノードの並びになっています。今回は大きな詰まりなく組めましたが、細かな調整やつまずきどころは、運用検証を進めるなかで別途まとめる予定です。

申請の保存を受け取るWebhookノードを置く

一つ目は、申請の保存をn8nが受け取る入口のノードです。どのアプリの、どのイベント（レコードの追加・更新）でWebhookを送るかは、kintone側のアプリ設定であらかじめ決めておきます。n8n側のこのノードで見ておくのは、その通知を待ち受けるURLが発行される箇所です。

 

kintoneのREST APIで過去のレコードを取得する

二つ目は、過去の実績を引き当てるノードです。設定画面で見るべきは、取引先と品目で絞り込む検索条件を入れている箇所になります。ここに条件を入れておくと、今回の申請と同じ相手・同じ品目の過去のレコードだけが集まります。

集めた履歴を生成AIノードにわたして判定させる

三つ目は、判定を任せる生成AIのノードです。設定画面では、集めた履歴と今回の申請値をこのノードへつなぎ、プロンプト欄に「疑わしいか、疑わしいとすればなぜか」を短く返させる指示を入れておきます。ここが、固定ルールでは書けない文脈の判断を担う箇所です。

判定結果をkintoneの申請レコードへ書き戻す

最後は、判定結果を申請レコードへ書き戻すノードです。設定画面では、書き込み先のフィールド（疑いの印と理由、そして前回の取引条件）を指定します。ここまでつなげば、ワークフローは完成です。承認者が目にするのは、疑いの印と理由、そして前回条件が並んだ承認画面です。

承認の質を、承認者個人の経験ではなく仕組みで支える

発注承認のビフォーアフター比較図。目視でゼロから点検する従来と、機械が付けた疑いの印を確認する導入後

これまで発注申請は「承認者が目視でゼロから点検する対象」でした。それが、この仕組みを入れると「機械が付けた疑いの印を確認する対象」に変わります。承認者は、白紙の状態から金額の妥当性を探すのではなく、機械が先に洗い出した候補を見るところから始められるのです。

固定ルールの入力チェックでは届かない「前回と違う」「相場から外れる」という文脈の判断を、履歴照合はn8nに、推論は生成AIに切り出す。こうすることで、発注ミスの発見が承認者個人の経験や勘だけに頼る状態から抜け出せます。

ただし、先ほども触れたとおり、技術的に実現できることと、社内で回せることは別の話です。「自社の手で作れる」と無条件に言い切れるものではなく、実装の時間を確保できるか、運用に乗せられるかという体制の問題は残ります。

もう一つ見落とせないのは、生成AIの判定は万能ではなく、正常な発注を「疑わしい」と拾ってしまう誤検知も起こりうるという点です。だからこそ、判定はあくまで承認者への材料であり、最終判断は人が担う設計にしておく必要があります。

費用の面では、必要になるのは主にn8nの利用料と生成AIのAPI利用料程度で、大がかりなライセンス投資を前提とする仕組みではありません。

もっとも、この仕組みにどれだけ投資する価値があるかは、発注ミスが自社でどの程度の頻度と金額で起きているかによって変わります。費用対効果は、体制の話とあわせて、それぞれの会社で検討すべき論点です。

まとめ

発注ミスを防ぐとき、まず思い浮かぶのは入力チェックの強化です。しかし入力チェックが止められるのは「空欄」「桁数」「上限」といった入力の形式までで、「前回と違う」「相場から外れる」という文脈のミスには届きません。

そこで、履歴の照合と文脈の推論を、承認する前の段階に組み込むという発想が生まれます。kintoneの申請保存をきっかけにn8nが過去実績を引き当て、生成AIが「なぜ疑わしいか」を判定し、その結果を承認画面へ書き戻す。承認者は、機械が付けた疑いの印を確認するところから承認を始められます。

大切なのは、承認の質を承認者一人の経験や集中力に背負わせないことです。

最後に

ここまで解説した仕組みは、自社の発注品目や取引条件によって、照合すべき履歴も異常の基準も変わってきます。「自社の発注業務にどう当てはめられるか」「どこから手をつければよいか」の判断がつかない場合は、無理に一人で抱え込まず、専門家に相談するのが近道です。

私たちは、こうしたkintoneと生成AI、外部連携ツールを組み合わせた業務改善を「ものづくりAI自動化ファクトリー」として支援しています。

発注承認の属人化や見逃しにお悩みでしたら、ものづくりAI自動化ファクトリーの無料相談をご利用ください。自社の状況に合わせた進め方を、一緒に整理します。

関連記事