🗻 Claudeコーチと富士山クライムラン2026を走りきった

こんにちは、 @Katonium0615 です。

Claudeをコーチにして、2026年9月13日の富士山クライムラン2026を 103分23秒 で完走しました。Claude Coachですね。

第3回富士山クライムラン【公式】

2026年9月13日（日）に開催される第3回富士山クライムランの【公式】サイトです。当サイトではコースマップ、エントリー情報などご覧いただけます。

mtfujiclimbrun.com

Claudeと相談した立てた計画はかなりの精度で当たっていたものの、本番にはいくつかのトラブルがありました。なんとか目標にしていた110分を無事クリアすることができたので、やったことのまとめと次回に向けた反省としてブログを書いています。

おしながき

前提：富士山クライムランというレース

富士山のふもとの富士北麓公園から富士山五合目までの11.9km・1,228mの登りを一気に駆け上がるトレイルランレースです。スタート地点の標高が約1,004m、フィニッシュが約2,232m。制限時間は180分ですが、110分以下でゴールできると翌年の富士登山競争のエントリー資格がもらえます。トレイルランははじめてでしたが、この110分を目指してレースに臨みました。

Claudeコーチとやったこと

はじめてのトレイルランレース、右も左もわからない状態で良いタイムを出すために、Claudeコーチとレースプラント3ヶ月間のトレーニングプランを立てました。Claudeにやってもらったことは大きく分けて5つです。

やったこと①：公式GPXを読ませてコースを分解する

まずはコースを知らないと話にならないので、過去の感想者のブログや公式サイトをClaudeにリサーチさせ、コースの情報を整理していきました。

• 大会公式サイトの大会要項
• 完走者のレポートの区間ラップ
• コースのGPXトラックログ（2024年6月の試走、1,515点）

コースのGPXが公開されているのは本当にありがたく、コースの距離・高度と時刻がわかるので実際にどのくらいの登りをどのペースで走ればよいのかについてClaudeが非常に精度高く予想してくれるようになりました。それまで「富士山を12km登る」というぼんやりした理解だったのが、区間ごとの数字に分解されます。

（この表は後述の理由で、当時渡した数字ではなくブログ執筆時に国土地理院のDEMをベースに引き直した値です）

もちろん各区間がずっとこの斜度ではないものの、コースをざっくりいくつかの区間に分けそれぞれに対策を行うことができるようになりました。

出てきた分析はHTML形式で成果物として出させて、一緒に出る仲間と共有しました。

やったこと②：タイムと心拍の計画を作る

コースが数字になったので、次は計画です。

いわゆる一般的なマラソンとトレイルランレースで違うのは、常に傾斜が代わり続けるトレイルランレースでは速度でペースを管理できないことです。コース自体が斜度0%から20%まで変わりますし、山道に急に平地が現れることもあります。トレイルランでは速度の代わりに心拍ゾーンでペースを決めることが多いようで、今回もその方針で計画を立てました。

登坂の能力については VAM（垂直速度・m/h） で管理することにしました。垂直速度の考え方は自転車のレースとかでも使われており、『斜面がキツくてもゆるくても単位時間に登れる高さは同じ』という考え方です。Claudeがこの数値を出してきたときには半信半疑でしたが、比較的一般的な概念のようで過去のレース出場者のペースを見る限りあてはまってそう・トレッドミルで試した感じそこまで外れてなさそうだったので登り区間のペースはこれをベースに設定しました。

必要なVAMは目標タイムから逆算して設定しました。

そのうえで、100分プランと、保険の108分プランの2本を作ってもらいました。

おもしろかったのが、完走者3件のレポートから 「馬返しの通過タイム ＝ ゴールタイムの43〜45%」 という相関を見つけてきたことです。3件しかないので統計的にどうこう言えるものではないですが、当日「馬返しで49〜50分なら108分圏、52分を超えたら110分が危うい」という判断基準が一個あるだけで、走っていて安心感が全然違います。（当日は結局何分で馬返しを超えればいいのか完全に忘れて走ったので意味はなかったのですが）

心拍ゾーンのほうは、年齢29歳・安静時心拍52から推定して組みました。

最大心拍数(推定) = 208 − (0.7 × 29) = 188
心拍予備(HRR)   = 188 − 52 = 136

この188を基準に、前半はZ3中盤（150〜158）に抑える、核心部は158〜168まで許容、ラスト1.4kmは168〜175まで出し切ってOK、という区間別の目標を決めました。トレーニングでは①当日の目標VAMでどのくらいの心拍になるか、②当日の目標心拍を維持したままだとVAMはいくつで何分間走れるか、という両面からメニューを組みました。心拍だけ、VAMだけでなく両面から自分の実力を分析することができたのは非常に良かったです。

