私は『死ぬまでにやることリスト』というのをNotionで管理している。

直近だと「『回らない高級寿司店で特上のものを食べる！』」という項目を達成した。

【人生経験】回らない高級寿司店で特上のものを食べてみよう！【寿司 はな岡】

例によってリストの中にあった

『フルマラソンを完走する』

を2026年1月25日に達成したので、今回はそれをログ的に残しておく趣旨だ。

出場の経緯

まず今回出場したマラソン大会は『第46回 館山若潮マラソン』。

元々は同年2月開催の『京都マラソン2026』に参加したく抽選に応募していた。

というのも『京都マラソン2026』は任天堂がプラチナパートナーとして参戦することが発表されていた。

40周年を迎えるマリオブラザーズがビブスにもあしらわれるということで、それを動機にゲーム好きで陸上経験のある友人と2人で参加しようとしていたのだ。

……ところが、非常に高い倍率を前に残念ながら2人とも落選。

当落が発表された10月末の時点で、既にマラソン練習を始めていたこともあり「このままでは終われない…！」と近い日付のマラソンを検討した。

いくつか候補はあったが、

• フルマラソンであること
• 同じコースを何回も周回する形式でないこと
• 東京から比較的行きやすいこと

などの条件を踏まえて最も良かった代案として、今回の『第46回 館山若潮マラソン』に参加したという経緯だ。

練習期間と内容

前提として当時の私のスペックはこんな感じ

• 30歳 男性 在宅デスクワーカー
• 中学はバスケ部だったが、最後の運動は高校の体育
• 高校卒業以降は10年以上ほぼ運動せず

ガチで久々の運動だったので「流石にヤバイかな？w」などと友人にヘラヘラ喋っていたが、案の定、練習初日3km走っただけで盛大に嘔吐した。

練習期間としては10月頭～1月中旬 くらいまでで、残りは大会までの調整という感じで過ごした。

10月: 基礎的な足作り
11月: 距離を伸ばす
12月: ペースを上げる
1月: 仕上げ＆調整

といって配分だった。

練習0ヶ月（10月）

先述の通り10月頭の練習初日、たった3km走っただけで限界を迎えた時の深い絶望感は今でも鮮明に覚えている。

夜の河川敷を練習場所としていたが、普段まったく家から出ないデスクワーカーとしては景色が広がり星も見える河川敷の風景はかなり心地が良くテンションも上がっていた。

ロケーションも相まって、走り始めは意外なほど身体も呼吸も楽で「意外と走れそう！気持ちいい！」くらいの感じだったが、1kmも走ったら息はかなり乱れ始め、全体が一気に崩れ始めた。

「5kmくらい走るつもりだったけど、初日だし3kmくらいで止めておくか…」とか考えながらひとまず3km走り終えた時には、下半身はガクガク。内蔵が上にあがってる感じがあって、数秒後に嘔吐。

「3km走っただけでこれか…」
「あと39kmあるが…」
「3ヶ月でいけるのか…」

全然行ける気がしてなかった。

いい大人が河川敷で半べそかきながらトボトボと帰路についた初日だった。

練習1ヶ月（11月）

とにかくやるしかない、と様々な記事やYoutube動画などでフルマラソンの攻略法を調べる中で

「フルマラソンの練習にはLSDがおすすめ！」と知った。

LSDというのは怪しいクスリとかではなくで、Long Slow Distance つまり、『長く・ゆっくり・距離を走る』トレーニングのこと

ということらしかった。

この月はとにかく「ゆっくり、時間をかけて、距離を伸ばす」ということに終始した。

2~3日に1度のペースで夜に練習を積み重ねて、3km→5km→8km→10km といった具合で徐々に時間と距離を伸ばしていった。

LSDでは「ペースを上げない、ゆっくり走る」ということが、結果的にステップ数を稼ぎ、脚作りに寄与するということも知った。

この練習は当時の私にとって非常に効果的で、ほぼ歩きみたいなペースで行うため負荷も比較的軽く、しかも距離が着実に伸びていく楽しさがあった。

結果的に効率的に練習を積むことができ、11月の末には30kmのLSDに成功することができた。

もちろん時間は5時間近くかかったし、歩きも混ぜながらの30kmではあったが、兎にも角にも『30km動き続けられた』という事実がめちゃくちゃ自信になった。

練習2ヶ月（12月）

距離は順調に伸ばすことが出来たが、次の課題は速度だった。

館山若潮マラソンは6時間制限かつ、足切りがあるレースだった。

全4箇所の関門を、制限時間以内に突破出来ないと脱落してしまう。

LSDで「動き続ける」ということは出来つつあったが、しっかり速度を守って「走り続ける」ということが次の課題となっていた。

この12月は

• Eペース走（息が大きく切れず、長く走り続けられるスピードで走る）
• ビルドアップ走（走るペースを段階的に上げていくトレーニング）

などに取り組み、「スピードを出す・それを維持する」という方向性でトレーニングを積んでいった。

すると段々と自分のペースが掴めるようになり、

「1km 8:00 なら割と維持できるな…」
「1km 7:30 だと結構キツイな…」
「1km 7:00 だと距離伸ばせないな…」

など1kmあたりどのくらいの時間がかかり、どのくらいキツいかという感覚が養われていった。

また、このあたりからスポーツ整体も通うようになった。

膝の痛みが出始めていたのと、リカバリーを早める狙いだった。

強張っている筋肉や、膝の痛みの原因、使えると有利な部位などをご教示いただき、結果的にいって正解だったと感じている。

練習3ヶ月（1月）

年明け、初週になんと風邪を引いてしまった。

これが厄介なことに長引き、1月は結果的にロング走は2回程度しか出来ず、あとは調整期間という感じになってしまった。

最後のロング走は「24kmを3時間フラットで走れたが、足はもうほぼ限界」といった所感だった。

「このペースを残り18km保つことが出来るのか…？」という不安を抱えてはいたが、ラスト1週間はグッと我慢して休養に集中した。

フルマラソン当日

前泊

このマラソンへの参加が確定した時点で宿を探したが、会場周辺の宿はすでに満室ばかりとなっており、ちょっと離れた木更津駅近くのビジネスホテルで前泊した。

前日の夜は友人のススメでうどんを食べた。

糖質を入れておいた方が良いとのこと。

スタートまで

早朝、木更津駅を出発して、1時間半ほど電車に揺られ、会場から最寄りの「那古船形駅」に到着。

ここから歩いて会場の「福原有信グラウンド館山」に向かう。

会場到着。ここで荷物の預け入れや着替えなどを行う。

