theonehub.app

KEYBOARD — キーボードとターミナル入力

キーボードアプリとプライバシー — あなたの入力はどこへ行くのか

公開日 更新日 執筆・編集 Sons Labo

キーボードアプリとプライバシー — あなたの入力はどこへ行くのかのアイキャッチ

キーボードアプリはすべての入力が通る場所。INTERNET 権限、クラウド変換、入力学習の観点から、安心できるキーボードの見分け方を解説します。

この記事の目次

Android でキーボードアプリを入れたとき、「このアプリにインターネットへのアクセスを許可しますか」と聞かれた記憶は、おそらくないはずです。聞かれないのは、通信の権限がインストール時に自動で付く「標準の権限」に分類されていて、実行時にリクエストする必要がないからです。Android の公式ドキュメントにそう明記されています(ネットワークに接続する)。一方 iOS では、他社製キーボードは初期状態でネットワークにアクセスできず、開発者が設定ファイルで「オープンアクセス」を要求し、ユーザーが「フルアクセスを許可」をオンにして初めて通信できる二段構えです(App Extension Programming Guide)。同じ「入力を預ける」道具なのに、片方は無言で通り、もう片方には関門がある。この非対称を知っているかどうかで、キーボードを選ぶときに見る場所が変わります。

キーボードアプリは、スマホの中で最も深い場所に立つソフトウェアです。検索語やメッセージの下書きなど、機微な文字列を扱うことがあります。ただし、OS の自動入力やアプリ独自のキー、iOS の保護された入力欄など、第三者キーボードを通らない経路もあります。この道具のプライバシーを考えることは、決して神経質な話ではありません。

この記事では、この話は「怪しいアプリを見抜く」という話に矮小化しないほうがよいと思っています。問題の中心は悪意ではなく構造です。キーボードという場所が構造的に何を見られるのか、データがどんな経路で外に出うるのか、そしてそれをユーザーがどう確認できるのか。以下ではその構造を順番に解きほぐし、最後に手元の端末で権限を実際に確かめるコマンドまで落とし込みます。

キーボードは何を「見て」いるのか

まず前提の整理です。スマホのキーボードアプリは、OS の IME(入力メソッド)の仕組みの上で動きます。あなたがどこかの入力欄をタップするとキーボードが立ち上がり、以後、その入力欄に打たれる文字はすべてキーボードアプリの処理を通ってアプリに渡ります。日本語なら、かなを漢字かな交じり文に変換する処理もキーボード側の仕事です(この流れは IME の仕組みの記事で詳しく書きました)。つまり「入力内容が見えている」のは盗み見ではなく、仕事のために必要な、正規の設計です。

OS からは、いまの入力欄がどんな種類か(通常のテキストか、パスワード用か、メールアドレス用か)といった情報もキーボードに伝わります。Android の IME 開発ガイドには、入力欄がフォーカスを受け取ると EditorInfo オブジェクトが IME に渡され、その inputType フィールドに入力タイプが格納されていると書かれています(入力メソッドを作成する)。まともなキーボードがパスワード欄で学習を止められるのは、この通知のおかげです。一方で、キーボードに見えないものもあります。キーボードが立ち上がっていない間の画面や、他のアプリの表示内容は、キーボードアプリの守備範囲外です。見えるのは、あくまで自分が入力を担当している瞬間の、入力に関わる情報です。

それでも十分に重い。1日に打つ文字を思い浮かべてください。メッセージ、検索語、ログイン情報、仕事のメール。人がスマホに打ち込む文字列の全集合は、その人の生活と内面の記録そのものです。それが全部通る場所の信頼性は、アプリ1個の話ではなく、スマホというデバイス全体の信頼性の土台になります。

ひとつ補足すると、外付けの物理キーボードをスマホにつないで打つ場合も、日本語変換は端末内の IME が担います。つまり物理キーボード派も、この記事の話と無関係ではありません。文字の発生源が画面上のキーか物理キーかに関わらず、変換と学習を扱うソフトウェアの素性という論点は共通です。

