株式会社MIXIでサロンスタッフ予約サービス「minimo」の機械学習やバックエンドの開発をしている鈴木です。
minimoでのLLMの活用事例として、2025年3月にリリースした「かんたんAIチェック」の裏側を紹介します。
minimoとは
minimoは累計700万ダウンロード突破 (2025年5月時点) のサロン予約サービスです。
美容師やネイリスト、アイデザイナーなどのサロンスタッフをサロン単位ではなく個人単位で予約することができます。
かんたんAIチェックとは
サロンスタッフがminimoに掲載する際には掲載を審査に提出する必要があります。
かんたんAIチェックは掲載が審査に提出された際に、運営事務局スタッフ (CS) による審査の前にLLMが審査を行う機能です。
かんたんAIチェックを導入した背景
従来の掲載審査では上図のように審査が提出されると、CSによる審査が行われ、承認されれば掲載開始となり、却下されたら掲載を修正の上、再度審査に提出する形になっていました。
しかし、一度で承認されないケースが4〜6割となっているため、却下 → 掲載修正 → 審査再提出のサイクルを回すことになるケースが多くなっています。
すると、1つの掲載を複数回CSが審査するケースが発生し、CSが扱わなければならない審査の数が増えることで、CSによる審査が行われるまでの時間も増えます。
これにより、サイクルを回すのに時間がかかり、掲載開始までの時間もかかる状態になっていました。
そのため、CSによる審査の前にかんたんAIチェック (LLMによる審査) を挟み、そこで却下 → 掲載修正 → 審査再提出のサイクルを速く回せるようにしました。
これにより、掲載開始までの時間を短縮することが期待されます。
また、かんたんAIチェックで問題なしと判断された掲載がCSによる審査に進むので、CSが扱わなければならない審査の数を減らすことが期待できます。
かんたんAIチェックの仕組み
アーキテクチャと処理の流れ
アーキテクチャの全体像を示すと上図のようになります。
処理の流れを見ていきます。
掲載審査提出
サロンスタッフがアプリから掲載審査を提出します。
すると、サーバーのECSタスクにリクエストが飛び、提出された掲載情報をRDSに書き込んだ上でSQSにJobを積みます。
かんたんAIチェック
Step Functionsを使い、Job WorkerのECSタスクを起動します。これはEventBridgeによって定期的に行われています。
そして、ECSタスクにてSQSから先ほど積まれたJobを取り出し、RDSから先ほど書き込まれた掲載情報を取得します。
取得した掲載情報を使ってプロンプトを自動生成し、それをBedrock上で動いているClaude 3.5 Sonnetに投げます。
そして、LLMから返ってきた結果から、通過/却下の判定や指摘内容の抽出を行い、その結果やサロンスタッフに送信するメッセージをRDSに書き込みます。
その後、SNSを使ってかんたんAIチェックの結果が出た旨のPush通知をサロンスタッフに送信します。
ここで却下となった場合は、サロンスタッフ側で審査を取り下げ掲載を修正して再度提出という流れになります。
CSによる審査
CSが管理ツールにアクセスすると、これまでに書き込まれた掲載情報やかんたんAIチェックの結果がRDSから取得され、表示されます。
CSはかんたんAIチェックの結果を参考にしながら掲載情報をチェックし、審査結果を送信します。
すると、サーバーのECSでその結果やサロンスタッフに送信するメッセージをRDSに書き込みます。
その後、SNSを使って審査結果が出た旨のPush通知をサロンスタッフに送信します。
ここで承認されれば晴れて掲載開始となります 👏
LLMに審査してもらうかの判断
LLMは「与えられた価格がm円以上なら却下」のような数の大小比較を苦手としているようでうまくいきませんでした。
そのため、大小比較が必要な観点については、Job Worker側で大小比較を行い、LLMによる追加の審査が必要な場合のみ、LLMに審査してもらうという方法をとっています。
プロンプトで工夫した点
思考を出力させる
### 出力フォーマット ###
以下の形に合わせて出力してください。
#### 思考 ####
出力フォーマット内に思考のセクションを含めることで、どのような思考でその出力をしたのか、デバッグしやすいようにしています。
3人のスペシャリストによる多数決
この質問について、3人の異なる審査のスペシャリストが回答していると想像してください。
全てのスペシャリストがstep by stepで思考した結果から多数決で１つの答えを導き出してください。
元々、Tree of Thoughtsを実現しようとしたものでしたが、それ自体はうまくいきませんでした。
しかし、3人のスペシャリストによる多数決を行うことで精度が上がったので使っています。
なお、企業の取締役は奇数人にしておくと、二択の意思決定の際に意見が割れても、多数決でどちらかに決められて良い、という話を以前聞いたことがあり、それを念頭に置いて3人にしています。
かんたんAIチェックプロジェクトの進め方
プロジェクトメンバー
次のようなメンバーで進めていきました。
- PM: 1名
- 全体のPM, プロンプト開発, バックエンド実装担当
- バックエンドエンジニア: 1名
- プロンプト開発, バックエンド・管理ツールのフロントエンド実装担当
- QA: 1名
- プロンプト開発, QA担当
- CS: 1名
- 仕様策定, テストデータ作成, ドメイン (審査業務) に関する質問窓口, プロンプト再編担当
通常のシステム開発と比べて特徴的な点として、コーディングに相当するプロンプト開発をエンジニア以外のメンバーが担当したり、協力を仰いだりできるという点がありました。
本プロジェクトでは上記の通り、QAもプロンプト開発を担当していますし、プロンプトの良い修正方法が思いつかなかったため、ドメイン知識を持つCSに修正案を考えてもらった場面もありました。
このように、プロンプト開発においてエンジニア以外の人も頼れるという点で、心理的な負担が軽減されてよかったと感じます。
進め方
Ph1: プロンプト作成の肌感を掴む
プロンプト開発を担当するメンバーが各々上記サイトを読み進めて、プロンプトエンジニアリングについて学習しました。
そして、CSに用意してもらったテストデータを使ってプロンプト開発を始めました。
このPhaseでプロンプト開発というものに慣れていきました。
Ph2: 本番運用に向けたプロンプト用意
テストデータに対する正解率が上がるようにプロンプトをブラッシュアップしていきました。
正解率が一定の閾値に達した段階で次のPhaseに移りました。
Ph3: 管理ツールへの組み込み
管理ツールにかんたんAIチェックの結果を表示する実装を行いました。
ここで初めてシステムへの組み込みを行いました。
また、CSからのフィードバックを受け、プロンプトをさらに修正していきました。
プロンプトやバックエンド実装の不備をサロンスタッフへ展開する前にある程度修正することができたので、このPhaseを設けてよかったと感じています。
CSからのフィードバックをプロンプトに一定反映できた段階で次のPhaseに移りました。
Ph4: サロンスタッフへの展開
かんたんAIチェックをサロンスタッフへ展開するための実装を行いました。
このPhaseは一般的な施策の開発と同様の流れでした。
かんたんAIチェックを導入してどう改善したか
Ph3 (管理ツールへの組み込み) リリース後、審査1件あたりにかかる平均時間が6%程度短縮されました。
これにより、月25時間程度のコスト削減に繋がりました。
また、Ph4 (サロンスタッフへの展開) リリース後、審査全体のうち、かんたんAIチェックによって却下され、サロンスタッフ自ら審査を取り下げた事例が9%ありました。
これはすなわち、CSを介さずに審査取り下げ (修正) まで完結しているということであり、CSの対応コスト換算で月45時間以上のコスト削減に繋がりました。
他にも、医師法・医療法・薬機法のいずれかに抵触する行為が記載されているかの審査では、CSが把握し切れていなかった表現をかんたんAIチェックが指摘し、CSで確認したところ、却下に値する表現だった、という事例もありました。
かんたんAIチェックの課題
ap-northeast-1リージョンのBedrock上で動いているClaude 3.5 Sonnetには、1分あたり20リクエストまでしかInvokeModelのリクエストを投げられないという制限があります。
これに引っかかると、かんたんAIチェックの結果を返すのが遅れてしまうという課題があり、解決に向けて試行錯誤しています。
他のLLMモデルに変えることも検討しましたが、精度の面で変えるのは難しそうという結論になりました。
とはいえ、クラウドサービス上で動くLLMモデルを使用する場合、選定時に見る指標の一つとしてリクエスト数の制限も重要であるということを実感しました。
最後に
LLMをプロダクトに組み込むというのはminimoとして初めての試みでしたが、CSのコストを削減することができました。
また、プロンプト開発においてはエンジニア以外の人も巻き込んでできるというのは大きな知見でした。
宣伝
minimoでは一緒に働く仲間を募集中です！
リモート勤務も可能ですので、詳しくは下記採用ページをご確認ください。
Discussion