こんにちは、エンジニアの君島です。
ギークフィードは2024年6月に開催されたAWS Summit Japanでシルバースポンサーとして出展していました。
当時は何を出展しようかと色々社内で議論していました。
せっかくなら生成AIと絡めた展示作りたいよね、ということで自社で開発をしたスタンプラリーを展示物のひとつにしました。今更ですが、発案から当日までのことを記事にしたいと思います
目次
どうしてはじまった？
AWS Summit Japanに出展が決まったものの、どんな展示内容にしようかというというアイデア会議での発案でした。
- 社内にAWS AmbassadorsやJr.Championsがいるので、知り合いのパートナーに依頼ができそう
- 他社の集客とも連動できる
- 生成AIを絡めた開発でギークらしさを出す
といったところから、自社開発でのスタンプラリーの案が出てきました。
なお、「教育目的で誰かに開発をしてもらえばよくて、間に合わなかったら私が巻き取って開発しますよ」などと口走った発言したことにより、私が主担当となります。
企画
事務局へ確認
まず、そもそも一出展者が他の出展者を巻き込んだ企画をしてよいのかわからなかったので、事務局へ大まかな企画内容と共に確認しました。もしかしたら、事務局自体で総括した企画などもあるかもしれないし、という不安もありました。
結果、複数の出展者での企画自体は問題無いが、正式にはコンテンツのレビューが必要なのでそちらを受けてくださいということでした。
ひとまずこれで、他の展示と同じ扱いということで、正式に企画スタートすることになりました。
企画の詳細決め
開発の方向性
まず、開発を自社でスクラッチで行うか、既にあるサービスを利用するかという議論がありました。
以下の表のような簡単なメリット/デメリットの比較がありましたが、サービス利用するくらいならわざわざギークがやる必要がない、という方向になり、自社開発をすることになりました。
| メリット | デメリット | |
|---|---|---|
| 自社開発 | 開発力のアピール | 準備の工数がかかる |
| サービス利用 | 工数が小 | 自社展示としてのアピール性がない |
また、工数を削減するために生成AI活用をしようということにしました。
要件・方針
企画段階を経て、そこまで具体的な要件はないものの、
- ユーザーの個人情報を保持しない方がAWSレビューを通りやすそう
- ユーザーは個人のスマホを使って操作する
- スマホで見れることが要件
- 説明を最小限にするため、複雑ではなくシンプルなUIがいい
- とはいえ、ユーザーが困ったときに管理者がヘルプする機能は必要であろう
- 生成AIで作成して、手間をかけずにこのコンテンツ自体もアピールにできたらいい
といった点を考慮する必要がありそうだとなりました。
機能仕様
仕様と設計の決め方
きちんとした工程の話をすると、機能の仕様があって、それから後工程の設計に入るものですが、要件がそこまで厳しくないのと、自由な開発でもあったので、生成AIに問い合わせるアプロ―チで両方の工程を行ったり来たりしながら進めることにしました。
いくつかのパターンの仕様及び設計が頭の中にあったのですが、どの方式にするか決め切れていないという状態で、以下のような質問を投げかけAmazon Bedrockのチャット機能で壁打ちをさせてもらいました。
- スタンプラリーをWebアプリで実装するなら、どんな技術を使うのがよい？
- スタンプラリーのスタンプを押したというデータをどのようにクライアント端末に持つとよい？
- 抽選機能も付けたいが、AWSで実装するならどんなサービスを使うのがよい？
想定していない回答の場合には、フロント部分とバックエンドを明確に分けて質問したり、一つの機能だけに絞って質問したりすると適した回答が得られると思います。
構成図
AWS Summit Japanに展示するとなると参加者が増えることになると思われるので、できるだけアクセス数が増大しても料金が膨れ上がらず、またシンプルな構成を目指しました。
以降の詳細からの記載は。開発するにあたって書いていたメモをそのまま流用していますので、少し言葉が足りないかもしれませんが、そのまま出しておきます。
詳細
ユーザー向け機能
- スタンプ機能
- ユーザー情報を保持しない、特定をしないスタンプ保存機能
- localstorageにスタンプ情報や各種情報(はずれた場合ははずれ情報)を保存する
- ストレージクリアしたら、また1からだが、それでもいいという判断
- ユーザー情報を保持しない、特定をしないスタンプ保存機能
- 抽選機能
- スタンプを全て集めたら抽選する
- 抽選確率を調整できるようにしたい
- Lambdaの環境変数で設定可能(今は5%ぐらい)
- 2回目以降は毎回問い合わせるのではなく、1回目の抽選結果を表示するだけにする
- localstorage利用
- 抽選確率を調整できるようにしたい
- スタンプを全て集めたら抽選する
管理者向け機能
- 管理機能
- ユーザーのヘルプをするための機能
画面
スタンプメイン画面
- スタンプを全部押した場合のみ抽選ボタンを押すことができます。
- 抽選ボタンを押すとバックエンドに通信して抽選結果を表示します
- バックエンドから”atari”という戻り値があるかどうかが当たり判定
各スタンプ画面
- 戻るボタン押下、あるいは表示から5秒後にメイン画面に戻ります。
管理画面
- 各スタンプをタップするとスタンプON/OFFがトグルで切り替わる
- localstorageをクリアボタン
- 抽選ボタン
- 戻るボタン
- メイン画面に戻る
バックエンド
抽選関数
- 当たりかはずれを抽選するための関数
- 環境変数で抽選確率を調整する
- 当たりの場合だけ、DBにレコードインサート
- 抽選自体は乱数生成で行う。
- あたり確率を厳密にするためDB使うくらいの意味合い
- なくても抽選は動く
- 抽選自体は乱数生成で行う。
DB
- 1レコード1つのくじとなるようなテーブル定義
- 当たりくじを引いたらレコードに格納する
設計方針と実装
全体
- 生成AIを使用してコード実装コストを省略する
- Amazon Bedrock、基盤モデルはClaude3 Haikuを使用しました。
- IaCまではやらない
- 再利用する可能性があるか未定なのと、開発者が私1人だけで自分の中でハンドリングできるので、アプリ開発そのもののスピードを優先したかった
- デザインも生成AIに提案してもらう
- 画像差し込みや微調整は人間の手で行う
以下のスクリーンショットは開発途中の物で、コード生成させてみたものにロゴ画像を差し込んでいました。1回の問い合わせだけでは理想通りにはならないので、何度か問い合わせて微修正してもらったりします。以下はスタンプを押した時の処理を赤い画像を重畳させる案を提案してくれましたが、人間の判断で不採用となりました。
不採用になったとはいえ、上記のスクリーンショットを見てもまずまずのデザインを提案し、動くコードも生成してくれます。HTMLに関してはほぼ人間の手による修正はしていないです。一部のstyleを変えるのを、問い合わせるより手動で直接直した方が早いと判断したくらいでした。
各スタンプ画面
実は全てコードの中身は同じにして、開発工数を省コスト化しています。
ファイル名に応じてどのスタンプを指定するかを決める処理が実装されています。この実装部分やファイル名の生成についてはプロンプトの問題か、うまくコードを出力してくれず、生成してくれたコードをベースにして自分で実装しました。
スタンプメイン画面
協賛企業が増える可能性があったので、スタンプ数を拡張できるような構成にしておきました。
管理画面
ほぼスタンプメイン画面と同じソースを流用して工数を削減しました。機能ごとにコードを生成して、最終的に人の手でマージしました。
バックエンド
Lambdaのコードも生成AIに出力してもらう。どのサービスを使って何をしたいのか、どの言語でLambdaを書くかというようなプロンプトでコードの大半を生成してもらいました。
あとはそれら部品を組み合わせるだけでした。
マニュアルの社内展開
一般ユーザー向けのマニュアルと、管理者向けのマニュアルやイメージ画像を早めに展開しました。実際にロールプレイしてもらって違和感や疑問点を解消したかったため、直前では何の意味もないという意図がありました。テキストに加えてデモ画面も用意したのは工夫点でした。文字を読解するよりも実際に画面を触ってもらう方が理解が早まると考えたからです。
ただ、シンプルな構成のアプリとはいえ、開発用と社内共有用の2系統が必要だったので、IaCを用意しなかったのがよろしくはなかったなと反省しました。
協賛パートナーの募集
企画書を作成して、個人的にアクション可能なパートナーさんに直接ご連絡したり、パートナーが参加するイベントでご案内させていただいたり、AWSさんにもご協力いただきました。
お陰様で11社ものパートナーさんにご参加いただきました。スタンプラリー自体は馴染みがあった点と、ほとんど労力なく展示物を増やすことができる点を強調し、参加のハードルをできるだけ削減したという点が良かったかと思います。
以下にパートナーさん募集用の資料を共有します。この資料の目次も生成AIに聞いて、作成しています。
参加される上でのメリットや想定されるQAを事前に盛り込んだ上で展開しました。
因みに、大変とまではいかないものの想定していなかったのは、各社さんのロゴが必ずしも正方形ではなかった点です。画像配置した時のstyle指定やバランスなどは人の目で見ながら、コード生成で微修正をしました。
Summit当日
1日目、私も現地参加することができましたので、協賛いただいたパートナーさんのブースを周ってご挨拶とお願いをしました。フォージビジョンさんは手作りスタンプラリーマップまでご用意いただいておりました。弊社よりもご準備いただいていて、頭が下がる思いでした。ありがとうございました。
よかったことは、2日間を通じてAWS上で検知できるエラーは発生しなかったことです。念のため、バックエンド側のCloudWatch Logsを時々見て正常なログも確認していました。
ただ、1日目を終えてなかなか参加される方が少なかったこともあり、抽選の確率はリアルタイムで変更したりもしました。抽選の確率はバックエンドで制御していたので、Lambdaのデプロイで対応しています。Lambdaは抽選時にしか動作しないため、影響は小さいと思ったためこのようにしました。
振り返り
- 生成AIをシステム開発に活かす経験と実績ができた
- ライトに使用しただけでも工数削減の効果が出た
- 優秀な新人を相手にしているつもりで、プロンプトを考えたり、質問をするとよい
- ミクロに見たときにきちんと動くコードを生成してくれるので、最終的な取りまとめや判断は人間がやればいい、と思うのが大事
- 他のパートナーさんを巻き込む経験ができた
- 今年の目標設定にしていたのでよかった
- どちらかというと、むしろ助けていただいてありがたかった
- 集客や当日のフォローなどの準備が反省点
- 直前の準備で、社内社外ともに迷惑を掛けてしまったと反省
- Summit当日は育休中で1日目しか参加できず、不安をかけてしまったと反省
- 事前のアナウンスが不十分だったので、協賛してくれたパートナーさんには集客の面では物足りなさを感じさせてしまったのも申し訳なかった
まとめ
AWS Summit Tokyoにスポンサー出展した際に、自作のスタンプラリーアプリを展示物にしたことを記事にしました。
単に設計、開発だけではなく、出展にあたっての事務局への確認、協賛企業への案内、あるいは、ブースに立つ方のオペレーションなど色々な面を考慮する必要がありました。来年以降出展する場合にも、参考になればと思ってまとめておきました。
開発したのは自分1人だけですが、展示にこぎつけるまでに色々な人が関わるということを改めて感じました。今回は自分で要件や企画を考えた自分主導の開発でしたが、お客様のいる業務での開発に於いても同様に、終了後に振り返りをするのは大事です。改善の機会を発見するきっかけになりますし、次やるときはもっとうまくできる点が見つかります。今回に関しても、反省も多くありましたが、私自身はやって良かったチャレンジだったと自分で勝手に納得しています。
さいごに、この場を借りてとなりますが、急な案内にも関わらず企画をご快諾いただいたり、参加できずともご検討いただいたパートナーさん達にも感謝を申し上げます。ありがとうございました。
- Amazon Bedrockでコード生成したスタンプラリーアプリをAWS Summit Japanで展示するまで - 2024-12-17
- AWS CloudShellでAmazon Q使えんの - 2024-12-08
- Pascalについて調べたまとめ - 2024-12-08
- 半年間の育休を取得しました - 2024-12-05
- オンラインでre:Invent2024の臨場感を味わおう - 2024-12-04
【採用情報】一緒に働く仲間を募集しています
