kintone 原価管理｜案件別の集計をどこまで載せられるか

「案件ごとの利益が見えないので、kintoneで原価管理をやりたい」という相談を受けたとき、 最初に確認するのはアプリの構成ではありません。その会社で「原価」に何が入っているのかです。 材料費と外注費は入っている。社内の人が動いた時間は入っていない。 現場の運搬費は営業経費に混ざっている。この状態で集計の仕組みだけ作ると、 出てきた数字が「案件ごとの原価」なのか「案件ごとの支払額」なのか誰も言えなくなります。

この記事では、kintoneで案件別原価をやるときに先に決めておくべき取り決めを整理したうえで、 kintoneに素直に載る部分と、載せると苦しくなる部分を分けます。 最後に、向く場合と向かない場合を表で置きます。

「原価が見えない」の正体は、集計する道具の不足ではない

案件別原価が出ない会社を見ていくと、集計の手段がないのではなく、費用側の記録に案件番号が付いていないことが原因になっている場合が多いです。 これは道具の問題ではないので、道具を変えても直りません。

理由は費用の発生の仕方にあります。仕入や外注の請求は取引先の単位で届きます。1枚の請求書に複数案件のぶんが混ざることもあります。 社内の工数は人の単位で記録されます。日報も勤怠も、人と日付で並んでいます。 どちらも案件を主語にしていません。この2つを案件に寄せる決めがないと、 月末に「この請求はどの案件だったか」を思い出す作業が発生し、 思い出せなかったぶんが共通費に流れます。

表の右の列は、すべて入力のタイミングと入力する人の話です。 集計画面の話が1つも出てきません。ここが決まっていない状態でアプリを作ると、 入力欄はあるのに埋まっていないアプリができます。そして 「使われないので集計もできない」という結論になり、道具のせいになります。

もうひとつ、案件番号そのものの話があります。案件番号をいつ発番するかが決まっていないと、材料の発注のときに 書く番号が存在しません。原価を案件別に出すつもりなら、 番号は最初の支払いより前に発番されている必要があります。 受注確定を待って発番する運用だと、受注前に動いた費用は入りません。

kintoneに載せるなら、この構成が素直

取り決めができている前提で、kintone側の形を書きます。素直なのは、案件アプリを親にして、費用を子のアプリに1件1レコードで積む形です。

ポイントは、費用を明細のまま積むことです。 案件アプリに「材料費合計」「外注費合計」の入力欄を作って人が打ち込む形にすると、 根拠が消えます。あとから「この材料費は何を買ったぶんか」を聞かれたときに、 答えられるのは明細を持っている側だけです。集計は明細から作れますが、 合計から明細は復元できません。

入力の入口を作るときは、業務のどの動作に乗せるかを決めておきます。 材料は発注のとき、外注は発注と請求の受け取りのとき、工数はその日の終わりに、 という具合です。既存の業務動作に乗らない入力は残りません。 この整理そのものは「業務の棚卸しのやり方」と同じ手順で進められます。案件そのものの管理アプリを先に作る場合は「kintone 案件管理アプリ｜Excel台帳から移す設計と向かない場合」を見てください。

レコード数とフィールド数の見通しを先に持つ

工数を日次で積む設計にすると、件数は人数と日数の掛け算で伸びます。 材料の明細も、案件が増えれば積み上がります。 kintone SIGNPOSTでは、性能の考慮点として 「利用者の快適さを考慮すると、レコード数は多くても100万レコードが目安となります。」 と示されています。同じページには 「絞り込みやアクセス権の設定を行っていない1つのアプリに、100万件を登録した状態で快適に使用できることを確認しています。」 という記載もあります（2026年8月時点の掲載）。

フィールド数についても 「1アプリの最大フィールド数は500ですが、100を超えるとレコード一覧/詳細画面の表示などに遅延が生じる可能性があります。」 と示されています。 原価管理のアプリは費目を増やしたくなる場所なので、この目安は効きます。 費目をフィールドとして横に増やすのではなく、費目を選択肢にして明細を縦に積むほうが、フィールド数は増えません。

kintoneの構造から来る壁を、3つだけ押さえる

ここからが「載せると苦しくなる部分」です。どれも不具合ではなく、 kintoneがそういう作りだという話です。知らずに設計すると後で作り直しになります。

壁1：計算フィールドは、同じレコードの中でしか計算しない

kintoneの計算フィールドは、そのレコードの中にある値を計算するものです。 つまり子アプリのレコードを合計して、案件アプリのフィールドに書き戻すという処理は、標準の設定では素直に書けません。 関連レコード一覧やグラフで合計を見ることはできますが、 その合計を案件アプリのフィールドとして保持して、ほかの計算に使うには手当てが要ります。

原価管理では、この差が実務にそのまま出ます。 「案件ごとの原価合計を見たい」だけなら見るだけで足ります。 しかし「受注金額から原価合計を引いた粗利をフィールドに持って、 粗利率で絞り込む」「粗利が一定を下回ったら色を変える」「粗利つきの一覧を書き出す」 となると、合計を保持している必要があります。

保持したい場合はAPI・プラグイン・JavaScriptカスタマイズといった外部サービス連携を使います。 サイボウズが公表している（2026年8月時点の掲載）とおり、 これらはライトコースでは使えず、スタンダードコース以上の機能です。 スタンダードコースは月額1,800円（1ユーザー・税抜）、最低契約ユーザー数は10ユーザーなので、 5人の会社でも10ユーザー分、月18,000円（税抜）から始まります。原価管理をやるなら実質スタンダード以上が前提と考えておくと、 後から「ライトで始めたのに足りなかった」という乗り換えを避けられます。 なお、サイボウズは30日間の無料お試しを用意しています。

