美容領域のAIに革命が起きたかもしれません

こんにちは。AI HACKに参加しているはまぐちです。
今回、AI HACK2026で【本番で通用する次世代のAIプロダクトを創る】のテーマのもとAIプロダクトを開発しました。

プロダクト名を紹介する前にお伝えしたいことがあります。
それは【美容の悩みは、肌質だけでは決まりません。】ということです

「明日は大事な予定がある」「今月は買い足しを控えたい」「手持ちのアイテムを活かしたい」「睡眠不足で、今日は最低限にしたい」など、その日の生活や気分によって、欲しい答えは変わります。

一方で、多くの美容サービスは数問の回答から結果を返す“診断”が中心です。便利な反面、ユーザーが「なぜその答えなのか」「今日はどうすればよいか」まで掘り下げる余地が少ないと感じていました。

そこで開発したのが、今回開発したAIプロダクトCHIGIRIです。
※以降、CHIGIRI Beautyという名称も出ますが同じものです。
　コードネームでございます。

CHIGIRIは、スキンケア・ヘア／頭皮・ボディ・メイク・ネイルの5領域を、会話を通じて整理し、手持ちアイテムや生活状況も踏まえ一緒に考える美容AI相談室です。
※CHIGIRIの由来はAIとユーザ間の相談内容に契り（ちぎり）を交わすほど信頼してもらえるAIプロダクトにするという想いからです。

CHIGIRIで解決したい課題

こんなことを思うことはありませんか

• 情報が多すぎて、自分に必要な美容情報を選べない
• 一度きりの診断では、その日の状況に合わせられない
• 商品を買い足す前提の提案になりやすい
• 「相談した内容」を次回に引き継げず、毎回説明し直す必要がある
• 美容領域ごとに欲しい会話のトーンや質問が異なる

CHIGIRIでは、正解を一方的に提示するのではなく、ユーザーの言葉を受け止めながら、必要な情報を少しずつ確認する会話設計を採用しました。

技術スタック

開発の背景：美容アプリの「診断の押し付け」に違和感があった

既存サービスが抱える構造的な課題

美容系サービスには、パーソナルカラー診断、肌診断、商品レコメンドなど便利なものが数多くあります。

ただし、体験設計には次のような限界があります。

特に大きかったのは、「ユーザーが何を言ったか」よりも、「フォームでどの選択肢を選んだか」が優先されやすい点です。

美容は生活と密接です。夜勤、イベント、予算、季節、手持ち商品、体調などを考慮せずに、「あなたにはこれ」と結論だけを返すのは不自然です。

そこでCHIGIRIでは、AIを“診断器”ではなく、相談を前に進めるコンシェルジュとして設計しました。

コア機能と差別化ポイント

1. 5人の専門コンシェルジュ

CHIGIRIには、扱う文脈を分けた5人のコンシェルジュがいます。

• ARCA：スキンケア
• SILQA：ヘア・頭皮ケア
• SOMA：ボディケア
• TINTA：メイク・コスメ
• UNEA：ネイル・ハンドケア

それぞれ単に回答する内容や質問を変えているだけではありません。

例えば、メイクでは「なりたい印象・使う場面・普段の服装」を、ヘア・頭皮では「乾燥・べたつき・ダメージ・スタイリング」を優先して確認します。専門領域ごとに会話の質問軸を変えることで、別領域のテンプレート回答が混ざることを抑えています。

2. いきなり商品を出さない会話設計

初回の相談で、すぐに商品名を並べると、AIが自分の話を聞いていないように感じられます。

そこで、会話状態を以下のフェーズとして扱っています。

listen → understand → align → coach → propose

• listen：悩みを受け止める
• understand：必要な条件を一つずつ確認する
• align：優先したいことをすり合わせる
• coach：手持ちの使い方や今日できることを案内する
• propose：ユーザーが希望した場合にのみ商品候補を提示する

この状態管理により、「商品を見たい」と言ったのに質問を繰り返す、「使い方を見直したい」と言ったのに商品提案を繰り返す、といった会話の破綻を減らしています。

3. 手持ちアイテムを起点にした提案

ユーザーは、保有しているアイテムを選択・追加できます。

提案時には、まず手持ちアイテムを会話コンテキストへ渡し、買い足しは不足カテゴリを補う場合に限定します。

これにより、購入を促すためのAIではなく、今ある選択肢を活かすAIを目指しました。

4. 相談履歴とGoogleログイン

未ログイン時は端末内で相談内容を保持し、Googleログイン後は履歴やマイアイテムをアカウント単位で引き継げるようにしています。

ログイン済みユーザーにはプロフィールアイコン付きのアカウントメニューを表示し、相談画面へ戻る導線とログアウト導線を分離しました。
※実装が途中のため、要改善

5. 公式製品情報と口コミサイトへの導線

提案対象は、公式情報を基に整備した製品カタログから選びます。

また、AIが外部口コミを断定的に要約するのではなく、LIPS、@cosme、Qoo10、楽天市場、Amazonなどをユーザーが選択して確認できる導線を用意しました。

これは、口コミ本文の無断利用を避けつつ、購入前の比較行動を支援するためです。

裏側の仕組みと技術的工夫

システムアーキテクチャ

図1

図1.1：処理の流れ（コード版）

┌──────────────────────────────────────┐
│              Browser                 │
│  会話UI / 履歴 / マイアイテム / 認証 │
└────────────────┬─────────────────────┘
                 │ HTTPS
┌────────────────▼─────────────────────┐
│             Next.js / Vercel          │
│  /api/chat                            │
│  /api/consultations                   │
│  /api/check-ins                       │
│  /api/uploads                         │
└───────┬──────────────┬───────────────┘
        │              │
        │              ├──────────────→ Vercel Blob
        │              │                添付画像
        │
        ├──────────────→ Turso / libSQL
        │                相談履歴・マイアイテム
        │
        └──────────────→ OrcaRouter
                         LLM応答生成