入力の処理、通信機能、保存や同期の方針を分けて確認する
入力の処理、通信機能、保存や同期の方針を分けて確認する
画像を選ぶと拡大できます。
  1. 入力内容は、キーボードアプリの処理を通ります。
  2. 通信できる機能や権限があるか確認します。
  3. 学習、同期、保存の扱いを、設定と説明で確認します。

リスクの構造を分解する

キーボードアプリが入力内容を外部に送りうる経路は、主に3つです。

  1. クラウド変換: 変換や予測の精度のために、入力中の文字列をサーバーへ送って処理する設計。送信そのものが機能の一部で、隠されているわけではないが、利用者がそうと知らずに使っていることが多い
  2. 入力学習の同期: 学習した語彙・入力履歴・ユーザー辞書をアカウントに紐づけてクラウドに保存し、複数端末で同期する機能。便利さと引き換えに、入力傾向の記録が端末の外にも存在することになる
  3. テレメトリ・広告: 利用状況やクラッシュ情報の収集、広告のための識別子の利用。無料アプリの収益源になっていることがあり、収集の範囲はアプリごとに大きく異なる

大事なのは、この3つのどれも「悪意」とは限らないことです。クラウド変換は実際に変換を賢くしますし、同期は機種変更を楽にします。利便性との交換としてプライバシーポリシーに明示されていることも多い。問題は、キーボードという場所の重さを考えると、この交換が割に合っているかをユーザー自身が判断すべきなのに、その判断の機会に気づきにくいことです。インストール時に規約を精読する人はほとんどいませんし、キーボードは一度入れたら意識から消える道具だからです。

過去には、クラウド変換機能を持つ IME が既定設定のまま入力内容を送信していたことが問題として報道され、官公庁が組織内での利用について注意喚起を出した例もあります。また、キーボードアプリに限らず、収集されたデータの保管側の不備で情報が漏れた事例は繰り返し起きています。送信された時点で、データの運命は送信先の管理体制に委ねられる。これが「そもそも送らない」構成に価値がある理由です。

もうひとつ押さえておきたいのは、リスクの大きさは「何を打つ端末か」で変わるということです。ゲームの攻略を検索するだけの端末と、仕事のメールとネットバンキングに使う端末では、同じキーボードでも預けているものの重さが違います。以降の見分け方を読むときは、「自分はこの端末で何を打っているか」を横に置いて読んでください。判断の基準は、アプリ側ではなくあなたの使い方の側にあります。

見分け方1: Android は INTERNET 権限を見る

Android では、ネットワーク通信をするアプリは INTERNET 権限を宣言する必要があります。公式ドキュメントは、ネットワーク操作を行うアプリはマニフェストに次の権限を含める必要があると書いています(ネットワークに接続する)。

<uses-permission android:name="android.permission.INTERNET" />

API リファレンスでは、この権限は「アプリケーションがネットワークソケットを開くことを許可する」もので、保護レベルは normal と定義されています(Manifest.permission)。逆に言えば、この権限を持たないキーボードは、通常のネットワークソケットを直接開くことが制限されます。ただし、他のアプリとの連携や OS のバックアップなど、別の経路まで否定する証明ではありません。アプリ全体と保存先も確認します。

確認の方法はいくつかあります。設定アプリからアプリ情報を開き、権限の詳細表示(「すべての権限」など、機種により表記が異なります)でインターネットアクセスの有無を見る方法。Play ストアのアプリページにある「データセーフティ」欄で、開発者が申告するデータの収集・共有の内容を見る方法。開発者が自分のサイトで権限構成を説明していれば、それも判断材料になります。ひとつ注意として、INTERNET 権限はマイクや位置情報のような実行時の許可ダイアログが出ない種類の権限です。前述のドキュメントにも、INTERNET は標準の権限であり、インストール時に付与され、実行時にリクエストする必要はないと書かれています。「許可した覚えがない」ことは「持っていない」ことを意味しません。だからこそ、一度は自分で確認する意味があります。

