守 vs K3 実力比較
第2R・第3R' 比較レポート

ゴルフ上達支援アプリ 設計書 — 「マイカルテ」（仮称）

1. 現状と課題の整理

練習記録から読み取れる現状・課題は以下の5点。

1. 前後半のスコア差が大きく、原因は技術ではなく体力・膝
   前半49に対し後半61（+12）。記録自身が「体力の限界（ガス欠）と、膝をかばったことによる数字」と分析している。技術練習よりも「体力・膝の状態とスコアの関係」を可視化することが上達の鍵になる。
2. 膝をかばうとスイングが崩れる、という明確な因果が見えている
   18番ホールの動画分析で「膝をかばうあまりインパクトでお腹の回転が止まり、手先で合わせてチーピン」と記録されている。膝コンディションはスコアの従属変数ではなく、ミスの直接原因として記録対象にすべき。
3. アプローチの慢性的ショート（ただし「成長の通過点」）
   「ひたすらショートした」が、手先で弾く癖を封印した正しいフォームの結果とされている。対策も既に明確（1番手大きいクラブを持つ）。あとは「どのクラブでどれだけ転がるか」の実測データを貯めれば解決に向かう。
4. スイングの軸「お腹の回転」と、守るべきチェックポイントが言語化済み
   「頭を残して、お腹でゆったり」「左つま先を10〜11時に開く」「フィニッシュで左かかとを浮かせる」など、守るべき型が文章で確立している。アプリはこれを毎回のリマインドとして再利用できる。
5. クラブへの愛着が強く、セッティングは確定済み
   中古ショップで1本ずつ集めたゼクシオ＋新ドライバー（QUANTUM MAX FAST 12.0度・R2、試打180ヤード）。クラブ探しは終わっており、アプリの役割は「今の相棒たちでどう続けるか」の記録に絞れる。

2. アプリのコンセプト

「膝と相棒（クラブ）に優しい、自分専用のゴルフカルテ」

狙い：スコアを追うアプリではなく、「膝の状態 × スイングの型 × スコア」を1セットで記録し、"のんびり長くゴルフを続けながら、気づいたら上手くなっている"状態を作る。記録のトーンも、依頼主が既に書いている「カルテ」の物語調をそのまま引き継ぐ。

3. 機能設計

4. データ設計

JSON（端末内保存）を基本とし、以下の4種のレコードで構成する。

Round（ラウンド）
  date, course, weather(雨/晴れ等), kneeBefore(1-3),
  holes: [ { no, par, score, missTags[], club, kneeFlag(かばった?) } ],
  kneeAfter(1-3), fatigueMemo, note

Practice（練習）
  date, theme, checkedItems[](お守りカードの項目), note

ApproachLog（アプローチ距離帳）
  date, club, targetDistance, result(short/just/over), memo

Club（相棒）
  name, type, loft, shaft, story(入手の思い出), active(使用中か)

Checklist（お守りカード・編集可能）
  items: [ "頭を残してお腹でゆったり", "左つま先10〜11時", "左かかとくるっ", "アプローチは1番手大きく" ]

ポイント：ミスは自由記述でなく missTags（チーピン／ショート／トップ等の固定タグ） にし、後で集計できる形にする。膝は入力負担を最小にするため3段階固定。

5. 画面・UX設計

スマホ縦持ち・片手操作前提。画面は4つに絞る。

1. ホーム：上段に「お守りカード」（今日意識すること）、下段に「ラウンド開始」「練習メモ」「距離帳に追加」の大きな3ボタン。膝の今日の調子を😊😐😣で1タップ記録。
2. ラウンドモード：1ホール1画面。スコアは数字を大きくタップ、ミスタグは候補チップから選択（チーピン・ショートは最上段に固定表示）。「膝かばった」トグルを常設。ホール送りで前後半は自動判定。カート待ち時間の10秒で入力完了できることを目標にする。
3. 距離帳：クラブ×距離帯のマトリクス表示。セルをタップすると結果（短/丁/長）を1タップ追記。「1番手大きく」の効果検証がここで見える。
4. ふりかえり：ハーフ別スコア推移の折れ線、膝の調子との重ね表示、チーピン・ショートの発生率推移、Markdown書き出しボタン。

