ヘルスケアの体重をChatGPTで自動分析したかったが、ショートカットで挫折した話

導入

体重は測れても、振り返りが面倒で「なんとなく」で終わる。

今週の流れ、増減の要因、次に直すポイント。ここを考えるのがだるい。

最初にやりたかったことは単純でした。

ヘルスケアに入れている体重データを自動で抜き出して、ChatGPTに渡せば、分析まで自動化できる。これなら、振り返りの手間が消える。そう思いました。

結論はこれです。

ショートカットで「取得→追記→送信→返答抽出→保存→通知」まで一気に作ると、手順と例外処理が膨れて挫折しやすい。

なので、目的を固定して、最小構成から育てるのが現実的です。

この記事で得られること：

• 挫折の原因を「手順」「例外」「目的のズレ」で切り分ける観点
• 自動化を捨てても成立する最小構成（継続優先）の手順
• 自動化する場合の分割手順（1機能ずつ）

前提（誰向けか／対象外は何か）

誰向けか

• Appleヘルスケアに体重を入れている人
• 体重管理で一番つらいのが「記録」ではなく「振り返り」になっている人
• iPhoneショートカットで自動化したいが、作るのが面倒で止まりがちな人

対象外

• ショートカットの具体的な画面操作・設定値の手順は扱いません。 代わりに、設計の分割と最小構成の考え方を扱います。

問題の正体（なぜそれが起きるか：原因を分類してみた）

原因1：手順が連鎖して、ゴールが見えなくなる

「体重を取る」だけなら簡単でも、そこから作業が連鎖します。

• 日付整形
• CSVヘッダ処理
• 改行付き追記
• 直近日数の抽出
• 送信用文章の組み立て
• 返答の取り出し
• 保存と通知

原因2：例外処理が多く、実装コストが読めない

自動化は「常に成功する前提」で組むと壊れます。

• 未入力の日
• 同日複数回入力
• ファイルがない／移動した
• 返答が長い／抽出方法がズレる

原因3：最初から完成形を狙ってしまう

「CSV」「自動分析」「保存」「通知」を一気にやろうとして、作る前に疲れます。

原因4：手段が目的を飲み込む

本当に欲しいのは「体重の流れを見て、次の一手を決める」のに、ショートカット作り自体が目的になります。

エンジニア目線の補足：今回の失敗は現場だとこういう現象

今回の挫折は、現場でいうと「スコープが膨らんで依存が増え、例外処理が仕様になって、途中成果が出ないまま止まる」現象に近いです。

• スコープクリープが起きた
  • 「体重を取る」から始まったのに、気づいたら「CSV整形」「分析」「保存」「通知」まで要件が増えます。
  • 便利にしたい気持ちが強いほど、自然に膨らみます。
• 依存が増えて、壊れる点が増えた
  • ヘルスケア → ファイル → 外部送信 → 返答抽出 → 保存 ここまで鎖が長いと、どこか1個落ちるだけで全体が止まります。
  • 現場なら「外部API障害で全滅」「タイムアウトで中途半端に終わる」に近いです。
• 例外処理が“後から仕様”になる
  • 未入力、複数入力、ファイル不在は、運用では普通に起きます。
  • 現場だと「PoCは動いたのに、本番運用で死ぬ」の典型です。
• 完成形前提で、途中の価値がゼロになった
  • 一気通貫が動くまで価値が出ない設計だと、途中で気力と優先度が落ちます。
  • 現場でも「リリースまで何も渡せず、途中で消える」案件は珍しくありません。

解決策（分類ごとに「対策→手順→注意点」）

解決策A：目的を固定する（分析か記録か）

対策

まず「欲しい成果」を1つに絞ります。

• 分析：流れを見て、次の一手を決める
• 記録：後で見返せる状態にする

手順

• 「困っているのは記録不足か、振り返りの負荷か」を言語化する
• 片方だけを先に満たす（もう片方は後回し）

注意点

• 最初から両取りすると、手順と例外処理が増えます。