やったこと③：トレーニング計画とその日のメニューを立てる

傾斜の異なる3区間を走るレースだったので、トレーニングも平地区間と登り区間に沿ってメニューを組んでもらいました。

毎週ABCを全部やる予定で組みましたが、全然そんなことはできず日々トレーニング前に何分間トレーニングするかを伝えメニューをその場で作ってもらい、週1-2回くらいトレーニングしました。

本番の縮小版のベンチマークテストも何度か実施し、これをもとに目標タイムの予想を常に変えてもらうことで緊張感を持ってトレーニングができました。

速度を固定するのではなく心拍を固定して速度を上げ下げすることで、平坦パートの平均ペースと登坂パートのVAMをそのまま予想タイムに変換できます。

① 平坦区間タイム = 3.8km × 平坦パートのペース(分/km)
② 登坂区間タイム = 1,152m ÷ 登坂パートのVAM × 60
予想ゴールタイム = ① + ②

コースを分析した結果登りは10%の登り区間と15%の登り区間に分かれることもわかったので、途中からは登坂パートを2つに分解してそれぞれ20分ずつで実施したりもしました。

10%の登り（ギリギリ走れる）と15%の登り（さすがに歩き）だと心拍・筋肉への負荷のかかり方も違い当初は同じ心拍数なのに15%パートの方がかなりいいペースで走れるような状況でした。10%パートのケイデンスを調整するなどして、10%パートのペースをあげられるようなトレーニングを重点的に行いました。こういう分析結果をもとにトレーニングにFBがかけられるのはClaudeコーチの導入ならではだなと感じています。

週末は山に本番に近い山を提案してもらい登るようにしていました。実際の山だと路面も異なりますし、傾斜もトレッドミルよりややきつい区間も多く、そして登り切ったあとまだ下りがあるというトレッドミルと違うハードを感じました。 基本はトレッドミル、週末に高尾山など近隣の山々に登りに行くような感じでした。

やったこと④：Garminのログを毎回読ませる

トレーニングをやりっぱなしにしないために、毎回Garminのログを読ませてフィードバックをもらうループを作りました。

これは通常のClaudeやChatGPTだとうまくいかず断念していたのですが、Garminの記録から共有リンクを作成して、それを自宅サーバーで動かしていた OpenClaw のPlayWright MCPで無理やりCSV出力させられることがわかってから使うようになりました。

もらえるフィードバックは、たとえば「この速度に対して心拍が上がりすぎている」「ケイデンスが低くて効率が悪いのでは」といった具合です。自分では「今日はがんばった」と思ってるところに「走り方の効率が悪い」みたいに突っ込んでくるのでもう少し優しくしてほしかったですが。。。

あとは心拍が取れるようになったことで都度 予想ゴールタイム を修正できるようになったのが大きかったです。このフィードバックループをいかに作るのかがトレーニングでは大事そうです。

トレーニングを分析させる中で、平地より登坂区間の方が余裕を持ってはしれていることがわかったので当日のペースも平地は抑えめで、登り区間から頑張るようなプランに調整していました。

当日うまくいかなかったこと

ここまでの準備で当日は完璧…！と思ったのですが、実際は全然そんなことはなく計画は大きく狂いました。

誤算①：心拍がいきなり最大ゾーンに入った

スタートしてしばらくは想定通りに心拍を維持することができましたが、2.2km地点で145から172に階段状に跳ね上がり、そこから最後まで下がることはありませんでした。ゾーン2からゾーン3前半で序盤は走る予定だったので、ゾーン5の心拍がこのタイミングで出るとレースは壊滅です。

オーバーペースにすると最後までもたないことはわかりつつも、想定よりペースがかなり遅い状態で心拍数が上がりきっていたので、『ここで止めないと後半まで保たないが、ここで止まると110分をクリアできない』と、序盤からすでに瀬戸際に追い詰められていました。

ここまで頑張ってきて自分からペースを下げてクリアできないのは悔しすぎるので、無理やりペースをキープすることにしました。練習で心拍数が170まで上がったときの負荷に対してかなり楽に走れているような感覚だったので、12kmくらいならこのまま走り切れるだろうという判断もありました。

事前にトレーニングしていたときにも後半はそこまで心拍への負担はないような印象をもっていたので、前半に心拍数の限界をしっかり使い切ろうと予定通りのペース（ただし予定外の心拍数）で走り続けました。 結果的にはこの判断が当たりました。心拍は上がったままでしたが、最後まで走り切ることができました。

心拍ゾーンがこのあとどう推移したのかを後日集計すると、走行時間の82.5%がゾーン5（174〜192）にあることがわかりました。標高の問題なのか緊張の問題なのかはわかりませんでしたが、実際のキツさをトレッドミルのトレーニングでなんとなく覚えていたのが幸いしました。

