kintoneの関連レコード集計値を数値フィールドへ保存するには、画面上の参照表示と永続化処理を切り離し、業務要件に応じた更新契機を設計する必要があります。明細更新を契機に非同期で親を更新する常時最新方式と、親の保存時に集計する保存時点方式では、APIの利用方針や許容遅延が異なります。取得漏れを防ぎ、失敗時に不正な値を残さない例外処理と照合体制の構築が不可欠です。
本稿は2026年10月7日時点の公式資料に基づく確認手順と設計ガイドであり、特定の実機環境での実行結果を示すものではありません。
画面表示と親レコードへの保存処理を分ける
kintoneの標準機能である関連レコード一覧は、他アプリの情報を画面上で参照するための仕組みです。cybozu developer networkのフィールド形式の仕様にあるとおり、関連レコード一覧フィールドそのものはAPIを介した値の取得や登録、更新ができません。このフィールドはアプリ間のリレーションに基づき動的に表示を生成しているだけであり、内部に集計数値を保持していません。こうした標準機能でカバーできない仕様に直面したときは、kintoneの限界はどこかを基準に回避策を重ねるか再構築するかを見極めます。
cybozu developer networkが公開する関連レコードの条件付き集計のTipsでも、集計値はスペースフィールドへ描画されています。スペースフィールドへの描画はブラウザのDOMを変更する処理にとどまり、親レコード自身のデータは更新されません。そのため、詳細画面に合計が表示されていても、一覧画面の検索やCSV出力でその数値を扱うことはできません。
数値を永続化して絞り込みやグラフ集計に利用するには、画面上の描画処理とは別に、親レコードの数値フィールドへ値を代入またはAPI更新する独立したデータ更新処理が必要です。永続化のための独自計算が過度に膨らむ場合は、kintoneで足りる会社、AI駆動開発が向く会社を参考に作り替えを視野に入れるのも一案です。
更新契機と履歴性の扱いを決定する
集計結果を親レコードへ書き込む際は、どの業務契機で集計処理を実行するかをあらかじめ定義します。明細の変更に追従させる要件と、親レコードの保存時点の値を記録する要件の差異は以下のとおりです。
| 設計項目 | 常時最新を目指す設計 | 保存時点の値を記録する設計 |
|---|---|---|
| 主な更新契機 | 子レコードの追加、編集、削除 | 親レコードの編集保存時 |
| 親への反映遅延 | 子の保存成功後に非同期更新（即時反映は未保証） | 親レコードを保存するまで未反映 |
| 主なAPI発生契機 | 子レコードの変更契機で都度実行（件数に応じたページングや再試行、定期照合による追加呼び出しあり） | 親レコードの保存契機で実行（件数に応じたページングによる追加呼び出しあり） |
| 想定される用途 | 日々の請求残高や進捗管理 | 見積確定時や月次締め処理の記録 |
| 追跡すべき情報 | 更新日時と明細側の最終更新者 | 親レコードが確定した処理日時 |
常時最新を目指す設計では、子レコードの保存成功時イベントなどを契機に、ブラウザや連携サービスが親レコード更新API（PUT）を発行します。ただし、子レコードの保存成功は親レコード更新を開始する契機にすぎず、親への即時反映を保証するものではありません。非同期（親の保存処理を待たずにバックグラウンドで進む仕組み）に伴う許容遅延を設定し、更新完了の判定や失敗時の再試行を組み込む必要があります。
一方、親レコードの保存前イベントを用いる方式では、cybozu developer networkのレコード編集画面の保存前イベント仕様に従い、画面の保存処理を待機させる仕組み（Promise）の中で関連レコードを取得し、イベントオブジェクトの数値フィールドへ代入します。この方式では、親の画面で保存を実行しない限り明細側の変更は反映されません。
また、確定時点の数値を固定したい履歴保持の要件では、最終保存時点の集計値と確定履歴値を区別します。履歴として確定させた後は再計算を抑止するフラグを設け、後日の編集保存で誤って値が上書きされない条件判定や、再確定を許可する条件（または認めない方針）を設計に含めます。
業務要件に合致した集計契機やアプリ設計の適合性を整理したい場合は、AI業務診断を活用して判定基準を具体化してください。
方式A：親レコード保存時方式（画面操作・同期処理）
- 親の保存前イベント 親レコード保存操作を検知。確定フラグ有効時は再計算を抑止。
- 全件取得と条件判定 Promise内で関連明細を全件取得して集計。エラー時は親の保存を中断。
- 正常保存 または 中断 正常時は親の数値フィールドへ代入保存。取得失敗時は親保存が中断され不正値を防ぐ。
方式B：子レコード変更方式（非同期処理・常時最新）
- 子レコードの変更成立 子の追加・編集・削除が確定（子の保存成立後は巻き戻し不可）。
- 明細再取得と親更新API 全明細を取得・集計し、PUT APIを発行。成否や競合を判定。
-
更新結果と整合性担保
［失敗時］エラー記録・再集計リトライ。
［正常時も含め］並行更新ズレに備え定期照合で収束。
親保存時方式は取得失敗時に親の保存を中断して不正保存を防ぎます。一方、子変更方式は子の保存が成立済みのため、親API更新の失敗回復（エラー記録・リトライ）に加え、正常終了時でも発生し得る並行更新ズレを防ぐ定期照合を併用して整合性を維持します。
全件取得の条件と例外処理を設計する
集計値を親へ反映する際は、REST API経由で対象明細を欠落なく取得する必要があります。親アプリ「顧客管理」、子アプリ「案件明細」において、顧客Aの明細1（値100）と明細2（値200）の合計300を顧客Aへ保存する場合、顧客Bの明細（値900）を除外する厳密なクエリ指定を行います。
cybozu developer networkのレコード取得APIの仕様にあるとおり、1回のリクエストで取得できる件数は未指定時100件、最大指定時で500件です。そのため、設定した取得上限を超える明細が存在する場合、未指定では101件目以降、500件指定では501件目以降が1回の取得から漏れます。ページング（複数回に分けて全件を取得する処理）を完了させることは前提ですが、これは「実行主体に見える範囲の取得完了」にすぎず、業務上集計すべき全明細を網羅できた証明とは別です。なお、オフセット（offset：取得開始位置の指定）は上限が10,000件に制限されているため、件数が上限に達する可能性がある環境では、カーソルAPIなど別方式を公式仕様に照らして採用します。
特にREST APIの実行権限による明細欠落に留意が必要です。kintoneでは閲覧権限のないレコードはエラーにならず、検索結果から除外されて返されます。例えば顧客Aの明細1の閲覧権限を持たない一般ユーザーが親レコードを保存した場合、APIは明細2のみを正常に取得し、過小な合計値で親レコードを上書きしてしまうリスクがあります。そのため、設計段階で「業務上必要な全明細を閲覧可能な実行主体（管理者権限のAPIトークンや実行専用アカウント等）」を明確に定めるか、必要範囲の明細取得を保証できない権限環境では親レコードの数値を上書きしない制御方針を決定します。
失敗時の扱いについても明確な分離が必要です。親レコード保存前の集計処理で通信エラー等が発生した場合は、親の保存処理を中断して0や部分合計の保存を防ぎます。一方、子レコード保存後に親を更新する処理が失敗した場合は、保存済みの子レコードを巻き戻すことはできないため、エラーログの記録や再集計フラグの付与、定期リトライによって整合性を回復する設計をとります。
なお、画面上の操作イベントだけでは、明細の削除や外部連携を捕捉しきれません。公式のkintoneヘルプ（Webhook）に記載されているとおり、「Excel/CSVファイルを読み込んでレコードを操作する」「複数のレコードを一括削除する」「複数のレコードを一括操作するREST APIを使用してレコードを操作する」の3つの操作はWebhookの通知対象外です。そのため、Webhookのみに頼るのではなく、一括取り込み後の明示的な再集計処理や定期バッチによる照合を併用します。
cybozu developer networkのレコード更新APIの仕様に基づく更新では、子レコードの取得と親レコードの更新は「一体の不可分な処理（トランザクション）」として保護されていません。リビジョン（レコード更新ごとに加算される変更管理番号）による競合エラーが発生しない正常終了であっても、取得タイミングのズレによって古い計算値が後から書き込まれ、子の更新を取り逃すリスクが存在します。そのため、許容遅延の策定や定期的な再集計、未反映データの検出体制を組み合わせる必要があります。
保存結果と更新漏れの照合手順
設計後は、画面表示だけでなくREST APIのGET取得やCSVエクスポートを用い、保存された数値フィールドの生データを確認します。
| 確認項目 | 試験条件 | 合格条件 | 備考 |
|---|---|---|---|
| 取得境界値 | 子明細が0件、101件、501件 | 全件取得完了後に正しい合計が親に保存されること | 1回の上限件数による脱落を防止 |
| 子の変更 | 子の追加、編集、削除 | 常時最新方式は所定期限内に反映、保存時点方式は次回保存後に期待値と一致 | 採用方式に応じた契機で確認 |
| 顧客指定の変更 | 明細の紐づき先を顧客AからBへ変更 | 常時最新方式は所定期限内に旧親と新親が更新、保存時点方式は各親保存後に期待値と一致 | 旧親の減算と新親の加算を確認 |
| 確定済み親の保護 | 確定フラグが有効な親レコードで明細変更や再保存を実行 | 確定履歴値が維持され、再計算による上書きが抑止されること（または許可条件通りに再確定されること） | 確定履歴保持の誤更新を防止 |
| 外部一括更新 | CSV取込やAPIによる子の一括更新 | 常時最新方式では所定の反映期限内に一致し、保存時点方式では直後に追従せず次回親保存・再計算契機後に期待値と一致すること | Webhook非通知操作の反映を確認 |
| 閲覧権限の差異 | 一部明細の非公開権限を持つユーザーで実行 | 部分集計による過小値の上書きが発生せず、設計方針通りに処理中断または専用権限での集計が行われること | 権限不足による過小集計を防止 |
| 取得エラー時 | 取得APIの通信切断やエラー発生 | 0や部分合計が保存されず、親保存の中断または失敗記録が行われること | 不正値の永続化を防止 |
| 同時更新の競合 | 複数明細から同一親への同時更新（API更新成功後に古い値で上書きされるケースを含む） | 競合エラー検知だけでなく、更新完了後に明細を再取得して計算する再試行または定期照合により、所定期限内に親レコードの値が最終集計値へ収束すること | 古い合計値の再送ではなく、明細再取得を伴う回復設計を確認 |
集計の自動化や外部ツールとのデータ連携を含めた全体構成を精査したい場合は、AI業務診断で要件の棚卸しを進めてみてください。
よくある質問
公式集計Tipsで合計値を保存できますか？
公式Tipsはスペースへの描画処理であり保存は行われません。数値を保存するには親の保存前イベントでフィールドへ代入するか、レコード更新APIを別途発行する必要があります。
500件を超える明細も集計できますか？
取得上限を超える場合はページングが必要です。offsetは上限10,000件の制約があるため、対象レコード数に応じてカーソルAPI等の別方式を公式仕様に照らし選定します。
親の保存時に計算すれば常に最新ですか？
常に最新にはなりません。親の保存時方式は「親レコードを開いて保存した時点」の明細を集計する設計のため、明細側が後から追加・編集・削除されても親レコードは自動追従しません。日々の残高などを常に最新に保ちたい要件では、明細変更をトリガーとする常時最新方式の採用や、定期バッチによる照合・再集計の設計が必要です。
revision指定で子の更新漏れも防げますか？
リビジョンは親レコード自身の更新競合を検知する機能です。明細取得から親更新までを一体のトランザクションとして保護するわけではないため、照合や再集計の設計が必要です。
参照資料
- フィールド形式：関連レコード一覧（cybozu developer network）（確認日: 2026-10-07） 関連レコード一覧フィールドの仕様と、APIによる直接取得・更新の制限事項が記載されています。
- 関連レコードの条件付き集計（cybozu developer network）（確認日: 2026-10-07） 関連レコードを取得して集計し、スペースフィールドへ描画する基本手順が示されています。
- レコードの取得（GET）（cybozu developer network）（確認日: 2026-10-07） 取得件数の既定値・最大値やクエリ指定、offset上限値などの取得仕様が解説されています。
- レコードの更新（PUT）（cybozu developer network）（確認日: 2026-10-07） 単一レコード更新APIの仕様およびリビジョン番号を用いた競合検知の仕組みが説明されています。
- レコード編集画面の保存実行前イベント（cybozu developer network）（確認日: 2026-10-07） 保存実行前イベントにおけるPromise対応と、非同期処理を伴うフィールド値書き換えの仕様が定義されています。
- Webhookを設定する（kintone ヘルプ）（確認日: 2026-10-07） Webhookの通知条件と、ファイル読み込みや一括削除、一括REST API操作などの非通知対象が明記されています。
