「習慣化アプリ、結局開くの面倒で続かないな…」と思ったことありませんか？
私も同じで、アプリを開くのが面倒で結局やめてしまうことが多かったので、
普段使っているLINEで 「適当に送るだけ」 で記録できる習慣Botを作りました。
今回リリースしたLINEチャットボット
PottoHabit（ポットハビット） は、LINEで適当にメッセージを送るだけで習慣を記録できるトラッカーです
- LINEで適当にメッセージを送るだけで記録できる
- 回数・距離などの定量データも自動で抽出
- グラフや定量値による可視化
- 記録やサマリ、リマインドがLINEで完結
モチベーション
健康面が気になり始めたことをきっかけに、毎日運動を載せるLINEグループを友人と作ったのがきっかけです。
もともと習慣化アプリも使っていましたが、アプリを開く・記録する・友達と共有するのが面倒と言った理由で、結局続かず、、、
そこで、普段使っているLINEで完結できるように、適当なメッセージで自然に記録できるサービスを作ることにしました。
リリースまでの1か月を紹介
0. 全体の流れ
今回のリリースまでは、ざっくり以下の流れで進めました。
機能設計からリリースまで一通り実施できたので、各工程で意識したポイントも含めて紹介していきます。
- チャットボットの機能設計
- アーキテクチャの検討
- LINE公式アカウントの準備
- 実装と検証（友人の協力含む）
- Stripeによる課金実装
- リリース
1. チャットボットの機能設計
今回の機能設計では、「とにかく手間をなくすこと」を最優先に考えました。
従来の習慣化アプリでは、アプリを開く⇒記録する⇒設定を操作する、といった一つ一つの操作が積み重なり、継続のハードルになってしまいます。
そこで、LINEをインターフェースとして最大限活用し、以下の機能をコアとして実装しました。
- LINE上でユーザが適当にメッセージを送るだけで、定量値も含めて自動で記録される
- 入力の手間を最小化
-
グループで友達と話しながら、会話を邪魔せずに使用できる
- 共有・継続のモチベーションアップに
- LINE上でリマインドや振り返り（サマリ）が自動で届く
- アプリを開かなくても振り返りができる
- リマインド設定などの操作も、適当なメッセージで完結
- UI操作を極力排除
今回は目標達成型ではなく、気軽に使い続けられる「ログ型」のサービスとして設計しています。
その他、習慣化サービスとして必要な機能として以下を用意しています。
- Webポータル画面
- グラフや定量値による詳細な振り返り
- リマインド設定や過去の記録の修正
- 課金管理
- 継続のモチベーションとなる育成要素（実装中）
2. アーキテクチャの検討
前提として今回は個人開発であり、チャットを随時処理する形式のため、
- 低コストで運用できること
- スケーラブルであること
- 運用の手間が少ないこと
を重視してアーキテクチャを検討しました。
その結果、普段AWSを使用していることもあり、Lambda (Node.js)、API Gateway、DynamoDBといったよくあるサーバレス構成を採用しています。
ただし、単純なサーバレス構成では対応しきれない部分もあったため、いくつか工夫しているポイントもあります。
- 自然言語の解釈
- ユーザが自由に入力するメッセージをそのまま扱う必要があるため、定型的なパースではなく、Bedrock（LLM）を用いて構造化データへ変換。
- Webhook処理と業務処理の分離（SQS）
- スパイク時の安定性や責務分離の観点から、Webhookの受信と実際の記録処理をSQSで分離。
- バッチ処理の疎結合化（SQS）
- スケジュール起動するサマリ生成やリマインド処理について、実行時間や責務分離の観点から、対象ユーザの抽出と実際の処理をSQSで分離。
インフラ～フロントまでの実装には以下を使用しています。基本的にはClaudeに書かせて、レビュー・修正していった形となります。
- フロント：Svelte / SvelteKit
- 軽量でシンプルに実装できる点が個人開発と相性が良く、新規技術のキャッチアップも兼ねて採用
- バックエンド：Node.js
- AWS SDKを使用可能かつ、今後AWSのエージェントフレームワーク（Strands Agents）に移行する可能性があるため。
- インフラ：Terraform
- 使い慣れているため。
3. LINE公式アカウントの準備
LINE公式アカウントを作成し、Webhook連携の準備を行います。
LINE Official Account Managerと、LINE Developersの両方を登録・設定しました。
LINEのWebhook連携ではHTTPS通信が必須となるため、検証環境の用意がポイントになります。
私は実装初期からドメインを用意していたため、LambdaにデプロイしたバックエンドをAPI Gateway・Route53でHTTPS公開し検証しました。
一方で、インフラやドメインのコストを抑えたい場合は、ngrokを使用することでローカル環境をHTTPSとして公開し、Webhookの検証を行うことも可能です。
4. 実装と検証（友人の協力含む）
今回はClaude CodeのProプランを活用し、コード生成 → レビュー → 修正のサイクルをガンガン回しながら開発を進めました。
インフラを含めCI/CDを構築し、自動でAWS上にデプロイする構成としていたので、実際にLINEでメッセージを送りながら即座に動作確認していました。
実装を進める中で特に重要だったポイントは以下です。
- SQSによる疎結合
- 各機能の責務を明確に分離し、処理単位ごとに独立して実行。
- 例）サマリ対象のユーザ抽出 ⇒ SQS ⇒ サマリ生成＋メッセージ送信
- 各機能の責務を明確に分離し、処理単位ごとに独立して実行。
- 冪等性の担保（Stripe / LINE Webhook）
- Webhookは同じイベントが複数回送信される可能性があるため、重複処理を防ぐ設計が必要でした。
また、友人や家族にも実際に使ってもらい、フィードバックをもらいながら改善を進めました。
本当に感謝です。
5. Stripeによる課金実装
機能がある程度揃ったタイミングで、Stripeによる課金実装を行いました。
Stripeに登録後、審査や設定を進めつつ、サブスクリプション課金を実装しています。
6. リリース
LPの作成や課金導線の整備を行い、ベータ版としてリリースしました。
現在は育成機能のアップデートを進めている段階です。
リリースしてみた感想
- Stripeの実装まで完走できたことで、今後Webサービスを個人開発する際の有償化への不安がなくなった。
- アイデア→機能設計→アーキテクチャの流れは、個人開発でフットワークが軽くても手を抜いてはいけない部分だと改めて実感した。後からの修正負荷に直結する。
- AIが優秀なので、基本は「動かしてフィードバック→修正」のサイクルを回すのが効率的。ただし、後から自分で読んで理解できない実装はその場で立ち止まるようにした。
- 次の課題はリリース後のマーケティング。「作る」より「使ってもらう」 の方が難しいと痛感している。
おわりに
最後まで読んでいただきありがとうございました！
PottoHabit（ポットハビット）、ぜひ一度使ってみてください。
LINEを開くだけで始められるので、まずは気軽に友達追加してみてもらえると嬉しいです。
ベータリリースということでまだまだ改善中です。フィードバックや感想があればこちらのフォームで送ってもらえると励みになります！
補足
本記事は、Zennに同じ内容を投稿しております