Work In Progress

このプロジェクトで現在進行中の作業と、過去のスナップショットを記録する。

現在の状況

• 2026-09-30: 9/29 付の Firebase 警告メール（「増加傾向にある安定性に関する問題」、5アプリ同時）は Google 側のサーバー障害で、対応不要・解消済み。Google Analytics for Firebase の sdk-exp に不正ペイロードが 9/29 00:41 UTC（9:41 JST）から配信され、iOS で Firebase Analytics を使う全アプリが起動約9秒後に key cannot be nil で落ちた。Firebase 公式がロールバック済みで「SDK 更新は不要」。Vision Training は 1.4.2 で34件/34人＋変種2 Issue（各2件/2人）、9/29 のみ・9/30 は0件。アプリ側の変更なし（DECISIONS 9/30）。他4アプリはメール本文のみ確認
• iOS 1.4.2 は 2026-09-03 に配信開始（9/3 時点の記載。9/4〜9/29 の進捗は今セッションでは未確認）。Unity タグ iOS1.4.2（bc1d300）。Android 1.4.1（versionCode 25）配信中、Android 1.4.2 は未定
• 価格A/Bテストの設計3点は決定済み（DECISIONS 9/3）: ①対象 = iOS・日本・1.4.2 以降の無料ユーザー全員（新規＋既存）50:50 ②購入完了イベントは足さず、群別購入は ASC 商品別売上で集計 ③買い切り 4,800円＋年額 2,400円を同時に載せて1本。日程提案（9月ベースライン → 10月上旬開始 → 11月上旬に中止判断のみ → 12月下旬終了 → 2027年1月上旬判定）は 9/3 にトムソンへ共有済みで回答待ち（9/3 時点。その後の返答は未確認）
• 計測上の重要事実（9/3 判明・変更なし）: Firebase 自動 in_app_purchase は StoreKit 2 非対応（Unity IAP 5 既定）で GA4 に購入は届かない。群別購入は ASC 商品別売上で見る。GA4 で群別に見るのは paywall_view / paywall_purchase_tap のみ
• Crashlytics の副次確認（9/30、iOS 直近7日の FATAL 全8件）: AnswerRegion.OnClickAnswerButton NRE は lastSeenVersion=1.4.0（旧版3人10件、1.4.2 では未発生）、UnloadSceneAsync は FATAL に無し。今回の障害以外の 1.4.2 新規は単発4件（__workq_kernreturn・osSetPosixAdvisoryLock・AppKit block_destroy_helper・CFStringFindWithOptionsAndLocale、各1〜2件/1人）で経過観察。Android と NON_FATAL は未確認
• リポ状態: operation main は最終 wrap-up が 9/3（1306295）、今回は .devnotes の4ファイルのみコミット。未追跡/未コミット（.aab-verify/・CLAUDE_CODE_HANDOFF.md・design-proposals/・store-assets/・SESSION_HANDOFF.md の変更）には触れていない
• 次にやること:
  1. 9/3 計画の続きの実施状況を最初に確認: ベースライン計測（paywall_view・購入タップ率・ASC 商品別件数・1.4.2 普及率）＋ Firebase A/B Testing のドラフト実験でテスト端末限定の本番確認 → 9月末に期間確定・トムソン報告（回答確認）→ 10月上旬テスト開始（Firebase A/B Testing、iOS・日本・1.4.2 以上、50:50、変数群 = t4800 + t2400）
  2. GoogleUtilities の nil キー無視の修正版（PR #249/#251 は 9/29 マージ済み・未リリース、最新は 8.1.3 / 8/26）が出たら、次の Firebase / Unity SDK 更新で取り込む（急がない。現状 GoogleUtilities 8.1.1 / Firebase iOS 12.4.0 / Unity SDK 13.4.0）
  3. Crashlytics の消滅確認の残り（Android・NON_FATAL）。Play ストア素材の続き（タブレット配置・フィーチャーグラフィック・手動アップロード）は据え置き
• 未決事項:
  • Crashlytics の障害 Issue 3件（OPEN）を閉じるか（書き込み権限が要る。トムソン管理）
  • 提案 HTML 3件（リポ直下）・store-assets/・design-proposals/・HANDOFF 2ファイル・.aab-verify/・SESSION_HANDOFF.md の git 管理方針（未追跡/未コミットのまま）
  • tools/build_sim.sh の既定は未署名のまま（RC 検証時だけ ad-hoc 署名を手で指定）
  • Crashlytics CalendarScene - SetupDaysText NRE は経過観察（直近7日の iOS FATAL には出ていない）/ RevenueCat 保留 / Play Console 自動化不可（従来どおり）
• 詰まっていること: なし

---

過去のWIPアーカイブ

2026-09-30 19:43 時点のスナップショット（9/3 12:51 セッション末＝iOS 1.4.2 配信開始・価格A/B日程提案をトムソンへ共有済みの状態）

• iOS 1.4.2 は 2026-09-03 に配信開始（READY_FOR_SALE）。リリース前に RC テンプレート v4 = 既定値・段階的リリース無し・ビルド VALID・同梱 IAP 2件 APPROVED を API で確認済み。リリース操作は You（ASC UI）。Unity タグ iOS1.4.2（bc1d300）push 済み
• 価格A/Bテストの設計3点を決定（DECISIONS 9/3）: ①対象 = iOS・日本・1.4.2 以降の無料ユーザー全員（新規＋既存）50:50 ②購入完了イベントは足さず、群別購入は ASC 商品別売上で集計 ③買い切り 4,800円＋年額 2,400円を同時に載せて1本（v6 の順次2本はやめ）
• 日程提案をトムソンへ共有済み（S3 眼球トレ価格ABテスト日程提案_20260903.html、ローカルはリポ直下・未追跡。URL 送付は You）: 9月ベースライン → 10月上旬開始 → 11月上旬に中止判断のみ → 12月下旬終了 → 2027年1月上旬判定（終了＋1週）。確認事項 = 設計可否（既存を含める・同時に変える）と推しプラン（開始前に決めたい）→ 回答待ち
• 計測上の重要事実: Firebase 自動 in_app_purchase は StoreKit 2 非対応（Unity IAP 5 既定）で GA4 に購入は届かない（IAP5 以降 0件）。群別購入は ASC 商品別売上で見る（変数群 t4800 / t2400 は正確、対照群 gen2.* は未更新ユーザー分が混入 → 全ユーザー対象なら数週間で解消）。GA4 で群別に見るのは paywall_view / paywall_purchase_tap のみ
• 検出力の根拠（対照群の必要購入件数、α=0.05 両側・検出力80%）: −25% 約220 / −29% 約157 / −40% 約79 / 半減 約47。年額トライアル開始 約19件/月/群（全ユーザー）なら 12週で −40%〜半減級を検出可。買い切り 約5.5件/月/群 は年単位で判定不能（方向性のみ）。iOS 日本新規 1,020人/30日
• Android 1.4.1（versionCode 25）配信中。Android 1.4.2 は未定
• リポ状態: Unity master bc1d300（クリーン、タグ iOS1.4.2）。operation main はこのセッションで .devnotes を更新
• 次にやること:
  1. 9/4 以降: Crashlytics で瞬間記憶2件（AnswerRegion.OnClickAnswerButton / UnloadSceneAsync）の消滅確認（dev-timer 未登録、候補 9/4 15:00 / 9/5 10:00）
  2. 9月中: ベースライン計測（paywall_view・購入タップ率・ASC 商品別件数・1.4.2 普及率）＋ Firebase A/B Testing のドラフト実験でテスト端末（AppInstanceId 取得済み）限定の変数配信 → 表示・購入の本番確認。GA4 到達確認は 24〜48h 後から
  3. トムソン回答 → 9月末にベースライン実数で期間を確定して報告 → 10月上旬テスト開始（Firebase A/B Testing、iOS・日本・1.4.2 以上、50:50、変数群 = t4800 + t2400）
  4. Play ストア素材の続き（タブレット配置・フィーチャーグラフィック・手動アップロード）は据え置き
• 未決事項:
  • 提案 HTML 3件（リポ直下）・store-assets/・design-proposals/・HANDOFF 2ファイル・.aab-verify/・SESSION_HANDOFF.md の git 管理方針（未追跡/未コミットのまま）
  • tools/build_sim.sh の既定は未署名のまま（RC 検証時だけ ad-hoc 署名を手で指定）
  • Crashlytics CalendarScene - SetupDaysText NRE 経過観察 / RevenueCat 保留 / Play Console 自動化不可（従来どおり）
• 詰まっていること: なし

2026-09-03 12:51 時点のスナップショット（1.4.2 審査待ち=前セッション末の状態）

• iOS 1.4.2（価格A/B土台＋瞬間記憶修正）を 2026-09-02 に審査提出済み（審査待ち）。トムソンがアプリ＋App 内課金2件（gen2.pro.t4800 4,800円 / gen2.1year.t2400 2,400円）を1つの審査提出に同梱。API で WAITING_FOR_REVIEW（09:41 UTC）確認済み。リリース種別は手動
• Remote Config テンプレートは v4 = 既定値（現行商品ID）。テスト中に t4800 / t2400 に切り替えたが戻し済み。リリース前にもう一度読み戻して確認すること（ズレていると配信直後から全員に変数価格が出る）
• 実機 Sandbox 検証はすべて合格（RC フェッチ Success・7商品取得・既定表示・t4800 表示→購入→再インストールで自動復元・t2400 表示→3日トライアル→Pro 解放）。手順書 1.4.2実機テスト手順.md
• GA4 カスタムディメンション登録済み: plan / kaikiri_product / year_product（配信前に完了）
• トムソンへ共有済みの資料3点（S3、thomson-share）: 土台提案（返答兼）・v6 原本・商品登録指示書。土台提案に書いた擦り合わせ2点（判定ルール・推しプラン）はトムソン回答待ち
• Android 1.4.1（versionCode 25）は審査通過・配信中。タグ Android1.4.1。Android 1.4.2 は未定
• リポ状態: Unity master bc1d300（クリーン）、operation main d5333bf。運用スクリプト: scripts/asc/asc_write.mjs（ASC の POST/PATCH）、scripts/ga4/register_custom_dimensions.py
• 次にやること:
  1. 審査状況の確認（dev-timer 未登録。候補 9/3 15:00 / 9/4 10:00）
  2. 審査通過 → RC 既定値の再確認 → リリース（手動。前回はトムソンが操作）→ iOS1.4.2 タグ → 翌日 Crashlytics で AnswerRegion.OnClickAnswerButton / UnloadSceneAsync の消滅確認
  3. 配信後の本番検証: Firebase A/B Testing のドラフト実験でテスト端末（AppInstanceId は実機ログで取得済み）だけに変数配信 → 価格表示・購入確認 → GA4 で paywall_view 到達とパラメータ分布（24〜48h 後）
  4. トムソンと判定ルール（(a) 期間延長 (b) 上流指標併用 (c) 悪化なし＋方向性）と推しプラン（900円主役 or 単価引き上げ誘導）を合意 → Firebase 側でテスト開始
  5. Play ストア素材の続き（タブレット配置・フィーチャーグラフィック・手動アップロード）は据え置き
• 未決事項:
  • store-assets/・design-proposals/・HANDOFF 2ファイル・.aab-verify/・SESSION_HANDOFF.md の git 管理方針（未追跡/未コミットのまま）
  • tools/build_sim.sh の既定は未署名のまま（RC 検証時だけ ad-hoc 署名を手で指定）
  • Crashlytics CalendarScene - SetupDaysText NRE 経過観察 / RevenueCat 保留 / Play Console 自動化不可（従来どおり）
• 詰まっていること: なし

2026-09-02 18:52 時点のスナップショット（1.4.2 提出直前=前セッション末の状態）

• 1.4.0（iOS、8/19 配信）に瞬間記憶の退行（「もう一度」後に回答キー無反応 467件/78人、ホーム二度押し例外 134件/49人）を 8/27 に発見し、1.4.1 として修正済み（Unity b1b94b5 + 0ccde78、CodeCommit push 済み）
• Android 1.4.1（versionCode 25）は内部テスト合格（2026-08-27、軽量チェック6項目 OK）。製品版プロモートは You。Android はこれで 1.3.2 → 1.4.1（ストリーク・簡体字修正・デザイン刷新・瞬間記憶修正が一度に載る）
• iOS 1.4.1 は未ビルド（ProjectSettings は 1.4.1 / build 1 で push 済み）。Unity iOS ビルド → Xcode アーカイブ → ASC は You、ASC の 1.4.1 バージョン作成と What's New 投入は API で可
• 1.4.0 の売上・DL は前後で有意差なし（新規DL 100〜115/日横ばい、課金は通常のばらつき内）。ストア素材刷新の効果は 2週間後に ASC アナリティクスのプロダクトページ閲覧→CVR で見る
• 次アプデ計画（確定）: 1.4.1 ホットフィックス → B+C 土台（課金計測イベント paywall_view 等 + Remote Config で商品ID差し替え + 価格違い商品の ASC 登録。既定値=現行価格で配信し本番確認）→ トムソン価格A/B。土台は 9/1 着手（dev-timer #52、バージョンは 1.4.2 か 1.5.0）。streak_chip_impression 過剰計上修正も土台に同梱
• トムソンへの価格A/B返答は依然保留。返答の骨子=検出力不足の実データ＋「土台先行・最小構成」＋ペイウォールの推しプラン擦り合わせ
• Play ストア素材（進行中、2026-08-27 13:10）: Play の掲載スクショは旧デザインのまま（公開ページで確認。旧UIの横長5枚＋4:3 4枚）で、Android 1.4.1 配信で見た目が食い違う
  • 完了: スマホ用 12ロケール × 7枚 = 84枚を store-assets/screenshots/android/<Playロケール>/phone/02〜08-*.png に生成（2560×1440、iOS 6.9インチ版を横2560に縮小し上下131pxの帯。帯色=上はヘッダーの紺・下は背景の紺の中央値色。「上下とも暗い紺に統一」案は You が却下、最初の版を採用）。ロケール対応は es-ES/es-419←es、fr-FR/fr-CA←fr、pt-BR/pt-PT←pt、zh-CN←zh-Hans、zh-TW←zh-Hant。生成スクリプト store-assets/screenshots/scripts/make_play_phone.py（引数でロケール指定可）。一覧シート preview/android-phone-contact-sheet.png
  • 残り: ①タブレット用（7インチ/10インチ）= iPad 版 7枚 × 9言語（ios/<locale>/ 配下の 2732×2048、4:3 は Play 要件内で加工不要）を android/<ロケール>/tablet/ に配置 ②フィーチャーグラフィック 1024×500（Play 必須、未作成）= Codex に生成依頼。store-screenshots スキルの手順どおりプロンプト案を You に見せてから発注（刷新トーン、ホーム画面＋キャッチ） ③動画は 55.6秒フル版 store-assets/videos/preview/fixed/00-full-preview.mp4 を YouTube に上げて Play にリンク（任意）
  • アップロードは You が Play Console で手動（メインのストアの掲載情報 → 各言語 → スマートフォン用スクショ最大8枚。ブラウザ自動化は不可、8/27 DEVLOG 参照）
  • Play 要件: スクショは縦横比 16:9〜9:16（最大 2:1）・各辺 320〜3840px・JPEG/24bit PNG・言語ごと2〜8枚。フィーチャーグラフィックは 1024×500 で透過なし
• 次にやること:
  1. Android 25 の製品版プロモート（You）→ 翌日 Crashlytics で AnswerRegion.OnClickAnswerButton / UnloadSceneAsync が 1.4.1 で消えたか確認（dev-timer 未登録、候補 8/28 15:00 / 8/29 10:00）
  2. iOS 1.4.1 ビルド・提出（What's New は修正のみの1行版、ja/en は DEVLOG 8/27 参照）
  3. トムソンへ返答 → 推しプラン確定 → 9/1 土台開発の設計
  4. Play ストア素材の続き: タブレット用の配置 → フィーチャーグラフィック（Codex、プロンプト相談から）→ You が Play Console へアップロード
  5. 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版（未着手）
• 未決事項:
  • Unity 側の未コミット差分（gradleTemplate.properties の aapt2 override＝Mac 固有パス、AndroidReleaseBuild.cs、Android addressables bin、crashlytics_build_id）のコミット方針
  • store-assets/（copy/play-release-notes-1.4.1.txt 追加）・design-proposals/・HANDOFF 2ファイルの git 管理方針（未追跡のまま）
  • Play Console 操作の自動化は不可（Google ログイン拒否・Chrome 136 制限）→ 当面手動。Play Developer API はトムソン経由のサービスアカウントが必要（L-005）
  • Crashlytics CalendarScene - SetupDaysText NRE は経過観察 / iPhone 側リングバグは修正しない / RevenueCat は従来どおり保留
• 詰まっていること: なし

2026-08-27 12:49 時点のスナップショット（1.4.0 審査通過直後・効果測定クローズ時点）

• iOS 1.4.0 が審査通過、「デベロッパによるリリース待ち」（2026-08-19）。手動リリース・段階的リリース未設定（リリース即時100%）を ASC API で確認済み。リリース操作はトムソンが本日中に実施見込み
• ストリーク効果測定を前倒しで確定・クローズ（8/27 予定 → 8/19 実施、対象=完了4週 7/20〜8/16）:
  • 本命指標（週あたりプレイ日数/人）は横ばい: 全体 1.11→1.13→1.13→1.03 / 既存 1.18→1.19→1.20→1.10 / 新規 0.51→0.49→0.50→0.48（W4 低下はお盆と解釈）
  • チップ CTR 約3%で安定（初週4.8%から新奇性減衰）/ 7日以上維持 106〜114人（アクティブ約3%）で伸びず / セッション/人は前後不変 / 滞在時間+30%は 7/31〜8/1 の段差と duration_sec 横ばいから外部要因と判断し判定除外 / 1.3.3 起因の新規クラッシュ 0
  • 判定 = 明確な押し上げ効果なし・悪影響なし → 「機能維持でクローズ、テコ入れは優先度下げて次施策へ」を報告書で提案
• 報告書を S3 共有済み: ストリーク効果測定報告.html → thomsons バケット ストリーク効果測定報告_20260819.html（public-read、タイトルは「THE眼球トレーニング ストリーク機能 効果測定報告」）。トムソンへの URL 送付は You → 返答待ちへ
• thomson-share スキル新設（.claude/skills/thomson-share/SKILL.md、プロジェクトレベル）: トムソン向け HTML 共有（S3 public-read / 命名 <名前>_YYYYMMDD.html / 同一キー上書きで URL 維持 / no-cache）を定型化。動作テスト済
• 次にやること:
  1. 1.4.0 リリース実施の確認（トムソン）→ リリース後の様子見（Crashlytics・レビュー）
  2. Android 1.3.3（versionCode 23）のビルド・提出（ストリーク・中国語修正の Android 展開）
  3. トムソンの効果測定報告への返答対応
  4. 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版（未着手・未議論）
• 未決事項:
  • Unity 側の未コミット差分（build 3 相当）のコミットタイミング
  • store-assets/・design-proposals/・ルートの HANDOFF 2ファイルの git 管理方針（未追跡/未コミットのまま）
  • streak_chip_impression の過剰計上修正（次回アプデ同梱）
  • Crashlytics CalendarScene - SetupDaysText NRE（10件/1ユーザー、初出 1.3.2）は経過観察
  • iPhone 側の同種リングバグは修正しない（従来どおり）/ シミュレータの向き180度ずれ / 価格A/B返答方針・RevenueCat ほかは従来から継続
• 詰まっていること: なし

2026-08-18 時点のスナップショット（1.4.0 提出待ち・効果測定前）

• iOS 1.4.0 は提出待ちのみ。素材・ビルド・メタデータはすべて登録完了（2026-08-18）
  • iPad プレビュー動画を全9ロケール制作完了（1600×1200 / 29.867秒 / 30fps / H.264+AAC、約36.5MB）。承認済み B案（瞬間移動フリーズ開幕 →5種目 → 瞬間記憶 → MOT → ブランド締め）を 4:3 へ移植したもの
  • ASC 登録完了: iPad 枠は12ロケール × 2枠（PRO_129 / PRO_3GEN_129）で スクショ14枚 + 動画2本が揃い、動画24本すべて COMPLETE＋トランスコード済み＋ポスターフレーム 00:00:00:10 指定済み。スクショ168枚は MD5 照合で最新素材と確認（追加アップロード不要だった）
  • Dropbox 納品済み: 動体視力/スクショ＆プレビュー動画/iPad版/<locale>/（動画9本＋スクショ63枚、SHA256 全72ファイル一致）
  • トムソンからスクショ＆プレビュー動画の OK 受領済み。提出は You が手動で実施
  • 提出前チェック（実機でレビューポップアップ閉止後の操作）も 正常を確認済み
• 撮影・レンダリング基盤が再利用可能な形で整った:
  • store-assets/videos/scripts/ipad_video.py ほか5本で、--locale <code> を渡すだけで任意ロケールの iPad 動画を生成できる
  • 撮影ツールは sim_tap.py / sim_state.py / sim_capture.py（AXe ベース、ウィンドウ位置・向き・スペースに非依存、マウスを奪わない）
  • ASC 操作は store-assets/scripts/asc_*.mjs（自前 ES256 JWT、GET専用の MCP では届かない POST/PATCH/PUT をカバー）
• 次にやること:
  1. 1.4.0 を審査提出（You が手動。手動リリース設定のまま）
  2. Android 1.3.3（versionCode 23）のビルド・提出
  3. 8/27 ストリーク確定判定（判定方法の決め直し込み）
  4. 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版（未着手・未議論）
• 未決事項:
  • iPhone 側の同種リングバグ（render_static.py:349 / render_zigzag.py:137）は You 判断で修正しない（提出済み iPhone 素材は現状維持）
  • Unity 側の未コミット差分（build 3 相当）のコミットタイミング
  • store-assets/・design-proposals/ の git 管理方針（未追跡のまま）
  • シミュレータのデバイス向きは 8/18 の再起動以降 180度ずれたまま。新規収録は hflip,vflip で正規化して吸収している（sim_capture.normalise_orientation）
  • 価格A/B返答方針・RevenueCat ほかは従来から継続
• 詰まっていること: なし

2026-08-18 01:09 以降のスナップショット（iPad動画制作の直前）

• iPad スクショが全9ロケール分そろった（2026-08-18 深夜）。ios/<locale>/13inch/ = 9ロケール×7枚=63枚、すべて 2732×2048 / RGB 検証済み
  • 02-teleportation の玉配置を刷新: 撮影位置そのままだと3球が横380px に固まっていたため、iPhone 承認版と同じ「大きな>字」3球（横960px・縦1240px）へ。配置は TELEPORT_LAYOUTS（initial/wide=採用/z/accel）で切替可能、既定=採用版
  • 合成バグ2件を修正: ①iPad レンダラーに速度ラベル差し替え（NORMAL→一般/正常/정상）が未実装 → localize_speed_header_ipad 追加（画面別ジオメトリ必須。iPad はヘッダー実寸が画面ごとに違う） ②remove_ball の二重乗算で黒リング → canvas へ直接 paste する形に修正（04-zigzag / 06-3d も全ロケール再生成）
  • 上書き前の 02/04/06×9ロケール=27枚は ios/<locale>/13inch/history/pre-spread-ring-fix-20260818/ へ退避（SHAマニフェスト付き）
  • 検証: ja/en は速度ラベル追加時点で提出済みと SHA完全一致（回帰なし）/ ロケール間差分の逸脱 0/56（ゲーム画素は全ロケール同一）
• 次にやること:
  1. ASC へ iPad スクショを登録（未登録10ロケール×7枚×2枠=140 + ja/en-US の 02/04/06 差し替え×2枠=12 → 計152アップロード）。ロケール対応（es→es-ES/es-MX 等）・表示順は iPhone 登録時の前例踏襲。You の可否待ちのみで、他に判断事項はない
  2. iPad App Preview 動画の制作（ja/en、30秒B案の 4:3 再構成、1600×1200） → ASC 登録 → 1.4.0 提出。提出前に実機でレビューポップアップ閉止後の操作を30秒確認
  3. 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版（未着手・未議論）
  4. 8/27 ストリーク確定判定（判定方法の決め直し込み）
  5. Android 1.3.3（versionCode 23）のビルド・提出
• 未決事項:
  • iPhone 側の同種リングバグ（render_static.py:349 / render_zigzag.py:137）は You 判断で修正しない。提出済み iPhone 素材9ロケールは現状維持
  • Unity 側の未コミット差分（build 3 相当: ProjectSettings buildNumber=3・瞬間記憶修正・MOTボール）のコミットタイミング
  • store-assets/・design-proposals/ の git 管理方針（未追跡のまま）
  • preview/index.html が陳腐化（生成元 build_preview.py は消失、l10n 以降はコンタクトシート運用。機能上は不要）
  • 価格A/B返答方針・RevenueCat ほかは従来から継続
• 詰まっていること: なし

2026-08-18 01:09 時点のスナップショット（iPad ja/en 提出準備完了・iPad動画のみ残）

• iOS 1.4.0 は「iPad 動画」以外の提出準備がすべて完了（2026-08-17 深夜、トムソンOK受領後に一括実行）:
  • iPhone 6.9インチ枠 = 新スクショ63枚+動画9本を12ロケールへ差し替え済み（旧 6.5/5.5 枠は削除、backup-old-sets-1.4.0.json 退避）。ポスターフレーム指定済み
  • What's New 12ロケール投入済み / build 3 添付済み（瞬間記憶スロット修正+MOTボール新テクスチャ同梱、暗号化申告不要）/ リリース方式=手動のまま
  • iPad 枠（ja/en-US のみ、You 決定）= 新スクショ7枚×2枠×2ロケール差し替え済み。旧 iPad 動画は削除済み（新動画完成まで iPad はスクショのみ表示）
  • 権利確認は You 判断で「問題なし」→ クローズ
• iPad 用の制作基盤が整備済み: raw-ipad/ja/（raw+補助素材+README）、scripts/render_ipad.py / render_ipad_screens.py（ja/en 14枚は ios/<locale>/13inch/ に確定済み）。シミュレータ撮影の自動化ノウハウは DEVLOG 23:46 の「気づき」参照（2台目シミュ排除が最重要）
• 次にやること:
  1. iPad App Preview 動画の制作（ja/en、30秒B案の 4:3 再構成、1600×1200） → ASC 登録 → 1.4.0 提出。提出前に実機でレビューポップアップ閉止後の操作を30秒確認（ツール起因の疑い濃だが念のため）
  2. 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版（未着手・未議論）
  3. 8/27 ストリーク確定判定（判定方法の決め直し込み）
  4. Android 1.3.3（versionCode 23）のビルド・提出
• 未決事項:
  • 他10ロケールの iPad 枠は旧デザインのまま（方針どおり。将来差し替えるか未定）
  • Unity 側の未コミット差分（build 3 相当: ProjectSettings buildNumber=3・瞬間記憶修正・MOTボール）のコミットタイミング
  • store-assets/（iPad 素材でさらに増量）・design-proposals/ の git 管理方針（未追跡のまま）
  • 価格A/B返答方針・RevenueCat ほかは従来から継続
• 詰まっていること: なし

2026-08-17 05:06 時点のスナップショット（多言語納品済・トムソン確認待ち）

• 多言語ストア素材が完成（2026-08-17 早朝）: スクショ8ロケール56枚（screenshots/ios/<locale>/6.9inch/）+ App Preview 動画8本（videos/ios/<locale>/6.9inch/01-overview.mp4）。翻訳データ2種（Codex レビュー反映済み）・指示書2種（CODEX_L10N_RENDER.md / CODEX_L10N_VIDEO.md）・ロケール別ホーム素材 raw/<locale>/00-home.mov も揃った。全数検証合格（スペック・ゲーム画素保全・音声SHA ja一致・日本語残存ゼロ。検収で見つけたテンキー巻き込み欠陥は Codex 修正済み・再検証合格）
• ja 版も確定: トムソン最終OKを受け、B案 v3（29.85秒）を 01-overview.mp4 へ差し替え済み（旧版 history 退避）
• Dropbox 納品済み: 動体視力/スクショ＆プレビュー動画/多言語版/（ロケール別8フォルダ+一覧シート、SHA 64ファイル全一致）。トムソン向け報告文案は作成済み・送付は You
• 次にやること:
  1. トムソンへ多言語納品の報告を送付（文案あり）→ 確認 OK 待ち
  2. OK 後、App Store Connect へ登録（ja + 8ロケールのスクショ・動画）。公開前の未決 = 動画音声の権利確認の扱いをこのタイミングで判断（COPYRIGHT_AUDIT.md、You は当面着手しない意向のまま）
  3. 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版（未着手・未議論）
  4. 8/27 ストリーク確定判定（判定方法の決め直し込み）
  5. Android 1.3.3（versionCode 23）のビルド・提出
• 未決事項:
  • 動画音声の権利確認（継続）
  • store-assets/（多言語追加でさらに増量）・design-proposals/ の git 管理方針（未追跡のまま）
  • ロケール版ホームの Pro バッジ非表示は許容済み（DECISIONS 2026-08-17）。気になれば後からパッチ再ビルドで差し替え可
  • 価格A/B返答方針・刷新リリースの載せ方・RevenueCat ほかは従来から継続
• 詰まっていること: なし（トムソン確認待ちは作業ブロッカーではない）

2026-08-16 23:20 時点のスナップショット（B案v3納品・トムソン最終返答待ち）

• 30秒版動画はB案構成で確定間近（2026-08-16 深夜）: トムソン第1回返答でスクショ・説明文は確定、動画はトムソン代案のB案（瞬間移動「その一瞬を、捉えろ」開幕→メニュー「見る力を、鍛える。」締め）を実制作。You の「締め表示前0.5秒の間」＋トムソン第2回指摘「冒頭静止スタート」を反映した v3 = 00-short-preview-b3.mp4（29.85秒） まで完成
• Dropbox 納品済・トムソンの最終返答待ち: 00-preview-30s.mp4=A案 / -b.mp4=B v2 / -b2.mp4=B v3（最新）。トムソンには「-b2 が静止スタート反映版」と案内する
• OK後の段取り: B案 v3 を 01-overview.mp4 へ差し替え（旧版 history 退避）→ App Store 提出準備。公開前の未決 = 動画音声の権利確認は継続（object.mp3 等の証跡未確認、COPYRIGHT_AUDIT.md 参照。You は当面着手しない意向）
• 残素材: スクショ1枚目（全メニュー動画）は後回し / 多言語版ラベル・動画は未着手（スクリプト側は --locale/--font 対応済み）
• デザイン刷新の実装は「到達可能な全画面」完了（ダッシュボード 5958de3）。次は実機通し確認 → トムソン共有
• 配信状況: iOS = 1.3.3 / Android = 1.3.2 のまま（ストリーク・中国語修正・刷新すべて Android 未配信）
• ストリーク効果測定: 8/27（6週）確定判定が近い。8/13（4週）一次判定は .devnotes 上に実施記録なし
• 次にやること:
  1. トムソン最終返答を受けて対応（OK → 01-overview.mp4 差し替え＋未確認SEの権利確認 → App Store 提出）
  2. 多言語版ラベル・動画の生成
  3. 8/27 ストリーク確定判定（判定方法の決め直し込み）
  4. Android 1.3.3（versionCode 23）のビルド・提出
• 未決事項:
  • store-assets/（2.3GB）・design-proposals/ の git 管理方針（現状未追跡。今回も .devnotes のみコミット）
  • 価格A/B返答方針・刷新リリースの載せ方・RevenueCat ほかは従来から継続（8/5 スナップショット参照）
• 詰まっていること: なし（トムソン返答待ちは作業ブロッカーではない）

2026-08-16 20:50 時点のスナップショット（第1回レビュー反映納品後・トムソン第2回返答待ち）

• トムソン第1回レビューの反映が完了（2026-08-16）: スクショ7枚を効果訴求タグに更新（トムソン案＋3微調整、Codex 分業）＋ App Store 用30秒版動画 00-short-preview-v4.mp4（28.45秒、冒頭に「目で追いかけてください」フック内蔵）を新規制作。両方 Dropbox 動体視力/スクショ＆プレビュー動画/ に納品済み（SHA一致確認済み、動画は 00-preview-30s.mp4）
• 報告文送付済み → トムソンの返答待ち。OKなら 01-overview.mp4 差し替え → App Store 提出準備へ。55.6秒フル版は Google Play・プロモ用に温存
• 公開前の未決 = 動画音声の権利確認（継続、You は当面着手しない意向）: object.mp3 / push 1.mp3 / se_correct.mp3 は証跡未確認、ball_hits.mp3 は自作録音の確認要、MOT の correct_tap1〜3.mp3 は On-Jin 由来疑い（store-assets/videos/audio/COPYRIGHT_AUDIT.md）
• 残素材・刷新・配信状況・ストリークは 8/16 深夜の「現在の状況」に引き継ぎ

2026-08-16 20:42 時点のスナップショット（トムソン第1回返答受領前の状態）

