Androidアプリの通知をローカルPCへ取り込む（公式APIが無いチャットサービス向け）

公式APIやWebhookが提供されていないチャットサービスから、投稿を自動で手元に集めるための指示書。 先に「その通知が本当に発生するか」を検証する手順を含む（ここを飛ばすと数日溶かす）。

適用条件

• 対象サービスに公式API/Webhookが無い、または対象のチャット種別が非対応
• 非公式クライアントは規約違反・アカウント停止リスクのため使わない
• 対象アプリがAndroid端末で通知を出す

全体構成

Android端末（通知）→ 通知リスナーアプリ → HTTP POST → 手元PCの受け口 → JSONL蓄積 → 夜間要約

外部クラウドを経由させたくない場合、受け口は手元PCに置き、 トンネル（Tailscale Funnel / Cloudflare Tunnel 等）でHTTPS公開する。

---

【最重要】着手前の検証（これを飛ばさない）

「通知が出ているはず」を前提に作り始めてはいけない。 出ていない通知は永遠に取れない。

手順

1. Android端末で開発者オプション → ワイヤレスデバッグを有効化し、PCからADB接続する
2. 通知履歴を有効化する

   adb shell settings put secure notification_history_enabled 1
   

3. 半日〜1日おいてから通知の記録を吸い出す

   adb shell dumpsys notification --noredact > notif.txt
   

4. 対象チャット名で検索し、通知が1件でも発生しているかを確認する

ここで0件なら、アプリ側が通知を発行していないということ。 設定を変えても解決しないので、通知経由は諦めて別方式（履歴エクスポート等）へ切り替える。

通知が出ない代表的な原因（この順で潰す）

層	確認
チャット個別	ミュートになっていないか
アプリ内設定	そのチャット種別の通知トグル。似た名前の別項目に注意（「◯◯のアクティビティ」が参加申請専用で、メッセージ通知ではない等）
アプリ内設定	メッセージ内容の表示。オフだと通知本文が固定文言になり、中身が取れない
Android通知チャンネル	adb shell dumpsys notification でチャンネルごとの mImportance を確認（0ならブロック）
サービス側	大規模グループでは提供元が通知を抑制している場合がある。利用者側では解決できない

本文が固定文言かの見分け方

蓄積したデータの本文の文字数を見る。実メッセージなら長さがばらつく。 21 と 24 のような数種類に固定されていたら、それは「新着メッセージがあります」等の プレースホルダで、中身は届いていない。アプリ側の「メッセージ内容を表示」をオンにする。

---

端末側の設定（通知リスナーアプリ）

MacroDroid 等のノーコード自動化アプリを使う。作るマクロは1つ。

• トリガー: 通知受信（Notification Received）。カテゴリは Device Events
  • カテゴリ名は版で変わるので、追加画面の検索窓に Notification と入れて探すのが確実
  • 対象アプリを1つだけ選ぶ
  • テキスト条件は Any（「絞り込まない」は空欄ではなく Any。Contains のまま空欄にすると保存できない）
  • Prevent multiple triggers は外す（連続投稿が捨てられるため。重複はサーバ側で除去）
• アクション: HTTPリクエスト（検索窓に HTTP）
  • POST / Content Type: application/json
  • ボディはテンプレートを貼ってから、プレースホルダをマジックテキスト挿入ボタン（{ }）から選んで置換する
  • 手打ち禁止。正しい変数名は版によって違い、手打ちすると空送信になる

{"chat":"CHAT","sender":"","text":"TEXT"}

CHAT を「通知タイトル」、TEXT を「通知テキスト」に置換する。

通知タイトルの形式（実測）

サービスによって異なるので、最初の数件で確認する。

• 1対1: 相手の表示名
• グループ: 送信者 [グループ名] や グループ名: 送信者 の形になることがある

サーバ側の照合は部分一致にしておくと表記揺れを吸収できる。

---

受け口の実装要件

公開エンドポイントになるので、以下を必ず入れる。

• 専用トークンで認証。他機能と共用の強い権限トークンを端末に持たせない。 ヘッダとクエリの両方を受け付ける（自動化アプリ側の都合に合わせるため）。 比較はタイミング安全に（ハッシュ化してから固定長比較するのが簡単）
• チャット名のallowlist。未設定なら全拒否（fail-closed）。 対象外のチャットは本文を保存しない——個人的な会話が混ざるため、これは設計の要
• 重複排除: 同一内容が短時間に再送されることがある。 内容のハッシュで判定し、判定はファイル末尾の一定バイトだけ読む（全読みしない）
• サイズ上限（例: 64KB超は413）
• 未展開プレースホルダの検知: 本文に {notification...} [not_...] 等が残っていたら 設定ミスなので保存せず記録する。利用者にデバッグさせず、こちら側で原因を特定できる
• 想定内のスキップは常に200で返す（自動化アプリにリトライさせないため）
• 診断ログに個人名を残さない。対象外チャットは名前を伏せ、 長さやハッシュだけ記録する。探しているチャットを見つけるためのヒント語に一致した時だけ名前を出す

蓄積と要約

• ~/<設定ディレクトリ>/<サービス名>/<YYYY-MM>.jsonl に1行1メッセージで追記
• 夜間バッチで安価なLLMに渡す。前処理でコード側から削る（短文・定型あいさつ・ スタンプ通知・重複）とトークンが大幅に減る
• 分類は判断項目を減らす。真偽値を返させず、スコアだけ返させて閾値で判定する （返す項目が多いほど壊れる）
• JSONモードを使い、パース失敗時は1回だけ厳しい指示で再試行する
• 要約はローリングウィンドウで保持する。その回の分だけで作り直すと、 投稿の少ない日に過去の有用な情報が消える
• 失敗した回は出力ファイルを一切書かない（前回の良い結果を空で上書きしない）

よくある落とし穴

• LLMをスタブしたテストは全部通るのに本番が空振りする。 プロンプトが要求していないフィールドをパーサが必須にしていても、スタブは自分で書くので気づけない。 実際のモデルで1回通して出力を目視するまで完了と言わない
• 止まっても誰も気づかない。取り込みが途絶えたことを検知する仕組みを最初から入れる
• 受け口が開発サーバ運用だとPC再起動で止まる。自動起動にする
• ADBのワイヤレス接続はポートが起動ごとに変わる。初回接続時に固定ポート化するか、 ポート自動探索を用意して、利用者に毎回聞かない

この方式が使えないと分かった時

通知が発行されないなら、履歴エクスポートに切り替える。 多くのチャットアプリはトーク履歴をテキストで書き出せる。 PWAに Web Share Target を登録しておけば、共有メニューから選ぶだけで取り込める。 通知と違い全文が取れ、取りこぼしもないため、そもそもデータとして優れている。