割と早めに到着できて写真のような感じの空き具合だが、この後どんどん人が集まり最終的にはフェス会場のような感じだった。

会場のすぐ裏手には海岸沿いの歩道があり、ここでウォーミングアップをする選手が多かった。

我々もアップやストレッチを行い、レース開始に備える。

エントリー時点で申請した、自身の「完走予想タイム」に沿ってブロックごとに区分けされていく（当然私は最後尾のブロックだ）

マラソン開始

凄い人口密度。

5000人の参加者が通りを埋め尽くすスタート地点。

全員自分より速そうな気がして気圧されたり緊張もしたが、もうここまで来たらやれることやるだけだ。

10:00 レース開始。

42.195kmの戦いが幕を開けた。

北条海岸沿いの通りを5000人のランナーが駆け抜けていく。

天気も最高で、波が朝日にキラキラ光るオーシャンビューのコース。

まず驚いたのは沿道の応援の量。

前半10kmくらいまで途切れることなく沿道の人が「頑張れ！」「楽しんで！」と声かけてくれたりハイタッチしたり、こんなにも応援してくれる人が多いんだとかなり驚いた。

次に驚いたのは想像以上のフェス感。

待機列ではわからなかったが、

• コスプレしている人
• 団体で同じ衣装の人
• ほとんど着ぐるみの人
• 動画撮影しながら走っている人

みたいな感じでお祭り騒ぎだった。

背中に「風除け上等！」と書かれた「塗壁」のコスプレをした人が、宣言通り我々の風除けになってくれる時間などもあった。逞しすぎるだろ。

ファンランの部はまた別で用意されているのに、フルマラソンの部でさえもそんな感じで賑やかだった。

マラソン中盤

10km越えた辺りで山間部に入りはじめた。

速さと距離のバランスを取りながら、関門を目指す。

ここから重要になったのが「エイド」だった。

（※画像はイメージです）

個人の体重にもよるが、フルマラソンは2000～3000kcalのカロリー消費がされる。

適切にエイドでカロリー補給しなければ、エネルギー切れを起こしてしまう。

練習中に、その知識が足りておらずハンガーノックを起こしたことがあったので、マラソン当日は胃が許す限りこまめに補給していこうと考えていた。

自身でもエネルギージェルを6パック持っていっていたが、運営が用意してくれていた飴、バナナ、チョコ、ナッツなどのエイドにも非常にお世話になった。これがなければ完走は難しかっただろう。

中盤戦でも多くの出会いがあった

• 応援に毎回大きくリアクションする律儀なおじさん
• グループと離れてしまったのか、電話で連絡を取り合う人たち
• トイレ待ちで並ぶ人
• 途中で倒れて救護されてた人
• リアル猪（本当に野生のやつ）
• 80歳のじいちゃん（ビブスに年齢書いてた）

リアル猪はマジで体当たりとかされたら洒落にならないようなサイズ感で、スタッフが対応する怖い一幕だった。

私個人でいえば猪とちょっと並走するみたいな時間があってガチビビリしてた。お陰でちょっとタイム巻いたかもしれん。

そんな猪さえも抑えて、特に印象深かったのが

47都道府県フルマラソン制覇中のお姉さん

だった。

背中に背負ったパネルには「現在 25県 達成！来週は”愛媛”」と書かれていた。

とんでもないバイタリティだなと感じて、思わず話しかけてしまったが、気さくに会話に応じてくれた。

といった感じで、不躾に話しかけたにも関わらず笑顔で語ってくれた。

なお、スピードは全然遅いとのことだったが、余裕で私よりも速いため、しばらくはこのお姉さんの背中を追いかけることを目標に走っていた。

エイドを入れて、走り出して、坂などでは歩きも混ぜつつ、一つ一つの関門を何とか時間以内に突破していった。

マラソン終了

26kmくらいのところで、エゲつない激坂区間に入った。

山間部の頂上に近いエリアで、キツく、長い坂をほとんど歩きながら進んだ。

永遠のような登りが終わって、沿道のスタッフも「山越えお疲れ様でした！」みたいな声をかけてくれる。

マジでキツかったが、これで市街地の方に戻っていくのかなと思っていたが……それは前座に過ぎなかった。

30kmを越えた時点で、今大会最大級の激激激坂に突入。

先程の山間部で限界を迎えた足腰と、心を折るような急勾配。ここが一番キツかった。

流石に、視界に入る限りの全ての人がこの区間は走るのを止めて歩いていたが、一方で、絶対坂で歩かない黄色い服着たオジサンとかもいて、本当に色んな人が走り方があるなと感じた。

最後の激坂を越え、練習でもやったことのない30km以降の未知の世界。

感覚としては30km時点のキツさが割とそのまま続いていくような感じだった。

もちろん物理的に脚が上がらなくなってきていて、キツさや重みは強まっていったものの、スピード感は30km時点のまま維持し、33km地点の最終関門をなんとか突破することができた。

ゴールが近づいてくる中で、先程の47都道府県フルマラソン制覇中のお姉さん と再び遭遇。

聞く所によると『これまで走ってきたマラソンコースの中でもTOP5のキツさ』だと言う。

やはり30km付近の激坂の連続は、経験者でもキツい勾配となっていたようだった。

「初挑戦でこのコースを走り切れるのは本当に凄いですよ」

と言ってくれた。

スゴく嬉しく、自信に繋がった。

正直もうラスト3kmくらいは歩いてもゴールに間に合いそうだと考えていたが、お姉さんの一言で何だか最後まで頑張ろうという気になった。

節々が痛い、筋肉も張り詰めて今にも切れそうで、全身が鉛のように重たい。

だが、これは「死ぬまでにやりたいこと」であったことを強烈に思い出して、最後まで死力を尽くして走りきった。

記録、5時間35分32秒。

長過ぎる戦いが終わった。

完走後は数十分その場から動くことが出来ないほど、本当に全てを出し切ることができた。

わかったこと

非常にたくさんの学びを得たと感じているが、正直、完走し終えて数日経った今でも、うまく自分の中で言語化できていない状態だ。

だが、とにかく一番強く感じたのは『本当に色んな人がいた』ということだ。

思い出せる範囲でも

