kintone在庫管理アプリの作り方｜標準機能の範囲と同時更新対策

先に結論｜在庫管理アプリの基本構成と、同時更新エラーを避ける設計

• 基本構成: 品目マスタと入出庫明細の2アプリ。在庫数を1つのフィールドとして持たず、入出庫のたびに明細を1レコード追加します。
• 現在庫の出し方: 入出庫明細アプリのグラフ（レポート）で、品番ごとに符号付き数量を合計します。プラグインもJavaScriptも使いません。
• 同時更新エラーへの考え方: 在庫数を直接書き換えるとレコードの取り合いになり、更新の競合エラーが出ます。明細を積み上げる設計なら、取り合う対象の数値がなくなります。

この記事では、標準機能でどこまでできるかの線引きから、作り方の手順、棚卸と発注の運用、承認後の書き換え防止、失敗しやすい点までを順に説明します。

kintoneで在庫管理はどこまでできる？標準機能の範囲と、別の手段が要るケース

在庫をExcelや紙の台帳で回している現場では、入出庫のたびに手集計をするうちに、本社の在庫表と倉庫の実数が合わなくなることが珍しくありません。kintoneで在庫管理アプリを作るとき、最初に知っておきたいのは「標準機能だけでどこまで届くか」です。公式ヘルプで確認できた範囲で整理します。

実現したいこと	標準機能での扱い（確認できた範囲）
品目の基本情報を持つ	アプリのフィールドで持てる（品目マスタ）
入出庫を記録する	入出庫のたびにレコードを追加する
品番ごとの現在庫を見る	グラフ（レポート）の集計で出せる。集計方法は「レコード数」「合計」「平均」「最大値」「最小値」の5種類
承認の流れを作る	プロセス管理で設定できる
承認済みの数字を守る	レコード単位のアクセス権で閲覧のみにできる。フィールド単位の編集不可は標準機能にない
複数アプリの値を1画面に自動で集約する	専用のダッシュボードは標準機能にない。関連レコード一覧フィールドは集計の対象にならない
レコード編集中に他の人の編集をロックする	そのような機能はない

最後の2行が、標準機能だけで作るときの限界です。ここから先、たとえば在庫を直接更新しながら競合を防ぎたい場合は、REST APIとJavaScriptによる追加開発が前提になります。ロット・期限の管理、バーコード入力、アプリ間での在庫引当、大量データの扱いなどが必要な場合も、標準機能の外側の話になります。

これらをプラグインで補えるかどうかは、各プラグインの公式ページで対応範囲・価格・前提アプリ数を確認してください。この記事ではそれらの仕様を確認できていないため、できるともできないとも書きません。サイボウズの公式サンプルアプリや導入事例にも在庫管理を扱うものがあるようですが、内容や成果の数字は、公式の事例ページで元の記述を確かめてから参考にしてください。

在庫管理に必要なアプリ構成｜品目マスタと入出庫明細

最初のつまずきは、同時更新のような技術的な問題より、「何から作ればいいのか」という入口にあります。とりあえずフィールドを並べて動くものを作っても、運用が始まってから数字が合わなくなり、Excelとの二重管理に逆戻りする、という流れは典型的です。

基本になるのは次の2つのアプリです。

1. 品目マスタ: 品番・品名など、扱う商品や資材の基本情報を持つアプリ
2. 入出庫明細: 入庫・出庫が起きるたびに1レコードずつ追加するアプリ

ここで最初の分かれ道があります。「在庫数」という1つの数字を入出庫のたびに書き換えるか、記録を積み上げてそこから在庫数を計算するか、という選択です。前者は一見シンプルですが、複数人が同時に使う環境では次の章の壁にぶつかります。

在庫数を直接更新する設計が招く、同時更新エラーの正体

複数人がほぼ同時に同じ在庫レコードを更新しようとすると、最初に保存が完了した1人だけが成功します。残りのユーザーには「レコードを再読み込みしてください。編集中に、ほかのユーザーがレコードを更新しました。」という更新の競合エラーが表示され、保存できません。kintoneには、レコード編集中に他ユーザーの編集をロックする機能がありません。