操作の流れ（ラウンド日）：ホームで膝チェック → ラウンドモードでホールごと10秒入力 → 終了後に膝アフター＋一言メモ → 後日ふりかえり画面で確認、必要ならAIに貼ってカルテ化。

6. 技術構成

単一HTMLファイルのPWA（ローカル保存型） を提案する。

• 実装：HTML+CSS+JavaScript 1ファイル。データは端末のIndexedDB（またはlocalStorage）に保存。Service Workerでオフライン動作（練習場・コースは電波が不安定という前提の推測込み）。
• 配置：GitHub Pages等の無料静的ホスティングに置き、スマホの「ホーム画面に追加」でアプリ化。サーバー・DB・月額課金は一切不要。
• バックアップ：ふりかえり画面のJSON/Markdown書き出しを、手動でクラウドドライブ等に保存（自動同期は作らない）。
• 選定理由：①常時稼働サーバー不要・無料枠のみ、②1ファイルなのでAIアシスタントに全文を貼って「ここを直して」と頼める＝専業エンジニアでない依頼主が自力で維持できる、③壊れても静的ファイルの差し替えだけで復旧できる。
• 代替案として表計算アプリ運用も検討したが、ラウンド中の片手10秒入力に向かないため見送り（推測を含む判断）。

7. 継続の仕掛け

• 入力を「1ラウンド3分・1ホール10秒」に抑える：続かない最大要因は入力負担。タップのみ・自由記述は任意。
• カルテの物語調を成果物にする：書き出したMarkdownをAIに渡せば、今回の添付のような読み物になる。「記録＝あとで自分の物語になる」ことが最大の報酬設計。
• 上達指標はスコアそのものでなく次の4つ：
  1. 前後半スコア差（体力・膝マネジメントの指標。現状+12）
  2. チーピン発生率（お腹の回転が止まらなかったかの指標)
  3. アプローチのショート率（距離帳と1番手アップの効果測定）
  4. 膝の調子とラウンド後の悪化有無（「悪化させずに回れた回数」を勝ちとカウント）
• スコアが悪くても「膝を守って完走」「ショートしたが正しいフォーム」を記録上プラスに扱う。これは記録自身の価値観（ショートは成長の証）をそのまま指標化したもの。

8. 開発ステップ

• v0.1（最初の週末で作る最小版）：ラウンド記録（ホール別スコア＋ミスタグ2種：チーピン/ショート）＋膝の前後チェック＋お守りカード表示。保存はlocalStorage、書き出しはコピー用テキストのみ。
• v0.2：アプローチ距離帳、練習メモ、ハーフ別集計の表示。
• v0.3：ふりかえりグラフ（前後半差・ミス率の推移）、JSON書き出し／読み込み（機種変更対応）、Service Workerによる完全オフライン化。
• v0.4以降（任意）：クラブ棚（相棒カルテ）、スイング動画へのリンクメモ（動画分析の習慣がある前提の推測）、チェックリストの編集機能。

拡張の原則：「入力が増える機能より、見返したくなる機能を先に」。v0.1の記録が3ラウンド分貯まってから次を作ることで、実データに合わせて画面を直せる。

ゴルフ上達支援アプリ設計書（仮称：「お腹でゆったりカルテ」）

1. 現状と課題の整理

課題①：再現性の敵は「技術」ではなく「体力と膝」

• 根拠： 前半49／後半61（計110）。記録にも「体力の限界（ガス欠）と、膝をかばったことによる数字です。技術のせいでは決してありません」と明記。「頭を残して、お腹でゆったり」という良いスイングは既に確立されており、崩れる条件が体力・膝に集中している。

課題②：ミスの型は特定済みだが、発生条件が集計できる形になっていない

• 根拠： チーピン（左に巻く球）の原因は「お腹の回転が止まり、手先で合わせる」ことと、フィッティング時と18番ホールの2箇所で同じ分析がされている。一方で「雨で体が冷える」「膝に負担」「ガス欠」などの発生条件は文章内に散在し、後から傾向を見られる構造データになっていない。

課題③：アプローチのショートが「通過点」として進行中

