太陽光発電所の保守会社が定期点検で撮ったパネル・架台・パワーコンディショナの写真から、割れ・汚れ・影・雑草・腐食の候補を拾い、点検報告書の下書きに回す

処理の起点を決める

1か所分の写真が写真の保管先にそろったときに動きます。 点検アプリで「この発電所の撮影を終える」を押すと、地点の番号の入った写真がまとめて上がり、プログラムが動きます。撮影の途中では動かしません。 途中で動かすと、撮っていない地点が「写真なし」として一覧に並び、点検員が混乱します。

台風・大雨・地震の後の臨時の点検も、同じ流れに乗せます。 太陽光発電協会の資料では、地震、台風、洪水、火災、悪天候の後に点検を行い、詳細な点検が必要なら定期点検要領の例の点検を行うことが望ましいとされています。臨時の点検では、前回の定期点検の写真と組にします。

撮り直しの写真が後から上がったときは、その地点だけを呼び直します。 点検員が直した所見を上書きしないよう、直した後の所見は別の欄に残します。

入力データを集める

質を決めるのは、地点の番号と、毎回同じ位置から撮ることです。 前回と今回の写真の向きや距離が大きくずれていると、同じ場所を比べられず、変化が「比べられない」になります。 地点ごとに、杭やフェンスの柱など目印を決めておくのがいちばん効きます。

撮影の条件は、汚れと影の見分けに使います。 逆光の写真では、パネルの表面の反射が汚れに見えます。夕方の写真では、草木の影が長く伸びます。条件を指示に入れておくと、反射を汚れと言いにくくなり、影の長さの違いを前回との変化と言いにくくなります。

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

前回の写真は、発電所の番号と地点の番号で、写真の保管先から取ります。 前回の定期点検の日を点検の管理表から引き、その日のフォルダの同じ地点の番号の写真を探します。地点の番号の一覧が変わった発電所（パネルを増設した など）は、前回に無い地点を「前回の写真なし」とします。

Gemini API へは、地点ごとに1回、前回と今回の2枚を組にして渡します。 1か所で数十回の呼び出しを並べて行います。地点ごとに分けると、どの組で比べたかがはっきりし、撮り直しのときにその地点だけを比べ直せます。

表示画面の写真は、別の指示で渡します。 パワーコンディショナの表示画面は、パネルの写真と見るものが違い、画面の文字（エラーの番号、運転の状態）を書き写すことが仕事になるからです。

有料の利用枠で使います。 Gemini API の規約では、有料のサービスではプロンプトと応答（画像などのファイルを含む）が製品の改善に使われないとされています。

AIへ渡す前に整形する

1. 形式と向き … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめ、画像の向きの情報で回転しているだけのものは画素を回転させます。向きが合っていないと、返った枠がずれます
2. 縮小 … 全景の写真は長い辺を1,600ピクセル程度に縮めます。パネルの寄りと表示画面の写真は、割れや文字がつぶれないよう大きめに残します
3. 組の確認 … 今回の地点の番号ごとに前回の写真があるかを見ます。無い地点は「前回の写真なし」とし、今回の写真だけで候補を拾わせます
4. 撮影の条件の付け足し … 前回と今回の天気・時刻・逆光かを指示に入れます
5. 地点の説明の付け足し … その地点が何を撮る地点かを指示に入れます。「アレイの全景」と「架台の基礎」では、見るものが違います
6. 大きさの確認 … 2枚と指示の文を合わせて20MBを超えないかを見ます。超えるときは縮め直します

4番目を軽く見ないでください。 前回が曇りの昼、今回が晴れの夕方なら、草木の影の長さは写真の上で大きく変わります。 その差を前提に比べさせないと、影が「新しく出た」と返ってきます。

AIに処理させる

させるのは、地点ごとに前回と今回の写真を比べ、今回の写真の候補を枠で返し、前回からの変化と、写っていない範囲を返すことだけです。 表示画面の写真では、画面の文字を書き写させます。

右端の列の考え方は、迷ったら点検員に見せる側に倒すことです。 汚れか反射か分からないものは候補に入れ、前回と比べられないものは「比べられない」と返させます。候補が多すぎるのは点検員の数秒で済みますが、候補から落ちた割れは次の点検まで誰も見ません。

4行目がいちばん起きやすい失敗です。 パネルの一部がわずかに変色した写真を渡すと、AIは「ホットスポットの可能性」と書きたがります。報告書に一度その言葉が載ると、発電事業者には異常として伝わります。 返すのは「変色の候補」という写っている事実までにします。

機器の内部の写真を撮らせないことも、この構成の前提です。 太陽光発電協会の資料では、太陽光発電用機器の内部は高電圧となっている部分があるため、日常点検は外部からの目視、異音、異臭、振動などの点検に留めるとされています。AIのために、点検員が機器の扉を開けて写真を撮ることはしません。

指示内容を固定する

あなたは太陽光発電所の保守点検の報告書づくりを手伝う係です。
同じ発電所の同じ地点を撮った2枚の写真があります。
1枚目は前回の定期点検、2枚目は今回の点検で撮ったものです。

【この地点】{地点の番号}：{アレイの全景／パネルの寄り／架台の基礎／フェンス／周囲の草木}
【撮影の条件】前回：{天気、時刻、逆光か}　今回：{天気、時刻、逆光か}

【やること】
1. 2枚目の写真で、次の候補を探す。
   割れ、汚れ、鳥の糞、草木の影、雑草、架台の腐食・さび、ボルトの欠け、
   フェンスの破れ、標識の欠け、配線の垂れ下がり。