データセーフティ欄を読むときのコツも書いておきます。あの欄は開発者の自己申告に基づく表示なので、「収集なし」という表示は約束ではあっても技術的な証明ではありません。Google Play のヘルプ自身が、データセーフティはアプリデベロッパーが宣言する情報に基づくもので、アプリの権限リストに記載されている情報とは異なる場合があると説明しています(Google Play のデータ セーフティ セクション)。申告の誠実さを裏づけるのは、権限という動かぬ構造のほうです。「データセーフティで方針を読み、権限で裏を取る」という順番で見ると、この2つの情報源はうまく補完し合います。両者が食い違っている(収集なしと書いてあるのに通信系の権限と広告 SDK の気配がある、など)場合は、その食い違い自体が判断材料です。

コマンドで権限を確かめる(adb と aapt2)

設定画面の表記は機種ごとに違いますが、コマンドで見れば表記ゆれはありません。Android SDK の adb と aapt2 があれば、端末にインストール済みのキーボードの APK を取り出し、マニフェストが宣言する権限を一覧できます。adb のドキュメントによると、pm list packages -3 はサードパーティ製パッケージだけを表示し、pm path は指定したパッケージの APK へのパスを出力します(adb)。aapt2 dump permissions は APK のマニフェストから抽出された権限を出力するサブコマンドで、aapt2 は Android SDK Build Tools 26.0.2 以上にスタンドアロンツールとして含まれています(AAPT2)。

# 端末内のサードパーティ製パッケージを一覧し、キーボードのパッケージ名を探す
adb shell pm list packages -3

# そのパッケージの APK の場所を調べ、手元に取り出す
adb shell pm path <パッケージ名>
adb pull <pm path が出力した APK のパス> keyboard.apk

# APK のマニフェストが宣言している権限を一覧する
aapt2 dump permissions keyboard.apk

最後の出力に android.permission.INTERNET が含まれていればネットワークソケットを開く権限を宣言しています。含まれない場合も、これだけで全データの移動経路を判断しないでください。開発者の説明やストアの表示がどうであれ、ここに出るのはパッケージに実際に焼き込まれた宣言です。開発者向けのツールではありますが、キーボードのように信頼の要求水準が高いアプリについては、この確認は手間に見合います。

また、権限は固定ではありません。アプリの大型更新で機能が増え、それに伴って権限構成が変わることはありえます。一度確認して終わりではなく、キーボードのような重要アプリについては、大きなアップデートの後に権限を見直す習慣があると堅牢です。頻繁である必要はありません。回数を固定するより、通信や同期の機能、アカウント、扱う情報が変わったときに見直します。

権限を持たないことを設計の柱にしたキーボードも存在します。The KeyBoard は INTERNET 権限なしを明示し、日本語変換も端末内の Mozc で完結させる構成です。「送らない」ではなく「送れない」——この差は、規約と合わせて確認する技術的な材料になります。開発者を信頼するかどうかという問いを、構造を確認できるかどうかという問いに置き換えられるからです。

見分け方2: iOS は「フルアクセス」を見る

iOS のサードパーティ製キーボードには、Android と別の仕組みがあります。他社製キーボードは標準では隔離された環境で動き、ネットワーク通信などが制限されています。Apple の開発者向けガイドには、キーボードは既定ではネットワークにアクセスできず、本体アプリ(containing app)とコンテナを共有することもできない、これを有効にするには Info.plist の RequestsOpenAccess キーを YES にする、と書かれています(App Extension Programming Guide)。現行のドキュメントでも、このキーは「キーボードがネットワークリソースへのアクセスや共有グループコンテナへの書き込みなどを必要とする場合に true にする」ものと説明されています(Creating a custom keyboard)。

<!-- キーボード拡張の Info.plist(NSExtension > NSExtensionAttributes 内) -->
<key>RequestsOpenAccess</key>
<true/>

開発者側がこのキーを立てたうえで、ユーザー側が「フルアクセスを許可」をオンにして初めて、キーボードは外部と通信できます。同じガイドは2つの状態の違いを、オープンアクセスなしなら「キーストロークはキーボードを使っているアプリにしか届かないとユーザーが分かる」、ありなら「キーストロークや入力イベントをサーバー側処理のために送信できる」と整理しています。オンにしようとすると OS が警告を表示するのは、それが入力内容の送信を可能にする操作だからです。

