Minerva Consulting AI & データエンジニア

業務の高速化・効率化の考え方と実装例

製造装置の稼働状況を“1行ログ”から読み解く

SQL 考え方・設計

― SQL MID関数によるリアルタイム分析の基本 ―

製造装置は「1行のテキスト」で状態を語っている

製造現場では、多くの装置が稼働状況を
「項目＝値」形式のテキストログとして出力しています。

これは、以下のような装置でよく見られる形式です。

  • チップマウンター

  • 画像検査装置

  • 液体製造装置
    　（材料投入、攪拌、温度・圧力制御、製造完了工程 など）

ログの例は、次のようなイメージです。

 
TIME=10:31,TEMP=72.5,PRESS=1.1,MIX=ON,MATERIAL=A_OK

人が読めば意味は分かりますが、
このままではシステムでの分析や監視は困難です。

製造装置ログの特徴と課題

この形式のログには、次のような特徴があります。

  • 項目名＝値 が連続して並ぶ

  • 並び順が装置やタイミングで変わることがある

  • すべてが 1つのテキストとして出力される

  • 装置メーカーや機種ごとに微妙に形式が異なる

その結果、

「ログは大量にあるが、
稼働状況をリアルタイムに把握できていない」

という状態に陥りがちです。

リアルタイム分析に必要なのは「切り出す力」

製造装置のリアルタイム分析で、
最初に必要になるのは高度なAIではありません。

**まず必要なのは、
長いテキストの中から“意味のある値だけを取り出すこと”**です。

  • 温度は今いくつか

  • 圧力が規定値を超えていないか

  • 攪拌状態は ON か OFF か

これらを即座に判定できる形に変換することが重要です。

SQL MID関数の役割

SQL の MID関数は、

文字列の「指定した位置」から
「指定した長さ」だけを取り出す

ための関数です。

製造装置ログ解析では、
この MID 関数を使って、

  • TEMP の値だけを取り出す

  • PRESS の数値だけを抽出する

といった処理を実現できます。

高度な解析の前段として、
装置の状態を“数値として扱える形”にする
その入口を担うのが MID 関数です。

試薬製造装置における活用イメージ

液体を扱う試薬製造装置では、

  • 温度

  • 圧力

  • 攪拌状態

  • 材料投入の有無

といった条件のわずかな差が、
製造品質や安定稼働に影響します。

ログを解析し、

  • 異常が起きる「前兆」を捉える

  • 条件変化をリアルタイムに可視化する

そのための基礎技術として、
文字列解析は非常に重要です。

まとめ

  • 製造装置は 1行のテキストで多くを語っている

  • リアルタイム分析の第一歩は「必要な値の切り出し」

  • SQL MID関数は、そのシンプルで強力な手段

製造装置ログを
「保存するだけのデータ」から
「判断に使えるデータ」へ変えるために、
MID関数は今も現場で活躍しています。

【参考】SQL-MID関数の実例

www.mitech.work

 

トップページへ

https://www.mitech.work/top

RPAだけではない業務自動化の選択肢

Batch

― Windowsバッチで実現する“軽量・確実”な自動化 ―

（副題）
Power Automate や UiPath 以前に、Windows標準機能でできること

はじめに（業務視点）

業務の自動化というと、
RPA（UiPath、Power Automate など） を思い浮かべる方が多いと思います。

確かに、
・画面操作をそのまま自動化できる
・非エンジニアでも扱いやすい
という点で、RPAは非常に有効な手段です。

一方で、現場ではこんな声もよく聞きます。

  • 処理が重い、実行が遅い

  • ちょっとした改修でもツール依存が強い

  • サーバー常駐やライセンス管理が負担になる

「目的は自動化・高速化であって、RPAそのものではない」
そう考えると、別の選択肢も見えてきます。

自動化は RPA だけではない

RPAは

Robotic Process Automation
＝ 人の操作を模倣する自動化

です。

それに対して、
Windowsバッチ（Batchファイル） は

  • OSレベルでの処理制御

  • ファイル操作・通信・ログ管理

  • 他プログラムとの連携

といった、裏方の自動化を得意とします。

つまり、

観点 RPA バッチ
主用途 　人の操作の自動化 　処理そのものの自動化
実行速度 　比較的遅い 　非常に高速
実行環境 　専用ツール 　Windows標準
安定性 　UI変更に弱い 　影響を受けにくい

業務によっては、
RPAよりバッチの方が“正解” というケースも少なくありません。

バッチプログラムでも、ここまでできる

このページで紹介するのは、
IoTデータ送信を想定した Windowsバッチによる自動化例です。

ポイントは次の2点です。

① 定期実行（Windowsタスクスケジューラ）

  • 毎日／毎時／指定時刻に自動起動

  • サーバー常駐不要

  • OS標準機能のみで構成可能

