LINEの複数端末ログイン問題と「タブレット向けOS」Android 12L
追記 google I/O 2022での発表とJetpackについての記載を追加中
2022年2月28日にLINE Liteはそのサービスを終了した。
このアプリは通信インフラがまだ整っていない一部地域をターゲットに展開されていたLINEの軽量版アプリである。
一番の特徴は既存のLINEアカウントでのログインが可能なことで、これにより2台のスマートフォンで一つのアカウントを運用することができた。
日本市場向けには配信されていなかったので、日本のユーザーはAndroid端末にミラーサイトからAPKファイルをダウンロードすることで使用していた。
複数端末ユーザーにとっては必須のアプリともいえたが、残念ながらサービスは停止されてしまった。
日本法人はその理由は把握していないようなので、少なくとも日本における非公式的な使われ方が影響したとかではなく、海外戦略上の都合だろう。
一応裏ワザとして複数のスマホで使う方法が無いわけではないが、通知が実質機能しなかったり、スタンプ画面でスクロールができないといった問題があり代替品にはなりえない。
これに際して、「複数端末ログインができないLINEは不便で時代遅れだから淘汰される」といった意見が見られた。
確かに、複数のスマホでログインできるメッセージアプリは存在するが、全体の傾向を見ると時代遅れとは必ずしも言えないのかもしれない。
そして、考察を進めると問題はGoogleの戦略にあるのではないかと考えるようになった。
メッセージアプリの複数端末ログイン対応状況
スマホ向けの代表的なメッセージアプリの複数端末対応状況をまとめた。
中：WeChat（微信）
スマホ+タブレット+PC (app,web)+Apple Watch
韓：Kakao Talk
スマホ+タブレット（AndroidはGalaxy Tabのみ？）+PC app
+スマートウォッチ
日：+メッセージ
スマホ
日：LINE
スマホ+ iPad+PC app+Chromeアドオン+スマートウォッチ
米：Messenger
端末制限なし (App,web,スマートウォッチ)
米：WhatsApp
携帯は一台のみ その他の端末4台 (Web,PC App)
英？：Telegram
端末制限なし (App,web,スマートウォッチ)
米：Discord
端末制限なし (App,web)
表記について
スマホ＝Android,iOS （windows mobileは不明）
タブレット＝iPad,Androidタブレット
App＝それぞれのプラットフォームでのアプリ
PC App＝Windows,MacOSアプリ 中にはLinux対応もあり
Web＝ブラウザ上で起動するサービス 対応ブラウザを使用できる端末全般
スマートウォッチ＝Apple Watch, WearOSで単独運用できるアプリ
スマートウォッチでもBluetooth接続で通知／簡易返信だけできるものは含めないよう心掛けたが、まとまった情報が無いため誤りを否定できない。
また、タブレットにおいても、スマホ版／タブレット版で別のアプリ扱いのものと、アプリとしては同じだがタブレットであることを感知すると既存アカウントでのログインメニューが表れるものがあった。
ここでは双方を区別せずに扱っている。
二つの思想
まとめてみると、これらのアプリには二つの傾向があることが分かる。
一つは、ログインする端末に制限がないアプリである。
Messenger、Telegram、Discordが該当する。
もう一つは、複数のスマホでのログインはできないが、各プラットフォームごとに提供されているアプリ等で複数ログインが可能であるアプリである。
ここにはWeChat、KakaoTalk、LINE、WhatsAppが入る。
仮に前者を開放型、後者を閉鎖型のアプリと呼称するとしよう。
+メッセージは現状複数端末ログインが不可能だが、仮に展開するとしてもpcアプリ程度で複数スマホでログインできるとは考えにくい。
閉鎖型の一種と考えるべきだろう。
（これを比較対象に入れた理由は、LINEは韓国企業が開発したもので日本のアプリの一例にはならないと指摘される可能性があったからである。そのため、日本企業が開発したメッセージアプリを他に追加する必要があった。）
メッセージアプリがこの二つのタイプに分かれた原因はなんであろうか。
少なくとも、開発された時期は関係ない。確かに、Discord (2015)やTelegram (2013)は比較的新しいアプリだが、LINE、KakaoTalk、WeChatとmessengerは同世代である上、この中で一番新しいのが+メッセージ（2019）であることを考えれば無関係であると分かる。
むしろこれは開発元の思想の違い、特にセキュリティに関する考え方が影響していると考えるほうが自然である。
ここには挙げなかったが、他にもSkype(2004)も複数端末ログインが可能である。
このようなPCソフトを出自とするメッセージアプリも含めて、コミュニティサイトやSNSの発想と同じように、（SMS認証はあれど）IDとパスワードがあればどの端末でも使えるという思想に影響を受けたものが開放型なのだろう。
それに対して、閉鎖型は初めから電話番号での登録を前提としたスマホアプリで、不正ログイン等のセキュリティ問題を無視できなかった。
特に、WeChatやLINEはアカウントに決済サービスが結び付き、アカウントが乗っ取られた場合のリスクが高くなっている。
このようにある意味出自としては新しい思想の下で発展したLINEが、度々のセキュリティ不備を指摘される中で、敢えてガードを緩めるような仕様に移るとは到底考えられない。
また、開放型が欧米、閉鎖型が極東地域で開発されているという傾向があることから、セキュリティに関する思想の地域差を指摘することができるかもしれない。
そう考えると、LINE Liteによる複数スマホログインの道を最近まで残していたLINEは実は閉鎖型の中でも複数端末運用に積極的だったとも言える。
それでも、LINEには対応端末を追加できる余地がまだ残っている。
LINEはAndroid タブレット非対応
そう、Androidタブレットが対応端末から抜け落ちている。
正確には、AndroidタブレットにLINEをインストールして使用することはできる。
しかし、それは既存アカウントでのマルチログインではなく、スマホと同じように登録／アカウント移行して使うことができるだけである。
利用には電話番号とSMSでの承認が必須であるため、単独で登録を完結することもできない。
LINEの公式的な立場としては、Androidタブレットはサポート対象外ということになっている。
しかし、同じ閉鎖型のメッセージアプリでも、WeChatやKakao Talkはタブレットでの既存アカウントログインに対応している。
では何故LINEは対応していないのか、そして対応するための条件とは何か。そのヒントはAndroid 12Lにあると考える。
Android 12Lの概要
2021年10月にGoogleはAndroid 12Lを発表した。
これはタブレット、フォルダブルスマートフォン、ChromebookといったAndroid（アプリ）の大画面端末での動作を向上させるために改良が加えられた、Android 12のFeature Drop（新機能）である。
これはAndroidタブレットに関するGoogleの取り組みではここ十年で最大の成果であるといえる。
振り返ると、Googleは2011年にタブレット専用のOSであるAndroid 3.0 "Honeycomb"を導入したが、バグや最適化不足で評判が悪く、その後はタブレット最適化への関心を徐々に失っていったという経緯がある。
https://www.computerworld.com/article/3647997/android-tablet-google.html
自社製品でもNexusシリーズの後継のPixel C（2015）以後はAndroidタブレットを発表せず、2018年のPixel SlateはAndroidではなくAndroid向けアプリの動作環境が導入されたChromeOS搭載端末として発売された。
このことはGoogleがタブレット端末においてはChromeOSに注力し、Androidを放棄した象徴とみなされていた。
Googleがタブレットへの関心を再び強めたきっかけは、Androidアプリに対応した大画面デバイスの需要が近年高まっていることにある。
特にコロナ禍で外出の機会が減る中、自宅での作業・娯楽端末としてのタブレットや教材端末としてのChromebookが売り上げを伸ばし、さらにメーカーの相次ぐ参入によりフォルダブルスマホの市場が拡大している。
もう一つの理由として、ChromeOS搭載のタブレットが本格的にはAndroidタブレットの代用品になりえない現状があった。
プロセッサーにx86(x64)系とArm系が混在するChromeOSではAndroidアプリの互換性が不十分であると度々指摘されていた。
特にx86においては対応していないアプリは32bitでの変換となり、動作が不安定であったり、あるいは起動しなかったりと、Androidアプリを動かす環境としては不完全であった。
https://developer.android.com/topic/arc/device-support?hl=ja
そのため、GoogleはChromeOSと並行してAndroidのタブレット最適化を進める方針に転換したようだ。
2021年にGoogleはタブレットアプリに関する部門のシニアエンジニアの求人を出し、また3月にはAndroidの共同開発者であったRich MinerをOS開発部門に呼び戻してタブレットチームに関与させるなど、体制を整えていった。
https://9to5google.com/2022/01/27/google-android-tablets-2/
同年5月のGoogle I/O 2021では大画面でのコンテンツ視聴を容易にするEntertainment Spaceを発表した。
https://wired.jp/2021/05/07/google-adds-entertainment-experience-android-tablets/
また同時に開発者向けにアプリを大画面端末に調整するための新たな取り組みが紹介された。
そして、10月に発表されたAndroid 12LはそれまでGoogleが進めてきた取り組みの結晶とも言えるだろう。
12Lの主な特徴は
・大画面に最適化されたシステムUI（通知シェードなど）
・マルチタスクを直感的に行うことができるタスクバーの導入
・互換性の向上
・Google Play ストアの変更（後述）
・大画面向けのUI最適化に役立つAPIやツールの追加（Jetpack）
UIの変更や開発者のアプリ最適化を容易にすることで、Androidのタブレット体験を向上させるための第一歩となるものである。
https://developer.android.com/about/versions/12/12L/summary?hl=ja
最後の記事のように12Lを「タブレット向けOS」と表現する媒体もあるが、それは正確ではない。
GoogleはこれをFeature DropまたはFeature Updateと呼んでいる。
APIレベルが12とは異なる（31→32）ことや、内部情報ではAndroid 12.1と表示されていることから、12LはあくまでAndroid 12にいくつかの機能を追加したマイナーアップデート版として見るのが正しいだろう。
実際、12Lのベータ版はタブレット（Lenovo Tab P12 pro）だけでなくスマホであるPixelシリーズにも配信されている。
つまり、12Lはスマホ向けAndroidとは異なるタブレット向けOSではない。
（おそらくAndroid12LはそのままAndroid13に引き継がれる。
12Lで追加された機能はおおよそ13でも実装されるはずである。）
これが意味するのは、現状は異なるプラットフォームとして大画面専用アプリが配信されるような仕組みにはなっていないということだ。
Play ストアの仕様変更からもそれが伺える。
12Lにおけるplay store
12L発表に際してgoogleが発表したPlay ストアの変更は以下の二点だけである。
・アプリが大画面に最適化されていない場合に注意を表示
・開発者がデバイスのタイプごとの星評価を分けて確認できるようにする
前者を説明すると、googleが作成した大画面アプリの品質に関するガイドラインに基づいてアプリは三段階の評価を受ける。
Tier 1 (Best) Large screen differentiated
Tier 2 (Better) Large screen optimized
Tier 3 (Basic) Large screen ready
このうち（おそらく）Tier 3のアプリに対してはタブレットのPlay ストアのページに「このアプリはお使いのデバイス用に最適化されません」の注意書きが表示される。
注意が表示される
12Lに「タブレット向けOS」としての役割を期待していた人は、Play ストアでタブレット専用のアプリが配信可能になるような変更が行われなかったことに落胆したかもしれない。
しかし、そもそも最初からそのような仕様変更は必要なかった。
なぜならPlayストアには大画面端末用のアプリを配布する仕組みがすでに存在していたからである。
画面ごとに別々のAPKファイルを公開する
あらゆる画面構成をサポートする単一の APK を作成することが適切でない場合のために、Google Play では、同一のアプリの掲載情報に対して複数の APK を公開することを許可しています。この機能を使用すると、マニフェスト ファイルで宣言されているように、それぞれが異なる画面構成をサポートする APK を別々に提供できます。しかも、Google Play ストアに個別の掲載情報を作成する必要もありません。
たとえば、スマートフォン版とタブレット版の両方のアプリを公開したいものの、両方の画面サイズ用の 1 つの APK を作成することができない場合、同一のアプリの掲載情報に対して 2 つの APK を公開できます。Google Play は、各デバイスの画面構成に応じて、各デバイスの画面サイズと一致する APK をダウンロードします。
タブレットまたはテレビ専用にアプリを制限する
<supports-screens> マニフェスト要素を使用することにより、スマートフォンでアプリをダウンロードできないようにすることができます
つまり、開発者はスマホ用のアプリとは別に作成したタブレット用アプリ（のAPKファイル）を同一のアプリ画面でタブレットだけに配信したり、あるいはタブレットのみがダウンロードできるアプリのページを作成することが可能であったのだ。
しかし、この仕組みが活用されているかといえば肯定できない。
忘れられているのか、周知されていないのか、あるいはメリットが薄いためにこの配布システムはほぼ使われていないというのが現状であろう。
（あるいは、使われてはいるが、一つのアプリで画面ごとのUI最適化と同一ページでの分離APK配信の違いがユーザー側からは判別できないだけかもしれない。この二つのケースはアプリバージョンが同じか異なるかで見分けられるはずである。）
数少ないタブレット向けアプリの例として、Amazon はスマホ版の他にAmazonタブレット向けのショッピングアプリを公開している。
注意は出ているもののタブレットへのインストールは可能
しかし、現状ではタブレットにおいてもスマホと同じバージョンをダウンロードできる（制限が掛けられていない）上に、この二つのアプリの間にはレイアウト上の違いを感じることができなかった。
（昔は異なっていたらしい。）
一応両者の共存は塞がれているようで、他方を入れた状態でもう一方をダウンロードしようと試みても失敗する。
またスマホにおいては、タブレットアプリをダウンロードできない場合と、スマホ版が入れられていない状態ではダウンロードが可能（だがUIは崩れている）パターンがあり、対応の一貫性の無さから実装が手抜きと見られてもおかしくはない。
レイアウトが崩れている
Google側も端末の画面構成に応じて複数のアプリを展開するという方針を強く推しておらず、むしろ画面サイズごとにUIを切り替える実装を考えているようだ。
タブレット専用アプリが困難である理由
なぜAndroidアプリにおいてタブレット専用アプリではなくスマホと同じアプリを柔軟に使うという方向性が取られるのか。
考えられるいくつかの理由を挙げる。
開発者側のリソース削減
アプリを二つ作るよりは一つのアプリに複数画面を対応させたほうが手間がかからない。
そもそもの話をすれば、メーカーや端末ごとに画面のサイズや比率に多様性のあるAndroidでは、アプリがそれぞれの画面に対応できるように実装することが前提であった。
従来からある仕組みと同じ発想で大画面向けUIを作ろうと考えるのは理にかなっている。
12LではJetpack WindowManager APIを利用したアクティビティの埋め込みにより、通常画面においてはリスト→詳細と遷移するUIを大画面では左側にリスト、右側に詳細と分割して表示するような実装を容易に実現できる。
これは、大画面でのUI最適化にとどまらず、画面分割やフォルダブルの画面切り替えでの画面サイズ変更時においてスムーズなUI切り替えを行うためにも重要である。
画面分割
大画面端末において複数アプリを起動するときに、アプリの展開サイズに合わせてUIやレイアウトを変更することが求められる。
特に、Android12からはアプリのマルチウィンドウサポートが標準となり、すべてのアプリがサイズ変更可能になった。
例えばタブレットでの二画面分割で片方をスマホサイズに、もう片方を大きめの画面で使うような配置であるならば、レイアウトはそれぞれスマホ用と大画面用に最適化されているほうが望ましい。
これを実現するためには一つのアプリでUIを柔軟に変更できる仕様が前提となる。
フォルダブル対応
今後折り畳み端末の需要が増加すると予想される中、アプリはフォルダブル端末のスムーズな画面遷移に対応する必要性がある。
Jetpack WindowManagerによるアクティビティの埋め込みなどにより、内側（外側）の大画面で起動していたアプリを、端末を閉じて外側（半折の一辺）の小さいディスプレイですぐに使用できるという実装が求められている。
当然、大画面用、小画面用でアプリを分けていたのではこの遷移を滑らかに行うことは難しいだろう。
これらの点を踏まえれば、12L導入に際しても開発者が大画面専用アプリの開発へと向かう可能性が著しく低いことが分かる。
Rich Minerは今後Tablet-Firstアプリの登場を期待していると語る。
しかし、これはTablet-Onlyではないのではないか。
タブレットでの使用を想定して作っても、最終的にはスマホでも動作可能であるようなアプリ開発が念頭に置かれている。
そのため、Androidタブレット版LINEはスマホと同じアプリ（APK）でタブレットでも同時ログインできるような方向性で実現させるのが妥当であろう。
事実、他のメッセージアプリではそのようになっている。
メッセージアプリのタブレットログインの例
LINEと同じく複数スマホでのログインが（原則）できない閉鎖型のメッセージアプリの中では、Kakao TalkとWeChatがAndroidタブレットでの同時ログインにすでに対応済みである。
両者ともにアプリバージョンがスマホ・タブレットで同一であることから、双方は端末に関わらず同じアプリ（APK）を配信しているものと考えられる。
（アマゾンアプリはスマホとタブレットでバージョンが異なっていた。）
この二つのアプリでのタブレットログインを検証してみた。
使用したタブレットはGalaxy Tab S5e（One UI 3.1）である。
またアプリバージョンは
KakaoTalkが9.7.5、WeChatが8.0.18である。
KakaoTalk
タブレットでアプリを起動するとQRコードログインの項目が出現する
表示されたQRコードをスマホ版アプリからスキャンする。
その後認証番号をスマホ側に入力することでログインできる。
アプリUIはタブレットに最適化されている。
Googleも大画面に対応した第三者アプリの一つとして挙げている。
なぜか最適化されないという注意が出る
QRコードログインオプションが追加
WeChat
最適化が進んでいないのかタブレットでも縦画面で起動する。
（ Galaxy Tabだとラボ設定で横画面を強制できる。）
「携帯とタブレットでログイン」「タブレットのみでログイン」を選択できる。
既存のアカウントを利用したい場合は「携帯とタブレットでログイン」を選択する。
QRコードが表示されるのでスマホでスキャンするとログイン完了。
UIはあまり最適化されていない。
（数日間使用しないと？）自動ログアウトされるが、登録デバイスをスマホ版アプリ設定から削除しない限りパスワードかSNS認証かQRコード読み取りでログインできる。
「携帯電話とタブレットでログイン」を選ぶとQRコードが表示される
何故Android版LINEはタブレットに対応していないのか
スマホ版と同一のAndroidアプリを利用してタブレットでのログインを可能にしたKakaoTalkやWeChatの存在を踏まえれば、LINEに同様の実装ができない技術的な問題は存在しないと考えていいだろう。
そもそも、これら二つのアプリは12Lを待たずとも対応が済んでいる。
LINEが対応しない理由は他にあるだろう。
日本におけるAndroidタブレットのシェアの低さ
日本でのAndroidタブレットの需要が少なく対応する必要性を感じないからという理由がまず思い浮かぶ。
普通に考えれば一番可能性が高い話であろう。
しかし、これは後述する理由から否定できる、あるいは説得的な理由としては採用できない。
セルラー版タブレット
モバイル通信ができるタブレットの存在を考慮していた。
もしタブレット対応が行われると、実質的に複数のモバイル端末で使用できることになり、セキュリティ上の問題が発生すると考えている。
これはiPad版が存在する以上理由としては論外である。
フォルダブル端末の対応
フォルダブル端末は開いた場合大画面になるので、タブレットとして認識される可能性がある。
そうなると、実質的に複数のスマホで一つのアカウントの運用が可能になってしまい、セキュリティ上の問題が発生する恐れがあると考えているのかもしれない。
確かに、複数端末でのログインが危険だという立場に立つのであれば、現状ではネックになるだろう。
しかし、そもそもフォルダブルが登場する前から対応が進まなかったのだから、理由としては弱い。
異なるプラットフォームとしてのAndroid タブレットOSが存在しないから
それなりに根拠のある論なのが、Androidタブレットにはスマホと異なるプラットフォームが存在しないからというものだ。
この説を補強する例としてWear OS版LINEアプリ開発の経緯が挙げられる。
2022年3月にLINEはWear OS版のアプリを公開した。
今までの（非Wear OS含む）スマートウォッチでもBluetooth接続で通知を確認したり、あるいは簡易返信することは可能だった。
Wear OS版アプリの特徴は、スマートウォッチでログインすることでWi-Fiやモバイル回線接続での単独運用が可能であることにある。（ただし、通知を受け取るためにはBluetooth接続が必要。）
【Wear OS 搭載スマートウォッチをご利用の方へ】
— LINE (@LINEjp_official) March 10, 2022
スマートウォッチからLINEの新着メッセージを見たり、簡単な返信ができるようになりました⌚️✨
スマホが近くになくても、いつでもメッセージを確認できます👍
▶️ https://t.co/RX8j8miIjl
※「LINE」12.3.0、watchOS 3.0、Android 6.0以上で利用可能 pic.twitter.com/e2Z6eiEbuD
そして、タブレットの需要が低いから対応しないという説を却下する理由がここにある。
スマホを製造する際はアプリ対応や手間を考えてAndroidを搭載することがほぼ必須となっている。
それに対して、スマートウォッチを作るうえでWear OSの搭載は必ずしも必要ではなかった。
スマートウォッチに求められているのは、スマホとのBluetooth同期での通知確認や運動時のトラッキング、心拍測定などの機能であるが、その程度の実装なら（IoT製品のように）自社開発のRTOSでも構わない。
そのためスマートウォッチにおけるWear OSのシェアは低いままであった。
（2021年のTizen OSとWearOSの統合により、それまでTizenを使っていたGalaxy Watchに初めてWear OSが搭載された。これが一因となり、Wear OSのシェアは2020 Q3→2021 Q3で14％増加している。）
さらに、LINEアプリをダウンロードできるのはWear OS 3以降の端末に限られるが、現状ではGalaxy Watch 4/4 Classicしか存在しない。
これらの情報を踏まえれば、日本においてWear OS版LINEが利用可能な端末の需要はAndroidタブレットのそれより低いはずがないのである。
では何故Wear OS版アプリは開発されたのだろうか。
実は開発者のインタビューがYoutubeのLINE Developersチャンネルに公開されている。
それによれば、Wear OS版アプリを開発した経緯は、Google I/O 2021において長期的なウェアラブルプラットフォームを進化させるためにGoogleが三星と提携したWear OS 3を発表するなど、昨今のスマートウォッチの普及を受けてのものだという。
これ自体は納得できるものではある。
注目すべきはその前の発言である。
「新しいプラットフォームがリリースされると、できるだけ早く対応するようにしています。これによりユーザーはあらゆるプラットフォームやデバイスで他のユーザーとつながることができます。」
つまり、LINEは今までにないプラットフォームが登場する場合においてアプリ開発へと動き始めると解釈できる。
それならば、現状スマホ用Androidと変わらず、新たなプラットフォームとして普及しているわけではないAndroidタブレットに対して興味を示さないのも理解はできる。
これはある意味利益ではなく、新たな分野に積極的に進出していきたいというエンジニアの開発精神によって左右されているのだろう。
（この方針に納得できるかかどうかは別として、その心構え自体は良いのではないだろうか。）
しかし、そうは言っても需要がWear OSよりは多いであろうAndroidタブレットの対応を進めないのはどうかと思える。
新しくないというならより早い時期に対応させていればよかっただろうに。
（タブレットも同じAndroidだからとは言うかもしれないが、実はiPad向けLINEが出た当時はまだIOSとiPadOSが分かれていなかった。その意味では異なるプラットフォームではない。重要なのは異なる体験が与えられるかどうかにあるのだろうか。）
タブレット対応実現に向けて
仮にこれからLINEがタブレットでのログインに対応するとしたら、どのような展開があり得るだろうか。
いくつかパターンを想定してみた。
①外圧
googleがLINEにタブレット対応を促す可能性。
ちょうどLINEの親会社であるソフトバンクはgoogleとの関係を深めている。
ただ、これまでの展開を見るにGoogle自体がアプリ開発側に積極的に働きかけることは考えにくい。
②プラットフォーム整備
改めてタブレット向けのOSを分立して作る。
それには多くのリソース消費とAndroidの更なる断片化のリスクを抱え込むことになるだろう。
それが難しいなら、12Lをタブレット向けOSとして宣伝し、新しいプラットフォームができたかのように錯覚させるという方法もある。
それに引っかかるかは怪しい。
③時流に乗る
12Lの発表を受けて開発者がアプリのタブレット対応を積極的に進めていく（想定上）中で、その流れにLINEも乗っかる。
現状では話が出ていないだけで、もしかしたら既に水面下で開発が進んでいる可能性もある。
Wear OS版アプリ開発でのきっかけはWear OS 3の発表だった。
同様にGoogleの動きに合わせて12Lをきっかけに開発を決めることも考えられる。
④日本のAndroidタブレット市場再興の流れに乗る
実は、WeChatやkakaoTalkがタブレットでの同時ログインに対応したのはここ2年の話である。
それまではiPadには対応していたというLINEと同じ状態だった。
方針転換の要因はおそらく国内でのタブレット需要の増加にあるだろう。
（中国では華為、韓国では三星 大手メーカーの製品がまず対応した。）
（個人的な見解として）所得を考慮すれば世界でも最悪のAndroidタブレット市場を抱えていた日本においても、この2年間多少潮目が変わったように思える。
2021年夏にはLenovo Yoga Tab 13が国内発売された。
これは日本では6年ぶりに登場したSnapdragon 800番台搭載のハイエンドタブレットであった。（Xperia Z4 Tablet以来）
続いて同年10月にはXiaomi Pad 5が国内市場に投入。
手ごろな値段ながらハイエンド級のプロセッサーを搭載したコスパモデルの登場により、価格も性能も中途半端だった日本のタブレットのレベルは一段と引き上げられた。
そして、今年に入ってからも聯想の最上級製品であるLenovo Tab P12 Proが発売。（またNECからLavie Tab T12としても登場。）
さらに、4月には（一般向けのSシリーズとしては）7年ぶりとなる三星のフラグシップタブレット、Galaxy Tab S8+とUltraが国内発表された。
このように国内でのタブレットのラインナップが充実しつつある現在においてLINEが検討を始める可能性はないだろうか。
問題は投入されている端末の多くが高価格帯で普及モデルとは言い難い点である。
そのため、開発者側がこれを需要の増加としては捉えずに静観するという事態は容易に考えられる。
他には、いずれかの商品が投入されるタイミングでパートナーとして対応を発表するというストーリーがあったが、そのようなバイタリティをメーカーもLINEも（キャリアも）持ち合わせていないようなので実現可能性は低いだろう。
LINEの開発元Naverは三星の元子会社という縁があるためGalaxy Tab S8の上陸の際に何らかのアプローチを行って欲しかったという気持ちもある。
（一方で、現在の親会社であるソフトバンクと三星の確執を考えれば起こりそうもないとも言える。）
いずれにせよ後はLINEの開発グループが動き始めるのを待つしかない。
wearOSアプリを先行して作った彼らのデヴェロッパー精神に期待する。
以下、愚痴。
Googleの役割
※Google I/O 2022前に書かれた文章
12Lでタブレットのサポートへと舵を切ったGoogleの方針は正しいが、それでも異なるアプローチでの介入も考えるべきではなかったか。
今までのAndroidタブレットを取り巻く環境は合理的な悪循環によって形作られていたといえる。
出発点はともかく次のような状況が何年間も続いていた。
Googleがやる気を出さない→アプリ開発者も対応に消極的→アプリが貧弱なので購買意欲が下がる→売れないのでメーカーは撤退・ラインナップ縮小→市場が狭まりGoogleの興味が無くなる＆アプリ開発者も対応に及び腰→消費者の購買意欲が下がる→…………（以後ループ）
また、
市場の縮小→低スペック廉価端末のみに注力→マシンパワーが必要なタブレット向け高機能アプリが開発されない→市場の縮小→……
というスパイラルも同時に存在していた。
上の悪循環の差し手一つ一つは（単純）合理的な判断に基づいている。
とはいえ、そのような判断しかできないならば、メーカーは何も売るべきではないし、GoogleもOSを開発するべきではないだろう。
上の図のアクターの中で特に主導権を持つこの二者は、時に可能性を切り開くための賭けや先行投資を行うべきではないのか。
華為や三星といったメーカーは、（市場戦略からすれば必ずしも合理性が無いわけではないにしろ）ハイエンドタブレットを出し続け、Googleの代わりにカスタムOSのタブレット最適化を進め、市場の沈没を辛うじて食い止めていた。（華為は別の要因で沈没してしまったが）
そして、この粘りがあったからこそ自宅での作業・娯楽器具としてのタブレットの需要が高まった際に他のメーカーの積極的な参入を促すことができたと考えている。
一方、Googleはかつて見捨てたプラットフォームが自分とは関係のないところで盛り上がっているのを見て追従したようにしか見えない。
もちろん、そこで行動を起こさないよりは起こしたほうが全体の得となる。
そして、12Lの、特に開発者向けのツール・コンポーネント追加はOS提供者に望まれる最善の手であり、正しい方向性を歩んでいる。
それでもなお、GoogleにはOSをいじってメーカーや開発者に先を託すだけの消極的な態度ではなく、自らハードに再参入するとか、他の大手IT企業に働きかけて対応を促すなどの積極策を取ってもらいたい。
（あるいは既にやっているのかもしれないが）
特に、Android陣営にアプリを引っ張ってくる役割は今までメーカー側がやらざるを得なかった。
これは開発者とメーカー双方にメリットがあることが前提に実現している（慈善事業ではない）というのは間違いないだろうが、例えばClip Studio PaintやLumaFusionといったクリエイター向けのアプリが三星との提携によってもたらされたような悪循環を強引に断ち切る一手を、果たしてメーカー側に任せていいのだろうか。
METAやTwitterなどの大手IT企業と張り合い、話を持っていけるのは、世界のIT社会を牛耳るほどの力を持つGoogleくらいなのではないか。
そこまで大きな話ではなくとも、日本においてGoogleがAndroid普及のために各アクターに積極的に働きかけたことがあるのだろうか。
Wear OSのGoogle Pay非対応にしろ、しがらみが多い国だとは分かっていても、どうもやる気が見えないGoogleには期待できない。
ユーザーの役割
アプリが完全対応していない、あるいは無かったりする場合、重要だが主導権としては一番弱いアクターであるユーザーは何をすべきだろうか。
対応をお願いしてみる
アプリの問い合わせフォーム等に声を届けてみよう
或いは、Play ストアのレビューに書き込むと反応を拾ってくれるかもしれない
デバッグをする
開発者側は最初からタブレットでの使用が念頭にないのかもしれない
報告されて初めて不具合に気づくこともある
（実際、スマホの環境だと問題の無い表示がタブレットだと著しく崩れている例を発見した）
具体的な環境と条件を添えて報告すると向こうも対応しやすいだろう
買う
ユーザー数の増加は開発者側に対応の動機を与えることになる。
ちょうどGoogleが自らの動きとは無関係に市場が盛り上がっているのを見てタブレット重視に転向したように。
逆説的だが、「最適化されていないからこそ買う必要がある」ということになる。
追記① Google I/O 2022
2022年5月に開催されたGoogle I/OではAndroidタブレットに関する気になる動きがいくつか見られた。
①Googleのタブレット再参入
Googleは自社のタブレット端末を2023年に発表すると告知した。
その外観およびSocとしてTensorを搭載することの他に詳細はないが、再びハード事業に参入することのインパクトは大きい。
（なお、上の記事では「Pixel Tablet」という名称になっているが、発表時に名前が明かされたわけではないためあくまで仮称である。）
Android 12L開発においては、ベータ版・正式版双方ともに対応端末が乏しいことが問題点としてあった。
ベータ版のテスト端末として指定されたのは発表時点ではまだ発売すらされていなかったLenovo Tab 12 Pro、もしくは高価なGalaxy Z Fold 3であり、ほとんどの開発者は第三の手段としてAndroid Studioのエミュレータを使用するという判断を下したであろう。
また、12Lの安定版が公開されて数か月が経過しても、OEM先でのカスタマイズを経由するために未だに対応端末はゼロである。
一方で、スマホにおいてはPixelがベータテスト用端末として使われており、新OSの配信も最速である。
（12Lの大画面用アプリバーを試すために、まず開発者はdpi設定を弄ったPixelを使用したという始末）
Googleが自社製のタブレットを用意すれば、タブレットにおいても同様のスピードでOSの大画面向け開発が進むと期待される。
また、自社製品投入というアクションは、社を挙げてタブレットに注力していく方針を示し、アプリ開発者側にもこれが「一時的な思い付き」ではなく本気であるとアピールすることになるだろう。
（同様にPixel WatchはWear OS普及のための大きな一手である）
②Android 13
I/Oと同時に公開されたAndroid 13 Beta2ではOSレベルでの大画面向け最適化のための機能が追加されている。
12Lで追加されたシステムUIやアプリバーなどの機能はそのまま受け継がれているが、その他にもスタイラスペン使用時のパームリジェクションがサポートされるようだ。
現状では各OEMが個々で対応する必要があるが、OSレベルでのサポートは開発コストの削減に繋がるだろう。
（同様に未だベータ版でしかないデスクトップモードの開発も進めてもらいたい。）
③大画面対応アプリの追加
Googleもタブレット体験におけるアプリ最適化の重要さを理解している。
そのため、まずはGoogle関連のアプリ（20以上）を大画面向けのUIにアップデートすることを発表した。
また他にもサードパーティーとしてTiktokやFacebook、Zoomといったアプリの最適化も告知。
上で述べたような大手IT企業への働きかけを一応行ってはいるようだ。
（Twitterにはフラれる）
④Developers
I/Oに関しては新製品やAndroidの次期バージョンに関する情報ばかりが報じられるが、そもそもは開発者向けのイベントであるため開発環境の変更点やガイダンスについて様々な発表が行われている。
Android DevelopersのYoutubeチャンネルにはI/Oに際して大量の動画が追加されているが、大画面向けアプリ開発に関するものがいくつか含まれている。
（内容はざっくり）
こうなったらいいなというプロモビデオ
Composeを使用して新規アプリを様々なサイズのアプリに最適化する
Composeを利用して既存アプリを大画面に対応させる
大画面向けアプリUIのデザインガイド
入力機器サポートのガイド
キーボード マウス タッチパット スタイラス
Compose Android View
xmlを使用した柔軟なレイアウト作成
追記② Jetpackについて（書きかけ）
※Android開発どころかプログラミングについても素人であるため雑
Googleの大画面向け開発促進のために行った開発環境改善は、Android Studioの12Lのエミュレータを追加、アプリの品質ガイドライン、playストアのデバイス別評価導入を除けば、Jetpackの追加・変更が大半だろう。
(Android) Jetpackの定義は難しいが、Android開発を効率化するためのコンポーネント、ツール、ガイダンス、ライブラリを集めたものと考えておく。
2018年のGoogle I/Oで発表された。
Jetpack導入のきっかけはAndroid開発のためのライブラリが乱立していた状況にある。
In the same way we already have support libraries such as v4 Support Libraries, v7 Support Libraries, Multidex Support Library, v8 Support Library, v13 Support Library, Design Support Library, Wear UI Library, Support Library for TV, v17 Preference Support Library for TV and Android architecture components separately.
Jetpackの前身であったSupport Libraryはこの有様であった。
また名称も混乱しており、v4やv7というのは本来APIレベルの最低要件であったらしいが、結果的にどちらもAPI14まで引き上げられている。
Jetpackは、これらのライブラリを一つにまとめ、他にも新規のツール・コンポーネントを加えることで、開発の難易度を下げ、アプリの完成度を高めるものである。
Jetpackのうち大画面に関わる主なもの
WindowManager
前述 フォルダブルでの画面遷移等に関わる
DragAndDrop
アプリ間のドラッグアンドドロップをサポートする
従来では公式的な開発ツールが存在せず、無理くりで実装していた
2021年12月にα版 2022年5月に正式版がリリース
Compose
UI開発ツール （実はマルチプラットフォーム対応でiOSやウェブアプリ用も存在する） 安定版は2021年中旬リリース
従来のAndroid ViewがXMLを使用する命令型であるのに対して、ComposeはKotlinによる宣言型（宣言型はreactやSwiftUIと同じ）
コードを従来より削減できる→生産性が上がる
上の動画で分かるように、大画面向けUI開発の環境整備はほぼComposeの改修である
Composeは未来！
Jim Sproch (ComposeのProgenitor:開発者)曰く
従来のAndroid Viewはメンテナンスモードに
新しい機能開発、バグ修正はComposeに一本化される
Jetpack Composeは未来です！https://t.co/3rsJcYblaV
— Jim Sproch (@JimSproch) April 22, 2022
（ただし、Googleから公式的にコメントされているわけではない。
それでも、現在も自ら引用している以上方針が変わったということもないようだ。）
→新規アプリ開発ではComposeが優先 既存も新規機能を使うために移行圧力がかかる
（大画面UI開発の観点から見た）メリット
導入圧力があるために優先的に使用される
→環境が整い、大画面UI開発のコストが削減 導入の障害を緩和
デメリット
移行に時間がかかる
移行を進めている企業もまずは追加分から導入
既存部分の移行がなかなか進まない
情報不足
xmlと比べて蓄積がなく、問題発生時に簡単に解決策が見つからない
互換性（関連性）
まだAndroid Viewに存在した機能が全て揃っているわけではない
ネック
Composeを前提としたgoogleの大画面対応策は既存アプリのCompose移行を必要としているのだから時間がかかる。
（真っ先にComposeを導入して「コード削減で開発効率化できた」例としてDevelopersでも取り上げられていたTwitterがこの始末）
従来のXmlを利用した大画面向けレイアウト作成ガイドを今公開するというのは、すなわちGoogleとしてもCompose移行を待たずとも先に大画面対応を促したいという妥協策を取っているのではないか。
→動画を改めて見返すと、ComposeだけでなくAndroid View用のAPIも追加している節がある
勿論、推奨されているのはComposeのほうではあるが、互換を切るようなことはしていない。
#Google
#Android
#タブレット
#Androidタブレット
#Android_12L
#LINE
#複数端末ログイン
#Playストア