kintone 在庫管理はどこまでできる？履歴で持つ設計と限界

「在庫をkintoneに載せたい」という相談は、たいてい同じ入り方をします。 品目マスタを作って、そこに「在庫数」という数値フィールドを付ける。 入ってきたら足して、出したら引く。作り始めた日はうまくいきます。 詰まるのはしばらく経ってから、棚の数と画面の数が違っていると気づいたときです。

このとき起きているのは「数が合っていない」という問題ではありません。合っているかどうかを確かめる手段がないという問題です。 この記事では、在庫をkintoneで扱うときに最初に決める設計の分岐と、 そのあとで必ず当たるkintoneの構造上の壁、そして向く会社と向かない会社の線を整理します。

在庫アプリで最初に出る症状は「合わない」ではなく「確かめられない」

在庫数を1つのフィールドで持つ設計は、いちばん自然に見えます。 画面を開けば今の数が書いてあり、違っていたら直せる。 kintoneはフィールドの値を編集できるので、直すのも簡単です。 この「簡単に直せる」ことが、あとで効いてきます。

ある品目の在庫数が、昨日より減っている。 この差が何なのかを、あとから説明できるでしょうか。 出荷で出ていったのか、入力ミスを見つけて誰かが直したのか、 棚を数えたら足りなかったので合わせたのか。 フィールドを上書きした時点で、前の値も、動かした理由も残りません。 残っているのは「今いくつと書いてあるか」だけです。

そして棚卸しの日が来ます。棚の数と画面の数が違う。ここで会社は困りますが、 困り方が2種類あります。原因を追える会社と、追えない会社です。 追えない会社は、差の分だけ画面の数字を書き換えて終わります。 翌月も同じ差が出て、同じ書き換えをします。在庫管理をしているつもりで、 実際にやっているのは「棚の数を画面に写す作業」です。

ここで多くの人が「kintoneでは在庫管理はできないのでは」と考えます。 ただ、詰まっているのは道具の性能ではありません。在庫を動かした事象を1件も記録していないという設計の問題です。 同じ設計でExcelに作っても、専用システムに入れても、 事象を記録しない限り差異の原因は出てきません。

在庫は「残高」ではなく「入出庫の履歴」で持つ

kintoneで在庫を扱うときの最初の分岐がここです。 在庫マスタに数を書くのをやめて、入庫・出庫・調整を1件1レコードとして積み、残高は集計で出す形にします。 在庫数というフィールドは持ちません。持たないことが設計です。

レコードは「いつ・どの品目が・いくつ・どちらに動いたか・なぜ動いたか・誰が記録したか」 を1件ずつ持ちます。入庫なら仕入や返品、出庫なら出荷や社内使用や廃棄、 調整なら棚卸しでの差異修正です。調整も必ず1レコードとして残します。 「合わせた」という行為そのものが、あとで読みたい情報だからです。

履歴型のほうが手間は増えます。増える手間は「今いくつあるか」を出すところで、 減る手間は「なぜ合わないのか」を調べるところです。 当社が相談を受けてきた範囲では、会社を止めているのは後者のほうが多い—— これは支援の現場で見てきた傾向で、統計ではありません。 棚卸しのたびに原因不明の差が出る状態は、数字が使えないだけでなく、 発注の判断も現場の信頼も削っていきます。

「マスタに数を書かない」が守れるかどうか

履歴型で作っても、あとから品目マスタに「現在庫」という便利な欄を足してしまうと、 そこが手で直され始めて元に戻ります。集計で出る数と、書かれた数が2つ並ぶと、 現場は書かれた数を見ます。1つの事実を書ける場所を2か所にしない、 という運用ルールのほうが設計より難しいところです。

履歴型にすると当たる、kintoneの構造上の壁

ここまでの設計はkintoneの標準機能で作れます。ただし、 作り進めると必ず同じ場所で止まります。止まるのは実力不足ではなく、 kintoneがそういう構造だからです。先に知っておくと、 「できないこと」を無理に標準機能で追いかけずに済みます。

前提として、サイボウズの開発者向け資料 「kintoneにおけるデータ設計の基本」には 「kintone の1つのアプリがリレーショナルデータベースの1つのテーブルに相当するように思えますが、別物として考えることが重要です」 と書かれています（2026年8月時点の掲載）。 データベース設計の感覚をそのまま持ち込むと、以下でつまずきます。

他レコードを合計して残高を書き戻す処理は、素直には組めない

kintoneの計算フィールドは、同じレコードの中にある数値を使った計算です。 入出庫アプリの全レコードを品目ごとに合計して、その結果を品目マスタの フィールドへ書き戻す——という処理は、標準機能の計算フィールドの役割ではありません。

「見る」ことはできます。一覧のグラフ・集計の機能で、品目ごとの入庫合計と出庫合計を 出して画面で確認する、という使い方は標準の範囲です。 在庫の残高を毎日眺めるだけなら、これで足ります。

足りなくなるのは、残高をフィールドとして持たせたいときです。 他のアプリからルックアップで引きたい、残高が一定数を割ったら通知したい、 受注時に引当可能かを画面上で判定したい。このいずれも、 残高が「集計結果」ではなく「フィールドの値」になっている必要があります。 そこを自動更新するには、外部サービス連携やJavaScriptカスタマイズが要ります。

