製造業の在庫・受発注管理、SaaSやkintoneの限界を感じたら何を検討すべきか【2026年8月版】
kintoneやクラウド在庫管理ツールで在庫・受発注管理を始めたものの、「ロットごとの追跡が難しい」「複数人が同時に触ると数字がずれる」といった壁にぶつかっていませんか。
kintoneは東証プライム上場企業の3社に1社が導入しているとされるほど普及が進んでおり、在庫管理でも豊富なプラグインとAPIによるカスタマイズ性の高さが評価されています。ただし、その柔軟性ゆえに「どこまでプラグインでカバーできて、どこから自社開発が必要になるのか」の見極めが難しく、気づけばプラグインを積み重ねた複雑な構成になっていた、というケースも珍しくありません。
SaaS・ノーコードツールは、導入のしやすさから中小製造業でも広く使われています。ただし、製造業特有の要件——ロット管理・トレーサビリティ・複数拠点での同時運用——が絡んでくると、標準機能や汎用プラグインだけでは対応しきれない場面が出てきます。
この記事では、実際にどのような場面で限界が表面化するのか、そして限界を感じたときにどう次の一手を考えればいいのかを、発注者目線で整理します。
先に、この記事の結論をまとめます。
- kintoneなどのノーコードツールは、複数の作業員が同時に同じ在庫を更新する場面で「競合エラー」が起きやすく、秒単位の厳密な排他制御が必要な運用には不向きなことがある
- ロット管理・トレーサビリティは、工程によっては物理的なラベル管理が難しく、システム側の工夫だけでは解決しない業務設計の問題を含む
- 「SaaSでは限界」と感じたら、まず自社の運用のどこがボトルネックかを切り分け、周辺業務はSaaSのまま残し、核となる部分だけをフルスクラッチに切り替える選択肢がある
※本記事は2026年8月時点の公開情報にもとづく整理です。
kintone等のノーコードツールで在庫管理をすると何が起きるか
kintoneは「在庫管理ができないわけではない」ツールです。ただし、標準機能だけでは対応しきれない場面があり、プラグインや外部連携を積み重ねる必要が出てきます。
在庫管理をkintoneで構築する場合、標準機能とプラグイン・外部サービスとの連携を組み合わせるのが一般的です。ただし、次のような限界に直面することがあります。
- 複数人による同時更新の競合: 複数の作業員が同時に同じ商品の在庫数を更新すると、「競合エラー」が発生することがあります。秒単位の厳密な排他制御が求められる大規模な倉庫運用には不向きな場合があります。作業員が多い現場や、出荷・入荷のピーク時間帯に更新が集中する現場ほど、この問題が顕在化しやすくなります
- プラグイン・外部連携の積み重ね: 発注書の自動作成、他システムとの連携など、必要な機能を1つずつプラグインや外部サービスで補っていくうちに、運用が複雑になりがちです。プラグインごとに個別の設定・保守が必要になり、担当者が変わるたびに「なぜこの設定になっているのか」が分からなくなるという属人化のリスクも抱えます
- ロット管理・トレーサビリティの限界: 熱処理や外注工程など、物理的なラベルを貼り付けられない工程があると、正確な追跡が難しくなります。これはシステムの問題というより、業務プロセス自体の設計を含めた課題です。ロット番号の重複・誤読・追跡の煩雑さといった課題は、Excelでの手動管理でもよく起きる問題で、システムを変えるだけで自動的に解決するとは限りません
これらは「kintoneが悪い」という話ではありません。汎用ツールが前提とする運用と、製造業特有の運用にズレがあるときに表面化する、という理解が実務的です。
「SaaSの限界」を感じたら、何から検討すべきか
まず自社の運用のどこがボトルネックになっているかを切り分けることが第一歩です。全部をフルスクラッチに置き換える必要はなく、周辺業務はSaaSのまま残し、核となる部分だけを作り込む選択肢もあります。
- ボトルネックの特定: 「同時更新の競合が頻発する」のか、「ロット追跡ができない」のか、「他システムとの連携が破綻している」のか。原因によって解決策が変わります。この段階を飛ばして「とりあえずフルスクラッチにする」と決めてしまうと、本来SaaSの設定変更だけで解決できた問題まで大規模な開発対象にしてしまうリスクがあります
- 周辺業務とコア業務の切り分け: 経理・勤怠管理などの定型業務はSaaSのまま残し、在庫・ロット管理など自社の運用に直結する部分だけをフルスクラッチで作り込む、という併用が現実的です。「全部を作り直す」と「全部SaaSのまま我慢する」の間には、幅広い選択肢があります
- 段階的な移行: 一度に全システムを置き換えるのではなく、影響の大きい業務から順に移行することで、リスクとコストを抑えられます。最初の移行対象は、最も業務への影響が大きく、かつ効果が見えやすい範囲を選ぶのが定石です
この考え方は、パッケージからフルスクラッチへの刷新を検討する場合とも共通しています。判断軸については中小製造業の基幹システム刷新、ERPパッケージとフルスクラッチどちらを選ぶかでも整理しています。
他システムとの連携で起きがちな問題
在庫管理・受発注管理は、会計ソフトや生産管理システムなど、他のシステムと連携して初めて業務全体が回ります。SaaS同士の連携が不十分だと、データの二重入力という見えにくいコストが発生します。
複数のシステムを組み合わせて運用していると、次のような問題が起きがちです。
- データの二重入力: 在庫管理システムと会計ソフトが連携していないと、同じ情報を両方に手入力する手間が発生します。これは単なる手間の問題だけでなく、入力ミス・入力漏れによるデータの不整合を招く原因にもなります。営業所と経理部のように、部署をまたいで同じ情報を別々に入力しているケースは特に見落とされがちです
- 連携できる範囲の制約: SaaS同士の連携はAPIやCSV連携で実現されることが多いですが、対応していないシステムの組み合わせや、連携できても一部の項目しか同期できないケースがあります。「連携機能はあるが、自社が必要な項目は同期対象外だった」というケースも実務ではよく起きます
- リアルタイム性の欠如: CSV連携の場合、日次・週次などのバッチ処理でデータを同期することが多く、リアルタイムでの在庫状況把握が難しいことがあります。出荷判断や発注判断をリアルタイムのデータで行いたい場合、このタイムラグが業務上の支障になることがあります
- カスタマイズの限界: 標準の連携機能だけでは自社の業務フローに合わない場合、追加のプラグインや外部ツールを組み合わせる必要が出てきます。組み合わせが増えるほど、どこで問題が起きているかの切り分けが難しくなります
API連携が可能な組み合わせであれば、生産の進捗データや在庫の入出庫情報を自動で会計システムに反映し、二重入力を解消できます。ただし、自社が使っているシステムの組み合わせがAPI連携に対応しているかどうかは、事前に確認が必要です。対応していない組み合わせの場合、連携部分だけをフルスクラッチで開発し、間を橋渡しする、という選択肢も検討の余地があります。
実際に多くの企業で見られるのは、営業部門と経理部門、あるいは製造現場と管理部門が別々のシステムで同じ受注情報・在庫情報を管理しているようなケースです。API連携が可能なシステムの組み合わせを選んでいれば、生産管理システムからの進捗データや在庫の入出庫情報を自動で会計に反映でき、手動でのデータ入力を大幅に削減できます。逆に、こうした連携ができないままシステムを増やしていくと、業務効率化のためのツール導入が、かえって作業量を増やしてしまう本末転倒な状態に陥りかねません。
SaaSからフルスクラッチへ移行する場合の進め方
いきなり全システムを置き換えるのではなく、最も課題を感じている業務から段階的に移行するのが現実的です。
- 現状の運用を棚卸しする: どのSaaSを、何のために、誰が使っているかを整理します。あわせて、データの二重入力がどこで発生しているかも洗い出します。この段階で、現場担当者へのヒアリングを丁寧に行うことが、後の設計の精度を左右します
- ボトルネックを特定する: 競合エラーなのか、ロット管理なのか、他システムとの連携なのか。原因によって、移行すべき範囲・優先順位が変わります
- 移行範囲を決める: 全業務を一度に置き換えるのではなく、最も課題が大きい業務（例: 在庫のロット管理）から着手します。範囲を絞ることで、移行にかかる期間・費用のコントロールがしやすくなります
- 並行運用の期間を設ける: 新システムと旧システム（SaaS）を並行して稼働させ、データの整合性を確認しながら段階的に切り替えます。並行運用の期間を短く切り上げすぎると、想定外の不具合に対応する余裕がなくなるため、十分な検証期間を確保することをおすすめします
- 周辺業務との連携を設計する: 移行した業務と、引き続きSaaSで運用する業務との間のデータ連携を設計します。ここを軽視すると、移行後も結局データの二重入力が残ってしまい、当初の目的が達成できません
この進め方であれば、業務を止めることなく、段階的にフルスクラッチへの移行を進められます。急いで一度に全部を切り替えようとすると、現場の混乱や想定外のトラブルにつながりやすいため、焦らず段階を踏むことが結果的に近道になります。
発注先を選ぶときに確認しておきたいこと
SaaSの限界に対応した開発を依頼する場合、「なぜSaaSでは対応できないのか」を正しく理解した上で提案してくれる発注先を選ぶことが重要です。
- ボトルネックの診断力: 「SaaSの限界」と一言でいっても原因は様々です。競合エラーなのか、ロット管理なのか、他システム連携なのかを正確に診断できるか。「とりあえず全部フルスクラッチにしましょう」という提案しかできない発注先は、診断が不十分な可能性があります
- 既存SaaSとの共存設計: 全部をフルスクラッチに置き換えるのではなく、周辺業務はSaaSのまま残す設計を提案できるか。既存のSaaS運用を無理に否定せず、必要な部分だけを見極める提案力が重要です
- API連携・データ移行の実績: 既存のSaaSやシステムとのデータ連携、移行作業の実績があるか。連携部分の設計・実装は、想定以上に手間がかかることが多い工程です
- 製造業の業務理解: ロット管理・トレーサビリティなど、製造業特有の要件を理解した上で設計できるか
- 段階的な移行提案: 一括での全面刷新だけでなく、影響の大きい業務から順に区切って進める提案ができるか
SaaSの限界を感じている部分を具体的に伝えられる状態で相談すると、発注先とのすり合わせがスムーズに進みます。「何がどう困っているか」を事前に整理しておくことは、見積もりの精度を上げることにもつながります。
SaaSの月額費用と、移行にかかる費用感の考え方
SaaSは月額費用が積み重なる料金体系、フルスクラッチは初期費用がまとまってかかる料金体系という違いがあります。長期的な視点で比較することをおすすめします。
SaaS・kintoneのようなノーコードツールは、初期費用を抑えて始められる一方、月額利用料・プラグイン費用が継続的にかかります。ユーザー数やプラグインの数が増えるほど、月額費用も積み上がっていく傾向があります。
一方でフルスクラッチは、初期の開発費用はまとまった金額になりますが、その後の月額費用は保守費用程度に抑えられることが一般的です。長期的に見ると、次のような視点で比較することが現実的です。
- 今後何年、その業務システムを使い続ける予定か: 短期的な利用であればSaaSの月額費用の方が有利なことが多く、長期的に使い続ける前提であれば、初期投資をかけてでもフルスクラッチにする方が総コストを抑えられることがあります
- ユーザー数・利用範囲の拡大予定: SaaSは利用者数に応じて費用が増える料金体系が多く、組織の拡大とともに月額費用も増加します
- カスタマイズの積み重ね状況: 既にプラグイン・外部連携を複数積み重ねている場合、その運用・保守にかかっている見えないコスト（担当者の工数等）も含めて比較することをおすすめします
具体的な費用相場の目安は中小製造業の基幹システム刷新、費用と期間はどれくらいかで整理しています。
なお、同じ「SaaSの限界」でも、業種によって表面化しやすいポイントは異なります。取引先ごとに異なるEDI形式や複数拠点の在庫管理が課題になりやすい物流・卸売業のケースは物流・卸売業の受発注・在庫管理、SaaSの限界からフルスクラッチ刷新を考えるで整理しています。
よくある質問
Q. kintoneをやめて、全部フルスクラッチにすべきですか？
A. 必ずしもそうとは限りません。kintoneが対応できている業務はそのまま残し、競合エラーやロット管理など、SaaSでは解決しにくい部分だけをフルスクラッチで補う、という併用も現実的な選択肢です。まずはボトルネックがどこにあるかを切り分けることをおすすめします。
Q. ロット管理・トレーサビリティは、システムを変えれば解決しますか？
A. システムだけの問題ではないケースがあります。熱処理や外注工程のように、物理的なラベル管理自体が難しい工程がある場合、システム刷新と合わせて業務プロセスの設計も見直す必要があります。
Q. 複数拠点・複数人での同時運用に強いシステムにするには、何を重視すべきですか？
A. 排他制御（同時更新の競合を防ぐ仕組み）の設計が重要になります。汎用ツールのプラグインで対応しきれない場合は、自社の運用パターンに合わせた設計をフルスクラッチで作り込むことで、こうした課題に対応しやすくなります。
Q. まずは何から相談すればいいですか？
A. 「SaaSのどこに限界を感じているか」を具体的に整理した状態でご相談いただけると、話が早く進みます。競合エラー・ロット追跡・他システム連携など、症状ごとに解決のアプローチが変わるためです。
まとめ：SaaSの限界は「切り分け」から始まる
最後に、本記事の要点を整理します。
- kintone等のノーコードツールは、複数人による同時更新やロット管理・トレーサビリティで限界を迎えることがある。ツールの普及度・カスタマイズ性の高さゆえに、プラグインを積み重ねた複雑な構成になりがちな点にも注意が必要
- これはツールの欠陥ではなく、汎用ツールの前提と製造業特有の運用のズレから生じる。ロット管理のような課題は、システムを変えるだけで自動的に解決するとは限らず、業務プロセスの設計を含めた対応が必要になる
- 他システムとの連携が不十分だと、データの二重入力という見えにくいコストが発生する。API連携が可能な組み合わせであれば自動化できるが、対応していない場合は連携部分の開発を検討する余地がある
- 「SaaSの限界」を感じたら、まずボトルネックを切り分け、周辺業務はSaaSのまま残しつつ核となる部分だけをフルスクラッチにする選択肢がある
- 段階的な移行により、業務を止めることなく、リスクとコストを抑えながら刷新を進められる。並行運用の期間を設け、データの整合性を確認しながら切り替えるのが定石
- 発注先を選ぶ際は、ボトルネックを正確に診断できるか、既存SaaSとの共存設計を提案できるかを確認する
「kintoneで在庫管理をしているが、そろそろ限界を感じている」という段階のご相談でも構いません。まずは現状の運用のどこに課題があるか、お問い合わせください。
具体的に検討する段階になったら、SaaSの限界からフルスクラッチへの移行の進め方をまとめたSaaSの限界からのフルスクラッチ移行もあわせてご覧ください。
※本記事に記載した内容は2026年8月時点の公開情報にもとづく整理です。
運営・編集