つまり iOS での確認ポイントは、そのキーボードがフルアクセスを要求するか、要求するなら何のためかです。クラウド変換や同期を売りにするキーボードは、機能の性質上フルアクセスを必要とします。それは取引として成立しうるものですが、何と引き換えなのかは知っておくべきです。逆に、フルアクセスをオフのまま使えるキーボードなら、通信の経路は OS が塞いでいます。設定アプリの「一般」>「キーボード」>「キーボード」(英語 UI では General > Keyboard > Keyboards)から、いまの許可状態をいつでも確認できます。

なお iOS では、パスワード欄などの機微な入力欄で他社製キーボードの代わりに標準キーボードが出てくる場面があります。前述のガイドによれば、他社製キーボードは secureTextEntry が有効な入力欄には入力できず、ユーザーがそこをタップすると一時的にシステムキーボードに置き換わります。さらに、銀行アプリのようにアプリ側が application:shouldAllowExtensionPointIdentifier: で他社製キーボードを一切拒否し、常にシステムキーボードを使うこともできます。OS 側にも、キーボードという場所の重さに応じた防御が組み込まれているわけです。プラットフォームの防御とアプリの設計とユーザーの確認、三層が重なって初めて全体の安心になります。どれか一層に丸投げしないことが、この分野の基本姿勢です。

見分け方3: 変換がオフラインで動くか

機内モードにして日本語変換が動くか試すのは、素朴ですが有効な確認です。動かない場合は、変換や予測の通信依存を調べる手掛かりになります。初回辞書取得や認証など、変換以外の原因も考えられます。1分で終わり、専門知識も要りません。

ただし、このテストで確認できるのは、その条件でその変換が通信なしで動いたかどうかです。オフラインで変換が動くことは、学習データやテレメトリを後から送信しないことの証明にはなりません。通信できる状態に戻ったときにまとめて送る設計はありうるからです。機内モードテストは、権限の確認(見分け方1・2)と組み合わせてはじめて全体の絵になります。オフラインで動き、かつ通信の経路が権限レベルで存在しない。この二点に加え、入力先アプリやバックアップなどの扱いも確認します。

クラウド変換を使う判断自体は個人の自由です。新語への強さという実利はありますし、それを理解した上で選ぶなら、それは交換であって被害ではありません。意味があるのは、「何と交換しているか」を知った上で選ぶことです。

見分け方4: パスワード欄での挙動

多くのまともな IME は、パスワード入力欄では学習・予測・履歴の記録を自動停止します。OS が入力欄の種別をキーボードに通知する仕組みがあり、それに正しく対応しているかどうかは、キーボードの品質と誠実さの分かりやすい指標です。Android の IME 開発ガイドは、パスワード欄については入力ビューと候補ビューの両方でパスワードを非表示にし、パスワードをデバイスに保存しないよう開発者に注意しています(入力メソッドを作成する)。つまりこれは OS ベンダーが IME に求めている振る舞いであって、気の利いたアプリだけの独自機能ではありません。アプリの説明やプライバシーポリシーで、パスワード欄の扱いに言及があるか見てみてください。言及がないより、あるほうが設計として意識されている見込みが高い項目です。

パスワード欄以外にも、「この入力は学習してほしくない」という場面はあります。人に端末を貸して何かを打ってもらうとき、一度きりしか使わない文字列を打つとき。実装によっては学習を一時停止する機能を持つキーボードもありますし、なくても、打ってしまった語を後から学習履歴から個別に削除することはたいてい可能です。学習は便利な機能ですが、消し方を知っていて初めて安心して使える機能でもあります。

ユーザー側でできる自衛も1つ書いておきます。パスワードをユーザー辞書に登録しないことです。辞書は暗号化された金庫ではなく、読みを打てば候補欄に表示される仕組みです。パスワードの管理はパスワードマネージャーに任せ、キーボードには覚えさせない。この線引きは、どのキーボードを使うにしても有効です。

