BEGIN:VCALENDAR
VERSION:2.0
PRODID:-//https://techplay.jp//JP
CALSCALE:GREGORIAN
METHOD:PUBLISH
X-WR-CALDESC:生成AIをWebアプリに組み込む設計実践 ― 非同
 期処理・生成履歴・再実行UXの考え方
X-WR-CALNAME:生成AIをWebアプリに組み込む設計実践 ― 非同
 期処理・生成履歴・再実行UXの考え方
X-WR-TIMEZONE:Asia/Tokyo
BEGIN:VTIMEZONE
TZID:Asia/Tokyo
BEGIN:STANDARD
DTSTART:19700101T000000
TZOFFSETFROM:+0900
TZOFFSETTO:+0900
TZNAME:JST
END:STANDARD
END:VTIMEZONE
BEGIN:VEVENT
UID:1000398@techplay.jp
SUMMARY:生成AIをWebアプリに組み込む設計実践 ― 非同期処
 理・生成履歴・再実行UXの考え方
DTSTART;TZID=Asia/Tokyo:20270101T140000
DTEND;TZID=Asia/Tokyo:20270101T160000
DTSTAMP:20260909T130329Z
CREATED:20260909T032606Z
DESCRIPTION:イベント詳細はこちら\nhttps://techplay.jp/event/10003
 98?utm_medium=referral&utm_source=ics&utm_campaign=ics\n\n文章、画像
 、動画、音楽などを生成するAIサービスでは、一般的
 なWebアプリとは異なる設計上の課題が発生します。ユ
 ーザーがボタンを押しても、結果がすぐには返ってこ
 ない。同じ条件でも毎回違う結果になる。生成に失敗
 することがある。一度作った結果を後から見返したい
 。少しだけ条件を変えて、もう一度生成したい。こう
 した特徴をそのまま放置すると、AI機能自体が優秀で
 も、Webサービスとしては使いにくくなります。今回の
 イベントでは、生成AIを実際のWebアプリとして提供す
 るときに必要になる「非同期処理」「状態管理」「再
 生成」「履歴」「プレビュー」「ダウンロード」など
 の設計を、実践的な観点から整理します。取り上げる
 内容\n\nなぜ生成AIでは同期処理だけでは足りないのか\
 n\n通常のフォーム送信では、数百ミリ秒から数秒で処
 理が終わることを前提にできます。一方、生成AIでは
 数十秒以上かかる処理も珍しくありません。そのため
 、リクエスト受付生成ジョブ作成バックグラウンド処
 理進行状態の保存結果取得という流れを分離して考え
 る必要があります。単純にHTTPリクエストを待たせ続け
 る設計との違いも整理します。\n\n「生成中」をどう見
 せるか\n\n生成AIサービスでは、処理時間そのものをゼ
 ロにできない場合があります。重要になるのは、その
 時間をユーザーにどう伝えるかです。「生成中」「処
 理待ち」「完了」「失敗」といった状態を明確にする
 ことで、ユーザーは現在何が起きているのかを理解で
 きます。ポーリング、SSE、WebSocketなどを使う場合の考
 え方についても触れます。\n\n生成結果を単なるファイ
 ルとして扱わない\n\nAIが生成した結果には、元になっ
 た入力条件があります。たとえば、プロンプトジャン
 ル用途生成日時生成バージョンモデル設定などです。
 結果だけ保存すると、後から「どの条件で作ったのか
 」が分からなくなります。そのため、生成物と生成条
 件をセットで管理する設計が重要になります。\n\n再生
 成とバージョン管理\n\n生成AIでは、最初の結果が必ず
 理想通りになるとは限りません。そこで重要になるの
 が、「最初から全部入力し直す」のではなく、現在の
 条件を残したまま再生成できる仕組みです。今回のイ
 ベントでは、元の条件を保持する条件の一部だけ変更
 する新しい生成結果を別バージョンとして保存する過
 去の結果と比較するといったUXについて考えます。\n\n
 生成失敗を前提にした設計\n\n外部AI APIやGPU処理を利用
 するサービスでは、タイムアウト、APIエラー、処理失
 敗などが発生する可能性があります。そのため、再試
 行エラー状態の保存二重実行防止課金処理との整合性
 なども最初から設計しておく必要があります。特に、
 有料サービスでは「生成に失敗したのに利用回数だけ
 消費された」といった状態を避ける必要があります。\
 n\nAI音楽生成サービスを例にした実装フロー\n\n後半で
 は、生成AIを使ったWebアプリの具体例として、日本語
 向けAI音楽生成サービス「AI Ongaku」の生成フローを取
 り上げます。\nAI Ongakuでは、ユーザーが曲の用途、雰
 囲気、ジャンル、歌詞などの条件を入力し、その内容
 をもとにAIが楽曲を生成します。このようなサービス
 では、単に「AIに曲を作らせる」だけではWebアプリと
 して成立しません。ユーザーから生成条件を受け取る
 入力画面、生成ジョブの管理、処理中の状態表示、完
 成した楽曲の試聴、条件を変更した再生成、過去の生
 成結果の管理といった一連の体験が必要になります。
 当日は、この実際の利用フローを題材にしながら、生
 成開始前に何を保存するか生成処理中にどの状態を持
 つか完成後にどのデータを残すか再生成をどのように
 設計するかユーザーが過去の生成物をどのように管理
 するかというWebアプリ側の設計を分解していきます。
 音楽生成は一例ですが、考え方そのものは画像生成、
 動画生成、文章生成、音声生成など多くの生成AIサー
 ビスに応用できます。\n\n小規模チームでも複雑にしす
 ぎない構成\n\n生成AIサービスというと、大規模なリア
 ルタイム基盤が必要に見えることがあります。しかし
 、すべてのサービスで複雑な構成が必要なわけではあ
 りません。ユーザー数、平均生成時間、同時実行数、
 失敗時の再実行要件などをもとに、どこまで非同期化
 するかどこまでリアルタイム通知が必要かどの情報をD
 Bに保存するかどこから先を外部サービスへ任せるかを
 判断する考え方についても紹介します。対象となる方
 ・生成AIを使ったWebサービスを開発している方・AI API
 を組み込んだSaaSを作っている方・個人開発でAIサービ
 スを作りたい方・バックグラウンドジョブや非同期処
 理の設計に興味がある方・生成履歴や再生成UXの作り
 方に悩んでいる方・AI機能を「デモ」ではなく継続し
 て使えるプロダクトにしたい方このイベントでは、特
 定のAIモデルを比較することよりも、生成AIをWebサービ
 スとして安定して提供するためのアプリケーション設
 計に重点を置きます。生成AI機能を一度実装したもの
 の、「待ち時間をどう扱えばいいか」「再生成をどう
 見せればいいか」「履歴をどう設計すればいいか」と
 いった課題を感じている方にも参加しやすい内容です
 。
LOCATION:
URL:https://techplay.jp/event/1000398?utm_medium=referral&utm_source=ics&ut
 m_campaign=ics
END:VEVENT
END:VCALENDAR
