Media > AI活用ユースケース > カスタマーサポート > レンタカーの返却時に撮った車体の写真を貸出時の写真と比べ、新しい傷・へこみの候補を拾って、確認と精算の記録の下書きを作る

レンタカーの返却時に撮った車体の写真を貸出時の写真と比べ、新しい傷・へこみの候補を拾って、確認と精算の記録の下書きを作る

実装ステータス:構成例 技術的に実現可能な構成として設計したもの。自社未検証

レンタカーの返却の立会いで撮った車体の写真を、同じ角度の貸出時の写真と既存の傷の記録と比べ、新しい傷・へこみ・割れの候補を位置付きで拾います。借受人と一緒に確かめるための一覧と、返却点検の記録の下書きを作ります。

サマリー
生成AI
ChatGPT/Claude/Gemini
連携・自動化
Google Apps Script/Python
対象業界
その他
対象部門
カスタマーサポート
対象業務
内容確認・チェック/記録・議事録作成
主な課題
人手が足りない/判断に時間がかかる/確認ミスが多い
AIで行う処理
画像認識
主な効果
品質標準化/対応スピード向上/工数削減
導入難易度
★★★☆☆
実装レベル
半自動化
費用感
API連携(中)
人間の確認
条件付き
現在工数
120h/月
AI導入後
40h/月
想定削減
67%
年間削減
960h
モデル条件による試算値です。実在企業の実績ではありません。

01導入前 / 導入後の業務フロー

導入前(Before)
  1. 借受人が車を返しに来る。担当者が貸渡の番号で管理システムを開く
  2. 担当者が決まった8つの角度から車体の写真を撮る
  3. 紙の点検表の傷の図を見ながら車を一周し、図に無い傷を探す
  4. 気になる箇所があれば、タブレットで貸出時の同じ角度の写真を開き、その箇所が貸出時にもあったかを見比べる
  5. 新しい傷があれば、借受人と一緒に確かめ、点検表に書き込み、写真を撮り足す
  6. 返却点検の結果を管理システムに入れる。新しい傷があれば店長に回す
  7. 店長が、料金表と補償制度に照らして精算を判断し、借受人に説明する
導入後(After)
  1. 人借受人が車を返しに来る。担当者が貸渡の番号を入れ、決まった8つの角度から写真を撮る
  2. 自動写真がそろうと、Python のプログラムが同じ貸渡の番号の貸出時の8枚と、車両の既存の傷の記録を取る
  3. 自動角度ごとに、貸出時と返却時の写真の組を Gemini API に渡す
  4. 【AI】 角度ごとに、新しい傷の候補(位置・種類)、既存の記録と同じ場所の傷、比べられなかった範囲とその理由を返す
  5. 自動プログラムが、候補の位置に枠を描いた写真と、候補の一覧をタブレットに出す
  6. 人担当者は、AIの結果を待つ間に車内・燃料・付属品を確かめる
  7. 人担当者が、候補の場所と比べられなかった箇所を、借受人と一緒に車体で確かめる
  8. 人担当者が、候補ごとに「傷あり(新規)」「既存」「傷ではない(汚れ・映り込み)」を選ぶ
  9. 自動選んだ結果から、返却点検の記録の下書きと、店長に回す確認事項を作る
  10. 人担当者が記録を確定する。新しい傷があれば、店長が精算を判断する
各工程の詳しい説明を読む
  1. 借受人が車を返しに来る。担当者が貸渡の番号で管理システムを開く
  2. 担当者が決まった8つの角度から車体の写真を撮る
  3. 紙の点検表の傷の図を見ながら車を一周し、図に無い傷を探す
  4. 気になる箇所があれば、タブレットで貸出時の同じ角度の写真を開き、その箇所が貸出時にもあったかを見比べる
  5. 新しい傷があれば、借受人と一緒に確かめ、点検表に書き込み、写真を撮り足す
  6. 返却点検の結果を管理システムに入れる。新しい傷があれば店長に回す
  7. 店長が、料金表と補償制度に照らして精算を判断し、借受人に説明する

(a)見比べが記憶に頼る。 4番目は「気になる箇所があれば」の手順で、気にならなければ貸出時の写真は開きません。 バンパーの角の小さな擦り傷は、急いで一周すると目に入りません。

