【toC】鎌倉観光Apps 紹介サイト

鎌倉の旅を、もっと自由に、もっと深く。
観光コンシェルジュアプリ「源 -MINAMOTO-」

観光DX × LINE Bot × 回遊支援 × 地域共創

「源 -MINAMOTO-」は、鎌倉を訪れる観光客の散策体験を支援しながら、自治体・DMO・商店街・個人事業主も無理なく運用へ参加できることを目指した観光コンシェルジュアプリです。

鎌倉には、大仏や寺社などの有名観光地だけでなく、地域の商店、工芸体験、歴史文化、自然、穴場スポットなど、多くの観光資源があります。

一方で、観光客が特定の場所へ集中しやすいこと、地域情報が複数の媒体へ分散していること、観光アプリの開発・運用費が高くなりやすいことなど、利用者側と運営側の双方に課題があると考えました。

そこで、利用者が日常的に使い慣れているLINEを入口にし、hachidori、Googleサービス、API、オープンデータを連携させることで、導入・利用・運用のハードルを下げるサービス構成を企画しました。

この記事で紹介していること

・鎌倉観光アプリを企画した背景と課題設定
・観光客・商店・自治体・DMOを対象にしたステークホルダー設計
・「源 -MINAMOTO-」という名称とブランドコンセプト
・混雑回避、趣味嗜好、地域体験を軸にした3つの狙い
・LINE、hachidori、API、オープンデータを組み合わせたシステム構成
・スケジュール、地図、スポット、天気などの機能設計
・観光地の世界観とサービス価値を両立させたビジュアルデザイン
・開発リソース不足を、ノーコード構成の発想へ転換した経緯
・企画、情報設計、UI/UX、ビジュアル制作で担当した内容

前談

制作背景

観光アプリを「作る」だけでなく、地域で「使い続けられる」仕組みへ

本企画は、LINE BOOT AWARD 2018への応募作品として制作しました。

当初は、観光客が鎌倉を便利に巡るためのLINE Botアプリとして構想していました。

しかし、企画を深めていく中で、観光アプリには利用者向けの機能だけでなく、地域側が無理なく情報を更新し、継続的に運用できる仕組みが必要だと考えるようになりました。

従来の観光アプリでは、開発会社へ依頼するための初期費用や、公開後の保守・機能追加に費用がかかります。

さらに、自治体、商店街、店舗などの関係者が情報更新へ参加しにくいと、アプリ内の情報が古くなる可能性もあります。

そこで、普段から多くの人が利用しているLINEやGoogleのサービスを活用し、地域関係者自身が参加しやすい運用モデルを検討しました。

今回は、鎌倉観光アプリ「源 -MINAMOTO-」の企画・UI/UX・紹介サイト制作について紹介します。

司会

観光客向けの便利な機能だけでなく、地域側の運用まで考えた企画なんですね。

Design Summary

観光アプリの企画から、ブランド・UI・紹介サイトまで一貫して設計

私の担当

私は、サービスコンセプトの立案、地域課題の整理、ステークホルダー設計、システム構成、UI設計、スライド制作、紹介サイトのビジュアルデザインを担当しました。

単に画面をきれいに見せるのではなく、以下の問いを軸に設計を進めています。

• 観光客にとって、必要な情報へ迷わずアクセスできるか
• 有名スポット以外の地域資源へ、自然に誘導できるか
• 自治体や商店が、専門的な開発知識なしで情報更新へ参加できるか
• 開発・保守費用を抑え、継続可能なサービスにできるか
• 鎌倉らしい世界観と、デジタルサービスの利便性を両立できるか

02. 課題設定

観光課題

観光客・地域住民・商店・自治体で異なる課題を整理

観光サービスを設計する際は、観光客だけを見ても地域全体の課題は解決できません。

私は、主なステークホルダーを「観光客」「地域住民」「商店・事業者」「自治体・DMO」の4者に分け、それぞれの立場から課題を整理しました。

観光客側の課題

• 有名観光地や特定の時間帯に人が集中しやすい
• 混雑状況や交通情報を、その場で把握しにくい
• 寺社、グルメ、工芸体験などの情報が分散している
• 同行者や趣味に合う散策ルートを組み立てにくい
• 災害時や悪天候時の情報へ、すぐアクセスしにくい

商店・事業者側の課題

