0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ei_1263_

LINE×AIで楽に生活を管理させたい

0
Last updated at Posted at 2026-08-28

LINE×AIで楽に生活を管理させたい

はじめに

「月曜日は何ごみだっけ？」

「制服、最後に洗濯したのいつだっけ？」

「トイレ掃除、いつやったっけ？」

一人暮らしをしていると、このようなことを意外と考える機会があります。

もちろん、カレンダーやメモ帳などに記録しておけば解決できます。

ただ、個人的には、

そもそもこういうことを自分で覚えておいたり、記録を探したりすること自体を減らしたい

と思いました。

そこで、日常生活における「記録・確認・判断」をAIに任せ、生活について考える回数を減らすことを目的とした個人向けシステムを作りました。

名前は仮に Life AI としています。

コンセプトはかなりシンプルで、

「生活情報をGitHubに置いて、LINEからAIに聞く」

です。

どんなことができるのか

現在は、主に以下のような情報を管理しています。

  • ゴミ出し情報

    • 曜日
    • 分別

  • トレーニング記録

    • 各種目のMAX
    • 直近のトレーニング記録

  • 掃除

    • 各場所の最終実施日

  • 洗濯

    • 衣類などの最終洗濯日

例えばLINEから、

いつトイレ掃除した？

と送ると、AIがGitHub上の生活データを確認して、

8月17日です。

のように回答してくれます。

また、

そろそろトイレ掃除したほうがいい？

のように、単純な検索だけではなく、保存されている情報をもとに判断させることもできます。

重要なのは、生活を厳格に管理するシステムにはしないことです。

「毎週○曜日に必ず掃除する」といったルールを厳密に強制するのではなく、

必要なときに聞けば、AIが生活情報を確認してくれる

くらいの「ゆるい管理」を目指しています。

全体の構成

全体としては、かなりシンプルな構成です。

┌─────────────┐
│ 👤 ユーザー
└──────┬──────┘
       │
       │ 「いつトイレ掃除した？」
       ▼
┌─────────────────┐
│ LINE Messaging API │
└──────┬──────────┘
       │
       │ Webhook
       ▼
┌────────────────────┐
│ ☁️ Cloudflare Workers │
│                      │
│ ・署名検証            │
│ ・メッセージ取得       │
└────────┬───────────┘
         │
         │ message
         ▼
┌────────────────────┐
│ 🤖 Gemini API        │
│                      │
│ 「どのToolか判断」     │
└────────┬───────────┘
         │
         │ Function Call
         ▼
┌────────────────────┐
│ Life AI Tool        │
│ ・掃除Tool           │
│ ・洗濯Tool           │
│ ・ゴミTool           │
│ ・筋トレTool         │
└────────┬───────────┘
         │
         │ GitHub API
         ▼
┌──────────────────────────┐
│ 🐙 GitHub Private Repository │
│                            │
│ ・cleaning.yaml            │
│ ・laundry.yaml             │
│ ・training.yaml            │
│ ・trash.yaml               │
└────────┬─────────────────┘
         │
         │ Tool Result
         ▼
┌────────────────────┐
│ 🤖 Gemini API        │
│                      │
│ 最終回答を生成        │
└────────┬───────────┘
         │
         │ answer
         ▼
┌────────────────────┐
│ ☁️ Cloudflare Workers │
└────────┬───────────┘
         │
         │ LINE Reply API
         ▼
┌─────────────┐
│ LINE        │
│             │
│「8月17日です」│
└──────┬──────┘
       │
       ▼
┌─────────────┐
│ 👤 ユーザー  │
└─────────────┘

ユーザーから見ると、

LINE → AI → 回答

だけです。

しかし内部では、

LINE → Cloudflare Workers → Gemini → Tool → GitHub → Gemini → LINE

という流れになっています。

技術スタック

今回使用した技術は以下です。

項目 技術
UI LINE
AI Gemini API
サーバー言語 TypeScript
Webフレームワーク Hono
バリデーション Zod
実行環境 Cloudflare Workers
データ保存先 GitHub Private Repository
データ形式 YAML / Markdown
永続化 GitHub Repository
テスト Vitest
DB 使用しない

特徴的なのは、データベースを使っていないことです。

なぜこの技術構成にしたのか

AI：Gemini API

まずAIについては、できるだけ無料で使いたいという理由がありました。

ChatGPTやGeminiなどのアプリをそのまま使うだけでは、今回やりたいような「自分の生活データを読み書きする」という拡張がしづらいです。

例えば、

AIに「トイレ掃除した」と伝える
↓
AIがGitHubのデータを書き換える

といった処理を、自分で作ったシステムとして実現したかったため、APIを利用することにしました。

Claude Codeも選択肢にはありましたが、継続的に利用するにはコストがかかります。

Discordも候補にはありました。

ただ、Discordは個人的にPCで使うことが多く、今回の用途では、

スマホからすぐ使えること

を重視しました。

その結果、

  • スマホから利用できる
  • LINEをUIとして使える
  • APIとして利用できる
  • 無料枠が比較的多い

という理由から、Gemini APIを採用しました。

UI：LINE

