kintoneで同時編集すると保存できない理由と、標準機能での防ぎ方

目次

1. kintoneは「先に保存した人」が勝つ
2. これは、むしろ安全側に倒した設計です
3. 起きやすいのは、こういう場面
4. 標準機能でできる対処
5. 1. プロセス管理とアクセス権で、擬似的にロックする
6. 2. レコードの構造を見直す
7. 3. 開いている時間を短くする
8. 本当に困るのは「保存を押すまで分からない」こと
9. 開く前と開いた直後に知らせる
10. 設定で、保存そのものを止められる
11. ロックが残り続けない
12. まとめ

日報を20分かけて書き込んで、保存ボタンを押したらエラーが出た。書いた内容は保存されず、もう一度入力し直すことになった——kintoneを複数人で使っていると、遅かれ早かれ誰かがこれを経験します。

不具合ではなく、kintoneの仕様どおりの動きです。ただ、なぜこうなっているのかを知らないと「kintoneは同時に使えない」という誤解につながります。この記事では、実際に何が起きているのかと、標準機能でどこまで避けられるかを整理します。

kintoneは「先に保存した人」が勝つ

kintoneのヘルプには、こう書かれています。

「最初に保存したユーザーの操作が優先されます」
— kintone ヘルプ「複数のユーザーが同時に同一レコードを編集できますか？」

そして、あとから保存しようとしたユーザーにはこのようなエラーが表示され、その編集内容は保存できません。

レコードを再読み込みしてください。編集中に、ほかのユーザーがレコードを更新しました。

これは、むしろ安全側に倒した設計です

「あとから保存した人の勝ち」にしてしまうと、どうなるでしょうか。Aさんが書いた内容が、Bさんの保存によって黙って消えることになります。しかも両者とも気づきません。データが静かに壊れていく、いちばん厄介な壊れ方です。

kintoneはそれを避けて、あとから保存する側を止めています。データは確実に守られています。

ただし、守られているのはデータであって、あなたが入力に使った20分ではありません。そこがこの仕様の割り切れないところです。

起きやすいのは、こういう場面

• 朝礼後に全員が同じ案件レコードを開いて、各自の欄を埋めていく
• 電話を受けた人がレコードを開いたまま保留にし、その間に別の担当者が更新する
• 週次の集計日に、複数人が同じ管理表レコードへ同時に入力する
• レコードを開いたまま離席し、戻ってきて保存を押す

共通しているのは、1つのレコードに複数人分の入力欄が同居していることと、レコードを開いている時間が長いことです。この2つが重なるほど衝突します。

標準機能でできる対処

1. プロセス管理とアクセス権で、擬似的にロックする

kintoneの標準機能だけで、編集できる人を1人に絞る仕組みが作れます。考え方はこうです。

1. プロセス管理を有効にし、ステータスを「公開中」と「編集中」の2つ用意する
2. レコードのアクセス権で、「公開中」のときは誰も編集できないように設定する
3. 「編集中」に進めた本人だけが編集できるようにする

編集したい人はまずステータスを「編集中」に変え、終わったら「公開中」に戻す。これで同時に編集する人が現れなくなります。

確実な方法ですが、代償もあります。編集のたびにステータスを2回動かす手間が全員に発生し、「公開中」に戻し忘れた人がいると、そのレコードは誰も編集できないまま固まります。運用でカバーできる規模かどうかを見てから採用してください。

2. レコードの構造を見直す

そもそも1つのレコードに複数人が書き込む設計になっていないか、という観点です。担当者ごとに別レコードへ分け、集計は一覧やグラフで見る形にすれば、衝突は原理的に起きなくなります。

作り直す手間はかかりますが、ロックの運用を全員に強いるより、長い目では楽になることが多い部分です。

3. 開いている時間を短くする

地味ですが効きます。長文はメモ帳など別の場所で書いてから貼り付ける、開いたまま離席しない、といった運用です。費用はかかりませんが、人の注意力に頼るので、忙しくなると崩れます。

本当に困るのは「保存を押すまで分からない」こと

ここまでの対処は、どれも「衝突を起こさない」ための工夫です。しかし現場で消耗するのは、衝突そのものより気づくのが遅すぎることのほうです。

他の人が同じレコードを開いていても、kintoneの画面には何も出ません。分かるのは、20分書いたあとに保存ボタンを押した瞬間です。もし開いた時点で「いま別の人が編集しています」と分かっていれば、あとにするか、声をかけるか、判断できました。失われるのは入力内容ではなく、判断の機会です。

そこを埋めるために作ったのが、同時編集ロック通知プラグインです。やっていることは3つあります。

開く前と開いた直後に知らせる

一覧や詳細の画面に「○○さんが編集中」と表示されます。編集画面に入ったときは、誰がいつから編集しているのかを警告として出します。入力を始める前に分かるので、20分書いてから引き返す事態になりません。

設定で、保存そのものを止められる

「他ユーザーが編集中の場合、保存を禁止する」を有効にすると、衝突する保存を実行前に止めます。警告だけ出して保存は各自の判断に任せたい運用なら、この設定をオフにすれば従来どおり保存できます。現場の空気に合わせて強さを選べるようにしてあります。

ロックが残り続けない

ロック方式でいちばん怖いのは、解除し忘れてレコードが固まることです。先ほどのプロセス管理を使う方法にも、まさにその弱点がありました。

このプラグインは、編集中に一定間隔で生存確認（ハートビート）を送り、それが途切れたら有効期限を過ぎた時点で自動的にロックを解除します。ブラウザが落ちても、PCの電源が切れても、そのレコードが永久に編集できなくなることはありません。有効期限と確認の間隔は、どちらも設定画面から変更できます。

購入前に無料で試せます。

まとめ

• kintoneは先に保存した人が優先。あとから保存する側はエラーになり、内容は保存されない
• 黙って上書きされるよりは安全な設計。データは守られている
• ただし守られないのは、入力に使った時間のほう
• 標準機能ならプロセス管理＋アクセス権で擬似的なロックが作れる。ただし手間と、戻し忘れで固まるリスクがある
• 1レコードに複数人が書く設計を見直せば、衝突は原理的に起きなくなる
• いちばんの問題は、保存を押すまで衝突に気づけないこと
• ロックを使うなら、解除し忘れても自動で戻る仕組みかどうかを必ず確認する

「kintoneは同時編集できない」とよく言われますが、正確には同時に編集はできるが、同時には保存できないという仕様です。ここを理解しておくと、アプリを設計する段階で衝突しにくい形を選べるようになります。