「受注したら販売管理システムへ入力する。その後、案件の進捗を管理するためにkintoneにも入力する。さらに営業会議用のExcelにも同じ案件を書く」
中小の卸売業や商社では、このような運用が珍しくありません。
たとえば、従業員20名ほどの商社を想定してみます。受注金額や商品、数量、得意先情報は、昔から使っている販売管理システムへ登録しています。
一方、その販売管理システムでは「メーカーへ納期確認中」「見積回答待ち」「営業担当が顧客へ確認中」といった細かな進捗を管理しにくいため、数年前にkintoneを導入しました。kintoneを使うことで、案件の進み具合は見やすくなりました。
ところが営業担当者に話を聞くと、別の問題が起きていました。同じ案件について、販売管理システム、kintone、営業会議用Excelへ、実質的に3回入力していたのです。
kintoneを導入した目的は業務効率化だったはずなのに、「管理する場所が増えて入力作業まで増えた」と感じる状態です。
この問題を解決するとき、大切なのは、いきなりAIに入力を任せようとしないことです。まず確認すべきなのは、基幹システムからCSVを出せるか、通常のデータ連携ができないか、既存の連携サービスを使えないかという点です。
この記事では、kintoneと基幹システムの二重入力を減らす方法を、中小企業の経営者にも分かるように順番に整理します。結論から言えば、検討する順序は「基幹側のCSV連携 → kintoneのAPI・連携サービスやプラグイン → Make・Zapierなどのノーコード連携 → AI転記」です。AIは最後です。AIが本当に向いているのは、単純なコピーではなく、例外や人の判断が必要だった転記です。
結論|kintoneと基幹の二重入力はAI転記から考えない

