「汎用DB API」による自己拡張オーサリング　～プライベート・ルーティング補完案～

2025年11月19日 11:31

前回、プライベートなAIのルーティング環境の整備を考えてみました。

これに「汎用DB API」を統合することで、AIは以下の二段階のオーサリングを実行できるようになるかなと。

ユーザー入力: 「冷蔵庫の中身を管理して」
ディスパッチャー判断: → tool_generic_db_api を選択。
実行: 汎用DB APIが、要求に基づき「食材名、個数、賞味期限」といった最適なDBスキーマを動的に設計し、外部DBサービス（Notion、Airtable、Firestoreなど）上に新規のDB（冷蔵庫）を作成します。

この仕組みは、現在の日記DB（Notion API）が「固定されたエピソード記録」であるのに対し、「動的に新しい管理台帳を作る」機能を提供します。

ルーティングの更新

ディスパッチャーLLM（Gemma-3-4B）のプロンプトに、以下の新しいツールを追加します。

ツール名：tool_generic_db_api
役割とルーティング基準：ユーザーが「〜を管理したい」「新しいリストを作りたい」「〜の在庫を登録/確認したい」など、新しいデータ管理やリスト作成を依頼した場合に選択。

冷蔵庫管理の例では、二段階のオーサリングをプロトコルとして定義する必要があります。

ユーザー: 「冷蔵庫の中身を管理して」
ディスパッチャー (Gemma-3-4B): → tool_generic_db_api を出力。
実行レイヤー (Python): tool_generic_db_api に「新規冷蔵庫DBの作成」を指示し、結果（DB IDなど）を取得。
フィードバック: 結果をGemma-3-12Bに渡し、「冷蔵庫DBを作成しました。どんな項目を管理しますか？」と次の会話を促す応答を生成させる。

この「汎用DB API」の追加は、AIシステムに単なる応答機ではなく、自律的な管理エージェントとしての能力を付与する一手となります。

リアルタイムの在庫確認を目的とせず、「賞味期限切れの無駄な廃棄と占有を防ぐ」ことに焦点を当てた管理システム。
（冷蔵庫の中をカメラで撮影して分析するという謎アプローチは不要）

入力の起点: 冷蔵庫（またはストッカー）に搭載されたカメラと、セルフレジ型のUIを採用。（スマホやタブレットを冷蔵庫に貼り付けても可。必要に応じてストッカーやパントリーへ移動）
ゼロエフォート登録の追求: 物理的なレシートは利用せず、商品そのものの情報を直接読み取る。ネット通販を含む、あらゆる購入チャネルに対応可能。（従来通りの紙レシートの読取りも対応）
- バーコード付き商品: 商品を庫内に収納する際に、カメラがパッケージのバーコードを直接スキャンして、品名と数量を自動登録。
- バーコードのない商品: 野菜などのバーコードがない商品は、AIの画像認識が品種を提案し、ユーザーが画面上で品種を選択して手動で登録。
- 自炊ストックの管理:
  - バーコード/タグの活用: 冷蔵・冷凍ストック用の保存容器にバーコード（またはQRコード）を貼り付ける。
  - 入庫時の登録: 料理をストッカーに入れる際、そのバーコードを冷蔵庫カメラでスキャンし、料理名（例：「ひじきの煮物」）と設定された賞味期限（例：冷凍なら1ヶ月など）を紐づけて登録。これにより、自炊品も購入品と同様に、確実なデータインプットに対応できる。

AIの主目的: 登録された品名と購入日（登録日）に基づき、インターネット上の情報から賞味期限を推論し、管理。
コア機能 (リマインド): 推論された賞味期限の1週間前など、設定されたタイミングでユーザーにリマインド通知をプッシュします。これは廃棄を未然に防ぐための唯一の「介入」機能。
付随機能 (レシピ提案): 在庫情報（特に期限が迫っているもの）に基づき、その食材を使ったレシピをAIが提案。

削除のトリガー: ユーザーは、リマインド通知が届いた際に表示される「消費済み」ボタンをタップすることで、リストからアイテムを削除。
削除のシンプル化: アイテムを使い切った時点でシステムに即座に通知する必要は無し。「使い切ったら問題解決」という思想で、早期消費されたアイテムも、リマインド通知が来た時点で削除することで、データ整理を完了。

このシステムは「不必要な複雑なリアルタイム追跡を避け、本当に必要な『期限切れ防止』と『利活用提案』にリソースを集中させる」という、効率的でユーザーフレンドリーな設計。

店内からスマホで在庫DBにアクセスして、買い忘れも減らせる（かも）