ここでコース選択の話に接続します。サイボウズが公表している料金表（2026年8月時点の掲載）では、API・プラグイン・JavaScriptカスタマイズを含む外部サービス連携はライトコースでは使えず、 スタンダードコース以上が対象とされています。 スタンダードコースは1ユーザーあたり月額1,800円（税抜）で、 最低契約ユーザー数は10ユーザーです。5人の会社でも10ユーザー分、 月18,000円（税抜）からになります。

ディスク容量はいずれも「5GB✕ユーザー数」、30日間の無料お試しがあります（同料金表、2026年8月時点の掲載）。 在庫だけを見るならライトでも始められますが、残高の自動更新や他システムとの連携を将来やるつもりなら、最初からスタンダードで考えるほうが手戻りが少ないという判断になります。連携の要否は在庫だけで決まらないので、 申請や承認をどこまで載せるかも一緒に見ておくとよいです（「kintone 稟議 申請の承認フロー」）。

ルックアップで持たせた品名・単価は、マスタを直しても過去分が古いまま残る

入出庫レコードに品名や単価を持たせる方法は2つあります。 ルックアップでコピーしてくるか、関連レコード一覧で参照するかです。 この2つは更新のされ方が逆で、ここを取り違えると棚卸しの金額が狂います。

サイボウズの開発者向け資料では、ルックアップは参照元が変わっても参照先のデータが自動では更新されないと説明されています（取得ボタンを押し直すか、APIで更新する必要があります）。 また、ルックアップでコピーしたフィールドは編集できません。 一方で関連レコード一覧は、参照元の変更が自動的に反映されます（同資料、2026年8月時点の掲載）。

実務では、取引の記録として残すもの（入出庫時の単価、当時の品名）はルックアップ、 今の状態を見たいもの（現在の品目区分、現在の保管場所）は関連レコード一覧、 という分け方になりやすいです。 問題になるのは、この区別をせずに全部ルックアップで作ったあと、 「マスタを直したのに古い名前が残っている」と言われる場面です。 これは不具合ではなく、決めていなかったことが表に出ただけです。

件数と項目数の見通し。効いてくるのは項目数のほう

履歴で積むと、レコードは動いた回数のぶんだけ伸びます。 「そんなに増やして大丈夫か」という質問は必ず出るので、公表値で確認しておきます。 kintone SIGNPOST「性能上の考慮点と改善策」には、 「利用者の快適さを考慮すると、レコード数は多くても100万レコードが目安となります。」 とあり、あわせて 「絞り込みやアクセス権の設定を行っていない1つのアプリに、100万件を登録した状態で快適に使用できることを確認しています。」 と記載されています（2026年8月時点の掲載）。

中小企業の入出庫の件数で言えば、履歴型の設計は当面もつ水準です。 件数を理由に履歴型を避ける必要はありません。

むしろ先に効いてくるのは項目数です。同資料には 「1アプリの最大フィールド数は500ですが、100を超えるとレコード一覧/詳細画面の表示などに遅延が生じる可能性があります。」 とあります。在庫アプリは項目が増えやすいところで、 ロット番号、賞味期限、棚番、シリアル、検査記録、付随する写真—— 思いつくものを全部1つのアプリに足していくと、件数ではなく項目数の側で重くなります。

kintoneの在庫管理が向く場合と、向かない場合

ここまでを踏まえて線を引きます。kintoneが弱いという話ではなく、kintoneが得意な形に自社の在庫が収まるかという話です。

「向かない」に当たった項目があるからkintoneをやめる、という話でもありません。 在庫の中核だけを専用システムに置き、案件や顧客の情報はkintoneで持つ、 という分け方もあります。製造業で在庫が合わない背景そのものは「製造業の在庫管理」で扱っています。エクセル台帳の限界から考える場合は「原価管理をエクセルで回し切る現場の型」も参考になります。

アプリを作る前に決めておくこと

最後に、これが決まっていないと作り直しになる3点です。 どれもkintoneの画面を開かずに決まるもので、 逆に言えば、決めていないと設定画面で全部聞かれます。

この3つは在庫に限った話ではなく、業務をシステムに載せるときに毎回出てくる形です。 自社の業務を先に並べる手順は「業務の棚卸しのやり方」に分けて書きました。同じ流儀で書いた他の記事は「kintone 勤怠管理は向くのか」「不動産会社がkintoneで顧客管理・物件管理を始める方法」、他のツールと並べるなら「中小企業向けCRM比較」「不動産会社にSalesforce・HubSpotは合うのか」もどうぞ。

在庫が合わないのは、道具を替えれば直るものではありません。在庫を動かした事象を記録すると決め、その事象を書き出し、 差異が出たときの直し方まで決める。ここまでやってから道具を選ぶと、 kintoneでも、専用システムでも、同じ設計がそのまま載ります。 順番は構造を決めてから道具を選ぶ、です。

※ 本記事は公開されている資料をもとにした一般的な整理です。 引用した金額・上限・仕様はサイボウズが公表しているもので、2026年8月12日時点の掲載内容にもとづきます。 料金や仕様は改定されることがあるため、検討時は必ず最新の公式情報をご確認ください。 「月18,000円（税抜）から」は、スタンダードコースの月額1,800円（税抜）に 最低契約ユーザー数10を当社が掛けたものです。 残高型と履歴型の比較、向く場合／向かない場合の区分、 作る前に決める3点は、当社が支援の現場で見てきた傾向を整理したものであり、 統計的に検証された区分ではありません。導入効果を示す削減時間や削減率は、 検証された実測がないため記載していません。