(b)既存か新しいかの判断に時間がかかる。 傷を見つけても、それが貸出時にあったかは、貸出時の写真を拡大して同じ場所を探さないと分かりません。 角度が少し違うと、同じ場所を見つけるのに1分を超えます。借受人を待たせているので、判断を急ぎます。

(c)後で見つけた傷はもめる。 立会いで見落とし、洗車のときに見つけた傷は、借受人がその場にいないので確かめようがありません。 返却後の連絡で「返したときには無かった」と言われると、写真を見せても話がこじれます。

(d)比べられない返却がある。 夜間や雨天の返却は、写真に水滴や映り込みが入り、写真で比べること自体ができません。 その場合は目で見るしかないのに、写真を撮ったことで確認した気になることがあります。

  1. 【人】 借受人が車を返しに来る。担当者が貸渡の番号を入れ、決まった8つの角度から写真を撮る
  2. 【自動】 写真がそろうと、Python のプログラムが同じ貸渡の番号の貸出時の8枚と、車両の既存の傷の記録を取る
  3. 【自動】 角度ごとに、貸出時と返却時の写真の組を Gemini API に渡す
  4. 【AI】 角度ごとに、新しい傷の候補(位置・種類)、既存の記録と同じ場所の傷、比べられなかった範囲とその理由を返す
  5. 【自動】 プログラムが、候補の位置に枠を描いた写真と、候補の一覧をタブレットに出す
  6. 【人】 担当者は、AIの結果を待つ間に車内・燃料・付属品を確かめる
  7. 【人】 担当者が、候補の場所と比べられなかった箇所を、借受人と一緒に車体で確かめる
  8. 【人】 担当者が、候補ごとに「傷あり(新規)」「既存」「傷ではない(汚れ・映り込み)」を選ぶ
  9. 【自動】 選んだ結果から、返却点検の記録の下書きと、店長に回す確認事項を作る
  10. 【人】 担当者が記録を確定する。新しい傷があれば、店長が精算を判断する

7番目と8番目が、この設計の分かれ目です。 AIは傷を決めず、担当者が借受人と一緒に車体を見て決めます。 候補の位置が示されているので、一周しながら探す時間が、示された場所を見る時間に変わります。

6番目で待ち時間を使うのも、意図してのことです。 写真を送ってから結果が返るまでには待ち時間が出ます。その間に、写真で比べない車内と燃料を見ておけば、借受人を余計に待たせません。

02今回想定するシステム構成

構成図
返却の立会い(タブレットで8つの角度を撮影、貸渡の番号を入力)
   ▼【トリガー】8枚がそろったとき
Python のプログラム(社内のサーバー)
   ├── 貸渡の管理システムから既存の傷の記録を取る
   ├── 写真の保管先から、同じ貸渡の番号の貸出時の8枚を取る
   ├── 写真の向きを直し、縮小する
   ▼
Gemini API(画像理解・構造化出力)── 角度ごとに貸出時と返却時の組を渡す
   │   新しい傷の候補(返却時の写真の枠)
   │   既存の記録と同じ場所の傷
   │   比べられなかった範囲と理由
   ▼
Python ── 枠を描き、候補の一覧をタブレットに出す
   ▼
【人】担当者が借受人と一緒に車体で確かめ、候補ごとに結果を選ぶ
   ▼
返却点検の記録の下書き / 店長への確認事項
役割想定する製品代替候補
処理Gemini API(貸出時と返却時の写真を比べ、新しい傷の候補と位置を返す)Claude API、OpenAI API
連携Python(写真と記録の取得、前処理、呼び出し、枠の描画、記録の下書き)Google Apps Script
台帳貸渡の管理システム(既存の傷の記録、返却点検の結果)-
端末立会い用のタブレット(撮影と確認の画面)スマートフォン

新しく足すのは、Python のプログラムと Gemini API の契約だけです。 タブレットで写真を撮る運用も、写真の保管先も、貸渡の管理システムも、すでにあるものです。管理システムへの書き込みは、担当者が確定した後の記録だけにします。

写真を見る土台は、Gemini API の画像理解です。 対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、画像を直接入れる場合はリクエスト全体が20MBまでです。1つのリクエストに複数の画像を入れられるので、貸出時と返却時の同じ角度の2枚を組にして渡します。

位置は、返却時の写真の上の枠で返させます。 公式の案内では、物体を検出させて枠を返させることができ、座標は画像の大きさに対して 0〜1000 に正規化されるため、元の大きさに戻して使います。例では [ymin, xmin, ymax, xmax] の順です。枠があれば、担当者は車体のどこを見ればよいかがすぐ分かります。

