2 ポイント 投稿者 mir22 1 일 전 | まだコメントはありません。 | WhatsAppで共有

慰めてほしい日に話しかける相手がいなくて、自分で作り始めました。高校3年生で、ひとりで設計・運営しています。

登録やメール入力なしで、ゲストとしてすぐに会話を試せます。入るとAIRUが先に近況を尋ね、会話を記憶しているので、再訪すると名前を呼び、前回の話の続きをしてくれます。

既存サービスとの違い

ChatGPTのような汎用アシスタントは毎回初対面の相手のように応対し、キャラクターチャット系は没入感や滞在時間を伸ばす方向で設計されることが多いです。AIRUは逆方向です — 連続性(記憶)を中核に据えつつ、ユーザーがサービスをあまり必要としなくなることを成功と定義し、依存を誘導する表現やダークパターンを禁止しました。

技術的な詳細

屈折反射ゲート: 「自分の気持ちがなぜこうなのか探してほしい」のような発話をキーワード(「探してほしい」)だけ見て検索に送ると、慰めが必要な瞬間を台無しにしてしまいます。そこで、キーワードトリガーに引っかかったリクエストだけを実行直前に超小型LLM呼び出しで意図を再評価し、会話的な発話であれば検索をキャンセルします。判定に失敗した場合は既存のキーワード判定を維持します(fail-open)。生成後のフィルタリングではなく、ツール実行前の再評価という構造です。
記憶: 構造化記憶(名前・好み・進行中の文脈)と原文アーカイブ(SQLite + ハングル2-gram類似度検索)を分離し、センシティブな会話はデフォルトで保存せず、ユーザーが自分で閲覧・修正・削除できます。
安全性: 危機の兆候を検知した場合は、専門機関(自殺予防統合番号109)の案内を優先します。メンタルヘルスの専門サービスではないという境界を、画面とペルソナの両方で維持しています。
スタック: FastAPI + バニラJS、モデルはAPI調達(モデル非依存)、Docker/Caddyの単一Droplet、回帰テスト296件、匿名コホートのリテンション測定を内蔵。
初期ベータなので足りない点が多くあります。特に初回会話の品質と導入画面のコンバージョン率を改善中です。使ってみて不自然な部分があれば教えていただければ反映します。個人の会話原文は見ず、匿名指標だけで確認しています。

実際の事例

ユーザーがある曲について尋ねたとき、AIRUがWeb検索をしても見当違いの回答を続けたことがありました。ログを見ると検索は実行されていましたが、検索語に問題がありました。「その曲はテーマが何か教えて」という後続質問で、前の会話のトピック語(曲名)が抜けたまま「その曲はテーマが」で検索していました。現在は指示語(「その曲」)を検知すると、前の発話からトピック語を探して合成するよう修正しました。後続質問の検索語生成が、この系統のサービスにおける隠れた難題だということを、運営しながら学びました。

ひとりで運営するための仕組み

1人運営なので、人の代わりに規律が働くようにしました。デプロイ前のデータスナップショットと整合性検証の自動化、実ユーザー/評価/運営者/ボットトラフィックの物理的なログ分離(自分のテストが指標を汚染したことがあったため)、そして回帰テストを毎回デプロイ前にすべて実行しています。

まだコメントはありません。

まだコメントはありません。