視覚障害者を補助するAI画像認識アプリ「スイフトアイ」を支える技術
はじめに
スイフトアイは視覚障害者を補助するAI画像認識アプリです。カメラで撮影した画像や写真アプリなどから共有された画像をAIが解析して、文章で読み上げます。
以下のアプリ紹介動画（3:30頃から）をご覧いただくと、動作の様子がご確認いただけます。本記事では、このアプリ開発の裏側を少し紹介します。
処理はサーバーで行う
まずは処理の方式についてです。本アプリの画像解析はGoogle Geminiを利用してサーバー上で行っています。
オンデバイスで動作する超小型のモデルも増えつつありますが、image-to-textタスクをオンデバイスで実行するにはハードウェアの性能が足りません。必然的にサーバーで処理する方式となります。
追記 2025-05-14
本記事の投稿直後にオンデバイスで画像認識を行うHeronというアプリが登場しました。Turing Motorsが開発したVLMです。
早速iPhone 15 Proで試したところ、数百msのオーダーで画像の説明文が生成されました。驚異的です。
ただし、間違った回答や意味不明な文章が出力されることも多いため、依然としてサーバー上でモデルを動作させる方式を置き換えるものではありません。とはいえ、オンデバイスで実現可能な範囲が広がる可能性を感じますし、今後の流れに注目です。
モデルには癖がある
今やマルチモーダルなモデルはありふれています。image-to-textのような基本的タスクをこなすだけであれば、モデルの差は生じないように思えるかもしれません。
しかし、実際に試してみるとモデルごとに固有の癖があることに気がつきます。一例として記事冒頭で紹介した動画ではApple Intelligenceとの回答が比較されていますので確認してみてください。
差が生じやすい項目の例
- 詳細より全体像を優先する: 画像に含まれているテキストを書き起こしさせると、画像全体の様子から類推されるキーワードで内容を置き換える。
- 過剰に説明的: 画像の中に同じようなパターンが繰り返し現れる場合に似たような説明を何度も繰り返す。
- 回答が曖昧: 間違った解答を避けようとして無難でつかみどころのない解答を返す。
多くのモデルを試した結果、記事を投稿した時点ではGemini 2.0 Flashが解答完了までの速度と内容の正確さ、コストのバランスが取れていると感じています。記事投稿時点では最新のモデルとしてGemini 2.5系がリリースされていますが、依然として2.0のバランスが最も優れていると感じています。
ただし、あくまで現時点での評価であり、今後より高性能なモデルが登場する可能性もあります。また、長期的な観点では各種モデルの性能差は縮小すると予想しています。
なお、モデルの評価方法については秘伝のタレということで本記事では詳細を省きます。１点だけヒントを与えると、利用者の立場になって徹底的に考えるのがコツです。
例えば、目が見えなくても触って判断できるものや様子について、あえて写真を撮影して解析させる頻度は低いと予想できます。そうすれば、どのような画像でモデルを評価するべきか、対象は絞られていくはずです。闇雲にあらゆる状況で万能なモデルを探すより実用度は高まります。
プロンプトエンジニアリングは行わない
ここでは期待する回答へ誘導する行為をプロンプトエンジニアリングと定義します。エンジニアリングの程度は製品によって様々ですが、例えば開発者向けのコーディング支援ツールではその膨大なプロンプトが度々話題になります。
本アプリにあてはめると、例えば視覚に障害のある方への説明方法として有名なのがクロックポジションです。例えば風景を撮影した画像があるとして、10時の方向に建物がある、といった具合にアナログ時計の文字盤でポジションを伝える方式です。
それでは、スイフトアイはプロンプトとして、どのような内容を指定しているのでしょうか？以下に全文を掲載します。
この画像には何が写っていますか？視覚に障害のあるユーザーを想定し、文章だけで内容が伝わるように回答をお願いします。
以上です。驚くべきことに、上記のプロンプトで記事冒頭に紹介した動画のような回答が得られます。プロンプトエンジニアリングは全く行っていません。
Geminiは視覚障害から連想される要件も暗黙に汲み取って解答を生成してくれます。下手にあれこれ指示するよりも素朴な指示の方がモデルの性能を引き出せる場合もあります。
また、プロンプトエンジニアリングを行わないことで、モデルを差し替える自由度が増す利点もあります。あるモデル固有の癖を回避するための指示が、別のモデルでは間違った解答や不自然な解答を誘発する原因になる場合もあります。
プロンプトの再利用が効果を発揮せず、結局モデルに適したプロンプトを都度作成する必要に迫られては面倒です。ならば、最初はプロンプトエンジニアリングを行わず、必要が生じた段階で最小限のプロンプトを追加するのが妥当です。
結果として、アプリの運用開始から記事投稿した現在までプロンプトの変更は全く行っていません。
画像の解像度にはスイートスポットがある
image-to-textタスクで問題になるのがモデルへ入力する画像の解像度です。大きければ画像の隅々まで詳細を正確に判断できますし、小さければ高速なレスポンスが期待できます。また画像の解像度に応じて消費するトークンも上下します。
それでは、スイフトアイの場合はどのように処理しているかというと、解像度が1 MP以下になるようにリサイズしてからGeminiに入力しています。この1 MPという数値は計算で求めたのではなく、画像認識を何度も試しながら得られた訂正的な評価に基づきます。
商品パッケージに書かれたテキストの文字起こしや風景写真の解析など、利用シーンは様々あります。しかし、どのシーンでも最低限確保するべき解像度はあまり大差ないことがわかりました。
このようなパラメータのスイートスポットは実際に試さなければわかりません。さらに、この値はあくまで現時点でのニーズに基づいた値であり、広く一般に適用できるものでもありません。
生成AIはあくまでプロダクトを実現するためのビルディングブロックに過ぎません。制御可能なパラメータの中で、快適なユーザー体験に影響する部分を見極めてチューニングするのは依然として人間の役割です。
おわりに
画像の内容をテキストで説明するだけの一見単純なアプリではありますが生成AIを活用する題材として思いのほか奥が深いです。需要があれば、さらに深掘りした記事も書こうかと思います。
Discussion