私のAIランニングコーチはGitリポジトリとClaudeエージェントでできている

練習を終える。時計はいつものように自動でStravaへ同期される。私はシャワーを浴びに行く。

出てくる頃には、私が何も触らないまま3つのことが起きている。練習の分析がトレーニング用リポジトリに書き込まれている。週のプランが調整され、変更の理由が横に添えられている。そしてStravaのアクティビティの下には、コーチからのコメントがある。今日の練習にどれだけの価値があったのか、金曜日の内容が何に変わるのかを教えてくれる。

このコーチは私が開発したアプリケーションではない。MarkdownファイルのGitリポジトリと、Claudeのサブスクリプションと、それらをまとめるAgentsRoomだ。サーバーは一行も書いていないし、トークン単位の請求もない。組み立てにかかったのは週末ひとつぶんくらいだ。

一式はテンプレートとして公開している：github.com/AgentsRoomDev/running-performance-coach。クローンして、空欄になっている箇所を埋めれば自分のものになる。この記事では、「API」という言葉は聞いたことがあるがwebhookは書いたことがない、という前提で、仕組みを部品ごとに説明する。

前提として：私は長く走っていて、マラソン2時間47分、ハーフ1時間13分59秒、10km 33分45秒。今のサイクルの目標は10kmで34分を切り直すことだ。この先の話に関わってくる：閾値走とは何かをいちいち説明し直す汎用コーチは私の役に立たない。そして、この仕組みが解決するのはまさにその問題だ。

練習を終えてからコメントが届くまでに起きていること

流れ全体は6段階だ：

1. 時計がアクティビティをStravaに送る。ここは誰でもすでにそうなっている。
2. 15分おきに、小さなPythonスクリプトがStravaに新しいものがないか尋ねる。
3. 新しい練習を見つけると、リポジトリの中にMarkdownの練習シートを作る：ラップ、スプリット、走行距離、心拍。実測値だけだ。
4. あわせてStrava上のアクティビティのタイトルと説明も書き換える。フィードに「午後のランニング」と表示され続けないように。
5. それから署名付きのメッセージをAgentsRoomに送り、練習内容をすでに手にした状態でClaudeエージェントを起動する。
6. そのエージェントがコーチの仕事をする：読み、比較し、分析を書き、週を調整し、コミットし、プッシュし、Stravaにコメントし、長いレポートをメールで私に送る。

最初の5段階は配管工事だ。6番目がこの記事の主題になる。

トレーニング記録はデータベースではなくGitリポジトリ

これがすべてを変えた判断であり、いちばん驚かれる判断でもある。

1回の練習 = 1ファイル、journal/2026/2026-09-03.md。1週間 = 1ファイル、plan/weeks/2026-W36.md。プランの変更 = 1コミット、理由はメッセージの中。データベースもスキーマもマイグレーションもインターフェースもない。

重要な順に3つの帰結がある。

コーチは自分の履歴を読み返せる。 3週間前に自分が何を処方したかを知っていて、それがうまくいったかを確認できる。練習内容を話して聞かせるチャットボットは、会話のたびにゼロから始まる。リポジトリを持つエージェントには記憶があり、その記憶は人間にも読める。

プランはスマートフォンのGitHubアプリで読む。 リポジトリのREADME.mdは紹介ページではない：私のダッシュボードだ。CLAUDE.mdに書いた契約はその点を明示している。READMEに反映されるまで、どんな計画も終わっていない。結果として、私は維持すべきインターフェースを1つも持たないのに、今日やることを表示してくれる画面を持っている。

取り返しがつかないものは何もない。 エージェントが書くものはすべてコミットだ。読めるし、反論できるし、revertできる。アプリケーションが自分の判断だけで決めてしまうのとはまるで違う。

ステップ1：Stravaが小さなスクリプトを起こす

StravaはAPIを公開している：プログラムが「このアスリートの最近のアクティビティをくれ」と尋ねるための手段だ。strava_sync.pyスクリプトはまさにそれをやり、返ってきた答えを練習シートに変える。

