💨
製造現場の隙間時間で、Next.jsダッシュボードを作った話

2025/10/29に公開
ダイカストマシンが製品を作ってる間、2〜3分くらい待つ時間があるんですよ。製造現場にいると、この「サイクルタイム」っていう隙間時間が1日に何回も訪れます。
普通、この時間って何もできないんです。機械が止まるのを待つだけ。
でも、Cursorを使い始めてから、この隙間時間が開発時間になりました。
サイクルタイムの隙間にPCを開く → Cursorに「この関数を実装して」って指示を入力 → 機械が止まる → 製品を取り出して、次の作業 → また隙間時間 → PCを開くと、コードができてる。
これを2ヶ月間繰り返して、Next.jsでダッシュボードを作りました。
この記事では、小規模製造業でゼロからダッシュボードを作った話を、技術選定から失敗談、Cursor活用まで、正直に書きます。

 なぜNext.jsを選んだのか最初、素のReactも検討したんです。
でも、Next.jsを選んだ理由は単純で、App RouterでAPIを作りたかったから。
小規模な製造業だと、フロントエンドとバックエンドを別々に作る余裕がない。人員もいないし、時間もない。Next.jsなら、同じフレームワークの中で両方作れる。これが決め手でした。
あと、モダンで知っていたっていうのもあります。正直、これはでかい。
SSR（サーバーサイドレンダリング）は使ってません。クライアントサイドレンダリングが中心です。だって、リアルタイムでデータを更新したいだけなので、SSRは不要だったんですよね。
技術選定って、理論的に完璧な選択をする必要はなくて、「自分が知ってる技術で、やりたいことができるか」が一番大事だと思います。

 最初のダッシュボードが失敗した理由正直に言います。最初に作ったダッシュボードは、複雑すぎて使われませんでした。
何を作ったかというと：
温度チャート（複数の温度データをグラフ化）
生産性統計（平均サイクルタイム、総ショット数とか）
Rechartsを使った凝ったグラフ
「データ可視化といえばグラフでしょ！」って思って、一生懸命作ったんです。
初回リリースまで2ヶ月かかりました。1日4時間くらい作業して。
で、社長に見せたら、「これいらない」って。
あ、そう...ってなりましたね。
社長が見たいのは、リアルタイムの状態だけだったんです。グラフは見ない。温度の推移とか、平均サイクルタイムとか、そういう統計データも見ない。
必要なのは：
今、何の製品を作ってるか
ショット数（何個作ったか）
サイクルタイム
圧力
機械が動いてるか、止まってるか
たったこれだけ。
失敗から学んだのは、「現場が本当に必要な情報だけを可視化する」ってこと。複雑な機能は不要で、シンプルな表形式 + リアルタイム更新に特化すれば良かったんです。
大幅改訂に1週間かけました。チャート機能を全削除して、シンプルな表形式に変更。これでパフォーマンスも約60%改善しました。
改訂後、社長から「これなら使える」って言われて、やっとホッとしました。

 使った技術スタックシンプルにいきます。
フロントエンド：
Next.js 14（App Router）
TypeScript（厳密な型チェック有効）
Tailwind CSS（ユーティリティファースト）
date-fns（日付処理）
バックエンド：
Next.js API Routes
SQLite（データベース）
使わなかったもの：
Redux、Zustand → React標準のuseStateで十分でした
Recharts → 実用性の観点から削除
状態管理ライブラリは入れてません。小規模なダッシュボードなので、useStateとuseEffectだけで事足りました。
レイヤードアーキテクチャは採用しました。データアクセス層を分離することで、コードの保守性が上がりましたね。後から機能を追加する時に楽でした。

 Cursorを使った「隙間時間開発」ここが一番伝えたいところです。
製造現場で開発するって、普通じゃないんですよ。開発環境がないし、集中できる時間もない。
でも、Cursorを使えば、隙間時間が開発時間になります。
具体的な開発の流れ：
ダイカストマシンが製品を作ってる間（2〜3分）、PCを開く
Cursorに指示を入力：現在記載されているコーディング規約に基づき仕様書に照らし合わせた実装をお願いします。
今回のタスクでは、〇〇機能の××コンポーネントに関して実装してください。
ただし実装後必ずlinter errorが発生していないか確認し、
またbuildが問題なく通ることを確認してください。