• 根拠： 「ひたすらショートしたのは…正しいフォームで打てている成長の証（通過点）」。対策（1番手大きいクラブを持つ）も決定済み。移行が完了したかどうかを確認する記録手段がない。

課題④：クラブ・フィッティングの知見が文章に埋もれている

• 根拠： 試打データ（ロフト12.0度・R2シャフト・180ヤード）や「ドライバーだけ軽さに問題があり、他のゼクシオはそのまま使う」という結論は貴重だが、検索・更新できる台帳になっていない。

課題⑤：「膝に優しい3つの裏ワザ」の定着度を測る仕組みがない

• 根拠： つま先を10時〜11時に開く／フィニッシュでかかとを浮かす／アプローチは1番手上げる、の3項目が提示されているが、毎回実行できたかを追う手段がない。

2. アプリのコンセプト

「お腹でゆったり」を、膝に優しく、毎回再現するための自分専用カルテ。

スイング理論を教えるアプリではない。①体調・膝の状態、②ミスの発生条件、③3つの約束の実行状況、を1箇所に記録し続けることで、「崩れた理由を後から特定できる」「崩れる条件が揃った日に自分で気づける」状態を作る。蓄まった記録はAIアシスタントに渡して分析させる前提（依頼主がAIを日常的に使いこなすという前提条件より）。

3. 機能設計

作らない判断： アプリ内に高度な分析機能やコーチング機能は載せない。分析はエクスポート先のAIアシスタントの仕事とし、アプリは「記録と集計」に絞る（維持コストを下げるため）。

4. データ設計

サーバーなし・端末内保存（IndexedDB）を前提とした、1ラウンド1レコードの構造。

• rounds: id, date, course, weather（晴／曇／雨）, knee（良／普通／悪）, stamina（元気／普通／疲れ）, front9, back9, memo, created_at
• promises（roundに紐付）: round_id, key（toe_out／heel_up／club_up）, done（0〜3）
• shot_notes: id, round_id, hole, club, result_tag（chipin／short／nice／other）, note
• clubs: id, name, type, loft, shaft, trial_result, compatibility_memo, is_active
• practice_logs: id, date, theme, memo

初回入力の手間を減らすため、クラブ台帳には初期データとして「QUANTUM MAX FAST／12.0度／R2／試打で180ヤード・真っ直ぐ」「ゼクシオ各種（軽量・そのまま愛用）」を登録済みの状態で配布する。

5. 画面・UX設計

前提： スマホ片手・ラウンド中の短時間操作。雨のラウンド実績があるため、濡れた手でも押せる大きめのボタンとする。入力は「必須は前後半スコアのみ、あとは全部任意」に徹する。

• ホーム: 「⛳ ラウンドを始める」「📝 あとで記録」「📊 ふりかえり」の3ボタンのみ。
• ラウンド開始: 最初に3つの約束チェック画面が出る（ここが習慣化の要）。天候・膝・体力はワンタップ選択。
• ラウンド中: ショット気づきメモのみ（任意）。「クラブ選択→結果タグ→（任意で一言）」の3タップで完結。ホール毎のスコア入力は強制しない（後半ガス欠時には入力自体が負担になり、記録が途切れる原因になるため。これは記録の前後半差から導いた設計上の配慮）。
• ラウンド後: 前半/後半スコア→3つの約束の振り返り→フリーメモの順に3画面。3分で終わる。
• ふりかえり: スコア推移・前後半差・約束実行率・ミスタグ内訳。エクスポートボタンを常設。

6. 技術構成

提案： オフライン動作するPWA（単一HTML＋素のJavaScript＋IndexedDB）。ホスティングは無料の静的ホスティング（GitHub Pages等）か、ローカルファイル直開き。

選定理由：

• 前提条件の「月額課金・常時稼働サーバーなし」を満たす（静的ファイルのみ、データは端末内）。
• 依頼主はAIアシスタントを使いこなすため、開発はAIとのペアプロが前提。フレームワーク非依存の素のJS＋ビルド不要にすると、AIがコード全体を把握して改修でき、開発環境の維持も不要になる。個人が一人で維持する現実的な最小構成。
• データはJSONエクスポートで常に全量取り出せるため、AI分析への受け渡しと、端末紛失時のバックアップを同じ仕組みで兼ねられる。
• 却下案： ネイティブアプリはストア登録・開発環境の維持が個人運用では重い。代替案： スプレッドシート＋フォームのノーコード構成も有力だが、ラウンド中の3タップ操作とグラフ表示のUXを優先して自作PWAを第一候補とした（推測： 入力UXを妥協するとラウンド中の記録が続かないリスクが高い）。

