サーバー室・データセンターの巡回で撮ったラックの前面と背面の写真から、異常を示すランプ・配線の乱れ・ラベルの欠けを見分けて、巡回記録と対応の依頼を作る

処理の起点を決める

写真がラックの番号のフォルダに入ったことを起点にします。 巡回の担当のタブレットから社内のファイルサーバーに写真が同期されると、Local File Trigger が検知してワークフローが動きます。監視するのは「写真の受け取り」の1つのフォルダだけにし、処理を終えた写真は別のフォルダに移します。

1本のラックの写真が4枚そろってから処理します。 前面と背面の上半分・下半分です。写真1枚ごとに動かすと、下半分の写真が無いまま「機器が見当たらない」と出ます。 ワークフローは写真の数を数え、4枚そろったラックから順に処理します。30分たってもそろわないラックは、「撮り漏れ」として下書きに出します。

巡回の担当がデータセンターから戻るころには、下書きができていることを目安にします。2拠点で45本なので、1本ずつ順に処理しても間に合います。 臨時の作業の後に撮った写真も同じフォルダに入れれば、同じ流れで記録に残ります。作業の前後で同じラックを撮っておくと、作業で何が変わったかを後から比べられます。

入力データを集める

質を決めるのは、ランプの意味の表です。 機種のマニュアルから、「前面の左のランプ、橙の常時点灯は電源の故障」のように、機種ごとに書き出します。この表が無いと、ランプの色が分かっても、それが異常かどうかが決まりません。 古くからの担当の記憶を、表に移す作業でもあります。

構成台帳には、U番号と「監視の有無」を持たせます。 監視に載っている機器のランプは、写真で異常が見えても、監視の通知と突き合わせてから扱います。 監視に載っていない機器は、写真がいちばん早い知らせになります。

ホスト名はAIに渡しません。 構成台帳から渡すのは、U番号と機種だけです。ホスト名は、AIの答えを台帳と照らした後に、ワークフローの側で付けます。

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

n8n のワークフローが、次の順に集めます。

AIには、「このラックのこのU番号に、この機種がある」という枠組みを渡します。 写真だけを見せて機器を数えさせると、ブランクパネルを機器と数えたり、2Uの機器を2台と数えたりします。台帳の並びを先に渡し、その並びに沿って答えさせます。

位置の手がかりは、ラックの柱のU番号です。 多くのラックは、柱に1Uごとの番号が印字されています。写真に柱が写るよう撮る決まりにし、AIにはU番号を読んで機器の位置を答えさせます。柱の番号が写らないラックは、上端と下端の機器を手がかりに並びを合わせます。

AIへ渡す前に整形する

1. 枚数と名前の確認 … 4枚がそろい、拠点・ラック・面・上下の記号が決まりどおりかを見ます
2. 写りの確認 … ぶれ・ピンぼけ・扉のガラス越しの反射が強い写真は、「撮り直し」とします
3. 向きの補正 … タブレットの縦横の向きの情報で、写真の向きを正しくします
4. 上下の重なりの確認 … 上半分と下半分の写真に、同じU番号が重なって写っているかを見ます。重なりが無いと、境目の機器が抜けます
5. 台帳の枠組みの作成 … そのラックの機器を、U番号の順に「U番号・機種・前面と背面のどちらにランプがあるか」の一覧にします
6. 大きさの設定 … 小さなランプを見分けるため、media_resolution を high にし、それでも見分けられない機種は写真を寄って撮ります

2番目の反射は、サーバー室ならではの問題です。 ラックの扉のガラスや、機器の前面のつやのある板に照明が映ると、照明の映り込みが白いランプに見えます。 扉を開けて撮る決まりにし、斜めから撮って映り込みを避けます。

4番目を省くと、境目の1台が毎回抜けます。 上下の写真の境目にある機器は、どちらの写真にも半分しか写らないことがあります。重なりを持たせて撮る決まりにします。

AIに処理させる

させるのは、台帳の枠組みに沿って、機器ごとに次の4つを答えることだけです。

ラベルは「有るか」だけを答えさせ、文字は読ませません。 ラベルにはホスト名や管理番号が書かれています。読ませれば台帳との照合はできますが、その文字を外部に送ることになります。 この構成では、有無だけを見て、照合は台帳の「ラベルの有無」の列で行います。

ラックの単位でも1つ答えさせます。 台帳に無い物（工具、段ボール、置かれた機器）が写っていれば foreign_object の印を付けます。置き忘れの工具は、次の作業で事故のもとになります。

指示内容を固定する

あなたはサーバー室の巡回の記録を補助する立場です。
同じラックの前面・背面の写真を、上半分と下半分で計4枚渡します。
渡す機器の一覧に沿って、機器ごとに見えるものだけを答えてください。

【機器の一覧】（U番号の下端から上端、機種、ランプのある面）
{rack_layout}

【答えること】
- position：柱に印字されたU番号から読んだ、機器の下端と上端
- lamps：ランプごとの色。green / amber / red / blue / off / unknown
- cable：抜けかけ・垂れ下がり・前面をふさぐケーブル。none / found / uncertain / not_visible
- label：機器のラベルが貼られているか。present / missing / not_visible
迷ったときに none や present を選ばないでください。

【厳守事項】
- ランプが異常か正常かを書かないでください。色だけを答えてください。
- ランプが消えて見えても、点滅の消えた瞬間かもしれません。off は「暗く見える」という意味で使い、
  止まっているとは書かないでください。