kintoneと販売管理システムの二重入力をなくしたい場合、最初に確認したいのは「AIで自動入力できるか」ではありません。先に確認するべきなのは、普通の仕組みでデータを移せないかです。
二重入力解消はこの順番で考える
- 基幹システム側のCSV入出力
- kintoneのAPI・連携サービス・プラグイン
- Make・Zapierなどのノーコード連携
- AIによる転記
たとえば、販売管理システムから毎日CSVを出力でき、そのCSVをkintoneへ取り込めるのであれば、得意先名や受注番号、商品コード、数量を人が打ち直す必要はありません。kintoneではCSV等のファイルを利用したデータの読み込みや書き出しが可能で、REST APIではレコードの取得・登録・更新などの操作が提供されています。基幹側の仕様が対応していれば、AIを使わなくてもデータ連携を設計できる余地があります。
定型処理にAIを使う必要はない
「基幹の商品コードをkintoneの商品コード欄へ入れる」「受注数量を同じ数字のまま転記する」という処理には、文章の意味を理解したり判断したりする必要がありません。決まった場所から決まった場所へデータを移すだけです。
このような仕事は、原則としてCSVやAPIなどの通常のシステム連携のほうが向いています。AIを使うと、読み取り結果の確認、誤認識への対応、出力内容のチェック、AI利用に関する社内ルール、重要データを扱う場合の安全管理など、別の管理も必要になります。単純転記なら、AIを使わずに済むほうが運用を安定させやすいでしょう。
AIを使うのは「判断」が残る部分
- メーカーから届いたメールを読んで回答納期を抜き出す
- FAXやPDFの注文書から品名や数量を読み取る
- 自由記述された問い合わせ内容を案件種別へ分類する
- 書き方が毎回違う依頼文から必要項目を整理する
- 備考欄の文章を読んで担当部署の候補を判断する
つまり、「決まった場所から決まった場所へコピーする仕事」ではなく、「人が一度内容を読んでから入力している仕事」がAIの候補です。
なぜkintoneを入れたのに二重入力が増えるのか
kintoneと基幹システムの二重入力が起きている会社では、「kintoneを入れたこと自体が失敗だったのではないか」と感じることがあります。しかし、多くの場合はそうではありません。二重入力が生まれる理由は、基幹システムとkintoneの役割が違うからです。
販売管理システムだけでは現場が欲しい項目を持てない
卸売業や商社で使う販売管理システムは、一般に受注、売上、仕入、請求、入金、商品、得意先など、会社の取引に必要な情報を管理する役割を持っています。一方で営業現場では、もっと細かな情報を確認したいことがあります。
- 見積提出済み
- 顧客回答待ち
- メーカーへ納期確認中
- 代替品を提案中
- サンプル発送済み
- 次回訪問予定
- 価格交渉中
- 上長判断待ち
販売管理システムにこれらの入力欄がなかったり、項目を自由に増やせなかったりすると、「営業案件だけ別に管理したい」という要望が出てきます。そこでkintoneを追加します。
kintoneで足りない情報を補うと、同じ基本情報が必要になる
kintoneで案件を管理する場合にも、得意先、案件番号、商品、数量、営業担当者、希望納期などの情報が必要になります。ところが、これらの情報はすでに販売管理システムへ入力されています。そのため、販売管理システムにある情報を、案件を管理するためにkintoneへもう一度入力する状態が生まれます。
kintoneが二重入力を作ったというより、基幹とkintoneの間に情報を渡す仕組みを作らないまま、管理場所だけ増えたと考えたほうが正確です。
Excelまで残ると三重入力になる
さらに問題になりやすいのがExcelです。「営業会議は昔からこのExcelを使っている」「社長がこの表を見ている」「月末だけExcelへまとめている」といった理由で、従来の管理表が残ることがあります。
すると「基幹 → kintone → Excel」と同じ情報が3か所に存在します。問題は入力時間だけではありません。更新のタイミングがずれるため、「どの数字が最新なのか」が分からなくなります。二重入力を解消するときは、転記作業の自動化だけでなく、そもそも3つの管理場所が本当に必要なのかまで見直すことが大切です。
最初にやることは「二重入力している項目」の棚卸し
システム連携を考える前に、まず現在の入力項目を書き出しましょう。ここを飛ばしてツール選定を始めると、「連携できたけれど、そもそも不要なデータだった」ということが起こります。
| 項目 | 基幹 | kintone | Excel |
|---|---|---|---|
| 得意先名 | ○ | ○ | ○ |
| 案件番号 | ○ | ○ | ○ |
| 商品 | ○ | ○ | ○ |
| 数量 | ○ | ○ | ○ |
| 希望納期 | ○ | ○ | ○ |
| 営業進捗 | △ | ○ | ○ |
| メーカー回答 | △ | ○ | △ |
| 売上金額 | ○ | △ | ○ |
| 営業メモ | × | ○ | ○ |
この表を作るだけでも、「得意先名や商品は3回入力している」「営業メモは基幹には必要ない」といったことが見えてきます。
「同じデータ」と「似ているデータ」を分ける
注意したいのは、名前が似ているだけで同じ意味ではない項目です。たとえば、基幹の「受注日」とkintoneの「案件開始日」は同じ日とは限りません。また、「顧客希望納期」「メーカー回答納期」「自社出荷予定日」も別の情報です。ここを雑に「納期」と一つにすると、連携後に事故が起こります。項目を整理するときは、何を意味する数字・日付なのかまで確認してください。
どちらを正マスタにするか先に決める
kintoneと基幹システムを連携するときに、最も重要なのが正マスタを決めることです。難しい言葉に聞こえますが、考え方は簡単です。
正マスタとは「食い違ったら、どちらを正しいとするか」
たとえば、ある案件の数量が販売管理システムでは100個、kintoneでは120個となっていたとします。このとき「どちらが本当の受注数量なのか」を決める必要があります。このように、同じ情報が複数のシステムに存在するとき、最終的に正しいと判断する元データを正マスタと呼びます。
基本は取引を確定させるシステムを正にする
卸売業・商社の場合、売上や請求につながる情報は販売管理システムを正にするケースが多いでしょう。たとえば、得意先コード、商品コード、受注数量、売上金額、請求情報、仕入情報などです。これらをkintone側で自由に変更できるようにすると、基幹と食い違ったときに混乱します。
一方で、案件の進捗、メーカーへの問い合わせ状況、営業担当者のメモ、次回フォロー予定、顧客とのやり取りなどは、kintoneを正にする設計が考えられます。
正マスタはシステム単位ではなく項目単位で決められる
「基幹とkintoneのどちらを正にするか」と聞くと、どちらか一つを選ばなければならないように思えます。しかし実際には、項目ごとに正を決める方法があります。
| データ | 正にしやすい場所 | 理由 |
|---|---|---|
| 得意先コード | 基幹 | 売上・請求と連動する |
| 商品コード | 基幹 | 受発注・在庫の基準になる |
| 受注数量 | 基幹 | 正式な取引数量になる |
| 売上金額 | 基幹 | 請求や会計処理につながる |
| 案件進捗 | kintone | 営業状況を柔軟に管理しやすい |
| 納期回答履歴 | kintone | 調整途中の履歴を持ちやすい |
| 営業メモ | kintone | 非定型情報を扱いやすい |
重要なのは、「同じ項目を両方で自由に編集しない」ことです。基幹を正にするなら、kintone側は参照用として扱う。kintoneを正にする情報なら、基幹へ無理に戻さない。このルールだけでも、二重管理の混乱を大きく減らせます。
方法1|まず基幹システムのCSV連携を確認する
kintoneと基幹の二重入力をなくしたい場合、最初に調べたいのがCSVです。CSVとは、Excelのような表形式でデータを保存するファイルです。専門的なシステム開発をしなくても、基幹からCSVを書き出せれば、データ移行や連携に使える可能性があります。
kintoneでは、レコードデータをCSV等のファイルへ書き出し、既存アプリへファイルからレコードデータを取り込む仕組みが用意されています。さらに、基幹システムなどから出力したCSVをkintoneへ登録する連携サービスも提供されています。
APIがなくてもCSVだけで改善できることがある
たとえば販売管理システムから受注番号、得意先、商品、数量、納期をCSVで出せるとします。この情報をkintoneへ反映できれば、営業担当者が同じ項目を最初から打ち直す必要はなくなります。完全自動でなくても、「毎朝CSVを出して取り込む」だけで二重入力を減らせる場合があります。
一方向連携だけで十分なケースは多い
中小企業では、最初から双方向連携を目指す必要はありません。たとえば「販売管理システム → kintone」だけでも、得意先、受注番号、商品、数量、売上予定を反映できれば、かなりの入力作業を削減できます。営業担当者は、そのデータに対して「納期確認中」「メーカー回答待ち」「顧客へ連絡済み」などkintoneでしか管理しない情報だけを追加します。
本当にリアルタイム連携が必要か考える
連携を検討すると、「入力したら1秒後にkintoneへ反映したい」と考えがちです。しかし、営業会議で翌朝確認できればよい情報なら、1日1回でも十分かもしれません。まずは「即時反映が必要」「1時間ごとでよい」「1日1回でよい」「営業会議前だけでよい」のように必要な更新頻度を決めましょう。
方法2|kintoneのAPI・連携サービス・プラグインを確認する
APIとは「システム同士がデータをやり取りする入口」
APIという言葉を難しく考える必要はありません。簡単に言えば、システムAとシステムBが自動で情報を渡し合うための入口です。kintoneのREST APIでは、レコードの取得・登録・更新・削除などの操作が提供されています。そのため、基幹側にもAPIや外部連携機能があれば、「基幹で新しい受注が登録されたら、kintoneにも案件レコードを作る」といった仕組みを検討できます。
プラグインや連携サービスで開発を減らせる場合もある
すべてを自社開発する必要はありません。既存の連携サービスやプラグインで対応できる場合があります。自社で一からプログラムを書くより、既存サービスで対応できないか、現在使っている基幹に専用連携がないか、販売会社や保守会社が連携オプションを提供していないかを先に調べたほうがよいでしょう。
「kintoneだから簡単につながる」とは限らない
重要なのは、kintone側だけで決まらないことです。基幹システム側がCSVを出せるか、APIを持っているか、外部アクセスを許可しているか、オンプレミスかクラウドか、データベースへ接続できるかによって難易度は変わります。特に長く使っているオンプレミス型の販売管理システムでは、外部連携できる範囲が限られている場合があります。
まずシステム会社へ「外部へ受注データを出す方法はありますか」「CSV自動出力はできますか」「APIやデータ連携機能はありますか」と確認するところから始めましょう。
方法3|Make・Zapierなどノーコード連携を検討する
CSVや専用連携だけで解決できない場合、MakeやZapierなどのノーコード連携サービスも候補になります。ノーコード連携とは、プログラムを一から書かず、複数サービスの処理をつなぐ仕組みと考えると分かりやすいでしょう。
クラウドサービス同士の連携に向きやすい
- kintoneに案件が追加されたらチャットへ通知
- フォームから問い合わせが来たらkintoneへ登録
- メールを受け取ったら担当者へ通知
- kintoneの情報を別のクラウドサービスへ渡す
プログラム開発なし、または少ない開発で作れる場合があります。
古い基幹システムとは簡単につながらないこともある
MakeやZapierを導入しただけで、すべての基幹システムと自動的につながるわけではありません。接続先にAPIがない場合や、社内ネットワーク内だけで動いているシステムの場合は、別の方法が必要になる可能性があります。「ノーコードなら何でも簡単につながる」とは考えず、基幹側の仕様を確認したうえで選びましょう。
方法4|AI転記を使うのは「例外と判断」が残った場所
CSV、API、既存連携、ノーコードで定型処理を減らした後、それでも人が読んで入力している仕事が残ることがあります。そこで初めてAIの出番です。
AIに向いている転記
たとえば、メーカーから「先日お問い合わせいただいた商品ですが、現在在庫切れです。次回入荷は10月下旬を予定しています。ただし100個以上の場合は11月初旬になる見込みです」といったメールが来たとします。従来であれば担当者がメールを読み、商品、回答内容、見込み納期、注意事項をkintoneへ入力していたかもしれません。
このような処理には「文章を読む」という判断が含まれています。AIを使えば、文章から必要項目を抽出して、入力候補を作れる可能性があります。ほかにも、注文書の形式が取引先ごとに違う、FAXで届く、PDFで届く、メール本文で注文が来る、商品名の書き方が一定ではない、備考欄を読まないと意味が分からない、といった仕事がAI活用候補になります。
AIに向かない転記
- 商品コードをそのまま移す
- 受注数量をそのまま移す
- 得意先コードを同期する
- 売上金額をコピーする
- 決まった列から決まった列へ値を移す
ルールが固定されているためです。
| 業務 | 通常連携 | AI |
|---|---|---|
| 商品コードの同期 | ◎ | △ |
| 受注数量の同期 | ◎ | △ |
| 売上金額の同期 | ◎ | △ |
| 固定CSVの取り込み | ◎ | △ |
| メール本文の読み取り | △ | ◎ |
| FAX・PDFの内容整理 | △ | ◎ |
| 自由記述の分類 | △ | ◎ |
| 例外案件の判定補助 | △ | ◎ |
AIは「何でもできるから使う」のではありません。普通の連携では扱いにくい部分だけに使うことが、安定した運用につながります。
AIが読み取った結果は重要項目ほど確認する
AIを使う場合も、完全に人を外す必要はありません。特に数量、金額、納期、商品コード、顧客名など、間違えると取引へ影響する情報は、「AIが入力候補を作る → 人が確認 → 登録」という運用から始めると安全です。
4つの連携手段を比較する