7. 継続の仕掛け

• 入力ハードルを極限まで下げる: 必須入力は前後半スコアのみ。「記録は3分」を保証する。
• 習慣化トリガー: ラウンド開始時に必ず3つの約束チェックが表示される＝アプリを開く行為と約束の想起を一体化。
• 上達の測り方（スコア以外の指標を主役にする）:
  1. 前後半スコア差の縮小（記録の49→61というガス欠構造が、そのまま改善指標になる）
  2. 「チーピン」タグの発生率低下と、発生条件（雨・疲労・膝の悪い日）の特定
  3. 「ショート」タグの推移（アプローチ移行期の脱出確認）
  4. 3つの約束の実行率
• 週次AI振り返り: 週1回エクスポートしてAIアシスタントに傾向分析させる運用を定型化。アプリは数字を出し、意味づけはAIと会話しながら行う。

8. 開発ステップ

• v0.1（最小版・まずこれだけ）: ラウンド記録（日付・天候・膝・体力・前後半スコア・メモ）＋一覧＋JSONエクスポート。画面2枚・静的HTML 1本。AIとのペアプロで半日〜1日が目安。
• v0.2: 3つの約束チェック＋実行率集計（コンセプトの核なので最優先で追加）。
• v0.3: クラブ台帳（初期データ入り）。
• v0.4: ミス・気づきメモ＋タグ集計。
• v0.5: グラフ表示と、AI分析用エクスポート文のテンプレート整備。
• 練習記録・体調ログは、運用してみて「欲しい」と感じてから追加する（作りすぎない＝維持を続けられる）。

改訂方針書 — 「マイカルテ」設計改訂（第3R'）

1. 追加情報の読み解き

依頼主は「記録の価値は理解しているが、構造化された手入力を継続できる人ではない」ユーザーである。しかも(2)は「AIアシスタント相手への入力でも同様」と明言しており、入力先をアプリからチャットに変えるだけでは解決しない。さらに(3)(4)から、スコアという最重要データは既にスマートウォッチ側に存在し、プレー中にスマホを開く前提は一切成立しない。

崩れた前提

• 「カート待ちの10秒で1ホール入力」＝ラウンドモードの根幹。プレー中スマホ不使用で全壊。
• ミスタグ・「膝かばった」トグル・距離帳のその場追記など、プレー中タップ入力の全機能。
• 「入力を1ラウンド3分に抑えれば続く」という継続仮説。3分でも手入力なら続かない、が本人の自認。
• スコア入力機能そのもの。時計と二重管理になり、二重入力は本人が最も嫌う行為。

崩れていない前提

• カルテの物語調が最大の報酬である点。元の練習記録自体が物語調で存在しており、「読み物として見返す」価値は生きている。嫌いなのは"パチパチ入力"であって、記録の成果物ではない。
• 膝×スイングの型×スコアの因果構造、上達指標4つ（前後半差・チーピン率・ショート率・膝悪化有無）。
• お守りカード（入力ゼロ・閲覧のみ）とクラブ棚（入力は一度きり）。
• サーバーレス・無料・自力維持という技術方針。

推測として明記：手入力が嫌でも「話す」「時計の画面を撮って貼る」程度なら許容される可能性が高い。ここに入力経路を寄せる。

2. 変更方針の要約

3. 改訂設計

機能：中心機能は「ラウンド後インタビュー」。ラウンド当日か翌日に、AIアシスタントとの1回の会話で記録を完結させる。手順は①時計（またはHUAWEI Healthアプリ）のスコア画面のスクリーンショットを貼る（AIが画像から前半/後半/計を読み取る）、②AIが定型3問を聞く——「膝は前後でどうだった？」「一番印象に残ったミスは？」「アプローチはショートした？」——、③回答は音声入力推奨（推測：話すだけなら継続可能）。AIはこの会話から構造化JSONとカルテ文章（物語調）を同時に生成する。なおHUAWEI側のデータ自動連携の可否は未確認のため、設計はスクショと口頭報告のみに依存させる。