ちなみに後から数字を見て気づいたのですが、当日の最大心拍は192でした。計画で使っていた推定値の188を超えています。年齢から計算した 208 − 0.7 × 29 = 188 を超えた心拍数を当日では出すことができていました。もう少し丁寧に当日のペースの設計をしても良かったのかも、というのは反省点です。

誤算②：序盤が平坦じゃなかった

もうひとつ、走っている最中はもっと焦ったのがこれです。

計画では序盤3.8kmは平坦（0.0%）の舗装路ということになっていました。ここをキロ5:24で淡々と走って、中ノ茶屋から登りが始まる、というレースだと思っていました。

ところが当日、序盤の2km地点あたりからもう登りが始まっていきます。一緒に走っていた仲間と「聞いてた話と違うんだけど…」とボヤきながらも、計画にない登りと高い心拍数に焦りはピークに達していました。

走り終わってGPXをプロットしてわかったこと

レース後、改めてコースのGPXをグラフにプロットしなおすことで原因がわかりました。

計測点の総数        1,515
高度の情報を持つ点     1,484
高度の情報が無い点        31  ← 0〜3.80km

サイトにて公開されていたGPXには、序盤の3.8km分、標高のタグがそもそも存在していませんでした。自分で見ればすぐに気づけそうでしたが、Claudeにデータの取り込みからグラフ化まで完全に丸投げしていたので、全く気づきませんでした。平坦なのではなく標高のデータがなかったため平坦として表現されてしまっていました。

当日のGarminの実測値と、国土地理院の標高API も参考にあらためてコースを書き直すと、実際の登りは4km地点よりも早くから始まっていることがわかりました。これは焦りました。

答え合わせと分析

いくつかトラブルはありましたが、トレーニング当初に想定していた『クリアできるとしたらこんなペース』にかなり近いペースで走っていました。

100分プランと108分プランの間くらいのタイムで常に走ることができたので、過去クリアした方々と同じようなペースで走ることができていたようです。

各セクションの目安タイムもClaudeに出してもらっていたのですが、走っている最中は完全に忘れて雰囲気で走っていました。それでこの精度だったので、トレーニングのなかで「このきつさならこのくらいのペース」「ここでこれくらい頑張っても最後まで走りきれる」という感覚のほうが仕上がっていたような気がします。本番ペースでのトレーニングをしておくの大事ですね。

ひとつ外れたのが、最後の急斜面エリア。ここは道が狭すぎて追い抜けないような道だったので、ここで盛り返すプランを組んでいたら詰んでいたなと感じました。

翌年以降に挑戦される方向けに、当日のペースについても記載しておきます。

スタートは 9:51。馬返しを境に 6.9 → 5.4 km/h と落ちているのが、舗装路からトレイル・木段に変わるところです。最後の 0.9km だけ 7.3 km/h に戻っているのは、四合目を過ぎて舗装林道に出るからで、ここはみんな走っていたので、走りました（両足攣りながらでしたが…）。

当日のGarminのGPXデータも公開しておきます。

fuji-climb-run-2026-garmin.gpx（745KB）

この記事の図はすべてこのファイルと、大会サイトで公開されていたコースGPX、国土地理院の標高API から生成しています。

学び

普段の仕事では意識していたのですが、

1. 良質かつ多くのコンテキストをAIと共有すること
2. グラフや数値のような決定的なものは可能な限り生成AIに出力させるのではなくプログラム的に出力すること
3. 生データを自分でも見て、欠損しているデータは勝手に補完させないこと

ということの重要性を改めて痛感しました。

1つ目はもう常識に近い話ですが、今回あらためて実感しました。「富士山を12km登る」から「10〜11kmの22.4%が最急なのでそこは歩く」まで解像度が上がるのは、GPXという一次データを渡したからです。

2つ目、3つ目はわかっていた（特に3つ目は大学時代にも散々言われていた…）ものの、Claude Codeに分析させると結果の共有が面倒で…HTMLアーティファクトを仲間たちと共有する楽さから claude.ai を使っていたのが裏目に出ました。

ちゃんとグラフをプロットさせていれば、データから図が出るようになっていればグラフに穴が開いて気づけていましたね。分析を頼むときは、結論だけでなく、結論を再現するスクリプトも一緒に出させるのがよさそうです。

結び

トラブルはありましたが、Claudeをコーチにしたのはかなり良かったです！練習メニューも、当日のスプリットも、栄養の取り方も、下山後の温泉も提案してもらいました。

来年はふもとから富士山の頂上まで登るレースに挑戦します。今回の反省を活かし、またClaudeコーチと頑張っていきます。