kintoneで得意先別の商品単価を確定保存する設計

2026 10/25

2026年10月7日 2026年10月25日

著者: Walkers編集部公開: 2026年10月7日最終更新: 2026年10月25日

kintoneで得意先別の商品単価を管理する場合、得意先と商品の組み合わせに加えて業務上の適用条件から価格を判定し、伝票側へ確定値として保存する設計をとります。単価マスターを直接参照し続けるのではなく、伝票作成時点で確定した単価を伝票レコードに独立して保持させることで、マスター改定に伴う過去伝票の値の変動を防ぎ、取引履歴としての整合性を保てます。

この記事は2026年10月7日時点の公式資料に基づく確認手順と設計方針をまとめたものであり、実機環境での動作検証結果は含みません。

得意先と商品の組み合わせで単価を識別する

商品単価は商品マスターの情報だけで決まるとは限りません。同一商品であっても、取引先との契約条件によって適用する金額が異なる運用に対応するには、得意先と商品を束ねて価格を特定する構造が必要です。

以下のような架空の取引条件を想定します。

得意先名	商品名	単価
A社	商品X	100円
B社	商品X	120円
A社	商品Y	200円

この関係を扱う基本設計では、得意先別商品単価マスターという独立アプリを用意し、得意先コードと商品コードを組み合わせた照合用キーに対して価格を紐づけます。このとき、異なるコードの組み合わせが同一文字列にならないよう、値に含まれない専用の区切り文字を挟むなど衝突を防ぐ生成規則を定めます。

得意先と商品の組み合わせに対して単一価格を持つ基本設計に対し、有効期間、数量帯、荷姿単位ごとに複数価格を持つ拡張設計では構造の切り分けが必要です。基本設計であれば結合キーによる標準ルックアップで対応可能ですが、期間や数量帯などを評価して動的に1件へ絞り込む拡張設計では、kintone標準機能の自動判定のみでは完結せず、JavaScriptカスタマイズやAPI連携などの追加実装が必要です。拡張設計では、マスターレコードの一意識別子と検索条件となる「得意先×商品」を区別して保持した上で、伝票側の基準日、発注数量、単位まで評価し、最終的な適用価格が1件に確定することを業務ロジック上の必須保存条件として規定します。顧客区分による掛率など独自の適用ロジックが複雑化するなら、楽楽販売・boardと自社の見積ロジックを基準にパッケージに残すか作り替えるかを線引きします。

ルックアップ機能の仕様とデータ構造の選択

kintoneのルックアップ機能は、取得操作を行った時点の値を対象フィールドへ静的な値のコピーとして書き込む仕組みです。そのため、伝票保存後にマスター側の単価を変更しても、保存済みの伝票レコードの値フィールドが自動的に書き換わることはありません。ただし、編集画面で再度「取得」ボタンを押下した場合や、APIやCSV読み込み等で外部から一括更新をかけた場合には値が上書きされます。そのため、過去伝票の価格を保護するには、確定済み伝票のルックアップ再取得を制限する運用やアクセス権の制御、価格を再確定する場合の修正承認フローと理由記録をあらかじめ設計しておく必要があります。

kintoneヘルプのルックアップ設定手順に記載の通り、ルックアップには関連レコードの絞り込み初期設定があります。ただし、入力キーワードと一致する候補が1件の場合は、初期絞り込み条件を満たしていなくてもそのレコードが自動取得されます。得意先が異なる候補でもキーワード一致によって意図しない単価が転記される恐れがあるため、照合キーによる厳密な絞り込みが必要です。

標準ルックアップでマスターから伝票へ単価を直接コピーする場合、コピー元にテーブル内フィールドを指定できない制約を受けます。そのため、標準機能のみで直接取得を完結させる構成では、個別単価データをテーブルではなく1レコード1行のフラットな構造で保持する必要があります。なお、この制約は標準ルックアップで直接取得する設計に限定されるものであり、外部APIや独自プログラムを用いてテーブル内データを処理する構成まで制限するものではありません。テーブル内フィールドを参照できないといった標準仕様の制約に直面した場合は、kintoneの限界はどこかを参考に機能の拡張や別構成への移行を検討します。

システム連携においてREST API経由でルックアップの取得・更新を伴うレコード登録や更新を行う場合、cybozu developer networkのフィールド形式仕様で規定されている通り、ルックアップのコピー元フィールドに「値の重複を禁止する」設定が必須となります。画面操作やCSVファイル読み込みによる更新仕様とは前提条件が異なる場合があるため、データ移行やAPI連携の設計時には、参照先マスターのキー設計においてこの重複禁止要件を満たしているか確認しておく必要があります。

業務要件に適したデータ構造や制約事項の整理に迷う場合は、業務改善診断を活用して設計課題を棚卸しできます。

価格未確定時の判定と優先規則

個別単価を検索する処理では、該当設定が存在しない場合や複数候補が存在する場合の規則をあらかじめ定義します。

状態	判定の考え方	保存可否とシステム側の対応
未登録	個別単価マスターに組み合わせが存在しない	代替価格ルールを適用し、未確定なら保存停止
0円設定	0円という数値が意図して登録されている	正常値として保存を許可し、無償理由を保持
単価未設定（空欄）	候補は存在するが単価フィールドが未入力	価格未確定として伝票保存を停止し、マスター是正を要求
候補重複	有効日や条件重複で複数件が抽出される	保存を停止しマスター側の修正を要求

