# LINEオープンチャットの投稿を自分のPCに取り込む（トーク履歴エクスポート方式） LINEのオープンチャットに流れる情報を、自分のPCに蓄積して要約・検索できるようにする手順。 スマホから3タップで送るだけで全文が入り、以降は無人で処理される。 **この指示書の価値は「動く実装」より「塞がっている道を全部先に潰してある」ことにある。** 下の §1 を読まずに着手すると、通知転送やAPIの調査に数日溶ける。 --- ## 1. 先に結論：使えない経路（再調査しないこと） | 経路 | 結果 | |---|---| | LINE Messaging API | **オープンチャット非対応**。Bot参加もWebhookも不可。公式経路は存在しない | | 非公式クライアント | 規約違反＋アカウントBANリスク。採用しない | | Android通知の転送（MacroDroid等） | **大規模オープンチャットでは通知自体が来ない**。実測: 端末の通知履歴24時間分を全数確認しても対象チャットは0件。他のトークの通知は正常に届いていたので配線の問題ではない。LINE側が抑制していると判断。設定では解決不能 | | PC版LINEの通知を読む | **Windowsの通知データベースにLINE本体の通知は1件も入らない**（入るのはスマホ連携アプリが中継した公式アカウントのみ）。独自のトーストウィンドウは出現するが、UI Automation で子孫要素の Name/Value がすべて空でテキストが取れない（Qt/QMLがアクセシビリティに公開していない） | | PC版LINEのローカルDB | 暗号化されている。鍵の抽出はアプリの保護回避になり、更新のたびに壊れる | | 画面OCR | 通知は本文が途中で切れる・取りこぼす。壊れやすい | **残るのは「トーク履歴のエクスポート」だけ**で、これはデータとしても最良（全文・取りこぼしゼロ）。 --- ## 2. 全体構成 ``` スマホ: LINEで対象チャットを開く → ≡ → Export chat history → 共有先に自分のPWAを選ぶ ↓ その場で保存完了 /share が受けてパース → JSONL に追記 ↓ 毎晩のバッチ: 未処理分を安価なLLMで選別・要約 → 作り置きを更新 ``` PC版LINEから保存した .txt を監視フォルダに置く経路も同じパーサで受ける。 前提: **自分のPCで動く PWA（Next.js等）を持っていて、スマホからHTTPSで到達できること**。 （トンネルサービス等でPCのローカルサーバを公開する。この指示書はその部分を扱わない） --- ## 3. 入口1: Web Share Target（スマホ経路） ### manifest.json ```json { "name": "<アプリ名>", "short_name": "<共有シートに出る短い名前>", "start_url": "/", "display": "standalone", "icons": [ ... ], "share_target": { "action": "/share", "method": "POST", "enctype": "multipart/form-data", "params": { "title": "title", "text": "text", "url": "url", "files": [ { "name": "files", "accept": ["image/*", "text/plain", ".txt"] } ] } } } ``` **落とし穴（実測）** - `files` に**同じ `name` で複数エントリを書かない**。Chromium が2つ目を無視することがある。1エントリの `accept` 配列にまとめる - `short_name` は共有シートに出る名前になる。**有名アプリと紛らわしい名前にしない**（選び間違える） - **すでにホーム画面に追加済みのPWAには、変更後の `share_target` が反映されない**。共有先の一覧に出てこないので、一度アンインストールして追加し直す必要がある。手順書に必ず書くこと ### 受け口 `/share` 既存の共有機能（画像共有など）がある場合、**壊さないように分岐を足すだけ**にする。 ```js // LINEの履歴らしさを判定。該当しないものは従来のフローへそのまま流す function looksLikeLineHistory(value) { const head = value.slice(0, 2048); return head.includes('[LINE]') && /(とのトーク履歴|Chat history|保存日時|Saved on)/iu.test(head); } ``` - multipart の `files` に `.txt` が来る場合と、`text` フィールドに本文が直接来る場合の**両方**を受ける - サイズ上限を設ける（実測で2MB超・3万行のファイルが来る。20MB程度を上限に） - 認証は既存のものを踏襲する。**共有シートから開かれるので Cookie が乗る**。未ログインだと取り込まれずログイン画面に飛ぶだけになるため、手順書に「先に一度開いてログインしておく」を入れる --- ## 4. エクスポート .txt の実フォーマット **推測で書かないこと。** 実物はこうなっている（Android・英語UIで確認）: ``` [LINE] Chat in <チャット名> Saved on: 8/27/2026, 8:57 PM ← PMの直前は U+202F (NARROW NO-BREAK SPACE) Fri, 3/13/2026 ← 曜日略称 + カンマ + M/D/YYYY（年が最後） 21:01送信者本文 本文の続き（タブ区切りの時刻で始まらない行） 空行をまたいでも同じ投稿の続き 21:08送信者本文 21:22送信者[Sticker] ``` **間違えやすい3点** 1. ヘッダは `Chat history in` ではなく **`Chat in`**（日本語UIだと `<名前>とのトーク履歴`） 2. 日付行は **`Fri, 3/13/2026`**。曜日が先頭、しかも **`M/D/YYYY`（年が最後）**。`YYYY/MM/DD` 決め打ちだと**1行も認識できず、全メッセージが捨てられて無言で0件になる** 3. 本文の継続行は**空行をまたぐ**。空行で切ると本文が分断される ### 日付のパース規則（曖昧さを残さない） - 4桁の数字が**先頭**なら `YYYY/M/D` - 4桁の数字が**最後**なら `M/D/YYYY`（米国式） - 曜日は「括弧付き」「カンマ+略称」「スペース+曜日名」のいずれも許容する - **`Saved on:` 行を日付行として拾わないこと**（これも日付で始まる。曜日側は数字とコロンを含まない語に限定すると分離できる） ### システムメッセージの除外 `参加しました` / `退出しました` / `joined the chat` / `left the chat` / `unsent a message` などの行と、 本文が `[Sticker]` `[Photo]` `[Video]` `[File]` だけの行を落とす。**過剰に落とさないよう完全一致か行頭一致に限る**。 --- ## 5. 冪等性の設計（ここが一番重要） **エクスポートは毎回「表示されている全履歴」を含む。** 週1回送れば毎回9割が既出になる。 - **id を `sha256(チャット + 日付 + 時刻 + 送信者 + 本文)` で作る** - 日時を含めないと、**同じ文言を別の日に再投稿したものが1件に潰れる** - **重複判定は保存済みの全ファイルを読んで行う**。月ごとにファイルを分けているなら全月を読む（月をまたぐ重複を防げない） - 既定で**直近N日分だけ取り込む**（例: 14日）。全期間を入れると要約のLLM呼び出しが跳ね上がる 実測: 2.21MB・31,166行・168日分のファイルで、17,471件を85msでパース。うち直近14日は1,489件。 --- ## 6. 失敗したときに実物が残るようにする（設計原則） **外部が吐くフォーマットを相手にするなら、失敗検体の保存を最初から入れる。** この仕組みでは、実物を見ずにフォーマットを推測して**3回失敗した**。2回目に「解釈できなかったファイルを保存する」を入れたので、3回目で実物が手に入り確定できた。これが無ければ、依頼者に何度もやり直しをさせていた。 - ヘッダが読めない/対象外/解釈0件 の**いずれの場合も、受け取った .txt を `rejected/` に保存する** - 画面には**ヘッダの1行目**と**認識できた日付行の数**を出す。「取り込めませんでした」だけでは何も分からない - 診断ログには**本文を残さない**（ヘッダ先頭数十文字までに留める） --- ## 7. 取り込み対象の絞り込み（プライバシー） 共有シートから何でも送れてしまうため、**対象チャットの許可リストを持ち、未設定なら全拒否（fail-closed）**にする。 ```js // 許可リストの語がチャット名に部分一致すれば通す。戻り値は「許可リストの項目そのもの」 function allowedChat(chat) { const candidates = (process.env.ALLOW_CHATS || '').split(',').map(s => s.trim()).filter(Boolean); const target = String(chat ?? '').normalize('NFKC').trim().toLowerCase(); return candidates.find(c => target.includes(c.toLowerCase())) || null; } ``` **設計上のコツ**: 保存するレコードには「実際のチャット名」ではなく**許可リストの項目名**を入れる。 こうすると実名がディスクに残らず、かつ複数チャットを取り込んでも由来を区別できる。 さらに、この設計だと**ヘッダからチャット名を厳密に抽出する必要がなくなる**。 `allowedChat(ヘッダ行そのもの)` で照合すれば、**LINEのヘッダ文言が変わっても壊れない**。 名前の抽出は補助に格下げしてよい。これが §4-1 の罠に対する本質的な解決策。 **許可リストを広げるのは「本文をディスクに保存する対象を増やす」こと**なので、勝手に足さず持ち主に確認する。 --- ## 8. CLIから使うときの落とし穴 Next.js は route のために `.env` を自動で読むが、**素の `node script.mjs` は読まない**。 共通ロジックをCLIから呼ぶと、許可リストが空になり `allowedChat` が全件 null を返し、 **夜間バッチが全ファイルを黙って拒否する**。CLI側で必要な変数だけ読み込むこと。 同様に、**本番サーバがビルド済みで動いている場合（`next start` 等）、コードを直しただけでは反映されない**。 CLIはソースを直接読むので先に直り、**CLIだけで検証すると「直った」と誤認する**。 変更のたびに**実際にHTTPで叩いて確認する**こと。 --- ## 9. 鮮度の警告と催促 取り込みが「直近N日分だけ」なら、**N日を超えて空くとその間の投稿は永久に入らない**。人に頼る運用なので、能動的に知らせる。 - **「最後に取り込んだ投稿の日時」から経過日数を判定する。** 作り置きファイルの更新時刻を見てはいけない（バッチが毎晩走る限り更新され続け、**入力が枯れても警告が出ない**） - **曜日固定で必ず送るのではなく、実際に空いたときだけ送る。** きちんとやっている人に無意味な通知を送ると、そのうち全部無視される - 同じ状態で毎日鳴らないよう、**再送は数日空ける** - 通知チャネルは「**すでに動いている経路**」を選ぶ。Web Push は購読にスマホ側の手作業が要るので、チャットツールのDM等のほうが早く確実 --- ## 10. テストの注意（実際にバグを隠した例） **fixture は本番が書くレコードと同じ形にすること。** タイムスタンプを ISO 文字列で書いた fixture でテストが全部通っていたが、本番は epoch ミリ秒の数値だった。 存在しない形式に対してテストが通り、**実データ1,489件がある状態で「まだ1件も取り込まれていません」と表示する**バグを隠していた。 同様に、**fixture のテストが通っても実物では0件**ということが起きる（§4）。 外部フォーマットを扱うなら、**実物を1つ手に入れて通すまで「動いた」と言わない**。 --- ## 11. 依頼者に渡す手順（この粒度で書く） システムに詳しくない人が読む前提で、タップする項目はUIの表示言語そのままで書く。 **初回だけ** 1. ブラウザで `` を開く → メニュー → `Add to Home screen` → `Install` - すでに追加済みなら、一度長押しして `Uninstall` してから追加し直す（§3の落とし穴） 2. 追加したアイコンから一度開いて**ログインしておく** **毎回（週1回程度）** 1. LINEで対象のオープンチャットを開く 2. **少し上にスクロールして過去の投稿を読み込ませる** （LINE公式仕様: "Only the messages that currently appear in the chat will be saved"） 3. 右上 `≡` → `Export chat history` 4. 共有先から自分のPWAを選ぶ 5. 「新規 N件 / 重複 N件」と出たら完了 頻度は**取り込みの保持期間の半分**を目安に。保持14日なら週1回（1回飛ばしても間に合う）。 ---