② トリガー実行（ファイル検知）

  • 特定フォルダにファイルが追加されたら実行

  • 人の操作を介さず、完全自動処理

  • センサー・装置・外部システムとの連携に向いている

この 「定期 × トリガー」の組み合わせ により、

  • データ収集

  • 加工

  • 外部送信

  • ログ保存

といった一連の処理を、安定して高速に自動化できます。

業務的な効果

業務視点で見ると、次のような効果があります。

  • 処理時間の短縮（人手・画面操作ゼロ）

  • 夜間・無人運用が可能

  • トラブル時の切り分けが容易（ログが明確）

  • RPA導入前の「下支え」として使える

  • RPAでは重すぎる処理をオフロードできる

特に、
「すでに目的は明確で、UI操作が不要な処理」
では、バッチは今でも非常に有効です。

RPAとバッチは“対立”ではなく“使い分け”

重要なのは、
RPAか、バッチか、どちらか一択にしないことです。

  • 人が行っている定型操作 → RPA

  • 裏で回る処理・データ連携 → バッチ

  • 両者を組み合わせて全体最適

こうした設計ができると、
自動化は「ツール導入」ではなく
業務改善の仕組みになります。

まとめ

  • 自動化は RPA（UiPath, Power Automate など）だけではない

  • Windowsバッチでも、強力で安定した自動化が可能

  • 目的はツール導入ではなく、業務の高速化・省力化

  • 技術を知っていると、選択肢が増える

この考え方は、
Power Automate の活用を検討する際にも、
設計の質を一段引き上げてくれます。

【参考】－バッチ開発　例　ー

www.mitech.work

トップページへ

https://www.mitech.work/top

設計書・設計変更説明を 「読む側が理解できる文章」にするために AIをどう使うか

AI

【このページの対象】

このページは、次のような立場の方を想定しています。

  • 情報システム部門の開発者・担当者

  • IT開発 / 製品開発プロジェクトのメンバー

  • 技術部門において
    設計書・設計変更説明文書を書く立場の技術者

「AIで文章を書く」こと自体が目的ではなく、
業務上の説明を、相手に正しく伝えること を目的としています。

【業務でよくある悩み】

設計書や設計変更説明文書について、
こんな経験はありませんか？

  • 自分では分かっているが、他人には伝わらない

  • 技術的に正しいが、読み手から質問が多い

  • レビューで
    「結局、何が変わったのか分からない」と言われる

  • 書き直し・説明対応に時間を取られる

👉 問題は、
内容ではなく「伝え方」 にあることが多いです。

【結論から】

生成AIは、

設計そのものを考えてくれる存在
ではありません。

しかし、

「説明文として分かりやすく整える補助役」

として使うと、
設計文書作成の負荷を大きく下げられます。

【AIが向いている業務／向いていない業務】

AIが向いていること

  • 文章の構成整理

  • 表現の言い換え

  • 読み手（非開発者）向けの平易化

  • 設計変更点の整理・要約

AIが向いていないこと

  • 設計判断そのもの

  • 技術的な正解の保証

  • 業務要件の決定

👉 考えるのは人、
整えるのをAIに任せる
という役割分担が重要です。

【業務での具体的な使いどころ】

① 設計変更説明文書の作成

元の設計内容と、変更点を箇条書きで整理した上で、

  • 「この変更を、非エンジニア向けに説明してください」

  • 「影響範囲と理由が分かる文章にしてください」

とAIに依頼すると、

👉 説明用の文章案 を短時間で作れます。

② レビュー前のセルフチェック

自分が書いた設計文書をAIに読ませて、

  • 「分かりにくい点はどこか」

  • 「前提知識が必要な部分はどこか」

を確認すると、

👉 レビュー指摘を事前に潰す ことができます。

③ 読み手別の説明文作成

同じ設計内容でも、

  • 開発者向け

  • 業務部門向け

  • 管理者向け

では、
求められる説明の粒度が違う。

AIを使うことで、

「この設計を、業務部門向けに説明してください」

といった
説明文の切り替え が容易になります。

【AIを使うときの注意点（重要）】

  • AIの文章を、そのまま鵜呑みにしない

  • 技術的な正しさは、必ず人が確認する

  • 設計の責任は、書いた人が持つ

AIは
“説明文を整える道具” であって、
設計者の代わりではない という前提を忘れないことが重要です。

【業務視点でのまとめ】

  • 設計書が伝わらない原因は
    技術力ではなく「説明構造」にあることが多い

  • 生成AIは
    説明文作成・整理に非常に相性が良い

  • AIを使うことで
    設計者は「考えること」に集中できる

👉 設計の質を下げずに、
説明コストを下げる手段 として
AIを使うのが現実的です。

 

【参考】 －AIで仕様書を作った例 －

www.mitech.work

トップページへ

https://www.mitech.work/top