• ストア素材制作（Codex 分業）が大きく前進（2026-08-15時点）: 日本語 App Preview 全体版動画が FIX（7種目タイトルラベル＋画面切替＋BGM入り 55.567秒、Dropbox 配置・SHA一致確認済み）。日本語静止画スクショも 02〜08 の7枚 FIX（2868x1320）。詳細は CLAUDE_CODE_HANDOFF.md / SESSION_HANDOFF.md と 8/15 DEVLOG

• トムソンの返答待ちで一時停止（2026-08-15）→ 8/16 に返答受領（スクショタグの効果訴求化提案＋動画の参加フック指摘）、同日中に反映完了

• App Store 提出用29.5秒版 01-overview.mp4 は未更新のまま

• 音声権利・残素材・刷新・配信状況・ストリークは 8/16 の「現在の状況」に引き継ぎ

• デザイン刷新の実装が一段落（2026-08-05）: Codex が主要画面をほぼ完走（実装完了 19/23 行）。残りは瞬間記憶リザルト・トレーニングポイント・おすすめアプリ・システムポップアップ5種のみ。次は実機(iPhone 14)通し確認 → トムソン共有

• 開発支援が整った: Editor 課金トグル（Tools > Vision Workout > Editor 課金状態にする）/ シミュビルド基盤 tools/build_sim.sh 一発化 / Codex 側の言語切替・レビューポップアップ表示トグル

  • 実装範囲: 背景 / 種目ボタン7種（アイコンは全面型3+グリフ型4の2系統）/ ストリークチップ（配色刷新込み）/ Play リング / フッター9ボタン / デモパネル / クロスプロモ画像 / 3DデモGIF / 瞬間記憶回答ボタン
  • 高品質が要るアセットは You→Codex 直接方式で生成、組み込み・後処理は Claude 側パイプライン（DECISIONS 2件参照）
  • iOS シミュレータ確認環境を確立（arm64+vtool 方式）。「画像修正 → 15〜25分でシミュ確認」のループが回る
  • リポ状態: operation 4a416e5〜 / Unity 07da4bb（CodeCommit master 同期済み）
  • 一時領域の消失リスク → 解消: パイプライン・変換ツール一式を tools/ にコミット済み（2d90c9c）

• 価格A/B提案への返答はまだ（実データ試算＋「刷新 → 計測基盤 → 価格検証」の順番入れ替え提案の方向。7/27 時点から変化なし。詳細は 7/27 スナップショット参照）

• 配信状況: iOS = 1.3.3 / Android = 1.3.2 のまま（ストリーク・中国語修正・デザイン刷新すべて Android 未配信）

• ストリーク効果測定は待ち期間中: 8/13（4週）一次判定 → 8/27（6週）確定判定

• 次にやること:

  1. 実機(iPhone 14)で刷新全画面の通し確認
  2. 刷新をトムソンに共有（スクショ or TestFlight）し、残り小画面・QA・リリース時期を決める
  3. 刷新のリリース載せ方を決める（Android 1.3.3 に同梱するか、iOS/Android 次版で同時か）
  4. トムソンへの価格A/B返答方針を確定
  5. Android 1.3.3（versionCode 23）のビルド・提出
  6. GA4 カスタム定義の反映確認（未実施なら5分。streak_bucket が (not set) でないか）
  7. 8/13 一次判定 → 8/27 確定判定

• 未決事項:

  • デザイン刷新の提案形式とスコープ（全画面一括か、ホーム先行の段階リリースか）・ペイウォールのプラン推し順（価格戦略と直結）
  • トムソンへの返答文面・タイミング
  • RevenueCat 導入の是非
  • ストリーク判定方法の決め直し（1.3.3 内週次トレンド＋標準指標の前後比較、newVsReturning 分割）
  • streak_chip_impression の過剰計上修正（次回アプデ同梱）
  • 炎スプライトの最終アート → 刷新で解消（icon_flame_on/off・flame_white 実装済み）

• 詰まっていること: なし

2026-07-27 19:57 時点のスナップショット（価格A/B実データ検証・デザイン刷新先行の方針決定）

• トムソンの価格A/Bテスト提案（v6）を検討し、デザイン刷新を先行させる方針に（2026-07-27 時点）。並行してストリーク効果測定の待ち期間中
• 価格A/B提案への現在のスタンス（トムソンへの返答はまだ）:
  • 提案の骨格（1変数ずつ・売上判定・既存者除外）は妥当だが、検出力が実データで不足。iOS 新規 約950人/月（ほぼ日本）に対し買い切り購入は日本11件/月 → 「14日判定・最短5週間」は非現実的で数ヶ月〜年単位の試算
  • GA4 に課金イベントがゼロ（自前 IAP 実装で Analytics 送信なし）。提案の Goal metric 前提が現状不成立で、イベント9種の新規実装が必要
  • 規約面は問題なし（Play は公式機能あり / Apple は 2.3.2 対策=表示名・説明を一意に＋promoted IAP に載せない / 日本法に規制なし）→「規約でNG」という却下理由は使えない
  • 返答の形: 実データ試算を共有し「刷新 → 計測基盤 → 価格検証」の順番を提案する方向
• デザイン刷新案: モック4枚（ホーム/プレイ/設定/ペイウォール、ネオン調）をリポ直下 眼球トレデザイン刷新案/ に配置済み。ストリーク効果測定を締めてから提案予定。ペイウォールのプラン推し順（モックは3か月900円が主役）は価格戦略と直結するのでトムソンと要擦り合わせ
• 配信状況:
  • iOS = 1.3.3（7/16 リリース、READY_FOR_SALE、到達率 96.1%）
  • Android = 1.3.2 のまま（AndroidBundleVersionCode: 22）。ストリーク機能も中国語修正も未配信
• Unity リポの状態: HEAD = 0842e66、origin/master と同期済み・作業ツリークリーン。タグ iOS1.3.3 push 済
• ストリーク健全性チェック（7/27 実施）= 合格: イベント4本正常発火・重複なし・qualified 漏れなし・1.3.3 新規クラッシュ 0。本命指標初期値=週あたりプレイ日数/人 1.10（既存 1.18 / 新規 0.51）、チップ CTR ユーザー 6.9%
• GA4 基盤: カスタム定義4件登録済み（反映24〜48h）。認証はサービスアカウントに統一、.mcp.json 向け替え済み
• 次にやること:
  1. トムソンへの価格A/B返答方針を確定（実データ試算＋順番入れ替え提案）
  2. Claude Code 再起動（.mcp.json の変更を MCP に反映させるため）
  3. 7/29 頃: カスタム定義の反映確認（streak_bucket が (not set) でないかだけ。5分）
  4. Android 1.3.3（versionCode 23）のビルド・提出
  5. 8/13（4週）一次判定 → 8/27（6週）確定判定（判定の重心は 8/27）→ その後デザイン刷新提案
• 未決事項:
  • トムソンへの返答文面・タイミング
  • デザイン刷新の提案形式とスコープ（全画面一括か、ペイウォール＋ホーム先行の段階リリースか）
  • RevenueCat 導入の是非（価格・ペイウォール実験を続けるなら基盤投資の選択肢。乗り換え工数と有料プラン前提がネック）
  • ストリーク4〜6週判定の方法を決め直す必要がある。streak_updated / training_completed は 1.3.3 新設イベントのため前後比較が構造的に不可能。代替は「1.3.3 内の週次トレンド」＋「プレイ時間・セッション数/人の前後比較（標準指標、リリース前4週のベースラインは 7/27 に取得済み）」。新規流入の減衰が交絡するので newVsReturning で必ず分ける
  • streak_chip_impression が仕様「1セッション1回」を14%超過（1.14/セッション）。次回アプデで修正
  • 炎スプライトの最終アート（現状は丸プレースホルダ）
• 詰まっていること: なし

2026-07-27 18:41 時点のスナップショット（1.3.3 健全性チェック合格・GA4 基盤整備完了）

• iOS 1.3.3 リリース済（2026-07-16）・リリース後1週の健全性チェック合格・GA4 カスタム定義登録完了（2026-07-27 時点）
• 配信状況:
  • iOS = 1.3.3（build 3、7/14 アップロード、7/16 リリース、READY_FOR_SALE）。ストリーク機能＋チップ被り修正＋中国語簡体字フォント修正＋Analytics 早押し修正を同梱。7/26 時点の到達率 96.1%
  • Android = 1.3.2 のまま（AndroidBundleVersionCode: 22）。ストリーク機能も中国語修正も未配信
• Unity リポの状態: HEAD = 0842e66、origin/master と同期済み・作業ツリークリーン。タグ iOS1.3.3 push 済
• 健全性チェックの結果（7/20〜7/26、iOS 1.3.3）: イベント4本すべて正常発火・iOS のみ / streak_updated の日次 events/users=1.02（重複なし）/ training_completed ユーザー 1,740 と streak_updated 1,739 が一致（qualified 漏れなし）/ impression ユーザー 3,120 ≒ 週次アクティブ 3,111 / 1.3.3 で新規クラッシュ 0
• 本命指標の初期値: 週あたりプレイ日数/人 = 全体 1.10（既存 1.18 / 新規 0.51）。チップ CTR = イベント 4.8% / ユーザー 6.9%
• GA4 の基盤が整った: カスタム定義4件（streak_bucket / chip_state / training_type / 指標 duration_sec）を登録済み（反映24〜48h）。認証はサービスアカウント ga4-mcp@ichirokisanuki...（プロパティ 271861292 に編集者で追加済み）に統一し、.mcp.json も向け替え済み
• 次にやること:
  1. Claude Code 再起動（.mcp.json の変更を MCP に反映させるため）
  2. 7/29 頃: カスタム定義の反映確認（streak_bucket が (not set) でないかだけ。5分）
  3. Android 1.3.3（versionCode 23）のビルド・提出
  4. 8/13（4週）一次判定 → 8/27（6週）確定判定（判定の重心は 8/27）
• 未決事項:
  • 4〜6週判定の方法を決め直す必要がある。streak_updated / training_completed は 1.3.3 新設イベントのため前後比較が構造的に不可能。代替は「1.3.3 内の週次トレンド」＋「プレイ時間・セッション数/人の前後比較（標準指標、リリース前4週のベースラインは 7/27 に取得済み）」。新規流入の減衰が交絡するので newVsReturning で必ず分ける
  • streak_chip_impression が仕様「1セッション1回」を14%超過（1.14/セッション）。トレーニング→ホーム復帰の再ロードが原因と推測。次回アプデで修正
  • 炎スプライトの最終アート（現状は丸プレースホルダ。HomeScene の Inspector の streakFlameSprite に挿すだけで差し替わる構造）
• 詰まっていること: なし

（新しい「現在の状況」を書く前に、古いものをここに追記でアーカイブする。新しいものが上）

2026-07-11 時点のスナップショット（ストリーク実装完了・トムソン確認待ち）

• ストリーク機能の実装完了・Editor 確認 OK・トムソンに実装内容の確認依頼中（2026-07-11 時点）
• Unity リポの状態: 05a3215（機能実装＋レビュー指摘10件反映）+ 3eb3612（チップ縁のAA修正）を CodeCommit master へ push 済み。dotnet build 0エラー
• 実装の中身: ホーム左上ストリークチップ（消灯/点灯・9言語・2段組み自動切替・実行時生成UI）/ ストリークロジック（ローカル日付・猶予ルール・既存履歴からの初回復元）/ 計測イベント4本 / カレンダー分数表示復活 / Prefs 既存バグ2件修正（周辺視野判定漏れ・2種目の履歴未保存）
• レビュー体制の記録: Codex 実装 → /code-review high（8視点→検証付き10件）→ Claude が修正、の分業が機能した。詳細は DEVLOG 2026-07-11 と ストリーク実装報告.md
• 次にやること（トムソン OK 後）:
  1. 計測QA: Firebase DebugView で7ケース（初回/同日2回目/日付跨ぎ/1日欠席/オフライン後送信/TZ変更/旧データあり）+ 7種目それぞれで qualified 確認
  2. 実機検証（SE 相当16:9のレイアウト・ES/PT/FR の2段組み含む）
  3. GA4 カスタムディメンション登録（streak_bucket, chip_state, training_type。反映24〜48h）+ ベースラインスナップショット取得（Claude が GA4 から）
  4. バージョン更新（1.3.3 / versionCode 23 想定）→ ビルド・提出（iOS/Android）
• 未決事項: 炎スプライトの最終アート（現状は丸プレースホルダ。HomeScene の Inspector の streakFlameSprite に挿すだけで差し替わる構造）
• 詰まっていること: なし（トムソン返信待ちのみ）

2026-07-10 時点のスナップショット（トムソン承認直後・実装フェーズ入り口）

• 次回アプデ＝ストリーク機能。トムソン承認済み（2026-07-10）、実装フェーズ入り口
• 確定済みの素材:
  • 機能仕様: Artifact「ストリーク表示 決定版」（https://claude.ai/code/artifact/0a2981e1-6840-4268-b5c0-6609b7a7d148 ）＋ トムソン共有用 S3 コピー（thomsons バケット ストリーク表示モック_20260710.html、リポ直下にも同名ファイルあり）
  • 計測仕様: ストリーク計測プラン.md（ライト版 v3 採用、フル版はアーカイブ）。イベント4本、本命指標=週あたりプレイ日数/人
• 実装スコープ:
  1. Prefs 既存バグ修正（前提・Codex発見）: IsOnTrainingPlayed に周辺視野を追加（現状4種目のみで周辺視野だけの日はカレンダー未チェック）/ 瞬間記憶テスト・MOT の日別履歴保存を追加（PlayType 拡張）
  2. ストリーク算出ロジック: 7種目いずれか完了で qualified、端末ローカル日付、初期値は既存履歴から復元（旧履歴は5種目分の近似）、再インストール復元は仕様外
  3. ホーム左上チップ UI: 炎＋「◯日連続」、未プレイ=グレー消灯・プレイで点灯、収まらない言語は2段組み自動切替、I2 Localization 9言語、タップで CalendarScene
  4. カレンダー分数表示の復活（CalendarScene.cs:148 の空文字固定を解除、データは保存済み）
  5. 計測イベント4本（training_completed / streak_updated / streak_chip_impression / streak_chip_tapped）
• このアプデに自動同梱されるもの: iOS 未配信の b53d8da（Analytics 早押し修正。Android は 1.3.2 で配信済み）
• 次にやること:
  1. 実装設計（作業分解）→ 実装 → Unity 実機検証
  2. 計測QA（DebugView 7ケース＋7種目 qualified 確認）
  3. GA4 カスタムディメンション登録（リリース直前、反映24〜48h）/ ベースラインスナップショット取得（Claude が GA4 から）
  4. ビルド・提出（iOS/Android）→ リリース後1週=健全性、4〜6週=方向判定
• 詰まっていること: なし

2026-07-09 時点のスナップショット（Android 1.3.2 配信判明・リリース記録訂正直後）

• 配信済みの最新（2026-07-09 時点で実態を訂正）:
  • iOS = 1.3.2（1bdb1c7、2026-06-26 配信、タグ iOS1.3.2）。SE.get_Instance NRE 修正 + バージョン更新まで
  • Android = 1.3.2（b53d8da、versionCode 22、2026-06-26 頃配信、タグ Android1.3.2 を 2026-07-09 に作成・push）。下記4修正すべて込み
• 4コミットの配信状況（HEAD = b53d8da）:
  • b53d8da Firebase Analytics 早押しクラッシュ防止 → Android 配信済み / iOS 未配信（クロスプラットフォーム、iOS に残る唯一の意味ある未配信修正）
  • ac57fc8 NativeShare 最新版（Android 12+ PendingIntent FLAG）→ Android 配信済み。Android 専用のため iOS には実質不要
  • 1bdb1c7 バージョン 1.3.2 / versionCode 22 → 両 OS 配信済み
  • fbdc9a9 SE.get_Instance NRE 対策 → 両 OS 配信済み
• Crashlytics 対応の到達点:
  • iOS 最多 SE.get_Instance（815件/368ユーザー）→ iOS 1.3.2 で配信済・トムソンへ報告済
  • Android NativeShareBroadcastListener PendingIntent（32件/24ユーザー）→ Android 1.3.2 で配信済（解消を要監視）
  • Android Firebase CheckDependencies 早押し（23件/5ユーザー）→ Android 1.3.2 で配信済（解消を要監視）
  • Android QueryProductDetails ServiceUnavailable（2件）→ 一過性の Play 課金エラーで見送り（監視枠）
• 次にやること:
  1. iOS へ b53d8da（Analytics 早押し修正）を配信 — 単独 iOS 1.3.3 にするか次回まとめに乗せるかは要判断。iOS ビルド前に Unity コンパイル確認 + Analytics 早押し導線の実機確認
  2. Android 1.3.2 の Crashlytics 監視 — NativeShareBroadcastListener（32件）と Firebase CheckDependencies 早押し（23件）が減少しているか / SE.get_Instance の減少・SE.Play 側への移動有無 / Android 課金観測（L-004）
• 将来の小改善候補（gods-talk 指摘の見送り分）: SE.PlayIfAvailable(Type) static safe wrapper 化
• 詰まっていること: なし

2026-06-26 時点のスナップショット（iOS 1.3.2 リリース直後・Android クラッシュ未着手）

• iOS 1.3.2 を本番リリース完了（2026-06-26）。SE.get_Instance NRE 修正 fbdc9a9 + バージョン更新 1bdb1c7 を同梱。タグ iOS1.3.2 push 済。Android は 1.3.2 未リリース（versionCode 22 はコミット済）
• iOS 最多クラッシュ SE.get_Instance（815件/368ユーザー）をトムソンへ報告済
• 次: iOS 1.3.2 後の Crashlytics 監視 / Android クラッシュ対応（NativeShare・Firebase CheckDependencies）/ Android 課金観測（L-004）

2026-06-26 時点のスナップショット（iOS 1.3.2 リリース直前）

• iOS/Android とも 1.3.1 リリース済。本番 Crashlytics で iOS 最多 SE.get_Instance（NRE、815件/368ユーザー）を根本対策（fbdc9a9、Current API 分離、gods-talk 2ラウンド）。CodeCommit push 済、Android1.3.1 タグ作成済
• この後 1.3.2 へバージョン更新（1bdb1c7）し iOS のみリリースへ

2026-06-25 19:16 時点のスナップショット

• iOS / Android 両方リリース完了。次回アプデ（IAP 5.1.2 / Billing 8・Crashlytics・Privacy・UMP・HTTPS化）が両プラットフォームに出た
  • iOS: 1.3.1 リリース済 / Android: 1.3.1（versionCode 21）を 2026-06-25 本番リリース・審査通過
• Android リリース時の最大の山＝課金初期化ハングを解決: R8 難読化が Google Play billing クラスを削除（Unity IAP は JNI 経由で billing を呼ぶため R8 が未使用と誤判定）。proguard-user.txt に billing keep ルール追加で解消（commit 29c9b10）。実機で全課金フロー検証済
• 作業ツリーはクリーン。keystore 参照は Dropbox 正規パスに統一、起動時 versionCode ログ常設
• 次にやること: 段階リリース%引き上げ / Crashlytics(本番)ウォッチ・GA4 で Android 課金観測（L-004）/（任意）lifetime 所有判定・UMP 実機確認

2026-06-10 19:00 時点のスナップショット

• 次回アプデのコード実装はほぼ完了（次回アプデTODO.md の #1〜#4・#6・HTTPS化）。すべて Unity Editor コンパイル通過・origin master へ push 済。コミット列: 98ab5dc(IAP)→1475981(Crashlytics)→42bc7a0(Privacy/Info.plist)→94edc31(HTTPS)→eb6981f(UMP)
  • ✅ #1 Unity IAP 5.1.2 移行（iOS/Android 両マネージャ、Billing 8）/ ✅ #2 Crashlytics 13.4.0 / ✅ #3 PrivacyInfo.xcprivacy / ✅ #4 Info.plist 位置情報削除 / ✅ HTTPS化 / ✅ #6 UMP コンセント
  • ⏭ #5 disclaimer のみ今回パス（医療 disclaimer、UI/I2 作業。Paywall2 の footerMessageGO 流用が有力）
• Unity 本体クローンの二重化を解消: 配信中 Android 版のソースが ~/UnityProjects/VisionTraining1 に未コミットでしか無かったのを cdev/origin に正規化（b51d1b2/4ce4ac9）。今後は cdev クローン1本。署名鍵ファイルは gitignore + backups にバックアップ。UnityProjects は You が中身確認後に手動削除予定
• 次にやること（実機検証フェーズ、You 実施）:
  1. 課金テスト（最重要）: iOS/Android で 5商品表示・新規購入→確定・既存購入者の Restore。段階リリース推奨
  2. Crashlytics: 実機でテストクラッシュ→再起動→Firebase Console で受信確認
  3. UMP: 欧州 IP 相当で同意フォーム表示確認
  4. iOS ビルド: xcprivacy 生成・plist 反映確認
  5. 問題なければ iOS 申請
• 未決/保留: #5 disclaimer の配置（footer/popup/注釈）と I2 term 追加は保留。AppLovin 等メディエーションへの UMP 同意連動はコード内 TODO 残置
• 詰まっていること: なし（コードは完了、残りは実機検証のみ）

2026-06-03 14:00 時点のスナップショット

• 役割構造確定: アプリオーナーはトムソン、You は提案者・実装者（提案 → 承認 → 実装 → 申請 → リリース）。戦略議論の最終ゴールは「トムソン承認用の提案資料」
• 提案書 v3 完成: 眼球トレ提案書.html（カードベース、優先度別バッジ、出典バッジ、トムソンコメント欄付き）
• Codex セカンドオピニオン取り込み済み: gods-talk で vision-training-update-proposals-001-feedback.md を受領、13 件の指摘を統合
• 全 16 件の提案ステータス確定:
  • 🔥 アクティブ 7 件: S-001a (Billing 8 移行・緊急) / S-001b (Apple メディカル訴求) / S-001c (UMP 実装) / S-002 (Crashlytics SDK + Privacy Manifest + Info.plist) / S-006 (スクショ刷新) / L-004 (Android 観測) / L-005 (ダッシュボード化)
  • 💤 保留 8 件: S-003 / S-004 / S-005 / L-001 / L-002 / L-003 / L-006 / L-007（戦略 B 本格化のタイミングで再検討）
  • ❌ 却下 1 件: L-008 (macOS / visionOS 品質確認、代替案「対応表示を外す」)
• 重要な技術的発見:
  • Unity IAP 4.12.2 内包の Billing 6.2.1 は 既にサンセット超過（次の Android リリースはほぼ確実にリジェクトされるリスク）
  • Firebase Crashlytics SDK が 未導入（過去のクラッシュデータが一切無い、S-002 で導入予定）
  • Google UMP SDK は入っているが アプリ側の実装が見当たらない（GDPR/CCPA リスク）
  • 利用規約・プライバシーポリシーが HTTP リンク（HTTPS 化必要、トムソン側のサーバー対応）
  • App Store の RSS フィードが機能していない（自前レビュー監視 Phase1 は別ルート要検討）
• 次にやる候補:
  1. アクティブ 7 件のうち、トムソン承認を得るために提出する順序と方法を検討
  2. 実装着手は S-001a (Billing 8 移行) + S-002 (Crashlytics SDK 導入) から
  3. L-008 代替案「対応プラットフォーム表示を iOS / Android のみに絞る」を S-006 と同時にやるか
• 詰まっていること: なし。次回はトムソン提出 → 承認後の実装計画から

2026-06-02 22:00 時点のスナップショット

• アプリ内部構造の把握まで完了: Paywall2 / HomeScene / 5 商品 / Pro 限定機能の動線まで Claude が認識済み。コンテキスト共有フェーズの大半は完了
• 戦略の核心特定済み: サブスク転換率 0.12% の原因 = NeuroTracker (Pro 限定の MOT スキル) が未課金ユーザーに触れないため Pro の価値が伝わらず買い切りに流れる構造
• 意思決定方針確定: 価格変更は当面しない / iOS 1.2.9 は軽量バグ修正のみ / ツール整備は段階的に
• 運用ツール候補は memory に整理済み（[[project-tooling-options]]）。判断は急がず You のペースで段階決定
• Claude の振る舞い調整: 価格変更等の大きな判断を強く推さない方針を memory に記録（[[feedback-pace-and-scope]]）
• 次にやる候補（順序は You 判断、急がない）:
  1. iOS 1.2.9 の具体的なバグ TODO リストアップ → リリース
  2. 自前レビュー監視 Phase1（App Store RSS、認証不要、1 日工数）
  3. トムソン依頼文（ASC API + Play Developer API キー / サービスアカウント）の作成
  4. Pro 機能の体験動線の設計議論（戦略 B の準備）
• 詰まっていること: なし。判断保留中なだけで技術的ブロッカーは無し

2026-06-02 14:00 時点のスナップショット

• 分析基盤完成: 売上ダッシュボード 眼球トレ売上推移.html + GA4 分析ダッシュボード 眼球トレGA4分析.html の 2 枚体制
• MCP 構成完成: Firebase MCP + analytics-mcp（OAuth/ADC）両方稼働、.mcp.json 登録済み
• GA4 アクセス: ichirokisanuki@gmail.com が GA4 プロパティ 271861292 に Viewer 追加済み（トムソン経由）
• 戦略アクションプラン確定:
  • A. 短期（〜1ヶ月）: iOS の更新を再開（軽量バグ修正、ASO シグナル復活）
  • B. 中期（2〜3ヶ月）: iOS サブスク UI 改善
  • C. 中期（3〜6ヶ月）: Android 1.3.0 課金最適化
  • D. 中長期: 海外現地化 + ASO 多言語化
• 次にやる: 次セッション冒頭で iOS 課金画面の実機スクショを You から共有してもらう → 現状の UI 弱点を特定 → iOS 1.2.9 / 1.3.0 のリリース内容（軽量 OK）を詰めて、A の最初の打ち手を実行可能な状態にする
• 詰まっていること: 特になし。トムソン依頼系の権限も付与済み

2026-05-25 19:00 時点のスナップショット

• 構成確立: operation リポ（GitHub private, main）と Unity 本体リポ（AWS CodeCommit, master, profile=thomson-ik）の2層構成が完成
• 基盤整備完了: CLAUDE.md / .gitignore / .devnotes/ が揃った
• Unity リポ清掃完了: Rosetta 警告解消、.git 2.6GB → 305MB、Unity 公式 .gitignore 適用済み
• バックアップ: ~/ichirokisanuki/visionworkout-backups/vision-training1-unity.backup-2026-05-25/（消えても可、と判断済み）
• 次にやる: 運用業務の方向性決め。候補は (a) 売上/DAU/クラッシュレート等の定期集計の仕組み化、(b) ストア説明文の version 管理、(c) ASO 対策メモ整備、(d) その他。次セッションで You にどこから着手したいか確認してから優先順を決める
• 詰まっていること: 特になし

ロードマップ

今週

• 実機検証フェーズ: iOS は申請・リリース済（1.3.1）。Android も実機で全課金フロー検証完了し 1.3.1（versionCode 21）を 2026-06-25 本番リリース・審査通過（途中で R8 が billing を削除する初期化ハングを発見・修正）
• 提案書 v3（眼球トレ提案書.html）をトムソンに提出するタイミング・方法を検討（メール添付 / リンク共有 / 対面）
• 提出順序の決定: アクティブ 7 件をまとめて提示するか、緊急度順（S-001a 単体 → 他）に分けるか
• SE.get_Instance NRE 修正（commit fbdc9a9）を CodeCommit へ push 済。iOS 1.3.2 を 2026-06-26 リリース完了（タグ iOS1.3.2）。Android 1.3.2 は今回見送り（次回）
• Android クラッシュ上位2件を修正・push 済（未配信）: NativeShare 更新（ac57fc8、PendingIntent）/ Firebase Analytics 早押しガード（b53d8da、AnalyticsUtil）。QueryProductDetails は一過性で見送り
• 次回アップデートで今回の修正をまとめて配信 → Android は 1.3.2（b53d8daビルド、4修正込み）として 2026-06-26 頃配信済みと 2026-07-09 に判明・タグ Android1.3.2 作成。iOS は Analytics 早押し修正（b53d8da）のみ未配信 → 次回ストリークアプデに同梱
• ストリーク機能の実装完了（2026-07-11）: Codex 実装 → /code-review high（10件検出）→ 修正込みで CodeCommit push（05a3215 + AA修正 3eb3612）。Editor 確認 OK、トムソンに実装内容の確認依頼中。残: 炎スプライトの最終アート差し替え（丸プレースホルダのまま）
• ストリークアプデの計測QA + 実機検証 → ビルド・提出（iOS/Android） → iOS 1.3.3 を 2026-07-16 リリース済（build 3、チップ被り修正 84dcccf と中国語簡体字修正 f595f22 も同梱、タグ iOS1.3.3）。Android は未着手（下記）
• Android 1.3.3（versionCode 23）のビルド・提出 → Android 1.4.1（versionCode 25）として内部テスト合格（2026-08-27）。1.3.2 → 1.4.1 でストリーク・簡体字修正・刷新・瞬間記憶修正を同時配信。製品版プロモートは You
• iOS 1.4.1 のビルド・提出 → 1.4.1 単独はやめ、1.4.2（価格A/B土台同梱）として 2026-09-02 審査提出済み・審査待ち（build 1、What's New「軽微な不具合修正」12ロケール、App 内課金2件を同一提出に同梱。DECISIONS 参照）
• 1.4.2 審査通過後: Remote Config が既定値（v4）であることを再確認 → リリース → iOS1.4.2 タグ → 完了（2026-09-03）: RC v4 既定値・段階的リリース無し・IAP 2件 APPROVED を API で確認 → You が ASC UI でリリース → READY_FOR_SALE → タグ iOS1.4.2（bc1d300）
• 9/4 以降: Crashlytics で AnswerRegion.OnClickAnswerButton NRE と UnloadSceneAsync ArgumentException が 1.4.2 で消えたか確認（Android 1.4.1 も配信済みなので両OS確認可能。dev-timer 未登録）→ 進捗（2026-09-30）: iOS 直近7日の FATAL 全8件で確認 = AnswerRegion NRE は lastSeenVersion=1.4.0（旧版3人10件、1.4.2 では未発生）・UnloadSceneAsync は FATAL なし。残 = Android・NON_FATAL
• 1.4.2 配信後の本番検証＋ベースライン計測（9月中）: Firebase A/B Testing のドラフト実験でテスト端末だけに変数配信 → 価格表示・購入確認 → GA4 で paywall_view 到達とパラメータ分布（カスタムディメンション plan / kaikiri_product / year_product は登録済み）。あわせて paywall_view 数・購入タップ率・ASC 商品別月間件数・1.4.2 普及率を実測し、9月末にテスト期間を確定してトムソンへ報告
• トムソンと価格A/Bの判定ルール・推しプランを合意 → Firebase 側でテスト開始 — 進捗: 設計3点（新規＋既存 / ASC 商品別集計 / 同時1本）を決め、日程提案（12週＋判定1週、10月上旬開始 → 2027年1月上旬判定）を 2026-09-03 に S3 共有済み（DECISIONS 参照）。残 = トムソン回答（設計可否・推しプラン）→ 10月上旬テスト開始
• ストア素材刷新の効果確認（9月上旬）: ASC アナリティクスでプロダクトページ閲覧数と CVR の 1.4.0 前後比較。売上・DL は 8/27 時点で有意差なし
• リリース直前: GA4 カスタムディメンション登録 / ベースラインスナップショット取得 → 2026-07-27 完了（リリース後11日目にずれ込み。登録には編集者権限が必要でトムソン依頼が発生した）。ディメンション3件＋指標 duration_sec、iOS 週次ベースラインは 6/14〜7/25 分を取得
• Claude Code を再起動して .mcp.json（GA4 認証のサービスアカウント移行）を MCP に反映させる → 反映済み確認（2026-08-19、SA 経由の analytics-mcp で効果測定を完走）
• 7/29 頃: カスタム定義の反映確認（streak_bucket が (not set) でないか。5分） → 確認済み（2026-08-19、streak_bucket・duration_sec とも効果測定で正常取得。7/27 以前分のみ (not set)）
• 配信後の Crashlytics 監視: SE.get_Instance 減少 + NRE が SE.Play/PlayCollectTap 側へ移動していないか / Android 上位2件（NativeShare 32件・CheckDependencies 23件）の消滅確認（Android 1.3.2 配信済みのため監視開始可能）
• トムソンへ価格A/B提案（v6）の返答 → 完了（2026-09-02）: 眼球トレ価格AB土台提案.html を S3 共有（検出力試算・土台先行の説明・判定ルール/推しプランの相談を含む）。商品登録指示書も共有し、商品2件の登録・審査提出まで完了
• ストア素材の仕上げ（App Preview 動画・スクショ）: ①未確認SEの権利証跡 → You 判断で「問題なし」としてクローズ（2026-08-17、DECISIONS 参照） ②多言語版ラベル・動画の生成 → 完了（2026-08-17）: スクショ8言語56枚+動画8本を制作・検収・Dropbox納品済（多言語版/） ③提出用29.5秒版の作り直し → トムソン最終OK受領、B案 v3 を 01-overview.mp4 へ差し替え完了（2026-08-17） ④スクショ1枚目（全メニュー動画） ⑤ストア説明文の多言語版（未着手）。スクショ7枚（ja）は効果訴求タグ版で承認済（2026-08-16）
• 多言語ストア素材のトムソン確認 → App Store Connect 登録 → 完了（2026-08-17）: トムソンOK受領後、ASC API で 1.4.0 へ一括登録。iPhone 6.9インチ12ロケール差し替え（旧6.5/5.5枠削除）+ ポスターフレーム + What's New 12ロケール + build 3 添付 + iPad 枠 ja/en 差し替え（新規制作7枚×2、旧iPad動画削除）
• iPad スクショは ja/en のみ → 全9ロケールへ拡大完了（2026-08-18、DECISIONS 参照）: 63枚（9ロケール×7枚）。02 の玉配置を「大きな>字3球」へ刷新＋合成バグ2件（速度ラベル未実装・remove_ball の黒リング）を修正。旧版27枚は history 退避済
• ASC へ iPad スクショを登録 → 完了確認済（2026-08-18）: ローカル素材との MD5 照合で 12ロケール×2枠×7枚＝168枚すべてが最新素材と一致。追加アップロード不要だった
• iPad App Preview 動画の制作（ja/en） → 全9ロケールで完了・ASC 登録済（2026-08-18、DECISIONS 参照）: 1600×1200 / 29.867秒を9本制作し、12ロケール×iPad2枠＝動画24本を登録（全て COMPLETE＋ポスターフレーム指定）。Dropbox 納品も完了
• 1.4.0 を審査提出 → 提出済み・審査通過・2026-08-19 配信開始（8/26 時点で iOS DAU の約86%が 1.4.0）
• 提出前に実機で30秒チェック → 通過済み（レビューポップアップ閉止後の操作正常を確認のうえ提出）