得意先別商品単価の判定分岐と伝票保存制御フロー

単価検索の実行 得意先・商品コードに加え、伝票の適用基準日・発注数量・荷姿単位を条件に対象単価を検索する。
検索失敗・未完了 処理中断（保存禁止） APIエラーや非同期通信が未完了の場合は、不完全な値での登録を防ぐため保存処理を即時中断する。
候補が1件かつ単価設定あり（0円含む） 単価確定・伝票保存 単価が空欄でなく数値として確定している場合に正常適用。0円は無償理由を、通常価格は適用区分を伝票側に記録して保存する。
候補が0件（未登録） 代替価格ルールの判定 標準単価など事前承認されたフォールバックルールが存在するかを確認する。
代替価格あり 代替単価で保存 標準価格等を伝票にセットし、適用区分に「標準単価適用」等の根拠を明記して保存を許可する。
代替価格なし / 候補重複 / 単価未設定（空欄） 伝票保存を停止 価格未確定（候補が1件でも単価が空欄の場合を含む）や重複異常としてエラーを表示し、伝票の保存を停止してマスター是正を促す。

本フローは設計上の判定規則を示したものであり、kintone標準機能のみで自動制御されるものではありません。拡張条件の判定にはカスタマイズ等の実装が必要です。

個別単価が未登録の場合、あらかじめ承認された標準単価等へフォールバック（代替価格への自動切り替え）できる業務規則であれば、その代替価格を適用して伝票を確定させます。代替価格も含めて価格が定まらない場合は、価格未確定として伝票保存を停止します。

無償サンプルなどで提供する0円設定は、数値が未設定である空欄状態とは明確に区別し、事後検証のために適用区分や理由を伝票側に記録します。また、条件の重複によって複数候補が抽出された場合に先頭行を自動採用することは避け、重複を検知した段階で処理を停止させてマスターの是正を促します。決定した単価とともに、適用区分（個別契約、標準単価、手動調整など）を伝票に保持させることで、監査時の計算根拠を確認できます。

変更操作とイベント処理の設計

伝票入力中には、得意先の変更や行追加などの操作が発生します。変更時の挙動は以下の観点で整理します。

得意先変更：ヘッダー（伝票全体の共通情報欄）の得意先が変更された場合、明細テーブルの全行で単価をクリアし、変更後の得意先条件に基づいて保存前に再判定を実施する
伝票の再利用：既存伝票を再利用して新規作成する際、保存されていた価格を一律流用せず、新伝票の基準日や数量条件で再判定する
適用基準日：単価の判定には「現在日付」を一律採用せず、業務規則で定めた適用基準日（受注日や出荷予定日など）を用いる
数量と単位の変更：まとめ買い割引や荷姿単位が変更された場合、該当する単価条件を再評価する

プログラムから過去明細を取得する際、cybozu developer networkのクエリ仕様にある通り、REST APIではfieldsパラメータで取得対象フィールドを絞り込めるものの、クエリ条件に合致した特定のテーブル行（サブテーブル行）のみを抜き出して部分取得する機能はありません。テーブルフィールドを指定すると行全体が返却されるため、プログラム側で配列を展開し、対象行を別途抽出・判定する必要があります。

画面カスタマイズにおいて、cybozu developer networkのレコード編集イベント仕様で示される通り、changeイベントはルックアップフィールドの値変更も検知します。しかし、cybozu developer networkのイベントオブジェクトで実行できる操作にある通り、changeイベントはPromiseに対応していません。イベントハンドラーからPromiseを返して非同期処理の完了を待たせる方式は利用できないため、非同期API呼び出しを伴う処理では設計上の配慮が求められます。他のイベントにおける対応状況は対象イベントごとの公式仕様を確認します。

非同期処理を組み込む場合は、以下の項目を実機検証の設計課題として確認する必要があります。

価格の取得完了前に伝票の保存が実行されない制御となっているか
API取得の失敗時や価格未確定時に伝票保存を確実に停止できるか
得意先や商品を連続で変更した際に古い応答が新しい単価を上書きしないか

自社業務の単価決定ルールをkintoneのアプリ構造へ落とし込む手順を整理したい場合は、業務改善診断で構造化の進め方を確認できます。

よくある質問

マスターの単価を変更すると既存伝票の値も変わりますか？

ルックアップ取得やAPIで伝票の数値フィールドへ保存された値は、マスター改定によって自動的に上書きされることはありません。ただし、編集画面でルックアップを再取得したり、更新APIを実行した場合は書き換わる可能性があるため、永久不変を保証するものではありません。確定伝票の編集制限や変更権限の分離を合わせて設計することが重要です。

得意先による初期絞り込みだけで誤選択を防げますか？

完全には防げません。ルックアップ検索窓の入力キーワードと一致する候補が1件の場合、初期絞り込み条件を満たしていなくても自動取得される仕様があるため、照合キーを用いた厳密な設計が必要です。

単価0円と未登録は同じ扱いでよいですか？

同一に扱うべきではありません。0円は無償提供など意図して定義された正常値であり、未登録は個別単価の設定がない状態です。また、候補レコードが存在しても単価フィールドが空欄（未設定）の場合は価格未確定として保存を停止します。未登録時は代替価格へのフォールバックを評価し、最終的に価格未確定となった場合に保存を停止します。