歩く理由製造機 ── 運動サプリ®。三日坊主、卒業。

ヘルスケア AI というと、多くの人は「健康について答えてくれる AI」や「運動を励ましてくれる AI」を思い浮かべる。

たとえば、食事について助言する。睡眠についてコメントする。歩数が少ないとリマインドする。生活習慣を改善しましょう、と励ます。

これはたしかに便利である。

しかし、行動変容の本当の難しさは、情報提供や励ましだけでは解決しない。

多くの人は、歩いたほうがよいことを知っている。運動したほうがよいことも、健康診断の数値を改善したほうがよいことも知っている。

それでも続かない。

なぜなら、行動変容は「知識」の問題だけではなく、「実行構造」の問題 だからである。

ここに、運動サプリ®の先進性がある。

運動サプリ®の現在地と将来像

最初に、よくある誤解を避けるためにはっきりさせておきたい。運動サプリ®の先進性は、現時点で AI が自動実行していることではない。 AI エージェントが将来実行できる「行動変容のオペレーション構造」を、すでに人間操作ベースで実装していることにある。

現状

人間がチャレンジを設定する。
人間がスポンサー・チャレンジャー・受取人・配分条件を決める。
アプリは、その条件に基づいてウォーキングチャレンジと金銭的コミットメントを運用する。

将来像

AI がユーザーの許可を得る。
AI がウォレット、予算上限、承認条件、受取人制限の 範囲内で チャレンジ案を作る。
ユーザー承認後に、AI がチャレンジ設定、供託、判定、配分までを自動化する。

表現するなら、行動変容オペレーション SaaS

運動サプリ®を一言で位置づけるなら、行動変容オペレーション SaaS である。

SaaS が業務プロセスを実行可能なソフトウェアに収めたように、運動サプリ®は 「歩く理由を維持する仕組み」をアプリ内で実行可能 にしている。

違いはひとつ ── ここで実行される操作は、将来 AI エージェントに委任できる輪郭で設計されている。

AI の進化は「答える」から「実行する」へ向かっている

近年の AI の大きな変化は、単に文章が上手くなったことではない。

AI が、現実の作業環境に対して実行権限を持ち始めたことにある。

ソフトウェア開発の世界では、この変化がわかりやすい。従来のチャット AI は、コードの書き方を説明したり、エラーの原因を推測したりしていた。いわば「助言する AI」だった。

しかし、Claude Code のようなエージェント型ツールでは、AI がコードベースを読み、ファイルを編集し、コマンドを実行し、結果を返す。ユーザーは「このバグを直して」「この機能を追加して」と依頼し、AI は実際の開発環境の中で作業する。

これは、AI の役割が「助言」から「実行」へ広がったことを意味する。

同じ変化は、ヘルスケアや行動変容の領域にも起こり得る。

従来のヘルスケア AI は、健康について答える。次のヘルスケア AI は、ユーザーを励ます。さらにその先のヘルスケア AI は、ユーザーが承認した範囲で、行動変容の仕組みそのものを設計し、実行する。

運動サプリ®が先取りしているのは、この第三段階である。

ただし、繰り返すが、現時点で運動サプリ®が AI によってそれを自動実行しているという意味ではない。

運動サプリ®がすでに持っているのは、AI が将来実行できるための「行動変容のプロトコル」 である。

行動変容に必要なのは、励ましではなく「仕組み」である

健康アプリの多くは、ユーザーにこう言う。

「今日はまだ歩数が足りません」「明日はもう少し頑張りましょう」「健康のために運動しましょう」

こうした通知や励ましには意味がある。

しかし、人間の行動は、通知だけではなかなか変わらない。通知を見ても、忙しければ後回しにする。疲れていれば歩かない。今日くらいいいか、と思ってしまう。

そこで重要になるのが、コミットメントの設計 である。

人は、自分ひとりの意思だけでは続けにくい。しかし、誰かに約束したときは続けやすくなる。