今月

• S-001a: Unity IAP 5.1.x へフルアップグレード（Billing 8 対応、iOS/Android 両マネージャ。2026-06-10 実装。iOS/Android とも実機検証・本番リリース完了 2026-06-25。Android は R8 削除問題を proguard keep で修正）
• S-002 のうちコード実装（Crashlytics SDK 導入 + Privacy Manifest + Info.plist 修正。2026-06-10 実装・push 済、実機テスト待ち）※ iOS 1.2.9 としての申請は実機検証後
• S-001c: Google UMP コンセント要求の実装（2026-06-10 実装・push 済、欧州IP相当の実機確認待ち）
• S-001b: Apple メディカル訴求の整備（規約 HTTPS 化はアプリ側完了=リンク13箇所を https 化。アプリ内 disclaimer は今回見送り。トムソンへ規約の更新日追加・「個人差」明記の依頼は残）
• S-006: App Store スクショ・説明文の刷新（S-002 と同梱、可能なら L-008 代替案「対応表示を iOS/Android のみに絞る」も同時実施）— 進捗: iPhone 12ロケール（2026-08-17）・iPad スクショ168枚・iPad動画24本（2026-08-18）すべて ASC 登録済。残=スクショ1枚目（全メニュー動画）・ストア説明文の多言語版
• ストリーク機能リリース後の効果判定（リリース=2026-07-16）→ 完了（2026-08-19 に前倒しで確定判定・クローズ。判定=本命指標への明確な効果なし・悪影響なし。機能維持で次施策へ、を報告書で提案しトムソン返答待ち）
  • 1週後の健全性ゲート = 合格（2026-07-27 実施）。イベント4本正常発火・重複なし・qualified 漏れなし・1.3.3 で新規クラッシュ0。本命指標の初期値=週あたりプレイ日数/人 1.10（既存 1.18 / 新規 0.51）
  • 8/13（4週）一次判定 → 8/27（6週）確定判定 → 8/19 に完了4週（7/20〜8/16）データで確定判定を前倒し実施（既存 1.18→1.19→1.20→1.10 で横ばい、W4 はお盆。DECISIONS 参照）
  • 判定方法の決め直し → 決定どおり「1.3.3 内の週次トレンド」＋「セッション/人の前後比較」＋ newVsReturning 分割で実施。滞在時間/人は 7/31〜8/1 の外部要因段差があり判定から除外した
• streak_chip_impression の過剰計上を修正 → 1.4.2 に同梱（2026-09-02）。真因は HomeScene 再ロードではなく「プロセス1回フラグ vs 30分以内のプロセス再起動をまたぐ GA4 セッション」。前回送信時刻を永続化して30分以内の再送を抑止（DECISIONS 参照）
• B+C 土台開発（9/1 着手、dev-timer #52） → 完了・1.4.2 として 2026-09-02 審査提出: paywall_view / paywall_purchase_tap + Remote Config（ios_kaikiri_product_id / ios_year_product_id、既定=現行）+ 価格違い商品2件の ASC 登録（トムソン）。実機 Sandbox で表示・購入・復元まで検証済み。配信後の本番検証は今週セクションへ
• トムソンへ価格A/B提案の返答 → 完了（2026-09-02、今週セクション参照）。残=判定ルール・推しプランの合意
• デザイン刷新提案の具体化 → iOS 1.4.0 として 2026-08-19 配信、Android は 1.4.1 に同梱（モック4枚はリポ直下 眼球トレデザイン刷新案/、価格プラン現行のまま）。課金計測イベントは刷新に同乗できず、B+C 土台開発（上記）へ移動。副作用として瞬間記憶の競合が顕在化 → 1.4.1 で修正

今四半期

• L-004: Android 課金状況の継続観測 + 最適化（1.3.1=Billing 8 リリース済 2026-06-25 → 観測開始。GA4 in_app_purchase で課金発生・Crashlytics で本番クラッシュをウォッチ）※ 2026-09-03 判明: GA4 の in_app_purchase は iOS/Android とも 0件（iOS は StoreKit 2 のため Firebase 自動収集の対象外。Android 側の理由は未調査）→ 課金発生は ASC / Play Console の売上で見る
• L-009: Crashlytics クラッシュ対応の継続（SE 修正リリース後の SE.get_Instance 減少確認 + NRE が SE.Play/PlayCollectTap 側へ移動していないか監視。残課題: SE.PlayIfAvailable safe wrapper 化 / Android NativeShareBroadcastListener の PendingIntent FLAG（プラグイン更新）/ Firebase CheckDependencies 前呼び出し）
• Firebase / Unity SDK 更新で GoogleUtilities の nil キー無視の修正版を取り込む（急がない）: 2026-09-29 の Firebase Analytics 障害（sdk-exp の不正ペイロードで iOS 全アプリが key cannot be nil クラッシュ・Google 側で解消済み）を受け、google/GoogleUtilities に修正（#249/#251）が入ったがリリースは未公開（最新 8.1.3 / 8/26）。公開されたら次の SDK 更新で取り込む。現状は Firebase iOS 12.4.0 / GoogleUtilities 8.1.1 / Unity SDK 13.4.0。購入計測用の LogAppleTransactionAsync()（Unity SDK 13.12.0+）を検討するときにあわせて見る（DECISIONS 2026-09-30 / 2026-09-03）
• L-005: 日次売上 / SKU 別 / 国別 + レビュー監視のダッシュボード化（トムソンに ASC API + Play Developer API 依頼が必要）
• iOS 1.3.0 リリース計画（1.2.9 後の次のリリース、内容はその時のデータで決める）
• L-008 代替: macOS / visionOS の対応プラットフォーム表示を見直す（外す方向）

いつか

戦略 B（サブスク強化）本格化のタイミングで再検討

• S-003: NeuroTracker を「完全ロック」→「体験して買う」導線へ
• S-004: Paywall と旧 SKU の整理（CTA 改修、旧 noads ¥1,500 を Removed from Sale に）
• S-005: Firebase Remote Config + 課金ファネル計測の導入 → 1.4.2 で実現（2026-09-02 審査提出）。最小構成（paywall_view / purchase_tap + 商品ID差し替え）。フル9種イベントは必要になったら拡張
• L-001: サブスクに継続価値を作る（月次チャレンジ / 個人プラン）
• L-006: 追加値上げの段階テスト（Paywall 整理 + Remote Config + 計測が揃った後）

中長期テーマ

• L-002: Teleportation を軸に「毎日の 3 分メニュー」と進捗体験（サーキット的アプローチは将来入れる方向と You 判断）
• L-003: 国別ストアページと Paywall の多言語最適化（US / China / India / KR / TW / 欧州）
• L-007: 関連アプリ群を「視覚トレーニングシリーズ (Vision Suite)」として扱う（トムソン側のシリーズ戦略次第）
• ASO 対策メモの蓄積場所を整備
• ストア説明文の version 管理

却下・代替案検討

• L-008 却下、代替案として「macOS / visionOS の対応プラットフォーム表示を外す」（今月セクションに移動済み）

完了済み

• 運用業務の方向性決め（→ 売上分析 + GA4 分析の 2 枚ダッシュボードで定例観測体制が確立、2026-06-02）
• 売上 / DAU / クラッシュレートの定期集計の仕組み化（→ 売上 HTML + GA4 分析 HTML で実現、2026-06-02）
• iOS の課金画面 UI を実機スクショで取って Claude に共有（→ 2026-06-02 完了、Pro 機能体験動線の欠如が核心と特定）
• 提案書フォーマットを HTML に決定（2026-06-03）
• Codex セカンドオピニオン取り込み（2026-06-03、13 件の指摘を提案書 v3 に統合）
• 規約・提出要件監査の 4 項目掘り下げ（2026-06-03、Android 16KB は対応済み / Health declaration は提出済みと判明）
• 全 16 件の提案ステータス確定（2026-06-03、アクティブ 7 / 保留 8 / 却下 1）

意思決定記録

このプロジェクトで下した重要な意思決定を記録する。 最新が上に来る。

---

2026-09-30: Firebase Analytics 障害（sdk-exp）によるクラッシュにアプリ側の対応はしない（ホットフィックス・SDK 緊急更新なし）

背景: 9/29 に Vision Training ほか5アプリで同一の key cannot be nil クラッシュ警告メールが届いた（Vision Training は 1.4.2 で34件/34人）。調査の結果、Google Analytics for Firebase の sdk-exp（実験ペイロード）に不正データが配信された Google 側の障害で、Firebase 公式がサーバー側ロールバックで解消済み（9/30 のクラッシュは0件）。

決定: ホットフィックスや SDK の緊急更新はしない。GoogleUtilities の nil キー無視の修正版（9/29 にマージ済み・未リリース）が公開されたら、次回の Firebase / Unity SDK 更新で取り込む（急がない）。

理由: 原因がサーバー側で、公式が「SDK 更新は不要」「すぐ更新する必要はない」と明言し、継続クラッシュの証拠もない。アプリ側で出すホットフィックスは（App Review を通しても）修正版 SDK が未公開の現状では再発防止にならない。You が了承（「ok」）。

---

2026-09-03: 価格A/Bテストの対象は「新規のみ」ではなく iOS・日本・1.4.2 以降の無料ユーザー全員（新規＋既存）にする

背景: 判定に必要な購入件数（対照群で −40% 検出に約79件、半減で約47件）に対し、新規限定だと年額トライアル開始が1群 約11件/月で、半減級でも 4.3ヶ月・−40% は 7ヶ月かかる。既存の無料ユーザーを含めると 約19件/月で 2.5 / 4.2ヶ月。

決定: 既存の無料ユーザーも対象に含め、iOS・日本・1.4.2 以降の全員を 50:50 に分ける。

理由: 期間が約半分になる。代償は以前 ¥3,400 を見た既存ユーザーに ¥4,800 が表示される評判リスクだが、日本のみ・期間限定で許容（You 判断「短い方がいい」）。土台提案（9/1）で「新規のみ」としていた点の変更。

---

2026-09-03: 購入完了イベントは追加せず、群別の購入件数は ASC の商品別売上で集計する

背景: Firebase 自動収集 in_app_purchase は StoreKit 1 専用で、Unity IAP 5（StoreKit 2 既定）では GA4 に届かない（6/1〜9/2 で 0件、公式 docs で確認）。対応するには Firebase Unity SDK 13.12.0+ の LogAppleTransactionAsync() か、自前の purchase_success イベントを載せた 1.4.3 が必要。

決定: 1.4.3 は出さない。変数群はテスト専用商品（t4800 / t2400）を買うので ASC 商品別で正確に分離でき、対照群は現行商品（gen2.*）の件数から未更新ユーザー分を差し引いて推定する。GA4 で群別に見るのは paywall_view / paywall_purchase_tap。

理由: 全ユーザー対象なら対照群の混入は未更新ユーザーだけで数週間で解消し、推定で足りる。アプリ更新をなくして日程を守る。

---

2026-09-03: 買い切りと年額を同時に変えてテスト1本にする（v6 の「1変数ずつ順番」はやめる）

背景: v6 は買い切り → 年額の順に2本。買い切りは 約5.5件/月/群 で、売上維持ラインの検出に 29ヶ月・半減でも 8.5ヶ月と単独では判定不可能。順にやると期間だけが倍になる。

決定: 変数群に 4,800円＋2,400円を同時に出し、年額（トライアル開始件数・閲覧者あたり売上）で判定、買い切りは方向性のみ参考にする。

理由: 最終的に採用したい「両方上げた状態」をそのまま検証できる。どちらの値上げが効いたかは分離できないが、片方だけ上げる案を残す必要がなければ実害はない（You「順番にする必要ないよね」）。

---

2026-09-03: 判定日程はトムソンの回答を待たず、こちらから目安を提案する（12週＋判定1週、4週目は中止判断のみ）

背景: 土台提案（9/1）で判定ルールを3案（期間延長 / 上流指標併用 / 悪化なし＋方向性）提示して回答待ちだったが、You が「こっちから目安を提案したい」と方針転換。

決定: テスト12週、終了＋1週（3日トライアルの課金確定・返金待ち）で判定、開始4週目は中止判断のみ。採用方向 = 閲覧者あたり売上（全プラン合計）が対照群を下回らない、不採用 = 年額トライアル開始が −40% 超の減少、中止 = 半減水準。

理由: 12週は年額 約19件/月/群 で −40%〜半減級を検出できる下限。売上維持ライン（−25%）の厳密判定は約12ヶ月かかるため目標にしない。ベースライン計測（9月）の実数で期間は再確定する。

---

2026-09-02: iOS 1.4.1 の単独提出はやめ、1.4.2（価格A/B土台同梱）として提出する

背景: 1.4.1 ホットフィックスは Android（versionCode 25）は配信したが、iOS は ASC にバージョンすら作られておらず未提出だった。土台開発（B+C）が同日中に実装・検証できる見込みだった。

決定: iOS は 1.4.1 を飛ばし、瞬間記憶の退行修正と価格A/B土台をまとめて 1.4.2 として1回で提出する。

理由: You のビルド作業（Unity → Xcode → ASC）が1回で済み、審査も1回。退行は iOS で1〜2週間長く残るが、レビューへの影響は出ておらず許容と判断。

---

2026-09-02: 価格A/B土台の設計（Remote Config は iOS のみ・既定=現行・許可リスト・ストア価格の分解表示）

背景: v6 提案の価格A/Bは Remote Config の出し分けと課金計測が前提だが、アプリには両方なかった。既存ユーザーに影響を出さずに「Firebase 操作だけでテスト開始できる状態」を1回のアプデで作る必要があった。

決定: ①RC キーは ios_kaikiri_product_id / ios_year_product_id の2つ、既定値=現行商品ID、値は既知の商品IDのみ受け付け未知は既定へ。Android/Editor は常に既定 ②テスト価格版2商品は RC の値に関わらずカタログに常時登録し、購入者はエンタイトルメント判定に含める ③変数が有効なときだけ、ストア取得の現地価格を「整数部・小数部・月あたり」に分解して I2 バインドの Text を上書きする（通貨記号は I2 のまま）④3か月プランは差し替え対象外 ⑤計測は paywall_view（表示商品パラメータ付き）と paywall_purchase_tap（plan）に絞り、購入・売上は Firebase 自動収集の in_app_purchase を使う。

理由: 既定値=現行なら Firebase 側で何もしなければ従来と完全に同じ動作で、配信リスクがゼロ。許可リストで RC コンソールのタイプミス事故を防ぐ。価格表示は I2 の「通貨記号＋整数＋小数」構造をそのまま使えば、変数価格の画像やローカライズ文言を用意せずに現行デザインを維持できる。Android は v6 が iOS 先行のため対象外にし差分を最小化。

---

2026-09-02: streak_chip_impression は前回送信時刻を永続化して30分以内の再送を抑止する

背景: 仕様「1セッション1回」に対し実測 1.14/セッション。原因は「プロセス1回」の静的フラグに対して GA4 セッションが30分以内のプロセス再起動をまたいで継続するため、再起動ごとに再送されていたこと（当初推測の HomeScene 再ロードは静的フラグで既に防げていた）。

決定: 静的フラグは残したまま、送信時刻を PlayerPrefs に保存し、30分（GA4 のセッションタイムアウト）以内なら送らない。

理由: 過剰計上の主因を潰しつつ、新たな送信を増やさない厳密に改善方向のみの変更。長時間1プロセスでセッションをまたぐ場合の過少計上は従来どおり残るが稀。

---

2026-09-02: テスト価格商品の命名・表示名・配置

背景: 価格A/B用に買い切り 4,800円版と年間 2,400円版を ASC に新規登録する必要があり、Apple の 2.3.2（同一メタデータの類似商品）リジェクト事例を避けたい。

決定: 製品IDは jp.thomsons.visiontraining.gen2.pro.t4800 / jp.thomsons.visiontraining.membership.gen2.1year.t2400。表示名は12言語とも「Pro+」系（例: Pro+（買い切り）/ Pro+（年間））で現行「Pro（…）」と重複させない。App Store プロモーション対象には載せない。年間版は同グループで現行年間と同列（レベル1）、トライアル3日・ファミリー共有は現行と同一。買い切り版もファミリー共有オン。

理由: 価格以外の条件を揃えないと価格テストにならない（ペイウォールでファミリー共有を Pro 特典として訴求しているため特に）。表示名の差別化は審査対策、プロモート非対象は「アプリ内でのみ見える実験用商品」として扱うため。

---

2026-09-02: 1.4.2 の What's New は「軽微な不具合修正」の汎用文面にする

背景: 当初は瞬間記憶の「もう一度」後に操作不能になる修正を具体的に書いた文面を12ロケール投入していた。

決定: You の指示で「軽微な不具合を修正し、安定性を向上しました」系の汎用文面に差し替え（12ロケール、1.4.0 の各言語の語彙に合わせた）。

理由: 退行の具体的な症状をストアに書くメリットがない。計測基盤の追加もユーザーに見える変化ではない。

---

2026-09-02: 1.4.2 の審査提出はトムソン側が行う（アプリ＋App 内課金2件を同一提出に同梱）

背景: バージョン作成・What's New・ビルド紐付けまでは ASC API で完了できるが、App 内課金を審査提出に載せる操作（「審査用に追加」）は API に存在せず UI 限定。商品を登録したのもトムソン。

決定: 提出操作はトムソンに一任する。ただし You/私は API で状態を確認し、ズレ（商品だけ単独提出・アプリが未送信）があれば指摘して直してもらう運用にする。

理由: 操作権限と作業の連続性がトムソン側にあり、API で結果を検証できるので任せてもリスクが低い。実際に単独提出→同梱への修正を1往復で解消できた。

---

2026-08-27: Android 1.4.0 の申請を止め、瞬間記憶の退行を修正した 1.4.1 を両OS同時配信する

背景: Android 1.4.0（versionCode 23）を申請する当日、iOS 1.4.0 の Crashlytics で瞬間記憶の「もう一度」後に回答キーが無反応になる退行（8日で467件/78人、プレイヤーの約11%）が見つかった。Android は同一コードなので、そのまま出せば同じ退行が載る。

決定: 申請を止めて修正を先に入れ、iOS 1.4.1 / Android 1.4.1（versionCode 25）として両OS同時に配信する。ホットフィックスは瞬間記憶の修正だけに絞り、計測基盤や streak_chip_impression 修正は同梱しない。

理由: 修正は小さく（Singleton の実体選択・二度押しガード・安全なアンロード）1日で検証まで済んだ。Android 側のストリーク・刷新の配信が1〜2日遅れる代償より、瞬間記憶ユーザーの1割が困る期間を作らない方を取った。ホットフィックスを薄く保つのは、検証範囲を最小にして早く出すため。

2026-08-27: 次アプデの順番は「1.4.1 ホットフィックス → B+C 土台（既定値=現行価格で配信・本番確認）→ トムソン価格A/B」

背景: 7/27 に決めた「刷新 → 計測基盤 → 価格検証」のうち刷新は 1.4.0 で完了したが、1.4.0 に課金計測イベント（paywall_* / purchase_*）は載っておらず、Remote Config も無い。トムソンの価格A/B提案（v6）は出し分けと計測がある前提で書かれている。

決定: 1.4.1 の後に B（課金ファネル計測イベント）＋C（Remote Config で商品IDを差し替える仕組み＋価格違い商品の ASC 登録）を土台として1回のアプデで配信する。土台は Remote Config の既定値=現行価格（ユーザーから見て無変化）で出し、イベント到達・RC 取得・テスター限定の商品差し替え・課金通しを本番で確認してから、Firebase 側の操作だけでテストを開始する。最小構成は C + 商品登録 + paywall_view（売上は Firebase 自動収集の in_app_purchase 等で代替可）。9/1 着手（dev-timer #52）。

理由: 土台とテスト開始を分けることで、テストの開始・停止・配分変更をアプリ更新なしに行える。土台を先に本番で動作確認してからテストに入る方が安全（You の判断）。検出力不足（日本新規の買い切りは1群あたり月数件）は土台では解消しないので、トムソンへの返答ではそこを本体として伝える。

2026-08-27: SingletonMonoBehaviour は別シーンの旧実体より新実体を優先し、「もう一度」は同一フレーム Unload→Load を維持する

背景: 加算ロードした同名シーンを Unload→Load すると、実機では旧実体の破棄前に新実体が Awake することがある。従来の Singleton ガードは「先にいる方が正」で新実体を破棄していたため、新シーンの Start() が走らず回答キーだけが表示される退行になった。修正案として「アンロード完了を待ってからロード」も試したが、待ち時間に下の難易度選択画面が一瞬見えた。

決定: SingletonMonoBehaviour.Awake は、既存実体が別シーンなら新実体を Instance に採用し（同一シーン内の重複は従来どおり破棄）、OnDestroy で静的参照をクリアする。「もう一度」は従来どおり同一フレームで Unload→Load し、アンロード完了は待たない。二重アンロードは SceneUtil.UnloadIfLoaded と二度押しガードで防ぐ。

理由: 派生クラスは FlashMemoryTestPlayScene だけで、シーンを跨いで生き残る用途は無いため「新しい方が正」で問題ない。競合が起きても壊れない構造にすれば、見た目は 1.4.0 と同じままにできる。シミュレータでは競合を再現できないので、順序に依存しない設計にする方が確実。

2026-08-19: ストリーク効果測定は4週データで確定判定し、前倒しでクローズ

背景: 確定判定は 8/27（6週）予定だったが、iOS 1.4.0 の審査通過を機にトムソンへ結果を共有したい状況になり、リリース後の完了4週分（7/20〜8/16）のデータが揃っていた。

決定: 4週データで確定判定を実施。判定は「本命指標（週あたりプレイ日数/人）への明確な押し上げ効果なし・悪影響なし」。機能は現状のまま残して測定をクローズし、テコ入れ（リマインダー通知等）は優先度を下げて次施策へ進む方針を報告書で提案する。

理由: 本命指標・診断指標（CTR、streak_bucket 分布）とも4週間完全に横ばいで、あと1週待っても判定が変わる見込みが薄い。計測プラン v3 の判定レンジ（4〜6週）内でもある。滞在時間の +30% は 7/31〜8/1 の段差・実プレイ秒横ばいから外部要因と判断し、判定材料から除外した。

2026-08-19: トムソン向け HTML 共有を thomson-share スキルとして定型化

背景: レポート・提案書・モックをトムソンへ共有するたびに、S3 のコマンド・命名・公開方式を都度組み立てていた。

決定: プロジェクトレベルのスキル .claude/skills/thomson-share/ を新設。方式は既存共有物と同じ thomsons バケット（profile=thomson-ik）への public-read 配置、命名は <名前>_YYYYMMDD.html、更新は同一キー上書きで URL を維持、--cache-control no-cache を常用。

理由: 過去の共有実績（2026-06 以降の提案書・モック）と同方式のため、トムソン側の受け取り方が変わらない。presigned URL は有効期限の管理が発生するため不採用。

背景: 8/17 時点では iPad 素材は ja/en のみと決めていたが、スクショを全9ロケールへ拡大した経緯があり、動画だけ2言語では釣り合わない。

決定: iPad プレビュー動画も iPhone 版と同じ9言語（ja/en/es/pt/fr/de/zh-Hant/zh-Hans/ko）で制作し、ASC には12ロケール（地域変種含む）へ登録する。

理由: レンダリングを --locale でパラメータ化した結果、追加コストの大半は撮影のみになった。撮影も AXe 導入で自動化が安定したため、9言語でも現実的な工数に収まる。

---

2026-08-18: zh-Hant / zh-Hans / ko は 01〜05 も撮り直す（ja 素材の流用をやめる）

背景: ゲーム画面には言語依存の文字がないため 01〜05 は ja 素材を流用する設計にしていたが、この3ロケールだけアプリ内の速度ラベルが NORMAL ではなく 一般 / 正常 / 정상 と表示される。

決定: zh-Hant / zh-Hans / ko については 01〜05 も各言語で撮り直す。es/pt/fr/de は NORMAL 表示なので ja 流用を継続。

理由: 代替案としてヘッダー文字の差し替え（iPhone 版の手法）を検討したが、iPad は画面ごとにヘッダーの実寸が異なり（01/03/04 は同一、02 と 05 は別サイズ）、画面別ジオメトリの実装と検証が必要になる。撮影は自動化済みで確実なため、撮り直しの方が低リスクと判断した。

---

2026-08-18: シミュレータ操作を cliclick から AXe へ移行

背景: cliclick は画面上の絶対座標を叩くため、Simulator が別スペースにある / ウィンドウ位置が動く / デバイスの向きが変わる のいずれでも破綻し、本セッションだけで3回撮影が停止した。

決定: AXe（brew install cameroncooke/axe/axe、MIT ライセンス）を導入し、sim_tap.py を AXe ベースに置き換える。座標はデバイス座標の半分（論理ポイント）を渡す。

理由: AXe は Apple の HID 経由でデバイスへ直接イベントを送るため、ウィンドウ位置・向き・スペースのいずれにも依存しない。加えてマウスカーソルを奪わないので、撮影中に別の作業を続けられる。無料の OSS で導入コストも低い。

---

2026-08-18: ブランド締めのホーム画面は静止プレート方式にする

背景: ホーム画面ではポイント獲得バッジ（白丸）が画面左から Play ボタンへ飛ぶ演出が1秒おきに繰り返され、32秒の収録でもバッジ無しの連続区間は最長 1.25秒しか取れなかった。締めには 3.5秒必要。

決定: 締めの下地は動画ではなく、バッジが写っていない1フレームを静止させたプレートを使う。ブラケットの展開・コピーのリビール・トランジションはオーバーレイ側なので動きは保たれる。

理由: バッジが出入りする映像はストア素材として不自然で、抑制する設定も見つからなかった。締めは元々ほぼ静止した画作りであり、静止プレートでも成立する。ロケールごとにクリーンなフレームを目視で選定して STILL_TIME に記録している。

---

2026-08-18: 締めのブラケット幅をコピーの実測幅に連動させる

背景: ブラケット半幅を固定値にしていたため、コピーが長い fr / de では fitted_font が 85% 下限でも収まらずエラーになり、短い訳では間隔が広くなりすぎていた。

決定: ブラケット半幅 = コピーの実測半幅 + 90px とし、全ロケールで間隔を一定に保つ。

理由: ja の見た目（半幅 419px）は変わらないまま、fr（550）de（590）も画面内に収まる。将来ロケールを追加しても調整不要になる。

---

2026-08-18: 種目名ピルの縦位置は cap height 基準で中央化する

背景: 上流の make_menu_label_overlay.py はフォントのメトリクス（アセンダ・ディセンダを含む範囲）で中央化しており、descender やウムラウトを持つ語（Teleportation / MOT Fähigkeit）が視覚的に上へずれていた。さらに「en の4ラベルだけ +2px 下げる」という手動補正が入っており、そちらは逆に +4px ずれていた。

決定: 手動補正テーブルを使わず、cap height（大文字上端〜ベースライン）の中央がピル中央に来るよう補正値を算出する（ipad_video._optical_offset）。iPhone 版のスクリプト自体は変更しない。

理由: タイポグラフィ上、行の視覚的中央は cap height の中央であり、張り出しの有無に左右されない。実際に補正が入るのは張り出しを持つラテン語のみで、CJK は 0（既存の見た目が変わらない）。

---

2026-08-18: 新規収録した raw は 180度回転して既存素材と向きを揃える

背景: 撮影途中でシミュレータのデバイス向きが失われ、復旧後は収録映像が従来と 180度ずれた状態になった。設定ファイルの書き換えでは戻せなかった。

決定: パイプライン側で向きを分岐させず、収録直後に hflip,vflip を掛けて既存素材（ja/en）と同じ向きに正規化する（sim_capture.normalise_orientation）。

理由: クリップごとに transpose を切り替えると、ja 流用と新規撮影が混在する 01〜05 で条件分岐が複雑になり事故を招く。素材側を揃えれば後段は一切変更不要で、再エンコードによる劣化も最終的な 1600×1200 へのダウンスケールに埋もれる。

2026-08-18: iPad スクショを全9ロケールへ拡大する（8/17 の「ja/en のみ」を撤回）

背景: 前日に「iPad 素材は ja/en の2ロケールのみ」と決めていたが、iPhone 用に作った翻訳データとレンダラーがそのまま流用できる状態になっていた。

決定: iPad 13inch のスクショを全9ロケール（ja / en / zh-Hant / zh-Hans / ko / es / pt / fr / de）で制作する。iPad 動画は引き続き ja/en のみ。

理由: レンダラーが --locale でロケール別ヘッダー差し替えまで自動化できており、追加コストが実質「スクリプト実行と検証」だけになった。前日の決定理由は「9言語×2枠の制作・検収コストに見合わない」だったが、そのコスト前提が崩れたため撤回する。動画は 4:3 再構成の実作業が残るのでスクショとは切り離す。

2026-08-18: 02-teleportation の玉配置は「大きな>字3球」を採用する

背景: iPad 移植時の 02 は撮影位置そのままで、3球が横380px（画面幅の14%）に固まり、最後の1手が内側に戻るため進行感が出ていなかった。4:3 の広いフィールドに対して構図が縮こまっていた。

決定: iPhone 承認版と同じ「>」字を 4:3 へ大きく展開した3球配置を採用（(1560,560) → (2520,1150) → (1620,1800)、横960px・縦1240px）。候補として作った Z字4球・加速カーブ4球は TELEPORT_LAYOUTS に残す。

理由: 3案を比較した結果、iPhone 版と意匠が揃うこの案が最も自然で、シリーズとしての一貫性も取れる。玉の位置は座標指定なので後からの微調整が容易。撮影し直しは不要（既存フレームの実画素を移送するだけ）。

2026-08-18: iPhone 側の同種リングバグは修正しない

背景: iPad の remove_ball で見つけた合成バグ（透明レイヤーへ paste 後に alpha_composite して二重乗算になり、ぼかし境界が最大25%暗くなる）と同じパターンが iPhone 用レンダラーの2箇所（render_static.py:349 = iPhone 02、render_zigzag.py:137 = iPhone 04）にもあり、提出済み iPhone 素材9ロケールが該当していた。

決定: iPhone 側は修正せず現状維持とする。iPad 側（02/04/06 × 9ロケール）のみ修正する。

理由: iPhone 版のリングは玉の近傍にあって目立ちにくく、実害が小さい。一方で修正すると提出済み9ロケール分の再生成と ASC 再アップロードが発生する。iPad は 02 の配置変更でどうせ差し替えるため、ついでに直すコストが小さかった。

2026-08-17: iPad ストア素材は ja/en の2ロケールのみ制作する

背景: 1.4.0 の iPad 枠には旧デザインのスクショ・動画が12ロケール分残っており、iPhone 同様に全ロケール刷新するかの判断が必要だった。

決定: iPad 用の新素材（スクショ7枚+動画）は ja と en-US の2ロケールのみ制作・差し替える。他10ロケールの iPad 枠は旧素材のまま残す。