出力は構造化出力で受けます。 response_format で mime_type を application/json にし、schema にスキーマを入れ、/v1beta/interactions に送ります。enum で値を決まった文字列に絞れます。構文として正しい JSON でも、値はアプリ側で検証するよう書かれています。

立会いのもとで返すことは、約款の前提でもあります。 国土交通省の地方運輸局が示す貸渡約款の参考様式では、借受人は会社の立会いのもとでレンタカーを返還し、通常の使用によって摩耗した箇所等を除き、引渡し時の状態で返還するとされています。貸出のときには、点検表に基づく車体外観の検査で借受人が確かめるとされています。この構成は、引渡し時の状態と返還時の状態を比べる作業を手伝うものです。

03どうやって実装するのか

Step1

処理の起点を決める

返却の立会いで、8つの角度の写真がそろったときに動きます。 タブレットの撮影の画面で、貸渡の番号を入れて8枚を撮り終えると、写真の保管先の返却用のフォルダに入り、プログラムが動きます。

8枚そろわないうちは動かしません。 1枚ずつ送ると、比べる組がそろわないまま候補が出て、担当者が途中の結果を見て判断してしまいます。

営業所の閉店後に鍵だけを返す返却は、この構成の対象外です。 立会いが無く、候補を借受人と確かめられないからです。写真は翌朝の担当者が撮り、比べの結果は社内の記録として残しますが、借受人と確かめた記録にはなりません。

撮り直しのときは、その角度だけを差し替えて、もう一度動かします。 雨粒が多い、角度が大きくずれた、と担当者が判断したら、撮り直した角度の組だけを比べ直します。

Step2

入力データを集める

データ中身取得元
返却時の写真8つの角度。ファイル名に角度のラベル(前・左前 など)と撮影時刻タブレット → 写真の保管先
貸出時の写真同じ貸渡の番号の8つの角度写真の保管先
既存の傷の記録車両ごとの既存の傷。部位(左前のバンパーの角 など)、種類、大きさの目安、記録した日貸渡の管理システム
撮影の条件屋内か屋外か、昼か夜か、雨か担当者が撮影の画面で選ぶ
傷の種類の一覧擦り傷、線傷、へこみ、割れ、塗装のはがれ、ガラスの欠けプログラムに持たせる

質を決めるのは、貸出時の写真が同じ角度で撮れているかです。 貸出時の左前の写真が、返却時の左前より車から遠く、斜めに撮られていると、同じ場所を比べられません。 撮る位置を床の印で決めておくのがいちばん効きます。

既存の傷の記録は、AIの判定を助けるために渡します。 「左前のバンパーの角に擦り傷(以前から)」と記録があれば、返却時の写真のその場所の傷を、新しい傷の候補から外して「既存の記録と同じ場所」として返させられます。記録の無い車両では、貸出時の写真だけが頼りになります。

Step3

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

貸出時の写真は、貸渡の番号で写真の保管先から取ります。 貸出のときも同じ8つの角度のラベルで保存しているので、ラベルで組にします。

既存の傷の記録は、貸渡の管理システムから車両番号で取ります。 API で取れない場合は、管理システムから毎朝、車両ごとの既存の傷の一覧を書き出し、プログラムが読む場所に置きます。貸出の後に記録が変わることは少ないので、毎朝の書き出しで足ります。

Gemini API へは、角度ごとに1回、貸出時と返却時の2枚を組にして渡します。 8回の呼び出しを並べて行います。8枚と8枚を1回でまとめて渡すこともできますが、角度ごとに分けると、どの組で比べたかがはっきりし、撮り直しのときにその角度だけを比べ直せます。

有料の利用枠で使います。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。

Step4