• コスプレしてた人（ジバニャン、ピカチュウ、ドレスを着たお姫様、塗り壁、カエル帽子の集団）
• 観客と写真撮りながら走っている人
• 途中で倒れて救護されてた人
• はぐれた人
• 坂道を絶対に歩かない人
• ずっと声出して励ましてる人
• 47都道府県フルマラソン制覇中のお姉さん
• 80歳のじいちゃん
• もう諦めちゃった人
• エイドステーションのコールドスプレーを独り占めする人
• 何度もトイレに並んでいる人
• ゴミを投げ捨てる人
• ZARDの『負けないで』を歌って応援してくれる沿道のおばちゃん達
• 1日中 学校の前で応援してくれてた学生達
• 応援に毎回丁寧にリアクションする人

同じ距離を走ってても、こんなにも多種多様で色々な表情の人がいた。

もちろん、レース経験が豊富で余裕がある人が余裕そうな顔してるのはわかるが、私と同じくらいのペースの中でも楽しんでいる人と苦しんでる人と混在していたのが印象深かった。

「人生はマラソンだ」という言葉がある。

出典は不明だが、マラソンに縁の無かった私でも聞いたことがあるようなありふれた格言だ。

たかだか6時間程度走っただけで悟った気になるのも恥ずかしいが、この格言が腹落ちするくらいたくさんの出来事と多くの人がいた。

同じ課題を与えられた時に、楽しむのも苦しむのも全て自分次第であるというメンタルの面と、

楽しむ余裕のあるものは、ちゃんと準備してきたり経験を積んできた力の有る者であるというフィジカルの面、

今後の人生も「楽しく」過ごしていくために、内側からも外側からもレベルアップが必要であるという、大きな気づきを与えてくれる42.195kmだった。

お疲れ様でした。

本当に辛かったけど、お陰で一生忘れない一日になった。

回らない高級寿司店で特上のものを食べてみよう！

私は『死ぬまでにやることリスト』をNotionで管理している。

• 日本一周する！
• 体脂肪率を一桁にする！
• 結婚する！

とかまあ大層なことを並べているリストなのだが、その中に

『回らない高級寿司店で特上のものを食べる！』

というものがあった。

かなり昔に書いた項目なので、このリストを作成しはじめた大学生くらいの時の夢だったのだと思う。

牛丼チェーン店が最高の贅沢だった貧乏大学生の私にとって、最高級の寿司を食べてみたいという願望は、まさに死ぬまでにやりたいことの一つだった。

『鮨 花おか』行ったみた

ということで渋谷にある高級寿司屋 『鮨 花おか』に行ってみた。

鮨 花おか とは

渋谷桜丘町、鮨と肴を愉しむ大人の隠れ家鮨屋。
素材本来の味わいだけでなく、まだ出会ったことのない魚の旨さを体験していただくために。
伝統にとらわれない珍しい素材や多彩な調理法を取り入れ、可能性を追求し続ける「鮨 花おか」
訪れるたび、新たな美味しい発見があなたをお待ちしています。
(公式サイト)

サクラステージを抜けた静かな路地の一角にある高級寿司屋。

他の高級なお寿司屋さんに行ったことはないが、銀座や麻布十番などの寿司屋でも10000円代程度が相場であることを考えると、特選コースが16500円の本店は紛れもなく”高級寿司屋” の一つであろう。

ちなみにきっかけは “ふるさと納税“。東京都渋谷区の返礼品として、こちらの食事券が用意されていたためだ。

通常16500円の特選コースだが、これが9000円引きで楽しめるということでありがたい。

メニューとしては上記の特選コースのみとなっており、そのコースが進む中でドリンクを適宜注文できるという仕組みだ。

普段はお酒を飲まない私だが、せっかくということでスパークリング日本酒を注文してみた。

全9席の洗練された店内。

（如何にも高級な寿司屋だ…！）とやや緊張しながらコースがスタート。

美味かった寿司’s

『花おか』さんで提供されるお寿司は日によって異なる。

これはある程度高級な寿司屋だとあるあるらしくて、その日の仕入れや旬の時期などによってコース内容が変わるとのこと。

特に『花おか』さんでは「まだ知られていない魚の旨さをもっと知ってもらいたい」というコンセプトで、希少な魚種が盛りだくさんとなっていた。

一部特に印象に残ったネタを紹介してみる。

まずはこちら『エイの肝』。

刺し身や天ぷらなどの前菜的なメニューの後、握りのフェーズに入って1巻目のネタ。手渡しされるスタイル。

エイて！しかも肝て！

普通に過ごしていたらまあ食べることのないネタに、恐る恐る口に運んだが……

美味い！！！！！！！！！！！！

トロットロの肝がめちゃくちゃクリーミーで、赤シャリと混ざりあって口いっぱいに旨味が広がる。

握り一発目でこれか！というのもあってめちゃくちゃ印象に残ってる。普通に注文するタイプの寿司屋だったらこれだけを200巻くらい擦ってたと思う。

続いて『チーム北海道 海鮮丼』

北海道産のズワイガニ、バフンウニ、イクラの3つが織りなすミニ海鮮丼。

各ネタのクオリティも然ることながら『よく混ぜてお召し上がりください』という大将の案内通り食べてみると、それらが互いの存在を活かしあいながら抜群のハーモニーを奏でる。

ウニそんなに好きじゃない妻もこちらは絶賛。

よく「ここの〇〇は苦手な人でも大丈夫だから」みたいな言い方でメニューを推してくる人がいるが、信じてもらえるとしたら「ここのウニは苦手な人でも大丈夫」だ。

こちらは『アカゼムロアジ』。聞いたことないよ。

なかなか採れない魚で市場には滅多に出回らないことから「幻の魚」とすら呼ばれている（本当か？）珍しい魚種らしい。

美味い！！！！！！！！！！！！

脂乗りがよくて味がしっかりしているので、味覚の繊細さに自信の無い私でもわかりやすく美味しかった。

『中トロ』。

結局トロが美味い。結局ね。

比べるのも変な話だが、やはり回転寿司の中トロとは何もかも別物だった。

陳腐な言い回しだが「口の中で溶ける」といった具合で、ネタが舌の温度で溶けてしまってるんじゃないかと思うくらいしっとりとろける美味しさ。

これだったら無限に食えるんじゃないかなと本気で思った。

美味しかった！……はずなのに

先に言っておくが、上記の通り『花おか』さんの提供するネタの数々、品質、ホスピタリティ、どれも星5という感じで非の打ち所は無かった。

良い経験になったし良い時間を過ごすことが出来たと思う。

だが『死ぬ前にこれを食べたいか』でいうと、率直なところ違うなと思った。

リストに記載していたこともあって、そのくらいの期待をしていってしまったのが良くなかった。

当たり前のことに気がついた

当たり前に考えて3000円の回転寿司の5倍美味いわけは無い。お金をかけた分美味しくなるというそんな単純な話ではないのだ。

