ルールが参照するドキュメントは、書き込み順序を決めるWhat your Firestore rules read decides your write order

Flutter / Cloud Firestore ／ 2026年8月Flutter / Cloud Firestore — August 2026

記録（Markdown・そのまま使えます）The notes (Markdown, ready to use)

GitHub で開く・ .md をダウンロード Open on GitHub ・ Download the .md

何の話かWhat this is about

Firestore のセキュリティルールで exists() や get() を使うと、そのドキュメントは他と対等ではなくなります。後続の読み書きすべての前提になり、並列に扱えなくなります。

エラーは PERMISSION_DENIED としか出ないので、ルールの書き方を疑って時間を使うことになります。ルールは正しく、順序だけが違います。

Using exists() or get() in your Firestore rules means that document is no longer a peer of the others. It becomes a precondition for every read and write that follows, and can no longer be written in parallel.

The only error is PERMISSION_DENIED, so you spend your time rereading the rules. The rules are correct. Only the order is wrong.

書いてあることWhat it covers

作成は最初、削除は最後。どちらも「前提が成立している時間を、それを必要とする処理より長くする」という同じ形
削除には逆向きの罠がある。先に権限を失うと残りが消せず、誰にも消せない残骸になる。しかも画面上は消えたように見える
症状から原因を引く表。「再起動すると成功している」「ルールは正しいのに弾かれる」「別の端末では残っている」
依存を見つけるには rules ファイルで exists( と get( を検索するだけ

Create first, delete last. Both are the same shape: keep the precondition true for longer than anything depending on it
Deletion has the trap reversed. Lose permission first and the rest can't be deleted — orphans nobody can remove, while the screen shows them gone
A symptom-to-cause table. "Works after a restart", "rejected although the rules are right", "still there on another device"
To find the dependency, just search your rules file for exists( and get(

引用・転載・改変　自由Quote, republish, and modify freely HY Studio