AIへ渡す前に整形する

  1. 形式と向き … PNG、JPEG、WEBP、HEIC、HEIF のどれかであることを確かめ、画像の向きの情報で回転しているだけのものは画素を回転させます。向きが合っていないと、返った枠の位置がずれます
  2. 縮小 … 長い辺を1,600ピクセル程度に縮めます。小さな擦り傷を見るため、縮めすぎない大きさを最小構成で確かめて決めます
  3. 組の確認 … 8つの角度のラベルがそろっているか、貸出時の同じラベルの写真があるかを見ます。組がそろわない角度は、AIに渡さず「比べられない(貸出時の写真なし)」と決めます
  4. 撮影の条件の付け足し … 貸出時と返却時の撮影の条件(屋内/屋外、昼/夜、雨)を指示に入れます。条件が違うことを知らせておくと、映り込みを傷の候補にしにくくなります
  5. 既存の傷の記録の整え … 部位の名前を、8つの角度のどの写真に写るかで振り分けます。「左前のバンパーの角」は左前と前の写真に写ります
  6. 人の映り込みの確認 … 車体の写真に借受人や通行人が写り込んでいれば、その写真は撮り直します。車体だけが写るように撮る位置を決めておきます

4番目を軽く見ないでください。 照明の映り込みや雨粒は、写真の上では細い線や点に見えます。貸出時が屋内、返却時が屋外の雨なら、その差を前提に比べさせます。

Step5

AIに処理させる

させるのは、角度ごとに貸出時と返却時の写真を比べ、返却時の写真にあって貸出時の写真に無い傷の候補を枠で返し、比べられなかった範囲を返すことだけです。

返すもの中身判断できないときの扱い
新しい傷の候補返却時の写真の枠、傷の種類、貸出時の写真の同じ場所の様子汚れか傷か分からなければ unclear として候補に入れる
既存の記録と同じ場所既存の傷の記録のどれと同じ場所か同じ場所か分からなければ新しい傷の候補として返す
比べられなかった範囲写真のどの範囲が、なぜ比べられなかったか(雨粒、映り込み、角度のずれ、暗さ)範囲がはっきりしなければ角度ごと「比べられない」

右端の列の考え方は、迷ったら人に見せる側に倒すことです。 汚れか傷か分からないものは候補に入れ、同じ場所か分からない既存の傷は新しい候補として返させます。候補が多すぎるのは担当者の数秒で済みますが、候補から落ちた傷は誰も見ません。

させないこと理由
傷かどうかの確定写真では汚れ・映り込みと区別できないことがある。車体で人が見る
使用中に付いたかの判断貸出時の写真の写り方で見えなかっただけのことがある
通常の使用による摩耗かの判断約款で除かれる部分。営業所と店長が判断する
修理費・営業補償の金額料金表と補償制度で店長が決める
借受人への説明文精算の説明は店長が行う
「傷なし」の結論比べられなかった範囲がある限り言えない

2行目がいちばん起きやすい失敗です。 貸出時の写真が明るすぎて傷が飛んでいただけの場所を、返却時に「新しい傷」と言い切ると、借受人に使用中の傷として伝わります。 AIが出すのは「返却時の写真にあって、貸出時の写真では見えない」という事実までにします。

Step6

指示内容を固定する

あなたはレンタカーの返却の立会いを手伝う係です。
同じ車を同じ角度から撮った2枚の写真があります。
1枚目は貸し出したときの写真、2枚目は返却されたときの写真です。

【撮影の条件】
貸出時:{屋内/屋外、昼/夜、雨の有無}
返却時:{屋内/屋外、昼/夜、雨の有無}

【この角度に写る既存の傷の記録】
{部位、種類、大きさの目安}

【やること】
1. 2枚目にあって、1枚目では見えない傷・へこみ・割れ・塗装のはがれの候補を探す。
2. 候補ごとに、2枚目の写真の上の枠を [ymin, xmin, ymax, xmax] の順で、
   0〜1000 に正規化して返す。種類と、1枚目の同じ場所の様子も書く。
3. 既存の傷の記録と同じ場所の傷は、新しい候補ではなく existing として返す。
4. 雨粒、映り込み、暗さ、角度のずれで比べられなかった範囲を、理由とともに返す。

【厳守事項】
- 傷かどうか確定しないでください。汚れか傷か分からないものは、
  kind を unclear にして候補に入れてください。
- 既存の記録と同じ場所か分からない傷は、新しい候補として返してください。
- 「使用中に付いた」「借受人の責任」「摩耗」とは書かないでください。
  あなたが返すのは、2枚目にあって1枚目では見えないという事実だけです。
- 比べられなかった範囲がある場合、その範囲について「傷なし」と書かないでください。
- 修理の要否、費用、補償については書かないでください。
- 車体以外(人、背景、ナンバー以外の掲示物)については書かないでください。