「在庫数」というフィールドを入庫のたび、出庫のたびに書き換え続ける設計では、同じレコードを取り合う構造が残ります。担当者や拠点が増えるほど、競合は「たまに起きる不具合」ではなく「構造上いずれ起きる現象」になります。棚卸のたびに数字が合わない、結局Excelに戻った、という状況の背景には、この仕様がある場合があります。複数人での入力ルールの定着については、kintone日報アプリの作り方と運用定着のコツも参考になります。

サイボウズが公式に案内している対策の一つに、レコード取得時のリビジョン値を更新APIに指定し、他ユーザーの変更があれば更新をキャンセルする技術があります。ただしREST APIとJavaScriptによる追加開発が前提で、在庫数フィールドを直接更新する設計を前提にしています。標準の画面操作だけで運用したい現場では、採用のハードルが高くなります。

そこで発想を変えます。「在庫数を書き換える」のではなく「入出庫のたびに新しいレコードを追加する」設計にします。複数人が同時に操作しても、各自が独立した新規レコードを追加するだけです。競合エラーは「同じレコードを更新しようとした」ときに出るものなので、取り合う対象がなくなります。現在庫は、特定の1レコードが持つ数値ではなく、積み上がった明細を合計した結果として求めます。

これは公式ドキュメントの仕様から導いた設計上の考え方です。「レコード追加なら競合が絶対に起きない」と公式が明言しているわけではありません。それでも、在庫数を直接書き換える設計より、競合が起きる条件を大きく減らせます。

作り方の手順｜フィールド構成・符号付き数量・グラフで現在庫を出す

入出庫明細アプリのフィールドは次のとおりです。この構成表がフィールド型の唯一の基準です。

入出庫明細アプリのフィールド構成

セクション	フィールド	型
基本情報	品番、品名	文字列(ルックアップ)
基本情報	処理日、担当者	日付／ユーザー
入出庫情報	区分	選択肢(入庫／出庫)
入出庫情報	数量	数値
集計用	符号付き数量	計算(数値表示)
管理	備考	複数行

承認の状態（未処理・処理中・完了）は、フィールドではなくプロセス管理のステータスで持ちます。後の章で設定します。

品番・品名は、品目マスタからルックアップ（別アプリのレコードを検索し、指定したフィールドの値をコピーする機能）で呼び出します。コピーされた値が品目マスタ側の変更に自動で追従するかどうかは確認できていません。明細に記録される品名は、入出庫時点のスナップショットとして扱うのが安全です。

数量フィールドで押さえたいのは「値の制限」です。フィールドの設定パネルで最小値を0にすれば、マイナスの数量そのものを入力できなくできます。出庫は数量を負にせず、区分（入庫／出庫）で表現します。

数量フィールドの設定内容

設定項目	値
フィールドタイプ	数値
値の制限(最小値)	0

そのうえで、符号付き数量という計算フィールドを次の式で自動計算させます。

IF(区分 = "出庫", -数量, 数量)

IF関数は「IF(条件式, 真の場合の値, 偽の場合の値)」という書式です。区分が「出庫」かどうかを=で判定し、出庫のときだけ符号を反転させます。出庫は自動的にマイナスの数量になり、あとは合計するだけで現在庫を導けます。なお、値の制限を設定しない既定の状態でマイナスを入力できるかどうかは、公式ヘルプに明記が見当たりません。この設計は、最小値の制限と計算フィールドの組み合わせで、その不確定要素に依存しない形にしています。

現在庫は、入出庫明細アプリのグラフ（レポート）で見ます。計算フィールドはグラフの集計対象にできます。複数データの集計表示については、進捗管理ダッシュボードの設計も参考になります。

グラフの設定内容(在庫集計用)

設定項目	値
グループ化項目(大項目)	品番
集計方法	合計
対象フィールド	符号付き数量(数値の計算フィールド)

