設備の点検・修理の記録を音声で入力して保全台帳に残す

処理の起点を決める

SharePointの音声フォルダにファイルが作成されたことを起点にします。Power Automate の SharePoint コネクタには「ファイルが作成されたとき」トリガーが用意されています。

録音アプリの側では、録音を止めた時点でファイルを保存します。Power Apps のマイクコントロールは、録音した音声を Audio プロパティで受け取れます。公開ドキュメントでは、録音を止めたときに動く OnStop プロパティで Collect や Patch を呼び、変数・コレクション・データソースへ保存する例が示されています。

ファイル名に、設備番号・作業日時・担当者を入れておきます。 音声だけから設備を特定させると精度の問題が残ります。設備は現場で選ばせるほうが確実です。

なお、Power Apps のマイクコントロールで録音される形式は、Androidが3gp、iOSがAAC、Webブラウザーが OGG と、端末によって異なります。どの形式が来ても処理できるようにしておきます。

入力データを集める

データの取得方法を決める

文字起こし： Azure AI Speech の高速文字起こし（Fast transcription）APIに音声ファイルを渡します。公開ドキュメントによると、このAPIは音声ファイルを同期的に処理して、句読点の入った読みやすい形の文字列をJSONで返します。扱えるのは5時間未満・500MB未満のファイルで、WAV・MP3・OGG・FLAC・AAC・AMR・WebMなどに対応しています。応答には全体の文字列（combinedPhrases）に加えて、区間ごとの文字列・開始位置・長さ・確信度（confidence）が入ります。日本語（ja-JP）は対応言語に含まれています。

用語の補強： 同じくAzure AI Speech には、認識させたい単語をあらかじめ渡して精度を上げる「フレーズリスト」の機能があります。公開ドキュメントでは、リアルタイム文字起こしと高速文字起こしで利用できること、フレーズは500件を超えないようにすることが案内されています。ここに設備の通称と部品品番を入れます。 「シールヒーター」「Hの2140」のような、一般の辞書にない言い方が対象です。

なお、まとめて処理するバッチ文字起こしAPIのほうは、フレーズリストに対応していません。用語を効かせたいなら、高速文字起こし側を使います。

マスタと履歴： 台帳システムから日次でエクスポートしたファイル、またはSharePointリストを直接参照します。リアルタイム連携は必要ありません。

AIへ渡す前に整形する

1. 無音と雑音の切り落とし … 録音ボタンを押してから話し始めるまでの数秒と、話し終えてから止めるまでの数秒を落とします。処理時間と費用が下がります
2. 形式の統一 … 端末によって3gp・AAC・OGGと分かれるため、1つの形式へ変換してから渡します
3. 設備番号の引き当て … ファイル名に入れた設備番号を設備マスタと照合し、設備名・型式・ラインを補います。音声から設備を推測させません
4. 短すぎる録音の除外 … 5秒未満は押し間違いとみなし、処理せずに担当者へ戻します

AIに処理させる

音声認識と生成AIで役割を分けます。

音声認識にさせること： 話した内容を文字にすること。ここは生成AIにさせません。専用のサービスのほうが精度が高く、費用も安く済みます。

生成AIにさせること：

原因を作らせないでください。 話されていない原因を生成AIが補うと、それが履歴として残り、後の分析を歪めます。語られていないものは「未記載」です。

指示内容を固定する

あなたは設備保全の記録を整理する担当者です。
現場担当者が作業直後に話した内容の文字起こしを、保全台帳の項目に切り分けてください。

【厳守事項】
- 文字起こしに無い内容を補わないでください。
  特に「原因」は、話されていなければ cause を null にし、
  missing に "原因" を入れてください。推測して書かないでください。
- 部品品番は、部品マスタの候補に一致するものだけ part_no に入れてください。
  一致しない場合は part_no を null にし、聞こえたままの文字列を
  part_no_heard に残してください。新しい品番を作らないでください。
- 数量・所要時間は、話された数値をそのまま使ってください。
  単位が不明なときは null にしてください。
- 発煙・異臭・発火・漏電・感電・けが・落下 のいずれかに当たる内容があれば、
  alert を true にし、該当箇所を alert_text に引用してください。
- 聞き取りが不確かな箇所は、書き換えずに uncertain に列挙してください。

【設備情報】
{equipment_master}

【この設備の直近3件の履歴】
{recent_history}

【部品マスタの候補（適合設備で絞った一覧）】
{part_candidates}

【文字起こし】
{transcript}

「原因を推測しない」の1行が、この構成でいちばん効きます。 保全台帳は、後から故障の傾向を読むための材料です。生成AIが埋めたそれらしい原因が混ざると、集計した瞬間に意味を失います。

出力形式を固定する

{
  "equipment_no": "",
  "work_type": "点検 | 修理 | 部品交換 | 調整",
  "symptom": "",
  "cause": null,
  "action": "",
  "parts": [
    {
      "part_no": "",
      "part_no_heard": "",
      "qty": 0,
      "unit": ""
    }
  ],
  "duration_min": 0,
  "next_action": "",
  "alert": false,
  "alert_text": "",
  "missing": [],
  "uncertain": [],
  "summary": ""
}

項目の型を決めて返させます。Claude API には、返す形を指定して構造化された出力を得るための仕組みが用意されています。所要時間や数量を文字列で受け取ると、後段の集計で必ず壊れます。数値は数値で返させてください。

missing と uncertain は、確認画面で色を付けるために使います。ここが空でも、全件を人が確認します。

システムへ連携する

承認後、保全台帳へ登録します。連携方法は台帳の作りによって3通りあります。

この部分は利用環境に応じた個別確認が必要です。 使っている保全システムのAPIの有無と仕様は、製品のベンダーに確認してください。

部品の出庫や発注は、この構成では自動化しません。承認済みの記録を起点に、既存の手続きへ渡すだけにします。 在庫を動かす処理は、記録の誤りがそのまま数字の誤りになります。

alert が立った記録は、登録と同時に保全課の責任者へ通知します。発煙や異臭は、台帳に残すだけでは間に合いません。

人が確認する

全件、人が承認します。

理由は2つあります。第一に、聞き取りの誤りが残るためです。現場の録音は、機械音・送風・防音具越しの声という条件で行われます。第二に、保全台帳は設備の履歴そのもので、誤った記録が残ると、次に対応する人が誤った前提で作業します。

確認を速くするための設計が重要です。

• 確認画面で、文字起こしの全文と、切り分けた項目を左右に並べて表示する
• missing（未記載）と uncertain（聞き取りが不確か）の項目を色分けする
• 部品品番は、マスタの候補を選択式で出す（手打ちさせない）
• 同じ設備の直近3件を画面の下に置き、前回と同じ処置なら一目で分かるようにする

これらがないと、確認に6分かかり、打ち直していたときと変わりません。

例外に対処する

記録を残す

• 音声の原本（承認後も一定期間残す）
• 文字起こしの全文と、区間ごとの確信度
• 生成AIが切り分けた結果（承認前の状態）
• 承認者、承認日時
• 人が直した項目と、修正前後の値

最後の項目が、精度の実測値になります。「部品品番は毎回そのまま通るが、所要時間は半分が直されている」と分かれば、次に手を入れる場所が決まります。

保存期間は自社の規程に合わせます。設備によっては、法令で点検記録の保存期間が定められている場合があります。 対象設備と保存年数は、自社の安全衛生の担当部署に確認してください。