「使用中に付いた」と書かせない一文は、表現の問題ではありません。 記録の下書きにこの言葉が載ると、担当者が確かめる前に、借受人への説明の言葉として使われてしまいます。 AIの出力から、責任に関わる言葉を最初から外しておきます。

「既存の記録と同じ場所か分からなければ新しい候補に」は、第7章の「迷ったら人に見せる側」を指示にしたものです。 既存の傷のすぐ隣に新しい傷が付くことは珍しくなく、既存と思って見過ごした場所が、実は広がっていたということが起きます。

Step7

出力形式を固定する

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

{
  "angle": "left_front",
  "candidates": [
    {
      "box_2d": [610, 120, 700, 260],
      "kind": "scratch | line_scratch | dent | crack | paint_peel | glass_chip | unclear",
      "checkout_view": "貸出時の写真では同じ場所に線は見えない",
      "note": ""
    }
  ],
  "existing": [
    { "record_id": "", "box_2d": [580, 80, 640, 160], "note": "記録の擦り傷と同じ場所" }
  ],
  "not_comparable": [
    { "area": "フロントガラスの上半分", "reason": "rain | reflection | dark | angle_mismatch | no_checkout_photo" }
  ]
}

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

{
  "type": "object",
  "properties": {
    "angle": { "type": "string", "enum": ["front", "rear", "left_front", "left_rear", "right_front", "right_rear", "left_side", "right_side"] },
    "candidates": { "type": "array", "items": { "type": "object",
      "properties": {
        "box_2d": { "type": "array", "items": { "type": "integer" }, "minItems": 4, "maxItems": 4 },
        "kind": { "type": "string", "enum": ["scratch", "line_scratch", "dent", "crack", "paint_peel", "glass_chip", "unclear"] },
        "checkout_view": { "type": "string" }
      },
      "required": ["box_2d", "kind", "checkout_view"] } },
    "not_comparable": { "type": "array" }
  },
  "required": ["angle", "candidates", "not_comparable"]
}

not_comparable を required に入れるのは、空でもよいから必ず返させるためです。 項目ごと省かれると、比べられなかったのか、比べられない範囲が無かったのかが区別できません。

1つ目の理由は、not_comparable を独立して持てることです。 比べられなかった範囲は、タブレットの画面で灰色の網掛けとして出します。担当者は、網掛けの範囲を目で見ます。候補が無いことと、比べられなかったことが、画面の上で別のものとして見えます。

2つ目は、担当者の選んだ結果をそのまま記録にできることです。 候補ごとに、担当者が「傷あり(新規)」「既存」「傷ではない」を選ぶと、プログラムが返却点検の記録の下書きを作ります。

【返却点検の記録(下書き)】
貸渡番号:R-2026-10-14-0123 車両:〇〇〇(登録番号の下4けた 1234)
確認日時:2026-10-14 17:42 確認者:(担当者名) 立会い:借受人ご本人
新しい傷:1件
  ・左前のバンパーの角 線傷 約5cm(担当者が車体で確認、借受人と確認済み)
    根拠写真:返却時 左前(枠1)/貸出時 左前
既存の傷:1件(記録どおり)
比べられなかった範囲:フロントガラスの上半分(雨)→ 担当者が目視で確認、異常なし
店長への確認事項:新しい傷1件の精算の扱い

下書きの「借受人と確認済み」は、担当者が画面で選んだときだけ入ります。 AIの出力から自動で入る項目ではありません。

プログラムは値を検証します。box_2d が 0〜1000 に収まり、上下・左右の順が逆でないか、angle が渡した角度と同じかを確かめ、外れたものは画面に「位置不明の候補」として出します。

Step8

システムへ連携する

つなぎ先方式内容
タブレットの撮影の画面写真の保管先に保存8つの角度の写真と撮影の条件
写真の保管先Python が読む貸出時と返却時の写真
貸渡の管理システム既存の傷の記録を読む/確定した記録だけを書く車両ごとの既存の傷、返却点検の結果
Gemini APIInteractions の REST 呼び出し角度ごとの候補・既存・比べられない範囲
タブレットの確認の画面Python が作る枠と網掛けを描いた写真、候補の一覧、結果を選ぶボタン
店長への知らせ社内のチャット新しい傷があった返却の確認事項

管理システムに書くのは、担当者が確定した記録だけです。 AIの候補をそのまま既存の傷の記録に足すと、汚れや映り込みが傷として残り、次の貸出で借受人に「前からある傷」として見せることになります。