• 有名観光地から離れた店舗へ人を呼び込みにくい
• 情報発信力やデジタル活用力に店舗ごとの差がある
• 観光需要の季節・曜日・時間帯によって売上が変動する
• 独自アプリを開発・運用する予算や人員を確保しにくい

自治体・DMO側の課題

• 交通調査や観光アンケートに時間と費用がかかる
• 複数の観光情報を一元管理することが難しい
• 記事や情報を公開するまでに確認・承認作業が発生する
• 施策の成果をデータで把握し、改善へつなげにくい

これらの課題は独立しているのではなく、互いに影響し合っています。

観光客が集中すると住民の生活負担が増え、地域店舗の収益機会にも偏りが生まれます。

一方で、地域側が情報を発信できなければ、観光客は有名スポット以外の選択肢を見つけられません。

そのため、関係者が別々に動くのではなく、情報と運用を共有できる仕組みが必要だと考えました。

03. アプリコンセプト

ブランド設計

「源頼朝」と「地域資源」を重ねた名称「源 -MINAMOTO-」

アプリ名は「源 -MINAMOTO-」としました。

名称には、鎌倉と縁の深い源頼朝公の「源」と、鎌倉に眠る多様な地域資源を活かすという二つの意味を込めています。

サービス名を見ただけで鎌倉らしさを感じられる一方、英字の「MINAMOTO」を組み合わせることで、現代的なデジタルサービスとしても成立するブランド表現を目指しました。

サービスのキャッチコピー

目指した体験

観光客に一方的に情報を提示するのではなく、その人の目的、同行者、趣味嗜好、当日の状況に合わせて、より良い選択肢を提示する「ツアーコンシェルジュ」を目指しました。

AIによる高度な自動提案までは実装できませんでしたが、まずは情報を一元化し、目的別に選べる設計とすることで、一般的な王道ルート以外の魅力へ気づける体験を検討しました。

04. 3つの狙い

サービス方針

混雑回避・個別提案・地域体験の3軸で価値を設計

本アプリでは、観光客の散策満足度と、地域関係者のメリットを両立させるため、3つの狙いを設定しました。

1. 人の流動・動線を分散し、混雑を回避する

混雑している主要観光地だけでなく、比較的空いている時間帯や別の散策スポットを案内します。

観光客の選択肢を増やすことで、特定エリアへの過度な集中を減らし、地域内の回遊を促すことを狙いました。

2. 趣味嗜好や同行者に合う散策を提案する

寺社、歴史、グルメ、甘味、工芸体験、自然、買い物など、目的別に情報を整理します。

一人旅、家族、友人、カップルなどの同行者や、滞在時間、天候に応じて、自分たちに合う散策を選びやすくする設計です。

3. 地域の魅力や職人技を体験へつなげる

観光名所だけでなく、商店街、個人店舗、工房、体験施設なども掲載対象とします。

地域の技術や文化を「見る情報」だけで終わらせず、予約・体験・買い物につなげることで、地域PRと消費額向上への貢献を目指しました。

司会

観光客を有名スポットへ案内するだけではないんですね。

はい。地域全体へ人の流れを広げ、観光客と地域の双方にメリットをつくることを意識しました。

05. ターゲットと利用シーン

ユーザー設計

目的・同行者・滞在条件によって変わる観光ニーズに対応

観光客のニーズは一様ではありません。

寺社や歴史を深く知りたい人もいれば、グルメやスイーツを中心に巡りたい人、工芸体験をしたい人、自然の中を歩きたい人もいます。

そこで、利用者が目的ジャンルを選び、自分たちに合う情報へ進める構成を検討しました。

• 寺社・歴史めぐり
• 穴場・隠れスポット
• グルメ・食べ歩き
• 工芸体験・ものづくり
• スイーツ・甘味
• 歴史・史跡・文化財
• 買い物・お土産
• 季節・花・紅葉・自然

主な利用タイミング

• 旅行前に行きたい場所を整理するとき
• 鎌倉へ到着し、当日のルートを決めるとき
• 混雑や天候を見て予定を変更するとき
• 予定より時間が余り、近くのスポットを探すとき
• 工芸体験や店舗イベントを予約するとき
• 災害や交通障害の情報を確認するとき

事前計画だけでなく、現地で発生する予定変更にも対応できる観光支援を目指しました。

06. プラットフォーム構成

システム設計

LINE・hachidori・API・オープンデータで導入障壁を下げる