| 方法 | 向いている業務 | 導入難易度 | 柔軟性 | AI判断 | 検討優先度 |
|---|---|---|---|---|---|
| CSV連携 | 定型データの受け渡し | 低 | 低〜中 | 不要 | 最優先 |
| API・プラグイン・連携サービス | 継続的な定型連携 | 中 | 高 | 不要 | 高 |
| Make・Zapier等 | クラウド間の連携 | 中 | 高 | 基本不要 | 中 |
| AI転記 | 非定型・例外処理 | 中〜高 | 高 | 必要 | 最後 |
実際の難易度は、販売管理システム側の仕様によって大きく変わります。だからこそ、「AIを入れれば解決する」ではなく、まず基幹から何を出せるのか確認することが重要です。
一方向連携と双方向連携、どちらがよいか
最初は一方向連携を優先する
中小企業では最初から「基幹とkintoneの両方を完全に同期する」必要はありません。たとえば「基幹 → kintone」の一方向にし、基幹で確定した受注情報をkintoneへ持っていき、kintoneでは営業進捗だけを追加する形です。この形なら「受注情報は基幹が正」というルールが明確です。
双方向連携では更新の衝突が起こる
もし基幹とkintoneの両方から数量を変更できる場合、午前10時に基幹で100から120へ変更し、その1分後に営業担当がkintoneで100から110へ変更したら、最終的に何個が正しいのか分からなくなります。システム上は「最後に更新したほうを採用」「基幹を優先」「kintoneを優先」「エラーにして人が確認」などのルールが必要です。双方向にすれば便利になるとは限りません。
kintoneから基幹へ戻す情報は必要最小限にする
kintoneで営業案件を管理している場合も、すべての項目を基幹へ戻す必要はありません。営業メモやメーカーへの確認履歴はkintoneだけで完結しても問題ない場合があります。基幹へ戻す必要があるものだけを整理することが重要です。
卸売業・商社で考える二重入力解消の想定例
ここからは、実在企業ではなく想定例として3つの運用を紹介します。
想定例1|受注情報を基幹からkintoneへ反映

