インターン期間にネイルデザインを提案するチャットボット作成を通して学んだこと
Author : 濵野 栞 (監修 : 中村 達也)
1. セルフネイルの普及と課題
調査によると、普段ネイルをしている人は 66 %、その中でも セルフネイルをしている人が 87.5 % という結果でした。また、別の調査では、コロナの影響でセルフ美容の意識が変わった人は 82 %、今までサロンやプロにお願いしたにも関わらずやめたことがある人は 52 % という結果でした。セルフで行うようになった代表的なことに、ネイルがあげられています。これらの結果から、普段からセルフネイルを楽しむ人に加えて、コロナ禍で始めた人もいることが分かります。
とはいえ、セルフネイルをしようと思うと、自分でデザインを考案するのが困難だという問題があります。自分でデザインを考えると思い通りにならないことがあり、ネイルをやり直すには多くの時間と手間がかかります。また、Web サイトや SNS でデザインを探すと、細かいデザインが施されていたり、持っていないパーツが使われていたりするため、自分に合ったデザインを探すには時間がかかります。
2. ネイルデザインを提案するチャットボットを作成する
そこで、セルフネイルを楽しむ人の持っているカラーやパーツだけを使用して好みの雰囲気にあったネイルデザインを提案するチャットボットを作成しました。
チャットボットを実装するまでのプロセスはこのような流れです。
![](https://d1.awsstatic.com/Developer%20Marketing/jp/magazine/2021/img_nail-design-chat-bot_01.4009e1c9a2e943bbfab0ec0b190cd248b7c3956a.png)
2-1. 技術調査
まず初めに、サーバーレスボットフレームワークのアーキテクチャ を確認しました。
インターンを始める前までは AWS のサービスを 1 つも知らなかったため、どのサービスから勉強していけばいいのか分かりませんでした。そのため、チャットボットを作るのに使用できそうなサービスから学んでいくことにしました。具体的には、サーバーレスボットフレームワークのアーキテクチャ図から AWS Lambda、Amazon DynamoDB、Amazon Lex を中心に勉強していくことにしました。
次に、サーバーレスについてのハンズオンを実施しました。
最初はサーバーレスという単語の意味を知らなかったため、ハンズオンと並行していくつかのサーバーレスに関する記事も読みました。
AWS Hands-on for Beginners〜 Serverless 編 〜 »
このハンズオンでは翻訳 Web API の構築を通して、サーバーレスアーキテクチャの基本を学ぶことができます。Web API の構築には AWS Lambda、Amazon API Gateway、Amazon DynamoDB を使用します。
また、社内用の Amazon Lex v2 に関するハンズオンや、AWS Lambda に関するハンズオンも行いました。この段階で、サービスの機能や使い方を少しずつ理解していきました。
2-2. PR / FAQ
次に、PR/FAQ (プレスリリース + FAQ )を書きました。
PR/FAQに関しては こちら に詳しく記載されていますが、PR/FAQ を最初に書くことで、サービスを作る目的やサービスの機能が明確になりました。先に明確にしておくことで、後から大きな変更をすることなく進めることができました。
私はサーバーレスなネイルデザインチャットボットを作成することにしました。ネイルデザインチャットボットとは LINE で「ネイルデザインを教えて」と話しかけて、3 つの質問に答えると、その特徴にあったネイルデザインを提案するサービスです。このネイルデザインチャットボットでは、セルフネイルを楽しむ人たちの持っているカラーやパーツだけを使用して好みの雰囲気にあったネイルデザインを提案します。
PR/FAQ のレビューは私の所属するチームの方にしていただきました。第 3 者にレビューをしてもらうことで、サービスの背景や目的には具体的な数字を用いて根拠を明確にすることで説得力を持たせることができるということを学びました。また、ビジネスモデルや他のサービスとの差別化について自分では思いつかなかった視点からアドバイスをいただくことができ、とても参考になりました。
2-3. アーキテクチャ
次にアーキテクチャを検討していきます。
アーキテクチャを考えるときは、初めに参考になりそうな他のサービスのアーキテクチャを調べました。様々なアーキテクチャを見ていく中でよく使われているサービスの役割を把握することができました。データの流れを意識しながら、アーキテクチャを考えていきました。
アーキテクチャについてもレビューを第3者に行っていただいたのですが、実装できるのか不安だった箇所のデータの流れが明確になりました。LINE のアクセスキーなどはコードに直接書き込むべきではない、などセキュリティに関する知識も得られました。また、実装するときに考えるべきポイントを先に教えていただくことができました。
![](https://d1.awsstatic.com/Developer%20Marketing/jp/magazine/2021/img_nail-design-chat-bot_02.55bc93354e371591f352c85880f4466ced32fdd5.png)
2-4. チャットボット作成の手順
このチャットボットは以下のような流れで作成しました。この記事ではすべての手順をご紹介しませんが、参考にしてみてください。
- Amazon S3 にネイルデザインの画像データを保存します。
- Amazon DynamoDB にはネイルの特徴と S3 のオブジェクト識別子を保存します。
- AWS Lambda では Amazon Lex から送られる slot のパラメータを用いて、ネイルの特徴にあった画像を取り出します。
また、画像の URL を Amazon Lex に送信します。 - Amazon Lex ではユーザーのリクエストを処理し、応答します。
- AWS Lambda では LINE Bot SDK を使用して Amazon Lex と接続します。
- AWS Secrets Manager には LINE アカウントのチャネルアクセスキーとチャネルシークレットを保存します。
- LINE で会話を送信すると Amazon API Gateway を介してリクエストが送信します。
3. Amazon Lex v2 の特徴
今回のチャットボットで対話を実現するのに Amazon Lex v2 を使ったので、このサービスについて少し深堀りしてご紹介します。
Amazon Lex は、音声やテキストを使用して、任意のアプリケーションに対話型インターフェイスを構築するサービスです。
ここでは、私の感じた Amazon Lex v2 の 3 つの特徴を紹介します。
3-1. 特徴 1 - 会話の設定方法が簡単
Lex には「インテント」、「スロット」という概念があります。
インテントは、ユーザーが実行したいアクションを表します。私が作成したチャットボットではネイルデザインを提案するため「SuggestIntent」というインテントを一つ作成しました。「FallbackIntent」とは、ユーザーの入力が想定通りではない場合に呼び出されるインテントです。このインテントはボットを作成したとき自動で作成されます。
スロットは、実行時に特定のスロット値を指定するようにユーザーに求めます。
私が作成したチャットボットでは、ネイルのカラー、パーツ、雰囲気をユーザーに答えてもらうため、「ColorType」、「PartsType」、「AmbianceType」を作成しました。
こうしてボットを作成してから、インテントとスロットを設定するだけで、会話の流れを簡単に設定できます。
3-2. 特徴 2 - すぐにテストできる
こちらの画面のように、右下にある、テスト のボタンを押すだけで、会話の流れをテストすることができます。
また、検証 ボタンから JSON 入力と出力 というタブをクリックすると、リクエストとレスポンスのデータを確認することができます。
3-3. 特徴 3 - Amazon Lex がセッション状態を保持する
Lex では、セッションによって、アクセスしているユーザーの識別や処理の状態を管理することができます。そのため、スロット値を検証し無効であればボットに値の再入力を求めることや、会話中にインテントを切り替えることもできます。
ユーザーがボットとの会話を開始すると、Amazon Lex はセッションを作成します。リクエストを行うと、セッションはボット名と指定したユーザー識別子の組み合わせによって識別されます。
<3 条件以上のユースケース>
場面 | 条件データ | 応答データ | |
5 | 指定した回答文の削除 | ユーザーID、設問ID、回答ID | なし |
<クエリ対象のアイテム>
パーティションキー (PK) | ソートキー (SK) | その他の属性 | |
2 | user#{ユーザーID}_theme#{設問ID} | comp#{回答ID} | 回答文、回答文の文字数 |
クエリ対象のアイテムの PK (user#{ユーザーID}_theme#{設問ID}) は、ユーザー ID と設問 ID の 2 つのデータの組み合わせになっています。クエリでは、PK でユーザー ID と設問 ID、SK で回答 ID による絞り込みが行われるため、3 条件を指定するクエリができます。
データの組み合わせ方について、以下のように PK をユーザー ID、SK を設問 ID と回答 ID とする方法も考えられます。しかし、この設計では、ユースケース 1「設問画面読み込み時に、ユーザーが登録した全ての『企業名・プロジェクト名・設問文・設問ID・登録日時』を取得」で PK に user#{ユーザーID} を指定してクエリをする際、theme#{設問ID}_comp#{回答ID} 等の不要なデータも含まれてしまいます。各ユースケースにおいて、クエリ結果に「期待するデータが不足なく含まれる」ことはもちろんですが、「期待するデータ以外のものはできる限り含まない」という点も考慮し、上記の組み合わせを採用しました。
<PK をユーザーID、SK を設問ID と回答ID とした場合>
パーティションキー (PK) | ソートキー (SK) | その他の属性 | |
2 | user#{ユーザーID} | theme#{設問ID}_comp#{回答ID} | 回答文、回答文の文字数 |
4. チャットボットを作成して気づいたこと
チャットボットを実装したことで、サービスに関する知識が深まりました。ハンズオンを見ながら実装すると必ず動かすことができますが、自分で実装するときは何度もエラーが出て調べたため、知識が深まりました。また、Amazon CloudWatch のありがたみを痛感しました。
実装するときに、自分のできそうなところから進めていったため、最後の方につまずいて焦りました。最初に少しのデータを使ってデータの流れを確認するところから進めていければ良かったと思います。
一方、PR/FAQ によるアプローチで大きな変更をすることなく進めることができたので、これから自分でサービスを作るときは使っていければと思っています。
5. まとめ ~ インターン期間で学んだこと
今回のインターン期間で学んだことは主に 3 つあります。
1 つ目は、知識の幅が広がったことです。
インターンを始める前までは、自分の得意な領域や苦手な領域について把握できていませんでした。インターンが始まってからネットワークやセキュリティに関する知識が乏しいことに気がつき、勉強を始めました。builders.flash にも分野ごとの勉強方法について紹介している記事があり、参考になりました。
また、AWS のサービスについても、主要なサービスの機能や使い方を学ぶことができて、インターン期間の最後に AWS Certified Cloud Practitioner を取得することができました。
2 つ目は、Amazon のリーダーシッププリンシプル (OLP) についての理解が深まったことです。
インターンが始まる前に OLP の存在は知っていたものの、実際に社員の方がどのように使用しているのかは知りませんでした。ミーティングや 1 on 1 をしているうちに、OLP の意味を少しずつ理解して、意識しながら行動できるようになりました。私が一番好きな OLP は Learn and Be Curious です。インターン期間が終わっても常に学び、自分自身を向上させていきたいです。
3 つ目は、実際に働いている方の考えを知ることができたことです。
実際に働いている方から、仕事のやりがいや AWS サービスの勉強方法を聞くことができました。また、私自身の就職活動や今後のキャリアについて親身に相談に乗っていただけました。実際に働いている方から自分にはなかった考え方を聞くことができて、とても為になりました。
インターン期間中には Building の他にもチームの方との1 on 1 やミーティング、shadowing、ハッカソンなど様々な成長する機会をいただきました。AWS の皆様本当にありがとうございました。
筆者プロフィール
![](https://d1.awsstatic.com/Developer%20Marketing/jp/magazine/profile/photo_hamano-shiori.ba1c0671315a9ea00d395c1499ce7c9313d246f1.jpg)
濵野 栞
アマゾン ウェブ サービス ジャパン合同会社
ソリューションアーキテクト 長期インターン
CG, UI の研究室で、ネイルデザインを提案するシステムについて研究している大学生。
好きなサービスは AWS Lambda で、気になるサービスは AWS DeepComposer。
監修者プロフィール
![](https://d1.awsstatic.com/Developer%20Marketing/jp/magazine/profile/photo_nakamura-tatsuya.9364037120ebdcae54b6037e65ec1472b2adc76d.jpg)
中村 達也
アマゾン ウェブ サービス ジャパン合同会社
技術統括本部 ソリューションアーキテクト
2019 年6 月に アマゾン ウェブ サービス ジャパンに入社後、流通・小売業界のエンタープライズ企業を担当しています。
入社前までは、SIer で ERP 導入エンジニア、Web 系企業のエンジニア、フリーランスなどで活動していました。
AWS を無料でお試しいただけます