サービスの入口には、多くの利用者が日常的に使っているLINEを採用しました。

専用アプリを新たにダウンロードしてもらうのではなく、LINE公式アカウントを友だち追加することで利用を開始できれば、観光客側の導入障壁を下げられます。

運営側についても、hachidori、Googleカレンダー、API、オープンデータなどを組み合わせ、専門的なプログラミングへ過度に依存しない構成を検討しました。

構成要素

• LINE：観光客が情報へアクセスする入口
• hachidori：Botの会話シナリオやメニューを構築する基盤
• Googleカレンダー：地域イベントや営業情報の管理
• Googleフォーム：アンケートや交通調査の収集
• API：天気、地図、交通など外部サービスとの連携
• オープンデータ：自治体や地域情報の活用
• 独自サーバー：必要に応じたデータ管理や独自機能の拡張

運営側のメリット

• 初期の開発コストを抑えやすい
• 自治体や店舗自身が情報更新へ参加しやすい
• 既存の使い慣れたツールを利用できる
• 小規模なテスト運用から始めやすい
• 利用状況を見ながら段階的に機能を追加できる

この仕組みの中心にあるのは、開発会社へすべてを依存するのではなく、地域の関係者が自分たちで育てられるサービスにするという考え方です。

07. 機能と情報設計

機能設計

観光中に必要な情報を、6つのリッチメニューへ整理

LINE Botのリッチメニューには、観光中に必要となる主な情報を6つに整理しました。

散策スケジュール

訪問日や予定時間を登録し、当日の行動計画を確認する機能です。

Googleカレンダーと連携できれば、地域イベントや体験予約、店舗情報なども一元的に確認できると考えました。

地図・路線検索

観光スポットの位置だけでなく、鉄道、バス、徒歩ルートなど、移動に必要な情報へアクセスします。

混雑状況や交通障害に応じて、別ルートへ切り替えられることも将来的な構想に含めています。

スポットガイド・クイズ

寺社、歴史、工芸、グルメなどの解説に加え、クイズやゲーム要素によって観光体験を深めます。

受け身で情報を読むだけでなく、現地で発見しながら学べる体験を狙いました。

天気・災害情報

天気APIを利用し、散策当日の天候を確認します。

災害や交通障害が発生した際には、安全情報へすぐアクセスできる導線も重要だと考えました。

地域からの情報

自治体、商店街、店舗、工房などが、イベント、限定商品、空席、体験情報を配信します。

地域側が情報を更新できることで、観光客へ鮮度の高い情報を届けやすくなります。

設定

旅行目的、同行者、趣味嗜好、滞在時間などを登録します。

本格的なパーソナライズにはプログラム開発が必要ですが、将来的には登録情報に応じた散策提案へつなげる想定でした。

08. 調査とデータ活用

リサーチ設計

観光客の声と行動データを、地域改善へ循環させる

従来の交通調査や観光アンケートでは、現地に調査員を配置する必要があり、時間や費用がかかります。

また、回答数が少ない状態で割合だけを示しても、実態を正確に把握できないことがあります。

そこで、LINE BotやGoogleフォームを利用し、観光客が旅行中または旅行後に回答できる仕組みを検討しました。

取得したい情報

• 訪問したスポットと移動経路
• 滞在時間と混雑の感じ方
• 同行者や旅行目的
• 興味を持ったジャンル
• 予定変更の理由
• 店舗や体験の満足度
• 再訪意向や改善要望

収集した情報は、観光客への次回提案だけでなく、自治体の交通施策、店舗の営業時間、イベント企画、観光情報の改善にも活用できます。

利用者へ情報を提供するだけでなく、利用結果を地域へ還元し、サービス改善へ循環させることを目指しました。

観光アプリを、情報を見るだけのツールで終わらせない設計ですね。

司会

はい。利用データやアンケートを、地域側の改善へ戻す循環も重要だと考えました。

09. UI・ビジュアルデザイン

デザイン設計

鎌倉らしい世界観と、アプリの実用性を1画面で伝える

紹介サイトのファーストビューでは、鎌倉を象徴する大仏の写真を大きく配置しました。

観光アプリの機能から説明を始めるのではなく、最初に「どの地域の、どのような体験を扱うサービスなのか」を直感的に伝えることを重視しています。

大仏と青空による第一印象

歴史的な重厚感を持つ大仏と、明るく開放的な青空を組み合わせました。

