Streamlit は社内ツールだけじゃない！PoC の速さで実現する'商用品質'の分析 SaaS アーキテクチャ

PyCon JP 2025.9.27 (DAY2)　14:05 - 14:35

Transcript

1. Streamlit は社内ツールだけじゃない！ PoC の速さで実現する"商⽤品質"の分析 SaaS アーキテクチャ PyCon JP 2025.9.27 (DAY2) 14:05 - 14:35 Recustomer 株式会社 古川 祐希
2. 名前: 古川 祐希 GitHub: K-dash 所属: Recustomer 株式会社 略歴: • 2012 ~ 2018 ◦ インフラエンジニア • 2018 ~ 2025 ◦ Web アプリケーション開発 ◦ サーバー/NW構築⾃動化 • 2025/04 〜 ◦ Recustomer の Platform チーム Python 歴: • 4 年ほど • Streamlit 歴は 1 年くらい ⾃⼰紹介
3. • Streamlitの基礎は押さえている • Streamlitの速さに魅⼒を感じつつも、商⽤品質とのギャップに悩んでいる • デコレータ∕型ヒント∕テストで堅牢な設計を⽬指したい 本発表が刺さりそうな⽅
4. • Streamlit を商⽤品質で提供するための Tips ◦ パフォーマンス ◦ 堅牢性＆セキュリティ ◦ 品質保証 ✅ お話すること • Streamlit の基本的な使い⽅ • Python 以外の技術要素の詳細 ◦ AWSなど ❌ お話しないこと 発表内容のスコープ
5. • シンプル ◦ 直感的 API で数⼗⾏から始められる • インタラクティブ ◦ ウィジェット操作が画⾯にリアルタイム反映 • Pythonで完結 ◦ Streamlit と Python の知識だけで作れる（HTML/CSS/JS は基本不要） • 共有しやすい ◦ 作ったものをすぐ⾒せて回せる（URL で共有しやすい） • エコシステム ◦ pandas, Plotly, NumPy など、既存の Python ライブラリ資産をそのまま活⽤できる ◦ 豊富なコミュニティライブラリ そもそも Streamlit とは？ Streamlit を知らない⽅向けに 特徴
6. イントロダクション Streamlit の爆速 PoC を 商⽤品質 に⾼めるミッション
7. Recustomer の製品ラインナップ
8. ある⽇、お客様からこんな声が 配送ステータス通知メールの開封率を可視化したい 返品率が⾼い商品を知りたい 分析機能のニーズが顕在化
9. AWS Cloud Recustomer のアーキテクチャ どんなアーキテクチャで実現するか？ ToBe向け フロントエンド 認証基盤 バックエンドマイクロサービス 返品‧キャンセル 配送追跡 注⽂管理 エンドユーザー Recustomer社員 社内分析基盤 顧客へ迅速に価値を届けるためには 外部向け 内部向け 案① 案② 社外部向け 分析プロダクト マルチテナント
10. Pros • ✅ 拡張性が⾼く、複雑な要件にも対応可能 • ✅ UI/UX の⾃由度が⾮常に⾼い Cons • ❌ 開発⼯数増で価値提供までの LT が⻑い • ❌ front/back 双⽅の専⾨知識が必要 顧客へ迅速に価値を届けるためには 案① Next.js + FastAPI Pros • ✅ Python の知識だけで迅速に開発可能 • ✅ 社内向け Streamlit の実装を活かせる • ✅ 豊富な可視化ライブラリを容易に統合できる Cons • ❌ デザインやレイアウトの⾃由度が低い • ❌ 複雑な UI インタラクションや状態管理は苦⼿ 案② Streamlit アプローチ なぜ Streamlit？ 顧客に価値を届けるまでのLTを最短にする
11. • ①パフォーマンス • ② 堅牢性‧セキュリティ • ③ 品質保証 とはいえ、Streamlit の採⽤には⼤きな壁が… 顧客へ迅速に価値を届けるためには ⽴ちはだかる「商⽤品質」の要件 Streamlit、本当に本番で使える？
12. • ① パフォーマンス ◦ レスポンス速度とコスト効率 ▪ 商⽤機能として提供するからには特にパフォーマンスが求められる… どうやって乗り越えたか？ 3 つの設計戦略 顧客へ迅速に価値を届けるためには • 👉解決策 ◦ データアクセスパターンの最適化 ▪ Streamlit のキャッシュ機構を活⽤して I/O を削減し、UI レスポンスを向上させる。
13. • ② 堅牢性‧セキュリティ ◦ 認証 ▪ Streamlit で既存の認証基盤と安全な認証を⾏いたい… ◦ 予期しないデータ漏えい ▪ Streamlit は例外が発⽣するとブラウザ画⾯に詳細な StackTrace を出してしまう… どうやって乗り越えたか？ 3 つの設計戦略 顧客へ迅速に価値を届けるためには • 👉解決策 ◦ 横断的関⼼事の分離 ▪ 認証‧例外エラー処理を Python の Decorator に集約する。
14. • ③ 品質保証 ◦ 他のマイクロサービスと同様にバグのない⾼い品質を担保したい… どうやって乗り越えたか？ 3 つの設計戦略 顧客へ迅速に価値を届けるためには • 👉解決策 ◦ 静的解析の徹底 ▪ 「型」の⼒で実⾏前にバグを検知する。 ◦ UIテスト
15. 社外向けアナリティクス 認証基盤 mypy∕pyright と Result 型を⽤いた型安全性の担保 例外ハンドラ（最外層のデコレータ） st.stop デコレータ（2層⽬） 認証 デコレータ（３層⽬） 可視化層 データ処理層 キャッシュ層 Sesson State aws-wrangler 3 つの設計戦略を取り⼊れた全体アーキテクチャ 顧客へ迅速に価値を届けるためには 開発者 データインフラ Amazon Athena Amazon S3 エンドユーザー PR CI（Lint/Test） PR merge Deploy ※AWS の構成（データソースや取り込み部分等）は便宜上省略 Session Cookie 検証 データ取得
16. １．パフォーマンス
17. 社外向けアナリティクス 認証基盤 mypy∕pyright と Result 型を⽤いた型安全性の担保 例外ハンドラ（最外層のデコレータ） st.stop デコレータ（2層⽬） 認証 デコレータ（３層⽬） 可視化層 データ処理層 キャッシュ層 Sesson State aws-wrangler 以下の話をします データインフラ Amazon Athena Amazon S3 エンドユーザー Session Cookie 検証 データ取得
18. • 分析ダッシュボード開発で誰もが懸念するのは「速度」と「コスト」 ◦ レスポンス遅延 → ユーザー体験の悪化 ◦ データスキャンコスト → 運⽤費⽤の増⼤ パフォーマンスの壁 体感速度UP と コストDOWNの両⽴
19. • アーキテクチャの前提と⽅針 ◦ 可視化対象データを S3 に蓄積し、 Streamlit から Athena で参照 • ねらい ◦ ⼩さく始めて 速く可視化、運⽤は 軽量にする データインフラ 体感速度UP と コストDOWNの両⽴ Amazon Athena ※S3のデータをSQLクエリで参照できるサービス Amazon S3 （NEW） 社外向け アナリティクス機能
20. • pandasとAWSデータサービスをシームレスに連携できるライブラリ AWS SDK for pandas (awswrangler) 体感速度UP と コストDOWNの両⽴
21. • 何も考えずに実装するとウィジェット操作のたびに同じ条件でもクエリが⾛る ◦ レスポンス遅延とスキャンコスト増という課題は解消されない クエリ発⾏回数をどう減らすか？ 体感速度UP と コストDOWNの両⽴ Streamlit には標準でキャッシュ⽤APIが存在します！
22. ユーザー/タブごとのキャッシュ • スコープ ◦ 1ユーザー1タブ単位（各タブは独⽴） • ⽤途 ◦ 同じ画⾯内での再クエリ ◦ 再描画で使い回す⼀時データ 体感速度UP と コストDOWNの両⽴ st.session_state()
 全ユーザー共通のキャッシュ • スコープ ◦ アプリ全体で共有（プロセス内） • ⽤途 ◦ 誰が⾒ても同⼀結果の低頻度更新データ @st.cache_data
 Streamlitの 2 ⼤キャッシュ機能（正確には 3 つある） ※他にも @st.cache_resource() がある
