Webエンジニア向けプログラミング解説動画をYouTubeで配信中!
▶ チャンネル登録はこちら

【ITニュース解説】Gemma read the parking sign perfectly. Then it got the rule wrong.

2026年10月19日に「Dev.to」が公開したITニュース「Gemma read the parking sign perfectly. Then it got the rule wrong.」について初心者にもわかりやすく解説しています。

作成日: 更新日:

ITニュース概要

駐車違反切符の異議申し立てを支援する「TicketBack」は、切符と標識の写真をAIが読み取り、コードが違反の有無を判断する。ユーザー確認後、AIが異議申し立てレターを自動作成。全ての処理をローカルで完結させ、プライバシーとコストを両立する。

ITニュース解説

ニュース記事は、駐車違反切符の異議申し立てを支援する「TicketBack」というツールについて解説している。これは、手間に感じる少額の駐車違反切符に対して、AIとプログラミングコードを組み合わせて自動的に異議申し立て書を作成するアプリケーションである。システムエンジニアを目指す初心者にとって、AIを実際の課題解決にどのように応用し、その過程でどのような課題に直面し、どう解決していくのかを学ぶ良い事例となるだろう。

TicketBackの基本的な仕組みはこうだ。ユーザーは駐車違反切符と、駐車した場所の標識をスマートフォンのカメラで撮影する。この二枚の写真をTicketBackに読み込ませると、まず「Gemma 3 4B」というオープンソースのAIモデルが、画像を解析して切符の内容(日時、場所、車両番号など)や標識に書かれた情報(駐車制限の時間、曜日など)をテキストデータとして抽出する。このAIモデルはOllamaというツールを通じて、ユーザー自身のコンピュータ上でローカルに動作するため、外部のサーバーにデータが送られることは一切ない。AIが読み取った内容をユーザーが確認し、必要に応じて修正した後、TicketBackの内部に組み込まれた「プレーンなコード」、つまり通常のプログラミング言語で書かれたルールが、読み取った事実に基づいて異議申し立ての根拠があるかどうかを判断する。例えば、違反切符の発行日時が標識の駐車制限時間外であった場合などだ。もし異議申し立ての根拠が見つかれば、再びAIモデルが、ユーザーが確認した事実に基づいて、フォーマルな異議申し立てのレター本文を自動で作成する。ヘッダーや署名部分などは、あらかじめプログラムされたコードが自動で追加する。この一連の処理がすべてユーザーのコンピュータ内で完結するため、プライバシーが保護され、データが外部に流出する心配がない点が最大の特徴だ。また、外部のAIサービスを利用しないため、処理ごとの費用がかからず、低価格でのサービス提供が可能になる。

このツールが生まれた背景には、駐車違反切符が抱える一般的な問題がある。例えば65ドルの違反切符は、弁護士を雇って争うには安すぎる一方で、支払うには高すぎると感じる人が多い。規則がすでに終了していたにもかかわらず切符を切られた場合でも、異議申し立ての手間を考えると、多くの人が不本意ながらも支払ってしまうのが実情だ。違反切符を詳細に読み解き、標識の規則を正確に把握し、礼儀正しくかつ毅然とした異議申し立て書を作成するには、10分程度の面倒な作業が必要となる。TicketBackは、この手間を解消し、正当な理由があれば簡単に異議を申し立てられるようにすることを目指している。個人ドライバーだけでなく、毎月のように違反切符を受け取る配送業者や建設業者などの小規模なフリート(車両群)にとっても、このツールは大きなメリットがある。彼らにとっては、チケットごとに写真を撮るだけで、争う価値のあるものについて異議申し立て書を得られる点が魅力的だ。

TicketBackの開発過程では、AIモデルの挙動に関していくつかの「意外な発見」があった。これらは、AIをシステムに組み込む上で重要な教訓を示している。

一つ目の発見は、AIへの指示の仕方が読み取り精度に大きく影響するというものだ。初期のバージョンでは、AIにJSONスキーマ(データ構造の定義)を与え、各フィールドが「もし見えなければnull」というオプション指定だった。しかし、これではAIは読み取り可能なチケットでも、14項目中8項目しか読み取らず、処理に74秒もかかった。同じ画像で、各フィールドを「もし印刷されていなければ空文字列」という指示に変更したところ、AIは14項目すべてを29秒で正確に読み取った。このことから、小さなAIモデルは「スキップしても良い」と許可されると実際にスキップしてしまう傾向があることが判明した。AIに全てを埋めさせようとするならば、曖昧な指示ではなく、明確に「すべて埋めること」を求める指示が必要だという学びがあった。

二つ目の発見は、AIがテキストを完璧に読み取っても、その意味を誤解することがあるという点だ。「2 HOUR / PARKING / 9 AM - 7 PM / EXCEPT SUNDAY」(2時間駐車、午前9時から午後7時まで、日曜日を除く)という標識に対し、AIはすべての単語を正確に転写したにもかかわらず、「この規則は週7日適用される」と報告してしまったのだ。AIは「日曜日を除く」という文言を認識しながらも、日曜を適用対象に含めてしまった。この一つのバグが、TicketBackのアーキテクチャを大きく変えるきっかけとなった。