生活管理システムなので、専用のWeb画面を作る必要性をあまり感じませんでした。

スマホで、

「明日は何ごみ？」

と聞ければ十分です。

そこで、UIとしてLINEを採用しました。

LINE Messaging APIを使えば、LINEからWebhookでメッセージを受け取り、処理した結果をReply APIで返すことができます。

つまり、

LINEそのものを生活管理システムのUIとして利用する

という考え方です。

データ：GitHub Private Repository

今回、データベースを使わず、GitHub Private Repositoryに生活情報を保存しています。

例えば、

data/
├── cleaning.yaml
├── laundry.yaml
├── training.yaml
└── trash.yaml

のような構成です。

理由は単純で、

この程度の個人データなら、DBを用意する必要がないのでは？

と考えたからです。

さらに、YAMLにしておけば、

  • 人間にも読みやすい
  • GitHub上で確認できる
  • Gitで変更履歴を管理できる
  • AIから扱いやすい
  • GitHub APIだけで読み書きできる

というメリットがあります。

今回は「大量のデータを高速に検索する」といった要件もありません。

そのため、当面はDBを使わない構成にしました。

Cloudflare Workers × Hono

実行環境にはCloudflare Workersを採用しました。

理由は、

  • 無料枠が充実している
  • デプロイが簡単
  • サーバーを管理しなくてよい
  • 今回のようなWebhookベースの処理と相性がよい

といった点です。

また、TypeScriptでサーバーを実装したかったため、WebフレームワークにはHonoを採用しました。

今回初めてCloudflare WorkersとHonoを使いましたが、この組み合わせはかなり使いやすいと感じました。

Function Calling / Tool

このシステムで重要なのが、Gemini APIのFunction Callingです。

例えばユーザーが、

「いつトイレ掃除した？」

と質問した場合、AIに直接GitHub APIを触らせるわけではありません。

Life AI側で、例えば以下のようなToolを用意しています。

cleaning_get_last_done
cleaning_get_recommendation
cleaning_update_last_done

laundry_get_last_done
laundry_get_recommendation
laundry_update_last_done

training_get_max
training_get_recent
training_update_max
training_add_record

trash_get_schedule
...

Geminiには、

「ユーザーの質問に応じて、適切なToolを選択してください」

という形でToolを渡します。

例えば、

ユーザー
「いつトイレ掃除した？」

        ↓

Gemini

「cleaning_get_last_doneを使おう」

        ↓

Life AI Tool

GitHubからcleaning.yamlを取得

        ↓

Tool Result

「トイレ：2026-08-17」

        ↓

Gemini

「8月17日です」

という流れです。

この構成にすることで、AI自身にデータ管理の細かい実装をさせるのではなく、

AI：何をしたいか判断する

Tool：実際にデータを操作する

という役割分担にしています。

ディレクトリ構造

現在のディレクトリ構造は以下のようになっています。

.
├── src
│   ├── errors
│   │   └── # カスタムエラー（例外時に投げる）
│   │
│   ├── features
│   │   └── feature
│   │   　　　├── schemas.ts
│   │  　　　 ├── tool.test.ts
│   │   　　　└── tools.ts
│   │
│   ├── lib
│   │   ├── __mocks__
│   │   │   └── # Vitest用モック
│   │   ├── gemini
│   │   │   ├── ask.ts
│   │   │   ├── askGemini.test.ts
│   │   │   └── client.ts
│   │   ├── github.test.ts
│   │   ├── github.ts
│   │   └── yaml.ts
│   │
│   ├── middleware
│   │   └── # LINEの署名検証
│   │
│   ├── routes
│   │   └── # ルーティング
│   │
│   ├── constants.ts
│   │   └── # ファイルパスなどの定数
│   │
│   ├── index.ts
│   │   └── # エンドポイント
│   │
│   └── utils.ts
│       └── # 汎用関数
│
├── .gitignore
├── biome.json
├── package-lock.json
├── package.json
├── tsconfig.json
├── vitest.config.ts
├── worker-configuration.d.ts
└── wrangler.toml

機能単位で features にまとめています。

例えば掃除に関する機能であれば、

features/
└── cleaning/
    ├── schemas.ts
    ├── tools.ts
    └── tool.test.ts

という形で、スキーマ・Tool・テストをまとめています。

一方で、GeminiやGitHubなど、複数の機能から利用するものは lib に置いています。

データ構造

データはYAMLで管理しています。

あくまで現在のイメージですが、例えば掃除なら以下のようになります。

areas:
  - name: トイレ
    last_done: 2026-08-17

  - name: 風呂
    last_done: 2026-08-16
    additional_tasks:
      - name: バスロマン
        last_done: 2026-07-20

洗濯なら、

items:
  - name: 普段着
    last_done: 2026-08-17

筋トレなら、

max:
  - exercise: ベンチプレス
    max: 95
    unit: kg
    updated_at: 2026-08-15

ゴミ出しなら、

schedule:
  # 毎週
  - weekday: monday
    type:

  # 第1金曜日
  - weekday: friday
    week: 1
    type:

rules:
  - name: アイロン
    type:

といった形です。

もちろん、これはあくまで例です。

