公開日：
こんにちは！システム開発グループのけいんです♪
SIチームの案件現場では、gusuku Customine（以下カスタマイン） の「レコードを扱う」系アクションを使う場面がとても多いです。
業務システム構築のプロジェクトでは、アプリ間でマスタ情報を同期したり、データを別アプリへ転記したりと、“データの流れをどう設計するか” がシステム全体の品質を左右します。
特に、
この４つは、名前こそ似ていますが、挙動・処理方式・適した用途がまったく異なります。
それを正しく理解しておかないと、データの重複登録やWebhook暴走といったトラブルを招くことも。
この記事では、SIチームでのkintone構築案件時に意識している、それぞれのアクションの特徴と使いどころをわかりやすく整理し、どんなケースでどれを選ぶのがベストなのかを掘り下げていきます。
① レコードを書き出す
まずは「レコードを書き出す」。
このアクションは、取得したレコードを一括でまとめて書き出すタイプです。
書き出し先は同一アプリでも別アプリでも指定できますが、基本的には「新規レコードをまとめて作成」する用途で使います。
Webhookは発生しないため、書き出し先アプリでの自動処理や外部連携は起動しません。
特徴まとめ：
- 一括処理でパフォーマンスが高い。
- 書き出し先の Webhook は発動しない。
- 「新規作成」用途に最適。
たとえば、営業アプリで月末締め時に請求アプリへ案件データをまとめて転記したい場合。
レコード数が数百件を超えるような処理でも、まとめて一括で出力できるため非常に高速です。
一方で、Webhookが起動しない点は注意。転記後に通知や自動承認フローを動かしたい場合は別の仕組みが必要になります。
SIチームの現場では、「夜間バッチ処理」や「バックアップ用アプリへの複製」など、大量データを安定して処理したいケースでこのアクションを採用することが多いです。
② レコードを1つずつ書き出す
次に「レコードを1つずつ書き出す」。
こちらは取得したレコードを1件ずつ順番に書き出す方式。最大の違いは、書き出し先アプリで Webhook通知が発生する 点です。
つまり、レコード作成をトリガーに外部サービスと連携したり、通知を自動送信したいときに有効です。
特徴まとめ：
- レコードを1件ずつ処理。
- 書き出し先の Webhook が起動する。
- 同一アプリ内での上書き保存にも対応。
個別処理のため、1件ごとにエラーを判定でき、トラブルシュートがしやすいという利点もあります。
ただし、件数が多い場合は処理時間が長くなるため、パフォーマンス面では注意が必要です。
こんなときにおすすめ：
- 書き出しをトリガーに通知・外部連携を行いたい。
- 少量データで確実な反映を重視したい。
- 処理失敗時に個別制御したい。
たとえば、1レコード追加ごとにSlack通知を送る、顧客登録後に外部APIで在庫確認を行うなど、リアルタイム性を重視する処理にぴったりです。
SIチームでは、Webhookを利用したkintone→外部SaaS連携や、クラウドストレージ自動更新のトリガーとしてよく採用されます。
③ レコードを更新する（キーの値をフィールドで指定）
そして３つ目、「レコードを更新する（キーの値をフィールドで指定）」。
これは既存レコードを上書き更新するためのアクションです。
更新対象を「キーとなるフィールドの値」で特定し、対応する項目をマッピングして更新します。
Webhook通知は発生しないため、静的なデータ同期や定期的な情報更新に適しています。
特徴まとめ：
- 既存レコードの上書き更新が可能。
- 更新対象をキー（例：レコード番号やID）で特定。
- Webhook は発動しない。
たとえば、外部システムから取り込んだ在庫情報を、商品マスタアプリの在庫数フィールドに反映する場合など。
新規追加ではなく既存データを置き換えるような用途に強みがあります。
また、テーブル内フィールドもキーとして指定できるため、行単位での細かい更新も可能。
「親子アプリ構成」で親情報を元に子テーブルの一部だけを更新したいときなどにも役立ちます。
ただし、存在しないレコードは新規作成されないため、UPSERT的な動き（なければ追加）はできません。
そんな時は次のやることの活用をおススメします。
④ レコードを更新または追加する（キーの値をフィールドで指定）
最後は「アップサート（Upsert）」系アクションです。
「キーとなるフィールドの値」で対象レコードを探し、存在すれば更新、なければ新規追加します。
つまり、「更新」と「追加」を一度に処理できる柔軟なアクションです。Webhookは発動しません。
特徴まとめ：
- 更新と新規追加を自動判定。
- 「キーとなるフィールドの値」で対象レコードを特定。
- Webhookは発動しない。
たとえば、外部システムからkintoneへ商品データを同期する場合、既存データは更新し、未登録データは追加する──この一連の流れを1ステップで完結できます。
SIチームの現場では、「更新」と「追加」を組み合わせた複雑なデータ同期ロジックを作る手間が大幅に減るため、マスタ管理や在庫同期処理での採用が増えています。
比較表で確認！
| アクション名 | 処理方式 | Webhook通知 | 主な用途 | 得意シーン |
|---|---|---|---|---|
| レコードを書き出す | 一括 | なし | 新規レコード追加 | 大量データ転記・夜間バッチ |
| レコードを1つずつ書き出す | 個別 | あり | 個別追加・上書き | 通知・外部連携が必要なとき |
| レコードを更新する（キーの値をフィールドで指定） | 一括 or 個別 | なし | 既存レコード更新 | マスタ同期・定期更新 |
| レコードを更新または追加する（キーの値をフィールドで指定） | 一括 or 個別 | なし | 更新＋追加（アップサート） | マスタ登録・差分同期 |
アクション選択のポイント
アクションを選ぶ際は、次の４つの観点を押さえると設計判断がしやすくなります。
- Webhook通知が必要か？
→ 必要なら「1つずつ書き出す」。不要なら「書き出す」「更新」「アップサート」。 - データ件数は多いか？
→ 大量処理なら「書き出す」で一括化。少量で確実性重視なら「1つずつ書き出す」。 - 目的は新規追加か上書き更新か？
→ 新規追加なら「書き出す」。既存データの修正なら「更新（キー指定）」。 - 更新対象をキーで特定できるか？
→ 明確なキーがある場合は「更新（キー指定）」で安全に更新可能。 - 既存レコードがあるかどうか不明？
→ その場合は「更新または追加（アップサート）」を選ぶ。
まとめ
カスタマイン の「レコードを扱う」４アクションは、どれも強力ですが、正しい使い分けを理解しておくことがシステム安定化のカギです。
SIチームのkintone構築案件では、要件定義の段階で「どのアプリがデータの主か」「どの方向に同期させるか」「Webhookを起動させるか」を明確に決めておくと、後工程がスムーズになります。
カスタマインの強みは、プログラミング不要でこれらの処理を柔軟に組み合わせられる点。
ただし、アクション選択を誤るとパフォーマンス低下や意図しないデータ更新につながることもあるので、仕組みを理解したうえで設計することが重要です。
この４アクションの違いを把握すれば、アプリ間連携の自由度は格段に上がります。
業務システム開発の精度をさらに高めたい方は、ぜひ活用してみてください！
投稿者プロフィール
-
kintone歴8年ユーザーからのジョブチェンジ。
サッカー日本代表と最近では湘南ベルマーレをこよなく愛してます♪