上の画像は、グラフ作成フォームの操作を見せるための例です。写っているのは「分類する項目＝区分」「集計方法＝レコード数」の設定で、在庫集計用の設定（品番×合計×符号付き数量）そのものではありません。実際の在庫集計では、表の3項目を指定してください。

集計方法は5種類のみで、入庫合計と出庫合計を別々に出して差分を取る計算は、この集計方法だけでは表現できません。符号付き数量にあらかじめ正負を織り込むのは、この制約を回避する工夫です。

この時点では、ステータスを問わずすべての明細が合計に含まれます。未承認の申請中の明細も現在庫に反映されるため、扱いは後の章で説明します。また、関連レコード一覧フィールドには集計機能がないため、現在庫の確認はこのグラフ経由になります。品目マスタの画面に品番ごとの現在庫が自動で表示される形ではない点も、あらかじめ知っておいてください。まとめて見たい場合は、スペースやポータルにグラフを貼る運用になります。

ここまでの設計は、フィールドの型・値の制限・計算式・グラフの集計軸を一つずつ組み合わせる作業なので、最初は迷うところも多いはずです。ここでつまずいたら、無料相談で画面を見ながら一緒に確認できます。

発注点割れと棚卸の設計｜欠品と数字のズレを防ぐ運用

在庫アプリの価値は、数字が見えることより、欠品や数字のズレに早く気づけることにあります。標準機能の範囲で考えられる運用を整理します。

発注点割れに気づく

この設計では、現在庫はグラフでしか出ません。品目マスタに「発注点」のフィールドを持たせることはできますが、グラフの合計と発注点が自動で突き合わされて通知される、という仕組みは、この記事では確認できていません。リマインダー（条件通知）の設定方法も、公式ヘルプで確認する範囲が残っています。まずは次の運用で始め、自動通知に載せられるかは公式ヘルプで確かめてください。

• 品目マスタに発注点を持たせ、基準を現場と合意しておく
• 決めた曜日にグラフを開き、発注点を下回る品番を確認する担当を置く

棚卸で数字を合わせる

棚卸のたびに数字が合わない悩みには、実地数量を現在庫の欄に上書きしない運用が向いています。実地で数えた結果が帳簿の合計と違った場合は、その差を調整用の明細として1件追加します。たとえば帳簿より実地が少なければ、差の数量を出庫の明細として追加し、備考に「棚卸調整」と書きます。これなら、いつ誰がいくつ調整したかが履歴に残り、履歴を消して数字だけ合わせる事態になりません。

棚卸の時点では、未処理・処理中の申請が残っていないかも確認してください。これらもグラフの合計に含まれているためです。

承認フローとアクセス権で、承認済みの数字を書き換えさせない

入出庫明細を誰でも自由に追加・修正できる状態だと、今度は「本当に出庫した数量なのか」というデータの信頼性の問題が出ます。ここでプロセス管理を使います。進捗管理にステータスを使う例はkintone案件管理アプリの作り方｜基本フィールドと進捗管理も参考になります。承認フローに担わせる役割は、集計を絞り込むことではなく、承認が済んだ数字を書き換えさせないことの一点です。

設定手順は次のとおりです。

1. アプリの設定でプロセス管理を有効にする
2. ステータスは初期値の「未処理」「処理中」「完了」をそのまま使う（名称は変更できますが、この記事では変更しません）
3. 各ステータスにプロセスを設定する（作業者、アクションが実行できる条件、アクション名、実行後のステータス）。未処理→処理中のアクション名を「処理開始」、処理中→完了のアクション名を「完了する」にする
4. プロセスのフロー図で流れを確認する
5. アプリを更新する

承認済みの数字を守るのは、計算フィールドではなくアプリのアクセス権です。アクセス権の設定で、条件を「ステータスが完了を含む」、対象レコードの権限を「閲覧のみ」にします。いったん完了した明細は、数量を含めて編集・削除できなくなります。未処理・処理中の間は、まだ修正できる状態です。

