app-offer

app-offer は何をしますか？

一度だけ、最初から最後まで実行します。推奨される1つのオファーをファイルに書き、代替案は付録に記載します。

ファイル

ファイル	読み取りタイミング
reference/frameworks.md (F§)	ステップで「F§nを読む」と指示されたとき。翻訳付きのフレームワーク、ルーブリック、サンプルを格納。F§16は適用不可と判断されたアイデア、F§17はランナー計算式を保持。
reference/app-store-constraints.md (C§)	ステップ7、8、9の前、および価格、クレーム、タイマー、保証、名前を記述する前に読む。「現在」の日付が記載されています。出荷予定のものは再確認すること。
reference/100m-offers-transcript.txt	オプション。詳細を確認するためにgrepで検索。このスキルはこれがなくても動作しなければなりません。15語を超える引用はしないでください。

ハードルール（全ステップ共通）

1. 正直にのみ記述すること。 偽のタイマー、カウント、希少性は禁止。偽の、AIが作成した、または帰属不明のレビューや証言は禁止。インセンティブがある場合は開示すること。「元の価格」や理由を捏造しないこと。隠れた更新条件、ビルドに含まれない機能は禁止。これらに違反するとアプリはリジェクトされます（Apple 2.3.1、5.6；Google 不正な動作）。またEU/UK/FTCのルール（C§7、C§8）にも違反します。
2. すべての金額には根拠が必要です： 節約時間×ユーザーの時間単価、現実世界の代替手段の価格、または実際の独立した価格。根拠がなければ数値は不可。価値のないアイテムはすべての比率でゼロとして扱います。テストを通すために数値を水増ししてはいけません。
3. 請求額を最も目立つ価格とすること。 1日あたりや1ヶ月あたりの換算額は小さく、二次的に表示します（C§2）。
4. 以下のリスクが現れた場合は、必ずフラグを立てること：
   • 成果＋期限の主張：アドネットワークが制限します（C§7）；アプリレビューはアプリが提供または実証できない主張を削除します（2.3.1）。
   • 健康、認知、金銭、収入に関する主張は実証が必要です（C§7）。アプリ内で測定されたスキル向上のみを主張し、仕事、学校、脳への転移効果は主張しないこと。
   • 子供または10代のユーザー：キッズカテゴリー、ペアレンタルゲート、COPPA、および州の年齢法が適用されます。これらはどのカテゴリーでも18歳未満のユーザーに適用されます（C§10）。
   • 機密データ（金融、健康、親密、位置情報）：C§16。
5. 保証は、それが表示されるすべてのプラットフォームおよびすべてのプランで支払い可能でなければなりません（C§5）。
6. 市場 > オファー > 説得。 最も弱いリンクから先に修正すること。
7. 本の内容は言い換えること。 一度に最大15語まで引用し、頻繁に引用しないこと。
8. 質問は最大3つまで。 ターゲットユーザーやコアジョブが推測できない場合のみ。そのうちの1つは、獲得チャネルが不明な場合にステップ0.7のファウンダー情報をまとめて尋ねてもよい。それ以外は仮定に[A]、C§14のベンチマークに[B]をタグ付けし、続行すること。
9. コネクタ： ユーザーがプロジェクトまたはアプリIDがこのアプリのものであると確認しない限り、アナリティクスや収益コネクタにクエリを実行しないこと。それ以外は尋ねるか、[A]とマークすること。
10. スタイルと長さ： 平易で直接的、ルーブリックには表を使用、冗長は避ける。本文は表を含めて約3,000～4,000語。超過分は付録へ。

ステップ0：情報収集と仮定