理由: iPad はトラフィック比重が小さく、9言語×2枠の制作・検収コストに見合わない。主要市場（日本）とグローバル既定言語（英語）を押さえれば実害は限定的。将来必要になればレンダラー（--locale 対応済み）で追加生成できる。

2026-08-17: 1.4.0 の iPhone 枠は 6.9インチのみ運用（旧 6.5/5.5 枠を削除）

背景: 1.4.0 ドラフトには旧デザインの 6.5/5.5 インチスクショ・動画が引き継がれており、新素材（6.9インチ）とデザイン混在になる状態だった。

決定: 1.4.0 から旧 iPhone 枠（APP_IPHONE_65/55、対応プレビュー含む）を削除し、6.9インチ枠のみに新素材を置く。削除前に全メタデータを退避（backup-old-sets-1.4.0.json）。

理由: 現行 App Store は 6.9インチ1系統で全 iPhone サイズに自動縮小適用されるため、旧枠を残すと小型機種にだけ旧デザインが表示されて逆効果。ライブ 1.3.3 の枠は別リソースなので公開中の表示には無影響。

2026-08-17: iPad 版スクショはレンダラーの iPad 移植で自動生成（Codex 発注せず）＋実画素レタッチを許容

背景: iPhone 多言語展開では Codex に画像加工を発注したが、iPad 版の制作方式を決める必要があった。またゲーム側のレイアウト都合（タイル点灯位置・MOT玉の重なり・周辺視野の注視点=中央固定）でコピーと被るケースへの対処も必要だった。

決定: iPhone 版レンダラー（render_static.py）を iPad キャンバスへ移植した render_ipad.py / render_ipad_screens.py で ja/en を自動生成する。被り対処は「同一セッションの実フレーム画素による移植・消去」（タイル点灯セルの転写、MOT 重なり玉の消去+シアン玉移動）を許容する。

理由: レンダラーが翻訳データ・ヘッダー差し替えまでパラメータ化できたため、Codex 発注は「スクリプト実行だけの作業」になり分業の意味がない。レタッチは合成元がすべて同セッションの実ゲーム画素であり、実体験を偽らない範囲（iPhone 版のゴースト合成と同じ思想）。

2026-08-17: 動画音声の権利確認は「問題なし」としてクローズ

背景: COPYRIGHT_AUDIT.md に記録していた未確認SE（object.mp3 等）の扱いを、ASC 登録のタイミングで判断することにしていた。

決定: You の判断で「権利関係は問題ない」としてクローズし、公開ブロッカーから除外する。

理由: You 側で権利状況を確認済み（経緯の詳細記録は You 側）。以後この件で公開を止めない。

2026-08-17: 1.4.0 提出ビルドは作業ツリー現状の build 3 とする

背景: ASC には 8/6-8/7 アップロードの build 2 が既存だったが、その後の作業ツリーに未コミットの改善（瞬間記憶回答スロットの表示防御修正、MOTボール新テクスチャ）が積まれていた。

決定: 作業ツリー現状から build 3 を新規ビルドして提出ビルドにする（ビルド番号 2→3）。

理由: ストア動画・スクショは新MOTボールで撮影済みのため、build 2 のままだと素材と実アプリの見た目がズレる。スクリプト差分も出荷に値する防御的修正のみで、リスクよりも整合性の利益が大きい。

2026-08-17: ストア素材の多言語展開は「ja素材流用＋文字差し替え」方式で行う

背景: スクショ・動画の8言語展開にあたり、素材をロケール毎に撮り直すか ja 素材を流用するかの方針が必要だった。

決定: 事前調査で言語依存箇所を洗い出し（スクショ=08ヘッダーのみ、動画=MOTヘッダー・瞬間記憶回答画面・zh/koの速度ラベル・締めホーム）、ホーム画面以外は ja のゲーム画素をそのまま流用して文字だけ帯置換する。撮り直しは締めカットのホーム画面のみ（ほぼ静止画面で構図リスクがないため）。

理由: 厳選済みのボール配置・構図が撮り直しで崩れるのを防ぎ、8ロケールの見た目を ja と完全に揃えられる。帯置換は render_3d.py に前例があり決定的に検証可能。zh/ko の NORMAL 差し替えはスクショと動画でストアページ内の整合を取るため。

2026-08-17: アプリUI由来の文言はアプリ内 I2 実文言を一字一句使用（粗さも据え置き）

背景: 種目タイトルラベルやフッテージ内指示文の翻訳に、アプリ内の既存訳（es「Teletransportacion」のアクセント欠落、de「Flash-Speichertest」等の粗さ）をそのまま使うか、直した訳を使うかの判断が必要だった。

決定: アプリUIを模倣・差し替えする文言はすべて I2 の実文言を一字一句使用し、変更禁止とする。粗さの修正はアプリ側 I2 の修正が先（将来のアプリ更新候補としてメモ）。マーケコピー（キャッチコピー・スクショ見出し等）は自由に翻訳し、Codex レビューで品質担保する。

理由: 締めカットにホーム実映像が映るため、ラベルだけ直すと実物と不一致になる。ストア素材はアプリの実体験を反映すべきという審査要件とも整合する。

2026-08-17: ロケール版ホーム素材の Pro バッジ非表示を許容

背景: ja のホーム素材には Pro バッジが映っているが、Pro 判定は IAP 初期化必須のためプレフ書き換えでは復元できず、撮影当時の一時パッチビルドの再ビルド（15〜25分＋撮り直し）が必要だった。

決定: ロケール版は Pro バッジなし（アイコン7個）のまま撮影・採用する。

理由: 締めカット3.5秒での7個/8個の差は軽微で、各ロケールの視聴者が ja 版と見比べることはない。再ビルドは 8/16 以降のメインライン変更が映像に混入するリスクがあり、差分を増やす方が害が大きい。気になれば後からパッチ再ビルド＋撮り直しで差し替え可能。

2026-08-16: App Store 30秒版はB案構成（瞬間移動開幕→メニュー＋ブランドコピー締め）を採用

背景: 30秒版 v4（静止ホーム＋「目で追いかけてください」開幕）に対し、トムソンから「静止したメニュー画面では追う対象が無い」という指摘と代案（瞬間移動「その一瞬を、捉えろ」開幕→メニュー「見る力を、鍛える。」締め）が提示され、判断はこちらに委ねられた。

決定: B案を実際にレンダリングしてA案と見比べたうえで採用。さらに You の「締め文言表示前に0.5秒の間」とトムソンの「冒頭を静止スタートに（1フレーム目を0.5秒フリーズ、凍結点は文言が完全表示になる2.60秒地点）」を反映した v3（29.85秒）を確定版とする。A案 v4 と B v2 も Dropbox に併置し比較・巻き戻し可能な状態を残す。

理由: App Preview はストア上でミュート自動再生され最初の2〜3秒が勝負のため、1コマ目から動きがある構成が Apple 推奨のセオリーに合う。「その一瞬を、捉えろ」も命令形で「考える前に参加させる」フックの狙いを維持でき、メニュー締めは7種目の網羅感＋ブランドタグで綺麗に閉じられる。理屈だけで決めず、ツールが揃っていて低コストな実制作比較で判断した。

2026-08-16: App Store 用30秒版は「FIXフル版の縮約＋冒頭に参加フック」で作る

背景: App Preview は15〜30秒制限のため、トムソンが GO を出した55.6秒フル版はそのまま iOS へ提出できない。またトムソンから「元動画の『目で追いかけてください』＝考える前に参加させる仕掛けが新版で落ちる可能性」の指摘があった。

決定: フル版から各シーンを実尺のまま切り出して28.45秒に縮約し（早送り・種目削減はしない）、冒頭2.5秒を「目で追いかけてください」フック（元タイトルと同じHUDブラケット演出）に差し替える。フル版は Google Play・プロモ用に温存。フック別バージョンを後日PPOで実験する案は、30秒版への内蔵で先取り解消とする。

理由: 早送りは「実際の体験を反映」という審査要件に抵触するリスクがある。種目削減は「7種目の網羅感」というフル版のコンセプトを壊す。切り出し窓は各動画に焼き込まれた2部構成コピー（前半フレーズ→決めゼリフ）の区切りに合わせれば文が切れない。フックは静止ホーム画面＋指示文なら変更最小で v1 構成を保てる（ボール同時表示案は PPO 対抗馬として温存）。

2026-08-16: スクショ下部タグは効果訴求型へ変更（トムソン案＋3微調整、後出し方式）

背景: トムソンから「タグは仕様・機能でなく『何が鍛えられるか』を伝えるべき」と具体案（①鍛える能力｜②補助的な能力｜③手軽さ/難易度）の提案。ただし一部文言に同義重複・単体で意味が取れない箇所があった。

決定: トムソン案を基本に3箇所だけ微調整して反映（PERIPHERAL VISION②「視野の広さ」→「状況把握」/ MEMORY TEST③「4段階」→「速度4段階」/ MOT SKILL③「2〜4個」→「ボール2〜4個」）。進め方は事前相談でなく「変更して完成物で確認を取る」後出し方式（You 指示）。あわせてチップ描画を実測文字幅からの自動算出に改修。

理由: 「周辺視野｜視野の広さ」は①②がほぼ同義で2枠の価値が薄い。「4段階」「2〜4個」は単体では何の数か伝わらない。自動幅化は文字数が変わる将来の多言語化にも効く。

2026-08-01: iOS シミュレータ確認環境は「arm64 のまま vtool 変換」方式で確立

背景: ホーム刷新の見た目確認を高速化するためシミュレータ起動が必要だったが、Unity 2022.3 + Firebase 構成はシミュレータ向けネイティブライブラリが無く、そのままではビルド・起動できなかった。

決定: x86_64 固定や Rosetta には行かず、arm64 のまま通す。Unity 側3ライブラリ（baselib / libil2cpp / libiPhone-lib）は Unity 同梱の sim 版に差し替え、device 専用の静的ライブラリ4つ（unity-plugin-library / Firebase 3種）は arm64 スライスの Mach-O platform を vtool で IOSSIMULATOR(=7) に書き換えて使う。

理由: arm64 の機械語は device/simulator で共通なので識別子の書き換えだけで動く。Firebase を外す・偽装する必要がなく実挙動（Analytics 送信まで）を確認できる。Apple Silicon の Simulator でネイティブ動作し、Xcode 26 では Rosetta シミュレータ自体が使えないため実質唯一の筋。Codex が同じ問題で x86_64 方向にハマったのを引き戻した実績もあり、確立手順として固定する。

2026-08-01: 品質要求の高い画像アセットは You が Codex に直接指示する方式に切り替え

背景: フッターアイコンの刷新で、Claude 経由の Codex CLI 依頼（プロンプト設計→一括生成）を2回試したがモックの質感に届かなかった。

決定: ビジュアル品質が重要なアセットは You が Codex デスクトップと直接反復する。Claude は保存先・命名・背景条件などのファイル規約と後処理パイプライン（透過化・Unity 反映）を提供して受け側に回る。

理由: 仲介を挟むと1反復が重く、視覚評価の解像度も落ちる。直接対話は試行回数を稼げて品質収束が速い（フッター9種+Play リング+背景バリアント等が短時間で完成した実績）。役割分担として「生成=Codex 直接、組み込み=Claude」が現状の最適。

背景: トムソンから iOS 価格A/Bテスト提案（買い切り 3,400→4,800円・年額 1,800→2,400円を順番に検証、最短5週間）を受領した。一方 You は前回リリース（ストリーク）の効果測定後にデザイン刷新（ホーム/プレイ/設定/ペイウォールのモック4枚あり）を提案する構想を持っていた。

決定: デザイン刷新を先に進め、価格検証はその後に回す。トムソンへは実データの検出力試算を共有した上で順番の入れ替えを提案する方向。

理由: ①刷新モックにペイウォールが含まれており、旧デザインで価格テストをしても刷新後に結果が保証されない（逆順だとやり直しになる）。②提案自身の「1回のテストで変える変数は1つ」「価格確定後に表現を改善」という原則とも整合する。③実データ検証で価格A/Bの検出力不足が判明しており（iOS 買い切りは日本11件/月、判定に数ヶ月〜年単位）、刷新でコンバージョンのベースラインを上げることが価格検証の期間短縮にもつながる。④計測イベント実装（現状 GA4 に課金イベントゼロ）は刷新の効果測定と価格テストの共通基盤なので、刷新リリースに同乗させれば二度手間にならない。

2026-07-27: GA4 のプログラム的アクセスをサービスアカウント方式に統一

背景: analytics-mcp が 403 で使えなくなり、原因は ADC（個人アカウントの OAuth）のスコープ不足だった。復旧の過程で、自前 OAuth クライアントの同意画面が「テスト」ステータスのため refresh token が7日で失効すること、さらに個人アカウントは閲覧者どまりでカスタム定義の登録権限が無いことが判明した。6/1 に「GA4 の UI がサービスアカウントのアドレスを拒否する」と判断して OAuth 方式を選んだが、実際には footballnext のプロパティに同じサービスアカウントが追加できており、その判断材料が誤っていたことも分かった。

決定: GA4 へのプログラム的アクセスはサービスアカウント ga4-mcp@ichirokisanuki.iam.gserviceaccount.com に統一する。トムソンにプロパティ 271861292 へ編集者で追加してもらい、.mcp.json の GOOGLE_APPLICATION_CREDENTIALS をそのキーファイルに、GOOGLE_PROJECT_ID を SA 自身のプロジェクトに変更した。個人アカウントの ADC は使わない。

理由: ① 7日でのトークン失効から解放され、ブラウザ再認証が不要になる ② スコープを自分で名乗れるので analytics.edit 追加でブラウザ往復が発生しない ③ 個人アカウントに編集権限を持たせずに済み、トムソン側も通しやすい。代償はキーファイルが失効しない秘密情報としてディスクに残ること（~/.config/gcloud/ 配下、リポジトリ外）。なおカスタム定義の登録は MCP ではできない（analytics-mcp は読み取り専用ツールしか持たない）ため、登録は GA4 Admin API の直叩きスクリプトで行う。

2026-07-27: カスタム指標 duration_sec も登録対象に追加

背景: 計測プラン v3 の「リリース前タスク」は登録対象をカスタムディメンション3件（streak_bucket / chip_state / training_type）としていたが、同じプランの「見る数字」表にある参考指標「プレイ時間/人 = training_completed の duration_sec 合計 ÷ ユーザー数」は、カスタム指標を登録しないと GA4 で合計が取れない。

決定: ディメンション3件に加えてカスタム指標 duration_sec（範囲=イベント、単位=秒）も登録する。

理由: プラン自身が定義した参考指標が取得不能になるのを避けるため。登録コストはゼロに近く（カスタム定義は50枠に対し4件使用）、不要になればアーカイブできる。

背景: コードレビューで、ストリークが「1のまま再スタート」するケース（1日おきプレイ等、旧値1→新値1）でイベントが送信されず、本命指標「イベント数÷ユーザー数＝週あたりプレイ日数」が過少計測になる欠陥が確定した。実装は仕様通りで、欠陥は計測プラン側の発火条件定義にあった。

決定: qualified した日は連続日数が同値でも毎回 streak_updated を送る（ローカル日付につき1回の上限は維持）。計測プラン v3 の記載も同期修正。

理由: 本命指標が「イベント数＝プレイ日数」で成立している前提のため、取りこぼしは許容できない。重複送信はローカル日付単位の判定（lastQualifiedDate 比較）で構造的に防がれている。

2026-07-11: 瞬間記憶/MOT の「即失敗でも qualified」は現状維持

背景: 瞬間記憶（誤答2回・約15秒）と MOT（failLimit 2）は失敗即終了でも結果画面に到達して qualified になる。動体系5種目（60秒完走必須）と非対称で、わざと即失敗すればストリーク維持できる穴がレビューで指摘された。

決定: 対策せず現状維持。「テストに挑戦した＝その日のトレーニング」と割り切る。

理由: 習慣化装置としては起動して挑戦させた時点で目的の大半を達成しており、悪用の動機も薄い。最低条件（1問正解・最低秒数等）を課すと、真面目に挑戦して連続ミスしたユーザーが qualified にならない誤爆リスクの方が大きい。

---

2026-07-10: 効果測定はライト版を採用、BigQuery Export / 無作為化は不採用

背景: ストリーク機能の効果測定を Codex レビュー2ラウンドで設計したところ、厳密にやるには固定分母 enrollment・ローカル holdout 無作為化・BigQuery Export が必要と判明。一方この計測で下す意思決定は「機能を残す/改善する/次の習慣機能に進む」の3択で、効果量の厳密な証明は不要。

決定: イベント4本（training_completed / streak_updated / streak_chip_impression / streak_chip_tapped）＋見る数字3つ（本命=週あたりプレイ日数/人、参考=プレイ時間/人、ガードレール=crash-free）のライト版 v3 を採用。BigQuery Export・Remote Config / ローカル holdout・pre_streak_layer ユーザープロパティは不採用。結論は「方向性の判断」と明記し「機能の因果効果」とは主張しない。

理由: 個人開発の運用コストと意思決定の粒度に合わせた割り切り。プレイ時間単体は偽陽性（リリース流入増で総量は必ず増える）と偽陰性（新規混入で平均が薄まる）の二重の罠があるため、「週あたりプレイ日数/人」を本命に据えることだけは譲らない。フル版設計は ストリーク計測プラン.md 内にアーカイブし将来復活可能。

2026-07-10: ストリーク表示の最終仕様（左上チップ・炎＋「◯日連続」・消灯/点灯・2段組み）

背景: ホーム画面での見せ方が施策の成否を握る。制約は2つ: iPhone SE (16:9) は種目列がほぼ全幅で左上余白が狭い / 9言語対応で西・葡・仏の文言が長い（最悪ケース「128 dias seguidos」）。

決定: 左上チップ固定。炎アイコン＋「N日連続」の一行表示を基本とし、枠に収まらない言語は「数字大＋単位語小」の2段組みに自動切替（最終保険でフォント縮小）。今日未プレイ=グレー消灯（ゆっくり明滅）→プレイで点灯＋1加算（昨日までの連続日数は保持する猶予ルール）。タップで既存 CalendarScene へ。炎はオレンジでなくシアン発光。

理由: アプリ既存の「選択中=シアン点灯」という状態表現の言語に載せることで世界観を壊さない。消灯/点灯ギミック自体が「今日やると点く」を無言で伝え、猶予ルールとも視覚的に一致する。比較検討した配置4案（左上/右上/カレンダーバッジ/Play下）とドット連なり案・起動時教育アニメ案はモックで比較の上不採用。

2026-07-10: 次回アプデ施策は「ストリーク表示＋カレンダー分数復活」（軽量・習慣化テーマ）

背景: アクティブユーザー・プレイ時間向上の施策を検討。GA4 実測で DAU/MAU≈0.9・月46セッション/人の超習慣アプリと判明し、既存ユーザーの離脱防止策は天井。効く余地は新規流入・休眠復帰・習慣の可視化。施策8案を検討。

決定: 軽量方針（1〜2施策）で ④ストリーク（連続日数）表示 と ⑤カレンダー分数表示復活 を採用。マネタイズが絡む ⑦NeuroTracker 1日1回お試し開放 は今回スコープ外。トムソン承認済み（2026-07-10）。

理由: 両施策とも既存データ（日付別プレイ履歴、IsOnTrainingPlayed）を使うだけで工数小、同じ画面・同じデータ系でテーマも「習慣の可視化」で一貫。ストアの新機能訴求が書きやすく「更新→新規流入増」の再現も狙える。

---

2026-06-25: SE シングルトンの終了フェーズ NRE は「終了フラグ」でなく「探索しない参照専用 API」で塞ぐ

背景: iOS 最多クラッシュ SE.get_Instance（NRE、815件/368ユーザー）は、FinishScene.OnDisable がシーン破棄/終了フェーズに SE.Instance を呼び、ゲッター内部の FindObjectOfType/DontDestroyOnLoad が NRE を投げるのが真因。当初は _isQuitting 終了フラグ＋早期 return で対処したが、gods-talk レビューで「フラグが立つ契機が OnApplicationQuit/OnDestroy に限られ、OnDisable がそれより先に走る順序では結局すり抜ける（実行順序依存で全消し保証が弱い）」と指摘された。

決定: 終了フラグ任せにせず、SE.Current（instance の既存参照だけ返し、探索も DontDestroyOnLoad も行わないプロパティ）を新設し、破棄・終了フェーズの呼び出し（FinishScene.OnDisable）は Current に切り替える。OnEnable のような通常フェーズは lazy 探索する Instance のまま。OnDestroy は instance=null に留め（永久 null 化を避ける）、_isQuitting は OnApplicationQuit の補助ガードとして残す。[RuntimeInitializeOnLoadMethod] で静的状態をリセット（Editor ドメインリロード無効対策）。commit fbdc9a9（Unity リポ）。

理由: 「終了中フラグ」はコールバックの実行順序に依存して取りこぼしが残る。teardown 経路から危険 API（FindObjectOfType/DontDestroyOnLoad）を物理的に排除する方が順序非依存で確実。全 SE.Instance.Play(...) 直呼びの safe wrapper 化（PlayIfAvailable）は再発面をさらに狭めるが、既知クラッシュは OnDisable 経路に集中するため今回スコープ外とし、リリース後の Crashlytics 監視で担保する。

---

2026-06-25: 難読化(R8)下で Unity IAP の Google Play billing クラスを keep する

背景: Android リリースビルドは難読化ON（AndroidMinifyRelease:1）。Unity IAP 5.x は billing を IL2CPP から JNI(文字列)経由で呼ぶため、R8 が「未使用」と誤判定して com.android.billingclient.** を削除し、実行時 ClassNotFoundException: PurchasesUpdatedListener で課金初期化が無限ハングした。

決定: Assets/Plugins/Android/proguard-user.txt（従来空）に billing の keep ルールを常設する（-keep class com.android.billingclient.** { *; } 他）。このルールは削除しない。

理由: billing 依存の宣言（IAP の自動注入で正常）も AAR の DL も問題なく、原因は R8 のストリップのみ。keep ルールが最小かつ確実な対処。mainTemplate.gradle への手動依存追記は不要と判明し revert 済。AAB の dex を grep して修正前0→修正後220で効果確認（commit 29c9b10）。

2026-06-25: 署名 keystore は git 管理せず Dropbox 正規保管＋バックアップで管理

背景: ProjectSettings が Downloads 配下の派生コピーを参照していた。keystore の保管先と git/GitHub 管理の是非が論点になった。

決定: keystore 実体は ~/Library/CloudStorage/Dropbox/動体視力/android-key/key.keystore（2021作成オリジナル、keyalias=visionworkout）を正規保管先とし、ProjectSettings もそこを参照（commit caa1e6b）。git には入れない（gitignore済・履歴にもパスワード無し）。バックアップは Dropbox本体 + ~/ichirokisanuki/visionworkout-backups/。

理由: keystore は実質的な認証情報で、private リポでも clone 拡散・履歴残留リスクがあり不適切。鍵は同一(md5一致)なので参照先変更で署名結果は不変。Bitwarden 等への一元集約は後日検討。

2026-06-10: Unity本体クローンは cdev を正とし、UnityProjects の配信中Androidソースは「移植して origin に push」で正規化（force pushしない）

背景: Unity 本体が ~/cdev/.../vision-training1-unity（Claude 管理・履歴書き換え済み・origin と一致）と ~/UnityProjects/VisionTraining1（旧作業コピー・原本履歴）の2箇所に clone されていた。後者に 2026-03リリースの Android 課金実装が未コミットでしか存在しないことが判明。両者の履歴は filter-repo 書き換えで分岐しており、UnityProjects から push すると非 fast-forward で --force が必須、かつ origin が 2.6GB の原本履歴に巻き戻る。

決定: UnityProjects からは push しない。意味あるソース（modified .cs / scene / I2 / ProjectSettings + 新規 PurchasingManagerForAndroid.cs 等）だけを cdev クローンへ移植して origin に push（commit b51d1b2/4ce4ac9）。今後の作業コピーは cdev 1本に統一。UnityProjects は中身確認後に削除。署名鍵 KeystorePasswordSetter.cs（PW平文）は秘密のため gitignore + ~/ichirokisanuki/visionworkout-backups/ にバックアップ。

理由: --force は運用ルールで禁止、かつ 5/25 の履歴軽量化（2.6GB→305MB）を壊す。軽量履歴の上に Android ソースを1コミット積む方が、禁止操作も巻き戻しも無く同じゴール（配信中ソースの正規化＋クローン一本化）に到達できる。

---

2026-06-10: iOS Info.plist の位置情報説明文は削除、#5 disclaimer は今回見送り

背景: 次回アプデ実装中、NSLocationWhenInUseUsageDescription="For firebase Analytics." の扱い（削除 vs 文言修正）と、#5 医療 disclaimer の対応要否を判断する必要があった。

決定: 位置情報説明文は削除。#5 disclaimer は今回見送り。

理由: 位置情報はアプリ本体コード・Player Settings・広告SDK のいずれも未使用と確認できたため、文言修正より削除が実態に合う（未使用APIの説明文は審査で不要な疑義を生む）。#5 は UI/I2 作業でシーン編集と翻訳整備が必要、かつ訴求への影響も小さいため、コードで完結する他項目を優先し今回は見送った。

---

2026-06-03: Billing Library 移行は Unity IAP 5.0.x (Billing 8) へフルアップグレード、4.13 (Billing 7) で繋がない

背景: 現状の Unity IAP 4.12.2 が内包する Google Play Billing Library 6.2.1 は 2025-08-31 サンセット (延長期限 2025-11-01) で既に超過。次の Android アップデートはほぼ確実にリジェクトされる。選択肢は (A) Unity IAP 4.13 へ最小アップグレードで Billing 7.1.1 にし当面 2026-08-31 まで耐える、(B) Unity IAP 5.0.x へフルアップグレードで Billing 8 にし 2027-08-31 まで耐える、の 2 つ。

決定: 案 B（Unity IAP 5.0.x へフルアップグレード）を採用。

理由: 案 A だと残り 2 ヶ月（2026-08-31）でまた 5.x 移行が必要で二度手間。PurchasingManager.cs に GooglePlayProrationMode の使用が無いことを確認済みで API 変更の影響範囲は限定的。5.0.x は API がコールバック → イベントベースに変わるが、5 商品の AddProduct を含めても 200 行程度の小さなクラス。一気に上げる方が中長期で安定。

---

2026-06-03: S-001（規約・提出要件監査）を 3 つに分割、S-002 を「監視基盤セットアップ + 軽量メンテ」にリパッケージ

背景: 旧 S-001 は「Android 16KB / Billing Library / メディカル訴求 / プライバシー / Health declaration」の 5 項目混在で粒度が荒く、優先度や工数がバラついていた。掘り下げた結果、Android 16KB と Health declaration は既に対応済みと判明、残る 3 つは独立した実装タスクと分かった。並行して S-002（iOS 1.2.9 軽量バグ修正）の中身を詰めようとしたところ、Firebase Crashlytics SDK が未導入でクラッシュデータが一切無いことが判明し、「何を直すか」を決める前提が崩れた。

決定: S-001 を S-001a（Billing 8 移行）/ S-001b（Apple メディカル訴求の整備）/ S-001c（UMP コンセント実装）の 3 タスクに分割。S-002 は「iOS 1.2.9 — 監視基盤セットアップ + 軽量メンテ」にリパッケージし、Crashlytics SDK 導入 + Privacy Manifest 作成 + Info.plist 文言修正の 3 点に内容を絞る。

理由: 分割することで各タスクの優先度・工数・リスクを独立評価でき、トムソン承認の判断材料がクリアになる。S-002 のリパッケージは「何を直すか悩む」フェーズを飛ばして、まずデータが取れる状態を作る方向に切り替える筋の良い再構成。次回 1.2.9 のリリース後、1.3.0 以降でクラッシュ駆動の改善ループが立ち上がる。

---

2026-06-03: 提案書のフォーマットは HTML（既存ダッシュボード群と統一）、Google Sheets / CSV は採用しない

背景: 提案管理シートのフォーマットで、Google Sheets（書き込み・コメント・グラフ）/ CSV（簡易）/ HTML（既存ダッシュボード群と同じスタイル）の 3 案で迷った。Google Sheets は書き込み・図解の柔軟性で魅力的だったが、Claude が直接編集するには Sheets API 連携の仕込みが必要。

決定: HTML 形式（眼球トレ提案書.html）に統一。眼球トレ売上推移.html / 眼球トレGA4分析.html と同じ Chart.js + 単純 CSS のスタイルで作成。

理由: 既存スタックとの一貫性が最重要。HTML なら Claude が直接編集できて即時更新可能、トムソンへの共有も URL or ファイル添付で完結する。Google Sheets API の仕込みは「列構造もまだ決まってない段階で API 仕込みが先行する」本末転倒。将来本格的に運用が回り始めて Sheets が必要になれば、その時に再検討する。

---

2026-06-03: アプリオーナーはトムソン、You は提案者・実装者。提案資料はトムソン承認を目的とする

背景: これまでの戦略議論で Claude が「Pro 機能の体験動線を作るべき」「価格を上げるべき」などの提案を You 自身の意思決定として進める前提で議論していたが、実際は You は提案者・実装者で、最終意思決定権者は株式会社トムソン。提案 → 承認 → 実装 → 申請 → リリースのプロセスを通る。

決定: 戦略議論の最終ゴールを「トムソンに承認をもらうための提案資料を作成すること」に明確化。眼球トレ提案書.html がその媒体。Claude の提案は技術論ではなくビジネス的価値（期待効果 / リスク / 工数 / 優先順位）で判断材料を揃える形式にする。

理由: 役割構造を明確にすることで、提案の組み立て方（「これがベスト」ではなく「これらの選択肢の中からどれを承認しますか」）と、進め方（実装着手前に提案承認が必要）が変わる。memory の project-thomsons にも反映済み。

---

2026-06-02: 運用ツール整備は「戦略 A 実行 + 自前レビュー監視 + トムソン依頼文準備」から段階的に、一気に全部やらない

背景: You がピンと来た運用ツール 3 つ（Firebase Remote Config / App Store Connect API + Google Play Developer API / 自前レビュー監視）の検討で構想が壮大化。Firebase Remote Config の現状確認結果は完全未着手（SDK 未導入 + テンプレ空 {}）で、導入には Unity 側 2〜3 日工数。トムソン依頼系も含めて「全部やる」ストレスをかけたくない。

決定: 一気に進めず、急ぐ理由のない順で段階的に着手する。

• 直近: 戦略 A（iOS 1.2.9 軽量更新）+ 自前レビュー監視 Phase1（App Store RSS、認証不要、1 日工数）+ トムソン依頼文の準備
• 2〜3 ヶ月後: トムソン依頼が通って ASC/Play API 連携稼働 + Firebase Remote Config 導入と戦略 B 実装を同時着手
• 6 ヶ月以降: 戦略 C/D、RevenueCat 検討

理由: 眼球トレは月 40 万円の安定基盤で急ぐ理由なし（資金繰り / 競合圧 / 期限なし）。「全部やる必要は全くない」前提で、戦略 A だけ実行して効果を見て次を判断するのが最もリスク低い。Remote Config は単体導入しても変える対象の UI 改善案が固まっていない限り宝の持ち腐れ、戦略 B 着手と同時が筋。詳細は [[project-tooling-options]] メモ参照。

---

2026-06-02: iOS 1.2.9 は「軽量バグ修正のみ」、Paywall 修正・トライアル延長・価格変更等は含めない

背景: 戦略 A（iOS の更新を再開して ASO ランキングシグナルを復活させる）の最初の一手として、1.2.9 に何を含めるか。Claude は当初「Paywall UI 修正 + トライアル 3 日→7 日 + 価格変更」を一緒に乗せる案を提示した。

決定: 1.2.9 は軽量バグ修正のみとする。Paywall 修正、トライアル期間延長、価格変更などの大きな変更は含めない（次バージョン以降に分割）。具体的なバグ TODO 詰めは次セッション以降で「地に足つけて」進める。

理由: 戦略 A の主目的は「リリース頻度を上げて ASO シグナルを回復させる」こと。内容そのものではなく「更新したという事実」が効くため、軽量で何でも OK。複数の重い変更を 1 バージョンに詰め込むと、効果検証もしづらいし、不具合混入リスクも高まる。

---

2026-06-02: 価格変更（買い切り値上げ）は現時点で実行しない方針

背景: GA4 分析で「価格弾力性が極めて低い」「買い切り 96% / サブスク 4% の構成は買い切り価格と年プラン価格の損益分岐点が 1.89 年で買い切りが合理的になっているのが原因」と判明。Claude が「打ち手 1: 買い切り ¥4,800〜¥5,800 への値上げ」を「最優先・最低コスト・最大効果」として強く推した。

決定: 価格変更は今は実行せず、戦略 A（iOS 更新再開）を先に進めて結果を見てから判断する。Claude からは価格変更等の大きなビジネス判断を強く推さないよう、振る舞いを調整する（メモリ [[feedback-pace-and-scope]] に記録）。