データ：Round レコードから holes[] を必須から外し、summary{front, back, total}＋missHighlights[]（会話から抽出した代表ミス1〜3件）＋kneeBefore/After＋karteText（生成された物語）に簡素化する。ApproachLog・Practice はレコード種として残すが、生成元は会話のみ。Club・Checklist は不変。

画面UX：4画面→2画面。①ホーム＝お守りカード（今日意識する型の表示と、インタビュー用プロンプトのコピーボタン）、②カルテ棚＝過去のカルテ一覧、前後半差・膝との重ね折れ線、ショート率推移。入力フォームは一切持たない。

技術構成：単一HTML PWA＋端末内保存の方針は維持するが、役割を「ビューア兼保管庫」に縮小。AI会話で生成したJSONブロックをカルテ棚に貼り付けて取り込む。手作業はこの「貼り付け1回」だけに絞る（推測：完成品を飾る作業なら"パチパチ入力"とは感じられない）。

4. 捨てる決断

削除するもの：ラウンドモード画面一式（1ホール1画面・ミスタグチップ・膝かばったトグル・10秒入力目標）、スコア入力機能、ホール単位データの必須化、距離帳マトリクスへのその場追記、練習メモの手入力欄。

成立する理由：元設計の価値は「膝×型×スコアの相関を物語として見返せること」であり、ホール単位の網羅データではない。上達指標4つは、時計由来のハーフ集計＋会話から拾う代表ミス・膝状態だけで算出または近似できる（チーピン率・ショート率は「発生回数の厳密値」から「言及された/されなかった」の粗い頻度に落ちるが、傾向把握には足りる）。網羅性を捨てて継続性を取る——記録が続かなければ相関もゼロである。

5. 改訂後の最小版（v0.1）

v0.1の主役はアプリではなくプロンプトである。作るのは次の3点。

1. インタビュー・プロンプトテンプレート：AIアシスタントに貼る定型文。「スコアのスクショを受け取り→3問聞き→JSON＋カルテ物語を出力する」まで指示済みのもの。
2. お守りカードHTML：閲覧のみ。「頭を残してお腹でゆったり」「左つま先10〜11時」「左かかとくるっ」「アプローチは1番手大きく」を表示し、上記テンプレートのコピーボタンを併設。
3. カルテ棚ページ（簡易版）：JSON貼り付けで取り込み、カルテ一覧と前後半差の表示のみ。保存はlocalStorage。

グラフ・距離帳集計・Service Workerはすべてv0.2以降へ後送り。判断基準は元設計の拡張原則を引き継ぎつつ一段強める——「入力が増える機能は作らない。話せば増える記録と、見返したくなる画面だけを作る」。3ラウンド分の会話ログが貯まった時点で、実際に会話から取れた項目に合わせてデータ項目とビューアを育てる。

改訂方針書：「お腹でゆったりカルテ」（第2R設計の改訂）

1. 追加情報の読み解き

依頼主は「記録が嫌いだが、無記録な人ではない」。 スコアは既にスマートウォッチに入力しており、添付のカルテ（AIとの対話から生まれた体裁の文章）が存在する時点で、会話経由の記録には実績がある。嫌いなのは「記録」そのものではなく「手打ち入力（パチパチ）」という入力行為。つまりこのユーザーは、自分に合った道具には自然に乗る人。設計の方向を「新しい入力行為を習慣化させる」から「既にある行為（時計入力・AIと話す）の出口にアプリを置く」へ転換すべきと読む。

崩れた前提：

• 「ラウンド中のスマホ利用を想定」（お題文の前提条件）→「プレイ中はほとんど開かない」で崩壊。ラウンド中UI全般の根拠が消えた。なお「スマホで使える」こと自体は維持できる（使う時間帯がラウンド中→ラウンド後に変わるだけ）。
• 「入力ハードルを下げれば記録は続く」→ 3タップ・3分でも手打ちである以上ナンセンス扱いされる。継続の仕掛けの根幹が崩れた。
• スコアの手入力 → 時計が既に担っており、二重入力は最も嫌われる行為。