このバグを受けて、開発者はAIモデルの役割を「コピーするだけ」に限定する決断を下した。つまり、AIはチケットのテキストフィールドと標識の単語を転写する機能に特化し、それ以外の意味解釈や判断は一切行わないようにしたのだ。標識のテキストが「Mon thru Fri」(月曜日から金曜日まで)や「except Sunday」(日曜日を除く)、「10 PM - 6 AM」(午後10時から午前6時まで)、「anytime」(いつでも)といった多様な表現で書かれていても、それを正確な曜日や時間、制限時間として解釈し、ルールを適用するのは「プレーンなコード」、つまりプログラムの役割になった。このコードには、様々な標識の表現に対応するための厳密なテストが多数記述されている。

さらに、ユーザーがAIの読み取り結果を必ず確認し、修正できるステップを設けることも重要だとされた。例えば、AIがナンバープレートを誤って読み取った場合、それが異議申し立て書に埋もれてしまえば大問題になるが、ユーザーが確認画面で修正できればわずか数秒で解決する。

ルールによる判断も、コードによって厳密に行われる。違反切符の発行時刻と標識の制限時間を比較したり、切符に記載された車両番号とユーザーの車両番号を照合したりするなど、9種類の異なる異議申し立ての根拠が、すべてコードによる明確な比較によって判断される。これにより、例えば「読み取れない標識の時間は無効」とは見なされず、「不明」は「無効」ではないという厳格な原則が守られる。

異議申し立てレターの作成時にも、AIとコードの役割分担が徹底されている。AIは、選ばれた異議申し立ての根拠からレターの本文を作成するが、コードはヘッダーや署名部分を追加するだけでなく、レター本文中の数字が、ユーザーが確認した事実と一致しているかを再度チェックする。初期のバージョンでは「制限は水曜日には適用されない」と書かれたレターがあったが、本当の理由は時間帯だったため、AIが誤った理由を推測してしまった。この経験から、コードが「制限は既に終了していました。午後6時に終了します」のように具体的な理由を明記するようになり、AIが推測する余地をなくした。

三つ目の発見は、時間の書式変換に関するものだった。初期の評価では、切符の発行時刻が正確に読み取れたのは12枚中6枚にとどまった。これはAIが「1025 HRS」のような時刻を正しくコピーしても、その後のプログラムが処理できなかったり、12時間表記の「2:30 PM」や「6:35 PM」をAIが24時間表記に変換しようとして「2:30」や「06:35」と誤って変換してしまったりしたためだった。この問題を解決するため、AIは時刻を「印刷された通りに正確にコピーする」だけに限定され、24時間表記への変換はすべてコードが行うように変更された。この修正後、時刻の読み取りは12枚中12枚で完璧になった。これらの経験から、AIモデルから複雑な意思決定やデータ変換の役割を奪い、コードに任せることでシステムの信頼性が向上するという共通のパターンが見出された。

システムの信頼性を確保するため、開発者は87ものテストを実装した。これには、午後6時ちょうどのような境界条件や、複数の標識が時間帯をカバーするケース、ハイフン付きで入力されたナンバープレートなどの検証が含まれる。さらに、実際のAIモデルに対する4つのテストも行い、コンテンツセキュリティポリシーの厳格化や、アップロードファイルのサイズ制限、すべてのテストがパスしないとリリースできないゲートも設けている。

TicketBackがローカルAIモデルを利用する「オープンイノベーション」にこだわったのには、明確な理由がある。一つはプライバシーだ。駐車違反切符は、車両番号と特定の日時の場所を結びつけ、標識の写真はユーザーの居場所を示す。これらは個人の位置情報履歴となりうるため、Gemmaモデルをローカルで実行することで、これらの機密情報がユーザーのカメラから自身のディスクへ直行し、外部に送信されることなく処理される。二つ目はコストである。わずか数ドルの異議申し立てに対して、画像処理ごとのAPI利用料が発生すると、利益がすぐに消えてしまう。ローカル実行であれば、チケットごとの費用はかからないため、サービスを低価格で提供できる。これは月間何十枚ものチケットを処理するフリートにとって特に重要だ。三つ目は開発における「制御」だ。前述の「意外な発見」は、開発者がAIモデルを自由に、かつコストやレート制限を気にすることなく何度でもテストできたからこそ解決できた。同じ画像を何度も繰り返し実行しながら、指示を少しずつ変えて試行錯誤できたことが、スキーマ変更が読み取り精度にどれほどの影響を与えるかを発見する助けとなった。AIモデルは環境変数一つで切り替えられるため、将来より優れたオープンな画像認識モデルが登場すれば、コードを一行変更するだけで簡単にアップデートできる。四つ目はオフライン対応だ。電波の届かない駐車場で切符を見つけても、すぐに異議申し立ての準備ができるのは大きな利便性である。

もちろん、TicketBackには限界もある。このツールは特定の都市の法律を理解しているわけではない。あくまで事実に基づいて異議申し立ての根拠を見つける「下書きツール」であり、法的なアドバイスを提供するものではない。また、読み取り精度の数値は、合成されたテスト用の写真に基づいており、現実の、くしゃくしゃになったり雨に濡れたりした切符に対する精度とは異なる可能性がある。これらの限界はアプリケーション内やREADMEにも明記されている。しかし、このような小型のAIモデルでも、その得意な部分(コピー)と苦手な部分(判断)を明確に区別し、苦手な部分は堅牢なプログラミングコードとユーザーによる確認で補うという設計思想によって、実際に役立つ、信頼性の高いツールを構築できることをTicketBackは示している。これは、システムエンジニアがAI技術を実社会の問題解決に応用する上で、非常に示唆に富む事例であると言えるだろう。

関連コンテンツ

関連IT用語