作業開始前に以下を徹底してください：
1. 不明点や曖昧な要素は必ず事前確認する
2. 確認完了後、作業手順と最終成果物を具体的に示す
3. 私の承認を得てから作業を開始する

推測での作業進行は禁止します。
機械が止まる → 製品を取り出して、次の作業
また隙間時間 → PCを開くと、コードができてる
動作確認 → 問題なければ次のタスクへ
Cursorは、コンポーネント生成、デバッグ、型定義、コード修正、全部やってくれました。
開発期間は、初回リリースまで2ヶ月。大幅改訂（チャート削除）は1週間。
正直、Cursorがなかったら、製造現場にいながら開発するのは無理でした。
隙間時間って、本来は何もできない時間なんです。でも、Cursorを使えば、その時間が開発時間に変わる。これが一番の収穫でした。

 実装で工夫した点技術的な話を少し。
1. データ取得の最適化
30秒間隔で自動更新（ポーリング方式）にしました。WebSocketは使ってません。理由は単純で、ポーリングの方がシンプルだったから。
並列データ取得にはPromise.allを使いました。複数のデータを同時に取得することで、待ち時間を短縮。
const [monitorData, productInfo, alarms] = await Promise.all([
  MonitorDataAccess.getLatestMonitorData(),
  ContinuousOperationAccess.getLatestProductInfo(),
  AlarmDataAccess.getLatestAlarms()
])
2. レスポンシブデザイン
Tailwind CSSで、モバイル対応しました。社長がスマホで見ることもあるので。
<div className="grid grid-cols-1 md:grid-cols-2 lg:grid-cols-4 gap-4">
  {/* 1列→2列→4列に自動調整 */}
</div>
画面サイズに応じて、1列、2列、4列に自動で変わります。
3. エラーハンドリング
データベース接続エラー、機器接続切断、ユーザーへのエラー表示、この辺りは結構丁寧にやりました。
最新データが5分以上前なら「接続切断」とみなす、みたいなロジックも入れてます。

 苦労した点一番苦労したのは、NASへのデプロイでした。
next.jsのモジュール関係でエラーが出るんですよ。.node_modulesと.nextを含めてアップロードすると、エラーになる。
正解は、これらを含めずにアップロードして、テラタームでnpm installしてからnpm run devで動作確認。スタート・ストップスクリプトは、テラターム内で作成すること。
これに気づくまで、3日くらい悩みました。
あと、データベースからの値の読み取りも大変でしたね。SQLiteのデータ構造を理解して、複数テーブルを並列取得するのに時間がかかりました。
それと、pingの応答がない問題。Wi-Fi接続切れが原因だったんですが、設備の再起動で復旧しました。
手順書を作って、今後同じ問題が起きないようにしましたが、正直、トラブルシューティングは毎回ドキドキします。

 現場の反応と運用社長が一番使ってます。
よく見られている画面は、ダッシュボード（全体俯瞰）とショット管理。
「リアルタイム更新が便利」って言われました。今まで手作業で集計してた時間が不要になったので、確実に楽になったそうです。具体的に何時間削減できたかは不明ですが、「正確な情報を見れるので信頼性がある」って評価をもらいました。
これが一番嬉しかったですね。

 まとめ：小規模製造業でのDX推進のポイント最後に、学んだことをまとめます。
1. 現場が本当に必要な情報だけを可視化する
複雑な機能は不要です。グラフも統計も、使われなければ意味がない。シンプルで速いダッシュボードが一番使われます。
2. 生成AI時代の開発スタイル
製造現場の隙間時間が、開発時間になる。Cursorを使えば、一人でも十分なシステムが作れます。
3. 失敗を恐れない
最初のダッシュボードは失敗しました。でも、その失敗があったから、シンプルで使いやすいダッシュボードが作れた。失敗は学びの機会です。
小規模製造業でのDX推進は、大企業とは違います。人もいないし、予算もない。でも、生成AIを使えば、一人でも戦えます。
もしあなたが同じような状況なら、まず小さく始めてみてください。完璧を目指さず、現場が使える最小限の機能から。
それが、一番の近道だと思います。
なぜNext.jsを選んだのか

最初のダッシュボードが失敗した理由

使った技術スタック

Cursorを使った「隙間時間開発」

実装で工夫した点

苦労した点

現場の反応と運用

まとめ：小規模製造業でのDX推進のポイント

Discussion