面白いのはネットワーク呼び出しではなく、再構成のほうだ。時計は生のラップを記録する。スクリプトは、それがどんな練習だったのかを割り出さなければならない：

Lap 1  : 4.40 km in 26'07 (5:56/km)   ← ウォームアップ
Lap 2  : 1.00 km in 3'41  (3:41/km)   ← 1本目
Lap 3  : 0.20 km in 1'59  (9:55/km)   ← つなぎ
...                                     → 「5 x 1000m r' 2'」

スクリプトは「いちばん速いk本のラップが本数だ」という形の分割をすべて試し、いちばん筋の通るものを残す。簡単そうに見えて簡単ではない：速度で素朴にグループ分けすると、ウォームアップがつなぎより速い瞬間に引っかかる。

とりわけ、練習の形は時計から再構成され、プランからは決して再構成されない。逆をやりたくなるし（プランに5 x 1000mと書いてあるのだからそう書けばいい）、それがまさに間違いだ：狙いは、私が別のことをやった日を検出することにある。両者が食い違うとき、その食い違いこそが情報であり、コーチはそれを見る：

予定 3 x 8' → 連続走で実施

始める前に、2つの注意点。

StravaのAPIは2026年6月から有料の開発者サブスクリプションを必要とする。 それがないと、どの呼び出しも403 Application Status Inactiveを返す。代替手段はあり、テンプレートにも組み込まれている：時計からTCXファイルを書き出し、import_tcx.pyに渡す。取り込みより下流はすべて同じように動く。

クォータは十分だが、実在する。 私のアプリケーションでは、読み取りが15分あたり300リクエスト、1日3,000リクエスト。スクリプトは定常状態で1周あたり1つしか使わないので、1日96だ。上限にはまるで届かないが、こういうものは後ではなく先に確認する類のものだ。

ステップ2：スクリプトが署名付きでエージェントを起こす

ここからが面白いところだ。

webhookは質問の逆だ。5分おきに新しいものがあるかと尋ねる代わりに、プログラムにウェブアドレスを渡しておくと、出来事が起きたときに向こうからメッセージを送ってくる。何も起きていない間は何も払わない。

AgentsRoomはまさにそれを提供している：webhookトリガーだ。アプリでトリガーを作ると、URLとシークレットが返ってくる。そのURLにJSONメッセージを送った者は誰でもエージェントを起動できる。自分が書いたプロンプトと、メッセージの内容がすでに差し込まれた状態で。

私のスクリプトが送るメッセージは意図的にごく小さい：

{
  "type": "created",
  "title": "03/09 · 5 x 1000m r' 2'",
  "body": "03/09/2026の練習をStravaから取り込みました。\n\nポイント練習：5 x 1000m r' 2'\nスプリット：3'41 - 3'40 - 3'38 - 3'40 - 3'35\n\n合計距離：12.51 km を 1h07'42 (5:25/km)、獲得標高 56 m\n予定していた練習：RP10-5x1000\n\n練習シート：journal/2026/2026-09-03.md\n週シート：plan/weeks/2026-W36.md"
}

ここにないものに注目してほしい：プランの本文だ。webhookが運ぶのは、予定された練習のコードとシートのパスであって、その中身ではない。リポジトリを持つエージェントは自分で読みに行く。持たないエージェントに私の内部指示を渡す理由はない。Stravaに公開する説明文と同じルールだ。

署名と、それに付いてくる罠

エージェントを起動する公開URLを、見つけた人なら誰でも使える状態にしておくわけにはいかない。そこでトリガーには署名が付く：スクリプトは共有シークレットを使ってメッセージの指紋を計算し（用語が通じるなら、HMAC-SHA256だ）、X-AgentsRoom-Signatureヘッダーに載せて送る。サーバー側も同じ指紋を計算し直し、一致しなければ拒否する。

署名がないと、返事はそっけない：

{"error":"REJECTED","message":"Signature missing."}