崩れていない前提：

• 課題①〜⑤の事実関係（体力・膝・ミスの型・クラブ知見・3つの約束）
• 「蓄積してAIで分析する」コンセプト
• 無料・サーバーレス・AIペアプロの技術方針
• クラブ台帳の価値（更新は年数回。手打ち嫌いと矛盾しない）
• 上達の4指標（データさえ流れ込めば有効）

2. 変更方針の要約

3. 改訂設計

機能 — 主機能は「インポート」と「ふりかえり表示」の2つに再編。

• 取り込み： ラウンド後、家か車でAIアシスタントに（a）時計のスコア画面の写真、（b）30秒程度の音声メモ（「前半良かった、後半ガス欠、18番でチーピン」等）を渡す。AIが元設計のJSON形式に構造化し、アプリはそれを受け取って保存するだけ。
• ※音声・写真なら手打ち嫌いのユーザーに受け入れられるかは、追加情報に明示がなく推測。ただし嫌悪対象が「手でパチパチ」と特定されているため、手打ち以外の経路を設計するのが筋。
• ※HUAWEI製時計側からスコアを直接エクスポートできるかは、手元知識では確証なし。依存しない設計とし、確認できた場合に自動取り込みへ拡張する余地だけ残す。

データ — 構造は踏襲し、以下のみ追加・変更。

• rounds に source（watch_photo／voice_memo／chat）を追加し、スコアの出所を明確化。
• promises.done の記録者はAI（音声メモ中の「かかと浮かしできた」等を拾う）。言及がなければ未記録のまま。必須をやめる。
• shot_notes は会話で出た分だけAIが生成。空を許容。

画面UX — 画面は2枚に縮小。

• 起動＝最新のふりかえり（スコア推移・前後半差・約束実行率・ミスタグ内訳）が直接開く。入力系ボタンは置かない。
• インポート画面： JSONファイル選択またはテキスト貼り付けの受け口のみ。
• ラウンド前の3つの約束はアプリから追放し、グローブやキャディバッグに貼る3行シール（アナログ）に置き換える。開かないスマホより、必ず目に入る物理物のほうが確実（推測を含むが、ラウンド中に開かない以上、画面上の想起手段は成立しない）。

技術構成 — 単一HTML＋IndexedDBの枠組みは維持。変わるのは役割だけで、「閲覧・インポート・エクスポート器」に縮小する分、実装量は元設計より減る。JSON生成はアプリ外の既存AIアシスタントの仕事とし、依頼用のプロンプト雛形を1枚用意する。これが実質的な「入力画面」の代わり。

4. 捨てる決断

削除するもの：

1. スコア手入力UI（ホール毎・前後半とも）
2. ラウンド中ショットメモ
3. アプリ内チェックリスト画面（開始時・終了時）
4. 練習記録・体調ログの専用入力画面
5. ホームの「ラウンドを始める」導線と「3分で終わる記録」という目標（「手打ちゼロ」に置き換え）

削除しても成立する理由： 元設計の価値は入力画面ではなく「分析可能な蓄積と週次振り返りの回路」にあった。入力者を人間からAI（写真・音声の構造化）に置き換えても、データ構造・4指標・振り返り回路はそのまま残る。時計という自動記録が既に存在する分、元設計より記録の欠損は減ると見込める（推測）。入力UIの削除は実装・維持の両コストの削減でもあり、「一人で作り維持する」制約にも好都合。

5. 改訂後の最小版（v0.1）

作るものは2つだけ：

1. AI用プロンプト雛形（1枚）: 「この写真のスコアと音声メモから、次のJSON形式でラウンド記録を出力して」と依頼する定型文。元設計のデータ構造をそのまま埋め込む。これが入力機能の全部。
2. 単一HTMLビューア（画面2枚）: JSONをインポートして保存し、スコア推移・前後半差・約束実行率・ミスタグ内訳を表示する。入力フォームは持たない。

クラブ台帳の初期データもプロンプト雛形でAIに作らせ、JSONとして同じ受け口から入れる。v0.2以降は「時計アプリからの直接取り込み可否の確認」「音声メモの質に応じた雛形の調整」程度に留め、機能追加は運用してから判断する。