工場の製造現場であれ、オフィスの管理部門であれ、新しいシステムやダッシュボードを導入しようとしたとき、最も恐ろしい瞬間とは何でしょうか。
それは、数ヶ月かけて開発したシステムを現場にお披露目したとき、「あれ、思ってたのと違うな」「これじゃ使いにくいよ」と言われる瞬間ではないでしょうか。いわゆる「コレジャナイ」問題です。
生産技術の現場において、良かれと思って導入された品質予測や異常検知の分析ツールが誰にも使われず、形骸化してしまうケースは珍しくありません。なぜ、このような悲劇が繰り返されるのでしょうか。
最大の原因は、「動くもの」を見ずに合意形成しようとしていることにあります。
Excelで作った要件定義書や、PowerPointの画面遷移図だけで、現場の担当者が完成形を具体的にイメージするのは困難です。しかし、プロトタイプを作るにはエンジニアのリソースが必要であり、時間もかかります。DX推進担当者が、現場の曖昧な要望と、社内エンジニアの枯渇したリソースの板挟みになっている状況は、多くの製造業で共通する課題です。
そこで有効なアプローチとなるのが、「Streamlit」と「生成AI」を組み合わせた、超高速プロトタイピングです。小さく始めて成果を可視化し、段階的にスケールアップする導入戦略において、非常に強力な手段となります。
Pythonの知識が少しあれば、フロントエンドのコードを一行も書くことなく、AIとの対話だけで「動くダッシュボード」が作成可能です。しかも、会議中にその場で修正できるほどのスピード感を持っています。
この記事では、実務の現場で有効とされている、エンジニアに頼らずに「動く画面」を作り、現場の合意を最速で取り付けるための具体的なフレームワークを解説します。「要件定義が終わらない」「手戻りが怖い」という課題に対し、定量的な効果をもたらす実践的なノウハウとなるはずです。
なぜ「動く画面」がないと要件定義は失敗するのか
DXプロジェクトにおいて、要件定義は最も重要かつ難易度の高いフェーズです。しかし、多くのプロジェクトがここで躓きます。なぜなら、私たちは「言葉」や「静止画」で、動的な体験を定義しようとしているからです。
Excelの要件定義書が現場に伝わらない理由
伝統的なシステム開発では、機能一覧や画面定義書をExcelで作成し、現場担当者に「これで承認お願いします」と判子をもらいに行きます。しかし、専門家の視点から言えば、現場の担当者は、そのExcelを本当の意味では理解していません。
彼らに悪気はないのです。ただ、静的なドキュメントから「ボタンを押した時の挙動」や「データの絞り込みスピード」、「グラフのインタラクティブな動き」を脳内でシミュレーションするのは、訓練されたエンジニアでなければ不可能なのです。
結果として、「承認」は形式的なものになります。そして、いざ完成品が出てきたときに初めて、「このボタンはここじゃない方がいい」「このグラフ、ドリルダウンできないと意味がない」といった、本質的な要望が噴出するのです。
これを防ぐ有効な方法は、初期段階で「触れるもの」を提供することです。「百聞は一見に如かず」と言いますが、システム開発においては「百見は一触に如かず」です。
「とりあえず作ってみる」が最強の合意形成ツールである根拠
ここでStreamlitの出番です。Streamlitは、PythonだけでWebアプリケーションが作れるフレームワークですが、その真価は「爆速で形にできる」点にあります。
製造現場での典型的なケースを考えてみましょう。品質管理部門から「不良率の推移を見たい」という要望があったとします。従来の手法であれば、要件定義に2週間、モックアップ作成に1週間は費やされていたはずです。
しかし、Streamlitを活用した現場では、その場で簡易的なグラフを表示するアプリを30分程度で作成し、「このようなイメージでしょうか？」と提示することが可能です。
実際に動く画面を見せた瞬間、現場の反応は一変します。
「いや、日次じゃなくてシフトごとの推移が見たいんだ」
「この異常値をクリックしたら、その時の設備パラメータが見れると嬉しい」
静的な資料を見せていた時には出てこなかった具体的な要望が、次々と溢れ出てくるのです。動く画面は、ユーザーの思考を刺激し、潜在的なニーズを引き出す触媒として機能します。
従来の開発フローとAI支援型プロトタイピングの工数比較
「でも、プロトタイプを作るにしてもコードを書く必要があるでしょう？」
そう思われるかもしれません。確かに以前はそうでした。しかし、ChatGPTやClaudeの最新モデルをはじめとする生成AIの進化により、状況は劇的に変化しました。
特筆すべきは、最新のAIモデルにおける推論能力とエージェント機能の飛躍的な向上です。以前のモデルでは、人間が詳細な指示を出し、エラーが出れば人間が原因を特定して修正を依頼する必要がありました。しかし、最新のAIは違います。
「製造ラインの異常検知ダッシュボードを作って。データはCSVで読み込む想定で」といった抽象的な指示でも、AIは文脈を理解し、自律的に計画（Plan）を立て、適切なライブラリを選定してコードを実装（Code）します。 さらに、AIエージェント機能の活用により、エラーが発生してもAI自身が原因を分析し、修正案を提示して自己解決するサイクルすら回せるようになりつつあります。あたかも熟練したエンジニアが隣にいて、ペアプログラミングをしているかのような体験です。
また、画像認識機能の強化により、ホワイトボードに描いた手書きの画面ラフをAIに読み込ませ、「これと同じレイアウトのStreamlitアプリを作って」と指示するだけで、瞬時にコード化することも可能です。
従来の手法では、DX担当者が要件をまとめ、エンジニアに依頼し、実装を待ち、レビューするというサイクルで、1つの画面を作るのに数日〜数週間かかっていました。エンジニアのリソース確保自体がボトルネックになることも珍しくありません。
一方、AI支援型プロトタイピングでは、DX担当者自身がAIに対話形式で指示を出し、生成されたコードをStreamlitで実行するだけです。これにかかる時間は数分から数十分というレベルに短縮されています。
- 従来: 要件定義(5日) → 設計(3日) → 実装(5日) → レビュー(2日) = 計15日
- AI×Streamlit: AIへの指示・生成(0.5時間) → 実行・確認(0.5時間) → 修正ループ(2時間) = 計3時間
この圧倒的な時間短縮により、「作って捨てる」ことが許容されるようになります。これが重要です。「間違っていたら捨てればいい」と思えるからこそ、失敗を恐れずに大胆な仮説検証が可能になるのです。
参考リンク
ベストプラクティス①：AIを「専属エンジニア」にするプロンプト設計
ここからは具体的な実践論に入ります。AIにコードを書かせる際、多くの人がやりがちなのが「売上データを表示するダッシュボードを作って」というような、曖昧で短い指示です。これではAIも困ってしまい、平凡で使いにくいコードしか返してきません。
AIを優秀な「専属エンジニア」として機能させるには、コンテキスト（文脈）と制約条件を明確に伝えるプロンプト設計が不可欠です。
要件を構造化してAIに渡す「コンテキスト注入」の型
実務で推奨されるプロンプトの「型」をご紹介します。以下の要素を含めることで、精度の高いStreamlitコードが一発で出力されるようになります。
- 役割定義（Role）: あなたは誰か。
- 目的（Goal）: 何を作りたいのか、誰が使うのか。
- 機能要件（Requirements）: 具体的に何が必要か。
- 技術制約（Tech Stack）: Streamlitを使う、ライブラリは何を使うか。
- データ構造（Data）: どのようなデータを扱うか（ダミーデータの指示も含む）。
具体的なプロンプト例を見てみましょう。
プロンプト例:
あなたは熟練したPythonエンジニアで、Streamlitを用いたデータ可視化の専門家です。
製造業の工場長向けに、日々の生産効率をモニタリングするダッシュボードのプロトタイプを作成してください。【要件】
- サイドバーで「日付範囲」と「ライン（Line A, Line B）」を選択可能にする。
- メイン画面上部に、選択期間の「総生産数」「稼働率」「不良率」をKPIカードとして表示する。
- その下に、時間ごとの生産数推移を折れ線グラフで表示する。
- 不良原因のパレート図を表示する。
【技術制約】
- ライブラリ: streamlit, pandas, plotly.express, numpy
- デザイン: シンプルで見やすいレイアウト。
st.columnsを使って整列させる。- データ: 手元にデータがないため、それらしいダミーデータをコード内で生成して使用すること。
【出力】
- そのまま実行可能なPythonコードのみを出力してください。
- コード内に各処理の解説コメントを入れてください。
このように具体的に指示を出すことで、AIは迷いなく、あなたの意図通りのコードを生成してくれます。ポイントは、「誰が」「何のために」使うかを伝えることです。これにより、AIは文脈を理解し、例えば「工場長向けなら、文字は大きめで重要な数字を強調しよう」といった配慮（推論）をコードに反映してくれることがあります。
Streamlit特有の記法をAIに遵守させる指示テクニック
Streamlitは非常に簡単ですが、いくつか特有の「クセ」があります。特に初心者が躓きやすく、AIも時々間違えるのが「リロード時の挙動」と「ステート管理」です。
Streamlitは、ボタンを押すなどの操作があるたびに、スクリプト全体が上から下まで再実行されます。これを知らないと、「ボタンを押したのに変数がリセットされてしまう」という現象に悩まされます。
これを回避するために、st.session_stateという機能を使いますが、AIにこれを意識させる指示が必要です。
追加指示の例:
- ユーザーの入力内容やフィルタリング結果が、画面更新時にリセットされないよう、必要に応じて
st.session_stateを活用してください。- 重いデータ処理を行う関数には
@st.cache_dataデコレータを付与して、パフォーマンスを最適化してください。
このように、Streamlit特有のベストプラクティスをプロンプトに含めることで、単に「動く」だけでなく、「快適に動く」プロトタイプが得られます。
エラー発生時にAIに自己修正させるデバッグフロー
AIが生成したコードを実行すると、エラーが出ることがあります。ここで焦ってはいけません。DX担当者の皆さんは、自分でエラーログを解読して修正する必要はありません。
エラーが出たら、そのエラーメッセージをそのままコピーして、AIに投げ返すのです。
デバッグ用プロンプト:
以下のエラーが発生しました。原因を特定し、修正したコード全体を再出力してください。
[エラーメッセージを貼り付け]
AIは自分の書いたコードの文脈を持っているので、エラーメッセージを見れば即座に修正案を提示してくれます。「自分で直そうとしない」こと。これが高速プロトタイピングの鉄則です。私たちはコードを書くのではなく、AIという優秀な部下をマネジメントする役割に徹するべきです。
ベストプラクティス②：ダミーデータ生成から始める「逆算」アプローチ
システム開発でよくある遅延理由の一つに、「本番データがまだ準備できていない」というものがあります。「データベースの接続権限がない」「CSVのフォーマットが決まっていない」……。
しかし、プロトタイピングにおいてデータを待つ必要はありません。むしろ、理想的なアウトプット（グラフや表）から逆算して、ダミーデータをAIに作らせるのが正解です。
本番データ接続のリスクを回避するFaker活用術
Pythonには Faker という、リアルなダミーデータを生成するライブラリがありますが、これもAIに任せればコードを書く必要はありません。
AIに対して、「このダッシュボードに必要な、もっともらしいダミーデータを生成するロジックを含めて」と指示すれば、pandas や numpy を駆使してデータフレームを作成してくれます。
例えば、日付、製品名、担当者名、数値データなどをランダムかつ現実的な範囲で生成させます。これにより、セキュリティリスクのある本番データに触れることなく、安全にUI/UXの検証を進めることができます。
「見たいグラフ」から逆算してデータ構造を定義する
この「逆算アプローチ」には、もう一つの大きなメリットがあります。それは、「必要なデータ構造の要件定義」ができることです。
とりあえずダミーデータでグラフを作ってみると、「あれ、このグラフを描画するには、製品ごとのマスタデータが必要だぞ」とか、「この分析をするには、1分間隔のタイムスタンプがないと無理だ」といったことに気づきます。
プロトタイプが完成した時点で、そのコード内で生成しているダミーデータの構造（カラム名、データ型）こそが、システム部門に依頼すべき「データ要件定義書」そのものになります。
「こんなデータください」と口頭で言うよりも、「このStreamlitアプリが動くのと同じ形式のCSVをください」と伝える方が、システム部門にとっても遥かに分かりやすく、誤解が生じません。
AIにダミーデータセットを作らせて即座に可視化する手順
具体的な手順は以下の通りです。
- ゴールイメージの言語化: 「昨対比の売上推移が見たい」など。
- AIへの指示: 「そのグラフを描画するために必要なダミーデータを生成し、可視化するStreamlitコードを書いて」と依頼。
- 確認と調整: 出てきたグラフを見て、「もっと異常値を含めて」「欠損値がある場合の挙動を確認したいから、データを一部抜いて」と追加指示。
このように、データそのものをAIにコントロールさせることで、あらゆるエッジケース（極端な状況）をシミュレーションできます。これは、綺麗な本番データだけを見ていては気づかない不具合を発見するのにも役立ちます。
ベストプラクティス③：現場フィードバックをその場で反映する「ライブ修正」
最も効果的なアプローチの一つとして、会議中に参加者の目の前でAIを使ってアプリを修正する「ライブ修正」が挙げられます。
通常、要望を持ち帰って修正し、後日再レビューとなると、その間に熱量は冷め、記憶も曖昧になりがちです。しかし、その場で修正を行い、即座に確認することで、合意形成のスピードは劇的に向上します。
会議中にAIでコードを修正し、再デプロイするスピード感
プロジェクターにStreamlitの画面と、ChatGPTなどの生成AI画面を並べて映し出すスタイルをお勧めします。ChatGPTの最新モデルでは、コーディング能力に加え、文脈を深く理解する推論能力が飛躍的に向上しており、以前のような試行錯誤の回数が大幅に削減されています。
例えば、次のようなやり取りを想像してください。
現場担当者：「うーん、この円グラフ、割合が分かりにくいから棒グラフにならない？」
あなた：「分かりました、やってみましょう」（ChatGPTに『円グラフを横棒グラフに変更し、数値ラベルを追加して』と入力）
〜 瞬時にコードが生成される 〜
あなた：（コードを適用して保存）「どうですか？更新されました」
現場担当者：「おお！これこれ！これが見たかったんだよ！」
さらに、マルチモーダル機能も強化されています。口頭での説明が難しい場合は、ホワイトボードに描いたラフ図を撮影してAIにアップロードし、「このレイアウトに変えて」と指示するだけで、意図通りの画面構成案を出力させることも可能です。
この体験こそが、信頼構築の鍵となります。「このチームは自分たちの要望をすぐに理解し、形にしてくれる」という信頼感は、プロジェクトを推進する上で何物にも代えがたい資産となります。
インタラクティブ機能（フィルタ、ドリルダウン）の実装パターン
現場からの要望で特に多いのが、「絞り込みたい」「詳細を見たい」というインタラクションに関するものです。
これらもStreamlitなら st.multiselect（複数選択）や st.dataframe（インタラクティブな表）を使うだけで実装可能ですが、AIに指示する際は「どのデータがどう連動するか」を明確にします。
現在の生成AIは、複雑な依存関係やロジックの推論にも長けています。「サイドバーで工場を選択したら、メイン画面のグラフだけでなく、下部の詳細テーブルも連動してフィルタリングされるようにして」と自然言語で指示すれば、AIは適切なフィルタリングロジックを正確に構築します。
「これじゃない」と言われた時のピボット戦略
ライブ修正をしていると、根本的に方向性が間違っていることに気づくこともあります。「そもそもグラフじゃなくて、アラートのリストだけあればいいんだよ」といったケースです。
そんな時も、AI活用なら痛手がありません。「分かりました、では一度グラフは全部消して、アラートリストに特化した画面を作り直します」と、ゼロからコードを生成させれば良いのです。
人間が手書きでコードを書いていたら、数日分の作業を捨てることに抵抗感（サンクコストバイアス）が生まれますが、AIに書かせたコードなら惜しくありません。この「心理的軽さ」こそが、正しい要件に最短距離で辿り着くための重要な要素なのです。
陥りやすい罠：プロトタイプをそのまま本番運用してはいけない
ここまで、StreamlitとAIによるプロトタイピングの素晴らしさを語ってきましたが、専門家として一つだけ、強く警告しておかなければならないことがあります。
それは、「プロトタイプをそのまま本番システムとして運用し続けてはいけない」ということです。
Streamlitのパフォーマンス限界とセキュリティリスク
Streamlitはプロトタイピングには最強ですが、大規模な本番運用には向いていない側面があります。
- 処理速度: 毎回スクリプト全体を再実行する仕組み上、アクセスが集中したり、データ量が数百万行を超えたりすると、動作が重くなります。
- セッション管理: 複雑なユーザー権限管理や、状態保持が必要な業務アプリには不向きです。
- セキュリティ: 簡易的な認証機能は追加できますが、エンタープライズレベルの堅牢なセキュリティを担保するには、別途構成が必要です。
現場が「これでいいじゃん、このまま使おうよ」と言ってくることがよくありますが、そこで安易に頷いてはいけません。それは将来的な「技術的負債」になります。
「とりあえずこれでいい」が生む技術的負債
プロトタイプのコードは、あくまで「見た目と動き」を確認するためのものであり、保守性や拡張性は考慮されていません（AIもプロトタイプと言えばそのように書きます）。
これを無理やり使い続けると、データが増えた途端に動かなくなったり、機能追加が困難になったりして、結局作り直すことになります。
プロトタイプから本番開発へ引き継ぐためのドキュメント化
では、どうすればいいのか。プロトタイプが承認されたら、それを「動く仕様書」としてエンジニアに渡すのです。
「要件はこのアプリの通りです。この挙動を、ReactとFastAPIを使って、セキュアでスケーラブルな構成で実装してください」と依頼しましょう。
エンジニアにとっても、曖昧な日本語の仕様書を渡されるより、動くコード（ロジックの参考になる）と画面がある方が、遥かに開発しやすいはずです。Streamlitで作ったロジック（データの加工処理など）は、そのままバックエンドの開発に流用できることも多く、本番開発の工数削減にも寄与します。
導入効果の測定：開発期間短縮と満足度向上
最後に、この手法を導入することでどれだけの効果が見込めるのか、一般的な導入事例における定量的な数値をご紹介します。
要件定義期間の短縮率
適切に導入した場合、従来2ヶ月かかっていた要件定義フェーズが、2週間前後に短縮される（約75%削減）事例も存在します。
最初の数日間で集中的にプロトタイプを作成・修正し、残りの期間で詳細を詰めるというスタイルに変えることで、無駄な持ち帰り検討や、書類作成の時間が大幅に削減されるためです。
手戻り発生回数の削減実績
さらに重要なのが、開発後の手戻りです。動く画面で合意形成を行うため、本番開発後に「イメージと違う」と指摘されるリスクは極めて低くなります。
発生する修正要望も、「実際にデータを入れてみたら傾向が変わったので、閾値を調整したい」といった、前向きなチューニングに関するものが中心となります。
ビジネス部門とIT部門の共通言語化
定性的な効果として、ビジネス部門（現場）とIT部門（エンジニア）の間に「共通言語」が生まれることが挙げられます。
Streamlitの画面を挟んで会話することで、現場は「データの見せ方」について具体的に語れるようになり、エンジニアは「現場の業務フロー」を直感的に理解しやすくなります。この信頼関係の構築と継続的な改善のサイクルこそが、スマートファクトリー化やDXを成功させる最大の基盤となります。
まとめ
「現場の合意が得られない」「エンジニアリソースが足りない」。そんな悩みを抱えるDX担当者にとって、Streamlitと生成AIは最強の武器です。
- AIへの明確なプロンプトで、コードを書かずにアプリを作る。
- ダミーデータからの逆算で、データ整備を待たずに検証する。
- ライブ修正で、その場で現場の心を掴む。
この3つのステップを実践すれば、プロジェクトの推進力は劇的に向上します。まずは、次の会議に向けて、小さなプロトタイプを一つ、AIと一緒に作ってみてはいかがでしょうか。小さく始めて成果を可視化するアプローチから、継続的な改善のサイクルは始まります。
コメント