『回らない高級寿司店で特上のものを食べる！』という目標が達成できて嬉しいのはもちろんだが、高価な食事というのはそれだけでは喜びの上限値がすぐ頭打ちになるということがわかった。

ちなみにリストには横並びで『フランス料理の高級コースを食べる』という項目もあったが、これはこの機に削除した。20代の私、食欲がすごいな。

この文を書きながら自分でも整理しているところだが、つまるところ今回の項目は『死ぬまでにやりたいこと』というよりは『生きているうちにどこかで出来たら良いこと』だったのだと思う。

だから達成した喜びが他の項目より弱いし、”こなした” 感じが否めない。

では死ぬ前に食べたくなるようなものって何なのだろうと思考を巡らせてみると、

• 実家で母が作った鶏の唐揚げ（大好物）
• 妻と食べた焼肉（仲良くなったきっかけ）
• 友達と馬鹿話した後に帰り食べたラーメン
• 日本一周中でご馳走してもらった海鮮丼

という感じでストーリーが乗っかってるものばかりだということに気づいた。

これらは全部『明日死ぬ』となったら絶対食べたいものたちだ。

そこには、単に高級なだけでは入ってこないのかもしれない。

高いお金を払って高級な物を食べる。これ自体は良い経験になったし、自分の物差しが大きくなった気がするので、やってよかったと思う。

だが、最高の食事というのは意外と何気ない日々に転がっていたりして、それをちゃんと認識できているかということの方が重要なのかもしれない。

行動しない人間ほど偏見や固定観念が多い。やってみればすぐ分かることも、自分では動かないので思い込みが見直されることもない。不思議な話だけど、思考の柔軟性は行動量に依存してる。

— 佐藤航陽（さとうかつあき） (@ka2aki86) December 31, 2017

こんなポストを見かけた。確かにすぎるだろ。

全然外に出なくなった両親とか、口ばっかで動かない友人とかほど、『〇〇はXXだから』みたいな偏見を持ちがちなのは体感としても納得感があった。

百聞は一見にしかず

『百聞は一見にしかず』ということわざがある。

一〇〇回聞くより一回見るほうがよくわかる。何度繰り返し聞いても、一度実際に見ることに及ばない。（出典 日本国語大辞典）

由来を調べると紀元前一世紀、前漢王朝の時代の中国で異民族の攻撃への対応策を問われた老齢の将軍、趙充国（ちょう じゅうこく）は、「百聞は一見に如かず（何度、報告を聞いたって、実際にその場に行って見るには及びません）」と述べ自ら現場に駆けつけようとした、ということかららしい。

戦が蔓延ってた当時と現代では状況はもちろん異なるが、詰まるところ『より深く理解するために効率的な方法』という話をしている。

百見は〇〇にしかず

『百聞は一見にしかず』を『より深く理解するために効率的な方法』 という観点で見た時、

• すぐに一見できるなら聞きまくるフェーズはすっ飛ばした方がいいな
• “一見した者” から聞く 一聞 は明らかに価値が高いな
• 一見するよりも深く理解する方法はないかな？

などが思いつく。

すぐに一見できるなら聞きまくるフェーズはすっ飛ばした方がいいな

→ そうだと思う。インプットにおけるタイパが良いし情報の質も上がる。

百聞って砂の中から砂金を見つけるようなもので、ノイズが多すぎるからほとんど意味ないような気がしている。

特にネットで情報が無限に流れ続けている現代においては、誤情報も多いしそもそも百聞で済まないことも多いからタチ悪い。

“一見した者” から聞く 一聞 は明らかに価値が高いな

→ これもそうだと思う。そりゃそうだよね。

「誰が語るか」が重要視されるのはこういった側面も作用してるのだと思う。

結局現代における「百聞」ってほとんどメディアからだと思うけど、メディアも情報も溢れすぎてるから全部は聞いてられない。そうなると確かな情報ソースを求めて自ずと「一見した者」（に匹敵する人・専門家）などの発言に飛びつくようなリテラシーにはなっていると思う。

一見するよりも深く理解する方法はないかな？

思うに『百見は一行にしかず』なのだと思う。

「いちぎょう」ではなく「いっこう」。百回聞くより一回行動した方がより深く理解できるよね。

勿体ぶって出すほどの意外性はないかもしれないけど、まあ感覚的にも納得してもらえる内容だと思う。

「自転車の乗り方」を百回見るよりも、一回やってみる方が遥かに理解できる。

まあ「見る」というのも一つのアクション（一行）とも取れるので、厳密には百見分に相当するかはちょっと審議入るかもしれないけど。

とはいえ元ポストにも通づるところだけど、同じ事柄を「一行で理解しようとする者」と「一万聞で理解しようとする者」がいた時、どちらが速くて正確そうかは想像に難くない。

なまじネットに情報が溢れかえり何でも調べられる現代では、一万聞アプローチを取ろうとしてしまう気持ちもちょっと理解できる。行動は面倒臭いからだ。

行動は面倒くさい

当たり前ながら、行動は多くのMPを消費するので面倒臭い。

• ゲーム自体は遊んだことないけど、実況で見る
• 自身では行かないけど、アウトドア系のチャンネルが好き
• もうプレイはしないが、昔部活やクラブでやってたスポーツの動画をよく見る

こういうのあるある過ぎると思うし別に否定する気も毛頭ない。

ただ、今回のテーマでいう「理解量」の観点でいうと、実際に行動した者に比べたら見ただけの人は 1%程度しか理解していない かもしれないということ。

• 見るだけじゃ伝わらなかったコントローラの振動、手触り、ディレイ感、キャラクターの重み
• 見るだけじゃ感じられなかった草木の匂い、荷物の重さ、焚き火の安心感、静寂
• 見るだけじゃ認識できていなかった身体の動き、イメージとのギャップ、フィールドの空気感

一行に比べたら一見しただけのことなんて『ほとんど何も理解(わか)ってない』 のだ。

タイパよく理解量を増やす行動を見極めよう

念の為、私は『一行』が『一見』より100倍優れていると論じたいわけではない。

理解したいレベルに対して行動が過剰になることもあると思う。

例えば「一行」の方が理解量が多いからといって、すでに体系化されたことを、自分でゼロから試して時間をかけて学んだりするのは効率悪い。ドキュメントを読まずに手探りで環境構築するみたいなものだ。

行動は理解の“深さ”を高めるが、必ずしも“速さ”を保証しない。
目的が「理解」なら行動、「把握」なら視覚情報で十分なことも多い。

ということは認識しておきたい。