そして、私に一晩を費やさせた罠がこれだ。署名が覆うのは、実際に回線へ出ていくバイト列そのものであって、メモリ上のオブジェクトではない。ディスク上のファイルに署名しておいて、別のレイヤーにオブジェクトを再シリアライズさせると（スペースが1つ増える、キーの順序が変わる、アクセントのエスケープの仕方が違う）、サーバーが決して受け取らないメッセージに対する、完全に正しい署名ができあがる。この拒否はデバッグ不能だ：両側とも何もかも正しく見える。

修正は一文で済む：シリアライズと署名は同じ場所でやる。テンプレートではpost_json関数が両方を担当し、それ以外はメッセージ本体に触れてはいけないことになっている。

ステップ3：3つのレイヤーが、自分は誰か、ここではどう動くのか、今何をするのかをコーチに伝える

コーチをするエージェントは、大きなプロンプト1つではない。3つの別々のテキストであり、その分離に意味がある。

レイヤー1、ペルソナ：誰であるか

AgentsRoom上でエージェントに紐づけたシステムプロンプト。トレーニング哲学を担っていて、意図的に競技に対して汎用的だ：誰のコーチでもできる。

あなたの仕事は、単にトレーニングプランを生成することではありません。アスリートのトレーニングを分析し、現在のフィットネスを理解し、これからの練習を調整しながら、継続的にコーチングします。［…］モチベーション系のチャットボットではなく、経験豊富なコーチのように話してください。

やらないことも書いてある：練習を「目標ペースを守れたか」だけで判断しないこと、レース予測の不確かさをはっきり述べること、アスリートが望んでいるというだけの理由で目標を承認しないこと。この最後の一行こそがコーチを役に立つものにしている。

自分で書く必要はない：このペルソナはAgentsRoomのエージェントカタログにランニングパフォーマンスコーチとして公開されている。ワンクリックでインストールでき、すぐ使える。

レイヤー2、CLAUDE.md：ここではどう動くのか

これは契約で、セッションのたびに最初に読まれる。ファイル構成、それを一貫させるルール、あらゆる提案を縛るトレーニングの原則、そして何より儀式：練習が報告されたときに実行すべき正確な手順が入っている。

精度の水準が分かるので、一部を引用する：

週が崩れたときに削る順番： まずジョグの追加分、次に補強、次にロング走の長さ、そしてポイント練習を1つ。週まるごとは絶対にない。

ここでコーチはチャットボットであることをやめる。毎回その場で手順を思いつくのではなく、私が一度だけ書いた手順に従う。テンプレートのリポジトリからファイルを1つだけ読むなら、これを読んでほしい。

レイヤー3、トリガーのプロンプト：今何をするのか

練習が届いたときにエージェントへ渡されるメッセージだ。アクティビティはテンプレート変数で受け取る：{{event.title}}、{{event.body}}、{{event.url}}。だからエージェントは、練習を探しに行くのではなく、すでに手にした状態で始まる。

トリガーに入っている、その骨格がこれだ：

Stravaから新しい練習を取り込みました。

**{{event.title}}** · アクティビティ {{event.id}}
{{event.url}}

{{event.body}}

---

あなたは`training-plan`リポジトリにいます。まず`CLAUDE.md`を読むこと：それが法です。
私の言語で書き、全体を通して私に直接語りかけること（§3）。

§6の儀式が適用されますが、その**ステップ1はすでに完了しています**：`strava_publish.py`
が練習シートを作成し、コミット済みです。あなたはステップ2から再開し、最後まで
やり切ります。成果物は3つ、この順番で：**リポジトリ内の分析**、
**Stravaアクティビティ下のコメント**、**メール**。

⚠️ **あなたは無人で動いています：質問を読む人はいません。** 判断を仰がない
こと：自分で決め、自分で動き、何をどう決めたのかとその理由を報告に書くこと。

## 1 · 分析とプランの調整（§6の儀式、ステップ2から6）

1. まず`git pull --rebase`：シートはサーバー側から来ているかもしれません。
2. この順で読むこと：今日のシート、週のシート、
   `athlete/zones-and-paces.md`、そして**直近3回の練習シート**：
   練習は決して単独では判断しません。
3. `## Analysis`セクションを書くこと：**まず結論**、次にそれを支える兆候、
   最後にそれが何を変えるか。
   ⛔ `## Analysis`がすでに埋まっている場合は書き直さないこと。
