研究所の試験装置の温度・圧力・振動のセンサーの記録を Python で見て、異常な波形の候補を拾い、AI で試験の条件と照らした説明を付けて研究者に返す

処理の起点を決める

15分ごとに、試験の管理表を見に行きます。 管理表で状態が「終了」になり、点検の済んでいない試験を見つけたら、その試験のデータを読みます。データロガーのファイルが書き終わったかどうかは、ファイルの更新の時刻が数分止まっていることで確かめます。 書き出しの途中のファイルを読むと、試験の後半が欠けたデータを「途切れ」として拾ってしまいます。

試験中には動かしません。 長い試験の途中で異常の候補を知らせる仕組みも作れますが、この構成では、試験が終わった後に1回だけ点検する形にします。試験中の監視は装置の側の警報の役目で、二重に知らせると試験担当が混乱します。

定時の実行は、社内のサーバーのジョブの管理の仕組みか、OS のタスクの予定で行います。 1回の実行で処理する試験は数件に限り、残りは次の15分の実行で続きから処理します。 処理の状態は管理表の「点検」の欄に書き、二重に処理しないようにします。

入力データを集める

質を決めるのは、試験の記録と既知の挙動の一覧です。 試験担当が扉を開けたことを書き込んでいなければ、AIは温度の下がりを扉で説明できません。記録の書き込みの決まりを「時刻を必ず書く」から始めてください。 時刻の無い書き込みは、照らす材料になりません。

既知の挙動の一覧は、最初はベテランの研究者と装置の担当に聞き取って作ります。 装置ごとに10行もあれば始められます。この一覧が、（c）の属人化をほどく元になります。

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

CSV は共有フォルダから読みます。 振動のチャンネルは大きいので、チャンネルごと・区間ごとに分けて読み、すべてを一度にメモリに載せない作りにします。

振動の周波数ごとの強さは、welch で窓ごとに出します。 公式のページでは、サンプリングの周波数 fs の既定は1.0、区切りの長さ nperseg の既定は256、重なりの既定は区切りの半分、トレンドの除去の既定は 'constant' とされています。fs は必ずデータロガーの記録の間隔から入れます。 既定のままだと、周波数の軸が実際の値と合いません。

AIへ渡す前に整形する

1. ファイルの確かめ … 書き終わりの確認、チャンネルの名前と単位、記録の間隔が条件表の装置と合っているかを見ます
2. 時刻を揃える … データロガーの時刻と、試験の記録の時刻の基準をそろえます。装置ごとの時計のずれは、管理表に持たせた値で直します
3. 区間を分ける … 条件表の段階の開始と終了の時刻で区間に分けます。段階の切り替えの前後数十秒は、切り替えの区間として別に扱います
4. 決まりの点検 … 値が欠けている、同じ値が長く続く（センサーの外れ）、条件の許す幅を外れた、を数で見ます。ここで見つかったものは、AIに渡す前に種類が決まっています
5. 窓ごとの特徴 … 温度と圧力は10秒、振動は1秒の窓で、平均・ばらつき・最大・設定との差・変化の速さ・実効値・周波数の帯ごとの強さ・強さが最大の周波数を出します
6. 外れ値の検出 … 試験の種類・装置・段階ごとに学習した IsolationForest で、窓ごとの decision_function を出し、負の窓を候補にします
7. 出来事にまとめる … 続いている候補の窓を1つの出来事にし、開始と終了の時刻、関わるチャンネル、いちばん外れた特徴を付けます
8. グラフを作る … 出来事ごとに、前後を含めた温度・圧力・振動の波形と、出来事の窓と正常な窓の周波数ごとの強さを並べた画像を1枚作ります

6番目は、学習のときに乱数の種を決めます。 公式のページでは、random_state を整数で渡すと結果が再現できるとされています。同じ試験を点検し直したときに候補が変わると、研究者が結果を信用できなくなります。 外れ値の割合の contamination は既定の 'auto' で始め、研究者の判断の記録がたまってから見直します。

