置き配の配達完了写真をAIで点検し、指定場所との違い・写りの不備・表札や部屋番号の写り込みを問い合わせの前に拾う

処理の起点を決める

写真が保管先のコンテナーに保存されたことを起点にします。 Azure Logic Apps の Azure Blob Storage コネクタにはトリガーが用意されており、ロジックアプリの種類で名前と動き方が違います。

組み込みのトリガーを使うときは、既存の写真に注意してください。 何か月分もの写真が入ったコンテナーに設定すると、すべてが一度に判定に回り、費用と確認の一覧が一気に膨らみます。 新しいコンテナーを用意するか、管理されたトリガーを使います。

夕方の集中に追いつくかも見ておきます。 組み込みのトリガーはベストエフォートで大規模な処理には向かないとされ、より速く確実に処理したい場合は Azure Event Grid のトリガーが勧められています。 月3,600枚なら組み込みで足りますが、荷主が増えたら切り替えを検討します。

入力データを集める

質を決めるのは、2つ目と3つ目です。 置き場所の指定が無ければ、写真の場所が合っているかを判定できません。住所の種類が無いと、集合住宅の共用廊下に置かれた荷物を「玄関前」として合っているかが決まりません。

住所そのものと受取人の氏名は渡しません。 判定に要るのは置き場所の種類だけで、誰の家かは要りません。

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

写真は、トリガーのあとに Blob の内容を取得する操作で読みます。管理されたコネクタの操作は50MB以下のファイルを扱い、それを超えると分割での転送が必要になります。 配達完了の写真なら通常は収まります。

写真はURLではなく Base64 で渡します。 公式の説明では、画像のURLは公開されている必要があり、プライベートエンドポイントやファイアウォールで制限されたURLは使えません。 受取人の家が写った写真のURLを公開するわけにはいかないので、中身を取り出して符号化して渡します。

管理されたトリガーには、見張るフォルダーの写真が3万枚までという上限があります。 超えると新しい写真でトリガーが動かないことがあるため、判定が終わった写真は日付ごとのフォルダーへ移します。

AIへ渡す前に整形する

1. 形式の確認 … JPEG、PNG、GIF、WEBP 以外（スマートフォンの HEIC など）は JPEG に変換します
2. サイズの確認 … 20MBを超えるものは縮小します
3. 向きの補正 … 撮影時の向きの情報に従って回転させてから渡します
4. 細部の設定 … detail を high にします
5. 重複の確認 … 同じ荷物で複数枚上がったときは、まとめて1回で判定します（10枚まで）

4番目を軽く見ないでください。 detail を low にすると、512×512の低い解像度で処理され、速く安くなりますが、画像内の物体や文字の認識の精度に影響しうるとされています。表札の文字や部屋番号を拾うのがこの構成の目的なので、ここで費用を削りません。 high では、低い解像度で全体を見たあと512×512の区画ごとに詳しく見ます。

3番目は、写真が横倒しのまま判定されるのを防ぎます。 横倒しの写真では、ドアや表札の文字が読みにくくなります。

AIに処理させる

させるのは、4つの観点で写真を見て、項目ごとに ok ／ ng ／ cannot_judge を付け、根拠を短く書くことだけです。

④の右端が、他の観点と逆向きになっていることに注意してください。 置き場所は迷ったら人に回しますが、写り込みは「読めないが文字らしきものがある」ときも、写っているものとして扱います。 見落としたときの害のほうが大きいからです。

①の判定には、住所の種類を必ず添えます。 戸建ての「玄関前」は門の内側の玄関ドアの前ですが、集合住宅の「玄関前」は共用廊下に面した住戸のドアの前です。同じ「玄関前」でも、写真に写るべきものが違います。 住所の種類を渡さないと、共用廊下の写真を「建物の入口」と取り違え、正しく置いた荷物を ng にします。

3行目がいちばん起きやすい失敗です。 「表札があるか」と聞くと、モデルは親切に「表札に『山田』と書かれています」と答えます。その文字列がログに残った時点で、写真から取り除きたかった情報が、文字として社内に増えます。

指示内容を固定する

あなたは配送センターで、置き配の配達完了写真を点検する担当です。
写真と、この荷物の置き場所の指定だけを見て判定してください。

【この荷物の情報】
置き場所の指定：{place_code}
住所の種類：{address_type}

【点検する4つの観点】
1. place ......... 写真の場所が、置き場所の指定と合っているか
2. handling ...... 宅配ボックスの扉が閉まっているか、通路をふさいでいないか、
                   屋外で地面に直に置かれていないか
3. photo_quality . 荷物が写っているか。ブレや暗さで場所が判別できなくないか
4. exposure ...... 表札の氏名、部屋番号、人の顔、車のナンバー、
                   送り状や郵便物の宛名が写っていないか

【status の選び方】
- ok ............ 問題が無いと写真から言える
- ng ............ 問題があると写真から言える
- cannot_judge .. 写真から判断できない
迷ったときに ok を選ばないでください。