4. 週のシートを更新し、**すべての**プラン変更を`## Adjustments`の下に
   理由付きで記録すること。
5. **`README.md`を再生成すること**：私がスマートフォンで読む画面です。
6. コミットとプッシュ、パスは明示的に、⛔ `git add -A`は絶対に使わないこと。

## 2 · Stravaでのkudosとコメント
   ⛔ Stravaのコメントは公開されます：目標心拍なし、不調の話なし、
   内部的な判断なし、予測タイムなし。

## 3 · メールでの完全なレポート

いちばん働いている行は真ん中にある：「質問を読む人はいません」。画面の前に誰もいない状態で動いているエージェントが判断を仰ぐのは、間違いを犯しているのではない。ただ止まるだけで、それに気づくのは翌日になる。

どのモデルを使い、なぜ100万トークンが見栄ではないのか

長いコンテキストは飾りではない。1回の練習をきちんと判断するために、コーチは今日のシート、週のシート、基準ペースの表、そして直前の3回の練習を読む。練習は決して単独では判断できない：積み上がった負荷、日々の並び、進行中の要注意事項によって、結論はまるごと変わる。2時間のロング走の翌日の3'38が3本と、休養日の翌日の同じ3'38は、同じ物語を語らない。

自律モードはいい加減さではなく、必然だ：画面の前に誰もいない実行には、git pushを承認する人がいない。そしてブラウザアクセスは、エージェントがStravaにコメントしに行き、メールを送るために必要なものだ。ここではどちらにも便利なAPIがない。

自動化したもの、そして意図的に自動化しなかったもの

これは私がいちばん気に入っている設計判断で、見落とされやすい。

取り込みの処理は記録して公開するだけで、決して判断しない。

判断を始めたスクリプトは、文脈のない結論を、誰も読み返さないコードに固まったロジックで量産することになる。判断するとは、週の負荷、今の状態、前回言ったことを同時に抱えることだ：それはコーチの仕事であり、資料一式を目の前に置いたエージェントがやる。

実務上の利点はすぐ効いてくる：エージェントが動かなかったとき（マシンが落ちていた、APIが不調だった）でも、シートは残っている。失われるものはなく、足りないのはコメントだけで、リプレイすれば済む。

同じ方向のもう1つの選択：スクリプトは、すでに処理したものを知るための状態ファイルを持たない。正となるのはStrava上の説明文だ。 空なら書き込み、自分の署名が付いていれば飛ばし、空でなく署名もなければ、あなたが書いたものなので触らない。ローカルの状態ファイルは、別のマシンが何をしたかについて何も言えなかっただろう。この方式なら、2台のマシンが並行して動いても踏み合わない。

分離のルールがあと2つ、リポジトリに刻まれていて、迂回してはいけない：

• Stravaに公開する説明文はプランの本文を決してコピーしない：私の週のシートには目標心拍やトレードオフが入っていて、公開アクティビティに載せる筋合いがない。
• 手で書かれた説明文は決して上書きしない。

アクティビティの下に届くコメント

狙いは自画自賛ではない。コーチの結論が、リポジトリを開かずに、アクティビティの下でスマートフォンから読めること、そしてそれが練習に紐づいたままずっと残ることだ。

だからコメントは意図的に狭い：結論を表す絵文字、それを支える数字、そして次の練習に対して何が変わるか。250文字ほど。

✅ 目標3'38-3'44に対して5本を平均3'39、心拍もブロック全体でフラット。ペース表は妥当。金曜はジョグのまま：今週の余力は使い切った。

心拍や、私が挙げた要注意事項や、来週の距離をどうするかという判断が入った長いバージョンは、リポジトリとメールに行く。2つのチャンネル、2つの読者、その境界を保っているのはプロンプトだ。

本番でしか壊れない3つのこと

これらの行はどれも、それがないときに何かが壊れたから存在している。記事の残りより教訓的だ。