壁2：kintoneはリレーショナルデータベースのテーブルではない

サイボウズの開発者向け資料には 「kintone の1つのアプリがリレーショナルデータベースの1つのテーブルに相当するように思えますが、別物として考えることが重要です」 と明記されています。 これは原価管理でとくに効きます。会計システムの勘定科目体系や、 原価計算の集計構造をそのままアプリに移そうとすると噛み合いません。

だから当社は、kintoneに載せるのは現場が入力できる粒度の一次データまでにするようお伝えしています。 そして、会計側で締めた数字と一致させることを目的にしない。 ここは曖昧にするとあとで必ず揉めるので、はっきり線を引いておきます。

一致を目的にすると、毎月「会計とkintoneが合わない」を追う作業が生まれます。 消費税の扱い、月をまたぐ請求、締め後の修正伝票、在庫の評価—— 合わない理由はいくらでもあり、そのどれも現場の入力ミスではありません。 kintone側の目的は案件ごとの赤黒を早く見ることに置いて、 制度としての原価計算は会計側に置く。目的が2つあると、どちらも中途半端になります。

壁3：ルックアップで持たせた単価は、改定後も古いまま残る

材料単価や外注の標準単価をマスタから引いてくるとき、 kintoneではルックアップと関連レコード一覧という2つの手段があります。 この2つは参照元が変わったときの挙動が違います。 サイボウズの開発者向け資料では、ルックアップは参照元のデータが変わっても 参照先のデータが自動では更新されない（取得ボタンを押し直すかAPIで更新する必要がある）、 一方で関連レコード一覧は参照元の変更が自動的に反映される、と説明されています。 ルックアップでコピーしたフィールドは編集できないという性質もあります。

つまり選ぶ順番は、機能の比較ではありません。その数字を過去のまま固定したいのか、常に最新にしたいのかを先に決める。 決まれば手段は自動的に決まります。ここを決めずに作ると、 「なぜ去年の原価が変わったのか」または「なぜ単価を直したのに反映されないのか」 のどちらかで問い合わせが来ます。

配賦は最後まで残る。だから直接費だけで始める

間接費や共通費を、どの案件にいくら乗せるか。これが配賦です。 そして配賦は計算方法の問題ではなく、取り決めの問題です。 売上比で割るのか、工数比で割るのか、案件数で割るのか。 どれも間違いではなく、どれも誰かにとって不利になります。

この取り決めが決まっていないうちにアプリへ配賦の計算を入れると、 何が起きるか。出てきた数字を誰も信じない状態になります。 自分の案件の利益が薄く出た人は「この配賦はおかしい」と言い、 その主張には根拠があるので反論できません。 そして数字は使われなくなり、入力も止まります。

だから当社は配賦なしの「直接費だけの案件別原価」から始めることを 提案しています。材料費・外注費・社内工数の直接ぶんだけを積む。 これでも「どの案件が薄いか」の順番はかなり見えます。 そして直接費が原価の大半を占める会社なら、判断に足ります。

配賦を入れるのは、直接費の入力が安定して回りはじめてからです。 入力が回っていない段階で配賦を議論すると、議論だけで数か月使います。 順番としては、直接費が毎月ずれなく積まれる状態を先に作り、 そのうえで「共通費をどう見るか」を経営の議題として別に立てるほうが早いです。

向く場合と向かない場合

ここまでを踏まえて、kintoneで案件別原価をやるのが向く条件と、 別の道具を見たほうがよい条件を分けます。

右の列に当てはまるものが複数あるなら、kintoneは原価計算の器としてではなく、一次データを集める入口として使い、 計算そのものは別の仕組みに置くほうが素直です。 また、いま表計算ソフトで回している段階なら、どこが限界でどこはまだ足りているのかを 確かめてから移すかを決めても遅くありません。乗り換えそのものが目的になると、 同じ取り決めの欠落を新しい道具に持ち込むだけになります。

先に決める3つ

道具の選定より前に決まるものだけを並べます。 この3つが決まっていれば、kintoneでも別の道具でも同じ設計が組めます。 逆にここが空欄のままだと、どの道具の設定画面でも同じ場所で止まります。

当社がやっているのは、この3つを埋める作業です。 アプリを作るのはそのあとで、順番を逆にすると作り直しになります。 構造を決めてから道具を選ぶ、というだけの話ですが、 原価はとくに決めていないことが数字になって出てくる領域なので、 前後を入れ替えたときの手戻りが大きくなります。

※ 本記事は公開されている資料をもとにした一般的な整理です。 引用したkintoneの料金・仕様・性能の目安はサイボウズが公表している内容 （2026年8月時点の掲載）で、変更される場合があります。実際の検討時は最新の公表内容を 確認してください。「月18,000円（税抜）」は、公表されている月額1,800円（1ユーザー・税抜）と 最低契約ユーザー数10ユーザーを当社が掛けたものです。 費用の寄せ方・配賦の進め方・向く／向かないの区分は、 当社が支援の現場で観察した傾向を整理したものであり、統計的に検証された区分ではありません。 原価率や削減時間などの数値は、当社が実測していないため記載していません。