理由: 月 40 万円の安定基盤があり急ぐ理由なし。価格変更は影響大きく不可逆性も高い。まず低リスクな打ち手（A: iOS 更新再開）から段階的に進めて、効果を見てから次のレバーを引くのが妥当。Claude が分析結果から「これが最優先」と一方的に推進するスタイルは You の意思決定プロセスと合わない。

---

2026-05-25: 戦略アクションプランを 4 つに確定、優先順位は A→B→C→D

背景: GA4 分析（DAU / 課金イベント / アプリバージョン推移）で「価格改定の効果は 100% ARPU アップ」「Android 急成長は大型バージョンアップが要因」「iOS 流入減は 1.2.8 で 4 ヶ月停滞が要因」「iOS 課金 96.4% は買い切り、サブスクほぼ機能していない」の 4 件が定量的に判明。打ち手の候補が多数浮上した。

決定: 以下の優先順位でアクションプランを実行する。

• A: 短期（〜1 ヶ月）iOS の更新を再開（軽量で何でも OK、ASO ランキングシグナル復活狙い）
• B: 中期（2〜3 ヶ月）iOS サブスク UI 改善（買い切り 96% → サブスク誘導強化）
• C: 中期（3〜6 ヶ月）Android 1.3.0 の課金最適化
• D: 中長期（6 ヶ月〜）海外現地化 + ASO 多言語化

理由: ROI 効率を最大化する順序。A は Android で「更新で流入回復」を実証済なので再現性高く、コストも最小（軽量バグ修正 / スクショ刷新 / 翻訳整理レベルでも ASO シグナルが効く）。B は買い切り 96% / サブスク 4% の構成を 1% でも改善すれば月 200〜300 万円規模の積み上げが見えるレバレッジ。C / D は A・B の動作確認後に手をつける。

---

2026-06-02: GA4 データ取得は公式 analytics-mcp（OAuth/ADC）に統一、サービスアカウント方式は放棄

背景: 当初は Google Cloud でサービスアカウント ga4-data-reader@vision-training-14596.iam.gserviceaccount.com を作成し、GA4 プロパティに Viewer 追加してデータを読み取る方式を計画。しかし GA4 の追加 UI が *.iam.gserviceaccount.com 形式のメールアドレスを「メールアドレスを入力してください」とバリデーションで拒否（メール通知チェック関係なし、公式情報なし、回避不能）。

決定: 公式 analytics-mcp（Google 製、PyPI 配布、Python 製の MCP サーバー）を採用し、OAuth デスクトップクライアント + ADC ベースで認証する。トムソンへの依頼は「ichirokisanuki@gmail.com を GA4 Viewer で追加」というシンプルな依頼に簡略化（普通の Gmail なので確実に通る）。

理由:

• サービスアカウント拒否問題を完全回避できる
• Google 公式プロダクトで品質保証あり
• run_funnel_report / run_conversions_report / run_realtime_report 等、自前スクリプトでは作るのが面倒なツールが揃っている
• 自然言語で GA4 データを問い合わせ可能になり、戦略議論に直接使える
• 自作 Python スクリプト scripts/ga4/ は OAuth 不調時の保険として残置（動作確認後に削除候補）

---

2026-06-02: トムソンに対して「Viewer 権限を依頼、サービスアカウント招待もトムソン経由」の前例尊重方針

背景: 当初は You 自身を GA4 管理者にしてもらう案も検討。しかし別アプリ（Fasting）の GA4 でも You の役割は「直接権限あり、ただし管理者ではない」と判明。トムソンの運用慣行として「管理者ロールはトムソン自身のみ、他者は閲覧/編集権限のみ」というガバナンスが明確。

決定: 眼球トレの GA4 でも管理者を求めず、ichirokisanuki@gmail.com を Viewer で追加してもらう前例通りの依頼に統一。将来追加が必要なサービスアカウント等の招待操作もトムソン経由で依頼する運用を継続する。

理由: トムソンの運用ポリシーの尊重 + 依頼の通りやすさ + 個人情報・課金設定の集約管理という観点で妥当なガバナンス。権限操作の頻度は年に数回程度の想定なので、毎回依頼するコストは許容範囲。

---

2026-05-25: operation リポの origin を SSH → HTTPS

背景: GitHub への push で SSH 認証失敗（ssh-agent has no identities）。一方 gh は HTTPS で認証済み（Git operations protocol: https）。

決定: operation 側の origin を git@github.com:... から https://github.com/... に変更。

理由: gh の credential helper が自動で認証してくれるため、SSH key を ssh-add する手間を回避できる。SSH を整える選択肢もあったが、gh 経由で十分実用なので最小手数を採用。

---

2026-05-25: Unity リポの履歴から *.aab / mapping.txt / symbols.zip を完全削除（公開済みバージョンのクラッシュ逆引きは放棄）

背景: Unity リポの .git が 2.6GB に肥大化。Builds/Android/ 配下に AAB と Proguard mapping、symbols.zip が複数バージョン分（1.0.3, 1.0.4 など）コミットされていた。

決定: git filter-repo で履歴から削除し、CodeCommit に --force push。S3 等への正規退避は行わず、ローカルフル clone のバックアップのみ残す（消失リスクは承知）。

理由: リポ重量化の解消が優先。You の判断で「mapping/symbols が消えても可」と確認済み。今後の build 産物は .gitignore 整備済みのため再混入しない。

---

2026-05-25: AWS CodeCommit アクセスは thomson-ik プロファイル固定、remote URL に埋め込み

背景: AWS の default プロファイルが未設定で、git push 時に codecommit helper が default を探して失敗。プロファイルは ichirokisanuki / thomson-ik の2つ。

決定: Unity リポの remote URL を codecommit::ap-northeast-1://thomson-ik@vision-training1-unity に書き換え、ローカル clone に埋め込み恒久化。

理由: 個人開発で常に thomson-ik を使うため、毎回 AWS_PROFILE 環境変数を付けるより URL 埋め込みのほうが運用負荷低い。.git/config 内の変更なのでリモートには影響なし。

---

2026-05-25: Unity 本体リポは nested clone + operation 側 .gitignore で分離（submodule 化しない）

背景: operation リポ直下に Unity 本体（CodeCommit, 別リポ）を clone する構成。何もしないと operation の git からは ?? 状態で見える。

決定: operation 側 .gitignore に vision-training1-unity/ を追記して完全無視。submodule 化はしない。

理由: 個人開発でバージョン固定の必要なし。submodule は管理オーバーヘッドが大きい。ignore で git の境界をクリーンに保つほうがシンプルで、Unity リポは独立した CodeCommit ワークフローで完結する。

---

2026-05-25: Unity の com.unity.collab-proxy（Plastic SCM 連携）を削除

背景: Unity 2022.3.62f2 Editor 起動時に macOS（Apple Silicon）が「Intel プロセッサ用アプリの対応は終了します」警告を表示。Unity 本体・Firebase 等の .bundle は arm64 対応済みで、原因は com.unity.collab-proxy@2.7.1 同梱の liblz4Plastic.dylib が x86_64 only であること。

決定: Packages/manifest.json から com.unity.collab-proxy を削除。

理由: 本リポは Git (CodeCommit) で管理しており Plastic SCM 連携は元々不要。削除すれば arm64 ネイティブで起動でき、将来 Rosetta 廃止後も動作可能。

開発日誌

このプロジェクトでの作業を時系列で記録する。 最新のエントリが上に来る。

---

2026-09-30

19:43 - Firebase Crashlytics 警告メール（5アプリ同時）を調査 → Google 側の Firebase Analytics 障害と特定、アプリ側の対応は不要

やったこと:

• 警告メール5通を確認（Gmail）: 「増加傾向にある安定性に関する問題（日付: 2026-09-29）」が Vision Training / FootballNEXT / BaseballNEXT / StudyTimer / channel7-ios の5アプリ（いずれも iOS）から届いていた。全て Crashlytics Issue ID 181010225a8f7695edf124ff32b9c406（別プロジェクトでも一致 = クラッシュのシグネチャ由来）、NSInvalidArgumentException: -[__NSDictionaryM setObject:forKeyedSubscript:]: key cannot be nil、いずれも1件/1人（メール上の件数は FootballNEXT 39・StudyTimer 35・channel7 15＋4・BaseballNEXT 12＋2・Vision Training 33＋変種2＋2）
• Vision Training の Crashlytics を Firebase MCP で調査（iOS appId 1:592194999741:ios:28d6aa2ca414611e336ed4）:
  • 主 Issue 34件/34人（1.4.2 が33・1.4.0 (3) が1）＋別 OS 向けの変種 Issue 2件（3ab948…・57dae5…、各2件/2人）。全て 9/29（UTC）で、9/30 は0件（日別に topIssues を切って確認）
  • スタックにアプリのフレームなし（GCD ワーカースレッド上の nil キー書き込み）。app_open から約8〜10秒後に落ちる（breadcrumbs のある5件）。OS は iPadOS 15.5〜iOS 27.0.0、端末も iPhone XS Max〜17 Pro Max・iPad と偏りなし。サンプルの時刻は 00:53〜00:54Z（変種は 01:32Z）
  • Pangle の hmdPAG_cpp_terminate_handle が主 Issue のサンプル5件中3件のスタックに出るが、終了ハンドラの連鎖で原因ではない（出ない2件も同じ原因で落ちている）
  • 同梱 SDK（Builds/iOS/Podfile.lock、9/2 ビルド）: Firebase iOS 12.4.0 / GoogleUtilities 8.1.1 / Google-Mobile-Ads 12.11.0 / 仲介 AppLovin・InMobi・Pangle・Vungle
• 原因を一次情報で特定（https://github.com/firebase/firebase-ios-sdk/issues/16728 ほか。gh api で本文・コメント・タイムラインを直接確認）: Google Analytics for Firebase の sdk-exp（実験ペイロード）に不正データが 2026-09-28 17:41 PDT（= 9/29 00:41 UTC = 9:41 JST）から配信され、GoogleAppMeasurement の実験処理が nil の flag 名を GULMutableDictionary に書き込んで非同期キューで例外。Firebase 公式（メンテナ）は 19:52 PDT にロールバックの展開完了、キャッシュ分は 23:52 PDT（= 9/29 15:52 JST）までに自然解消、「SDK 更新は不要」と告知。9/30 00:30 UTC にも「継続クラッシュの証拠なし」。報告された SDK 版は 10.29〜12.19、アプリ版・OS も問わず、A/B 実験未設定のアプリも落ちた
• 結論: アプリ側の不具合ではなく Google 側障害。1.4.2 の Remote Config・価格A/B土台とも無関係。対応不要。確認の深さ: Vision Training は Crashlytics 実データ＋一次情報、他4アプリはメール本文のみ（Issue ID・日付・例外文・1件/1人の一致で同一原因と判断）
• SDK 側の硬化: google/GoogleUtilities に nil キーを無視する修正（#249、ログ追加 #251）が 9/29 にマージ済み。ただしリリース済み最新は 8.1.3（8/26）で修正版は未公開（9/30 時点）。Firebase は根本原因の事後報告を約束済みだが未公開

決めたこと（DECISIONS.md にも転記）:

1. ホットフィックス・SDK の緊急更新はしない。GoogleUtilities の修正版が公開されたら、次回の Firebase / Unity SDK 更新で取り込む（急がない）

詰まったこと / 気づき:

• Crashlytics の Issue ID はクラッシュのシグネチャ（ブレームされたフレーム＋例外種別）由来で、プロジェクトをまたいで一致する。複数アプリで同一 ID・1件/1人・同日の警告メールが来たら、自分のリリースを疑う前に firebase-ios-sdk の Issue を gh で見るのが早い（今回は例外文で検索して即ヒット）
• 10月の価格A/B（Firebase A/B Testing）との関係: 実験未設定のアプリも落ちているため、A/B 開始が追加リスクになる話ではないと判断（推論。公式の原因説明は未公開）
• crashlytics_list_events は詳細が保持されたイベントしか返さず、主 Issue は34件中5件・変種は1件と0件だった。crashlytics_get_report の時間フィルタは日単位なので、収束の判定は日別の topIssues で行う
• 副次確認（iOS 直近7日の FATAL 全8件）: AnswerRegion.OnClickAnswerButton NRE は lastSeenVersion=1.4.0（旧版3人10件、1.4.2 では未発生）、UnloadSceneAsync は FATAL に無し。今回の障害以外の 1.4.2 新規は単発4件（__workq_kernreturn・osSetPosixAdvisoryLock・AppKit block_destroy_helper・CFStringFindWithOptionsAndLocale、各1〜2件/1人）で経過観察。Android と NON_FATAL は未確認
• 前回の wrap-up が 9/3 で、9/4〜9/29 の進捗（ベースライン計測・トムソン回答など）は今セッションでは未確認。WIP は 9/3 の記載を引き継いだ

次回やること:

• 9/3 計画の続きの実施状況を最初に確認（ベースライン計測・トムソン回答・10月上旬の A/B 開始準備）
• GoogleUtilities の修正版リリースを確認 → 次の Firebase / Unity SDK 更新で取り込む（現行 Firebase iOS 12.4.0 / Unity SDK 13.4.0。購入計測の LogAppleTransactionAsync() は Unity SDK 13.12.0+ が必要なので、SDK 更新を検討するときはあわせて見る）
• Crashlytics の障害 Issue 3件（OPEN）を閉じるか（書き込み権限が必要・トムソン管理）

2026-09-03

12:51 - iOS 1.4.2 リリース完了（RC 既定値確認 → READY_FOR_SALE → タグ）。価格A/Bの判定日程を試算し直して設計3点を決め、トムソンへ日程提案を共有

やったこと:

• リリース前チェック（すべて API）: Remote Config テンプレート v4 = 既定値（gen2.pro / membership.gen2.1year）のまま、1.4.2 は PENDING_DEVELOPER_RELEASE・releaseType=MANUAL・段階的リリース null（即時100%）、ビルド 1.4.2 (1) VALID、同梱の App 内課金2件（gen2.pro.t4800 / gen2.1year.t2400）とも APPROVED
• リリース操作は You が ASC UI で実施（API からのリリースも可能だったが You が②を選択）。API で READY_FOR_SALE を確認 → Unity bc1d300 に注釈付きタグ iOS1.4.2 を作成・push（既存の iOS1.4.0 / Android1.4.1 と同じ命名）
• 判定日程の試算（1回目）: 二群の比率の差の検定で「新規のみ」前提に所要期間を算出 → You がモデルを切り替えて再試算を指示 → 前提から見直して3点を訂正
  1. 判定指標が GA4 に届かない: 6/1〜9/2 の3ヶ月で purchase 系イベントが iOS/Android とも 0件。Firebase 自動収集 in_app_purchase は StoreKit 1 専用で、Unity IAP 5.1.2 は既定 StoreKit 2（Runtime/Utilities/StoreKitSelector.cs、CHANGELOG「By default, StoreKit 2 will be used」）。StoreKit 2 で送るには Firebase Unity SDK 13.12.0+ の LogAppleTransactionAsync() が必要で現行は 13.4.0。1.4.2 の自前イベントは paywall_view / paywall_purchase_tap の2つだけで購入完了イベントは無い（公式 docs を developerknowledge で確認）
  2. 年額トライアル開始 38件/月（ASC 2026-06）は日本の全ユーザーの数字で、新規限定なら6割程度（1群 約11件/月）
  3. 「3ヶ月で半減級を検出」は新規限定だと成り立たない（4.3ヶ月）
• 必要件数を「対照群の購入件数」で整理し直した（母数の仮定に依らない。α=0.05 両側・検出力80%）: 売上維持ライン −25%（年額）約220件 / −29%（買い切り）約157件 / −40% 約79件 / 半減 約47件。直近30日（8/3〜9/1）の iOS 日本新規 1,020人
• 所要期間: 新規＋既存で年額 約19件/月/群 → 半減 2.5ヶ月・−40% 4.2ヶ月・維持ライン 11.6ヶ月。新規限定 約11件 → 4.3 / 7 / 20ヶ月。買い切りは 約5.5件/月/群 で半減でも 8.5ヶ月・維持ライン 29ヶ月（どの構成でも判定不能）
• You が設計3点を決定（DECISIONS）: ①対象は「新規＋既存」（短い方）②purchase_success イベントは足さない（1.4.3 なし、ASC 商品別で集計）③買い切り＋年額を同時に載せて1本（「順番にする必要ない」）
• 眼球トレ価格ABテスト日程提案.html を作成 → thomson-share で S3 共有（眼球トレ価格ABテスト日程提案_20260903.html、HTTP 200、ブラウザで表示確認）。内容: 結論／12週＋判定1週／日程表（9月ベースライン → 10月上旬開始 → 11月上旬に中止判断のみ → 12月下旬終了 → 2027年1月上旬判定）／v6 対比表／必要件数の根拠／判定ルール案5項目／計測方法（ASC 商品別）／確認事項2点（設計可否・推しプラン）。URL 送付は You

決めたこと（DECISIONS.md にも転記）:

1. 対象 = iOS・日本・1.4.2 以降の無料ユーザー全員（新規＋既存）50:50
2. 購入完了イベントは追加せず、群別購入は ASC 商品別売上で集計
3. 買い切りと年額を同時に変えて1本（v6 の順次2本はやめる）
4. 判定日程はこちらから目安を提案（12週＋1週、4週目は中止判断のみ）

詰まったこと / 気づき:

• Firebase 自動 in_app_purchase は StoreKit 2 非対応。IAP5 移行（1.3.1）以降 GA4 に購入が0件だった理由はこれで、土台提案（9/1）の「購入は自動収集で取る」は誤りだった。Android も 0件（理由未調査）
• 検定に必要なのは母数でなく「対照群の購入件数」。分母を新規/閲覧者に変えても所要期間は変わらないので、トムソン向け説明はこの形が分かりやすい
• 変数群はテスト専用商品を買うので ASC 商品別売上で正確に分離できる。対照群は現行商品に未更新ユーザーが混ざるが、全ユーザー対象なら数週間で解消
• GA4 MCP の dimension_filter は snake_case（field_name / string_filter / match_type）。camelCase だとエラー
• ASC のリリース操作は POST /v1/appStoreVersionReleaseRequests で API からも可能（asc_write.mjs raw）。今回は UI 操作を選択

次回やること:

• 9/4 以降: Crashlytics で瞬間記憶の2件（AnswerRegion.OnClickAnswerButton NRE / UnloadSceneAsync）が 1.4.2 で消えたか確認（dev-timer 未登録。候補 9/4 15:00 / 9/5 10:00 は未回答）
• 9月中: ベースライン計測（paywall_view・購入タップ率・ASC 商品別件数・1.4.2 普及率）＋ Firebase A/B Testing のドラフト実験でテスト端末限定の変数配信 → 表示・購入の本番確認。GA4 の到達確認は 24〜48h 後から
• トムソン回答（設計可否・推しプラン）→ 9月末にベースライン実数で期間を確定して報告 → 10月上旬テスト開始

2026-09-02

18:52 - 価格A/B土台（1.4.2）を実装→実機 Sandbox 検証→商品2件同梱で審査提出まで完走。トムソン向け資料3点共有・Android 1.4.1 タグ

やったこと:

• Android 1.4.1（versionCode 25）審査通過 → Unity 0ccde78 に注釈付きタグ Android1.4.1 を作成・push。Android ビルド副産物5件（AndroidReleaseBuild.cs・gradle aapt2 override・addressables bin・crashlytics_build_id）を 7ff7baa として整理コミット
• トムソン向け資料を作成し S3 共有（thomson-share）: ①眼球トレ価格AB土台提案.html（v6 提案への返答兼。土台の中身・検証手順・検出力試算・規約調査・擦り合わせ2点=判定ルール/推しプラン）②v6 提案原本のコピー ③眼球トレ価格AB商品登録指示書.html（現行商品の実設定を ASC API で裏取り: トライアル3日・12言語・ファミリー共有・グループ順位。表示名は 2.3.2 対策で「Pro+」系）
• 1.4.2 のアプリ側実装（Unity f9df6a8）:
  • PricingRemoteConfig.cs 新規: RC キー ios_kaikiri_product_id / ios_year_product_id、既定=現行商品、許可リスト外の値は既定へ。iOS 実機のみ動作、Development Build はフェッチ間隔0
  • PurchasingManager: テスト価格版 gen2.pro.t4800 / gen2.1year.t2400 をカタログに常時登録、購入対象を RC 解決、変数商品もエンタイトルメント判定、GetProductById 追加
  • Paywall2AdditiveScene: paywall_view（kaikiri_product / year_product パラメータ）と paywall_purchase_tap（plan）を送信。変数有効時はストア取得価格を整数部/小数部/月あたりに分解して I2 バインドの Text を上書き（通貨記号はそのまま、現行デザイン維持）
  • InitializeOnceOnStartup: 依存解決後に RC フェッチ、A/B テスト端末登録用の AppInstanceId をログ
  • StreakChipView: streak_chip_impression の過剰計上修正。原因は「プロセス1回」の静的フラグに対し GA4 セッションが30分以内の再起動をまたぐこと。前回送信時刻を PlayerPrefs に永続化し30分以内の再送を抑止
  • Firebase RemoteConfig SDK 13.4.0 を追加（最初 AppDependencies.xml の 12.4.0 を SDK 版と誤認して 12.4.0 を DL → FirebaseCppApp-13_4_0 と manifest で 13.4.0 と判明し取り直し。unitypackage を tar 展開して RemoteConfig 固有14ファイルのみ配置）。bundleVersion 1.4.2
• シミュレータ検証: tools/make_sim_libs.sh の変換対象に libFirebaseCppRemoteConfig.a を追加（未追加だとリンクエラー）。未署名ビルドでは RC フェッチが SecItemCopyMatching -34018（Keychain 拒否）で失敗 → CODE_SIGN_IDENTITY="-" の ad-hoc 署名で Success を確認。ペイウォール既定表示 OK、ASC 未登録商品を含むカタログでも IAP 初期化が完了（5/7 商品取得）
• iOS 1.4.1 が ASC に存在しない（未提出）と判明 → 1.4.2 に統合（DECISIONS）
• トムソンが商品2件を登録 → API 照合で3点の修正依頼（t4800 ファミリー共有オフ→オン、t2400 配信可否未設定=MISSING_METADATA、t2400 の順位が現行年間より上）→ 修正完了を API で確認。「審査用に追加」は押さないよう依頼
• Remote Config テンプレート v1 公開（書き込み権限確認。空テンプレートは ETag で失敗するため force）。テスト中に v2（t4800）→ v3（既定/t2400）→ v4（既定に戻し）
• 実機テスト: 最初 Xcode に端末が出ず。原因は SimScreenshotBuild が Target SDK を Simulator にしたまま ProjectSettings に残り（1.4.1 時点からコミット済み）、GUI ビルドの Xcode プロジェクトが SUPPORTED_PLATFORMS = iphonesimulator になっていたこと。Device SDK に戻し、スクリプトはビルド後に復元するよう修正（78cb61d）。実機で RC Success・7商品取得・既定表示・t4800 表示(¥4800)→Sandbox 購入→削除再インストールで自動 Pro 復元・t2400 表示(¥2400/¥200月)→3日トライアル購入→Pro 解放、すべて OK。ログ文言修正 68beed1、リリースビルド副産物 bc1d300
• ASC 提出準備: scripts/asc/asc_write.mjs（MCP と同じ鍵で POST/PATCH）で 1.4.2 バージョン作成（releaseType は作成時指定不可）・What's New 12ロケール投入（You 指示で「軽微な不具合を修正し、安定性を向上」系に差し替え）・ビルド 1.4.2 (1) 紐付け（usesNonExemptEncryption=false 設定済み）
• 審査提出（トムソン）: 当初は商品2件を単独提出、アプリは「審査提出に追加」のみで未送信 → 指摘後、単独提出2件をキャンセルしアプリ＋商品2件を1つの提出に同梱して提出。API で WAITING_FOR_REVIEW（2026-09-02 09:41 UTC、項目3件）を確認
• リリース前準備: GA4 カスタムディメンション plan / kaikiri_product / year_product を登録（scripts/ga4/register_custom_dimensions.py、SA 認証・編集者権限）。7月の登録漏れ教訓の再発防止
• 1.4.2実機テスト手順.md を作成。operation a5e7349 / d5333bf

決めたこと（DECISIONS.md にも転記）:

1. iOS 1.4.1 の単独提出はやめ、1.4.2（土台同梱）として提出
2. 価格A/B土台の設計（RC は iOS のみ・既定=現行・許可リスト・変数商品カタログ常時登録・ストア価格を分解して差し替え）
3. streak_chip_impression は永続タイムスタンプで30分以内の再送抑止
4. テスト価格商品の命名・表示名・配置（t4800 / t2400、Pro+、プロモート非対象、同列）
5. What's New は「軽微な不具合修正」の汎用文面
6. 審査提出はトムソン側が行う（アプリ＋商品の同梱）

詰まったこと / 気づき:

• Firebase Unity SDK の版は Assets/Firebase/Editor/*_version-X_manifest.txt か FirebaseCppApp-X.bundle で見る。*Dependencies.xml の version は iOS Pod 側の番号
• 未署名シミュビルド（CODE_SIGNING_ALLOWED=NO）では Firebase Installations が Keychain を使えず RC だけ失敗する（Analytics は動く）。RC 検証は ad-hoc 署名で
• 「Xcode に実機が出ない」は端末側でなく Unity の Target SDK（iPhoneSdkVersion: 989=Simulator）が原因だった。xcodebuild -showdestinations に「Any iOS Device」すら出ないのが決め手
• ASC MCP request は GET 専用。POST/PATCH は scripts/asc/asc_write.mjs。App 内課金を審査提出に載せる操作は API に無く UI 限定
• ASC の「提出準備中」表示と API の MISSING_METADATA はズレることがある（t2400 は UI では準備中に見えていたが配信可否が未設定）。登録依頼後は API で全項目照合すべき
• Sandbox: 買い切り購入済みアカウントでサブスクを買おうとすると既存ロジックで「サブスク不要」ポップアップに流れる → 商品ごとに別テスター
• LastFetchFailureReason は失敗が無いとき Invalid を返すので「Success / Invalid」と出て紛らわしい（ログ修正済み）
• Development Build は Unity のプレイヤー接続で「ローカルネットワーク上のデバイスを見つける許可」ダイアログが出る（リリースビルドでは出ない）
• 審査提出の UI は「審査用に追加」→「審査へ提出」の2段。前者だけだと READY_FOR_REVIEW（提出日時なし）で止まる

次回やること:

• 審査状況の確認（dev-timer は未登録。You が (a) 9/3 15:00 (b) 9/4 10:00 (c) 不要 を未回答）
• 審査通過 → RC テンプレートが既定値であることを再確認 → リリース（手動。前回はトムソンが操作）→ iOS1.4.2 タグ → Crashlytics で瞬間記憶の例外消滅確認
• 配信後の本番検証: Firebase A/B Testing のドラフト実験でテスト端末（AppInstanceId 取得済み）だけに変数配信 → 価格表示・購入確認 → GA4 で paywall_view 到達とパラメータ分布
• トムソンと判定ルール（期間延長/上流指標/方向性判定）と推しプランの合意 → テスト開始
• Play ストア素材の続き（タブレット配置・フィーチャーグラフィック）は据え置き。Android 1.4.2 は未定

2026-08-27

13:07 - Google Play 用スクショ 12ロケール84枚を iOS 素材から生成（旧デザイン掲載の解消に向けて）

やったこと:

• Play の掲載スクショが旧デザインのままなのを公開ページ（play-lh.googleusercontent.com の画像を取得）で確認。Android 1.4.1 は刷新デザインなのでストアと食い違う状態
• iOS 6.9インチ版（2868×1320、2.17:1）は Play の上限 2:1 を超えるため、横 2560 に縮小して 16:9（2560×1440）に上下 131px の帯を付ける方式に。帯色は元画像の上端/下端の中央値色（上=ヘッダーの紺・下=背景の紺）。「上下とも暗い紺に統一」も試したが You は最初の版を選択
• ja-JP で確認 → OK 後に残り11ロケール（es/fr/pt は同一画像を2ロケールへ流用）を一括生成。全84枚 sips で 2560×1440 を検証。スクリプトは store-assets/screenshots/scripts/make_play_phone.py に恒久化
• 続きはデスクトップアプリのセッションで（WIP の「Play ストア素材」ブロックに引き継ぎ内容を集約）

次回やること:

• タブレット用 = iPad 版 7枚 × 9言語をそのまま android/<ロケール>/tablet/ へ配置
• フィーチャーグラフィック 1024×500 を Codex で生成（プロンプト案を You に見せてから）
• You が Play Console へ手動アップロード

12:49 - 1.4.0 の瞬間記憶退行を発見 → 1.4.1 ホットフィックス（Android versionCode 25 内部テスト合格）＋次アプデ計画の整理（B+C 土台 → トムソン価格A/B）

やったこと:

• dev-timer 整理: #42（ストリーク6週確定判定、8/27 9:00）は 8/19 に前倒し確定済みのため done。#52「B+C（課金計測イベント＋Remote Config）の土台開発」を 9/1 15:00 に登録
• iOS 1.4.0（8/19 配信）の売上・DL 前後比較: ASC 日次売上レポートを自前 Node スクリプト（scratchpad asc_sales.mjs、MCP サーバの JWT 生成を流用）で 7/22〜8/25 を集計。MCP 経由だと TSV 全行がコンテキストに載って重いため。結果=新規DL 100〜115/日で横ばい、有料件数/週 30→40・売上 ¥38k→¥41k は直前週（お盆）比では微増だが 7月末水準（46〜58件/¥49〜65k）には届かず、1.4.0 の影響は判別不能。GA4 iOS newUsers も 131→120/日で横ばい。ストア素材刷新の効果は2週間後に ASC アナリティクス（プロダクトページ閲覧→CVR）で見る方が直接的
• 次アプデ計画の材料集め中に Crashlytics で 1.4.0 の退行を発見: iOS FATAL 608件/8日（1.3.3 の同期間は 9件）。上位2件がどちらも瞬間記憶
  1. AnswerRegion.OnClickAnswerButton NRE — 467件/78人（1.3.3 全期間で14件）。1人平均6回＝回答キーが効かず連打
  2. FlashMemoryTestPlayScene.OnClickHomeButton → UnloadSceneAsync "Scene to unload is invalid" — 134件/49人（1.3.3 は7件）
  • 瞬間記憶プレイヤー約700人中78人（約11%）。Crashlytics 上は FATAL だが Unity の managed 例外なのでアプリは落ちず「押しても反応しない」画面固まりとして体験される。レビューには未反映（8/19 以降0件）
• 原因の確定: リザルト「もう一度」（FlashMemoryTestResultScene.OnClickResumeButton）が同一フレームで Unload(Play)→Load(Play) を発行。実機では旧シーン破棄前に新シーンが Awake し、SingletonMonoBehaviour.Awake が新実体を破棄 → Start() 未実行のまま回答キー（シーン保存状態が active）だけ表示 → タップごとに Instance が null で NRE。Crashlytics の複数イベントで NRE が training_completed の数秒後に連続する履歴と一致。ホーム側は二度押しで2回目のアンロードが例外。1.4.0 で刷新の実行時生成オブジェクトが増えアンロードが重くなり、旧来からあった競合が顕在化した（1.4.0 唯一の .unity 差分は Play シーンの EventSystem 無効化で、これは無関係と判断）
• 修正（Unity b1b94b5、8ファイル）:
  • SingletonMonoBehaviour: 別シーンの旧実体が残っていても新実体を Instance にする（同一シーン内の重複は従来どおり破棄）。OnDestroy で静的参照クリア。派生は FlashMemoryTestPlayScene のみで安全
  • SceneUtil（新規）: GetSceneByName + isLoaded を見てからアンロードする UnloadIfLoaded（string / Scene）
  • リザルト・プレイ・モード選択: 二度押しガード、自シーンは gameObject.scene で指定、プレイシーンの多重ロード防止
  • AnswerRegion / FlashNumberRegion: Instance null 防御、Fire で CancelInvoke と配列境界チェック（1.4.0 新規の BlinkOn IndexOutOfRange 6件も対処）
• 検証: dotnet build 0エラー → tools/build_sim.sh でシミュ確認ビルド（8/17 の既存 .app で先に現行動作を確認してからリビルド）。競合自体はシミュレータ（速すぎる）では 1.4.0 でも再現せず、修正版で「もう一度」×6・ホーム二度押し・モード二度押し（ロード済みのためロードしない ログ1回）で例外0を確認。テスト広告（Pangle）が3回目の結果画面ごとに割り込んでタップを吸い、ランディングページに飛ぶ→残留ビューで無反応、で何度かやり直した
• バージョン更新と Android ビルド: 1.4.1 / iOS build 1 / Android versionCode 24（b0a3153。8/24 に内部テストへ上げた 23 と重複回避）。AndroidReleaseBuild.Build をバッチ実行（gitignore 済み KeystorePasswordSetter.cs が InitializeOnLoad で署名設定するのでバッチでも通る）。24.aab を bundletool（manifest）/ dex grep（PurchasesUpdatedListener 2・billingclient 233＝R8 keep 健在）/ keytool（23 と同一証明書）/ global-metadata（SceneUtil 同梱）で検証
• 内部テスト 24 で「もう一度」時に難易度選択画面が一瞬見える（アンロード完了待ちの副作用）→ 同一フレーム Unload→Load に戻し（競合対策は Singleton 側で担保）versionCode 25（0ccde78）を再ビルド・同様に検証。CodeCommit master は d109ea5 → 0ccde78
• Play 用リリースノート 1.4.1 を store-assets/copy/play-release-notes-1.4.1.txt に作成（1.4.0 のデザイン一新12ロケール文面＋各言語に瞬間記憶修正行。種目名は video-copy.i18n.json の訳語に合わせた）。Play Console のブラウザ自動化（Playwright）は Google ログインが自動化ブラウザを弾いて断念 → You が手動でアップロード。軽量チェック6項目（刷新表示 / edge-to-edge / もう一度×3 / 戻る操作 / ペイウォール価格 / 広告→ストリーク点灯）すべて OK
• トムソン提案との関係を整理: 価格A/B（v6）は価格検証そのもので、B（課金計測イベント）＋C（Remote Config）はその前提の土台。今のアプリには出し分けも計測もない。最小構成 = C + 価格違い商品の ASC 登録（Unity IAP はビルド時カタログなので土台ビルド前に作成）+ paywall_view（購入売上は Firebase 自動収集の in_app_purchase 等で代替可）。土台は既定値=現行価格で配信 → 本番でイベント到達・RC 取得・テスター限定の商品差し替え・課金通しを確認 → Firebase 側の操作だけでテスト開始（アプデは1回）。検出力不足（日本新規の買い切りは1群あたり月数件）は土台を入れても解消しない点はトムソンへの返答の本体

決めたこと（DECISIONS.md にも転記）:

1. Android 1.4.0 の申請を止め、瞬間記憶の退行を修正して 1.4.1 として両OS同時配信（Android は 1.3.2 → 1.4.1 で刷新・ストリーク・簡体字修正を同時に載せる）
2. 次アプデの順番 = 1.4.1 ホットフィックス（修正のみ、計測基盤は同梱しない）→ B+C 土台（9/1 着手、既定値=現行価格で配信し本番確認）→ トムソン価格A/B。streak_chip_impression 修正も土台に同梱
3. SingletonMonoBehaviour は別シーンの旧実体より新実体を優先。「もう一度」は同一フレーム Unload→Load を維持（アンロード完了待ちはちらつく）

詰まったこと / 気づき:

• Crashlytics の「FATAL」は Unity SDK が managed 例外を致命扱いで送るもの。件数急増でも「落ちる」とは限らず、UI 無反応系は Impacted users と1人あたり回数（連打）で読む
• AXe のタップ座標: Unity アプリ内は ランドスケープ 874×402 pt、通知許可/ATT などシステムダイアログの frame はポートレートで返るので lx = py, ly = 402 - px で変換。axe tap --label '許可' でラベル指定も可。スクショは sips -r 270 で正立
• simctl launch --stdout= はファイルが作られず、--console をバックグラウンドで回してファイルへリダイレクトすると Unity の Debug.Log が取れる
• シミュ確認ビルドは Assets/AddressableAssetsData/iOS/addressables_content_state.bin を書き換えるので終わったら git checkout で戻す
• Play Console は Chrome 136+ の制限で既存ログイン済み Chrome を CDP で掴めず、Playwright 起動の Chrome は Google ログインを弾く（フラグ隠蔽でも不可）。Apple Events からの JavaScript も既定オフ。Play Console 操作は当面 You の手動
• Apple の jarsigner/keytool はシステム Java が無いと動かない。Homebrew の /opt/homebrew/opt/openjdk/bin/keytool -printcert -jarfile で AAB の署名確認ができる

次回やること:

• Android 1.4.1（25）を製品版へプロモート（You）→ 翌日に Crashlytics で両イシューの消滅確認（dev-timer 候補 8/28 15:00 / 8/29 10:00）
• iOS 1.4.1 のビルド・提出（Unity iOS ビルド → Xcode → ASC は You。ASC の 1.4.1 バージョン作成と What's New「瞬間記憶テストの不具合修正」12ロケールは API で投入可）
• トムソンへ返答（検出力の実データ＋「土台先行、最小構成」の提案）とペイウォールの推しプランの擦り合わせ
• 9/1 B+C 土台開発（バージョンは 1.4.2 か 1.5.0。dev-timer #52 の本文「1.4.1」は登録時の仮称で、1.4.1 はホットフィックスに使った）

2026-08-19

09:05 - 1.4.0 審査通過 → ストリーク効果測定を前倒し確定・報告書をS3共有・thomson-share スキル新設

やったこと:

• iOS 1.4.0 の審査通過を確認。ASC API で PENDING_DEVELOPER_RELEASE / 手動リリース / 段階的リリース未設定（＝リリース即時100%）を確認。リリース操作はトムソンが本日中に実施見込み
• ストリーク効果測定の確定判定を前倒しで実施（8/27 予定 → 8/19、対象=リリース後の完了4週 7/20〜8/16。判定方法は 7/27 に決めた「1.3.3 内週次トレンド + 標準指標の前後比較 + newVsReturning 分割」）
  • 本命指標「週あたりプレイ日数/人」は横ばい: 全体 1.11→1.13→1.13→1.03 / 既存 1.18→1.19→1.20→1.10 / 新規 0.51→0.49→0.50→0.48。W4 の低下はお盆週（8/13〜16）と重なるため季節要因と解釈。週内プレイ到達率も横ばい（既存 56.2→52.8% / 新規 50.4→47.2%）
  • 診断: チップ CTR はイベントベース 4.8→3.5→3.1→3.2%（ユーザーベース 7.0→5.2→4.7→5.0%）で新奇性が抜けて約3%で安定。7日以上ストリーク維持は週 114→106→106 人（アクティブの約3%）で伸びず、bucket 分布は「1-2日」が支配的（約1,600人）＝大多数は2日目までに途切れる。30+ は 28〜29人で安定
  • 前後比較: セッション/人は前後不変（既存 2.13〜2.21 → 2.16〜2.23）。滞在時間/人（userEngagementDuration）は既存で +30% 増えていたが、①7/31〜8/1 を境にした段差（リリース 7/16 と無関係）②実プレイ秒 duration_sec/人 は 269→292→262 で横ばい、の2点から外部・季節要因（夏休み）と判断して判定から除外
  • ガードレール合格: 1.3.3 の FATAL は 7/16〜8/18 の34日で 32件・約11ユーザー、全件 1.3.1/1.3.2 由来の既存 issue で 1.3.3 起因の新規クラッシュ 0。うち24件は特定2ユーザーの連発
  • 判定 = 明確な押し上げ効果なし・悪影響なし → 計測プラン v3 の3択のうち「機能は残して測定クローズ、テコ入れは優先度を下げて次施策へ」を提案の形にした
• トムソン向け報告書を制作・共有: ストリーク効果測定報告.html（既存提案書と同系デザイン。トムソン向けには Crashlytics/ガードレールの記述は載せない方針で削除。タイトルは「THE眼球トレーニング ストリーク機能 効果測定報告」）を S3 thomsons バケットへ public-read 配置し公開URL発行。URL 送付は You
• thomson-share スキルを新設（.claude/skills/thomson-share/SKILL.md、プロジェクトレベル）: HTML を thomsons バケットへ public-read でアップロードし公開URL発行→検証→ブラウザ確認までの定型手順。命名 <名前>_YYYYMMDD.html、更新は同一キー上書きで URL 維持、--cache-control no-cache 常用。ダミーファイルで実アップロード→200確認→削除まで動作テスト済

決めたこと（DECISIONS.md にも転記）:

1. ストリーク効果測定は4週データで確定判定し前倒しクローズ（機能は維持、テコ入れは優先度下げ）
2. トムソン向け HTML 共有を thomson-share スキルとして定型化（public-read 方式を踏襲）

詰まったこと / 気づき:

• 7/27 健全性チェックの本命指標の分母は「appVersion=1.3.3 で絞った週次アクティブ」だった。素の iOS 週次アクティブで計算すると W1 既存が 1.00 になり合わず、定義照合（W1 で 1.18/0.51 の完全一致確認）に一手間かかった。定点指標は分母の定義まで記録しておくべき
• userEngagementDuration は施策と無関係の要因で +30% 動くことがある（今回 7/31〜8/1 に段差）。実プレイの実態はカスタム指標 duration_sec 側が頼りになる。7/27 に指標登録しておいたのがここで効いた
• Crashlytics の CalendarScene - SetupDaysText NRE（10件/1ユーザー、初出 1.3.2）は 1.3.3 で復活させたカレンダー分数表示と同画面。既存 issue なので経過観察扱い

次回やること:

• 1.4.0 のリリース実施確認（トムソン）→ リリース後の様子見
• Android 1.3.3（versionCode 23）のビルド・提出
• トムソンの効果測定報告への返答対応

---

2026-08-18

13:00 - iPad プレビュー動画を全9ロケール制作＋ASC登録完了（撮影基盤を AXe へ刷新）

やったこと:

• iPad 版 App Preview 動画（1600×1200 / 29.867秒）を9ロケール分制作し、ASC 登録まで完了。1.4.0 の残タスクだった iPad 動画がこれで片付き、提出ブロッカーが解消
• レンダリング基盤を iPad へ移植: ipad_video.py（1600×1200 キャンバス、add_phrase / add_vignette / add_text_haze / メニューピル / ffmpeg エンコード）+ render_ipad_scenes.py（01-05・07）+ render_ipad_instant_memory.py（06、2ソース連結）+ render_ipad_closer.py（99 ブランド締め）+ assemble_ipad_preview.py（B案組み立て＋BGM）。コピー・タイミング・center_y は承認済み iPhone 版から一字一句流用し、キャンバスと型サイズ（TYPE_SCALE 1.06）だけ 4:3 用に変換
• 不採用だった左寄せキネティックタイポではなく、実際に採用されている中央配置版（render_teleportation_cinematic_v2 系）を移植対象と特定したことで、移植コストが当初想定より大幅に下がった
• 撮影: 9ロケール分の raw をシミュレータで収録。ja/en は全クリップ、es/pt/fr/de はホーム+MOT+瞬間記憶（01-05 は ja 流用）、zh-Hant/zh-Hans/ko は 01-05 も撮り直し（速度ラベルが 一般/正常/정상 のため）
• 瞬間記憶は2段構えの半自動撮影を実装（sim_capture.py memory-flash → 数字を目視 → memory-answer 362）。9ロケール分の答えを読み取って入力し、✓ の正解演出まで収録。✓ の出現時刻は中央スロットのシアン率で自動検出して切り出し位置に反映
• Dropbox 納品: 動体視力/スクショ＆プレビュー動画/iPad版/<locale>/ へ動画9本＋スクショ63枚。SHA256 で72ファイル全一致を確認
• ASC 登録: MCP は GET 専用のため ES256 JWT 署名の自前クライアント store-assets/scripts/asc_client.mjs を実装（予約→チャンクPUT→MD5コミットの3段）。動画24本（12ロケール×iPad2枠）を登録し、全て assetDeliveryState=COMPLETE＋トランスコード完了、ポスターフレーム 00:00:00:10 を指定。スクショ168枚は MD5 照合で全て最新素材と判明し、二重アップロードを回避
• 提出前チェックがクリア: 実機でレビュー依頼ポップアップ閉止後の操作が正常と You が確認。8/17 から持ち越していた懸念（シミュレータでの入力不能）はツール起因で確定

You レビューで直した点:

• 締めの HUD ブラケットとコピーの間隔を 141px → 90px、位置を 90px 上（中心 y=872→782）へ。ブラケット幅はコピー実測幅に連動させ、fr/de の長い訳でも破綻しないようにした（従来の固定 660px だと de/fr は 85%縮小でも収まらずエラーだった）
• 種目名ピルの縦位置ずれを修正。上流はフォントのメトリクス基準で中央化しており、descender やウムラウトを持つ語（Teleportation / MOT Fähigkeit）が上にずれていた。加えて「en の4ラベルだけ +2px」という手動補正が逆に +4px ずらしていた。cap height（大文字上端〜ベースライン）の中央で合わせる方式に置換し、全ロケールで解消
• MOT のシアン点滅（どの球を追うか）が B案の窓から外れていたので、raw 頭出しを 4.0→0.1秒にして窓の2秒地点に来るよう調整
• 01/03 で玉がコピーに重なる問題は、コピー帯の明るさを raw 全体で走査して重ならない頭出しを機械的に選定（01: 2.0→4.5秒、03: 2.0→6.0秒）

詰まったこと / 気づき:

• cliclick 方式が3回破綻し、AXe（brew install cameroncooke/axe/axe、MIT）へ移行。cliclick は画面上の絶対座標なので、①Simulator が別スペースにある ②ウィンドウ位置が動く ③デバイスの向きが変わる のどれでも即破綻する。AXe は HID 経由でデバイス座標に直接届くため全部無関係になり、マウスも奪わないので撮影中に別作業ができる。座標は論理ポイント（デバイス座標の半分）
• open -a Simulator がデフォルトデバイス（iPhone 17 Pro）を勝手に起動する。2台目が起動すると simctl io screenshot が "Timeout waiting for screen surfaces" で詰まる（8/17 の「2台目シミュ排除が最重要」と同じ罠）
• シミュレータ再起動でデバイスの向きが失われ、アプリがレターボックス表示になった。向き設定は ~/Library/Preferences/com.apple.iphonesimulator.plist の DevicePreferences に入っているが、書き換えても復帰せず、最終的に You の手動操作で復旧。以後の撮影は 180度ずれたままなので、収録直後に hflip,vflip で正規化して既存素材と向きを揃える方式にした
• 画面状態の判定は fallback を playing にする必要がある。02 周辺視野だけヘッダーの実寸が違ってタイマー検出に掛からず、paused と誤判定して「ホームに戻れない」で撮影が止まった（iPad はスクショ制作時も画面ごとにヘッダー実寸が違った）
• scratchpad は消えることがある。撮影ツールを scratchpad に置いていたら消失して撮影が失敗したため、store-assets/videos/scripts/sim_*.py へ保全した
• タップの押下保持は 220ms 必要（120ms だと難易度選択などで取りこぼす）。※AXe 移行で解消
• 作業中に「security が Chrome Safe Storage を使おうとしています」というキーチェーン要求が出たが、本セッションの実行内容（brew/simctl/ffmpeg/python）には該当なし。同時刻に別の Claude Code セッションが2つ起動しており、そちら由来の可能性が高いと報告

次回やること:

• 1.4.0 の審査提出（トムソンからスクショ＆動画の OK 受領済み。You が手動で申請）
• Android 1.3.3（versionCode 23）のビルド・提出
• 8/27 ストリーク確定判定（判定方法の決め直し込み）
• 残素材: スクショ1枚目（全メニュー動画）/ ストア説明文の多言語版

2026-08-18

01:09 - iPad スクショを全9ロケールへ拡大＋瞬間移動の玉配置刷新＋合成バグ2件修正

やったこと:

• iPad 13inch を残り7ロケールへ展開（zh-Hant / zh-Hans / ko / es / pt / fr / de × 7画面 = 49枚）。ios/<locale>/13inch/ が iPhone と同じ9ロケール体制（計63枚）になった。コンタクトシートは build_l10n_contact_sheet.py --frame 13inch で9枚再生成
• バグ①: iPad レンダラーに速度ラベル差し替えが未実装だった → localize_speed_header_ipad を追加。iPhone 側は 02〜07 全画面で localize_speed_header を通して NORMAL→一般/正常/정상 に差し替えていたが、iPad 版は 08 の MOT ヘッダーだけ処理していた。ja/en は差し替え不要なので露出していなかった欠陥。iPad の raw は画面ごとにヘッダー実寸が違う（小=02/04/05 字高51px / 中=07 は56px / 大=03 は92px / 06 は 04 のヘッダーを流用）ため、画面別ジオメトリを実測値で持たせた
• 02-teleportation の玉配置を刷新: 撮影位置そのままだと3球が横幅380px（画面の14%）に固まり動きが出ていなかった。候補3案（Z字4球 / 大きな>字3球 / 加速カーブ4球）を提示し You が「大きな>字3球」を選択。玉 (1560,560) 0.56 → (2520,1150) 0.78 → (1620,1800) 白で、横960px・縦1240px を使う。未使用だった ghost-b も候補用に配線済み。配置は TELEPORT_LAYOUTS（initial / wide=採用 / z / accel）として保持し --teleport-variant で切替、既定=採用版
• バグ②: remove_ball の合成ミスで黒リングが出ていた → 透明レイヤーに patch を貼ってから alpha_composite するため RGB がマスクで乗算され、さらにアルファでも乗算されていた。ぼかし境界の合成重みが m² + (1−m) になり m=0.5 で25%暗くなる。GaussianBlur(11.0) なので帯が広く可視。canvas へ直接 paste する形に修正し、修復後の画素がクリーン参照と全チャンネル差0になった
• 同バグの影響を受けていた 04-zigzag / 06-3d も全ロケール再生成（You 承認）。リングは玉に隠れず露出していた（04: 最寄り玉まで384px / 06: 371px）。06 はシアンのグリッド線を暗く食っていて最も目立っていた（x=2400 の輝度 40→46 に復元）
• 履歴退避: 上書き前に 02/04/06 × 9ロケール = 27ファイルを ios/<locale>/13inch/history/pre-spread-ring-fix-20260818/ へ退避し、SHA マニフェスト history-manifest-pre-spread-ring-fix-20260818.txt を作成

検証:

• ja/en の回帰なし: 速度ラベル追加後に再レンダーして提出済み14枚と SHA完全一致を確認（差し替え前）
• ロケール間差分の逸脱 0/56: コピー塊＋ヘッダーラベル以外に画素変化がない = ゲーム画素は全ロケール同一
• 63枚すべて 2732×2048 / RGB（アルファなし）。見出しは自動縮小の上限内（例外ゼロ）、本文・チップ最大1412px（スクリム1760px内）
• 目視: ko / de / zh-Hant 全画面、速度ラベル6画面×3ロケール、MOTヘッダー9ロケール（消去残りなし）、02 の横展6ロケール

決めたこと: iPad 素材を全9ロケールへ拡大（8/17 の「ja/en のみ」を撤回）/ 02 の玉配置は「大きな>字3球」/ iPhone 側の同種リングバグは修正しない → DECISIONS 参照

詰まったこと / 気づき:

• 06-3d に残る暗い領域はアーティファクトではない。b05（クリーン背景の供給元）が raw より平均12レベル暗く見えたため患部を疑ったが、外周リングでの canvas−patch 中央値差は0で、輝度プロファイルもパッチ境界で連続。平均差はブルームがグリッド線に乗った分で、暗部は 3D シーンの壁面そのもの
• iPhone 側に同じ合成バグが2箇所ある: render_static.py:349（iPhone 02 が使用）と render_zigzag.py:137（iPhone 04）。提出済み iPhone 素材9ロケールが該当。You 判断で修正しない。なお光彩・スクリム描画でも同じ Image.new("RGBA") + alpha_composite を使うが、あちらは意図的な半透明重ね描きなので対象外
• preview/index.html は 8/11 の ja・6.9inch のみで陳腐化。生成元 build_preview.py は既に存在せず、l10n 以降はコンタクトシート運用に移行している（機能上は不要）

次回やること:

• ASC へ iPad スクショを登録（未登録10ロケール×7枚×iPad2枠=140 + ja/en-US の 02/04/06 差し替え×2枠=12 → 計152アップロード）。ロケール対応・表示順は iPhone 登録時の前例踏襲
• iPad App Preview 動画（ja/en、30秒B案の 4:3 再構成、1600×1200）→ ASC 登録 → 1.4.0 提出
• 提出前に実機でレビューポップアップ閉止後の操作を30秒確認

2026-08-17

23:46 - 1.4.0 提出準備を一括実行（ASC素材差し替え・build 3・What's New・iPad版スクショ制作）

やったこと:

• トムソンOK受領 → ASC 登録を ASC API 直叩きで実施（~/.config/asc/ の既存キー 765NS3X2S3 + jose で JWT 署名、スクリプトは scratchpad の asc/*.mjs）。1.4.0 は ASC 上に作成済みだった（8/6、PREPARE_FOR_SUBMISSION）ためバージョン作成は不要だった
• iPhone 6.9インチ枠の素材差し替え（12ロケール）: スクショ63枚+動画9本をアップロード（es/fr/pt は地域変種 es-MX/fr-CA/pt-PT にも同素材）。全件 assetDeliveryState=COMPLETE を検証。旧 iPhone 6.5/5.5 インチ枠は削除（メタデータは backup-old-sets-1.4.0.json に退避、ライブ 1.3.3 は別リソースで無影響）
• 動画ポスターフレームを全12本に指定（冒頭0.5秒フリーズ内の10フレーム目、previewFrameTimeCode=00:00:00:10）
• What's New を12ロケール一括投入（ja/en は承認文面・MOT言及なし版、他10ロケールは既存翻訳データの語彙と整合させて翻訳）
• build 3 を制作・アップロード・添付: 作業ツリー現状（瞬間記憶回答スロットの表示防御修正+MOTボール新テクスチャ、ストア動画と実アプリの一致のため同梱）で DeviceCheckBuild.Build → arch → アップロードは Xcode ログインセッション経由（-authenticationKey の APIキー 8M2SWG78S6 は IDE distribution で Unauthenticated になる）→ 処理完了を待って 1.4.0 へ自動添付（VALID、ITSAppUsesNonExemptEncryption=false 焼き込み済みで暗号化申告不要）。ビルド番号は 2→3（ProjectSettings、未コミット）
• iPad 版スクショを新規制作（ja/en のみ、You 決定）:
  • 撮影環境: iPad Air 13-inch (M4) シミュレータ（2732×2048 ネイティブ = ASC iPad 枠要件そのまま）+ 課金状態一時パッチビルド（MOT解放・広告なし、ソース即復元）+ prefs 演出（ストリーク「2日連続」点灯・クロスプロモ/レビューポップアップ抑制、cfprefsd kill で反映）
  • raw 7画面を撮影し raw-ipad/ja/ に保存（バースト連写・simctl 録画からのフレーム抽出、レンダラー用の補助素材とREADME込み）
  • レンダラーを iPad 移植: scripts/render_ipad.py（スクリム・コピー塊の 4:3 再配置）+ render_ipad_screens.py（7画面の合成移植: 瞬間移動ゴースト軌跡・ジグザグ機械軌跡・3D バウンドV字・瞬間記憶数字オーブ・MOTヘッダー英語差し替え）
  • You レビュー往復で確定: 05=タイル用スクリム再設計（ソリッド1250/フェード1950/上端196・blur12）+ 点灯タイルの実画素移植（ベースフレーム差し替え+右上白セルへ転写）/ 08=撮り直し+重なり玉の消去・シアン玉移動（円形パッチ+正円ディスク復元で仕上げ）/ 03=コピー塊を+100下げて注視点を見出し1行目右横の空白に通す配置
  • en 7枚はレンダラーの --locale en で自動生成（Codex 発注は不要と判断）。ja/en 14枚（2732×2048）を ios/<locale>/13inch/ に確定
• iPad 枠の ASC 差し替え完了: ja/en-US × iPad 2枠（PRO_129/PRO_3GEN_129）へ28枚アップロード（全件COMPLETE）、旧デザインの iPad 動画は削除（新動画制作までは iPad はスクショのみ表示）
• 権利確認は You 判断で「問題なし」 → 公開ブロッカーから除外

決めたこと: iPad素材は ja/en のみ / iPhone 枠は 6.9 のみ運用 / iPad スクショはレンダラー移植で自動生成+実画素レタッチ許容 / 権利確認クローズ / build 3 は現状ツリー同梱 → DECISIONS 参照

詰まったこと / 気づき:

• シミュレータのクリック自動化の真因: タップ不発の主因は「2台目のシミュレータ（iPhone 17 Pro Max）のウィンドウ」で、落としたら安定した。他の教訓: cliclick は押下保持式（m→dd→w120→du）が確実 / スクリプト中断で mouse down が残留すると以降が全部ドラッグ化する（du 先打ちで解除）/ ウィンドウ座標は白画面キャリブレーション+ベゼルインセットで補正 / prefs 書き換えは cfprefsd kill で即反映（シミュ再起動不要）
• 途中「レビューポップアップ閉止後に入力不能」を疑ったが、対照実験ではあとで/嫌だ両経路とも正常でツール起因の可能性が濃厚。提出前に実機で30秒だけ要確認（ポップアップを閉じた後に操作できるか）
• 周辺視野の注視点は常に画面中央固定・数字玉は左右2位置のみ（フレーム選びでは回避不可）。ゲーム固定レイアウトはコピー側を動かすのが正解
• ASC の appScreenshots/appPreviews アップロードは 予約→チャンクPUT→MD5コミット の3段。表示順は relationship の PATCH で明示確定できる

次回やること:

• iPad App Preview 動画（ja/en、30秒B案の 4:3 再構成、1600×1200）の制作 → ASC 登録
• 提出（手動リリース設定のまま）。提出前に実機のレビューポップアップ30秒チェック

05:06 - ストア素材の多言語展開が完成（スクショ8言語56枚・動画8本の制作・検収・Dropbox納品）

やったこと:

• スクショ多言語化（8ロケール56枚）: 翻訳データ screenshots/copy/screenshot-copy.i18n.json / TRANSLATIONS.md を作成（9言語、アプリ内 I2 の既存訳と用語整合、シアン強調の行頭制約込み）→ Codex CLI レビュー（must-fix 16件を全反映、nice-to-have 13件見送り）→ 指示書 CODEX_L10N_RENDER.md で Codex 発注 → 56枚納品を全数検証（2868x1320、ゲーム画素の ja 完全一致、ヘッダー差し替え目視）で合格
• 事前調査で撮り直し不要と確定: raw 7枚の言語依存は 08 の MOT ヘッダー指示文のみ。zh 2種と ko はアプリ内速度ラベルが「一般/正常/정상」のためヘッダー中央 NORMAL を差し替え（他ロケールはアプリ実物も NORMAL）
• トムソン最終OKを受領 → 30秒版動画を確定版に差し替え: B案 v3（29.85秒）を videos/ios/ja/6.9inch/01-overview.mp4 へ（旧版は history 退避、SHA 照合済み）
• 動画多言語化（8ロケール8本）: 翻訳データ videos/copy/video-copy.i18n.json / VIDEO_TRANSLATIONS.md（キャッチコピー11句+種目ラベル7種）→ Codex レビュー（must-fix 5件+提案6件反映）→ 全編0.5秒スイープで言語依存UIの完全リストを確定（MOTヘッダー・瞬間記憶回答画面の指示文・zh/ko の NORMAL・締めホーム）→ 指示書 CODEX_L10N_VIDEO.md で発注
• シミュレータでロケール別ホーム素材を撮影: -AppleLanguages 起動引数で I2 が追従することを検証（再ビルド不要）。ストリーク「2日連続」点灯はアプリコンテナの plist 直編集（vsn1_streak_length / vsn1_last_qualified_date、simctl spawn defaults はサンドボックス外で効かない）＋シミュレータ再起動で復元し、8ロケール分 raw/<locale>/00-home.mov（各約25秒）を録画
• Codex 生成中の指摘に対応: 瞬間記憶クリップの回答画面に日本語UI「表示された順に数字を入力してください」が焼き込まれている件 → I2 実文言9言語を footage_fixups として JSON に追加、指示書に帯置換対象と全編スイープ検証を明記
• 検収で欠陥1件を検出 → 修正 → 再検証合格: 全8ロケール共通でフレーム495〜498（16.50〜16.60秒）のテンキーがキャッチコピー消去処理に巻き込まれて破損（Codex の0.5秒スイープでは4フレーム欠陥を検出できず）。フレーム単位チェックを指示書の検証6として恒久化し、修正後にフレーム数896・音声SHA の ja 一致維持＋f490〜505 無傷を確認
• Dropbox 納品: 動体視力/スクショ＆プレビュー動画/多言語版/ にロケール別8フォルダ（スクショ7枚+動画1本）+ 一覧シート16枚。SHA256 で64ファイル全一致を確認。トムソン向け報告文案も作成済み（送付は You）

決めたこと:

• 多言語展開は「ja 素材流用＋文字差し替え」方式（撮り直しは締めホームのみ）→ DECISIONS 参照
• アプリUI由来の文言（種目ラベル・フッテージ内指示文）は I2 実文言を一字一句使用 → DECISIONS 参照
• ロケール版ホーム素材の Pro バッジ非表示を許容 → DECISIONS 参照

気づき:

• 0.5秒サンプリングのスイープは数フレームの欠陥を素通しする。オーバーレイの in/out 境界は±8フレームをフレーム単位で見る必要がある（指示書に恒久化済み）
• 別エンコード同士の画素比較は「差分ゼロ」でなく「差分の所在と大きさ」で判定する（平均0.2〜0.8/255はエンコードノイズ、テキスト領域外に構造的差分がないことを確認）

次回やること:

• トムソンへ多言語納品の報告送付（文案あり）→ 確認 OK 後に App Store Connect への登録
• 公開前の未決「動画音声の権利確認」の扱い判断

2026-08-16

23:20 - トムソン第2回レビュー対応: 30秒版はB案構成（瞬間移動開幕→ブランド締め）を制作・確定

やったこと:

• トムソン第1回返答を受領・整理: 【1】スクショ7枚=3微調整込みで承認（確定）【2】説明文2行=後日PPOのA/Bで検証に合意（確定）【3】動画=代案提示（「瞬間移動『その一瞬を、捉えろ』で開幕→最後にメニューで『見る力を、鍛える。』締め」）で判断はこちらにお任せ
• B案を実制作して見比べで決める方針（You 選択）。締めフレームはフル版イントロで承認済みの HUD ブラケット様式＋「見る力を、鍛える。」を流用（コピーもブラケット寸法も原寸一致）
  • 新規スクリプト: render_brand_closer.py（締めフレーム）/ render_short_preview_scan_b.py（B案組み立て）/ render_teleportation_freeze_opener.py（後述の静止オープナー）。既存の組み立て・BGMスクリプトはシーン列・入出力名をパラメータ化（既定値=v4 のままで再現性維持）
• 3イテレーションで確定: b1（28.97秒）→ You 指摘「ホーム復帰後、文言表示前に0.5秒の間」→ b2（29.47秒、締め3.5秒化で吸収）→ トムソン第2回返答「B案良い＋最初の1フレームを数フレームコピーして静止スタートに」→ b3（29.85秒）= 冒頭0.5秒（15フレーム）フリーズ
  • フリーズ実装の要点: 窓開始点=コピー境界の2.50秒は決めゼリフの出現アニメーション中でぼやけた絵になるため、文言が完全表示になる2.60秒へ開始点をずらして凍結。音声も同尺の無音を先頭に挿入して同期維持
  • 機械検証: 凍結区間内のフレーム間ピクセル差分≈0（完全静止）、0.5秒以降は差分最大（動き再開）を確認
• Dropbox 納品の最終形（動体視力/スクショ＆プレビュー動画/、全て SHA-256 一致確認済み）: 00-preview-30s.mp4=A案 v4 / 00-preview-30s-b.mp4=B案 v2 / 00-preview-30s-b2.mp4=B案 v3（最新・トムソン確認待ち）
  • 途中、-b.mp4 を v3 で同名上書きしてしまい You 指摘で整理: v2 をローカルから復元し、v3 は別名 -b2.mp4 で併置（②方式）

気づき:

• App Preview はストア上でミュート自動再生されるため「1コマ目から動きがある」B案は Apple 推奨のセオリーに合う。A案の華やかなネオンホームは締めに移動しただけで失われていない
• フリーズオープナーを作るときは「コピー区切りの窓開始点」と「凍結に耐える完全表示フレーム」は別物として選ぶ必要がある
• 総尺29.85秒で30秒制限まで余裕0.15秒。今後さらに足すならどこかの窓を削る必要がある

次回やること:

• トムソンの最終返答を受けて対応（OKなら B案 v3 を 01-overview.mp4 へ差し替え・旧版 history 退避 → App Store 提出準備。未確認SEの権利証跡確認を含む）

20:42 - トムソンレビュー反映: スクショ新タグ7枚＋30秒版App Preview動画を制作しDropbox納品

やったこと:

• トムソンのレビュー受領・対応方針決定: 【1】スクショ下部タグの効果訴求化は即反映 / 【2】説明文2行削除と動画別バージョンは後日プロダクトページ最適化(PPO)のA/B実験へ。進め方は事前相談ではなく「変更して完成物で確認を取る」後出し方式に切替（You 指示）
• スクショ7枚のタグ更新（Codex 分業）: 最終文言=トムソン案＋3微調整（PERIPHERAL VISION②「視野の広さ」→「状況把握」/「4段階」→「速度4段階」/「2〜4個」→「ボール2〜4個」）。Codex 向け指示書 store-assets/screenshots/CODEX_TAG_UPDATE.md を作成し You が Codex へ投入。チップ描画は固定幅指定→実測文字幅からの自動算出に改修（多言語化にも効く）
  • 検証: 7枚とも 2868x1320 / 旧版との画素差分がタグ帯（y:1107〜1188）のみに収まることを機械確認。06-3d のみ追加のボールAA修正あり（pre-ball-aa-20260816 退避付きの意図的修正）
• App Store 用30秒版動画を新規制作（Claude 側で実施）: App Preview は15〜30秒制限のため、トムソン GO 済み55.6秒フル版を縮約
  • 新規スクリプト: render_short_preview_scan.py（シーンごとに窓を切り出して既存の転換演出で再結合。早送りは審査要件リスクがあるため実尺切り出し）/ add_short_preview_bgm.py（bgm014 を自然テンポのまま＋末尾フェード）/ render_hook_opener.py
  • 構成: フックオープナー2.5秒 → 5種目の決めゼリフ窓 各2.65秒 → 瞬間記憶フル6.8秒（✓正解まで完結）→ MOT 8.0秒（記憶→START→追跡）= 28.45秒
  • 各FIX単体動画は「前半フレーズ→決めゼリフ」の2部構成コピーが焼き込みのため、窓はコピー区切りに合わせて選定（文が途中で切れない）
• 冒頭に「目で追いかけてください」フックを実装: トムソン指摘「考える前に参加させる」の反映。演出は元の「THE 眼球トレーニング」タイトルと同じ HUD ブラケット様式（hud_brackets_two_stage_frame / add_closing_phrase 流用、静止ホーム画面ベース）。v1(種目コピー調)→v2(HUD様式)→v3(枠スパン820→960pxで余白拡大)の3イテレーションで確定 = 00-short-preview-v4.mp4
• 動画の系譜を整理: A=ストア公開中の元動画（目で追いかけてください版）/ B=旧29.5秒 ios/ja/6.9inch/01-overview.mp4（効果見出し型、未更新）/ C=55.6秒FIX版。30秒版は「Cの縮約＋Aのフック」のハイブリッド
• Dropbox 納品（動体視力/スクショ＆プレビュー動画/）: 新タグスクショ7枚（旧版は history/*-before-2026-08-16-tag-update.png へ退避）＋ 00-preview-30s.mp4（v4と同一）。SHA-256 全ファイル一致確認済み
• トムソンへ報告文を送付（You が投稿）: タグ3微調整の理由・30秒版の経緯（30秒制限＋フック内蔵）・フル版は Google Play/プロモ用に残す旨。→ 返答待ち

気づき:

• 旧29.5秒版（B）は「効果訴求見出し＋DAILY TRAINING締め」の構成で現行スクショとデザイン言語が同じ。PPO実験の対抗馬素材として価値が残る
• フック内蔵により、トムソンの言う「別バージョンでPPO実験」の論点は30秒版で先取り解消した形
• store-assets/（2.3GB）は引き続き未追跡のため、今回も .devnotes のみコミット

次回やること:

• トムソン返答を受けて対応（文言修正 or 提出準備へ）
• OK後: 01-overview.mp4 差し替え（旧版history退避）→ App Store 提出準備（未確認SEの権利証跡確認を含む）

---

2026-08-15

03:26 - ストアスクショ・App Preview動画のCodex制作分を引き継ぎ確認、トムソン返答待ちで一時停止

やったこと:

• Codex（デスクトップ）側で完了したストア素材制作の引き継ぎ2通（CLAUDE_CODE_HANDOFF.md 新規 / SESSION_HANDOFF.md 追記分）を精読し、成果物を検証:
  • 最終FIX版 store-assets/videos/preview/fixed/00-full-preview.mp4（1920x886 / 30fps / 55.567秒 / H.264 / AAC）の存在と SHA-256 一致（2834a161…）を確認。Dropbox 動体視力/スクショ＆プレビュー動画/ にも配置済み・SHA一致確認済み
• Codex 制作分の要点（8/11〜8/15、詳細は上記2ファイル参照）:
  • 日本語 App Preview 全体版が FIX: 7種目すべてに左下シアン楕円の種目名ラベル（瞬間移動/周辺視野/ジグザグ/タイル/３Ｄ/瞬間記憶テスト/MOTスキル）、横スライド＋スキャン光の画面切替、swoosh、BGM（pixabay-bgm014 採用、futuristic-pulse は不採用）入り。単体FIX版7本も同様に更新。旧版は fixed/history/ と Dropbox history/ に退避済み
  • 日本語ストア静止画スクショ 02〜08 の7枚 FIX（2868x1320、store-assets/screenshots/）。MOT はレンダラー製候補05を採用。1枚目（全メニュー動画）は後回し
  • スクリプト整備: ラベル生成 make_menu_label_overlay.py（文字幅自動調整・欠落字形検出・--locale/--font 対応で多言語下地あり）/ 埋め込み embed_menu_label.py / 全体再結合 render_full_preview_scan.py / BGM付与 add_full_preview_bgm_variants.py
  • 注意: プロジェクト内サブセットフォント NotoSansCJKsc-VWSubset.otf は「辺」の字形欠け → 日本語生成はヒラギノ角ゴ W3 使用。欠落字形があれば生成停止する仕様
• 公開前の未決リスク = 音声権利（store-assets/videos/audio/COPYRIGHT_AUDIT.md）: 採用BGMと swoosh 2種は出典・ライセンス記録あり。object.mp3 / push 1.mp3 / se_correct.mp3 は証跡未確認、ball_hits.mp3 は自作録音であることの確認要、MOT の correct_tap1〜3.mp3 は On-Jin 由来の可能性が高く商用動画利用の許諾記録が必要。証跡が揃わなければライセンス記録のある素材へ差し替えが安全
• App Store 提出用の29.5秒版 store-assets/videos/ios/ja/6.9inch/01-overview.mp4 は未更新のまま
• トムソンの返答待ちのため、ここでいったん区切り

気づき:

• operation リポの未追跡に store-assets/（2.3GB）と design-proposals/ がある。素材の git 管理方針（大容量の扱い、Dropbox をマスターにするか）は未決のため、今回は .devnotes のみコミット

次回やること:

• トムソンの返答を受けて再開。候補: ①未確認SEの権利証跡集め or 差し替え ②多言語版ラベル・動画の生成 ③ストア提出条件に合わせた短尺版の作成

2026-08-05

19:05 - デザイン刷新の実装が一段落（Codex が主要画面を完走）＋Editor 課金トグル＋シミュビルド基盤の恒久化

やったこと:

• 8/2〜8/5 で Codex が残り画面の刷新を完走。コミット単位:
  • 48854b9 周辺視野 / 0bf30c8 ジグザグ / b6b33c9 3D(奥行きシェーダー)
  • 6263ae9 タイル・瞬間記憶(モード選択/プレイ)・MOTスキル(モード選択/プレイ/リザルト)・ポーズ(47ファイル)
  • 07da4bb 設定パネル5・カレンダー・リザルト(旧5種目)・チュートリアル・レビュー/カスタム数値ポップアップ(44ファイル)
  • 実装様式は「専用シェーダー+RenewalView」で解像度非依存。共通フィールド部品を種目間で共用
• MOT テスト用の課金状態を2系統整備: シミュレータ=一時パッチビルド(ビルド直後にソース復元、リポ痕跡なし)/ Unity Editor=恒久トグル Tools > Vision Workout > Editor 課金状態にする(acda0fc、#if UNITY_EDITOR 内のみでビルド不含)
• シミュビルド基盤を tools/ に恒久化(2d90c9c): 変換済みライブラリが macOS の3日 tmp 掃除で消失→再構築でハマった教訓。build_sim.sh / make_sim_libs.sh / convert_ar.py / arm64-to-sim(MIT)。再構築中に発見した「ar -x が同名メンバー(GADUInterface.o x2)を上書き消失させ UMP 関数が実行時 NULL になる」問題は ar 直接パース方式で解消
• ダッシュボード更新(4a416e5): 実装完了 19/23 行、フェーズ A/B 完了・C 進行中
• Codex の Editor 支援ツール(言語切替・レビューポップアップ表示トグル)と9言語検証スクショも収録

残り(実装): 瞬間記憶リザルト・トレーニングポイント・おすすめアプリ・システムポップアップ残り5種

次回やること:

• 実機(iPhone 14)での通し確認 → トムソン共有
• QA フェーズの計画(9言語・iPad・課金全通し)と課金計測9イベントの実装

2026-08-01

19:59 - 瞬間移動プレイ画面の刷新完了（Codex）＋UIテクスチャ品質ガード導入

やったこと:

• Codex が瞬間移動（TeleportationScene）のプレイ画面を刷新: プレイフィールドを専用シェーダー（TeleportationPlayField.shader）で描画する構成に変更、刷新ビュー・スタートカットインの新規スクリプト3本＋シーン調整
• UiTextureQualityGuard.cs（Editor）を導入し、Renewal スプライト一式に mipmap＋Trilinear を一括適用（縮小表示のジャギ対策）。種目ボタン・クロスプロモ・ペイウォール閉じるボタン画像も品質再処理
• ダッシュボード反映: フィールド:瞬間移動 = 実装完了、スタートカットイン = 進行中（瞬間移動分のみ実装済み・他種目への展開残）
• コミット: Unity 71932db
• after スクショは未撮影（Unity 起動中でビルド不可のため次回シミュビルド時に）

次回やること:

• シミュビルドで瞬間移動プレイ画面の実物確認＋after スクショ撮影
• 残り種目のプレイフィールド展開（ジグザグ/タイル/3D/周辺視野）とスタートカットインの共通化

14:56 - ペイウォール画面の刷新完了（Codex）＋進捗ダッシュボード整備

やったこと:

• Codex がペイウォール（Paywall2AdditiveScene）を刷新: paywall_* 画像一式（閉じる/CTA/プランラベル/炎/プレミアム帯等）・ヘッダーバンド新規・シーンのレイアウト/配色調整。価格・プラン構成は現行のまま（7/28 決定どおり表示デザインのみ）
• シミュレータで実物確認しスクショ取得（刷新スクショ/after/paywall.png）。ホームの after も背景刷新版（ネットワーク調バリアント）に更新
• 進捗ダッシュボード整備: 工程列を「モック/実装」の2列に簡素化（アセット/レビュー/QA 列は削除、DATA は温存）、ホーム・ペイウォールの実装完了とマイルストーン・決定ログ2件（8/1 分）を反映
• コミット: Unity 3364d52 / operation 34593fe〜a27b1a9

次回やること:

• 刷新済み2画面（ホーム・ペイウォール）をトムソンに共有
• 残り画面の刷新継続（設定パネル・共通HUD・カレンダー等はモック生成から）

13:15 - ホーム画面デザイン刷新の実装完了（Claude+Codex 分業、シミュレータ・実機確認まで）

やったこと:

• モック1（ネオン調）ベースでホーム全アセットを Codex CLI で生成し、透過化パイプライン（scratchpad の process_assets.py: fill/lum 2方式・対称トリム・背景差し引き・端フェード等をジョブ別オプション化）で 刷新アセット/home/final/ に整備。RenewalApply.cs（バッチ実行可能・冪等）で HomeScene に適用
• iOS シミュレータでの確認環境をゼロから確立: Unity 2022.3 の Firebase 入りビルドを arm64 のまま通す方式（詳細は DECISIONS）。以後「画像修正 → 15〜25分でシミュ確認」のループが回るようになった
• 種目アイコン7種を実物確認しながら個別ブラッシュアップ: 瞬間移動（玉サイズ・配置）/ タイル（6列3行化・マス拡大・間隔維持）/ 3D（ボタン全面 1.3:1 型に再構成）/ 周辺視野（刷新前の構図=目+左右ターゲット玉+「2」を新トーンで復元、以前からの「2」欠落課題も解消）/ ジグザグ（テーパー軌跡+大玉）/ MOT（線除去・玉のみに）/ 瞬間記憶（38ボール）。アイコンは「全面型（周辺視野・ジグザグ・3D）」と「グリフ型（他4種）」の2系統に整理
• 選択中/非選択ボタンの見かけサイズ差（選択中が約13%小さい）をトリム基準の統一で解消
• 実機確認: iPhone 14 へ開発署名の直インストール（DeviceCheckBuild.cs + 自動署名 Team JFBRCYHN24）
• フッター刷新は Claude 経由の Codex 依頼2回で品質がモックに届かず → You が Codex デスクトップに直接指示する方式へ切り替えて完成（グリフ込みボタン btn_ft_* 9種、Play リング改良、クロスプロモ画像刷新、3DデモGIF色調、瞬間記憶回答ボタン、背景バリアント等も Codex が実施）。Codex がシミュビルドで x86_64/Rosetta 方向にハマった際は確立手順をコピペ用アドバイスとして提供して復帰
• コミット: operation d28b74f（作業アセット一式）/ Unity 5b67e6d（刷新適用）+ f9671f1（Codex 仕上げ分）

気づき:

• 幅フィット表示ではアイコン画像内の要素を拡大しても表示サイズはほぼ変わらない（全体幅が広がり同率縮小される）。マスの見かけを変えるのは表示領域（anchor）側
• Unity Editor を開いたまま Editor で行った変更は、バッチビルド前に Cmd+S 保存されていないと反映されない（今回 anchor 変更を RenewalApply に恒久化して解決）

次回やること:

• 刷新ホームをトムソンに共有（スクショ or TestFlight）し、他画面（プレイ/設定/ペイウォール）への展開スコープを決める
• 刷新のリリース載せ方を決める（Android 1.3.3 と同梱するか、iOS/Android 次版で同時か）
• process_assets.py はセッション一時領域にあるためリポへの保存を検討

2026-07-27

19:57 - トムソンの価格A/Bテスト提案（v6）を実データで検証 → デザイン刷新を先行させる方針に

やったこと:

• トムソンから iOS 価格A/Bテスト提案を受領・精読（~/Downloads/vision_workout_pricing_ab_test_proposal_v6.html、2026-07-22 v6版）
  • 内容: iOS 新規ユーザーを Remote Config で 50:50 に分け、①買い切り 3,400円 vs 4,800円 → 勝者100%配信 → ②年額 1,800円 vs 2,400円 の順に1変数ずつテスト。3か月900円は両群共通・既存契約者除外。判定は Firebase A/B Testing の「ペイウォール閲覧者1人当たり購入売上」、14日を最短判定点、最短5週間。採用価格は Android にも反映。目標=iOS新規ユーザー収益 10〜20%改善
• 検出力を実データで裏取り → 「14日判定・最短5週間」は成立しない可能性が高いと判定
  • GA4: iOS 新規 約950人/月（ほぼ全て日本）→ 1群あたり約475人/月
  • ASC 2026-06 月次: 買い切り（gen2.pro）32件/月・うち日本11件 / 年額有料（gen2.1year）日本19件（更新込み）/ 年額トライアル開始 日本38件 / 3か月有料 日本14件
  • 日本の新規ユーザー限定だと買い切り購入は1群あたり月数件のオーダー。売上維持ライン（件数29%減）の検出には1群数千〜数万人が必要で、数ヶ月〜年単位かかる試算
• GA4 に課金イベントが1件も存在しないことを確認（直近28日の iOS イベント一覧に purchase 系ゼロ）。提案の Goal metric（Purchase revenue）は現状では成立せず、イベント表9種（paywall_view / purchase_success 等）を丸ごと新規実装する必要がある
• 規約面の調査（「課金額のA/Bは規約的にOKか」）→ 明文で禁止する規約はどちらのストアにもない
  • Google Play: 買い切りの Price experiments が公式機能として存在（提案書も引用）
  • Apple: 公式機能はないが複数商品＋出し分けは業界標準（RevenueCat 等が商用提供）。ただし同一表示名・説明のサブスク2本をプロモート対象にして 2.3.2（Accurate Metadata）でリジェクトされた事例あり（Developer Forums thread 724623）→ 回避は「表示名・説明を商品ごとに一意にする」「promoted IAP に両バリアントを載せない」
  • 日本法: パーソナライズド・プライシングを違法とする規定は現時点でない。景表法で問題になるのは二重価格等の誤認表示で、StoreKit/Play Billing 取得値を表示すれば問題なし。EU の個別価格告知義務は日本限定テストなので非該当
  • 残るリスクは規約より評判（同一サブスクグループ内でもう一方の価格が管理画面に見える可能性、「人によって値段が違う」レビュー）
• 課金実装が完全自前であることをコードで確認: RevenueCat 類は不使用。PurchasingManager.cs（426行）＋ PurchasingManagerForAndroid.cs（320行）が Unity IAP 5.1.2 を直接ラップ。商品IDハードコード・レシート検証サーバーなし・Analytics 送信ゼロ。A/B の計測基盤はゼロからの実装になる
• デザイン刷新モック4枚を確認（ホーム / プレイ画面 / 設定 / ペイウォールの近未来ネオン調）し、リポ直下 眼球トレデザイン刷新案/ にコピー（未コミットだった分を今回コミット）

決めたこと（DECISIONS.md にも転記）:

1. 価格A/Bテストより先にデザイン刷新を進める方針（順番: 刷新 → 計測基盤 → 価格検証）

詰まったこと / 気づき:

• モックのペイウォール（4.png）は「まずは3か月試す」と900円プランを主役にしているが、トムソンの意図は年額・買い切りの単価引き上げ。どのプランを推すかは刷新デザインと価格戦略の交点なので、ここだけはトムソンと擦り合わせてから確定させる必要がある
• 計測イベント（paywall_view / purchase_success 等）はデザイン刷新の効果測定にも価格テストにも必要な共通基盤。刷新リリースに同乗させれば一石二鳥
• ROADMAP の「いつか」にある S-005（Remote Config + 課金ファネル計測）と L-006（追加値上げの段階テスト）が、トムソン提案によって前倒しの検討対象になった形

次回やること:

• トムソンへの返答方針の確定（実データ試算の共有＋「刷新→計測基盤→価格検証」の順番提案）
• ストリーク効果測定（8/13 一次 → 8/27 確定）は予定通り進める

18:41 - iOS 1.3.3 リリース後1週の健全性チェック（合格）＋ GA4 カスタム定義登録・認証をサービスアカウントに移行

やったこと:

• 記録の空白（7/14〜7/27午前）を実態調査で確定。DEVLOG が 7/11 で止まっていたため、Unity リポと App Store Connect から復元
  • 84dcccf（7/14）ストリークチップが種目ボタン列に被る問題を修正（幅上限を画面幅比率でなく列左端ボタンの実座標から逆算、ノッチ側セーフエリア控除、4:3 iPad はボタン列下へフォールバック）
  • f595f22（7/27 12:39）中国語簡体字の一部文字が表示されない不具合を修正（ChineseFontSwapper 新規＋全シーンのフォント差し替え）
  • 0842e66（7/27 12:39）バージョン 1.3.3 ＋ iOS リリースビルド時の自動更新分。タグ iOS1.3.3 作成・push 済
  • ASC 確認: iOS 1.3.3 = READY_FOR_SALE、build 3 は 7/14 19:53 アップロード。7/14 のビルド後に未コミットのまま作業が溜まり、7/27 に2コミットへ整理した形
• リリース後1週の健全性チェックを実施（計測プラン v3 の「リリース後1週=実装健全性ゲート」）。判定=合格
  • GA4 の appVersion 別アクティブ推移から リリース日=2026-07-16 を特定（ASC API にはリリース日が出ない）。7/19 でほぼ置換、7/26 時点の 1.3.3 到達率 96.1%
  • イベント4本すべて発火・iOS のみ（Android 1.3.3 未配信と整合）
  • streak_updated の日次 events/users = 1.02 → ローカル日付1回制御が効いている（重複なし）
  • training_completed ユーザー 1,740 vs streak_updated 1,739 → qualified 判定の取りこぼしなし
  • impression ユーザー 3,120 ≒ 1.3.3 週次アクティブ 3,111 → チップは実質全アクティブに表示
  • 本命指標「週あたりプレイ日数/人」= 全体 1.10（既存 1.18 / 新規 0.51）、週内プレイ到達率 既存 56.2% / 新規 50.4%
  • チップ CTR = イベント 4.8% / ユーザー 6.9%（新規 6.1% > 既存 4.6%）
  • Crashlytics: 1.3.3 で新規クラッシュ 0（3件とも 1.3.1/1.3.2 からの既存、影響3ユーザー）
  • iOS 全体の週次ベースラインを 6/14〜7/25 で取得。秒/人 574〜633、セッション/人 2.02〜2.10 でほぼ横ばい（1週目で差は出ていない＝プラン通り）
• GA4 認証・権限の詰まりを段階的に切り分けて解決
  • analytics-mcp が 403 → ADC が 6/24 に analytics.readonly なしで再作成されていた
  • 標準 gcloud クライアントでの再認証は「このアプリはブロックされます」→ --client-id-file で自前 OAuth クライアント指定が必須と判明
  • 再認証しても MCP サーバーは起動時の認証情報を掴んだままなので、GA4 Data API / Admin API を直叩きするスクリプトを書いて進行
  • カスタム定義の登録を試行し、ACCESS_TOKEN_SCOPE_INSUFFICIENT（スコープ）→ 再認証 → The caller does not have permission（ロール）と切り分け、個人アカウントが閲覧者どまりであることを確定
  • You の示唆でサービスアカウント ga4-mcp@ichirokisanuki.iam.gserviceaccount.com を検証 → 眼球トレのプロパティには未追加、アクセス可能なのは studytimer / channel7-ios / footballnext の3件のみと判明
  • トムソンへ依頼 → プロパティ 271861292 に編集者で追加してもらい解決
• カスタム定義4件を登録: ディメンション streak_bucket / chip_state / training_type、指標 duration_sec（秒）。登録後に一覧で存在確認済み。集計反映は24〜48h
• .mcp.json の analytics-mcp をサービスアカウントキーに向け替え（GOOGLE_PROJECT_ID も SA 自身のプロジェクトへ）。同じ SA で Data API 読み取りが通ることも確認済み。反映には Claude Code 再起動が必要

決めたこと（DECISIONS.md にも転記）:

1. GA4 のプログラム的アクセスをサービスアカウント方式に統一（個人アカウント ADC から移行）
2. 計測プランの3ディメンションに加えてカスタム指標 duration_sec も登録する

詰まったこと / 気づき:

• カスタム定義の登録漏れが発覚。計測プラン・WIP・DEVLOG の3箇所に「リリース前タスク」として書いてあったのに、7/14 のビルド〜提出でチェックリストに戻らず素通りした。「リリース直前でOK」と書いたことで後ろに倒せるタスクになったのが一因
• ただし思い出していても間に合わなかった。登録には編集者権限が必要で、閲覧者しか持っていなかった。プランで「アプデ不要・自己完結」と分類したこと自体が誤りで、実際はトムソン依存タスクだった。計測プランを書く時点で権限の有無を確認すべきだった
• 損失は診断指標（streak_bucket 分布 / chip_state 別 CTR / 種目別完了数）の11日分のみ。GA4 はバックフィルしない。本命指標とガードレールは素の eventCount で取れるため影響なし
• DEVLOG の記録が「6/1 に GA4 のユーザー追加 UI がサービスアカウントのアドレスを拒否、回避不能」としていたが、footballnext には同じ SA が実際に追加されている。あの時の拒否は You 側の権限/UI の問題だった可能性が高い。方針転換の判断材料が誤っていた例
• 自前 OAuth クライアントは同意画面が「テスト」ステータスのため refresh token が7日で失効する。6/24 の再認証痕跡も今日の 403 もこれが根因の可能性が高い。SA 方式への移行でこの問題は消える
• 同名の ga4 MCP サーバーは別プロパティ（footballnext, 211701453）を向いている。眼球トレの分析には使えない

見つかった課題（今回は対応せず）:

• streak_chip_impression が 1.14/セッションで、仕様「1セッション1回」を 14% 超過。トレーニング → ホーム復帰で HomeScene が再ロードされる分の二重計上と推測。実害は CTR 分母が膨らみ CTR が低めに出ること。アプリ側修正なので次回アプデ送り
• 本命指標の前後比較は構造的に不可能。streak_updated / training_completed は 1.3.3 で新設したイベントなので 1.3.2 以前の値が存在しない。4〜6週判定は「1.3.3 内の週次トレンド」＋「プレイ時間・セッション数/人の前後比較（標準指標）」の組み合わせになる
• 新規流入の減衰が交絡する。新規 0.51 日/週・既存 1.18 日/週と差が大きいため、必ず newVsReturning で分けて見る必要がある

次回やること:

• 7/29 頃: カスタム定義の反映確認（streak_bucket が (not set) でないか。5分）
• Android 1.3.3（versionCode 23）のビルド・提出。現在 AndroidBundleVersionCode: 22 のままでストリーク機能も中国語修正も未配信
• 8/13（4週）一次判定 → 8/27（6週）確定判定。診断データは登録日から蓄積されるため、判定の重心は 8/27 に置く
• 関連メモリ: [[project-ga4-adc-auth]], [[project-thomsons]]

---

2026-07-11

03:12 - ストリーク機能を実装（Codex分業→多視点レビュー→修正・CodeCommit push・Editor確認OK）

やったこと:

• Codex 向け実装指示書（ストリーク実装指示書.md）を作成して実装を委譲。ポイント: シーン/プレハブ編集禁止（UI は実行時生成）、コード変更は Unity リポのみ・commit 禁止、ビジュアルの正解としてリポ直下のモック HTML を参照させる、既存フック地点を実行番号つきで指定
• Codex が実装完了（新規3ファイル: StreakManager / StreakChipView / StreakLocalization + 既存11ファイル修正、ストリーク実装報告.md に報告）。dotnet build 0エラー、指示逸脱も報告書に明記される良質な仕上がり
• /code-review (high) を実行: 8視点ファインダー（行単位/削除挙動/クロスファイル/再利用/簡素化/効率/高度/規約）→ 候補38件 → 重複統合12件 → 検証エージェントで1件ずつ裏取り → 10件生存（CONFIRMED 9 / PLAUSIBLE 1）、1件反証棄却
  • リリースブロッカー級: ①マイグレーションが最大2,570回の同期ES3ファイルI/O（長期ユーザーほど初回ホームでフリーズ/ANR）②streak_updated が「値が変わった時のみ」送信のため隔日ユーザーで生涯1回しか飛ばず本命指標が崩壊（私の仕様の欠陥）③日付文字列がカルチャ依存とInvariantに分裂（タイ仏暦端末で照合不能）+ 0時跨ぎで履歴とストリークが別日付
  • 品質系: 実測秒の水増し（放置・広告混入）/ カレンダーI/O 3.5倍 / 初期レイアウト0.5秒グリッチ / 非可視impression / switch のcase漏れ耐性 / 日付判定3重実装 / 色定義重複
• 9件＋色定数を修正して Unity リポへコミット 05a3215・push。主要な直し方: qualified日ごとのstreak_updated送信 / Prefs.CreatePlayHistoryReadSettings()（ES3.CacheFile で一括読み、マイグレーション2,570回→1回）/ AppUtil.GetDateText()（Invariant）に日付生成を統一し完了処理の日付を貫通 / フレーム寄与0.5秒クランプ+1回30分上限 / チップ生成をWaitForEndOfFrameに遅延+Refresh早期リターン / sceneLoaded/Unloadedでadditiveオーバーレイを数えてimpression抑止 / switch→1行キー生成 / Classify()ヘルパー
• チップ縁のギザつき修正（You の実機スクショ指摘）: 実行時生成スプライトが64×32の二値アルファだったのが原因。4倍解像度+距離ベースAAに変更、pixelsPerUnit同率調整で表示サイズ不変（3eb3612）
• You が Unity Editor で表示・動作を確認 → OK。トムソンへ実装内容の確認依頼中

決めたこと（DECISIONS.md にも転記）:

1. streak_updated は「値が変わった時のみ」→「qualified 日ごとに毎回」に仕様変更（計測プラン v3 も同期修正）
2. 瞬間記憶/MOT の「即失敗でも qualified」は現状維持（挑戦＝トレーニングと割り切り）

詰まったこと / 気づき:

• 検証エージェント12本のうち6本がセッション5h制限で落ちた → リセット後に再起動して完走。多エージェントレビューは制限帯で分割実行を意識する
• 実行時生成UIスプライトは二値アルファだと拡大表示でギザつく。距離ベースのアルファ勾配（SDF的な1px遷移）+高解像度化が定石
• 「指示書に書いた仕様自体の欠陥」をレビューが検出するケースが2件（streak_updated送信条件・即失敗qualified）。実装レビューは仕様のレビューを兼ねる

次回やること:

• トムソン確認の返事待ち → OK後: 計測QA（DebugView 7ケース+7種目 qualified）→ 実機検証 → GA4カスタムディメンション登録+ベースライン取得 → バージョン更新・ビルド・提出
• 炎スプライトの最終アート差し替え（現状は丸プレースホルダ。HomeScene の Inspector に挿すだけ）

---

2026-07-10

18:51 - 次回アプデ施策「ストリーク表示」企画〜モック〜計測プラン〜トムソン承認（7/9〜7/10）

やったこと:

• アクティブユーザー・プレイ時間向上の施策を検討。GA4 実測（DAU/MAU≈0.9・月46セッション/人の超習慣アプリ、新規は月1,000人でアプデ月に2倍）＋ Unity コード棚卸しで「ある装置/ない装置」を整理し、8案から軽量方針で ④ストリーク（連続日数）表示 + ⑤カレンダー分数表示復活 を選定
• ストリーク表示の UI モックを Artifact で反復設計 → 決定版: 左上チップ・炎＋「◯日連続」・今日未プレイはグレー消灯→プレイで点灯＋1（昨日までの連続保持ルール）・タップでカレンダーへ
  • iPhone SE (16:9) では左上余白が狭い問題 → 実画面再現モックで検証
  • 9言語対応: 西・葡・仏は一行で収まらない → 数字大＋単位語小の2段組みに自動切替で解決
• 効果測定プランを設計し、gods-talk で Codex レビュー2ラウンド（streak-metrics-review-001/002）
  • R1: GA4標準指標は「アプリ利用」しか測れない / appVersion 疑似A/Bのセレクションバイアス / D7+2〜3pt は検出力不足（要3,000人/群）/ イベント2本では不足
  • R2: 週次イベント方式は離脱者の0日週が欠落する構造欠陥 → 固定分母＋日次イベント方式の提案 / Unity コードまで読んで既存の本番バグを発見
• Codex 発見の既存バグ2件を検証・確定（ストリーク実装の前提修正として必須）:
  1. Prefs.IsOnTrainingPlayed が周辺視野を見ていない（4種目のみ）→ 周辺視野だけプレイした日はカレンダーにチェックが付かない
  2. 瞬間記憶テスト・MOT が PlayType に無く日別履歴未保存 → 7種目でのストリーク加算には保存追加が必要
• 計測はライト版 v3 に確定して ストリーク計測プラン.md に固定（採用版＋フル版アーカイブの2部構成）。イベント4本（training_completed / streak_updated / streak_chip_impression / streak_chip_tapped）、本命指標は「週あたりプレイ日数/人」、判定は1週=健全性・4〜6週=方向判定
• トムソンへ DM 提案 → Artifact 共有が Team/Enterprise 限定と判明 → 単体 HTML 化（ストリーク表示モック.html）して S3 thomsons バケットへ既存共有ファイルと同じ public-read 方式で配置 → トムソン承認取得（2026-07-10）

決めたこと（DECISIONS.md にも転記）:

1. 次回アプデ施策 = ストリーク表示＋カレンダー分数復活（マネタイズ系は今回スコープ外）
2. ストリーク表示の最終仕様（左上チップ・炎＋「◯日連続」・消灯/点灯・長文言語2段組み）
3. 効果測定はライト版採用。BigQuery Export / Remote Config・ローカル holdout 無作為化は不採用

詰まったこと / 気づき:

• プレイ時間単体の判定は二重の罠（総量はリリース流入増でほぼ確実に増える偽陽性 / 1人あたり平均は新規混入で薄まる偽陰性）→ 本命指標を「週あたりプレイ日数/人」に
• Codex にコードベースへのアクセスを与えるレビューは、計測設計の域を超えて実バグ発見までリーチした。gods-talk の費用対効果が高かった回

次回やること:

• 実装設計（作業分解）→ 実装 → 計測QA（7ケース＋7種目 qualified 確認）→ ビルド・提出

---

2026-07-09

Android 1.3.2 が配信済みだったと判明 → リリース記録を実態に訂正

やったこと:

• You から「Android 版も 1.3.2 で配信済み」との情報。WIP は Android = 1.3.1（versionCode 21）のままだったため実態調査
• Unity リポの HEAD / タグ / commit 時刻を確認し、配信内容を特定:
  • iOS1.3.2 タグ = 1bdb1c7（SE NRE 修正 + バージョン更新まで。NativeShare・Analytics は含まない）
  • HEAD = b53d8da（4修正すべて込み）
  • ac57fc8（NativeShare）= 6/26 14:47、b53d8da（Analytics 早押し）= 6/26 15:03 のコミット
• You に確認 → 配信済み Android 1.3.2 は HEAD（b53d8da）ビルド = 4修正すべて搭載と確定
• Android1.3.2 タグを b53d8da に作成し CodeCommit へ push（従来未作成だった）
• WIP.md「現在の状況」を実態に更新（Android 1.3.2 配信済み・タグ済み、残タスクを「iOS へ b53d8da 配信」＋「Android 1.3.2 の Crashlytics 監視」に置換）

確定した実態:

• iOS = 1.3.2（1bdb1c7）→ Analytics 早押し修正 b53d8da が iOS 未配信（クロスプラットフォーム、iOS に残る唯一の意味ある未配信修正）
• Android = 1.3.2（b53d8da、versionCode 22）→ 最新に追いついている。NativeShare（ac57fc8）は Android 専用のため iOS には不要
• 「次回まとめアプデ待ち」という旧認識は誤り。正しくは「Android は完了、iOS のみ Analytics 修正1件が残」

次回やること:

• iOS へ b53d8da を配信するか（単独 1.3.3 or 次回まとめ）判断
• Android 1.3.2 の Crashlytics 監視（NativeShare 32件・Firebase CheckDependencies 早押し 23件の解消確認）

---

2026-06-26

Android クラッシュ上位2件を修正（NativeShare 更新 / Firebase Analytics 早押しガード）

やったこと:

• Android Crashlytics の上位2件を修正。いずれも CodeCommit push 済（次回アップデートでまとめて配信予定。iOS 1.3.3 単独リリースはしない方針）
• ① NativeShareBroadcastListener の PendingIntent クラッシュ（32件/24ユーザー・最多） — commit ac57fc8
  • 原因: Assets/Plugins/NativeShare/Android/NativeShare.aar が2021年5月版で、Android 12（API 31）の PendingIntent FLAG_IMMUTABLE/MUTABLE 必須化に未対応
  • 対処: yasirkula/UnityNativeShare 最新版へ asset 一式を差し替え（tarball で一括取得）。.meta は維持し GUID 不変。C# 公開 API は互換（AddFile/SetText/SetUrl/Share）で呼び出し側無修正。新版は Android Share の JNI 引数が1つ増えており C#↔AAR はセット更新必須
• ② Firebase CheckDependencies 前の Analytics 早押しクラッシュ（23件/5ユーザー） — commit b53d8da
  • 原因: 起動直後（CheckAndFixDependenciesAsync 完了前）に HomeScene.GoEvent から FirebaseAnalytics.LogEvent を呼ぶと ThrowIfCheckDependenciesRunning 例外。準備完了フラグが無かった
  • 対処: 安全ラッパー AnalyticsUtil（Ready フラグ、未準備時は黙って捨てる）を新設。依存解決成功時に Ready=true。HomeScene と EventAppOpen の LogEvent をラッパー経由に。アクティブな危険呼び出しは HomeScene:387 の1箇所のみ（他はコメントアウト済）
• ③ QueryProductDetails ServiceUnavailable（2件/1ユーザー）は対応見送りと判断
  • FATAL 表記だが実態は Unity IAP 内部が投げる一過性の Play 課金エラー（GoogleBillingResponseCode: ServiceUnavailable、ローエンド端末/Android 9）。ReportUncaughtExceptionsAsFatal=true 設定で fatal 計上されているだけ。うちのコード起因ではなく件数も極小のため監視枠

気づき:

• Crashlytics の FATAL は「未捕捉 C# 例外を全部 fatal 扱い」設定の影響で、外部要因・一過性のものも混ざる。blame owner（DEVELOPER/PLATFORM/THIRD_PARTY）と processState で実害を切り分ける
• ネットワークが不安定で GitHub/CodeCommit が Connection reset を頻発 → 個別 curl はリトライ、リポ取得は tarball 一括が安定。push もリトライで通る

次回やること:

• Unity 検証（後日）: コンパイル確認＋実機テスト3点 — SE クラッシュ導線（広告→ホーム戻り→バックグラウンド）/ NativeShare 共有 / Analytics 早押し
• 次回アップデートで今回の修正（SE / NativeShare / Analytics）をまとめて iOS・Android 配信

---

2026-06-26

iOS 1.3.2 リリース完了（SE.get_Instance NRE 修正同梱）

やったこと:

• iOS 1.3.2 を本番リリース完了（SE.get_Instance NRE 対策 fbdc9a9 + バージョン更新 1bdb1c7 を同梱）。Android は今回見送り、次回に回す
• バージョン更新: bundleVersion 1.3.1→1.3.2（iOS/Android 共通）、iOS buildNumber 1.3.2、AndroidBundleVersionCode 21→22（commit 1bdb1c7、CodeCommit push 済）
• iOS 最多クラッシュをパブリッシャー（トムソン）へ報告（規模・原因・対応・1.3.2 同梱予定を共有、送付済）
• git タグ: iOS1.3.2（annotated、→1bdb1c7）を作成し CodeCommit へ push

次回やること:

• リリース後の Crashlytics 監視: SE.get_Instance の event 減少確認＋ NRE が SE.Play/PlayCollectTap 側へ移動していないか
• Android のクラッシュ対応（未着手）: NativeShareBroadcastListener の PendingIntent FLAG（32件/24ユーザー・最多）/ Firebase CheckDependencies 前呼び出し（23件/5ユーザー）。次回 Android リリース（versionCode 22 起点）に同梱検討

---

2026-06-25

Crashlytics 確認 → iOS 最多クラッシュ SE.get_Instance の根本対策（gods-talk 2ラウンド）

やったこと:

• iOS/Android 両 Crashlytics を確認（Firebase MCP、直近30日・全 1.3.1）。App ID は MCP で取得（iOS=...ios:28d6aa2ca414611e336ed4 / Android=...android:d49cb150481659df336ed4）
  • iOS: SE - get_Instance（NullReferenceException）が突出。815 events / 368 impacted users で iOS クラッシュの実質全量。他は各1〜3件（AnswerRegion NRE、意図的テストクラッシュ、GoogleMobileAds EXC_BAD_ACCESS、SceneManager UnloadSceneAsync）
  • Android: 件数少なめで分散。最多 NativeShareBroadcastListener.Initialize（S+ の PendingIntent に FLAG_IMMUTABLE/MUTABLE 未指定、32件/24ユーザー＝yasirkula NativeShare プラグインが古い）、次点 Firebase CheckDependencies 前呼び出し（23件/5ユーザー）、QueryProductDetails ServiceUnavailable（2件＝IAP絡み要観測）、libc SIGQUIT、ANR×2
• iOS issue にメモ付与（Crashlytics note、自由タグ機能がないため note で）。原因と対処方針を記録
• 真因特定: サンプルイベントのスタックは get_Instance (SE) → OnDisable (FinishScene)、processState: BACKGROUND、直前 breadcrumb は AppLovin 動画広告表示。FinishScene.OnDisable の null ガードは既存（commit cb2cb59）だが、NRE は呼び出し側でなく SE.Instance ゲッター内部で発生。終了/破棄フェーズに FindObjectOfType/DontDestroyOnLoad を呼ぶのが不正で、ガードをすり抜けていた
• 修正（commit fbdc9a9、CodeCommit Unity リポ）: SE.Current（探索しない既存参照プロパティ）を新設し FinishScene.OnDisable を Current 化＝teardown 経路から探索 API を物理排除。OnDestroy は instance=null に留め永久 null 化を回避。[RuntimeInitializeOnLoadMethod] で静的リセット。_isQuitting は OnApplicationQuit の補助ガードとして残置。Debug.LogError 削除
• gods-talk を2ラウンド実施（topic=se-teardown-nre-fix）。R1 で「_isQuitting は立つ順序依存で全消し保証は弱い→破棄系から lazy getter を呼ばない API 分離を」を受けて Current 化に強化。R2 で「OnEnable まで Current にすると初回捕捉前に ForceEnable を取りこぼす」を受け OnEnable のみ Instance に戻した
• git タグ整備: リリース済み状態を確定。Android1.3.1（→66f6c22）を新規作成し CodeCommit へ push（既存 iOS1.3.1 はそのまま）

詰まったこと / 気づき:

• Crashlytics の「タグ付け」依頼は当初 note と解釈→実際は git tag の意。命名規則は iOS1.3.1/Android1.2.6 のプラットフォーム別 lightweight
• _isQuitting 単独だと終了コールバックの実行順序に依存して残存リスク。「終了フラグ」より「探索しない参照専用 API」の方が確実という設計上の学び

次回やること:

• 修正版リリース後の Crashlytics 監視: 同 issue の event 減少確認＋ NRE が SE.Play/SE.PlayCollectTap 呼び出し側へ移動していないか（gods-talk 指摘の medium ③ 残リスク）
• 将来の小改善候補: SE.PlayIfAvailable(Type) の static safe wrapper 化（終了フェーズ NRE の再発面を狭める）。Android NativeShare プラグイン更新（PendingIntent 問題）

---

Android 1.3.1（versionCode 21）リリース完了 — 課金初期化ハングの真因究明と修正

やったこと:

• iOS リリース完了を受けて Android のテスト→リリースに着手。memory の「Android版未着手」は古く、実際は 6/10 時点で iOS/Android 両マネージャとも Billing 8 移行済みと確認
• Android 課金が初期化で無限ハングする問題が発生（内部テスト実機）。ログは INVP - IAP初期化開始... の繰り返しで停止
• 真因究明: R8/ProGuard 難読化が Google Play billing クラスを削除していた。リリースは難読化ON、Unity IAP は billing を IL2CPP から JNI(文字列)経由で呼ぶため R8 が「未使用」と誤判定 → com.android.billingclient.** を削除 → 実行時 ClassNotFoundException: PurchasesUpdatedListener → StoreController 例外 → 初期化未完了
  • 誤った第一仮説（billing 依存が build に無い→mainTemplate.gradle 手動追記）は外れ。billing 依存は IAP の自動注入（IAPAndroidDependencies のビルド時コールバック）で正常に入っており AAR も gradle キャッシュに DL 済だった。手動追記は revert
  • AAB の dex を grep して検証（修正前 PurchasesUpdatedListener=0、修正後=2、billingclient 総数 37→220）。Play に上げる前にローカルで成否判定できた
• 修正: Assets/Plugins/Android/proguard-user.txt（空だった）に billing の keep ルール追加（commit 29c9b10）
• 起動時 versionCode ログを追加（InitializeOnceOnStartup.LogAppVersion()、Android=PackageManager JNI）。実機で最新ビルド同一性を即確認。実際これで「新アカウントに本番v17が入っていた」事故を検知できた
• 実機で全課金フロー検証（versionCode 21, Play 内部テスト経由）: 初期化完了 / 3商品取得 / 既存サブスク復元 / 非課金判定 / 新規購入→OnPurchasePending→OnPurchaseConfirmed(acknowledge済) / 購入後の再起動復元。テスト後にテストサブスクは注文管理から払い戻し済
• keystore 正規化: ProjectSettings の参照を Downloads の派生コピーから Dropbox 正規パスへ修正（鍵は同一md5、署名結果不変、commit caa1e6b）。keystore 実体をバックアップに追加
• 取り残し変更の整理: 課金修正コミット時に避けたビルド/エディタ副産物を整理（Paywall2シーンの事故的再シリアライズ=revert・崩れなし確認、addressables bin=revert、FirebaseCrashlytics.androidlib=追跡追加 commit 66f6c22）
• Android 1.3.1（versionCode 21）を本番リリース → 審査通過・公開

決めたこと（DECISIONS.md にも転記）:

1. 難読化(R8)下で Unity IAP の Google Play billing クラスを keep する（proguard-user.txt に常設・削除禁止）
2. 署名 keystore は git 管理せず Dropbox 正規保管＋バックアップで管理（git管理は不適切と確認）

詰まったこと / 気づき:

• Android 課金テストはサイドロード不可（ローカル署名が Play App Signing 鍵と不一致 → INSTALL_FAILED_UPDATE_INCOMPATIBLE）。必ず Play 内部テスト経由でインストール
• 新テストアカウントを内部テスターに追加＋オプトインしないと、Play が本番版(v17・旧コード)を配信し誤テストになる（versionCode ログと旧 Billing 文字列で発覚）
• 実機の端末時計が約8日遅れており adb ログは 06-17 表記だが実日付は 06-25

次回やること:

• 段階リリースなら%引き上げ、Crashlytics(本番)と GA4 in_app_purchase をウォッチ（L-004）
• 買い切りlifetime購入の所有判定・UMP(EEA)同意フォームは未確認だが、コード共有/低リスクのため You 判断でスキップ

---

2026-06-10

18:50 - 次回アプデ実装（#1〜#4・#6・HTTPS化）+ Unity本体クローン二重化の解消

やったこと:

• 【重要】Unity 本体クローン二重化の発見と解消
  • IAP 移行のパッケージ解決確認中に、Unity で開いていたのが ~/UnityProjects/VisionTraining1（別の作業コピー）で、Claude が編集していた ~/cdev/.../vision-training1-unity（正クローン）と別物だと判明
  • 調査の結果、~/UnityProjects/VisionTraining1 に2026-03リリースの Android 課金実装が未コミットでしか存在しないことが発覚（PurchasingManagerForAndroid.cs + iOS/Android の #if 分岐を12+ファイルに配線、署名鍵 KeystorePasswordSetter.cs 含む）。配信中 Android 版のソースがそこにしか無い危険な状態
  • origin の履歴は filter-repo 書き換え済みで UnityProjects とは分岐 → UnityProjects から push すると force 必須＋軽量化が巻き戻る、と判明。安全な経路として「意味あるソースだけ cdev に移植 → origin に push」を選択
  • 移植実施（commit b51d1b2 + 4ce4ac9）。署名鍵は秘密のため gitignore + ~/ichirokisanuki/visionworkout-backups/keystore-setter-2026-06-10/ にバックアップ。UnityProjects は You が中身確認後に手動削除予定（移植済みで安全）
• #1 Unity IAP 5.1.2 移行（Billing 8.0.0）: iOS=PurchasingManager.cs / Android=PurchasingManagerForAndroid.cs を v5（StoreController + イベント + エンタイトルメントのローカルキャッシュ）に全面書き換え。公開API互換で呼び出し元12+ファイル無改修。EDM4U Force Resolve 済（commit 98ab5dc）
• #2 Crashlytics SDK 13.4.0 導入: InitializeOnceOnStartup で ReportUncaughtExceptionsAsFatal=true（commit 1475981）
• #3 PrivacyInfo.xcprivacy: XcodeProjectUpdater.addPrivacyManifest() で iOS ビルド時に本体ターゲットへ生成、Required Reason API 4種申告（commit 42bc7a0）
• #4 Info.plist: NSLocationWhenInUseUsageDescription（位置情報未使用と確認）を削除（同 42bc7a0）
• 規約リンク HTTPS 化: アプリ内13箇所の http→https（サーバ側は既に対応済を確認、commit 94edc31）
• #6 UMP コンセント実装: ConsentInformation.Update→LoadAndShowConsentFormIfRequired→CanRequestAds() で AdMob 初期化をゲート、拒否時は非パーソナライズ広告（commit eb6981f）
• #5 disclaimer: 今回パス（医療 disclaimer、UI/I2 作業。Paywall2 の footerMessageGO 流用が有力と整理のみ）

決めたこと（DECISIONS.md にも転記）:

1. クローン正規化: 配信中 Android ソースは UnityProjects から push せず、意味あるソースを cdev に移植して origin に乗せる。今後は cdev クローン1本に統一
2. #4 位置情報説明文は削除（実態未使用のため）。#5 disclaimer は今回見送り

詰まったこと / 気づき:

• IAP 5.x は API が大きく刷新（コールバック→イベント、エンタイトルメント非同期）。同期 getter 維持のため CheckEntitlement 結果をローカルキャッシュする設計で吸収
• 課金が iOS/Android で別マネージャ・別商品ID（visiontraining.* / vw.android.gen2.*）だったため、移行は両方必要だった
• Crashlytics import 直後に EDM4U の GooglePlayServices CS0246 が一瞬出たが import 処理中の一過性で解決済み
• すべて Editor コンパイル通過のみ。実機テスト（課金 Restore / クラッシュ受信 / UMP フォーム / xcprivacy 生成）は未実施

次回やること:

• You による実機検証フェーズ（課金購入/復元・テストクラッシュ・欧州IP相当のUMP・iOSビルドでxcprivacy）
• 問題なければ iOS 申請。#5 disclaimer は必要になったら footer 流用で実装

---

2026-06-03

14:00 - 提案書 v3 完成（S-001 を 3 分割、S-002 リパッケージ、全 16 件のステータス確定）

やったこと:

• アプリオーナーが株式会社トムソン、You は提案者・実装者（提案 → 承認 → 実装 → 申請 → リリース）という役割構造を確認、memory の project-thomsons に追記
• 提案書のフォーマットを HTML（既存の 眼球トレ売上推移.html / GA4 分析.html と同じスタイル）に確定
• Codex に「短期 / 中長期でやるべき対応」をゼロベースで検討してもらう gods-talk 依頼書 vision-training-update-proposals-001-issue.md を作成
• Codex から 13 件の指摘を含む vision-training-update-proposals-001-feedback.md を受け取り、内容を整理（特に「メディカルカテゴリ訴求リスク」「Android 16KB page size」「Billing Library サンセット」「macOS / visionOS 対応」等の盲点を発見）
• 眼球トレ提案書を v2 → v3 に更新（カードベース、優先度別バッジ、出典バッジ、トムソンコメント欄付き）
• 規約・提出要件監査の旧 S-001 を 4 項目に分けて掘り下げ:
  • Android 16 KB page size: ✅ 対応済み（You 確認）→ 除外
  • Google Play Billing Library: Unity IAP 4.12.2 内包の Billing 6.2.1 は 2025-08-31 サンセット超過、Unity IAP 5.0.x（Billing 8.0.0）へフルアップグレードに決定
  • Apple メディカル訴求: 利用規約の disclaimer は OK だが HTTP リンク + 更新日なし、アプリ内 disclaimer 無し
  • プライバシー / 広告ターゲティング: UMP SDK は入ってるが実装が見当たらない、PrivacyInfo.xcprivacy 独自版なし、NSLocationWhenInUseUsageDescription が雑
• Google Play Health apps declaration: ✅ Play Console で提出済み確認（You 確認、Play Console アクセス可能と判明）
• S-001 を 3 タスクに分割: S-001a (Billing 8) / S-001b (Apple メディカル訴求) / S-001c (UMP 実装)
• S-002 を「監視基盤セットアップ + 軽量メンテ」にリパッケージ:
  • 当初は「Crashlytics 上位クラッシュの修正」を含める案だったが、調査で Firebase Crashlytics SDK が未導入と判明（過去クラッシュデータ無し）
  • 内容を Crashlytics SDK 導入 + PrivacyInfo.xcprivacy 作成 + Info.plist 文言修正に変更
• S/L 全 16 件のステータスを You と一緒に確定
  • アクティブ 7 件: S-001a / S-001b / S-001c / S-002 / S-006 / L-004 / L-005
  • 保留 8 件: S-003 / S-004 / S-005 / L-001 / L-002 / L-003 / L-006 / L-007
  • 却下 1 件: L-008（macOS / visionOS 品質確認、代替案「対応表示を外す」を残置）

決めたこと（DECISIONS.md にも転記）:

1. 役割確定: アプリオーナーはトムソン、You は提案者・実装者
2. 提案書フォーマットは HTML（既存ダッシュボード群と統一）
3. S-001（規約・提出要件監査）を S-001a/b/c に分割
4. S-002 を「監視基盤セットアップ + 軽量メンテ」にリパッケージ
5. Billing Library 移行: Unity IAP 4.13 ではなく 5.0.x（Billing 8）へフルアップグレード（4.13 で繋ぐと残り 2 ヶ月で再移行が必要、二度手間回避）

詰まったこと / 気づき:

• 提案書フォーマットを「Google Sheets vs CSV vs HTML」で迷い、最終的に既存 HTML 群との一貫性で HTML に統一
• Codex の指摘の中で「規約・提出要件監査」が最大の盲点。特に Billing Library 6 が既にサンセット超過していることに気付けたのは大きい
• App Store の RSS フィードが機能していない（entry キーが返ってこない）→ 自前レビュー監視 Phase1（L-005 の前提）は再設計が必要
• Firebase MCP に Crashlytics 用のデータ取得ツールが無い（ガイドのみ）→ Crashlytics データを Claude から直接見る方法は現状なし
• 戦略 B 関連（NeuroTracker 体験化 / Paywall 整理 / Remote Config / サブスク継続価値 / 追加値上げ）はすべて You の方針で保留に。「現状の価格設計を尊重して、まず戦略 A（iOS 更新再開）の効果を見る」が一貫した姿勢

次回やること:

• アクティブ 7 件のうち実装着手するもの（おそらく S-001a / S-002 から）の具体的なリリース計画を立てる
• 必要なら「対応プラットフォーム表示を iOS/Android のみに絞る」（L-008 代替案）を S-006 と同時にやる
• 提案書 v3 をトムソンに提出するタイミング・方法を別途検討
• 関連メモリ: [[project-thomsons]], [[project-tooling-options]], [[project-sales-strategy-wip]]

---

2026-06-02

18:00 - アプリ内部構造の共有 + 運用ツール整備の選択肢整理

やったこと:

• iOS の Paywall (Paywall2AdditiveScene) のスクショを共有してもらい分析
  • UI 自体はサブスク誘導が比較的良い設計（年プランハイライト + おすすめバッジ、3日間無料トライアル、月額換算表示）
  • にもかかわらず買い切り 96% に流れる原因は価格設計側にある可能性（買い切り ¥3,400 ÷ 年プラン ¥1,800 = 1.89 年で損益分岐、長期使う気のあるユーザーは買い切りを選ぶ合理性）
• App Store ページから情報取得（WebFetch 経由）
  • カテゴリ: メディカル / 評価: 4.6 (4,945 件) / visionOS 1.0 対応 / アプリサイズ 131.7MB
  • デベロッパー: THOMSON Inc.、同シリーズアプリ: THE 視力回復・THE 周辺視野トレ・脳トレ覚醒
  • 1.2.6 (2025/12/24) でチュートリアル機能追加（Android 流入急増と同時期）
  • 価格表示「¥1,500〜¥3,400」← 旧買い切り ¥1,500 が下限として残っている
• Unity プロジェクトの構造を調査
  • メインゲーム 7 種: タイトル直下 4 大（Teleportation / Zigzag / Tile / 3D）+ サブ階層 3 種（PeripheralVision / FlashMemoryTest / NeuroTracker）
  • Scene 多数発見: HomeScene（現役）/ TitleScene（旧、不使用）/ PaywallAdditiveScene（旧）/ Paywall2AdditiveScene（現役）/ TutorialAdditiveScene / TrainingPointScene（不使用）/ RecommendedAppsScene / CalendarScene 等
• PurchasingManager.cs から課金商品 5 個の正体確定
  • 第1世代: jp.thomsons.visiontraining.noads(旧買い切り¥1,500) + .membership.1year(旧年サブ¥840)
  • 第2世代: jp.thomsons.visiontraining.gen2.pro(新買い切り¥3,400) + .membership.gen2.1year(新年サブ¥1,800) + .membership.gen2.3months(新3ヶ月¥900)
  • 旧商品もアプリコード上で AddProduct されたまま、App Store Connect 側も Available 状態と推定
• You への質問形式で確認
  • NeuroTracker (MOT スキル) が GA4 で 1% しか使われていない理由 = Pro 限定
  • NeuroTracker を Pro 限定にしたのは「価格帯を上げるための差別化」の歴史的経緯
  • Paywall2 が現役、PaywallAdditiveScene と TitleScene と TrainingPointScene は不使用
  • prVideoGO (自社広告) は TitleScene 内なので今は表示されていない
  • 広告なしを体験できるリワード広告等の動線は無い
• 運用ツール整備の構想を別角度で議論
  • You がピンと来たもの 3 つ: Firebase Remote Config / App Store Connect API + Google Play Developer API / 自前レビュー監視
  • レビュー監視は App Store RSS なら認証不要で自前実装可能
  • Firebase Remote Config の現状確認: テンプレートは空 {} で完全未着手、Unity 側も Firebase Remote Config SDK 未導入

決めたこと（DECISIONS.md にも転記）:

1. 価格変更（買い切り値上げ）は現時点で実行しない方針
2. iOS 1.2.9 は「軽量バグ修正のみ」、その他の変更は送り（リリース頻度回復が主目的）
3. 運用ツール整備は「戦略 A 実行 + 自前レビュー監視 + トムソン依頼文準備」から段階的に（一気に全部やらない）

詰まったこと / 気づき:

• Claude が GA4 分析結果から「買い切り値上げが最優先」と前のめりに推した結果、You から「価格上げる前提で進めたくない」と明確な反対
• iOS 1.2.9 の具体的なバグ TODO を即詰めようとしたが、You は「今はコンテキストを Claude に共有してる段階だから地に足つけて進めたい」とペース調整を希望
• → memory に feedback_pace_and_scope を新規追加（次セッション以降の Claude の振る舞いを調整）
• 戦略の核心が明確化: 「Pro 機能の体験動線がない」ことがサブスク転換 0.12% の原因の核
  • 価格上げのために NeuroTracker を Pro 限定にしたが、未課金ユーザーは触れないので価値が伝わらず買い切り選択に流れる構造

次回やること:

• 方針判断（迷い中、急がない）: 自前レビュー監視 Phase1 着手 / トムソン依頼文準備 / iOS 1.2.9 の具体内容詰め / Pro 機能体験動線の設計議論 のどれから着手するか
• 関連メモリ: [[project-tooling-options]], [[feedback-pace-and-scope]], [[project-sales-strategy-wip]]

---

14:00 - GA4 Data API 接続完成 + 売上戦略分析の核心 4 件特定

やったこと:

• Firebase 公式 MCP を接続（.mcp.json に project scope で登録、Firebase CLI 15.19.0 を Homebrew でインストール）
  • 用途確認の結果、Analytics 集計データは Firebase MCP の範囲外と判明
• GA4 Data API ルートに切り替え。最初はサービスアカウント方式で進めようとしたが、GA4 の追加 UI が *.iam.gserviceaccount.com 形式のメールアドレスを「メールアドレスを入力してください」とバリデーションで拒否する事象に遭遇（メール通知チェック関係なし、回避不能）
• 公式 analytics-mcp（Python、PyPI 配布）に方針転換
  • pipx / gcloud CLI を Homebrew でインストール
  • Google Cloud で OAuth デスクトップクライアント作成（~/.config/gcp/oauth-client.json に配置）
  • OAuth 同意画面の「対象」セクションに ichirokisanuki@gmail.com をテストユーザー追加（最初忘れて access_denied エラー）
  • gcloud auth application-default login で ADC 取得（~/.config/gcloud/application_default_credentials.json）
  • .mcp.json に analytics-mcp を追加
• トムソンに GA4 Viewer 権限の依頼テンプレを作成 → ichirokisanuki@gmail.com を GA4 プロパティ 271861292 に Viewer 追加してもらい完了
• 売上分析ダッシュボード 眼球トレ売上推移.html を作成（前回セッション末で配置済み、今回 GA4 で裏付け）
• GA4 から以下を並列取得して分析:
  • 月次 DAU / 新規 / 全ユーザー（過去 365 日）
  • OS別 月次 active / new
  • 国別 active / new（過去 30 日 Top 30）
  • イベント別 件数 / ユーザー数（過去 365 日 Top 50）
  • アプリバージョン × 月 × OS 別 active / new
  • 課金イベント月次推移（in_app_purchase, app_store_subscription_convert, app_store_subscription_renew）
• 戦略議論のための GA4 分析ダッシュボード 眼球トレGA4分析.html を作成（Chart.js, KPI / Finding / 戦略アクションプランの3層構成）

決めたこと（DECISIONS.md にも転記）:

1. GA4 データ取得は公式 analytics-mcp（OAuth + ADC）ベースに統一。サービスアカウント方式は放棄
2. 戦略アクションプランの優先順位を確定（A: iOS 更新再開, B: iOS サブスク UI, C: Android 課金最適化, D: 海外現地化）

詰まったこと / 気づき:

• GA4 UI のサービスアカウント拒否は調査しても明確な公式情報なし。OAuth ルートに切り替えて完全回避（公式 analytics-mcp がそもそも OAuth ベース推奨だったので結果オーライ）
• OAuth クライアント作成時の「テストユーザー追加」は必須。漏れると access_denied で詰まる
• gcloud auth application-default login は対話的（ブラウザ）。background 起動時は完了まで画面を閉じないよう注意
• ネスト git で git remote set-url を cd 漏れで実行する事故が再発しないよう、git -C 厳守を Memory に再強化済み（前回事故と同種）

今回の分析で判明した「戦略の核心」4 件:

1. 2025/10 売上 4 倍化は 100% ARPU アップが要因（アクティブ -1.5%, 新規 -2.3% だけで売上 +178%）。価格弾力性が極めて低く、もう一段の値上げ余地あり
2. Android 2025/12 急成長の正体は大型バージョンアップ（1.0.4 で 1 年放置 → iOS と同期した 1.2.5 に。ASO ランキングシグナル復活 → オーガニック流入急増）。2026/03 の 1.3.0 で課金統合
3. iOS 流入 -27% 減の真の原因は 1.2.8 で 4 ヶ月更新停滞。Android 1.3.0 開発リソース集中の副作用。「更新で流入回復」効果は Android で実証済なので iOS でも再現可能
4. iOS 課金者の 96.4% は買い切り、サブスクは事実上機能していない。サブスク UI 改善で ARR ベース月 200〜300 万円規模の積み上げポテンシャル

次回やること:

• iOS の課金画面 UI を実機スクショで確認 → サブスク誘導の弱点を特定
• iOS 1.2.9 or 1.3.0 のリリース内容を詰める（軽量で何でも OK の方針）
• 関連メモリ: [[project-firebase]], [[project-thomsons]], [[project-sales-strategy-wip]]

---

2026-05-25

17:00 - プロジェクト立ち上げ + Unity リポ統合・履歴整理

やったこと:

• CLAUDE.md にプロジェクト概要を追記（iOS/Android アプリ「THE眼球トレーニング」の運用リポであることを明文化）
• Unity 本体プロジェクト vision-training1-unity/ を operation 直下に nested clone（別管理、AWS CodeCommit ap-northeast-1）
• operation 側 .gitignore に vision-training1-unity/ を追加して git レベルで分離
• Unity Editor 起動時の Rosetta 警告（"Intel プロセッサ用アプリの対応は終了します"）の原因を特定
  • Unity 本体 (2022.3.62f2) や Firebase の .bundle は arm64 ネイティブ対応済み
  • 原因は com.unity.collab-proxy@2.7.1 同梱の liblz4Plastic.dylib が x86_64 only
  • Packages/manifest.json から com.unity.collab-proxy を削除 → Unity 再起動で警告解消
  • CodeCommit に commit & push（remote URL に thomson-ik プロファイル埋め込み）
• Unity リポの履歴ダイエットを実施
  • 元 .gitignore は Library/, Builds/, Build/ の3行のみで Logs/UserSettings/.DS_Store/.csproj/.sln 等が無防備だった
  • Unity 公式準拠の .gitignore に整備し、現 HEAD で tracked になっていた Logs/UserSettings/Builds/.DS_Store + 30 個の .DS_Store を git rm --cached で untrack
  • git filter-repo で履歴から Library/ Builds/ Temp/ obj/ Logs/ UserSettings/ *.csproj *.sln *.aab *.apk *.unitypackage *.app を完全削除
  • .git 2.6GB → 305MB（88% 削減）
  • フル clone のバックアップを ~/ichirokisanuki/visionworkout-backups/vision-training1-unity.backup-2026-05-25/ に保管（3.6GB）
  • CodeCommit に force push（共同開発者なし、ユーザー承認済み）
• operation 側コミット & GitHub push
  • SSH 認証失敗（ssh-agent has no identities）のため origin を SSH → HTTPS に切り替え（gh の credential helper を活用）
• .devnotes/ 既存ファイルに今日の活動を記録（本ファイル含む）

詰まったこと / 気づき:

• ネスト git 構成（operation × Unity）で git remote set-url を cd 漏れで実行し、operation 側 origin を Unity リポ URL に誤上書き事故 → 即復旧。以後 git -C <絶対パス> 厳守をメモリに記録
• 公開済みバージョン（1.0.3 / 1.0.4 等）の mapping.txt / symbols.zip は履歴から消滅。クラッシュ逆引き不可（バックアップにのみ存在）。ユーザー「消えても大丈夫」確認済み

次回やること:

• 運用業務の方向性決め（分析・集計・告知物・ASO 等のどれから着手するか未定）

visionworkout-operation

概要

（記入予定）

セットアップ

（記入予定）

使い方

（記入予定）