自分のお金がかかっていると真剣になる。達成したときに大切な人が喜ぶなら、さらに頑張れる。失敗したときに望まない配分が起きるなら、途中でやめにくくなる。

このうち「自分のお金がかかっている」「失敗したときの望まない配分」は、行動経済学でいう 損失回避 ── 利得側の喜びより、失う痛みのほうが約 2 倍強く効く認知バイアス ── を駆動する設計である。

そして「達成したときに大切な人が喜ぶ」「失敗したら家族や友人が受け取れなくなる」は、自分のためではなく誰かのために行動する 利他性 を駆動する設計である。

運動サプリ®は、この 損失回避 × 利他性 の構造を、アプリ上で実行可能にしている。

「望まない配分」をどう設計するか ── 操作と支援の境界線

ここで注意すべきは、「失敗時の受取人」の選び方には倫理的な配慮が必要だ、ということだ。

「本人が少し避けたい相手」を受取人にすると、損失回避の動機を強められるのは事実である。

しかし、これは 行動操作と行動支援の境界線 に触れる設計でもある。

たとえば、嫌いな政治団体や特定の個人を受取人に指定して、本人に強い反感を起こさせる設計は、行動変容の手段としては効果的でも、本人の意思の自由を侵害する。

運動サプリ®の設計指針は、受取人の選択肢を 本人にとって社会的に肯定可能な範囲 に限定することにある。家族、友人、応援したい慈善団体など、本人が事前に納得し、かつその選択が周囲から見ても妥当と認められるものに限る。

負のインセンティブを過剰に強くしない。「やや残念だが社会的には問題ない」程度に留める。

行動変容の設計には、操作と支援の境界線を引く倫理 が常に必要である。

現在の運動サプリ®は「人間が設定する行動変容エンジン」である

運動サプリ®の現在の価値を正確に表現するなら、こうなる。

AI が全自動で動かすアプリではなく、人間が設定する行動変容エンジン である。

ユーザーやスポンサーが、チャレンジの条件を決める。誰が応援するのか。誰が挑戦するのか。いくら供託するのか。成功したら誰に配分するのか。失敗したらどう配分するのか。何歩を、どの期間、どれくらい達成するのか。

こうした設定は、現時点では人間が行う。

しかし、ここで注目すべきなのは、設定作業が手動であることではない。

その設定項目自体が、将来 AI エージェントに委任できる構造になっていることである。

たとえば将来、AI エージェントが次のように動くことは自然に考えられる。

「あなたの過去の歩数データを見ると、いきなり 1 日 1 万歩は難しそうです。まずは週 5 日、7,000 歩から始めるのがよいでしょう」

「供託金は高すぎると負担になり、低すぎると行動変容効果が弱くなります。今回は 3,000 円を上限にしましょう」

「成功時の受取人に家族を入れると、本人以外のために頑張る動機が生まれます」

「失敗時の配分先は、社会的には問題のない選択肢の中から、本人にとって少し避けたい相手を選んでください」

「この条件でチャレンジを作成します。実行してよいですか?」

ユーザーが承認すれば、AI がチャレンジを作成し、必要な範囲でウォレットを操作し、供託や配分まで行う。

これは、現在の運動サプリ®がやっていることと 原理的には同じ である。違いは、現在は人間が設定している操作を、将来 AI がユーザーの許可のもとで代行する点にある。

運動サプリ®の先進性は「AI 機能」ではなく「AI 化しやすい構造」にある

ここを間違えてはいけない。

運動サプリ®の先進性は、現時点で高度な AI が実装されていることではない。

先進性は、AI が入るべき実行レイヤーを、すでに設計していること にある。

多くのヘルスケア AI は、会話レイヤーにいる。ユーザーに話しかける。励ます。アドバイスする。質問に答える。

一方、運動サプリ®が扱っているのは、行動変容の 実行構造 である。