ただ、これを意識しておければ「やってみた方が速いな」という択を選べる。この択を持っていればタイパよく理解量を増やすにはどうすればいいかが見極めやすくなると思う。

マジで今更だと思われるかもしれないが、アニメ『少女☆歌劇 レヴュースタァライト』を鑑賞した。

率直にめちゃくちゃ面白かったので熱量があるうちに軽く整理してみる。

『少女☆歌劇 レヴュースタァライト』との出会い

2018年放映のアニメ作品を2025年になって今更どのように出会ったかでいうと、今年に入ってから友人と「アニメの第一話だけを見て作品のテーマを解剖し結末を予想する」という遊びを定期的に行っていて今作もその中で選ばれた作品だった。

しばらくアニメから離れていた自分としては完全に初見で、どんな作品か全然知らなかった。

1話目を半分くらいまで見て

「あー、ミュージカル風『ラブライブ！』みたいな作品かな」

と感じていた。歌劇に青春を燃やす少女たちの群像劇的な。

しかしその印象は、1話目18分あたりで大きく覆った。

1話目を見た印象と当時のテーマ解剖・結末予想

学園に普段は存在しないエレベーターを見つけ、不思議な地下劇場へと誘われる。

ここまでそういった非日常感を感じない作りだったため、このシーンはかなり面食らった。（あとから調べると当時もそういう反応は多かったようで「意味不明」とか「何これ」みたいな感想は溢れていた模様）

そこからあまりにも印象的な『アタシ 再生産』のカットが挟まり、主人公・愛城華恋を中心とした “レヴュー” と呼ばれる舞台少女たちの戦いが始まっていくという話。

一話目を見終えた時に並べていたテーマの解剖と結末予想は以下（全話見た今見返してみても大きく外してはないような気がしていてちょっと嬉しい）

テーマ解剖

• Revue（歌劇）を見つめ直し（Review）、再生産する物語

レヴュー

• 歌・ダンス・寸劇が組み合わさったショー
• 「情熱のレヴュー」では華恋 vs ひかり（華恋優勢、ひかりは情熱を失いかけているということ？）
  • 海外で打ちのめされた？
• 審判がキリン（高い視座の存在、としてのメタファー？）
  • 華恋はキリンを超えて舞台に飛び入っている（キリンの想定を超える何かを起こしてくれそう）
  • 「わかります…」が「わからない…！」になるのが楽しみだ

東京タワー

• 華恋とひかりの夢の始まりの場所
• 高度経済成長の中で建設された東京タワーは建築期間約1年半という、着工から完成までが異例のスピード工事だったらしい。
  • => 「急成長」のメタファーとして華恋ちゃんのポテンシャルを表現している？

結末予想

• 華恋とひかりのW主演で、悲劇→喜劇（ハッピーエンド）に「再生産」
• 心が見えず、情熱を失いかけていた光と、2人でスタァを目指したい華恋とのコンビが次々にレヴューで勝ち進んでいく。「ぶつかり、いさかい、すれ違いながらも結ばれていく絆」
  • キャラ毎の心情が見えてきたら、各女神枠の予想もできるかな？（まひるちゃんは嫉妬の女神だと思う）
• 99回目でW主演だった西條 クロディーヌ・天堂 真矢がラスボスとして登場。最後のレヴューが始まる
• 圧倒的な実力を前に力及ばずか…という窮地で「いこう、あの舞台へ。輝くスタァに二人で。」
  • ひかりの”再生産”が発火。（東京タワーと対照にエッフェル塔とかビッグベンとかから落ちる演出だと面白い）
  • 一つの頂上ではない、2人が輝くスタァを見出す
  • 『スタァライト』を別れで終わる悲劇→再会で終わる喜劇に再生産し、”最もきらめいたレヴューを見せた” 2人がレヴューを勝ち残る
• これまでの伝統的なスタァライトを再生産し、新しい時代を作り出した第100回 聖翔祭を演じきって最終回（聖翔祭は3月に行われるので、卒業を控えた3年生は演じず、2年生で最後なのでは）
• ばななちゃんが撮影した第100回 聖翔祭の写真を見返しながら「懐かしいね」などと会話しつつ、それぞれの進路が仄めかされる
• 再生産で熱意を取り戻したひかりは再びイギリスへ。いつかくる再会の日に期待しつつそれぞれのスタァへの道を歩み始めて終幕

テーマに沿って再まとめ

• 既存のRevue（スタァライト）を見つめ直して再生産した各キャラクターが今度は己の歌劇（拡大解釈すると人生。舞台少女は歌劇に生きているので）を見つめ直して、各々を再生産していく。

どういう作品だったか・感想

めっっちゃくちゃ面白かった（小並感）。

映像や曲のクオリティももちろんながら、巧みな暗喩が非常に豊富。

トマト、ミロのヴィーナス、紙飛行機、東京タワー、タクシー代…

挙げ出したらキリがないがモチーフやセリフ、演出など随所に暗喩がねじ込まれていて「これってこういう意味なのかな…？」と推察できる作りになっている。

12話で9人のキャラを掘り下げながら充実した展開を作るのは非常に大変だと思うが、この巧みな隠喩や、2人ずつのペアで物語を進めたりなどの工夫で、凄まじく濃密な12話になっている。

再生産総集編と劇場版も見たが、全体通してのテーマとして核は一言でいうと『Revue（Review）＆ Rebuild』とかになるのかなと解釈した。

考察記事も別途作ろうか（とはいえもう巷に出尽くしている感じもあるのでそれこそ今更か…）とも思っているので、ここでは多くは語らないが、「私たちはもう 舞台の上」にいて、最高の舞台(人生)にするために「日々進化」していく必要がある。

進化にも色々あると思うが、人生を大きく変える進化は『既存のものを見つめ直して再生産する』覚悟が必要で、それは舞台少女だけでなく普遍的な教えとしてし見る者に届くのではないだろうか。

面白くなりたい。

大喜利で面白い回答を出したり、ボケに対して面白いツッコミを切り返したりしたい。

そういった所謂「お笑い」的な面白さもそうだし、映画などのコンテンツを受け取って面白い考察をしたい。

これらは個々で見れば別のベクトルの面白さだなと頭では理解しながらも、自分の中では「面白くなりたい」という方向感でどれも鍛え上げたい能力だ。

「面倒だからまとめて一気に鍛え上げることは出来ないかなー」、と怠惰の極みみたいな思考を巡らせていたら、何となく共通項が見えてきた気がしたのでそれらを備忘録的にまとめたい。

大喜利・ツッコミ・考察に共通する能力

