AIエージェントとGitで回すパワーリフティングトレーニング
Language: 日本語
昨年、ジムに入会してパワーリフティングを始めました。スクワット・ベンチプレス・デッドリフトの3種目で挙げた重量の合計を競う競技です。
パワーリフティングでは、いまの目的に合わせて数週間から数ヶ月の計画を設計するのが一般的です。負荷を細かく調整することもあり、その結果、同じ種目でもセッションごとに重量や回数が変わることもあります。組んで、練習して、記録と突き合わせて、計画を直す。そのループを、私も回しています。
今までは、紙のノートやスプレッドシートに計画や記録を書いていましたが、どれもしっくりきませんでした。なぜしっくりこないのか、自分はどういったトレーニングノートが欲しいのか、先日改めて要件を考え直してみました。
この記事はその暫定解です。要件を一言でいえば、トレーニング計画を実験計画として扱い、その実験ノートとして機能すること。いまは一つのGitリポジトリを基盤に、エージェントとの対話で、計画・実行・振り返り、次の計画までを回しています。まだこの仕組みで回す最初の計画の途中です。リポジトリ自体は個人情報やコーチからの指導内容も含むため非公開ですが、構造と考え方は見せられます。題材はパワーリフティングですが、書いているのは計画と結果を突き合わせて自分で改善ループを回す仕組みの設計です。そのどこにAIエージェントを入れて、どこには入れないか。この部分は、題材が変わっても同じだと思います。
トレーニング計画は実験計画である
計画の組み方にはよく知られている理論がいくつかありますが、最適な内容は人によって異なり、同じ人でも時期や課題によって変わります。少なくとも自分に合う形は、仮説を立てて試し、結果を見ながら探っていくほかないと私は考えています。だから計画と実績を、実験ノートとして残しています。
計画は仮説です。何を試すか、何を検証したいか、計画の期間中にどの指標を観察するかを設計時に書きます。日々のログはデータで、ブロック (計画を区切る数週間単位) 末のRM (所定回数で挙げられる最大重量) 測定や大会記録が結果。計画が終わったら、仮説とデータを突き合わせて所感を書き、それが次の計画の設計に入力されます。リポジトリの構造は、このループをそのまま写したもので、仮説が plans/、データが logs/、結果が meets/ です。
メニューを消化すべき予定として扱うと、狙った重量と回数が挙がらなかった日は、それだけで「失敗」と評価されます。しかし、次の計画を正確に立てるには、未達の原因が実行にあったのか、計画にあったのかを切り分けなければなりません。実験として扱うなら、評価すべきことは2つに分かれます。「計画を守れたか」(実行度)と、「計画が正しかったか」(計画妥当性)です。この2つを区別するには、計画とのズレを正しく記録することが前提になります。
計画と実績に差が出たとき、見直すべきなのが実行とは限りません。計画したボリューム (セット数×回数) をこなせなかった日でも、原因が体調なら、次の計画重量を下げるのではなく、コンディションがよい状態でもう一度試します。逆に、計画より重い重量を狙いより楽に挙げられた日は、実行に余力があったということで、計画のほうが保守的すぎた可能性があります。計画と実績だけでなく当日の状態も残すことで、見直すべきなのが実行なのか計画なのかを切り分けられます。
専用アプリを作りかけて、やめた
実験ノートとして計画と実績を残すなら、それを扱う器も要ります。紙とスプレッドシートの次に試したのは、専用アプリを自分で作ることでした。
作っていたのはRxというトレーニングデータのバックエンドです。GoのAPIサーバーとNext.jsのWeb UI、PostgreSQLという構成で、Protocol Buffersのスキーマから、gRPCとgrpc-gatewayのコード、そしてOpenAPI定義を生成するスキーマファーストの設計。約2ヶ月半で753コミットも作り込んでいました（とはいっても、実装の大半はClaude CodeとCursorに任せていたのであまり労力はかかっていませんでした）。
問題意識ははっきりしていました。多くのトレーニングアプリはsets × reps × weightなど固定スキーマを前提にしていますが、実際のプログラムにはテンポ指定、目標RPE(主観的運動強度)、ポーズの長さ、セット間のインターバルなど、アプリが用意していない情報が必要になります。スプレッドシートがリフターの間で根強く使われる理由の一つは、このスキーマの自由さにあると考えています。Rxはこの自由度と構造化の両立を「固定の構造化コア + ユーザーが定義できるフィールド」という設計で解こうとしていました。計画と分析は最初からエージェントの仕事と割り切り、Rx自身は解釈をしないデータストアに徹する構想です。
やめた理由は、作りながら気づいたことにあります。計画を実験として回すなら、記録したい情報そのものが計画ごとに変わります。ある計画ではワイドデッドリフトの足幅や角度を変えて検証していたり、別の計画ではセット間のインターバルを変えてみたり、どのペースで減量するとどれだけパワーが落ちるかを細かく残したくなったりします。コアに無いものはユーザー定義フィールドとして足せば設計上は足ります。ただ、計画ごとに知りたいことが変わるなら、計画をまたいで固定するコアの構造にどれだけ意味があるのか、という疑いが残りました。知りたい情報ほどユーザー定義フィールドに乗り、その数が増えれば、機械的な集計もUIの設計もしづらくなります。DBであることのメリットが薄くなっていきます。
もうひとつは、エージェントの位置です。読み書きの境界に常にエージェントがいるなら、永続層そのものに厳密なスキーマを持たせなくても、書き込み時にMarkdownの規約へ整形できます。計画と分析がClaude Codeの仕事なら、真ん中のバックエンドを抜いて、Markdownを直接読み書きさせればよいのです。なくなったのはスキーマではなく、スキーマを所有する専用バックエンドでした。バリデーションと整形の責任を、DBの固定スキーマから、エージェントが書き込み時に適用する規約へ移したほうが、探索中のノートとしては良いと判断しました。
もちろんトレードオフもあります。入力の手間だけを比べれば、対話より専用フォームのほうが少なくて済みます。それでも自由度を取りました。いまは記録のスキーマ自体を探索しているフェーズです。
計画と実績を突き合わせられる形
自由形式と言っても、なんでも散文で書いているわけではありません。実験ノートを一緒に書くのはエージェントなので、構造はエージェントに読ませる前提で決めています。実験のループを写したデータと、エージェントがそれを扱うためのコントロールプレーンを、同じリポジトリに置いています。
.
├── plans/ # 仮説。1計画 = 1ディレクトリ
│ ├── 2026-05/
│ │ ├── plan.md # 計画の設計文書（設計判断・変更ログを含む）
│ │ ├── b1w1d1.md # 1セッション = 1メニュー（ブロック・週・日）
│ │ ├── b1w1d2.md
│ │ └── ...
│ └── ...
├── logs/ # データ。1セッション = 1ログ
│ ├── 2026-05-05.md
│ ├── 2026-05-06.md
│ └── ...
├── meets/ # 結果。1大会 = 1ファイル
│ ├── 2026-04_東京都大会.md
│ └── ...
├── CLAUDE.md # 全ユースケース共通の規約
├── .claude/skills/ # ユースケースごとの手順（5つ、後述）
├── context/ # 自由記述のメモ
│ ├── 2026-04-26_フォーム指導.md # コーチングやセミナーの記録
│ ├── プログラム設計方針.md # 理論や方針のまとめ
│ └── ...
└── docs/
└── decisions/ # 仕組みの意思決定。1決定 = 1ファイル
├── 2026-07-18_意思決定記録の4層化.md
├── 2026-07-19_伴走モードの開始フローと提示単位.md
└── ...スキーマは消えたわけではなく、CLAUDE.mdの規約として残っています。規律の線引きはディレクトリ境界と一致させています。plans/とlogs/とmeets/はフォーマット厳守、context/とdocs/は自由形式。集計や突き合わせの対象になるデータは構造を保ち、コーチに教わったことのメモのような一回性の情報は自由に書きます。ログのfrontmatterには所属する計画とセッション名を持たせ、対応するメニューファイルへたどれるようにしてあります。実物はこういう形です。
---
date: 2026-07-24(金)
cycle: 2026-05
session: b2w2d3
---
## 記録
| 種目 | 区分 | RPE | weight | reps | sets | note |
|------|------|-----|--------|------|------|------|
| ナローBP | トップ | 6 | 110 | 1 | 1 | 計画107.5より重め |
| ナローBP | メイン | 6 | 100 | 4 | 1 | 計画97.5より重め |
| ナローBP | バックオフ | - | 90 | 4 | 6 | 計画87.5より重め。2–4setはリストラップなし |
| ローバーSQ | トップ | 8 | 205 | 1 | 1 | 計画200より重め |
| ローバーSQ | メイン | 6 | 175 | 6 | 1 | 計画172.5より重め |
| ローバーSQ | バックオフ | - | 155 | 6 | 2 | |
| DBプレス | - | - | 30 | 10 | 3 | 計画通り |
**ナローBP — バックオフ**: 手の乗る位置を確認するためにリストラップなしでもやってみたが、手首に少し怖さあり。脇を開くと手首が寝るが、寝ないように締めると手首が痛くなる
**ローバーSQ**: トップはハムと尻で受ける意識でゆっくりやりすぎ、ボトムのハネを完全に殺していた。メイン以降は修正。今日は背中の乗りがいまいち
## セッション総括
- ナローBP: 計画より重め。リストラップなしでの手首と、脇の開きのいいバランスが見つかっていない。
- ローバーSQ: ハム・尻での重さの受けは意識できたが、やりすぎるとボトムでハネを殺しすぎてしまう。メイン以降は修正できた。背中の乗りは課題。
- DBプレス: 計画通り
## 次に試したいこと
- ナローBP: リストラップなしでの手首を継続観察。脇の開きと手首角度のバランスを探る
- ローバーSQ: ハネを殺さない範囲でハム・尻の受けを意識する。背中の乗り位置を次回確認これはログのフォーマットです。計画側のメニューファイル (この例ならplans/2026-05/b2w2d3.md) もほぼ同じ表にそろえていて、weightやRPEの列に計画値が入っています。そうすることで計画と実績の突き合わせが容易になります。区分列のトップ・メイン・バックオフは、その日の最重量セット、主となるセット、重量を落として量を積むセットです。- は「値なし」の印で、区分が該当しない補助種目や、狙いRPEを置いていないバックオフのRPEに入ります。やらなかった種目も行を消さず、weight と reps を - にして理由をnote列に書きます。行がないだけでは「記録がない」のか「やらなかった」のか分からないからです。
note列に載せるのは、計画とのズレのような短い事実です。フォームの所感やコーチングの指摘など、表に収まらないものはテーブルの直後に種目名付きで残します。末尾の「セッション総括」と「次に試したいこと」が、その日の判断と次セッションへの申し送りです。
空欄をエージェントに埋めさせてしまうと、実行度も計画妥当性も評価できなくなります。だからCLAUDE.mdに「推測で埋めない」と書いてあります。事後入力で開始・終了時刻が分からなければ日付だけにする、体感RPEを覚えていなければ - のままにする、と明示してあります。
「フォーマット厳守」といっても、実体はMarkdownの見出しと表です。次の計画で記録したい列が増えたら、次の計画から変えれば済みます。過去データを書き換えるマイグレーションはせず、計画ごとの形式差はエージェントに読み分けさせます。差が増えてきたら、その読み分け方をSkillやCLAUDE.mdに書き足します。この規模なら、複雑さを読み取り側へ寄せるほうが安い、という判断です。
トレーニング結果は、エージェントとの対話の中でログ形式に整え、そのままコミットします。口述やメモ書きによる報告をlogs/に保存し、コミットしてプッシュするところまでが1回の対話です。専用の入力システムはなく、Gitの履歴が入力イベントの記録を兼ねています。ジムではスマホからClaude Codeを開き、セット間のレスト中に入力しています。
判断は対話の外へ書き戻す
ログにその日の所感や次に試したいことが残っても、なぜその計画にしたかの経緯、つまり実験意図までは残りません。計画妥当性を後から評価するには、それも一次記録として残す必要があります。
計画の設計はエージェントとの対話で行いますが、そこで検討して却下した案を、次のセッションが確実に引き継ぐとは限りません。Gitのdiffも「何を変えたか」しか表現しません。だから、決定とその理由は対話が終わる前にノート側へ書き戻す、という規律を敷いています。記録場所は意思決定のレイヤーで決めています。
| レイヤー | 例 | 記録場所 |
|---|---|---|
| 実施時の単発のズレ | その日だけ重量を下げた | ログのnote列 |
| 計画の開始後の変更 | 運用ルールの入れ替え、以降のメニューの書き換え | plan.mdの「変更ログ」 |
| 計画の設計時の判断 | ブロック構成・種目選定・目標値の決定 | plan.mdの「設計判断」 |
| 仕組みに関する意思決定 | Skillや規約の変更。変更しないと決めたことも含む | docs/decisions/ (1決定 = 1ファイル) |
「検討した結果、変更しないと決めたこと」も1つの決定として記録します。次に同じ疑問を持ったとき、再検討をゼロからやり直さないための一次データです。決定ファイルは追記型で運用し、過去の決定を覆すときは新しいファイルを作って新旧を相互リンクします。
人間同士なら記憶や口伝でなんとなく引き継がれていたようなものが、対話が毎回リセットされるエージェントとの運用では、書いていないものは存在しないのと同じになります。逆に言えば、書いてさえあれば、次の対話は前回の検討の続きから始められます。
手順はSkillにする
この運用は、ユースケースごとにAgent Skill (Claude Codeが用途に応じて読み込む手順書) へ分けています。全ユースケース共通の規約はCLAUDE.mdに置き、ユースケースごとの差分を各Skillに置いています。
現在用意しているのは5つ。計画の設計 (design-cycle)、ジムでの伴走(live-training-session)、事後の一括入力(log-training-session)、大会記録(meet-record)、計画の終了後のレビュー (review-cycle)です。伴走と一括入力の2つは日常的に使っていて、計画の設計はいまの計画の作成で使いました。大会記録と計画の終了後のレビューは、最初の計画が終わっていないのでまだ回していません。レビューの出力が次の計画の設計の入力になるよう接続してありますが、この接続が実際に動くのはこれからです。Skillのつながりが、実験のループそのものになる設計です。
伴走で効いているのは手順そのものより、各ステップに置いた制約のほうです。セット間の休憩は疲れているので、応答は数行以内、確認は数値が曖昧なときだけ、解説も励ましも要約も不要、と書いてあります。計画とのズレ——重量やrepsの変更、種目の差し替え、途中打ち切り——はnote列に理由付きでそのまま記録し、正規化も削除もしません。報告を受け取ったエージェントが、計画に合わせて数値を丸めたり、逸脱を要約で消したりしないよう、書き込みの瞬間に効かせるための一行です。
紙のノートやスプレッドシートから何が変わったか
この形で運用を始めてから日が浅く、競技成績が伸びたと言える段階ではありません。いま確かに変わったのは、計画を立てる手間と、記録の使われ方です。
まず、計画のメニューを立てる時間が短くなりました。計画には、コーチから指摘されたこと、前の計画で自分が感じた手応え、そのとき何がうまくいかなかったかを反映したい。ところが、これらは時間が経つと忘れます。紙のノートのときは、思い出すためにノートを遡って読み返す必要があり、その手間が計画づくりの前に置かれていました。さらに、RPE基準でメニューを組むと、目標RPEとレップ数から実際に扱う重量への換算が種目ごとに発生します。一つひとつは小さくても、セッションの数だけ積み上がる作業です。いまはコーチング記録も過去のログも同じリポジトリにあり、エージェントがそれらを読んだうえでメニュー案を出してくるので、この2つがまとめて減りました。
次に、記録の検索性が上がりました。ある部位に痛みが出たときや、フォームのバランスが崩れていると感じたときに、過去に同じ症状が出ていなかったかをすぐに調べられます。出ていたなら、その前後でどういったメニューをやっていたか、何を意識してやっていたかまで、ログをたどれば分かります。原因が練習ペースにあるのか、フォームにあるのかを、記憶ではなく記録から推定できるということです。紙のノートにも同じことは書いてありましたが、手動で網羅的な検索をかける手間を考えると、実際にはやりませんでした。同じ検索が練習の最中にも効きます。セットに入る前にエージェントに聞けば、コーチング記録と過去のログから、今回の練習で意識すべきことを教えてくれます。
ただし、エージェントに判断そのものをさせているわけではありません。引き出しているのは、コーチの言葉と自分の記録に根拠がある情報だけで、一般論としてのアドバイスはさせないようにしています。メニュー案も、コーチから教わった考え方と過去のログから組み立てたものとして出させ、最終的にどうするかは自分で決めます。
そして、こうした使い道が見えてきた結果として、ノートに書き込む情報量が紙のときより増えました。書いたものが後で引かれると分かると、書くコストを払う気になります。量が増えれば突き合わせられるデータも増えるので、次の仮説を立てるときの材料は、紙のときより厚くなっている実感があります。
まとめ
振り返ると、「トレーニング計画を実験計画としてとらえよう」と決めた時点で、この運用のおおよその形も決まっていました。実験だから、記録したい情報の変化に合わせられるよう、固定スキーマを持つ専用アプリをやめました。実験だから、計画との差を正確に残し、実行度と計画妥当性を分けて評価します。そして実験だから、判断とその理由を一次記録として残し、次の計画の設計につなぎます。
AIエージェントを入れた場所も、この線に沿って決まりました。入れたのは、報告を規約どおりの形に整える書き込みの境界、過去のログとコーチング記録を引き出す検索、それらを材料にしたメニュー案の起草です。入れなかったのは、空欄の推測、計画とのズレの正規化、根拠のない一般論、そして最終判断です。記録の正確さを守る側にはエージェントを置き、仮説を選ぶ側には置かない。この線引きは、題材が変わっても持ち越せると思っています。
専用アプリという選択肢を捨てたわけではありません。記録のスキーマや手順が安定したら、その時点で固まった形に合わせてアプリ化を考えればよいでしょう。いまの運用は、その意味で実験ノート自体のプロトタイプでもあります。スキーマを固定するのは、探索が一段落してからでいい。少なくとも今は、その順番がよいと考えています。