23. • ①再クエリの条件を明⽂化 ◦ キャッシュキー ▪ ⼊⼒条件（⽇付等）＋ テナント境界値（ユーザーID等）の組み合わせ ▪ 上記に変化があるときだけクエリ発⾏ ◦ ②スコープで使い分け ▪ st.session_state()
 • 直前に取得した表データ、フィルタ適⽤後の中間結果等
 ▪ @st.cache_data
 • マスタ⼀データ等
 キャッシュ戦略 体感速度UP と コストDOWNの両⽴
24. • 危険なキャッシュキー @st.cache_data の罠 体感速度UP と コストDOWNの両⽴ @st.cache_data マルチテナントでの安全なキャッシュ • 安全なキャッシュキー テナント境界値を含める テナント境界値がない
25. • 起きる問題: メンテナンス性の低下 ▪ どこで何がキャッシュされているか不明 ▪ →同じキー名で意図しない上書きが発⽣する懸念がある st.session_state() の罠 体感速度UP と コストDOWNの両⽴ 便利な反⾯、多⽤すると保守性が低下する st.session_state()
26. • st.session_state() を扱うキャッシュ⽤のクラスを作る ◦ キャッシュの⽤途ごとに getter/setter を⽤意するイメージ ▪ すべてのメソッドは引数でテナント境界値を受け取る ◦ 当該クラス以外で st.session_state() の利⽤を禁⽌ st.session_state() への唯⼀のアクセスポイントを作る 体感速度UP と コストDOWNの両⽴
27. st.session_state() への唯⼀のアクセスポイントを作る 体感速度UP と コストDOWNの両⽴ • Ruff の banned-api でガバナンスを効かせる ◦ 前述のアクセスポイントクラス以外からは st.session() を利⽤できないようLinterレベルで保証 する pyproject.toml pyproject.toml アクセスポイント以外で st.session() を呼び出している状態で ruff check 実⾏ 違反が検出される
28. • 👉キャッシュ戦略によるクエリ最⼩化 ◦ st.session_state と @st.cache_data の戦略的な使い分けが鍵 ▪ 初回は遅くても、2回⽬以降の操作が⾼速になる設計を意識する • 👉マルチテナントでの安全なデータ分離（@st.cache_data） ◦ tenant_id 等のテナント境界値を含むキャッシュキーを⽤いてデータ漏洩を確実に防⽌する • 👉状態管理の⼀元化 ◦ st.session_state の集約クラスで散在を防ぎ、安全なキャッシュキー設計を強制する 『パフォーマンス』のまとめ
29. 『パフォーマンス』で伝えたいこと • キャッシュ戦略によるクエリ最⼩化 ◦ st.session_state と @st.cache_data の戦略的な使い分けが鍵 ▪ 初回は遅くても、2回⽬以降の操作が⾼速になる設計を意識する • マルチテナントでの安全なデータ分離（@st.cache_data） ◦ user_id 等のテナント境界値を含むキャッシュキーを⽤いてデータ漏洩を確実に防⽌する • 状態管理の⼀元化 ◦ st.session_state の集約クラスで散在を防ぎ、安全なキャッシュキー設計を強制する 対話は⼀度に、 境界は明確に、 無法地帯をなくせ
30. ２．堅牢性＆セキュリティ
31. 社外向けアナリティクス 認証基盤 mypy∕pyright と Result 型を⽤いた型安全性の担保 例外ハンドラ（最外層のデコレータ） st.stop デコレータ（2層⽬） 認証 デコレータ（３層⽬） 可視化層 データ処理層 キャッシュ層 Sesson State aws-wrangler 以下の話をします データインフラ Amazon Athena Amazon S3 エンドユーザー Session Cookie 検証 データ取得
32. Streamlit 例外処理の"罠" UI から情報漏えいさせない • Streamlit のデフォルト設定では、例外が発⽣するとStackTraceがブラウザにそのまま表⽰されてしまう。 • これはデバッグには便利な反⾯、情報漏えいのリスクがあり、商⽤環境では致命的。
33. • 設定ファイル（.streamlit/config.toml） ◦ showErrorDetails = "none" を指定することで、 例外情報がブラウザ画⾯に漏れ出すことを防げる。 絶対にやってほしい対策 UI から情報漏えいさせない これで安全は確保ができるが‧‧‧
34. • 代わりにユーザーには意味のない汎⽤エラーが表⽰されるようになる ◦ showErrorDetails = "none" の場合に表⽰されるエラーは以下 課題 ①：不親切なエラー表⽰ UI から情報漏えいさせない 私たちが本当に表⽰したいのは意味のあるメッセージ
35. • 意味のあるメッセージを表⽰する場合、例外を捕捉して st.error(), st.stop() を使うのが定⽯ ◦ しかし、これをアプリケーションの⾄る所に記述するとビジネスロジックと UI 制御が癒着し、 コードの可読性‧保守性が著しく低下する 課題 ②：コードの汚染と例外ハンドリング忘れ UI から情報漏えいさせない 例外ハンドリングを忘れる可能性もある st.error(), st.stop()が ⾄る所に散在し、⾒通しが悪い st.error(), st.stop()が ⾄る所に散在し、⾒通しが悪い
36. • コードの汚染と例外ハンドリング忘れを防⽌し、 • 確実に意味のあるメッセージを表⽰させたい… ２つの課題に対する対応策 UI から情報漏えいさせない 例外ハンドラ（最外層のデコレータ） st.stop デコレータ（2層⽬） これ これらを解決する強⼒なピースが Python の デコレータ
37. • 失敗する可能性のある処理は、成功/失敗を持つ特別な結果オブジェクトを返すというルールを設ける ◦ 弊社では、Rust ライクな Result 型 と AnyError 型 を⽤意して実現 （詳細は後述） • エラーの場合は st.error() や st.stop() を実⾏する ⾨番的なデコレータ を⽤意 ◦ デコレータは Result(T, E) を受取り、Eの場合は E に含まれるメッセージを st.error() にセットして return するイメージ 第 1 防衛線：想定内エラーをデコレータで処理 UI から情報漏えいさせない st.stop デコレータ（2層⽬） 例外ハンドラ（最外層のデコレータ）
38. 第 1 防衛線：想定内エラーをデコレータで処理（コード例） UI から情報漏えいさせない st.error()がデコレータ内のみになる ページのmain関数を実装するときにデコレータを 1回だけつければいいので以降の付与漏れを防⽌ ページのmain関数 st.stop デコレータ Result型を返す関数 エラーの場合、ブラウザ画⾯に表⽰するメッセージを AnyError 型に包んでデコレータに渡す
39. 第 2 防衛線：想定外エラーを"最後の砦"で捕捉 UI から情報漏えいさせない st.stop デコレータ（2層⽬） 例外ハンドラ（最外層のデコレータ） • しかし、万が⼀の考慮漏れや、予期せぬ例外は起こり得る… ◦ その場合に備え、ページ全体を try-except で囲む "最後の砦"デコレータ を最も外側に配置 予期せぬ例外が起きたときに必ず表⽰させたい メッセージをデコレータに定義しておく
40. 堅牢性と可読性を両⽴する積層デコレータ UI から情報漏えいさせない この 2 段構えのデコレータを main 関数に適⽤すれば完成 st.stop デコレータ（2層⽬） 例外ハンドラ（最外層のデコレータ） main 関数内に st.error(), st.stop() は⼀切登場しない
41. 社外向けアナリティクス 認証基盤 mypy∕pyright と Result 型を⽤いた型安全性の担保 例外ハンドラ（最外層のデコレータ） st.stop デコレータ（2層⽬） 認証 デコレータ（３層⽬） 可視化層 データ処理層 キャッシュ層 Sesson State aws-wrangler 実は、もう⼀層あります データインフラ Amazon Athena Amazon S3 エンドユーザー Session Cookie 検証 データ取得
42. 1. toB向けフロントエンドで既にログイン済みのユーザーだけがアナリティクスを利⽤できること 2. テナント‧ユーザー単位でデータ分離できること（SessionID ベースで厳格に） 3. タブ間でも⼀貫した認証状態を維持できること（複数タブでも認証状態が整合すること） 社外向けアナリティクス機能における認証要件 認証 フロントエンド 認証基盤 エンドユーザー （マルチテナント） （NEW） 社外向け アナリティクス機能 ①ログイン ②認証 ④Cookie付きで アクセス ⑤Session IDの検証 ③SessionIDを Cookieに含めて返却
43. • Streamlit 公式認証の特徴 • できること ◦ ✅ OIDCベースのログイン/ログアウトとユーザー識別（"誰か"は分かる） • ⾜りないこと ◦ ❌ マルチテナントの認証フローは⾃前設計が必要 Streamlit標準認証では解決できない課題 認証 標準の認証機能だけでは要件を満たすことができないことが判明😢
44. • Streamlitの通信⽅式 ◦ Streamlitはリアルタイム更新のため、ブラウザとサーバー間でWebSocket通信を⾏う仕様 • 特性 ◦ 各ブラウザタブは独⽴した WebSocket を確⽴ ＝ 別セッション StreamlitのWebSocket接続とセッション管理 認証
45. 認証結果はキャッシュしないこと 認証 • ⚠このアプローチの具体的なリスク ◦ 失効が効かない：認証基盤で無効化しても古い認証情報で動き続ける ◦ ログアウトの不整合：他タブや他端末でのログアウトが反映されない 危険 危険 • ❌認証チェックは重いから、⼀度確認したらキャッシュ（session_state 等）に保存しよう
46. • 設計思想 ◦ UI層（st.session_state() 等）で認証の真偽はキャッシュしない ▪ リクエストごとに Cookieの SessionID を抽出 → 認証基盤に照会 ▪ 失敗時は統⼀的なエラー表⽰とロギング 第 3 防衛線：認証デコレータ 認証 st.stop デコレータ（2層⽬） 例外ハンドラ（最外層のデコレータ） 認証 デコレータ（３層⽬） 認証デコレータ内で 都度Cookie（SessionID）の検証
47. • 最後に、認証デコレータを main 関数に追加することで堅牢性を備えた 3 層構造が完成 完成形: 3 層積層デコレータ 認証 st.stop デコレータ（2層⽬） 例外ハンドラ（最外層のデコレータ） 認証 デコレータ（３層⽬）
48. 完成形: 3 層積層デコレータ 認証 st.stop デコレータ（2層⽬） 例外ハンドラ（最外層のデコレータ） 認証 デコレータ（３層⽬）
49. 3 層デコレータで実現できたこと • 👉セキュリティ向上 ◦ データ漏洩防⽌: 例外発⽣時に安全で意味のあるメッセージを表⽰する ◦ ログイン失効の即時反映: 認証結果はキャッシュせずに都度検証による安全性 • 👉保守性向上 ◦ 本質ロジックに集中: 認証や例外ハンドリングから開放されるので認知負荷の軽減 ◦ 保守性向上: st.error() や st.stop() がコードのあちこちに散らばらない ◦ 付与漏れ防⽌: 最初にデコレータを main 関数に付けるだけ 『堅牢性＆セキュリティ』のまとめ
50. 3 層デコレータで実現できたこと • 👉セキュリティ向上 ◦ データ漏洩防⽌: 例外発⽣時に安全で意味のあるメッセージを表⽰する ◦ ログイン失効の即時反映: 認証結果はキャッシュせずに都度検証による安全性 • 👉保守性向上 ◦ 本質ロジックに集中: 認証や例外ハンドリングから開放されるので認知負荷の軽減 ◦ 付与漏れ防⽌: 最初にデコレータを main 関数に付けるだけ 『堅牢性＆セキュリティ』で伝えたいこと 横断的関⼼事は、外層で吸収せよ デコレータ
51. ３．品質保証
52. 1. 静的品質保証 ◦ 型チェックの徹底 ＝ 型安全ファースト 2. UIテスト⾃動化 ◦ Streamlit Testing API ⾼速‧⾼品質を⽀える重要な柱 ⾼速な開発サイクルを⽀える仕組み
53. 社外向けアナリティクス 認証基盤 mypy∕pyright と Result 型を⽤いた型安全性の担保 例外ハンドラ（最外層のデコレータ） st.stop デコレータ（2層⽬） 認証 デコレータ（３層⽬） 可視化層 データ処理層 キャッシュ層 Sesson State aws-wrangler 以下の話をします データインフラ Amazon Athena Amazon S3 エンドユーザー データ取得 Session Cookie 検証
54. • 型は制約ではなく、開発を加速させるガイド • 安全なリファクタリングが可能 • コードが動くドキュメントになる • 強⼒なIDE⽀援を享受 • LLM（コーディングエージェント）に実装の意図を伝える明確な仕様書 なぜ『型』が開発スピードを上げるのか？ 柱① 型安全ファースト
55. 型チェッカー（mypy/pyright）の詳細は… 柱① 型安全ファースト
56. Result型：型安全なエラーハンドリング 柱① 型安全ファースト 例外の代わりに型で表現（以下は実装の⼀部を抜粋） ‧エラーが発⽣する可能性を関数シグネチャで明⽰ ‧エラーハンドリングの漏れをmypyで静的に検出可能 ‧呼び出し側で必ずis_okまたはis_errの確認が必要  →エラーハンドリングの実装漏れを防⽌
57. AnyError型：構造化されたエラー情報 柱① 型安全ファースト エラーの階層化と型安全性（以下は実装の⼀部を抜粋） エラーの種類を型レベルで明⽰ 任意の⽂脈情報を持たせることができる
58. • Streamlit アプリをブラウザレスで実⾏し、ウィジェット操作と画⾯結果をコードから検証する • AppTest がアプリを疑似実⾏し、要素取得‧操作（クリック∕⼊⼒）‧再実⾏を提供 
 
 
 Streamlit Testing API 柱② UIテスト⾃動化 Streamlitには、公式の Testing API （streamlit.testing.v1）が⽤意されています！ テスト対象の Streamlit アプリコード テストコード