詰まるところ「情報から連想されるキーワードを抽出して再構築する能力」なのではと考える。

大喜利の場合は「お題」、ツッコミの場合は「ボケ」、考察の場合は「コンテンツ」を受け取って、まずはそこから連想されるキーワードを抽出する。

例えば大喜利のお題が「こんな本屋は嫌だ」だとした時に、このお題から連想されるキーワードを洗い出す。

後述もするが、ここはとにかく量を出すのが良い。連想キーワードをブレインストーミングする。

連想キーワードが洗い出せたらそこから「再構築」に入る。今回の例は大喜利なので上記のキーワードから「こんな本屋は嫌だ」へのアンサーを考えてみる。

いや、一旦おもしろ度合いについては目を瞑ってほしい。あくまで例ってことで。

もちろん大喜利の上手な人は逐一こんなことをせずとも、脳内でパパッと構築できるのかもしれないが、基本的にはこういう思考プロセスを踏んでいるはずである。

これが「抽出」と「再構築」であり、これをスムーズに行いつつ、大喜利なのかツッコミなのか考察なのかに合わせて適用させていけば各所で高い面白さを発揮できるのではと思う。

抽出は「具材集め」で 再構築は「料理」

「情報から連想されるキーワードを抽出して再構築する能力」は「具材集め」と「料理」に例えるとイメージしやすい。

特定の情報に対して、脳内で関連タグを収集する作業が「具材集め」で、集まった材料を再構築するのが「料理」。

例えばツッコミならスピード感が要求されるので、「具材集め」も「料理」も凝り過ぎずにスパッと出したものがウケやすい。

大喜利はツッコミに比べもう少し時間が取れるので、「具材集め」も「料理」も少々時間をかけて、ストレートなものより凝ったものや、想像の一歩先をいった料理なんかを提供するとウケやすい。

考察ではガッツリと時間を取れるので、「具材集め」で最高の材料を並べてガッツリと「料理」することで、新しい見方や見解を出せるとウケやすい。

この能力はどうやって鍛えればいいか

抽出は「具材集め」、再構築は「料理」、とした時に、何はなくとも具材がないと料理ができない。

そのため基本は 情報から連想されるキーワードを抽出する能力の向上が優先され、再構築はカテゴリに沿ったものをある程度専門的に実践する方が効率的だと考える。

スマートな練習方法を提示したいところだが、今の所自分は愚直に『物や事象に対して連想されるキーワードを出しまくる』というマッチョな方法に着地している。

2017年ごろ、上記画像がミームとして大流行したが、これは非常に的を得ている感覚。

「頭が良い」= 「面白い」ではないのはもちろんなのだが、面白い要素を見つけやすいのはやはり連想が早く多い方ではあるよなと。

そのため大喜利にしろツッコミにしろ考察にしろ、まずは「大量の連想キーワードを素早く洗い出す」というのが面白のコアスキルになってくるのではと思う。

「抽出」と「再構築」の二軸で考えれば、自分がどこが弱いか特定しやすい（自分の場合は「抽出」が足りてないように感じている。有り体にいうと頭が悪い。）

まとめ

仮説「大喜利・ツッコミ・考察などのスキルってある程度共通の能力で伸ばせるのではないか？」
↓
その共通の能力とは「情報から連想されるキーワードを抽出して再構築する能力」なのでは？
↓
抽出を「具材集め」、再構築を「料理」で考えるとイメージしやすく、この二軸で分けると足りない能力を鍛えやすい

うまくハマれば総合的なおもしろスキルを効率よく伸ばすことができるのではとワクワクしている。

Dockerを使って開発しているのですが、ある日突然以下のようなポップアップが表示されました。

Docker.appを開くとコンピューターが破損します。ゴミ箱に入れる必要があります。

これまでキビキビ動いてくれていたのに、いきなりのマルウェア扱い。どうしちゃったんだ…

今回は上記問題の解決方法を備忘録としてまとめていきます。

結論

Dockerをゴミ箱に入れて 公式が公開している回避策コマンドを実行後、Dockerを再インストールする！

以下でもう少し詳細に記載します。

具体的な対応

Docker.appを開くとコンピューターが破損します。ゴミ箱に入れる必要があります。

は何度キャンセルしても繰り返しポップアップが出てくるので一旦 [ゴミ箱に入れる] をクリック。

その後、一旦ゴミ箱の中身を空にします。

「一度Dockerを消して再インストールすることで解決した！」という記事も見かけましたが、私の場合はうまくいかず、検証のタイミングで

“Docker.app”は壊れているため開けません。ゴミ箱に入れる必要があります。

と表示されてしまいました。

調査しているとDocker公式から『Docker Desktop on macOS unable to start due to malware reports 』（マルウェア報告により macOS上のDocke Desktopが起動できない）という障害報告ページを発見。

2025年1月8日 時点のレポートではDocker公式も原因を調査中で、どうやら com.docker.vmnetd または com.docker.sockert のいずれかがマルウェア判定されてしまう ということらしいです。

workaround（回避策）として対応方法を記載してくれているので、上から順に対応します

1. Docker Desktopを終了し、アクティビティモニターを使用して残りのdockerプロセスが実行されていないことを確認。
2. コマンドを実行（ 2の箇所にあるコマンドを上から順に実行 ）
3. Docker Desktopを再起動

上記実行後、無事にDockerが再起動し、正常動作するようになりました。

最後に

障害報告ページを見ると ver4.37 でパッチが当てられたらしく、それ以降のDocker for Macを再インストールすれば治るっぽいんですが、私の環境では再インストールで正常動作しなかったですね…

割と同じ事象で困っている方がSNSなどでも散見されたので、助力になれば幸いです。

改めてブログ書くのって結構良いなと思った。ちょっとその辺りの考えをまとめてみる。

ブログに書き出すことのメリット

詰まるところ、書き出すことのメリットが充実している気がしている。大きいメリットは以下だと思う。

• わかってないところの見える化
• 知識・知見のデータベース化
• 思考ツリーの手綱

わかってないところの見える化

例えばプログラミングについて記事を書こうという時、大抵の場合は「こういう事象に遭遇したから、解決までのプロセスをまとめておこう」とか思って書き始める。

頭の中では 問題提起 → 解決 までのゴールが見えている気がして颯爽と書き出してみるのだが、いざ文章にしようとすると

• 「何でそう思ったんだっけ？」
• 「そもそもこれって何だっけ？」
• 「この言葉って使い方合ってるっけ？」

とか絶対なる（断定）。