- 反射や照明の映り込みで色が決められないときは unknown にしてください。
- ラベルや画面の文字を読み取って答えないでください。
- 一覧に無い機器や物が写っていれば、foreign_object に位置と見た目を短く書いてください。
- 機器の一覧と写真の並びが合わないときは、layout_mismatch を true にしてください。
- found と missing のときは、写真の番号と box_2d を返してください。

「異常か正常かを書かない」を明記しないと、AIは書きます。 橙色のランプを見れば、多くの機種で警告の意味だと知っているからです。その推測が当たる機種と外れる機種があり、外れた記録が残ります。 意味の判断は表に寄せます。

「off は止まっているという意味ではない」も同じ理由です。 点滅のランプを「消灯」と記録し、それを「停止」と読む人が出ると、動いている機器の対応の依頼が飛びます。

出力形式を固定する

構造化出力で、ラックごとに次の形のJSONを受け取ります。

{
  "rack_id": "DC1-B07",
  "layout_mismatch": false,
  "devices": [
    { "u_bottom": 12, "u_top": 13,
      "side": "front | rear",
      "lamps": ["green | amber | red | blue | off | unknown"],
      "cable": "none | found | uncertain | not_visible",
      "label": "present | missing | not_visible",
      "photo_no": 1,
      "box_2d": [0, 0, 0, 0] }
  ],
  "foreign_object": [ { "photo_no": 3, "box_2d": [0, 0, 0, 0], "note": "" } ]
}

色や状態の値を enum にして、決めた値以外を返させません。 Gemini API の構造化出力では、enum と required が使えます。ただし、JSONとして正しくても値が正しいとは限らないため、アプリケーションの側で値を確かめるよう案内されています。 ワークフローで、返った機器の数とU番号が台帳と合うかを確かめ、合わない機器は「確認が要る」にします。

区分は、ワークフローが表と前回の記録から決めます。

「前回と同じ」に続く日数を付けるのが、変化を追う仕組みです。 「注意：12日目」と出れば、先月から放置された注意だと一目で分かります。

監視に載っている機器が「要対応」になったときは、監視の通知を確かめる手順を案に入れます。 監視が通知していないのに写真で故障の色なら、監視の設定の漏れか、写真の誤りのどちらかです。

システムへ連携する

チケットは、担当が確かめてから起票します。 案をそのまま自動で起票すると、写真の誤りで他のチームを動かしてしまいます。 起票の後の対応は、これまでどおりチケットの流れで進めます。

構成台帳は読み取りだけです。 台帳に無い機器が写っても、台帳には書き足しません。台帳を直すのは、作業の記録を確かめた担当です。 台帳外の機器は、無断の設置か、台帳の更新漏れかを確かめる材料になります。

人が確認する

すべてのラックで、担当の確定を通します。 写真を開く機器は区分で絞ります。

1. 「要対応」を最初に見る … 写真で確かめ、監視の通知と突き合わせ、チケットに起票します
2. 「確認が要る」を片付ける … unknown が続く機器は撮り方を変え、layout_mismatch は台帳を確かめます
3. 「注意」の日数を見る … 続く日数の長いものから、担当のチームに確かめます
4. 「前回と同じ・正常」は一覧で確定する … 下書きを流し見て、まとめて確定します

目標は、900件をならして1本1.4分です。 「正常」が並ぶラックは一覧で数十秒、「要対応」「確認が要る」があるラックは写真を開いて数分かかります。

最初の1か月は、これまでの手書きの記録と並べて動かします。 担当が見つけた異常に、AIが色や候補を出していたかを照らします。出していなかった機器は、撮り方かランプの意味の表を直す材料です。 逆に、担当が「正常」に直した機器も数えます。同じ機種で直しが続くなら、表の色の書き方か、撮る角度のどちらかがずれています。 新しい担当が確定するときは、最初の2週間だけ古くからの担当が下書きを一緒に見ます。

例外に対処する

下の3行で、「機械が見ていない」状態を見えるようにしておきます。 未処理のラックを「正常」と混ぜると、その日の巡回記録が無いのと同じになります。

記録を残す

• ラックごとの4枚の写真と、撮影の時刻、撮った担当
• 機器ごとのAIの答え（位置、ランプの色、配線、ラベル、box_2d）
• 区分と、そのとき使ったランプの意味の表の版
• 担当が直した内容と、確定した区分
• 起票したチケットの番号
• 機器ごとの「注意」「要対応」が続いた日数

巡回記録の下書きは、たとえば次の形にします。

【巡回記録の下書き】DC1 2026-10-08 09:20 撮影（担当 A）
 B07  U12-13 管理用スイッチ（監視なし）  前面 amber → 注意：12日目
      U20    PDU（監視なし）            背面 ケーブルの垂れ下がり → 要対応
      U31    テープ装置                 前面 unknown → 確認が要る（映り込み）
 B08  すべて 前回と同じ・正常
 B09  layout_mismatch → 確認が要る（U05-06 が台帳に無い）

ホスト名は、ワークフローが台帳から付けて社内の記録にだけ書きます。 AIの答えに含まれていないので、写真と一緒に外へ出ることはありません。

写真は、障害のときに遡る記録として決めた期間残します。 「障害の3日前に、この機器の背面のケーブルが垂れていたか」を写真で確かめられます。写真の保存先は社内のファイルサーバーで、外部には残しません。