release-check

name	release-check
description	アプリの一般公開・ストア公開に向けた共通チェックリストの正本。 対象 repo を調査して現在地と突き合わせ、固有の公開準備チェックリストを issue に起こす。 Claude Code で /release-check、Codex で $release-check と入力したとき、または「公開準備」「リリース準備」 「ストアに出す準備」を始めると言ったときに使用する。
argument-hint	[対象 repo のパス]（任意）

/release-check

Web サービス・モバイルアプリを一般公開する前の共通チェックリストと、対象 repo への適用フロー。ベースは catnose さんの公開前チェックリスト。

進め方

• 対象 repo を調査して現在地を把握する。実装済み・未実装を区別し、既存のロードマップ文書・公開準備 issue があれば正本として尊重して重複を作らない
• 共通チェックリストの全項目を 済み / 未対応 / 対象外 に判定する。repo の調査だけでは法務・ITP・アクセシビリティ・外形監視のような痕跡のない観点が出てこない。項目を読み飛ばさず全部に判定を出す
• 未対応項目は repo の現状に即して具体化し、関連ファイルや設計 doc への参照を添えて issue 本文にする。repo 固有の項目も足す。済み項目は「済み」として本文に残し、対象外項目は理由ごと末尾に残す
• issue 本文内のファイル・doc へのリンクは issue 上で解決される URL (https://github.com/<owner>/<repo>/blob/main/...) で書く。repo 相対パスは issue では壊れる
• issue 作成は外向き操作。本文を提示して承認を得てから作る
• 対象が外部 repo、もしくは所有者を判定できない場合は、issue 作成より先に sibling の oss SKILL.md を明示的に読み、その承認境界に従う
• 公開作業中に共通チェックリストの抜けに気づいたら回答で提案する。ユーザーがこの skill の更新も依頼した場合だけ、dotfiles repo の home/.agents/skills/release-check/SKILL.md を変更する

法務

• 利用規約。返金・日割り・解約条件を明記する
• プライバシーポリシー。エラートラッキング・メール送信・決済など、データの外部送信先をすべて列挙する
• 特定商取引法に基づく表記。有料販売があるなら必須。決済代行(Stripe 等)のアカウント審査でも要求される
• アカウント削除機能。GDPR と App Store 審査(アカウント作成できるアプリは削除機能必須)の両方の要件
• 退会時にサブスクリプションを自動キャンセルする
• 電気通信事業の届出の要否。ユーザー間のメッセージ機能を提供するなら確認する
• 規約・ポリシーへの導線をアプリ内に設置する

文書テンプレート

Web サブスク(決済代行 + 無料枠 + クラウドにユーザーデータ保存)向けのドラフト雛形。ファイルがそのまま文書本文になっている。プレースホルダの【 】は必ず埋める。〔 〕の節・行は該当する場合だけ残し、記号は外す。

• 利用規約テンプレート.md。告知日数(料金改定・規約変更・サービス終了)と管轄裁判所は一般的な相場で置いてある
• プライバシーポリシーテンプレート.md。外部サービスの表と外部送信の節は、実際に使うサービスに差し替える
• 特定商取引法に基づく表記テンプレート.md。販売事業者は戸籍上の氏名または登記上の法人名で、屋号のみは不可。所在地・電話番号の「請求があった場合、遅滞なく開示」方式は実際に請求へ遅滞なく応じられる体制が前提で、確実にするなら記載する。申込み期間の定め・販売数量の制限がある場合は行を足す

埋める前にコードと運用の実態を確認する。リポジトリを読むだけでは決まらない項目があり、推測で埋めると文書と実態がずれる:

• プラン構成と価格の管理場所。決済側管理で価格がコードにないなら【 】のまま残してユーザーに確認する
• 解約の挙動。期間満了まで利用可(Stripe なら cancel_at_period_end)か即時か。カスタマーポータルの設定で決まる
• アカウント削除時の課金とデータの扱い。即時解約か、返金の有無、削除後も残るデータ(監査ログ・決済記録)
• データ保存先の国名。外的環境の把握(個人情報保護法)は国名の記載が要件。リージョン設定を確認する
• 外部送信規律(電気通信事業法27条の12)の対象の洗い出し。エラートラッキング・音声系 API・アナリティクスなど、端末から直接送信される先だけが対象。自社サーバー経由は対象外
• メール送信基盤。認証基盤の組み込みか独自 SMTP(Resend 等)かで委託先の表が変わる
• エラートラッキングの保持期間と Session Replay のマスキング設定
• 返金方針(途中解約の日割り・サービス終了時)、告知日数、管轄裁判所は運営判断。テンプレの値は一般的な相場で、ユーザーに確認する
• 公開前に弁護士レビューを推奨する。特に免責と返金

根拠: 通信販売の広告表示事項(消費者庁)、外部送信規律(総務省)、外的環境の把握(個人情報保護委員会 FAQ)

サポートと運用

• お問い合わせ導線。最初はフォームへのリンクで足りる
• 外形監視とステータス確認。ヘルスチェックエンドポイントを用意し、UptimeRobot や Better Stack 等で監視する。実装パターンは エラーページとヘルスチェック.md
• エラートラッキング。フロントエンドとサーバーの両方に入れる
• 404 / 50x ページ。適切なステータスコードを返す。実装パターンは エラーページとヘルスチェック.md
• アナリティクス。入れるならプライバシー配慮系(Plausible 等)を検討する

メール送信

• SPF / DKIM / DMARC を送信ドメインの DNS に設定する
• 一斉送信するなら購読解除リンクと List-Unsubscribe ヘッダー(Gmail の一括送信者要件)
• 送信処理の冪等性。webhook の at-least-once 配送やバッチ再実行で同じメールを二重送信しない

決済

• 決済プロバイダと自前 DB の不整合検知。日次の reconcile バッチ等。実装パターンは 決済reconcile.md
• 重複決済の防止
• カード期限切れ・支払い失敗時のハンドリングと猶予期間
• インボイス(適格請求書)対応の要否確認
• 解約導線をユーザーが自力で見つけられる場所に置く

セキュリティ

• Cookie 属性。HttpOnly / Secure / SameSite、__Host- プレフィックス
• サーバーサイドバリデーション。クライアント検証だけに頼らない
• セキュリティヘッダー。HSTS / X-Frame-Options / X-Content-Type-Options / CSP。実装パターンと CSP の組み立ては セキュリティヘッダー.md
• API のレート制限。DB を正本にする実装パターンは APIレート制限.md
• 更新・削除系 API の権限チェック棚卸し
• オープンリダイレクト対策。ログイン後の遷移先を検証する
• メールアドレス列挙防止。登録の有無で応答を変えない
• 重要操作(メールアドレス変更・退会等)の前に再認証を挟む
• オブジェクトストレージの公開設定確認
• ユーザー生成コンテンツを含むレスポンスを共有キャッシュに乗せない
• 利用クラウドサービス(レジストラ・ホスティング・決済・メール)の 2FA 有効化
• DB バックアップの有効化と保持期間の確認

SEO とシェア

実装パターン(PWA manifest 含む)は SEO・OGP・PWA資産.md。

• title / meta description / canonical
• OGP(og:title / og:description / og:url / og:image)と twitter:card
• favicon / apple-touch-icon
• robots.txt / sitemap、Search Console 登録
• PWA manifest。アイコンはブランド確定までプレースホルダーで良い
• サービス名の多言語チェック。他言語で変な意味にならないか

品質と複数環境

• iOS Safari 実機検証。メモリ上限・自動再生制約・IndexedDB クォータは実機でしか分からない
• iOS Safari の ITP 対策。7日間訪問がないと localStorage / IndexedDB が削除されうる。端末内保存が要のアプリは PWA としてホーム画面に追加してもらうと対象外になる
• クロスブラウザ確認(Chrome / Safari / Firefox)と OS 別フォント表示
• レスポンシブ確認。長いユーザー入力で崩れないかも見る
• アクセシビリティ。img の alt、アイコンボタンの aria-label、スクリーンリーダー。freee アクセシビリティー・ガイドラインが実用的
• パフォーマンス。bundle-analyzer で不要モジュール除去、静的アセットの CDN キャッシュ、画像最適化、SQL インデックス

ストア公開(iOS / Android)

• Apple Developer Program 登録(99 USD/年)、Google Play Console 登録(25 USD 買い切り)
• App Store Small Business Program 申請。前暦年と現暦年の全アプリ合計純収益が 100万 USD 以内なら手数料が 30% から 15% になる。自動適用ではなく申請が必要。持ち分 50% 以上の関連デベロッパアカウントも合算判定。現暦年に超過するとその時点で標準手数料に戻る
• Google Play の 15% サービス手数料。年間収益の最初の 100万 USD が対象。Play Console で適用条件と登録要否を確認する
• アプリ内課金の設計。ストア内のデジタル機能解放は原則 IAP 必須で、Web 用の決済(Stripe 等)をそのまま流用できない。エンタイトルメントを一元管理する層(RevenueCat 等)の要否を検討。日本はスマホ新法で外部課金の緩和が進行中なので着手時に最新動向を確認する
• App Privacy(プライバシーラベル)と Google Play データセーフティの申告
• ストア掲載素材。アイコン・スクリーンショット・説明文
• 審査ガイドラインの確認。アカウント削除機能・年齢レーティング・トラッカー申告あたりが定番の指摘どころ