1. ブラウザを固定する。 私のChromeには2つのClaude拡張が接続されている。エージェントがどちらを掴むかは保証されないし、Stravaのセッションを持っているのは片方だけだ。結果：2回に1回は、エージェントが間違ったブラウザの中で、ログアウト状態で、何にもコメントできずにいた。デバイスIDによるブラウザの選択はセッションをまたいで保持されない：だからそれはプロンプトの中に置くべきで、どちらを選ぶかユーザーに聞きに行くことは明示的に禁じておく。無人運転では、質問はデッドロックだ。

2. Stravaのコメント欄にはmaxlengthがない。 ブラウザ側には長く書きすぎるのを止めるものが何もない：送信時に拒否するのはサーバーだ。600文字の見事な段落を書いたエージェントは、それを全部打ち込み、「投稿」を押し、理解できない失敗を食らう。だからプロンプトは、書き始める前に短さを課し、そのうえで失敗した場合に備える必要がある：送信に失敗したら短くして投稿し直す、決して2つのコメントに分けない。

3. 1つのアクティビティにコーチのコメントは1つ。 テストのためにイベントをリプレイすると（最初のうちはよくやる）、このルールがないとエージェントは処理済みのアクティビティにコメントを積み上げる。だからプロンプトでは、書く前に「コメント」タブを読ませ、すでに自分のコメントがあれば見送らせる。リポジトリ側も同じ考えだ：## Analysisセクションがすでに埋まっていれば書き直さない。

かかる費用

この構成にはトークン単位で課金されるAPIキーがない。これがいちばん過小評価されている点だと思う：同じものを従量課金のAPIで作っていたら、練習のたびにメーターが回っていて、たぶん私は使い続けなかった。

今週末に作る

手順を順番に。StravaのアカウントとClaudeのサブスクリプションがすでにあるなら、一晩を見ておけばいい。

1. テンプレートをクローンして自分のものにする。

git clone https://github.com/AgentsRoomDev/running-performance-coach.git my-coach
cd my-coach
rm -rf .git && git init

コピーはプライベートにすること。 トレーニング記録には健康データが入る：心拍、睡眠、故障。テンプレートは公開されているが、あなたのコピーはそうであってはいけない。

続けて、この順に埋めていく：athlete/profile.md（ランナーとしてのあなた）、athlete/records.md（自己ベスト）、athlete/constraints.md（実際に確保できる時間帯）、athlete/zones-and-paces.md（基準ペース）、plan/objective.md（レースと目標）、そしてCLAUDE.mdでは{{...}}のプレースホルダーをすべて置き換える。

最後に、Claudeエージェントでリポジトリを開いてこう言う：「CLAUDE.mdとathlete/を読んで、最初の1週間を作って。」

2. Stravaをつなぐ。

cp .env.example .env && chmod 600 .env
python3 scripts/strava_oauth.py     # ブラウザで1クリック、最初の1回だけ
python3 scripts/strava_sync.py --dry-run

--dry-runは、何も書かずに、書き込まれる内容を表示する。練習の再構成が自分に合っているか確認するのはこのタイミングだ。

3. AgentsRoomでトリガーを作る。 TriggersからNew trigger：

AgentsRoomがURLと署名用シークレットを発行する。両方を.envに入れる：

WEBHOOK_URL=https://agentsroom.dev/api/triggers/t_xxxxxxxxxxxx
WEBHOOK_SECRET=whsec_xxxxxxxxxxxxxxxxxxxxxxxx

4. 信用する前にテストする。

python3 scripts/webhook_replay.py scripts/examples/webhook-session.json --dry-run
python3 scripts/webhook_replay.py scripts/examples/webhook-session.json

これは、次の練習を待たずに、そして自動処理の状態にも触らずに、練習をトリガーへ流し込む。✅ HTTP 202が表示され、AgentsRoomにエージェントのタブが開くはずだ。

5. 15分ごとに動かす。

bash scripts/systemd/install.sh          # Linuxサーバー上で

oneshotユニットとタイマーの組み合わせだ：常駐プロセスはなく、マシンが落ちている間に飛ばした周回は次の起動時に取り戻す。