歴史ある鎌倉の深みを伝えながら、観光へ出かけたくなる軽やかさも感じられるビジュアルを目指しました。

スマートフォンモックでサービスの実体を見せる

観光写真だけでは、一般的な観光サイトに見える可能性があります。

そこで、画面右側へスマートフォンのUIを配置し、LINEで利用するデジタルサービスであることを同時に伝えました。

左側で鎌倉の世界観を見せ、右側でサービスの具体性を見せることで、視線が自然にアプリへ着地する構成にしています。

ロゴを、地域とサービスを結ぶ軸にする

中央の「源 -MINAMOTO-」ロゴは、大仏の写真とスマートフォンUIをつなぐ役割を持たせました。

和を感じる漢字表記と、現代的な英字表記を組み合わせ、歴史的観光地とデジタルサービスの両立を表現しています。

感性と情報を分けたページ構成

ファーストビューでは写真とブランドで感情的な興味をつくり、その下では白背景を使って、企画・機能・システム構成を落ち着いて読めるようにしました。

観光の高揚感と、ポートフォリオとして必要な情報理解を、上下の2段構成で両立させています。

10. 制作中に発生した制約

開発上の課題

エンジニアの離脱を、運用モデルを見直す機会へ変える

当初は、チームのプログラマーと共同でLINE Messaging APIを利用した開発を進める予定でした。

しかし、応募締切前にプログラマーへお子様が誕生し、十分な開発リソースを確保することが難しくなりました。

その後、私自身で実装へ取り組みましたが、LINE Botの仕様理解やエラー対応に時間がかかり、企画やプレゼン資料をまとめる時間が減っていきました。

ノーコード開発への方針転換

開発に苦戦していた時期に、Bot構築サービスのhachidoriを教えていただきました。

GUIで会話シナリオを構築できるため、プログラムを一から書くよりも短期間でプロトタイプを作れる可能性がありました。

そこで、Messaging APIを中心とした実装から、hachidoriを主軸にしたノーコード・ローコード構成へ計画を変更しました。

自分の困りごとが、地域側の課題と重なった

この変更を通じて、私は次のことに気づきました。

これは、自分だけの問題ではありません。

自治体、DMO、商店街、個人事業主も、同じような悩みを持つ可能性があります。

自分の開発上のピンチが、運営側の導入障壁を考えるきっかけになり、サービス構成そのものを見直すことにつながりました。

11. 設計上の判断

UX判断

高機能な独自アプリより、参加しやすく育てやすい仕組みを優先

本企画で重視したのは、すべてを独自開発することではありません。

独自アプリで高度な機能を実装できても、利用者がダウンロードしてくれない、地域側が更新できない、運用費を継続できない状態では、サービスは定着しません。

そこで、機能の新しさよりも、以下の条件を優先しました。

1. 観光客が普段使っているLINEから利用できること
2. 自治体や店舗が、専門知識なしで更新へ参加しやすいこと
3. 小さくテストし、利用状況を見ながら改善できること
4. 初期費用・運用費・機能追加費を抑えられること
5. 複数の関係者が、それぞれの得意領域へ集中できること

関係者が担う役割

• 自治体・DMO：地域全体の情報整理、広報、オープンデータ提供
• 商店街・店舗：商品、イベント、空席、体験情報の更新
• 観光客：サービス利用、アンケート、口コミ、行動データ提供
• 開発・運用支援者：テンプレート整備、API連携、改善支援

デザイナーとして、画面上の使いやすさだけでなく、サービスへ参加する関係者全体の体験を設計対象としました。

12. スライド紹介

企画資料

課題・コンセプト・機能・システム構成を整理した提案資料

企画資料では、鎌倉の観光課題、ステークホルダー、アプリの3つの狙い、プラットフォーム構成、利用機能、運用モデルを整理しました。

画面デザインだけを提示するのではなく、「なぜこの機能が必要なのか」「誰がどのように運用するのか」まで説明できる資料構成を意識しています。

資料で意識したこと

• 課題と解決策の関係が一目で理解できること
• 観光客と地域側のメリットを分けて説明すること
• 文章だけでなく、図解や画面例で具体的に伝えること
• システム構成を非エンジニアにも理解しやすくすること
• 地域ブランドの世界観を資料全体で統一すること

13. 成果と振り返り

制作成果

応募結果だけでなく、運用を含むサービス設計を学んだ

