スマホの手話AI：PixelのASLテキスト変換と音声以外のAIアクセシビリティ設計
スマホの手話AIの現在地を、Pixel 11のASL-to-English入力、Android支援機能、手話と音声文字起こしの違い、FoneClawの現在の範囲から整理します。
- スマホの手話AIは大きな前進を見せていますが、現在の実用範囲はPixel 11から始まるASL-to-EnglishのGboard dictationとLive Transcribe対応として見る必要があります。
- 手話AIは音声文字起こしとは別物です。手話は独立した自然言語で、手、顔、体、空間、時間表現を同時に使うため、英語の単語置換では設計できません。
- Androidのアクセシビリティは、手話入力、typed text、Live Transcribe、Live Caption、RTT、Switch Access、視覚確認、振動などをタスクごとに組み合わせて使います。
- FoneClawは現在、手話認識やDeepMind SL2T連携を主張しません。 typed interaction、ユーザー選択の文脈、Tool policy、見えるタスク状態、停止、復旧を通じて、音声以外のphone-agent設計を改善していきます。
スマホの手話AIで今できること
AIはスマホで手話を理解できるのか。現在の答えは、「一部の端末と一部の言語入力で、実用的な入口が始まった」です。Google DeepMindのsign language AIをユーザーの手元へ届ける発表では、SL2TがPixel 11から、ASL-to-Englishのsign dictationとしてGboardとLive Transcribeに入ることが示されています。これは、スマホの手話AIにとって大きな節目です。ただし、すべてのAndroid端末、すべての手話、すべてのアプリ操作で使えるという意味ではありません。
現在の中心は、ASLを英語テキストへ変換する入力です。Gboardでのdictationなら、手話から生成された英文を入力欄へ入れる用途に向きます。Live Transcribeでの利用なら、会話の橋渡しとして役立ちます。どちらも、スマホ上で言語入力や会話支援を広げる機能です。Androidアプリを直接操作するAIエージェント機能とは別に考えます。
ここで重要なのは、手話AIを「音声入力の別版」として扱わないことです。手話をテキストにできることは、phone-agent actionを自動で許可することではありません。たとえば「母に今から行くと送って」というASL入力が英語テキストへ変換されたとしても、その後には、相手の解決、アプリの選択、送信前確認、結果表示、失敗時の戻り道が必要です。
More devices and languages are described as future workという流れはありますが、読者が今確認すべきなのは、自分の端末、言語、アプリ、設定で実際に使えるかです。スマホの手話AIは、音声以外のAIアクセシビリティを前へ進めます。同時に、言語入力と安全なスマホ操作を混同しない設計が、phone-agent builderに求められています。
手話翻訳は音声文字起こしと違う
手話AIは音声文字起こしと同じではありません。音声文字起こしは、話された音をテキストに変える技術です。手話翻訳は、視覚言語を別の書き言葉へ訳す技術です。手話は世界共通のジェスチャー集ではなく、ASL、BSL、日本手話、フランス手話など、それぞれ独立した自然言語です。世界には200以上の手話があるとされ、ASLがすべての手話を代表するわけではありません。
手話では、手の形だけでなく、動き、位置、向き、顔の表情、視線、体の傾き、空間の使い方が意味を持ちます。文法も音声英語や書き英語と同じではありません。複数の情報が同時に表現されるため、単語を一つずつ置き換えるだけでは訳せません。特定のhandshapeだけを覚えるグローブ型やジェスチャー辞書型の発想では、実際の言語としての手話を十分に扱えない場面があります。
この違いは、phone-agent designにも影響します。翻訳されたテキストは、ユーザーの意図の候補です。誤訳や曖昧さがある場合、エージェントはすぐに操作へ進まず、文脈を確認し、選択肢を見せる必要があります。特に送信、発信、予定変更、共有、削除のような操作では、翻訳結果をユーザーが読み直し、修正できる画面が必要です。
ろう者向けスマホアシスタントを考えるなら、手話を「声の代替入力」ではなく、独立した言語入口として扱います。入力方法が変わっても、安全な実行設計は変わりません。相手、本文、アプリ、権限、承認、結果確認を分けて、ユーザーが自分の言語で判断できる状態を作ることが大切です。
SL2Tの仕組み、根拠、プライバシーの境界
DeepMindの説明では、SL2Tは端末のカメラ映像からMediaPipe Holisticでpose landmarksを抽出し、幾何学的な座標をサーバーへ送り、raw videoは破棄されるとされています。その上で、直接landmark-to-textの翻訳モデルが動きます。ここでの設計は、すべてが端末内で完結するという話ではありません。on-device landmark extractionとserver translationを分けて理解します。
学習規模も大きなポイントです。DeepMindは、100,000時間を超えるデータと50以上の手話を含む学習について説明しています。ただし、現在の製品対応はASL-to-Englishから始まります。多言語の研究データや将来の拡張可能性と、いまPixel 11で使える入力機能は分けます。スマホの手話AIを過大評価しないためには、この境界を読者に見せることが重要です。
精度についても、ベンチマークだけで語りません。DeepMindは、rare signs、rapid fingerspelling、classifiers、passive constructions、tenseに関するエラー例を示しています。これは弱点を誇張する話ではなく、実用時に確認すべき場所を教えてくれる情報です。固有名詞、指文字、専門語、時間表現、受け身表現が含まれる入力では、変換結果を見て直す流れが必要になります。
プライバシー面では、raw videoが破棄されるという説明と、landmarksがサーバーへ送られるという設計を両方見る必要があります。landmarksは映像そのものではありませんが、すべての文脈で法的に匿名データと断定してよいわけではありません。ユーザーにとって重要なのは、何が端末で処理され、何がネットワークへ送られ、どの機能で必要になるかを把握することです。
この節の結論は、SL2Tが手話入力をスマホ上で現実的にする一方、確認と修正を前提に使うべき技術だということです。phone-agent builderは、入力の革新をそのまま実行許可に変えず、翻訳結果、意図、権限、承認、結果を一段ずつ分けます。
スマホタスクごとに入力と出力を選ぶ
アクセシブルなAIエージェントを作るとき、入力方法を一つに決める必要はありません。手話入力、typed text、音声入力、Live Transcribe、Live Caption、RTT、Switch Access、画面上の視覚確認、振動、字幕、TTSは、それぞれ役割が違います。大切なのは、ユーザーを一つのモードへ押し込めないことです。場面、端末、言語、疲労、周囲の環境、通信状態によって、使いやすい経路は変わります。
| タスク | 入力の候補 | 出力・確認の候補 | 注意点 |
|---|---|---|---|
| 短いメッセージ作成 | 手話入力、typed text、音声入力 | 画面上の下書き、編集、送信前確認 | 固有名詞と宛先を必ず確認する |
| 対面会話の理解 | Live Transcribe、typed response | 画面テキスト、sound labels、history controls | 音声文字起こしは手話認識ではない |
| 動画や通話の内容把握 | 対応メディアの音声 | Live Caption、call captions、typed responses | Live Captionのon-device説明をSL2Tへ広げない |
| 電話での文字会話 | RTT、typed text | リアルタイムテキスト、視覚通知 | 通信事業者や端末対応を確認する |
| 端末操作 | Switch Access、typed commands、画面選択 | フォーカス表示、振動、画面結果 | 操作経路とAI推論を分ける |
| AIエージェント依頼 | typed text、選択した文脈、将来の手話入力 | action preview、承認、task state、fallback | 入力理解だけで実行しない |
AndroidのAccessibility overviewでは、画面読み上げ、caption、switch、braille、RTTなど複数の支援機能が示されています。Live Transcribeは近くのspeechやsoundをscreen textへ変え、typed responsesやsound labels、history controlsを扱います。Live Captionは対応するmediaやcallsのcaptionsを表示し、GoogleはLive Captionについてon-device processingを説明しています。
これらを同じものとして扱わないことが大切です。Live Transcribeはspeech-to-text、Live Captionはmedia/call caption、SL2Tはsign-to-text、Switch Accessは非タッチ操作、RTTは通話中の文字会話です。FoneClawのようなphone agentは、これらの入力や出力から得たユーザー意図を、対応済みAndroid操作へつなげる設計を考えます。
視覚障害やロービジョン向けの音声操作とは、必要な確認設計が変わります。TalkBackやVoice Accessとの比較は、視覚障害のある人向けAndroid音声操作：TalkBack、Voice Access、FoneClawの使い分けで扱っています。本記事では、手話AIの節目から、音声以外の入力とphone-agent actionをどう分けるかに集中します。
言語入力とphone-agent実行を分ける
Android 手話 テキスト変換ができても、それはAndroidアプリ操作の完了ではありません。翻訳された文は、エージェントに渡せる入力になります。しかし、エージェントはその文を読んだ後に、意図、対象、アプリ、権限、承認、結果確認を解決する必要があります。これは音声入力でもtyped textでも同じです。入力がアクセシブルになったからといって、送信や削除が自動で許可されるわけではありません。
たとえば、ASLから「Alexに今夜の予定を送って」という英文が出たとします。ここで必要なのは、Alexが誰か、どのアプリで送るか、予定内容はどこにあるか、本文をどう書くか、送信前に確認するか、失敗したらどう戻るかです。翻訳が少しずれている場合、特に名前、日時、場所、否定、条件が含まれる場合は、確認画面が重要になります。
アクセシブルな確認は、音だけに依存してはいけません。ろう者や難聴者が使うphone agentでは、画面上のaction preview、編集可能な下書き、状態表示、振動、視覚的な完了表示、明確な停止ボタンが必要です。TTSだけで「送信してよいですか」と聞く設計では不十分です。入力と同じくらい、確認と結果の出し方がアクセシビリティになります。
FoneClawでは、capability routingとexecution authorityを分ける考え方を採用しています。候補ToolやWorkflowが見つかることは、実行許可ではありません。AutoAttach、Suggest、Fallbackのような能力選択の仕組みを詳しく知りたい場合は、AIエージェントの能力ルーティング：AutoAttach、Suggest、FallbackでAndroid操作を選ぶ実践ガイドで、候補選択と実行承認を分けて説明しています。
FoneClawを音声以外のアクセシビリティで見る
ここでFoneClawの現在の境界を先に明確にします。FoneClawは、現時点で手話認識、SL2T integration、DeepMindとの連携、アクセシビリティ認証を主張しません。FoneClawが現在提供しているのは、Android phone-agent runtimeとしてのtyped interaction、ユーザーが選んだ文脈の利用、対応済みTool、Tool policy、visible task state、停止、permission recovery、結果確認の設計です。
私たちがFoneClawを作る中で学んだのは、アクセシビリティを音声だけに寄せると、phone agentの入口が狭くなるということです。音声は便利ですが、誰にとっても最適な入力ではありません。typed textで頼みたい人、画面を見ながら確認したい人、現在画面を自分で添付して文脈を渡したい人、音ではなく視覚的なタスク状態を見たい人がいます。FoneClawでは、AIの入口とAndroidの実行を分け、ユーザーが見える形で判断できる体験を重視しています。
たとえば、ユーザーがtyped textで「この画面の内容をもとにメモを作って」と頼む場合、モデルは内容を理解し、FoneClawは対応済みToolへ進みます。現在画面の文脈が必要なときは、ユーザー操作で添付します。Capability matchingは候補選択であり、保存や送信を自動で許可しません。高い影響を持つ操作では、action preview、承認、停止、結果確認を分けます。
現在画面を使う設計の詳しい話は、Android フローティングAIアシスタント 画面認識：現在画面から安全に操作へ進む方法で扱っています。私たちはこのような文脈入力を、将来の手話入力と同じく「意図を伝える入口」として考えます。入口が増えても、権限、承認、監査、復旧の設計は必要です。
FoneClawの次の課題は、音声以外の入力でも同じくらい分かりやすい操作状態を保つことです。下書きがどこにあるか、どのToolが候補か、何を承認するのか、どこで止めるのか、失敗時に何が足りないのか。これらを画面で読み取れるようにすることが、アクセシブルなAIエージェントに近づく道です。
ろう者と一緒にphone agentを検証する
手話AIやろう者向けスマホアシスタントは、当事者抜きで設計できません。DeepMindは、concept、data、evaluation、impact assessmentにDeaf participantsやadvisory committeeが関わったことを説明しています。これは、単にデータを集める話ではなく、どの課題を解くべきか、どの失敗が深刻か、どの確認方法が使いやすいかを、実際の利用者と一緒に決めるということです。
検証では、言語の範囲を最初に確認します。ASLなのか、日本手話なのか、別の手話なのか。地域差、年齢、学習背景、片手での表現、左利き、カメラ位置、立った状態、座った状態、照明、服装、背景、スマホの持ち方も影響します。DeepMindが実用上の課題としてleft-handed and one-handed signingに触れていることは、研究精度だけでは見えない現実の使い方を示しています。
次に、失敗時の修正を確認します。rare signs、rapid fingerspelling、classifiers、passive constructions、tenseのようなエラーが起きたとき、ユーザーが画面上で直せるか。候補を選べるか。入力をやり直せるか。typed fallbackや別のモードに切り替えられるか。ベンチマークの平均値ではなく、誤訳が起きた瞬間の修復経路を見ます。
phone agentの実行まで含めるなら、権限と監査も見ます。誰の名前を解決したか、どのToolを使うか、どのデータへアクセスするか、何を承認するか、結果がどこに出るかを、音声なしで理解できるか。権限と監査ログの設計は、AIエージェントのアイデンティティ、権限、監査ログ：ツール単位で安全に実行する設計で詳しく扱っています。
一人のテスターや一つのデモで、コミュニティ全体の使いやすさは判断できません。ろう者、難聴者、手話通訳者、家族、職場、医療や公共窓口など、利用場面ごとに期待とリスクは変わります。アクセシブルなAIエージェントは、技術の精度だけでなく、当事者が修正し、止め、説明を受けられる設計を持つ必要があります。
音声以外のphone workflowを小さく試す
最後に、音声以外のphone workflowを使う前に、小さく検証します。最初のタスクは低リスクにします。たとえば、手話入力やtyped textで短いメモを作る、現在画面から要約を作る、送信せずに下書きを作る、予定を開くだけにする、といった作業です。送信、発信、削除、共有、設定変更は最初のテストに向きません。
- 入力結果を確認します。手話から出たテキスト、typed text、captionが意図に合っているかを見ます。
- 対象を確認します。相手、アプリ、ファイル、予定が正しいかを確認します。
- 権限を確認します。カメラ、マイク、通知、連絡先、位置情報、ファイルアクセスを分けます。
- 実行前にaction previewを見ます。何が起きるか、どこで止められるかを確認します。
- 結果を確認します。保存されたか、画面に出たか、失敗理由が見えるかを見ます。
- fallbackを試します。カメラなし、ネットワークなし、認識失敗、権限拒否でも別の入力へ戻れるかを確認します。
一回の成功は、すべての場面の保証ではありません。スマホの手話AIは、音声以外のAIアクセシビリティを広げる強い節目です。ただし、phone-agent builderが学ぶべきことは、入力を増やすだけでは不十分だという点です。翻訳、意図解決、Tool選択、承認、結果、復旧を分け、ユーザーが自分の方法で確認できることが、アクセシブルなAIエージェントの土台になります。