Concept — 2026.07.26

LINE写真報告システム
収集 → ビジョン分類 → ギャラリー → 報告率

発端: 清掃前後の写真報告を100%に近づけたい。ただし現場の「LINEグループに写真を送る」という今のやり方は一切変えない。その上で、写真の自動格納・AI説明付き分類・カレンダーから飛べるギャラリー・施設別報告率まで一気通貫にする。

1. 最大の発見 — 収集層はすでに完成している

「トークグループにそのまま写真を送れば自動格納される」は、すでに実現済みです。

稼働中のLINE bot(Railway)は、グループに投稿された画像・動画を受信した瞬間に Google Drive(月別 → グループ別フォルダ)へ自動アップロードし、収集GSheetの行に DriveURL・投稿時刻・投稿者・前後メッセージ文脈を記録しています。つまり今この瞬間も、清掃スタッフが送った写真は全て Drive に溜まり続けています。

足りないのは収集ではなく、その先の3層 — ①写真が何なのかをAIが判定する分類層、②溜まった写真を誰でも見られるギャラリー層、③「報告されるべきだった清掃」と突合する報告率層。ここを作れば、現場への追加依頼ゼロでシステムが完成します。

2. 全体アーキテクチャ(4層)

稼働済Layer 1 — 収集
LINE Webhook(Railway bot)→ 画像を Drive へ自動保存 + GSheet に DriveURL・時刻・投稿者・グループを記録。現場の操作は「トークに写真を送る」だけ。変更なし。
新規Layer 2 — ビジョン分類
日次バッチ(BLADEルーティン)が新着写真を Gemini Flash に渡し、施設・カテゴリ(清掃前 / 清掃後 / チェックアウト後 / 破損・不具合 / 備品 / その他)・1行説明・部屋/エリア推定 を JSON 化。時刻・カレンダーの清掃予定・前後のLINEメッセージ文脈も判定材料に使う。
新規Layer 3 — ギャラリー
クリーナーカレンダー(cleaner-minamiboso 等)から1クリックで飛べる写真ページ。左カラム=日付・施設・タグの目次、右カラム=Lightroom的な全量グリッド(デフォルト全表示)。「施設の正しい完成形」タグの基準ギャラリーも併設。URLを知る人は誰でも閲覧可(カレンダーと同じ思想)。
新規Layer 4 — 報告率
AirHost予約データから「この日この施設でOUT清掃があったはず」を分母に、清掃前後の写真報告が揃った清掃を分子にして施設別・月別の写真報告率%を算出。ギャラリーページ上部にスコアカード表示。

3. 各層の設計 — 推奨と捨てた案

分類層: 日次バッチ + Gemini Flash(推奨)

既存の photo_pipeline(リサイズ→Gemini並列分類)の資産をほぼ流用できます。リアルタイム分類(Webhook時に即ビジョン)は捨てました — 報告率やギャラリーは日次で十分で、Railway側に処理を足すと bot 本体の安定性リスクとコストが上がるためです。緊急性のある破損報告はすでにテキストのキーワード検知(Slackアラート)が担っています。

清掃前/後の判定: 3つの手がかりで自動推定(推奨)

現場に「#前 と付けて送って」等の新ルールを課す案は捨てました — 「今のやり方を変えない」が本件の第一条件であり、ルールを課した瞬間に報告率の敵(面倒くささ)を自ら作ることになるためです。自動推定の精度が実測で不足したら、その時に最小のルールを検討します。

ギャラリー層: カレンダーと同じ Cloudflare Pages 構成(推奨)

クリーナーカレンダーの実証済みパターン(build.py で静的生成 + KV + 日次自動デプロイ)をそのまま拡張します。画像本体は Drive に置いたまま、Drive のサムネイルURLで表示(botが既に共有権限を付与済み)— 画像を二重コピーしない。Googleフォトや専用ストレージへの移設案は捨てました(既に Drive で動いている流れを壊す理由がない)。

データの持ち方

分類結果は photos.json(写真1枚=1レコード: DriveURL・施設・日付・カテゴリ・AI説明・投稿者)としてビルドに同梱。SoTは収集GSheet+分類JSONで、ギャラリーHTMLは生成ビュー — ホーム決定ルール準拠です。

4. LINEの制約と運用ライン

LINEアルバムへの追加は bot に流れません。LINE Messaging API の仕様上、Webhook が受け取れるのは「トークへの直接送信」のみで、アルバム作成・アルバムへの追加・ノート投稿はイベントとして取得できません。

ただしこれはむしろ追い風です — 「アルバムを作らなくても、トークにそのまま送れば全部自動で整理される」が正式運用になれば、アルバム作成の手間そのものが不要になります。ギャラリーが検索性でアルバムを完全に上回るので、自然に移行が進む構図です。既存アルバムの過去写真は、必要になった施設だけ手動一括エクスポート→Drive投入で救済できます(Phase 3以降の任意作業)。

5. 段階展開

Phase内容成果物
1. 南房総で試走分類バッチ+ギャラリーページを Sun Terrace Cove 1施設で構築。既存カレンダーにリンクを追加。過去数ヶ月分の蓄積写真も遡って分類。カレンダー→ギャラリー導線が動く実物
2. 報告率の可視化OUT清掃×写真突合ロジックを実装し、施設別報告率%をギャラリー上部に表示。判定精度を実データで検証。報告率スコアカード
3. 全施設横展開bot の GROUP_CONFIGS に各施設グループを登録(登録するだけで収集開始)。ギャラリーを施設切替対応に。「正しい完成形」基準タグ付け。全施設ギャラリー+横断報告率

全社視点では、これは南房総1施設の道具ではなく「LINEに流れる現場の事実を構造化する共通基盤」の写真版です。テキスト側(7カテゴリ分類・日次サマリー)と対になり、月次オーナーレポートの設備対応写真・清掃品質エビデンスにもそのまま流用できます。コスト側は Gemini Flash で100枚≒10円、Drive追加コストなし、Pages無料枠内 — ランニングはほぼゼロです。

6. 判断のお願い

🔵 現場への周知の仕方(関係者への態度に関わるためお伺い)

システム側は現場の操作変更ゼロで動きますが、「アルバムを作らなくても、トークに送るだけでOK」を現場にいつ・どう伝えるかだけはOtakeさんの判断です。

A) Phase 1 が動いてギャラリーURLを見せられる状態になってから伝える(推奨) — 実物を見せながら「送るだけで全部ここに載る」と言える/ B) 今から先行して「写真報告をトークに送る運用」を口頭で強化しておく / C) 周知せず自然に任せる。
無回答なら A で進めます。

YAMATO Operations — LINE写真報告システム構想 v1 / 2026-07-26 / 実装エンジン: 既存 line_bot (Railway) + photo_pipeline + minamiboso_calendar パターン流用