前編では、「パーソナルトレーニングに通うか、アプリを入れるか」で迷った結果、自分専用のAIコーチを作ったという話を書きました。
やっていることは単純です。毎日、体重と食べたもの・飲んだものと走った距離をざっくり投げる。飲んだ日は「その飲みがどうだったか」もひとこと足す。週に1回カレンダーを渡す。それだけで、週の残りの計画を組み替えてくれる。指示書もそのまま公開しました。
ただ、最後に書いたとおり、あれは第4版です。
初号機は、2週間で使わなくなりました。
後編は、その失敗の話から始めます。
1. 育て方 ── 最初のバージョンは、失敗でした
最初に作ったものは、要するに高機能なカロリー計算機でした。「今日は500kcal超過なので5km走ってください」。それだけ。
使わなくなった理由はシンプルです。
・提案が毎回「走れ」ばかりで、選択肢がない
・入力が面倒(食べたものを正確に打ち込まないと動かなかった)
・そして何より、指標が間違っていた
・提案が毎回「走れ」ばかりで、選択肢がない
・入力が面倒(食べたものを正確に打ち込まないと動かなかった)
・そして何より、指標が間違っていた
1つ目と2つ目は、指示書を直せば済む話でした。問題は3つ目です。
僕が本当に管理したかった指標は「摂取カロリー」ではありませんでした。
**「その週に一番長く走る予定だった距離を、予定どおり走り切れた率」**でした。
これが8割を超えている週は、体重も自然に落ちて、飲む時間も楽しめていました。逆にこれが5割を切る週は、カロリーをどう調整しようが、走れる距離が伸びていかない。焦りだけが増えていきます。
そこで指標を差し替えました。
【Before】主要指標:摂取カロリーの収支
【After】 主要指標:一番長く走る日の実行率(予定距離に対する達成率)
補助指標:体重の4週移動平均、週の純アルコール総量、
満足度◎だった飲みの回数
【Before】主要指標:摂取カロリーの収支
【After】 主要指標:一番長く走る日の実行率(予定距離に対する達成率)
補助指標:体重の4週移動平均、週の純アルコール総量、
満足度◎だった飲みの回数
体重も日々の数値を追うのをやめて、4週移動平均だけ見るようにしました。飲んだ翌日は1kg増えます。あれに一喜一憂するのが、一番のノイズでした。
育てる、とは何をすることか
やってみてわかった「育て方」は、次の3ステップの繰り返しでした。
① 予測と実績のズレを記録する
例:AI予測「今週▲0.4kg」→ 実績「▲0.1kg」
② ズレの原因を"僕が"言語化する
例:「金曜の会食で、締めのラーメンを計上していなかった」
③ 指示書に1行追記する
例:「会食の見積もりには、締めの炭水化物を必ず含める」
① 予測と実績のズレを記録する
例:AI予測「今週▲0.4kg」→ 実績「▲0.1kg」
② ズレの原因を"僕が"言語化する
例:「金曜の会食で、締めのラーメンを計上していなかった」
③ 指示書に1行追記する
例:「会食の見積もりには、締めの炭水化物を必ず含める」
これを毎週日曜に10分。それだけです。
大事なのは、AIに「学習しておいて」と頼むのではなく、人間が指示書を書き換えることでした。AIコーチを育てるという行為は、AIをいじる作業ではなく、自分の業務ルールを更新し続ける作業でした。
もうひとつ。指示書が膨らみすぎたら、削ります。
例外ルールが増えると、AIコーチの回答は途端にぼんやりします。これはもう完全に技術的負債と同じで、ひと月に1回はリファクタリングが必要でした。いまの指示書は3回書き直しています。行数そのものは増えましたが、例外ルールの数は初号機より減りました。
2. 運用の仕方 ── 「型」がないと3日で終わる
これは仕事でも痛感していることですが、どんなに良い仕組みも、運用が定着しなければゼロです。
いま試している型が、これです。
【毎朝 10秒】
Slackを開くと、もう投稿されている
→「今日は6〜8km。夜に会食があるので昼に走るのが安全」
→ 体重だけ返す(「今朝68.4」)
【お昼 20秒】
→「朝と昼、何を食べましたか?」と聞かれる
→「おにぎり1個とサラダ」くらいでいい
【夜 20秒】
→「夕食は何でしたか?」と聞かれる
→ 飲んだ日は「今日の飲みはどうでした?」も聞かれる
(「楽しかった。翌朝スッキリしてそう」/「いまいち。惰性で3杯目いった」)
【23時 読むだけ】
→ 今日のサマリが届く
(摂取/消費/純アルコール/週予算の残り/明日の目安)
【随時】
「金曜に会食入った」と一行投げる
→ 翌朝以降の指示に、勝手に織り込まれる
【毎週月曜】カレンダーを貼る → 今週のプランが出る
【毎週日曜】週次レポートが出る → 指示書を1行更新
【毎朝 10秒】
Slackを開くと、もう投稿されている
→「今日は6〜8km。夜に会食があるので昼に走るのが安全」
→ 体重だけ返す(「今朝68.4」)
【お昼 20秒】
→「朝と昼、何を食べましたか?」と聞かれる
→「おにぎり1個とサラダ」くらいでいい
【夜 20秒】
→「夕食は何でしたか?」と聞かれる
→ 飲んだ日は「今日の飲みはどうでした?」も聞かれる
(「楽しかった。翌朝スッキリしてそう」/「いまいち。惰性で3杯目いった」)
【23時 読むだけ】
→ 今日のサマリが届く
(摂取/消費/純アルコール/週予算の残り/明日の目安)
【随時】
「金曜に会食入った」と一行投げる
→ 翌朝以降の指示に、勝手に織り込まれる
【毎週月曜】カレンダーを貼る → 今週のプランが出る
【毎週日曜】週次レポートが出る → 指示書を1行更新
合計すると、1日に使っている時間は1分もありません。 4回、聞かれたときに一言返すだけです。
僕は何も思い出さなくていい。 これが続いている一番の理由だと思います。
いまのところ効いているコツは、2つあります。
ひとつ目は、1回の入力を20秒以内に収めること。 ここはアプリを諦めた理由そのものでした。「鶏もも串1本」を選ぶ作業は、僕には続きません。入力の正確さを捨てるのではなく、正確に直す作業をAI側に寄せた、というのが設計上の判断です。僕は雑に答える。AIが概算する。この役割分担にしたら続きました。
ふたつ目は、既存の習慣にフックさせること。 朝の投稿時刻は、僕が毎朝体重計に乗る時間に合わせてあります。乗った直後に数字を返すだけ。新しい習慣を作らず、すでにある習慣に相乗りする。いまのところ、これで抜けはほとんどありません。
これも、お客様の現場でシステムを定着させる時にやっていることと、まったく同じでした。
実際どうなったか
まだ運用して2ヶ月ほどです。正直、大きな成果と呼べるものはまだありません。 体重の4週移動平均が、ようやく下向きに傾きはじめたくらいです。
ただ、1つだけ確実に変わったことがあります。
飲みに行くときの罪悪感が、なくなりました。
「今週の予算内で、この時間までに切り上げれば、土曜に長い距離を走れる」とわかっているからです。制約が明確になると、選択が楽しくなる。 これは想像していなかった効果でした。
日曜に出てくるレポートが、思ったより効きました
毎週日曜、こんなレポートが返ってきます。(数値はイメージです)
【今週】
・体重 ▲0.3kg(4週移動平均も下向き)
・走行距離 24km(先週比 +2km)
・純アルコール 78g(週予算100g/残22g)
・満足度◎ 1回/飲んだ回数2回
【6月からの累計】
・体重 ▲2.4kg
・走行距離 168km
・満足だった飲み 8回/全10回
【今週】
・体重 ▲0.3kg(4週移動平均も下向き)
・走行距離 24km(先週比 +2km)
・純アルコール 78g(週予算100g/残22g)
・満足度◎ 1回/飲んだ回数2回
【6月からの累計】
・体重 ▲2.4kg
・走行距離 168km
・満足だった飲み 8回/全10回
このレポートで一番効いたのは、一番下の行でした。
10回飲んで、満足だったのは8回。 逆に言えば、2回は「いまいち」だったわけです。
ここに気づいてから、考え方が変わりました。削るべきは「飲む回数」ではなく、「いまいちな回」だった。 惰性で3杯目に行った日。義務感で出た日。そういう回を減らせば、体重にもアルコール量にも効くのに、満足の総量はまったく減らない。
「飲む量を減らす」でも「飲む回数を減らす」でもなく、「満足度あたりのコストを下げる」。 これがやりたかったことでした。
そして、これは測りはじめて初めて見えたものです。満足度を記録していなかったころは、こんな発想は出てきませんでした。
いま、うまくいっていないこと
現在も改善中なので、つまずいている点も書いておきます。
・定時投稿が、毎回きっちり同じ時刻に来るとは限らない
→ ベータなので、ここは様子を見ながら
・カレンダーのコピペが、地味に面倒
→ Googleカレンダーは繋げられそうなので、次はここ
・会話が長くなると、週予算の残りをAIが見失う
→ 週の頭に「今週の台帳」を作って貼り直す運用で暫定対応中
・睡眠時間を、計算に入れられていない
→ 入力項目をこれ以上増やしたくないので、いまは保留中
・「今週はもう諦めて、来週立て直す」という判断ができない
→ ここが一番の課題。潔く撤退する基準を、まだ言語化できていない
・定時投稿が、毎回きっちり同じ時刻に来るとは限らない
→ ベータなので、ここは様子を見ながら
・カレンダーのコピペが、地味に面倒
→ Googleカレンダーは繋げられそうなので、次はここ
・会話が長くなると、週予算の残りをAIが見失う
→ 週の頭に「今週の台帳」を作って貼り直す運用で暫定対応中
・睡眠時間を、計算に入れられていない
→ 入力項目をこれ以上増やしたくないので、いまは保留中
・「今週はもう諦めて、来週立て直す」という判断ができない
→ ここが一番の課題。潔く撤退する基準を、まだ言語化できていない
とくに最後の1つは、仕事でもそのまま出てくる論点だと思っています。計画を守らせることより、崩れたときにどう立て直すかのほうが、よほど設計が難しい。
3. 「自分専用のアプリを作る」必要は、なかった
いま入力しているものの多くは、本来ならすでにどこかに記録されているデータです。
・体重 → 体組成計にある
・走った距離 → Appleのヘルスケアにある
・睡眠時間 → Appleのヘルスケアにある
・予定 → スケジュールアプリにある
・体重 → 体組成計にある
・走った距離 → Appleのヘルスケアにある
・睡眠時間 → Appleのヘルスケアにある
・予定 → スケジュールアプリにある
つまり、僕が毎日手で入力している項目のうち、本当に僕しか知らないのは「何を食べたか」「何を飲んだか」「その飲みがどうだったか」の3つだけなんです。
なので当初、僕はこう考えていました。
「最終的には、Apple Watchに話しかけるだけのアプリを作ろう。」
朝、時計が「今日は6〜8km」と教えてくれる。「今日はビール2杯」と話しかけるだけで記録される。そこまで行けたら一生使うだろう、と。
調べてみたら、前提が2つ崩れました
ひとつ目。「Apple Watchで受け取る」は、すでに動いていました。
Slackの通知は、Apple Watchに届きます。つまりコーチが朝7時にチャンネルへ投稿すれば、それがそのまま手首に来ている。 作るものは何もありませんでした。気づいていなかっただけです。
ふたつ目。ヘルスケア連携は、僕が考えていた方向では不可能でした。
Appleのヘルスケアのデータは、iPhoneの中にしか存在しません。クラウドに上がっていないので、外部のサービスが取りに行くための窓口が、そもそも用意されていないのです。Googleカレンダーのように「繋ぐ」という発想が、ここだけ通用しませんでした。
ただ、逆向きなら通ります。iPhoneの側から、外に押し出す。
iPhoneのショートカットで時刻の自動実行を設定して、ヘルスケアのデータをSlackに投げる。これなら成立します。毎朝6時55分に、
体重 68.4 / 昨日の距離 8.2km / 睡眠 6時間30分
体重 68.4 / 昨日の距離 8.2km / 睡眠 6時間30分
とチャンネルに自動投稿される。コーチはチャンネルの投稿を読むので、それがそのまま材料になります。
気づいたら、全部「チャンネルへの投稿」だった
ここまで整理して、ようやく構造が見えました。
コーチが取りに行くもの → Googleカレンダー
向こうから投げ込むもの → ヘルスケア(ショートカット)
Apple Watchの音声(ショートカット)
自分が答えるもの → 食べたもの・飲んだもの・満足度
→ すべて「Slackチャンネルへの投稿」に統一される
コーチが取りに行くもの → Googleカレンダー
向こうから投げ込むもの → ヘルスケア(ショートカット)
Apple Watchの音声(ショートカット)
自分が答えるもの → 食べたもの・飲んだもの・満足度
→ すべて「Slackチャンネルへの投稿」に統一される
入力経路が何本増えても、コーチ側の指示書は1行も変わりません。
そして、これに気づいた瞬間に、作ろうとしていたアプリが消えました。
やるべきことは「アプリを開発する」ではなく、**「入力経路を1本に集める」**だっただけです。ネイティブアプリが必要になるのは、これを他人に配るときだけでした。
やり残していること
【済】Slackに住まわせて、向こうから声をかけてくる形にした
【済】Apple Watchで受け取る(=Slackの通知だった)
【次】Googleカレンダーを繋いで、コピペをやめる
【次】ショートカットでヘルスケアを自動投稿させる
【次】Apple Watchのショートカットから、声で投げられるようにする
【済】Slackに住まわせて、向こうから声をかけてくる形にした
【済】Apple Watchで受け取る(=Slackの通知だった)
【次】Googleカレンダーを繋いで、コピペをやめる
【次】ショートカットでヘルスケアを自動投稿させる
【次】Apple Watchのショートカットから、声で投げられるようにする
3つとも、合わせて1日あれば終わりそうです。アプリを作ろうとしていたら、何ヶ月かかったかわかりません。
前編で「コードは1行も書いていない」と書きましたが、この先も書かないままで済みそうです。
そして、いちばん恥ずかしい話
前々回の記事で、僕はこう書きました。
システムを作ることが目的ではありません。Webサイトを作ることが目的でもありません。AIを導入することが目的でもありません。
自分で書いておきながら、自分のダイエットでは「アプリを作る」ことを目的にしていました。
やりたかったのは「入力の手間をなくすこと」です。アプリはその手段のひとつに過ぎず、しかも一番重い手段でした。調べてみたら、もっと軽い手段で足りた。
手段を目的にすり替えていたのは、僕でした。
これが今回、いちばんこたえた学びです。
そして、ここまでの話は技術の話というより、「どの入力を人間に残し、どれを機械に寄せるか」の切り分けの話です。……という言い方をすると、もう完全に本業の話になってしまいますね。
なので、このAIコーチは第4版ですが、まだ完成していません。たぶん、しばらく完成しないと思います。 それでいいと思っています。生活が変わればルールも変わるので、そのつど書き換えていくものなのだろうと考えています。
4. で、これが仕事とどう関係するのか
前編の冒頭で「独断でこじつけます」と書きました。そろそろ、こじつけを回収します。
AI活用がうまくいかない理由は、ほぼAIの側にありません。
・そもそも追うべき指標が間違っている
・データが取れない/入力が面倒すぎて続かない
・判断基準が言語化されていない
・運用の"型"が決まっていない
・そして、手段が目的にすり替わる
・そもそも追うべき指標が間違っている
・データが取れない/入力が面倒すぎて続かない
・判断基準が言語化されていない
・運用の"型"が決まっていない
・そして、手段が目的にすり替わる
僕が自分の体でつまずいたのは、全部これでした。そしてこの5つは、AIが解いてくれる問題ではありません。
これを解くのは、
- 業務を理解する力
- 課題を整理する力
- 指標を定義する力
- 運用を定着させる力
- 作らなくていいものを、作らないと決める力
前々回、僕が「AIに代替されない仕事」として挙げたものと、ほぼ一致しました。自分の体を相手に、小さな受託開発を1本やってみたようなものでした。
最後の1つだけは、書いていなかったものです。「作らない」という判断が、いちばん価値のある提案になることがある。これは今回、身をもって学びました。
そして正直に言うと、自分でAIコーチを作って、失敗して、育て直した経験がある人間と、AIについて調べただけの人間では、お客様に「AIを入れましょう」と言うときの解像度がまったく違うと思います。
だから僕は、自分たちがAIを使い倒している会社でありたいと思っています。お客様の業務改善を提案する前に、自分の生活で試してみる。うまくいかなかった理由まで、自分の言葉で語れるようにしておく。
大げさな話ではありません。ダイエットでいいんです。
もしこれを読んで「自分もやってみようかな」と思った方がいたら、前編の指示書をコピーして、【 】を自分の数字に置き換えるだけで動きます。Slackでなくても、GPTsやClaudeのProjectに貼れば同じように動きます。 ただしその場合は向こうから話しかけてこないので、スマホのリマインダーを4つセットしてください。 それでも十分に機能します。
そして初号機がうまくいかなかったら、それは正常です。 僕もそうでしたし、いまも改善の途中です。
次回は、いよいよ本題に戻ります。この変化の中で、SPIN D&Dがこれからどんな仕事に注力していくのか。そして僕たちが「これから面白くなる」と本気で考えている領域について書きます。
このAIコーチのほうも運用を続けて、体重と走れる距離がどうなったか、そして結局コードを1行も書かないまま「話しかけるだけ」に到達できたかを、いずれまた報告したいと思います。
とりあえず今週は、土曜に長い距離を走るところからです。金曜の会食は、純アルコール24gまでだそうです。
興味を持っていただけたら、ぜひ次回も読んでいただけるとうれしいです。
※本記事は個人の実践記録です。減量や飲酒量の判断は体質や既往症によって大きく変わります。健康上の不安がある方は、必ず医師や専門家にご相談ください。