目標をどう設定するか。誰が応援するか。どの金額を供託するか。誰が受け取るか。成功時に何が起きるか。失敗時に何が起きるか。結果をどう判定するか。

これは、単なる会話ではない。行動を変えるための制度設計 である。

AI が本当に行動変容に関与するためには、この制度設計のレイヤーに入る必要がある。

Claude Code との類似点は「すでに AI であること」ではなく「委任可能な作業構造」にある

運動サプリ®と Claude Code を比較するときも、表現には注意が必要である。

Claude Code は、すでに AI がコードを書き、ファイルを編集し、コマンドを実行するツールである。一方、現在の運動サプリ®は、AI が自動でチャレンジを作成し、資金配分まで行うツールではない。

したがって、両者を同列に「どちらも AI が実行している」と言ってはいけない。

正しくは、こうである。

Claude Code は、ソフトウェア開発において、AI が実行権限を持った例である。

運動サプリ®は、行動変容において、将来 AI が実行権限を持つための対象業務をすでに構造化している例である。

つまり、比較すべきなのは「現在の AI 実装レベル」ではなく、「委任可能な作業構造」である。

Claude Code で AI に委任できる作業は、コードの修正、ファイル編集、テスト実行、コマンド実行である。

運動サプリ®型で将来 AI に委任できる作業は、チャレンジ設計、供託金額の提案、受取人設計、成功・失敗条件の設定、結果判定、配分実行である。

コード SaaS の接続点 × 行動変容 SaaS の接続点

別の角度から言うとこうなる。

Claude Code が「コード SaaS と AI の接続点」に立つツールであるように、運動サプリ®が目指すのは「行動変容 SaaS と AI エージェントの接続点」である。

SaaS が業務を実行可能なソフトウェアに収めた歴史の上に、AI エージェントが「ユーザーの権限範囲を委任された別主体」として動く時代が乗る。Claude Code はこれを開発業務で示した先行例である。運動サプリ®は同じ構造を、行動変容という別領域で先に作っている。

なぜ銀行 API やエスクローではダメなのか ── JPYC の必然性

ここで素直な疑問が出る。

なぜわざわざ on-chain 通貨を持ち出す必要があるのか。AI に銀行 API を叩かせればよいのではないか、第三者エスクローサービスを使えばよいのではないか。

しかし、AI エージェントが行動変容を執行するには、銀行 API と従来エスクローでは 構造的に足りない要件が三つ ある。

1. 24/7 のリアルタイム決済

歩数目標の達成・未達は、行動が発生したその瞬間に判定が始まる。日次・週次のチャレンジで「金曜の深夜に目標達成、土曜午前 0 時に配分を実行」を、銀行営業日・営業時間に依存せずに動かす必要がある。

銀行 API は原則として営業時間制約があり、夜間・週末・祝日のリアルタイム決済はまだ多くの現場で不可能か、可能でも条件付きである。

オンチェーンの円ステーブルコインは、ネットワークが稼働している限り、いつでも動かせる。

2. プログラマブルな条件分岐

「目標達成 → チャレンジャーへ全額、未達 → 受取人へ X%、運営手数料 Y%」のような条件分岐は、スマートコントラクトであれば数行のコードで記述・自動実行できる。

従来エスクローでは、判定と分配は人間のオペレーターか、業務委託先の手作業に依存する。

AI が判定結果を投入した瞬間に分配が走るためには、契約の条件分岐自体が 機械可読・自動実行可能 でなければならない。

3. AI エージェントが直接署名できる、検証可能な API 境界

これが最も大きい。

銀行 API は、原則として人間ユーザーの認証が前提で、AI が「ユーザーの代わりに署名する」ことを想定していない。OAuth 等の代理アクセスも、出金・送金の決済主体としては設計されていない。

一方、スマートコントラクトとオンチェーン通貨は、次のような設計が初めから組み込まれている。

