ニンジャマイルズは「キーロガー」ではない━━一次情報に基づく情報整理
はじめに ── 本稿の目的と立場
2026年2月26日、Webフロントエンドエンジニアのmizchi（竹馬光太郎）氏がX（旧Twitter）において、キーボード型ポイ活アプリ「ニンジャマイルズ（Ninja Miles）」を「キーロガー」であると断定的に批判する投稿を行った。
本稿は、この騒動に関して「ニンジャマイルズ側にもmizchi氏側にも与しない」中立的な立場から、公開されている一次情報 ── 利用規約、プライバシーポリシー、Apple/Googleの公式開発者ドキュメント、App Store審査ガイドライン ── に基づいて事実を整理し、技術的に何が正しく何が不正確であるかを切り分けることを目的とします。
私自身は訪問看護師として医療現場における個人情報保護の実務に携わりながら、大学院で経営学を学び、TRPGのゲームクリエイター兼シナリオライターとしても活動しています。
登場人物たちのようなIT専門家ではありません。ただ、プライバシーとセキュリティへの関心から本件を調査しました。技術的な検証にあたっては、Apple Developer Documentation、Android Developers公式ドキュメント、Citizen Labの学術調査報告、およびScribd上で公開されているiOS Custom Keyboard Extension APIの技術概要文書を参照しています。
また、本稿は2026年2月26日時点の公開情報に基づいています。新たな技術的証拠が提示された場合は追記します。
第1章 事実の整理 ── 登場人物とアプリの概要
1-1. mizchi（竹馬光太郎）氏について
mizchi氏は、日本のWebフロントエンド技術コミュニティにおいて最も影響力のあるエンジニアの一人です。本人の公開する経歴情報（GitHub Gist「about_mizchi_job.md」2019年版、およびGitHub Pages上の経歴スライド）を総合すると、キャリアは以下の通りです。
2012年にAimingにゲームエンジニアとして入社し、2013年にQuipperへソフトウェアエンジニアとして転職。その後Increments（Qiita運営元）にてQiita本体およびKobito for Windows（Electronベースのデスクトップアプリ）の開発に従事し、2017年3月に退職。同年よりプレイドにてReact / Next.js / Node.jsを中心としたフロントエンド開発を担当した後、フリーランスに転身。現在はFrontend Opsコンサルタントとして、主にCI/CDパイプラインの最適化、Core Web Vitalsの改善、Webpack/Vite関連のパフォーマンスチューニングを専門としています。
自己紹介では「Node.jsとフロントエンドのエキスパート」と明言している。
主要技術スタックとしてNode.js、TypeScript、React、Next.js、Deno、Cloudflare Platform、WebAssemblyを、副次的言語としてPython、Ruby、Scala、Java。関心領域としてRust、WebAssembly、TensorFlow.jsが挙げられている。
ただ、今回の焦点であるニンジャマイルズはiOS/Andoridで配信されているアプリだ。mizchu氏の経歴等からはSwift、Kotlin、Objective-Cといったモバイルネイティブ開発言語は確認できませんでした。
React Nativeについて論じた2018年6月のブログ記事「いつReactNativeを使っても大丈夫か」では、「一応AndroidとFlashとUnityの経験した上で」（Aiming時代のゲーム開発文脈）と述べつつも、「Webの人間はモバイル基準だとインタラクションに激弱」「RNは貧者の開発ツール」と記しています。
特筆すべき点として、公開情報を精査する限り、iOSのCustom Keyboard Extension（カスタムキーボード拡張）またはAndroidのInputMethodService（IMEサービス）の開発経験は確認できません。
IMEに関する言及は、Qiita/Kobito開発時のCodeMirror上でのIME入力挙動の対応（Web上のテキストエディタにおけるcompositioneventの処理であり、ネイティブIME開発とは根本的に異なる）と、今回のニンジャマイルズに関する投稿のみです。
出典:
https://gist.github.com/mizchi/4e097923bb92399d03ced9da44f15cfa
https://gist.github.com/mizchi/b803f6872035248f86309057d6c97ee9
1-2. サンゴテクノロジーズ株式会社について
今回mizchi氏に指摘されたアプリである、ニンジャマイルズの開発・運営元です。
2020年8月7日設立、本社は東京都世田谷区玉川3丁目20番2号マノア玉川第3ビル501号室。代表取締役CEOは野間悠磨氏。資本金は5,119万9,500円（2023年10月時点）。従業員数は11〜50名。2023年10月にシリーズAファーストクローズとして1.9億円の資金調達を実施しており、SBIインベストメント、イーストベンチャーズ、DIWEMENSIONなどが株主に名を連ねています。
同社が運営するもう一つのプロダクト「TapNow」（Z世代向けSNSアプリ）は、Google Play Best of 2024「隠れた名作」部門大賞を受賞しています。Google Playの審査を通過し、Bestアプリに選出されている事実は、同社がプラットフォームの品質基準を一定水準で満たしていることは予想されます。
出典:
1-3. ニンジャマイルズの仕組み
争点の中心にあるニンジャマイルズについて、簡単に説明する。
これはiOS / Android両対応のキーボードアプリで、スマートフォンの標準キーボードをニンジャマイルズのキーボードに置き換え、日常的な文字入力（LINE、メール、Web検索など）の打鍵回数をカウントします。
カウントされた回数に応じてポイント（マイル）が貯まり、PayPay、Amazonギフト券、dポイント等に交換できます。収益モデルは動画広告であり、ユーザーはマイル獲得速度を上げるために広告動画を視聴します。
今回の争点はこのキーボードの打鍵回数のカウントがキーロガーに当たる、というものです。
第2章 「キーロガー」の定義と技術的要件
議論の前提として、「キーロガー」の厳密な定義を確認します。
キーロガー（Keystroke Logger）とは、ユーザーがキーボードから入力した文字列の内容 ── パスワード、クレジットカード番号、メッセージ本文、検索クエリなど ── を記録し、外部に送信するソフトウェア（またはハードウェア）です。元来はソフトウェアデバッグや法執行機関の監視ツールとして開発されましたが、現在ではスパイウェア・マルウェアの代表的手法として知られています。
キーロガーの成立要件は以下の2つです。第一に、入力された文字列の内容を取得すること。第二に、取得した内容をユーザーの意図に反して外部に送信することです。
そのため、「何回キーを押したか」という回数のみを記録する行為は、入力内容を取得していないため、キーロガーの定義には該当しません。
この区別は、例えるならば「郵便配達員が手紙を何通配達したかを数えること」と「手紙の中身を開封して読むこと」の違いに相当します。前者はプライバシーを侵害しませんが、後者は重大な侵害です。
第3章 公式ドキュメントの精査 ─利用規約とプライバシーポリシー
3-1. 利用規約 第8条「キーボード入力数の測定」
ニンジャマイルズの利用規約の第8条には、ニンジャマイルズのコア機能に関する記載があります。以下に第8条の全文を引用します。
本アプリにより計測される利用者のキーボード入力数実績データ（以下、「入力数データ」といいます。）は、次の各号のとおり取り扱われるものとします。
入力数データは、所定の条件の下で本アプリを起動させた利用端末により測定され、本アプリを配信する弊社の管理するサーバに送信されます。
前号に定めるサーバに送信された入力数データは、本アプリ上に表示されます。
利用端末の電源が入っていない場合、または本アプリの起動時に利用端末が圏外である等通信環境が整っていない場合、入力数データが測定されないことがあります。
利用者の入力数データより算定される獲得マイルは、利用者個人を特定できない形式により本アプリ内で公開され、利用者以外の本アプリの利用者と共有されることがあります。
上記の条文が定義する取得対象は「キーボード入力数実績データ」、すなわち打鍵回数のみです。入力された文字列の内容への言及はありません。サーバーへの送信対象も「入力数データ」に限定されています。
3-2. プライバシーポリシー 第2条3項4号
プライバシーポリシーでは、取得する個人データとして以下が列挙されています。
キーボード入力情報（入力文字数、その他の入力情報を含み、以下同じ）
「入力文字数」が主たる取得対象であることは明確です。しかし、「その他の入力情報」という文言が併記されています。この「その他」が具体的に何を指すのかは定義されていません。
技術的には、入力速度（タイピングリズム）、使用中のアプリケーション名、キーボードのレイアウト情報（言語設定等）などが考えられます。
明示がない以上、この曖昧さは批判の対象として正当です。
3-3. 第三者提供に関する規定
プライバシーポリシー第2条5項2号では、第三者への提供について以下のように規定しています。
本サービスの利用開始時以降に当社が取得し、当社所定の加工工程を経ることにより特定の個人が識別されないよう加工したキーボード入力情報
第三者への提供は匿名化処理を経た上で行われると明記されています。ただし、「当社所定の加工工程」の具体的な手法（k-匿名性、差分プライバシー等）は開示されていません。
3-4. オプトアウト機構
第2条12項2号により、ユーザーはキーボード入力情報の取得を拒否できます。ただし、この場合マイルの加算はできなくなります。これはアプリの根幹機能と直結するため、実質的にはオプトアウト＝アプリの利用放棄を意味します。
3-5. 情報収集モジュール（広告SDK）の開示
プライバシーポリシー第2条8項では、閲覧履歴情報の取得に使用される情報収集モジュールとして、AppsFlyer、AppLovin、Unity Ads、Pangle（ByteDance）、Liftoff、Mintegral、LINE、InMobi、DT Exchange、AdMob（Google）、Tapjoy、Meta、Moloco、Mixpanel、Adjust、OneSignalの計16社が列挙されています。これは広告収益モデルのアプリとしては標準的な構成であり、むしろ開示されていること自体が透明性の証左です。
出典:
第4章 プラットフォームのセキュリティモデル ── PC、iOS、Androidの根本的な違い
4-1. なぜPCのキーロガーの歴史をそのまま適用できないのか
mizchi氏は「キーロガーとセキュリティの歴史」を論拠として挙げていました。
しかし、PC環境とモバイルプラットフォーム（iOS/Android）では、セキュリティモデルが根本的に異なります。
PC環境（Windows、macOS、Linux）では、伝統的にアプリケーションはOSの広範なAPIにアクセスでき、キーボード入力のグローバルフック（OS全体のキー入力を傍受する仕組み）が技術的に可能です。初期のキーロガーはこの仕組みを利用して、ユーザーの全入力を密かに記録・送信していました。
これに対し、iOS/Androidのモバイルプラットフォームはサンドボックスアーキテクチャを採用しています。各アプリは隔離された実行環境で動作し、他アプリのデータや入力を原則として傍受できません。カスタムキーボード（iOS: Keyboard Extension、Android: InputMethodService）には、さらに特有の制限が課されます。
詳細は以下に記載しますが、結論としてはAndroidはパスワード保護に関してiOSより構造的に弱いという指摘は正当です。
ただし、これはニンジャマイルズ固有の問題ではなく、Gboard以外のすべてのサードパーティAndroid IMEに共通する構造的課題です。
4-2. iOSのCustom Keyboard Extensionのセキュリティモデル
Apple Developer公式ドキュメント「App Extension Programming Guide – Custom Keyboard」および「Configuring a custom keyboard interface」に基づき、iOSにおけるカスタムキーボードの権限モデルを整理します。
4-2-1. 二段階のサンドボックス設計
iOSのカスタムキーボードには、RequestsOpenAccess（フルアクセス要求）というInfo.plistキーに基づく二段階の権限モデルがあります。
RequestsOpenAccess = false（デフォルト）の場合、キーボード拡張は完全に隔離されたサンドボックス内で動作します。使用できる機能は、UITextDocumentProxyを介した文字の挿入・削除、システム共通語彙辞書（Common Words Lexicon）へのアクセス、ユーザーが設定したテキスト置換ショートカットの参照のみです。ネットワーク通信、App Groupsを介した共有コンテナへのアクセス、UIPasteboard（クリップボード）へのアクセス、位置情報・連絡先へのアクセスは、すべてシステムレベルでブロックされます。
RequestsOpenAccess = trueの場合、ユーザーが「設定 → キーボード → [キーボード名] → フルアクセスを許可」を明示的にONにすると、ネットワーク通信、App Groups共有コンテナ、UIPasteboard、位置情報（別途許可必要）、連絡先（別途許可必要）へのアクセスが可能になります。
つまるところ、ニンジャマイルズが打鍵回数をサーバーに送信してマイルに変換するためには、ネットワーク通信が必要です。フルアクセスがOFFの状態ではネットワーク通信が物理的に不可能であるため、フルアクセスの要求は技術的に不可避です。この点は、Gboard、SwiftKey、Simejiなど、すべてのサードパーティキーボードに共通する設計上の制約です。
4-2-2. セキュアフィールドの強制保護
iOSにおいて最も重要なセキュリティ機構の一つが、セキュアテキストフィールドの強制保護です。Apple Developer Documentation「Configuring a custom keyboard interface」には以下の記述があります。
"Secure text field entries always show the system keyboard when the user begins entering text in a secure text field, temporarily removing your custom keyboard."
UITextFieldのsecureTextEntryプロパティがYESに設定されたフィールド（パスワード入力欄、クレジットカード番号入力欄など）では、フルアクセスの有無にかかわらず、iOSが自動的にApple標準キーボードに切り替えます。サードパーティキーボードはこのフィールドに一切関与できません。これはアプリ開発者の実装に依存せず、OSレベルで強制される保護機構です。
同様に、電話番号パッド（UIKeyboardTypePhonePad、UIKeyboardTypeNamePhonePad）でもサードパーティキーボードは使用されず、システム標準のテンキーが表示されます。
さらに、アプリ開発者はapplication:shouldAllowExtensionPointIdentifier:メソッドを使用して、自アプリ内でサードパーティキーボードを完全にブロックすることができます。銀行アプリや企業向けセキュリティアプリではこの手法が広く採用されています。
4-2-3. App Store審査ガイドライン §4.4.1
Appleの App Store審査ガイドラインのセクション4.4「Extensions」内の4.4.1条は、キーボード拡張に対する追加規則を定めています。
"Keyboard extensions have some additional rules."
"They must: Provide keyboard input functionality (e.g. typed characters)"
"They must not: Include marketing, advertising, or in-app purchase content in the keyboard"
また、同セクションおよびApple Developer Enterprise Program License Agreementでは、キーボード拡張によるキーストロークのログ記録について、事前に明確なユーザーへの開示を要求しています。
App Store審査ガイドラインのセクション2.5.14は、より一般的に以下を規定しています。
"Apps must request explicit user consent and provide a clear visual and/or audible indication when recording, logging, or otherwise making a record of user activity."
Apple Developer Documentationの「Configuring open access for a custom keyboard」では、フルアクセスを有効にした場合の開発者の責任として、「キーストロークデータをキーボード機能の向上目的以外に使用しないこと」「パスワードや個人情報を収集・送信しないこと」が明示されています。
出典:
https://developer.apple.com/documentation/uikit/configuring-a-custom-keyboard-interface
https://developer.apple.com/documentation/uikit/configuring-open-access-for-a-custom-keyboard
4-3. AndroidのInputMethodServiceのセキュリティモデル
Android公式開発者ドキュメント「Create an input method」に基づき、AndroidにおけるIMEの権限モデルを整理します。
4-3-1. IMEの権限構造
AndroidのカスタムIMEはInputMethodServiceクラスを継承して実装され、マニフェストにandroid.permission.BIND_INPUT_METHODパーミッションの宣言が必要です。このパーミッションはシステムのみがバインドできる特別な権限であり、不正なアプリがIMEに成りすますことを防止します。
ユーザーがサードパーティIMEを初めて有効にする際、Androidは以下の警告を表示します。
「この入力方法を使用すると、パスワードやクレジットカード番号を含むすべての入力テキストを収集できる可能性があります。」
この警告はiOSの「フルアクセスを許可」に相当するものですが、重要な違いがあります。
4-3-2. iOSとの差異 ── パスワードフィールドの保護
iOSではセキュアフィールドにおいてシステムが強制的に標準キーボードに切り替えますが、Androidにはこの強制切り替え機構がありません。
AndroidではEditorInfo.inputTypeにTYPE_TEXT_VARIATION_PASSWORDが設定されたフィールドにおいて、IMEに対して「これはパスワードフィールドである」という情報が通知されます。
良心的なIMEはこの情報をもとに学習機能や予測変換を無効化しますが、これはアプリ開発者の自主的な実装に依存するものであり、OSレベルの強制ではありません。
4-3-3. ネットワーク通信の権限
AndroidのIMEがインターネット通信を行うには、マニフェストにandroid.permission.INTERNETを別途宣言する必要があります。iOSのフルアクセスがネットワーク通信を包括的に制御するのとは異なり、Androidではネットワーク権限とIME権限は独立して管理されます。
INTERNETパーミッションは「Normal」権限に分類されており、インストール時に自動的に付与され、ユーザーの明示的な許可ダイアログは表示されません。
出典:
第5章 mizchi氏の主張の時系列分析と技術的検証
5-1. 時系列の整理
mizchi氏の投稿は、時間とともに主張の性質が変化しています。公開されたX投稿のURLから確認できる範囲で整理します。
第1段階（2026/02/26 約18時間前の投稿）
「あまりにも直球で危険なアプリ見つけて戦慄してる。ユーザーにキーロガーをインストールさせてポイ活と称して入力を促す」
「こういうの誰に言えばいいんだろ」
技術的な確定事実であるかのような断定的表現です。「キーロガー」という用語は、前章で定義した通り「入力内容を記録・送信するソフトウェア」を意味し、これは重大な指摘です。
第2段階（2026/02/26 約4時間前の投稿群）
「ポイ活を謳って広告もなくタップ数で収益が発生するとしたら、法人としてユーザーの個人情報を販売していると自分は推測します。」
「本当にタップ数のみで、御社に悪意がないと仮定しても、キーロガーとセキュリティの歴史を知らずにやってたとしたらそれはそれで問題です。技術者倫理として、注意喚起をせざるを得ません。」
「内情は無関係で、セキュリティは無知や稚拙が許される範囲ではなく、社会全体の問題だからです。」
第3段階（2026/02/26 約3-4時間前の投稿群）
上記の投稿の約4時間後の投稿。
「これ『広告もなしに』の部分はこちらの事実誤認なんだけど、その場合でも最悪 Ad Network にユーザーのキー入力が流れてることが想定されるので、相当危ないです」
「ただ、権限の組み合わせとして重大な問題が発生しうるならそれを想定すべきで、悪意ある人間の攻撃可能な状況が成立するなら、常に最悪を想定すべきです。」
「他は状況証拠しかありませんが、IMEを置き換えるのにポイ活アプリを名乗っていること、tiktok の(ユーザーには申し訳ない言い方だけど)あまりリテラシーが高くない層に広告を打っていること、IMEや通信・広告だけでなく各種SNSの非常に強い権限を持っていこと、そして利用規約によってニンジャマイルズの行動はほとんど縛られていないことに問題としています：
「広告がない」という前提が事実誤認であったことを認めつつも、主張の方向性を修正せずに仮説を追加しています。「Ad Networkにキー入力が流れている」という推測には、具体的な証拠（パケットキャプチャ、APK/IPAの逆コンパイル結果、通信ログ等）は示されていません。
具体的な脆弱性の指摘から、歴史的教訓、技術者倫理、最悪想定論という抽象的・原則論的な議論へと移行しています。
5-2. 各主張の技術的検証
主張①:「ニンジャマイルズはキーロガーである」
検証結果: 事実に基づかない。
利用規約第8条が定義する取得対象は「キーボード入力数実績データ」であり、入力内容ではありません。プライバシーポリシー第2条3項4号も「入力文字数」を主たる取得対象としています。キーロガーの定義（入力内容を記録・送信するソフトウェア）に照らして、回数カウントはキーロガーに該当しません。
さらに、iOSのApp Store審査ガイドライン§4.4.1はキーボード拡張によるキーストロークデータの不正収集を禁止しており、Appleの審査を通過してApp Storeで公開されている事実は、少なくともAppleの審査時点でキーロガー的挙動が検出されなかったことを意味します。
ただし、「その他の入力情報」の範囲が未定義であるという曖昧さは残ります。この点への批判は正当ですが、「曖昧さがある＝キーロガーである」とは論理的に導けません。
主張②:「Ad Networkにキー入力が流れている可能性がある」
検証結果: 技術的可能性は否定できないが、証拠が提示されていない推測。
フルアクセスを許可した状態のiOSカスタムキーボードはネットワーク通信が可能であるため、理論上はキー入力データをAd Networkに送信する技術的可能性は存在します。しかし、以下の事実を考慮する必要があります。
第一に、iOSのセキュアフィールド保護により、パスワードやクレジットカード番号はサードパーティキーボードに到達しません。
第二に、App Store審査ガイドライン§2.5.18は、キーボード拡張内での広告表示を禁止しています。
第三に、プライバシーポリシーに記載された16の広告SDKは閲覧履歴情報の取得に使用されるものであり、キーボード入力情報との関連は記載されていません。
第四に、この推測を裏付けるパケットキャプチャ、通信ログ、逆コンパイル結果等の技術的証拠はmizchi氏から提示されていません。
「最悪を想定すべき」というセキュリティの原則は正しいですが、最悪の想定を事実であるかのように公に断定することとは区別されるべきです。
主張③:「キーロガーとセキュリティの歴史を知らずにやってたなら問題」
検証結果: 原則として正当だが、プラットフォームの理解不足が見られる。
サードパーティキーボードアプリの開発において、キーロガーの歴史を認識し、プライバシーに配慮した設計を行うべきだという主張自体は正当です。2013年のSimeji事件（Baidu製IMEが実装バグにより入力データをサーバーに送信していた問題）は、IME開発者が肝に銘じるべき教訓でしょう。
ただし、mizchi氏の主張はPC環境のセキュリティ史をそのままモバイルプラットフォームに適用しており、iOSのセキュアフィールド強制保護機構、App Store審査ガイドライン§4.4.1、AndroidのTYPE_TEXT_VARIATION_PASSWORDフラグ通知といった、モバイルプラットフォーム固有のセキュリティ機構への言及が完全に欠落しています。
第1章で整理した通り、mizchi氏の専門領域はWebフロントエンド（Node.js / TypeScript / React）であり、iOSのKeyboard ExtensionやAndroidのInputMethodServiceの開発経験は確認できません。
これは人格や技術力の問題ではなく、専門領域の境界です。Webフロントエンドのエキスパートであることと、モバイルプラットフォームのネイティブセキュリティモデルに精通していることは、異なる技能です。
主張④:「同様のアプリが氾濫することが真に危険」
検証結果: 正当な懸念。
将来、悪意ある開発者がニンジャマイルズと同様のビジネスモデル（キーボード×ポイ活）で参入し、規約上はカウントのみと謳いながら実際にはキー入力内容を窃取するアプリが登場する可能性は否定できません。
特にAndroidは、iOSのようなセキュアフィールド強制保護がなく、INTERNETパーミッションも自動付与されるため、悪意あるIMEが構造的に成立しやすい環境にあります。このリスクへの啓発は社会的に意義があります。
第6章 Simeji事件との比較 ── 何が同じで何が違うのか
mizchi氏が暗に参照していると思われる歴史的事例として、2013年12月のSimeji（Baidu IME）事件があります。比較を通じて、ニンジャマイルズの状況を客観的に位置づけます。
Simeji事件では、Baidu製のPC用IME「Baidu IME」およびAndroid用IME「Simeji」が、ユーザーが入力した文字列の内容を、クラウド変換機能の一環としてBaiduのサーバーに送信していたことが、セキュリティ企業ネットエージェントの調査により判明しました。
特にSimejiでは、クラウド入力機能を「無効」に設定してもデータが送信され続けるという実装バグが存在していました。Baiduは「実装バグ」と説明し修正版をリリースしましたが、ユーザーへの説明が不十分であったことが強く批判されました。
ただし、この事件とニンジャマイルズの間には、以下の明確な差異があります。
第一に、Simejiは入力内容を送信していましたが、ニンジャマイルズの規約上の取得対象は入力回数です。
第二に、Simejiは「送信していない」と誤認させる設計（無効設定時も送信継続）が問題でしたが、ニンジャマイルズはフルアクセスが必要であることを設定画面で明示しています。
第三に、Simeji事件は第三者のセキュリティ調査により発覚しましたが、ニンジャマイルズについてはそのような技術的調査結果は現時点で公開されていません。
一方で、共通する構造的リスクも存在します。いずれもサードパーティIMEであり、フルアクセスを許可した場合に技術的にはキー入力内容を外部送信できる環境にある点は同一です。この「技術的可能性」と「実際の挙動」の区別が、本件の議論の核心です。
出典:
第7章 残る正当な懸念 ── ニンジャマイルズに対して指摘すべき点
本稿はニンジャマイルズが完全に問題がないと主張するものでもありません。以下の点は、技術的にも法的にも正当な懸念です。
7-1. プライバシーポリシーにおける「その他の入力情報」の曖昧さ
第2条3項4号の「その他の入力情報」が具体的に何を指すのかが定義されていません。GDPR第13条やCCPA/CPRA §1798.100(b)が求める「収集するデータの具体的な種類の開示」の観点から、この曖昧さは改善されるべきです。
7-2. Androidにおけるパスワード保護の構造的脆弱性
iOSとは異なり、Androidではサードパーティ IMEがパスワードフィールドでも動作し続けます。ニンジャマイルズがAndroid版においてTYPE_TEXT_VARIATION_PASSWORDフィールドで学習・送信を無効化しているかどうかは、外部からは確認できません。
7-3. フルアクセス許可の意味のユーザーへの説明不足
アプリの初期設定フローにおいて、「フルアクセスを許可する」ことの技術的意味（ネットワーク通信が可能になること、理論上はキー入力データの外部送信が技術的に可能になること）を、一般ユーザーにわかりやすく説明するUIが不足している可能性があります。
OS標準の警告文だけでは、ITリテラシーの低いユーザーには十分に伝わらない懸念があります。
7-4. 匿名化手法の非開示
第三者提供時の「当社所定の加工工程」が具体的にどのような匿名化手法を用いているかが開示されていません。
タイピングリズム（キーストロークダイナミクス）は生体認証に利用可能な情報であり、打鍵タイミングが取得されている場合、回数データのみの匿名化では再識別リスクが残る可能性があります。
第8章 結論
ニンジャマイルズは「キーロガー」か、という点については否である。
公開されている利用規約、プライバシーポリシー、AppleおよびGoogleのプラットフォーム仕様、App Store審査ガイドラインに基づく限り、ニンジャマイルズは入力「内容」を記録・送信するキーロガーには該当しません。取得対象は「入力回数」であり、iOSではセキュアフィールドの強制保護によりパスワードやクレジットカード番号がサードパーティキーボードに到達すること自体が不可能です。
mizchi氏の注意喚起に意義はある。ただし、内容の妥当性については指摘内容の一部に限られる。
サードパーティキーボードにフルアクセスを安易に許可するリスクについて一般ユーザーの認知を高めるという目的自体は正当であり、社会的に意義があります。特に、「キーボード×ポイ活」というビジネスモデルが模倣された場合に悪意あるアプリが登場するリスクへの指摘は重要です。
問題点は、第一に確たる技術的証拠がない段階で特定のアプリを「キーロガー」と断定したことです。「キーロガー」は刑法上の不正指令電磁的記録に関連しうる極めて重い表現であり、安易に使用すべきではありません。
第二に、事実誤認（「広告もなしに」）の訂正後も主張の方向性を修正せず、論点を技術的事実から倫理・歴史論へシフトさせたことで、事実と推測の境界が曖昧になりました。
第三に、モバイルプラットフォーム固有のセキュリティ機構（iOSのセキュアフィールド強制保護、App Store審査ガイドライン§4.4.1、AndroidのTYPE_TEXT_VARIATION_PASSWORDフラグ）への理解が議論から欠落していたことです。
これはmizchi氏の専門領域（Webフロントエンド）とモバイルネイティブ開発の専門領域の境界に起因すると考えられ、人格攻撃として述べるものではありません。
終わりに
SNSで流れてくる「危険だ」「安全だ」という主張のいずれかを鵜呑みにするのではなく、一次情報 ── 公式ドキュメント、利用規約、プライバシーポリシー、プラットフォーム仕様書 ── を自分の目で確認する習慣を持つことが、情報リテラシーの第一歩だと思われます。
出典一覧
Ninja Miles 利用規約: https://get-miles.ninja/ja/term-of-service/
Ninja Miles プライバシーポリシー: https://get-miles.ninja/ja/privacy-policy/
Apple Developer – App Extension Programming Guide – Custom Keyboard: https://developer.apple.com/library/archive/documentation/General/Conceptual/ExtensibilityPG/CustomKeyboard.html
Apple Developer – Configuring a custom keyboard interface: https://developer.apple.com/documentation/uikit/configuring-a-custom-keyboard-interface
Apple Developer – Configuring open access for a custom keyboard: https://developer.apple.com/documentation/uikit/configuring-open-access-for-a-custom-keyboard
App Store Review Guidelines: https://developer.apple.com/app-store/review/guidelines/
Android Developers – Create an input method: https://developer.android.com/develop/ui/views/touch-and-input/creating-input-method
Citizen Lab – Vulnerabilities Across Keyboard Apps Reveal Keystrokes to Network Eavesdroppers (2024): https://citizenlab.ca/2024/04/vulnerabilities-across-keyboard-apps-reveal-keystrokes-to-network-eavesdroppers/
Technical Overview of the iOS Custom Keyboard Extension API (Scribd): https://www.scribd.com/document/975290894/Technical-Overview-of-the-IOS-Custom-Keyboard-Extension-API
mizchi – X投稿群 (2026/02/26): https://x.com/mizchi/status/2026738205551366372 , https://x.com/mizchi/status/2026949162953261067 , https://x.com/mizchi/status/2026956415634710786 , https://x.com/mizchi/status/2026963120154153004
mizchi – about_mizchi_job.md (GitHub Gist): https://gist.github.com/mizchi/4e097923bb92399d03ced9da44f15cfa
mizchi – 経歴スライド (GitHub Pages): https://mizchi.github.io/kyonmm-lt/
mizchi – Frontend Ops紹介 (GitHub Gist): https://gist.github.com/mizchi/b803f6872035248f86309057d6c97ee9
mizchi – いつReactNativeを使っても大丈夫か (2018): https://mizchi.hatenablog.com/entry/2018/06/20/115539
mizchi – Qiita退職エントリ (2017): https://mizchi.hatenablog.com/entry/2017/03/01/153816
PR Times – サンゴテクノロジーズ資金調達 (2023): https://prtimes.jp/main/html/rd/p/000000004.000108088.html
Google – Google Play Best of 2024: https://blog.google/intl/ja-jp/products/android-chrome-play/google-play-bestof2024/
@IT – Baidu IME / Simeji入力データ外部送信問題 (2013): https://atmarkit.itmedia.co.jp/ait/articles/1312/26/news104.html
CNET Japan – バイドゥ、IMEアプリSimejiで入力ログを無断送信 (2013): https://japan.cnet.com/article/35041966/
指摘側が論拠を示すためにリバエンするのは、それこそ利用規約違反のリスクを利用側が追うことになります。リバエンして得た情報は不正な手法で得たものとして法的に拒否することも可能で、そのリスクをユーザーに押し付けるのはおかしいと感じます。論拠を示さなきゃいけないのはむしろ開発側であり、…