シーパラ攻略隊の雨の日記事を「おすすめスポット一覧」にしなかった理由
シーパラ攻略隊の雨の日記事を、スポット紹介ではなく「予定どおり行く・水族館中心・延期」の判断支援として設計した理由を、実際の制作判断から振り返ります。
GAOCRAFTでは、実際に作ったWebプロダクトやコンテンツについて、「何を作ったか」だけではなく、なぜその形にしたのかも記録しています。
シーパラ攻略隊で「雨の日」の記事を作ったときも、最初に考えたのはおすすめスポットの数ではありませんでした。
雨の日でも楽しめる場所を集めて、「雨の日おすすめ○選」のような記事にすることもできます。
でも、実際に記事を設計していく中で、それでは読者が最初に抱えている迷いに答えきれないと考えました。
そこで作ったのが、
予定どおり行く
水族館中心へ変更する
延期を検討する
という3つの選択肢から考える「雨の日判断ガイド」です。
今回は、なぜGAOCRAFTが「おすすめスポット一覧」ではなく、この形を選んだのかを振り返ります。
最初から
図：雨の日にどこで遊ぶかを並べる前に、予定をどうするかという判断を記事の中心にした。
雨の日の記事を作ると決めたとき、分かりやすい作り方のひとつは「雨の日でも楽しめる場所」を並べることです。
水族館、屋根のある場所、レストラン、ショップなどを集めれば、記事としては成立します。
ただ、シーパラ攻略隊で実際に解決したかったのは、その一歩前にある迷いでした。
雨予報を見た人が知りたいのは、本当に最初から「どこで遊べるか」なのか。
それよりも、
「せっかく予定を立てたけれど、そのまま行っていいのか」
「水族館中心なら楽しめるのか」
「アトラクションが目的なら延期した方がいいのか」
という判断で止まっている人がいるのではないか。
そう考えました。
おすすめ一覧が悪いわけではありません。
今回は、おすすめを出す前に、そもそも予定をどうするか決める必要がある記事だったということです。
そこで今回の雨の日記事では、「雨でも楽しめる場所紹介」ではなく、来園判断そのものを記事の役割にしました。
最初の
図：雨の日の過ごし方を勧める前に、来園者が何を楽しみにしているかを確認する。
記事の入口を変えると、その後に必要になる情報も変わります。
「雨の日にどこで遊ぶ？」から始めれば、必要なのはスポット情報です。
一方で、
「雨予報だけど、シーパラへ行く？」
から始めると、先に整理しなければならないのは、その人の目的です。
水族館が一番の目的なのか。
アトラクションが一番の目的なのか。
水族館もアトラクションも両方楽しむ予定だったのか。
同じ「雨の日」でも、目的が違えば判断は変わります。
水族館が主目的の人と、特定の屋外アトラクションに乗ることが主目的の人に、同じ答えを返すのは無理があります。
そこで、記事を書く前に「おすすめする場所」を増やすのではなく、読者が何を判断する記事なのかを先に決めました。
この順番は、記事の構成を考えるうえでかなり重要でした。
ひとつの
図：一律の正解ではなく、来園目的と当日の状況に合わせて選ぶ3つの可能性を示した。
雨の日の記事だからといって、
「雨でも大丈夫です」
と断定することはできません。
反対に、
「雨なら延期した方がいいです」
とも一律には言えません。
そこで今回の記事では、答えを1つに決めず、
予定どおり行く 水族館中心へ変更する 延期を検討する
という3つの選択肢に分けました。
大事なのは、GAOCRAFT側が正解を決めるのではなく、読者自身が自分の目的と照らし合わせて選べることです。
たとえば水族館が主目的なら、雨予報だけで予定を変更する必要がないケースもあります。
水族館とアトラクションの両方を予定していたなら、水族館中心へ組み替える方法もあります。
一方、特定の屋外アトラクションが一番の目的なら、その日の運行状況によっては延期も選択肢になります。
「おすすめはこれです」と答えるより、
何を一番楽しみにしているかによって判断が変わる
という構造を、そのまま記事にしました。
「雨の
図：雨の日向けの紹介があっても、当日に利用できるとは限らないため、運行状況は別途確認する。
この雨の日記事を作っていて特に注意したのが、情報の役割を混ぜないことでした。
公式には、雨の日の楽しみ方として紹介されている施設やアトラクションがあります。
しかし、それと「今日そのアトラクションが動いているか」は別の話です。
天候、強風、点検などによって、当日に運転を中止することもあります。
つまり、
「雨の日に楽しめると紹介されている」 ＝ 「今日利用できる」
ではありません。
この2つを混ぜてしまうと、記事だけ読んだ人が「雨の日向けなら今日は乗れる」と受け取ってしまう可能性があります。
そこで今回の記事では、雨の日の楽しみ方を見る情報と、当日の運行状況を確認する情報を分けました。
おすすめ情報を増やすよりも、
「この情報は何を判断するための情報なのか」
を整理することを優先しました。
コンテンツでは、情報量が多いことよりも、違う意味の情報を同じものとして扱わないことの方が重要な場合があります。
実体験は
図：現地での雨の日の体験は参考にするが、すべての雨の日が同じ状況になるとは書かない。
シーパラ攻略隊には、実際に雨の日に訪れた経験もあります。
その日は、アトラクションの運休が多く、施設間を移動するときには足元も濡れました。
一方で、屋根のある区間も多いと感じ、シーパラ攻略隊としては十分遊べたという体感もありました。
この経験は、記事を作るうえで重要な材料です。
ただし、
「雨の日はアトラクションがたくさん止まる」
「雨でも十分楽しめる」
と一般化する材料にはしませんでした。
これは、ある雨の日に自分たちが経験したことだからです。
雨の強さも違います。
風も違います。
運行しているアトラクションも日によって変わります。
訪れる人の目的も違います。
実体験があるからこそ説得力を持たせられる部分はありますが、1回の経験を全体の事実に変えてしまうと、別の問題が生まれます。
そのため今回の記事では、公式情報と実体験を分けて掲載しました。
自分たちで体験したことは、できるだけ具体的に書く。
でも、体験していない範囲まで話を広げない。
これはシーパラ攻略隊の記事を作るときに、今後も守りたい線引きです。
ひとつの
図：来園判断をこの記事の役割とし、細かな情報はそれぞれの既存記事へつなぐ。
雨の日の記事を作っていると、書こうと思えばいくらでも内容を増やせます。
雨具。
服装。
水族館の所要時間。
おすすめの回り方。
アトラクション。
チケット。
雨の日モデルコース。
しかし、全部を今回の記事に入れると、「雨の日に行くかどうかを判断する記事」という役割がぼやけます。
そこで、すでにシーパラ攻略隊にある記事を使いました。
水族館中心へ変更するなら、水族館だけの所要時間の記事。
時間配分を組み直すなら、モデルコースの記事。
雨具や服装を知りたいなら、持ち物・服装の記事。
アトラクションが目的なら、アトラクション攻略の記事。
今回の記事では、その入口となる来園判断だけを担当することにしました。
これは、1記事だけを見て設計するとやりにくい考え方です。
サイト全体で考えると、
「この記事に何を追加するか」
だけではなく、
「この記事では何をやらないか」
も決められます。
結果として、雨の日モデルコースや雨具の詳しい比較などは、今回の記事には増やしませんでした。
足りない情報をすべて1ページに追加するのではなく、既存ページへつなぐ。
それもWebサイトとして育てているからできる設計です。
この
図：記事を公開したことと、その構成が読者に役立ったことは別であり、結果はこれから観測する。
雨の日判断ガイドは、2026年10月5日に公開しました。
ただし、この記事を書いている時点で、
「おすすめ一覧にしなかったから成功した」
とは考えていません。
記事を公開したことと、記事設計が正しかったことは別です。
これから確認するのは、検索結果への表示、クリック、雨に関する検索語句、自然検索からの流入、記事内の回遊などです。
実際にユーザーがどのように記事へ入り、どこへ移動するのか。
そもそも検索されるのか。
3択の判断構造が役に立っているのか。
それらは公開後のデータを見なければ分かりません。
アクセスが少ない段階で大きな結論を出すこともしません。
今言えるのは、
「こういう理由で、この設計を選んだ」
というところまでです。
その判断が結果につながるかは、これから観測します。
FIELD NOTESでは、うまくいった話だけではなく、こうしたまだ答えが出ていない途中の判断も残していきます。
今回の
図：何を書くかより先に、読者に何を判断してもらう記事かを決めて構成する。
今回の雨の日記事で一番大きかったのは、
何を書くかより先に、この記事で何を判断してもらうのかを決めたこと
でした。
テーマが「雨の日」だからといって、雨の日情報をできるだけ多く集めればよいわけではありません。
おすすめスポットを並べることが正解とも限りません。
最初に読者が困っていることを置く。
その判断に必要な情報だけを集める。
公式情報と実体験の役割を分ける。
別の記事が担当している内容は、無理に重複させない。
そして公開したら、実際のデータを見る。
今回の記事では、この順番で記事を作りました。
もちろん、今後データを見た結果、構成を変えることもあると思います。
「おすすめスポット」の情報が必要だと分かれば、別の記事として追加する可能性もあります。
大事なのは、最初から決めた形を守り続けることではありません。
なぜ今この形にしているのかを説明できること。
そして、公開後の反応を見ながら変えていけること。
GAOCRAFTでは、記事も完成品として置いて終わりにせず、プロダクトと同じように育てていきます。