AIによる対話型の鑑定
星詠の公開仕様では、Claude APIとOpenAI APIを使ってAI応答を生成。占い結果・対話・PDF鑑定書をAI生成コンテンツとして扱う。
ASTRAIA企画と設計の
記録
AIの生成を、 確認できる仕様にする。
個人で企画・開発し、本番公開した星詠 / Hoshiyomi。対話から鑑定書を届ける体験を、生成待ち・生成中・完成・失敗、保存先の条件へ具体化。実物PDF見本とDB設計をもとに紹介します。
設計の過程を読む課題の整理 → 構成の設計 → 技術の選択画像・データ構造・説明用デモで読み解く
01 / 課題から仕様・成果物へ要望を整理し、
要望を整理し、
確かめられる形に。
要望・設計上の問い
設計上の問い：対話から生まれる鑑定書を、生成中や失敗も含めてどう届け、後から確認できるようにするか。
要件・仕様に変える
PDF注文に状態・進捗・失敗理由・保存先を持ち、会話と記憶も分ける。状態名の制約と、正しい遷移や再実行の保証は分けて考える。
設計判断を読む成果物で確かめる
実物の鑑定書PDF。PDF注文の進捗・失敗理由・保存先と、会話・記憶を記録するDB定義を確認できます。
実画面を見る
この事例の担当範囲
個人で企画し、生成AIを活用して設計・実装から本番公開まで担当。対話・PDF注文の設計と、生成した実物PDF見本を紹介します。
使う人：占いや対話を通じて自分を振り返りたい人02 / 体験と処理の流れ画面の操作と、
画面の操作と、
裏側の処理をつなぐ。
画面の見どころ / 01
対話の先に、読み返せるコンテンツを。
- 01鑑定内容をPDFとして届ける。
- 02表紙から本文まで、一冊の体験として制作。
操作に対応する内部処理を読む
利用者の操作内部の処理
- 01
鑑定の結果を残す
占いや診断の結果を読む。
内部の処理fortune_readingsに結果や生成モデル・利用量を保持。
- 02
対話につなぐ
結果をもとに会話を続ける。
内部の処理会話に鑑定の参照キーを持ち、要約や重要度付きの記憶を別に保存。
- 03
鑑定書を生成する
PDFの出来上がりを待つ。
内部の処理注文に状態・進捗・エラー・完了日時を保持する構造。
- 04
生成物を届ける
鑑定書を読み返す。
内部の処理保存資料ではMinIOにPDFを保存。サンプルのメタデータはChromium / Skiaによる出力。
03 / AI・APIの役割AIが担う体験と、
AIが担う体験と、
APIの役割。
生成AIによる対話と、鑑定コンテンツ
AIが会話し、 鑑定を言葉と一冊にする。
- 01問い・これまでの文脈
会話・鑑定結果・要約と記憶
- 02AIが言葉を生成
Claude API / OpenAI API
- 03対話・鑑定コンテンツ
チャット応答・鑑定書として届ける
AI・APIの役割と、確認できる範囲
AIによる対話、占い結果の生成、読み返せるPDF鑑定書。会話の文脈と生成物の管理を組み合わせた、星詠 / Hoshiyomiの体験です。
会話の文脈をつなぐ
鑑定の参照キー、会話の要約、重要度付きの記憶を保持。会話の続きに必要な情報を分けて管理する構造。
生成量と成果物を管理
生成モデル名と入出力トークン数を記録。PDFは進捗・完了・失敗を管理し、成果物をMinIOに保存する。
本番公開済みのサービスです。星詠 / Hoshiyomiで利用するAPIと、対話・生成物の保存設計を紹介しています。
04 / データのつながり体験を支える、
体験を支える、
データの関係。
- 問い・鑑定の文脈会話と要約・記憶
- AIと生成処理Claude・OpenAI
- 対話・PDFPostgreSQL・MinIO
会話の文脈から、続く体験と生成物へ。
資料から整理した構成図データ項目と関連を詳しく見る
項目を選ぶと、そのデータにつながる関係を確認できます。
主要なデータの関係
外部キー キー・保存先fortune_readingsuser_id接続先：app_userschat_sessionsuser_id接続先：app_userschat_messagessession_id接続先：chat_sessionsmemory_entriesuser_id接続先：app_userspdf_ordersuser_id接続先：app_userschat_sessionscontext_fortune_id接続先：fortune_readings
実線はSQL上の外部キー、破線は保存されている参照キーです。鑑定と会話の参照キーについて、外部キー制約はこの資料では確認できません。
05 / 設計判断と制約その設計には、
その設計には、
理由と制約がある。
画面の先まで考える
その場の発言と、後に引き継ぐ文脈を異なる情報として整理できる。
01会話、記憶、鑑定を分けて持つ。
- しくみ
- 会話には要約と鑑定参照キー、記憶には重要度・タグ・キャラクター・削除日時を保存する。
- この構成でできること
- その場の発言と、後に引き継ぐ文脈を異なる情報として整理できる。
- 制約・考慮点
- 記憶の重要度は1〜5の制約があるが、何を覚えるか、要約が適切か、削除が応答へ反映されるかは別途確認が必要。
参照：astraia.sql / chat_sessions・memory_entries
02PDFを、結果だけでなく生成中の状態でも扱う。
- しくみ
- pending / generating / completed / failedをCHECK制約で限定し、進捗・失敗理由・各日時を保持する。
- この構成でできること
- 生成が途中で止まった場合にも、更新時刻や失敗記録を手がかりに状況を追える。
- 制約・考慮点
- CHECK制約が保証するのは状態名の範囲。遷移順序や再生成・返金の整合性を保証するものではない。
参照：astraia.sql / pdf_orders_status_check
03生成量を記録し、共通の結果を再利用する構造にする。
- しくみ
- モデル名と入出力トークン数を保存。日次占いは星座・日付・時間帯を一意キーとしてキャッシュを保持する。
- この構成でできること
- 生成量を分析し、共通する結果を使い回す設計の土台になる。
- 制約・考慮点
- 実際のキャッシュヒット率やコスト削減量は未測定。時刻境界での更新や再生成も確認が必要。
参照：astraia.sql / chat_messages・daily_fortunes_cache
06 / 場面ごとの動きこんなとき、
こんなとき、
どう動く？
鑑定書ができるまで、進み具合をどう管理する？
生成待ちから完成まで、保存する情報を4つの場面で紹介します。説明用のため、実際のAI生成や課金は行いません。
下の状況を選ぶと、図や説明が切り替わります。
この例の結果
注文を記録し、鑑定書の生成を待ちます。
注文内容・生成に使う条件・作成日時を保存します。まだ完成していない注文も、状態を分けて管理できる構造です。
しくみと、実運用で確認したいこと
- 生成待ちこの例の注目点
- 生成中この例では未実施
- 完成この例では未実施
- 生成の状態
- 生成待ち（pending）
- 進み具合
- 0（説明用）
- 保存される情報
- 注文・生成条件・作成日時
実運用で確認したいこと長時間待ったままの注文を見つけられるかを確認します。
07 / 担当と次の検証担当したことと、
担当したことと、
今後の改善。
この作品で取り組んだこと
01
体験を要件に分ける
対話から読み返せる鑑定書へ、必要な画面・会話の文脈・生成中の状態を分けて企画を具体化する。
02
個人制作で形にする
体験・仕様・画面構成を自分で決め、コード作成に生成AIを活用。対話からPDF生成まで、意図した動作になっているか検証し、改善する。
03
完成以外の確認条件を持つ
生成中断、再実行、保存先の実在を確認条件にする。実物PDFがあることと、復旧や二重生成防止が動くことを区別する。
掲載資料と確認できる範囲
完成物で示せること
MinIOのsamples領域に「星詠 / HOSHIYOMI」の鑑定書見本を確認。人物名は例文。
仕様と生成の資料
PDF注文の状態・進捗・失敗理由・保存先をDB定義で紹介。掲載するPDF見本は、実際に生成した鑑定書です。
AI・動作確認の範囲
本番環境へ公開済みです。Claude API・OpenAI APIを利用し、AI対話とPDF鑑定書を提供。掲載の図と条件切替デモでは、生成処理と保存する状態の関係を説明します。