8番目の画像は、長い辺を2,000画素以下にします。 公式のページでは、1回のリクエストの画像が20枚を超えると、1枚ごとの寸法の上限が厳しくなるとされ、どの画像も2,000画素を超えないようにするか、20枚以下に抑えることが案内されています。1回のリクエストでは1つの出来事の画像1枚だけを送るので、どちらの形でも収まります。

AIに処理させる

させるのは、1つの出来事について、次のどの種類に当たるかを判定し、根拠を示して説明を書くことです。

unexplained を正しく出すことが、いちばん大事な役目です。 研究者が時間を使うべきなのは、説明のつかない出来事です。材料に無い理由を作って説明してしまうと、本当に見るべき出来事が「説明済み」の側に紛れます。

2行目は、公式のページの限界の記述に沿っています。 画像の内容の判断について、低品質・回転した・200画素未満のとても小さな画像では誤りがありうること、位置の出力はおおよそであることが挙げられています。ピークの高さや時刻は、特徴の数値の表から読ませます。

指示内容を固定する

あなたは研究所の試験データの点検を補助する立場です。
試験のセンサーの記録から、プログラムが「異常の候補」として拾った出来事が1つあります。
画像（波形と周波数ごとの強さ）、特徴の数値、試験の条件、装置の既知の挙動、
試験の記録を見て、この出来事がどの種類に当たるかを判定してください。

【種類】
- test_condition .. 条件表の段階の切り替え・設定の変更で説明がつく
- known_behavior .. 装置の既知の挙動の一覧のいずれかの行で説明がつく
- operator_action . 試験の記録に書かれた作業で説明がつく
- sensor_issue .... センサーの不具合と考えられる（1チャンネルだけの跳ね、途切れ、平らな値）
- unexplained ..... 上のどれでも説明がつかない
迷ったときは unexplained を選んでください。

【厳守事項】
- 判定の根拠には、渡した材料の行だけを使ってください。
  根拠にした行は evidence に、渡した文字列のまま写してください。
- 値（温度・圧力・周波数・時刻）は、画像から読み取らず、
  特徴の数値の表に書かれた値だけを使ってください。
- 材料に無い装置の挙動や作業を、理由として作らないでください。
- 時刻が出来事の範囲と5分以上離れた記録を、根拠にしないでください。
- 試験を有効とするか無効とするかを書かないでください。
- 試料が壊れた・劣化した・亀裂が入ったと結論づけないでください。
  試料の変化の可能性に触れるときは、unexplained とし、
  check_points に研究者が確かめる点として書いてください。
- check_points には、研究者が次に確かめるとよい点を3つまで書いてください。

【出来事】{event}（開始・終了の時刻、関わるチャンネル、いちばん外れた特徴）
【特徴の数値】{features}（出来事の窓と、同じ段階の正常な窓の値）
【その時刻の試験の条件】{condition}
【装置の既知の挙動】{known_behaviors}
【出来事の前後30分の試験の記録】{log_lines}

「迷ったときは unexplained」を明記するのは、説明をつけたがる傾向を抑えるためです。 既知の挙動の一覧を渡すと、形が少し似ているだけの行を根拠に known_behavior としがちです。説明がつかないと書くことを、正しい答えとして先に示しておきます。

「5分以上離れた記録を根拠にしない」も同じ理由です。 試験の記録は前後30分を渡しているので、20分前の「扉を開けた」を、今の温度の下がりの理由にしてしまうことがあります。時刻の近さはプログラムの側でも検査します。

出力形式を固定する

Claude API の構造化出力で、次の形の JSON を受け取ります。 公式のページでは、output_config.format に type: "json_schema" を指定し、オブジェクトには additionalProperties: false を付けることとされています。

{
  "test_no": "T-2026-1187",
  "event_id": "E-03",
  "category": "test_condition | known_behavior | operator_action | sensor_issue | unexplained",
  "explanation": "",
  "evidence": [
    { "source": "log | condition | known_behavior | features", "text": "14:05 扉を開け試料を確認" }
  ],
  "check_points": [""],
  "needs_review": ""
}