常時稼働のマシンがないなら、この手順は飛ばしていい：気が向いたときにstrava_sync.pyを手で走らせるか、会話の中でエージェントに練習内容を話すだけでもいい。CLAUDE.mdの儀式は同じように働く。失うのは自動化であって、コーチではない。

ランニングを超えて、ここから持ち帰るもの

この構成にランニング固有のものは何もない。示しているのは、個人的なデータが溜まっていて、それについて有能な意見が欲しい、というほぼあらゆる領域で使い回せるパターンだ。

部品は3つ、それだけだ。MarkdownファイルのGitリポジトリを、機械にもあなたにも読める記憶として。エージェントを起こすイベントを、ループで問い合わせて無駄にトークンを燃やすエージェントの代わりに。3つの設定レイヤーが、エージェントが誰か、あなたのところでどう働くか、今この瞬間に何をすべきかをきれいに分ける。

「ランニングの練習」を「銀行の明細」「コーディングのセッション」「血糖値の測定」「読書メモ」に置き換えてみてほしい：仕組みは変わらない。

よくある質問

AIランニングコーチを作るのにコーディングの知識は必要ですか

ターミナルでコマンドを1つ実行できて、テキストファイルを編集できれば十分です。テンプレートのリポジトリはそのままクローンでき、Pythonスクリプトは標準ライブラリしか使っていません（pip installは不要です）。コーチングの部分は、Markdownファイルにふつうの文章を書いて設定します。本当の作業は技術的なものではありません：ランナーとしての自分が何者で、何を目指しているのかを正直に書くことです。

月額でいくらかかりますか

エージェントはすでに持っているClaudeのサブスクリプション（ProまたはMax）で動きます：トークン単位で課金されるAPIキーはありません。加えて、15分おきにStravaを見に行くための常時稼働の小さなマシンがあると便利です。VPSなら月5ユーロ前後、Raspberry Piなら0です。プライベートなGitリポジトリは無料です。残るのはStrava APIで、2026年6月から有料の開発者サブスクリプションが必要になりました。

なぜデータベースではなくGitリポジトリなのですか

履歴が、コーチにとってもあなたにとっても読めるものになるからです。1回の練習が1つのMarkdownファイル、プランの変更1つが理由付きの1コミットです。エージェントは3週間前に自分が処方した内容を読み返して、それがうまくいったかを確認できますし、あなたはインターフェースを1行も書かずに、スマートフォンのGitHubアプリでプランを読めます。

webhookとは、簡単に言うと何ですか

webhookとは、あなたが呼びに行くのではなく、向こうから呼んでくれるサービスのことです。5分おきに新しいものがあるか尋ねる代わりに、プログラムにウェブアドレスを渡しておくと、出来事が起きたときに向こうがメッセージを送ってきます。ここでは、練習を取り込むスクリプトがそのメッセージをAgentsRoomに送り、AgentsRoomが1秒とかからずClaudeエージェントを起動します。この構成が安上がりなのもそのためです：ループで問い合わせるエージェントは毎ターン、トークンを消費しますが、webhookトリガーは何も起きない限り何も費用がかかりません。

ランニング以外のスポーツでも使えますか

使えます。取り込み処理は時計のラップを再構成しますが、自転車も水泳もラップを記録します。変わるのは戦略のファイルと練習カタログで、どちらも書き換え可能なテキストです。仕組み（取り込み、webhook、エージェント、リポジトリ）は動きません。

エージェントが間違えてプランを壊してしまうことはありますか

間違えることはありますが、大して壊せません：エージェントが書くものはすべて、読んで、反論して、取り消せるGitのコミットです。CLAUDE.mdファイルは、履歴を書き換えること、あなたが提供していないデータをでっち上げること、理由を記録せずにプランを変えること、医学的な助言をすることを明示的に禁じています。痛みが怪しければ、専門家のところへ行くよう促してきます。

---

テンプレートのリポジトリはこちら：AgentsRoomDev/running-performance-coach。クローンして自分のペースを埋めれば、コーチができあがる。エージェントを起こす部品を見たければ、webhookトリガーのページで説明している。AgentsRoomのダウンロードはこちら。