販売管理システムのような基幹システムとkintoneをつなぎたい。
そう考えたとき、まずSIerへの相談が頭に浮かぶ方は多いのではないでしょうか。
見積もりを取ると、要件定義から始まる数か月のプロジェクトとして数百万円規模の金額が返ってきます。
その金額を前に、検討が止まったままという会社もあるはずです。
この記事では、販売管理システムとkintoneをn8nでつないだ記録をまとめます。
kintoneで入力した受注を販売管理へ自動登録するまでを、自社の検証環境で試しました。
結論から言えば、 実装自体は半日で終わりましたが、ハマりポイントが３箇所ありましたので共有します。
目次
販売管理とkintoneの連携は、SIerに頼まないと実装できないのか
販売管理とkintoneの連携は、多くの会社で「SIerに頼む大掛かりな開発案件」として棚上げされています。
棚上げされる理由は、判断材料が手元にないからです。
受注・売上・在庫を販売管理で扱い、現場はkintoneを触っている。
この2つをつなぎたいという要望は、製造業のDX推進担当者から繰り返し出てきます。
ところが、それが自社でできる規模の話なのか、専門の開発会社に任せるべき話なのかを見極める材料がありません。
たとえば連携をSIerに相談すると、要件定義から始まる数か月のプロジェクトとして見積もりが返ってきます。
金額は数百万円規模になり、稟議に上げても通る見込みが薄いと感じてしまう。
かといって自社で手を出せる範囲かどうかも判断できないため、そこで検討が止まります。
そこで、本当にSIerに頼まなければ実装できないのかを、自分の手でたしかめてみました。
n8nを挟めば、kintoneで入力した受注は販売管理に半日で流せる
結論として、自動化ツールのn8nを挟むことで、作業時間は半日ほどでkintoneで入力した受注を販売管理へ登録するところまでが動きました。
なお、n8nそのものについては別記事で扱っています。
ツールの概要から知りたい方は【超入門】n8nとは？kintoneと生成AI連携のはじめかたをご覧ください。
社内サーバーで動かす方法はn8nの「セルフホスティング」で安全にkintoneと連携！料金や導入手順を紹介で解説しています。
本記事では、n8nがすでに動いている状態を前提に進めます。
前提として、これは自社の検証環境で実施した記録であり、手を動かしたのはエンジニアではない担当者です。
顧客の本番環境ではなく、応研の「大臣AXクラウド」とkintoneを用意しました。
大臣AXクラウドは会計や販売管理などを載せるクラウド基盤で、今回つないだのは販売管理を担う「販売大臣AX」の受注・売上伝票です。
API連携が可能かどうかも分からない状態からの着手でした。
最終的にゴールは、このようなものになりました。
- kintoneの受注アプリでレコードを登録すると、販売管理に売上伝票が作られる
- 販売管理側で採番された伝票番号が、kintoneのレコードへ自動で書き戻される
- 得意先マスタ・商品マスタは、販売管理からkintoneへ同期しておく
紙とExcelの転記をなくし、現場の入力を販売管理へ自動反映する
この構成を組む目的は、現場と販売管理のあいだに挟まった転記作業をなくすことです。
ここでいう現場とは、受注を受け付ける営業事務・出荷担当を指します。
今回の検証で想定した入力の経路は、3段階に分かれていました。
- 現場が紙の伝票に書く
- 事務がExcelに打ち直す
- 誰かがあとから販売管理へ転記する
同じデータを3回入力しているわけです。
なぜこの手間が残り続けるのでしょうか。今回検証した製品の場合、理由は課金方式にありました。
クライアント数課金であり、入力する人数を増やすとライセンス費がそのまま増えていきます。
検証環境のWebAPIオプションは3ライセンスで、販売管理を直接触れるのは事務・経理の数名に限られる想定でした。
同じ課金方式を採る製品であれば、同じ制約が働きます。
つまり、現場に直接入力させると費用が跳ね上がる。
だから紙とExcelで受けて、あとからまとめて転記する運用が残ります。
ライセンスを節約した分だけ、人の手が余計に動いている状態です。
ここでkintone側に入力を受け、販売管理への書き込みだけを自動化すると、構図が変わります。
現場はkintoneに打ち込み、販売管理への登録はn8nが代行する。
販売管理のユーザー数は増えないまま、入力できる人だけが増えていきます。
3段階あった経路は1段階になり、転記がまるごと消えるのです。
実装を誰が担うかという論点にも触れておきます。
手を入れる必要があるのは認証まわりに限られ、範囲は広くありません。
今回の検証も、エンジニアではない担当者がkintoneのアプリ設定の延長で進めています。
ただし、社内で手を動かす時間を確保できるかどうかは別の問題になります。
技術的に可能かどうかと、社内で回せるかどうかを分けて考えてください。
公式ドキュメントに書いていない場所で3回止まった
「APIがあるならすぐ実装できるだろう」と考えて着手しましたが、実際にはコードを書く前の段階で3回止まりました。
止まった理由は「APIがあるかどうか」ではなく、「そのAPIを叩ける状態にあるか」でした。
契約していても、対象ユーザーにライセンスが割り当たっていないとAPIは呼べない
1つ目の壁は、認可画面にたどり着く手前にありました。
アクセスした瞬間に、次のエラーで弾かれます。
ライセンスが無効です。このユーザーにライセンスが割り当てられていないか、または上限を超えて割り当てられています
契約はしていたにも関わらず、弾かれた原因は、ライセンスがユーザー単位で管理されている点にあります。
契約数を確保するだけでは足りず、APIを使うユーザーへの割り当てが別途必要でした。
さらに厄介だったのが、その割り当て操作の場所です。
Windows専用のデスクトップ管理ツールからしか実行できず、ブラウザの管理ポータルには項目自体がありません。
筆者はMacで作業していたため自分では手が出せず、担当者に依頼して待つことになりました。
自社で確認するときは、契約数ではなく「自分のユーザーに割り当たっているか」を見てください。
なお、Web API連携の仕様そのものは応研の販売大臣AX公式ページで公開されています。
通常のOAuth2を通しただけでは、ほとんどのAPIが呼べない
2つ目の壁は、認証の構造そのものでした。
この販売管理システムは、一般的なOAuth 2.0に加えて、会社とデータ領域を指定する独自の認証ステップを持っています。
1段目のOAuth2を通しただけでは、ほとんどのAPIが呼び出せません。
2段目を通して初めて、伝票の登録やマスタの取得が可能になります。
しかも2段目の仕様が、n8nの標準機能と噛み合いませんでした。
独自ステップは、1段目で取得したトークンをリクエストボディに入れて送る形式です。
ところがn8nの標準OAuth2機能は、独自方式の追加ステップに対応していません。
保管しているトークンの値を取り出して別の場所に差し込む使い方も想定されていません。
結果として、認証処理をすべて手組みし直すことになりました。
標準機能があるから設定だけで済むと考えていた分、この作り直しは想定外でした。
リフレッシュトークンは1回使うと無効になる
3つ目が、いちばん痛い失敗です。
このシステムのリフレッシュトークンは、1回使うと無効になります。
更新のたびに新しい値が発行され、古い値は即座に使えなくなる仕様でした。
気づかないまま、更新のたびに手作業で値を貼り替えていました。
ここまでなら、手間がかかるだけで済みます。
問題はその先です。
更新に失敗したときにも保存処理が走る作りにしてしまい、空の値で上書きしてしまいました。
有効なリフレッシュトークンは、これで完全に失われます。
認証が一度は動いていただけに、原因の特定にも時間がかかってしまいました。
3回止まったあとにたどり着いた、つなぎ方の設計
同じ場所で止まらないために、最終的に落ち着いた設計を共有します。
順に手を入れれば、認証まわりの事故はほぼ防げるはずです。
なぜ設計の話から入るのかというと、認証の詰まりはワークフローの組み方に起因しているからです。
APIを1本ずつ動かすだけなら、力技でも通ります。
運用に載せた瞬間に壊れるのは、トークンの扱いが分散しているときです。
トークンの処理は、最初から1本のワークフローに切り出す
トークンの取得と更新は、共通のワークフローとして独立させてください。
APIごとにワークフローを作ると、認証処理が各所にコピーされます。
仕様の理解が変わったとき、すべてのワークフローを直す羽目になります。
1本に切り出しておけば、修正箇所は常に1か所です。
更新に失敗したときは、絶対に保存しない
トークンの更新結果は、成功をたしかめてから保存してください。
具体的には、レスポンスのステータスコードを確認し、成功していなければそこで処理を止めます。
3つ目の落とし穴を再発させないための、直接の対策です。
認証エラー時に保存しないという判断が、いちばんの安全策になります。
アクセストークンをキャッシュして、更新の回数そのものを減らす
有効期限内のアクセストークンは、使い回してください。
リフレッシュトークンは単一の資源です。
複数の処理が同時に更新をかけると、必ず競合します。
片方の更新が成功した時点で、もう片方が持っている値は無効になるためです。
キャッシュを挟んで更新回数を減らせば、競合そのものが起こりにくくなります。
伝票を送る前に、商品マスタをkintone側にそろえておく
マスタの同期は、伝票連携より先に済ませてください。
伝票を登録するとき、得意先名や税区分は販売管理システムがマスタから自動で補完します。
ところが単価だけは補完されません。
kintone側に商品マスタを持っておけば、そこから単価を引いて送れます。
【実装担当向け】必須項目はドキュメントを読み込むより、投げてたしかめる方が早い
伝票登録APIの必須項目は、ドキュメントを精読するより、実際にリクエストを投げた方が早く分かります。
実装を担当する方への補足であり、ここは読み飛ばしても記事全体の理解に支障はありません。
早く分かる理由は、レスポンスの返し方にあります。
項目が足りない場合、どの項目が必要かを名指しでレスポンスが返してくれるためです。
最小構成で投げて、エラーメッセージに従って足していく。
この進め方がいちばん短時間で済みました。
販売管理とつながった受注データが、現場の入力そのものになる
kintoneに入力したデータは、販売管理とつながった瞬間に意味が変わります。
データがkintoneのなかで止まっているうちは、現場の記録のままです。
誰かが見て、誰かが販売管理へ打ち直す前提のデータでしかありません。
販売管理とつながると、現場が打ち込んだその1件が、会社の受注データそのものになります。
打ち直しを待つ時間も、転記ミスを探す手間も、そこで消えるのです。
そして、そこへ至る道のりで詰まる場所は3か所と分かっています。
- ライセンスが対象ユーザーに割り当たっているか
- 認証に独自のステップが追加されていないか
- リフレッシュトークンが使い捨ての仕様になっていないか
この3点を先に確認しておけば、現場が直接入力できる状態まで自社で組めます。
手を入れる必要があるのは、認証まわりだけです。
ただし、手を動かす時間を社内で確保できるかどうかは別問題になります。
そこは体制の話として切り分けて考えてください。
自社の販売管理システムで同じ構成が使えるかどうかは、APIの仕様とライセンス体系によって変わります。
判断がつかない場合は、アディエムの無料相談からお気軽にお問い合わせください。
kintoneと外部システムの連携は、販売管理以外にも応用が利きます。
kintoneの添付ファイルをn8nでBoxへ自動移動！削除なしで容量を解放する仕組みでは、同じn8nを使ってファイル整理を自動化した例を紹介しています。
関連記事
2026-06-01
Claude Codeへの初期セットアップが開発品質を決める——プロジェクト開始時にやるべきこと
在庫数が閾値を下回ったら一覧画面で赤字表示したい。 承認待ちのレコードを色分けして、ひと目で状況を把握したい。 こういった要件を、1行もコードを書かずにClaude Codeだけで実現した実験を以前行いました。 プラグインは完成しました。 ただ、振り返ると「最…
2026-05-18
1行もコードを書かずにkintoneプラグインを作れるか？Claude Codeで試してみた
「在庫数が閾値を下回ったら一覧画面で赤字表示したい。」 「承認待ちのレコードを色分けして、ひと目で状況を把握したい。」 こういった要件は、よくある小さな悩みですが、kintoneの標準機能では実現できません。 プラグインがあれば解決できるのに—— 「でも、誰が…
2026-04-05
AIと一緒にブログを書いてGitHubで自動公開——製造業のブログ量産の仕組みを作った
製造業の会社がブログを書く理由は、意外と多い。 現場の改善事例やDX取り組みを発信して取引先・顧客に実績をアピールする。 技術者・現場スタッフの採用に向けて「うちの現場はこんな仕事をしています」を伝える。 展示会出展後のフォローとして、製品の詳細情報や活用事例…