パスワードマネージャーの自動入力(オートフィル)は、この文脈で積極的に使う価値があります。OS の自動入力の仕組みで入るパスワードは、キーボードで1文字ずつ打つ経路を通りません。自動入力は手打ちする経路を減らせますが、入力欄や OS、アプリの実装まで含めた完全な秘匿を保証するものではありません。パスワードに関しては「良いキーボードを選ぶ」より「キーボードを通さない」が最上の答えです。

学習データとユーザー辞書はどこにあるか

見落とされがちなのが、送信の話とは別にある「蓄積の話」です。キーボードはあなたの入力から学習します。よく使う語、言い回し、固有名詞。この学習データとユーザー辞書は、あなたの語彙の記録であり、それ自体が保護すべき個人データです。

確認しておきたいのは3点です。学習データが端末内に保存されるのか、アカウントに同期されるのか。学習を削除・リセットする手段が用意されているか。ユーザー辞書を書き出す手段があるか(これは機種変更時の実用の話でもあります)。端末内保存なら、端末のロックと暗号化がそのまま守りになります。同期型なら、アカウントの安全性(強いパスワード、二要素認証)が学習データの安全性に直結します。端末を手放すときの初期化、共用端末で自分のアカウントを消すときなど、「端末とデータの縁を切る」場面でも、学習データの所在を知っているかどうかで動きが変わります。

なお、学習の仕組みそのものは入力を速くする味方でもあります。学習とユーザー辞書をどう育てると入力が速くなるかはフリック入力のコツの記事に書きました。守る対象であると同時に、育てる資産でもある。この両面を知っていると、むやみに学習をオフにするのではなく、置き場所を確認した上で活用する、という成熟した付き合い方ができます。

隣の論点: クリップボードとメモの中身

キーボードの話に隣接する論点を2つだけ触れておきます。1つはクリップボードです。コピーした文字列は、キーボードとは別の経路でアプリから読まれる可能性が長らく問題でしたが、OS 側の制限は年々強化されています。それでも、パスワードのような機微な文字列を長時間クリップボードに残さない習慣には意味があります。その理由は次の項で具体的に説明します。

既定のキーボードはクリップボードを読める

Android 10 の変更で、クリップボードのデータにアクセスできるのは「デフォルトの IME のアプリ」か「現在フォーカスのあるアプリ」に限られました(Android 10 のプライバシーの変更)。裏を返すと、既定に設定したキーボードだけは例外で、フォーカスを持たない状態でもクリップボードを読める立場にあります。キーボードにペースト系の機能があること自体は普通なので、この例外は不自然ではありません。ただ、キーボードを選ぶことは、クリップボードを読める数少ないアプリを選ぶことでもある、という意味になります。Android 12 以降は、アプリが別のアプリのクリップデータに初めてアクセスするとトーストで通知されるようになりました(Android 12 の動作の変更点)。iOS でも、iOS 14 以降、アプリがユーザーの意図によらずに他のアプリ由来のペーストボードの内容を取得すると、システムがユーザーに通知します(UIPasteboard)。通知は事後に気づくには役立ちますが、読まれた事実そのものは取り消せません。だから、コピーしたパスワードはすぐに貼り付けて、クリップボードに残さない。この習慣の価値は、IME の例外を知ると具体的に理解できます。

もう1つは、打った後のデータの守り方です。キーボードの経路をどれだけ固めても、書き込んだ先のメモやメッセージが平文でクラウドに置かれるなら、守りはそこで途切れます。メモの中身をサービス側からも読めなくする方式についてはE2E 暗号化の記事で書きました。入力の経路と保存の経路、両方が揃って初めて「書いたものが自分だけのもの」になります。

よくある失敗と対処