【厳守事項】
- exposure では、文字らしきものが写っていて読めない場合も ng にしてください。
- 表札・部屋番号・宛名・ナンバーに書かれた文字を書き起こさないでください。
  「表札がある」「宛名ラベルがある」のように、種類だけを書いてください。
- 人の顔があっても、その人について説明しないでください。
- 写真に写っていないことを推測しないでください。
  例：荷物が写っていないのに「玄関前に置かれたと思われる」と書かない。
- ドライバーの責任や、盗難のおそれについては書かないでください。
- 置き配の写真でないと判断した場合は、点検せず image_type に種類を書いてください。

【返し方】
指定されたJSONの形だけで返してください。
reason は各20字程度で、写真の中の何を見たかを書いてください。

「文字を書き起こさない」を明記しないと、ほぼ必ず書き起こします。 根拠を書けと言われれば、モデルは見えた文字を根拠として写すのが自然だからです。禁じるのは、根拠の書き方そのものです。

「迷ったときに ok を選ばない」は、写りの観点に効きます。 暗い写真で荷物らしき影があると、何も言わなければ「荷物が写っている」とします。cannot_judge を選べる道を用意し、そちらへ寄せます。

出力形式を固定する

次の形のJSONで受け取ります。 Azure OpenAI の Structured Outputs では、Chat Completions は response_format、Responses は text.format にスキーマを定義し、strict: true を指定します。すべての項目を required に入れ、オブジェクトには additionalProperties: false を付けます。

{
  "image_type": "delivery_proof",
  "checks": {
    "place":         { "status": "ok | ng | cannot_judge", "reason": "" },
    "handling":      { "status": "ok | ng | cannot_judge", "reason": "" },
    "photo_quality": { "status": "ok | ng | cannot_judge", "reason": "" },
    "exposure":      { "status": "ok | ng | cannot_judge", "reason": "",
                       "kinds": ["nameplate | room_number | face | plate | label"] }
  }
}

1つ目の理由は、判定と行き先を別の層に置けることです。 checks はモデルが埋め、行き先は Logic Apps の規則が決めます。

2つ目は、kinds で写り込みの種類だけを持てることです。 何が写っていたかは残し、何と書いてあったかは残しません。 月ごとに kinds を数えれば、送り状が写りやすいのか表札が写りやすいのかが分かり、撮影の決まりのどこを伝え直すかが決まります。

3つ目は、項目の欠けが起きないことです。 公式の説明では、スキーマはオブジェクトのプロパティが合計100個まで、入れ子は5段までで、minLength や pattern などのキーワードは使えません。 上の形はこの範囲に収まります。

システムへ連携する

配送管理システムへの書き込みは、「連携を止める」印だけにします。 配達完了の状態そのものは変えません。AIの判定で配達が未完了に戻るような経路は作りません。

受取人への連絡は、お客様窓口の人が行います。 needs_review から受取人への連絡まで自動でつなぐと、正しく置いた荷物について謝る連絡が出ていきます。

人が確認する

人が開くのは needs_review の写真だけです。 retake はドライバーが撮り直し、pass は件数を見るだけにします。

1. place の ng を先に見る … 受取人への連絡が要る可能性があり、時間がたつほど問い合わせが先に来ます
2. ドライバーに事情を聞く … 指定の宅配ボックスが満杯だった、受取人から直接頼まれた、などの事情を確かめます
3. 受取人に連絡するかを決める … 連絡するならお客様窓口へ回します
4. cannot_judge を見る … 多くは写真の問題で、撮り直しで解決します
5. 判定を覆したら記録する … どの観点を、どちらに変えたかを残します

2番目を省かないでください。 指定と違う置き方の多くには、現場でしか分からない理由があります。 写真だけで是正を求めると、ドライバーは理由を言わなくなります。

目標は、3,600枚をならして1枚0.5分です。 開くのは1〜2割という想定で、それより多い月は、撮影の決まりが伝わっていないか、置き場所のコードが実態と合っていません。

例外に対処する

5行目が運用でいちばん起きます。 撮り直しの依頼が届くまでの時間が長いと、ドライバーは次の配達先に向かっています。依頼が届くまでの時間を毎週測り、遅い時間帯を見つけます。

日没後の写真にも注意します。 冬の夕方以降は、フラッシュを使わない写真が photo_quality の cannot_judge になりやすいと考えられます。判定の基準を緩めるのではなく、撮影の決まりにフラッシュの使い方を足します。

記録を残す

• 元の写真と、変換・縮小した場合はその写真
• 判定に使った置き場所のコードと住所の種類
• モデルが返したJSONの全文と、規則で決めた行き先
• 人が判定を覆した記録 … どの観点を、どちらに変えたか
• 撮り直しの依頼から2枚目が上がるまでの時間
• ドライバーごと・地区ごとの kinds の件数

ログに写り込みの文字は残りません。 指示で書き起こしを禁じ、出力の形も種類だけにしているからです。それでも元の写真には写っているので、写真の保存期間と見られる人は別に決めます。

最後の行は、ドライバーへの声かけの材料になります。 特定のドライバーで送り状の写り込みが続くなら、撮る角度の癖です。 判定を厳しくするより、1回の声かけで直ります。