AI エージェントが自分のキーで署名できる(その権限範囲はユーザーがあらかじめ定める)
署名行為が公開台帳に 検証可能な形 で残る
署名前後の状態が 監査可能な形 で観測できる

銀行 API で AI を動かそうとすると、AI は「ユーザーになりすます」しかない。これは安全性・責任所在・監査性のすべてで破綻する。

JPYC のようなオンチェーン円ステーブルコインは、AI が 「ユーザーの権限範囲を委任された別主体として」 動ける、現時点で唯一の決済基盤である。

これは「Web3 を使いたいから使う」のではない。AI エージェントが行動変容を執行できる経済基盤は、現時点では on-chain 円ステーブルコインの上にしか存在しない、という設計上の必然である。

AI がウォレットを持つ時代に、何が重要になるか

将来、AI エージェントがウォレットを持ち、ユーザーの許可を得て支払い・供託・配分を行うようになると、ヘルスケア AI の役割は大きく変わる。

ただし、AI がウォレットを操作できるなら、慎重な設計 が必要である。

支出上限、人間承認、受取人制限、監査ログ、緊急停止、データ最小化 ── 必要な要件は多い。

抽象的な要件を、具体的な UI に落とす

これは抽象的な要件リストに見えるかもしれないが、UI/UX としては具体的に組み込める。

たとえば、ユーザーは AI 代行の権限を設定する画面で、以下のようなルールを宣言できる。

「月の自動供託上限を 5,000 円までに制限」
「一回あたりの供託金が 1,000 円を超える場合は、通知してユーザーが承認するまで動かない」
「新しい受取人を AI が提案したときは、必ず本人確認を経る」
「直近 7 日間の支出が想定を超えたら、緊急停止して人間に判断を委ねる」

AI エージェントは、その宣言された輪郭の中でしか動かない。輪郭の外に出るときは、必ず人間の承認が必要になる。

これは「AI を信頼するか / 信頼しないか」という二項対立ではなく、「どこまで信頼を委任するかを、ユーザー自身が宣言できる」 という設計思想である。

このガードレールがあって初めて、AI は行動変容の実行レイヤーに入ることができる。

運動サプリ®が将来 AI エージェント化する場合も、重要なのはここである。AI が勝手にチャレンジを作るのではない。AI が勝手にお金を動かすのでもない。ユーザーがあらかじめ許可した範囲の中で、AI がチャレンジ設計と実行を支援する。

この設計思想を明確にしておくことが、社会的な信頼につながる。

まとめ ── 「AI 化しやすい構造」を先に持っていることの意味

ヘルスケア AI の進化は、大きく三段階に整理できる。

第一段階は、答える AI である。 健康情報を説明し、質問に答える。

第二段階は、寄り添う AI である。 ユーザーと会話し、励まし、行動を記録し、フィードバックする。

第三段階は、実行構造に関与する AI である。 目標設定、コミットメント、金銭的インセンティブ、受取人設計、結果判定、配分実行に関与する。

運動サプリ®は、第三段階の AI を 実装済み というわけではない。

しかし、第三段階の AI が実行すべき 構造を、すでに行動変容オペレーション SaaS として持っている。

多くの AI ヘルスコーチは「歩きましょう」と言う。

運動サプリ®は、ユーザーが歩き続けるための 約束・資金・受取人・配分条件 を作る。そして将来的には、その設計を AI エージェントがユーザーの許可のもとで代行できる。

その基盤として必要なのは、24/7 のリアルタイム決済、プログラマブルな条件分岐、AI が直接署名できる検証可能な API 境界 ── すなわち、JPYC のようなオンチェーン円ステーブルコイン である。

そしてその上に必要なのは、ユーザーが委任の範囲を宣言できる ガードレール と、操作と支援の境界線を引く倫理 である。

すでに AI だから先進的なのではない。

AI が実行すべき行動変容の型を、行動変容 SaaS として先に作っているから先進的なのである。