← 一覧に戻る

visionworkout-operation

GitHub ↗ HTML 最終push: 2026/6/10 18:53

WIP(現在進行中)

Work In Progress

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

現在の状況

  • 次回アプデのコード実装はほぼ完了次回アプデ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 作業。Paywall2footerMessageGO 流用が有力)
  • 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 残置
  • 詰まっていること: なし(コードは完了、残りは実機検証のみ)

過去のWIPアーカイブ

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

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 にどこから着手したいか確認してから優先順を決める
  • 詰まっていること: 特になし

ROADMAP(計画)

ロードマップ

今週

  • 実機検証フェーズ(You): 課金の購入/復元(既存購入者Restore最重要)・テストクラッシュ受信・UMP同意フォーム(欧州IP相当)・iOSビルドでxcprivacy生成 を確認 → 問題なければ iOS 申請
  • 提案書 v3(眼球トレ提案書.html)をトムソンに提出するタイミング・方法を検討(メール添付 / リンク共有 / 対面)
  • 提出順序の決定: アクティブ 7 件をまとめて提示するか、緊急度順(S-001a 単体 → 他)に分けるか

今月

  • S-001a: Unity IAP 5.1.x へフルアップグレード(Billing 8 対応、iOS/Android 両マネージャ。2026-06-10 実装・push 済、実機テスト待ち)
  • 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 のみに絞る」も同時実施)

今四半期

  • L-004: Android 1.3.0 課金状況の継続観測 + 最適化(GA4 で定期チェック)
  • 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 + 課金ファネル計測の導入
  • 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)

DECISIONS(意思決定)

意思決定記録

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


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 側 .gitignorevision-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 廃止後も動作可能。

DEVLOG(作業ログ)

開発日誌

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


2026-06-10

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

やったこと:

  • 【重要】Unity 本体クローン二重化の発見と解消
    • IAP 移行のパッケージ解決確認中に、Unity で開いていたのが ~/UnityProjects/VisionTraining1(別の作業コピー)で、Claude が編集していた ~/cdev/.../vision-training1-unity(正クローン)と別物だと判明
    • 調査の結果、~/UnityProjects/VisionTraining12026-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 導入: InitializeOnceOnStartupReportUncaughtExceptionsAsFatal=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.UpdateLoadAndShowConsentFormIfRequiredCanRequestAds() で AdMob 初期化をゲート、拒否時は非パーソナライズ広告(commit eb6981f
  • #5 disclaimer: 今回パス(医療 disclaimer、UI/I2 作業。Paywall2footerMessageGO 流用が有力と整理のみ)

決めたこと(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.jsonanalytics-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-urlcd 漏れで実行する事故が再発しないよう、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 側 .gitignorevision-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 リポの履歴ダイエットを実施
    • .gitignoreLibrary/, Builds/, Build/ の3行のみで Logs/UserSettings/.DS_Store/.csproj/.sln 等が無防備だった
    • Unity 公式準拠の .gitignore に整備し、現 HEAD で tracked になっていた Logs/UserSettings/Builds/.DS_Store + 30 個の .DS_Storegit 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-urlcd 漏れで実行し、operation 側 origin を Unity リポ URL に誤上書き事故 → 即復旧。以後 git -C <絶対パス> 厳守をメモリに記録
  • 公開済みバージョン(1.0.3 / 1.0.4 等)の mapping.txt / symbols.zip は履歴から消滅。クラッシュ逆引き不可(バックアップにのみ存在)。ユーザー「消えても大丈夫」確認済み

次回やること:

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

最近のコミット

README

visionworkout-operation

概要

(記入予定)

セットアップ

(記入予定)

使い方

(記入予定)