🤖

家族LINEで使えるタスク管理BotをAIコーディング前提で作ってみた

に公開
AI
Firebase
個人開発
LINE Bot
Claude
tech

LINE上で動くタスク管理Bot 「わすれんボット」 を作りました。

https://wasurenbot.com
👉 https://wasurenbot.com

※ベータ版のため不具合や予期しない挙動が発生する可能性があります。ご利用は自己責任でお願いします。

この記事はプロダクト紹介というより、

  • 家族LINEで使うことを前提にしたタスク管理をどう設計したか
  • AIコーディングを前提にすると、実装や設計がどう変わるか
  • LINE × 自然言語入力をどう成立させたか

といった話になります。

LINEで「やること」が流れていく問題

子育て中の我が家では、

  • 「明日保育園にxxxを持っていく」
  • 「週末にxxxを買う」
  • 「今月中にプリントを持っていくの忘れない」

といったやりとりが、ほぼ全て 家族のグループLINEに集約 されます。

一方で、こうしたメッセージは、

  • あとで見返そうと思って流れる
  • 誰かが覚えている前提になる
  • 結果、忘れる

ということがよく起きていました。

Todoアプリを使えばいいのではと思って試行錯誤もしましたが、

  • 入れても開く習慣がつかない
  • 家族全員に定着させる難易度
  • いつの間にか使われなくなる

というケースがほとんどでした。

機能の問題というより、

家族で使う前提だと、新しいアプリを増やすこと自体が負担になる

というのが正直な感触です...。

LINEでタスク管理をしたい

そこで考えたのが、

  • すでに全員が使っている家族LINEに
  • 日本語でそのまま書いて
  • それが裏側で自動的にタスクを作成してくれる

という形です。

新しい操作やルールを増やさず、
家族LINEの会話の延長として使えることを重視しました。

入力体験は変えず、 解釈と整理だけを裏側でやる。

その役割をAIに任せる、という構成です。

「開発をどこまでAIに任せられるか？」という興味

もう一つ大きかったのが、

最近のAIエージェントがかなり強力なので、
自分で細かく実装しなくても、どこまで形になるのか試してみたかった

という興味です。

今回は特に、

  • 正規表現を書かない
  • 日付パースを自前で実装しない
  • 細かい例外を先回りしない

代わりに、

  • AIに「どう解釈してほしいか」を言語化する
  • 制約だけを渡す
  • その結果を前提に処理を書く

このやり方で、
用途として十分使えるラインに届くのかを検証してみたかった、という背景があります。

解釈ロジックを任せる

LINEで使う前提だと、

  • 書き方は人によってバラバラ
  • 主語が省略される
  • 文としてはかなりラフになる

という前提があります。

この状態で、

  • 正規表現
  • 厳密な日付パース
  • 例外処理の積み上げ

をやり始めると、実装が一気に破綻します。

今回は最初に、

意味解釈はコード上でやらない

と決めました。

Function Calling

https://platform.openai.com/docs/guides/function-calling

今回の実装の中心は OpenAI の Function Calling です。
これを単なる
「API連携の便利機能」としてではなく、

制御構造（if / switch）の代替

として使っています。

system prompt の例

const systemPrompt = `
あなたはタスク管理アシスタントです。

- タスクは「行動」を表す文章のみ有効
- 「次の〇曜日」は7日以内として解釈
- 意味のない単語はタスクとして扱わない
- 利用可能なタグ: ${availableTags.join(", ")}
`

ここに書いているのは、

  • 日付解釈ルール
  • バリデーション条件
  • 分類の制約

といった、
以前ならロジックとして書いていた判断基準です。

実装は「解釈された前提」で進める

await openai.chat.completions.create({
  model: "gpt-3.5-turbo",
  messages: [
    { role: "system", content: systemPrompt },
    { role: "user", content: messageText }
  ],
  tools: [
    { type: "function", function: { name: "createTask" } }
  ]
})

この設計で意識しているのは、

  • 解釈結果を過剰に疑わない
  • ズレたらロジックではなく prompt を直す
  • 精度は「日常用途として十分」で止める

という割り切りです。

開発フロー

実際の開発フローはこんな感じでした。

  • v0 でデザインの方向性を決める
  • Claude で構造と大枠を作る
  • Cursor でコードを整理・修正
  • 想定と違う挙動は prompt を調整
  • コード量が増えたらリファクタ

体感としては、

コードを書く時間より
「どう解釈してほしいか」を考える時間の方が長かったです。

v0

https://v0.app/

UIデザインは得意ではないんですが、今回はv0を使って、

  • 画面構成の叩き
  • コンポーネントの雰囲気
  • 全体のトーン

をほぼ任せました。

結果として、デザインが得意でなくても「それっぽい」UIをかなり短時間で作れたのは、かなり大きかったです。

個人的にはデザインのハードルがとても高かったので、ここを一気に下げてくれるAIは本当にありがたいですし、追い風に感じる人も多いんだろうな、と思いました。

Firebase

今回はインフラに Firebase を使っています。

理由はいくつかありますが、一番大きいのは、

ほぼすべての操作をコマンドラインから完結できる

という点でした。

  • プロジェクト作成
  • Functions / Hosting のデプロイ
  • エミュレータの起動
  • 環境の切り替え

といった一連の操作を CLI で完結できるので、
AIエージェントに実装からデプロイまで任せやすい という感触があります。

AIエージェントとの相性

  • 「デプロイまで含めてやってほしい」

といった指示を、かなりの割合で AI に投げていました。

その際、

  • Web コンソールでの手動操作が必要
  • GUI 前提の設定作業が多い

といった構成だと、
どうしても人間の介在が増えてしまいます。

Firebase は、

  • 設定がコード or CLI に寄っている
  • 構成が比較的シンプル
  • 変更が即反映しやすい

という点で、
AIエージェント前提の開発フローと相性がよかったです。

AIに渡すコンテキスト

AIエージェントに開発を任せるときに意識したのは、

どこまで文脈を共有するか

でした。

情報を渡しすぎると精度が落ち、 逆に足りないと既存の設計と矛盾した提案が返ってきます。

置いているドキュメントの例

  • context.md
    プロジェクトの背景、技術選定の理由、前提条件

  • project-knowledge.md
    設計上の決定事項や、避けたい実装パターン

  • common-patterns.md
    よく使う実装パターンやテンプレート

  • debug-log.md
    過去に起きた問題とその対処メモ

この構成にした理由

AIに「全部読んで」と渡すのではなく、

  • まず全体像を把握
  • 必要なときだけ詳細を見る

という流れを作りたかったからです。

実際、「なぜこの実装にしたか？」と聞かれたときも、
project-knowledge.md を参照すれば答えられる状態を保てています。

作ってみて感じたこと

この構成で作ってみて、

  • 実作業はかなり減った
  • 代わりに「意図を言語化する力」が重要になった
  • 設計の重心がコードから意図に移った

という変化を強く感じました。

ドキュメントをリポジトリに
どの粒度で置いていくか、といったベストプラクティスも
まだ試行錯誤中ですし、このあたりは新しい知見を追っていきたいところです。

おわりに

今回あらためて感じたのは、
AIを前提にすると、

個人開発でも取り得る設計の選択肢が一気に増える

ということでした。

ロジックを厚くする代わりに、
「どう使われるか」「どう解釈してほしいか」を考える時間が増え、設計の重心が少し変わった感覚があります。

もともと曖昧でラフな入力が前提の場所では、
このやり方は特に相性がいいのかもしれません。

何かの参考になれば嬉しいです。

もしよければ使ってみてください。
👉 https://wasurenbot.com

Discussion