統制できる粒度には注意してください。特定のステータスのときに数量フィールドだけを編集不可にする、というフィールド単位の制御は標準機能にありません。実現できるのは、ステータス条件と組み合わせた、レコード単位の権限制御です。「完了した明細はレコード全体が編集不可になる」という粒度で理解しておくと、期待値のずれを防げます。

プロセス管理とアクセス権の設定内容

区分	設定項目	内容
プロセス管理	ステータス	未処理、処理中、完了(初期値のまま変更しない)
プロセス管理	アクション	処理開始(未処理→処理中)、完了する(処理中→完了)
アクセス権	条件	ステータスが完了を含む場合は閲覧のみに設定

自作・テンプレートの選び方

ここまでの設計（明細を積み上げ、グラフで合計する）は、プラグインやJavaScriptを使わず標準機能だけで再現できます。試行錯誤する時間が取りにくい場合は、あらかじめ形になったテンプレートから始める選択肢もあります。ただし、この記事の設計と当社の「在庫管理スターターパック」は、設計方式が違います。

• この記事の設計: 入出庫を明細として積み上げ、グラフで現在庫を出す（積み上げ型）
• 在庫管理スターターパック: 品目マスタと入出庫申請の2アプリ構成で、在庫数を直接編集させず、申請→承認→在庫反映のプロセス管理を設定済みにした申請フロー型

この記事の手順をそのままパック化したものではありません。どちらの方式が自社に合うかは、使い方で選んでください。

自作とテンプレートの比較

項目	自作（この記事の設計）	在庫管理スターターパック
設計方式	入出庫明細を積み上げる	申請フロー型（申請→承認→在庫反映）
価格	0円（自分の作業時間はかかる）	¥9,800（買い切り）
プラグイン・JS	不使用	不使用

自作するかテンプレートを使うかは、社内にkintoneの設計に慣れた担当者がいるか、かけられる時間があるかで決まります。開発パートナーに相談する場合は、外注の際のチェックリストも参照してください。詳しい構成は在庫管理スターターパックのページで確認できます。

導入で失敗しないための注意点とまとめ

最後に、設計とは別に、在庫アプリの運用で起きやすいつまずきを挙げます。ここに書くのは、これまで説明した設計から導いた一般的な注意点です。

1. 最小構成から始める: 品目マスタと入出庫明細の2アプリで動かし、必要が出てから足します。
2. 在庫の粒度を現場と合意する: 品番単位か、ロット・棚番単位かで、フィールドとグラフの集計軸が変わります。
3. 体制と権限を先に決める: 誰が明細を追加し、誰が承認し、誰が完了後の明細を見られるかを、アクセス権と合わせて決めます。運用の責任者も決めておきます。
4. 外部システムとの連携を洗い出す: 販売や会計のシステムと数字を突き合わせる運用がある場合は、標準機能の外側の話になるので、最初に確認します。
5. 移行と教育の段取りを置く: 既存のExcelの数字を初期在庫としてどう入れるか、入力ルールを現場にどう伝えるかを決めておきます。

kintoneで在庫管理アプリを作る基本は、品目マスタと入出庫記録の2アプリ構成にし、在庫数を1つのフィールドとして直接書き換えない設計にすることです。入出庫のたびに明細を積み上げ、現在庫はグラフの集計で導けば、複数人が同時に操作しても競合が起きにくい状態を作れます。プロセス管理による承認と、完了レコードを閲覧のみにするアクセス権を組み合わせれば、承認済みの数字は書き換えられません。ただし、集計の対象はステータスを問わず全明細のままなので、未処理・処理中の申請が残っていないかは運用側で確認する必要があります。

どちらのルートを選んでも、品番ごとの現在庫をグラフの集計から確認できる仕組みは組み立てられます。ただし、棚卸のたびに数字が合わない状態が実際に減るかどうかは、別の問題です。入出庫のたびに明細を登録し、承認を通す入力ルールを現場に定着させて初めて、効果は現れます。まずは、これから作る、あるいは今使っている在庫アプリが、在庫数を直接書き換える設計になっていないか、一度見直してみてください。