LASSIC Media らしくメディア
Streamlit入門｜社内データアプリの内製手順
LASSIC IT事業部｜元請（プライムベンダー）としてシステム開発・検証を受託
データ分析や機械学習モデルの検証結果を、Excelやスライドではなく画面上で触れる形で社内共有したい――。データ部門や情報システム部門から、こうした相談を受ける機会が増えています。分析結果をグラフやテーブルで確認できる簡易ダッシュボードや、モデルの入出力を試せる検証用アプリは業務改善に直結しやすい一方、「Webアプリを作る」と聞くとフロントエンドエンジニアの確保が必要だと身構え、着手をためらう企業も少なくありません。
こうした場面で選択肢になるのが、Streamlitというオープンソースの軽量Webアプリフレームワークです。HTML・CSS・JavaScriptの知識がなくても、Pythonのスクリプトを上から書いていくだけで、データフレームの表示やグラフ、入力ウィジェットを備えた画面を組み立てられる点が特徴です。本記事では、Streamlitの基本的な機能と、社内向けデータアプリを内製で始める手順、内製と外部委託の判断軸を整理します。
なお本記事は、Pythonが書けるデータ担当者を想定読者に、Streamlitというツールを使った内製の手順に主題を絞ります。業務システムのCRUD画面を作る汎用ノーコードツールや、GUI操作中心のBIダッシュボードツール一般論とは狙いが異なるため、本記事では扱わない方針です。あくまでPythonスクリプトでデータ・機械学習系の社内アプリを素早く形にする方法に焦点を当てます。
この記事のポイント
- Streamlitは、Pythonスクリプトだけでデータフレーム表示・グラフ・入力ウィジェットを備えた画面を組み立てられるオープンソースのWebアプリフレームワークです。
- st.dataframeやst.line_chartといった関数、キャッシュ機能、セッション状態を組み合わせることで、Pythonが書けるデータ担当者が分析結果やMLモデルの検証画面を短いコードで内製しやすくなります。
- 内製と外部委託は二者択一ではなく、業務の複雑さやセキュリティ要件に応じて使い分ける判断軸を持つことが実務上のポイントです。
目次
Streamlitとは何か：Pythonスクリプトでデータアプリを組み立てられる仕組み
Streamlitは、データ分析や機械学習の結果を画面として素早く形にするための、オープンソースのPythonフレームワークです*1。HTML・CSS・JavaScriptを書く代わりに、Pandasのデータフレームを扱うのと同じ感覚でPythonのコードを上から書いていくと、それがそのままブラウザ上のWebアプリになる点が大きな特徴です。ウィジェットの値が変わると、スクリプト全体が上から再実行され画面が更新されるという、独自の実行モデルを採用しています*1。
提供形態は大きく分けて二つあります。一つはStreamlit社が運営するCommunity Cloud（クラウド版）で、GitHubのリポジトリと連携させるだけでアプリを公開できます*2。もう一つは、ライブラリ自体はオープンソースであるため、社内のサーバーやコンテナ環境にセルフホストする形態です。どちらを選ぶかは、扱うデータの機密度や社内の運用体制によって変わってきます。
想定する利用者像：Pythonが書けるデータ担当者
Streamlitが力を発揮するのは、分析やモデル構築のためにすでにPythonを日常的に使っているデータ担当者が、その延長で画面を作る場面です。GUI操作でアプリを組み立てるローコードツールとは異なり、Streamlitはコードを書くことが前提のツールです。逆に言えば、Pythonのコードを書けない担当者だけで内製・保守を回すのは難易度が上がるという前提を押さえておく必要があります。なお、対応バージョンや料金プランなどの詳細は執筆時点の情報であり、最新の仕様は公式サイトで確認することをおすすめします。
Streamlitでできること：向くケース・向かないケース
Streamlitには、データアプリの画面を構成するための関数群が用意されています。代表的なものを整理すると、次のとおりです*2。
| 機能カテゴリ | 代表的な関数 | できること |
|---|---|---|
| データ表示 | st.dataframe／st.table | Pandasのデータフレームを表としてそのまま表示する |
| グラフ | st.line_chart／st.bar_chart等 | 推移や分布を簡易なグラフとして描画する |
| 入力ウィジェット | st.slider／st.selectbox／st.file_uploader | パラメータ変更やファイルアップロードをユーザーに操作させる |
| レイアウト | st.sidebar／st.columns／st.tabs | 画面をサイドバーや列・タブに分けて整理する |
| 状態管理 | st.cache_data／st.cache_resource／st.session_state | 再実行のたびに重い処理を繰り返さないよう結果を保持する |
これらを組み合わせると、CSVを読み込んでフィルタ条件をウィジェットで変更し、結果をグラフとテーブルで確認する画面を数十行程度のスクリプトで組み立てられます。GUI設定でグラフを組むBIダッシュボードツールとの違いは、コードでロジックを自由に書ける点にあります。
向くケース・向かないケース
これまでの特徴を踏まえると、Streamlitが向くケースと、無理に使うと苦労しやすいケースは次のように整理できます。
- 向くケース――社内向けの簡易分析ダッシュボード、MLモデルの検証・デモ画面、少人数で使うデータ確認ツール、企画段階のプロトタイプ
- 向くケース――既存のPythonの分析コードやモデルを、そのまま画面に転用したい場合
- 向かないケース――多数の利用者が同時にアクセスする基幹系や、複雑なトランザクション処理を伴う業務システム
- 向かないケース――対外向けサービスのように、独自性の高いUI／UXを細部まで作り込む必要がある場合
- 向かないケース――Pythonを書けない担当者だけで、長期的な保守を回さなければならない体制
社内データアプリの内製ユースケース
社内向けという文脈でStreamlitの活用が検討されやすい用途を整理すると、次のようなパターンが挙げられます。
- 分析ダッシュボード――売上や稼働状況などの集計データを、部門内で日次・週次に確認する簡易画面
- MLモデルの検証・デモ――構築した予測モデルに実データを入力し、出力結果をその場で確認できる画面
- データ品質チェックツール――取り込んだデータの欠損や異常値を一覧・グラフで確認し、担当者が目視で点検する画面
- 簡易シミュレーションツール――パラメータをスライダーなどで変更し、試算結果を即座に確認できる画面
共通するのは、いずれもすでにPythonで書かれた分析コードやモデルを、「一人で見て終わり」から「関係者と画面越しに共有する」段階に引き上げる用途だという点です。分析コードが整理されていない場合は、内製の難易度が上がりやすくなります。
Streamlitで内製を始める6つのステップ
社内向けデータアプリを内製する際の大まかな流れを整理すると、次の6ステップになります。
ステップ1〜3：課題とデータ確認から読込・整形まで
最初に取り組むのは、誰に何を共有したいのかという課題と、その元になるデータの所在を確認する工程です。すでにPythonで分析している集計結果やモデルがあれば、それが最も着手しやすい題材になります。次に、pipコマンドでStreamlitをインストールし、手元のPython環境で開発を始められる状態を整える流れです。課題とデータが固まったら、Pandasなどで表示用にデータを読み込み・整形する段階に進みます。
ステップ4〜6：UIの記述から動作確認、社内共有まで
データの準備ができたら、st.dataframeやst.line_chartで表とグラフを表示し、必要に応じてst.sliderやst.selectboxといった入力ウィジェットを組み込んでいきます。ここまで書けたら、streamlit runコマンドでローカルにアプリを起動し、実際の画面表示や操作時の挙動を確認する工程です。表示や動作に問題がなければ、認証やアクセス範囲の設定を行ったうえで、対象の部門・利用者に共有します。
この一連の流れは、慣れれば数十行程度のスクリプトで最初のバージョンを組み立てられる手軽さが特徴です。ただし、社内共有に耐える画面にするには、次の共有・認証まわりの検討も欠かせません。
共有・認証・デプロイの勘所
ローカルで動くところまで作れても、社内にセキュアに公開するには別の観点が必要になります。押さえておきたい主な論点は次のとおりです。
- デプロイ先の選択――Streamlit Community Cloudを使うと、GitHubリポジトリと連携させるだけで比較的手軽に公開できます*2。一方、機密度の高いデータを扱う場合は、自社サーバーやコンテナ基盤へのセルフホストも選択肢になります。
- アクセス制御・認証――公開範囲を限定したい場合、アプリ側でのユーザー認証や、社内ネットワーク経由でのみアクセスできるようにする構成など、認証・アクセス制御の設計を別途行う必要があります。認証まわりの具体的な機能や提供条件は執筆時点でも変化があり得るため、公式ドキュメントで最新情報を確認することが望ましいです。
- Snowflakeとの関係――Streamlitは提供元がSnowflake傘下となっており、Snowflake環境上でアプリを動かす形態も用意されています*1。社内基盤にSnowflakeを使っていれば、その配下での運用も選択肢になります。
- パフォーマンスとキャッシュ設計――重いデータ読込やモデル推論を毎回実行しないよう、st.cache_dataやst.cache_resourceで結果を保持する設計を検討します。
- 運用体制――公開後も利用状況を確認し、データ更新やライブラリのバージョン変更に追随できる担当を決めておくことが望ましいです。
セキュリティ面では、セルフホストなら自社管理下でデータを扱える一方、サーバーの運用・保守負荷は自社で負います。Community Cloudは公開の手軽さが利点ですが、機密度の高いデータでは利用条件を事前に確認しておく必要があるでしょう。
内製と外部委託の判断軸
Streamlitのようなフレームワークがあることで、社内向けデータアプリの多くは内製できる可能性が広がりました。ただし、すべてを内製すべきとは限らないというのが実情です。内製と外部委託のどちらが適するかは、次のような観点で整理できます。
| 観点 | 内製が向くケース | 委託を検討したいケース |
|---|---|---|
| 業務の複雑さ | 既存のPythonコードを画面に転用すれば完結する用途 | 複数システムとの連携や独自の業務ロジックが多い用途 |
| 社内のリソース | Pythonを書けるデータ担当者が時間を割ける | Pythonが書ける担当者が他業務と兼務で確保しにくい |
| セキュリティ要件 | 自社基準での運用体制を整えられる | 監査対応や契約上の要件が厳格で専門知識が必要 |
| スピード感 | 小さく試してから広げたい | 多数利用者を前提に早期に安定稼働させる必要がある |
内製から始め、利用範囲が広がった段階で基幹部分を外部パートナーに委託する、あるいは委託で土台を作ってから運用ノウハウを社内に移す進め方も現実的です。LASSICのような元請会社は、こうした組み合わせについても中立的な立場でご相談に応じられます。
内製でつまずきやすい点と対策
Streamlitを使えば専門のフロントエンドエンジニアがいなくても着手しやすくなる一方、内製ならではのつまずきも存在します。実務でよく見られるパターンは、次のようなものです。
- 再実行モデルを理解しないまま重い処理を書き、操作のたびに画面が固まる――st.cache_dataなどのキャッシュ機能を使い、重い処理を再実行しない設計に見直すことが有効です
- 作った担当者しかコードの構造を理解しておらず、異動すると保守できなくなる――コードにコメントを残し、簡単な設計メモを共有しておく必要があります
- 公開後の利用状況を誰も確認せず、データが古くなっても放置される――定期的な見直しの担当と頻度をあらかじめ決めておくとよいでしょう
- 認証設定を後回しにしたまま社内に共有し、想定外の範囲から機微データにアクセスできてしまう――公開前にアクセス範囲と認証方式を明確にしておくことが欠かせません
いずれも、Streamlit自体の機能不足というより体制側の準備不足が原因になりやすい点です。手軽に作れるツールだからこそ、運用ルールを最初に決めておくことが失敗を避ける近道です。
まとめ：Streamlitは内製の選択肢を広げるツール
本記事では、Streamlitを使った社内データアプリの内製について、基本機能から始め方の手順、共有・認証の勘所、内製と委託の判断軸までを整理しました。Streamlitは、st.dataframeやst.line_chartといった関数、入力ウィジェット、キャッシュ機能をPythonスクリプトの中で組み合わせられる点が特徴で、Pythonが書けるデータ担当者であれば内製に着手しやすいフレームワークです。
一方で、内製がすべての場面に適するわけではありません。業務の複雑さやセキュリティ要件、社内リソースの状況を踏まえて、内製と外部委託を使い分ける判断軸を持つことが、社内データアプリを継続的に活用していくための土台になります。
よくある質問
Streamlitは無料で使えますか。
ライブラリ自体はオープンソースとして公開されており、無料で利用できます*1。クラウド版のCommunity Cloudにも無料枠が用意されていますが、プランや条件は変更される可能性があるため、詳細は公式サイトの最新情報を確認することをおすすめします。
Streamlitの利用にプログラミングの知識は必要ですか。
はい、Pythonでスクリプトを書くことが前提のツールです。GUI操作中心のノーコードツールとは異なり、Pandasなどでのデータ加工を含めてPythonの知識が必要になります。すでにPythonで分析やモデル構築を行っている担当者であれば、その延長として扱いやすいでしょう。
MetabaseやSupersetなどのBIツールと何が違いますか。
MetabaseやSupersetは、GUI操作を中心にダッシュボードを組み立てるBIツールです。一方Streamlitは、Pythonのコードで画面のロジックを自由に書ける点が異なり、既存の分析コードやMLモデルをそのまま画面に転用したい場合や、独自の入力ウィジェットを組み込みたい場合に向いています。どちらが適するかは、GUI設定で足りるか、コードでの柔軟性が必要かで判断するとよいでしょう。
Community Cloudとセルフホストは、どちらを選ぶべきですか。
公開の手軽さを優先するならCommunity Cloudが検討しやすい一方、扱うデータの機密度が高い場合や社内ネットワーク内に閉じた運用が必要な場合は、自社サーバーへのセルフホストが選択肢になります。どちらも一長一短があるため、データの機密度と運用体制の両面から検討することが望ましいです。
内製と外部委託は、どちらから始めるべきですか。
既存のPythonコードを画面に転用すれば完結しそうな用途であれば、内製から小さく試すのも一つの方法です。複数システムとの連携やセキュリティ要件が厳格な用途、あるいはPythonを書ける担当者を確保しにくい場合は、外部パートナーへの相談も選択肢に入れるとよいでしょう。
著者：テレリモ総研編集部 鈴木 亮佑
システム開発・内製化のご相談はLASSICへ
元請（プライムベンダー）として、Streamlitを使った社内データアプリの内製支援から、複雑な要件のシステム開発までご提案します。まずはお気軽にご相談ください。
ご不明な点はお問い合わせフォームからもご連絡いただけます。
- *1 出典：Streamlit公式サイト（https://streamlit.io/）
- *2 出典：Streamlit Documentation（https://docs.streamlit.io/）
