アプリ内お知らせの運用：表示期間・既読管理・頻度制御

2026/9/18

背景と問題

ストアのリリースノート（opc-release-notes-rhythm）とは別に、アプリ内お知らせは「既存ユーザーに直接届く唯一の放送枠」。表示期間・既読管理・頻度制御の定説を整理する（B 方向）。表示の ON/OFF は opc-remote-config-solo と opc-feature-flag-solo で制御する。

发现

（出典はいずれも 2026-09-18 アクセス）

事実：定説の書き方は「何が変わったか＋なぜ大事か＋誰に影響するか」をユーザー視点で短く、実装詳細より影響を先頭に（Appcues、ReleasePad）。定期的なアプリ内お知らせが製品変更の認知を維持する（Beamer）。
事実：頻度制御の定説——頻度キャップを設ける、目標達成者には非表示、高意図フロー（購入等）を中断しない（Adjust、Acoustic、Refiner）。表示済み/完了後はサプレスする。
事実：実装パターン——お知らせはサーバー側に有効期限付きで保持し、ユーザー×お知らせ単位の既読状態（閲覧または明示的に閉じた時点で既読、全既読対応）と未読バッジを持つのが App Inbox 型の標準（Bloomreach の App Inbox パターン、Stack Overflow の既読スキーマ議論）。
事実：モーダル UX のルール——閉じるボタンは絶対に隠さない、複数の閉じ方を用意、読み終わる前に自動で消さない（Userpilot、LogRocket、USWDS）。
推测：一人開発の最簡構成——①お知らせは JSON（タイトル/本文/掲載開始終了日/対象バージョン）を 1 ファイルで管理 ②既読は端末ローカル保存で十分（マルチ端末同期までは不要、推測）③バッジは 1 件のみ（常時赤バッジは無視されると推測）④掲載期間は Remote Config の条件でも制御可能。

结论

（調査継続中）

待办 / 下次继续

お知らせ JSON スキーマ v0（タイトル/本文/期間/対象バージョン/優先度）を定義。
既読管理（ローカル）+バッジ 1 件ルールの最小実装を組み、次回リリースに載せる。

下次继续：スキーマ v0 定義から。お知らせの文章型は opc-communication-design-consolidated の 4 層表に合わせる。

关联

opc-release-notes-rhythm opc-remote-config-solo opc-feature-flag-solo opc-communication-design-consolidated