実際には機能ごとに必要な情報を持たせています。

なぜYAMLなのか

今回YAMLを選んだ理由は、単純に「人間にもAIにも扱いやすそうだったから」です。

例えばDBの場合、

users
cleaning_records
laundry_records
training_records
trash_schedules
...

のようにテーブル設計が必要になります。

しかし今回管理したいのは、あくまで自分の生活情報です。

しかも、

  • 大量のデータではない
  • 複雑な検索をしない
  • 高い同時実行性も必要ない
  • 自分で中身を確認したい
  • AIから読み書きしたい

という条件です。

そのため、

「わざわざDBを導入するほどでもない」

と判断しました。

GitHub上のYAMLをそのまま生活情報のストレージとして使っています。

実際の写真

ここでは実際にLINEからLife AIを利用している様子を載せます。

例えば、

「いつトイレ掃除した？」

と質問すると、

「8月17日です」

のように回答します。

また、

「そろそろトイレ掃除したほうがいい？」

のように、記録された情報をもとにAIに判断させることもできます。

1000005129.jpg

1000005130.jpg

今後やってみたいこと

今後は、生活に関する情報をもう少し増やしていきたいと思っています。

ゆるい在庫管理

例えば、

トイレットペーパー
洗剤
シャンプー
米

などの在庫を、

十分
少ない

くらいの大雑把な粒度で管理してみたいです。

厳密に「残り3個」のような管理をするのではなく、

「そろそろ買ったほうがいいものある？」

と聞いたら答えてくれるくらいが理想です。

家電情報

家電についても、

  • メーカー
  • 型式
  • 型番
  • 代表的なトラブル
  • トラブルシューティング
  • 取扱説明書に関する情報

などをYAMLやMarkdownで管理してみたいです。

例えば、

「洗濯機の○○が点滅してるんだけど何だっけ？」

と聞いたら、保存している家電情報をもとに回答してもらうような使い方です。

ランニング記録

筋トレではMAXや直近の記録を保存していますが、ランニングについても、

「自己ベストは？」

と聞いたら答えられるようにしてみたいです。

例えば、

5km
10km
ハーフマラソン

などの記録を残しておき、自己ベストを管理するイメージです。
日々の記録はスマートウォッチで十分ですかね。

お金の管理について

お金についても管理対象にすることは考えました。

ただ、現在はマネーフォワードを利用しているため、あえてLife AI側で同じものを作る予定はありません。

一方で、

クレジットカードなどのAPIを個人でも簡単に利用できるようになったら面白そう

とは思っています。

そこまで簡単に金融データを取得できる環境があれば、Life AIとの連携もやってみたいです。

作ってみての感想

今回、初めてCloudflare WorkersとHonoを使ってみました。

個人的には、

Cloudflare Workers × Hono、かなり良い

という感想です。

今回のような小規模なAPIサーバーであれば、かなり手軽に作ってデプロイできます。

また、今回はAIを使ってコードを書く、いわゆるバイブコーディングも積極的に活用しました。

ただ、単純に「AIに全部コードを書かせて動けばOK」という作り方にはしないようにしました。

今回作ったものは自分だけが使う小さなシステムではありますが、今後、

  • 新しい生活情報を追加する
  • 新しいToolを追加する
  • GitHub以外のデータソースを追加する
  • AIに新しい判断をさせる

といった拡張をする可能性があります。

そのため、

「今動けばいい」ではなく、「後から機能を追加しやすいか」

を意識して開発しました。

例えば、掃除・洗濯・筋トレ・ゴミ出しといった機能を features 単位で分けたり、GeminiやGitHubなどの外部サービスとの処理を lib に切り出したり、Toolごとにスキーマやテストを用意したりしています。

AIに実装を手伝ってもらいつつも、

どんな構成にするか、どこを責務として分離するか

については自分で考えるようにしました。

個人開発なので、そこまで大げさな設計は必要ありません。

それでも、最初からある程度拡張性を意識しておくことで、後から機能を追加するときに「全部作り直す」という状態は避けられると思っています。

そして、外部APIをいくつか実際に触ってみて、改めて感じたのが、

結局、リファレンスを読むのが大事

ということです。

今回は、

  • LINE Messaging API
  • Gemini API
  • GitHub API
  • Cloudflare Workers

など、複数のサービスを組み合わせました。

AIにコードを書かせること自体はかなり簡単になりましたが、APIの仕様や制約までAIが完全に保証してくれるわけではありません。

実際に動かすためには、公式ドキュメントを読んで、

  • どのようなリクエストを送るのか
  • どのようなレスポンスが返るのか
  • 認証はどうするのか
  • エラー時にはどうなるのか
  • どの機能が利用できるのか

といった仕様を理解する必要があります。

そのため今回の開発を通して、

「AIにコードを書かせる能力」だけではなく、「AIが書いたコードを正しく判断するための知識」も重要

だと感じました。

個人的には、

自分で設計を考える → AIに実装を手伝ってもらう → 公式リファレンスで仕様を確認する → 実際に動かして検証する

という開発スタイルが、今回のような個人開発ではかなり相性が良いと感じました。

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?