新しい傷が確定したら、既存の傷の記録に足すのは、修理するかどうかが決まった後にします。修理するなら、修理後に記録から外します。

Step9

人が確認する

担当者が、借受人と一緒に車体で確かめます。

  1. 候補の場所を車体で見る … 枠の場所に行き、傷か、汚れか、映り込みかを見ます。汚れなら拭いて確かめます
  2. 網掛けの範囲を目で見る … 比べられなかった範囲は、AIは何も言っていません。ここを見ないと、雨の日の返却は確認が抜けます
  3. 候補ごとに結果を選ぶ … 「傷あり(新規)」「既存」「傷ではない」。新規なら、大きさの目安と、近くで撮り足した写真を付けます
  4. 借受人と確かめたことを記録する … 借受人に見せたかどうかを選びます
  5. 新しい傷は店長に回す … 精算の扱いは店長が決めます

2番目を省かないでください。 雨の日や夜の返却では、網掛けの範囲が広くなります。AIの候補が0件でも、網掛けの範囲が広ければ、それは「確かめられていない」という結果です。

借受人には、枠を描いた返却時の写真と、同じ角度の貸出時の写真を並べてタブレットで見せます。 見せるのは担当者が車体で確かめた後です。確かめる前に枠だけを見せると、汚れの枠まで「傷があると言われた」と受け取られます。 「傷ではない」と選んだ候補の枠は、借受人に見せる画面から消します。

目標は、1,200件をならして1件2分です。 候補が0〜1件で網掛けの少ない返却は1分ほど、候補の多い返却や雨の日は数分かかります。

Step10

例外に対処する

起きること対応
貸出時の写真が無い・角度が足りないその角度は no_checkout_photo。担当者が点検表の図で確かめる
貸出時と返却時の角度が大きく違うangle_mismatch。撮り直すか、その角度は目で見る
雨・夜で網掛けが大半写真の比べは補助にとどめ、担当者が一周して見る
候補が多すぎる(汚れた車)汚れの多い範囲を目で見る。洗車後に撮り直す運用も検討する
box_2d が範囲外・順が逆「位置不明の候補」として出し、その角度を目で見る
API が応答しない・上限に当たるこれまでどおりの立会い(点検表の図と目視)に戻る
借受人が急いでいて確認に立ち会えない立会いが無かったことを記録し、写真と候補を保存する
返却後の洗車で傷が見つかった返却時の写真と候補・網掛けを見て、立会いのときに比べられていたかを確かめる
写真に人が写り込んだ撮り直す

「API が応答しない」ときに、これまでの立会いに戻れることが前提です。 この構成は立会いの手順を補助するもので、AIが止まっても返却は受けられるようにしておきます。

Step11

記録を残す

  • 貸渡の番号、角度ごとの貸出時と返却時の写真、撮影の条件
  • AIが返した JSON の全文(候補・既存・比べられなかった範囲)
  • 担当者が候補ごとに選んだ結果と、撮り足した写真
  • 借受人と確かめたかどうか、確かめた日時
  • 店長の精算の判断(AIの記録とは分けて残す)
  • 角度ごとの網掛けの割合

2つ目と3つ目を並べて残すのは、後で問い合わせがあったときのためです。 「返却のときに何が候補に出て、担当者がどう判断したか」が残っていれば、洗車の後に見つかった傷が、立会いのときに比べられていた範囲かどうかを確かめられます。

最後の行は、撮り方を直す材料になります。 特定の営業所の、特定の角度だけ網掛けが多いなら、照明か撮る位置に理由があります。

04実装レベルの3段階

最小構成:短いスクリプトで角度ごとの2枚を送り、候補と網掛けを返させる / 写真の比べ
半自動化:上記+8枚がそろうとプログラムが動き、枠と網掛けをタブレットに出し、選んだ結果から記録の下書きを作る / 比べ・候補の提示・記録の下書き
本格構成:上記+貸出の段でも同じ比べを行い、前回の返却時の写真と貸出時の写真の差を整備担当に知らせる / 貸出と返却の両方の比べ

最小構成では、立会いの場で使えません。 結果が出るまでに手で並べる手間があり、借受人を待たせます。確かめるための段階です。 半自動化が、本記事の想定です。 1件6分が2分になるのはこの段階です。車を一周して探す3分と、貸出時の写真を開いて見比べる2分が、示された場所と網掛けを見る時間に変わります。 本格構成は、修理が追いついているかを見る段です。 前回の返却で確定した新しい傷が、次の貸出までに修理されたか、既存の傷として記録されたかを確かめられます。

