看板の施工・保守会社が屋外広告物の点検で撮った写真を Gemini で見て、さび・ボルトの緩み・表示面の割れの候補を点検項目ごとに拾い、点検報告書の下書きにする
看板の点検員が現地で撮った写真を、前回の点検の写真と一緒に Gemini に見せ、さび、ボルトの緩み、表示面の割れなどの候補を自治体の点検項目ごとに拾います。拾った候補を点検記録と広告主への報告書の下書きにします。
- 生成AI
- ChatGPT/Claude/Gemini
- 連携・自動化
- Google Apps Script/Python
- 対象業界
- 不動産/小売/広告/建設
- 対象部門
- 品質管理
- 対象業務
- 内容確認・チェック/書類作成
- 主な課題
- 人手が足りない/書類作成に時間がかかる/確認ミスが多い
- AIで行う処理
- 画像認識
- 主な効果
- 入力漏れ削減/品質標準化/工数削減
- 導入難易度
- ★★☆☆☆
- 実装レベル
- 本格構成
- 費用感
- API連携(中)
- 人間の確認
- 条件付き
01導入前 / 導入後の業務フロー
- 点検員が現地で、基礎・支柱・接合部・ボルト・表示面・照明を目視し、写真を撮る
- 目視で判断できない箇所は、打診などで詳しく見る
- 事務所に戻り、写真をパソコンに取り込み、看板ごとのフォルダに分ける
- 前回の点検のフォルダを開き、同じ部位の写真を探して見比べる
- 点検記録の用紙に、点検項目ごとの結果を書く
- 報告書の雛形に写真を貼り、異常のある箇所に印を付け、説明と対処の案を書く
- 自治体へ出す点検結果の報告書(許可・更新のとき)を作る
- 人点検員が現地で目視し、部位ごとに決まった順で写真を撮る(スマートフォンのアプリで看板の番号と部位を付ける)
- 人目視で判断できない箇所は打診などで詳しく見て、結果をアプリに入れる
- 自動写真が共有のフォルダに上がると、プログラムが看板の台帳と前回の点検の写真を探す
- 自動部位ごとに、今回の写真と前回の写真を Gemini API に渡す
- 自動点検項目ごとの異常の候補と、写っていない部位が JSON で返る
- 自動候補に枠を描いた写真と、点検記録の下書き、報告書の下書きを作る
- 人点検員が下書きを開き、候補を自分の目視と打診の結果と照らして直す
- 人点検項目ごとの結果と、補修・撤去の要否と、対処の案を点検員が書く
- 人報告書を広告主に送る。自治体へ出す報告は点検員が作る
各工程の詳しい説明を読む
- 点検員が現地で、基礎・支柱・接合部・ボルト・表示面・照明を目視し、写真を撮る
- 目視で判断できない箇所は、打診などで詳しく見る
- 事務所に戻り、写真をパソコンに取り込み、看板ごとのフォルダに分ける
- 前回の点検のフォルダを開き、同じ部位の写真を探して見比べる
- 点検記録の用紙に、点検項目ごとの結果を書く
- 報告書の雛形に写真を貼り、異常のある箇所に印を付け、説明と対処の案を書く
- 自治体へ出す点検結果の報告書(許可・更新のとき)を作る
(a)報告書を書く時間が、点検より長い。 30枚の写真から報告書に使う写真を選び、部位の名前を付け、印を付けて説明を書くと、1面30分かかります。 月400面では月200時間で、点検員が現地に出られる日が減ります。
(b)前回との比べ方が人によって違う。 前回の写真を探して見比べる人もいれば、今回の写真だけで書く人もいます。さびが広がったのか、前回からあったのかが、報告書によって書かれていたり書かれていなかったりします。
(c)写真の見落とし。 現地では気付かなかったボルトの脱落や、表示面の端の細い割れが、事務所で写真を見返したときに見つかることがあります。 逆に、写真を急いで見ると、撮ってあるのに見落とします。
(d)点検項目の欄が空く。 点検員が気になった箇所を中心に写真を撮るため、照明やビスの写真が無いまま記録を書くことがあります。 空欄が「異常なし」なのか「見ていない」のかが、記録からは分かりません。
- 【人】 点検員が現地で目視し、部位ごとに決まった順で写真を撮る(スマートフォンのアプリで看板の番号と部位を付ける)
- 【人】 目視で判断できない箇所は打診などで詳しく見て、結果をアプリに入れる
- 【自動】 写真が共有のフォルダに上がると、プログラムが看板の台帳と前回の点検の写真を探す
- 【自動】 部位ごとに、今回の写真と前回の写真を Gemini API に渡す
- 【自動】 点検項目ごとの異常の候補と、写っていない部位が JSON で返る
- 【自動】 候補に枠を描いた写真と、点検記録の下書き、報告書の下書きを作る
- 【人】 点検員が下書きを開き、候補を自分の目視と打診の結果と照らして直す
- 【人】 点検項目ごとの結果と、補修・撤去の要否と、対処の案を点検員が書く
- 【人】 報告書を広告主に送る。自治体へ出す報告は点検員が作る
7番目が、この設計の分かれ目です。AIの候補は、現地の点検の代わりではありません。 点検員は今まで通り看板に近づいて見て、必要なら打診をします。写真で見つかった候補は、現地の結果と照らすための材料です。 写真だけで点検記録を確定させる設計にすると、打診でしか分からない内部の腐食が記録から消えます。
8番目を人に残すのも、意図してのことです。 補修や撤去が要るかは、看板の大きさ、高さ、人通りによって重みが変わります。AIの候補の多さで決めず、点検員が現地の状況と合わせて決めます。
02今回想定するシステム構成
現地の点検(目視、必要なら打診) │ スマートフォンのアプリ:看板の番号と部位を付けて撮る ▼【トリガー】共有のフォルダへのアップロード 処理のプログラム(Python) ├── 看板の台帳(種類、高さ、表示面積、設置の年、前回の点検の日)を読む ├── 前回の点検の同じ部位の写真を探す ▼ Gemini API(画像の理解・枠・構造化出力)── 今回の写真+前回の写真 │ 点検項目ごとの異常の候補(さび、腐食、合いマークのずれ、割れ、剥離 など) │ 前回からの変化、写っていない部位 ▼ 処理のプログラム ── 枠を描いた写真、点検記録の下書き、報告書の下書き ▼ 【人】点検員が目視・打診の結果と照らし、結果と対処を決める ▼ 広告主への報告書/自治体への点検結果の報告(点検員が作る)
| 役割 | 想定する製品 | 代替候補 |
|---|---|---|
| 処理 | Gemini API(今回と前回の写真を比べ、点検項目ごとの異常の候補を枠つきで返す) | Claude API、OpenAI API |
| 連携 | Python(フォルダの監視、台帳の読み込み、呼び出し、枠の描画、下書きの作成) | Google Apps Script |
| 撮影 | 点検員のスマートフォンと点検用のアプリ | デジタルカメラ |
| 記録 | 看板の台帳と点検記録の表(共有の表計算) | 保守管理の仕組み |
新しく足すのは、写真に看板の番号と部位を付けて上げるアプリ、プログラム、Gemini API の契約です。 看板の台帳、点検記録の様式、報告書の雛形は、すでにあるものです。現地の点検のやり方と、結果を決める人は変えません。
写真を見る土台は、Gemini API の画像の理解です。 公式の案内では、対応する形式は PNG、JPEG、WEBP、HEIC、HEIF で、1つのリクエストに複数の画像を入れられます。 今回と前回の写真を同じリクエストに入れて比べさせます。枠は [ymin, xmin, ymax, xmax] の順で0〜1000に正規化され、元の画像の大きさに戻して使います。Gemini は物を見つけるだけでなく、輪郭のマスクを返すとされ、さびや表示面の剥離のように広がりのある異常は、輪郭で返させます。
出力は構造化出力で受けます。 /v1beta/interactions に送り、response_format で mime_type を application/json にし、schema にスキーマを入れます。enum で値を決まった文字列に絞れます。値はアプリ側で検証するよう書かれています。
03どうやって実装するのか
処理の起点を決める
点検員が写真を共有のフォルダに上げたときに動きます。 処理のプログラムがフォルダを見張り、1面の看板の部位がそろったところで処理を始めます。 そろったかは、看板の種類ごとに決めた部位の一覧とファイルの数で見ます。
現地からその場で上げる形にします。 点検員がまだ看板の前にいるうちに「照明の写真が無い」「基礎の写真がぶれている」と分かれば、その場で撮り直せます。 事務所に戻ってから分かると、もう一度現地に行くことになります。
処理が終わったファイルは、看板ごとの点検のフォルダに移します。 移すのは下書きを作り終えたときだけです。共有のフォルダに残っている数が、処理を待っている数になります。 次の点検のときは、このフォルダから前回の写真を探します。
入力データを集める
| データ | 中身 | 取得元 |
|---|---|---|
| 今回の写真 | 看板の番号、部位(基礎、支柱、接合部、ボルト、表示面、照明)、撮った日時 | 点検用のアプリ |
| 前回の写真 | 同じ看板・同じ部位の、前回の点検の写真 | 看板ごとの点検のフォルダ |
| 看板の台帳 | 種類(袖、壁面、野立て、ポール)、高さ、表示面積、設置の年、材質、前回の点検の日と結果 | 看板の台帳(表計算) |
| 点検員の現地の記録 | 目視の気付き、打診をした箇所とその結果 | 点検用のアプリ |
| 点検項目の一覧 | 自治体の点検記録の様式にある項目 | 自治体ごとの様式から書き抜いた表 |
質を決めるのは、部位ごとに決まった順で撮ることです。 看板の種類ごとに撮る部位の一覧を決め、アプリが順に「次は接合部」と出すようにします。撮る部位がそろっていれば、写真の無い点検項目の欄は生まれません。
点検項目の一覧は、自治体ごとに持ちます。 看板の所在地によって条例と様式が違い、たとえば三重県は令和8年10月1日の申請分から自己点検結果報告書の様式を変えています。台帳の所在地から自治体を引き、その様式の項目で返させます。
打診の結果は、AIに渡さず記録の欄に直接入れます。 打診は音と手応えで判断するもので、写真の候補と混ぜると、どちらの判断かが記録から分からなくなります。
データの取得方法を決める
写真の看板の番号と部位は、アプリが付けたファイル名から読みます。 点検員が看板に貼った管理番号の札を読み取ってから撮ると、「看板の番号_部位_連番」の名前で上がるようにします。決まりを外れた名前の写真は処理せず、点検員の画面に出します。
看板の台帳は表から読みます。 種類、高さ、表示面積、所在地、前回の点検の日を取ります。台帳に無い看板の番号は処理を止め、保守部の担当に知らせます。 新しく取り付けた看板の登録漏れが、ここで分かります。
前回の写真は、看板ごとの点検のフォルダから同じ部位のものを探します。 点検の間隔は年単位なので、前回の写真は1〜3年前のものになります。 前回の写真が無い看板(初めて点検を請け負った看板)は、比べずに今回の写真だけを見させ、下書きに「前回の写真なし」と出します。
Gemini API へは、部位ごとに1回、その部位の今回の写真と前回の写真を渡します。 部位ごとに分けると、撮り直したときにその部位だけを見直せます。写真の順番は「前回、今回」の対にし、指示の文で順番を説明します。
有料の利用枠で使い、store を false にします。 Gemini API の規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API は既定でやり取りを保存し(有料の枠で55日)、保存しないときは store=false を付けると案内されています。
AIへ渡す前に整形する
- 部位がそろったかの確認 … 看板の種類ごとの部位の一覧と、上がった写真を突き合わせます
- ぶれと逆光の確認 … ぶれの大きい写真と、空を背にして暗くつぶれた写真は、撮り直しの印を付けます
- 人と車の番号の確認 … 通行人の顔や車のナンバーが写っていれば、その範囲を塗りつぶしてから送ります
- 大きさ … ボルトの合いマークや細い割れが見えるよう、縮めすぎない大きさで送ります
- 台帳の付け足し … 看板の種類、材質、設置の年、点検項目の一覧を指示に入れます
- 写真の対の確認 … 今回と前回の写真が同じ部位どうしで対になっているかを確かめます
4番目を軽く見ないでください。 公式の案内では、大きな画像は768×768ピクセルの区画に分けられ、区画ごとにトークンが数えられます。 縮めれば費用は下がりますが、高所の看板を下から撮った写真では、ボルトの合いマークは数ピクセルにしかなりません。 ボルトと接合部は、望遠か高所作業車の上から寄った写真を別に撮る決まりにします。
3番目は、看板の写真に写った人の情報を外部に送らないためです。 街なかの看板は、通行人や駐車中の車と一緒に写ります。看板の点検に人の顔も車の番号も要りません。
AIに処理させる
させるのは、部位ごとの写真を前回の写真と比べ、点検項目ごとの異常の候補を枠と輪郭で返し、前回からの変化と写っていない範囲を返すことだけです。
| 点検項目(三重県の例) | 写真で見る候補 | 判断できないときの扱い |
|---|---|---|
| 基礎及び取付部分の変形、腐食、亀裂等 | 基礎のコンクリートのひび、アンカーの周りのさび、取付の金物の曲がり | 土や草で隠れていれば not_visible |
| 主要部材の変形、腐食、劣化等 | 支柱・フレームのさび、塗装のはがれ、曲がり | さびか汚れか分からなければ unclear |
| ボルト、ビス等のさび、緩み、脱落等 | 合いマークのずれ、ナットの欠け、穴だけ残ったビス、さび | 合いマークが無ければ no_match_mark |
| 表示面の汚染、変色又は剥離 | 色あせ、汚れ、シートの浮き・はがれ | - |
| 表示面の破損 | 割れ、穴、欠け | 割れか反射か分からなければ unclear |
| 照明又はネオン設備等の異常 | カバーの割れ、配線の垂れ、器具の外れ | 点灯の有無は昼の写真では分からないため書かない |
右端の列の考え方は、迷ったら点検員に見せる側に倒すことです。 さびか汚れか分からないものは unclear として返させます。候補が多いのは点検員の数秒で済みますが、候補から落ちたボルトの脱落は、強い風の日に看板の落下につながります。
| させないこと | 理由 |
|---|---|
| 安全か危険かの判断 | 近づいての目視と打診で、点検員が決める |
| 補修・撤去の要否 | 看板の大きさ、高さ、人通りと合わせて点検員が決める |
| 内部の腐食の推測 | 外から見えない。打診などの詳しい点検の領域 |
| ボルトの締め付けの強さ | 写真からは分からない。見えるのは合いマークのずれまで |
| 照明の点灯の有無 | 昼の写真では分からない。点検員が確かめる |
| 「異常なし」の結論 | 写っていない範囲がある限り言えない |
1行目と2行目がいちばん起きやすい失敗です。 支柱にさびが写っていると、AIは「危険度が高い。早急な交換が必要」と書きたがります。報告書の下書きにその言葉が載ると、点検員が現地の結果を書く前に結論が決まってしまい、広告主にも過大に伝わります。 返すのは「主要部材のさびの候補。前回より広がって見える」までにします。
指示内容を固定する
あなたは看板の会社で、屋外広告物の点検記録づくりを手伝う係です。
点検員が現地で目視と打診をして結果を決めます。あなたは、点検員が写真で確かめるべき箇所を示してください。
【看板】{看板の番号}({袖看板/壁面看板/野立て看板/ポールサイン}、高さ {m}、設置 {年}、材質 {鉄/ステンレス/アルミ})
【部位】{基礎/支柱/接合部/ボルト/表示面/照明}
【点検項目】{自治体の様式の項目の一覧}
【写真の順番】前半が前回の点検({日付})、後半が今回の写真です。同じ順番で対になっています。
【やること】
1. 今回の写真で、点検項目に当たる異常の候補を探す。
2. 候補ごとに、今回の写真の上の枠を返す。広がりのあるもの(さび、剥離)は輪郭も返す。
枠は [ymin, xmin, ymax, xmax] の順で 0〜1000 に正規化し、何枚目の写真かを書く。
3. 候補ごとに、当てはまる点検項目を1つ選び、見え方を下の一覧から選ぶ。
4. 候補ごとに、前回の写真と比べて new/grown/same/no_previous のどれかを選ぶ。
5. ボルトは、合いマークがあればずれているかを見る。合いマークが無ければ no_match_mark にする。
6. ぶれ、逆光、物陰で見えない範囲を返す。
【厳守事項】
- 安全か危険か、補修や撤去が必要かを書かないでください。
- ボルトが緩んでいると断定しないでください。合いマークのずれが見えることだけを書いてください。
- 内部の腐食について推測しないでください。
- 照明が点いているかどうかを書かないでください。
- さびか汚れか、割れか反射か分からないものは、appearance を unclear にして候補に入れてください。
- 見えない範囲について「異常なし」と書かないでください。
- 写真に写った人や車について何も書かないでください。
「安全か危険かを書かない」を最初に置くのは、記録の責任の所在のためです。 点検の結果は有資格者の点検員が決めるもので、記録の上でも点検員の判断として残します。
「緩んでいると断定しない」を別に書くのは、写真で分かることの限界をはっきりさせるためです。 合いマークがずれていても、締め直した後に線を引き直していないだけのことがあります。見えるのは線のずれで、緩みかどうかは点検員が工具を当てて確かめます。
出力形式を固定する
部位ごとに、次の形の JSON で受け取ります。 item、appearance、vs_previous、reason は enum で決まった文字列に絞ります。
{
"sign_id": "S-03218",
"part": "bolt",
"previous_date": "2024-11-12",
"candidates": [
{ "image_index": 4,
"box_2d": [380, 450, 430, 500],
"has_mask": false,
"item": "foundation | main_member | bolt_screw | face_stain | face_damage | lighting | other",
"appearance": "rust | corrosion | crack | deformation | match_mark_shift | missing_bolt | coating_peel | fading | sheet_peel | face_crack | cover_broken | wire_hanging | unclear",
"vs_previous": "new | grown | same | no_previous",
"location": "上段のフランジの右から2本目" }
],
"match_mark": "present | no_match_mark",
"not_visible": [ { "image_index": 4, "area": "裏側の接合部", "reason": "blur | backlight | obstructed" } ]
}
1つ目の理由は、item で点検記録の欄に振り分けられることです。 点検項目の欄ごとに候補が入り、候補も写真も無い欄は「写真なし」として目立ちます。 第3章の(d)の空欄が、空欄のまま見過ごされなくなります。
2つ目は、vs_previous で前回からの変化が報告書に残ることです。 「前回からあったさび」と「今回新しく出たさび」が分かれていれば、広告主にとっては補修の優先の順を考える材料になります。 点検員ごとの書き方の違い(第3章の(b))も減ります。
3つ目は、match_mark で次の点検の準備が分かることです。 合いマークの無いボルトが多い看板は、今回の点検で線を引いておけば、次回から写真で見比べられます。
点検記録の下書きの行は、次の形です。
| 点検項目 | 部位 | 候補 | 前回と比べて | 打診の結果 | 点検員の結果 | 対処の案 |
|---|---|---|---|---|---|---|
| ボルト、ビス等 | 上段のフランジ | 合いマークのずれ | new | (点検員が書く) | (点検員が選ぶ) | (点検員が書く) |
| 主要部材 | 支柱の根元 | さび | grown | (点検員が書く) | (点検員が選ぶ) | (点検員が書く) |
システムへ連携する
| つなぎ先 | 方式 | 内容 |
|---|---|---|
| 点検用のアプリ | 共有のフォルダへのアップロード | 看板の番号と部位を付けた写真、現地の記録 |
| 看板の台帳 | 表の読み取り | 種類、高さ、材質、所在地、前回の点検の日。書き込まない |
| Gemini API | API呼び出し(/v1beta/interactions、store=false) | 点検項目ごとの候補の枠と輪郭、見え方、前回との比較、見えない範囲 |
| 点検記録の表 | 表への書き込み | 候補の欄だけ。打診・結果・対処の欄には書かない |
| 報告書の雛形 | 文書の作成 | 枠を描いた写真と候補の説明。結果と対処は点検員が書く |
点検員の結果と対処の欄には、プログラムから何も書きません。 記録に残る結果は、点検員が選んだものだけです。AIの候補から「要補修」の行が作られる経路を作りません。
自治体へ出す点検結果の報告書も、この下書きから自動では作りません。 報告書は様式が自治体ごとに決まっており、有資格者の点検員が自分の点検の結果として作ります。
人が確認する
- 候補を現地の結果と照らす … 下書きの候補を、現地での目視の気付きと打診の結果と並べて見ます
- 候補ごとに「異常」「異常でない」を選ぶ … 異常でないときは、汚れ、反射、塗装の模様、線の引き直し忘れなどの理由を選びます
- 候補の無かった部位も見る … 写真を全部見て、AIの拾わなかった異常があれば足します。足したものには「AIの候補に無し」の印が付きます
- 結果と対処を決める … 点検項目ごとの結果と、補修・撤去の要否、対処の案を書きます
- 迷うものは上長に回す … 基礎と主要部材の
grownの候補で判断に迷うものは、屋外広告士の資格を持つ上長が見ます
3番目を省かないでください。 AIは、逆光や物陰の異常、写真の端の異常を拾えないことがあります。下書きに候補が無いことは、異常が無いことではありません。
目標は、400件をならして1件12分です。 候補の少ない小さな袖看板は数分で済み、大きな野立て看板やポールサインで候補が多いものは30分を超えます。3番目で足した異常が週に何件あるかを数え、多い部位は撮り方の決まりを見直します。
例外に対処する
| 起きること | 対応 |
|---|---|
| 部位の写真がそろわない(撮り漏れ) | アプリの画面にすぐ出し、現地で撮り直す |
| ファイル名の決まりを外れる | 処理せず、点検員の画面に出す |
| 台帳に無い看板の番号 | 処理を止め、保守部の担当に知らせる |
| 前回の写真が無い | 比べずに今回の写真だけを見る。no_previous として返る |
| 逆光や物陰で見えない範囲が大きい | not_visible として返る。角度を変えて撮り直すか、現地で特に注意して見る |
| 合いマークが無い | no_match_mark として返る。今回の点検で線を引くよう点検員に出す |
JSON の値が enum に無い | その部位の候補を下書きに書かず、点検員に回す |
| Gemini API が応答しない | 共有のフォルダに残し、点検員は従来どおり写真を見て記録を書く |
上から6行目までが大半を占めます。 どれもAIの精度の問題ではなく、撮り方と台帳の整備の問題です。 部位ごとに決まった順で撮ることと、合いマークを引いておくことのほうが、指示の文をいじるより効きます。
落下のおそれがある異常を現地で見つけたときは、この構成を待ちません。 点検員がその場で広告主と上長に連絡するのは今まで通りです。
記録を残す
- 部位ごとの写真と、Gemini API が返した JSON の全文
- そのとき比べた前回の写真の日付と、参照した台帳と点検項目の一覧の版
- 点検員が「異常でない」とした候補と、その理由
- 点検員が足した異常(AIの候補に無かったもの)
- 打診の結果、点検員の結果、対処の案、広告主への報告書
- 看板ごとの候補の続き方(同じ部位のさびが点検のたびに広がっているか)
4つ目の行が、この構成でいちばん大事な記録です。 AIの拾わなかった異常が、どの種類の看板のどの部位に、どんな撮り方のときに出たかが分かれば、撮る部位の一覧と寄った写真の決まりをどこで足すかが決まります。
記録は次の点検まで残します。 三重県の案内では、安全点検の記録は次回の点検のときまで保管することとされています。写真と下書きと点検員の結果を、看板ごとのフォルダにまとめて残します。
04実装レベルの3段階
最小構成では件数がさばけません。 月400面の写真を手で渡す時間はありません。確かめるための段階です。 半自動化で、1件30分が20分程度になります。 写真の仕分けと前回の写真探し、候補の拾い出しは自動になりますが、点検記録と報告書を書く作業が残ります。本格構成で12分になり、この段階が本記事の想定です。 差が大きいのは、候補が点検項目の欄と報告書の写真に入り、二度書きが無くなるからです。 段階を飛ばさないでください。 半自動化で1か月回すと、「異常でない」の多い部位と、足した異常の多い看板の種類が分かります。そこの撮り方を直してから本格構成に進むほうが、点検員の確認の時間が減ります。
05工数削減シミュレーション
導入後 400件 × 12分 ÷ 60 = 80 時間/月
自社条件で導入効果を整理したい方へ
このユースケースを自社に当てはめた場合の前提値と削減見込みを、業務ヒアリングをもとに整理します。
06向いている企業・向いていない企業
- 看板の製作・施工に加えて、広告主から屋外広告物の安全点検と許可の更新の手続きを請け負っている看板の会社。管理する看板が数千面あり、点検員が1日に何か所も回って写真を撮るが、事務所に戻ってから写真を点検項目ごとに並べ、記録と報告書を書く時間が点検そのものより長い場合。点検員によって写真の撮り方と報告書の書きぶりが違い、前回の点検との比べ方が決まっていない場合。
- 管理する看板が数十面で、点検の頻度も少ない場合。点検を建築物の定期報告と一体で建築の調査の会社に任せている場合。なお、看板が安全かどうかの判断、打診の結果の評価、撤去や補修の要否、自治体へ出す点検結果の報告の内容の判断は、この構成では代替できません。
07最小構成で試す方法
- 前回と今回の両方の写真がある看板から、種類の違うもの(袖看板、野立て看板、ポールサイン)を合わせて20面選ぶ(異常が見つかったものと見つからなかったものを混ぜる)
- その20面について、点検員がどの写真で何を見つけたかを聞き取る
- Gemini API の有料の利用枠で、部位ごとに前回と今回の写真を対にして渡す
- 「点検項目ごとに異常の候補を枠で示し、前回と比べて新しいか広がったかを付けてください。安全かどうかや補修の要否は書かないでください」と指示する
- 出てきた候補を、点検員の記録と突き合わせる
20面は必ずやってください。 アプリとプログラムを組む前に、「いまの撮り方で、点検項目ごとの候補が返るのか」を確かめます。
| 出てきた内容 | 判断 |
|---|---|
点検員の記録の異常の大半が候補に入り、vs_previous も合っていた | アプリとプログラムの作成に進む |
| 「危険」「交換が必要」と書いた | 指示の書き方で直る。構成は有効 |
ボルトや割れをほとんど拾えず、not_visible が多い | 寄った写真の撮り方が先。 AIの問題ではない |
3行目が出ることは珍しくありません。 失敗ではなく、点検員が現地で近づいて見ていたものが、写真に残っていなかったということです。 ボルトと接合部を寄って撮る決まりを足して、もう一度試してください。
08実装時につまずきやすいポイント
| 問題 | 対策 |
|---|---|
| 「危険」「交換が必要」と書く | 指示で禁じる。 下書きの結果と対処の欄を空ける |
| 写真の無い点検項目が空欄のまま通る | 部位の一覧で撮り漏れを現地で知らせる |
| 合いマークのずれを緩みと断定する | 見え方だけを返させ、工具での確認を点検員が行う |
| 高所のボルトが小さすぎて見えない | 望遠か高所作業車の上から寄って撮る決まりにする |
| さびと汚れ、割れと反射を取り違える | unclear を使い、前回の写真と比べさせる |
| 前回の写真と対を取り違える | 写真の順番を指示に書き、プログラムで部位を確かめる |
| 通行人や車の番号を送る | 塗りつぶしてから送る |
| 自治体の様式の変更に追いつかない | 点検項目の一覧を自治体ごとに版で持ち、変更の案内を確かめる |
| 下書きに候補の無い部位を見ない | 写真の見直しを点検の手順に書く |
| 打診の結果が写真の候補と混ざる | 打診の結果は別の欄に点検員が直接入れる |
上の2行が、この構成の失敗のほとんどです。 どちらも、AIに点検員の判断の代わりをさせる失敗と、写真がそろっていない失敗です。結果の欄を空けておき、部位ごとに撮り漏れを現地で止めるかどうかで、点検記録が使えるものになるかが決まります。
09セキュリティ・AIガバナンス上の注意点
この構成で扱うデータ: 看板の写真、所在地、広告主の名前、看板の台帳、点検の結果です。街なかの写真には、通行人の顔や車のナンバーが写り込みます。
- 写り込んだ人と車を送らない … 塗りつぶしてから送り、写真に写った人や車について AI に何も書かせません
- 有料の利用枠で、保存させない … 規約では、有料のサービスではプロンプトと応答が製品の改善に使われないとされています。Interactions API の
storeをfalseにします - 広告主との取り決めを確かめる … 点検の写真を外部のサービスに送ってよいかを、保守の契約で確かめます。出店前の店舗の看板のように、公開前の情報を含む写真もあります
- 点検の結果の責任の所在を変えない … 有資格者による点検が必要な看板の結果は、点検員が自分の点検として決めます。AIの候補を結果として報告しません
- 自治体への報告を自動で作らない … 点検結果の報告は、様式に沿って点検員が作ります
- 職員だけが使う仕組みにする … Gemini API の規約は18歳以上であることを利用の条件にしています。広告主や一般の人が写真を上げる窓口には使いません
誤りが起きた場合のリスクは、AIが拾わなかった異常がそのまま残り看板が落ちることと、AIの言葉が強すぎて不要な撤去を勧めることの2つです。 前者は写真の見直しを省くと起き、後者は結果の欄をAIに埋めさせると起きます。どちらも、写真を全部見直す手順と、結果の欄を空けておく設計で防げます。
10まず何から始めるか
1週目:撮る部位と順番を決める
看板の種類ごとに、撮る部位の一覧と順番を決めます。ボルトと接合部は寄って撮ること、合いマークの無いボルトには線を引くことも決めます。
2週目:20面で試す
前回と今回の写真がある20面を選び、Gemini API に部位ごとに対にして渡します。点検員の記録の異常が候補に入るか、「危険」「交換」を書いていないかを最優先で見ます。
3週目:台帳と点検項目を整える
看板の台帳に所在地の自治体を足し、自治体ごとの点検項目の一覧を作ります。所在地の多い自治体から順に整え、様式の変更の時期も書いておきます。
4週目:写真の上がりから候補の一覧までをつなぐ
アプリで上げた写真をプログラムが拾い、前回の写真と対にして、枠を描いた写真と候補の一覧を出すところまで作ります。この時点では下書きを作らず、点検員は従来どおり記録と報告書を書きます。
2か月目: 点検記録と報告書の下書きを足し、二度書きをやめます。「異常でない」とした候補と、足した異常を毎週数えます。3か月目以降: 全部の看板の種類に広げ、1件30分が何分になったかを実測します。足した異常の理由が撮り方の決まりに反映され、さびの広がり方を広告主への補修の提案に毎月使えるようになった時点で、この構成は完成です。
11関連ユースケース
12この仕組みを理解するための記事
13技術仕様の確認日・参考情報
| 確認した内容 | 情報源 | 確認日 |
|---|---|---|
| 点検の義務の対象が(貼り紙などの簡易なものを除き)すべての広告物であること。許可を要する表示面積1平方メートル以上かつ高さ4メートルを超える広告物は有資格者による点検が必要なこと。点検項目が、基礎及び取付部分の変形・腐食・亀裂等/主要部材の変形・腐食・劣化等/ボルト・ビス等のさび・緩み・脱落等/表示面の汚染・変色又は剥離/表示面の破損/照明又はネオン設備等の異常/その他であること。目視で安全性を判断できない場合は打診等の詳しい点検を行うこと。記録を次回の点検時まで保管すること。令和8年10月1日申請分から自己点検結果報告書の様式が変わること | 三重県: 屋外広告物の安全点検制度 | 2026-10-26 |
対応する画像の形式が PNG、JPEG、WEBP、HEIC、HEIF であること。1つのリクエストに複数の画像を入れられること。枠が [ymin, xmin, ymax, xmax] の順で0〜1000に正規化され、元の画像の大きさに戻して使うこと。輪郭のマスクを返すこと。大きな画像が768×768の区画に分けられ区画ごとにトークンが数えられること | Gemini API: Image understanding | 2026-10-26 |
構造化出力が /v1beta/interactions に response_format で mime_type を application/json にし、schema にスキーマを入れて送る形であること。enum が使えること。値はアプリ側で検証するよう書かれていること | Gemini API: Structured output | 2026-10-26 |
Interactions API が既定でやり取りを保存し、有料の枠で55日保持すること。store=false で保存しないようにできること | Gemini API: Interactions | 2026-10-26 |
| 有料のサービスではプロンプトと応答が製品の改善に使われないこと。18歳以上であることが利用の条件であること | Gemini API Additional Terms of Service | 2026-10-26 |
点検の義務、有資格者の要件、点検項目と報告の様式は、看板の所在地の自治体の条例と案内で確かめてください。 本記事は三重県の案内を例に、公開の資料で確認できた範囲だけを扱っています。
実装ステータス:構成例。 公開仕様に基づいて設計した構成であり、当社で実際に構築・検証したものではありません。工数の数値はモデル条件による試算です。
自社の業務に使えるAI活用候補を整理します
このユースケース(UC-1871)についてのご相談はこちらから。