LINE BOOT AWARD 2018では、一次選考を通過することはできませんでした。

一方で、今回の制作を通じて、観光アプリは利用者向けの画面を作るだけでは成立しないことを学びました。

地域の情報を誰が登録するのか。
情報の鮮度をどう保つのか。
店舗や自治体が参加しやすいか。
開発・運用費を継続できるか。
集めたデータを地域改善へ活用できるか。

こうしたサービス運用全体の設計が、観光DXでは重要になります。

改善すべき点

• 解決したい課題と機能を、初期段階でもう少し絞る
• 観光客向け価値と、地域運営者向け価値を明確に分けて説明する
• ノーコードで実現する範囲と、独自開発が必要な範囲を整理する
• 導入後の収益モデルや運用体制を、より具体的に示す
• 実際の観光客や店舗へのユーザー調査を行い、仮説を検証する

現在につながる学び

本企画で得た経験は、その後のUI/UX設計にもつながっています。

画面単体のデザインではなく、ユーザー、運営者、事業者、システム、コストを一体で考えること。

技術制約を単なるマイナスと捉えず、サービスモデルを見直す材料にすること。

利用者の導入障壁だけでなく、運営者の導入障壁もUXとして考えること。

これらは、現在のプロダクト設計でも大切にしている視点です。

司会

コンテストの結果以上に、運用を含めたサービス設計が大きな学びになったんですね。

はい。利用者だけでなく、地域側が続けられる仕組みまで考える必要性を学びました。

14. ポートフォリオとしての見どころ

アピールポイント

観光体験のビジュアル化と、地域運用を含むUX設計

この作品におけるポートフォリオ上の見どころは、観光アプリの画面を制作したことだけではありません。

地域課題を複数のステークホルダーから整理し、利用者向け体験と運営側の仕組みを一つのサービスとして設計した点にあります。

企画・UX

• 観光客、地域住民、商店、自治体の課題を構造化
• 混雑回避、パーソナライズ、地域体験という3つの価値を設定
• 旅行前・旅行中・予定変更時の利用シーンを整理
• 観光客の行動データを地域改善へ戻す循環を設計

UI・情報設計

• LINEのリッチメニューへ、観光機能を6カテゴリに整理
• 利用者が目的別に情報を選べる導線を設計
• 観光中の状況変化にも対応できる機能構成を検討
• 非エンジニアにも理解しやすい図解と資料を制作

ビジュアル・ブランド

• 鎌倉を象徴する大仏を中心に、地域性を明確化
• 「源」という和の名称と英字表記を組み合わせてブランド化
• 観光写真とスマートフォンモックを一画面で統合
• 世界観で惹きつけ、機能説明へ進ませる視線導線を設計

サービス・技術構成

• LINE、hachidori、Google、API、オープンデータを組み合わせた構想
• ノーコード・ローコードによる導入障壁の低減
• 小規模なテスト導入から拡張できる運用モデル
• 技術制約からサービス構成を再設計した対応力

表層のデザインだけでなく、観光体験をどのように構造化し、地域側の継続可能な運用へつなげるかまで考えたことが、本作品のアピールポイントです。

15. まとめ

まとめ

鎌倉の魅力を、観光客と地域が一緒に育てるサービスへ

「源 -MINAMOTO-」は、鎌倉を訪れる観光客の散策を支援しながら、自治体、DMO、商店街、個人事業主も運用へ参加できる観光コンシェルジュアプリとして企画しました。

観光客には、目的や同行者に合った情報、混雑を避ける選択肢、地域ならではの体験を届ける。

地域側には、低コストで情報発信へ参加し、観光客の声や行動データを改善へ活用できる仕組みを提供する。

その両方をつなぐため、LINE、hachidori、Googleサービス、API、オープンデータを組み合わせた構成を検討しました。

制作途中には開発リソース不足や実装エラーも発生しましたが、その制約をきっかけに、地域の運営者が抱える導入・更新・コストの課題へ視野を広げることができました。

本作品は、観光アプリのUI制作にとどまらず、地域課題の整理、サービスコンセプト、情報設計、ブランド表現、運用モデルまでを一貫して考えた企画です。

鎌倉観光を便利にするだけでなく、地域の人が一緒に育てられるサービスを目指した企画でした。

司会

デザイナーとして、画面・体験・運用を横断して考えたことが伝わるポートフォリオになりましたね。