05工数削減シミュレーション

前提値(モデル条件)
対象人数
10 名
月間件数
1,200 件
1件あたり現在時間
6 分
1件あたり導入後時間
2 分
現在  1,200件 × 6分 ÷ 60 = 120 時間/月
導入後 1,200件 × 2分 ÷ 60 = 40 時間/月
月間削減時間
80h
削減率
67%
年間削減時間
960h
年間金額換算(時間単価2,500円)
240万円
モデル条件による試算であり、実際の効果は業務内容・運用方法によって異なります。

自社条件で導入効果を整理したい方へ

このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。

AI活用について相談する

06向いている企業・向いていない企業

向いている
  1. 貸出と返却のときに車体の写真を撮る運用をすでに持ち、返却の立会いで、紙の点検表の傷の図と貸出時の写真を見比べて新しい傷を探しているレンタカーの営業所。週末や連休の夕方に返却が集中し、立会いが急ぎになって傷の見落としや、後から見つけた傷で借受人とのやり取りがこじれることがある場合。車両ごとの既存の傷の記録をデータで持てる場合。
向いていない
  1. 貸出時の写真を撮っていない、または撮る角度が決まっていない場合(比べる相手がありません)。返却が無人の受け渡しで、立会いの場で借受人と確かめられない場合。屋外で夜間・雨天の返却が大半で、写真の写りで比べられない場合。なお、傷が使用中に付いたものか、通常の使用による摩耗か、営業補償や修理費を請求するか、補償制度の対象かの判断は、この構成では代替できません。

07最小構成で試す方法

  1. 先月の返却から30件を選ぶ(うち数件は、返却の後に傷が見つかったものを入れる)
  2. 30件の貸出時と返却時の8枚ずつと、既存の傷の記録を用意する
  3. 有料の枠の Gemini API に、角度ごとの2枚と第7章の指示を送る短いスクリプトで、候補と網掛けの範囲を返させる
  4. 返った候補と、実際の立会いの記録・後で見つかった傷を並べる
  5. 汚れや映り込みを候補にした数と、比べられなかった範囲を「傷なし」にしていないかを数える

30件は必ずやってください。 プログラムを組む前に、「同じ角度の2枚で、新しい傷の候補を拾えるか」を確かめます。

出てきた内容判断
後で見つかった傷が候補に出ていたタブレットの画面とつなぐ段に進む
汚れや映り込みが候補に多い候補が多い分には構成は有効。撮影の条件の書き方で減らす
雨の日の写真で「傷なし」と言い切った指示の厳守事項で直る。網掛けを必ず返させる
角度がずれて比べられない組が多い撮る位置の印が先。 AIの問題ではない

4行目が出ることは珍しくありません。 写真は撮っていたのに、比べられる写真ではなかったということです。床に撮る位置の印を付け、次の月の写真で試し直してください。

08実装時につまずきやすいポイント

問題対策
比べられなかった範囲が「傷なし」になるnot_comparable を必ず返させ、画面で網掛けにする
映り込み・雨粒が傷の候補になる撮影の条件を指示に入れる。候補が多い分は人が数秒で外す
既存の傷の隣の新しい傷が見過ごされる同じ場所か分からなければ新しい候補にする
「使用中に付いた」と書かれる責任に関わる言葉を指示で禁じる
角度がずれて比べられない床に撮る位置の印を付ける
枠が別の場所に描かれる画素を回転させてから渡し、座標を元の大きさに戻す
AIの候補を既存の傷の記録に足す担当者が確定したものだけを記録する
結果を待つ間に借受人を待たせる待ち時間に車内・燃料・付属品を見る手順にする
API が止まると返却が止まるこれまでの立会いに戻れる手順を残す
無料の枠で業務の写真を送る有料の枠だけで使う

上の2行が、この構成の失敗のほとんどです。 どちらも「写真で比べられることと、比べられないこと」の区別から出ています。網掛けを画面に出すかどうかで、雨の日の確認が残るかが決まります。

09セキュリティ・AIガバナンス上の注意点