解決策B：ショートカットを作らずに、継続できる最小構成に落とす

対策

自動化は後でいい。まず「続く運用」を作ります。

手順（案1：毎日1行＋週1回だけ分析）

• 毎日：メモに「日付 体重」だけ書く
• 週1回：7行をまとめて貼って、分析コメントを作る

注意点

• 最初に勝つべきは「自動化」ではなく「継続」です。

解決策C：CSVは作るが、追記は手動（10秒）にする

対策

データの形を先に決めて、集計しやすい状態を作ります。

手順（案2）

• CSVは2列に固定する：date,weight_kg
• 追記は1日1回、コピペでOKにする

注意点

• ここまでなら「未来の自分のための貯金」で済みます。

解決策D：自動化するなら分割する（1機能ずつ）

対策

一気に完成させない。機能単位で進めます。

手順（案3）

1. 体重取得→画面に表示（保存しない）
2. 表示が安定したらCSV追記を追加
3. 追記が安定したら分析を追加
4. 最後に通知と保存

注意点

• 例外処理は最初から全部入れません。壊れた分だけ足す設計にします。

エンジニア目線の補足：これは段階リリースと同じ

「分割して進める」は、現場でいう段階リリースと同じです。

• まずは 観測できる（表示できる）
• 次に 再現できる（保存できる）
• 次に 価値が出る（分析できる）
• 最後に 運用が楽になる（通知する）

現場の言葉に寄せると「ログ出す → 永続化する → 集計する → アラート出す」の順番に近いです。

チェックリスト

• 目的は「分析」か「記録」かを先に決める
• 最初は2列だけ：date,weight_kg
• 自動化は1機能ずつ追加する
• 失敗する日を想定する（未入力、複数入力）
• 作る手間が15分を超えたら一旦やめる（勝ち撤退）

具体例（運用イメージ）

• 毎日やることを「日付 体重」の1行に固定する
• 週1回、直近7行をまとめて見て「次に直すこと」を1つだけ決める
• この週1回が回り始めたら、初めて「取得の自動化」から着手する

※増えた／減った幅などの具体の数値例は、ここでは入れません（データがないため）。

FAQ

自動化を最初から狙うのはダメですか？

ダメではありません。ただ、手順と例外処理が膨れて折れやすいです。最小構成で継続を作ってから育てる方が安定します。

最小構成はどれが一番軽いですか？

「毎日1行＋週1回だけ分析」です。作るコストがゼロで始められます。

CSVにするメリットは何ですか？

後から集計・見える化がしやすくなります。将来、自動化や分析を足すときの土台になります。

例外処理は最初から全部入れるべきですか？

入れない方が続きます。壊れた分だけ足す設計にすると、作るコストが膨らみにくいです。

自動化の価値って結局なんですか？

時間を生むことです。ただし、作るコストで燃え尽きたら逆効果です。

まとめ（結論の再提示＋次の一手）

今回の挫折の原因は、完成形を一気に狙って、手順と例外処理が膨れたことです。

自動化は正しいですが、最初は最小に落とし、続いてから育てるのが現実的です。

要点は3つです。

• 目的を固定する（分析か記録か）
• 継続できる最小構成を先に作る
• 自動化するなら1機能ずつ分割する

今日やることは1つです。

メモに「日付 体重」を1行で残し、週1回だけ直近7行を見て次の一手を1つ決めてください。

エンジニア目線の補足：これは「技術力不足」ではない

今回の話は、技術が足りないのではなく、設計の勝ち筋が違っただけです。

• 完成形を最初に狙う → 価値が出るまで遠い → 途中で優先度が落ちる
• 最小構成から育てる → 途中でも価値が出る → 続く

自動化は「便利ツール」ではなく、運用まで含めると小さなプロダクトです。

だから一番大事なのは、便利さよりも「やめない設計」です。

関連記事

電子書籍が向いてる人／紙の本が向いてる人：3問で診断

気を遣いすぎて疲れる人へ：人間関係の摩擦を減らす設定

SNSで他人と比較してしんどい時の対処