この分野で見かける、もったいない判断のパターンを挙げておきます。

  • 許可ダイアログが出なかったから安全だと思う: 通信の権限は許可を求めるダイアログが出ない種類です。「聞かれなかった」は判断材料になりません。自分から権限一覧を見に行く必要があります
  • 有名アプリだからと確認を省く: 有名であることと、クラウドへ送る設計であることは両立します。むしろ大手の多機能キーボードほどクラウド機能を持っている割合は高い。確認の手間は同じなので、知名度で省略しないでください
  • 不安になって学習ごとオフにする: 学習は端末内に置ける機能で、置き場所さえ確認すれば入力を速くしてくれる資産です。オフにして不便を我慢するより、端末内で学習する構成を選ぶほうが、安全と快適を両立できます
  • キーボードだけ固めて他の経路を放置する: パスワードを平文メモに書く、機微な文章を同期先の分からないアプリに書く、といった保存側の穴は、キーボードの対策では塞げません。入力と保存をセットで考えてください
  • アプリストア外からキーボードを入れる: キーボードは信頼の要求水準が最も高い種類のアプリです。配布元の分からないパッケージを入力経路に据えるのは、割に合いません

開発者の視点: なぜ「送れない」を選ぶのか

少しだけ、作る側の話をさせてください。The KeyBoard を INTERNET 権限なしで設計したのは、「開発者を信じてください」と言いたくなかったからです。プライバシーポリシーは開発者の意思表明にすぎず、意思は変わりえます。会社が買収されるかもしれないし、方針が変わるかもしれない。ユーザーの側からそれを監視し続けるのは現実的ではありません。

権限を持たないという選択は、この問題を消します。将来の開発者の誰かが心変わりしても、送信する機能は追加の権限宣言なしには作れず、権限の変化は先ほどの aapt2 dump permissions のようにユーザーが確認できる形で表に出ます。信頼を人格ではなく構造に置く。セキュリティの世界で昔から言われてきた原則を、キーボードという道具に適用しただけのことです。変換の賢さは端末内の Mozc が担ってくれるので、この構成は理想論ではなく実用として成立します。

この設計思想が唯一の正解だと言うつもりはありません。クラウドの計算力を使った変換には端末内では出せない体験があり、それを選ぶ理由も理解できます。ただ、選択肢として「直接のネットワーク通信を制限したキーボード」が存在すること、そしてそれが実用水準で動くことは、もっと知られてよいと思っています。選択肢を知らないままの選択は、選択とは呼べないからです。

現実的な指針

ここまでを、立場別の指針にまとめます。

  • 銀行・仕事・私的な文章を打つ自分の端末では、INTERNET 権限のない(iOS ならフルアクセス不要の)、またはオフライン動作を明示したキーボードを選ぶ
  • クラウド機能を使うと決めたなら、学習データの削除方法とアカウントの二要素認証を確認しておく
  • 会社支給端末では、会社のポリシーが指定するキーボード以外を入れない。業務情報の入力経路は個人の判断で増やさないのが原則
  • 家族に端末を貸すことがあるなら、候補欄に学習が表示されることを覚えておく。学習した語の個別削除に対応しているかを確認する
  • キーボードを乗り換えるときは、旧アプリのユーザー辞書を書き出してから、旧アプリの学習データを削除する

どれも数分で終わる確認です。キーボードは「入れたら忘れる」道具だからこそ、入れる前と、この記事を読んだ今の、2回の確認が効きます。逆に言うと、この確認を一度済ませてしまえば、日常的に何かを警戒し続ける必要はありません。プライバシー対策は不安を飼うことではなく、確認を構造に変えて忘れることです。良い構成を選んで、あとは入力そのものに集中する。それがこの記事のゴールです。

よくある質問

大手のキーボードなら安心ですか

運営の信頼性や漏洩時の対応力という点では、大手には分があります。ただし「大手だから送信していない」は成り立ちません。クラウド変換や同期を主要機能とする大手キーボードは、設計として入力に関わるデータを送ります。確認すべきは会社の規模ではなく、権限と設定と説明です。大手かどうかは、その説明を信じられるかの補助材料にすぎません。

INTERNET 権限がないと、不便ではないですか

失うのは、クラウド変換・複数端末の同期・サーバー由来の新語辞書です。変換は端末内エンジン(Mozc が代表例です)で実用水準に達しており、新語はユーザー辞書への登録で補えます。アプリ本体の更新はアプリストア経由なので、通信権限がなくても新機能や辞書の改善は届きます。日本語入力の日常使いで権限なし構成が失うものは、具体的な影響はアプリの機能と連携方式で変わります。