1つ目の理由は、evidence をプログラムで照合できることです。

置き換える先を unexplained にしているのは、誤りの向きを決めておくためです。 検査で引っかかった説明は捨て、研究者が見る側に倒します。 見る件数は少し増えますが、見落としは増えません。

2つ目は、種類で一覧を並べ替えられることです。 研究者は unexplained と sensor_issue を先に見て、説明のついたものは画像を流し見ます。

3つ目は、種類の値を決めておけることです。 公式のページでは、列挙型の値は大文字小文字だけ違う形で返ることがあるとされているので、比べるときは大文字小文字を区別しません。 構造化出力は数値の最小値・最大値の制約に対応していないため、値の範囲は特徴の計算の側だけで扱い、AIには数値を返させません。

システムへ連携する

画像は、1つの出来事につき1枚を base64 で渡します。 公式のページでは、画像は JPEG・PNG・GIF・WebP に対応し、1枚の寸法の上限は8,000×8,000画素、API に直接送る場合の1枚の大きさの上限は base64 で10MB とされています。波形のグラフは PNG で作り、長い辺を2,000画素以下にします。 画像は文章より前に置くほうがよいとされているので、画像、特徴の数値、条件、既知の挙動、記録の順に並べます。

1つの試験で出来事が多すぎるときは、AIに渡さずに止めます。 出来事が数十も出る試験は、センサーの外れや装置の不具合で全体がおかしいことが多く、1つずつ説明を付けても意味がありません。 上限（たとえば20件）を超えたら「試験全体の確認が要る」として研究者に知らせます。

人が確認する

研究者が、試験ごとの点検の一覧を読みます。

1. unexplained を先に見る … グラフと特徴の数値を見て、試料を確かめるか、装置の担当に聞くかを決めます
2. sensor_issue を見る … どのセンサーかを確かめ、そのチャンネルのデータを使えるかを決めます
3. 説明のついたものを流し見る … 根拠の行が本当にその出来事の説明になっているかを、グラフで確かめます
4. データを解析に回すかを決める … 試験の管理表に、解析に回す・確認を続ける・やり直すを書きます
5. 候補ごとの判断を記録する … 本当の異常か、説明のつくものか。説明のつくものが既知の挙動の一覧に無ければ、一覧に足す案を書きます

1試験9分を目安にします。 候補が数件で説明のついたものが多い試験は数分、unexplained のある試験は試料や装置を確かめるので十数分です。候補が一つも無い試験も、一覧の「候補なし」を確かめて記録します。

5番目は省かないでください。 判断の記録は、外れ値の検出の学習を見直す材料と、既知の挙動の一覧を育てる材料の両方になります。記録が無いと、半年たっても同じ扉の開け閉めを毎回見ることになります。

例外に対処する

4行目は、新しい試験の種類を始めたときに必ず起きます。 正常な試験の特徴がそろうまで、外れ値の検出は使えません。研究者が「問題なし」とした試験が10回ほどたまったところで学習し、 それまでは決まりの点検だけで回します。

記録を残す

• 実行の日時、試験の番号、読んだファイルと記録の間隔
• 決まりの点検の結果と、外れ値の検出の窓ごとの値（decision_function）
• 学習に使った試験の一覧と、学習の日、random_state の値
• 出来事ごとの画像、特徴の数値、AIに渡した材料、AIが返した JSON の全文
• 検査の結果と、unexplained に置き換えた理由
• 研究者の判断（候補ごと、試験ごと）と、既知の挙動の一覧に足した行

3つ目で学習の中身を残すのは、候補の出方が変わったときに理由を追うためです。 学習を作り直すと、同じ試験でも候補が変わります。どの学習で点検した結果かが残っていないと、過去の試験と比べられません。

保存の期間は、試験のデータそのものと同じにします。 点検の一覧は、そのデータを解析に回してよいと判断した根拠です。試験の報告書を後から見直すときに、点検の記録も一緒に見られるようにしておきます。