この構成で扱うデータ: 車体の写真、車両の登録番号、貸渡の番号、既存の傷の記録、返却点検の結果です。借受人の氏名・免許証の情報は、AIに渡しません。 写真に人が写り込んだものは撮り直します。

  1. 有料の枠で使う … Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています
  2. 借受人の情報を渡さない … 比べに要るのは写真と既存の傷の記録だけです。貸渡の番号で写真を引き、氏名は渡しません
  3. AIの候補を借受人への説明に使わない … 説明するのは、担当者が車体で確かめた傷だけです。「AIが傷と判定した」という説明はしません
  4. 精算の判断を分ける … 約款の参考様式では、使用中の事故・汚損などで会社が車両を使えない場合の損害は料金表の定めによるとされています。どの傷にどの定めを当てるかは、料金表と補償制度を見て店長が判断します
  5. 立会いの記録を残す … 借受人と確かめたかどうか、確かめられなかった範囲をどう見たかを残します。後の問い合わせで、記録が無い部分は説明できません
  6. 写真の保存期間を決める … 貸出と返却の写真を、いつまで残すかを決めます

誤りが起きた場合のリスクは、新しい傷を見落とすことと、無かった傷を借受人の責任のように伝えることの2つです。 前者は比べられない範囲を「傷なし」にすると起き、後者はAIの候補を確かめずに説明に使うと起きます。網掛けと、担当者が車体で確かめる手順で、両方を止めます。

10まず何から始めるか

1週目:撮る位置と角度をそろえる

貸出と返却の場所の床に、8つの角度の撮る位置の印を付けます。写真のファイル名に角度のラベルを付ける決まりを、タブレットの撮影の画面に入れます。屋外の営業所は、照明の位置も見直します。

2週目:30件で試す

先月の返却30件の写真で、角度ごとの候補と網掛けを返させます。比べられなかった範囲を「傷なし」にしていないか、後で見つかった傷が候補に出ていたかを最優先で見ます。

3週目:既存の傷の記録をそろえる

保有車両の既存の傷を、部位の名前と角度でそろえて管理システムに入れます。記録の無い車両から、貸出のときに順に入れていきます。

4週目:1営業所でつなぐ

1つの営業所で、8枚がそろうとプログラムが動き、タブレットに枠と網掛けが出るところまで作ります。この時点では、担当者はこれまでどおり一周して見たうえで、候補と比べます。

2か月目: 候補と網掛けの場所を見る手順に切り替え、候補ごとの結果と網掛けの割合を毎週数えます。3か月目以降: 営業所を広げ、1件6分が何分になったかを実測し、返却の後に見つかる傷の数を見ます。どの営業所でも網掛けが少なく、日曜の夕方にも同じ確認ができるようになった時点で、この構成は完成です。


11関連ユースケース

12この仕組みを理解するための記事

13技術仕様の確認日・参考情報

技術仕様確認日:2026-10-14/最終更新:2026-10-15
確認した内容情報源確認日
対応する画像の形式(PNG、JPEG、WEBP、HEIC、HEIF)。画像を直接入れる場合にリクエスト全体が20MBまでであること。1つのリクエストに複数の画像を入れられること。物体の枠を返させられ、座標が 0〜1000 に正規化され、例で [ymin, xmin, ymax, xmax] の順であること。画像のトークンの換算(384ピクセル以下は258トークン、それより大きいものは768×768のタイルごとに258トークン)Gemini API: Image understanding2026-10-14
構造化出力が response_format で mime_type を application/json にし、schema にスキーマを入れる形で、/v1beta/interactions に送る例であること。enum が使えること。値はアプリ側で検証するよう書かれていることGemini API: Structured output2026-10-14
有料のサービスではプロンプトと応答が製品の改善に使われないこと。18歳以上であることが利用の条件であることGemini API Additional Terms of Service2026-10-14
貸渡約款の参考様式で、借受人が点検表に基づく車体外観の検査で確かめること(第13条)。借受人が会社の立会いのもとで返還し、通常の使用によって摩耗した箇所等を除き引渡し時の状態で返還すること(第20条)。事故・汚損等で会社が車両を使えない損害は料金表の定めによること(第28条)国土交通省 北海道運輸局: レンタカー貸渡約款(参考様式)2026-10-14

精算の扱いと借受人への説明は、自社の約款・料金表・補償制度に沿って店長が判断してください。 本記事は公開の資料で確認できた範囲だけを扱っています。

実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。

自社の業務に使えるAI活用候補を整理します

このユースケース(UC-1577)についてのご相談はこちらから。

AI活用について相談する
目次