59. Playwright (ヘッドレスブラウザ) Streamlit Testing API (ブラウザレス) Testing API は⾼速だけど万能ではないという話 柱② UIテスト⾃動化 • 本物のブラウザを裏側で動かす • ⾒た⽬(CSS/JS)までテストできる ◦ その分、動作は相対的に重い • ブラウザを⼀切動かさない • UIロジック中⼼をテストする ◦ 超軽量で⾼速
60. • 👉静的品質保証の徹底 ◦ 型やLinterの⼒で実⾏前にバグを検知し、開発スピードと安全性を両⽴ • 👉UIテストの⾃動化 ◦ Streamlit Testing APIをCIに組み込み、UIの品質を担保 ◦ ※⾒た⽬の検査は別途、Playwright等のE2Eテストフレームワークが必要 『品質保証』のまとめ
61. • 👉静的品質保証の徹底 ◦ 型やLinterの⼒で実⾏前にバグを検知し、開発スピードと安全性を両⽴ • 👉UIテストの⾃動化 ◦ Streamlit Testing APIをCIに組み込み、UIの品質を担保 『品質保証』で伝えたいこと 品質規約とUI仕様は、コードで保証せよ
62. まとめ
63. まとめ デコレータによる関⼼の分離 • 積層防御アーキテクチャ 🛡 堅牢性 & セキュリティ 戦略的キャッシュによる I/O 最⼩化 • 安全な状態管理 🚀 パフォーマンス 静的解析と UI テスト • 型安全ファースト • Streamlit Testing API ⚙ 品質保証 🎉 成果 • 開発着⼿から 2 週間でリリース（2025年5⽉〜） • リリースから現在までインシデントゼロで安定稼働中 • 品質を保ちつつ、Streamlitの俊敏性で絶賛機能拡張中
64. Streamlit は社内ツールだけじゃない！ Pythonのピースを組み合わせれば Poc の速さ × SaaSの品質は両⽴できる
65. Thank you!