会話処理のシーケンス

図2：会話処理シーケンス図

OrcaRouterを入れた意義

OrcaRouterは、単にLLM APIを呼ぶためだけに採用したわけではありません。今回の評価軸であるLLMコストとセキュリティを担保すべく採用しました。
OrcaRouter公式サイト↓

美容相談では、すべての発話に高コストな推論を使う必要はありません。たとえば「わからない」「使い方を見直す」「商品を見たい」といった操作意図は、モデルに推論させず、アプリケーション側で確定できます。

そこで、以下のようにルールベースの会話制御とLLM応答を分離しました。

const assessment = assessConversation(specialist, input, history, memory);

// 初期ヒアリングや安全案内は、制御可能なローカル応答を使う
if (assessment.phase === "listen" || assessment.phase === "safety") {
  return buildLocalReply(...);
}

// 深い相談や理由づけが必要な箇所だけOrcaRouterへ渡す
const response = await fetch("https://api.orcarouter.ai/v1/chat/completions", {
  method: "POST",
  headers: {
    Authorization: `Bearer ${process.env.ORCAROUTER_API_KEY}`,
    "Content-Type": "application/json",
  },
  body: JSON.stringify({
    model: process.env.ORCAROUTER_MODEL || "orcarouter/auto",
    messages,
  }),
});

この構成のメリットは次の3点です。

• 相談導線がモデル出力に左右されにくい
• 不要なLLM呼び出しを減らし、コストと待ち時間を抑えられる
• 将来モデルを変更しても、UIと会話制御を大きく変えずに済む

APIキーはORCAROUTER_API_KEYとしてサーバー環境変数にのみ設定します。NEXT_PUBLIC_変数やGitHubへキーを置かないことが重要です。

会話履歴は「全部送らない」

履歴をすべて毎回LLMに送ると、トークンコストが増え、応答も遅くなります。（ここがLLMコストの削減に繋がります）

CHIGIRIでは、直近の会話を上限付きで送る一方、過去の重要な情報は以下のようなコンパクトなメモリとして保持します。

type ConversationMemory = {
  facts: string[];
  knownKeys: string[];
  askedKeys: string[];
};

たとえば、「乾燥が気になる」「買い足しは1点まで」「パーソナルカラーは不明」といった条件を短く保持します。

これにより、会話の一貫性とコストのバランスを取っています。

安全性：美容提案と医療行為を混同しない

美容AIでは、体調や症状への対応が重要です。

強い痛み、腫れ、出血など、美容の範囲を超える表現を検知した場合は、商品提案を止め、医療機関への相談を促す設計にしています。

AIが医療判断をするのではなく、相談の境界を明確にすることを優先しました。

開発で直面した壁と学び

1. 自然な会話は「モデルを賢くするだけ」では解決しない

最初は、5人のコンシェルジュに専門プロンプトを与えれば自然な対話になると考えていました。

しかし実際には、以下のような問題が起きました。

• 直前の説明を繰り返す
• ユーザーの短い選択肢を、前の質問への回答として誤解する
• メイクの相談なのにスキンケアの質問へ戻る
• 商品を希望していないのに候補を出す

解決策は、LLMへの指示を増やすことではなく、会話の状態・操作意図・質問済み項目をアプリケーション側で持つことでした。

LLMは自然言語の表現を担い、会話遷移の正しさはアプリケーションが担保する。この役割分担が最も重要な学びでした。

2. 「速い回答」と「自然な間」の両立

AIの応答が速すぎても、ユーザー体験としては機械的に感じることがあります。

一方で、単に待機時間を追加すると、遅いアプリになるだけです。

そこで、初期ヒアリング・短い選択肢・使い方の見直しはローカル応答で即座に返し、個別事情の整理や提案理由が必要な場面だけOrcaRouterを利用する構成にしました。

これは単なるレイテンシー改善ではなく、会話の内容に応じて応答の深さを切り替える設計です。

3. 実運用では「精度」だけでなく、保存・UI・失敗時の体験が重要

ハッカソンではAI応答に注目が集まりがちですが、実際に使ってもらうには以下が重要でした。

今後の展望

CHIGIRIは、現時点では「会話を通じて美容の悩みを整理する」ことに集中しています。

今後は、以下を拡張したいと考えています。

• 写真を使った経過記録と、変化を振り返るUI
• パーソナルカラー・メイク提案の継続的な学習
• 朝・夜・イベント前など、利用シーン別のプラン生成
• 肌・髪・ネイルなど領域横断のコンディション分析
• 商品の公式情報更新を検知するデータパイプライン
• ユーザーが許可した範囲での長期的な美容ログ活用
• レスポンスモードごとのモデル・コスト最適化

目指しているのは、「おすすめ商品を返すAI」ではありません。

その日の状況、手持ち、予算、続けやすさを会話で整理しながら、ユーザーが自分で納得して選べるようになる美容AIです。

Links

• デモ動画:https://youtu.be/_MxigIjROk8
• GitHub: https://github.com/keyakizakap-alt/chigiri-beauty-apps

ハッカソンという短い期間では、すべてを完璧にすることはできません。

だからこそCHIGIRIでは、AIの“すごさ”を見せることよりも、ユーザーが相談を続けられる体験、会話が破綻しない仕組み、そして本番運用へ伸ばせる構成を優先しました。

ただできる限り美容とAIの間にある「相談したいけれど、何から話せばよいかわからない」という距離を、少しでも縮められるプロダクトにしてます。