頭の中だけで完結してる時は、脳内補完が上手に働いてさも1から100までわかった気でいるのだが、アウトプットしてみると案外5割くらいしか分かってなかったみたいなことがザラにある。

また、他人に説明しようとすることで学習が捗るみたいなデータもあるらしく、これは体感としても納得できる。

わかってないところが見え、わかっている部分をより咀嚼して吸収率を上げる、という行いは結構大きいメリットだと感じる。

知識・知見のデータベース化

私はシンプルにかなり忘れっぽい。

プログラミングでも一度やったことのある手続きとかお作法なんかをどんどん忘れていく。

これはちょっと時間的にも勿体無いので、書いて覚えを良くしていきたい。また、同時に備忘録としてもブログは大いに活躍するはずだ。

楽だからテキストばっかりで書いちゃうけど、写真とか動画とかもどんどん乗せて充実したデータベースにしていくのが良いんだろうな。

思考ツリーの手綱

あんまり利口ではないので、考えているうちに思考があっちこっち行ったり、霧散したりして、まとめるのに時間がかかることがある。

プログラミングでもとりあえず手をつけてみるが

• 「そもそもこの方針で良いんだっけ」
• 「ここ2パターン思いついてたけど、Bパターンって何する予定だったんだっけ」
• 「お腹すいたな。一旦ご飯食べようかな」
• 「ここまで進めてきたけど、そもそも最初からこっちの手法の方が良いっけ」
• 「煮詰まってきたから昼寝しようかな。後にしようかな」

こんな感じになってしまう（よくない）。

ブログ書きながら物事を進めると、時間はかかってしまうが、すんなり思考の軌跡を辿れるのでこれが手綱となり元に戻ってこれることが多い。

思考の解像度向上

「ヤバい」とか「エモい」とか、世の中便利な表現が多いので、よく使ってしまう。

湧き上がった感情を文章化しようとすると「何でエモいと感じたんだっけ？」みたいな考えが巡って、結果意外かつ自分の中で納得感のある表現に落とし込めたりする。

「ああこの”エモさ”って、ここまでの経緯を一気に見せてもらって、自分の過去の経験とも類似するところが多くて共感しきった時に、あのカタルシスだったから響いたのかも」

みたいに理解できると、考えがクリアになって何だか気持ちが良い。自分のことが少し分かった気になれる。

ブログに書き出すことのデメリット

多分デメリットもある。

• 時間がかかる
• うまくまとまらないと萎える

とはいえどっちも、長期的に見れば解決する問題な気がしている。

時間かかる

正直これがネックな部分はある。この記事もなんとなくまとめてみようと軽い気持ちで始めたのに1時間近くタイピングしている。だるい。

• 別にライターとして食ってるブログじゃないのだから力抜く
• デカいことを網羅的にまとめようとしない
• 60%で良いから世に出しちゃう

この辺を意識しつつスピード感というか “フッ軽” 感もって取り組みたい。ブログ書くの面倒って思ったら多分負け。ハードルは低く。

うまくまとまらないと萎える

逆にうまくまとまると気持ちいい。脳がスッキリする感じがある。

多分最初のうちは文章をまとめるの自体が大変なことに感じるが、慣れの部分が大きいと思う。

「考えていることをサクッとまとめる練習」と割り切って、最初はダメでも書き続けてみたい。

ブログは健康に良い（持論）

デトックス作用ある

イライラした時に「なぜイライラするのか」を文章に書き出してみると、意外なほど冷静になれるというライフハックがある。これはブログをやる前からメモ帳とかでやってたので体感としても納得している。

なので「あいつムカつくぜー！全てが嫌いだー！」とか思った時も、具体的にどんなところが嫌いか洗い出そうとすると意外なほど出てこない。

出てきた場合にも「あ、これはこっちの受け取りの問題かもな…」とかちょっと冷静な自分も顔を覗かせたりする。文章化すると客観的になれてそういう点に気づきやすい。そうやっているうちにイライラが少し引いている。

頭の中でモヤモヤ・グルグルしている時間は割ともったいなくて、サクッとアウトプットして客観的に捉えた方が、脳の負荷も溜飲も下がるし良い感じ。

瞑想作用ある

「頭の中が整理されていく感じ」が気持ちよくてドンドン書いているうちに、なんかすごく集中している時がある。

歳取ってくると、何かに没頭している状態って意外と少なくなっていて、これはとても健康に良い気がしている。

ガチで瞑想（マインドフルネス）に取り組んでみていた時期もあったが、10分の瞑想よりも10分ブログで考えを整理した方が個人的にはメリットが多いと感じた。

まとめ

改めて自分にとってブログ書くことって利点が多いと感じたので、ここからの更新頻度はすごいよ。

掲題通り。解決までの道筋を備忘録として残そうと思う。

前提

• t3.medium で稼働しているEC2インスタンスのタイプを r7g.medium に変更してほしいという依頼を受けた
• Auto Scaring GroupなどはじめAWS構成をTerraformで管理しているので、.tfファイルの修正 -> apply を伴う
• アプリ自体は GithubActionでイメージをECRにプッシュし、該当イメージをECSでデプロイする流れ

x86ベース → ARM への移行という障壁

今回の肝はここ。

t3.medium → r7g.medium に変更するということは、アーキテクチャがx86ベース → ARMベースに変更されるというポイントがある。

x86

• パソコンやサーバーで主に使用
• 高性能だけど、電気をたくさん使う
• 複雑な計算が得意
• IntelやAMDが作っている

ARM

• スマートフォンやタブレットで生まれた CPU
• 軽くて省エネ・省電力
• バッテリーが長持ちする
• Amazonが作ったGraviton2/3ベース

簡単に言えば、x86は「パワフルだけど電気を食う」、ARMは「少ない電気で効率的に動く」タイプのCPU、と理解した。

アーキテクチャが変わることによる影響範囲を当時はあまり理解できていなかった。

切り替え自体は楽だが使用するイメージに注意

アーキテクチャが変わるとはいえ、instance_type = "r7g.medium" としてやればいいだけだと考えていた。

が、インスタンスタイプが切り替わったあと、元々動いていたサービス上でタスクが起動しなくなっていることに気づいた。