2. 候補ごとに、2枚目の写真の上の枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。種類と見え方を書く。
3. 候補ごとに、1枚目と比べて new（前回は無い）／progressed（広がった・伸びた）／
   unchanged（同じ）／improved（減った）のどれかを付ける。
   1枚目で同じ場所が見えなければ not_comparable とする。
4. 逆光、遠すぎる、草で隠れているなどで見えない範囲を、理由とともに返す。

【厳守事項】
- 異常の程度、緊急度、修繕・清掃・除草の要否を書かないでください。
- 「ホットスポット」「発電量の低下」「故障」と書かないでください。
  あなたが返すのは、写真に写っている候補と、前回からの変化だけです。
- 汚れか反射か分からないものは、kind を unclear にして候補に入れてください。
- 天気や時刻の違いによる影の長さの違いを、変化として扱わないでください。
- 見えない範囲がある場合、その範囲について「異常なし」と書かないでください。
- 近隣の建物、人、車については何も書かないでください。

「ホットスポット」「故障」を禁じる一文は、表現の問題ではありません。 報告書の下書きにこの言葉が載ると、技術者が確かめる前に、発電事業者への説明の言葉として残ってしまいます。 責任と費用に関わる言葉を、最初から外しておきます。

表示画面の写真には、別の指示を使います。 「画面に出ている文字と数字を、そのまま書き写してください。読めない文字は ? にしてください。エラーの意味は書かないでください」とし、書き写した文字を技術者が取扱説明書で引きます。

出力形式を固定する

地点ごとに、次の形の JSON で受け取ります。 kind、change、reason は enum で決まった文字列に絞ります。

{
  "site_id": "",
  "point_id": "A-03",
  "candidates": [
    {
      "box_2d": [520, 140, 610, 330],
      "kind": "crack | soiling | bird_droppings | shading | vegetation | corrosion | missing_bolt | fence_damage | sign_missing | cable_sag | unclear",
      "description": "パネルの左下の角に放射状の線",
      "change": "new | progressed | unchanged | improved | not_comparable"
    }
  ],
  "not_visible": [
    { "area": "B列の西半分", "reason": "backlight | too_far | hidden_by_vegetation | no_previous_photo" }
  ],
  "display_text": ""
}

1つ目の理由は、change で報告書の書き方をそろえられることです。 new と progressed の候補は報告書の所見の欄の先頭に、unchanged は「前回から変化なし」として後ろにまとめます。点検員ごとに違っていた所見の並べ方が、変化の区分でそろいます。

2つ目は、kind で地点をまたいだ集計ができることです。 発電所ごとに vegetation の progressed が何地点あるかを数えれば、除草の提案を出す時期の材料になります。 提案するかを決めるのは技術者です。

3つ目は、not_visible で撮り直しの頼み方が具体的になることです。 「B列の西半分が逆光」と出れば、次の点検で撮る時刻を変えればよいと分かります。

response_format の schema には、次のように値を絞った形を入れます（抜粋）。

{
  "type": "object",
  "properties": {
    "point_id": { "type": "string" },
    "candidates": { "type": "array", "items": { "type": "object",
      "properties": {
        "box_2d": { "type": "array", "items": { "type": "integer" }, "minItems": 4, "maxItems": 4 },
        "kind": { "type": "string", "enum": ["crack", "soiling", "bird_droppings", "shading", "vegetation", "corrosion", "missing_bolt", "fence_damage", "sign_missing", "cable_sag", "unclear"] },
        "change": { "type": "string", "enum": ["new", "progressed", "unchanged", "improved", "not_comparable"] }
      },
      "required": ["box_2d", "kind", "change"] } },
    "not_visible": { "type": "array" }
  },
  "required": ["point_id", "candidates", "not_visible"]
}

システムへ連携する

発電事業者へは、この構成から何も送りません。 下書きをそのまま送る経路を作ると、点検員と技術者が見る前の候補が、発電事業者の手元で「異常」として読まれます。

人が確認する

1. 点検員が候補を確かめる … 候補のある写真、new と progressed の候補、not_visible の出た地点を見ます。現地の点検表のメモと照らし、候補を残すか外すかを決めます
2. 点検員が所見を直す … 下書きの言葉を、自社の所見の書き方にそろえます
3. 技術者が程度と修繕の提案を書く … 異常の程度、緊急度、清掃・除草・修繕の提案は、技術者が書きます
4. 外した候補を記録する … 反射を汚れと言った、影を新しいと言った、などの理由を残します

1番目で現地のメモと照らすのは、写真に写らない気づきがあるからです。 異音、異臭、振動は写真に写りません。点検表のメモにある気づきは、AIの候補が無くても所見に残します。

目標は、90件をならして1件20分です。 候補の無い地点は一覧で地点の番号を流し見るだけにし、new と progressed の候補と not_visible の地点に時間を使います。点検員が外す候補が1件で半分を超えるなら、撮影の条件の入れ方か、地点の目印が崩れています。 外した理由を毎週集め、多い理由から直します。

例外に対処する

上から3行目までが大半を占めます。 どれもAIの精度の問題ではなく、写真の組と、撮る位置と時刻の問題です。 地点の目印を決め直すほうが、指示の文をいじるより効きます。

記録を残す

• 発電所と地点の番号ごとの、今回と前回の写真と、Gemini API が返した JSON の全文
• 指示に入れた撮影の条件
• 点検員が外した候補と、その理由
• 技術者が書いた程度と修繕の提案、報告書を送った日
• 地点ごとの not_visible の出方の記録

3つ目が、指示の文を直す材料です。 外した理由で「反射」が多ければ撮影の条件の書き方を、「影」が多ければ時刻の違いの扱いを見直します。