従来は営業事務が販売管理システムへ受注を登録したあと、営業担当がkintoneへ同じ案件を作成していました。改善後は「販売管理システムで受注登録 → 受注番号、得意先、商品、数量などをkintoneへ反映 → 営業担当は進捗項目だけを追加」という流れにします。正マスタは基幹です。営業担当は得意先名や数量を再入力する必要がなくなります。
想定例2|納期確認の途中経過だけkintoneで管理
販売管理システムには最終的な納期は登録できても、「メーカー回答待ち」「顧客確認待ち」「代替品提案中」といった途中経過を持てない会社を想定します。この場合、商品、数量、受注番号は基幹からkintoneへ反映し、「メーカー回答待ち」「回答予定日」「顧客連絡済み」など営業管理に必要な情報だけをkintoneへ持たせます。基幹を無理に改修せず、kintoneを現場が必要とする補助管理として活用する形です。
想定例3|メーカーから来る不定型メールだけAIで整理
メーカーごとに納期回答の書き方が違い、A社はExcel添付、B社はPDF、C社はメール本文、D社はFAXという場合、固定されたCSV連携だけですべて処理するのは難しいことがあります。そこで「AIが文章や書類を読み取る → 案件番号や回答納期の候補を抽出する → 担当者が内容を確認する → kintoneへ反映する」という使い方を検討します。ここではAIが本来得意な、非定型データを整理する仕事を担当します。
kintoneと基幹の連携で失敗しやすい5つのポイント
1.正マスタを決めずに双方向連携する
最も避けたいパターンです。両方で同じ項目を編集できると、どちらが正しいか分からなくなります。連携前に必ず「この項目はどちらが正か」を決めましょう。
2.すべてリアルタイムにしようとする
受注直後に即時反映が必要な情報と、翌朝までに反映されればよい情報は違います。必要以上のリアルタイム連携は、設計を複雑にする可能性があります。
3.Excelを残したままシステムだけつなぐ
基幹とkintoneを連携しても、営業会議用Excelへまた手入力していれば三重入力は完全にはなくなりません。「このExcelは何のために必要なのか」まで確認しましょう。
4.AIでできるという理由だけでAIを使う
AIで入力できることと、AIを使うべきことは同じではありません。固定ルールで処理できるものは通常連携を優先します。
5.エラー時の処理を決めていない
連携では例外が起こり得ます。得意先コードが見つからない、商品コードが一致しない、必須項目が空欄、数量形式が違う、同じ案件番号が重複している、といったときに「誰が確認するか」「どこへエラーを通知するか」「修正後にどう再処理するか」まで決めておきましょう。
中小企業ならこの順番で進める
STEP1 二重入力している項目を一覧化する
まず、基幹、kintone、Excelのそれぞれに何を入力しているか書き出します。
STEP2 正マスタを決める
得意先、商品、数量、売上、案件進捗など、項目単位で決めます。
STEP3 基幹のCSV・APIを確認する
現在使っている販売管理システムのベンダーや保守会社へ、CSV出力、定期出力、API、外部連携機能の有無を確認します。
STEP4 一方向連携から試す
まずは「基幹 → kintone」など一方向に限定すると分かりやすくなります。
STEP5 例外だけAI利用を検討する
メール、PDF、FAX、自由記述など、通常連携では処理しにくいものを洗い出します。
STEP6 Excelを廃止できるか確認する
最後に営業会議用Excelなどが残っていないか確認します。kintoneの情報を見れば会議できるのであれば、Excelそのものを廃止できる可能性があります。
連携前に確認するチェックリスト
- 基幹システムからCSVを出力できるか
- CSVには受注番号や案件番号など一意の番号があるか
- kintone側の項目と対応づけられるか
- どの程度の更新頻度が必要か
- 基幹とkintoneのどちらを正マスタにするか決まっているか
- 同じ情報をExcelにも入力していないか
- エラー時に誰が確認するか決まっているか
- 重要項目を両方から編集できる状態になっていないか
- AIを使う必要がある非定型処理が本当に残っているか
- AIの出力結果を誰が確認するか決まっているか
この10項目を整理してから業者へ相談すると、「何を自動化したいのか分からないまま見積もりを取る」状態を避けやすくなります。
まとめ|AIではなく「正マスタと連携順序」を決めることから始める
kintoneと販売管理システムを併用している卸売業・商社では、基幹で管理できない案件進捗や納期確認をkintoneで補った結果、同じ情報を二度入力する状態が生まれることがあります。さらに営業管理用Excelまで残ると、三重入力になることもあります。
しかし、だからといって「kintoneをやめる」「基幹を入れ替える」とすぐに考える必要はありません。まずは、同じデータをどこへ入力しているのか整理してください。
そのうえで、「基幹側のCSV → kintoneのAPI・連携サービスやプラグイン → Make・Zapierなどのノーコード連携 → AI転記」の順番で検討します。
そして最も重要なのが、どちらを正マスタにするか決めることです。売上や商品、数量など正式な取引情報は基幹。案件進捗や営業メモなど、基幹では管理しにくい情報はkintone。このように役割を分けると、システムを無理に一つへ統合しなくても、二重入力を減らせる可能性があります。
AIを使うのは最後です。決まった項目を決まった場所へ移すだけなら通常連携を使い、メール、PDF、FAX、自由記述など「人が読んで判断してから転記していた部分」だけAIに任せるという考え方が、中小企業では現実的です。
目的はAIを導入することではありません。社員が同じ案件を何度も入力しなくてよい業務フローを作ることです。
よくある質問
kintoneと基幹システムは連携できますか?
可能かどうかは基幹システム側の仕様によります。kintoneにはCSV等のファイルを使った入出力やREST APIが用意されていますが、基幹側から必要なデータを取り出せなければ、そのままでは連携できません。まず利用中の販売管理システムについて、CSV出力、API、外部連携機能の有無を確認してください。
CSV連携だけでも二重入力はなくせますか?
すべてではなくても、大きく減らせる可能性があります。たとえば基幹から受注番号、得意先、商品、数量をCSVで取得してkintoneへ反映できれば、その項目を再入力する必要はありません。リアルタイム性が不要なら、CSVから試す価値があります。
MakeやZapierを使えば簡単にkintoneと連携できますか?
接続する相手によります。MakeやZapierにはkintoneとの連携機能がありますが、相手側のシステムに接続手段がなければ、そのまま利用できるとは限りません。特にオンプレミス型の古い基幹システムでは事前確認が必要です。
AIで基幹システムへ直接入力させても大丈夫ですか?
技術的に実現できる場合でも、最初から重要情報を無確認で登録する運用は慎重に検討したほうがよいでしょう。特に数量、金額、納期、商品コードなどは取引へ直接影響します。まずはAIが候補を作り、人が確認して登録する運用から始める方法があります。
kintoneと基幹、どちらを正マスタにすべきですか?
システム全体ではなく、項目ごとに決めるのがおすすめです。受注数量や売上金額など正式な取引情報は基幹、案件進捗や営業メモなど現場管理情報はkintone、といった役割分担が考えられます。
ご相談・お問い合わせ
kintoneと基幹システムの二重入力は、いきなりシステムを入れ替えなくても減らせる場合があります。
まず確認したいのは、何を二重入力しているか、基幹からCSVを出せるか、どちらを正マスタにするか、一方向連携だけで解決できないか、AIを使う必要がある例外業務はどこかという点です。
現在の業務フローを整理すると、「CSVだけで十分なのか」「通常のシステム連携が必要なのか」「AIを使うべき部分があるのか」を切り分けやすくなります。
相談前には、利用中の販売管理システム名、kintoneで管理している項目、Excelで管理している項目、二重入力している内容、1日の受注件数などを整理しておくとスムーズです。