resource "aws_launch_template" "lt" { name_prefix = "${local.app_name}-lt-" image_id = "ami-0dba57a21a03d3f66" # Arm対応ECS-Optimized AMI instance_type = "r7g.medium" key_name = var.ssh_key_name

原因は image_id だった。

上記修正を行うまで、 単にARM64に対応している最新のimage_idを指定していたが、Arm用の ECS-Optimized AMI を指定してやらないと、DockerやECSエージェントがプリインストールされないため、サービス上でタスクがいつまでも起動しない（ECSとECRが紐づかない）状態となってしまった。（これ気づくの時間かかった…）

こちらを適用後、インスタンスとサービスを再起動することでタスクは動き出した。

Github Actionでエラー

GithubAction実行時に以下のエラー

8 0.190 exec /bin/sh: exec format error

これは Docker ビルド時にコンテナが ベースイメージのアーキテクチャ と 実行環境のアーキテクチャ が一致していなかったために発生するものらしい。

ベースイメージはDockerFile内で node:18-slim を指定していた。これはマルチアーキテクチャに対応してくれることを事前調査済みだったので安心していたが、問題は実行環境のアーキテクチャ。

Github Actionはデフォルトで x86ベース で動作するため、これが不一致の原因だった。

Github Actionでアーキテクチャが異なる環境でプログラムを動作可能にするには、QEMUとBuildxというツールを使うのが一般的だと知った。

 - name: Setup QEMU uses: docker/setup-qemu-action@v2 with: platforms: linux/arm64 - name: Setup Docker Buildx uses: docker/setup-buildx-action@v2

• QEMU: 異なるアーキテクチャをエミュレートのするためのツール
• Buildx: いろんな環境用に効率よくアプリを作るためのツール

らしい。

これらを導入することでbuildも通った。

build時間がめちゃくちゃ長くなった (5分程度 → 30分程度) のが微妙過ぎるが、これはまた別の課題とする。

こんにちは。

Ruby on RailsでWebアプリケーションサービスの開発をしています。

普段のコーディングはVisual Studio Code(VS code)を利用しているのですが、Ruby onRailsの開発をしていると、「この定義元ファイル確認したいなー」なんてことがよくあります。

ショートカット⌘ +⇧+  fなどで全検索してもよいですが、サッと定義元にジャンプできた方が楽ですし早いですよね。

今回は定義元にジャンプする設定をご紹介します。Rails開発している方はぜひ参考にしてみてください。

Railsを書いている時にメソッドの定義に移動する設定

VSCodeの拡張機能「Ruby」導入

まずはVisual Studio Codeの拡張機能『Ruby』を導入します。

Visual Studio CodeでRubyを扱う場合には、ほぼ必須と言ってよいくらい優れた拡張機能です。

まだ導入されていない方はMarketplaceで「Ruby」と検索し導入しましょう。

定義に移動する設定をONに変更

タスクバーからVScodeの[基本設定]=>[設定]をクリック。画面上部[設定の検索]に「Ruby」と入力します。

Ruby:Intellsense の設定を[false]から[rubyLocate]に変更して設定完了です。

定義にジャンプする方法

使い方は簡単。

定義されたメソッドにカーソルを持っていき、⌘ボタンを押した状態でクリックすることで、定義元に一瞬でアクセスできます。

これ有る無しで開発効率が段違いなのでオススメです。

VSCodeでRubyのメソッド定義に移動する方法 まとめ

ということで今回はVScodeで開発する際の、定義元ジャンプの設定についてでした。

VScodeの拡張機能はたくさんあって、各言語似たような設定があることかと思います。

メソッドにすぐ飛べると確認効率も上がり、開発スピードが高速化すること間違いありません。

まだ設定していない方は、一度設定するともう無かった頃には戻れないほど快適なコーディングになるはずです。

ぜひ自身の環境で試してみてください

短いですが、今回はここまで。

こんにちは。

Ruby on RailsでWebアプリケーションサービスの開発をしています。

開発中にvalidatesエラーでrenderするも、renderした画面でエラーメッセージが表示されないという問題に陥りました。

今回その原因と解決方法についてご紹介します。

validatesエラー時にrenderしてもエラーメッセージが表示されない！

作りはまあシンプルで、user_controllerのcreateアクションに成功した時と失敗した時の処理を書いていました。

 def create @user = User.new(user_params) respond_to do |format| if @user.save format.html { redirect_to top_path } else format.html { render 'setting' } end end end

ユーザーmodelでは、名前の未入力バリデーションを記述していました。

class User < ApplicationRecord validates :first_name, presence: true validates :last_name, presence: true
end

ユーザーが名前を未入力でsubmitした場合、バリデーションが走りエラーを返します。

byebugで止めながら処理を見ていきましたが、createアクションでは正常にelseに入っています。

render先のviewでは以下のような処理を書いていました。

  <% if @user.errors.any? %> <p>エラーです！！！！！！！</p> <% end %>

ターミナルから確認しエラーであることも確認しました。

(byebug) @user.errors.any?
true
(byebug) @user.errors.full_messages
["Password can't be blank"]

ビューまでエラーが伝わっており、条件に合致しているにも関わらずエラーメッセージが表示されません。

なんでじゃ！！

validatesエラー時にrenderしてもエラーメッセージが表示されない！ 解決方法

local: true をつける！

ユーザーのnameをsubmitする画面をform_withで作成していました。

<%= form_with model: @user do |f| %> <%= f.text_field :last_name, placeholder: "苗字" %> <%= f.text_field :first_name, placeholder: "名前" %>
<% end %>

form_withはデフォルトでremote: trueになっています。これがエラーメッセージ表示を阻害する原因でした。

Ajaxで処理をしたいわけではないので、明示的にlocal: trueを記述します。

<%= form_with model: @user, local: true do |f| %> <%= f.text_field :last_name, placeholder: "苗字" %> <%= f.text_field :first_name, placeholder: "名前" %>
<% end %>

form_withで作成した入力フォームにlocal: trueを記述した状態で、改めてsubmitします。

先ほど通りvalidateで弾かれて、エラーを抱えた状態で正常に条件分岐して、ビューまでたどり着き……

じゃん！

無事にrender先でバリデーションエラー時のメッセージを表示することができました！よかった〜〜！

validatesエラー時にrenderしてもエラーメッセージが表示されない！ まとめ

ということで今回はRuby on Railsで、バリデーションエラー時にrenderした先でエラーメッセージが表示されない問題の解消方法についてご紹介しました。

form_withにまだ慣れていなくて結構苦戦してしまいました。

Railsのバージョンアップとともに便利になっていくメソッドたちですが、それが果たしてどういった処理をしているのかちゃんと紐解いてやらねばなりませんね。

同じようにバリデーションは効いているのにrender時にエラーメッセージが表示されなくてお困りの方の、参考になれば幸いです。

今回はここまで。

参考サイト

• https://qiita.com/k_senbei/items/a361171f653edcd888ad