音声入力のプライバシーはどう考えればよいですか

音声認識は計算量が大きく、クラウドで処理される構成が今も多い領域です。端末内で認識する方式も増えていますが、どちらなのかは機能や設定によって異なります。考え方はキーボードと同じで、「処理がどこで行われるか」を確認し、機微な内容は音声で入力しない、という線引きが現実的です。声は文字と違い、内容以外の情報(誰が話しているか)も含むことは意識しておく価値があります。音声入力を多用する人は、音声認識の設定画面に端末内処理の選択肢がないか、一度探してみてください。

結局、何を基準に選べばよいですか

自分が打つ内容の重さで決めるのが一番実際的です。仕事の文書やパスワードを日常的に打つ端末なら、直接のネットワーク通信を制限したキーボードを既定にする。エンタメ中心の端末で、新語の強さを最優先したいなら、クラウド型を理解の上で選ぶ。どちらも合理的な選択です。避けたいのは、選んだ自覚がないまま使い続けることだけです。

次の一歩

今日できる確認を3つにまとめます。

  1. いま使っているキーボードアプリの権限を確認する。Android は設定のアプリ情報からインターネットアクセスの有無を見るか、adb と aapt2 が使えるなら上の手順で aapt2 dump permissions の出力に android.permission.INTERNET があるかを見る。iOS は「一般」>「キーボード」>「キーボード」でフルアクセスの状態を見る
  2. 機内モードにして日本語変換を試し、その操作が通信なしで動くかを確かめる
  3. ユーザー辞書と学習データの削除・書き出し方法を、設定画面で1分だけ探しておく

確認の結果、いまのキーボードで納得できたなら、それが答えです。納得できなかったなら、乗り換えの前にユーザー辞書の書き出しだけ忘れないでください。あなたが育てた辞書は、キーボードを替えても持っていける資産です。

この3つを終えたとき、あなたは自分の入力の行き先を「知らないまま使っている人」から「知った上で選んでいる人」になっています。変換の裏側の仕組みまで興味が湧いたら IME の解説記事へ、端末内で完結する変換エンジンの実例を知りたければ Mozc の記事へ進んでください。

確認できた事実と、まだわからないことを分ける

プライバシーの確認では、一つの観察から結論を広げすぎないことが大切です。「通信する権限がある」「公式説明に送信しないとある」「オフラインでも変換できた」は、それぞれ別の情報です。矛盾するとは限らず、証明できる範囲も違います。

たとえばネットワーク権限があっても、辞書の更新に使うだけという説明があるかもしれません。その権限だけで入力内容を送信しているとは断定できません。反対に、通信しない変換エンジンを採用していても、アプリ内の別機能が通信する可能性は残ります。確認対象を機能ごとに分けます。

確認の材料わかることそれだけではわからないこと
権限一覧宣言された能力の一部実際に送った内容
公式ポリシー提供者が説明する扱い配布物のすべての動作
オフラインでの試用その操作が通信なしで動くか復帰後の送信の有無
同期設定有効にした機能保存先での詳しい管理

確認メモには、日付、アプリ、設定、根拠のページを残します。「安全だった」という一言より、何を確かめたかがわかる記録のほうが、更新後にも比較できます。

キーボードを替える前後のデータを確認する

乗り換え時には、入力を新しいアプリへ切り替えることと、旧アプリの保存データを扱うことを分けます。既定のキーボードを変更しても、旧アプリの辞書やクラウド側の記録まで自動で消えるとは限りません。

最初に、持ち出したいユーザー辞書があるかを確認します。書き出しに対応している場合は、保存場所と内容を確かめ、新しい環境で必要な語が使えるかを試します。移行が終わってから、旧アプリの同期、学習履歴、アカウント側のデータについて、それぞれの削除手順を確認します。

一方、試用だけなら旧環境をすぐ消す必要はありません。元の入力へ戻せる状態を残し、架空の短文で使い勝手を比較できます。便利さとデータの扱いを同時に確認し、自分の用途に合うと判断できた段階で移行を完了させます。

参考リンク