1. 入力を分類する： 1文 / ドキュメント / URL / 既存のリポジトリ。作業ディレクトリがこのアプリのプロジェクトと見なされるのは、入力がそのアプリを指定しているか、コードとメモがアイデアと一致する場合のみ。それ以外は入力を新しいアイデアとして扱う：作業ディレクトリをgrepせず、./<app-slug>-grand-slam-offer.md に書き出すこと。
2. 既存アプリ： 何かを設計する前に、証拠に基づいて基礎を固めること。
   • プロダクトと価格：grep -rniE 'purchases_flutter|revenuecat|Purchases\.|offering|entitlement|productId|product_id|weekly|annual|lifetime|StoreKit|BillingClient' --include='*.dart' --include='*.swift' --include='*.kt' --include='*.ts' --include='*.tsx' --include='*.json' --include='*.storekit' --exclude-dir={build,Pods,.dart_tool,node_modules,.git} .
   • ペイウォールとオンボーディング：*paywall* *onboard* *intro* *upgrade* *pro* *premium* という名前のファイルと、ローカライズされたコピー（.arb, .strings, strings.xml）。出荷済みのロケールを記録すること。
   • アナリティクス：track(, logEvent、Mixpanel/Amplitude/Firebaseの呼び出し。paywall_view、trial_start、purchase、cancel、retentionイベントのうち、どれが存在するかを確認すること。
   • メモ：CLAUDE.md、README*、docs/、research/、メモリファイル、fastlane/metadata、CHANGELOG、および *brand* *voice* *tone* *style* *listing* *aso* *keyword* *mascot* *pricing* *monetis* *paywall に一致するファイル（画像も含む）。
3. 証拠モード。 WebSearch/WebFetchを使用する場合：約12回のルックアップで、5～10の競合の価格と評価、トップ3の1～3つ星レビューのテーマ、および1つのコミュニティスレッドを調査。付録BにURLと日付を引用すること。ウェブを使用しない場合：各項目に[A: メモリ、未検証]とタグを付け、「価格設定前に確認すること」の下にリストアップすること。ライブデータなし：名前付きのC§14行を[B]の代替として使用（返金率＝カテゴリ返金行；有料期間＝F§17.1；トラフィック＝インストール数×ペイウォール到達率）。ローンチ前：レビューマイニングは「n/a：ローンチ前」とし、代わりに競合のレビューをマイニングすること。
4. 現在のオファー を本の3つの部分で説明：何を得るか、どのように支払うか、条件（F§1.2）。新しいアイデア：「ビフォー」＝述べられたアイデア（ベア機能、オファーなし）。
5. 既存アプリ： 現在のペイウォールとオンボーディングをC§2、C§7、C§8に対して監査する（解約、開示、ラベル付き見積もり、暗示された成果、バッジ）。違反を§0にリストアップする。これらはオファーに関係なく最初に出荷される。
6. 過去の決定 メモやメモリに見つかったものは§0の制約となり、それぞれ「維持」または「挑戦」（理由付き）とマークする。黙って上書きしないこと。挑戦者は付録Aに記載する。
7. ファウンダー数値（デフォルト[A]）：収益目標（年間$100k、手数料控除後）；獲得チャネル（オーガニック）；開発能力（ソロ、パートタイム）；ストア手数料（中小企業プログラムの場合は15%、それ以外は30%；Googleの場合はC§1に従う）；粗利益に占めるVAT割合（ストアフロントのミックスから、それ以外は8%）；所得税率（30%）；アバターの時間単価（地域の平均賃金）；週間ペイウォールビュー数（実測値、それ以外は300）。
8. フラグ： 子供または10代のユーザー；健康、認知、または金銭に関する主張；機密データ；ユーザーあたりの変動費（推論、人時間、SMS、サードパーティデータまたはAPI手数料（銀行集約、OCR、KYCなど）、ストレージ）；マルチユーザープロダクト（カップル、家族、チーム、クラス：誰が価値のために参加しなければならないか、誰が支払うか）；脆弱なユーザーに対する悪用の可能性（強制、監視、未成年者）。

§0と、§11および§12で使用される「ビフォー」カラムを書き込む。

ステップ1：飢えた群衆の市場テスト（F§2を読む）

テスト	1	3	5	証拠
痛み	あれば便利、誰も不満を言わない	繰り返し発生する煩わしさ	切実、高コスト、または恥ずかしい；自発的に提起される	競合の1～3つ星レビュー、Reddit、検索語句
購買力	支払い者が支払えない（子供、失業者）	混合	支払い者に資金と理由がある（キャリア、試験、健康、親）	支払い者 vs ユーザー、ストアフロントミックス、ユーザー地理別LTV（C§14）
ターゲットの容易さ	集まる場所がない、キーワードがない	いくつかのチャネルがある	独自のキーワードクラスター、コミュニティ、クリエイターがいる；カスタムプロダクトページで彼らだけに語りかけられる	ASAキーワード人気、サブレディット、クリエイター
成長性	縮小している、またはOSや無料のAIに吸収されようとしている	横ばい	追い風（人口動態、プラットフォーム、季節、規制）	カテゴリトレンド、「Sherlock」リスク

• アプリを 健康、富、または人間関係 にマッピングする。純粋なエンターテイメント：そのように明記する；そこでは痛みベースの価格設定は弱い。
• 候補をスコアリングする： 述べられた市場（既存アプリ：現在のリスティングとブランドがサービスする段階）と、2～4のサブグループ。
• 判定。 述べられた市場（既存アプリ：現在のリスティングとブランドがサービスする段階）を判定する。以下の順序で確認する：
  1. PIVOT：すべてのテストが3+の候補がない。はっきりと述べること；オファーでは修正できない。
  2. GO：述べられた市場がすべてのテストで3+、かつ合計14+。GO（通常市場）：すべてのテストで3+、合計12～13、かつすべてのテストで3+のサブグループがより高いスコアで存在しない；オファーがそれを支える（F§2.7）。
  3. ニッチダウン：それ以外。すべてのテストで3+の最も高いスコアのサブグループを採用する；そのスコア、GOに達するかどうか、ギャップ、およびそれを埋めるものを記載する。
• ニッチダウン状態の既存アプリ： ユーザーが再ポジショニングを要求しない限り、メインペイウォールは現在の段階に維持する。サブグループをオンボーディング目標トラック、カスタムプロダクトページ、および独自のオファリングとして追加する；そのコンテンツが出荷され、テストに合格した後にのみプロモートする。
• 市場 / オファー / 説得 を「素晴らしい / 普通 / 悪い」で評価する。努力を最初に向ける場所を明記する。
• ニッチラダー： 汎用的から超特化的までの4つの段階と、それぞれの価格への影響。ラダー全体で約2～5倍のプレミアムを期待する（本の100倍ではない、F§16）。コミットする段階は、GOの場合は述べられた市場、それ以外はニッチダウンサブグループ（既存アプリ：上記のルール）。
• アバター： 4つの具体的な資格条件、対象外のユーザー、および製品またはその悪用によって害を受ける可能性のあるユーザー（およびどのオファー要素がオプトインまたは除外されるか）。
• ポジショニング： 「私たちは[アバター]が[独自のメカニズム]を通じて[結果]を得るのを支援し、[最大の恐怖]を回避します。」
• TAM： リーチ可能な支払い者数 × 支払い者あたりのLTGP = 天井。新しいアイデア：暫定LTGP = カテゴリの年間価格中央値 × (1 - 手数料) × (1 - VAT割合) × 1.3期間 [A]；ステップ7で再計算し、判定が変わった場合は§1.3を更新する。計算された天井（プラトーではない）が目標を下回っている場合にのみ、隣接するニッチを計画する；プラトーは、まずオファーを改善することを意味する。
• コミットする。 他のアバターは、後日カスタムプロダクトページまたはオンボーディングトラックになる。1回のテストに失敗しただけでニッチを飛び越えないこと。

§1を書き込む。

ステップ2：コモディティチェック（F§1.6、F§4.10、F§4.12を読む）

• 無料のものを含む少なくとも5つの代替品をリストアップする：2～3の名前付き競合アプリ、YouTube/TikTok、ChatGPTまたは他の無料AI、OS機能、紙とペン/本/講師、そして何もしないこと。ステップ0.3に従って価格とレビューテーマを収集する。
• 表：代替品 | 金銭的コスト | 結果までの時間 | 労力 | 夢 / 可能性 / 時間 / 労力のスコア（0、0.5、1。1は購入者に有利：大きな夢、高い可能性、短い時間、低い労力） | 合計/4 | 誰かがそれを選ぶ理由。
• 回答：(1) 見込み客はストア検索でこれらをどのように比較するか（アイコン、スクリーンショット1、評価、価格）？ (2) このアプリは時間または労力の点でどこで勝つか？速さは無料に勝る。 (3) これを カテゴリーの独占 にする一文は何か（名前付きメソッド + アバター + 結果 + 期間）？説明が必要なら、それは失敗である。

§2を書き込む。

ステップ3：価値方程式の監査（F§4を読む）

価値 = (夢の成果 × 知覚された可能性) / (時間の遅れ × 労力と犠牲)。各ドライバーを1～5でスコアリングする；高い方が常に良いため、時間と労力はその小ささでスコアリングする。アプリの自然なリズム（日次のゲーム、週次の予算、月次のレポート）に合わせて調整する；F§4.11には3つのアプリタイプの例がある。

ドライバー	アプリの測定基準	1	5
夢の成果	ユーザーの仲間やパートナーが気づくような成果	機能（「Proを解除」）	特定の結果と期間、ユーザーの仲間グループやパートナーにとって重要なシーンで
可能性	評価と数、測定された結果の統計、個人のベースライン、パーソナライズされた計画、結果のデモ、適合シグナル、リスクリバーサル	証拠なし	ベースライン + 「あなたのような人々」のデータ + 計画 + 保証
時間の遅れ	最初に感じられる勝利までの時間；トライアル終了前または最初の更新前の測定された利益；目に見える進捗	最初の請求前に感じられる勝利なし	最初のセッション内で感じられる勝利（目標は秒単位）；トライアル終了前の測定された利益
労力と犠牲	タップ数、タイピング、アカウント、セットアップ、権限、サイクルあたりの分数、意志力、恥ずかしさ	価値の前にアカウント + セットアップ + 権限の壁；長いセッション	コアジョブに本当に必要なステップのみ、価値の前にはなし；ミスは非公開に保たれる

• スコアが3以下のドライバーごとに、論理的修正（ビルドの変更）と心理的修正（プログレスバー、計画画面、次の解除までのカウントダウン、1日あたりのフレーミング、名前変更）をリストアップする。心理的修正を最初に試みる；それらは安価である。
• 分母をゼロに近づける：代わりにやってくれるバージョンはどのようなものか？
• 長期的な夢と、人々が留まるための利益に名前を付け、アプリのリズムに合わせたマイルストーン（例：1日目 / 3日目 / 7日目 / 30日目）を設定する。

§3（ビフォアスコア；アフタースコアはステップ11で追加）を書き込む。

ステップ4：問題インベントリ（F§7.2を読む）

1. ジャーニーを辿る：発見 > ストアページ > インストール > オンボーディング > 最初のセッション > （マルチユーザー：招待送信 > 2人目のユーザー参加）> 2日目 > 最初の週 > プラトーまたは退屈 > 課金と更新 > ライフイベント（旅行、忙しい週、新しい電話、共有デバイス）> 共有 > 成功後の次の問題。
2. 各段階で4つのバケツをチェックする：価値がない（夢）；私には効かない / 続けられない（可能性）；難しすぎる / バカに見える（労力）；遅すぎる / 時間がない（時間）。
3. 各障害をユーザー自身の限界的な信念の言葉で書く。レビュー、Reddit、サポートメール、キャンセル理由、オンボーディング離脱（ローンチ前：競合のレビュー）からマイニングする。
4. それぞれにそのドライバーをタグ付けする。20以上を目標に；30～60が普通。頻度×重大度でランク付けする。

本文：上位25行（# | 段階 | ユーザーの言葉 | ドライバー | ソース）。残りは付録Dへ。

§4を書き込む。

ステップ5：ソリューションと提供手段（F§6、F§7.3-7.8を読む）

1. 各問題を「[障害]があっても[ベネフィット]を得る方法」に反転させる。本文は上位10個を示す；残りは付録Dへ。
2. すべての問題に対して手段をリストアップする：上位10個には少なくとも3つ、残りには少なくとも1つ、判断する前に（発散してから収束する）。同じ手段を共有する問題をグループ化する。デリバリーキューブを使用する：

軸	オプション
注意	1:1（ファウンダー、人間コーチ、AIチューター） / 小グループ（友達のデュエル、家族リーグ、コホート） / 1:多（機能、コンテンツ、リーダーボード、ライブイベント）
労力	DIYツール / DWYガイドプランまたはAIコーチ / DFY自動化
媒体	アプリ内、ウィジェット、通知、ウォッチ、ロック画面 / ライブアクティビティ、メール、チャット、音声、ライブセッション、印刷可能
応答速度	即時24/7（ソフトウェア、AI） / 同日 / 毎週

3. ブリックエクササイズ：一度に1つの属性（表面、フォーマット、セッション長、ソーシャルサイズ、オーディエンス、支払い者）を変更し、新しいアイデアを書き留める。
4. 10倍 / 1/10テスト：10倍の価格で何を提供するか？ユーザーは1/10の価格でもどのように勝利するか？両方の端から最良のアイデアを保持する。

§5を書き込む：問題 | 方法ライン | 手段（キューブコード）。

ステップ6：トリミングとスタッキング（F§7.9-7.12を読む）

1. 「コア機能」をすべて取り除く。もしこれらがなければ、製品は価値を提供しなくなる。これらは非交渉である。
2. 残りすべてにラベルを付ける：エキサイティングな加速器、素敵だが不要、あるいは混乱要因（削除）。混乱要因は削除するか、上位ティアのみに限定する。
3. 残ったものを、アプリのアップグレードレーンに従って価値スタックのセットに構成する（F§3.11、F§7.13、C§3）。
   • アプリがサブスクリプション内で段階的なプロダクトレベルを持っている場合（スターター→プロ→エンタープライズ）、レベル内およびレベル間で積み上げる。
   • そうでなければ、単一のサブスクリプションに積み上げ、強力な自由層とプレミアム層を提供する。
4. 各スタックについて、価格を正当化する節約時間の概要を示す。
5. 戦略的損失リーダーを特定する：サブスクリプションの決定を促進する無料機能。
6. F§7.12に従って、スタックの制約と価格設定ルールを書き留める。

§6を書き込む（ビフォアスタック、ステップ11でアフターを追加）。

ステップ7：価格設定とティア（F§3、F§4.11、F§7.11、F§7.12、C§3、C§14、F§17を読む）

価格設定は、推奨販売価格（SRP）と最小販売価格に分けられます。

1. 購買力テスト： ターゲットアバターはこの価格帯にカテゴリの代替品に対して支払っているか？
2. 価値ベースの価格設定： 年間節約額 × 共有率（F§4.13）から開始する。
3. F§17.1 ランナー価格計算： 購入確率が最大化される価格を計算する（C§14のベンチマークトラフィック、期間、維持率を使用するが、どこでも利用可能である）。これが最小販売価格に設定される。

トライアルと初期割引：

• トライアル期間は平均維持期間に一致させる（ゲームは3～7日間のトライアル、ユーティリティは14～30日間）。
• 本の「不可能なオファー」時間枠を使用する：結果を保証するのに十分な長さ。
• 最初の期間割引は、年間購読の最初の月割引に限定する。

アップグレードとダウングレード：

• アップグレードは比例配分される。
• ダウングレードは現在の期間の終了時に有効になる。
• 年間から月間へのダウングレードは可能だが、現在の年間期間の終了後まで有効にならない。

価格設定表：

ティア	価格	期間	トライアル	割引	特典
無料	$0	無制限	-	-	コア機能、広告サポート
プレミアム	$X/月	月間	14日間無料トライアル	年間（Y%割引）	全機能、優先サポート
限定版	$Z/年	年間	なし	年間コミットメント割引	全機能 + 限定ボーナス

既存アプリ： 現在の価格をこれらの結果と比較する。移行戦略を書く（グランドファザリング、段階的値上げ、またはすべての新規購読に新しい価格を設定し、既存ユーザーを移行する）。

§7を書き込み、付録Bに競合価格のセクションを含める。

ステップ8：スカーシティと緊急性（F§5.4-5.8、C§5、C§7、C§8を読む）

スカーシティ：

• アイテム（枠、スポット、ダウンロード）の実際の限られた可用性のみ。
• ライブカウンターは実際の残り枠を確認できる場合にのみ使用する。
• ボーナスまたは限定機能に限定する：コア機能は決して不足させない。
• よくあるパターン：早期割引枠、限定コンテンツ、熱心なユーザー向けの限定機能。

緊急性：

• 真の期限のみ：ローンチ価格（最初のNインストールのみ）、ライブイベントの開始時間。
• フェイクカウントダウンは禁止。
• 年間プランは、毎月の支払いに比べて節約額を強調する。
• トライアルはリマインダーと更新を送信するが、偽の期限を作成しない。

$8（今日のオファー限定の取引の詳細、すべての期限付きオファーの期限、期限切れの更新ルール）。

ステップ9：ボーナスと保証（F§5.1-5.3、F§5.6-5.8、C§4、C§5、C§6を読む）

ボーナス：

• ボーナスは価値を追加し、補完的であり、ペイウォールの前または支払い時にのみ利用可能である。
• ボーナスは製品自体と競合してはならない。
• 一般的なボーナス：テンプレート、チェックリスト、専用コミュニティ、優先サポート。
• 時間制限付きボーナスはステップ8のスカーシティルールに従う。

保証：

• 保証は訪問時に支払い可能で、すべてのプラットフォームで支払い可能でなければならない（C§5）。
• 返金は、申し立てられた理由に対して比例配分されるか全額返金される。
• よくある保証：
  1. 30日間のリスクフリートライアル
  2. 年間プラン：四半期ごとに使用状況を確認し、使用していない場合は返金（4四半期すべてで機能）。
  3. 結果保証：特定の結果が達成された場合、全額返金（健康または学習アプリの場合は、アプリ内の進捗に基づく）。
• 実現不可能な保証を述べないこと（Apple 2.3.1）。

$9（すべてのボーナス、その説明、利用規約、保証条件、返金率（既存アプリ）または[B]推定値、および保証の収益/チャーンへの影響）。

ステップ10：ネーミングとペイウォールの配置（F§3.10、C§2、C§7、C§8を読む）

ネーミング：

• 名前はアバターの価値を反映し、覚えやすく、わかりやすいものでなければならない。
• App Storeのガイドラインに従ってください：類似または混乱を招く名前は避けてください。
• キーワードは名前の一部にすることができるが、これに限定されない。
• 名前のどこにでも「Pro」を追加することは、パフォーマンス上の理由から推奨されない。

ペイウォールの配置：

• 各ペイウォール画面に対して、トライアルまたは購入を促す一次行動喚起（CTA）を定義する。
• CTAは明確で、決意を促すものである（「今すぐ開始」 vs 「詳細」）。
• ペイウォールをアプリの自然なインタラクションに合わせる：
  1. オンボーディングペイウォール： 最初の価値を提供した後（オンボーディングの最終画面または最初のアクション後）。
  2. 機能ペイウォール： プレミアム機能にアクセスしようとしたとき。
  3. 時間制限ペイウォール： トライアル終了後。
  4. コンテンツペイウォール： 限定コンテンツの場合。
• 各ペイウォールは、その時点でのユーザーコンテキストに合わせてローカライズする：
  • 「あなたの進捗を解除する」 vs 「プレミアムを購入する」。
• すべてのペイウォールを、F§3.10のオファー階層内に配置する。

$10（推奨アプリ名、各ペイウォール画面のデザイン、その配置の根拠、各画面のCTA、ペイウォール間のユーザージャーニー）。

ステップ11：オンボーディングのファストウィン（F§4.5-4.7を読む）

1. 最初の価値（ファストウィン）を定義する： ユーザーが最初のセッションで体験すべき、測定可能な成果または状態の変化。
2. オンボーディングジャーニーをマッピングする： ステップ4の問題インベントリから、オンボーディング中の摩擦を特定する。
3. ファストウィンを提供するためのオンボーディングフローを設計する（ガイド付きウォークスルー、プログレスバー、最初の価値を明確に示す）。
4. パーソナライズ： 初回起動時に設定を収集してエクスペリエンスを調整する（必要な最小限）。
5. 複数のペルソナ（アバター）がいる場合、オンボーディングのパスを分岐させる。
6. オンボーディング後のエンゲージメント： ユーザーに戻る理由を与える（毎日の目標、週次の洞察、責任パートナー）。
7. リターゲティングのために、プッシュ通知のパーミッションを依頼するタイミングを計画する（価値を提供した後、妨害になる前に）。

$11（オンボーディングフロー、最初のファストウィン、パーソナライゼーション戦略、エンゲージメントサイクル）。

ステップ12：テスト計画（F§9を読む）

テストの優先順位：

1. 見えないものをテストする：価格弾力性、保証の文言、ペイウォールの配置。
2. 高リスクの項目を最初にテストする：価格設定、トライアルの長さ、オファーの文言。
3. 低リスクの項目を繰り返す：ボーナス、限定コンテンツ。
4. 一度に1つの変数：ペイウォールの文言、価格、保証の表示。

テストの設計：

• 各テストに対して、成功指標（コンバージョン率、収益、LTV）を定義する。
• サンプルサイズの要件を計算する（統計的有意性、少なくとも1,000人のユーザーが各バリエーションを閲覧すること）。
• 実行期間、配分方法、評価基準を定義する。

最小実行可能テスト：

• 新しいアイデアに対する最初のテスト：
  1. ペイウォールの配置（オンボーディング vs 機能 vs 時間制限）。
  2. 価格（A/BテストX対Y）。
  3. オファーの文言（スタンダード vs 「不可能なオファー」の文言）。
• 既存アプリ：
  1. 現在のペイウォールと提案されたペイウォール。
  2. 価格変更（段階的 vs 即時）。
  3. 保証の影響。

$12（テスト計画、サンプルサイズ、期間、指標、優先順位）。

ステップ13：出荷計画（F§10を読む）

優先順位付け：

1. オファーの変更を最初に出荷する：ペイウォール、価格設定、保証（これらは最大の影響を与える）。
2. オンボーディングの改善を次に出荷する。
3. 機能の変更は最後に出荷する。

出荷チェックリスト：

• すべてのコピーはステップ10の制約に準拠しているか？
• すべての価格設定に根拠があるか？
• すべての保証は支払い可能か？
• すべてのスカーシティ要素は本物か？
• ペイウォールはアプリの自然なインタラクションに適合しているか？
• オンボーディングは最初の価値を提供しているか？
• すべての期限は実際のもので、実装されているか？
• プライバシーとデータに関する声明は準拠しているか？
• アナリティクスはテスト計画のために導入されているか？
• 販売前の確認のために、ストアのスクリーンショット/プレビュービデオが準備されているか？

既存アプリの移行：

• 既存の購読者のグランドファザリング。
• 段階的値上げの場合はアプリ内通知。
• 新規購読者は直ちに新しいオファーを受け取る。

$13（出荷のタイムライン、依存関係、各出荷バッチの目標、移行計画）。

ステップ14：全体の書き出し

offer/grand-slam-offer.md に書き出す：

# [アプリ名] グランドスラムオファー

## エグゼクティブサマリー

この文書は、先の章で特定された市場、オファーコンポーネント、および出荷計画をまとめたものです。

## オファーの概要

- **アバター：** [説明]
- **ポジショニング：** [ポジショニングステートメント]
- **コアオファー：** [単一の推奨オファー]
- **価格設定：** [ティアと価格設定]
- **保証：** [保証の説明]
- **ボーナス：** [ボーナスの説明]
- **スカーシティ：** [スカーシティ要素]
- **緊急性：** [緊急性要素]

## オファーコンポーネントの詳細

### §0：情報収集と仮定

[§0の内容]

### §1：市場

[§1の内容]

…

### §7：価格設定

[§7の内容]

…

## 付録

### 付録A：代替案と課題

[拒否された代替案と課題の説明]

### 付録B：競合調査

[競合価格設定、レビューテーマ、コミュニティスレッドの表]

### 付録C：F§とC§のリファレンス

[参照されたフレームワークと制約の文書リスト]

### 付録D：問題と解決策の完全なリスト

[問題インベントリとソリューションの完全なリスト]

### 付録E：根拠

[各価格設定、ボーナス、保証の決定の背後にある計算と論理]

### 付録F：オファーのビフォア/アフター（既存アプリのみ）

[既存アプリの以前のオファーと新しいオファーの比較]

アプリが既存のものである場合、「ビフォア」セクション（§11、§12で使用）は、変更されたオファーを表すために「アフター」サマリーとともに含める。

新しいアイデアの場合：ファイル名は ./<app-slug>-grand-slam-offer.md とする。