はじめに
突然ですが、私は石を拾うのが好きです。
河川敷で瑪瑙を見つけたり、山で水晶を探したり、海でジャスパーを拾っています。
拾った石をタンブリングで磨いて、ワイヤーアクセサリーに仕上げる。この一連の流れが最高に楽しい。
現在国外に住んでいて、週末にrock hounding（石拾い）に出かけるのが趣味なのですが、帰国後も続けたい。でも、ふと思ったんです。
「日本で石拾いスポットを探せるアプリ、なくない？」
調べてみたら、本当になかった。なので企画をはじめました。
反応がよければ作りたいと思っています。
この記事は、エンジニアが趣味ドリブンでアプリを企画するまでの過程を書いたものです。技術選定やDB設計にも触れるので、個人開発を考えている方の参考になれば嬉しいです。
日本市場を調べてみた
まず既存のアプリやサービスを調べました。
日本で使われているもの
| サービス | 特徴 | 石拾い専用？ |
|---|---|---|
| ヤマレコ | 登山GPS。ルート共有で鉱物採集に流用する人もいる | × |
| スーパー地形 | 地質図も見られるGPSアプリ。プロも使う | × |
| 趣味人倶楽部 | SNS。鉱物採集コミュニティがある | × |
| X / Lemon8 | 採集報告の投稿はあるが、マップ共有はない | × |
海外にはある
| サービス | 特徴 |
|---|---|
| Rockd | 岩石識別 + 地質SNS。マップにピン留め、AR機能あり |
| Rockhounding.org | GPS座標付きスポット投稿、コメント、投票。全米50州対応 |
| GaiaGPS | 地質マップ、鉱山レイヤー、土地所有区分を表示 |
結論：日本語対応で「マップ × コミュニティ × 鉱物採集」を統合したアプリは空白地帯。
ニッチだけど、だからこそ刺さる人には深く刺さる。やる価値あり。
どんなアプリにするか
名前は COBO STONE（仮）。
石拾いユーザーの行動サイクルに沿って、アプリが自然にフィットする設計を目指します。
スポットを探す → 石を拾う → 記録する → 磨く/加工する → 見せる
今はこの各ステップがバラバラのツール（ヤマレコ、カメラロール、X、メルカリ等）に散らばっています。これを一つの場にまとめるのがCOBO STONEの役割です。
コア機能（3つ）
① スポットマップ
- 地図上にピンを立てて採集スポットを共有
- 石の種類でフィルタリング
- コメント・いいね
② 採集ログ
- 拾った石を写真+場所+種類で記録
- タイムラインで振り返り
③ 作品ギャラリー
- タンブリングやワイヤーアート作品の投稿
- Before/After（原石→完成品）を紐づけられる
設計で悩んだポイント
1. ログイン画面は要らない
コミュニティアプリだからといって、起動直後にログイン画面を出すのはNG。ストアで見つけて開いた瞬間に離脱されます。
フリクションポイント認証を採用しました。
アプリ起動 → すぐマップ表示（ログイン壁なし）
閲覧 → 自由
投稿・コメント・いいねボタンをタップ → ここで初めてログインを促す
「投稿したい」と思った時点でユーザーのモチベーションは高いので、コンバージョンしやすい。認証方法はGoogle Sign-InとApple Sign-Inの2つだけ。メアド登録は省略。
2. 石の種類がわからない問題
一般の人は拾った石の種類なんてわかりません。投稿時に「石の種類を選んでください」と出したら、そこで手が止まる。
解決策はシンプルです。
- 「よく登録される石」をチップ表示（ワンタップ選択）
- そのスポットで過去に見つかった石を自動表示（他ユーザーの投稿から集計）
- 「わからない」ボタンを堂々と置く
「わからない」で投稿すると、コミュニティの詳しい人がコメントで教えてくれる。これがコミュニケーションのきっかけになるので、むしろ正解です。
AI画像認識による石の自動鑑定は将来的に入れたいですが、MVPでは見送り。
3. 採集スポットを教えたくない心理
鉱物採集の世界では「産地を教えたくない」という文化があります。苦労して見つけたスポットを公開するのは抵抗がある。
そこで公開範囲を選択制にしました。
- 「エリアのみ」（デフォルト）：市区町村レベルで表示
- 「詳細座標も公開」：正確な位置を表示
デフォルトが「エリアのみ」なので、投稿者は安心して共有できます。
4. タンブリングする人は少数派
タンブリング（研磨機で石を磨く工程）やワイヤーアクセサリー制作をする人は、石拾い全体から見るとかなりの少数派です。
なのでBefore/After機能を強制しない設計にしています。
- 投稿時に「石の状態」をタグ選択：原石（デフォルト） / タンブリング済 / 加工済
- ほとんどの人は「原石」のまま投稿。それでOK
- 加工する人だけ、同じ石に後から写真を追加できる（石の成長日記）
少数派が生み出すコンテンツは質が高い。コミュニティの核になります。
5. 山奥で電波がない
鉱物採集は山奥や河川敷が多く、電波がないことがよくあります。
MVPではオフライン地図は見送り（実装コストが重すぎる）。代わりに：
- GPS座標の取得は電波不要（端末のGPSチップで動作）
- 写真＋座標＋メモをローカル保存
- 電波復帰時にまとめてアップロード
「オフラインで記録、帰宅後にまとめて投稿」という体験を実現します。
なぜWebじゃなくネイティブアプリなのか
「スポット共有ならWebアプリでよくない？」と思うかもしれません。僕も最初は考えました。でも石拾いというユースケースを考えると、ネイティブ一択でした。
- 現場で使う。山奥や河川敷で片手にスマホ、片手にハンマー。ブラウザを開いてURLを打つ体験ではない
- GPS・カメラへの即時アクセス。写真を撮ってその場で位置情報と紐づける動作がコア体験。PWAでもできなくはないが、OSごとの挙動差が大きい
- オフライン保存。電波のない場所でローカルにデータを溜めて、復帰時に同期する。これはネイティブの方が圧倒的に安定する
- プッシュ通知（将来）。「あなたの投稿にコメントがつきました」はコミュニティを回す上で不可欠。Webプッシュはまだ制約が多い
逆に管理コンソールはWebで作ります。管理者が使うだけなので、ブラウザで十分です。
技術スタック
Frontend: Flutter（iOS / Android 両対応）
Backend: AWS Amplify Gen2
Auth: Amazon Cognito（Google / Apple Social Sign-In）
DB: Amazon DynamoDB
Storage: Amazon S3
Map: Google Maps SDK for Flutter
Flutterを選んだ理由は、1人で両OSをカバーできること。Amplify Gen2はCognitoやDynamoDBのセットアップが圧倒的に速い。個人開発にはこの組み合わせが最適だと考えています。
管理コンソール（タグ管理・ユーザー管理）はFlutter Webで作ります。モデル定義をモバイルアプリと共有できるので、別フレームワークで書くより手間が少ない。
DB設計（DynamoDB）
MVPで必要なテーブルは8つ。
| テーブル | 用途 |
|---|---|
| User | ユーザー情報 |
| Spot | 採集スポット |
| StoneTag | 石の種類マスタ |
| Collection | 採集記録 |
| GalleryPost | ギャラリー投稿 |
| Comment | コメント |
| Like | いいね |
| Report | 通報 |
Spot テーブルの設計例
Spot
├── id (PK): UUID
├── name: スポット名
├── latitude / longitude: 座標
├── areaName: エリア名（市区町村）
├── prefecture: 都道府県
├── locationType: 河川敷 / 渓谷 / 海岸 / 山
├── stoneTags: [タグID配列]
├── difficultyLevel: 初心者向け / 中級 / 上級
├── visibilityLevel: "area" / "exact"
├── rating / ratingCount / likeCount
├── photoKeys: [S3キー配列]
├── authorId: 投稿者ID
└── createdAt / updatedAt
ポイントは visibilityLevel。「area」の場合、クライアント側で座標をエリア中心点に丸めて表示します。生の座標はDBに保存するけど、APIレスポンスではマスキングする設計です。
S3 バケット構成
cobo-stone-media/
├── spots/{spotId}/{uuid}.jpg
├── collections/{collectionId}/{uuid}.jpg
├── gallery/{postId}/{uuid}.jpg
└── avatars/{userId}.jpg
画面構成
ボトムナビ5タブ構成です。
[ マップ ] [ ログ ] [ ＋ ] [ ギャラリー ] [ マイページ ]
中央の「+」ボタンから3種類の投稿ができます。
- スポットを登録する
- 採集を記録する
- 作品を投稿する
投稿フローは4ステップ。30秒で完了する設計です。
写真を撮る → 場所（GPS自動） → 石の種類（任意） → 確認して投稿
開発の進め方
8つのフェーズに分けて、少しずつ積み上げていきます。
| フェーズ | 内容 |
|---|---|
| 1 | プロジェクト初期設定 + ボトムナビ |
| 2 | マップ画面（ホーム） |
| 3 | スポット詳細 + コメント・いいね |
| 4 | 投稿フロー（スポット登録 + 採集記録） |
| 5 | コレクションログ画面 |
| 6 | ギャラリー画面 |
| 7 | マイページ + ユーザー設定 |
| 8 | 管理コンソール（Flutter Web） |
もし開発がきまれば、次回の記事では、フェーズ2のマップ画面をFlutter + Google Maps SDKで実装する過程を書く予定です。
おわりに
「こんなニッチなアプリ、誰が使うの？」と思われるかもしれません。
でも、日本には1,139種もの鉱物が発見された記録があり、河川敷や海岸で瑪瑙や翡翠を拾うのを趣味にしている人は確実にいます。ただ、その人たちが集まれる場所がない。
小さくても濃いコミュニティを作る。 それがCOBO STONEの目標です。
「こんなアプリ作るべきだと思う！」という方は、いいねください。 いいねの数で需要を判断して、実際に作るかどうか決めます。皆さんの一票が開発のゴーサインになります。
宣伝
COBO STONEと同じ技術スタック（Flutter + AWS Amplify Gen2）で先にリリースしたアプリがあります。
Cobo Memo
AWS・情報処理試験・TOEIC・プログラミング言語の文法など、暗記が必要な学習全般に使えるように設計している。カードからそのままテスト用紙を出力できる。
過去の投稿記事：「カード作りが面倒すぎる」問題をAIで解決したら、資格勉強が続くようになった
次回予告（みなさまの反応で開発がGOになれば）
「鉱石拾いが好き。地図にピン立てていい？（マップ実装編）」
Flutter + Google Maps SDKでスポットマップを実装します。ピンのクラスタリング、カスタムマーカー、ボトムシートの実装あたりを書く予定です。お楽しみに。