こんにちは、DX攻略部のkanoです。
ダッシュボードの軽微な修正や、現場が使う簡単な業務アプリでも、外部ベンダー依頼だと見積もり調整や開発待ちが発生しがちです。
結果として「見たい指標が見られない」「改善の判断が遅れる」状態が続いてしまいます。
そこで注目したいのが、Snowflake上でStreamlitアプリを動かせるStreamlit in Snowflake（Snowflakeの中で画面アプリを実行できる仕組み）です。
データを外部に移さずに、可視化（グラフや表）と入力（フォーム更新）を同じ場所でつなげられます。
この記事では、内製ダッシュボードとワークフロー（申請や承認などの業務手順）を、どこから小さく始めるべきかをユースケースで整理します。
読み終える頃には「最初の1画面」の作り方が具体化するはずです。
そして、DX攻略部では、Snowflake×Streamlitを活用した統合BI基盤構築支援サービスを行っています。
SnowflakeとStreamlitによるデータ可視化ソリューション。業種別ダッシュボードで意思決定を加速。SCD T…
記事の内容を確認して、Snowflakeを自社に活用してみたいと考えた方は、下記のボタンをクリックしてぜひDX攻略部にご相談ください！
Snowflake×Streamlitでできること一覧
ここではSnowflake×Streamlitで実現できる機能の全体像を押さえます。
この章では「Snowflake×Streamlitが向く仕事」を、判断しやすい形に整理します。
ポイントは、見る（可視化）だけで終わらず、操作する（入力や更新）があり、流す（承認や通知など次の手順につなぐ）までを一続きにしたいかどうかです。
この3つがそろうほど、別ツール間の行き来やCSV受け渡しが減り、意思決定から反映までのリードタイム（完了までにかかる時間）を短縮できます。
まずは自社の業務で「操作」と「流す」がどこにあるかを探してみてください。
ダッシュボードと業務アプリとワークフローの違い
Snowflake×Streamlitの強みは「見る」「操作する」「流す」を同じ場所で扱えることです。
ダッシュボードはKPIの可視化や深掘り分析に向き、業務アプリはフォーム入力やボタン操作でデータを更新できます。
ワークフローは定期実行や通知まで含んだ一連の業務手順です。
これらを一体化することで、Excelの配布やCSVの受け渡しといった手作業を減らし、意思決定から反映までの時間を短縮できます。
代表的な活用シーン（営業・在庫・CS・管理部門）
営業では、案件一覧を見ながら確度や次アクションをその場で更新できるため、会議後の入力待ちが減ります。
在庫では、欠品予兆を見つけた瞬間に「推奨発注量」を提示し、承認ボタンで確定まで進められます。
CS（カスタマーサポート）では、応答時間や一次解決率を見て、エスカレーション（上位担当へ引き上げる対応）の登録まで同じ画面で完結できます。
管理部門でも、稟議の簡易承認や支払ステータス更新を「見ながら操作する」形に寄せられます。
これにより「見てから別システムで操作する」という行き来が減り、現場のスピードが上がります。
可視化と入力UIで「データを動かす」基本
Streamlitはドロップダウンや日付選択、フォームなどのUI部品が標準で使えます。
ここでいう「データを動かす」とは、データを外部にコピーして持ち回るのではなく、Snowflake内のテーブルを更新して業務を前に進めることです。
StreamlitにはドロップダウンやフォームなどのUI（ユーザーインターフェース：画面の操作部品）があり、入力内容を条件に集計を変えたり、承認結果をテーブルに記録したりできます。
可視化と更新を同じ画面でつなぐと、「見た人がその場で直す」流れになり、現場の待ち時間が短くなります。
こんにちは、DX攻略部のkanoです。 顧客データを活用したマーケティングは「つなぐ力」で成果が大きく変わります。 Snowflakeはデータのサイロを解消し、分析と配信の両方に耐える柔軟な基盤を提供するツールです。 顧客デー[…]
インタラクティブなダッシュボードを内製する
この章では、現場が“触れる”ダッシュボードを作るときの設計ポイントを整理します。
狙いは、会議中に「その条件でもう一度見たい」が出たとき、担当者が自分で絞り込み、数十秒で仮説検証できる状態です。
例えば「日次売上の前年差」を会議で確認し、原因商品をドリルダウン（上位から明細へ掘り下げる操作）で追えるだけで、意思決定のスピードが上がります。
運用指標としては、会議後の追加集計依頼件数や、意思決定までの時間が分かりやすいでしょう。
セレクターとフィルターで即時絞り込み
Streamlitを使えば、日付範囲や担当者、商品カテゴリなどの選択に応じて、グラフや指標を即時更新できます。
現場の担当者は自分の切り口で絞り込み、気になる点をその場で確かめられます。
複雑な設定がなくても、実務で使える対話型のダッシュボードが作れるのが魅力です。
期間比較・上位下位・ドリルダウン
前年同週比や上位下位の抽出など、定番の切り口はSQL（データを集計・検索するための言語）の集約で表現できます。
ウィンドウ関数（順位付けや移動平均との差など、行のまとまりを見ながら計算できるSQL機能）を使うと、ランキングや前年差の算出が安定します。
切り替え操作はStreamlitのセレクター（選択UI）で受け取り、同じロジックに条件だけ渡す形にすると、会議中の検証が速くなります。
グラフから明細へドリルダウンし、差異の理由をすぐに追跡できる設計にしておくと、定例会議での「その場検証」に強くなります。
計算ロジックはSnowflakeのSQL（集約、ウィンドウ関数など）で、切り替えや明細へのドリルダウンはStreamlitが選択状態を保持して再クエリする形です。
グラフとテーブルの連動設計
SnowflakeとStreamlitを使えば、折れ線グラフで選んだシリーズに応じてテーブルを再計算する、テーブルの行選択に合わせて詳細カードを出す、といった連動が簡単です。
ユーザーの操作がそのままクエリ条件に反映されるため、説明と検証を同じ画面で完結できます。
こんにちは、DX攻略部のkanoです。 企業のDX推進では「データを集められるか」だけでなく、「意思決定に使える状態にできるか」が成果を左右します。 ところが現場では、部門ごとにデータが分断され、集計に時間がかかり、結局は経験と勘に戻っ[…]
現場ワークフローをアプリ化する
ここでは申請や承認、コメント記録などの軽量業務フローをアプリに落とし込む方法を説明します。
ワークフローをアプリ化する価値は「早くなる」だけではありません。
誰がいつ何を承認し、どの値がどう変わったかをテーブルに残せるため、監査対応（後から追跡できる状態）と属人化の解消に直結します。
現場ワークフローをアプリ化するためのポイントを確認していきましょう。
申請・承認・コメントを画面で完結
SnowflakeとStreamlitを使って、申請・承認・コメントを画面で完結できるアプリを作成できます。
例えば、経費や在庫移動など、軽量な申請・承認フローはフォーム入力→承認ボタン→コメント履歴という画面で完結する形です。
承認権限はロール（役割）で制御し、誰が何を承認したかの履歴をテーブルに残せば監査にも対応できます。
フォーム入力でテーブル更新と履歴管理
更新系の処理は「本体テーブル」と「履歴テーブル」を分けるのが基本です。
履歴には変更前後の値、操作ユーザー、操作時刻を保持したものにしましょう。
差分を下流処理に渡す必要があれば、変更検知により安全に後続バッチや通知へつなげられます。
通知連携と定期実行の設計
通知連携や定期実行に関わるアプリの作成も可能です。
例えば、毎朝の定型集計や、しきい値を超えたときのアラート通知はスケジュール実行と通知連携で自動化します。
アプリで承認されたレコードだけを対象にして、担当者へメールやチャット通知を送るといった“最後の一押し”まで含めると、運用工数が大きく下がります。
SQLとPythonを同じ場で使う
SnowflakeとStreamlitを使えば、SQLとPythonの得意分野を組み合わせられます。
SQLとPythonを同じ場面で使った効率化について紹介します。
SQLで集計しPythonで業務ロジックを実装
集計や結合はSQLが得意で高速です。
Streamlitのセレクターやフォームで受け取った絞り込み条件をSQLのパラメータに渡し、集計結果を更新するようにしましょう。
一方で複雑なビジネスルールや外部サービスとの連携はPythonが適します。
Streamlitのボタン操作をきっかけにSnowflake上のPython実行基盤（Snowpark）を呼び出すことで、画面操作と再計算を滑らかにつなげられます。
SnowparkとUDFで再利用可能な処理にする
Snowpark（Snowflake上でPythonなどを実行できる仕組み）を使うと、画面操作をきっかけに計算やデータ加工をSnowflake内で完結できます。
繰り返し使う計算は、UDF（ユーザー定義関数：自社ルールの計算を関数として登録する仕組み）や、ストアドプロシージャ（複数処理をまとめて呼び出せる手順）としてSnowflake側に寄せると、複数アプリでロジックがぶれません。
Streamlitは、実行結果の見せ方やエラー表示、再実行ボタンなど「現場が迷わない体験」を担当します。
こうして役割分担すると、計算の正しさと画面の使いやすさを両立できます。
外部API連携の基本パターン
SnowflakeとStreamlitを使った、外部API連携の基本パターンは以下のような形です。
在庫マスタ照会や配送ステータス取得、為替レート更新などの外部API呼び出しは、Streamlitのボタンで開始し、SnowparkのPythonコードでAPIを実行、結果をテーブルに保存して画面へ反映します。
外部API連携は、成功パターンよりも「失敗しても復旧できる設計」が重要です。
例えばレート制限（一定時間に呼べる回数の上限）で失敗した場合、画面に理由を出し、数分後に再実行できる導線を用意すると現場が止まりません。
また、実行結果をステータステーブルに記録しておけば、担当者は「いつ失敗したか」「どこまで終わったか」を追えます。
運用目線では、ここまでが最低ラインだと考えてください。
こんにちは、DX攻略部のkanoです。 この記事は、はじめてSnowflakeを触る方が「最初の30分」で迷いやすいポイントだけを先回りして、最低限の動作確認まで進めるためのガイドです。 具体的には、Snowsight（Snow[…]
データを持ち出さない安全なアプリ運用
ここではセキュリティとガバナンスの考え方を整理します。
データを持ち出さない安全なアプリ運用について確認していきましょう。
ロールと権限の最小化設計
アプリやテーブルへのアクセスはロールで付与します。
SnowflakeではRBAC（ロールベースアクセス制御：役割に権限を付与する仕組み）で、誰が何をできるかを一元管理できます。
閲覧者、承認者、開発者のように役割を分け、必要最小限の権限だけにすると、アプリが増えても運用が破綻しにくくなります。
閲覧だけのユーザー、更新を行う承認者、アプリを編集する開発者など、役割ごとに最小限の権限だけを与えるのが基本です。
権限はアプリ配布前にチェックリスト化して点検しましょう。
行レベル・列レベルのアクセス制御
部署や顧客単位で見せる行を切り替える行レベル制御、個人情報など特定の列をマスクする列レベル制御を使えば、アプリ側のコードを変えずに統一されたガバナンスを実現できます。
権限の追加や削除にも強く、運用の手戻りを防げます。
監査ログと変更管理
アプリの改修はロールを分けて管理し、バージョンや変更理由を記録します。
データ更新は履歴テーブルと操作ログを整備し、いつでも追跡できる状態にしておくと安心です。
定期的な棚卸し（不要権限の削除）も有効なので、参考にしてみてください。
配布とスケールの考え方
この章では、作ったアプリを「使われる状態」にするための配布とスケール設計を扱います。
多くの現場で詰まるのは、同時接続の性能よりも、部門追加時の権限設計と運用ルールの違いです。
最初から部門共通の参照ビューやポリシーを用意し、部門ごとは最小限の上書きで済む形にすると、横展開が一気に楽になります。
結果として、内製アプリが標準機能として育ちやすくなります。
社内配布のやり方についてチェックしましょう。
社内配布のやり方と権限セット
アプリは所有者が配布先ロールを指定し、閲覧者はリンクからアクセスします。
配布時は「誰が見られてはいけないか」を起点にロール設計を見直し、テストユーザーで実機検証を行うと事故を防げます。
マルチアカウント・部門横断展開
利用部門が増えると、権限の粒度や運用ルールの違いが表面化します。
共通の参照ビューやポリシーを作り、部門ごとに最小限の上書きで済む構成にすると展開が楽です。
必要に応じてアプリをパッケージ化し、標準機能として横展開する戦略も有効です。
同時接続とパフォーマンスの設計
同時アクセスが増えると待ち行列が発生します。
自動スケール（同時に動く計算クラスターを増やす仕組み）を使えば、負荷に応じて処理能力を自動的に拡張・縮小できます。
高負荷の時間帯を想定した負荷試験を事前に行っておくのがコツです。
こんにちは、DX攻略部のkanoです。 「Snowflakeを導入したけど、思ったよりコストがかかっていた」 「もう少しSnowflakeの料金を節約したい」 こういった悩みを持つ方も多いかもしれません。 Snowf[…]
運用とコスト最適化
ここでは運用コストを抑えつつ体感速度を高める方法を紹介します。
Snowflakeの秒課金を味方にし、事前計算や差分更新でムダな再計算を減らし、監視指標で継続的に改善する方法についてまとめました。
ウェアハウスサイズと自動スケール
Snowflakeは秒課金のシステムを採用しています。
そのため、重い集計は短時間だけ大きめのサイズで一気に処理し、使わないときは自動停止する設定にしましょう。
朝会前だけ起動、就業時間外は停止といった運用でムダを削れます。
キャッシュとマテリアライズドビュー
同じ条件のクエリは結果キャッシュで再利用されます。
日々使う重い集計はマテリアライズドビュー（事前計算して保存する仕組み）にして読み取りを高速化します。
ただし更新のたびに再計算コストがかかるため、更新頻度や鮮度要件とバランスを取りましょう。
実行計画の確認と監視指標
遅いクエリは実行計画（どの順序で処理するかの設計図）を確認し、不要な結合や全件スキャンを減らします。
差分更新に適した動的テーブル（基データの変更分だけを反映）を使うと、バッチの無駄が減ってコストも安定するのでおすすめです。
運用監視ではクエリ時間、同時実行、失敗率、キャッシュヒット率などをダッシュボード化しておきましょう。
こんにちは、DX攻略部のmukkukoです。 Snowflakeの導入成功は「導入したかどうか」ではなく、「データサイロ（部門やツールごとにデータが分断される状態）をどう解消し、運用コストやムダな処理コストをどう抑えたか」で決まります[…]
使い分けと共存（BIツールとの比較）
既存のBIレポートとStreamlitアプリをどう住み分けるかを整理します。
Streamlitアプリを導入する際に参考にしてください。
レポートとアプリの境界線
「決まった指標を見せる定型レポート」は既存BIが得意です。
一方で「画面から値を入れて更新する」「承認する」「外部APIと連携する」といった双方向の体験はStreamlitが得意です。
既存BIの横に小さな操作タブを増設する発想で共存させると、移行の負担が小さくなります。
既存BIとの共存アーキテクチャ
指標定義や共通SQLはSnowflakeに寄せ、BIもStreamlitも同じビューや動的テーブルを参照します。
権限はSnowflakeで一元管理し、ツールごとの差分設定を最小限にすると安全です。
これで「同じ数字なのに画面ごとに違う」問題を防げます。
Streamlitを選ぶ判断基準
Streamlitを選ぶ判断基準についても確認しておきましょう。
| チェック項目 | はいの場合の示唆 | 最初の1画面の例 |
|---|---|---|
| 定型レポートだけでなく「入力や更新」も同じ画面でやりたい | BI単体よりStreamlitが向きやすい | 案件一覧＋確度更新フォーム |
| 承認やコメントなど、軽いワークフローがある | 「見る→操作する→流す」を一体化できる | 発注案の承認ボタン＋履歴表示 |
| 要件が頻繁に変わり、改善を短いサイクルで回したい | 小さく作って育てる運用に合う | KPIカードの追加・並び替え |
| データを社外に出したくない（データ持ち出しを避けたい） | Snowflake内で完結する設計が取りやすい | 社内向けダッシュボード＋入力 |
| 権限をツールごとにバラバラ管理したくない | Snowflake側で一元管理しやすい | RBACで閲覧者／承認者を分離 |
Streamlitを選ぶかどうかは、現場が自分で触る前提か、入力や承認などの操作があるか、要件が頻繁に変わるか、そしてデータを社外に出したくないか、といったことが関わってきます。
これらが複数当てはまるなら、SnowflakeとStreamlitを合わせて使うことが第一候補です。
こんにちは、DX攻略部のkanoです。 Snowflakeと連携するBIツール選びは「誰が何をどの頻度で見るか」を固めると迷いません。 また、SnowflakeとBIツールの選定は、「どのツールが高機能か」ではなく「誰がどの指標で意思決[…]
テンプレートで始めるユースケース集
ここでは最初の一歩として取り組みやすいStreamlitアプリ例を示します。
実データに置き換えればすぐに社内で試せる規模感を意識しているので、実際の導入時をイメージしながらチェックしてみてください。
営業パイプライン管理と見込み精度チェック
営業会議で使える、一覧と更新を一体化したアプリでは、案件一覧と進捗を表示し、次アクションや確度をフォームで更新する形がおすすめです。
- deals（案件）
deal_id、account、owner、stage、amount、expected_close_date、probability、next_action、forecast_category、created_at、updated_at - deals_history（変更履歴）
deal_id、changed_at、changed_by、before_stage、after_stage、before_amount、after_amount - deals_outcome（結果）
deal_id、closed_at、result、won_amount
-
期間や担当者のセレクターで条件を受け取り、dealsを集計してステージ別金額と件数を表示します。
-
dealsとdeals_outcomeを突き合わせ、予測金額と実績金額の差分を計算します。乖離率が高い案件にタグを付与します。
-
テーブルの行内編集でnext_actionやprobabilityを更新し、変更はdealsとdeals_historyに書き込みましょう。
-
会議での意思決定を支援するため、選択した案件の詳細カードとメモ欄を表示します。
過去実績との乖離を自動計算して、過大評価の案件にタグ付けすれば、会議での注力先が明確になります。
拡張案として、直近三ヶ月の遷移率から確度の上限値を提示する、といった形も検討してみてください。
在庫アラートと発注支援フロー
欠品と過剰在庫の両方を避ける、現場向けの簡易補充アプリを作成してみましょう。
承認付きの更新で誤操作を防ぐものになります。
-
inventory（在庫）
sku、product_name、category、on_hand、on_order、safety_stock、lead_time_days、updated_at -
demand_daily（日別需要）
sku、date、qty -
purchase_suggestions（発注案）
suggestion_id、sku、suggested_qty、reason、created_by、status（draft、approved、rejected）、created_at、approved_at、approved_by -
purchase_suggestions_history（履歴）
suggestion_id、changed_at、changed_by、before_status、after_status
-
需要の移動平均や季節係数を使い、リードタイム期間の需要予測を計算します。
-
on_handとon_orderを加味して、safety_stockを下回る見込みのSKUを抽出します。
-
推奨発注量を算出してpurchase_suggestionsに下書き保存し、承認者だけがstatusをapprovedに更新できるようロールで制御します。
-
承認済みのみを下流システムに連携する前提で、履歴テーブルへ変更を自動記録します。
安全在庫割れを検知したら、推奨発注量を提示して承認ボタンで確定する形です。
また、承認済みの変更だけを下流システムに渡すことで、誤操作の影響を抑えた運用ができます。
経営ダッシュボードの一画面設計
朝会で数分見ることを想定した、要点集中型の一枚ダッシュボードを作成しましょう。
売上、粗利、在庫回転、採用進捗など主要指標を一画面に集約する形です。
-
kpi_daily（主要指標の日次テーブル）
date、revenue、gross_profit、inventory_turnover、pipeline_amount、new_hires、attrition -
kpi_targets（目標値）
metric、target_ytd、target_mtd -
alerts（注意報）
alert_id、metric、level、message、created_at、status
-
kpi_dailyは動的テーブルやマテリアライズドビューで事前計算し、朝のアクセス集中でも即時表示できるようにします。
-
KPIカードでは対目標と対前年の差を色分けして一目で判断できるようにします。
-
alertsは別ジョブで生成し、レベルに応じて上部にピン留め表示します。
-
役員が気になる数値をクリックすると該当部門の詳細ビューに遷移できる導線を用意します。
重い指標は事前計算で高速化し、朝会の短時間でもサッと使える体験を目指します。
今回ご紹介したものは、「小さく作ってすぐ使う」を重視したテンプレートです。
運用で必要になった項目だけを足していく発想にすると、スピードと品質を両立できますので、ぜひStreamlitアプリを作成する際に活用してみてください。
こんにちは、DX攻略部のkanoです。 Snowflakeの導入や活用を外部コンサルに頼るべきか、どのように契約し何を成果物として受け取り、どんなKPIで評価すればよいか、初めてだと判断が難しいポイントが多いものです。 本記事で[…]
開発の型と品質
SnowflakeとStreamlitを使ったアプリは、作って終わりにしないことが重要です。
そのための、作って終わりにしないための設計と品質のポイントを確認しましょう。
ページ構成・コンポーネント分割・状態管理
一つの画面に機能を詰め込み過ぎると、迷いやすく壊れやすくなるので注意しなければなりません。
画面は「一覧」「詳細」「入力（編集）」の目的で分け、共通パーツは部品化して再利用します。
また、フィルターやヘッダー、アラートバナーなどは共通部品にすると保守が軽くなります。
状態は画面内だけでなく、セッションやURLにも保存しましょう。
例えば選択した期間や担当者をセッションに保持し、URLにも埋めておけば、ページ更新や共有時にも同じ状態を再現できます。
これにより再現テストやレビューがやりやすくなります。
入力バリデーションとエラーハンドリング
入力の検証は「UIで予防」「サーバ側で最終確認」の二段構えにします。
必須項目、数値範囲、日付の前後関係などは画面で即時にエラー表示し、書き込み時はSnowflake側で一意制約や型チェックを必ず行います。
書き込みは小さなトランザクションに分け、失敗しても他へ波及しないようにしましょう。
競合が起きやすい箇所は、更新対象にバージョン列や更新日時を持たせる楽観ロックが有効です。
デザイン原則とアクセシビリティ
見やすさは品質であり、文字の大きさや余白、色の使い方を統一し、情報の優先度に応じて視線誘導を設計しましょう。
ボタンの位置や文言は画面間で揃え、色だけに頼らずラベルやアイコンも併用します。
入力部品には必ずラベルとプレースホルダーを付け、テーブルは列幅と桁区切りを整えます。
キーボード操作や画面リーダーでも使えるよう、フォーカス移動と代替テキストにも配慮すれば、扱いやすいアプリになるのでおすすめです。
こんにちは、DX攻略部のkanoです。 「Snowflakeを導入したいけど、導入先を探す判断材料が欲しい」 「Snowflakeコンサルを依頼する際に、その企業がSalesforceパートナーとなっていたがどういった資格なのか[…]
よくあるつまずきと回避策
ここではSnowflakeとStreamlitを連携して導入する際に起こりがちな課題と対処法をまとめます。
事前によくあるつまずきを確認し、適切に対処できるようにしましょう。
クエリ遅延の切り分け手順
遅いと感じたら、まず「どこが遅いか」を分けます。
クエリ自体が重いのか、同時実行が多く待たされているのか、画面側の再実行が多すぎるのか、の順に確認すると迷いません。
クエリが重い場合は、実行計画（処理順序の設計図）で全件スキャンや不要な結合がないかを見直します。
同時実行が原因なら、ウェアハウスの自動スケールや稼働時間帯の調整が効きます。
更新系処理の整合性とロック対策
画面からの更新は1回の操作で変えるレコードを最小化し、履歴テーブルに変更前後を保存しましょう。
承認済みレコードだけを下流へ流すことで、誤操作の影響を抑え、並行処理時の競合を減らせます。
権限エラーとデータマスキングの落とし穴
「画面が真っ白」「一部の列だけ空になる」場合は、権限やポリシー設定に起因することが多いです。
表示できない行や列があるのは設計通りでも、想定外に真っ白に見える場合は権限の付け先やポリシーの対象がズレていることを疑いましょう。
検証用ユーザーで実機確認し、最小権限で必要十分かを定期点検しましょう。
こんにちは、DX攻略部のkanoです。 企業のDXが進む一方で、「データを見たいのに毎回集計依頼が必要」「スプレッドシート運用が限界」「現場が使える画面が作れない」といった壁にぶつかるケースは少なくありません。 特にエンジニアが[…]
まとめ
Snowflake×Streamlitは、ダッシュボードの可視化から軽量な業務アプリ、簡易ワークフローまでを「データを動かさずに」内製できる実用的な選択肢です。
SQLとPythonを同じ場で使い、RBACや行列レベル制御でセキュリティを保ちながら、現場がその日から使える画面を素早く届けられます。
最初は単一部門の小さな一画面から始めるようにしましょう。
このようにSnowflakeはStreamlitと連携して使うことで、さらに使う幅を広げられるツールです。
そして、DX攻略部では、Snowflake×Streamlitを活用した統合BI基盤構築支援サービスを行っていますので、Snowflake導入を検討している企業様はぜひDX攻略部にご相談ください！
