GCPとLINEで実現する画像テキスト自動抽出Bot
はじめに
こんにちは。
ソフトウェアエンジニアとして IT 企業に入社して 2 年目になる YamaTo です。
今回は、LINE のチャットルームに送られた画像を OCR 技術を用いて解析し、適切なテキストデータとして返す Bot を開発しました。
1 人で開発・リリース・本番運用まで持っていったその背景についてお話ししようと思います。
気が向いたら、どこかで実装方法についても詳細を載せる予定です。
開発背景
所属するスポーツチームでは、LINE グループを通じて毎月 1〜2 回行われるリーグ戦の試合情報を共有しています。
しかし、大会の運営側から個別に連絡が来る仕組みはなく、開催日や会場、対戦相手、当日の注意事項といった情報は、公式のランディングページ（以下 LP）が更新される形で全体に公開されるのみです。
本来であれば、チーム全員がその LP を都度確認すれば問題ありません。ところが実際には、全員が欠かさず確認するのは難しく、情報が行き届かないこともありえます。そこで私は、LP が更新されるたびに該当箇所をスクリーンショットして LINE グループに投稿し、さらに自チームに関する情報だけを抜き出してテキスト化し、リマインドする作業を続けてきました。
最初はそれほど負担を感じなかったものの、同じ作業を毎月繰り返すうちに「これは自動化すべきだ」と考えるようになりました。
自動化の方法を検討するにあたり、以下の要件は必ず満たす必要があると考えました。
- LP に載っている一次情報はそのまま共有すること
- 万一誤りがあっても、グループ内のメンバーが気づいて修正できる（自然なダブルチェック）
- 画像から情報を抽出するテキスト化のプロセスは必ず自動化すること
- 手動でのテキスト入力は誤変換や書き間違いのリスクがあるため避けたい
- 人手による再入力や手作業の介在を極力排除すること
これらを踏まえて最終的にたどり着いたのが、
「試合情報が載った画像を LINE グループに送り、API で画像を解析し、Bot が決まったフォーマットで通知してくれる仕組み」 でした。
画像解析の知識はほとんどありませんでしたが、現在は便利なライブラリやクラウド API が数多く存在します。そこで「とりあえず試してみよう」という姿勢で開発に着手しました。
アプリ概要
チャットルームに送られた画像に対しての返信メッセージをトリガーに、画像を解析。
↓
テキストデータを抽出し、Web アプリにレスポンス。
↓
Web アプリ内で整形し、チャットルーム内で返信。
以上のプロセスを踏む流れとなっています。
※チューリップが Bot です
システム図
各ソフト間でのデータの流れを示しています。
使用技術
| 項目 | 使用技術 |
|---|---|
| ランタイム / 言語 | Node.js TypeScript |
| Web フレームワーク | Express |
| API | LINE Messaging API Google Cloud Vision |
| 実行基盤 | Docker Google Cloud Run |
| デプロイ / セキュリティ周り | Artifact Registry Secret Manager |
選定理由
今回の開発に当たって使用した技術の選定理由になります。
つらつらと書いていますが、特に意識したポイントは 3 つです。
- 金銭コスト
- より安価にできるか
- 開発コスト
- スピーディーに実装・リリースまで持っていけるか
- 運用コスト
- アプリを拡張していく可能性も見据えて、変更容易な構成か
これらは日々の Web アプリケーション開発・運用業務の中でも常に意識しています。
Node.js
LINE Messaging API の公式 SDK としてサポートされている点が大きな決め手です。
小規模な Web アプリケーションであるため、運用コストは可能な限り抑えたいと考えました。
また、SDK を利用しない場合はリクエストやレスポンス処理を自前で実装する必要があり、開発効率の低下につながる懸念があったため、公式 SDK のある Node.js を選定しました。
Google Cloud Vision
「画像からテキストを検出する」という要件を満たし、多言語にも対応している点に魅力を感じました。
さらに、他の OSS や生成 AI ベースの OCR と比較して、精度とコストのバランスが良いことも利点です。利用規模も月に数十リクエスト程度と見積もっており、料金体系を踏まえても 1000 リクエストを超えることはなく、十分にコストを抑えられると判断しました。
加えて、Node.js 向けの公式クライアント SDK（@google-cloud/vision）が提供されており、実装の容易さや開発効率の向上につながる点も選定理由としました。
Google Cloud Run
アプリケーションの性質上、常時稼働する必要はなく、リクエストがあったときだけ処理すれば十分でした。そのため、サーバーレスで自動スケーリングしてくれる Cloud Run は要件に適していました。
また、Docker コンテナをそのままデプロイできる点も大きな利点で、既存の開発環境から本番環境へ移行しやすいというメリットがあります。
さらに、料金体系がリクエストベースであり、小規模利用ではコストを抑えやすいことも選定理由のひとつです（無料枠もあるため、少量利用であればほぼ追加コストなしで運用可能）。
加えて、Artifact Registry や Secret Manager といった他の GCP サービスとシームレスに連携できる点も、運用面での安心感につながりました。
今後の展望
画像から抽出したテキストデータを整形して、Bot で返信をするという当初掲げた仕組みに関しては実装することができました。
しかし、運用をする中で写っている情報の構造やそのものの大きさが異なっている画像に関しては、上手く適切な情報をチャットルームに返信できないことが確認できました。
デバッグする中で、画像内のテキストデータそのものの取得は問題なくできているものの、ユーザーに送る適切なレスポンスに整形する過程で上手くいかないことがわかっています。
今後の運用で、この問題を少しずつ改善して、どんな構造の画像データでも適切に読み取り返信ができるよう努めて行けたらと思います。
Discussion